Explore

Integration of Gnosis Safe usage into Sequencer.

Basic flow description.

The sequencer currently checks each reported value’s signature before accepting it from a reporter. Once this check passes correctly, the sequencer only stores the value in the container space determined for the given reporter. We need to change this and preserve the entire report received + the signature. This will enable us during the second phase of the consensus to send all the data used to reach an aggregated value for a feed ID to the reporters for validation and generation of signature share. The signature share is collected on a Gnosis Safe transaction, containing in itself the batched feed keys/values. This transaction must contain a nonce set by the user – the Sequencer. In the new flow, after each time slot for batching aggregated values, the sequencer will not send directly to our contract the aggregated batched values, but instead send them to each reporter for processing as mentioned above. The sequencer might have to give a time frame in which the reporters must return their confirmation, and in case quorum is not reached the batch needs to be dropped and not further propagated. This is needed, because the Gnosis safe has a nonce counter and we cannot post transactions in parallel to it.

Packet sent to reporters for validation and signature during second phase:

⁠

Happy path:

⁠

From the diagram we see that the sequencer has to set the nonce for Gnosis safe when initiation of signature shares collection starts. Thus a question arises what the desired behavior should be in the case when Batch1 is not processed yet by the Gnosis contract, but a Batch 2 is ready for signature shares collection. • One solution would be for the Sequencer to remember the in-flight transactions and set the Nonce to be +1 to the last in flight transaction. This might be problematic, because those transactions might be included in a block out of order in a given network and some will get invalidated. • Another way to proceed is to set the Nonce always to be the next expected by the contract. This implies that if Batch1 is not processed by the contract in a timely manner, Batch 2 might overwrite it, because now both will be competing for the same Nonce. From the above description it becomes obvious that the batch collection / block generation time is now restrained to values sufficiently large to minimize this possibility.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.