Building on Base Appchains with Flashblocks

Transcript

All right. Uh, hello everyone. Uh, this is building on base app chains with flash blocks. Uh, my name is Chris Hunter. I'm an engineer on the base team working on base app chains. Also a quick Canada day to all the Canadians. And my name is Ryan Morning. I also work on the base app chains team as a software engineer. Hey, my name is Alec. I work with Chris and Ryan on the base app chains team. Today we're going to be talking about building on base app chains with flash blocks. So first of all, what are app chains? You can think of app chains as dedicated block space for your application. We support lowcost, high throughput transactions and they are fully customizable to your application's use case as well.

Let's talk a little bit about those customizations. First of all, we support custom gas tokens. So you can allow users to pay for gas on your chain using any ERC20 token of your choosing. We also provide contract allow lists so you can prevent spam on your chain and preserve your precious block space for your core contracts. We also have account abstraction support as well with support for smart wallet and ERC 4337 bundler and pay master. Okay. Uh yeah and one of the last kind of primary issues to solve with app chains is uh typically like app chains used to mean kind of more siloed experiences. Um and the solution that we have here is like fast bridging to and from base uh which is actually really powerful when you think about it. Um

fast bridging in of course is kind of standard for other chains as well. uh fast bridging out kind of removes one of the main friction points uh a lot of app chains would see where I don't know bridging in and you think oh if I bridge into this game you know maybe my assets are stuck there for seven days for a withdrawal period. Um, also, uh, with what we'll jump into, like a 10-second withdrawal means, uh, app chains can really start to feel more like traditional apps where, you know, you can try it out, try out a game, uh, you can withdraw back to base, uh, and, you know, be back into the, uh, large ecosystem of base uh, with all the liquidity, all the users, etc. So um really that's like uh the main pain point we wanted to solve

and how we did that is how we did that is through op enclave which is an modification to the op stack. Uh basically it proves uh the output via a trusted execution environment or TE and that's what gives us our lightning fast withdrawals of about 10 seconds. Uh so yeah looking a little bit closer at OP enclave. Uh appchain blocks are executed by the TE. Uh we're using ads nitro. Uh basically the TE will execute and then sign its output state. Uh this is then posted back to base uh for the withdrawal. Uh and no fraud proofs or ZK required. So, um, although ZK like we're super excited about for sure, uh, the 1second block base block times of app

chains, uh, are not yet, you know, sufficiently they're they're too quick to basically prove with ZK yet, but, uh, we're keeping an eye on that space. Uh, so yeah, this is the withdrawal flow. Um, so we'll just kind of step through the whole thing here. Um basically yeah a user uh on the app chain say they want to withdraw back to base here. Uh they'll submit a withdrawal transaction to the sequencer. Uh at that point uh the proposer and the batcher which are just standard OP stack components uh will become aware of that withdrawal. Um the batcher's job is to basically submit uh commitments to the uh transactions uh that the uh you know chain has uh included in its blocks. So the batcher will submit the batch. At

that point the safe head uh which is just like basically where the current uh state of commitments are uh advances. So with the safe headed advance the proposer uh is now in a position to submit its output. Uh and so what it needs to do now is to basically call uh the TE within AWS Nitro. Uh and for the enclave to uh recomputee the block uh because we run these uh TE's in a stateless manner uh so we can scale to n app chains we need to include the execution witness uh and what that basically is is like all the state touched um during execution of the block uh that the sequencer had, we include

that in the request to the TE. So then when the block is re-executed um you know the enclave has all the information it needs to actually advance that state uh at the end of the uh block basically the TE has uh you know its output it will return that to the proposer uh which then submits it to base and that would mean that we would have a withdrawal that um is all app chains have their own uh basically like bridge contract but they're all managed or communicate with this testing system config global contract and that validates and stores uh PCR0 uh and PCR0 is basically uh it's a hash of the code and the initial state within

the TE um so then you're you're sure what the TE is running um and that will accept signers as we mentioned the TE will return a signature u with that signature you know that signature came from a specific PCR0 and that's what withdraws uh sorry that's what validates or proves the withdrawals for app chains. So basically when a withdrawal happens um you can be sure you know it was optack or optimism that uh did the state transition therefore it is a valid block. Uh and of course you know the all blocks kind of build on the previous one of course. So additional tool we added uh into OP enclave is basically the um PCR0 verifier. uh just allows you to

basically measure the uh code within OP enclave and then you can verify uh what's uh accepted in the system config global contract on chain. So basically you can be then be sure that uh optimism is what's running within the TE and uh proving the output. Uh yeah so how to integrate uh with this system basically you can you know build your own uh UX of course uh and we also provide onchain kit uh UI uh components um which just basically allows you to bridge uh tokens in and out of the app chain. Uh but either way, two seconds to bridge in uh 10 seconds to bridge out and uh you know your apps have a lot less friction.

Okay, so we'll get a little bit into flash blocks. And what are flash blocks? So flash blocks are going to be ephemeral blocks that allow us to have 200 millisecond block time and real-time UX for onchain applications. So on base app chains, we have a base block time of 1 second. We can split that into five ephemeral blocks of 200 milliseconds. uh and then you'll be able to start to get pre-confirmation data from those uh flash blocks. So what does this really look like under the hood? So we have a typical sequencer here that you would see in optimism. You have your consensus layer uh in charge of keeping the canonical state of the chain updated and then your execution layer which is uh building blocks and then returning those blocks back to the consensus layer. So

what did we add that's new? So added new here is going to be the roll-up boost and the new external block builder. And so we'll kind of get into like what the role here of roll-up boost is. So rollup boost is going to be in charge of multipplexing the engine API calls to both the proposer, you can think of the proposer as the typical sequencer that we used to have uh now upgraded with roll-up boost and the new external builder which is also building blocks. So this starts to look like uh the proposers op node will trigger some block building by sending out an engine fu call uh fork choice update and it'll multiplex that both to its internal uh execution layer and the builder's

execution layer. Uh at this point the builder will start broadcasting those flash blocks those uh ex uh ephemeral flash blocks and after a while the op node will will after one second it'll reach out for that uh built block. So it'll multipplex out that engine get payload. Uh that block will actually get validated with the internal opf but it has already validated its own block. So that's cached and then we'll update the chain state. So, how can we start retrieving this flashblocks data? Well, we have the new flashblocks aware RPC. Uh, the flashblock aware RPC is going to come with some new flash block specific

methods. Uh, the two that are interesting to call out is um the flash block transaction receipt with the pending param uh and as well as all the other standard Ethereum JSON on RPC methods that are working out of the box. You can also stream real time flash blocks updates with the websocket API as well. So what does this look like for an app? Uh you'll see the client can use the existing uh receipt RPC to get preconfirmed receipts, right? So the client will send off some e send raw transaction over to the sequencer that'll respond with a hash. We'll pull for that get transaction receipt and then uh we'll return the receipt. Um, and all of that will be preconfirmed

from those 200 millisecond flash blocks. Uh, we're also looking to support EIP7966, which is the new ETH send raw transaction sync. We kind of see how this cuts down a lot on a lot of that wasted time from the asynchronous calls, right? So, in that first flow I showed you, we send off the uh send raw transaction and then once we get the hash, we have to pull back out and wait for the receipt. uh some of that time can be mitigated because at the same time that we have the transaction execution the receipt is already available. Uh so with the new eson raw transaction sync we uh batch all that up and we uh cut transaction and submission and confirmation time by 50%. Uh and

then we also remove that extra need for polling in the clients. uh this gives that more responsive feel that a lot of people are used to and that closer to web 2 uh user experience. Um also the ESI raw transaction sync is just using existing RPC methods. So it just works as is. So you might be wondering what can I build with flash blocks and base app chains? Well, we see a lot of our current customers are gaming customers. So they take advantage of our lowcost and high throughput transactions to put uh partial or fully onchain gaming. And we also see arts and culture. So for example, crowdfunding platforms that require uh lots of transactions uh as well as real world assets and deep pin

apps as well. So we answered the what um why should you build with flash blocks and base app chains? Well, first it's fully customizable out of the box. We have native support for custom gas tokens, contract allow lists and as well as interop with base uh nearly instant bridging and withdrawals. Second of all, you also get coinbased integrations such as flash blocks onchain kit smart wallet and pay master with more. Third, uh high throughput transactions uh where you know for your use case maybe using blobs for DA is cost prohibitive. Uh with our infrastructure, we allow you to send uh transactions at fractions of the cost of using blobs.

Additionally, our 200 millisecond uh block times unlock real-time low latency apps and provide a user experience very similar to traditional web two apps. So you can get started today actually um because all our infrastructure is compatible with the standard EVM tooling. So everything you use today for your app such as Foundry, Wagmei, VM should have support out of the box for uh base app chains. We provide a standard and a private RPC for you. They have different rate limits and access to different methods such as the debug namespace. You're also able to access, deploy, and manage your base app chain through the Coinbase developer portal.

And for mainets, we're currently in private preview. So a quick demo we have right here. Um we built a demo app called base app chains bakery. This showcases the power of flash blocks and base app chains. How it works is essentially um you have like 10 seconds you spam space bar as fast as you can and each space bar is one onchain transaction and the kind of like pastry you bake uh depends on how many transactions you can get through in that time period. So as you can see here I'm spamming spacebar and you can see the transactions show up on the bottom of the screen.

In the 10 seconds, I get around 37 transactions confirmed on chain uh with a 90% cost savings compared to blobs for DA. Finally, we're going to open it up for Q&A and we also have a QR code for the weight list if you are interested in this product. Hi, thanks um you mentioned the PCR0 for the OP enclave. Um so uh these app chains are operating in a T and uh so there's a different set of um uh

security assumptions uh there um how how does an end user of an app chain uh ver um get the attestation for execution? How do I uh take a transaction that happened in an app chain and and get back to the source code that's actually running in that T, right? Uh okay. So that I guess it would be like a withdrawal, I guess. Or are you saying I mean Okay. So the app chain will you know uh periodically uh also put uh its output through proposal. It also does that when there's withdrawal to so people can withdraw within 10 seconds.

Uh but once it's within that uh output, you obviously need the information uh of like what's on chain. Uh so like you get the state there. Um you can then view uh you would I mean you might have to it depends how far you want to go back but you could basically look at assuming you can okay so you have the state uh the state hash within the output. Um you now need to know that uh optimism is what said that this is a valid state given kind of like some initial block you want to kind of prove from I guess right. Um once you have that though uh you basically need to go up the certificate chain to know that uh ADS nitro was the one that uh did the state transitions.

Um so within the system config global contract like we manage uh what PCR0 are being added. That's like a permissioned uh uh signer. we control uh we've added uh OP enclave there. So you would be able to then basically verify the PCR0 within the TE is uh OP enclave um the signature within uh so basically how yeah like another level that's what's happening because we don't want to post the full like uh enclave uh attestation with each output. Uh we basically get uh the enclave will create a ser uh that ser uh local inside of the enclave. uh and then we when it signs an output and

sends it to the proposer we that's the signature we include. So when we get that signature the system with big global contract looks at okay is the signer uh approved and if it's approved therefore that means that it was within an AAT that had a valid certificate chain and if it has a valid certificate chain like uh that PCR0 is what and then you could use the little kind of tool we have there to see okay that it it is running OB enclave okay so on a high level um if I'm going to want to trust this but I want to verify I follow those steps approximately to to verify that um uh my my trust assumptions are holding in the app chain. Correct. Yeah. Great.

Thank you. Thank you. Any more questions? Uh yeah, there's also a blog post that goes into the kind of what you need to do to uh validate something like that. Uh it's on the base engineering blog uh with a bunch of other good content. All right. Yeah. Thank you.