Life Cycle of a Preconf Transaction
The lifecycle of a preconf transaction on Taiyi
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.
Each of these stages involves multiple steps and interactions between different components of the Taiyi protocol and the Ethereum network. The following sections will delve into the details of each step in this process, providing a clear picture of how preconf transactions are handled from start to finish.
This is the current version Taiyi-0.0.1 as of Oct 18, 2024. Details are subject to change as the protocol evolves.
Let’s break down each step of the preconf transaction lifecycle:
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
The Preconfirmer
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 the PreconfRequest
, the following steps occur:
5A. Preconfirmer
calls batchSettleRequest
The Preconfirmer
calls the batchSettleRequest
function on the LubanCore
contract to process the complete request.
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 partial PreconfRequest
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.
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
The Relay
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
The Relay
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
The Relay
shares the selected block header with the Validator
for signing.
12. Validator signs block header
The Validator
signs the block header, validating its contents.
13. Relay proposes block
Finally, the Relay
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.