# Preconf Sequencing Rules As we will further decentralize the preconfer role, we need to enforce a MEV-resistant sequencing rule to prevent potentially malicious preconfers. Our end game is to develop a [concurrent proposer consensus](https://ethresear.ch/t/concurrent-block-proposers-in-ethereum/18777) for both L1 and L2 preconfirmations to maximize censorship resistance, MEV resistance, and liveness properties. As the first step, however, we will introduce a verifiable sequencing mechanism that's much easier to implement. Consider the scenario where a sequencer is responsible for ordering user transactions. To limit the sequencer's ability to extract MEV, we establish specific rules for the final order of transactions. Here we define a verifiable sequencing rule to be a sequencing rule that can be effectively determined within polynomial time. ### Definitions * A **sequencing rule** is a function $$S$$ with two variables: * a sequence of transactions $$\text{txs}=\$$ and * prior blockchain states $$X$$. The output, $$S(\text{txs}, X)$$, is nonempty subset of all permutations of $$\text{txs}$$, representing allowed orderings of $$\text{txs}$$. * A sequencing rule $$S$$ is **verifiable** if and only if for any transaction sequence $$\text{trs}$$ and any given prior states $$X$$, it can be determined in polynomial time that is $$\text{txs} \in S(\text{txs}, X)$$ or $$\text{txs} \notin S(\text{txs}, X)$$. **Note**: * We gave a slightly more general definition of sequencing rule $$S$$ above. In many other works, the first input of $$S$$ is set of transaction instead of a sequence of transaction. Our definition is more general in the sense that if we add the restriction $$S(\text{txs}', X) = S(\text{txs}, X)$$ for any permutation $$\text{txs}'$$ of $$\text{txs}$$, then we obtain the definition of a sequencing rule found in other works. * A sequencing rule $$S$$ is verifiable here means $$S$$ can be verifiable effectively within polynomial times A sequencing rule defines what kind of ordering is acceptable and add restrictions to sequencers ordering of transactions. A good sequencing rule should be designed to achieves designer goal. In the next section, we use an example work to illustrate the initial version of our verifiable sequencing mechanism. Taiyi V0's sequencing rule will be based on the verifiable sequencing rule proposed by [Credible Decentralized Exchange Design via Verifiable Sequencing Rules](https://arxiv.org/abs/2209.15569). Here is the gist of the rule: Usually, a sequencer can extract MEV from user’s currency exchange transaction $$T$$ on a convex AMM pool $$P$$ by inserting sequencer’s own currency exchange transactions before and after $$T$$. This is particularly profitable when the sequencer can use users’ transactions to significantly shift $$P$$’s position from its prior state. In this context, the **position** of a liquidity pool is represented by a pair $$(m,n)$$, indicating the amounts of each currency in the pool. This suggests that it may be beneficial to restrict the sequencer’s ability to significantly shift a liquidity pool’s position. In particular, the paper points out following key dichotomy: Consider a pool $$P$$’s prior position is $$(m\_0,n\_0)$$, where $$m\_0$$ and $$n\_0$$ are amounts of currencies $$C\_0$$ and $$C\_1$$, respectively. A **buy** is a transaction that sell $$C\_0$$ for $$C\_1$$, and a **sell** is a transaction that sells $$C\_1$$ for $$C\_0$$. Then for any position $$(m,n) \neq (m\_0,n\_0)$$, exactly one of following is true: 1. A buy at position $$(m,n)$$ buys more than it does at position $$(m\_0,n\_0)$$ if $$m\m\_0$$ Based on this dichotomy, the paper suggests a **greedy sequencing rule**: when $$m\m\_0$$, the next transaction on $$P$$ must be a sell unless no remaining sell transactions are available for sequencing. Thus, the greedy sequencing rule requires oscillation around the convex AMM pool’s prior positions for as long as possible. Clearly, this greedy sequencing rule can be verified with linear time complexity, making it **verifiable**. As for implementation, we will leverage zk-coprocessor, [Axiom](https://www.axiom.xyz/) to verify transaction sequence according to the rule. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://luban-1.gitbook.io/tai-yi-v0/mfrlyXSvVliigkr4PsmM/taiyi-system-analysis/preconf-sequencing-rules.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.