The fair exchange problem exists between the user and the preconfirmer. There are multiple attack vectors that could be exploited, allowing either party to take advantage over the other. Here are a couple of examples:
  1. The preconfirmer, upon receiving the user’s preconfirm request, could withhold the information instead of broadcasting it. Worse still, they could steal the user’s transaction to front-run it. To address this problem, the system has to rely either on centralized trusted parties or alternative data availability solutions such as EigenDA. Simply put, the solution is not ideal.
  2. On the other hand, the user could withhold the transaction to intentionally cause the preconfirmer to be slashed, since the preconfirmer has no transaction details to share.
In fact, this is a classic problem in cryptography - Fair Exchange problem

​
Definition of the Fair Exchange Problem

The Fair Exchange Problem can be defined as follows:You have two parties, Alice and Bob. Alice has a piece of data DaD_a (e.g., raw data identified by a hash, signatures, results of a database query, etc.) that Bob wants, and Bob has a piece of data DbD_b that Alice wants.Problem: Can one design a trade mechanism that ensures atomicity, i.e., either both Alice gets DbD_b and Bob gets DaD_a, or neither Alice gets DbD_b nor Bob gets DaD_a?
A key result in the field is that, in the general case, fair exchange is impossible without a third party. However, in our context, we don’t want to rely on a third party. A zero-knowledge proof may be applicable to the current problem.

​
Proposed Solution

According to Justin Drake, he proposed a solution to the fair exchange problem using zero-knowledge proofs. The scheme would work as follows:
  1. Both Alice and Bob encrypt DaD_a and DbD_b using public keys PubaPub_a and PubbPub_b to produce EaE_a and EbE_b
  2. They swap (non-atomically) EaE_a and EbE_b (this shouldn’t reveal information about DaD_a or DbD_b if padding is used)
  3. They prove to each other in zero knowledge (e.g., using zkSNARKs or zkSTARKs) that EaE_a and EbE_b were correctly constructed
  4. They post a large collateral (much larger than the value of DaD_a or DbD_b) into a fair exchange smart contract initialized with parameters PubaPub_a and PubbPub_b
  5. They reveal their private keys to the contract
  6. The contract verifies that the private keys match PubaPub_a and PubbPub_b, and if so, releases the collateral back to both parties
  7. Alice and Bob can now decrypt EbE_b and EaE_a respectively
While this sounds promising, the cost of on-chain interaction and latency caused by the state of the art zkp tech stack raises user experience concerns. We need a more performant solution.

​
Taiyi’s Solution

Here, we propose a solution that leverages the game-theoretical dynamic between the preconfirmer and user. Inspired by the design of LedgerHedger, we can indeed solve the fair exchange problem. Our approach introduces a strategic game between two key players:
  1. The user (transaction initiator)
  2. The preconfirmer (transaction executor)
This game is designed to achieve the system goals of Partial Data Commitment and Fair Exchange without additional Trust Assumptions.

​
The Game

For a detailed explanation of this mechanism, we recommend reading Simon Brown’s article on Proposer Commitment Infrastructure in Ethereum. Simon Brown provides an excellent breakdown of how this system works and its implications for fair exchange in blockchain transactions.
  1. User Request:
    • The user sends a request with: 
      {
  "estimatedGasLimit": "uint256",
  "blockNumber": "uint256",
  "executionConditions": "optional",
  "tip": {
    "prePayment": "uint256",
    "afterPayment": "uint256"
  }
}
    The request does not include transaction data (preconfTx).
  2. Preconfirmer Response:
    • The preconfirmer simulates the transaction to ensure the user has sufficient balance.
    • If the tips are sufficient, the preconfirmer accepts the request by co-signing it with the proposer and sending it back to the user.
  3. Transaction Data Sharing:
    • The user must share the transaction data (preconfTx) with the preconfirmer no later than 6 seconds into the specified block.
  4. Exhaust Function:
    • If the user fails to share the data or submits a transaction exceeding the original gasLimit, the preconfirmer can call the exhaust() function.
    • The exhaust() function: a. Burns an amount of gas equal to the specified gasLimit b. Transfers the prePayment from the user to the preconfirmer c. Relieves the preconfirmer of the commitment duty
  5. Incentive for Inclusion:
    • If the user sends the transaction data on time, the preconfirmer is incentivized to include the transaction rather than calling exhaust().
    • This allows the preconfirmer to receive both the prePayment and afterPayment.

​
Conclusion

The success of Taiyi’s fair exchange system hinges on carefully balancing incentives through thoughtful parameter selection, particularly in the distribution of payments:
  1. PrePayment: This initial payment to preconfirmers upon accepting a transaction request must be sufficient to maintain an attractive risk-to-reward ratio, ensuring continued interest in the system.
  2. AfterPayment: This contingent payment, released upon successful transaction execution, must be substantial enough to discourage abuse of the exhaust() function and promote commitment fulfillment.
In the initial stages, we recommend users set higher afterPayments, relying on social consensus to prevent abuse. However, as we progress towards decentralizing the preconfirmer role, it becomes crucial to:
  • Conduct extensive game theory analysis, drawing inspiration from studies by Manifold Finance and 20Square.
  • Continuously refine the system based on simulations and real-world data.
By meticulously designing and iterating on the game-theoretical aspects of Taiyi, we aim to establish a robust, fair, and permissionless market that serves preconfirmers, proposers, and end-users alike. This ongoing process of refinement and optimization will be key to Taiyi’s long-term success and adoption in the blockchain ecosystem.