Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement native Golang consensus module instead of sfc contracts system #122

Open
trinhdn97 opened this issue Nov 21, 2024 · 0 comments
Open

Comments

@trinhdn97
Copy link
Contributor

The theme is maintaining a separate, standalone consensus KVDB. After dumping storage of SFC, NodeDriver and NodeDriverAuth contracts to KVDB, we will implement native Golang logic to operate consensus actions on top of this DB.

For the first phase of development, this whole native flow will run along with the current SFC contract as a non-breaking feature. It means when encountering a consensus action such as (un)delegating/withdrawing, finalizing EpochState, etc. some nodes will interact with consensus contracts and modify the consensus DB at the same time. This dual process enables us not only to evaluate the correctness of the native consensus protocol, compared to the SFC contracts’ behaviors, but also to benchmark the performance differences between them.

After testing and running along for a long enough time, we will get rid of 3 contracts to use the native consensus module only, by a hard fork for all the network.

Plan A (preferred) Plan B
SFC contract storage migration Simply iterate the whole contract storage to get all storage slots at the latest block state #111. Feed the list of all validator/delegator addresses, maybe from staking subgraph as mapping keys, to retrieve and restructure the consensus DB.
Consensus DB design Must follow the storage trie structure of an U2U account. Store a dump of the storage tries of SFC contracts at latest block state. Flexible to design a more human readable, key-value or even SQL schema based on our requirements, including the full list of validator/delegator addresses from the start.
Consensus DB getter/setter Need to self-calculate the storage slot needed to retrieve/update/aggregate data based on smart contract storage layout. Just CURD the database designed above.
Native Golang consensus logic implementation Port every solidity function to Golang. Each function will use corresponding getters/setters and store the state diff in its consensus DB, just like the EVM call behaviors. Port every solidity function to Golang. Each function will modify the custom consensus DB as a form of DB transaction.
Disadvantages Still need a 3rd-party service like subgraph to index staking data. The ETH storage trie structure isn't capable for querying or self indexing when we don't have the full list of validators and delegators. Hard to double check the correctness of our native logic in the experiment stage. For plan A we just need to compare the root of native SFC storage trie and the current SFC contract one.
Hard to input the required all validator/delegator addresses at the dump command.
We also need to define a method to quickly verify the integrity of the consensus DB between nodes. Can't inherit the trie root check like plan A.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant