# Ray Tracing

## Team

Artem, Lido - Lido Nodes, DevOps

Edgar, Flashbots - payment contract, contract deployments, bundles generation

Jackie, Nethermind - testing

Lukasz, Nethermind - core implementation (MEV and The Merge plugins)

Tomasz - testing, truffle, product design

## Mentors

Alejo, Alex - Flashbots research ideas

Tina - coordination / hackathon submission

Sam, Victor - Lido contracts

## Intro
Setup an MEV devnet with Eth2 validators and beacon chain and Nethermind Eth1 nodes that mimics the Flashbots bundle inclusion process in an L1 post-Merge, non-sharded environment.

### Targets
* Flashbots post-merge PoC
* Finish Rayonism MEV plugin in Nethermind and get it to build in a mergenet
* Sample searcher/user calling devnet directly
* Replacing features from the central relay when it goes away
* Lido validators and pooled staking integration

## Guiding questions

* How should the reward be distributed?

* Where shall the bundle be sent?

* Do Eth1 operator and validator operator have to be the same entity? Can this agreement be achieved in a decentralized way?

* Can we remove the role of MEV-Relay thanks to the knowledge about the validator minutes ahead of block propagation?

* Is there any risk to MEV opportunity during the attestation / voting phase?

* What do validators want? What do searchers want? How can the implementation be designed to maximize traction and adoption?
* The current process to become an MEV miner is to sign up for it and implement the required features. In the future, it should be easier than this, i.e. permissionless.

* Will there alternative flashbots implementations once decentralization is acheived?

## A naive Rayonism flashbots implementation
A naive PoC of flashbots post-merge would be to have validators register their Eth1 engines with the Mev-relay to call `eth_sendBundle` as before. Nothing really changes for searchers, but miners are replaced by validators and all they have to do is install an implementation and register with flashbots like miners did before. It entails a working combination of Rayonism Eth1 engine, beacon node, and validator software, at minimum.

## Does the naive implementation break down?
Assume at time `t`, we are in epoch `e` and the block production phase for slot `s`. Searchers in total submit `k` bundles targeting the pair `(e,s)` (equivalent to block number), in some distribution over interval $[t-\delta_1,t+\delta_2]$. Otherwise, the Eth1 engine scores the bundles and judges it against a vanilla block, producing a valid block for `consensus_assembleBlock`. Attestors recognize the block, and it is eventually finalized. The main problem is that there are two/three clients post-merge, but current architecture only pays the coinbase. If the validators runs their own Eth1 operator and is indepdendent, this is not a concern. However, if the validator is a part of a pool using others' stake and/or uses an externally operated Eth1 node (Eth1 client abstraction) then distributing MEV only to the Eth1 coinbase beneficiary is unfair. Also, mining pools are replaced by staking pools.

## Proposed approach
The proposed approaches and discussion.

### Assuming only validators are in a pool
#### No proxy
Eth1 engine receives coinbase reward as before, ie backwards compatible up to Flashbots v0.2. A transaction that pushes the additional reward to additional parties (in a staking pool) is included with 0 gas fee signed by a coinbase wallet. These must be excluded from scoring, i.e the tx are added after scoring. Requires modification from the client. This approach is the simplest (profit switch on the coinbase reward, and then send some to validators), although the downside is a private key must be kept in memory.

The searcher could this transaction in their bundle with the same privileges as above, but signed by them. This may be a contract call too. This adds additional overhead for a searcher, and is not very good UX. Additionally, the client need to be modified to profit switch on these transactions or contract calls, and we would have to rely on searchers sending transactions to the right places.

Gas fees go to the Eth1 engine, who must appropriately score the bundles.
#### With proxy
All MEV payments go to a proxy. Pools pull reward from proxy. Gas fees still go to the Eth1 operator. This approach is more flexible, however more complicated in terms of scoring and gas fees.

### Non-pooled validators
We contact validators directly.

