The only way to be based is to be sequenced… wait I think I got that backwards…

I touched in last mirror on a concept known as “Competitive Based Sequencing.” Let’s expand on that here and talk more about how we can leverage blockchains as dedicated data availability and transaction sequencers. This is all in a series on Aori, Based Sequencing, and how we can build apps in the future that without using auctions minimize MEV leakage and dead weight loss.

When a base layer of decentralization like Ethereum exists, we can imagine networks of non-blockchain layers; for example, Actively Validated Services (AVS). However, AVS systems are much more appropriate when security of another network is the goal. Something important to consider is what specifically is the application’s goal for it’s transaction sequencing. In the case of Aori, speed of execution is our number one priority in order to minimize state drift.

In this code example from AoriV2.sol, you can see that in the order details and user signature, we’re storing and validating that the order hash has not been previously settled. This ensures two things:

1. The order cannot be double settled

2. If there is a network of orderbook operators competing to settle this transaction to capture the fee of the transaction, then it is in the best interest of the orderbook operator to be FAST.

If for example, the goal of an application was not speed, and instead compliance; they could instead require that the transaction sequencer was a particular public key of a known node operator (this would be most applicable for institutional applications). Another alternative of this would be an application that requires a certain level of decentralization, so it could add directly in that a transaction must have a minimum of three signatures provided by alternative operators (aka a Multi-Sig wallet). This ensures propagation and consensus but is entirely “Based” in that the organization of these signatures is entirely off-chain.

In the above diagram, the queen is both defending the rook, and the knight (highlighted with red arrows). The mistake the white player made was rook to e3 (purple), as that overloads his queen. Now, black can play the brilliancy Queen c2, which allows white to take the queen on c2, followed by white queen taking the black queen on c2, then the fork knight to e3, putting the king in check and winning back the queen on c2. Black wins a rook in this exchange.

This is known as “Overloading” a piece. The queen is trying to do two things at once, and thus cannot do either. Decentralized applications have done the same thing. They have tried over and over to include two components into their smart contracts, which thusly negates both:

1. Logic

2. Storage

Let’s look at an example with relation to AMM’s. Historically when a new asset class is created, sophisticated market makers and liquidity providers of all kinds take sometimes years to inoculate themselves and scale into said emerging markets. The AMM allows for a market to instantly have both a market maker, and guaranteed liquidity at the time of execution. It truly appears to be the solution to the problem of finding and sourcing liquidity all in one innovation!

However, this is not so. When we analyze the historical performance of AMM’s we see clearly that the announcing of the market making strategy (constant function, range bound liquidity, etc. etc), gives all other actors an informational edge to exploit. We then clearly see that the way market makers and LP’s in traditional finance make money is some asymptotic information or strategy, and that if they were to announce their strategy, the same thing that happens to AMM’s would happen to them.

This is a case of overloading, simply because:

1. The AMM appears to solve the problem both of finding a market maker, and being easy to deploy

2. External actors then can attack the pool through various strategies such as sandwiching, LVR, and others.

I think this means that the only solution is to have smart contracts with strict guard railing aimed at ensuring that node operators are not able to manipulate user intents/signatures without instant reversion. You can see how we’ve approached that here:

Every single line of code in this screenshot is decoding the user’s signature that they provided to the node operator, and validating the following:

• The order hasn’t expired

• The maker or taker nonce isn’t stale

• The chain Id the user’s signed for is correct

• The smart contract the user signed for settlement to is this exact contract

• The signature actually came from the correct maker and taker address, and is not fraudulent

• And lastly that the tokens that both users signed to swap are matching

When smart contract development becomes creating giant walls of requirements, rather than hiring auditors for +$250,000 to review every single piece of logic, the risk declines by orders of magnitude. Almost all of the largest non-exchange hacks were this form of exploitation, and a removal of logic from smart contracts appears to be the only way to appropriately onboard the next billion users.

