Merge branch 'master' of https://github.com/soispoke/EIPs

EIPS/eip-FOCIL.md

@@ -14,15 +14,15 @@ created: 2024-07-??
 Implement a robust mechanism to preserve Ethereum’s censorship resistance and chain neutrality properties by guaranteeing timely transaction inclusion. 
 
 FOCIL is built in three simple steps:
-	- Each slot, a set of validators is selected to become IL committee members. Each member gossips one local inclusion list according to their subjective view of the mempool.
+	- In each slot, a set of validators is selected to become IL committee members. Each member gossips one local inclusion list according to their subjective view of the mempool.
 	- The block proposer collects and aggregates available local inclusion lists into a concise aggregate, which is included in its block.
 	- The attesters evaluate the quality of the aggregate given their own view of the gossiped local lists to ensure the block proposer accurately reports the available local lists.
 
 ## Motivation
 
-In an effort to shield the Ethereum validator set from centralizing forces, the right to build blocks has been auctioned off to specialized entities known as builders. Over the past year, this has resulted in a few sophisticated builders dominating the network’s block production. Economies of scale have further entrenched their position, making it increasingly difficult for new entrants to gain significant market share. A direct consequence of centralized block production is a deterioration of the network’s censorship resistance properties. Today, two of the top three builders are actively filtering out transactions interacting with sanctioned addresses from their blocks. In contrast, 90% of the more decentralized and heterogeneous validator set is not engaging in censorship. This has driven research toward ways that allow validators to impose constraints on builders by force-including transactions in their blocks. These efforts recently culminated in the first practical implementation of forward ILs, [EIP-7547](./eip-7547.md), being considered for inclusion in the upcoming Pectra fork. However, some concerns were raised about the specific mechanism proposed in EIP-7547, leading to its rejection. 
+In an effort to shield the Ethereum validator set from centralizing forces, the right to build blocks has been auctioned off to specialized entities known as builders. Over the past year, this has resulted in a few sophisticated builders dominating the network’s block production. Economies of scale have further entrenched their position, making it increasingly difficult for new entrants to gain significant market share. A direct consequence of centralized block production is a deterioration of the network’s censorship resistance properties. Today, two of the top three builders are actively filtering out transactions interacting with sanctioned addresses from their blocks. In contrast, 90% of the more decentralized and heterogeneous validator set is not engaging in censorship. This has driven research toward ways that allow validators to impose constraints on block construction by force-including transactions in the blocks. These efforts recently culminated in the first practical implementation of forward ILs, [EIP-7547](./eip-7547.md), being considered for inclusion in the upcoming Pectra fork. However, some concerns were raised about the specific mechanism proposed in EIP-7547, leading to its rejection. 
 
-FOCIL is a simple committee-based design improving upon previous IL mechanisms or co-created blocks proposals, and addressing issues related to bribing/extortion attacks, IL equivocation, account abstraction (AA) and incentive incompatibilities.
+FOCIL is a simple committee-based design improving upon previous IL mechanisms or block co-creation proposals and addressing issues related to bribing/extortion attacks, IL equivocation, account abstraction (AA), and incentive incompatibilities.
 
 ## Specification
 
@@ -35,11 +35,11 @@ FOCIL is a simple committee-based design improving upon previous IL mechanisms o
 A set of validators is selected from the beacon committee to become IL committee members for `slot N`.
 
 - **`Slot N`, `t=6`**: The IL committee releases local ILs, knowing the contents of `block N`. Local ILs are sets of transactions pending in the public mempool represented as (`from_address`, `gas_limit`) pairs.
