search

stellar / rs-soroban-env

Rust environment for Soroban contracts.
Apache License 2.0
59 stars 40 forks source link

Allow the contract used for settings upgrades to be verifiable #1362

Closed sisuresh closed 4 weeks ago

sisuresh commented 5 months ago

We would like to verify the contract used to write the Soroban settings proposal using https://www.sorobanexp.com/contract/dashboard. This tool expects a specific structure that our contract directory doesn't follow (the makefile is at a higher level). I'm guessing that the wasm file is also expected to be written to a specific location.

sisuresh commented 5 months ago

This should be fixed before our next settings proposal. I think an easy solution would be to copy it into the example repo, and update the core command line tool to take an optional wasm hash to skip the contract upload. This would allow the util to use a wasm built outside of test wasms.

leighmcculloch commented 5 months ago

+1 anything we're building and executing on chain should be verifiable.

copy it into the example repo

The example repo is targeted at contract developers, where-as this contract is rather unique and is only used by network/validator operators. So I think it'd be distracting to bundle it there.

The layout of the repo doesn't seem that odd, so I think we should work with sorobanexp.com folks to make it more flexible for different directory structures. Folks are going to have a variety of directory structures, and as long as the default rust tooling can build a contract, hopefully a verification tool could support it.

In regards to urgency to get this contract verified, it doesn't seem urgent because validators voting on the settings contract data ledger entry don't need to trust this contract because they're voting on a specific contract data entry. Any contract can write the data entry and no one has to trust the contract that writes it.

sisuresh commented 5 months ago

Yeah good point. The protocol will not accept a tampered upgrade, so this isn't urgent. We need to figure something out with the current contract though because the test-wasms use a local patch for the sdk, so the toml file may not be enough. You mentioned a new repo for the upgrade contract offline, which is a clean way to solve this.

sisuresh commented 4 weeks ago

I'm closing this because the upgrade contract is irrelevant - the protocol does not allow a tampered contract data entry for the upgrade.