7. The Smart Transaction Infrastructure

Alice wants to swap tokens, ensure minimal slippage and fast turnaround. Alice initiated her transaction by sending her request to the Laminator. The Laminator stored it onchain, acting as a virtual mempool. Its job was to provide spatial awareness. It understood the current state of the blockchain, including the status of all pending transactions. The transaction is now ready to be picked up by the Solver.

Fig 1. Smart Transaction flow, simplified

With respect to the Laminator's virtual mempool, Alice's transaction gets broken down by the wallet (or the equivalent frontend application used) into smaller individual transitions that make up the entire transaction. These are known as CallObjects, or internal transactions. Each CallObject represents a specific part/transition of the transaction, such as checking the token price, verifying account balances, or executing the swap itself.

The CallBreaker interacted with the CallObjects, verifying the truth conditions for each one. For instance, before executing the token swap, the CallBreaker would verify that « the token price was within the acceptable range specified by Alice » (being one of the truth conditions). If any condition was not met, the CallBreaker would halt the process, preventing any unintended or malicious actions.

7.1. Avoiding The Paradoxes of Time Travel

Any infrastructure that leverages time travel must have the capacity to handle paradoxes around changing events/transitions that further invalidate other such events/transitions which could then lead to invalidating the call from which the time travel was initiated. This is another form of the classic Grandfather Paradox. In order to avoid this, we use Deutsch’s solution around “causal consistency check” [“Closed Timelike Curves Make Quantum and Classical Computing Equivalent”, source]. This is the logic: upon return from the after/before transition, enforcing a causal consistency check as a default for any commitment on the call execution to be considered final, failing which, causes a rollback followed by trying again with a different timeline such that eventually no such causal consistency checks fail.

Transactions with Temporal Awareness: $T_i=(C_i,t_i)$

• $C_i$: Conditions.
• $t_i$: Logical times.

Oracle Function: $O(t)=D$

Example: Time Traveling Token Swap Transaction with Causal Consistency Check

1. Initial Transaction Definition:
   $U$ser initiates the $T$ransaction.
   $U\rightarrow T_{\text{init}}$

   Alice defines the transaction to swap 100 X tokens with a maximum acceptable price of 50 USDC per token at a future date.

   $T_{\text{init}} = { \text{SWAP 100 \textit{X} tokens in the future at }}t_{future}{, \text{Max Price} = 50}$ USDC

2. Storage and Spatial Awareness: $\mathcal{L}$aminator (virtual mempool) stores the transaction onchain, providing spatial (à la blockspace) awareness: $\mathcal{L}(T_{\text{init}}) \rightarrow T_{\text{store}}$
   Stored transaction with conditions: $T_{\text{store}} = {T_i, C_i}$

3. $\mathcal{S}$olver and Sequential Execution: Solver pulls the transaction sequentially for execution (could be at a later block based on temporal conditions: $t_{future}$ ).
   $\mathcal{S}(T_{\text{store}}) \rightarrow T_{\text{exec}}$

4. $\mathcal{E}$xecution and $\mathcal{V}$erification: Transaction is executed and verified to check if conditions are met.
   $\mathcal{E}(T_{\text{exec}})$
   $\mathcal{V}(T_{\text{exec}}) \rightarrow \{ \text{True}, \text{False} \}$

5. Interaction with Time:
   

   1. Check Past Conditions: Oracle provides historical data: $O(t_{\text{past}}) = 45$ USDC
      Condition met as 45 ≤ 50.
   2. Check Future Conditions: Oracle provides future data: $O(t_{\text{future}}) = 48$ USDC
      Condition met as 48 ≤ 50.

   Past and future conditions are $V$erified using MEV-Time Oracles.
   $\mathcal{V}(C_{\text{past}}, t_{\text{past}}) \rightarrow O(t_{\text{past}}) = D_{\text{past}}$
   $\mathcal{V}(C_{\text{future}}, t_{\text{future}}) \rightarrow O(t_{\text{future}}) = D_{\text{future}}$

6. Causal Consistency Check: Ensure the transaction does not create paradoxes: by ensuring that the future condition does not invalidate the past condition.
   $\mathcal{V}(T_{\text{exec}}) = \text{True iff } T_{\text{future}} \text{ maintains } C_{\text{past}}$

   This involves finding a fixed point where the state remains consistent over time.
   $\text{Find } x \text{ such that } f(x) = x$

7. Transaction Completion: If all conditions are met and causal consistency constraint is maintained, the transaction is considered completed (i.e., ready to be submitted for inclusion in the block, or an equivalent mechanism depending on the specifics of the confirmation logic of the chain). Otherwise, rollback and try again.
   $T_{\text{exec}} \rightarrow T_{\text{complete}}$

7.2. The Smart Transaction Lifecycle

