Ethereum Sequencing and Preconfirmations Call #11

Transcript

hi everyone and welcome to the sequencing and pre-confirmation call uh number 11 uh today we have folks from coinbase who will be talking about uh keyspace I think we have a presentation specifically by uh Nan uh but before that um I kind of want to talk about uh ECC um there is um a uh a persistent uh test net that is being uh spun up so this is a a public and persistent test net uh called helar um the idea is to basically continue on the success of of Zubin and go from a Dev net to to a test net is not I think most of the focus is

not on the the heski test net uh by having our own private um testnet will be able to to move a little bit uh faster uh the name Helga comes from from um Dutch it means bright uh because the future is bright because of Base rollups and uh as far as I can tell there is a lot of interest from uh many different teams uh 20 or so teams uh across the the the whole stack so if you are interested in uh participating or getting involved in this uh persistent test net uh do do get in touch um without further Ado uh n and the floor is yours to talk about

keyspace all right thanks Justin thanks everybody for being here I'm calling in from I I don't normally live in California but I'm in California right now and that's very early but uh hopefully that does not affect the quality of the presentation uh so let me start my slides uh uh as I'm going through this this is fairly informal so uh feel free to chime in and if if it gets too much I'll push back on it but let's start by assuming that it's going to be totally fine uh so my name is neon babalola I work on the base team at coinbase uh our goal in general is we want as many people on chain as possible uh so that means as many users that means as many

Builders as possible that means as much value as possible and that means that we have to scale the network so that can all happen cheaply for all these users uh so that's uh what we believe that's what we're working on part of that vision is making sure that people can use Smart wallets across all the chains that they use so for us this isn't just a base thing we expect that for people to have the kind of user experience that we want to have that they're going to need smart wallets to have pay masters to have uh Pass key uh signatures for their accounts all the benefits of that uh but they need that to be a unified experience no matter where they go if they go to another chain and they have a bad experience that means they having a

bad experience on Bas 2 we don't want that uh so the what where key space fits in is that it's uh it's a cross chain key store for these smart wallets uh so uh vitalic has done a lot of writing about this vision of having a single source of Truth for the signing keys of your wallet because once you H once you move away from externally owned accounts to uh smart wallets uh the the the the smart wallet is storing the signing key that controls the wallet in the storage of the account if you're on another chain you don't have that storage everything gets out of sync uh so there's a lot uh in the keyspace docs

there's a lot of writing in the references that I'm linked to so feel free to if you haven't seen all that writing that Vall is done there's a lot of links there uh it's all good stuff so we're trying to implement a version of uh that Vision uh keyspace is implemented at a ZK rollup so uh we settle to ethereum uh the state route stored there and every time we're trying to update the route there's a zero knowledge proof that's being verified to uh update the rout each time uh this is not a zkm it's not a general purpose blockchain at all uh and in that sense it feels weird to even think of it as an independent blockchain when you think of an when I think of an independent

blockchain I think of optimism I think of arbitrum I think of nosis chain I think of these that uh have their own Rich State uh that people are querying that people are sending transactions with Etc uh the in in my head what keyspace is doing feels more like a fancy smart contract it's one application with very limited operations that you can take on it like a smart contract would be but it is its own independent chain we limit the operations that can happen on keyspace because at the end of the day this the chain is uh controlling access to your funds if there's some sort of bug some sort of error because we're trying to

support all the use cases in the world uh that ends up cascading to people's wallets and people have a bad time so instead we want to minimize the attack surface of key space so there's very few operations that can happen uh we want it to be straightforward for people to audit for people to trust and for it to be reliable over time so that's what keyspace is it's a minimal key store rollup it's a ZK rollup few defined operations and that's what's going on here so in the context of this call I I haven't actually been to any of these presentations but my understanding is that it's a lot of rollup Builders thinking heavily about pre-confirmation and things like that so in that context uh uh the The Limited statefulness and

key space kind of informs like what we've been thinking that we need to care about and we're very interested in feedback from you all whove done a lot of thinking about this but uh to think about where keyspace fits in uh in ethereum we have this Rich account based state where the order of all transactions is affecting uh what happens on chain it's Rich statefulness it's why ethereum is this very useful platform for writing these applications if you go a step down you have bitcoin's utxo based state where the order of the transactions that are consuming the same utxos is very important but other than that if I'm using some utxos and you're using some utxos our state is independent so the ordering of those is less important than it would be in

ethereum and then taking a step even lower than that is something like certificate transparency uh if you've heard of it great if you haven't it's not that important but it's basically the state doesn't depend on the ordering at all it's just a log of the certificates that have been issued so the the the ordering isn't super important uh key space is kind of in between Bitcoin and certificate transparency on the Spectrum uh every wallet has its own record and each record has its own independent history so you can manage your keys I can be managing my keys and the fact that uh our transactions might be included in a different order isn't super important and it's for this reason that we haven't been super focused on things like pre-confirmation things like that uh we

