Starting Fulltime Work on the Causevest Protocol!

Another weekly update:

This week I make syncing much faster and more efficient by upgrading the p2p network to allow multiple blocks and headers to be requested at once, allow the header handler to send multiple headers in one request, and allow the database to load multiple blocks in a single pass. I also created a database handler that interfaces with the database to replace the old sync.mutex locking mechanism I had before. All in all it syncs much faster now.

I have also created a random txn generator to begin populating the network with transactions. However, after building this, I found a couple of bugs in transaction processing that I have to fix. Once those are taken care of I will be able to begin testing the network under load.

Beyond that, I want to make a proper difficulty adjustment algorithm so I can control the average block time and begin figuring out what the optimal throughput for a node might be. I also need to think about how I will implement the Causevest specific features.

See you next week.

1 Like

Weekly Update:

I’ve been working on debugging transaction generation and chain reorganizations this week. I’ve got the system accepting txns and able to reorg the chain with txns in it without crashing the node or having issues with the UTXO set. There are still some problems I’m running into, but as I move forward I will be making tools that audit the chain to squash any more bugs that I might run into. This next week will be cleaning up anything I missed from last week and starting dynamic difficulty adjustment and other tools necessary to bring the full chain into reality.

Talk to you next week,
Ben

1 Like

Whoops I missed an update last week, but no worries, progress is still steaming along.

These last couple of weeks have led to the creation and implementation of the difficulty adjustment algorithm (DAA). After some testing, I’ve decided on using the ASERT DAA described here (with a similar RTT also shown). I ran the test by simulating 100,000 blocks and taking statistics of the difficulty and block time.

diff_vs_time

Once I had decided on the correct form of the DAA, I implemented it in the node using an integer only scheme to make sure the nodes are consistent and no errors arise due to numerical error of floating point math.

Once I finish final testing, I will be ready to move on and start building other parts of the protocol, such as multisig, vaults, voting and economics.

1 Like

Trying to keep on track with weekly updates for now, lets talk about last week.

This last week I tested the difficulty adjustment algorithm with random transactions. I also built new functions that allow for even faster node synchronization and which should increase node stability. I have been able to run the nodes for a few days without major issues, although it does look like one crashed today.

For the next week, I want to begin on the infrastructure of the Causevest specific features. In particular, I want to look at how vaults, multisig, and voting transactions will be structured and implemented. I origonally was going to copy Bitcoin’s scripting language, but I now thing that is a mistake. It is both too complicated, and unable do important functions (vaults) simply. I will work on building a system that covers the main points without too much overhead.

See you next week!

1 Like

I’ve been a bit slacking on updates, but not on work. I’ve got a new video out that showcases what I’ve accomplished over the last 6 months. I’ve also been working on the vault feature, and now have a complete technical plan on how to proceed with their implementation. That should be done by next week. Once vaults are implemented, I will likely begin work on finality or voting, and after that streamlining the UTXO set interaction.

So without further ado, the video!

1 Like

but not on work >.> … is that sooo

Hey Everyone,

For this update - we’ve gotten vaults implemented and working - you can send coins to a vault address and revert txns that unvault within the specified time period. Unvaulting txns cannot be used for staking or as inputs to any other txn until the unvaulting period is complete, at which point they become irreversible. Each vault address has a hierarchy of keys when created, such that keys can revert txns of an equal or lower level then themselves only. This means that if you have a transaction created by a level 2 key it cannot be reverted by a level 1 key, but a transaction by a level 3 key could revert it.

This feature allows for superior security and user experience. The user can keep a level 1 key (called a spend key) unencrypted for easy use, and if the key falls into the hands of an attacker, they can use a higher level key that was more strongly secured to reverse the transaction and save the coins.

Now, we am moving on to creating voting at the protocol layer - this with allow anyone with coins to vote on a hash that could represent everything form a cause to a delegator. This will allow people to signal with XCV.

Talk to you later

1 Like

This weeks update:

We now have basic implementations of voting as well. With these base implementations, we can begin to work on the economic parameters and make sure every interaction with the Causevest protocol is rewarding.

Implementation work on finality (specifically, Casper FFG) is ongoing and we hope to have a working implementation in a week or so. Once finality is implemented the code will need to be refactored and optimized, but aside from the economic parametrization, the protocol alpha will have all of it’s major features. Work on the GUI and the beta is coming soon.

See you next week!

1 Like