Open sug0 opened 1 year ago
We will not need this after all. The version of the smart contract was only being signed together with the vote extension to guarantee monotonicity of sequence numbers across contract upgrades. The contract is now being initialized with a sequence number (the epoch), so it's not required to sign over version fields.
We're using version fields in Ethereum signed messages. They're currently hardcoded to 1, but we should look them up from storage. Upgrades to contracts can be delivered via governance proposals, updating the appropriate storage keys (contract address + version).
The
Bridge.sol
smart contract contains aversion
field, which is updated with every contract upgrade. Validator set updates are signed together with the version of the contract. Therefore, in the ledger, we should keep track of this value, probably inStorage
, which will be fetched at the end of an epoch to sign the new validator set.Additionally, the
Governance.sol
smart contract has aversion
field of its own, separate from the one present inBridge.sol
. Thus, in our code, we would need, e.g. someStorage::get_bridge_contract_version
andStorage::get_governance_contract_version
methods.As for the mechanism to synchronize these
version
values with the smart contracts, there are two ways to go about it:version
value at the FinalizeBlock stage, after a vote extension has been decided with the given event.Getter fields in smart contracts don't spend gas, so option 1) is probably the best method to follow. However, we need a certain number of blocks as confirmation before we can use this value.