This document outlines a plan for an MVP for threshold-encrypted sequencing on Gnosis Chain. The objective is to enable front-running protection and to strengthen anti-censorship guarantees. The design philosophy behind it is to make strong trade-offs to minimize implementation effort, security risks and UX changes, while still ensuring a realistic path towards a complete solution exists.
The following entities participate in the protocol:
During a setup ceremony, the keypers run a DKG process for an identity-based encryption scheme, outputting an eon key which is published. Users wanting a transaction to be protected use this key and the block number in which the transaction shall be included to encrypt it. Alternatively, they send the transaction in plaintext to a trusted JSON RPC endpoint who does the encryption for them. To schedule it for execution in a future block, the encrypted transaction is sent to a smart contract called the sequencer.
Once the parent of the inclusion block has been proposed, the keypers generate the decryption key. The proposer of the inclusion block queries the encrypted transactions from the sequencer contract and waits for the decryption key from the keypers. They will then decrypt the transactions and build a block. This block must contain the valid decrypted transactions at the front and may contain standard transactions from the mempool at the back. The validator may still outsource block production to builders/relays as long as they follow the same protocol.
https://www.figma.com/file/7Zbhn5CwF8RDoMwEtpb3DX/Shutterized-Gnosis-Chain?node-id=0%3A1
Here we describe the individual participants and their responsibilities in more detail.
The keyper set is managed by a contract on Gnosis Chain. Its owner can define new keyper sets that become active at specified activation block numbers.
Before a keyper set becomes active, it has to generate the eon key. They do so off-chain. To publish the eon key, the keypers send it to the eon key broadcast contract which authenticates it via signatures of the majority of keypers.
After each block on Gnosis Chain, the keypers generate the decryption key for the next block. The key is broadcast on a p2p network.
The encrypting RPC endpoint provides the standard Ethereum JSON RPC interface. The only difference is the endpoints that send transactions: Instead of sending them plain text, the endpoint encrypts them for some slot in the future and sends them to the sequencer contract.
Validators who want to participate in this scheme would register in a smart contract. It would become their responsibility to include sequenced transactions according to the commitment, provided they are valid. No changes to the client implementation itself would be necessary: An external program connecting through the builder API would suffice. Validators may still outsource building the block to builders, as long as they follow the commitment as well.