-- **`Slot N`, `t=9`**: Local IL freeze deadline, after which everyone locks their view of the observed local ILs. The `slot N` proposer broadcasts a signed IL aggregate, constructed by deduplicated and taking the union of transactions from collected local ILs. Every IL aggregate (`from_address`, `gas_limit`) is associated with a `bitlist` field indicating which IL committee member included a given transaction.
-- **`Slot N+1`, `t=0`**: The block producer of `slot N+1` releases its `block B` which contains both the payload and the IL aggregate.
+- **`Slot N`, `t=9`**: Local IL freeze deadline, after which all attesters lock their view of the observed local ILs. The `slot N` proposer broadcasts a signed IL aggregate constructed by deduplicating and taking the union of transactions from collected local ILs. Every IL aggregate (`from_address`, `gas_limit`) is associated with a `bitlist` field indicating which IL committee member included a given transaction.
+- **`Slot N+1`, `t=0`**: The block producer of `slot N+1` releases its `block B`, which contains both the payload and the IL aggregate.
 - **`Slot N+1`, `t=4`**: The attesters of `slot N+1` vote on `block B`. `Block B` is considered valid if:
   - The IL aggregate corresponds to the attesters' local view of available local ILs
-  - The IL aggregate entries are satifisfied by payload transactions
+  - The IL aggregate entries are satisfied by payload transactions
 
 ## Rationale
 
@@ -48,11 +48,11 @@ A set of validators is selected from the beacon committee to become IL committee
 inclusion lists. This approach imposes stricter constraints on creating the aggregate list and significantly reduces the surface for bribing and extortion attacks. For instance, instead of bribing a single party to exclude a particular transaction from the IL, attackers would instead need to bribe the entire IL committee, substantially increasing the cost of such attacks.
 - Fork-choice enforced: By including the IL aggregate in `block B`, satisfying its entries by including the corresponding transactions in the payload becomes a new block validity condition enforced by all attesters. This allows reliance on a large set of participants to check the IL and block validity and addresses concerns around IL equivocation in EIP-7547. In FOCIL, an IL equivocation would result in a block equivocation, which is a known, slashable offense from the protocol's perspective.
 - Same-slot: By having FOCIL run in parallel with block building during `slot N−1`, we can impose constraints on `block B` by including transactions submitted during the same slot in local ILs. This property implies that a transaction in the IL aggregate can’t be invalidated because of a transaction in the previous block, which represents a strict improvement over forward IL designs like EIP-7547. Same-slot censorship resistance might also prove particularly useful for time-sensitive transactions that might be censored for MEV reasons.
-- Conditional and anywhere-in-block: Transactions satisfying entries in the IL aggregate share blockspace with the payload, can only being included if the block isn’t full (i.e., has reached the gas limit), and can be ordered arbitrarily by the block producer. These choices were made to reduce the risk of sophisticated block producers using side channels to circumvent an overly rigid mechanism, imposing a specific order or strictly limiting the size of the IL.
+- Conditional and anywhere-in-block: Transactions satisfying entries in the IL aggregate share blockspace with the payload can only be included if the block isn’t full (i.e., has reached the gas limit) and can be ordered arbitrarily by the block producer. These choices were made to reduce the risk of sophisticated block producers using side channels to circumvent an overly rigid mechanism, imposing a specific order, or strictly limiting the size of the IL.
 
 #### Main FOCIL Functions:
-- `Agg`: Transactions from local ILs broadcast before the Local IL freeze deadline during `slot N` should be collected, deterministically aggregated and deduplicated to construct an IL aggregate.
-- `Eval`: `Slot N` attesters assess the quality of the IL aggregate included in `block B` by using the `Agg` function to generate their own aggregate from all local ILs observed in their view, and compare it to the IL aggregate included by the proposer. The `Eval` function can be defined so that the proposer’s IL aggregate is considered valid if it includes a sufficient proportion of transactions observed by the attesters, as defined by a parameter Δ.
+- `Agg`: Transactions from local ILs broadcast before the Local IL freeze deadline during `slot N` should be collected, deterministically aggregated, and deduplicated to construct an IL aggregate.
+- `Eval`: `Slot N` attesters assess the quality of the IL aggregate included in `block B` by using the `Agg` function to generate their own aggregate from all local ILs observed in their view and compare it to the IL aggregate included by the proposer. The `Eval` function can be defined so that the proposer’s IL aggregate is considered valid if it includes a sufficient proportion of local ILs observed by the attesters, as defined by a parameter Δ.
 - `Valid`: This function encodes whether the IL aggregate conforms to pre-defined core IL properties defined in the above section (e.g., conditional, anywhere-in-block, etc..)
 
 ## Backwards Compatibility