emailtovamos
commented
2 years ago Each leader epoch, the FTSO data providers vote on the share of block generation each registered Flare leader has on his respective chain. This system is built in Solidity, so the information is held in a smart contract.
Would it be, in theory, possible to have the above done in Go as opposed to in Solidity/Smart Contract? If yes, what does the above has in terms of advantage?
-
take a hash of the parent block, so that we can disambiguate between blocks at the same height.
Is there certainty that parent blocks don't have any ambiguity?
-
we need to inject an additional component into the windower upon initialization,
Which part of the code is it referring to? When we create the windower struct or something else?
awfm9
In Flare, blocks are created by underlying chain validators, with the set of underlying chains being determined by the available FTSO assets. Each leader epoch, the FTSO data providers vote on the share of block generation each registered Flare leader has on his respective chain. This system is built in Solidity, so the information is held in a smart contract.
That being said, the Go portion of the system has to read the leaders from a smart contract and use them when sampling leaders in Avalanche consensus. This is complicated by the fact that the leader selection logic is as far removed from the EVM layer as possible, happening on the level of the Avalanche code base, while the EVM is executed deeply nested within in a binary plugin.
In order to expose the leaders, as found in the smart contract state, to the leader selection logic, we need to take the following steps:
Modify the windower of the sampling logic to take a hash of the parent block, so that we can disambiguate between blocks at the same height. This is not relevant when validators are held in the P-Chain state. In our case, the validators are held in the C-Chain state, so we need to handle ambiguous block heights, where validator sets might differ between one branch and another branch of the blockchain.
Remove the P-Chain height from the windower parameters, and instead use the block ID (which corresponds to the block hash at the EVM level) to retrieve the set of validators. In order to do so, we need to inject an additional component into the windower upon initialization, which wraps around a plugin API, which takes the block hash as a parameter, and returns the weighted list of validators at this block hash.
Create a plugin client and a plugin server using the Hashicorp GRPC plugin system, in its new namespace, which will be injected into this new component. It should exist in parallel to the VM namespace used by the Avalanche code base, so that we don't need to modify any of the existing interfaces.
On the Coreth side, where the GRPC plugin is initialized, we should create a secondary wrapper, which takes the VM pointer as a dependency, and uses it to extract the blockchain. This in turn allows us to create the necessary EVM context to execute our contract call to read the leaders when given a block hash.