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:

  1. Initiation: The user sends a PreconfRequest to a Preconfirmer.
  2. Validation and Signing: The Preconfirmer validates and signs the request.
  3. Execution: At the target slot, the Preconfirmer either settles the request or exhausts it.
  4. 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 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

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.