MD-7: Suzuka MEV #7
Conversation
| - Assess how transaction provenance can be formed. | ||
|
|
||
| ### D2: Merge Blocks and Assign Deterministic Cut-points | ||
| **User Journey**: An honest Suzuka Full Node can only form the final blocks needed for execution by (a) merging blocks in a given DA height range, (b) ordering transactions deterministically, and (c) assigning deterministic cut-points for block formation. |
There was a problem hiding this comment.
- what does the full node do in this context? execution? would be good to define it quickly here
- from our discussion we need to have a deterministic process to extract the txs sequence on DA for the execution engine (full node?), so that the state output of the execution engine is reproducible. The execution engine should have no control over the inclusion or ordering of transactions
There was a problem hiding this comment.
A Full Node currently performs all operations in the transaction dataflow after the transaction leaves the Client and excluding the work done by Celestia. This is initial transaction validation, transaction sequencing, block verification, block execution, settlement, and block reversion.
|
|
||
|
|
||
| ## Overview | ||
| The Suzuka Network is known to be subject to MEV exploits in the form of manipulating block size and order. That is, while transactions within a block are ordered deterministically, full nodes are currently given freedom to chose which transactions to include in a block and when to send those blocks to the network. Execution-level validation will only assert that the sequence numbers are appropriate and other dApp-specific logic. There are no penalties for being to have withheld a transaction. |
There was a problem hiding this comment.
who exploits the block size and order and at what step. What is a block? when is a block? are there blocks before the DA? or only unordered batches?
i assume the proposer sends a batch, while the execution engine (or full node?) extracts a block from the DA.
There was a problem hiding this comment.
The Suzuka Proposer can currently exploit by forming what is currently a block for the remainder of the dataflow. They are not able to decide transaction order within the block or block order w.r.t. all other blocks. However, they can decide which transactions are included in a block and have the guarantee that block will not be merged with others, i.e., both inclusion and exclusion.
There was a problem hiding this comment.
Currently, before the DA, the Proposer will create a batch which has a deterministic order of transactions that is verifiable by other nodes.
The want expressed in the desiderata is that the other and cutpoints between blocks is determined by a similar rule. If such is adopted, there will be no blocks until the DA stream is processed by an honest node, only batches.
Note, we do need to verify that this is cryptographically secure @mzabaluev , via the current hash being used with the BTreeSet.
MD/md-6/README.md
Outdated
|
|
||
|
|
||
| ## Overview | ||
| The current implementation of the Suzuka Network relies on a public and permissionless DA. The blocks are further not validated besides their correctness w.r.t. the Aptos executor. |
There was a problem hiding this comment.
should we differentiate between batches from proposers (sent to DA) and blocks executed by nodes (and extracted from DA). it seems these are different.
There was a problem hiding this comment.
Yes, this should be a distinction we make at this point.
|
|
||
| **Recommendations**: | ||
| - This would be a highly experimental feature and should be researched and implemented with caution. | ||
| - Deterministic transaction and block ordering should cover most of the cases of unfairness. These are discussed in [MD-7](../md-7/README.md). However, in theory you could also slash on conditions like including too many transactions from one user, sending too many blocks at a given time, sending too few blocks at a given time, sending blocks of unequal size when transactions are available, etc. |
There was a problem hiding this comment.
I would argue it only covers a sub category rather than the majority.
However, in theory you could also slash on conditions like ...
i am not sure why we need to slash. could we have a rule on the executor side whether to accept a batch or not based on these rules instead? or does the DA remove the batch wrapping? where would the slashing be enforced?
There was a problem hiding this comment.
In the case you have the staking requirement mentioned above, would always slash in the settlement contract.
| - Be sure to consider what is lost in this approach. For example, currently, a developer could bypass a Suzuka Full Node an submit directly to the DA--allowing them to avoid any potential censorship. This would be lost in a naive implementation of this approach, as they would be required to either (a) submit via a full-node or (b) stake themselves. | ||
|
|
||
| ### D3: Invalidation or Validator-slashing for Producing Unfair Blocks | ||
| **User Journey**: Validators can be slashed for producing unfair blocks. |
There was a problem hiding this comment.
I think you mean to say proposer. The validators could be the proposer, but this is a different topic. (D2)
There was a problem hiding this comment.
Yes, that was the intent.
| Most of the account of MEV attacks should be based on the model of transaction fairness given in [MD-6](../md-6/README.md). | ||
|
|
||
| Many of MEV attacks addressed can also be classed as censorship attacks. That is, a miner can choose to not include a transaction in a block. This is a form of censorship. As such, the desiderata herein also address censorship attacks. | ||
|
|
There was a problem hiding this comment.
There is a need for section with definition of terms in the document.
E.g. what is and does
- node
- proposer
- validator
- block (where, who issues or consumes)
- batch?
There was a problem hiding this comment.
Do we want to add terms sections to the templates for the MD and MIP? How high do we want to set the initial bar for MD definitions? IMO, they are supposed to be free-flowing desiderata that are interrogated as we are doing now to come to clear terms.
Co-authored-by: Andreas Penzkofer <[email protected]>
Co-authored-by: Andreas Penzkofer <[email protected]>
Co-authored-by: Andreas Penzkofer <[email protected]>
Summary