Skip to main content

4. Key Concepts

Key Concepts, or how to reframe existing blockchain concepts in horological ways so we can apply them to our analysis of MEV, leveraging which we then design a horological resolution to MEV.

4.1. Trust as Timing: Timechain design insights​

The question of trust is always also one of time (or, timing to be precise): if I can go forward in time and always ensure that assertions are never broken, that such a time travel acts as a compensation for the need to trust. What precedes and remains inherent in the question of trust is the question about future. This comes mostly in the form of uncertainty and how we deal with it: what will happen in and as the future, what does the future hold for us in terms of the promises being made in the past as we ask this question the present.

Since it remains impossible to escape our present (see §4.3, “when we time travel, so does our present”), the question of trust can then be addressed when reframed in terms of our ability to travel to a transition that come after the current one so as to be able to report back to the current one. More specifically, this is time as timing in terms of being the before-after relation, and not on temporality (that of the past-present-future relationship). Timing is also the question of when exactly does a transition happen or need to happen, for the need to fulfill an assertion, thus trust assumptions as timing assumptions/assertions.

If we had a crystal ball to look into transitions that come after the current one such that we could make assertions that will always eventually come true, we would indeed inhabit a trustless universe. This is echoed in the theme of trustlessness [“this is the first time we're trying a decentralized, non-trust-based system”, Nakamoto] that Nakamoto inspired in all of us, as the rationale behind the invention of Bitcoin. Thus, the term timechain which Nakamoto used to refer to what we now call the blockchain seems in alignment to this logic of trust as a question of time. It is in this sense that we can speak of the concept of trustlessness in terms of timing under the logic of: to always eventually come true. (In Lamport’s framework of distributed systems, the always-eventual aspect is the liveness guarantee, and the coming-true is the safety guarantee [source])

  • Trusted third parties can then be framed as third parties that demand our time (as patience) in order for us to be able to infer whether they end up holding onto their promises (as an alternative to Szabo’s framing of “Trusted Third Parties are Security Holes”, source). Thus, when we deem a service to be untrustworthy, it is because over time it has kept failing at holding on to its guarantees. In both cases, the need to trust can then be translated as the need for the required time to pass, required for us to make the justifiable inference on trustworthiness or not. This makes the time travel argument: that if by some magic, we could peer into a later time from our vantage point in the here and now, that inference could be made immediately. It is in this way that time travel removes the need to trust — by replacing trust with facts from the future travelling back to past for a veracity check — making our relationship toward the service appear trustless. (more on this in §8.1)

  • In fact the replayability guarantee (inherent in the definition of blockchains) states that if we go back in time and replay through all of the confirmed transactions exactly in the order they appear on the blockchain (block by block), we will get the same resulting blockchain. Replayability is thus a rationale centered around the conception of the block production being akin to the ticking of a clock: as long as we bracket out the Leader Selection and the Transaction Selection Logic, by just considering the confirmed transactions as they appear on the block, each time we roll back the clock, we get the exact same chain. This is a clock that shows the time of the day in terms of the current block height, while also essentially leaving a trace (of provenance) of all of the time it had shown/ticked (in terms of the confirmed or past blocks — the “past tense” from §2). This is the time that is always and ultimately linear, in that no forks are allowed, as all attempted forks ultimately and always get collapsed into the singular/canonical chain (along with the uncles as the traces of those forks that lost, which is the case with some consensus protocols). Replaying is, thus, guaranteed to always and forever produce the same exact blocks all over again every single time. In the rhetoric of crypto, this is framed as trustlessness. This means creating a system where guarantees are so fully enforced that our reliance on trust is unnecessary for it to function as promised. This is largely made possible by the replayability guarantee. Essentially, it mirrors a clockwork universe through consensus mechanisms.

  • A similar argument can be made about verifiable computation, such that we can have guarantees of what would happen if the computation was run without actually having to run it. When a ZK Rollup produces the proof to be anchored in the chain, verifying the proof onchain implies that the offchain computation must have been run with the results as implicated in the onchain proof, all of this, without the chain needing to actually re-run the offchain computation in an onchain way. If an L1 had to run the original computation that would defeat the main point of offchain and expensive computation with cheap onchain verifiability. It is in this way that we can say blockchains also represent technologies of time compression: time seems to move faster in the L2 than in the L1 provided that the former can be compressed enough to be squeezed in between the moments/ticks that make up L1.

4.2. Time Travel Works On Timing and Never on Temporality​

When we mention "time travel," it is meant only in the way that time could be represented in the before-after mode (i.e., timing), and not as the mode of temporality (past-present-future). From a computational perspective, this means that the time element of smart transactions is to be modelled as a data structure of transitions/events such that they are ordered in a before-after relationship. This translates to a ordered series of ‘when’ each smart transaction exists.

This reliance on timing is due to the fact that even with going back or forward in time, one (the user, the transactor) can only and always remain in one's present. Where one is in time, that is the present moment. There is no present without there being a subject present. This is not a question of experience for even in sleep, we are where are in time, we do not vanish from the timeline just because we are asleep or absent minded. By presence, we mean physical presence, psychological presence is besides the point here. The present, by being so, remains inescapable for subjectivity or subjecthood. Where the subject, is when the present is.

So when we time travel, so does our present. Travelling in time remains in terms of temporality. Rather, it is implemented by changing the index of the before-after series of happenings: transaction ordering in the current block being produced, where a transaction belongs in a bundle/block, from where in the current timeline is it expecting calls and returnvalues as a condition for its execution). This is an expression of timing and not of temporality. From a computational perspective, this translates to reshuffling the ordering of transitions that make up the transaction. What remains impossible via time travel in smart transaction is reordering of blocks (aka a blockchain reorganization or a reorg), for that would have been an exercise in time travel with respect to transaction temporality.