This also begs the question how do we guarantee censorship resistance if the applications are off-chain servers? Let’s address first the simple fact that signatures without access to the user’s private keys are impossible to forge. So the only risk with the above contract is censorship (outside of having enough signature validation rails as mentioned in the previous section). That is where several approaches can work, by my estimation.

1. Competitive Based Sequencing

2. TEE’s

3. AVS

Let’s take each one at a time.

This is the approach I’m most sympathetic to, and thus am listing first. Competitive based sequencing makes the assumption that a sufficient enough set of node operators competing on settlement of every transaction. This works similar to the current setup I detailed in the above section “Logic Not Required,” but allows for a user to send an order to multiple orderbooks, and settlement to be a race between all orderbook operators. Any app could integrate this system in, and allow specific node operators to earn fees depending on that app’s setup. Every orderflow provider can send to their own node to capture the fees, or pay other node providers for the service of speed, kickbacks, or hosting costs.

Trusted Execution Environments are another new approach to this problem of how can you guarantee or get as close to guaranteeing settlement of a user’s specified transaction in a timely manner. I am not going to pretend to have some unique insight surrounding the security of TEE’s or any software limitations, minus the fact that TEE’s do have additional latency added; which makes some applications not feasible. Additionally there is the trust assumption associated with a single box running the entirety of an application’s off-chain logic, which runs into issues like hosting safety, risks associated with outages, and more.

An AVS system is another non-blockchain decentralized approach I am a fan of. I think the primary benefit of an AVS is that there is punishment associated with failures to sequence transactions, wherein competitive based sequencing takes the approach of making operators compete on fee kickbacks, speed, or bonus features. An AVS allows for slashing and other punishment mechanisms for dishonest validators which I believe in conjunction with competitive based sequencing could allow for the best of both worlds.

It is my belief that chain abstraction, bridging, decentralization of applications, and most importantly stopping every fucking app developer from launching an app chain; is of the utmost importance and can only be achieved universally through building decentralized networks that prioritize propagation over consensus.

So let’s build some cool shit without being slow.

The only way to be based is to be sequenced… wait I think I got that backwards…

I touched in last mirror on a concept known as “Competitive Based Sequencing.” Let’s expand on that here and talk more about how we can leverage blockchains as dedicated data availability and transaction sequencers. This is all in a series on Aori, Based Sequencing, and how we can build apps in the future that without using auctions minimize MEV leakage and dead weight loss.

When a base layer of decentralization like Ethereum exists, we can imagine networks of non-blockchain layers; for example, Actively Validated Services (AVS). However, AVS systems are much more appropriate when security of another network is the goal. Something important to consider is what specifically is the application’s goal for it’s transaction sequencing. In the case of Aori, speed of execution is our number one priority in order to minimize state drift.

In this code example from AoriV2.sol, you can see that in the order details and user signature, we’re storing and validating that the order hash has not been previously settled. This ensures two things:

1. The order cannot be double settled

2. If there is a network of orderbook operators competing to settle this transaction to capture the fee of the transaction, then it is in the best interest of the orderbook operator to be FAST.

If for example, the goal of an application was not speed, and instead compliance; they could instead require that the transaction sequencer was a particular public key of a known node operator (this would be most applicable for institutional applications). Another alternative of this would be an application that requires a certain level of decentralization, so it could add directly in that a transaction must have a minimum of three signatures provided by alternative operators (aka a Multi-Sig wallet). This ensures propagation and consensus but is entirely “Based” in that the organization of these signatures is entirely off-chain.

In the above diagram, the queen is both defending the rook, and the knight (highlighted with red arrows). The mistake the white player made was rook to e3 (purple), as that overloads his queen. Now, black can play the brilliancy Queen c2, which allows white to take the queen on c2, followed by white queen taking the black queen on c2, then the fork knight to e3, putting the king in check and winning back the queen on c2. Black wins a rook in this exchange.

This is known as “Overloading” a piece. The queen is trying to do two things at once, and thus cannot do either. Decentralized applications have done the same thing. They have tried over and over to include two components into their smart contracts, which thusly negates both:

