Merge pull request ethereum#1 from Ma-Julian/Ma-Julian-update-FOCIL-f…

…unctions

Update Main FOCIL functions

EIPS/eip-FOCIL.md

@@ -51,9 +51,9 @@ inclusion lists. This approach imposes stricter constraints on creating the aggr
 - 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 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..)
+- `Agg`: This function takes as input a set of local ILs and outputs an aggregate IL which is a set of entries (`from_address`, `gas_limit`, `bitlist`). The _i_th value of the bitlist reflects whether the entry (`from_address`, `gas_limit`) associated with this bitlist was included in the local IL of the _i_th committee member. This function removes local ILs that are invalidated by others and outputs the union of the remainder with corresponding bitlists.
+- `Eval`: `Slot N` attesters assess the quality of the IL aggregate included in `block B` by using this `Eval` function. This function takes as input the set of local ILs observed before the deadline by the attester and a list of local ILs used by the block producer. It outputs whether the aggregate IL was constructed correctly. First, it checks whether, at most, a fixed amount, Δ, of the attester's view, was not used to construct the aggregate IL. Then, it checks whether the aggregate IL was constructed using the list of local ILs used by the block producer and the `Agg` function.
+- `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..). It takes as input the execution payload and the corresponding aggregate IL. If the block is full, the inclusion list is always applied correctly (conditional property). If the block is not full, all transactions referenced in the aggregate inclusion list must be in the execution payload.
 
 ## Backwards Compatibility