Starting Fulltime Work on the Causevest Protocol!

Causevest XCV Development & Technical Discussion
#18

Time for another update! The alpha testnet is tantalizingly close: I’ve completed and tested the code for long lived TCP connections and node communication has become much more stable and responsive. However, there does seem to be one major issue preventing the alphanet from working: it seems there is some kind of memory issue in the program that causes it too use far too much memory after a short time running. My next order of action is to understand why this is happening and fixing it. Once this is taken care of, I think the alphanet will be ready for full time running.

After the alphanet is up, I will move to adding the Causevest-specific features we need to complete the alpha and begin working on the GUI and beta.

See you next week!

1 Like
#19

Looking forward to progress next week

#20

This weeks update:

My work on the nodes has made them much more stable, I left 3 running over the weekend and by Monday two were still up and responding normally (with 1300 blocks produced!). Next, I will begin automatic transaction generation so that there is load being placed on the network. I’m sure this will uncover new issues that will have to be dealt with, but by the end of the week I hope we can last next weekend with blocks full of transactions.

1 Like
#21

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
#22

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
#23

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
#24

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
#25

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
#26

but not on work >.> … is that sooo

#27

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
#28

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
#29

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.

#30

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
#31

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
#32

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
#33

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.

#34

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

1 Like
#35

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
#36

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
#37

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