[Music]
kind of I mean it's fine but since
we okay yeah very good afternoon to all
of you present here so have we have
reached the final day of Devcon we have
had like 10 different uh talks on
pre-confirmation three full scale events
and the only question that I've been
getting is how do you make all of this
like Fast transaction confirmations yeah
yeah we get it but how do you make this
so yeah now on the last day uh welcome
to the workshop on designing an end2end
system for based pre-confirmation
a quick introduction of the speakers uh
Ahmed go ahead yeah um so my name is
ahed B I work as an ethereum core
developer normally I'm also the product
manager of Surge and the technical lead
for our pre-confirmation
solution and I'm Anu I am working as a
blockchain engineer at nethermind and I
joined this industry like 5 years ago
mostly focused on dii but for the past 6
months uh my efforts have been mostly
concentrated on Bas precon
confirmations so today this session is a
no code session so I won't be like
writing a line of code and then asking
you to copy it and repeat it like 100
times over I know most of you will leave
in like half an hour if I do that so
instead this is a session on design
thinking where we'll build the whole
concept from ground up and share exact
what exactly we did during our research
over the past 6
months but if you are interested in
looking at the code then I have linked
it below it's Tao precom AVS repository
which you can find on the neine GitHub
page
so since we want to build it all up from
ground up we have to start with the
foundational knowledge which is rollups
because the based in in based
reconfirmations comes from based
rollups just by show of hands how many
of you do understand what a rollup
is okay pretty much everyone that's
great well rollup is a scaling
solution and why do we need a scaling
solution we need a scaling solution
because the L1 is is really slow the
throughput of L1 is not much and why
exactly is that the case well in a
blockchain blocks are basically a
consensus on state transition that's the
first section of the ethereum white
paper you have state a you put a bunch
of transactions and apply it to State a
which is like a Delta and you get a
state
B but now imagine millions of nodes
doing this every single Epoch now that's
going to make this network really slow
and that's a major
problem so what's the rollup way of
doing it well if processing State
transitions is the biggest issue on the
L1 what if we process these State
transitions off chain or apply these
Deltas off chain and that's exactly what
a rollup does we have like you can have
a one single rollup node or an L2 node
since it becomes a lay to that applies
applies this Delta of chain processes
the state transition and the L1 is just
an observer on the L1 you have a rollup
inbox contract and you simply push this
state transition and the Delta maybe as
a form of a blob or in the call data in
the image it's a blob and the L1 is just
an
observer and in the most basic form this
is what a rollup
is but is this enough well no because if
it's just one note pushing the
transition and the Delta how do we know
whether it's actually correct correct or
not and this is where the flavors of the
rollups come in optimistic and ZK in the
case of an optimistic rollup well you
push the state transition and the Delta
and then you just wait you just wait for
someone to prove you incorrect if you're
correct it's it's all good but someone
can just come by and say oh hey it's a
proof here's a proof this transition
that you posted is not possible with the
Delta that you posted and then you kind
of get slashed if you have some stake in
depends on uh what kind of process the
rollup wants to
do and arbitrum is an example of an
optimistic rollup I guess most of you
must have used arbitrum and then we have
ZK rollups in the case of ZK rollups
instead of waiting on for someone to
prove you incorrect the moment you push
the transition and the Delta you have to
prove that this is
correct so it's called a validity proof
you're basically proving the validity of
the
transition but the point here is that
what whatever time or computational
effort it takes to verify this validity
proof must be less than what it takes
for the L1 itself to process all the
data only then it actually makes sense
right so these are the two variants for
proving whether a transition is correct
or
not once again by sh fans how many of
you have heard of centralized
sequencing okay it's the most cursed
concept right now and just to give a
quick primer when you're making a
transaction on arbitrum you're not
directly sending the transaction to a
public mempool like when you're doing
when you are transacting on ethereum L1
instead it's going to an arbitrum
sequencer and it's a private server what
the sequencer does is it has complete
control over arranging or ordering the
transactions and they usually promise
that they will arrange the transaction
in a certain way we don't know whether
they're actually doing it or not but in
the case of arbitrium the promise is
that it's a first come first serve if
your transaction comes before that other
person we'll put your transaction first
in in the block but once again it's a
promise we don't know whether that's
actually happening or
not so let's get based and talk about
based rollups and pre
confirmations well the based part is
actually not a different variant of a
rollup so it it doesn't stand beside a
optimistic or ZK rollup instead based is
a form of sequencing just like we have
centralized sequencing we have base
sequencing and in the case of Base
sequencing the L1 proposer is the
sequencer you don't have a centralized
server sequencing the transactions
instead it's the L1
proposal let's say we have Tao Tao is a
based rollup and in the case of Tao the
L1 proposal literally runs a tao
software alongside the usual consensus
and execution clients and whenever their
block comes in they literally just put
pull the blocks pull the L2 transactions
from public Tao M Pool they order it in
their L1 block and put it on the network
so yeah you basically are inheriting the
L1 security as well as the L1 liveness
because the L1 itself is your
sequencer so just a quick overview of
how Tao actually is arranged well you
have the rollups inbox contract that I
have been talking about and although Tao
doesn't really call it rollup inbox uh
this is the colloquial term Tao has like
a bunch of contracts that work together
and they just call it Tao L1
contract so that's the L1 component now
if you're running an ethereum validator
you usually run an execution client and
a consensus client right so in a similar
way if you want to run or be a part of
an L2 Network the proposer has to run an
L2 execution client or an L2 and an L2
consensus client so in this case Tao get
is the execution clant which is a
modification of the standard go
ethereum and this is where you have the
mempool you have the actual L2 chain all
the blocks are formalized and you also
have the evm on the L2 Network and then
we have the Tao client which has some
subcomponents and this forms the
consensus client and it deals with
proving the blocks and proposing the
blocks whenever
required now today the most important
thing for us are block proposals because
that's where the whole concept of
pre-confirmation will be built
upon so how exactly block proposals work
in Tao or in a based rollup so well when
you're making a transaction using any
kind of standard wallet it goes to the
meol or the public me pool which is
offered by
Tao and every few seconds or depending
upon what algorithm the proposer is
using transactions are feted from the
mempool and this transaction batch forms
the actual Delta and when you're calling
the RO up inbox contract you're
basically calling a function which is
proposed block and you're just passing
this Delta
along now you might be wondering well
that's the Delta fine where's the
transition so in Tao it's a two-step
process the Delta is gone and now we
have the Tao prover which comes in later
on and just says okay remember that
Delta that was pushed uh a few seconds
ago or few minutes ago you see this is
the transition that that Delta causes
and since Tao is a ZK rollup it pushes a
concise proof along with it like okay
this is the transition and this is the
proof that the Delta caused this
transition now the most important aspect
Tao
driver so once these L2 blocks are put
on L1 there is an block proposed event
that is released which shows that hey
okay this L2 block was put in the L1
contract and whenever that block
proposed event is released Tao driver
listens to it and advances the head in
get advancing the head basically means
you're formalizing and putting an L2
block within uh the L2 Network and this
is when the wallets end up getting the
transaction receipt or the
confirmation so you see the catch here
is that Tao driver only receives the
block proposed event every 12 seconds
that means when you're making a
transaction on Tao you get a transaction
receipt after 12 seconds which is huge
that's not ideal for a rollup or a
scaling
solution and that's very evident from
the DU analytics graph of Tao's block
times it's average between 12 to 24
seconds which makes sense it's
inheriting L1 block time that's not
ideal at
all so we need pre-confirmation and
pre-confirmation is not something new we
have already had it on arbitrum for a
long while and several other rollups
again show off hands how many of you
have transacted on
arbitrium and when you transact on
arbitrium you basically get a
transaction receipt like in a very small
period of time like half a second 1
second sometimes 2 seconds but the point
here is that arbitrum only posts blocks
every 2 minutes on L1 so how are you
getting this transaction receipt
immediately it's because that's a
pre-confirmation they're giving you a
promise that hey see this is the receipt
and we will be putting this on the L1
eventually in Tao you have to wait for
it to put be put on the
L1 but well this gives better ux for
arbitrum and bad ux to
Tao now what if we want to put
pre-confirmation on Tao it's really
tricky because in the case of arbitrum
we have one server literally one server
in one corner of the world just running
except ordering transactions providing
pre- confirmations easy in the case of
based rollups the sequencer is changing
every single slot the proposer changes
every single slot so well the sequencer
changes every single slot and then these
days we don't have the proposer building
the blocks the blocks are actually built
via a PBS pipeline like me boost by
flash Bots where Builders build the
blocks for you or for you as the
proposer and then you just propose the
block which which whichever Builder
gives you the highest bid you just take
their block and propose it you don't
even have any control over what's in the
block so how exactly will you put in
base prec confirmations with three
layers of
complexity well we have done it and
let's start with the design
principles maybe a quick round of
questions if anyone has any questions no
okay take it over all right great thank
you
um okay so the first thing we wanted to
do do was we wanted to not introduce
centralization again and the way we
wanted the um the idea here is that if
we wanted to do to introduce
centralization we wouldn't have built it
as a based rollup in the first place
then how are we going to solve this
complex problem so let me explain how
gateways work first so gateways are
basically centralized servers that
expose an RPC for the user to be able to
provide them the precom they the the
user sends the transaction to the RPC
and then it selects which uh which uh
transactions wants to precom and then it
it provides it to uh it proposes that
block to
L1 of course the confirmation receipt
that goes to the user is given like in a
matter of milliseconds between 100 and
200 milliseconds which is very fast of
course the ux is very cool but the
compromise is very
high now also like there is a another
concept here in pre-confirmation that is
important which is not all validator has
signed up to become pre-
confirms and because of this you
sometimes have some validators who have
uh decided to register as a pre- comfor
and some others that haven't registered
so the Gateway can provide
pre-confirmation for users and it should
it could it not necessarily will push a
block uh a propose a block for the L2 on
this slot but it could potentially push
it here and the way to do this will be
explained in a later stage when we talk
about um forc inclusion
lists all right the other thing that we
wanted to focus on which was important
for us is that we wanted to use the the
existing transaction structure the
existing wallet we didn't want to invent
a new um a
new a new like complexity to the to the
already existing situation when you are
sending transactions through
wallets um so some suggestions in the
precon space were like oh we should
potentially put an inclusion precom fee
premium so like what are you going to
pay P the promer to to to so he can
provide you with this fast service or
and the base fee per gas for that as
well or for example an execution precom
yeah it's it's basically very similar uh
to to each other like they're all like
the same so what we decided is no we're
going to choose something that is basic
so we're going to choose the same exact
EIP 1559 fields which is the priority
fee so the the priority fee pays for the
pre-confirmation the proposing and the
approving of that transaction and the
user does not have to worry about all of
these complex things other
things
okay it's not
moving
okay all right so I'll start now
explaining what we we
designed
so in Tao like explained we have the in
Tao we have that uh Tao client and we
also have Tao
G in Tao also we have before these
before we come to these we have the
contract that receives the block
proposals
and so so what we did is we added
uh something we call a pre-c confing
node and that sits between uh the
proposal and the contracts and we added
some contracts one contract is the
pre-confirmation service contract that
basically receives the blocks that are
coming from the promer and also um we
added a restake a reor staking contract
that will basically uh allow
the proposers to
register uh as a
preon and by this these proposers
whichever they are any validator can
basically just run this set of software
as a site car to uh whatever they're
running for the validator so alongside
L1 you're just running these three uh
basically uh these three um Docker
Docker Docker images Docker containers
and then you are able to precom
transactions when your slot is
up so what H how how does this exactly
work so we have a loop that happens
every 3 second when when when when you
are chosen as the pre-c comer for the
upcoming slot what happens is that you
as a pre confing node will Fitch the
transactions every 3 second from the tyo
proposer which will basically fit them
from
Tao the user will have sent this
transaction to the mle so there is no
centralizing aspect here you don't have
to connect to a specific AO to send that
transaction and every 3 second the
pre-con fer will sign this trans uh this
batch of transactions that it has
received from The Tao proposer and then
broadcast it to other pre confers
through P2P
oops
okay um okay permission okay so here we
we we we we look at okay so how do we
choose which of the registered prec
confers are going to be used or have the
right to propose these
blocks and this is when we use the look
ahead that is provided by the consensus
layer to know which exactly uh is the
proposer that has been registered in the
upcoming 6 uh 64 uh or like in the in
this Epoch and in the epoch after so in
consensus layer and Beacon chain you can
query the CL client for the existing uh
Epoch the current Epoch which which
which uh which proposer which validators
have the right to propose and for the
upcoming
Epoch um so it provides you with a list
32 uh long list of after you specify the
epoch that you want and so basically the
what we did is that we made the pre
precon node fix this list from the CL
client and push it to the
pre-confirmation
service and this way we know for example
that since this proposer is not
registered this proposer is not
registered we know that this this
proposal is registered so then we choose
this proposal to uh be the one who is
precc coming those
blocks this thing doesn't all always
work let's just
okay um so then there is like with with
any system you have to have incentive to
act correctly some systems depend on uh
um on only rewarding uh good behavior
some systems depend on uh punishing bad
behavior most systems or a lot of
systems depend on doing both so in this
case the preon getes that
pre-confirmation
fees and the proposing
fees in return he needs to precom and
provide good
information uh and honor the
pre-confirmation that he gave to the
users the way we check that is that in
the case the pre-c confer
node reveals the signed malicious
pre-confirmation the way it's done is
that so let's say I precom a batch of
transaction and then I didn't end up
pushing this batch of transactions on
chain but I have already broadcasted
that I have pre-comp this batch of
transaction with my signature so what
would happen is another promer that was
listening on P2P would then pick this
signature with uh with the with the
batch of transactions and push that to
the pre-confirmation service contract
would check if this is a valid signature
for the pre-c confer of this slot and if
it
is then it will go and ask the reaking
or staking contract to slash the signup
and in this case um yeah the there is
also the slashing for the incorrect uh
look ahead because you fish the look
ahead from the CL but how does the El
know that this uh look ahead is correct
there is you can use um
4788 uh EIP uh which uh basically
provides you with the CL Beacon root um
and using that you can push a proof
if the look ahead is incorrect and the
prec confer who sent an incorrect look
ahead would be
slashed okay so I before I move on if if
you guys have any questions it's it's
good to to have them now so yeah please
go ahead I have two questions first one
is based on I'm not familiar with
478 not
only yeah so the thing about 4788 is
that it provides you with the beacon
route of the parent block and not the
current block and because of this when
the look ahead is pushed I cannot in
that moment verify its correctness but
after one single block I can with the
proof using
4788 make sure that if it's not correct
that it is not so this is why we opted
for this in the case that it was
possible to verify we would have
potentially opted for um pushing the
proof with the look ahead the problem
with that normally entails that you
would pay more because the proof needs
to be verified on
chain in every single submission whereas
if you do it in a fraud prooof manner
only when someone is acting maliciously
that you need to do this so the cost
drops dramatically and there is
precautions to this so whoever is
submitting the look ahead will get
rewarded submitting the proof the fraud
proof for the look ahead will get
rewarded for this uh by uh the slashing
of the other
promer other questions yeah yeah you go
back to the slide where was
com to one okay uh let me try to make
this work somehow
okay work please Okay no
Okay yeah over here sure
um well not this was one where there was
a
SL I was wondering um I mean here this
one is not opted in and this one is so
for example if I take confirmations from
someone who SLS
reliable
St St possi
that okay so this is probably not
mentioned in this
presentation which is uh a problem but
hey
sorry um so basically what based rollups
depend on giving the user the ability to
always push
transactions on the L1 with permission
perm permission LLY okay and that means
that there is no one who could prevent
the user from pushing a transaction that
could invalidate future transactions
that have been precom that will be
pushed later that have been pre-comp um
and this leads to execution precom not
being able to be provided and the only
solution that we have to that is delayed
inbox so pre comers are able to push
directly to the Tao smart contract to
propose block blocks whereas normal
users who don't want to use the pre-c
confing system that is built and want to
push directly to avoid potentially
censorship uh uh by the promer even
though this is a decentralized solution
it could potentially have some type of
censorship so if they push their
transaction to this delayed inbox what
happens is that we wait for the
pre-confirmation to land and then we
include those uh transactions that have
been pushed by the user so in this
instance just to be clear uh any
transactions that come in this
slot uh will will go to the queue and
will not be proposed no it will not be
denied it will go to the Q yeah delayed
yes it will be delayed till after the
the pre confer has uh pushed his
pre-confirmation and then it will be
included what if my preon is dependent
on one state which is like really nice
component
um yeah no um I could I could expect the
pre conf with interacting with
L1 yes so if we engage a composability
in here then it could yes any state any
L1 State change could potentially affect
uh this uh L2 transaction that depends
on it and this is not a problem that the
solution is trying to solve
unfortunately just like an yeah I don't
think I don't think like um as of now
there is potentially there's some people
working on this but I'm not aware of any
solution to this particular problem this
is a very good question thank you
sir any other questions yeah go
ahead yeah so I think this might be
talked about in a later stage so I'm not
going to touch on it more but there is a
way for choosing a random pre- Comer in
the case that there isn't AE Comer
available for the next 64 uh block
slot any other
questions y go ahead um could you touch
on more about the so I'm doing PR
Gateway as like a a subset of the P lay
that's exclusive for pre that's how
interact this immediately sounds like a
Loosely coupled system to me off the bat
do you feel like there's
consensus required here to agree on
preon state like what happens if the
propos is to pull back to another like
you unpack the
gate the
Gateway okay so the Gateway basically
buys the right from the proposers that
have registered at P confers to propose
at a certain
slot do I even agree on like for
example us
provide um I don't think so know like
they can they can have varying tips
between one one one one one gateway to
another the problem is that with
gateways is that the gate the gateways
will have to compete in the beginning we
might have a couple of gateways out
there the problem with that is that it
it normally con people normally end up
converging into a couple of gateways
that then would have a monopoly so like
two or one Gateway that would then be
dominating because the idea here is that
if a gate way cannot
secure uh uh verif uh validators or
proposers that are willing to sell it to
sell the Gateway their right to propose
these uh Tao transactions the Gateway
cannot uh operate would there ever be an
inst where
pre Builds on other pre
fromal yeah so consensus um you do and
that's why we have the P2P I'll explain
that and in this
slide so when we said here sorry this
this thing is not that okay yeah so when
when we said that the precom node every
3 second batches a transaction uh takes
a batch of transaction and signs it and
then it broadcasts the sign prec
confirmation precon blocks on P2P this
is important because anyone who's
listening can do a bunch of things first
they can advance the head of the uh of
the Tao so people can keep up with these
precon prec confirmation you moving to a
safe head there sorry is it moving just
to a safe head it's not a safe head no
it's it's not even a safe head at this
point because it's basically a soft head
very soft head because as long as long
as it hasn't been proposed on L1 it's
not fully safe I mean there is financial
precautions to to that proner if he
doesn't obey or honor these prec
confirmations but they can always
software can always fail or um they they
could potentially have other incentives
so it's a very soft head but at least
you get consistent block times which is
a better user experience than what you
get right now um I mean ano said that
transactions normally take 12 seconds
and on Tao sometimes they take 20
seconds so there is some kind of extra
delay it's very long time
um any other questions before moving on
sorry I just wanted to understand the
consensus at the P2P lay that you were
describing
um so what what do you mean the
consensus so my original question was if
you have um pre-confirmation being built
upon by sorry new pre-confirmation being
built upon the state of previous
pre-confirmation
mhm how does that like consensus is
needed there for between two different
so the the pre confer that comes so
let's say that okay let's um let's say
that all of these are pre-c confers and
this one is a pre-c confer and has been
pushing um it pushed basically four
blocks it precom first one second one
third one fourth one and then it
basically just went and pushed it to L1
this one would be listening to these
pre-confirmation
batches on the P2P and would receive
them and it would just wait for a
confirm that they have landed on L1 and
then it would start building on top of
that would the middle one be accepting
pre-confirmation before it's been posted
to L1 no no because since its
pre-confirmation
um depends on uh the the state of what
happens in the chain here so it can't do
that or it will collect I mean it can
but it to collect a bunch of potentially
a bunch of um transactions that has been
already included for example so it would
potentially lose that space uh on the L1
side and yeah and also if it um it and
if it does not if it sees if it for
example precom a bunch of transactions
that uh then already has landed the
execution precom is not honored that
doesn't mean that it will be slashed it
won't be slashed in the system that
because the inclusion precom is still
there but it will lose that uh that and
if it does not include them it will be
slashed so in both cases it's kind of
losing something of course non-inclusion
makes it lose more so it would include
them even though they're already
processed and will be invalid if they're
included again but it won't at least it
won't be
slashed yeah so this is this is the
consensus um I mean this is a problem
with also like varying types of precs
because because you can always U that
like if if so in in the system right now
we're trying to build with prec
confirmations is that trying to avoid a
singular solution to dominate so there
is multiple Solutions so there is the
Gateway there is what we're building and
there is multiple ones so if each one
kind of like needs to build on the one
other the other one it needs to wait for
um the L1 the state of L1 to be updated
to start building on top of it
additionally to that that um if someone
if a user pushes a transaction directly
to L1 without um without pushing it
through a proner then that also changes
the state so it doesn't make any sense
at all to start building
pre-confirmation before knowing the
exact state in the on the L1 yeah thank
you okay let's hope this marker starts
working okay
uh yeah so we talked about slashing
now so as we said the pre- confer needs
to include and propose these batches of
transactions on
L1 but if this validator is selling his
right to build the block to a through
PBS to a builder it cannot accomplish
that because it has no control over the
content of that
block and the solution we found to that
is that we would modify the epbs
pipeline um to accomplish this exact uh
uh goal so the the the precom node would
go until basically the the Mev poost
that there is a constraint on the
Builder and that the builder needs to
include a bunch of L2 blocks which are
basically a couple of L1 transactions or
it could be one L1 transaction and their
blobs and it could in it should include
them and that's why the uh and and then
the PBS relayer would return with okay
yeah I can honor that and and they build
a block including these transactions at
the end and we propose the L1 block this
is the way that um and currently we're
using um bolt Smith boost because they
have that constraint API already
implemented so we we didn't want to
implement reimplement the wheel but of
course there is also commit boost which
can have that bolt myth boost module
built on it and you can have it for more
details on those please search them on
Google commit boost and bolt M boost
both of them are they have open source
GitHub repositories that you can um uh
look at and
yeah pre-conference selection I think
Anu will take over here
thank you sir thank you you want the mic
mic just this one
yeah okay so now you have a good idea of
what the overall design looks
like and let's talk about pre-con fer
selection because we did speak about how
we want the L1 proposer to be the only
one who can precom and then propose the
L2 blocks in a particular slot now this
is actually a very hard problem even
though it doesn't look like because at
ethereum we love patching things up and
in the process of patching things up we
develop new
problems so when eth moved from P to POS
what happened was we introduced a new
layer the consensus layer besides the
existing execution so earlier it was
merged into like one single thing and
now we have it's separate we have a
consensus layer which manages the POS
part and we have the execution layer
where which is what we developers
usually handle when we are develop
deploying smart contracts or interacting
with ethereum using a wallet the problem
is the consensus layer is where the
proposer identity
lives and that has a BLS signature
scheme but the execution layer where all
the inbox contracts are where all the
transactions are made that has an ecdsa
signature scheme and that's a big
problem how do we make a connection
between both of these there's no way to
make a connection
so what we need is we need a BLS to
ecdsa mapping so let's say I'm an entity
I have an ecdsa address and I run a
thousand validators with thousand
different BLS public
keys I need a way that I can prove that
I own those thousand validators I can
show it to the registry contract so we
have the pre-confirmation service
contracts actually have three
subcontracts the pre-confirmation
registry which we'll be dealing with in
this slide and two other contracts that
we'll be taking up later on
so this entity needs to prove that hey I
own these validators and I actually have
the right to propose an L2 Block in a
particular slot and how exactly do you
prove ownership of a key through
signatures right so we have this
signature format here which you can see
it basically has the standard thing like
having a chain ID and then validator op
is basically either zero or one if it's
zero you're removing a validator from
your list one you're adding and then
there is an experim and the actual
precon fer so in here the pre- confer in
the signature uh message is the ecdsa
address that I'm claiming that is
claiming the ownership of a BLS
address so the ecdsa address just pushes
a signature and the contract just
verifies that yeah it's the signature is
correct and this BLS public key actually
belongs to this ecdsa key and inserts it
into a simple
map now the execution layer has no
native way
of verifying BLS signatures right now
but very soon in the next upgrade the
pectra upgrade a new pre-compile is
being added via EIP 2537 that's where
all the discussion uh has happened and
this pre-compile or a set of pre-
compiles three pre- compiles actually
will help us verify BLS
signatures now this is are really
expensive because for verifying one
signature we need to spend like three
100K units of gas that's really
expensive so in our next alter in our
next PC we are actually proposing an
alternative where in the case of BLS
there's a great feature and that's
aggregation so if you have thousand
validators what you can do is you can
have thousand signatures offchain then
add all of these signatures up it's
basically elliptic curve addition you
add these signatures up and then on the
contract you just have to verify one
signature
so essentially you can add uh like you
can put thousands of validators in your
registry via just one signature and just
a bit more than 300 gigas which is
amazing and this is what we will
potentially be putting in the next
version but yeah right now it's one to
one single address single signature
every single
time so how is this used to construct
the look ahead because the BLS look
ahead is absolutely useless on the
consent that's on the consent layer we
need an ecdsa look ahead on the
execution layer so every every single
time we know that only this ecdsa is
supposed to propose no other ecdsa can
propose an L2
block so in this case it's kind of
simple the pre-comp node has the logic
the pre-com node can take a look at the
consensus layer because the pre-com node
is has the view of both the execution
layer and the consensus layer so the
pre-com node pulls all the proposal from
the consensus layer for the next Epoch
then it fetches the associated ecds key
from the pre-confirmation registry
because we have the BLS to ecdsa mapping
there and it just matches it okay this
this BLS for for the next slot is
belongs to this ecdsa This one belongs
to this and it creates the entire look
ahead now in our design we have assigned
the duty to push the look ahead of
pushing the look ahead to the first
precon fer of every Epoch so the first
prec confer of current Epoch will be
pushing the the look ahead for the next
Epoch and they are basically bounded by
this Duty they must do it if they well
it it kind of there's no option of not
doing it because the contract expects
you to provide
that and this is what a simple look
ahead like like one of the nodes in the
look ahead array or mapping looks like
I'll get to what the look ahead what
data structure we actually use but in
here the Tim stamp the second field and
the fourth field makes sense the time
stamp is the time stamp of the slot and
the proner is whoever is supposed to be
proning in that slot or proposing an L2
block we have another field fall back
and previous timestamp now what are
these well the previous timestamp is
just a link to the
last uh look ahead nodes Tim stamp what
this allow us to do
is um arrange the look ahead as a link
list within the contract or sort of a
link list within the so every look ahead
structure is an item in a map and the
previous timestamp just points to one of
the other timestamps what this allows us
to do is have advanced proposals because
not every proposer will be opting in and
also not every proposer will be
registering and exposing an ecdsa
address some are just not interested in
preconfig right so in this case we
cannot just have an entire Epoch be
empty if there are no pre-con fers or if
there are very few pre-con fers we need
to do something in the empty
slots and what we do is we allow the
next chosen preuner to precom in
advanced and because of this link we can
do that with a simple check a a simple
if condition that's why in here you can
see that P2 pre- confer 2 can precom in
the second and third slot already and P3
can precom in three slots in advanced
that is made possible because of this
linkless
design finally if we have an Epoch where
there are no prec confers at all and
that's very much possible if no one none
of the proposers in that uh Epoch has
opted in we don't have anyone as a pre-
confirm then we have to select someone
randomly and that's a very simple
selection like we need a source of
Randomness and with apply like simp
simple modulus to select one of the
indices of who is exactly going to be
the proner from the registry and the
source of Randomness comes from the
beacon root contract so we uh as far as
as far as I remember we basically end up
choosing the beacon route of the first
block in the last Epoch because this
gives us a pre a deterministic idea of
who's going to be the random preuner in
the next deok so we use that as a source
of Randomness and we just use that to
pick out a pre confir
and this fallback pre- coner has an
advantage and that is it can preon in
every single slot of this Epoch because
no one else is there to
precom
yeah
uh
notos you're not to
in six
months well but we won't be stopping for
six stopping the system for six months
right yeah so I can uh get in here I
understand the question um so you're
asking is since the pre comfor does not
have the right to pre uh to propose a
block in the next Epoch for example and
we chose it at random um how will it be
able to honor these preon
and the answer to this question is that
it might not be able to honor the
pre-confirmation
but uh it will not be slashed if it does
not honor them in this case because it's
a random picked pre confer and also we
thought about this like okay maybe it
shouldn't be providing pre-confirmation
but this would be a very bad ux so we'
provide the pre-confirmation we would
send them in the P2P on on on um on the
M Pool and potentially someone will pick
them up and include them if the if the
if the if the fee is right um and this
was like the mechanism that we wanted to
do in the be so um what Tao is doing
also is that they're they're they're
they're using this fullback mechanism to
say okay if there is a no a promer
registered in the next Epoch then we are
going to propose just to keep the the
the liveness of the of the chain um and
of course this proposal will go to the
mle and someone will pick it up but if
someone intentionally is censoring uh
these uh transactions and there is no
mechanism to force the builders to
include them then they will potentially
not be embedded uh in time
yeah thank you
Ed and one thing to not is that
throughout this POC we have never
touched the Tao contracts although
eventually we might to add that delayed
inbox but in here we have tried to not
mess around with The Tao contract and
what our task manager does is it simply
routes the blocks that are being
proposed over to Tao contract so because
of this the prover architecture doesn't
have to change that's the best part
nothing in the prover has to change and
the proposer also needs very minor
modifications because the original
contract original contracts of Tao have
barely been
changed go ahead for the next
step thank you thank thank
you okay so now we're going to go back
to the pre-confirmation loop that we
discussed that every 3 second we go and
um in a bit more
details I hope this clicker
works okay I'll just stand here
um all
right
so first we start with
the normal event Loop for Tao
so what Tao does is that once every L1
slot it pulls the pending transactions
from the men poool Tao proposer goes and
forms the block and then pushes it
through the blob to the rollup inbox
contract through the proposed block
function very simple
straightforward what we have with the
prec confing solution is the following
so we have the pre-com node every 3
second requesting from The Tao proposal
a batch of transaction Tao proposer goes
and fitches those batch of transactions
from
Tao and forms a batch gives that batch
to the precom node
and the precom node then goes and then
um uh pushes this transaction to the P2P
like we said the batch of transactions
to the P2P and of course the this also
only happens after it made sure that it
is the prec comfort for this specific uh
for the up for this slot and or an
upcoming slot that is very
near so this is the the new uh
loop okay all right so what do we sign
when we provide the prec confirmations
through P2P what's the
signature so the the structure that we
use is we use the block ID because we we
need to commit to a specific block
height or that uh pre confer could
potentially sandwich transaction if it
wanted to if we don't commit to a
specific block height that it needs to
to uh to propose this uh batch app also
the chain ID in case we are we have like
multiple uh chains and transaction list
hash which is basically just a hash of
the rlp encoded transaction list and I
see there are some hands for questions
yeah go ahead you you have the mic it's
fine just raise your seconds yeah so 3
seconds was like a just a conservative
um random number that we chose at this
point because we weren't sure how fast
the the system would be the latencies
all of that um what we're going to be
working on later as you we will see and
one of the slides is is like getting
that number lower and seeing how it's
going to be behave and how will it work
we will talk about that in in in later
slides
okay so this works here
okay yeah so the the the
pre-confirmation structure we saw it and
then there is the pre-confirmation
object that is sent on P2P because the
pre-confirmation structure is the one
that can be pushed as a proof for uh uh
fraud proof but here we need to uh when
we are pushing the precom batch on P2P
we need more details that one is not
enough so we have the block height and
the pending transaction list the whole
list and
um and the pending transaction bytes I'm
not entirely sure what that is for and
the proof uh uh of the precom
message and this is what ends up being
sent exactly in the P2P and the reason
we need the batch of transactions is
because we need all the other uh pre-
confers or all of the other participants
in the network to be able to advance the
head with this batch of
transaction and we also um need them to
be aware of this so when their role of
pre- confing comes along they know that
okay these transactions have been
already precom and potentially will be
proposed in the next and and in the in
the previous L1 block before we start
pre confing
ourselves
yeah so when um when a pre-com node
receives the batch of transaction from
the P2P once it's has been ProMed
we currently the way it's it it works uh
in Tao before the precom is that we get
an event which is called block proposed
from the one and that goes the Tao
driver is basically subscribed to this
specific event and advances the head uh
uh once it receives this event which
means that the user will get a
transaction receipt every 12 to 24
seconds and this is the main point that
prec confirmation our precon solution is
trying to
alleviate with this design so now the
pre- confing node can once it receives
the uh pre-comp message with the pending
transaction list it can provide it to
Tao driver and Tao driver can basically
Advance the head of Tao in around 3
seconds given that we choose a 3sec uh
confirmation Loop um
time all right
so the the nonpr so there is the precc
confing node so this is the previous
slide was about the pre-c confing node
so once it pre-com the transaction list
it does this and there is also the non-
preconfig node receiving this message
through P2P and then sending it to Tao
priv driver to advance the head so the
whole network advances together and not
a single uh one of the nodes in the
network yep so we already kind of
discussed this so um we have two ways
that the pre confer sends his
transactions or that the L1 transactions
that will basically push the uh L2 uh
transaction batches so first we said
okay let's say that we have a pre-
confer in slot number five and this prec
confer is on duty for slot number 1 2 3
4 and five that means that they need to
precon a lot of batches on in these
slots and then they can force include
them in slot number five and that's not
a problem that's easy to do by using the
PBS software like we
explained um the problem arises if there
are sparse prec Comforts there isn't a
lot of pre Comforts and that would mean
that potentially one pre- Comfort could
be in slot number 42 and he's
responsible for slot uh I don't know
five up until 40 to and this would mean
that he needs to push a lot of
transactions in in his slot if we follow
this model so instead we said okay maybe
we should just push all the precom
transactions right away to the
mol so we get batch a batch B and we
just push them directly to the men pool
and at the same time we put them in a
Que in a cache and the idea of this
cache is that once an L1 block comes and
it has those uh batch transaction that
has been pushed here in it then we can
remove this batch from the
cash if if that doesn't happen then the
batch of trans if L2 transaction stays
in the cash and then once it is yeah and
so basically if it's if it's U if it's
included we clear that batch from the
from the cache
okay so on the proposal
slot we take the ones that hasn't been
included uh that we pushed to the m pole
and hasn't been included yet and we make
sure that we push them through the
constraints API of Bolt Smith boost to
be forc included by the Builder and then
once we receive the L1 block we have the
guarantee from the relayer that these
transaction
uh uh L1 transactions that contain the
L2 transaction batches are included then
in the uh L1 proposed L1
block and she will talk about slashing
and
yeah got yeah
okay so now comes the pre-confirmation
service manager contract which we
haven't spoken about yet and this is a
very interesting contract because what
we have tried to achieve with this PC is
a really flexible interfacing because we
have a number of reaking solutions right
now out there in the in the market we
have ananl we have kak we we might also
have our own staking contract later on
if a community decides on one which uh
is actually going on
a discussion is going on on having a
unified
registry and that calls for having some
kind of a middleware contract so that
later on the code logic doesn't have to
be changed and the staking is just
abstracted away to a different set of
contracts and that's what we achieve
with the service manager is essentially
like a middle wear that ensures that
only those proposers who have a required
stake are allowed to precom or propose
in in the upcoming blocks in the
upcoming slots
so what kind of slashings do we have or
when exactly do we slash well one one
time do we that we do slashes when the
look ahead being posted is incorrect or
the look ahead posted is
incorrect a basic version of this is
that when you have uh like let's say for
a validator with BLS key BLS public key
B5 uh in the look ahead mapping uh in in
sorry in the BLS mapping you have E4 as
the associated individual who owns the
B5 key but the proposer who pushed the
look ahead placed E2 as the associated
ecdsa key which is factually
incorrect now this might look like an
easy way to just compare hey okay both
of these are not really equal so why not
we slash the the person who posted a
look ahead but it's kind of tricky to
prove this inequality because we have B
and E4 from the pre-confirmation
registry but in the task manager we
don't have access to who exactly was the
BLS the the validator and its Associated
BLS key for the current slot or any slot
that is incorrect we don't have that
information in like s in a simple
way and what we need to do is we
basically need to have uh this kind of a
match that okay B5 from the
pre-confirmation registry and B 5 in the
current slot both of them have different
ecdsa keys and then B on the basis of
that we slash the pre the poster of the
look
ahead so well there is a way to do that
and I kind of have to make a correction
on my previous uh statement that there
is no connection between the consensus
layer and execution layer well there is
but it's kind of a complicated
connection and that's through the beacon
block route which I think Emma touched
upon briefly
so you see just like the consensus layer
has blocks sorry the execution layer has
blocks that we deal with the consensus
layer also has Beacon blocks because
it's the beacon
chain and each beacon block has a state
route and if you
unravel like the entire state tree then
you'll realize that in Beacon State we
have the validators field which contains
all the validators or the
proposers uh and that includes the their
unique index as well as their BLS
key so what E7 4788 proposes is that we
get this eventual Merkel route like if
we meriz this entire Beacon State and
then eventually the beacon block we
eventually get a 132 by long Merkel
route and we make this available within
the execution
layer so the thing here is that there's
a problem and that's we only have access
access to historical Roots we don't have
access to the current slots proposer
because well the consensus layer is yet
to create the block so we can't have the
we can't really know who the proposer
is so we have to slash or prove that a
look ahead is incorrect optimistically
and the way we do it is we wait until
the incorrect slot has passed and we
have the route and once we have the
route we can basically make a static
call to this contract which is the
beacon Roots contract and get that
Beacon route and then just need to send
two
proves so first the proposer or sorry
the Challenger posts the BLS key of
whoever was supposed to be the validator
of that slot as well as their validator
index and along with this it sends two
proofs first is the proof that in this
case if you see we have a proposer index
in the beacon block but in the beacon
State well we basically end up having
BLS keys of the validators at respective
indices so whilea aoral proof we have to
make this connection that hey this
proposer index actually belongs to this
particular BLS key or BLS public key and
that's the step
two and then in the next step the
validator or once again not the
validator the Challenger needs to prove
that this is the proposal index that is
present in the beacon block as you can
see here the second field so very simply
with two simple Merkel proofs you're
able to get whoever was the BLS the BLS
key of whoever was the validator in the
current slot or the pre the slot that is
being
challenged and well once you get that
you can just go ahead and
make check if this inequality is
actually satisfied if it is then well
the look ahead slot is incorrect and you
can slash whoever posted
it along with that we have slashing of
bad prec confirmations which I think was
touched upon by ahmmed but in this case
if we want to expand it we have
execution pre- comps that could be bad
and we could also have bad inclusion
pre- comps in the case of execution
proms well the proposer did push the
eventual block that he pre-confirmation
that was not actually
preconiran-food.com
that was on the
P2P and in the case of inclusion pre
comps that's a bit more simpler we end
up getting different proposers for the
same block ID because it might have
happened that well he pre-confirmation
no on the inclusion can happen that I do
for I don't might turn five away but
someone incl
before and then the pre proposer would
have really is that true yeah so in this
case we actually have uh discovered a
few issues so another variant a more
simple variant of your issue would be I
precom and I don't include it but then
for a long period no one actually
includes any block so what happens is we
a long time passes and the dispute
period gets over so even though that
there is no pre-confirmation there is a
pre-confirmation but there is no
Associated block like the block ID has
never really progressed on chain and and
that's an issue but you can't really uh
prove the incorrectness of this so we
have a way of doing that and uh that is
so we might have to go back to so let's
say this is
like the slots okay so whenever uh a
pre-confirmation is being made we also
include a look ahead pointer which
basically points to Which slot in the
look ahead am I prec coming for so in
this way what we have to do is we have
to make a connection between the uh
pre-confirmation and the proposed block
why are the look ahead I think now that
answers your question because if we have
that look Ahad pointer that basically
states which look ahead slot have we
made the pre-confirmation for and if it
lands on at a different time on uh on
the
L1 we can make the
inequality okay but but is it possible
that I pre-confirmation
prec confirmations I I don't know if
that makes sense I mean not really
because you are prec because the
proposer is once again the I mean this
is Advanced proposals I mean you just
put it in you just release it in the
public me pool and it might happen that
the proposer does not included but then
your slot will be coming in so if you go
back to this slide that
Ahmed uh presented in this case when
your slot comes in you clear all those
pending transactions that have never
been included because the proposer
didn't want to include but your slot has
now arrived so you pick those
transactions and you force includeed
whilea the inclusion list through the uh
PBS pipeline yeah the the other answer
to this question is that the previous
pre-
Comer um cannot uh like that the
previous slot and if if you're talking
about if if this slot is for prec confer
2 to precom at the the precom one cannot
then go and push transactions there
every slot has an assigned pre-c Comer
and only a specific pre-c Comer can uh
push transactions or batches in those
slots so the contract will just ignore
any batches that arrive from pre-
Comforts that are not assigned to these
specific slots okay
perfect any more
questions no
I think we can touch upon the future
work now
yeah um all right so first we start with
soft blocks So currently what we do when
we advance the head is that we push a
whole full block to Tao and in this way
what ends up happening is that it goes
and lands in the canonical chain and
this is normal and this is why those
transactions are then removed from the
mol so when you propose the next block
they don't get included twice so that's
one thing um the problem with this
approach
is um is that when you we are proposing
these blocks at the end on L1 we need to
propose multiple blocks so for example
if I pre-confirmation
this is costy proposal and verification
of these blocks is costy for a block
proposal it cost around 200 um 200 um
200,000 gas Anu right yeah give or take
and um around
400 for verifying the ZK proof for a
single block give or take as well uh
could be a bit more than 400 more closer
to 500 so every block that we end up
proposing is is is adding a lot of cost
for proposal and verification so what
did we end up with is a solution where
when you
precom um you're going to add the batch
to taoes push it and then when you push
another batch what it ends up happening
is that it gets added to the block
instead of being so it gets appended in
the block so what happens is that a new
block is formed with the previous
transactions that are in the block
and um the new transaction batch and the
previous block gets reorg out and then
we include the new
block and this keeps happening until the
precom node sends end of end of
pre-confirmation
or uh and then this block becomes a
standard block and gets pushed to L1 as
a whole single proposal and this gives
us the cost saving that we're looking
for but it's still not finalized
something that we're going to hopefully
work on the next couple of
months another thing like uh our friend
here asked about before is the slot time
uh for the L2 So currently we have a
constant three block second block time
and what we're looking for to
accomplishing is one second walk time
and it's not that this is not possible
currently it just hasn't been tried yet
and we're not sure what limitations
we're going to hit with the P2P
Etc yeah and then in the last one I
think you will talk about it
yeah so when I was talking about the
pre-confirmation service manager
contract I said we are trying to make it
like a middleware so that as and when we
want to change the reaking service or
the staking service we can just swap it
out and use a new one and
in regards to that the community is
planning to launch a universal
pre-confirmation registry so chances are
there will be many more based rollups
down the line not just Tao and when you
have so many based rollups it could be
the case that one proposer wants to
propose or pre-comp for multiple based
rollups but it doesn't really want to
register continuously because that will
cost him a lot of gas and also it won't
be that credibly neutral because might
be the case that every rollup starts up
its own staking service and and that's
not reasonable for the proposer and
that's a waste of eth not a good use of
collateral so in this case there will be
a universal pre-confirmation registry
where any proposer who wants to become a
pre- confer can go in register the BLS
mapping instead of being in the protocol
owned registry it will be here in the
Universal pre-confirmation registry
along with that so the slashing
condition optin this is a very important
aspect
ECT so
the uh rollup protocol like whether
whoever makes another base rollup wants
to have might want to have their own set
of conditions based on which they want
to slash so maybe they don't want to
slash inclusion proms they want to just
slash execution pre-s so they can Define
their own slashing conditions and then
only have those proposers who have opted
into these slashing conditions be prec
confers for their
roll up so yeah this is still an ongoing
discussion in the community and
eventually there will be we will be
specking it all out and releasing it but
yeah that's it's going to be a
while well that's it thank you so
much okay there's a question
here how do you see this integrating
into existing kyc systems or rather the
path to scale and adoption on the side
of us users and institutions I'm not
sure that's a question for the session
yeah
yeah all right so any
questions final how's how how do I
evaluate the security of a say I I
probably doesn't care if I send million
I if they
say right so what you're asking about is
the fair exchange problem
and this is something that our research
team has been looking into for quite
some time now um as of now we don't have
a solution for the fair exchange problem
um and I think most of the existing or
proposed Solutions depend on a
reputation system as of now where um if
the pre-c confer or the Gateway
providing the pre-confirmation
um uh is acting maliciously they would
this would affect the reputation in a
bad way and they would potentially be uh
cut out of pre confing for the specific
protocol they're working on and this
would potentially lead them for losses
so they the reputation B system uh being
proposed for now but we are working on a
non- reputation based system where there
is um some oversight over how the pre-c
comers are acting and if they are
actually pre confing in the correct time
providing pre confirmations in a timely
manner without like um delaying the
pre-confirmation by the you from coming
from the users or um um like reordering
transactions uh with this delay to to to
just generate more meev or or profit for
themselves there's another question here
what kind of slashing conditions do you
see is it a penalty or more tougher
so I think right now our slashing
condition is very straightforward we
just slash the entire stake which is not
ideal and it's definitely not going to
be this eventually I think there was one
there is one proposal by the research
team and that's we have let's say slash
tickets so for every pre-confirmation
that you provide and every validator
that you register you have a a fixed
amount of stake so for pre-confirmation
let's say you are staking one eth for
every pre confirmation that you provide
and once the pre-confirmation is settled
you can basically reuse those tickets
but if you mess up that reconfirmation
only that one e amount will be slashed
and not your entire stake so this is
open for discussion and one once again I
think this is a part this will be a part
of the community-led discussion of how
seriously we want to slash a a a
malicious prec
confirm uh sorry how do you think uh
distributed validator technology fits
into your prec confirmation design do
you think it could make it much more
secure or have have you guys looked into
that H so in DVT I'm not entirely sure
about the block proposal and how it
works exactly so uh I I know that for
the
attestation uh multiple uh
like three out of four nodes they need
to sign basically to get a proper signat
a BLS signature and um I think it's kind
of the same for the proposal but I'm not
sure how they choose which one of the
nodes is the one who is responsible for
forming the block so honestly no uh we
have not looked into how D DVT would
interact with with this protocol at this
moment uh because also DVT does not form
a
significant um like um share in the
market of proposers as of now so it it
it would it might not make sense for us
to look into it in a serious um in a
serious manner but potentially if it
becomes more popular then yeah this
would make
sense you have any website for networ
metri how many subscribed to this kind
of stuff are you measuring life or I
mean this is not yet on Main net because
firstly we don't even have the pre-
compiles yet we need to have the prra
grade so it's it's running on testnet on
Helder testnet uh have you heard of
Helder testet it's a devnet which was
released during each CC so Tao already
has uh not the final version but one of
the intermediate versions running on
Helder providing pre confirmations but
once again that's a devet so it's only
the validators that Tao is running but
yeah this this was tested using 300
validators and it worked great yeah okay
thank
you
might if you can speak to the mic
because I didn't hear half of what you
said yeah how just how do you decide how
much you pay for the pre-conference to
post the roll up blocks because there
might be multiple base rollups and for
the slot and they might be compete for
this pre same
precom so for the payment we
have we have lifted up for the market
and because we decided that the priority
fee will be used then basically the
preconference will just not prec confirm
transactions that are not profitable
um so any transactions that are do not
have a high priority fee that is paying
the
[Music]
pre-conferences blob which is basically
now free one way to to get a blob as of
now um the the the more I can make money
so we lift the pricing to the market to
decide um there are some research that
is going on in the space by Connor um
and Lynn from nethermind and there's
another guy I think called Finn Finn
yeah uh I don't know their full name so
I apologize for that about the economics
of pre-confirmation and the pricing for
pcoms ETC and this work um there is a
lot of talks that Connor Finn and Lynn
has been talking about pre-confirmation
um I advise you to go check the
recordings for these Talks by these
people they're BL they're they touch
exactly on what you asked about thank
you how do you
think
of do you
think it improves it uh is that a reason
for
concern um personally um like meev or
not me um the the protocol works with
local built blocks and also works with
forced inclusion through PBS pipeline
the only problem here that I see is that
if relays and Builders decided that
they're not going to
adopt the constraint API that we talked
about because it basically reduces their
income because pre-confirmation are not
profitable enough compared to what they
can include other than these
transactions um then we would have a
problem but as of now and as we uh as we
heard from our partners is that there's
a lot of talk and the Rel layers and
Builders are agreeing to add the
constraint API um to their pipe to the
epbs pipeline so they would be
potentially uh including
pre-confirmation
to add to this we I think we also have
plans for L2 meev extraction so when
that is added to this I think the
dynamic changes a bit Yeah so basically
since we have like currently 3C and
potentially 1 second uh uh block times
for the L2 in this one second you can
the the pre- comfor still at at well can
re order these transaction but we would
not expect every prec Comer which is
basically just an L1 validator to have
thetic the sophistication needed uh in
the software and in the hardware to be
able to support such ordering in one
second and I think what's going to
happen is that there will be an a PBS
pipeline for L2 blocks if this uh
protocol gets adoption that will that
tries to extract M from these L2 blocks
in this 1 second slot
sorry last question uh what are the
latency figures that you guys have
regarding like the block transmission
from the preconference we don't we don't
have that yet because as of now we have
only Dev Nets and Dev Nets are basically
just U curtosis uh setup uh instances
that are running on local machines I
mean we have Helder but deployed a
hybrid solution between Gateway precom
and our solution so our smart contracts
but Gateway software basically and um as
of now that that's what no that's that's
deployed in Hilder yeah okay yeah so
that's what deployed in Hilder right now
so it's not the same and we don't have
that distribution of of site cars
running so we can calculate this this
latency we can do some simulations po
potentially but yeah reality always is
is different than
simulations do we have more
questions think
not all right that's thank you everyone
for having for for for attending