Achieving chain abstracted experiences will require the ability to execute multiple transactions across multiple blockchains as a single "action", ideally with a single signature used for permissioning. 

In this talk I'll explore the concepts of transaction orchestration and single-signature, multi-chain permissioning. I will present what are the benefits, how to create such systems and what are the drawbacks (e.g. soft atomicity, stale permissions, etc...)

Stage 4

Mislav is a software engineer and founder, working in the blockchain space since 2016. Some notable achievements are: Co-authoring one of the first textbooks on Ethereum development (Developers guide to Ethereum), organizing the first blockchain developers meetup in the Balkans region. Business wise, Mislav has worked as an engineer and manager in several blockchain projects spanning topics as diverse as real world asset tokenization on one end and core protocol research on the other.

Mislav Javor

Achieving Chain Abstraction through Transaction Orchestration

 . Good morning everyone. Glad to be here. As you see, I renamed my presentation, but it's the same thing, I promise. So we basically just rebranded some things. I applied here as co-founder at Cluster, but now I work as VP product at Byconomy. So without further ado, we only have five minutes, so let's get started. So one of the things that we basically deal with today is, let's call it, monolithic execution. So let's call it like this. You have your normal blockchain transaction, you encode the transaction, you sign it, and you send it to an RPC node, and the RPC node sends it to a block builder who then, you know, it goes to a miner or a validator or a sequencer, they include it into the blockchain, and that's it. That's monolithic. And some of the features of the monolithic environments are they're unicast, like one RPC node communicates to one blockchain. They're isomorphic in a sense that an EVM node doesn't understand an SVM transaction or like a near transaction or a WASM transaction or whatever. Signature scheme coupled, you know, your Ethereum node really does only use one signature scheme for everything. They're non-composable. So imagine if you are pre-signing two transactions, so one and two, you can't pre-sign that the second transaction takes as its input the output from the first transaction. They're non-collaborative. If you have multiple transactions that you want to execute, first of all, you can't even bundle them in a single object. But even if you could, there is no way for a collaborative execution where, let's say, a solver solves for a fraction of your transaction, then a bundler solves for the next fraction of your transaction, etc. So yeah, these are the problems with monolithic execution. And that's where we go into this modular execution, what we use to call transaction orchestration. Modular execution environment, in essence, is using super transactions. And a super transaction is a single data object which can contain the payment information for how you want to pay for this super transaction, user ops, intents, off-chain actions, ZK proofs. It's modular, it's extensible, and it's also recursive. So what does this enable? So this enables essentially a node to commit to multiple actions to the user, and the user permissions these multiple actions with a single signature. It requires smart contract accounts. It relies on ERC 7579 validator module. It encodes all of this into a Merkle tree. Then you sign the Merkle tree root hash. And after you've signed the Merkle tree root hash, this essentially gives permission to all of the leafs to get executed. What's the cool thing about modular execution environments? Well, like one of the coolest things is that they are modular, obviously, but they are also recursive. What does this mean? So let's say I'm a node which has committed to execute something for you. And I don't know how to execute the entire thing that you have given me. Maybe it has like an intent to move funds from optimism to base. And then it has a requirement for two or three user ops uh to execute a certain you know let's call it like this uh intent uh user op first remove my supply from ave on optimism then an intent uh move this usdc from optimism to base and then a user op supply to aveave on base, which is basically, let's call it a rebalancing and Aave position in a single transaction, super transaction. And this is kind of, let's say this can be done by a single node, but for just for an example, let's say a thought experiment, let's say that the node doesn't know how to trigger an intent. It doesn't know how to trigger an intent. It doesn't know how to front liquidity. What can happen essentially is that one of the leaves of this Merkle tree can be the root of another Merkle tree, and then one node can commit to another. So essentially this is a data structure for a new type of transaction, which is recursive by default, and which has multiple elements of execution by default. recursive by default and which has multiple elements of execution by default. We are trying to essentially push this to become one of the main, if not the main, data model for transactions within a chain abstracted world because it bridges gaps between... So like the leaf can be a Solana transaction, it can be an Ethereum transaction, it can be a Vazen transaction, payment can be like an on-chain payment, it can be an off-chain payment. Off-chain actions, for example, you can trigger a call to some API, then require this to generate a ZKTLS proof that something has been executed. So it's very extensible, very modular. It really effortlessly achieves all the elements of chain abstraction, like gas abstraction, single signature, multi-chain stuff. And yeah, also what we are building is a modular execution environment, which is a permissionless execution layer for all of this. But I wanted to keep this technical and not shielding our own things. So yeah, this is it for super transactions and modular execution environments. Thank you, Mislav. And now we have time for questions. Raise your hand if you have a question. I know you do. Don't be shy. Yes. All right. So I'm going to throw you the box. Get ready to catch it. Yeah. And go. OK. How do you ensure transaction atomicity in environment? Let's say you did a transaction on Optimus and Mainnet, and then something happened to Optimus, and someone claimed that the rollup was faulty and the block reverted, what happens to the transaction which was settled before? So the super transactions and modular execution environments are just technical concepts. They don't really guarantee or not guarantee atomicity. So a example of a modular execution environment can be one which guarantees atomicity. So we are currently working with certain block builders who can build blocks on top of multiple blockchains at the same time. So you can get a pre-confirmation whether or not it's going to get executed everywhere or nowhere. A lot of things don't really require this type of hard atomicity. Like, for example, this case that I said with Aave. The worst case, if a piece of the transaction fails, you'll just retry the transaction on the destination chain. And then, so even like a super transaction can contain also retry instructions. So you can pre-sign all of the retry instructions that are needed. In our experience, like 99% of everything goes through. But yeah, for certain cases, let's call it maybe trading or DeFi positions where maybe you want to do a cross-chain flash loan or something like that, where atomicity is very important. There we are already in active conversations with certain projects which do block building on top of multiple roll-ups at the same time. And then you basically get a pre-commitment to inclusion of all of the transactions within the super transaction hash. Thanks. We already have another question lined up. Yeah, my question actually was the same as about the automaticity. So in general, it's a convenient way to put all transactions together. And do you have some ways to prescribe a sequence of transactions? So let's say this transaction should happen before this one or some mechanisms like this. So in general, they are sequenced by default um so a node will not execute a transaction if it simulates a revert and also there is like this entire trustless protocol with staking and slashing that actually ensures the liveness of all of this but let's call it like if you are bridging to base and like the transaction on base requires 100 USDC, until you have 100 USDC on base, like it will not, like the node itself will not execute that piece of the transaction. The secondary part which you can do is you can set conditions with on-chain variables. So for example, let's call it transaction on optimism triggers a cross-chain message onto base, which updates an on-chain variable, which gives permission to the second transaction in a row. So we are actively working with a few cross-chain messaging protocols to enable this functionality. The entire idea is that you should be able to write, let's call them smart contracts in only front-end code, where it's like you put, you know, if-else conditionals, just call this transaction, if output is bigger than this, then write to this chain, set this transaction. We're also building an SDK called abstract.js that's going to enable all of this. But so essentially, the nodes use reverts for sequencing. So until the transaction reverts, nothing gets executed. And then you can use on-chain variables to control the sequence flow. but let's call it for this Ave example and for a lot of other examples that we have, sequencing happens automatically because like until conditions are met nothing gets executed.

https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/6735719f9dbb7a90e19870fb.vtt