Encrypted mempool

[stompesi]

Proposed Solution - Encrypted Mempool

Figure 1. Madara transaction type

Radius' proposal introduces an innovative and secure approach to transaction processing within Madara's framework, leveraging an encrypted mempool to optimize the extant transaction processing mechanism. Traditional transaction processing workflows involve making transactions public and processing them within a common pool.

In the proposed encrypted mempool architecture by Radius, transactions can be executed without causing any detrimental impact to the user, even in the event of transaction execution order changes. For instance, Declare or Deploy transactions will not impact users adversely even if the order of execution changes. Consequently, variations in the execution order of such transactions do not pose significant issues. Additionally, straightforward Invoke transactions, like the transfer of cryptocurrency funds from one entity to another, can benefit from the prevailing transaction processing mechanisms.

Simultaneously, the encrypted mempool approach helps to shield transactions that could be affected by changes in execution order. By encrypting these transactions, the framework mitigates potential damages associated with variations in execution order. Although this method might require users to bear slightly higher transaction costs due to decryption needs, it effectively safeguards users from threats like front-running and sandwich attacks.

Figure 2. Overview of proposal about encrypted mempool

As depicted in Figure 2, the JSON-RPC request method has bifurcated into two separate transaction processing pathways: starknet_addInvokeTransaction and the newly introduced starknet_addEncryptedInvokeTransaction. This division caters to user preferences, presenting an option for lower transaction costs through the conventional method or enhanced transaction stability via encrypted transactions.

Both starknet_addInvokeTransaction and starknet_addEncryptedInvokeTransaction equip users with an order_commitment for their submitted transactions. In the case of starknet_addEncryptedInvokeTransaction, users initially encrypt their transaction and relay it to the sequencer. The sequencer then decrypts this encrypted transaction and incorporates it into the encrypted mempool.

The primary decryption mechanism involves the user supplying the decryption key. Once the user obtains the order_commitment from the sequencer, they transmit the decryption key through RPC via the starknet_provideDecryptionKey function, enabling immediate transaction decryption by the sequencer. Nevertheless, the situation where the user fails to provide the decryption key poses a challenge as the transaction remains undeciphered. To counter this issue, a delay function is integrated into the protocol that enables calculation of the decryption key and subsequent transaction decryption.

Moreover, to ensure transaction order integrity, the sequencer establishes an order for the transactions and provides an order_commitment to the user. This order_commitment is later utilized to verify any potential malicious behavior by the sequencer, such as altering the transaction execution order. However, the exact usage of the order_commitment still necessitates further investigation.

Our Step-by-Step Execution Plan

The subsequent sections elucidate the tasks essential for meeting the objectives of the Proof of Concept (PoC). Each task includes an estimated timeline for completion, considering the manpower of two primary developers and one additional reviewer. If conducted consecutively, these tasks will require a cumulative development duration of eight weeks.

• Task-1 - Encrypted transaction mempool - interface (1~2 weeks)

This defines the JSON-RPC interface for transactions to be stored in Madara. This interface will reasonably consider the type and storage method of transactions to be stored in the encrypted mempool, but it may be updated before final delivery depending on what is discovered during the implementation of the rest of this proposal. The goal here is to deliver users' transactions encrypted and provide order commitment based on this. Sharing decryption key or using the delay function, the transactions are decrypted and stored. Each required feature is described below.

• Client (using postman)

  • Create a transaction
  • Encryption: using JSON-RPC for rust-based testing (using Postman)
  • Sending transactions

• Madara [[encrypted mempool](https://github.com/keep-starknet-strange/madara/tree/main/crates/client/transaction-pool)]

  • Receive a transaction (JSON-RPC: starknet_addInvokeEncryptedTransaction)
  • Return order commitment (dummy)

• Task-2 - Encrypted transaction mempool - store & provide transaction - (2 ~ 4 weeks)

  • Madara [[encrypted mempool](https://github.com/keep-starknet-strange/madara/tree/main/crates/client/transaction-pool)]
    • Add option of encrypted transaction mempool and Transaction mempool
    • Transaction conversion
      • InvokeEncryptedTransaction → MPTTransaction
    • Order commitment
      • message: (block_number, transaction_order, transaction_hash, encrypted_transaction_hash) - should be checked
      • signature: sequencer_signature
    • Decrypt transaction
    • Saving transactions
    • Transaction ordering
    • Added the ability to provide a list of transactions (pool → proposer)
    • Transaction Verification

• Task-3 - Validation of transaction ordering (2 ~ 3 weeks)

  • We are currently progressing with the verification aspect of this project. Given that the existing method employed by Radius is tailored specifically for Ethereum, we will strategize a more fitting approach for Madara through meticulous code analysis and research.
  • We would also like to leave this as an open discussion and discuss it with the Madara team.

Team’s Expertise and Capabilities

Radius has extensive experience researching and advancing methods for fair and efficient sequencing solutions for blockchains. Our dedication began and is well-demonstrated through our achievement at the 2021 HackMoney hackathon, where we presented an MEV-resistant decentralized exchange (DEX) that ensures the secure execution of user transactions. Ethereum Foundation’s endorsement of this research and mechanism attests to the validity of our approach.

Radius proposes a solution for encryption-based transaction ordering, which implements an encrypted mempool. We present a way to decentralize rollups while upholding the promise of scaling Ethereum with higher throughput and lower fees. This sequencing mechanism enhances the overall security and interaction among multiple rollups, while even presenting opportunities for arbitrage.

Links for Reference

• Website: https://www.theradius.xyz/
• Documentation: https://docs.theradius.xyz/overview/introduction-to-radius
• Practical Verifiable Delay Encryption (PVDE): https://ethresear.ch/t/mev-resistant-zk-rollups-with-practical-vde-pvde/12677
• EF Grant: https://twitter.com/EF_ESP/status/1621526676202196994?s=20
• HackMoney: https://ethglobal.com/showcase/tex-yneai

[jommi9]

This is a very intriguing idea! And I know the Radius team are experts in their field so the fit on this is imho top-tier!

[stompesi]

Thanks, I'll work and develop it further and hope to include encrypted-mempool function in Madara.