we don't think that we need to think about that if you think differently we want to know so we can correct that uh but that's how uh we view statefulness in keyspace uh in terms of how keyspace is sequenced right now the deployed test net version is uh it's uh it's permissionless sequenced by anybody who wants to show up and Advance uh the state of the rollup there's no um that you don't get a slot to prove or anything it's just you show up and you prove this is not not shippable in its current state it's just the way things are right now uh in particular the current model uh introduces a lot

contention if I start proving a block and you start proving a block uh we're going to have a bad time because if when your proof gets on chain all the work that I've done is now invalid and sometimes that work is very computationally heavy uh to to get proving times of currently about five to 10 minutes with our current circuits um the we are running a a relatively beefy machine cost money to do uh and we we don't want that sort of contention to be there in real life so we the end game for sequencing in keyspace we believe is BAS sequencing uh we we want to inherit a lot of the benefits that you get from relying on the L1 sequencers to do the sequencing so uh in terms of liveness

right now if our sequencer stopped uh it's very hard for somebody else to step in if we had a whit list sort of um approach you could benefit from having a couple of other people but we really want any L1 validator to be able to step in we also want to uh benefit from from from the decentralization of the validator set having any uh instead of trying to build our own validator set using ethereums knowing that uh the the allocation of proving the sequencing slots is already well distributed and then we definitely want ethereum alignment because again this we're not trying to create our own ecosystem uh what we want to end up with is something that the entire ethereum ecosystem sees as core infrastructure uh we want many

many users wallets to be integrating with this system does somebody have a question um George maybe I'll just mute you if you don't have a question no worries uh so so the model of uh base sequencing that uh is kind of the latest thinking that we're familiar with is the vanilla Bas sequencing where basically if there if the current L1 uh validator is opted into the system then they're the validator for our chain and if they're not opted in then a random opted in val validator would be selected that's kind of the setup that we expect to end up

with so uh getting more into how keyspace Works uh there's basically a sequencer running that's accepting users's key change requests through RPC calls uh when you have a when you want to change your keys you say hey keyspace n here's my signed uh keychain transaction can you include it for me the sequencer then takes a batch of uh key change requests and creates a recursive badge proof for all those requests uh it submits those uh proofs on chain to advance the state route that currently costs 330,000 uh gas with our implementation uh my understanding is

that the uh lower bound for these types of proofs is 200,000 gas so there's some legal room but we can't get it down by like an order of magnitude it's kind of just uh the cost of doing business with Z rups on ethereum right now uh definitely looking for input there and then there's also a forced inclusion um path for uh to avoid censorship by the sequencer uh you can submit your recovery directly on L1 and then the sequencer is forced to include your uh recovery in an upcoming batch so the the way the force inclusion mechanism works right now is that for every one offchain transaction that the sequencer wants to prove basically

something that they receive through an RPC call they have to include one of the force inclusion transactions alongside it so when you submit your Force inclusion transaction you're not guaranteed any sort of ordering you're just guaranteed ordering within the set of force inclusion transactions the sequencer will be picking one of each and going from there to create its batches uh so you'll be eventually included in the state of keyspace uh so once we have the updated keyspace rout on L1 where we really want this is L2 uh most of the smart wallet activity we expect to happen on L2 you can have a smart wallet on L1 you can

read the keyspace state rout from L1 but uh where where the action really is is L2 so we need to get these uh key store roots on to L2 and the way that we do this currently differs depending on what kind of chain we're syncing to uh for op stack chains uh the L1 block hash is available from one of the built-in contracts so we can do Merkel proofs from that L1 block hash to be able to sync the key store state route to a contract on the L2 that wallets can access uh for for uh other chains that don't have the L1 black hash we need to rely on an oracle uh for our current

proof of concept we're sinking to I believe seven chains and then the eighth chain is ethereum main net uh the the the way that we get to most of these chains is using Wormhole as an oracle uh at the end of the day we don't want to necessarily rely on a single Oracle we're investigating things like Hashi that can produce consensus among oracles for the L1 block hash and then proof from there but the current deployed uh system from the latest release from this from this week uh uses Wormhole to sync the keyspace route directly uh so there's no intermediary of the L1 block hash that's being synced since we're using an oracle we're just saying just

get me the keyspace state route uh and get it to the chain that I care about uh so that's how we get to most of the chains right now so there's those two trustless chains right now which are Bas and Optimus and uh of of our supported chains that the op stack chains and then the rest are um Oracle based chains um arbitrum is uh an L2 so it could theoretically have the L1 block hash that uh contracts could access but there's currently no way to actually access that uh L1 block hash on arbitrum that we know about uh so if we're wrong about that we want to know and if we can get that L1 block cash we we definitely want to have it the uh other way of generating these

