DAPPCON 2024: The State Problem: One Account Multiple Chains - Jérôme de Tychey

DappCon 2024 · May 2024 · 25:15

Jérôme de Tychey speaks at DappCon 2024 under the title The State Problem: One Account Multiple Chains. That framing points to the challenge of a single account existing coherently across multiple blockchains, each with its own separate transaction history. The talk stays anchored to that title's framing rather than detailing a specific solution.

Speakers

Topics

From DappCon 2024, hosted by Dappcon Berlin.

Transcript

hello everyone um super happy to be here last time I was here is was to talk about a castle in the town of e uh and now we talking about the state problem so where have we been where have we been uh so I'm the founder and CEO of KF you maybe heard of us uh I'm also teaching there and I'm indeed the president of friend I hope to see you all at itcc in July it's going to be A bash uh yeah hopefully see you what see so before we start to Deep dive I want to give you the angle that we have when me talk about this problem at KF we are a gaming company like we do we do games uh we've been doing onchain games we've been doing less onchain games and recently we started a game on epic game store

distributed there uh and we do also the text tack for those game to work so we distribute uh middle Wares for retail application and notably we work with nosis on on Metric um so while we were trying to onboard people into games when we were trying to onboard non web tree minded people into uh retail blockchain application we were faced with a huge customer acquisition problem uh because you need to install a wallet because you need backup because you need to buy crypto because you need to crypto to use on the chain and so on um and for us it was just a nightmare the conversion funnel was just so so so so bad uh it was in the year of 20121 and 2022 so we didn't have as many fancy techniques as we do right now to on board and for our

latest this game we move to full account abstraction that we distribute in package on top of safe and also uh on our own layer Tree on top of arbitrum so we have the capacity to properly sponsor transaction for the user now here's what we think is going to be the low hanging fruit in term of user acquisition uh here's Bob so Bob has if on uh a centralized exchange uh so he's already crypto interested Crypt minded it's easier to convert those people than it it is to convert someone that has heard about Bitcoin but F it's for uh uh terrorism and uh and money laundering and it's also easier to convert those people than just say like hey it's cool it's on the blockchain you should check it out so typically when you have um a full I abstraction application uh the

user don't really see their account at first they just get unboarded that they would on any web2 application and when they start to dig in they realize that they have a wallet and they maybe willing to withdraw some money on this account and start to use this account elsewhere or in another way so we have many bubs already in the in our games like people that have on boarded on our game that have tried to do transaction that were sponsored didn't really realize what was happening started to put their own wallet to grow the number of owners of the save for example and at some point many of them decide to withdraw from their software exchange to uh their safe that we deployed for them and thus they Rush on the Discord asking like where's my money I don't know where is my my my balance with of data and so

on and then we get into from what we perceive is a pretty big state state problem like the state of the different EVMS that we have deployed and not properly shared together and as of today we are entering a change of Paradigm I mean you've seen this in this conference umire metry mum clave nois pay and so on we start to have a lot of very good way to onboard people so we are likely going to get a lot of bubs and this problem is going to get bigger and bigger thankfully uh the best Minds in our ecosystem are thinking hard on this problem and so like vital and other people are posting a lot of research stuff about this problem like making sure that we have a eventually a minimum key store rollup where we store

everything that's happening in the account and we replicate uh the state of the account this way between different chains um trying to suggest thing that we should do in order to improve the situation because the the problem is about to grow a lot coming back from when we started ethereum uh when we were using ethereum and installing a node the first thing you were supposed to do do is go on the eum browser called Mist once you were running a eum node you had Mist install on your machine and Mist was connected to your node and you were browsing the web the web 3.0 through mist and every time you had a request for something blockchain related then M will just talk to your node and you will access the the

blockchain data this way uh unfortunately it was a bit too hard to push people to all install a node in order to access the blockchain we started to have wallets like metamask like others that were exposing remote procedure call RPC towards nodes like infer and so on and then we start to lose a bit this um this strong connection to the chain like putting everything that's available on chain directly on the computer of the user well then we started to switch about how we are going to scale the network and the first attempt of scaling ethereum was to use the Bon chain as a coordination layer as a coordination layer between different shards where things we going to be executed and everything would be reconciled towards

the beacon chain so Beacon chain as a cons as a coordination layer uh as the tough problem of how do we make sure that there is cross Shard communication and in the Years 2018 2019 uh early 2020 a little bit uh everybody was thinking about that like how do we how do we do good cross chain communication problem uh the main problem was shaped as the hotel train problem like if there is a hotel on this sh and a train on that CH how do I make sure I do one single reservation to one single booking to uh to access my training tickets so all the techniques that we started to shape at this uh at this stage were asynchronous or synchronous and they translated themselves into different attempts at

