This is a guest post published by The Shutter Network.
We just deployed the contracts and activated a Keyper network for the Shutterized Gnosis Chain on the Gnosis Chain testnet Chiado.
This deployment represents a key milestone for an encrypted mempool for the Gnosis Chain using Shutter in a collaborative effort with the Gnosis and Nethermind teams. This collaborative effort aims to bolster front running protection and reinforce anti-censorship guarantees. It's also an excellent occasion to properly introduce the Shutterized Gnosis Chain and talk more in-depth about its architecture.
Accessibility, base layer neutrality, and censorship resistance form the basis of the value proposition of public blockchains like the Gnosis Chain and Ethereum. We believe an encrypted mempool is a critical requisite and a significant milestone toward ensuring those fundamental properties.
By focusing on minimizing implementation efforts, security risks, and user experience changes, we lay the groundwork for a better infrastructure that's more economically sustainable, safer, and easier to navigate for everyone.
Also, if you're a Shutter Keyper, let us know if you want to become a beta tester for this!
A Simple Overview
The protocol involves several key players:
- Gnosis Chain validators/block producers
- A sequencer contract
- A set of 21 Keyper nodes
- A new JSON RPC endpoint
The process begins with Keyper nodes generating an encryption key during a setup ceremony. Users seeking to protect their transactions use this key to encrypt them or can send the transaction in plaintext to a trusted JSON RPC endpoint, which handles the encryption. Encrypted transactions are subsequently sent to a sequencer contract, which schedules them for execution in a future block.
When the encrypted transactions are ready for inclusion, Keyper nodes generate a decryption key. The validator proposing the inclusion block retrieves the encrypted transactions from the sequencer contract and awaits the decryption key. After decrypting the transactions, the validator constructs a block containing both decrypted and regular transactions. The order of the encrypted transactions is determined by the sequencer contract (at inclusion time before the decryption), and regular transactions can only be included afterward. This is what prevents front running transactions.
Benefits to Users
We think by adopting an encrypted mempool, Gnosis Chain (and other beacon chain-like L1s) become better, more neutral base layers and validators, DEFI dapps on top as well as their users can gain the following benefits:
- Safer trading for DEFI users (no front running)
- Added (real-time) censorship resistance
- More profitable trading for DEFI users (because less value is lost due to malicious MEV)
- Validators can plausibly argue that they no longer have the ability to front run transactions nor censor transactions based on their content by design (potential compliance, image, and regulatory benefits for the sequencer operator)
- Validators and/or the chain at large still retain the ability to collect or distribute back-running related MEV (arbitrage and liquidations).
Why Sustainable Market Architecture Matters
The rising popularity of Ethereum's open finance (DeFi) ecosystem has led to an increasing amount of maximal extractable value (MEV). Unfortunately, it has also exposed the network to potential exploitation through front running and other MEV-related tactics, which can deter prospective investors and traders. Furthermore, the measures put in place to manage this issue have proven to be suboptimal, introducing unnecessary trust assumptions and centralization factors. For instance, MEV relays, though beneficial for market health, require a high degree of trust, making them unsustainable in their current form. An effective approach to transaction ordering and inclusion is required to unlock the billions in side-lined investment and ensure Ethereum's long-term base layer neutrality.
Malicious MEV and Censorship
Front running and malicious MEV extraction pose significant threats to Ethereum's ecosystem. Front running involves the unethical practice of a broker executing orders on a security for its own account while taking advantage of knowledge in advance of pending orders from its customers. On Ethereum, this has resulted in a measurable amount of value extraction from users. Unfortunately, MEV relays introduced as a solution increase centralization risks due to the required high degree of trust.
This tendency to centralize parts of the transaction supply chain infrastructure not only adds censorship vectors but also facilitates actual censorship on the protocol level, as evidenced by instances of adherence to sanctions lists such as the Office of Foreign Assets Control (OFAC) list.
Understanding the Key Players
Let's delve deeper into the roles of the participants in the process:
Keypers
Keypers manage encryption and decryption keys. A contract on the Gnosis Chain governs them, and their owners can designate new Keyper sets activated at specific block numbers. Keypers generate and publish the encryption and decryption keys for each encrypted transaction on the Gnosis Chain.
The work on this segment is divided between several teams. The Shutter team is responsible for the Keypers and their node operations, the Key Broadcast Contract, the Keyper Set Manager, and the Encrypting RPC Server. The Gnosis team is accountable for the Sequencer Contract and the Validator Registry. And the team behind Nethermind is working on the Validator operations.
Encrypting RPC Endpoint
This endpoint offers the standard Ethereum JSON RPC interface with a twist: instead of transmitting plaintext transactions, it encrypts them for future slots and forwards them to the sequencer contract.
Validator
Validators participating in this scheme register in a smart contract, making them responsible for including sequenced transactions according to the commitment, provided they are valid. Validators can still delegate block building to builders as long as they adhere to the commitment.
Sequencer Contract
The sequencer contract serves as an inbox for encrypted transactions. Users can submit transactions as calldata, annotated with the block number for which they have been encrypted.
In the future, the contract may calculate a rolling hash over them by block number to enable the generation and verification of inclusion proofs.
The Architecture in a Nutshell
At the start of a slot whose assigned block producer has registered in the validator registration contract, the Keyper set generates the decryption keys for a slice of encrypted transactions in the sequencer contract's transaction queue. The slice starts with the first transaction in the queue that has not been decrypted for an earlier slot. The length of the slice is as long as possible without the sum of the transactions' gas limits exceeding the encrypted gas limit, a system parameter.
Each Keyper derives the decryption key shares from their secret share and the identity values of the transactions in the slice. The shares are broadcast, and once they receive them from at least threshold Keypers, anyone can aggregate them to derive the decryption keys for all transactions in the slice.
In addition, the Keypers also generate an aggregate signature of the start and the end of the slice of transactions to decrypt, i.e., for which transactions the decryption keys are. Both key (shares) and (individual) signatures can be sent in one message, resulting in no additional round trip.
Upon receiving the decryption keys and the aggregate signature from the Keypers, the block producer fetches the transactions to decrypt from the sequencer contract and decrypts them. Subsequently, it builds the block by adding transactions one by one in the order given by the decryption key message. Transactions that fail to be decrypted, that have a different hash or gas limit from what was specified, or that would make the block invalid are not included. The rest of the block can be filled at will.
Taking a Practical Approach
Starting with an "opt-in" approach: Instead of forcing all users to adopt the encrypted mempool immediately, we are initially making this a voluntary option. This approach allows us to test and improve the system iteratively while still delivering value to early adopters.
Developing an Encrypted RPC Endpoint: We are developing an encrypted RPC endpoint to expedite the implementation. Users can send transactions to this endpoint in plaintext, which handles the encryption. This effectively reduces the burden on users to perform the encryption themselves.
While these steps allow us to ship a working version of the encrypted mempool quickly, they have downsides. For instance, relying on an RPC endpoint to handle encryption could pose a security risk if compromised. Additionally, the opt-in approach may lead to low initial adoption rates. However, we plan to address these issues by developing client libraries for local encryption and making the encrypted mempool mandatory for validators.
A Collaborative Effort
The implementation of the Shutterized Gnosis Chain is a collaboration between three teams: Shutter, Nethermind, and Gnosis.
Shutter Team: Manages the Keypers, Key Broadcast Contract, Keyper Set Manager, and currently the Encrypting RPC Server. Their responsibilities revolve around key generation, key management, and transaction encryption.
Nethermind Team: Takes charge of the Validators, oversees block production, and manages validator registration.
Gnosis Team: Oversees the Sequencer Contract and Validator Registry, handling encrypted transactions submission and validator registration, respectively.
Each team plays distinct and critical roles to ensure the chain operates efficiently and securely.
Comparison to Other Encrypted Mempool Approaches
The threshold encryption for the Shutterized Gnosis Chain ensures the privacy of mempool transactions. This approach strikes a good balance between security and technical feasibility.
In comparison, the other alternatives have some caveats:
- Centralized front running protection services, like Flashbots Protect, may be useful temporary solutions but are ultimately less desirable due to their reliance on trust in a single entity.
- Some proposed protocols depend on trusted hardware such as Intel SGX. However, frequent vulnerability reports raise concerns. Moreover, users would still need to trust the chip manufacturer even if they were more secure.
- Time-lock encryption based on Verifiable Delay Functions (VDFs) is another potential option. Custom ASICs are necessary to guarantee robust security against advanced threats, but they are expensive to develop and produce. The time-sensitive nature of VDFs also presents its own set of protocol design challenges.
- Advanced forms of MPC and FHE are exciting developments but aren't cost-effective, or practical today. That being said, these are the most likely candidates for future iterations of the encrypted mempool.
Potential Other Shutter Use Cases
Beyond its usefulness for front running and censorship protection, Shutter also has the potential to bring other improvements to the Gnosis Chain ecosystem.
Shutter's utility spans a variety of use cases. For instance, in voting protocols like Snapshot, Shutter-enabled shielded voting ensures a level playing field and information symmetry by encrypting the real-time voting results.
Gaming is one of those with vast potential. Strategy games like DAOplomacy that utilize turns need a way to keep the players' actions hidden until it is time to reveal them all at once. Game developers could also create systems related to in-game items or interactions with the game worlds.
Also, new NFT launches - which are notoriously prone to front running - could be protected by Shutter, e.g., by implementing it into an NFT launchpad.
And a fascinating use case could be time-locked public disclosures. A Shutterized document disclosure system could be used for (legal) situations like timed publication of documents that need to be announced ahead of time. Or with timed access to documents that are considered time-critical for stakeholders. With the system, the knowledge of the published information would remain protected from third parties prior to public release or be accessible as soon as allowed for parties with limited access.
Future Enhancements
To further improve security, we plan to:
- Implement slashing for validators who either fail to include sequenced transactions or include them in the wrong order. However, other means should also be explored, such as integration into the base protocol.
- Develop client libraries and wallet integrations for local encryption instead of relying on an RPC endpoint.
- Integrate the Keyper set, key generation, and sequencing into the base protocol, making validator participation mandatory.
By introducing encrypted sequencing on the Gnosis Chain, we aim to enhance transaction security for all.
What did we deploy, and what’s still missing?
The Alpha Keyper Testnet that has been deployed this week consists of two major components: A set of contracts and three keyper nodes. The contracts can be found at the following addresses on Chiado:
- Keyper set manager: 0xAb7ca51926d9F3e75BC4200B50D4A1367b7036df
- Keyper set: 0x0C0E819fD16dE36DCDeCf8D43BA7518b2E6E25e7
- Key broadcast contract: 0xdE436c4f17f4B3AB7eAEaf2977DFF71FA34DD8aD
- Sequencer contract: 0x0F4a2952f26390264581E0AE0c8A245d4C7A8194
- Validator registry: 0x0C0E819fD16dE36DCDeCf8D43BA7518b2E6E25e7
The keypers are hosted on a server for now. They have successfully performed the encryption key generation ceremony and are consistently producing decryption keys for each transaction that is submitted to the sequencer contract. In order to be able to observe the performance even if there are only a few transactions, they additionally produce one key for each new block.
Console output from keys being generated
In order to make the keypers feature complete, more work is left to do. The most significant modification is to watch the validator registry contract and trigger decryption key generation only for those slots whose proposers signed up to participate in the protocol. Of course, the network should also not run centrally but for example by the already existing entities selected by the Shutter DAO 0x36. If you're a Shutter Keyper, let us know if you want to become a beta tester for this!
And as always, there is ongoing work to fix bugs, improve performance, and rigorously test the system.
Next steps
We’ll continue to work on and improve the Shutter and Keyper system part of this collaboration. In addition, Nethermind are working tirelessly to implement the necessary client changes. We’re optimistic that a full testnet implementation will be released soon and then a mainnet integration can follow not long after that.
Join the Revolution for Supporting Front Running and Censorship Resistance
Developing an encrypted mempool on the Gnosis Chain heralds a revolution for one of the first Ethereum sidechains, focusing on heightened security, user accessibility, and economic viability. This integration directly tackles challenges like front running and malicious MEV exploitation, which have been detrimental to Ethereum's ecosystem, paving the way for a fortified decentralized finance (DeFi) landscape.
Additionally, the Shutter extends beyond mere security measures, emerging as a time-lock encryption tool that amplifies the capabilities of DeFi applications built on the Gnosis Chain. As we look ahead, the roadmap is clear: amplifying transactional security for every Gnosis Chain user, encapsulating the essence of a trusted and robust blockchain future.
Get in touch by joining the Shutter Forum or contact us at contact@shutter.network! We are happy to discuss your requirements and needs regarding front running and censorship resistance!
FAQ
1. What is the Encrypted Mempool on the Gnosis Chain?
The encrypted mempool is a feature on the Gnosis Chain that enhances front running protection and reinforces anti-censorship guarantees.
2. Who are the key players in this protocol?
The key players include:
- Gnosis Chain validators/block producers.
- A sequencer contract.
- 21 Keyper nodes.
- A new JSON RPC endpoint.
3. What are the benefits for users?
Users can expect safer trading, added censorship resistance, and more profitable trading due to reduced malicious MEV.
4. When will the Shutterized Gnosis Chain go live?
The exact date is yet to be announced. We hope to release an initial version within 2 or 3 months. Stay tuned for updates from the Gnosis and Shutter teams.
5. What are the tradeoffs for implementing an encrypted mempool this way?
There's a small increased cost for users, which is expected to be offset by better prices due to less front running. The DKG adds latency but can most likely be parallelized, so the tradeoff shouldn't be significant.
6. How is the Shutter useful for DeFi dapps?
The Shutter enhances functionality and security in DeFi dapps, especially in voting protocols, ensuring fair, secure, and transparent voting.
Resources/Links
Specification documentation at GitHub
Shutterized Beacon Chain proposal at ethresear.ch