3. MEV-Time and Cross-Time Transactions
What we get with the Present Active temporality of a transaction lifecycle, is that finally EVM based infrastructures can now be in an interactive relationship with transactions as they are under the confirmation process. This opens up realtime operations for the first time in crypto, as realtime is the confluence of present and active.
However, to be precise, there was always a case for Active mode of transaction lifecycle in crypto but not in the full spectrum as MEV has opened up. This was the case, where for example, Bitcoin scripts once included in the block, will later on be offchain executed by whoever intends to claim the bitcoins associated with that script, then sending the result in a transaction for it to be included for those coins to be claimed/forwarded, making the active mode being possible but at a later time of the initial transaction script being included in the chain, as also its verification of having been executed at an earlier time than the inclusion in the chain. There is also a similar decoupling of active from any present modality for offchain computations that are verified later onchain, or with rollups. But the change that MEV brought was the coming together of the active and the present, which is referred to as realtime.
3.1. MEV-time > Blocktime
With MEV, we have realtime in terms of the temporalities of transaction lifecycle (Chronos), as we have time travel with respect to the (timing as now) before-after notion of transaction timing (Kairos). These two advancements in technologies of time as the timechain, when put together results in « hypertime = realtime + time travel ». We refer to this as MEV-time, or MEVt.
MEV represents an evolution in the way time operates in consensus protocols by evolving from blocktime to MEV-time. Even with the limitations of having to wait for blocktime for confirmation, interaction with the chain is now mid-blocktime as well, as a result of hypertime.
Searchers can interact with transactions during MEV-time by introducing values, updating oracle data, and performing operations within the transaction flow. This interaction breaks the traditional atomicity of transactions, allowing for more complex and adaptive behaviors. By leveraging MEV-time, transactions can become aware of multiple possible futures and adjust their execution based on the most favorable outcomes.
3.2. MEV-Time Oracles: Communicating Across Time
Traditionally, information travels in space, moving between servers, nodes, client endpoints, and so on. Oracles exist to facilitate such movement between blockchains and the outside world, since all information within the chain must be verifiable, oracles act as trusted portals for such movement in space. However, with time travel, transactions can refer to values or calls from the future for their own validation, This is information that is travelling no longer in space, as both sides of the movement remain within the chain (even with the same block at this development stage of our infrastructure). Rather the information is travelling across time: since cross-time transactions do not leave the chain, they come with the same degree of trust guarantees on both sides of source/destination. It is a purely onchain movement of information but with different time horizons. Thus, the terms of on versus off chain are no longer sufficient here, as they are spatial metaphors — on is the space inside the chain as compared to off as outside that space.
We need new terms to refer to movement of information across time but within the same chain. This will be the case of an oracle communicating not between the here and the there (being the case with traditional oracles), but between the now and the then. How about nowchain and thenchain? How about cross-time transactions instead of cross-chain transactions.
Since the information never leaves the chain, both sides of the here and the now follow the same logic of verification that all onchain information must abide by. Thus, this particular type of oracle is working across time, or if we call it, the MEV-time Oracle. It does not suffer from the challenges of the traditional oracle (i.e., the space oracle), that of the trust assumption. The information of the there can be verified onchain by the now. MEV-time Oracles are onchain oracles.
To sum it up, we can say: it is onchain oracles that act as portals for cross-time transactions by being a pathway for data to move between the thenchain and the nowchain since such data comes with the same verification logic on both sides of the movement.