You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: