►
Description
Speaker Dmitry Kurinskiy
Host Bernhard Borges
Slides & calls wiki https://www.notion.so/fluencenetwork/Jan-27-2022-Community-Call-8-How-Aqua-language-and-Fluence-network-enables-the-transition-from-8458e31bf1db41808dc4cb32a301cb58
A
All
right,
I
guess
it's
five
after
I
guess
we
can
start
the
call
well
welcome
everybody
to
our
first
2022
community
call
today
the
agenda
is,
we
have
mitri,
give
an
overview
of
the
recent
tech
advances
because
guess
what
we
actually
work
through
the
holidays,
we're
super
productive
and
have
a
lot
to
report
and
take
questions
and
answers.
I
don't
think
we
have
any
community
projects
today,
right
anna.
A
B
D
So
we
have
a
huge
update
of
all
the
stack
from
the
network
marine
marine
web.
We
updated
lip
b2p,
we
did
a
lot
of
aqua
updates
and
huge
refactoring
and
everything
should
arrive
next
week
and,
let's,
let's
discuss
it
after
that-
and
maybe
we
can
even
have
the
dedicated
community
call
next
time
just
to
cover
the
updates.
B
B
B
B
A
B
A
E
Well,
what
I've
been
working
now?
There
are
actually
metrics
collected
from
the
fluence
nodes,
and
you
soon
will
be
able
to
see
them
on
grafana's,
pretty
dashboards,
and
I
think
we
will
even
publish
it
at
least
some
in
read-only
mode.
So
there
will
be
nice
graphs,
nice,
colored
numbers
and
different
insights
into
the
inner
workings
of
the
fringe
network.
That
would
be
nice.
E
F
E
A
E
It's
already
available
for
private
network
right.
So
if
you
bring
up
a
local
network,
you
can
just
it
will
publish
prometheus
metrics,
so
you
will
have
to
bring
up
prometheus,
it
will
read
metrics
and
you
can
start
grafana.
All
dashboards
are
public,
like
configuration
for
dashboards,
so
you
can
just
copy
paste
everything
and
it
will
be
the
same
always.
E
G
G
G
A
F
Yes,
but
I
have
a
pure
internet
connection
today,
so
story
for
possible
walks
after
last
call
that
was
probably
in
december,
like
here
here
like
we
have
a
huge
progression
here
so
now,
scours
in
scours
are
supported
in
lambdas,
then
we
fixed
several
bugs
in
aquarium
now.
So
now,
I'm
working
on
a
memory
footprint,
while
this
in
memory
footprint,
interpreter
and
also
investigation.
F
Yeah
well,
like
bernard
bernard,
so
gives
me
the
first
version
of
the
communication
for
marine
and
now
we
are,
we
are
working
on
a
memory
consumption
and
when
we
release
our
network
we
will
mention
and
we
will
be
released,
so
I
mean
the
reason
I
mean
that
video
released
memory
limits
in
our
network.
Then
we
fight
and
we
will
conquer
this
problem.
F
C
A
H
Hi,
it's
yura
I'd
like
to
just
check
in
to
say
I'm
still
here
and
I'm
still
interested
in
working
as
well.
I've
missed
the
last
calls,
but
you
know
I'm
still
here,
maybe
next
time
or
the
time
after
I'd
like
to
present
what
I'm
working
on.
I'm
almost
done,
but
I
just
found
a
bug,
and
so
now
I
just
dismantled
everything.
So
I
can't
show
you
anything
at
the
moment.
H
H
D
A
H
So
there
is
a
recurring
script
running
on
a
fluence
node
that
listens
to
that
particular
event
and
then,
when
the
event
comes
in,
it
pulls
like
every
30
seconds
and
when
it
sees
that
a
new
vote
has
been
made.
It
goes
to
the
graph
to
collect
all
the
data
on
the
proposal
and
then
makes
a
sort
of
a
widget
or
in
html
for
it
and
yeah.
H
I'm
almost
done,
but
now
I
found
a
bug
and
and
the
cool
things
about
what
what
I'm
learning
about
how
to
work
is
that
basically,
every
time
the
script
runs
so
every
30
seconds
I
I
make
it,
I
have
it,
create
all
the
services
and
then,
at
the
end
of
the
you
know,
at
the
end
of
the
run.
It
just
removes
all
the
services
again
and
there
is
the
bug
now
because
it
just
keeps
on
creating
services.
H
H
A
H
H
H
Basically,
so
so
that's
very
easy
for
me
to
always
be
able
to
lock
from
out
from
a
surface
to
a
central
place,
so
I
can
just
see
where
all
the
errors
are
and
and
as
as
I
told
you,
because
I
can
update
these
surfaces
while
the
script
is
running
I
can.
I
can
just
insert
like
logs
while,
while
this
script
is
running
just
to
see
how
far
it
goes-
and
you
know
where
the
error
might
be.
B
A
A
Well,
I
I
got
nothing
else,
so
I
think
I
exhausted
everybody
on
the
team
and
and
in
the
audience
as
well.
Thank
you
terrer
and
we'll
do
it
again
in
two
weeks
and
then
I
think
we're
gonna
have
a
lot
of
updates
and
we're
also
gonna
have
some
probably
more
feedback
from
the
hackathons.
Some
results
and.
A
I
C
D
D
To
use
it
efficiently
and
we
have
a
lot
of
products
like
the
one
that
we're
using
right
now,
which
merges
from
this
setup
and
now
probably
we're
switching
to
web
three.
But
let's
discuss
why
we're
doing
it,
and
what
does
this
mean
and
let's
discuss
it
in
comparison,
web
2
and
web
3?
What
we
had
what
we
have
and-
and
why
so,
first
of
all,
let's
speak
about
the
common
web
to
distributed
approach.
D
D
D
I
want
it
to
be
maintainable
and
I
want
to
decouple
life
cycles
of
different
parts
of
my
service.
So
that's
about
decoupling
and
composition
and
the
compound
approach
is
microservices,
so
I
can
reuse
microservices
in
different
languages.
I
can
wire
them
together
and
so
on.
That's
another
motivation.
D
D
D
So
that's
why
I
want
to
be
distributed
cool
and
why
won't
would
I
want
to
have
something
in
web3
so
web3?
First
of
all,
what
is
it
it's
about
being
peer-to-peer
not
just
distributed,
but
more
decentralized?
More
peer-to-peer
more
permissionless,
so
the
motivation
for
web3
first
of
all
is
economy
and
governance.
D
It
doesn't
always
mean
to
make
money,
but
it
means
that
you
have
the
new
ways
to
create
something
and
to
scale
something
and
that's
that's
important,
and
then,
after
the
economy,
there
are
different
properties
that
are
also
nice
to
have
and
which
actually
make
the
web.
Three
were
three
like
no
single
point
of
failure:
no
vendor
lock-in,
that's
nice
and
that's
a
property
of
a
peer-to-peer
web.
Three
permissionless!
D
If
you
build
a
peer-to-peer
network,
if
you
make
it
accessible
to
everyone,
if
you
make
it
open
source,
then
it
means
that
you
open
the
doors
for
creativity
and
the
community
can
be
involved
if
you
build
another
cloud
or
another
api
and
so
on.
There
is
no
incentive
to
be
involved,
because
we
have
so
many
cases
when
enterprises
uses
the
community
creativeness
and
then
that
closes
the
door.
D
D
D
D
D
D
Usually
you
have
some
kind
of
mailboxes
and
for
mailboxes
you
have
managed
queues,
kafka
and
so
on
to
connect
different
parts
of
the
application.
You
have
persistence
and
for
persistence.
You
have
many
choices
like
key
key
value
stores,
journals,
write,
catalogs,
different
databases
for
any
shape
of
data,
and
so
on
then,
for
scaling
and
operations.
You
have
kubernetes
for
service
discovery,
you
have
console
and
generally
speaking,
you
have
dns
and
so
on,
and
you
have
data
centers
virtual
networks
for
connectivity
between
them,
some
side,
cars
for
connectivity
like
easter
and
and
so
on.
D
So
basically
I
can
decompose
the
problem
of
a
distributed
web
2
back
end,
and
I
know
how
to
start-
and
I
know
why
why
everything
will
be
okay
and
I
don't
need
always
to
get
everything.
But
if
I,
if
I
take
almost
any
approach,
probably
it
will
have
some
solutions
for
every
part
of
that,
for
example,
if
you
take
actor
system,
then
it
has
its
own
mailbox
for
every
actor.
You
have
mailbox,
you
can
switch
on
persistence
and
have
right
head
log.
D
D
If
I
don't
need
to
have
discovery,
if
I
have
a
white
list
or
if
I
don't
care
where
to
connect,
because
every
node
every
peer
every
service
has
the
same
state
like
with
the
blockchain,
then
I
need
to
to
live
with
that.
This
decision
will
last
with
me
and
it
will
constrain
me
like
what
can
and
what
and
what
cannot
be
done.
D
And
when
I
consider
security,
then
I
need
to
switch
to
the
second
part
with
many
questions
which
change
the
design.
The
system
design
of
my
network
dramatically
like
what
state
is
needed
and
what
exact
state
is
needed
and
how
exactly
I
want
to
to
make
it
available.
What
guarantees
do
I
need?
What
latency
do
I
need
and
so
on
then
the
question
for
my
website
application:
can
it
be
deterministic?
D
If
I
don't
want
to
be
deterministic,
then
the
question
is
how
to
synchronize
my
peers:
do
they
want
to
have
eventual
consistency
or
no
consistency
or
how
to
approach
it
and
what's
the
right
algorithm
at
this
point,
I
can
think
about
the
network
algorithm
and
then
the
question
is
okay.
I
have
this
notes,
but
what
is
the
business
model?
How
can
I
make
the
development
self
sustainable,
and
how
can
I
incentivize
the
community
to
like
to
to
provide
creativity
to
commit
into
into
this
web
three
project?
D
How
to
distribute
the
tasks
and
like
that's
another
question,
and
we
have
some
solutions.
For
example,
you
can
have
inflation
or
you
can
have
a
mining
reward,
or
you
can
have
something
that
like
that.
But
for
every
solution
you
have
constraints
and
there
are
not
so
many
choices
here.
Actually
and
finally,
after
I
considered
security,
and
I
keep
it
in
mind
and
then
I
made
a
lot
of
decisions
on
the
domain
of
my
web3
application.
D
It's
not
not
very
trivial.
It
does
match
all
the
cases.
If
you
decided
to
to
choose
a
blockchain,
then
you
have
a
throughput
that
also
limits
the
scale,
and
this
throughput
can
be,
can
be
big
and
different.
Blockchains
compete
with
each
other
for
like
a
number
of
transactions,
and
it's
still
not
not
billions,
you're,
still
limited,
and
then
the
question.
D
D
D
D
D
The
the
easiest
way
is
to
not
be
able
to
solve
how
and
if
you
don't
solve
the
how
of
web
three,
how
exactly
to
build
your
system?
How
exactly
to
approach
your
business
opportunity,
then
there
could
still
be
an
opportunity
to
create
a
web
to
business.
Like
sas,
and
we
have
some
cases
when
we
see
that
web
three
specific
problems
are
fixed
by
centralized
web
to
driven
businesses,
the
most
important
example
is
in
fura.
It
fixes
some
problems
with
the
ethereum
by
providing
a
web
2
driven
sla.
D
D
D
And
often
we
see
that,
for
example,
for
infuria,
we
have
alchemy
right
and
we
have
something
like
network,
and
I
know
about
a
lot
of
different
approaches
to
decentralize
this
ethereum
access,
but
with
the
with
no
luck.
No
luck
compared
to
infuria,
because
it's
very
hard
to
to
build
to
maintain
to
evolve,
because
there
are
many
questions
how
to
do
it
still.
D
Would
be
nice,
would
it
be
nice
to
bridge
the
worlds?
And
what
does
that
mean?
It
means
that,
ideally,
we
want
to
get
wise
both
of
web
2
and
web
3..
Why?
Both
because
we
are
doing
web
to
kind
of
distributed
development
in
a
distributed
way
and
we
approach
this
distributed
setups
with
a
specific
disrupted
mindset
and
web
3
is
essentially
another
kind
of
a
distributed
network.
D
It's
not
not
closed,
it's
open,
but
essentially
we
still
have
this
fault,
tolerance,
requirements,
scalability
and
so
on.
Why
do
I
say
so
on
maintenance,
scalability
and
duography,
or
something
like
that,
so
we
want
to
have
this
still,
but
also
to
be
weaponry
specific
and
to
get
the
opportunity
of
of
the
new
web.
You
want
to
get
wise
of
web
3..
D
D
D
So
how
can
we
approach
these
problems
with
the
with
aqua?
First
of
all,
we
take
the
theory
of
web
2,
especially
p
calculus
lambda
calculus.
We
use
signatures
all
around
and
we
build
everything
from
from
ground
up
with
security
in
mind,
and
this
means
that
in
many
scenarios,
when
you
had
to
keep
security
in
mind
just
to
to
get
from
from
the
like
blank
page
to
hello
world
for
your
application,
now
you
can
focus
on
the
hello
world
or
on
the
application.
D
D
So,
for
example,
with
aqua
you
can,
you
can
have
discover
primitives
like
in
web
2.
We
have
many
developed
projects
which
evolved
over
decays
or
at
least
years
like
console,
zookeeper
or
dns,
and
a
console
means
that
you
have
a
consensus
based
on
raft
consoles
is
essentially
a
raft
algorithm
and
nothing
more
and
zookeeper
is
the
is
what.
D
Boxes
right,
it's
also
that
the
algorithm
and
both
algorithms
can
be
implemented
in
aqua
for
non-global
discovery
for
application,
specific
discovery,
but
generally
aqua
influence
provides
for
web3.
First
of
all,
academia,
and
currently
we
are
using
the
lip
b2p
implementation
of
kadamlia,
but
we
we
are
going
to
switch.
D
We
are
going
to
switch
to
aqua
and
marine
implementation,
the
fluence
native
implementation
of
academia.
We
want
to
switch
to
our
own
implementation
of
cadenza,
not
because
it's
fun,
but
because
in
this
case
the
community
will
be
able
to
plug
the
custom
logic
into
academia
and
use
academia
to
form
sub
networks
for
the
particular
products.
D
So
it
lowers
the
barrier
dramatically
because
you
don't
need
to
run
your
own
network
to
have
your
own
network.
You
can
deploy
a
sub
network
on
existing
nodes
and
you
can
prioritize.
They
discovered
the
connections
between
these
nodes
over
the
the
general
usage
we
have
registry,
it
previously
was
known
as
aqua.ht.
D
D
D
D
D
D
Stage
synchronization
in
web
2,
we
have
a
databases
of
any
skill
for
any
data
shape
like
we
have
anything
for
web
3
is
much
harder,
but
we
have
blockchains
big
and
small
of
various
shapes
and
different
algorithms
and
with
aqua
influence
you
can
proxy
requests
to
to
blockchains.
You
can
delegate
state
synchronization
to
blockchain.
If
you
want
to,
and
it
could
be
ethereum
you
can
read
from
ethereum,
you
can.
D
C
D
And
logic
in
web
2,
we
have
a
huge
number
of
languages
frameworks
and
we
have
a
lot
of
open
source
and
we
have
a
lot
of
closed
source
like
rest,
apis,
different
software
as
a
service
and
so
on,
and
you
can
just
build
your
application
from
from
that
things
in
a
in
a
web
to
world
and
often
that's
the
only
thing
you
need
to
do
just
to
wire
different
existing
apis
together
for
web
3.
Everything
is
is
a
bit
harder
because
you
know
about
the
problem
of
blockchain
bridges.
D
For
example,
it's
not
not
trivial
to
get
data
from
one
storage
to
another
storage.
If
you
consider
a
blockchain
as
a
storage,
for
example,
but
with
aqua
and
marine,
you
can
access
apis
and
services
from
from
aqua
and
you
can
bring
services
or
you
can
bring
existence
existing
code
bases
to
this
web3
setup,
which
sometimes
very
efficient
and
like
good,
that's
what
we
did
with
the
ipfs.
D
For
example,
we
brought
the
ipfs
api
or
cural
api
to
to
aqua
and
it
can
be
reused
in
various
scenarios
with
help
of
of
marine
essentially
and
for
the
new
logic
for
the
new
problems
and
new
domains
or
yeah
you
can
you
can
use
marine
or
whatever
something
around
time
and
to
have.
You
can
have
a
security
and
portability
of
the
code
execution
out
of
the
box,
so
with
marine
you
can
run
the
code
on
on
the.
C
D
D
The
next
problem
is
operations
and
scalability
in
web
2.
We
have
a
lot
of
tools
like
terraform,
kubernetes,
docker
and
so
on
for
web
3.
It's
time
to
replace
docker
with
web
assembly
and
with
marine.
We
have
effects
access
with
the
help
of
webassembly,
because
it's
sandbox
that
it's
secured
and
it's
safe
to
expose
the
capabilities
of
the
node
to
the
outer
world
with
the
with
web
assembly.
It's
much
much
more
secure
than
doing
doing
so
with
docker.
D
Then
a
couple
of
words
about
developer
experience
in
web
2.
We
have
a
lot
of
tooling
to
to
protect
from
from
common
bugs
and
problems,
and
usually
this
is
a
this
critical
just
super
critical
to
have,
for
example,
akka
started
untyped,
but
his
development
with
a
untyped
akka
is
barely
doable.
He's
super
hard,
it's
extremely
hard
and
not
a
lot
of
people
can
can
do
it
without
the
proper
typing
and
the
proper
patterns.
D
So
I
believe
that
if
we
want
to
commoditize
web3
development
and
if
you
want
to
make
it
accessible
to
people
and
to
unlock
the
possibilities
of
these
different
businesses
with
the
web
3
values,
we
need
to
to
provide
the
developer
experience
that
is
close
to
the
solutions
to
the
web.
To
solutions
that
aims
on
the
same
problem
and
also
speaking
about
developer
experience
distributed
part
is
separated
from
computations,
just
like
with
the
workflow
management
languages
in
web
2.
D
D
D
We
need
to
have
distributed
algorithms
as
libraries
and
we
need
to
have
composibility
on
language
level
and
that's
what
we
have
with
aqua,
and
this
means
that
you
can
distribute,
distribute
problems
between
different
developers
and
different
developers
with
different
interests
and
backgrounds
can
benefit
from
the
stack
and
can
add
the
value
to
the
stack
so
and
to
wire
everything.
Together.
D
You
can
do
you,
you
have
a
simple
mailbox
for
every
service
on
every
period,
but
it's
kind
of
limited,
just
like
in
inaka.
The
built-in
mailboxes
are
very
simple,
but
with
aqua
you
can
do
the
more
complex
patterns
like
back
pressure,
pulling
persistence
and
so
on,
and
probably
the
generic
solution
for
this
problem
of
mailboxes.
D
But
the
simple
solution
is
already
here
with
the
service
mail
boxes,
then
there
is
a
problem
of
shadower
when
you
need
to
shuttle
the
jobs
and
to
distribute
to
the
workload
among
the
peers
in
web
2.
We
have
a
lot
of
solutions
in
web.
3
affluence
provides
scheduler
for
aquascripts,
it's
very
simple.
It
just
runs
some
script
currently
and
it's
probably
the
the
most
primitive
schedulers
of
web
2
like
the
built-in
archive
scheduler,
for
example,
more
complex
things
to
be
invented.
D
So
it's
already
here
as
a
fundamental
solution,
but
needs
to
be
improved
at
least
and
for
economy
for
the
connection
with
all
the
all
the
new
economy,
it's
more
about
fluency
than
about
aqua,
but
in
web
2.
When
you
begin
the
new
projects,
you
have
a
lot
of
options
like
subscriptions
application
marketplaces
and
for
web
3.
You
also
have
some
options
like
crypto
dolls,
or
something
like
that.
D
We
want
to
implement
some
some
mechanics
later
as
a
part
of
the
fluency
stack
but
dials.
If
you
have
a
dial
on
on
some
blockchain
with
a
limited
effort,
you
can
connect
this
down
to
fluence
periods
with
a
like
managed
whitelist,
for
example,
and
that's
planet.
That's
not
not
work
in
progress,
but
will
be
soon
and
that's
also
important.
D
D
That's
a
tiny
snippet
of
a
hello
world
made
trivial
finally
and
trying
in
a
web
3
peer-to-peer
fashion
in
four
lines
of
code,
so
it
seems
very
simple.
You
say
that
you
want
to
call
some
function
somewhere
and
you
want
to
get
to
this
place
through
some
relay,
but
actually
it
involves
all
these
signatures,
different
attacks,
protection
and
and
all
the
stuff
to
make
it
trivial
like
it,
has
a
lot
of
complexity.