(However, when we colloquially speak of going back to the past or the future, if we reframe this with our current understanding, we are referring to the past/future of someone else who is still in the timeline we left from, someone who was in the same present as me before I left for the past/future. In fact, this someone else usually happens to be not another person, rather a projection of ourselves, as if a part of us is still there in the timeline I used to live in prior to my time travel.)

4.3. Time Travel Does Not Break Immutability​

No time travelling transaction can go back beyond the current block, that is, to one of the confirmed blocks. However, it can go forward to a block that is not been confirmed, be it the current one in the middle of it being produced, or one that is to come later, by having the transaction remain in an onchain waiting station ready to be picked up by a Solver based on timing assumptions being true. This is key to the rationale behind virtualizing the mempool, as is the case with our infrastructure (see §7). This entails holding the mempool onchain rather than the usual way of prechain mempool. This is carried out by storing the new/pending transitions onchain. While waiting to be picked up is one aspect of timing, the other one is also around locks and partial isolations for transactions to be able to manage their side-effects — this is the logic behind atomicity, and to be precise version of it, that of semi-atomicity. Atomicity remains fundamental as a property for the safety of a transaction execution, even in the case of time travelling transactions.

This means, with time travelling transactions, the infrastructure should be able to change (such as, when deciding to commit a transition or to rollback -and-retry) a before transition/event based on validating what comes after (returnvalues or calls), but must at all costs be barred from being able to change the past. Since the past represents confirmed transactions, we would have to be able to reorder confirmed blocks — that is definitely not conceptually possible and remains technically impermissible by what we mean by and how we design our time travel infrastructure. It is rather searchers reshuffling the before-after relationships of transaction ordering towards optimizing the most MEV. In fact this is where we see the great confluence of the blockchain immutability regime and the replayability guarantee: the latter ensures that we can always go back to the past, while the former prevents us from being able to change the past when we are in it. And now with smart transactions, transactions can travel to before and after places in the timeline to change the ordering of transactions being currently solved.

This is how we resolve the paradox of immutability with respect to time travelling transactions, since we:

  • can traverse back to past blocks
    • and replay the past (as replayability operates under temporality)
    • but never be able to change the past (as immutability operates under temporality)
  • yet we can change before-after relationships between transactions (this is time travel as it operates under timing).

Thus, time travel happens with respect to timing (going back to a before or an after, searchers reshuffling the ordering of transactions), while immutability is a matter of temporality, in that the past/confirmed transaction can never changed (Refer to Table 2). Therefore, contrary to popular opinion, time travel does not break immutability.

Time Travel’s reliance on the before-after model is in line with Leslie Lamport’s 1978 inaugural work on distributed systems where he framed the question of coordination as one of being able to synchronize around the differing before-after sequences of the nodes of the network; this was his paper on logical clocks. This reliance on timing over temporality as a design criteria is also reflected in Nakamoto’s design of the “peer-to-peer distributed timestamp server” as stated in the Bitcoin Whitepaper.

In this paper, we discuss the partial ordering defined by the "happened before" relation, and give a distributed algorithm for extending it to a consistent total ordering of all the events. This algorithm can provide a useful mechanism for implementing a distributed system. We illustrate its use with a simple method for solving synchronization problems. Unexpected, anomalous behavior can occur if the ordering obtained by this algorithm differs from that perceived by the user. This can be avoided by introducing real, physical clocks. We describe a simple method for synchronizing these clocks, and derive an upper bound on how far out of synchrony they can drift.
- Leslie Lamport, 1978, “Time, Clocks, and the Ordering of Events in a Distributed System”

4.4. Cryptoeconomics of Time Travel​

The logic behind the meme, "don't trust, verify", is one of collapsing the twin sides of a different kind of time travel that what we discussed so far. We refer to this as cryptoeconomic time travel (differentiating it from the time travel using MEV oriented transaction reshuffling, that we discussed so far).

  1. Trustlessness is ‘virtual’ time travel travel to the future. To trust x — is to have the assurance that promises that x entails will be kept. But if we are able to visit the future, we would not need to trust, for we would just be in presence of the events happening or not, to verify if indeed it is trustworthy. Thus, being able to free oneself from the burden of trust is as-if one is travelling to the future, so no trust is needed, just direct evidence.

  2. Verification of a Proof is ‘virtual’ time travel to the past. But me verifying a proof of x signifies that the x already exists/happened for the proof of it to be generated/there. To be able to verify means that the proof is already there, so the event for which the proof is a stand-in, as it already happened. It is as-if what the proof claims of what happened (what happened, captured as x) is indeed true without me physically travelling to the past, but with the same effect if I did, which is virtual time travel to the past.

In both cases of time travel described above, the future and the past are actual, they are not virtual. However, the travel is not actual but virtual. No one (e.g., a computer agent, a verification engine, an user, fraud checker) is physically leaving the present moment, so as to vanish and reappear at a point in the past or the future. Rather, it a movement in time by virtue of the cryptoeconomic setup, by doing so results in the same effect of an actual time travel but without actually doing so. This element of ‘acting as if,’ ‘by virtue of, ‘ ‘acting so but without doing so’ brings in the aspect of virtuality in terms of the time travel to actual past and actual future.

A major difference must be pointed out. Cryptoeconomic time travel happens on the temporality register while the transaction reordering one is one of timing. The former is possible in spite of the objections in §4.2 because it happens virtually and not actually, while the latter is not a travel to past or future, but to the before or after by way of reshuffling the before-after relationship in terms of transactions ordering.