Deploying the Blobstream contract if no valset is in store

[rach-id]

Currently, if the network is stable for more than 3 weeks, we will not be able to deploy a Blobstream smart contract until there is a change of 5% in the validator power. This is because the last valset in store would be pruned since we prune attestations that are older than 3 weeks.

Also, the existing relayers will fail because they will not be able to find a valset in state to compare the signatures against and send it as call data to the Blobstream contract.

Proposal 1: calculate current valset

We calculate the current valset and deploy the Blobstream contract using it.

Pros

Deploy the Blobstream contract anytime even if there are no valsets in store.

Cons

Two Blobstream contracts might have the same valset. In fact, we create a new valset when there is a change > 5% in the valset. If we have, for example 4%, then we keep using the same valset. So, if there was a change of 4%, and we calculate the valset ourselves and use it to deploy the contract, it will have a different hash.

This doesn't mean that the commitments to data will change, or anything. It only means that if we compare two Blobstream contracts, we might find a different in the valsets they're reporting to.

Also, this does that the Blobstream contract will be attesting to a valset that wasn't created by the state machine.

Another big drawback to this would be for relayers that are already running. Once the valset is pruned, they would be using the current valset, which can have a different hash => halt.

Proposal 2

We store the latest valset in the Blobstream P2P network and query it when needed.

This means that for relayers, they will first try to get the valset from the state machine, but if they fail, they will fall back to the P2P network to get it. Then, they would use it to continue relaying events. If the valset is malicious, then the Blobstream contract will reject the updates and the bridge will halt.

For newly deployed contracts, we could provide a prompt stating:

No valset found in store, using valset from P2P network. This valset is untrusted, do you wish to continue to deploy the contract?

And a bridge deployed using a compromised valset can lead to attesting to invalid data. So not sure if this is worth it.

Pros

Existing relayers will continue functioning.

Cons

No new trusted deployments of the contract can occur if there is no valset in state.

Proposal 3

Add a new key in state containing the last valset. This would be a breaking change and can be included in v2 upgrade. But now, we can't add it.

Pros

Would save us from the gymnastics defined above.

Cons

None.

Decision

Proposal 2 makes most sense for now, and we can wait for v2 to implement Proposal 3 and get rid of all this complexity.

Fall back

A fallback for these situations would be to use an archive node, but it's better to fix this not to force validators to run archive nodes or trust others.

[rach-id]

cc @evan-forbes @adlerjohn

[evan-forbes]

thanks for writing this up

imo, if we document the edge case that archive node is required to retrieve the older valset, that is also an option.

[rach-id]

imo, if we document the edge case that archive node is required to retrieve the older valset, that is also an option.

Isn't the Fallback section referring to that? or you mean we should add it as a proposal?

[evan-forbes]

which fallback section?

[rach-id]

?

[adlerjohn]

No new trusted deployments of the contract can occur if there is no valset in state.

This seems fine because the blobstream contract can be checked for correct initial state out of band, right?

[rach-id]

This seems fine because the blobstream contract can be checked for correct initial state out of band, right?

Yes, the initial state can be taken from some other trusted Blobstream deployment