[Music]
okay hold on a sec I get the slides in
the right
place um yeah hi I'm Mark Holt I work on
the Aragon team um and basically what
I'm going to talk about today is Aragon
3 which is the kind of latest
incarnation of Aragon which is just
coming off out of alpha so we're
expecting by the time we get to um Petra
to have that as the client we would like
everybody to use so the um purpose of
this talk is to talk about Aragon and
what it's doing and why it's slightly
different from other clients
um and what do I
oh so yeah so Aragon a bit about us
Aragon is a um is a is a client team now
although we're principally used for
execution in fact one of the things
about later versions of Aragon 2 and
Aragon 3 is actually it's combined
client it basically does both CL and El
in one application um now it was based
on a turbo Turbo gu which was a project
which I'll talk a little bit about um
but it's essentially built to become
mainly an AR us as an archive client
which is you see we're down at 2% of
usage um and that's because basically we
get used for um people who've got who've
got an interest in the whole history
essentially and historically we've not
been quite so good at at operating for
people who are purely doing validators
already interested in the tip of the
chain now hopefully with Aragon 3 that
will change a bit um so what I'm going
to talk about today is just an overview
of what Aragon 3 is the journey we've
been through from Turbo gu which is
where we started from to where we are
now um I'll explain a little bit about
the architecture of of Aragon 3 because
I think it's important in um in
understanding how we think it's
different from other clients and and
what what the implications of that are
and then I'll talk a little bit about
the future of of what we've got um
so I called this um this talk a Aragon 3
a paradigm shift for clients and that's
partly because I think within the Aragon
team itself we think about the client
slightly different from other clients at
the moment especially in I I guess the
ethereum space in that we don't really
think about consensus versus execution
because we've got a combined client um
what we think more about is what happens
at the tip of the chain and effectively
what happens after that because a lot of
the technical work we've done is about
the transition of data as it goes
through the um life cycle from coming
out of a m poool to getting into
consensus and then you know what happens
with all of the data afterwards as it
gets into the um in in into the archive
space because I mean for us we never
throw data away and that includes both
CL and El data so we're basically
working out the how do we how do we
store and distribute this stuff so we've
kind of got a model that chain has an
application that thinks about chain
dissemination which is you know the live
chain and what happens when it operates
in real time and how do we work that
effectively and then there's a whole
process of once you've basically got the
chain data how do you then distribute it
efficiently to other nodes um and we
kind of split that and we don't
necessarily do that through the entire
the um the same life cycle as everybody
else so um I'll talk a bit to start off
with about the Aragon Journey because I
I think it's interesting it's also
interesting in terms of the last
conversation we had which was about
client diversity um I think one of the
interesting things about client
diversity in the context of Aragon is
it's not just for the live chain I mean
one of the things about client diversity
is Aragon's had a quite a long journey
to get from where it started from to
where it's ended up now and that's
effectively been funded out of the
community because it accepted there
wasn't a one one siiz fixs all and
because there's not a one siiz fits all
if you believe enough in about something
you'll get the backing to keep going
although there are several other people
doing the same thing and that can lead
to different outcomes
um so if we um if we talk about this
where do we start from so um I think
Alexi who's actually in the audience
here was was talking in Devcon 4 which
is an an introduced turbo guess which
was a changed the way guest stores data
so that was in you know Devcon 4 we're
now several iterations through the um
through the Journey and we've we've
probably finally come to the point where
we're deling on the original Vision um
and I think that's that's another thing
about the
um the space that we're in is that
actually if you look at Aragon it's had
the space to kind of learn over seven or
eight years to get to a point where it's
actually delivering a product without
the kind of pressure of you get you got
get time to Market and if you haven't if
you failed within the the first couple
of years you kind of you've got to go
off and do something else so there's
there's longevity in this process
now I think if you look in Turbo gu that
what it was doing was looking at the
data storage and saying if we have a
look at the way data is stored in and do
analysis of it in in the um in the
clients we can do better with the
storage model effectively and I think
the the turbo gu piece of the journey
was about essentially how do we make
storage more optimal and if if you look
at the numbers um the the lesson there
was you look at the majority client and
we we with the analysis that we did and
and the work we got down to a fifth of
the storage model so you get to a
situation where the effort was worth it
to get something slightly different
essentially now I I
think what that does is says right
there's a product here and people start
using it because there's a there's a
benefit for people because as as the
chain grows disc size is important so
having a client actually cares about
this is an important process so that's
what got the whole thing kicked off and
then essentially what we ended up with
there is an ongoing development of
Aragon which took that original idea and
de pushed it to its um next conclusion
and the the next stage of this journey
was the realization that actually if you
start caring about the data and the data
going into a database you start thinking
about what the day space is doing and
asking yourself the question can you
optimize that and the other thing that
you begin to do when when you look at
that is say is see even in the data
storage space there's a pipeline of um
different things that you need to do in
the storage process and if you if you
want to do different things you need a
slightly more adaptable client um so
essentially what you ended up in Aragon
2 was this concept of a stage Loop where
the stages of storage are done inde
dependently from each other and if you
want to do slight something slightly
different in the process you can insert
something into that model so you get a
bit of flexibility and if you look at
quite a lot of the Aragon Forks that
people have done quite a lot of the
adaptions in those are adding stages
into the stage Loop um the other thing
that Aragon too did is is realize that
blockchain data has actually got a
series of stages to it and and
especially now the chains get finalized
quite quickly you've got stuff that you
need to do in a read write database
which is has got a a a certain set of
criteria that you need to meet but after
a certain amount of time the data just
doesn't ever change effectively so
you've got this model where you've got
live data but you can transition that Li
that data through a freezing process
into essentially a different storage
model and the interesting thing about
that different storage model is it's a
lot easier to distribute you don't you
don't need to take that data and push it
through the whole execution process to
get it onto a dis for a machine you can
just transfer it by some other medium
and essentially what Aragon 2 does it
says well that Frozen data you can just
put it into a torrent and pass it around
using um torrent information and you get
the same data on the on the same dis now
Aragon 2 for anybody who's used it um
will see that process of you load the
files when it start but then it's got a
downside which is you still have to take
those files and execute them and that's
because in the Aragon 2 version of the
system the state of the of of the chain
was still had to be computed because we
had no way of dealing with the how do
you store the state and redistribute it
essentially so um what what then
happened is we moved into okay fine if
we're going to actually make this
distribution model work we need to
actually do it for everything and it was
quite a large effort I would say which
is the Aragon 2 to Aragon 3 which has
been I guess ongoing since the merge I
think that that process um but what that
was doing was kind of saying well
actually the model of distrib bution
that you've got for um transaction data
and transaction history you can also
apply to state so um if you look at the
picture here for um Aragon 3 um the what
I'm trying to show in this is that you
can take the turbog model where you're
dividing the data out you can take the
Aragon 2 piece of the model where you're
actually taking things from the data
store and pushing it onto disk and then
basically once you've got that data out
of the store onto disk in a form that
you can distribute you can distribute
the whole chain
independently of the um of of the
consensus mechanism because what you're
actually delivering at that point is
just the Frozen chain and I think the
way that I kind of conceptualized that
is we've now got the same process as you
would do if you're basically have got a
um you know we're very used to when you
compile code you compile it and then you
distribute it in compiled form you don't
constantly recompile it because once
you've once you've got a the compiled
data you can deliver it and link it in a
variety of ways so it's it means that
you can think about you know what we're
doing in Aragon is we're taking the
blockchain and we compile it into
compiling it into a redistributable form
um now that probably wasn't the original
intention but it's effectively where
We've Ended
up um so I'm going to talk a bit more
about how that works by giving you um a
bit of insight into the way that the um
Aragon architecture works so you can see
what we're actually doing inside of the
model
so essentially a lot of um what Aragon
does and a lot of what the team work on
is this kind of process where um we we
think about what the EVMS doing and all
of the the peer-to-peer Network actually
a lot of what what we're coding in is
this process of taking the um the blocks
that we've got and the and the evm
execution and pushing them into the
machine's page file so they can be
efficiently stored on disk um and then
essentially they will either go into the
database if they rewrite data or they
get pushed into files and then R and a
lot of the basic performance that you
get of Aragon is essentially the uh the
layer we've got which actually manages
how do you use the machine's page cache
um which is why if you run Aragon you'll
see you may have a relatively small
process but if you've got a machine with
memory on it we will take all the memory
that the operating system will give to
us in its page cache now it's to some
extent that's quite alarming for users
when they first see it I mean the the
good news is that if somebody El
something else wants wants the memory
because it's uh operating system managed
it does get it back again it's just um
will basically eat eat as much page cast
as you like but it's it's useful to
think about I think the the the the
chain being process and then put into a
set of pages that put onto diss that are
that are just managed um and effectively
the data goes into a database if it's
read right and and as it as it
essentially um ages it'll get pushed
into um a set of readon files now
essentially those readon files are used
by anybody who's using us as an RPC
provider because the majority of the
historical data will actually get read
especially in Aragon 3 out of these um
out of these files um and the other
thing that's going on inside an
operating Aragon process is we've got
this bottom line where we're basically
continually pulling stuff out of the
database pushing it into these flat
files and then reconstituting the data
um so when we're thinking about the
performance of what we're doing we're
thinking about essentially how do you um
how do you balance this that you've got
the evm running at the tip of the chain
and effectively we've got this process
of pulling stuff out of the database and
pushing onto the disk and we need to
coordinate all of that in the at the
same
time um the other thing we're doing with
which is what this picture is is doing
is we're we're effectively in that
process the data that's pushed through
the operating systems page files are
also formed in this in a um in a flat
state which basically then we distribute
across the network and the reason I've
drawn this picture like this is
effectively what you've got on every
Aragon node that's running
is really really you can think of it as
a replicatable page system where
essentially um we're the data that's in
a database between two machines is going
to be different because it's it's it
it's been loaded and and um and
processed dependent on on what the
database on that machine is doing but
the files that we've got um that we
store on the disk in in our background
process are exactly the exactly the same
on every machine in the network
essentially so effectively what we're
producing on end machines is completely
deterministic it would always be the
same set of files and it's that feature
that allows us to basically um if you
like push them through the network as a
set of pages so what what what we're
doing when we're Distributing stuff from
Aragon is we're essentially Distributing
a verifiable binary version of the chain
from one machine to another essentially
and what this diagram is is showing you
is you you've got a set of pages and
they're all hash
verified uh now what are the
implications of all that um uh process
well they basically what you end up with
is very quick sync performance
effectively so the big difference
between Aragon 2 and Aragon 3 is the
amount of time it takes to sync
something and this is um you see this
particularly on
uh large uh chains so um basically my
role in The Aragon team I'm mainly
working on polygon rather than rather
than ethereum which is essentially a um
I mean on on Aragon 2 it's about 8
terabytes of data that needs to be moved
and if you sync it you can literally
wait weeks literally so um with Aron
three effectively that time goes down
to only a couple of which seems like a
long time but actually in that chain
it's not a lot and effectively for
ethereum you're getting down to being
able to sync within a few hours
essentially so and just talking as a
developer using a chain actually
completely changes the way you're
thinking because the Chain's there you
know comparatively almost immediately um
the other thing about our background
syncing process it scales with network
bandwidth so um I
I go back to polygon an example so
basically if you if you stick an an
Aragon 3 node in a data center that's
got enough Network bandwidth this um
this four terabyte um chain that you're
trying to sync happens in a couple of
hours effectively now and that's
essentially because we're not
reprocessing everything all the time
we're we're essentially just copying
everything across the network and as
long as you've got enough Network
bandwidth it happens
quickly um and what this diagram is
showing you a bit about is why does that
happen well if you think about the
distribution effectively across the
peer-to-peer Network you're you're
effectively taking the data pushing into
the network and then every machine on
the network is basically running a
consensus interpreter an execution
interpreter and then putting onto the
dis we're basically doing a straight
verified copy and the thing is that you
get exactly the same result in both
paths it's just that the second path is
an awful lot quicker um now it's also
because each node produces exactly the
same files effectively you know you can
know between two nodes that you've got
this straight data copy but effectively
because of the hashing involved you also
know that this is a copy of the chain
effectively um so you know that that
that's why we we think that's a change
um and then just quickly at the end of
it I want to talk a little bit about the
future so um the other thing that that
does is because we've now got
essentially a thing that's Distributing
data for our application we're beginning
to think about Aragon as splitting our
client into two things one is a database
which is effectively running a DLT data
store which we we can separate out as a
separate thing and then a set of
components that actually operate the
chain now I think what's important for
us as a team is over the next year or so
we're probably going to spend a lot of
time re dealing with data and a lot more
time about dealing with this front end
of effectively how does how does the
chain
operate um and I think the other thing
we can start thinking about is
essentially we've got this model for
Distributing a compiled form of across
the um across the network how do we push
that and start thinking about having
sparse clients that don't bother
downloading everything all the time
because really if you've got a fast
Network you can actually afford to not
do anything until you need it and then
load pages on demand and that at that
point that distributed version of Aragon
looks like the very local version of it
where effectively we've got a two-stage
page cache effectively operating the
chain
and I think that with that I'm out of
time and I'm done thank
[Applause]
you so two of these questions I'm going
to combine um which is uh how do you
compare in terms of speed and cost
efficiency um and storage uh compared to
the other execution layer
clients um depends which client so
something
like so we we're I think we're probably
still and don't quote me we're about a
fifth of the stories for GU on on a
reasonable size size chain um the others
I'm actually not quite sure about um are
there other pros and cons of running um
Aragon versus any other execution layer
clients um yeah so Aragon is good in in
storage performance and its RPC layer
it's not so good if you're doing things
like validation because we simply
haven't worked on that as a you know
we've optimized
the storage not the interactions um but
I think that is less to True with Aragon
3 effectively great thank you um how
much bandwidth overhead does Aragon
introduce to push verified data across
the network
[Music]
um as much as you want to give it so
basically what you can do when you run
an Aragon node is you can tell it how
much bandwidth it wants to give away um
and it
basically if you don't want to have that
turned on it doesn't take any it doesn't
take any overhead if you if you're if
you're conversely a seeding node you
know it'll it'll run as much bandwidth
as you want to give it um basically got
a lot of questions coming in at the last
hour is Aragon 3 going to make the
support of other EVMS uh more easily
what about
l2s um yeah I think it is I mean one of
the things that we're explicitly doing
with Aragon is doing L2 support I think
the the big difference for us in um in
2025 from 24
is we'll spend a lot more resources in
in in actually actively working with L2
chains to get an L2 version of of Aragon
and one of the reasons for
componentization is so that we can we
can have a core Aragon that does the
databased thing and then as we work with
more chains we're simply building
components because what we want to do is
end up with not having endless FS of
Aragon in order to support other chains
but have an ecosystem that means that
you can plug in and extend it
essentially which is something that we
haven't been able to do while we've been
concentrating on getting the storage
model working are slot storage of a
contract in the same page
file are what top question are slot
storage of a contract in the same page
file um they will be if they're close
enough together in storage basically so
it the question is it depends when
they're
stored will it be possible to query
underlying database direct DB with
directly without Json RPC
um it it will do but it's not at the
moment basically so I mean when we talk
about Aragon DB what we're talking about
is can we give it its own data access
layer that effectively runs alongside of
the RPC layer so it actually operates as
a as a DLT database basically but that's
where it becomes a product in its own
right and not part of Aragon as a
client what is the biggest performance
bottleneck in Aragon right now
um it's dis
IO sorry it's dis
IO right the the amount of time it takes
to write to a disc is a thing that
actually so it doesn't matter what you
do to optimize it it's how much it t
takes to get stuff onto and off the disc
um basically so I think this question is
similar for transaction processing
throughout AKA trans transactions per
second is dis access access the main
bottleneck yeah yeah absolutely is the
separate RPC D in process staying yes
did you consider changing
mdbx it's sanctioned software by a
ftic um we did but we've got a lot of
Russians in the team so they don't
actually have quite the same uh view of
it do you support
veral uh we we have a veral
implementation
yes is it is it is it going to get
deployed well that's I think not not not
the same question yeah how do you
optimize the database so that old and
new data are not stored right next to
each
other I don't know the answer to that
question uh wouldn't sparse clients
contribute to storage fragmentation or
loss um I don't think I don't think they
would do actually I think they're a
natural extension of what we've done
because the question becomes you know if
you've got a lot of clients and you
you're all storing a bit of the N
Network essentially you won't
necessarily lose it I think I think the
the question there is
more I think part of where we're going
to is you've got to answer the question
is if we want an internet St scale
blockchain you can't have all the data
on all the clients all the time you have
to get to a situation where you've got
some kind of Spar
storage basically and then it becomes uh
how many people have got how much of the
chain
cool um thank you so much we are out of
time for questions but if you want to
ask these questions to him afterwards
find him afterwards can we give one more
big round of applause
[Applause]