proofs would be instead of using the L1 block hash to use the uh EIP 4788 uh Beacon root proofs uh We've implemented this but uh currently I don't think we're actually going to end up using this anywhere uh the like for the chains that are actually rollups they uh they tend to either Implement that L1 BL hash or nothing at all so uh arbitr for instance doesn't provide the L1 block hash but they also didn't Implement uh EIP 4788 uh their approach was to basically make the beacon rot Oracle uh I think revert if you try to call it because we're like we don't have a beacon chain so this shouldn't return anything uh op

stack does support uh Beacon Roots but since we have the L1 black Casher already we're just using that to prove there so we expect that uh that that mechanism won't be used but it's an Avenue if for some reason people prefer implementing that to the L1 uh blash Oracle the the other benefit of the beacon Oracle that the standard specifies the address that the Oracle should be reading from and the addresses kind of have cascading effects on uh addresses throughout the uh the system uh if I have to refer to a particular address on one chain and a particular address on another chain then my ability to use create two to generate these contracts is limited I'm G to have to

use something else to get the consistent addresses uh but with uh the beacon Oracle we could actually deploy it using Create to and that would be nice but uh we don't think that's going to happen uh lastly the uh deposit transactions are the most straightforward way to do this for rollups but they're just very expensive right now but I think 10 times more expensive than doing Merkel proofs so uh Merkel proofs it is so once we have the uh keyspace route uh on the L2 chains the all L ones everybody knows what the latest rout of key space is the next thing is for wallets to actually integrate uh with

keyspace and the way this integration works is if you think about the way you have uh signing keys in your smart wallets today uh it's you just store it directly in the contract storage so when you're integrating a keyspace you basically remove that uh your your signing Keys no longer live in your smart contract they live in keyspace so if your signing keys aren't there locally that means that with every transaction you send every single one you need to prove that the signing key that you're signing with can actually access the wallet so instead of just providing a signature of the transaction that you're trying to send you provide a signature uh you provide the data that's

stored in key space for your record which in this case is the public key and then you provide a proof of your configuration in key space uh this proof uh is uh is a snark right now but it's equivalent to a merel proof of the state in uh keyspace there's nothing fancy going on there it's just cheaper to verify the snark than it is to verify a miracle proof uh and actually uh that that may be incorrect let me back up there the by using snarks for the key uh for the state proof when you're sending a transaction with your wallet that gives us the ability to aggregate those proofs

uh later on currently there's no aggregation happening but if uh we built a uh ERC 4337 aggregator we could aggregate those proofs so uh which would lower the overhead for these transactions so once you're providing all this data you do your normal signature verification but on top of that you also need to verify the snark that's saying that hey this key that I'm using is actually in the latest state of keyspace for my wallet and with those two things together your transaction is authorized so if that's happening on the smart contract side on the client side in your JavaScript library and your mobile app whatever you're doing in

addition to just signing the transactions the way that you usually do you also need to be fetching that state proof from a keyspace node uh when you're in the process of signing a transaction making sure that you have the latest proof to be able to send with your transaction to authorize that signature so that's uh how the wallets are integrated there's also work that bundlers can do to make keyspace work better uh so one is to support those ERC 4337 aggregators that I was talking about uh those State proofs that we're including with each transaction at at current prices an overhead of about 11 cents for each transaction that's uh

much higher than our goal uh we we want uh uh transaction to happen in one second and for them to cost one cent and if there if we have an 11 Cent overhead for these transactions that's not where we want to end up we want to get it much lower than that uh so aggregation is One path towards lowering that overhead and then another thing that bundler can do for us is to allow our state lookup across contracts so when we provide that state proof with each transaction and we're uh generating and we're verifying the proof we need to access the latest uh key store root value that value lives in another contract and the ERC 4337 standard does not allow that in the

process of uh uh uh validating transactions and it does this to protect the bundler from uh losing value uh however uh the the bundlers that we' spoken to are very aware that that constraint is too strict so basically making sure that there are possibilities to work around that by configuring the like your bundler instance to say hey these specific State accesses we know about just allow them the standard doesn't allow them but we've looked at them and just just let it go uh that's one path for allowing this the other is to create kind of a uh standard single contract for these cross contract accesses and what would be special about

the Singleton contract is that the uh time the the the bundler issue is that they don't know when the state is going to change in this uh contract that you're doing this uh access to so if you have a Singleton contract where each storage slot has a kind of frequency that is enforced by the contract that you try to update it and it just doesn't allow it because you updated it too recently then the bundlers can say hey we trust accesses to this contract you don't have to tell us about it you don't have to get each one of us to configure this because we know this contract enforces the constraints that we need to be able to protect our resources that's another path forward so either per

