SecureRpc is a bare-metal, fully conformant JSON-RPC/gRPC Infrastructure plane that aims to perform well and meet the following requirements:
- censorship resistance
- latency
- optimizations
- support for bespoke RPC Calls
- seamless usage
- privacy focused
- improve trade execution
- improve trade settlement
- resistant against coercions from state-level actors
All of this while using as little of your validators’ resources as possible, and without hosting on any cloud provider infrastructure like AWS or Google Cloud.
Differences between SecureRpc and Flashbots
Key differences between SecureRpc (current state, 09/27/2022) and Flashbots-equivalent Relays (Flashbots, Bloxroute, Blocknative):
Searchers can send their bundles to our SecureRpc Relay (OpenMEV) - that’s the only interaction we allow ATM.
Support for whole block submission should be available post devocon (Late October 2022) along with bottom of the block bidding support.
We are also not adding ETH for blocks: there is no loss there as we’re not bleeding additional money (ETH) per block we send to validators (i.e. subsidy).
To the point of this method, there is a lack of concept (re: motivation) where this money would come from to begin with. We’ve found that EIP1559 gives enough tools to include the priority fee in the transaction, so why add another transaction? On the other hand, EIP1559 makes the calculation of how much one will ‘tip’ at the end of the day really awkward. So having such a transaction optional maybe is not a bad idea. However, we have taken out the requirement when validating the block sent to the mev-boost-relay for now.
Block Building
If available, we add a transaction bundle from our private virtual mempool at the top of the block - this is done by our private block builder.
- When validating a block coming from the block builder
We skip the tracing part and checking against some arbitrary blacklist - that also gives us slight timing advantage since tracing takes some time (unambiguously). We don’t check for direct payment of reward to the block proposing validator since we don’t include such a transaction. We maximize reward by adding high value transaction from our private virtual transaction mempool.
Connection
Discussion
We are aware of the issues mentioned in this discussion thread https://dao2.rocketpool.net/t/draft-outline-for-a-pdao-proposal-on-rules-of-sp-and-mev-boost/1066/27, and are willing to help enable such oversight, etc, for the RP DAO.