Validators are known for 2 epochs in advance. However, they must supply an endpoint (additional overhead) if they are to receive bundles directly. A registry must be maintained of endpoints and validator pubkeys. Validators in this registry receive the full MEV reward, whereas it is split if they join a staking pool (since validators in a staking pool don't own the stake they are using).

`function getValidatorEndpoint(string memory blsPubKey) returns (string)`
A smart contract that contains a registry of bls public keys of validators (or indices?) to their eth1 engine endpoints. With hundreds of thousands of validators in production, this will need heavy optimization.

`eth/v1/beacon/states/head/next_validators`
Endpoint to retrieve the know validators up to epoch `N+2`. There does not seem to be a an endpoint for this already.

### What changes for those who include and order transactions (prev. miners) ?
Mainly, a single party receiving revenue is no more. Post merge, assuming EIP-1559 implementation, block production involves three clients (Eth1 engine, beacon node, validator client). The Eth1 engine as before collates tx for `consensus_assembleBlock` to an Eth2 beacon node, which passes it to an Eth2 validator client during its slot for sealing. The Eth1 engine then executes the tx in the sealed block (is this accurate?). Effectively, the Eth1 engine provides part of the infrastructure surrounding execution, while the (beacon node, validator) pair provide the sealing.
#### Distributing rewards
There are two infrastructure providers post-merge, three if you count stakers providing stake. Their contribution to the MEV bundle inclusion process should be reflected in the portion of the reward they receive. For new infra operators, the opportunity costs with respect to running each other part should be 0 for a given time frame. Infra providers without setup costs should have negative opportunity costs.

Instead of considering the marginal cost of including one bundle, we consider the simpler marginal cost of running a piece of infrastructure itself necessary to include one bundle.

Stakers purchase Eth to stake and get an appreciating asset. Validators and Eth1 engine providers require hardware, i.e. a depreciating asset. And while the upfront hardware costs to run a node are less than the cost of purchasing 32 Eth, such hardare also requires some maintenance, physical space, and electricity to function. Eth1 operators still receive gas fees, validators in a pool receive pool rewards, and stakers receive Eth2 staking yields.

Concretely, what could be illustrative to find the parameters for 0 opportunity costs include
1) a spreadsheet model that can be adjusted
2) solving a formalized optimization problem with matrix algebra

### Lido integration
Using stETH, a rebasable token to represent rewards between stakers and validators.

Only miners can currently capture MEV. The stakeholders that capture this are mining pools and their miners, in their capacity as mining farms or individual miners. The MEV is added to the total revenue of the pool and divvied up proportionally. With PoS, the block proposer for an epoch's slot is the equivalent of the winning miner.

#### Rewards distribution in Lido
Rewards may be distributed to a single block proposer instead of the entire pool of validators, with certain statistical assumptions, this may be fair enough despite variance in MEV. This mimics validators outside a pool receiving their full share of Mev.

### Edge cases
Reversion from FFG and LMD Ghost, voluntary and forced exit of validators.

## Effects of obviating a central relay
The current method is to used a central relay endpoint. This relay also has logging purposes for various other flashbots tools such as historical bid pricing. Nonetheless, some abstraction, not necessarily centralized, is necessary to relay the transactions.

A validator could miss their slot, and the MEV remains available (a relay would be able to alert the searchers of the failure, but a system without a relayer would not).

One method of guaranteeing that block producers don't tamper with (e.g. frontrun) bundles is full bundle privacy through encryption (the current direction is with Mev-SGX). This obviates the need for a central relay whitelist, but does not address the need for transparency into MEV activity provided by such a relay.

#### Bundle logging mechanism
The goal is to have a decentralized, permissionless standard that is implementation agnostic. We could leverage existing blockchain principles to build a decentralized data source, secured by consensus. Alternatively, a simpler approach would be to calculate data ex post facto from included blocks.

## Relevant Reading
[Potential delays on the ETH2 network - A data-driven view of the beacon chain incident](https://barnabe.substack.com/p/a-data-driven-view-of-the-beacon)