application configuration we hope that people value keyspace enough to be able to do that and just a general solution for all applications that want to be able to do cross uh contract accesses in their smart wallets is another path forward lastly there's work that rollups can do to make it easier to integrate with keyspace we're already deploying to rollups deploying all l1s but the cost and the experience can be better if rollups were doing more to support our use case so one thing is just support reading data directly from L1 uh that uh if we're doing that then we wouldn't have to do all the syncing work to get the uh route from L1 to all the other

chains and if you're a rollup you have that L1 node right there why won't you let me read from it it would be so convenient if you just let me read from the L1 node that you have on your machine so there's various proposals out there to make progress on this but uh my understanding is that nothing really has legs yet uh uh the uh scroll has their own implementation that they've already gone and rolled out and and that makes their implementation of a key store much more convenient because I can just read all one uh there's a op stack proposal that seems to be uh stale now but they they basically had like a remote static call op code that would be very useful but we we would like to read from L1

that would be very nice another thing that they could do and this is very much a wish list I I don't know how uh how convincing I can be on this front but if uh rollups if all if all the l2s all the l1s if they just decide that keyspace is so important that they want to make key keyspace part of their consensus that would be great then you could just read directly from keyspace I don't have to do my state proof of like oh this is the key that controls my wallet right now just read from keyspace and say okay here's my op code that lets me read from keyspace and says that my uh that I'm allowed to do this that would be really great I I don't expect that to happen but if y'all are excited about it

I I want that that would be good uh so in terms of our road map where we're going from here so we have this test net beta that's on the eight chains that I mentioned uh we like it's it's in a state where it works and we just need to make it better uh in terms of speed in terms of cost in terms of operational efficiencies and in terms of security uh so that's really where we're headed the the kind of the Top Line issue right now is optimizing our recursive circuits because that has cascading issues uh uh cascading effects through the whole system if we change the the proving systems that we're using that's basically rewriting all the

circuits involved uh and that's kind of a big impact so we want to take on that cost earlier rather than later uh and the there's various systems that uh uh have pitched the that they have 30X 100x uh speed improvements in terms of proving time over what we're currently using which is kind of the first generation of uh plon proofs so we could try using planky 2 and see if that gets us the speed up that we want we could try using planky 3 which currently it seems like there's a lot of momentum behind uh in particular if we end up using plony 3 then we can benefit from using something like the sp1 uh ckvm so when people want to write their own

custom uh contracts with their custom wallets with their custom recovery logic we're going to provide our own circuits with general recovery logic out of the Gat if you have like a MN multi- signature wallet you're probably not going to have to write your own circuits but if you have some sort of fancy wallet that you want to implement you you do currently have to write your own circuit to get that implemented it would be great if instead of saying hey write some domain specific circuits to get your logic written if it could say write some rust or write some general purpose language have it compile to uh using a ZK VM and just plug in our uh verification systems that would be great

uh so that's one benefit that we see from that uh like we're we're not necessarily right now at The Cutting Edge of like knowing what the latest going on in the ZK ecosystem is so again if planky 3 and sp1 sounds like oh there's actually another approach that you should be taking looking for input there but right now we're excited about trying out planky 3 and seeing where that gets us instead of having five to 10 minute uh proofing times I hope it gets down to seconds and that would be pretty cool uh another thing we want to do is the uh ERC 4337 aggregation that I mentioned before uh we also want to think about making key space in L3 so what that

means is uh I was talking about how the lower bound of our batch proof is 200,000 gas uh and right now the actual cost is 330,000 gas uh that ends up being uh at current prices $8 to $20 uh for a batch proof to settle on uh ethereum's main that's a problem for our application like if you're let's say you're a ZK evm hopefully you have enough transactions happening in your system that you can kind of spread that cost out among all users and it doesn't it doesn't end up being that big of a deal uh we are a minimal ZK rollup for uh changing Keys uh people don't change

their keys that often so our low uh utilization ends up making that cost of uh proof validation a big deal uh in the early days it's very unlikely that we'll be able to batch any recoveries together like if a recovery is happening the chance that somebody else is changing their key at the same time very low are we going to tell people that when you want to change your key it's going to change once per day and we're going to batch up the 10 recoveries we have each day to get the cost down uh that that's probably not the greatest story so uh instead what we expect to happen is to get that uh proof validation cost off of L1 and to have it on an L2 instead using

some sort of um special purpose L2 that's for aggregating proofs so when I say it's an L3 it's not that it's settling on Bas or settling on some other general purpose L2 it's really thinking more like uh something like polygon's AG layer I think a veil has a proof aggregation system uh I think in the starkware ecosystem they have their own kind of uh proof aggregation system that's the kind of L2 that I'm talking about where again we we're seeking a minimal attack surface so minimal functionality but really we're just seeking something that Aggregates the proofs so we can settle to L1 and share with everybody else that happens to be

