Skip to content

jihoonsong/awesome-focil

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 
 
 

Repository files navigation

Awesome Fork-Choice Enforced Inclusion Lists (FOCIL)

A list of articles related to FOCIL. The summaries are my own.

Articles

Forward inclusion list - Nov 15, 2022

This article by Francesco introduces the censorship-resistance list (crList) as a means for proposers to combat censorship by forcing the inclusion of certain transactions. In this system, the proposer of slot N publishes a crList while the attesters of slot N+1 ensure that the builder of slot N+1 complies with it. After EIP-1559, the cost of censorship for a builder attempting to censor transactions by filling up blocks becomes exponentially expensive as the basefee increases exponentially. The article also cites the design goals of the censorship-resistance mechanism proposed by Vitalik.

This article by Elijah and Max proposes using multiple concurrent block proposers to enhance censorship resistance by moving away from a single leader and eliminating temporary monopolies. This approach raises the cost of censorship as the bribing agent now needs to bribe each of the leaders.

In this article, Mike Neuder proposes an inclusion list (IL) design where the proposer of slot N includes an IL in a block to constrain the proposer of slot N+1 while preventing free data availability (DA). The IL in a block contains transaction summaries and free DA occurs when a transaction in the IL of slot N is invalidated by a transaction in the payload of slot N. Since this can only happen between transactions from the same address with the same nonce, free DA can be avoided by ignoring the transaction in the IL, which is delivered as a P2P object.

This article by Toni Wahrstätter introduces the concept of a forward-cumulative inclusion list (IL) design. In this model, a transaction included in the IL of slot N remains valid after k slots, provided it can cover the basefee of slot N+k. The motivation behind this design is to prevent a censoring validator from bypassing compliance with the IL, especially in cases where the validator has enough staking power to control consecutive slots.

The first EIP on inclusion lists. Unfortunately, it is rejected due to some concerns such as transactions in the IL of slot N may be invalidated by transactions in the payload of slot N.

This article by Mike Neuder advocates for the use of an unconditional inclusion list (IL) that brings agency back to the proposer in a PBS world by allowing them to express preferences over which transactions are included onchain. Each IL has a fixed gas limit and be placed at the bottom of the next block with its transaction order preserved. The article also explores the tradeoffs between unconditional and conditional ILs.

This article by Mike Neuder explores multiple concurrent block proposers in Ethereum as a means to improve censorship resistance and decentralization. It demonstrates that the cost of censorship increases linearly with the number of proposers in each slot while further examining potential approaches for adapting proposer boost to accommodate multiple proposers.

This article by Julian Ma introduces the concept of chain neutrality and uncrowdable inclusion lists. It explores design approaches such as conditional ILs, COMIS, and mixed ILs to implement uncrowdable ILs. The article suggests that conditional reward to IL proposers, rather than block proposers, could enhance censorship resistance. It also argues that whether a protocol should intervene in block space allocation is a governance question, not one for markets to answer.

This article by Potuz discusses the incompatibilities between EIP-7547 and EIP-3074, highlighting the need for a better design for the inclusion list. This ultimately led to the rejection of EIP-7547.

In this article, Thomas Thiery points out the oligopoly in block production, which undermines Ethereum's censorship resistance, and introduces FOCIL, a mechanism based on a committee-based inclusion list (IL) design. In this model, each IL committee member for slot N produces a local IL and the aggregated local ILs constrains the block for slot N+1 to include at least a certain percentage of transactions from the IL aggregate in order to be validated.

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published