doing good Bridges between chains um the number of U of of bridges hack at the cost of using Bridges and um and the maturity of those bridges highlights how much we need to work a little bit more on those on those problems um and today we have this rollup scaling strategy which has been very successful into giving us a lot of evm block space to fill um so we switch to having ethereum as a a beacon chain connecting all the charts and making sure that the communication is good between those charts into several layers of layer one uh several stages of layer one so you have the execution layer like where we actually run on the transaction

the main net the evm on the main net and we have at the consensus layer a way to get the consensus on proof of stake of what is the stage of the layer one but also to gather some data like the blobs from uh the EIP 4844 the the data can be a bit misleading because this data is not supposed to be permanent it's supposed to be there for a while just to guarantee some some security aspect and then all the rollups all the l2s and l3s and so on uh can communicate with the layer one and benefit from uh the blobs and the the consensus layer and the execution layer to continue acting and providing security to the to the user but it feels like we kind of forget that we need good cross layer communication so a big lingering

question for me is are we going to get enough block space to dilute this problem into more gas more gas pending and as of today we have a few researchers notably anit and Stefan from Frontier research that are trying to shape this problem in the rollup context in the multiple evm context without any good coordination layer so they came out with the cake framework for chain abstraction key elements that uh highlight the different component that you do that you do need to realize a good cross chain attraction a good chain abstraction to have good abstraction of the chain you are in for user when you when as a user you browse a websit you're not asking yourself is this website on AWS are they using gcp I'm not sure I need I need money on gcp to

use it yes indeed and the end game would be of course that my wallet j. if um is showing me the balance that I have on all the networks together all at once like eventually with a weighted fashion say like oh yeah but you need to pay X to get out of this and get there but this is what you have in your wallet in the first place so in order to get there I try to look at those different components of course you don't need all the components to realize a good Solutions there's mixes that you can be uh can be done um but looking at the different companies that we're building on those different components and try to say like well they only have a landing page no code is public the documentation is out there oh

yeah they're live on this network on that Network I try to goge how much we were mature on the topic uh so that's my personal view on on this maybe maybe I missed a lot of uh of people that were're trying to build in this space but we still have a lot of work to do to make it workable from my from my perspective and also if you want to do cross uh well chain abstraction as a whole you need to be support ing a lot of chains so it means that your infrastructure need to be super scalable as well so yeah adding adding problems on the problems um couple of highlights though uh at this conference there were um a talk about Ashi which is the cross chain Alliance that's going to look at this problem and try to bring solution or bring together different initiatives

towards this solution and also the work that we did uh in R&D at KF called story loose which is storage proofs like proving that something is included in an evm and try to figure out how we index that and distribute that at large space uh we will do some updates on that at ECC very likely uh and if you want to check it out the the code is also there and as a conclusion um we still have 10 minutes that's great uh I wanted to uh give an opportunity for Stefan to get a deeper dive on one balance which is an initiative that builds on top of the cake framework to realize what we think is going to be the next thing in terms of ACC abstraction and chain

abstraction so please Stefan amazing thank you so much Jerome and so kind of you to give up some of your time I know you have to run to the airport soon and so I really appreciate it big big shout out to him I mean what a legend in the space and uh so yeah feeling blessed for for the opportunity okay um let's talk a little bit about one balance um you know leveraging a bit of what what he's talking about with the cake framework first we can talk about um about why we care about chain abstraction at all um and so I think everyone realizes that the best time they've had on E theorum so far was a

few years ago um when it was easy to farm vegetable coins and it was like oneclick experiences um but it also was really expensive to do so and so we spent the better part of last four years trying to figure out how do we actually make it so it doesn't cost a million dollars just to do a transaction um and we've you know managed to achieve it but now we're in this world where we have fragmentation across the entire ecosystem and uh I've found it extremely difficult to use the chain and I'm sure I'm not the only one um and so unless you're really motivated and in many cases financially motivated to do so it makes very little sense for users to go figure out this this mess and so how do

we actually get to the dream world that we want to be in where we actually have both the usability and the scalability um that's sort of the problem that that chain abstraction is is trying to solve for um and so we proposed this framework called the cake framework and the entire thesis behind this is if we solve the cake framework we get to the world that we want to be in um the other part of it is we believe each one of these component there's already we stand on the shoulders of giants and there's a ton of money that's been spent trying to solve of these issues the main issue is that these people aren't really talking to each other and they're in integrating sort of common interface to be able to achieve the the ux Improvement and so that's what the fragmentation comes from