trying to settle their proofs to L1 at the same time rather than taking that cost on ourselves uh so that takes the cost down significantly uh I think valal was writing an estimate that's basically like the cost of a storage plus some bookkeeping operations so something like 8,000 or 13,000 gas I forgot exactly what that was but it's a far cry from 330,000 gu and that would uh make it much uh more feasible to have even potentially users cover the costs of their own recoveries right now in the the testnet version it's just we're we're running the thing uh if we were launching key spaces in L2 we'd probably try to find some way to cover that cost

because it doesn't make sense for users to pay 8 to $20 to change the keys so uh try trying to get to a path where we can even if we launch with an L2 where we have a road map to get to an L3 where those costs no longer need to be subsidized at that large of a scale speaking of subsidies uh we also want to be able to collect user fees from recovery transactions and when I say collect user fees I'm not saying we want to be rich we want to make money from users changing their keys uh what I'm saying is that we want key space to be more resilient than it is today right now the operation depends on the generosity of coinbase Incorporated uh we we run the thing the the costs are

covered by the the we're running a sequencer it's just it's the keys are going to get processed but for key space to be the kind of uh ecosystem-wide infrastructure that we want it to be it cannot depend on generosity it has to depend on economic guarantees instead so the current thinking around making sure that there's a way for users to pay uh for recoveries or for their wallet provider to pay for their recoveries for them is to allow uh intents to be used to trigger recoveries rather than just directly sending your uh recovery to the keyspace N uh what that means is making sure that there's a way for the sequencer to prove that they've included

a par included a particular user's recovery transaction so then they can go to whichever chain that the user initiated their intent of on and claim the value that they uh want to be compensated with for processing that recovery in that model uh we could continue subsidizing it like if coinbase is running the sequenc we say hey we support these intents but like we're just covering it for now so we don't care if you actually funded an intent or not we could keep doing that but then on the day when coinbase decides we're not so generous anymore we're we're not subsidizing this anymore uh anybody else could step in and say okay I'm going to run a sequencer but instead of doing what they were doing and just accepting

any recovery I'm only going to accept recoveries with a funded intent and then I'm going to collect that money at the end of the day that's the kind of workflow that we want to support so uh the system can be more resilient and not dependent on subsidies anymore even if it is subsidized lastly uh we want to be able to support time delayed recoveries so uh one of the uh one very common pattern in terms of securing uh C systems uh is just time delays if you have if something goes wrong if you have the time to take action to like reject whatever was happening that makes systems easier to trust easier to

reason about and right now there's no mechanism to have time delays within key space so let's say uh you actually lost your key uh it's not like oh I'm changing my key I have this one pass key I want to approve another one but man I lost my key I don't have it anymore uh it would be nice to be able to have some sort of Guardian feature where there's somebody else who can help you recover your key but right now in the current Implement implementation of key space There's no distinction between different recovery methods if I'm adding a guardian they have as much rights as I do to my wallet they have control to all my funds and I I probably don't want that so time delayed recoveries allow us

to add basic another type of recovery where when you uh initiate it there's some sort of configurable waiting period and then uh after that waiting period is passed that's when the key change is processed so that ends up being a significant change to the circuits because right now when you're uh the the account circuit which is what's used to prove the uh key changes uh the inputs that it takes are just user provided inputs there's no kind of environment provided inputs uh to the circuit and that's what we would need to be able to uh implement this kind of prepare and commit uh two-stage process for time

delayed recoveries uh so the easiest thing to reason about is let's say you initiating your time delayed recoveries on L1 then we need some way to get the L1 data into the circuit and prove there uh I I am assuming that that path is relatively straightforward that if we wanted to allow the uh recoveries to be initiated on L1 doing the proof in circuit from the L1 block hash uh might make might make that possible uh the where it gets harder is if we want to say okay it's expensive to initiate the recoveries on L1 so maybe we want the guardian to be able to initiate their recoveries on an L2 what does that look

like well if it's an optimistic uh L2 the uh settlement times are fairly long but maybe those settlement times are actually not an issue in our time delay if our time delay is one week or two weeks then the fact that it takes a week to settle maybe we don't care and we just end up doing uh uh proofs against an L2 uh in that way uh but also want to investigate uh the ZK l2s and doing uh time delayed recovery proofs from those chains as well so that's kind of an overview of where we're heading uh we're always looking for feedback we uh in terms of like zero knowledge systems we've learned so much

from the people who've been doing Cutting Edge work uh there's always more to learn there so looking for feedback on that uh rollup architecture a lots of people have been thinking about how to make this happen well we're looking for feedback there and if you've just been thinking about wallets for a long time when you have a case that you want to throw away uh we're always interested in talking and we want want this to be a neutral piece of infrastructure for the whole ethereum ecosystem to rely on and at the end of the day we want millions of users using smart wallets to send their transactions that cost one cent that take one second to process so it can build an economy on top of these decentralized systems that Empower people uh that's keyspace amazing thank you so much Nan

