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

Hey everyone,

Sorry about dropping updates for awhile there. Things are still moving forward and a strong pace. We’ve gotten the FFG implementation complete and have begun refactoring the full codebase. We’ve rebuilt HeaderChainHandler and Chainfrags handler and made them much cleaner and simpler. We’ve cleaned up the core package and am working on rebuilding how the node handles the internal chainstate (what’s been called the UTXOset, although it’s a bit more then that now). We plan to use a sparse Merkle Tree to organize on chain state and are looking at using the LazyLedger implementation

We hope to have the chain state rebuild done by early next week and begin moving on to look at finishing off final parts of the refactor and the economy.

In addition, We’ve made some protocol alpha videos! Check them out (1,2,3) on our youtube channel

See you soon.

Hey Everyone,

It’s been a bit between updates, but that’s because we’ve been so busy with the protocol! A major rebuild of the protocol’s handling of chainstate has been completed. Previously, the node made a complete copy of the chainstate every block in order to update it to the new chainstate. This was obviously unsustainable, as the chainstate will continue to grow as the chain matures. As such, a new method of state handling had to be created. In addition, state was organized using a regular Merkle Tree.

Now, the largest parts of chainstate are kept on disk instead of in memory, chainstate can be updated by only getting copying the needed parts from disk instead of upgrading the entire thing, and state is organized using am optimized spare merkle tree.

After finishing off these changes, the last few weeks have focused on cleanup and bugfixing. As we finish this up, we will begin working on finishing off the alpha transaction and node back end features and begin work on the economy.

See you later.

1 Like

This thread hasn’t been updated in awhile, but never fear - work on the Causevest Protocol has continued throughout the end of 2020 and the dawn of 2021. The focus has been adding new user features and preparing for the testnet and eventual mainnet release.

We have created a new accounts system that derives each key from a root passphrase. The node now can sync your account history and get your past incoming and outgoing transactions. We have also begin work on rebuilding the command line interface to make it more user friendly.

Once our current work and a few more cleanup changes are made, we will begin work on the Economy Update and fee system. Once these are complete and the GUI is integrated we will be ready for the first public testnet release. We hope to have that in the first half of this year. Hope to see you there!

1 Like

Hello Everyone.

I take personal responsibility for the lack of updates here. With everything going on it just kept slipping my mind, and I convinced myself that no one reads these anyway. Thanks to those who got me back on the wagon with these updates, so without further ado:

These past few months have seen major updates to the CLI and (now) GUI with a focus on rebuilding and user experience. The protocol itself and alpha-node implementation has also seen some improvements bugfixes and feature updates. Multiple important bugfixes with delegators, accounts reverting vault transactions. Work has begun on Slashing and advanced vault features.

I’ll drop another update in a couple of weeks. See you later

1 Like

I read them also these posts have some of the highest views on the forum :slight_smile: our devs are working hard represent!!! I only want to read about protocol work here. Keep your flashy GUI and CLI talk to the other thread. Talk dirty blockchain/ protocol development here.

Well, it’s been a month, and a lot has happened!

1 Like

Keeping on the trend of making these once a week. Last weeks work was on finish up the p2p library migration (it should be done this week) and on various CLI and Node bugfixes and improvements for the GUI devs.

Next week the p2p integration and testing should be done and the cloud nodes should be up with a new testnet. See you then.

1 Like

Last week saw the merging of the new p2p libraries back into the main master branch of the node repository. Since then we’ve had the cloud nodes running and been fixing problems as they come up. They’re not perfectly stable right now, but things are improving and by this time next week they should be running smoothly.

We are focusing on node improvements and new CLI RPCs needed for the GUI this week.

1 Like

Hello,

These last couple of weeks has seen the following improvements:

  • Bugfixing the p2p networking to properly use incoming connections
  • Added the removecause rpc that allows Causes to be removed from the cause set. In the future this will possibly be expanded to causes having a donation cap or time limit.
  • Created the headerMergeRequest p2p struct that allows a node to find all the headers from the most recent finalized checkpoint to the header in a single quick call.
1 Like

Everyone.

This has been an interesting summer. I went on a vacation to see my family and got to spend time on the beach. Work has still been churning through this. Since the last update, much has been done:

  • The construction of the p2p datashare. This is a way to share non-consensus critical data (so not on-chain) over the p2p network. For example. Think about the description or cause name. These do no need to be on chain, but need to be available.

  • The transaction index - this gives the user an efficient way to query any arbitrary confirmed transaction quickly. Effectivly, it makes it easy to look up past transactions.

  • The validator engine has been built for the keychain. This allows generating finality using the command line. At initial release, we are planning on only having finality generation be available through the command line, as it is an advanced feature.

  • The Sparse Merkle Tree (SMT) forked from the Celestia project has been updated to its latest version. This allowes the proper pruning of deleted leaves from the SMT, vastly improving sync times and scaleabitliy.

Any many more. Currently we’re working on fixing a few bugs with the p2p network that cause memory issues. Till next time.

1 Like