it's not just about like technical fragmentation it's like social uh language of the developer Community not talking to each other with fragmentation so that's what what we're looking to solve with the with this working group so we just have a bunch of different folks here and um these are all sort of middleware sort of layer uh folks um and then we're launching uh a new work stream for for wallets and apps and so anyone that's working more towards the ux uh of solving these problems we we have a new group for this um so that's my cake plug um and then I would love to talk a little bit about one balance and uh and what I call the fat account thesis so I think we've been in this

sort of view of the world since 2016 more or less that focuses on the idea that the chains and the l1s is where the majority of the value acrs and if you look at sort of the top 100 coins on coin gecko um the majority of them are sort of L1 protocols right um but there isn't really anything that sort of backs this this U this meme um and as far as I can tell this is sort of the the source of it so the idea for fat protocols is saying oh actually all the network effects acre to the base layer where the uh the smart contracts are actually operating um my claim is that this is actually an outdated view of the world and this is based off of a perceived

scarcity of block space which we no longer have and in a in a post abundance of block space world what we actually go towards is um what I call the fat account thesis so the chain Centric view says okay we have credible commitment machines and Global consensus that are bundled together and because you're bundling Global consensus it's really slow and expensive to do and so therefore it's going to accumulate all of value and it's going to have Network effects um what I'm proposing is now whe we're going to post blog space carcity World actually what we're bundling together is the accounts and the credible commitment machine and we're taking out the global consensus and this completely shifts the ecosystem from focusing on chains to focusing on

accounts um and my claim is this transition is both inevitable and necessary if we want to solve all the ux problems that U the fragmented space has today so um what what is our contribution to this our contribution is looking at the equivocation and Global consensus dilemma um so equivocation comes from sort of the way that uh eoa accounts are designed today so EA accounts are public private key Pairs and they sit outside of the chain and so the chain has no view over what the account has or hasn't signed um as far as the chain knows any request that is a valid signature over a given nons needs to be processed in in uh compliance with the consensus of

the protocol and so at any time a user is able to equivocate their request by simply overriding their nons um and so this nons overriding is possible because the chain doesn't have this view the problem is if you're relying on an architecture like in the cake framework where a counterparty brings the transaction to the chain on behalf of a user if the user able to equivocate they can essentially grief the the solver and this uh issue becomes uh even bigger in a cross-chain setting where you have asynchrony because if the user issues a request over here on chain a and then the solver does something over here on chain B they can't rely on the atomicity of execution between these two things to provide safety over their

request and so they can't revert if the user double spends on on chain a um the class of solution for this is sort of widely known as htlcs um and uh it sort of says okay well we actually need to lock the user State on the origin chain for a period of time to allow time for asynchronous execution to happen on the other network so um this is where we go into sort of the next Evolution after EAS which is the concept of of smart contract accounts and so one solution to this equivocation problem is to say let's just put the account on chain now the chain has a view over everything that the account signs and so the chain is able to say oh this account has locked this state for this period of

time it's credible because that's state is locked on chain and it's within the rules of the of the global consensus the problem with this is global consensus is really expensive um and so we enter into this this thing called the account dilemma where on one side you have eoas which are fast and cheap and you can issue a bunch of different signatures basically at the speed of of signing but you allow the user to equivocate at any time and then on the other side you have Smart contract accounts which can't equivocate because they're part of a credible commitment machine but they're really slow and expensive because of global consensus and so the dream world that we need to be able to achieve chain

abstraction is top right corner 22 um and I'm going to present sort of what I think we need to to get there so that's what one balance is trying to resolve is this is this dilemma the way that we do so is by introducing the concept of a credible account so credible account is sort of a successor to Smart contract account and it says instead of Hosting um accounts directly on a chain with global consensus accounts can be hosted on any credible commitment machine that's mutually agreeable between the user and the solver um that's a key point we'll get more into that and then the other piece I introduces is the idea of a resource lock so a resource lock is like a really scaled down version of

call data that actually doesn't specify anything about the execution trace or the execution semantic on the destination chain it only specifies the inputs and the outputs of a specific State transition and it lets to Sol or figure out the rest um so these locks are these like credible commitments so they're escros that are issued within the account that solvers can rely on for the period of time that this um this escrow is is is in practice so this is an htlc at the account level um and then credible accounts so credible accounts are again just accounts that are hosted on on a credible commitment machine which allow for the fast and and and cheap fulfillment one way to think about this is take smart contract wallets and

put them such that each smart contract wallet is its own rollup that's able to deposit state from an arbitrary number of chains and it's able to process you know transactions really really quickly because it has its own sequencer and it doesn't have any dependencies on anything outside but it's able to trigger State transition functions on any other domain that's essentially the world that uh that I'm proposing we we had towards um there's many different ways to get there so we explored in our post um four different architectures that uh that we believe sort of achieve this this outcome I call them like the four architectures for for credible accounts one of them is using uh trusted execution environments like sgx another

one is by um by using an MPC and doing threshold signatures over sort of a consensus of nodes another one is putting this sort of smart contract accounts on on a on a rollup approach and finally some of the you know more recent discussion is around the use of um of VM modifications directly like 7702 so all of these try to achieve sort of the same thing and they all come with different trade-offs I expect that the optimal implementation of this is going to evolve over the course of the next few years as the the trans as we make the transition towards this this account Centric worldview I posit that this new worldview is necessary and inevitable um and what we're building is a framework

for being able to manage these types of accounts on a bunch of different architectures and so we consider every part of the cake stack U sort of a module or a plug-in that fits into these uh these new types of of credible accounts um so yeah there's a link here if you want to learn more about it and again thank you so much jome for the for the stage space appreciate it [Applause] you want to take questions oh yeah okay all right um does anyone have any questions

yes hi thanks for this presentation but I'm wondering how to create a smooth transition to new proposed accounts because currently we have a huge problem with Legacy for example we have a ec20 standard then maker token doesn't support name a symbol in uh string value returns by 32 and all time when you Innovations come we create like evm versioning when one evm version doesn't support POS zero op code or t up code and so on and when the new accounts could come how the current code base for example Unis swap or a or any other big

protocols could support these new accounts to make it simless transaction to users without do not rebuilding the whole code base of really well battle pested protocols yeah I I have an answer but I mean you've seen this firsthand with the transition to Smart contract yeah there there's many discussion happening right now on how we make people transition from EA to Smart accounts uh it's it's completely oped in you don't you're not technically supposed to be forced to be trans transitioning to any smart accounts uh but there is a lot of very good arguments that this should be the case and this should be at some point the default as well notably with rolling out different keys and being able to change

your keys and so on uh there was an initiative that got replaced recently by another one the EIP 3074 That was supposed to be included in the next work that would be replaced with another uip that's more aiming towards smart account as a transition so the at the at the evm core level uh we are introducing ways for people to migrate easily from their EAS to Smart accounts and what you will be doing is like oh I'm I'm taking my metamask and I'm now declaring that this metamask is now invoked by this new smart account the good thing uh for existing smart account smart contracts like Unis Swap and blah blah blah is that from a smart contract perspective talking to a Smart account that has been transitioned from a eoa will be the same

the transaction or will be the same you'll be invoking from uh this account and so there's no change to be done while we do this transition and this transition is already happening and already like in Target yeah so I think it touches really well on on the smart contract account sort of transition my my claim is maybe a little bit more meta which is I see current EAS as an inadequate equilibrium if you're familiar with that concept and like a lot of standards are poorly designed are they're kind of these things that everyone uses because everyone else uses but they would rather be using something else and there's like clearly something else that's better and so I see my job in the ethereum ecosystem or the crypto ecosystem as a

whole to like help the community switch from one inadequate equilibria to like a a better one and that's a coordination problem like any standard is a coordination problem any blockchain technology is a coordination problem and so when you ask this question what I hear is how do we solve the coordination problem getting people to switch over from a inadequate KU to a to to to a proper one um it takes a lot of like presenting things getting people excited about it uh and all this stuff but fundamentally people only shift when they have an incentive to do so and so I believe that this is inevitable because the capabilities that it delivers for end users is so much better that the applications that integrate this first are going to have a huge advantage over

current applications like this is over a 10x improvement over the current state of things with EAS and so so it's inevitable that people will innovate and start to adopt this and then eventually the the bigger folks that are slower to move are also going to change practically what needs to happen is we need to switch away from this Json RPC API that was designed in like 2014 to manage eoas on ethereum nodes towards an RPC API that's actually designed for wallets and there's a bunch of different proposals and so we're working with folks like wallet connect to get uh these new methods that are much more modern deployed Within all of these uh these different uh wallets and apps yeah smart account at scale are cheaper for the network yes

yes anything else I think we're out of time okay anyway thank you for the question Let's uh let's chat if you want to Deep dive more just