for this extremely thorough and comprehensive uh presentation we we have about uh 20 minutes for questions during the public part of the call um anyone want to kick us off on the questions uh Len go ahead um so yeah thanks for the talk um I have a question about so you mentioned that you probably are you don't need pre-c confirmations but you also mentioned that you're going to use a like the vanilla based sequencing which is actually a pre-confirmation solution because it so where they require the L1

proposer to explicit op in and opting in is required because they need to be like subject to slashing condition and the slashing condition is required because you need like flashing when they equivocate on the pre-confirmation so I was wondering like why you need that kind of explicit optin like is it going to be used for something else and pre confirmations that's a great question so the answer is uh I don't know what I don't know so the the the thing that seems attractive about vanilla Bas sequencing is really kind of the smoother adoption curve the fact that um like the we we want to kind of Leverage the

distribution of proving slots that uh the L1 iic already provides for us so the optin is really uh in in the thinking so far is just a way to in like uh when the the nice the the the kind of the the happy path for Distributing these proving slots is literally for every L1 sequencer to be running keyspace or for many L1 sequencers to be running keyspace because then we know that many people were involved in uh proving for key space and the chances of uh livess failures because there were uh

like few people actually involved doing it and then they decide to stop uh is reduced so really that's what we're looking for in their approach if there's a simpler way than vanilla Bas sequencing uh if the optin isn't actually necessary uh that's definitely something we want to think about but the way I think about the opt-in right now it's just we're trying to know who to select from in both the happy case where the current L1 sequencer is saying hey I I want to participate in the system or in the unhappy case where it's like uh the current L1 sequencer knows nothing about keyspace who do we pick now should be one of the people who've opted in but if

there's if there's another way to do it I and I suspect that there might be very interested in that I see so kind of like to get the liveness guarantee from having explicit opted in that's what're okay I see yeah thanks and once you have uh user fees um then I guess the Searchers will be interested in providing bundles to the builders and you you'll get this for free with PBS but one of the things you want to make sure of is that um you don't have this contention with different people building proofs that are inconsistent with each other but if you can get the proving time to be under 12 seconds which might actually be

possible in your case because you have a very simple virtual machine then this is the best best case scenario where you don't need any opting in that would be great if the Prov are that fast uh there's a question in the chat is proving and sequencing permissionless uh it currently is and what we've deployed right now uh there are kind of two paths towards a broader launch uh one is just biting the bullet and doing Bas sequencing and having the first production release of keyspace uh using that method and then it would continue to be permissionless uh and we would just be relying on the L1 sequencer distribution to make that happen there's another path towards release where we

say okay uh that work is going to take too much time but we want to get this out there let's just launch the way that most rollups launch and have a white list of allowed sequencers and launch them that way so that's the scenario where it doesn't end up being permissionless uh but that's that's not our end goal um sorry that was just my question but thanks that was a great talk on I really enjoyed that and the way you explained your stff um how would you weigh up like the the odds of like path one versus path two right now in your head like path one being going based and and path two having this white list and do you have an intuition for that or uh I I think there's a chance that we

end up actually implementing base sequencing uh that that depends on I ideally we're not the uh we're not super early in doing that like uh but if there especially if there are live implementations out there I expect that we would follow quickly uh with our own implementation and launch in that way but uh we just haven't done enough research to know how big of a commitment implementing that would end up being uh if it ends up being very large I could see us uh launching like just it seems fairly typical to kind of Kick the Can on that particular issue with rollups and say we're just G to gradually uh

decentralize it um so if I if I to say which one is more likely I would probably say gradually decentralizing it but uh it would be better than that okay thank you I have a question I have a question about the latency so for the various uh key store raw operations uh what are the latency requirement in your mind I think this is related to uh what kind of sequencing model you end up Chosen and if you are um using peration then um because we are working on profilation we want to understand what's a requirement on the latency side when people are um doing these like a ZK operations if that makes

sense yeah yeah that makes sense so for our use case uh changing Keys it's typically not super time sensitive uh because of the requirements for changing the key you have to have access to the old key uh you're signing the new key like you want to be able to use the new key it would be nice but the since the wallet has access to both keys at the same time if it's slow to update you just keep signing transactions with the old key until the update happens so we don't have like if if it took uh two hours for a key to update I think it would' be fine I think we have kind of like a constraint that we put in one of the design documents that might

be less than that um but is if your keys change in 30 minutes I think I think we're good thanks one question I have is around governance and how updates to the contract are done um ideally we have a super simple virtual machine and it's fully mutable uh but do you think it's more likely than not that there will be governance initially and what would that look like so the current thinking is no governance at all so basically deploying keyspace as an immutable system and when

