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 Bridge.sol smart contract contains a version 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 in Storage, which will be fetched at the end of an epoch to sign the new validator set.
Additionally, the Governance.sol smart contract has a version field of its own, separate from the one present in Bridge.sol. Thus, in our code, we would need, e.g. some Storage::get_bridge_contract_version and Storage::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:
We can have a getter field in the smart contract that returns its version.
We can gossip an Ethereum event after a version update, and modify our local 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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: