❓Taiyi V0 Solution

Overview

Inspired by the design of LedgerHedger's, we introduces a strategic game between two key players: the user (transaction initiator) and the preconfer (transaction executor) to achieve the system goals, namely Partial Data Commitment and Fair Exchange without additional Trust Assumptions.

By defining a set of rules and conditions under which transactions are executed, this design effectively transforms these interactions into a strategic game. This game is designed to align the incentives of both parties with the intended behavior prescribed by the protocol.

The Taiyi's preconfirmation system is "optmisitc", relying on a fraud proof based mechanism such that

• If the preconfirmer fails to include an inclusion commitment on the requested block, the user could submit a challenge to slash the preconfirmer later.

To facilitate fair exchange and enable partial commitments, the system must prevent users from intentionally slashing preconfirmers by withholding transactions. If the preconfirmer has no transaction data, there are no transaction to submit. As such, user could intentiaonlly slash the preconfirmer by not sharing the transaction detail after getting preconfirmer's commitment.

Due to this concern, the game has to align seemingly conflicting interest parties by

• requiring users to put up collateral. If the user fails to provide the transaction data, the preconfirmer can claim the collateral to avoid being slashed.

• creating an incentive structure that makes it more profitable for preconfirmers to include the transaction when the user submits it on time.

The Game

1. The user sends a request with estimated gasLimit, block number, optional execution conditions, and a two-part tip (prePayment and afterPayment), but without transaction data(preconfTx).

2. Upon receiving the request, the preconfirmer simulates the transaction to ensure the user has sufficient balance to cover both prePayment and afterPayment. If the tips are deemed sufficient, the preconfirmer accepts the request by co-signing it with the proposer and sending it back to the user.

   1. Initially this is done via a special purpose escrow contract. Later, fund locking mechanism could easily transition to smart contract wallets that implements ERC7579 modules.

3. The user must share the transaction data (preconfTx) with the preconfirmer no later than 6 seconds into the block specified in the initial request. If the user fails to do so or submits a transaction that exceeds the original gasLimit, the preconfirmer could call the exhaust() function at anytime to void the commitment.

4. The exhaust() function does three things

   1. burns an amount of gas equal to the gasLimit specified in the original request,

   2. transfers the prePayment from the user to the preconfirmer (but not the afterPayment), and

   3. relieves the preconfirmer of the duty to honor the commitment.

   Sample implementation of gasBurner function

   ‌function gasBurner(uint256 gasLimit) public view returns (uint256) {
           uint256 startGas = gasleft();
           uint256 gasCost = 0;
           while (gasCost < gasLimit) {
               if ((gasCost + startGas - gasleft()) > gasLimit) {
                   break;
               } else {
                   gasCost += startGas - gasleft();
               }
               startGas = gasleft();
           }
           return gasCost;
   }
   

5. Alternatively, if the user has sent the transaction data on time, the preconfirmer is incentivized to include the transaction rather than calling exhaust(), as they can receive both the prePayment and afterPayment.

---

While the current design outlines the fundamental rules of the game, a critical aspect of ensuring the success and functionality of this system lies in the careful selection of parameters, particularly the distribution of payments (prePayment and afterPayment).

• PrePayment: This is the initial amount paid to the preconfirmer when a transaction request is accepted. If this amount is too low, preconfirmers may find the risk-to-reward ratio unappealing, which could result in a lack of interest in accepting requests.

• AfterPayment: This is contingent on the successful execution of the transaction as per the agreed conditions. If this amount is too low, there is a higher incentive for preconfirmers to abuse the exhaust() function without actually honoring the commitment.

Initially, we recommend users to set a higher afterPayment since we can be trusted not to abuse the exhaust() function by social consensus.

As we gradually decentralize the preconfer role, it is imperative to conduct more extensive game theory analysis similar to the one has done by Manifold Finanace and 20Square.

By carefully designing the game-theoretical aspects of Taiyi and continuously refining the system based on simulations and real-world data, we aim to create a robust and fair solution to create a fair and permissionless market for preconfirmers, proposers, and end-users.