an upgrade needs to happen you deploy a new key space uh the lever for upgrades in that scenario would be on the wallet side rather than on the keyspace side when you want to update to the latest version of keyspace you update your smart contract wallet that wallet is pointing to a different key store and using different logic than your initial wallet was so because the wallets themselves are typically upgradeable we believe that keyspace probably does not need to be and it's probably better if it's not so then people can opt into whatever version they want to use amazing so a very similar model I guess to Unis swap where you have V1 V2 V3

potentially exactly like a hello uh so I have two questions actually the first one was based on uh what you just recently answered um so regarding the part where you said you know like if you have access to both keys and if it takes like 30 minutes to update it's fine so my first question is uh like obviously this uh like uh if if you lose I was thinking of this scenario like let's suppose you lose a key right for any XYZ reason maybe you realized you pushed on GitHub by mistake or you did some something and like similar to the Web Two World you you lost you lose an API key so you can instantly go revoke it now this doesn't exist in the EA world but uh do you think like smart contracts would like to provide this

feature like by any chance if you leak your private key you can instantly revoke it because if that's true then a 30 minute or a 2hour upgrade might be like very for something like that so you're absolutely correct there the um in terms of thinking of the engineering behind this it's uh it's kind of easy to take the lazy approach and be like the current systems do not provide this so do the new systems necessarily need to provide this the at least for the first iterations of this kind of system it's much uh easier to approach it in a way that where latency is a acceptable because the existing EAS just don't provide this at

all um the and and the main scenarios of key changes like the the the the fact that smart wallets allow you to change your keys it it's I I guess maybe some people are implementing it as kind of like a disaster recovery sort of thing oh I exposed my key let me change it but the primary use case that I've seen for it is just letting you move to a different device or move to a different uh signing key rather than the you rather than the fact that you've exposed it uh since exposing a key is a catastrophic thing today uh expecting it to continue to be

catastrophic is the way that we're currently thinking about it don't exposure key that's bad uh the keyspace can like just technically speaking can help people respond to that I publish my G my key on GitHub let me change my key as fast as I can like it's possible to design a system that does that it's just in my head so far down the list on things that uh wallets need from us that it hasn't been a priority to design for them makes sense thank you and my second question was around uh I think uh in the arbitrum side you mentioned that uh you have to use an article because you don't have the block hashes so maybe I'm missing something but uh is is it

possible that you know like you you deploy a contract on L1 and you send the previous block hashers by like L1 L2 messaging or some other way yes so we we could Implement a trustless deployment of key space on arbitrum through deposit transactions uh the only reason that we don't is because the deposit transactions are expensive um but I I honestly hadn't thought of it deeply until you just mentioned so it it really depends which which factor ends up being more important to people if people are like hey I we want trustless deployments of key space in as many places as possible then we would just fall back to deposit transactions

on arbitrum and Achieve trustless that way if the costs are more important then since we don't have a cheap trustless way to do it on arbitrum we would stick with the Oracle but uh that's a very good point to bring up we could just use deposit transactions makes sense thank you one question I have is um what is the the team size of the the key space uh project uh so right now it's about three people uh I think we have one more person who's about to join the team uh but uh the just just so I'm not taking

credit for somebody else's work this work has been led by Michael Deo who's done a lot of thinking about the key store rollup uh really uh kind of wanted to be like a torch bear for like valal did all this writing it's like hey like somebody needs to go and implement this and making sure that it gets implemented in a way that the ecosystem can rely on uh so Michael's done a lot of thinking on that uh I I joined uh the Bas team in like late January early February so I I haven't actually been around that long although maybe I need to stop saying that because the months are passing pretty quickly but uh I I've I've enjoyed like it's been a very fun project to work on I've I've been in like the crypto space for a while and most of the projects that I work on you

know having real people use them and get value from them uh it's it's hard to get to that point but working on something like keyspace where it can like be a core piece of infrastructure for the ecosystem has been a relative Delight in that fact because I can like the the other wallet teams like interacting with them uh getting to know like their concerns because they actually want real users to uh be impacted by these systems it's been uh a fun rate and if there's no more questions I'll keep asking um you mentioned that you wanted to um potentially do a fast follow in terms of launching a a base

rollup um do you have a an ideal timeline in mind as to when you'd like to launch uh so we're currently on a Cadence of roughly quarterly launches so really getting as much out as we can each quarter is the idea um for the next release I expect that sequencing isn't actually going to be super high on the list because we're going to be doing all this work trying to evaluate py 3 uh all this work on um there's another thing that super I forgot what our second priority was but the the currently there's higher priorities than the sequencing so I expect that that might get it down a little bit so if if we were launching a

base rollup I would currently guess that that would be early next year understood thank you any final questions before we wrap up the public part of the call or maybe Nan if you have questions for for this group um we could also entain them yeah the main things that we're always looking for is feedback on like base sequencing in general I we've we've been following the discussion from afar so when when our assumptions sound like they might be off like thinking of yourselves as the experts rather than us

