►
From YouTube: Babel fees via limited liabilities
Description
In this video Polina Vinogradova, IOG's research engineer walks us through the Babel Fees - a novel mechanism that allows the payment of transaction fees in user-defined tokens on Cardano.
Find out more about Babel Fees here: https://iohk.io/en/blog/posts/2021/02/25/babel-fees/
A
Hi
everyone,
my
name-
is
paulina
vinogradova
and
today
I'm
going
to
be
talking
to
you
about
babel
fees
via
limited
liabilities,
which
is
a
paper
that
I
co-authored,
along
with
manuel
trachardi,
nico's,
cara,
janitus,
nicolas
cayas
and
michael
payton
jones,
to
spoil
the
surprise
a
little
bit.
Vapor
fees
are
a
mechanism
that
we
designed
to
allow
users
to
pay
fees
in
non-aided
tokens.
A
So
currently
fees
are
required
to
be
paid
in
ada.
The
proof
of
state
consensus
algorithm
relies
on
this.
Some
prospective
users
don't
want
to
use
their
own
data.
Therefore,
they
can't
build
valid
transactions
because
transactions
require
fees
to
be
paid.
So
these
could
be
users
that
want
to
transact
in
in-game
tokens
in
an
in-game
marketplace.
For
example,
different
users
may
value
different
non-primary
tokens
differently.
A
For
example,
the
quantity
of
non-primary
tokens
the
user
wants
is
limited
and
after
that
they
don't
want
any
more
of
a
given
token
market.
Price
of
the
token
can
also
affect
how
many
tokens
of
the
non-ada
kind,
which
is
non-primary
tokens
a
user,
might
want,
and
we
don't
want
to
mandate
any
users
to
accept
rewards
in
some
non-primary
token,
at
an
exchange
rate
said
by
another
user
or
the
system
or
unpredictable
market
fluctuation.
A
We
want
all
the
users
to
accept
an
exchange
rate
that
they
are
comfortable
with,
and
the
summary
of
the
solution
that
we
propose
for
this
is
that
we
propose
the
babel
fees
mechanism
which
lets
users
submit
transactions
that
function
like
exchange
offers.
So,
for
example,
I
offer
x
amount
of
token
y
to
anyone
who's
willing
to
supply
the
data
required
to
cover
the
fee
for
this
transaction.
A
So
anyone
interested
in
the
offer
may
submit
a
transaction
which
accepts
it
so,
together,
these
two
transactions
form
a
valid
batch
and
can
be
added
to
the
ledger
in
the
batch.
Neither,
however,
can
be
added
by
itself,
and
the
result
of
this
mechanism
is
effectively
that
the
user
is
paying
fees
in
token
y,
instead
of
ada
a
little
bit
of
background.
Slash
review
on
what
the
cardano
fee
mechanism
looks
like
in
order
to
see
why
it's
difficult
to
directly
pay
fees
in
non-aida
tokens,
so
users
submit
transactions.
A
So
in
this
case
you
see
three
users
submitting
three
transactions
each
with
a
different
fee
and
a
block
producer
sees
those
transactions
block
producer,
one
in
this
case.
So
the
transaction
fee
is
calculated
based
on
size,
smart
contract
execution,
time
and
other
parameters,
and
all
fees
go
towards
rewarding
block
producers.
A
In
particular,
this
block
producer
chose
to
include
only
the
first
two
transactions,
presumably
because
the
third
transaction
didn't
fit
into
the
block
and
then
once
the
block
producer
makes
a
block,
they
send
it
off
disseminated
across
the
network
for
all
the
nodes
to
process
it
and
add
it
to
their
local
ledger
and
a
ledger
contains
a
lot
of
data,
including
the
etxo
set.
For
example,
this
utxo
set
contains
some
outputs
from
transaction
two
and
transaction
one
as
well
as
a
feed
pot.
A
So
this
is
where
all
the
fees
go
and
that's
what
we
care
about
in
this
presentation.
The
feed
pod
is
just
the
number
of
ada
tokens
which
have
been
collected
as
fees
over
the
course
of
an
epoch
and
over
the
course
of
the
epoch.
More
blocks
are
added,
more
fees
are
collected
and
they
all
go
into
the
same
feed
pot.
In
this
case,
we
have
some
value
in
the
feed
pod.
After
all
that,
and
once
the
block
boundary
hits
the
rewards
get
distributed.
A
So
all
the
money
in
the
feed
pod
gets
shared
among
all
the
bloke
producers
and
stakeholders
that
have
produced
blocked
or
owned
stake
during
this
epoch.
So
every
block
producer
in
each
epoch
gets
a
share
of
the
feed
pod
containing
fees
from
every
block
produced
in
that
epoch.
So
everything
gets
divided
up.
According
to
some
rules,
dividing
up
non-fever
words
would
require
a
very
complicated
ledger
change
to
calculate
what
part
of
some
non-aided
token
every
block
producer
or
stakeholder
is
going
to
get
as
rewards
is
very
difficult.
A
So
this
is
the
reason
that
it
is
hard
to
have
a
mechanism
to
pay
fees
directly
in
non-aided
tokens
and
babel
fees.
Does
things
a
little
bit
differently
and
I'm
going
to
explain
how
in
a
second
a
little
bit
of
related
work,
so
the
first
bit
of
related
work
is,
of
course,
douglas
adams,
hitchcock's
guide
to
the
galaxy
who's,
the
inventor
of
the
babel
fish
and
the
babel
fees
mechanism
lets
us
translate
from
one
currency
to
another.
Just
like
the
babel
fish
helps
us
translate
from
one
language
to
another.
A
Now
for
a
bit
of
actual
related
work,
there
are
existing
solutions
for
blockchains.
Addressing
this
very
problem.
For
example,
ethereum's
solution
is
to
use
the
gas
station
network,
which
is
kind
of
a
complicated
structure
that
is
built
on
top
of
ethereum,
and
it
requires
additional
infrastructure
and
it
requires
changes
to
existing
deployed
contracts.
A
Stellar
has
a
different
approach
to
this.
Stellar
is
another
multi-asset
blockchain
that
supports
a
ledger.
Implement
dex,
which
is
a
distributed
exchange
distributed.
Exchanges
are
complicated
and
susceptible
to
certain
attacks.
There's
also
another
solution
out
there
by
al
grand
which
uses
meta
transactions
or
incomplete
transactions,
and
this
kind
of
approach
requires
back
and
forth
communication.
So
two
users
have
to
communicate
off-chain
together
to
build
this
meta
transaction.
A
Our
big
fees
mechanism
again
is
different
than
any
of
those
a
bit
of
advertisement
for
the
beyblades
mechanism,
so
why?
A
Why
is
this
a
good
approach,
so,
first
of
all
minimal
complexity
of
changes
to
the
platform
so
minimal
changes
to
the
transaction,
construction
and
processing,
minimal
changes
to
validity
or
effects
of
existing
transactions,
not
a
ledger,
implemented
decks
and
the
simplicity
of
the
changes
we
propose
allows
to
maintain
existing
ledger
security
guarantees,
second
of
all,
minimal
overhead
for
users,
no
costly
design,
implementation
or
upgrade
or
execution
of
existing
smart
contracts,
because
this
is
a
change
to
the
ledger.
It
operates
at
the
ledger
level,
not
the
smart
contract
level.
A
A
Exchanges
are
not
enforced
by
a
fixed
algorithm,
giving
users
the
power
to
configure
their
selection
process
at
any
time
and
decide
what
kind
of
tokens
they
want.
It's
also
quite
low
commitment,
so
users
are
not
forced
to
commit
to
or
prepay
for
accepting
any
future
offers
until
they
submit
the
accepting
transaction.
A
So
they
might
say
that
they're
willing
to
cover
certain
kinds
of
offers,
but
they
can
decide
on
the
spot
when
they
see
a
transaction,
making
an
offer
of
exchange
at
a
certain
token,
whether
they
want
to
accept
it
or
not.
And
finally,
the
mechanism
we
propose
is
versatile
because
it
can
be
used
for
smart
contract
fee
coverage
and
spot
swaps,
as
well
as
tightly
batched
transactions,
which
I'll
also
go
into
a
bit
more
detail
later
on
a
bit
of
a
reminder
of
what
multi-assets
look
like
on
the
cardano
blockchain.
A
So
all
unchained
assets
are
stored
using
something
called
token
bundles,
which
are
heterogeneous
collections
of
primary
and
user-defined
asset
tokens,
for
example.
In
this
case,
we
see
an
example
of
one
sword:
twenty
game
coins
and
negative
four
ada
in
the
same
token
bundle.
So
this
negative
four
eta
is
a
liability
because
it's
negative,
we
call
it
a
liability.
A
Currently,
this
kind
of
value
cannot
appear
in
transaction
outputs.
However,
one
of
the
main
changes
we
propose
to
the
ledger
mechanism
is
that
the
liability
is
now
allowed
on
the
ledger
temporarily
and
I've
kind
of
already
said
it,
but
for
the
big
reveal,
the
paper
title
is
limited
liabilities,
so
limited
in
this
case
refers
to
non-persistent
and
liabilities
refers
to
debt,
so
debt
comes
in
the
form
of
negative
value
and
non-persistent,
because
we
do
not
allow
negative
values
to
persist
on
the
ledger.
They
have
to
be
resolved
within
a
batch.
A
A
So
debt
on
the
ledger
must
be
resolved
inside
a
batch
enforced
by
a
change
in
the
block
validation
rules
which
now
validate
transactions
in
batches
rather
than
atomically.
So
before,
when
you
process
a
block,
you
validate
one
transaction,
you
determine
whether
it's
valid
or
not.
However,
with
this
change,
each
transaction
in
a
batch
can
only
be
determined
to
be
conditionally,
valid,
so
valid,
but
may
contain
liabilities.
A
All
liability,
outputs
created
inside
a
batch
must
be
consumed
inside
the
same
batch.
So
that's
where
the
non-persistent
part
of
debt
comes
in
so
inside
a
batch.
All
liabilities
have
to
be
consumed
before
that
batch
is
fully
valid
and
can
be
added
to
the
ledger.
So
a
natural
batching
strategy
is,
of
course,
that
each
block
forms
a
batch.
A
So
here
you
see
that
alice
has
an
output
with
five
swords
and
bob
has
an
output
with
30
game
coins.
Suppose,
they're
both
playing
a
game
together
and
they're
only
interested
in
exchanging
game
tokens
in
the
games
marketplace
and
neither
of
them
have
any
ada
or
want
any
ada.
However,
they
want
to
construct
a
transaction
during
the
exchange
where
bob
buys
four
of
alice's
swords
for
five
game
coins
per
sword.
A
Alice
has
noticed
that
a
one-to-one
exchange
rate
of
game
coin
to
ada
is
advertised
by
a
block
producer,
and
she
wants
to
take
advantage
of
that.
So
they
continue
constructing
this
transaction.
The
transaction
fee
is
going
to
be
five
eta
and
the
outputs
of
the
transaction
will
demonstrate
that
bob
now
has
four
swords,
which
is
how
many
he
was
trying
to
buy
and
he
has
ten
king
coins
remaining
alice
still
has
one
sword.
A
However,
she
would
have
20
game
coins
if
there
was
no
transaction
fee,
but
the
fee
has
to
be
paid
so
in
order
to
pay
the
fee.
There
is
this
additional
liability
output.
That's
made,
that
is
part
of
the
transaction
where
a
negative
five
value
of
eta
is
included
in
it,
as
well
as
a
positive
five
value
of
game
coin
so
effectively.
That's
an
exchange
offer
of
five
game
coins
for
anybody
who's
willing
to
pay
five
eta,
so
the
difference
between
the
outputs
that
have
the
little
locks
with
the
names
next
to
them,
alice
and
bob.
A
These
refer
to
the
fact
that
alice
or
bob
have
to
sign
in
order
to
be
able
to
spend
those.
However,
the
lock
with
liability
next
to
it,
anybody
can
spend
it.
There
are
no
restrictions
so
long
as
the
transaction
spending
it
is
able
to
cover
the
debt
in
the
liability,
so
in
this
case
alice
and
bob
both
sign
the
transaction,
because
that's
required
by
the
locks
and
the
fee
of
five
data
is
included
in
the
transaction
through
putting
that
in
the
negative
five
liability
that
you
see
there.
A
So
this
transaction
by
itself
is
not
valid
to
be
put
on
the
ledger,
because
it
has
an
unresolved
liability.
So
what
happens?
Next,
with
any
luck
calvin
who
has
made
the
one-to-one
exchange
offer
of
ada
to
gamecoin
sees
that
this
transaction
has
been
disseminated
over
the
network
and
he
decides
to
complete
the
batch.
So
he
adds
his
own
input
to
a
new
transaction
transaction
2,
and
this
input
is
of
15a.
So
now
he
spends
the
liability
and
the
15
data
input
and
also
he
needs
to
pay
the
580
fee.
A
So
after
this
batch
is
applied
to
the
ledger,
this
liability
does
not
actually
appear
on
the
ledger
in
the
ut
excel
set,
and
that's
why
we
call
this
debt
non-persistent,
because
the
utxo
set
of
a
valid
ledger
does
not
actually
contain
this
liability
output.
It
does
an
intermediate
calculation
of
applying
a
block.
However,
so,
in
order
to
facilitate
batch
transactions
to
be
added
to
the
ledger,
we
need
a
way
to
allow
people
to
find
out
about
what
kind
of
offers
will
be
accepted
and
be
able
to
complete
batches.
A
So
this
is
the
price
discovery
mechanism,
so
all
exchange
rates
from
all
sellers
are
published
on
an
off
chain
roster.
In
this
case
you
see
two
different
rates
for
swords
and
one
game
coin
for
one
ada
exchange
rate
users
can
look
at
this
roster
and
decide
to
make
offers
based
on
what
they
see
there.
A
So
sellers
produce
babel
offers
which
are
transactions
with
liabilities
and
publish
them
to
the
network
and,
as
I
said,
they
decide
which
ones
to
make
based
on
what
they
see
on
the
off
chain
roster
and
they
want
their
offers
to
be
live.
So
if
a
babel
offer
attracts
at
least
one
honest
party,
the
accepted
offer
will
be
eventually
published
to
the
blockchain
is
the
liveness
condition
and
of
course
you
want
to
make
an
offer
that
will
be
live.
A
So
in
this
case
we
see
the
offer
of
five
ada
or
five
game
coins
and
it
is
sent
off
and
block
producer.
One
sees
it
has
such
an
offer,
and
this
offer
goes
into
block
producer.
One's
mempool,
so
block
producers
construct
blocks
of
transactions
by
choosing
from
a
set
of
available
transactions
called
the
mempool.
A
So
block
producers
see
all
the
offers
disseminated
across
the
network
and
they
are
able
to
decide
which
of
these
offers
that
have
gone
into
their
mempool.
They
want
to
resolve
the
liabilities
of
themselves
and
which
existing
resolved
batches.
They
want
to
include
in
their
blocks.
So
a
rational
block
producer
tries
to
maximize
the
amount
of
primary
currency
earned
by
the
blocks
that
they're
producing
and
in
the
limited
liabilities
paper.
A
So
in
the
picture
we
see
that
a
block
producer
gets
this
transaction
with
the
liability
puts
it
in
the
mempool.
Maybe
completes
the
batch
themselves
and
produces
a
block
with
the
completed
batch
and
block
producer.
One
as
a
result
gets
five
game
coins
and,
as
I
said,
this
payable
fees
mechanism
is
pretty
versatile
in
particular.
There's
a
few
other
ways
to
use
this
mechanism,
for
example,
atomic
swaps,
so
atomic
swaps
broadens
the
idea
of
babel
fee
offers
for
any
kind
of
exchange,
not
just
fees.
A
A
Accepting
the
software
by
changing
the
script
or
signature,
locking
the
liability
output,
it's
possible
to
control
what
kinds
of
transactions
are
able
to
consume
that
liability,
so
previously
any
transaction.
If
you
change
the
lock
on
the
utxo,
it
allows
users
to
form
batches
where
transactions
cannot
be
replaced
with
another
transaction,
so,
for
example,
this
is
very
useful
in
case
you
have
scripts
that
need
several
transactions
in
order
to
run
a
program
step
to
completion.
So
a
single
step
of
a
script
has
to
be
separated
into
several
transactions.
A
This
can
be
formed
into
a
batch
using
the
liability
mechanism.
There
are
some
other
things
that
need
to
be
worked
out
in
order
for
this
mechanism
to
be
viable.
For
example,
currently
the
mental
transaction
validation
process
in
the
existing
system
takes
a
valid
ledger
to
another
valid
ledger
by
applying
a
transaction,
so
a
mempool
has
a
transaction
and
the
block
producer
tests,
whether
the
transaction
is
valid
by
applying
it
to
the
current
valid
ledger
and
seeing
if
the
next
ledger
is
also
valid,
but
the
babel
fees
mechanism.
A
So
after
we
have
settled
on
how
to
resolve
that,
we
would
follow
the
usual
process,
so
we
would
make
the
cip
we
would
formalize
this
mechanism,
we
would
implement
it
in
the
ledger,
the
wallet,
dbsync
and
so
on,
and
then
voila
payment
of
fees
in
non-primary
currencies,
and
thank
you
very
much
for
listening.
Hopefully,
you
enjoyed
that
presentation.