[Music]
hi my name is petuk I work at imop and
I'm going to present you our approach to
nanop
payments
in ethereum and how we believe they can
be implemented
uh by Nano payments we understand
payments that are two orders of
magnitude smaller than typical micro
payments it's not a formal definition
but we believe that typical micro
payment is a payment under uh
$10 uh we came across this problem when
we tried to implement uh parts of our
project the Golem project which is a
distributed superc computer in fact it's
a distributed peer to Network where each
node can participate both as a computer
and as a task Center and each Noe uh
taking part is computation should be
able to receive payment uh
eventually and uh this results in nanop
payment because tasks can be split into
uh pretty small uh pretty substantial
amount for example single task can be
split into up to 10,000 tasks where a
cost of one task is below $1 we try to
achieve task payments as small as 1 cent
for a simple simple sub task but we
believe that we can approach even one
cent of a scent uh to make it attractive
to users we believe that cost of renting
qu CPU core shouldn't exceed 5 cents on
average per
hour uh to make it even more attractive
we believe that from the user
perspective the setting should be that
the transaction fees are below the 5% of
the total task value uh framework should
not require any Central Authority and
trusted Authority everything should work
inside the peer-to-peer Network Golem
Network and in fact also an ethereum
Network users Computing notes shouldn't
be required to stay online at any
specific times for example due to
changes in time zones they should be
able nevertheless to get their payments
at some point even if they're offline
and ideally would like to skip any
payments from users so that they don't
have to pay up front any FS to start a
computation We Believe also that nanop
payments can be used in other scenarios
for example paying for articles or for
streaming content paying directly to
artist or for likes on social media also
you can donate something on forums and
blogs for people who write something
that you find useful but there are many
more
ideas uh why we believe etherum is the
solution
well traditional payment systems are
simply too costly and they require
additional ISM trusted Central
authorities we don't want to trust them
well people wouldn't have to trust them
because there are some Central Central
and external authorities that work
outside of the network additionally we
have Bitcoin which up to some point can
solve our problem but first of all it
requires additional payments for D
transactions additionally there are some
penalty fees for many transactions in
one block and you have to pay
additionally for large
blocks possibly we could overcome these
problems in Bitcoin network but we also
believe that additional logic would be
implemented in a contract attached to
Golem which makes
Bitcoin a bad choice and ethereum the
right one so how the typical payment
scenarios look like
well we thought about them a bit we
investigated all of them and it seems
that external service would be the best
solution because they would solve the
problem to in simply but they require uh
the external servers and additional
Authority something which is of the
network both Golem and ethereum and it
is not feasible in our scenario bing up
to some point solves the problem but but
it's not scalable well it direct
transfer costs approximately 21,000 gas
right now or even exactly and batching
is two up to three times cheaper but
that's that's it you cannot get any
better with it U batching boils down to
initiating all transaction just with one
message in ethereum it's just a loop
that sends uh value to all
users very promising option is micro
payment channels unfortunately this
requires the setting when two parties
cooperate together for a longer period
of time and this is not the case in goem
unfortunately and the last one
probabilistic payments described by
vital in his on his blog uh seems very
promising unfortunately it requires
users to send large amount of Val value
before starting the calculation and
those deposits We Believe may not be
acceptable by senders who simply would
like to pay the predefined amount of
money and be sure
that that's enough to make the whole
payment so how it looks in
ethereum well with the gas price and it
costs at the level presented on the
slide it looks like this direct transfer
cost 21,000 gas whereas batching cost
11,000 it's an improvement but it's not
enough for a now no payments micro
payment channel would work provided that
we could establish a connection between
two parties which we unfortunately
cannot do when we take Golem uh into
mind probabilistic
payments would work unfortunately there
is no fixed uh cost per user uh expected
cost could be calculated but we're not
going to do it
here our minor minor improvement
over batching is sub accounts sub
accounts is a simple smart contract
which
establishes uh a mapping for between
addresses and values and sender
transfers values sending a vector of
data pairs of addresses and values and
they accumulate in uh those accounts
stored in the contract from time to time
and users can cash out and we believe
that on average it should cost cost
8,000 gas per user which give
5K for contract
modification uh 2K gas for sending
message to the contract and we believe
that users should be able to boil down
to 1,000 gas for cashing out this still
is not a perfect solution it doesn't
scale and that's why we come up with
came up with Lottery contract which
supposedly solves all the
problems and it in principle it looked
like this task Center a person who
broadcasted the task into Golem network
uh sends of chain uh the description of
the lottery to all receivers and
additionally sends some data to the
smart contract so that all receivers can
verify that they are treated fairly and
contract should be able to verify that
some user uh has won the second step is
drawing a random number I'll talk about
the randomness Source later on we
believe that we can provided that we can
do it it's just a matter of running the
contract so that it pays the required
amount to the winner and so that
everyone can verify that indeed that
person
won um in Ideal World we would be able
to draw a random number easily and in a
very verifiable way and in that setting
the algorithm would be pretty
straightforward uh task Center would
send very description to everyone in the
colum Network so that everyone would be
able to verify that it is fair and after
that anyone could call a reward winner
into the contract which would simply
send uh the funds to to the winning node
unfortunately we don't know how to do it
because there is no source of trusted
source of Randomness but if we could uh
draw a random line random number from
some external source that can be checked
later on on then sender would call start
Lottery with Lottery ID Lottery ID Maps
uniquely
to to the description of the lottery and
the ID of the task that was sent to the
Golem Network and after the random
number is generated
someone maybe sender or the winner calls
reward winner and just as before funds
are transferred to the winning note
unfortunately this is still invisible
and we have to come up with something
else so we use as suggested by vitalic
hases from future blocks an additional
method determine winner can be called by
anyone and that method stores a
predefined hash of a predefined Blog
future blog and after that the thing
everything goes as before someone calls
reward winner and the funds are transfer
to the winning note uh the point is that
reward winner can be called upon anyone
determine winner is required to be
called within some amount of time and
there is an incentive uh for everyone to
do it uh first off the paying Noe task
cender pays some small additional
deposit and this deposit is returned if
uh the sender calls the termine winner
ear on if that note fails to call it
anyone can call determine winner in the
deposit is transferred to that note so
there is an incentive to do
it well what's more import what's
important here is that winner
certificate is uh pretty similar to what
we had in sub accounts case it's a list
of pairs uh notes addresses and values
that correspond to each Noe and each
value is proportional to the time that
node oh well compute resources that note
spent uh for the task or even
subtask and this is are in number of
nodes we believe that it should be
better and everyone knows what this
structure is numerical tree can be used
to Simply send logarithmic amount of
data with regard to the number of
participants uh the only change in the
algorithm is that the winner certificate
right now consists of triplets uh
address a partial sum up to the point
where the
uh node is in a vector and its value so
that it can
be determined in a tree so when the path
is
set the lottery ID is changed to the H
of the root of the tree concatenated
with Lotter
ID we believe that we can do even better
we can keep the cost of the whole
Lottery
constant but this setting requires some
optimistic assumptions that
prove the one that is sent in fifth
step is sent only when necessary
necessary meaning that someone was
cheated someone was cheating so a
winning note sends lottery winner
message without any proof and stores a
huge deposit which would be paid to
other note if that sending note is a
cheater after that
anyone participating in the network can
send a proof and if the Tater is
revealed then the not sending the proof
gets the deposit and the winner gets
gets the value gets the price uh we
believe that 24 hours is just enough to
make it
fair the algorithm is pretty similar to
the uh first implementation that is not
optimistic but uses uh certificates
right here we add three additional
points in fact two lottery winner and
lottery payout lottery winner is used to
indicate that a note believes is a
winner lottery payout can be called
after 24 hours is no one vetos and
reward winner is a veto which results in
revealing cheater and sending a deposit
to the revealing note and sending prize
to the winning
note
so one very important problem that we
have to deal with is how to Generate
random value well generating values
random values by Future blocks is not a
perfect method because it's um prone to
minus fraud and at the point of this
presentation only 25 and 56 blocks can
be well hashes of blocks are available
to the contract
so within 25 2000 and 56 blocks a block
hash has to be stored in a contract
because later on it cannot be verified
if that doesn't happen then the next
batch of 25 2256 blocks is used and
another hash is used it's fair but it
changes the winner so it's an incentive
to everyone to get that has from the
first 256
blocks well so far we don't know any
better solution but we're aware of
approaches that can in future uh replace
our approach run our contracts and alarm
clock if when stable and well welld
developed may be a better approach to
this problem and may solve it easily we
don't know right now there are not very
reliable and well more expensive than
our approach simply
so with know that they exist we know
that they can be used but we have to
wait until they get a bit more
mature so the cost comparison between
presented methods like here is like this
Bing and sub accounts gross linearly
with the number of users Lottery check
as you can see gross uh logarithmically
lottery winner is a constant cost and
for less than 256 users
Lottery check is cheaper than Lottery
winner which makes it a preferable
method in our setting as you can see for
100 users cost is 6 to7 times higher
than for lottery Bing and sub accounts
and for 1,000 users it's two ERS of
magnitude more expensive which makes it
unusable in our setting uh what might be
interesting for a user who takes part in
a probabilistic setting is how long
would well a user would have to wait for
the first pay payment and it seems that
the probability of not getting a payment
during first and number of lotteries
drops to zero pretty quickly which means
that it goes Rises to one pretty quickly
probability of getting a payment Rises
Qui quickly to
one what's even more interesting is
what's the chance of getting some
predefined amount of expected income
after a number of lotteries well using a
simplified approach with binomial
cumulative
distribution uh we can show that this is
this grows to one with the number of
lotteries the way it's presented on this
graph and it's pretty convincing that it
should work and it should be convincing
to users to take part take part in
lotteries thank you very much if you
have any question please don't hesitate
to contact us
[Music]