[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