Fair Sequencing Services - Ari Juels

okay i'm going to talk today about fair sequencing services a system we're building a chain link turning into a product i should emphasize that i'm speaking in my industry role in other words as chief scientist of chain link labs rather than my academic role but you've already heard about the work that's gone in my academic going on in my academic group from phil and him now we've talked about flash boys 2.0 and iquitos and so on and so forth and i'll allude to that work but that's not the focus of this presentation my own view of mev is that there are many different forms of mev some very roughly speaking are good and some very roughly speaking are bad for example there are certain forms of arbitrage that one can argue on wall street or in blockchain systems are beneficial in a sense they're beneficial in that they communicate valuable price information across markets for instance and therefore make those markets more efficient i would contrast this with many forms of front running front running in general communicates essentially only the fact that users can be shafted in systems as they're designed today i would allege now this distinction between good and bad is an open research problem as is the formulation of good metrics to measure whether or not a form of mev is good or bad and even the extent of mev and there are different metrics used in different places in the economics literature for instance there's study of the impact of various forms of arbitrage like latency arbitrage on the cost of trading to investors and i think this is a good metric others today have spoken about or will talk about other metrics mahimna talked about the metric underlying iquitas and pimaguin has an interesting take on metrics for measuring whether or not we have a fair system as well but to be fair this is an open problem i would say that however we define bad mev we probably can't eliminate it in its entirety so what we can only hope to do is to build tools that help enact fairer policies for users and by fair i mean fair in the sense for instance that the hymnal discussed or fair in terms of the fees incurred by users when they trade and this is the goal of fare sequencing services the current model of transaction ordering we've reviewed over the course of the day very simply transactions enter the mempool in an l1 system in some order and a minor or a validator picks them up and decides unilaterally how they're going to be sequenced in the block that the miner mines now the miner may decide this on the basis of gas price it may decide it on the basis of an mev auction but the point is that this decision is being made exclusively by the miner that mines the winning authoritative block and this is clearly a form of centralization and its harms have been well documented in an older setting where mev was mostly extracted directly by bots in the flash boys 2.0 paper new models of course are emerging and an important impending model is one in which transactions go not to the mempool but instead to an l2 system like a rollup and the important thing to observe here is that the l2 system now is ordering tr transactions unilaterally now i won't say that this is a destructive or harmful form of centralization it could be it depends on how these systems are designed and for instance arbitram is looking to sequence transactions in a fair way that comports with the notions of fairness that i mentioned earlier so it's not inevitable that we see the same degree of centralization that exists in today's world with miners the idea in fair sequencing services very simply is to decentralize the process of ordering transactions to leave it not in the hands of a single entity but instead to invest a committee with the power to order transactions a decentralized committee and so the committee collectively decides how transactions are ordered on chain and this decision takes place off-chain users can send their transactions through the mempool and nodes in the committee can just observe the mempool that's one possible design option a better more practical one has users sending their transactions direct directly to committee members and then they decide in the aggregate how those transactions get ordered now natural question to ask of course the first question one would ask is where are these committee members going to come from how are we going to compose this committee what we've observed at chain link is that existing decentralized oracle networks are already good ready-made committees with many of the trust properties that users are looking for to begin with these networks are already serving price feeds for instance across a range of defy products and staking and various exogenous cryptoeconomic guarantees of type that for instance mentioned before can help provide the assurances that users are looking for in this setting another interesting observation is that ordering transactions is actually a very natural operation for an oracle network what do oracle networks do today they observe off-chain behavior and they collectively decide on some value to convey on chain so for instance a collection of nodes may observe the price of some token they may observe it from multiple sources they get together and they reach consensus on authoritative price and then they relay it on chain what's happening in fair sequencing services well oracle nodes are observing an off-chain activity namely the transmission of transactions they're observing in particular the order in which transactions come in they're taking this data they're collectively agreeing on an authoritative ordering an authoritative observation of the events that they've seen in the real world and conveying that on chain so is this a very natural extension of what oracle networks are already doing today in the first phase of our design of fss we're going to use a notion of fairness called secure causal ordering or secure causal atomic broadcast to be a little bit more precise this is the idea of encryption essentially but the intuition here is that no node sees a transaction payload before the transaction is ordered or to put it another way transactions get ordered or sequenced before anyone observes the transaction payloads this idea is actually about three decades old devised by mike writer i think in his thesis phd thesis at cornell and adapted to the public key setting by christian kashan and others including klaus will be speaking shortly the way this is implemented is relatively simple conceptually straightforward transactions are transmitted to the committee in encrypted form encrypted under public key belonging to the committee with a corresponding private key that is shared in a threshold way among committee members the committee orders these encrypted transactions and after they've been ordered authoritatively then decrypts them that's the that's the idea that's the way this notion is implemented this works very well because it's hard to front run something that you can't see but it does have some limitations and i point to two limitations in particular one is that metadata are still visible in this setting you know for instance from what account a transaction originated and that can in some circumstances leak significant information about the content of the transaction even if it's encrypted the other problem is what i would call blind front running best defined perhaps by example suppose there's an ico and one of the nodes in the committee wants its transaction sequenced in this ico first right she wants to buy all the tokens secure causal ordering is not going to prevent this from happening at least not definitionally but there's an interesting observation we can make here which is that secure causal ordering doesn't actually specify the ordering of transactions right it says that once transactions are ordered then they can be decrypted but it doesn't say doesn't specify exactly how transactions have to be ordered transactions can be ordered as they were received as i show here or they could be ordered in some other way and that would be consistent with the definition here this observation leads to the refinement we're planning for the second phase of development which is the addition of iqatas these are the protocols alluded to in the previous talk this family of protocols uh developed by uh mahindra kelkar and and some others in my group um was proposed first in 2020 in a paper that's theoretical in nature uses consensus protocols in a black box way and therefore isn't terribly efficient but a more efficient version should come out in a month or so uh maybe a little bit more than a month so these protocols can be practical the intuition here is that transactions essentially are ordered according to the time that they're received by a super majority of nodes and how the super majority how large the super majority has to be is a parameterizable feature of the protocol family things are a little bit more complicated than this but this is this is the basic intuition how do we compose these two well this is fairly straightforward when transactions are sent to the committee in encrypted form the committee orders them exactly as i showed before but now it uses iquitas in particular to order the transactions once the transactions have been ordered then they can be decrypted and in this way you get causal ordering in addition to the features of iquitas now iqatas in and of itself actually prevents the attacks that i described frequently previously at least mitigates them it prevents things like metadata based attacks because it's ordering transactions according to the time that they were received so it's potentially stronger than secure causal ordering in the right setting it will be but it's somewhat sensitive to network adversaries and if an adversary for instance in the limit controls the internet the adversary can decide how transactions are ordered and there's not much you can do about that iquitas isn't going to help right um secure all causal ordering will actually help in that setting ico toss is also a little bit more complicated to implement than secure causal ordering but the two nicely complement one another but they act as hedges for the other protocol and this is the reason why we're interested in composing them fss can be used in any of a variety of settings it can work for instance as a pre-processing stage for l1 functionalities specific smart contracts can be fss enabled and this doesn't require terribly much of a developer it's not much more than would be required for instance to integrate roll-ups into a contract but of course as we know we're living in a world in which ordering is increasingly taking place off-chain for instance at layer layer two in in roll-ups flashbots and so on and so forth it's worth pointing out that fss can work equally well in those settings if we're talking about a roll-up for instance you can use fss to sequence transactions that then go into the rollup and the composition again is fairly natural and this may well be the first place in which we see fss used that's it for my talk if you're interested in learning more i would direct you to the academic paper on iquitas and those on secure causal ordering classic papers now if you're interested in fss in particular you can read a bit about it in the chain link 2.0 white paper at the url given here thank you