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

Get Ethereum smart contract version from Storage #249

Open
Tracked by #2023
sug0 opened this issue Aug 1, 2022 · 2 comments
Open
Tracked by #2023

Get Ethereum smart contract version from Storage #249

sug0 opened this issue Aug 1, 2022 · 2 comments

Comments

@sug0
Copy link
Collaborator

sug0 commented Aug 1, 2022

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:

  1. We can have a getter field in the smart contract that returns its version.
  2. 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.

@sug0
Copy link
Collaborator Author

sug0 commented Aug 8, 2022

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.

@sug0 sug0 closed this as completed Aug 8, 2022
@sug0
Copy link
Collaborator Author

sug0 commented Jul 18, 2023

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant