►
From YouTube: Developer Community Call #7 -- Nodes Architecture
Description
00:00 Intro
2021 TECH RECAP
00:21 Past, Present and Future of the Fluence development
01:04 The story of the current Fluence tech, the beginning of 2021
02:19 Challenges of 2021
PAST
03:22 What has been developed during 2021
03:47 Aqua, the main way to interact with Fluence network
05:24 Marine (WebAssembly runtime and tooling) development & essential parts
07:03 Fluence Peers (AquaVM+Marine+libp2p+event tool)
09:13 Builtins — parts of core protocol, delivered as services
12:01 Integrations with other protocols - IPFS, Ceramic, NEAR, Ethereum
13:03 Documentation overview
PRESENT
14:01 The situation at the end of 2021
15:19 Challenges for 2022
FUTURE
17:27 Aqua. Roadmap towards Aqua 1.0
19:48 Fluence development schedule for 2022 Protocol, DX, community
24:10 Briefly about upcoming events and hackathons
NODES ARCHITECTURE
26:22 Fluence Rust peer node. Sequence diagram and code explanation
54:32 Q&A
59:39 End of meeting
Speakers: Dmitry Kurinskiy, Alexey Pyshnenko
Diagram https://bit.ly/34VjNfH
Community calls wiki https://www.notion.so/fluencenetwork/Dec-16-2021-Community-Call-7-Nodes-Architecture-9855a0a6da714a3cacbc6a247df23b5a
How to start hacking with Fluence https://www.notion.so/fluencenetwork/How-to-hack-on-Fluence-97e20ba47ef04df2bfd0c234ee90537d
Fluence Documentation https://doc.fluence.dev/docs/
Aqua Book https://doc.fluence.dev/aqua-book/
Fluence Quickstart https://github.com/fluencelabs/examples/tree/main/quickstart
Fluence Examples https://github.com/fluencelabs/examples
Discord support https://fluence.chat/
A
B
A
A
A
A
E
A
A
A
To
asynchronous
aqua
virtual
machine
which
had
a
huge
performance
impact,
we
implemented
crdz
streams,
so
data
is
really
crdt.
Now
that
backs
this
aqua
vm
execution,
and
we
introduced
a
few
new
and
very
necessary
aqua
vm
instructions
here:
instructions
on
top
of
aqua
vm
we
have
aqua
and
aqua
is
round
just
since
april.
A
Then
we
delivered
we
implemented,
but
not
yet
delivered
not
yet
announced
marine
web,
the
way
to
run
marine
web
assembly
in
browser
and
node.
This
opens
the
doors
to
have
the
full
featured
fluence
pure
implementation
in
javascript,
which
we'll
do
next
year,
hopefully,
and
there
we
were,
we
made
a
lot
of
more
low
level.
Improvements
like
we
introduced
memory
limits.
So
now
memory
is
constrained
for
marine
and
resource
consumption
is
a
better
man.
Now
we
provided
possible
reference.
A
A
So,
first
of
all
this
year,
like
since,
since
this
summer,
we
have
fluence.js
with
aqua
support,
and
actually
it
serves
as
a
fluent
sphere
for
javascript
and
typescript
developers.
It
runs
both
in
the
browser
and
in
node.js,
and
also
what
we
developed
but
not
yet
announced.
We
implemented
web
workers,
for,
I
think,
aqua,
vm
pool
and
it's
quite
performant,
and
it
means
that
this
fluency
sphere
is
quite
full-featured,
which
is
nice.
B
A
A
A
D
A
You
face
when
you
begin
working
with
a
fluence,
more
high
level
and
this
the
the
basic
solution,
the
fundamental
solution
for
this
problem.
Then
we
developed
and
delivered,
but
not
yet
announced
the
trust
graph.
Implementation
is
described
in
our
rfc
and
basically
it's
a
decentralized
public
infrastructure,
fluence
native
one
that
aims
of
management
aims.
B
A
Beginning
of
the
next
year
to
describe
it
and
to
tell
about
it,
because
it's
a
big
thing,
then
we
implemented
ipfs
integration
and
it's
quite
important
for
us
because,
like
in
general,
it
allows
you
to
transmit
and
store
files
using
ipfs
network
and
then
manage
them
on
the
fluence
network.
Like
do
some
computations,
for
example.
A
A
A
E
A
C
A
C
A
A
C
A
A
And
you
need
to
have
more
things
provided
by
the
network
to
compose
and
currently
to
develop
a
service
and
to
provide
it
to
the
network.
The
only
way
to
do
it
is
to
develop
in
rust,
but
it
creates
an
entry
barrier,
so
we
want
to
have
more
javascript
or
type
street
or
aqua
experience
enabled
for
the
service
development.
A
Second
security
system
is
not
feature
complete.
Currently,
we
need
to
provide
some
cryptography
and
resource
consumption
management
and
such
such
stuff.
And
finally,
we
want
to
enable
the
community
to
make
scalable
web3
native
components
and
like
protocols,
and
to
do
so
we
need
to
enable
more
complex
algorithms
distributed
algorithms.
A
A
A
Stream
canonicalization
and
some
more,
you
can
take
a
look
on
the
aqua
ibm
repository
if
you're
curious
and
these
features
unlock
different
features
of
the
halal
language
of
aqua,
like
abilities,
the
modularization
and
internal
compatibility
approach
of
of
aqua,
lambda
expressions
or
handling
patterns
and
and
more
primitives,
and
the
goal
for
these
language
primitives.
For
this
syntax
and
semantic
is
to
provide
algorithms
and
libraries
which
are
to
be
delivered
in
aqua.
A
So
the
goal
is
to
commoditize
the
development
of
distributed
protocols
by
the
fluence
community
to
make
it
as
like,
as
the
new
domain
influence
tool
set
to
provide
tooling,
to
make
it
simple
to
make
it
stable,
scalable
and
so
on.
So
this
will
be
one
of
the
main
topics
for
the
next
year
and
for
overall
fluency
development
schedule.
A
A
C
A
E
D
D
Sorry
for
the
next
year,
the
plan
is
to
participate
in
more
hackathons
to
post
the
bounties
to
engage
people
more
in
in
the
fluence
tech
and
building
projects
with
fluence.
The
nearest
hackathons
we
are
going
to
have
is,
if
denver
in
in
february.
If
anybody
is
going
there
offline,
let's
meet
offline,
there
are
going
to
be
a
week
of
events.
D
If
you
are
not
going
to
be
there,
they
will
have.
Also
online
version
is
one
week
of
hacking.
We
will
be
posting
all
the
news
about
that,
and
also
we
are
planning
to
do
a
hackathon
in
person
hackathon
in
moscow
during
the
next
year
and
more
news
to
come.
We
will
we
will
post
everything
in
our
channels,
and
I
want
to
thank
everyone
who
who've
been
with
us
during
this
year.
It
was
amazing
and
yeah.
Let's
keep
it
going.
Thank
you.
C
B
B
B
So
what's
what
peers
influence
network
do
most
of
the
time
they
exchange
particles?
So
when
a
user
sends
some
one,
when
a
user
wants
to
execute
something
on
flynn's
network,
she
writes
aquascript,
compiles
it
and
sends
to
the
network
and
that
to
send
to
the
network,
it
means
to
connect
to
some
peer
and
send
particle.
So
that's
the
first
steps
that
we
see
here.
B
B
Some
call
results,
some
routing
results.
All
this
goes
to
data
that
makes
particle
stateful
and
time
to
life.
It
says
how
many
seconds
milliseconds
should
be,
should
a
particle
leave
after
it
was
sent.
For
example,
I
can
say
here's
a
particle,
send
it
to
the
network
and
say
this
particle
should
be
executed
for
60
seconds
or
less
like.
If,
if
it
somehow
looped
or
something
happened,
and
it
executes
more
than
60
seconds,
then
all
peers
will
just
drop
it.
B
Usually
our
peer
receives
a
lot
of
particles
and
it
should
maintain
some
performance
levels
from
some
latency.
Some
latency
should
be
manageable,
so
users
can
receive
their
response.
Timely
and
their
ui
works
smooth
smoothly.
So
for
that
we
use
a
few
cues.
Basically,
what
fluent
spears
is
it's
a
queue
and
a
big
big
loop?
You
can
see
it's
it's
a
big
one
here,
so
we
have
a
particle
q.
It's
called
it's
inside
an
entity,
that's
called
dispatcher,
it
dispatches
particle
execution
and
all
that
follows
it
has
a
single
key.
B
Then
it
has
a
particle
cube
and
a
big
big
loop
that
dequeues
from
the
particle
from
that
queue
and
executes
particles
concurrently.
So
it
has
some
threads.
Some
some
are
parallel
and
concurrent
execution
and
all
particles
they
execute
at
the
same
time
until
the
tread
pull
is
saturated.
So
it's
like
16
particles.
At
the
same
time,
if
you
have
eight
cores
or
something
like
that,.
B
So
one
dispatcher
sees
a
new
particle
in
the
queue
it
takes
it
and
sends
to
execution
to
accommodate
pool
what
is
aquamarine.
It's
a
layer
of
execution
for
particles.
So
it's
it
takes
a
single
particle,
finds
some
executor
for
it
and
executes
it
interprets
the
script
applies
the
data
to
that
script
and
gives
some
results
back.
B
What
kind
of
results
come
out
of
particle
execution?
Two
kinds
of
results?
First,
one
is
where
to
send
particle
next
and
second,
one
is
what
to
do
with
that
particle
like
call
some
code
or
or
do
nothing
just
forward
it
to
some
other
beer
in
the
network,
so
to
execute
the
particle
in
a
way
that
still
maintains
good
performance
on
the
node.
We
need
to
have
several
executors
each
execute.
B
A
particle
executor
is
called
aquavium,
that's
basically
an
interpreter
in
webassembly
and
the
webassembly
runtime
together
they
receive
particle,
execute
its
script
and
return
results
back.
We
have
a
whole
pool
of
such
executors,
like
on
on
every
node.
There
is
8
or
16,
depending
on
number
of
cores
of
such
executors.
That
means
that
we
can
simultaneously
execute
8
or
16
particles.
B
Now,
in
order
all
particles
have
id,
like
all
particles
has
particle
ids.
It
should
be
like
here
as
a
fourth
field.
That
means
that
the
same
particle
can
go
to
the
same
peer.
Several
times
like
I
receive
this
particle,
send
it
to
other
peer.
It
sends
it
back,
and
that
could
happen
like
simultaneously.
B
B
And
that
poses
a
problem.
If
we
are
to
execute
particle
with
the
same
id
concurrently,
then
we
will
have
data
rays.
We
will
raise
on
the
field
on
this
data
field
in
the
top
left
corner
and
in
order
to
avoid
that
we
introduce
actors,
actor
is
created
per
particle
id.
So
if
we
receive
a
lot
of
particles
with
the
same
id,
they
all
go
to
the
same
actor.
B
B
So
what
we
see
here
when
particle,
when
actor
receives
a
particle,
it
asks
the
executor
pool
for
a
free
executor
for
a
free,
aqua
vm
when
it.
If
there
is
a
free,
aqua,
vm
it's
allocated
for
that
actor
and
actor
can
begin
the
execution
it
submits
script
and
data
to
the
executor
to
the
aquarium.
Aqua
vm
interprets
air
script
and
returns
result
back.
As
I
said,
there
are
two
kinds
of
results:
it's
either
next
peers
to
forward
particle
two
or
service
calls.
B
That's
basically
some
code
execution,
so
every
particle
it
could
be
either
routed
further
to
the
network
or
trigger
some
code
execution
locally
or
both.
That's
how
particles
that's
two
effects
of
particles.
First,
one
is
network
effect,
send
me
somewhere
and
second,
one
is
code.
Execution
effect
like
do
something
right
here.
B
Now,
for
each
of
the
service
call
of
the
service
calls
we
execute
them
concurrently
on
the
same
node.
Basically,
in
the
same
actor,
we
execute
all
the
call
server
all
the
service
calls
in
parallel.
If
we
have
free
threads
that
can
take
this
work
so,
for
example,
it
could
be
at
the
same
time
it
could
be
some
operation,
like
sql,
write
to
one
database
and
at
the
same
time
read
from
registry
some
value
and
those
two
operations
they
can
happen
at
the
same
time.
B
They
don't
depend
on
each
other,
so
their
par
can
be
paralleled
and
that's
what
happens
that
allows
for
higher
throughput
of
code
execution.
That
means
that,
even
if
a
script
contains
a
lot
of
operations
on
the
same
peer,
they
will
all
execute.
At
the
same
time,
that's
a
pretty
pretty
novel
thing
to
have
in
our
peer,
because
previously
it
was
all
synchronous
like
several
months
ago.
It
was
all
synchronous
so
and
it
caused
some
performance
troubles
like
q.
B
Wasn't
wasn't
dequeued
fast
enough
and
particles
were
all
struggling
in
that
queue
and
timeouts
happening
now.
It
doesn't
happen
because
we
process
the
particles
asynchronously
and
we
don't
clog
the
cues
okay,
so
particle
gave
us
some
service
calls
to
execute
and
we
executed
them
concurrently.
It
also
gave
us
some
next
peers
to
forward
particle
2.
B
B
This
situation
actually
is
a
little
bit
more
complex
because
when
dispatcher
receives
a
network
effect
like
a
forward
particle
somewhere,
it
has
to
find
that
beer
yeah.
So
we
have
like
a
network
effect,
that's
a
particle
and
the
list
of
peer
ids
and
those
peer
ids.
They
might
not
be
yet
connected
to
our
peer,
so
we
have
to
find
them
for
that.
We
use
kadamli,
it's
not
visible
on
this
diagram
because
it
would
be
too
much
it's
already
too
much.
B
B
Okay,
so
what's
what
else?
I
found
really
interesting
about
this.
The
particle
execution
is
this
piece
or
the
14th
step
that
I
haven't
described
yet
so
when
we
execute
service
calls
some
code
that
particle
has
asked
us
to.
We
need
to
re-enqueue
particle
back
to
the
actor
yeah.
So
like
that's,
because
when
we
execute
some
code,
we
go
through
the
script
like
we
execute
one
line
in
the
script.
It
asks
us
to
write
something
to
database.
B
And
that
means
that
when
we
execute
some
code,
we
get
result
back
and
we
write
that
result
to
the
data
almost
like
that
to
the
data,
and
we
submit
the
particle
back
to
the
executor.
And
this
way
we
progress
through
the
script
line
by
line
or
by
several
lines
if
they
are
marked
as
parallel
and
can
be
executed.
Concurrently,.
B
What
that
means
is
that
we
have
here
a
loop
that
can
go
on
almost
forever
until
ttl
expires,
because
when
we
go
further
through
the
script,
when
we
progress
through
the
script
code,
it's
possible
that
we
receive
more
call
service,
calls
and
more
next
peers.
So
every
iteration
of
the
particle
execution
could
could
yield
more
next
peers
and
say:
send
this
particles
further
to
the
network
and
execute
more
code
and
that's
a
process
that
can
go
for
a
long
time.
B
B
So
that's
basically
the
whole
diagram
we
have
here
how
much
time
I
have
well,
let's
try
to
take
a
look
at
the
code
that
that
implements
this
diagram.
So,
as
you
may
know,
fluence
p
influence
peers.
They
use
lib
p2p
to
communicate
in
case
of
rust,
fluent
spear
where
we
use
rastly,
p2p
rustly
p2p
defines
a
very
it
has
a
very
interesting
architecture,
it's
kind
of
like
actors
and
delegates
on
at
the
same
time.
B
So
what
we
have
here,
if
we
have,
we
have
network
behavior
trade
if
you're
familiar
with
rust,
it's
just
like
if
you're
not
familiar
with
rust,
it's
almost
like
an
interface
so
and
it
this
interface
defines
a
few
methods
that
we
implement.
First
of
all,
we
implement
inject
connect.
That
means
that
that's
a
method,
that's
called
when
someone
connects
to
us
it's
the
first
step
here
in
the
diagram
we
receive
connection
from
that
peer
id.
We
we
like
write
it
down
and
we
now
remember
that
we
were
connected
to
that
beer.
B
The
second
point
on
the
diagram
is
receiving
of
particles.
Here,
that's
a
method
for
that.
We
have
a
method.
That's
called
inject
event
when
it's
called
that
means
that,
from
this
peer
id,
we
received
the
following
event:
the
event
is
usually
particle.
It
could
be
some
errors
or
something
else,
but
most
of
the
time
it's
a
particle.
So
what
we
do
we
put
particle
to
the
queue
and
we
ask
threadpool
to
wake
up
and
send
and
trigger
us,
because
each
connection
pull
connection
pool
on
the
node.
It's
like
a
stream.
B
What
we
do
here
is
we
look
at
our
queue
that
we
just
enqueued
the
particle:
it's
a
local
queue
and
if
we
have
a
particle
there,
we
send
it
to
the
dispatcher.
That's
exactly
what
happens
here.
We
have
connection
what's
described
here.
We
have
connection
tool
and
we
send
particle
to
dispatcher
it's
a
usual
rust
channel
like
in
go.
They
have
channels,
and
in
rust
we
have
channels
too,
almost
everywhere
in
every
programming
language.
We
have
something
like
this.
B
B
Now,
let's
take
a
look
at
the
aquamarine
layer,
what
we
have
here
here,
we
also
have
a
few:
it's
called
inlet,
meaning
that
it's
a
like
a
receiving
port.
It's
a
queue
basically,
and
we
take
particle
from
that
queue
and
we
ingest
it,
meaning
that
we
now
are
creating
the
r
actor
if
it
didn't
exist,
yet
we
either
find
it
or
create
if
it
not.
If
it's
not
exist
distant
and
we
say:
hey
actor,
please
ingest
this
particle
and
actor
ingests
the
particle.
B
Where
is
the
ingest
method
here?
It
is
and
it
puts
the
particle
to
the
mailbox.
So
you
see
we
have
everything
in
queue
like
we
have
a
lot
of
q,
like
a
q
for
each
layer,
we
have
a
q
for
each
layer,
okay
and
this
particle
this
actor.
It
acts
also
as
a
string,
meaning
that
it
has
a
pole
method.
That's
that's
called
by
the
thread
pool
asking
actor
to
progress
in
the
particle
execution
and
what
we
do
here
we
take
from
our
mailbox.
B
B
B
And
all
of
them
could
be
pc
or
all
of
them,
except
one
could
be
busy
and
we
then
we
take
this
one
and
send
that
executor
to
the
actor.
So
it
can
use
it,
but
if
actor
is
already
busy,
it
just
returns,
it
back
says
I'm.
I
can't
execute
more
particles
right
now,
because
we
need
in
actor.
We
need
to
guarantee
sequential
execution.
B
Okay,
so
if,
if
an
actor
is
ready
to
execute
particle,
it
executes
it,
it
sends
it
to
the
aquarium.
As
on
the
said
on
the
diagram,
aquavium
executes
it
asynchronously,
and
this
execution
yields
a
feature.
It's
like
a
javascript
promis
scala
future,
it's
as
a
notion
of
asynchronous
computation
and
is
executing
like
works
by
taking
that
future
is
set.
B
First,
one
I
already
described
it
asks
actors
to
take
next
particle
and
the
second
one
asks
actor
to
return
results
back
if
it
if
it
already
executed
the
particle,
so
it
just
pokes
future.
It
says:
hey
future.
Are
you
already
finished
and
if
you're
finished,
please
give
me
back
network
effects
and
I
will
roll
the
particle
further
through
the
network.
B
All
the
service
call
execution
is
encapsulated
inside
actor.
It
happens
here.
If
particle
yielded,
only
service
calls
but
didn't
yield
any
any
next
peers.
It
will
keep
executing
until
either
yields
nothing
at
all.
Then
it
will
stop
execution
or
until
it
returns
network
effects.
In
that
case,
it
will
rot
the
particle
further
in
the
network
yep.
B
What's
the
built-ins
built-ins
is
a
this
big
switch
case,
but
big
pattern
matching
thing
that
defines
all
the
built-in
api
of
the
node
like
in
influence.
You
call
service
by
service
id
and
by
function.
Name,
like
you
say,
for
example,
you
say
a
survey
list,
meaning
that
you
want
to
see
all
the
services
running
on
the
node
on
the
pier
right
now.
B
Or
you
can
ask
the
peer
to
do
nothing.
In
that
case,
you
just
say
op
nope,
and
it
will
just
do
nothing.
Sometimes
it's
useful
and
things
like
that.
That's
the
whole
api
of
the
built-ins
that
we
have
on
the
no
on
the
rust,
pier
it's
almost
the
same
on
the
flynn's,
js
piers,
except
that
fluence
js
doesn't
have
cadamilia
and
it
doesn't
have
the
srv
and
this
namespace
because
it
until
we
have
marine
web
on
the
fluence.js,
we
can't
create
new
services
from
webassembly.
B
Okay
and
in
case
none
of
the
built-ins
matched
to
the
service
id
function.
Name,
we
go
and
check
for
the
created
webassembly
services
they
created
webassembly
services
have
their
ids
in
the
form
of
huge,
unique,
universally
unique
identifiers.
So
it's
basically
a
long
string
with
alphanumeric
and
dashes
and
a
function
name.
B
B
B
B
You
see
it's
just
a
stream
where
each
item
is
effect,
which
is
always
a
network
effect
which
is
as
said
here
just
a
particle.
We
have
a
list
of
peer
ids,
okay,
so
for
each
effect,
what
we
do
is
we
execute
it
very
simple:
we
do
it
concurrently
and
executing
an
effect
means
that
we
what
we
do
here,
we
resolve
the
resolve,
resolve
the
target
period
for
condemning
and
once
we
resolved
it,
we
send
ask
connection,
pool
to
send
the
particle
to
resolved
peer.
Id
result.
B
Peer
id
means
that
we
from
peer
id
we
receive
back
peer
id
and
multi
address
like
ip4.
Some
ip
address
port
things
like
that.
So
we
basically
look
for
the
network
address
on
the
academia
and
connect
to
the
peer,
and
then
we
can
send
particles
and
that's
it
that's
how
the
fluence
rust
peer
works
for
the
transgress
peer
it.
It's
almost
the
same
in
case
of
aqua
vm
executors.
We
have
web
workers
now.
B
B
Also,
we
have
webassembly
services
that
can
be
deployed
on
demand
and
also
we
can
name
this
webassembly
services
and
give
them
human
readable
names.
For
example,
we
can
deploy
some
webassembly
service
and
it
will
have
id
of
ueet
long
alphanumeric
id,
and
then
we
can
say
hey,
please
add
alias
for
this
service
id
and
if
someone
writes
aqua,
ipfess
know
that
aquafest
corresponds
to
this
big
big
alpha
numeric
id
and
it's
called
service
aliases
and
every
node.
Every
fluence
trust
node
is
capable
of
starting
webassembly
services
of
deploying
them
on
node
start.
B
So
when
node
starts,
it
downloads
service
package
from
this
url
and
deploys
it
and
assigns
this
alias
to
it,
and
that
makes
a
service
a
built-in
in
the
sense
that
when
you
run
a
node,
it's
deployed
immediately
or
just
restarted.
If
you
restart
the
node
and
it's
always
available,
you
can
always
go
and
use
ako,
epfs,
aqua,
dht
that
will
be
called
registry
soon
and
trust
graph
they
are
built
in.
B
So,
regarding
the
curl
there,
it's
a
little
bit
different
story
because
they
are
available
on
the
github.
You
can
download
their
webassembly
files
from
url
and
deploy
through
the
through
this
api.
You
can
create
a
service
that
uses
coral
web
assembly
inside
that
links
against
it
and
uses
coral
function
in
your
service
service
and
it's
always
available
because
you
can
always
download
it
from
github
upload
to
ipfs
and
deploy
on
the
flintstone.
C
Did
I
answer
your
question?
What
I
actually
meant
was
so
this
is
great,
so
we
got
these
free,
pre-build,
webassembly
modules
right
ready
for
deployment,
but
the
actual
resource
is
not
provided
by
the
node.
The
actual
resource
is
provided
by
the
underlying
operating
system
right,
so
the
curl
service
is,
is
provided
by
a
layer
below.
B
Well,
yeah
binary,
binary
yeah.
When
you
have
a
web
assembly
module,
you
have
service
and
services
consist
of
webassembly
modules
and
each
webassembly
module
is
able
to
call
binaries
that
are
available
on
the
operating
systems.
File
system,
like
you,
can
call
you
can
call
curl
or
you
can
call
echo
you
can
call
ipfs
binary.
You
can
call
whatever
you
want
if
you
write
a
webassembly
wrapper
around
it.