and giving us the feedback definitely interested there and like uh just uh in terms of choosing uh like ZK stacks and things like that the experiences that people have had uh that's always uh welcome as well uh Justin thanks for all the information you provided uh for us so far that's been very helpful and always always interested in more feedback uh Len okay so I have a more nerdy question about the based reconfirmation sequencing side so and it might be more for George but um like so in the Pilla Bas sequencing so like you randomly elect for a non opted in slot or when the proposer is not not opted in

you randomly select like uh a validator who has opted in but the problem here is that they don't have the control over that slot so they can't promise that they will actually include the transactions in their allocated slot so they can like come delayed if like the because they have to go through the mle and the Builder might not include them and maybe the Builder will include like the next slots like um ofed in valid dous transaction before like the current random one like that so like another approach is like from Justin's like original based rollup design where or sequencing a pre pre-confirmation design where like you

just let the next pre-conference look ahead handle like the pre-confirmation for like the non opted in SLS so this way eventually that entity that proposer will have their Sal and they will have control over it so they can include it seems to give better guarantees so I was wondering about that part of the design uh that's a great point that I hadn't thought too deeply about so basically just to restate what you're saying uh if we select a random validator from the pool of validators that have opted in and say hey you're you're the one who's doing the next uh proving block for keyspace uh they may not actually be able to get their uh proving transaction into a block

um yeah uh I need to think more about that that makes that sense so what yourest go ahead yeah hi well um there is not too big a difference between what Justin is suggesting and what vanilla Bas sequencing is suggesting because you certainly end up with a scenario where you might not have a single opted in base sequencer within the uh luad Cube so you end up with the same things the good part of what came out out of uh Z Lim is this L1 PR informations Gateway that actually enable you to despite not being the basic oner yourself you can you can get a one prer formation of the inclusion of this

transaction which is then again uh even further more uh increase but yeah this is the this is the the the tradeoff within any B sequencing when the current uh A1 proposal has not outed in uh yeah and I hope there is no much static noise around yeah like yes in the case said there's no pre-conference in the look ahead yeah you do have to fall back to some random but it doesn't have to be random at every thought that seems no no no I I don't think you understand understood the correctly uh the the elected sequencer the elected signal through the pullback selection can use

the L1 pre confirmations uh infrastructure that is currently being built I know for example header that is uh that uh head header right Hilder that is being built sorry shout out to Drew uh yeah so Hilder is currently being built so you can use that and now that you have a larm PR confirmations the cool part is that in this way you can have even more uh even more sequencers through van Bas sequencing and you can have L more decentralization because you're having rotation of among more more accur because one of the worst things in my opinion you can do is to give a monopo over 10 12 minutes over a single to a single proposer so in this

way we're actually shuffling Monopoly every 12 seconds I'd argue that this is better in terms of uh I guess yeah many decentralized points so is it that there's going to be a separate L1 inclusion pre-c confer entity that can guaranteed inclusion that or this what currently is being built uh in in Helder uh again the scope of L2 and L1 prec confirmations uh are differing and they are diverging at certain places uh currently there is uh L1 PR formations Gateway being built as

a test n that is going to be I don't know whether I should be saying this but expect some exciting stuff on HCC I guess I see even if you have the inclusion I'm still wonder about the order of these Landing but I guess you can handle that at the contract level yes yeah okay I see yes the the one of the worst parts to to be like uh clear on this one is that uh it's hard for one to prove who's the current proposer but yeah I have I have written extensively in the in the white paper on the various ways that you can mitigate this uh uh yes this downside I think that is a very simple solution to this but as our great

friend Connor says we don't like designing system that bent on several L1 L1 Forks so there like workarounds that don't require L1 Forks but L1 Fork is going to help us tremendously just by telling us who's the current proposer their BLS public or whatever it is there and then Bas sequencing can be like many many cral points of vanilla Bas sequ oning and Bas sequencing can be for True solidity and smart contracts which is going to be yeah very cool see yes thanks uh just to make sure I understood what George is saying if you have L1 pre-confirmation then when uh in in the case where you're choosing a random uh

opted in validator uh they they know that their transaction is going to get into the block because they have pre-confirmation of it uh but what if they try to get a confirmation and they don't get one uh this is the same as submitting this uh within a block withoute prec confirmation but then they're paying the inclusion tip so yeah I mean it's it's the risk of when you're not actually the proposer there is definitely a risk in in any case that is not primary selection regardless there is there is there is this risk that is that is there yeah it can

we can we can discuss more on this off chain in order for to understand like what's better better like what's going to be important for for for you there in order to be able to advise better on solution I guess okay Nan thank you so much again for this presentation this concludes the public part of the call