As the LaminatedProxy held the transaction onchain, and the CallBreaker verified the conditions, the CallObjects interacted with each other across time. This dynamic interaction was orchestrated through the concept of MEV-time, allowing transactions to adapt and respond in hypertime (i.e., to both real-time data and future states as well).

The CallObjects would query oracles for the latest price data, check gas fees, and ensure that all parts of the transaction aligned perfectly. They communicated seamlessly, adjusting their execution paths based on the information they received.

Once all conditions were verified and optimal conditions were met, the CallBreaker would give the green light: the Laminator releases the transactions from the virtual mempool, and the CallObjects execute their tasks. If the Solvers actually optimize the transaction’s capital performance, Alice's token swap would be completed seamlessly, with minimal slippage and guaranteed timing.

Fig 2. Smart Transaction lifecycle

7.2.1. Example Workflow for a Token Swap with Conditional Execution Alice wants to swap tokens under specific conditions. She pushes her transaction calls to the LaminatedProxy, which includes an assertion that the solver must call a function checkBalance() to verify the trade conditions. The solver, Bob, then executes these calls, ensuring that Alice's conditions are met before completing the trade.

1. Transaction Queuing: Users push a series of CallObjects (aka internal transactions) to the LaminatedProxy with specified conditions. For example, a user might queue a transaction to swap tokens only if certain price conditions are met.
2. Transactions Stored Onchain: The proxy stores the internal transactions associated with trade execution along with other internal transactions associated with conditions/assertions.
3. Verification and Execution: The LaminatedProxy holds these transactions until their specified conditions are satisfiable by the smart transactions solvers. The CallBreaker executes the calls and ensures their integrity by reverting and invalidating the bundle if 1) a call fails or if 2) a call doesn’t return the expected return value. If the bundle is executed fully, then all included internal transactions’ revert-conditions must have been satisfied.

Fig 3. Alice swaps tokens with Bob as Solver

Diagram Description:

1. Alice: Initiates a transaction.
2. Laminator: Manages transactions and uses push() to forward the transaction to the LaminatedProxy.
3. LaminatedProxy: Acts as an intermediary, handling calls from users and directing them appropriately.
4. Bob: Checks conditions and states within the system.
5. CallBreaker: Verifies conditions and safeguards the integrity of the transaction flow. Interacts with Bob’s verification step as a final check and authorization step before the transaction is executed.

Flow:

• Alice’s call to the LaminatedProxy includes a transfer of 10 Token A.
• The transaction asserts that Bob will make a future call to checkBalance().
• Bob pulls calls from the LaminatedProxy with verify() to ensure the conditions are met.
• The CallBreaker interacts with Bob’s verification as a final check before the transaction is executed.

7.3. The Time Turner Mechanism

A mechanism that allows for checking and acting upon conditions in both the past and the future. Enables interaction with future states for temporal flexibility by embedding entire calls from the future. Basically, the setup ensures that smart transactions consider both historical and future states before execution, providing a robust mechanism for temporally aware condition-based transaction management.

This is the Time Turner high-level flow:

1. EVM Execution Direction:
   1. Check if in the past: A step to verify past conditions.
      1. The Time Turner checks if the condition is met in the past.
   2. First make a call to the past, then make call to the future: A sequential step where past conditions are validated before future conditions.
      1. If the condition in the past is met, it proceeds to execute actions related to the past.
      2. The sequential call step first makes a call to the past and then to the future.
   3. Check if in the future: A step to verify future conditions.
      1. Finally, the future condition is checked before executing future-related actions.
2. Smart Transaction Execution Direction:
   • This subgraph represents the ordered execution of transactions within the smart contract system.
   • Each step (marked with numbers 1 to 5) represents a direction in the transaction execution sequence/flow.

Fig 4. Time Turner High-level flow example

7.3.1. Detailed Breakdown of The Time Turner Lifecycle

1. Initial State (Push to Past)
2. Sequential Calls
3. Future State (Push to Future)

1. Initial State (Push to Past)
   • User Action: The user initiates a transaction sequence and pushes it to the LaminatedProxy.
     
   • Condition Check: This sequence includes a condition to be checked in the past facilitated by the Time Turner.
   • Steps:
     1. Push the first transaction to check if the condition in the past is met.
     2. If the condition is met, proceed to « do stuff in the past ».
        

Fig 5. Pushing to Past: Initial State of Time Turner

2. Sequential Calls

   • Validation: After validating the past condition, the next step involves making a call to the past first, followed by a call to the future.
   • Steps:
     1. First make a call to the past using the Time Turner to validate conditions.
     2. Then make a call to the future to ensure future conditions are set up correctly.
        
     

     Fig 6. Sequential Calls in Time Turner

3. Future State (Push to Future)

   • Final Check: The final sequence involves checking a condition in the future and executing actions based on this future state.
   • Steps:
     1. Push the second transaction to check if the condition in the future is met.
     2. If the condition is met, proceed to « do stuff in the future ».
        

Fig 7. Push to Future in Time Turner