On June 30, Vitalik published a new article discussing Ethereum's problems with transaction confirmation speed. Vitalik mentioned that Ethereum has made great improvements compared to five years ago. Thanks to EIP-1559 (dynamic adjustment of transaction fees) and the stable block generation time after the merger, transactions sent by users on L1 are usually confirmed within 5-20 seconds. However, this time can be further improved. For some applications that explicitly require a delay of several hundred milliseconds or even shorter, it makes sense to further shorten the confirmation time. To achieve this goal, the Ethereum community and researchers have proposed some practical solutions, one of which is preconfirmations.
What is pre-confirmation?
Preconfirmations (preconf) is a pre-confirmation state of a transaction before it is officially confirmed. Specifically, it refers to a temporary confirmation by the node before the transaction is included in the block by the miner and officially on the chain. This temporary confirmation means that multiple nodes verify the validity of the transaction and temporarily store it in the memory pool. This allows users to get a signal that the transaction has been accepted in a short period of time, so as to get instant feedback, reduce waiting time, and improve user experience. This preconfirmation is not the final confirmation and may still be revoked (such as block reorganization), but this situation is relatively rare.
Typically, in the pre-confirmation mechanism, the proposer acts as a provider of pre-confirmation services. Users can obtain a signed commitment that their transaction will be included in the next block by paying an additional fee. If the proposer fails to fulfill their commitment, they will face financial penalties.
Specific implementation plan: Based Preconfirmations
Justin Drake, a researcher at the Ethereum Foundation, has been promoting an approach to Ethereum’s pre-confirmation mechanism: Based preconfirmations, which provides fast transaction confirmation through specific incentive and penalty mechanisms.
In order to reduce the risk of transactions failing to be included in blocks for various reasons in the Based preconfs mechanism, additional proposer penalties and mandatory inclusion are required:
Proposer slashing: L1 proposers must choose to add additional slashing conditions to become preconfirmers. This can be achieved through re-staking mechanisms.
Proposer forced inclusions: L1 proposers must be able to force transactions to be included on the chain, even when it is economically uneconomical or other proposers are uncooperative. This can be achieved through inclusion lists.
L1 proposers become pre-confirmers by opting in to the following two pre-confirmation penalty conditions. Pre-confirmers issue a signed pre-confirmation commitment to the user, promising to include the transaction in a block within a specified time period, and receive a tip from the user for fulfilling the commitment.
Liveness slashing: Pre-confirmers face penalties if they fail to include pre-confirmed transactions within a specified period of time.
Safety slashing: If the pre-validator's commitment is inconsistent with the actual transactions included, they will face penalties.
In addition, pre-confirmers are prioritized according to their position in the proposer's outlook to execute pre-confirmed transactions faster. The proposer's outlook mechanism is a mechanism used to determine which proposers will have the opportunity to package blocks in the future. Each future proposer is assigned a position number, which indicates their order in future block proposals. Pre-confirmers are sorted according to their position in the proposer's outlook. The smaller the position number, the higher the priority. Assuming that a transaction is committed by pre-confirmer B, the proposer with a smaller position number before B (pre-confirmer A) can package the transaction immediately, reducing the user's waiting time and not having to wait for the time period when B becomes the proposer. If the proposer before B fails to package the transaction in time, pre-confirmer B needs to ensure that these transactions are included within its time period, otherwise it will face penalties.
Through the above conditions and settings, Based preconfs can provide L1 with faster transaction confirmation. If the rollup is based (L2 sorting is left to L1), that is, all L2 blocks are logically regarded as L1 transactions, then the same mechanism can be used to provide pre-confirmation for L2.
Community Discussion
Justin Drake proposed Based preconfirmations, which attracted the community's attention to the preconfirmation mechanism. After that, the community had a rich discussion around the topic of preconfirmation. The more noteworthy ones are: Blockchain Capital member Jonah B proposed to allow users to customize the punishment measures in the preconfirmation mechanism; independent developer Matthew proposed to use the chain preconfirmation mechanism (preconf chaining) to protect the proposer from being punished by external unexpected situations such as power outages, network interruptions, etc. (liveness failure); Primev researcher Christian Matt introduced two preconfirmation modes: one is provided by a designated leader (leader-based), and the other is provided by multiple competitors (leaderless) in the absence of a leader. The advantage of the leader mode is that it can provide nearly 100% confirmation guarantee. The competitive environment of the leaderless mode helps to effectively discover the price of preconfirmation and optimize the benefits of validators. Christian Matt also proposed several solutions combining leader and leaderless preconfirmation; Ethereum Foundation member potuz discussed various challenges and solutions for introducing the preconfirmation mechanism under the ePBS framework.
