Overview
This page provides a comprehensive walkthrough of the lifecycle of a preconfirmation (preconf) transaction in the Taiyi protocol. Understanding this process is crucial for users, developers, and validators interacting with the Taiyi ecosystem. A preconf transaction goes through several key stages:- Initiation: The user sends a PreconfRequest to a Preconfirmer.
- Validation and Signing: The Preconfirmer validates and signs the request.
- Execution: At the target slot, the Preconfirmer either settles the request or exhausts it.
- Block Production: The transaction is included in a block through the Ethereum consensus mechanism.
This is the current version Taiyi-0.0.1 as of Oct 18, 2024. Details are subject to change as the protocol evolves.
1. User sends PreconfRequest
The process begins with the user creating and sending a PreconfRequest to the Preconfirmer. This request can be either complete (with transaction calldata) or partial (without calldata).
2. Preconfirmer validates request
The Preconfirmer checks the validity of the received request, including verifying the user’s balance in the escrow contract.
3. Preconfirmer signs PreconfRequest
After validation, the Preconfirmer signs the PreconfRequest to indicate its approval.
4. At target slot
ThePreconfirmer waits until the specified target slot is reached, then perform the following steps, depending on whether the user has supplied transaction calldata:
Scenario A: User supplies transaction calldata
If the user has provided complete transaction calldata in thePreconfRequest, the following steps occur:
5A. Preconfirmer calls batchSettleRequest
The Preconfirmer calls the batchSettleRequest function on the LubanCore contract to process the complete request.
batchSettleRequest() function
batchSettleRequest() function
6A. Preconfirmer submits transaction calling batchSettleRequest
The Preconfirmer submits the transaction that calls batchSettleRequest to the Relay for inclusion in a block.
Scenario B: User doesn’t supply transaction calldata
If the user sends a partialPreconfRequest without transaction calldata, the process differs:
5B. Preconfirmer calls exhaust function
The Preconfirmer calls the exhaust function on the LubanCore contract to process the partial request.
exhaust() function
exhaust() function
6B. Preconfirmer submits transaction calling exhaust function
The Preconfirmer submits the transaction that calls the exhaust function to the Relay.
Common steps for both scenarios
After either scenario A or B, the process continues with the following steps:7. Relay broadcasts transaction constraints
TheRelay broadcasts the transaction constraints to Block Builders. This step is part of the Ethereum consensus mechanism.
8. Block Builder builds block with constraints
Block Builders attempt to construct a block that satisfies the given constraints. This is part of the Ethereum block production process.
9. Block Builder submits block bid
Block Builders submit their constructed blocks as bids to the Relay. This is part of the competitive block production process in Ethereum.
10. Relay selects highest block bid
TheRelay chooses the most profitable block bid from the submitted bids. This selection process ensures the most economically viable block is chosen.
11. Relay shares block header for signing
TheRelay shares the selected block header with the Validator for signing.
12. Validator signs block header
TheValidator signs the block header, validating its contents.
13. Relay proposes block
Finally, theRelay proposes the selected and signed block to be added to the blockchain. This completes the block production process and adds the preconf transaction to the Ethereum blockchain.