Achieving Chain Abstraction through Transaction Orchestration by Mislav Javor | Devcon SEA

[Music] [Music] good morning everyone uh glad to be here uh as you see I renamed my trans uh my presentation but it's the same thing I promise uh so we basically just rebranded some things uh I applied here as um co-founder at cluster but now I work as VP product at bomy so uh without further Ado we only have 5 minutes so let's get started um so one of the things that we basically deal with today is let's call it monolithic execution um so let's call it like this you have your normal blockchain transaction you encode a 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 minor or a validator or a sequencer they include it into the BL Blain and that's it that's monolithic and some of the 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 uh signature scheme coupled uh you know your ethereum node really does only use one signature scheme for everything uh they're non-c 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 uh and 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 uh transaction then a bundler solves for the next fraction of your transaction Etc um so yeah this are the problems with monolithic execution and that's where we go into this modular execution what we use to call transaction orchestration uh modular execution environment uh in essence is um 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 uh user Ops intents offchain actions ZK proofs it's modular it's extensible and it's also recursive so what does this enable so this enables essentially um a node to commit to multiple actions to the user and the user permissions these multiple actions with a single signature uh it requires uh smart contract accounts it relies on ERC 7579 validator module it encodes all of this into a Merkel tree then you sign the Merkel tree root hash and after you've signed the Merkel tree root hash this essentially gives permission to all to all of the leaves to get uh executed um what's the cool thing about modular execution environments well like one of the coolest things is that they are uh modular obviously but they are also recursive uh what does this mean so let's say I'm a node um which has committed to execute something for you um and I don't know how to execute the entire thing that you have given me maybe it has like a intent to move funds from optimism to base and then it has a requirement for two two or three user Ops uh to execute certain you know let's call it like this uh intent uh user op first remove my Supply from a on optimism then an intent uh move this usdc from optimism to base and then a user op Supply to a on base which is basically let's call it a rebalancing an AA position in a single single transaction super transaction um and this is kind of let's say this can be done by a single node but for for just for um 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 front liquidity what can happen essentially is that one of the leaves of this Merkel tree can be the root of another Merkel 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 uh we are trying to essentially push this to become the one of the main if not the main um data model for transactions within a chain abstracted world because it Bridges gaps between uh so like the leaf can be a Solana transaction it can be an ethereum transaction it can be a vasm transaction uh payment can be like an onchain payment it can be an offchain payment um offchain actions for example you can trigger a call to some API then require this to generate a ZK TLS proof that something has been executed so it's very extensible very modular it uh really effortlessly achieves all the elements of chain abstraction like uh gas abstraction single signature multi-chain stuff um and yeah also what we are building is a modular execution environment U which is a permissionless execution layer for all of this but you know I wanted to keep this Technical and not Shilling our own things so um yeah um this is it for super transactions and modular execution environments thank you m 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 GNA throw you the box get ready to catch it yeah and go okay uh how do you ensure like transaction atomicity in a multichain environment let's say uh you did a transaction on optimism and Main and then something happened to op optimism and someone claimed that the rollup was faulty and the block reverted what happens to the transaction which was settled before so the um 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 uh certain block Builders who can like build blocks on top of multiple blockchains at the same time so you can get like a pre-confirmation whether or not it's going to get executed everywhere or nowhere um a lot of things don't really require this type of hard atomicity like for example this case that I said with AA like 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 that are needed uh in our experience like n 99% of everything goes through uh but yeah for certain cases let's call it maybe trading or or defi positions where like 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 like block building on top of multiple rollups at the same time and then yeah you basically get a pre-commitment to to inclusion of all of the transactions within the super transaction hash right thanks we already have another question lined up uh yeah my question actually was the same uh as about atomicity so in general it's U like convenient way to uh put all transactions together and uh do you have some ways to uh prescribe uh sequence of transactions so let's say uh 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 10 100 usdc until you have a 100 usdc on base like it will not the node itself will not execute that piece of the transaction the secondary part which you can do is you can set conditions with onchain variables so for example let's call it um transaction on optimism triggers a cross chain message onto base which updates an onchain variable which gives permission to the second transaction in a row so um we are actively working with a few cross-chain messaging protocols to enable this functionality uh 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 um you know if else conditionals just call this transaction if output is bigger than this then write to this chain set set this transaction we're also building an SDK called abstract JS that's going to enable all of this uh but so essentially the nodes use reverts for sequencing so until the transaction reverts nothing gets executed and then you can use onchain variables to control the sequence flow but let's call it for this a example and for lot of other examples that we have sequencing happens automatically because like until conditions are met nothing gets