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 Builder
s. This step is part of the Ethereum consensus mechanism.
8. Block Builder builds block with constraints
Block Builder
s 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 Builder
s 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.