Radius block building solution for rollups consists of the following modules:
We call it module because each does a specific job(s) to achieve our goal: enriching rollup economy and providing a new source of income by reinvesting captured MEV in rollups. To better understand how each module works, we need to view the system from the perspective of a transaction, which we describe as a transaction journey.
This guide is not intended to be technical. With all complex implementations under the hood, let's find out how we achieve, alongside our original goal, protection of user transactions (e.g. Harmful MEVs, Sandwich attacks, front-running and etc).
A user transaction has a lifecyle just like us. When a user tries to send 1 Ethereum from the address A to B and click the send button from the wallet, the transaction gets born. The unencrypted user transaction gets sent to a designated RPC endpoint of Secure RPC where the user transaction is encrypted. Secure RPC is a layer between the wallet and sequencers which encrypts and forward user transactions to sequencer.
When the user transaction reaches Secure RPC unencrypted, Secure RPC is responsible for encrypting the transaction with the latest encryption key generated by Distributed Key Generator. The key generated by Distributed Key Generator is mathematically guaranteed to stay encrypted for a certain amount of time. It is within this specific window of time that the order commitment (inclusion guarantee) made by the Sequencer is valid.
The encrypted transaction in Secure RPC is forwarded to one of the sequencers in the cluster. The order commitment corresponding to the encrypted transaction made by the leader sequencer in the cluster is returned and our transaction, while remaining encrypted, gets copied to follower sequencers in the cluster with the order commitment and stored with order commitment and encryption key.
When the rollup executor requests the block for execution, the leader sequencer starts decrypting the transaction with the decryption key fetched from Distributed Key Generator. After filling the block with decrypted transactions, the leader proposes the block to the executor and submits a block commitment for followers to validate. After this point, anyone including the user with order commitment can challenge the leader in case of failed order validation.
The execution of the proposed block by the rollup executor marks the end of the journey. For those who finds this explanation too vague to be useful or wants to know more about the implementation details, I suggest you to visit our GitHub repositories for each module.