00:00welcome to modular March I'm handy this
00:02is Robbie and we are the rollup modular
00:04March is an educational experience about
00:41welcome to modular March we have another
00:44episode today with Nick Dodson the CEO
00:46fuel of course join with Rob GM Rob and
00:51Nick hey how's it going um should I do a
00:55quick intro on myself sure yeah sure all
00:58right uh y so I'm Nick the CEO of fuel
01:02um and yeah very very happy to be
01:06here awesome yes stoked to uh get into
01:08this presentation let's let's do it
01:11awesome all right well so um so for
01:15today I thought um I thought we'd go
01:18deep into some of the problem space and
01:21then um kind of how fuel is approaching
01:24solving some of the current problems in
01:25the landscape right now and and how
01:27we're thinking about building things I'm
01:29sure given the amount of presentations
01:31you guys have been doing um you know for
01:34for modular March I I I'm sure there's
01:36like a a ton of content already on like
01:39numerous topics so I'll try to be brief
01:42with the problem section and then just
01:44try to go um heavy into uh into some of
01:47our solutioning but yeah so let's uh
01:50let's dive into it so first of all um
01:52the problem so right now in the roll of
01:56space uh just to to dive right into it
01:58um you know it's 2020 for um we're doing
02:01a lot of rollups now there's a lot of
02:03new um different chains coming out
02:05there's a lot of new architectures in in
02:07the space um basically you can kind of
02:10briefly categorize the architectures
02:12that are in the space into two sort of
02:14broad categories one of them is um you
02:17know architectures that were really
02:18designed for monolithic layer one
02:21blockchains so um you know if you're
02:24familiar with monolithic and modular
02:26architecture you'd know that that's sort
02:27of like layer ones that um really are
02:30trying to design for everything and um
02:33and effectively the evm fits into this
02:36category so uh does move and so does a
02:38salon ofm in a sense these are
02:40architectures and virtual machines that
02:42were really designed for um you know
02:44monolithic chains uh and on the other
02:47side of the spectrum you have arbitrary
02:49Computing uh environments and so in that
02:52sense you have things like wasm and mips
02:54and risk 5 being used so a lot of the
02:57architecture right now for rollups in
03:002024 is really divided along these two
03:03these two lines right and um you know
03:07when we get into just thinking about
03:08this problem some more you can kind of
03:11see in the in the current rollup
03:13landscape um you know most chains right
03:16now are using either monolithic lay one
03:18or some kind of mixture of an arbitrary
03:21Computing environment um and monolithic
03:23lay one maybe there's one or two that
03:25were really designed for the tasks that
03:28we're really doing rollups like darket
03:31but the rest of them are really using
03:33architectures that we've seen in the
03:34space that makes sense you know you see
03:37the evm out there um it's everywhere so
03:39there's a big business model around it
03:41um same with salana same with movm so it
03:44sort of makes sense from a business
03:45perspective to do this but of course A
03:48lot of these architectures were never
03:49intended to be used in what we what we
03:52now Define as rollups so uh maybe a
03:56helpful analogy for at least how I see
03:59some of the problem transpiring in the
04:01space so um like a simple analogy would
04:04be like you wouldn't put you know
04:07Windows uh like desktop on a phone it
04:10just wouldn't make any sense um Windows
04:12desktop not configured for your hands
04:15not configured for mobile networking not
04:17configured for a ton of stuff that you
04:20typically experience with a phone and
04:23you know when you look at the way
04:25something like an iPhone's built or an
04:27iPhone's constructed they constructed
04:29everything around exactly how it's used
04:31they constructed everything around you
04:33know networking around the fact that
04:35your hand is touching things the fact
04:37that uh you know there's certain battery
04:39constraints right and so it brings up
04:42this bigger problem which is we're using
04:44all these monolithic layer one
04:45architectures or we're using these
04:48architectures but we're using them for
04:50something that they weren't really
04:52intended for which is rollups and so the
04:54analogy sort of holds here like that and
04:57to bring up some useful um useful
05:00tweeting you know basically when we look
05:03at the constraints we look at the
05:04current space for rollups um you know
05:07we're starting to see that people are
05:09figuring out that um you know you can't
05:12just get everything you want out of the
05:15existing architectures so nothing is
05:17Magic and nothing is for free and
05:19basically you know we we probably talked
05:22a lot about you know parallel execution
05:24you probably talked about a lot of
05:25things like State blo and other things
05:27with previous podcasts well they're all
05:30interl and they're all really complex
05:32set of problems and when you're reusing
05:35these previous monolithic designs you're
05:38going to inherit all the same problems
05:40that they have nothing's for free
05:42nothing's really changing and you can't
05:45just magically you know turn up the
05:47dials and say well it's a rollup so
05:49everything's fixed now um and so a way
05:52to yeah yeah if you don't mind could you
05:55um would you mind breaking this tweet
05:57down for uh like a five World sure yeah
06:01so with rollups and particularly
06:05blockchains we want to do a lot of
06:07transactions um but unfortunately when
06:10you start doing a lot of transactions
06:13there's problems with that so for
06:15example if your systems designed where a
06:19lot of transactions basically depend on
06:21each other um we call this like state or
06:24state contention um basically um you
06:28have problems with just managing what we
06:31call like this the statefulness of a
06:32blockchain but you also have problems
06:34with um incurring States so if you're
06:38making tons of transactions that's great
06:39well now you have tons more data to
06:41store you have tons more things to keep
06:43track of you have you have so much more
06:44stuff that could depend on each other
06:47that um could basically bottleneck a
06:49system right and so effectively when you
06:53have um you know a very high throughput
06:56blockchain well there's side effects to
06:58that and there's problem with that and
07:01really if you don't have a good strategy
07:02for how you're going to manage the state
07:04of things right which is just you know
07:06you have this I have this and as well if
07:09you make a transaction I make a
07:10transaction and they touch the same
07:12piece of State how you going to deal
07:14with all of that right so both state
07:16contention and this sort of like big
07:18bloat of state that we're having with
07:20blockchains is causing a lot of issues
07:22um and so really it's not so much that
07:25you can just do a lot of transactions
07:28that's fine you can Des design a system
07:30you could write a python script tomorrow
07:32that does a lot of things that look like
07:33a transaction and and process that just
07:36fine the big question is is like what
07:39are really all the side effects of this
07:41what do you really need to run this
07:42system what do you need to keep track of
07:45um what are all the interdependencies
07:47and unfortunately for a lot of
07:49blockchains and a lot of designs they
07:51don't really have a good solution for
07:52this they don't really have ways that
07:53developers could fix some of this stuff
07:56so you know it's one thing to be like
07:58well I can do a lot of TV s well sure
08:00you can write a server tomorrow that
08:01does hundreds of thousands of TPS right
08:05but the design of the system the way
08:07that it works is actually the most
08:08important thing if you want to build a
08:10blockchain if you want to build real
08:12decentralized networks and that's no
08:14different for lir ones it's no different
08:16for rollups so um yeah maybe that's a
08:19explanation quick clarification on on
08:22the state bloat it does historical State
08:25contribute to the bloat or is it yeah so
08:29I would say that um there's a few
08:31different ways to think about state so
08:33really um when when you're thinking
08:35about the problem you're thinking about
08:37a few different things one is what does
08:39the node need to keep track of right now
08:42in order to progress things right so
08:44what does it need to have sort of on
08:46hand in its uh in its database to make
08:49sure that if someone makes a transaction
08:50they can process it and know that it's
08:52valid um and then another side of it is
08:55you know keeping all this historical
08:57information over time uh which is more
09:00like what you would do with things like
09:01archive nodes and stuff like that so
09:03archive nodes are um you know they're
09:06part of a lot of normal blockchain
09:08architecture but they're sort of
09:09separate whereas state is sort of like
09:12what does the node need to keep on hand
09:14in order to progress things into the
09:15future right and that's like what does
09:17it need to keep in a database
09:18effectively so for typical blockchains
09:21that aren't ZK this is what you'd have
09:23to deal with continually and even for ZK
09:26you would still want the state
09:27information because you would need to
09:28know how to build new state in the first
09:31place so both systems actually have to
09:34keep track of State uh in this way that
09:36makes sense got it thanks cool so um so
09:42one way to think about this this problem
09:44this is like a helpful way that we've
09:46described it is trying to solve for PSI
09:49so performance sustainability and
09:51interoperability right you want your
09:53blockchains to be super performant super
09:55fast you also want them to be
09:56sustainable like you don't want to run a
09:58super computer right and I think a lot
10:00of the a lot of the negativity around
10:03certain chains is that effectively their
10:05node requirements are too high and
10:07they're running what is effectively like
10:08a supercomputer and there's no plan for
10:10exactly how they're going to manage the
10:12database of those systems how they're
10:14going to manage the state access of
10:16those systems so they're very
10:17contentious and they're they're very
10:19large um and then as well you have to
10:22manage for interoperability which is
10:24really a new thing you want blockchains
10:26particularly rollups to be able to talk
10:28with each other and you you want them to
10:30be able to introspect each other and you
10:32want to be able to go over on one rollup
10:34make a swap go over to another do some
10:36lending come back and do another swap
10:39probably have that happen in a very
10:40short period of time or in the same you
10:42know block for example so you want to be
10:44able to do these things so we want to
10:46solve for these particular problems
10:48right and unlike sort of traditional
10:51problem solving that you've seen in the
10:53space um you know you actually want to
10:55solve for all three so uh this is what I
10:58sort of described for as like the rollup
11:00trilemma which in the blockchain
11:02trilemma where it was like
11:04decentralization security and
11:06performance which is like a little
11:07different where they were like picked
11:09two you know in this case I'm going to
11:10say you actually want all three and you
11:12just want them so you there's no there's
11:15no pick two here it's just pick all
11:17three or or nothing basically so you
11:20want rollups to be super fast you want
11:22them to be sustainable and you want them
11:24to be interoperable um and you know in
11:26the state of the architecture nowadays
11:28like everyone wants all these things so
11:30for this I call it the rollup
11:32trma um and to look at sort of the
11:35landscape what's happening in the space
11:37and I'm sure you guys have covered this
11:38with a lot of the modular stuff you've
11:39done um there's the landscape is like
11:42rapidly evolving right now so there's
11:44tons of different execution environments
11:46there's tons of different sequencing
11:47options tons of different proving
11:49options um lots of different data
11:51availability layers uh and lots of
11:53different settlement layers so there's a
11:56crazy phenomenon happening where if you
11:58are building a blockchain as a rollup
12:00you've got crazy amounts of options
12:02happening right and all of these will
12:04touch or interplay with um effectively
12:07these things right like depending on
12:08what you pick depending on how you go
12:10about it it's going to affect any one of
12:12these things right so we've got this
12:15wide landscape of things happening and
12:18obviously for a developer this is going
12:20to be pretty daunting right and like
12:22there's a lot of issues here in just
12:24what do I pick and how do I navigate
12:26this space right so there is sort of a
12:28need to bring some clarity and some
12:31Harmony around how this is all going to
12:33work and what people can actually do
12:35with all this stuff so a helpful analogy
12:38here is um we actually saw similar
12:40things happen with Computing and also
12:42like the early internet so you can think
12:44about different pieces of the stack is
12:46sort of different things that you would
12:48do with the system so you know some
12:51tasks are more like CPUs some tasks are
12:52more like networking some task are more
12:54like GPU some tasks are more like
12:56storage and some task more like iio and
12:59we've got users and we've got
13:00applications and typically um how we've
13:02dealt with this in the past is we've
13:04built operating systems so operating
13:06systems are this sort of low-level code
13:09that helps us just deal with all of
13:12these different things right they help
13:13us manage all this stuff so that when
13:15users are using applications um they're
13:18not thinking about like you know oh my
13:20CPU is too slow or you know I don't have
13:22enough storage the users are just using
13:25applications in the space right and so
13:28similarly we think of the rollup problem
13:31as a very similar issue right where
13:33effectively you have users you have
13:35applications and you need some kind of
13:37operating system to really bring
13:39everything into order and design for all
13:42the problems that we currently see in
13:43the space right and do you know the
13:46right thing and so um this is where we
13:49kind of get into a little bit more about
13:51Fuel and what it is so fuel is really an
13:54operating system for the rollup
13:56landscape and for the rollup space
13:59so fuel brings a lot of things to the
14:01table in terms of our virtual machine
14:03our networking our proving or as well
14:06the way that we do da adaption um and
14:09the idea is just that similar to how
14:12computers and Hardware have an OS right
14:15that deals with you know all the
14:17different tasks that your computer has
14:19to deal with our Ro of os does something
14:21very similar which is basically just
14:23trying to say hey like um you know
14:25you're going to need proving you're
14:27going to need really you know a c kind
14:29of state transition that works really
14:30well for for blockchain you're going to
14:32need bridging you're going to need
14:33sequencing you're going to need all
14:34these things um you know we will come in
14:37and we will harmonize all these things
14:38for you right and so in this sense what
14:41fuel's always trying to do is give you
14:44the right tool for the job so something
14:46that's really going to come in and solve
14:47a lot of these issues that we experience
14:49in the space um and also just design
14:52things that are more harmonious with the
14:55the current landscape and the current
14:57space so we say this solution is really
15:00rollup OS itself um and so you know to
15:04cover some of the things that um we kind
15:06of bring to the table here in terms of
15:08the modular landscape itself um so fuel
15:11has the fuel virtual machine we have a
15:13unique proving model is hybrid proving
15:16as well we have da adapters that you'll
15:18be able to use to select whatever da
15:21layer you want as well we have a very
15:23unique set of tools that allow you to
15:25build applications in a way that the
15:27space doesn't really offer and then as
15:29well we have a network so a network of
15:32different rollups that can interoperate
15:34with each other and basically um you
15:37know address a lot of the current
15:38problems that we see in the space in
15:40relation to in operation so to talk
15:44about some of the virtual machine and
15:46and sort of how this works so the fuel
15:49VM um really it it packs a a big punch
15:53and it's really is well influenced and
15:56informed by all the previous virtual
15:58machines that we seen in the space so
16:00whether it's the salono VM move VM the
16:02evm wasum all these different VMS that
16:05we see in the space we basically
16:08educated the design of all of those
16:10things into a single virtual machine so
16:13we have a very highly performant sort of
16:1564-bit uh virtual machine um it's
16:18capable of doing a lot of transactions
16:21so you know something like right now at
16:23least and it's unoptimized currently so
16:25around 12,000 TPS per core on ethereum
16:28if we're fully optimized with da
16:30compression something like 5,000 TPS for
16:32for transfers so it can do a lot of TPS
16:35quite frankly um as far as the way that
16:38it works um Fuel and the fuel VM uses a
16:42utxo model so um you know if you've ever
16:46looked at or seen Bitcoin before it's
16:49something similar to that but ours is
16:51much more advanced so really we have you
16:54know a utxo model but it works over not
16:57just coins like in Bitcoin but it also
16:59works over contracts so you get all the
17:02same things that you can do with the evm
17:04but you get this really unique um sort
17:06of State access system um that allows
17:08you to use both coins and contracts
17:11together in in a single transaction and
17:13you can do many and you can do many
17:14different types with many different
17:16people owning many different things so
17:18it's a really sophisticated transaction
17:19model in and of itself and on top of
17:22that you can do things like scripts uh
17:24which we don't really have with ethereum
17:26right now and as well you have things
17:29like accounts uh which are predicated
17:32accounts so these we call like spending
17:35conditions and this enables you to do a
17:37whole crazy host of things but um before
17:40we get into that um happy to like pause
17:43here in terms of like fuel virtual
17:44machine stuff and like we could talk
17:46over that if we need to before we get
17:49into the into the VM I've got a question
17:50about the utxo model versus the account
17:53model like sure my understanding was
17:55that Bitcoin wasn't able to have Smart
17:57contracts because they have the utxo
18:00model so how are you able to get smart
18:02contracts using this utxo model what is
18:05your general thesis on why you chose
18:07this model yeah so I I think that the
18:11utxo model got a very bad WP both from
18:13Bitcoin and from cardono so basically a
18:16lot of the things that were said about
18:17it are not related to the utxl model but
18:21just the way the system is constructed
18:23and thus this huge problem happened
18:25where effectively the community blamed
18:27utxos for something that they didn't do
18:30and then uh you know we kind of had this
18:33Divergence but all utxos really mean is
18:36that you're just defining what areas of
18:38State you're going to touch right
18:40however you want to Define that and then
18:42you're going to produce something and
18:44you're just going to say hey I've
18:45changed all these different things right
18:48so when you look at the inputs here
18:49you're just saying hey I'm touching
18:50these coins and I'm touching these
18:52contracts there's nothing crazy about
18:53that but that's actually the utxo model
18:56and then when you have outputs you're
18:58just saying hey I'm going to you know
19:00send these coins here I'm going to
19:02change these contract State here there's
19:05nothing crazy about that and there's no
19:07Divergence from the ethereum experience
19:09of smart contracts or anything like that
19:11so you really get to have everything you
19:13ever wanted with the utxo model with no
19:16downsides um quite frankly the only
19:19downside is that maybe it can use a
19:21little more data sometimes um but quite
19:24frankly that's worth it because you want
19:26to Define when you're processing
19:28transactions it's like hey these this
19:30group of transactions touches this over
19:31here this group of transactions touches
19:33this over here right and then you can
19:35say send this to thread one send this to
19:37thread two right and so when you have
19:40that it makes processing super simple
19:43and so um you know the utxo model got a
19:45very bad rep uh but quite frankly it
19:48does nothing in the way of a transaction
19:51other than just trying to say hey I'm
19:53touching these things now there's some
19:55subtleties right cardano implemented too
19:57much determinism so they basically
19:59couldn't build Unis swap because Unis
20:02swap has this contentious State that's
20:04like you know the amounts in the pool
20:06and you don't know what the final
20:07amounts are going to be when you're
20:08making a transaction it's settled later
20:11by U the block Builders right so
20:14effectively it creates this huge
20:16contention and you know you can only
20:18make like one transaction per block per
20:20app or some crazy dumb thing like that
20:22now we just didn't design it that way so
20:25we just designed it with the similar way
20:26ethereum does which is basically just to
20:28say hey like you know if you're touching
20:31this contract um then basically you can
20:34have five six different people touch the
20:36same contract we just order it and line
20:38it up in such a way that um you don't
20:40need to know the final state of things
20:42until later on anyway so there's no
20:45contention there basically even if you
20:47touch the same contract so so
20:49effectively the utxl model gives you
20:51what you really want which is u a state
20:54access list of what you're touching in
20:55state um and so um similarly with
20:59predicates um predicates allow you to
21:01then take these things like coins here
21:04and then basically do like what would be
21:07considered maybe a count abstraction
21:09over those coins and you can just Define
21:11like what are my spending conditions and
21:13a lot of the time you don't even need to
21:16use Smart contracts at all um you can
21:18just use predicates and use these
21:19stateless scripts and you can imagine
21:22that like right now we're processing
21:25maybe 50 to 500,000 people's
21:29daily with blockchain right but imagine
21:30if you had the whole world running
21:32through these chains like the entire
21:34world right billions of people you can't
21:36have contentious State like you
21:38basically you would cause it' be way too
21:41difficult um for the system to have to
21:43comprehend all these things you wouldn't
21:45want someone in India holding you up
21:48when you're making a transaction in you
21:50know like Germany right like it just
21:52would be awful so you want to try to
21:54break away from using stateful smart
21:56contracts and you want to go to things
21:58that more lighter they're easier to
22:00process they're easier to handle and so
22:02predicates give us that ability to to
22:05kind of do this um and basically in the
22:08next slide just covering some of the
22:10crazy things we can do with predicates
22:12but and again this is without Smart
22:13contracts we can do things like multisig
22:16BLS aggregation social recovery we can
22:19support any wallet so metam Mass Phantom
22:21secure Enclave we can do things like fee
22:24payers so basically you know pay gas and
22:26any coin you can set settle really
22:29complex trades right um you know really
22:32complex trading conditions as well um
22:34you can settle really complex intense
22:37right um and the idea is that because
22:40we're designing for things like
22:42sustainability we wanted to opt in these
22:45kinds of designs to say developers
22:47really want these things they actually
22:49want to build better systems that are
22:51more sustainable they're lighter they're
22:53easier to manage they're easier to
22:54maintain so predicates are really a part
22:57of that for us in our virtual machine
22:59design um so I can pause there but um
23:02yeah hopefully that answers your
23:04too yeah it does and this is a a special
23:08result of the fuel VM that you get both
23:11the the utxo model and the predicates
23:14yeah it's basically everything coming
23:16together into one really nice package so
23:18we're taking the best of Bitcoin we're
23:19taking the best of um basically uh move
23:23you could say the best of a lot of these
23:25different blockchains and putting them
23:27into one architecture and making that
23:29into something that um is actually
23:31pretty special so so this is on the
23:33virtual machine side so just touching on
23:35some of the things there is way more
23:37stuff in the fuel VM but you know just
23:39wanted to touch on a few things um to go
23:42into more of the proving side so um
23:45basically fuel uses what we call like um
23:47it's like an optimistic and ZK hybrid so
23:51essentially um we combine both
23:53techniques together where if you have an
23:55invalid block you just submit it to a ZK
23:57proof if it proves that the fraud is you
24:01know uh is there then you just remove
24:03that block but you just keep producing
24:05new blocks from the most recent valid um
24:09block and so the system really never
24:12stops um but effectively you have this
24:14much easier way to prove that a block is
24:17invalid this also gets the fuel
24:19architecture ready for ZK um which we do
24:22really like but we're just using a
24:24little more pragmatically especially if
24:26our system's going to be doing you know
24:28you know 12,000 TPS per core for example
24:31that's one core so one core in your M1
24:33can do 12,000 TPS now if you do eight
24:36you multiply that by eight right now to
24:38do that same work over a ZK requires
24:41like lots of things like a crazy amount
24:44of stuff and warehous yeah a warehouse
24:47now mind you that might work for certain
24:50things and that might be totally fine
24:53for certain things and asex and other
24:54things are going to come all kind kinds
24:56of crazy stuff but for now fuel is more
24:59pragmatic about how we want to use
25:01proving in ZK so for us like we'll use
25:03it right now when things are invalid
25:05eventually maybe as they get more
25:07efficient we'll use it for when
25:09everything is valid um so basically just
25:12using the technique in different ways
25:14but yeah the idea is we have a much more
25:16simplified game it's a single round game
25:18and when there's an invalid block just
25:20prove that slash the block keep going so
25:23this allows us to do a few things like
25:25we can reduce eventually uh bridging
25:27time down um and as well I also released
25:30a paper on uh or re research on what we
25:34call fast finality optimistic rollups
25:36which effectively can get the finality
25:39of an optimistic rollup down to
25:42potentially even one ethereum block if
25:44you have the right kind of design in
25:46there so so essentially um we have lots
25:48of different ways to make optimistic
25:51rollups into the system that we really
25:53want to see um but ZK is playing a role
25:56for for us in multiple different ways um
25:58so um so yeah that's just like a you
26:01know I can pause here as well but um
26:04yeah happy to go into I got a question
26:06here too and your answer might just be
26:07go read the paper but like it is is one
26:11way to think about this essentially that
26:13it's an optimistic rollup and then
26:15there's a fallback to ZK in the case of
26:18uh essentially that that s-day dispute
26:21window that no one really likes no one
26:22really takes the canonical Bridge
26:24because it because of that s-day dispute
26:26period um you basically have the
26:28optimistic settlement on the L2 and then
26:32in in that case where you're either
26:34going back to the L1 or in the case
26:36where someone calls dispute that's when
26:38you fall back to this ZK uh proof to
26:41prove that the the fraud is there and
26:45re so let me um describe a few different
26:48things so with this there's a lot of
26:50nuance um so basically the way to think
26:54about the 7-Day window um is sort of it
26:57actually doesn't have a lot to do with
26:59the mechanism itself so whether you're
27:00using this CK dispute prover or you're
27:03using just a pure ivg model like what
27:06optimism is implementing or or arbitrum
27:09the 7-Day window is really just you're
27:11trying to give enough time to submit a
27:14transaction to say hey there's something
27:16wrong and then you go through the whole
27:18process of the game right but
27:20unfortunately the way that ethereum's
27:22designed um you know if someone just
27:25fills up ethereum blocks for a long time
27:28um and you make that window Too Short
27:30then basically you have this big issue
27:32where like you can't get in the flag
27:35transaction to say like hey there's
27:36something wrong you can't get it in so
27:38an attacker a smart one you know could
27:40basically attack all these systems right
27:42um so this mechanism uh is just trying
27:45to simplify the s-day window down um
27:49sort of in a sense of we know we can
27:51probably safely get the window down to
27:5324 hours um regardless of the mechanism
27:56just to try to do that um but the
27:59finality post that I made is actually a
28:02little different the finality post um
28:05takes the optimistic rle up on its head
28:06and it sort of says well um instead of
28:10trying to submit a transaction only when
28:12there's fraud what you do is you have
28:14everyone submit constantly that they're
28:18things are okay and if one of those
28:19transactions is missing then you know
28:22that there's actual fraud and you start
28:23expanding the window passively so you
28:26flip it on its head and then that way um
28:28a censor can't censor you so it's an
28:31interesting post it's definitely going
28:32to be part of our sort of finality model
28:35uh for offering um fuel rollups um but
28:39the idea is just that when you flip it
28:41on its head you no longer have this
28:43censorship is issue because you're
28:45basically saying if there's a missing
28:47transaction then we assume censorship
28:49and the window just passively expands up
28:52to something like seven days so
28:54basically um this allows us to do some
28:56pretty wild stuff like you can have many
28:59different optimistic rollups that are
29:01coming to finality effectively like a
29:03soft finality um just so long as
29:05everyone checks in um all the different
29:08validators in the pool check in um so
29:11it's a slightly different model U to
29:14what's described here in the sense of
29:15this is just for voting and progressing
29:17state but um the whole idea is just that
29:21um the combination of these techniques
29:22can allow us to really significantly
29:25reduce um the finality time optimistic
29:28rollups which was a huge burden before
29:31because it was like you know you want to
29:33deploy an arbit from lirer 3 well you
29:34got to wait seven days to withdraw to
29:36that right it's like that sucks you know
29:38but now actually with fast finality
29:41optimistic rollups and as well using
29:43things like the ZK techniques you can
29:45simplify the actual game and you can
29:47lower the finality window so um I didn't
29:50really cover that too much on this
29:51because it's still sort of like active
29:53research but the idea is just to say
29:55that um we have the ways now to do a lot
29:57of different really cool things um and
30:00uh and as well even that other technique
30:02does use ZK so it's not to say like gets
30:05rid of ZK it's just to say we use it
30:07slightly differently than ZK rollups
30:11yeah um yeah so that's on on that point
30:14but there's sort of a difference between
30:16the proving mechanism versus like the
30:18finality window and the challenge window
30:20and that sort of stuff like they're kind
30:23yeah um cool uh so in terms of da um as
30:29well like fuel will aim to support all
30:32of the common da layers that you see so
30:35um our first one's going to be 444 da
30:37but of course we'll allow for options
30:39for Celestia and ail uh igen da near da
30:42all the other kind of Da layers that are
30:44out there um so we'll have full da sort
30:47of adapters for for all these things um
30:50right now we just got to focus on
30:51ethereum uh as we get our first layer
30:53two out um but we'll allow for these
30:55other da options after
30:58on the tooling side um we also have our
31:01own language we have our own tool chain
31:03called fork and we have our own uh
31:08essentially um this problem of like
31:10having to go between five different
31:12tools or all these different you know
31:13pieces of infrastructure Etc um is now
31:16completely simplified so when you have
31:18your own language it also means you can
31:20do everything you can do testing you
31:22deployment you can do indexing you can
31:24do everything with the one language um
31:26so sway will really be sort of the
31:28ultimate blockchain language that that
31:30people can use um and Fork will allow
31:33you to do it all in one tool chain so
31:35you don't need to have five six
31:37different tool chains you can deploy an
31:38app with that you can deploy a rollup
31:40with that you don't need to go anywhere
31:41else as a as a developer sort of answers
31:44all your questions and then as well for
31:46fuel infra all these other things like
31:49um providing really rapid um soft
31:51confirmations providing all kinds of
31:53different data and streaming
31:55infrastructure all the things that you
31:56typically see with blockchain but
31:58providing that for a very high
32:00throughput chain so doing it for the evm
32:02is one thing it's like 15 TPS doing it
32:04for something that could do you know
32:07thousands of TPS it has to be designed a
32:09certain way so um we try to provide all
32:12the necessary tooling and especially
32:15with our language and you know um all
32:17the different attacks you typically see
32:19uh with solidity and everything else
32:21it's nice that you have a different
32:23blockchain language that tries to
32:24address some of these problems um so on
32:26the right is all of the reentrancy
32:28attacks uh that have happened on
32:30ethereum it's not all of them too it's
32:32just a it's just a section of them uh
32:35and then uh on the left is a smart
32:38contract with re-entrancy inside of it
32:40um so naturally you know when you're
32:43designing a language for a blockchain
32:45you want to address some of these things
32:46and sway does um and sway brings a much
32:49simpler kind of system or interface to
32:51the to the table so full standards being
32:54available for everything as well like
32:56re-entrancy prevention is provided in
32:58the standard Library itself and just
33:01bringing in all the new things that we
33:03know about language design into the
33:05table like traits and all this other
33:06stuff so it should be a very fulfilling
33:08language for developers to use and
33:10something that they can be really
33:12productive in really really quickly um
33:14Nick real quick on the sway part uh
33:17forgive me for my lack of programming
33:19knowledge but isn't creating your own
33:21language risky and also isn't it just
33:24recreating the same problem of solidity
33:27where it's like users have or devs have
33:29to go and learn this entire new language
33:31and kind of start from scratch versus
33:33something that they may already know
33:36yeah so I think there's a few points to
33:38that so so one is that it's not
33:40inherently that solidity is bad because
33:42it's blockchain language uh in fact I
33:45think that's one of the best things
33:46about solidity is that it is designed
33:48for what it's for now mind you because
33:51of the way the evbm is constructed
33:53because of the way solidity works
33:55sometimes it's really hard to pick up
33:56things like rency with it and as well
33:58the language was designed iteratively
34:01over time with many different code
34:03maintainers so it kind of succumbed to a
34:05lot of like grammatical complexity that
34:07it might not have needed to um but
34:10solidity actually its problems are
34:14basically that it didn't have other
34:15great languages to look at and I think
34:17rust was still a developing language at
34:18the time so it couldn't really model
34:21itself after something really strong now
34:23on the flip side if you do use rust to
34:25make smart contracts it's also horrible
34:27in a different way so when you use rust
34:30or C to write a smart contract those
34:32languages were really designed for
34:34systems like they were designed for
34:35systems programming right and when you
34:38use something again that's not designed
34:40for what it is you end up with this like
34:42super Band-Aid mess where like sway
34:45right now looks like it's only you're
34:47only writing what you really need for
34:49your smart contracts you're only
34:51defining and setting things up for
34:54exactly how the thing works with rust
34:56that's like you have five million
34:57different annotations you have like 10
34:59different ways that you need to
35:00constrain the system just to make it
35:02work properly and that's because it's
35:05not really designed to build smart
35:07contracts it can but it probably isn't
35:09the best tool so sway tries to mediate
35:12between all the things we learn from
35:13solidity all the nice things we learn
35:15from Modern programming and rust and it
35:17tries to give that to a developer and
35:19quite frankly learning sway is going to
35:21be really easy for someone with solidity
35:23because you have things like um a
35:26blockchain language that's designed for
35:27things like storage and abis and
35:29everything else so that'll be very
35:30familiar to a solidity Dev like they'll
35:33look at this and be like takes two
35:35seconds and as well similarly with Russ
35:37like they'll be very familiar with the
35:39syntax and the uh intention of the
35:41language so effectively you might think
35:45yes it is more risky but actually all
35:47we're doing is bringing the best stuff
35:49from what we saw with previous
35:51blockchain languages the best stuff from
35:53rust and trying to bring that to a Dev
35:55in a way that um you know makes a lot of
35:57sense and is actually designed for the
36:00job of building these smart contracts so
36:03yeah are there uh trans compilers that
36:07like if I want to write it in solidity
36:08or rust or hypothetically even if I
36:11wanted to write something in like
36:12natural English language like it'll just
36:14kind of translate over so um I really
36:19shouldn't do this but I could share
36:22something if you want to see something
36:25yeah uh okay let me see if I can share
36:27my screen real quick so this we haven't
36:31released yet um but you can use it right
36:34now let me just present my screen for a
36:37second um okay so here's sway playground
36:41so this is actually public um you see my
36:45screen yeah yeah okay so you can
36:48actually just hit this solidity Tab and
36:51we actually have these full
36:53transpilation demos now so you can fully
36:55transplate here's solidity on on the
36:57left here's the sway on the right and
36:59again this is more educational so here
37:01I'll pick an E20 token so you can see
37:03like sway is actually pretty nice
37:05language in the sense that because we
37:07took these nice things from solidity we
37:09actually have a much easier time
37:11transplating the logic over um so this
37:14we haven't launched yet so I guess just
37:17don't bring it up too much in the tweets
37:20um but uh but yeah this is really meant
37:23to try to train solidity devs into sway
37:25really quick right and make that process
37:27super simple um so so anyway um and
37:31we'll have a lot more really Dynamic
37:34translation um later as well so uh it'll
37:37only get better from here and as well we
37:39also want to have sway Target other
37:42backends so there's all kinds of
37:44blockchains that could really benefit
37:46from a frontend like sway basically um
37:49so like Aztec or or miden um it's really
37:52hard to build a language so we we spent
37:55a lot of time on this so basically I
37:57think could benefit from it if we could
37:58get it to to work so anyway that's um
38:01maybe a sneak peek um but yeah yeah so
38:05you can you can take a look at that
38:06that's like sway playground. org um cool
38:10okay oh any other stuff on sway or next
38:14good so um so the last thing which is
38:17also a little bit of alpha is um we
38:21actually are putting together a
38:22sequencer for fuel too and the sequencer
38:25allows for um the sequ saying of um both
38:29block production and transactions over
38:31many different rollups so the idea is
38:33that um fuel has a very special virtual
38:36machine and has a very special kind of
38:38transaction system and we can really
38:40create a lot of interesting advantages
38:42with this at the sequencing level where
38:44blockchains can really actually look at
38:46each other and talk to each other if
38:48you're putting the transactions in the
38:49same funnel and so um so fuel will have
38:52its own sequencer but we'll always allow
38:55people to pick the sequencer they want
38:56so if they want to use this espresso
38:57they want to use a combination of like
38:59espresso and fuel sequencer they'll be
39:02able to do things like that um and so
39:05effectively we want to give people as
39:06many options as possible but we also
39:08want to offer our own selfishly because
39:11we think we can offer a lot of really
39:12interesting design patterns in value so
39:15basically um you know when it comes to
39:18you know producing uh blocks for
39:20different rollups you would have the you
39:22know transaction go to the builders the
39:24builders um are then going to either via
39:27an auction or depending on how the
39:29rollup setup you know many different
39:31models are then going to decide um the
39:34sequence um and then that basically goes
39:37into uh execution and um gets passed off
39:40or it gets passed off into um just going
39:43down the bridge um back to ethereum so
39:46um this diagram is not the best diagram
39:48because it goes from sequencer to rollup
39:50but the point is just that um um
39:53contextually speaking you can have um
39:55these fuel Builders they could build for
39:57potentially different rollups um and um
40:00you know you'll have sort of
40:02a a system in which rollups can not only
40:06have blocks being built for them but
40:08also they can interoperate so the
40:09rollups can see each other and they can
40:11introspect each other which is something
40:13that um you want to do as fast as
40:16possible and you want to do um basically
40:19at the earliest possible stage and so
40:21with fuel you can have um two different
40:24rollups that are basically looking at
40:26each other's block Construction they're
40:27looking at each other's block design um
40:30and then they're basically like filling
40:31in different information from different
40:33chains um and given the way that
40:35predicates work and other things in in
40:37our virtual machine design um you can
40:40basically have things like trades that
40:42settle when certain trades happen in
40:44different chains you can have all kinds
40:46of sort of instantaneous interoperation
40:48going on and when you mix these models
40:51with things like our fast finality
40:52Gadget you get this really crazy sort of
40:56system of rollups that we just haven't
40:59really seen yet because we've been
41:00working with the evm we've working with
41:02move and you know these VMS are not
41:05really designed in this way so for fuel
41:07because we design it from the beginning
41:09this way in operation is going to be
41:10really smooth and the sequencer is going
41:12to help with that process um gotcha real
41:16quick there if you don't mind yeah um
41:19the the big like sequencer situation is
41:22you know why use decentralized shared
41:24sequencers if you're rollup operator why
41:26give away all your Revenue espresso is
41:28like no you don't have to asri is like
41:30no you don't have to no kid Etc so that
41:33problem is kind of being solved by the
41:34shared sequencer level in a sense at
41:36least being thought of and iterated on
41:38when it comes to fuel sequencer what is
41:40going to be the financial or economic
41:43situation between rollup operators and
41:45fuel um kind of Dow or however we want
41:49to Overlay that yeah so so I think with
41:53sequencing um there's a few different
41:55things so most blockchains are not
41:57dealing with what fuel's model is right
42:00and so they're not really set up for
42:01that now they might say they are but if
42:04you ask someone like Josh they'll be
42:06pretty honest with you and be like we're
42:07mainly doing the evm right now right
42:09which means that you know for a new
42:11architecture like fuel it's pretty rough
42:13to actually get the kinds of things you
42:15want inside of a sequencing environment
42:17right and secondly sequencing can happen
42:21in a more additive way so when we
42:23decided to go down the route of doing a
42:25sequencer we know that um we probably
42:28could at different stages tap into other
42:30sequencers for different things um and
42:32so I actually think that sequencing can
42:34happen over a bunch of different layers
42:37and not just have to happen through
42:38through one specifically but moreover
42:41there's a lot of different kinds of
42:43design that we wanted to do with utxos
42:46that are sort of settling in a stream
42:49format you can say so long before it
42:51ever gets to you know ethereum or like a
42:54final settlement layer almost at the
42:57meol level there's kinds of Trades and
42:59settlement happening via utxos and Via
43:02predicates and that's something we
43:04uniquely can can Advantage right so for
43:07fuel as we build out our architecture we
43:09want to really be able to have apps and
43:13uh devs really advantage that because
43:15it's really the fastest kind of trading
43:18the fastest kind of transactional design
43:20you can possibly do right it's way
43:22before it's almost even in a blockchain
43:24you're already settling things you're
43:25already moving things around right like
43:27as high frequency as you can get it so
43:30the reason why we wanted to do our own
43:31sequencer is because we wanted to really
43:34um you know show out show off you could
43:37say all the different things that fuel
43:39can do um but also because at a very
43:42basic level we just want to decentralize
43:44our block production and quite frankly
43:47um you know for the kinds of
43:48architecture that we make and we we
43:50build we'd prefer to be able to tweak
43:53that pipeline so that devs get the best
43:55experience users get the best exp
43:57experience and of course we'll always
43:59offer other sequencers as you try to
44:01deploy rollups so you don't like it you
44:03want to use espresso or asria go ahead
44:06you know I think it's just we we want to
44:09um really have the best Showcase of our
44:10Tech so maybe that's the answer
44:17awesome so um what I got I only have a
44:20few more slides left so it's h it's it's
44:22closing out um but uh but yeah so to
44:26kind of it up um you know we have a
44:29whole Suite of tools we have a whole set
44:31of architecture um for you know rollups
44:34themselves all designed to really meet a
44:36lot of the problems that you see in the
44:38space um and basically we try to address
44:41a lot of these problems with um just
44:44good design whether it's like
44:46performance where we have the VM and the
44:47transaction model or sustainability
44:49which is more in the transaction model
44:51in the predicates or interoperability
44:53which is like the transaction model in
44:54the sequencing we try to provide the
44:57developer um really comprehensive
44:59operating system to really build
45:01incredible rollups and ones that can you
45:04know scale they can perform really well
45:07and they can also be very very
45:08sustainable um and you could just
45:10imagine systems both like conduit and
45:13also um something like fuel is a service
45:15where you just select the sequencer
45:17select your GA layer select you know
45:19your proving model deploy it's done and
45:22you have you know rollups that can do um
45:25you know 12,000 DPS per core so it'll be
45:28a pretty wild reality for for for that
45:30and it's already starting to happen with
45:32other architectures and really between
45:34these different these different tools
45:35these different ideas um we want to
45:38really comprehensively solve a lot of
45:40the problems that we see in the space
45:42with again good design good architecture
45:44um and yeah that's basically uh
45:47basically end of presentation yeah well
45:50you better watch out because Josh is
45:52coming for all the RAS providers so FAS
45:55has got a got a hotthead for him I uh I
45:59believe it but uh you know I I know all
46:02of Josh's weaknesses so it's it's okay
46:04uh we we every time we we meet at a
46:08conference we have a good good
46:09conversation so yeah good man we really
46:12appreciate you coming on and um giving
46:15us a live demo a full um conversation
46:18and answering some of our questions for
46:20sure and um yeah I guess the last
46:23question that that we have which
46:25everybody has for for you and fuel is
46:27Wen when yeah so um soon TM uh and you
46:35know like if you're if you go back into
46:38like old ethereum uh folklore uh it's
46:41like two two weeks TM is the is the
46:44statement so you know yeah they said two
46:48weeks TM and it took them another eight
46:49months so something like that so
46:52somewhere between two weeks and eight
46:53months sounds sounds plan yeah all right
46:57thank you man awesome all right thanks
![Welp, Here's what the Fed *Just* Said [Fed FOMC Minutes]](/_next/image?url=https%3A%2F%2Fi.ytimg.com%2Fvi%2Fl8u23oq1E9E%2Fhqdefault.jpg&w=3840&q=75)
