QGB decide on keeping the history of attestations

[rach-id]

With the #657, the Valset/DataCommitment confirms will be kept as transactions. However, the attestations, i.e ValsetRequests and DataCommitmentRequests will be pruned. We can also think of a similar design for attestations and dump them in a block to preserve the whole QGB history.

[evan-forbes]

oh shoot, totally forgot about this, good thinking!!

Perhaps we could add them to PrepareProposal as transaction types. If we did that, we would also want to include an additional check in ProcessProposal to ensure that they are correct given an honest majority.

This will likely depend on our slashing mechanism(s) as well #332

[rach-id]

Agreed, do we need to specify this now, or we can leave it for later?

[evan-forbes]

imo we should leave this for later, as it seems likely blocked by our slashing mechanism.

Which also means that the amount of pruning that we need to do is also blocked by our slashing strategy

[rach-id]

Sounds good, I will keep it as part of QGB 2.0 tracking issue. Thanks a lot for your help

[evan-forbes]

to update this, we have to decide if we want the whole QGB history bad enough to make it consensus critical. This would mean adding the attestation requests to the block data during prepare and process proposal.

@sweexordious mind elaborating on the benefits of having this be consensus critical? per sync discussion

• It would allow us to not bloat the state machine while also preserving the entire history so that new QGB constracts could load all data

cc @adlerjohn

[rach-id]

Thoughts: The benefit of dumping the QGB state to block data and making it consensus critical will enable relayers to sync from genesis for any new QGB contract.

The problem is, will we have the confirms available?

Since, in the new v2 design (v3 is different), we're going for a P2P network to gossip the confirms. If we want to suppose that the confirms will be available, we will need to make assumptions like:

• The orchestrators and probably some relayers will preserve the whole QGB confirms since genesis. And are willing to share it with the network.
• Or, assume that some third party service will save the confirms and serve them subsequently

If not, then dumping the attestations to block data is meaningless. Since, we won't have access to the confirms on the P2P layer.

However, since we're submiting the data to EVM chains, we may be able to recover the call data, and decode the confirms. Or, even without decoding them, just replaying the same payload to any other target EVM chain.

If we assume the latter, then, even the attestations history doesn't matter. Since, redeploying the QGB to another chain will be just replaying the transaction history from another already-deployed QGB. Thus, the only assumption in this case is: a QGB has already been deployed to some EVM chain.

[evan-forbes]

Thus, the only assumption in this case is: a QGB has already been deployed to some EVM chain.

yeah 💯 !

[evan-forbes]

can we close this issue? cc @sweexordious

[rach-id]

sure, thanks a lot