Author
Abstract
Blockchain applications may have preferences over the order in which transactions execute: an automated market maker may use an external feed to price its liquidity, and require that the oracle update incorporating this price execute before any swap; an exchange may want to execute cancellations of limit orders before incoming market orders; an application may run an on-chain auction by executing bids from highest to lowest, so that the first bid wins. However, the ordering of transactions is chosen by the underlying blockchain and may not be compatible with the requirements of a specific application. In this paper, I tackle this problem by introducing an algorithm called unanimity override. The intuition is that when all the applications agree on how to order two transactions, the underlying blockchain should respect this agreement; a default order - the order in which transactions appear in the block - settles the rest. The problem with this naive approach is that application unanimity may form cycles, which the algorithm must break. Cycle-breaking is also the rule's main vulnerability because an attacker can insert transactions to manufacture a cycle. Yet two guarantees hold against any attacker who sets the default order, deploys applications, and inserts transactions. All transactions that interact with a single application that expressed preferences are ordered according to that application's preferences, even when they also interact with other applications that did not express preferences. Also, gated transactions - those that cannot be outranked in the unanimity order by any transaction crafted by an attacker - always execute as the applications unanimously prefer, even when they touch many applications. The two guarantees identify the preferences the protocol can protect, and they tell applications and senders in advance which transactions will execute in the intended order.
Suggested Citation
Download full text from publisher
Corrections
All material on this site has been provided by the respective publishers and authors. You can help correct errors and omissions. When requesting a correction, please mention this item's handle: RePEc:arx:papers:2607.06144. See general information about how to correct material in RePEc.
If you have authored this item and are not yet registered with RePEc, we encourage you to do it here. This allows to link your profile to this item. It also allows you to accept potential citations to this item that we are uncertain about.
We have no bibliographic references for this item. You can help adding them by using this form .
If you know of missing items citing this one, you can help us creating those links by adding the relevant references in the same way as above, for each refering item. If you are a registered author of this item, you may also want to check the "citations" tab in your RePEc Author Service profile, as there may be some citations waiting for confirmation.
For technical questions regarding this item, or to correct its authors, title, abstract, bibliographic or download information, contact: arXiv administrators (email available below). General contact details of provider: https://arxiv.org/ .
Please note that corrections may take a couple of weeks to filter through
the various RePEc services.