5. Design Rationale

Design Rationale, or on what principles and guidelines are we to build a time machine on Ethereum.

5.1. TLDR

• The Current Problem underlying MEV: Discovery of the « Present and Active » mode of Consensus
• Current Solution (a la PBS): Decoupling the Present from the Active, wrt Proposers and Searchers bring responsible for each respectively
• New Solution (a la STXN): « Time Travel » — Instead of The Decoupling, transactions can validate across time, by leveraging Future Active modes of temporality. This is MEV-time. Kairos (Timing) to rescue Chronos (Temporality).

5.2. Time Travel Infrastructure

The philosophy of smart transactions extends transaction semantics to improve the ability of transactions to validate their execution. The basic approach is to create a space and an interface where searchers and smart transactions can interact, also allowing smart transactions to interact with each other across time. Smart transactions infrastructure should be used by searchers to provide timely and reliable information to transactions, information based on which transactions can conditionally revert their own execution, and also those of all transactions bundled with them. This information might include, for example, future return values of future transactions, amounts of gas consumed, and oracle values.

Consider a transaction designed to swap tokens. As its first criteria, it wants to maintain a certain slippage protection: the transaction will search far and wide to find enough hops between many other pairs to eventually settle such that it results in the satisfaction of the acceptable slippage range, failing which, the transaction will revert itself. As its second criteria, if the tokens to be swapped operate under the conditions that adjust the execution based on realtime price data from an oracle, then if the price moves unfavorably, the transaction can automatically revert or adjust the swap parameters to minimize losses.

Thus, smart transactions infrastructure is to be designed in such a way that the transactions manage their own lifecycle with the aim of ultimately satisfying the constraints encoded in the transactions. This demands that transactions be able to operate in MEV-time allowing transactions to

• self-adjust in an interactive mode with the Searchers (as these transactions are waiting to be confirmed for the current/next block)
• decide whether to execute or revert by verifying truth conditions

The infrastructure should allow for transactions to be able to inspect neighboring transactions within the same timeframe, or on the eventual outcomes from the future (as long as within the MEV-time horizon, which is blocktime in most cases), or on the information from the outside world (Oracles that run on MEV-time instead once every block). “Smart” means being — able to adjust its execution path, manage its lifecycle, — powered by MEV-time interactivity. Thus, we need to design the underlying transaction infrastructure in such a way that it facilitates interactivity.

5.3. Key Design Objectives:

1. Model Time as Timing (before-after relations) and not as Temporalities (Past-Present-Future).

   • Principle: When a smart transaction exists is a question of where it is in the sequence of before-after relationships of transitions/events.
   • Implementation: The time data structure must be able to unequivocally establish the before-after sequence of transitions/events that make up the list of all smart transactions on the system.
   • Example: The ordering of transactions in a bundle/block already reflects their internal before-after relationships with respect to each other; this is also the index for each transition, as also the ever-increasing nonce for every attempt at sending transactions (the increasing aspect is what makes the after be at least one more than the before).

2. Extend Transaction Semantics Over Transaction Execution

   • Principle: The extension of transaction semantics is a fundamental principle that allows transactions to express conditions and preferences beyond the linear execution of code.
   • Implementation: Leveraging MEV search, transactions can interact dynamically with the context, making real-time adjustments based on the latest available I/O and state changes.
   • Example: A transaction can be designed to execute only if the real-time price data from an oracle falls within a specified range, ensuring optimal conditions are met before execution.

3. Empowering Transactions to Trust-but-Verify

   • Principle: Ensures that if any transaction in a bundle is executed without invalidation, all other transactions in the bundle are also executed successfully.
   • Implementation: Include verification steps within transactions to check the validity of their conditions before execution. This minimizes the risk of fraudulent or erroneous executions.
   • Example: A batch of transactions includes multiple token swaps. If one swap fails the verification, the transaction reverts, but the other valid swaps proceed, ensuring partial execution instead of complete failure.

4. Enabling Context Awareness in Transactions

   • Spatial Awareness: Awareness of the current state of the blockchain, including the mempool and blockspace context. This involves understanding the status and details of pending transactions and the state of the world outside the blockchain.
     • Implementation: Transactions are designed to adapt based on realtime data from the blockchain and external sources, adjusting their behavior accordingly.
     • Example: A transaction adjusts its gas price based on the current congestion in the mempool, ensuring timely execution without overpaying.
   • Temporal Awareness: Awareness of past, present, and future states, allowing transactions to validate values from the future or recontextualize present execution based on past states.
     • Implementation: Transactions consider temporal factors, scheduling execution based on anticipated future events or validating conditions from past states.
     • Example: A transaction can be scheduled to execute at a specific future block height or upon receiving a particular oracle update.
   • Always Be Retro-fitting Prophecies To Remain Fulfilled: Transactions should MEV-timely verify their conditions and adapt to ensure they meet their intended outcomes, even as the blockchain state evolves.
     • Implementation: Embed adaptive logic within transactions to MEV-timely check and adjust conditions to align with desired outcomes.
     • Example: A transaction designed to trigger an automated market maker (AMM) adjustment MEV-timely checks oracle data and adjusts parameters to ensure market alignment.

5. Turning Transactions into (Virtual) Programs or Autonomous Entities / Blurring the Boundaries Between Transactions and Contracts

   • Principle: Transactions are no longer static instructions but dynamic entities that can adapt to the blockchain's state (current and future state) and external information.
   • Implementation: Transactions incorporate conditional logic and verification steps, enabling them to function autonomously and interact with multiple contracts and data sources.
   • Example: A transaction can include logic to check multiple conditions, interact with various smart contracts, and trigger additional actions based on outcomes, similar to a smart contract's functionality.