Ethereum, Aeternity and the distributed wonders (Luca Marchesini)


Once upon a time…
There was a king.
His kingdom was big, and he ruled upon it
with great strength and justice.
So that all his people loved him.
But what he loved the most were his three
daughters.
The princesses.
And one day, the king felt that death was
imminent.
So he decided to sit down and divide his kingdom
in three perfectly equal parts.
Then he wrote a testament, made copies of
it, and handed one copy to each one of his
daughters.
He kept one copy for himself, and then the
four of them, they went to the notary office.
And once the notary has put his seal on each
of the copies, the king felt relieved.
He knew that he could spend the rest of his
days in peace, because if at any moment after
his death someone tried to forge a false testament,
trying to change his will, the notary would
grant the authenticity of the first original
copy.
The one that he wrote.
But these days didn’t last long.
Because not much time later, he received an
anonymous message, saying that the notary
and his youngest daughter were conspiring.
Because they were in love.
They wanted to forge a New Testament that
would give all the lands to her.
Stealing them from her sisters.
And the notary would grant that this fake
document would be the original.
The king could have the notary captured.
Tortured.
And killed.
But he didn’t do that.
He knew that it would be very difficult to
substitute him, and even if he could substitute
him, how could he know that the loyalty of
this new man would be forever?
The king quickly understood that the problem
here was the need to trust a single person
for such a job.
Unable to find a solution, the king published
an announcement, promising a huge reward to
the one who could solve the problem of granting
the authenticity of a document, without trusting
anyone.
He received many engineers, inventors, wizards,
alchemists to the castle.
And he discarded each and every one’s solution,
because they were weak.
Because trust was still a basic block.
Right before the king began losing hope, a
young boy introduced himself.
He said that he knew a machine so perfect,
so unstoppable, so uncorruptible, that trust
was not even a problem.
He said that this machine could solve any
problem, as far as the problem could be expressed
in the language of the machine.
Okay, said the king.
So…
What’s the name of the machine?
The young boy said…
Ethereum.
The king said…
Ethereum.
You bunch of hipsters!
(laughter)
So show me this Ethereum machine, said the
king.
I can’t, said the boy.
The machine is everywhere.
The machine is nowhere.
Oh my God, said the king.
So tell me how it works.
The young boy took a deep breath, and started
talking.
Ladies and gentlemen, bonjour.
My name is Luca Marchesini, and I work at
Kuzzle, where I contribute to the construction
of probably one of the most awesome backends
up there.
And I’m here because my team helped me prepare
this talk.
And while I was doing my slides and rehearsing,
they kept up to pace, providing good code
to the repository.
And I’m here today to tell you what the young
boy said to the king.
I’m here to explain a little bit Ethereum.
And it turns out that the best way to understand
Ethereum is as a generalization of BitCoin.
So let’s talk about BitCoin.
BitCoin is nothing more than a bank.
And a bank is nothing more than a system that
helps us keep track of the states of a set
of accounts.
And it does so by maintaining a ledger of
transactions, which is nothing more than a
log of transactions.
And the interesting thing here is that, by
keeping the log, we can compute the balance
of each account at any moment in history.
Right?
And BitCoin is exactly the same thing.
It’s a ledger.
It maintains a list of transactions.
But the difference is that BitCoin doesn’t
rely on a single, centralized entity.
It’s not one server or one cluster.
It’s decentralized and trustless.
BitCoin relies on a network of computers that
work together, keeping up the service, without
trusting each other.
So how could this possibly work?
First, because every piece of information
in BitCoin is public.
Every Node that joins the network — and anyone
can do that.
Anyone can join the network.
Every node gets a full copy of the whole ledger,
which today is about…
100 gigabytes, I think.
Probably more.
And this allows every node to verify all the
information in the ledger.
It’s their duty.
Every node has to verify everything.
Transactions are signed.
So nobody can send a transaction to the network
on behalf of anyone else.
Because nobody can fake cryptography.
And in addition to this, every transaction
must comply to a set of rules.
Which we will call the consensus mechanism
of BitCoin.
And if a node tries to submit a transaction
to the network and this transaction goes against
consensus, the transaction is simply rejected.
And in order to synchronize themselves, nodes
do not just stack transactions one up on the
other.
They group them in blocks.
And blocks here behave pretty much like git
commits, in the sense that they are linked
together.
They form a chain.
That’s why we say that BitCoin is a Blockchain.
And the way they are linked together is that
each block contains in its header the hash
of the previous block.
And Git works exactly the same.
The only difference is that in Git a commit
can reference many parents, and in BitCoin,
in a Blockchain, every block can reference
one and only one parent.
But the interesting thing here is that, by
being chained in this way makes the Blockchain
immutable.
Because if you wanted to alter the content
of one block, we would need to reconstitute
all the subsequent blocks.
Because all the hashes would change.
Right?
And this is theoretically possible.
But in BitCoin, this is extremely expensive.
Because the algorithm artificially makes expensive
the process of building a block.
Which we call mining.
So the name of the game here is that playing
by the rules is more profitable than cheating.
It’s a game theory thing.
So I will not discuss more here about BitCoin.
First, because we just have half an hour,
and if you want to talk about Ethereum, we
just don’t have enough time.
And also because many of these concepts are
extremely well covered by Andreas Antonopoulos.
Which is the most prominent BitCoin evangelist
out there.
And probably the best speaker I’ve ever seen.
So there is this master class that he gives
at the University College in London.
Where he explains the consensus mechanism
that underpins BitCoin, in an awesome way.
So if you want to fill the gaps, just go for
it.
It’s a one and a half-hour video.
Definitely worth the effort.
Did everyone get the QR code?
Okay.
I hope maybe we can put a link in the video
for the YouTubers.
So if you’re not familiar with the technology
behind BitCoin, I ask you to have a little
bit of faith.
Just stay with me.
BitCoin is actually a thing.
The market gap is just huge.
It’s insane.
It’s decentralized.
It’s trustless.
It’s immutable.
It’s secure.
And it works.
From now on, let’s generalize.
We said that BitCoin is a ledger.
Right?
What’s a ledger?
At the end of the day, the ledger is just
a state machine, which is a system that provides
a function that, given a state, and an event,
which we call a transaction here, for consistency,
given these two things, the state transition
function allows us to compute the subsequent
state.
The next state.
And so on.
Every time there’s a new transaction, we get
a new state.
Right?
And this state transition function in BitCoin
is hardcoded.
Whenever you run a node, you run a software,
and this state transition function, which
contains all the rules of the consensus mechanism,
is hardcoded in the software.
Which is perfectly okay, because BitCoin just
has one purpose.
Being a bank.
Nothing more, nothing less.
But what if we could make S programmable?
That’s pretty much what Alan Turing did, when
he invented…
Guess what?
Computers.
Well, we would get Ethereum, which defines
itself as a Turing-complete virtual machine
running on a decentralized distributed trustless
network.
In Ethereum, what would persist — it’s the
list of transactions.
We would persist them in the Blockchain.
And we keep the latest states in memory.
In the fashion that…
In order to change the state, we have to submit
the transaction.
There’s no other way to change the state.
And every transaction is persistent.
So let’s go back to the problem of the king.
The notary problem.
Do you remember the problem?
Yes.
You do remember.
Okay.
Let’s take a look at this piece of code that
I just got on GitHub.
There’s many of them.
Credits on the bottom right corner.
The core thing here is this function.
Register proof.
That the king may call, providing the hash
of the testament.
Right?
And this hash would be used as the key for
an associative array.
That would be associated to a metadata structure
containing the address of the king.
MSG.sender contains the address of the account
that called the method.
The now timestamp.
And a comment that the king may have passed
to the function.
So we create the new entry to this associative
array.
Of course, before we checked that the entry
doesn’t exist yet.
And here is where we declared the metadata
structure.
And everything is wrapped in a class.
In a very object-oriented fashion.
But instead, we don’t call it a class.
We call it a contract.
And that’s the way…
That’s the vocabulary of solidity.
Which is the high level, strongly typed, object-oriented
language that compiles to byte-code, that
the Ethereum virtual machine can understand.
Awesome.
So we have a bit of code.
What do we do now?
Well, just the classic things that we do when
we write code.
We compile it, we load it in memory, and then
we execute it.
Just like on a computer.
Let’s see how it works in Ethereum.
Okay.
Not very exciting.
This is just a compilation step.
Works as using.
You have a compiler.
It’s called Solc.
And it generates bytecode that we want to
load in memory.
And loading things in memory boils down to
changing the state of this memory.
And we said that to change the state, we need
to submit a transaction.
That’s exactly what we do.
We take the bytecode.
We create the transaction that wraps it.
Of course, we have a full toolchain to do
that.
And when we send the transaction to the network,
and the transaction is approved by the network,
we get an address.
For the bytecode that we just deployed.
Just like when we load the program in memory,
we get an address in memory.
So that we can tell the processor: Hey, read
at that address.
Take n bytes.
Treat these bytes as instructions.
And execute them.
And to do that, we do the same thing.
We create a transaction.
Containing the address that we just got the
name of the method that we want to execute
on the contract, and the arguments.
Okay?
And what happens here is exactly what we just
said before.
Nodes in the network receive the transaction,
and they have to run this state transition
function against the transaction, in order
to compute the new state.
But our transaction is a method call.
So all the nodes that receive the transaction,
in order to validate it, they have to run
our code.
Which leads us to say that in Ethereum, nodes
do not share the computational load.
Like on on a cluster.
Ethereum is not a cluster.
Ethereum runs in a trustless environment.
So that nodes do not share the computation.
They replicate it.
Because they have to verify that every other
node said the truth.
And performance here is not the aim.
Security is the aim.
In addition to this, for a transaction to
happen, it must be included in a block.
And we said that building a block is expensive,
in terms of computation, in terms of energy,
and in terms of time.
In Ethereum, building a block and having the
block accepted by the network takes on average
17.5 seconds.
Which is not fast.
You don’t want to deploy on Ethereum an image-processing
task.
Awesome.
We deployed a small piece of code.
So how do we interact with it?
How do we let over people, non-nerd people,
we don’t want to send emails saying…
This is the address.
Build a transaction.
We need a UI.
And this UI, just like classical client server
protocol, needs to communicate with the backend.
But the backend here is the Blockchain.
How do we make this possible?
It’s extremely easy.
The Ethereum core developer network provides
a set of libraries, and I picked the web3.js,
which is the JavaScript library that I’m familiar
with.
And it just provides all the APIs that enables
any layer to communicate with the Blockchain.
And we just made a DApp.
Where the D stands for decentralized.
Let’s go back to the contract now.
Does this make sense to everybody?
I hope so.
We can dive a little bit more on what happens
with contracts.
This is the notary contract, once again.
And it inherits from another class, called
owned.
Why is that?
Let’s take a look at owned.
It has a public member.
Called Owner(), which is an address.
And Owner() contains the address of the account
that called the constructor.
msg.sender is that address.
And this is reliable information, because
msg.sender is an environment variable provided
by the Ethereum virtual machine, that reads
the address of the sender of the transaction,
which is signed.
So it’s reliable.
And passes through the msg.sender to make
it available for the code.
And in this concrete case, the constructor
is automatically called by the transaction
that deploys the contract.
So deploying a contract means actually creating
an instance of this class that we just declared.
So that we can deploy many times the same
contract.
Because we are actually deploying instances
of the contract.
So here the owner of the contract is the account
that deployed the contract.
Why do we want to do that?
Because we want to restrict some execution
of some methods to the owner only.
And we do that by declaring a modifier.
A modifier is just like a function that wraps
another function.
Like…
And we add an instruction, a check, that throws
if the sender is not the owner.
And then if everything is okay, we excuse
the rest of the function code.
Which is represented by this place holder
here.
So let’s see this modifier applied somewhere.
This is another contract, called Mortal.
That inherits from Owner.
So it inherits all the modifiers as well.
And here we apply the modifier on the owner
to the function kill(), so that the self-destruct
function is executed only if the owner has
called the kill() method.
Did I say self-destruct?
What’s the point of self-destructing a contract?
This is because, in Ethereum, we are pretty
different.
It’s a pretty different environment than a
Linux box.
Contracts that we may think about as processes
in a Linux box…
They are meant to be autonomous entities.
When you deploy a contract, it’s not yours,
unless you tell it so.
The Ethereum virtual machine will not try
to stop anything.
The Ethereum virtual machine will not provide
signals or kill comments to stop contracts.
They are meant to run forever.
And the Ethereum virtual machine is something
you just…
You can’t stop it.
There’s no on/off switch button.
It’s a network.
So you have to force everybody that participates
in the network to shut down their computer.
Which is not easy.
So unless we tell them so, contracts are gonna
run forever.
So what happens here, when we self-destruct
a contract, is that we send a new transaction
that unloads what we previously loaded.
It undeploys the contract.
So that when we call our address, the machine
throws an exception.
And the other funny thing that happens is
that all the money that the contract owned
is sent to that address, that we pass as an
argument to the self-destruct function.
Whoa, whoa, whoa.
Did I just say money?
Did I just say funds?
Yes, I did.
In Ethereum, we have a cryptocurrency, just
like BitCoin.
It’s exactly the same.
Except it’s called ether, not BitCoin.
And the funny thing here is that contracts
can own money.
Just like humans.
In Ethereum, contracts are really first class
citizens, just like us.
Now, let’s check this function that we previously
ignored in the notary contract.
You can see it inherits from Owned and Mortal.
But there’s this piece of code that we didn’t
take into account before.
It’s an anonymous function that every contract
can implement.
And we call it the fallback function.
Because it’s a fallback, when someone tries
to call a method that doesn’t exist.
On the contract.
And also, it’s executed whenever someone sends
money to the contract.
So this implementation here…
It’s pretty honest.
Because the notary contract isn’t meant to
manage any money.
So the author here just makes the function
throw.
So that when someone tries to send by mistake
some ether to the contract, the function throws,
and the ether is sent back to the sender.
The exciting thing here is that we are dealing
with a system where money and the rules that
allow money to flow — they live in the same
system.
Which is different from real life.
Let’s explain that with a concrete example.
Imagine that the king wants to buy a TV set
from a merchant.
He goes to the website, checks the cart out,
sends the money, and once the merchant has
the money, he has the choice.
It’s a moral choice.
Either he sends the merchandise to the king,
either he runs away with the money.
He goes against the law.
The king can leverage the law, because he
can try to get refunded and get his money
back, but in the meanwhile, the merchant has
fled with this money.
This is how real life works.
Imagine that we can put a middleman contract
between the two.
When the king checks the order out, he can
send the money to the contract, instead to
send them directly to the merchant.
And then the contract would hold the money
in escrow, and notify the merchant that there’s
a payment pending for him.
If the merchant wants his money, he must send
the merchandise.
And once the shipping is complete, the king
and the shipping company can sign together
a transaction to notify the contract that
the shipping is done.
The contract can then unlock the money and
let it available for the merchant to withdraw
the money.
And everybody is happy.
Our story is close to its end right now.
We are running out of time.
We can see that the king is happy, because
he solved this problem.
The notary is sad, because he and all the
notaries in the world, they had lost their
job.
Which is something that always happens whenever
we introduce a new disruptive technology.
The other thinkers in the kingdom are now
wondering if the humanity will be able to
deal with such a perfect, unstoppable machine
as it gains more and more power.
But the king sleeps like a child.
He’s unaware of what’s going on.
He doesn’t know that somewhere in the suburbs
of his kingdom, in a very well hidden garage,
a group of hackers are trying to code a contract
that, once deployed, it will enable for perfectly
democratic decision taking.
The king doesn’t know that the age of monarchy
is probably over.
He doesn’t know that the age of democracy
is probably coming.
But this, ladies and gentlemen, is another
story.
Thank you very much.
(applause)
>>I’ve lost the speaker!
Come back, come back, come back!
You have Q and A to do yet!
I have a lot of questions.
>>I was running away, you know?
>>Okay.
That was great.
I have lots of questions.
So where should we start?
So in the kingdom-merchant scenario, how do
you ensure that the king and the delivery
guy don’t conspire against the merchant?
>>Very good question.
I’ve asked it myself.
Well, of course, there’s the use case that
I described — is pretty simplified.
There’s people that actually work on these
kinds of things — have figured out many scenarios.
I’m probably very naive here.
But one thing we could do is that, if the
shipping company wants to get paid, they are
forced to be honest with the king, and properly
sign the transaction that the delivery has
done…
Has been done well.
So that the contract can unblock the funds
for the king sorry, for the merchant and for
the delivery company.
So if they don’t do that, they don’t get their
money.
Right?
>>Okay.
Another one on the more technical side, I
guess.
If you can write any program and anyone can
execute it — if everyone executed it, isn’t
that a very easy way to spread malware.
>>Oh, yes, of course.
You can deploy…
I never thought about that.
But yeah.
You can deploy malwares on Ethereum.
You can tell people to use that.
We are…
Entering…
We are overlapping a little bit with an anarchist
realm.
So it’s pretty much up to you.
You have to be careful.
There’s a lot of hacks in the Ethereum world.
There have been a lot of hacks this year.
There’s a lot of companies that claim that
they were an online wallet, and instead of
managing your funds, they just send all your
funds to their address.
And this is something they can’t revert.
So yes, everybody can’t deploy everything,
and it’s up to each and every one of us to…
To be aware of what we do.
>>You talked about the hacks.
Obviously, earlier in the year, Parity’s wallet
was hacked.
How should we, if we’re going to use this
— defend ourselves?
So we don’t become victims?
That was just a one-line bug, if I remember
rightly.
>>I actually previously…
When I first wrote…
The first draft of this talk…
I wanted to talk about the Parity multisignature
hack.
Because it’s a very good example of how fragile
this environment is right now.
Because when you deploy, what happens is that…
Someone hacked three very rich wallets.
And then everybody can see everything.
So they were seeing that they were being hacked.
And all the other people that used that wallet
— they couldn’t do anything.
And what happened is a group of hackers, white
hat hackers, they hacked systemically all
the other wallets and transferred the funds
to more secure wallets.
This is because you can’t stop contracts on
Ethereum.
If you deploy a bug, it’s gonna be there.
So updating a contract is kind of an open
issue right now, in Ethereum.
There are solutions being proposed.
Which involve the use of libraries.
Which I wanted to discuss, but I couldn’t.
But I think that the best way we can protect
ourselves from these kinds of flaws is to
test more.
To enable ourselves to automatically test
contracts in a more extensive way.
And we know that object-oriented programming
is not the best paradigm to do that.
Functional programming enables for automatically
generated tests.
I don’t know if you have ever heard of it.
But there’s clearly a lack here.
And I believe that the lack will be filled
by the toolchain that will improve itself
more and more.
And bugs will be almost automatically spotted
by the toolchain.
I hope so!
>>I have three more questions linked to this.
One I was wondering was: If the contracts
run forever, how do you avoid DDoSing?
Could you not just spawn loads of those contracts?
>>Yes.
This is another thing that I wanted to talk
about.
It’s okay.
It’s perfect.
Actually, to avoid DDoS, and avoid flooding
of the network, Ethereum introduces the concept
of gas.
Which is basically a measure for the computing
resources that you’re gonna use.
So when you send the transaction that triggers
the execution of a method, you have to declare
two things.
First, how much gas do you want to allocate?
Which means…
How many instructions are allowed to be cuted
by this goal?
So if you execute less, it’s okay.
If you execute more, it fails.
And you have to figure out: How much money
you want to pay your gas for?
This is important, because if you pay less
money for gas, your transaction is going to
be cheap, but miners will not…
Are going to be likely to deprioritize your
transaction, in favor of more expensive transactions.
So if you pay a lot of money for your transaction,
you’re gonna be sure that the transaction
is going to be taken into account quickly.
The thing is that no transaction gets lost.
So at a certain point, every transaction is
executed.
But by introducing these gas…
Concepts…
You just can’t flood the network.
If you want to execute huge pieces of code,
it’s going to be very expensive for you.
And it’s going to be finite, always.
>>You mentioned a moment ago that maybe an
object oriented language isn’t the best choice
in some ways for this.
Are there other languages?
This is running on a VM, right?
Could you have an immutable language that
you use instead of something that’s stateful?
>>Well, Vitali Butarin, which is the inventor
of Ethereum, is proposing alternatives to
solidity.
And there’s also this new company that I wanted
to talk about, but I couldn’t.
Which is called Aeternity.
Which is addressing this problem of using
object-oriented languages for very critical
pieces of code.
And they propose to write smart contracts
in a functional, fully functional language.
It’s on its early stages.
So I don’t really know if they are going to
succeed.
But I think this is the good path to go, I
think.
This is the safest.
If you want to extensively test your code,
it’s better to do it in a functional fashion.
Which is more difficult, probably, to code.
And it prevents you from storing state.
I don’t know.
>>You would have to see how it evolves.
>>Yeah.
You have to balance the…
The ins and outs.
>>Two final questions.
Both a bit more practical.
One: How do you debug and test these contracts?
If we wanted to go out and make our own now?
>>Just like in BitCoin, you have an offline
Blockchain that you can run on your own laptop.
And then you have a test net that you can
use to deploy your contracts, and then let
your testing team send transactions, and see
what happens.
And the test net…
I think it gets reset every now and then.
And money doesn’t mean anything down there,
so you can open an account on the test net
and get as much ether you want.
I’m not sure what I say, but there are means
to test it.
But we know that testing it depends on us.
And we are not perfect.
>>And then the final question and probably
the most important one: Should we all be going
out and buying BitCoins?
What do you think about the ICOs?
>>Oh.
>>This doesn’t count as investment advice,
legally.
>>What do I think about ICOs?
>>Do you want to explain what ICOs are?
>>Let’s just explain what ICOs are.
So in Ethereum, it’s trivial to create new
cryptocurrencies.
You can find on the Ethereum homepage there’s
a documentation section.
It’s like 20 lines of code that you can deploy,
and you have your own cryptocurrency.
You just have to put a name on it, and it’s
yours.
And then you just have to convince other people
that they have to buy it, because it’s great.
So ICOs is a practice that…
It got massively adopted this year as a fundraising
method from startups that work on the Blockchain.
And huge amounts of money have been raised,
because this company, they issue their own
cryptotoken.
And this cryptotoken will be used later, when
the company will provide services.
It will be used to pay the services.
So investors, they buy tokens for later to
use.
And they get the tokens.
They trade them.
And they don’t get shares of the company.
The company gets all the money.
And you don’t get to be a shareholder.
You just have tokens.
You’re just a trader.
So I think it’s very complex to express my
opinion right now.
I promise that I’ll write an article on this.
And I will tweet it.
But the TL; DR of this article right now…
The only thing I can say is…
Hmmm…
Hmmmm…
Hmmm…
(humming Wolf of Wall Street song)
It’s up to you what you want to invest in
this kind of things.

Add a Comment

Your email address will not be published. Required fields are marked *