1. Logic

2. Storage

Let’s look at an example with relation to AMM’s. Historically when a new asset class is created, sophisticated market makers and liquidity providers of all kinds take sometimes years to inoculate themselves and scale into said emerging markets. The AMM allows for a market to instantly have both a market maker, and guaranteed liquidity at the time of execution. It truly appears to be the solution to the problem of finding and sourcing liquidity all in one innovation!

However, this is not so. When we analyze the historical performance of AMM’s we see clearly that the announcing of the market making strategy (constant function, range bound liquidity, etc. etc), gives all other actors an informational edge to exploit. We then clearly see that the way market makers and LP’s in traditional finance make money is some asymptotic information or strategy, and that if they were to announce their strategy, the same thing that happens to AMM’s would happen to them.

This is a case of overloading, simply because:

1. The AMM appears to solve the problem both of finding a market maker, and being easy to deploy

2. External actors then can attack the pool through various strategies such as sandwiching, LVR, and others.

I think this means that the only solution is to have smart contracts with strict guard railing aimed at ensuring that node operators are not able to manipulate user intents/signatures without instant reversion. You can see how we’ve approached that here:

Every single line of code in this screenshot is decoding the user’s signature that they provided to the node operator, and validating the following:

• The order hasn’t expired

• The maker or taker nonce isn’t stale

• The chain Id the user’s signed for is correct

• The smart contract the user signed for settlement to is this exact contract

• The signature actually came from the correct maker and taker address, and is not fraudulent

• And lastly that the tokens that both users signed to swap are matching

When smart contract development becomes creating giant walls of requirements, rather than hiring auditors for +$250,000 to review every single piece of logic, the risk declines by orders of magnitude. Almost all of the largest non-exchange hacks were this form of exploitation, and a removal of logic from smart contracts appears to be the only way to appropriately onboard the next billion users.

This also begs the question how do we guarantee censorship resistance if the applications are off-chain servers? Let’s address first the simple fact that signatures without access to the user’s private keys are impossible to forge. So the only risk with the above contract is censorship (outside of having enough signature validation rails as mentioned in the previous section). That is where several approaches can work, by my estimation.

1. Competitive Based Sequencing

2. TEE’s

3. AVS

Let’s take each one at a time.

This is the approach I’m most sympathetic to, and thus am listing first. Competitive based sequencing makes the assumption that a sufficient enough set of node operators competing on settlement of every transaction. This works similar to the current setup I detailed in the above section “Logic Not Required,” but allows for a user to send an order to multiple orderbooks, and settlement to be a race between all orderbook operators. Any app could integrate this system in, and allow specific node operators to earn fees depending on that app’s setup. Every orderflow provider can send to their own node to capture the fees, or pay other node providers for the service of speed, kickbacks, or hosting costs.

Trusted Execution Environments are another new approach to this problem of how can you guarantee or get as close to guaranteeing settlement of a user’s specified transaction in a timely manner. I am not going to pretend to have some unique insight surrounding the security of TEE’s or any software limitations, minus the fact that TEE’s do have additional latency added; which makes some applications not feasible. Additionally there is the trust assumption associated with a single box running the entirety of an application’s off-chain logic, which runs into issues like hosting safety, risks associated with outages, and more.

An AVS system is another non-blockchain decentralized approach I am a fan of. I think the primary benefit of an AVS is that there is punishment associated with failures to sequence transactions, wherein competitive based sequencing takes the approach of making operators compete on fee kickbacks, speed, or bonus features. An AVS allows for slashing and other punishment mechanisms for dishonest validators which I believe in conjunction with competitive based sequencing could allow for the best of both worlds.

It is my belief that chain abstraction, bridging, decentralization of applications, and most importantly stopping every fucking app developer from launching an app chain; is of the utmost importance and can only be achieved universally through building decentralized networks that prioritize propagation over consensus.

So let’s build some cool shit without being slow.