8. Beyond MEV: Smart DApps

The design of the smart transaction infrastructure must be aligned with respect to the applications that it will be catering to. Thus, a careful consideration of the application layer is essential for a design that is adaptable.

Currently, all of the innovations at addressing MEV, in spite of the high promises, ultimately almost always exclusively end up being deployed to build better and fancier services for swaps. It usually comes wrapped up with the framing of a DEX but at the base of it all, it is still a swap, it still deals with liquidity provision or order books or questions of matching efficiently counterparties. It is tragic and comic at the same time, that behind all of the sophistication of computer science and the complexities of cryptoeconomics, it is all at the service of: how to have slippage protection and low gas fees for swapping tokens. In fact, to look at the broader class of applications of and in crypto, swaps, staking, wallets, attestations, and the various variations of these and with each other, cover all of the use cases that are currently the most used. This is a stark contrast with today’s dominant application usage patterns. This is where our approach differs:

1. A (smart) transaction is not always reducible to a swap. (For example, querying a database or uploading a file to cloud storage are transactional operations but not swaps)
2. Solvers must be solving real life problems (including but not limited to swaps)
3. MEV-time Oracles makes syncing I/O much more immediate than the previous limit of blocktime.

Solvers, optimizing for MEV, prioritize transactions that can be easily verified and yield high returns. Swaps, with their clear input-output relationships, are ideal candidates for this optimization. This dynamic has led to an ecosystem where most onchain operations are swaps, sidelining other potential uses of blockchain technology.

Unless a solver also can solve real world problems, like that of finding the most efficient route from Point A to Point B (such as for building a taxi hailing cab onchain), then solvers are only left with solving one task: (capital efficient) swaps. What prevents solvers to provide these other services is the trust assumption required behind these. But with swaps, we can establish objective functions to achieve capital efficiency in ways we can prove the veracity of the auction mechanism used, making it best suited to trust-minimized applications.

This is a careful design choice we make here:

1. Rather than look for a zero trust use case, we look for designing around applications that can be decomposed into its many aspects, some of which can be made trustless within acceptable levels. Each of these parts would act in the form of microservices based third party searchers to provide services.
2. MEV-time allows for anchoring trust points mid block instead of the previously possible one of the blocktime being the limit where anything that is beyond L1 (L2 and more) can be anchored, and the same for oracles for outside world communications. Instead with MEV-time anchoring of computations that can be in an interactive mode with the chain in almost realtime (à la just-in-time), or with MEV-time Oracles for outside world communications. We refer to this as L1.5
3. Smart DApps that are a hybrid leveraging the benefits of both crypto and Web by having the third party searchers sit in between the two worlds.

Microservices based virtual service provider that anchor its I/O (such as, by co-signing a hash of I/O data to have it MEV-timestamped) with respect to the chain in MEV-time — that is the approach toward building hybrid apps.

8.1. Third Party Searchers

Third Party Searchers (TPS) bridge the gap between Web and crypto by offering services that enhance smart transactions. These services include HTTPS connections to send/fetch data on demand, off-chain services of web hosting, and transaction relaying. This is the aspect of the smart transaction infrastructure that leverages services across chains as also connecting beyond blockchains insofar as the trust assumptions — when leaving the home chain, especially when it relates to non-crypto service endpoints — can be justifiably compensated with respect to the capital benefits from such scale for all stakeholders involved. This would entail domain specific design and deployment of complex incentive schemes that can ensure acceptable levels of honesty across the stakeholders.

Fig 8. STXN Supply Chain

TPSs provide services via API connections, enabling smart transactions to leverage Web services for future hybrid applications. There could be multiple TPSs providing similar services in competition with each other, such that they are in a staked service layer marketplace, where if any provider gets caught providing faulty service could be punished. However, TPSs are not real providers but extract value through interactions with external third parties, reducing their liability.

They operate by making API endpoints where a HTTPS query is replied with a JSON object, such that the HTTPS Session and the crypto transaction lifecycle can be mutually incentivized. They are a bridge between Web and crypto, made possible largely due to the discovery of MEV-time, since it opened the possibility of I/O and onchain verifiability that does not have to wait for blocktime but can sync immediately between the worlds of crypto and Web. This opens up the possibility of building Hybrid DApps that leverage services between these worlds.

Ethereum [...] also opens the door to whole new kinds of applications that have never been seen before.
— ethereum.org on the WayBackMachine from 2014.

8.2. Hybrid (D)Apps need Hybrid Timelines

This question of hybrid applications is one of bridging the differences in trust assumptions between applications, especially, when it caters to decentralized applications on one side and centralized ones on the other, as in that case, the trust assumptions are not just different but incompatible, that is to say, there seems to be an intrinsic incompatibility of trust between these applications resulting from the differing network topologies (centralized/decentralized) of power and/as politics.

It is here that we see the relevance of the idea from a previous section §4.2: “the question of trust is always also one of timing.” When we superimpose this idea onto the current one (that of hybrid applications as one of bridging the differences in trust assumptions of Web and crypto) into a single image, we realize that: the question of hybrid applications is one of time travelling but in a specific way; this is not travelling within the same timeline (for that would be the case between applications of compatible/interoperable trust topologies), rather that of time travelling between incompatible timelines, while needing to communicate between these disparate timelines.

Each application with its own timeline reflects the trust assumptions (the topologies that enable those). From a computational perspective, this translates to having not just a single sequence of before-after relations on which the multiple applications' transactions can then be mapped onto, instead multiple such sequences (at least one for each application), many of which do not even align their before-after markers (or index separators) with each other. That is, the transitions that make up the transactions in each application do not always align in terms of their before-after markers, making any attempt at time travel a considerable design issue.

Fig 9. The Example of Three Timelines in Lamport’s 1987 paper, a timeline for each process

This takes us back to Lamport’s inaugural paper (that introduced the subject of distributed systems in computer science), as this mismatch was precisely the challenge that separated distributed systems (that Lamport wanted to study) from concurrent systems (that previously Dijkstra, Hoare and others studied). Just as Lamport went from improving the work of Dijkstra/Hoare on Concurrent Systems, what we have with MEV (and specifically, STXN in our case) is the challenge of going one step further from Lamport. We can do this by incorporating Nakamoto's improvements on time modeling: in addition to the before-after relationships for transaction ordering in Bitcoin (and later Ethereum) offers, the Proof-of-Work (and later all other consensus protocols in spirit, like that of Proof-of-Stake) makes the time plastic by mandating the sync block by block instead of the continuous model of Lamport and all traditional BFT ones as well, since the blocktime offers enough time to sync the gaps between the different before-after markers of the multiple timelines (as not all nodes in the network will be on the same timeline at all times). Our proposal here is to go one step further building on Nakamoto’s sync-block-by-block-within-a-before-after-sequence, by forcing the sync between the differing and incompatible timelines to happen in MEV-time instead of waiting on blocktime.

Basically, we have to leverage MEV-time Oracles to ensure time travel between systems that differ in their trust (and so timing) assumptions: MEV-time Oracles to bridge Web and crypto (like between Ethereum and other EVM chains). This is the design goal of Hybrid DApps as Hybrid Timechains since each app comes its own timeline: syncing up on the timing differences between the different trust topologies.