okay so this is intended to be a kind of
introduction that's as simple as
possible while at the same time covering
all of the important bits of basically
what the etherium protocol actually
looks like from a technical standpoint
so I'll just kind of dive straight into
it and start off with the basically the
background which has you know why does
the theory of need to exist so back when
I came up with the original white paper
at the end of 2013 there was already a
large amount of interest from the public
in blockchain technology and
particularly people starting to look at
using blockchain technology going beyond
what was then just Bitcoin the currency
and people were looking at various
applications issuing assets on the
blockchain crowdfunding domain
registration projects like named coin
land title registration gambling
prediction markets IOT applications
healthcare applications many different
applications of blockchains
that go beyond I have 50 bitcoins I send
20 bitcoins to you you now have 20
bitcoins so the problem is most existing
blockchain protocols at the time were
designed like this right so what
properties does a pocket calculator have
it can do one thing and it could do one
thing fairly well but that's the only
thing that he can do now granted if you
have some super fancy TI 80 whatever you
can probably try come up with some way
to program a video game on top of it but
like nobody really wants to do that so
in general it just ends up being one
tool they can do one thing so problem is
what if he wants to do more than one
thing well you could buy five different
devices for five different purposes but
it very quickly becomes too clunky so
the next step is that people were
starting to create protocols that worked
like a Swiss Army knife so you might
imagine a group of people come into a
room and they brainstorm for an hour and
they come up with 25 different
blockchain applications and then they
come up with 25 different transaction
types transaction type 1 create a crowd
fund create transaction type 2
participated a crowd fund transaction
type 3 create an insurance contract
grant transaction type 4 create a two
person bet transaction type 5 register a
domain name and so on and so forth for
every application they can think of so
this is what I mean by a Swiss Army
knife protocol and at the time there are
actually quite a few of these that were
being created the problem is though that
if you have a Swiss Army knife protocol
and you have these people come up with
with 25 different projects sitting
together in a room they create this
protocol release the protocol one week
later some teenager from Finland comes
up with the twenty-sixth blockchain
application and then you have to change
around the entire protocol so why not
make a protocol that works like this
right so basically why not make a
blockchain protocol that basically works
like a smartphone it's instead of the
blockchain protocol supporting just a
very small suite of applications and
that's all that you can do instead we
have a blockchain protocol where the
blockchain protocol supports the a
programming language which gives you the
ability to create applications and what
is an application well anyone can write
a piece of code and package that echo it
up and upload it and you have an app and
if anyone else wants to use your app
that you can just download the app and
it appears on their phone and they can
use it and run it right so this is
basically the reason why one single
phone can make phone calls browse the
Internet listen to music have text
conversations with people play games and
just basically do thousands of things
all in one device right this is the
power of general-purpose computation and
this is the kind of spirit I wanted to
bring to the blockchain world so the
concept right so first of all aetherium
is a blockchain
yay but you know there is a few tiny
additions right so first of all
aetherium has this built-in
general-purpose programming language
that allows you to program a very wide
array of applications inside of it now
in a blockchain that is intended only to
support money transfers then there would
be one type of account and that type of
account would just be an account that's
controlled by some user and that account
will hold coins and you would be able to
pass those coins from one account to
another in aetherium we have two types
of accounts the first type of an account
is an account that is controlled by a
user so you have a cryptographic private
key and there exists a corresponding
aetherium address and if you have the
cryptographic private key you can use
this to digitally sign messages that
perform operations on behalf of this
address and these operations are
transact all transactions they can be
broadcasted to the network and if they
get included in a block then those
operations get executed the other type
of account is basically an account
controlled by a piece of code that is in
run inside of the blockchain itself so
you could have a account which is
controlled by a computer program and
this computer program has some set of
rules and the rules might say if thing a
happens then send some coins to person X
if thing B happens then send some coins
to person Y if things C happens then
just hold on to the coins for now and if
you then send coins into this account
then the code of that account is the
only thing that has the power to make
those coins move anywhere else from that
on so it is literally digital assets
that are under the direct control of a
computer program now of course these
contracts can be used for many more
things than just controlling digital
assets they can be used to represent the
business logic of basically arbitrarily
complex on blockchain applications
so this includes things like ENS the
etherium name system this could be used
to keep track of some kind of on
blockchain voting scheme this could be
used to keep track of various on chain
issuer backed assets and missed lots of
different use cases so anyone can create
an application with any rules basically
just by defining it as a contract so DNS
the whole world of aetherium this is
basically kind of the simplest contracts
you can write that still does something
reasonably useful so the idea is that
this is a piece of code and I mean you
might notice that the code has changed
somewhat from last year basically the
reason why is that last year's code was
written in serpent and we now have Viper
which is much better than serpent and
maybe some people will talk about it
later
so basically you have two functions and
these two functions represent things
that you can do with the contract and at
the top you have a declaration of
basically you know like what the
contract stores so the contract stores a
mapping of basically don't make a domain
- what is the owner of the domain and
what IP address the domain is supposed
to point to there is a function called
register and if a domain does not yet
have an owner then the owner gets set to
basically whoever sends the message so
whoever sent the transaction that made
that function call and you have another
function set IP and that function call
is fairly simple it basically just
checks if you own the domain that you're
trying to set the IP address of and if
it does then it sets the IP address to
whatever you want so in a contract
basically a where does all this
information gets stored right so in a
simple blockchain you can think of the
state that the blockchain keeps track of
as just basically being a simple mapping
of accounts to balance us address one
two three four five has 70 coins address
B seven eight eight four has twenty
thousand coins and so on and so forth
the etherium state is a bit richer so
it's still a mapping of account to thing
inside that account but the thing inside
that accounts key to be considerably
more
complex so first of all you have the
account balance so how much ether does
the account have you have the nonce
which is basically a counter that gets
used for a reef for replay protection
and you have the code of the contract if
that account is a contract and you have
the contract storage and a contract
storage is this kind of mini database
that basically any contracts and on the
ethereum blockchain can use so in this
case the mapping of domains to who owns
that I mean what is the IP address would
actually get stored in contract storage
now the history in a blockchain is
things that happen so you have
transactions and in aetherium you have
this concept called receipts so
currently all full notes us to a store
state some full notes store history and
there is the possibility of full nodes
that do not store history so there we go
every account object contains four
pieces of data I'll leave that open for
about five seconds in case anyone wants
to photo it five four three two one
okay now code execution so every
transaction specifies a to address so
every transaction specifies or basically
what is the destination or the target of
that transaction now if the target of a
transaction is just a regular account or
really in any case and if that
transaction contains ether then the
transaction also is a transfer from one
account to another account now if the
target of the transaction has code so if
the target of the transaction is a
contract then the code of the target
address executes and the code has the
ability to do a bunch of things so the
code has the ability to send either two
other contracts it has the ability to
read and write to a contracts own
internal storage so if you were to look
at this example then a call of the
register function would be a transaction
in this transaction would you know
basically lead to this the owner of the
domain being said and that actually is
writing to storage and the if-statement
actually also is reading from the
contract storage so it could read and
write through storage and it can even
call other contracts so this is also
called an internal transaction basically
contracts can talk to other contracts in
the exact same way that user external
users can talk to contracts every full
node on the blockchain processes every
transaction and stores the entire state
its bold because it's important so gas
in aetherium so in general there's
something called the halting problem
which basically says you can't really
tell in general whether or not a program
will just keep running forever so you
can make a program where basically
figuring out whether that program will
stop after a certain number of steps or
whether will keep going forever is
something that just mathematically
cannot be proven one way or the other so
the solution that we have is this
mechanism where we charge a transaction
fee basically per computational step
that a transaction consumes in the unit
in which we measure the computational
steps is called gas so gas is not a
currency right gas is not kind of
something that you can transfer or hold
gas is basically a unit of measurement
it says this computation if it if it
consumes 30,000 units of gas then that
means that the protocol says that this
computation takes about thirty thousand
units of effort in order to execute so
there's also special gas B's that are
applied to operations that take up
storage transactions to take up space
basically any kind of cost that gets
incurred by the etherium network is
translated into some kind of gas
expenditure so every transaction has to
specify the gas limited sure it's
actually has to specify the amount of
maximum gas that that transaction can
consume then when the code executes the
execution starts using up the gas and if
the code execution stops before the gas
is used up then everything is good but
if the code execution gets to the point
where all the gas is spent then the
transaction basically reverts exit
with an error but the sender of the
transaction still has to pay a fee so
the gas limit in aetherium he has a
counterparts in the block size of women
in Bitcoin and the way that it's set is
fairly simple basically miners vote on
it and currently the gas limit is at 6.7
million and if there become and if there
comes that need to raise it then miners
can vote to raise it fairly simple
transactions so it transactions in
etherium have seven parts to them so
there is the transaction nonce which is
basically an T transaction replay so if
you send a transaction so if let's say I
send 10 ether to Bob then this prevents
Bob from taking my transaction and
including it in the blockchain 100 times
so that instead I sent a thousand ether
to Bob every transaction so far it can
only be included once I'm gas price is
the amount of ether that you pay per
unit of gas that your transaction takes
up so this is a the transaction via goes
to miners start gas the maximum amount
of gas that the trend so the maximum
amount of computational resource that
this one's actually can consume um to
the target the value transactions could
send ether um data which is if your
transaction has a target which is a
contract then the contract can read the
data so this is a way of doing things
like specifying function arguments and
VRS which is an ECDSA signature for the
cryptographers here the V is in there
because you need an extra bit in order
to recover the public key from the
signature so we do the public key
recovery thing and not kind of
verification the way that say Bitcoin
does it
um logs so blogs are this kind of
append-only
a form of storage which is not readable
by contracts in the point of logs is
basically to say here is an event that
occurred during contract execution and
we want it to be very easy for people to
search for these events and to detect
that these events have taken place so a
log has up to four topics and there's a
bloom filter so you can search for
topics very easily and it also allows
you to store any amount of data the logs
get put into a miracle tree which allows
very efficient light act light client
access to logs so if you have a light
clients then you can search through logs
and you can use topics as a keyword and
this once you very easily finds events
that contracts have created of a certain
type so very useful for a kind of
decentralized application programming a
theory and virtual machine so basically
you have a stack and numbers can be
pushed and popped from the stack you
have memory memory is in temporary array
of data that the VM can access so memory
only kind of exists ephemerally within
one execution context once the execution
execution finishes then the memory stops
existing storage is like the contracts
database it's its permanent storage
environment variables so contracts in
the EVM can access things like the block
number and the timestamp um you have
logs and sub calling so contracts have
the ability to call contracts by sending
what we call these internal transactions
now it's most of the time you're not
going to be writing in etherium virtual
machine code directly because aetherium
virtual machine code directly is very
cumbersome to write in instead you'll be
writing in high-level languages that can
pile down into e vm code and there's a
bunch of them you have VIPRE you have
solidity you have LOL you have bamboo
once again you might notice serpent is
no longer on the list if you are still
using serpent I suggest you switch to
Viper
so the API so this is the way that
function calls get compiled or encoded
into transaction data so if you're
calling a contract then what that's
actually doing is it's making this
function call and or sorry if you make a
function call it's actually doing is
it's creating a transaction in the
transaction has data which is specified
in this format right so you have four
bytes for a function ID you have 32
bytes for one arguments 32 bytes for
another argument and if you try to call
a function of a contract then you and
your clients would create this
transaction
broadcast the transaction to the network
and the contracts code has the ability
to read the transaction data and it
interprets that you're the first four
bytes of the transaction data as
which function is getting cold and the
other bites as well what are the
arguments so that's basically how
function calling works in a nutshell
Merkel Trias
everyone please bow down and pray to
Ralph Merkle okay Ralph Merkle is
single-handedly beat his Merkel tree is
single-handedly responsible for making
light clients possible so it's very
important to show the technology a huge
amount of respect but basically the idea
is that it's in Merkel tree is allow for
efficiently verifiable proofs that a
transaction was included in a block or
generally efficiently the archival
proofs that any particular piece of data
is included in a much larger piece of
data so if you have a huge hunk of data
then you can make what's this data
structure called myrtle tree out of the
data and with this Merkel tree you can
then for any given piece of data in the
tree make what's called a Merkel branch
which is basically just these kind of
hashes going up the tree at all of these
intermediate levels and by checking the
hashes against each other
you can basically check that this piece
of data actually is in this tree right
so by to build up the tree you would
basically take your data hash two pieces
together then hash that for every two
pieces then you - two hashes hash two
hashes let's we'll eventually have one
hash at the top and then to prove the
membership of any one particular piece
you would get this kind of branch of
hashes and check them against each other
if there is even one error so if you try
to make a proof of a piece of data which
is not actually there then at least one
of the hashes will not match up in
aetherium this gets viewest in order to
prove transitive that some particular
transaction is in a block but there is
also something called the state tree so
the state tree is a Merkel tree of the
entire aetherium state so basically
every account every contract the balance
the nonce the contract code contract
storage the entire state all the data in
aetherium is hashed in this tree
structure and the root hash of this tree
structure goes into the block header and
this is called the state
so from in one block to the to the next
block there are going to be some parts
of the state that get modified and so
the Merkel tree will change but we have
a specific kind of tree called the
Merkel Patricia tree which basically
means that when this thing gets changed
the number of updates to the Merkel tree
that have to be made is actually fairly
small
it's basically log logarithmic per
update so with this basically a white
client can ask the network for you know
give me a Merkel branch for one
particular account and some full node
can reply back with this branch and a
white client can itself basically check
the hashes of the branch going all the
way from the top to the bottom and if
all the hashes match up then you know
great and the white clients is that
basically accepts and has this
confirmation that this particular piece
of data representing you know the
balance of some account or some storage
key actually is in the Merkel tree so
Merkel's reason aetherium are used for
transaction state receipts
patrícia trees allow for efficient in
certain delete operations block headers
contain these three trees so what's new
in Byzantium so Byzantium was this hard
fork that we did that went live on
October the 16th and it introduced a
bunch of wonderful new privacy features
so these are kind of the three main
probably most interesting features in
Byzantium so basically you know if there
are features directly but these are the
some three interesting things that just
become enabled by the new features in
Byzantium right so basically in
Byzantium we have what are called pre
compiles so basically think kind of
optimized virtual contracts don't let
you do elliptic curve addition elliptic
curve multiplication elliptic curve
paring and big number math and this
allows you to write contracts in
aetherium that do things like verifying
ring signatures verifying zk snarks
if you're applying RSA signatures so
this could be used to really increase
etherium compatibility with existing
systems that use just via public keys
and certificate authorities and so forth
ring signatures at Z key star
or both very powerful privacy
technologies and you'll be hearing about
these later and aside from this there
are also a bunch of important features
things like the static call opcode which
allows you to write safer contracts that
don't have like the same kind of mute
ability and reentrant see issues in some
cases this also lets you do pure
functional programming more easily
you have revert of return to copy revert
op codes that help you see if gas of
course that makes the EVM more efficient
in some cases and a bunch of this fairly
long tail of smaller improvements but
you know basically I would say the
motive main theme of the Byzantium hard
fork is adding in this kind of strong
cryptography that makes powerful
privacy-preserving applications possible
so if and there there are already lots
of interesting things that are being
built on on top of it there is already
you know I mean Zeki snark based
reputation system that I've heard about
yesterday so this is moving forward
quite quickly so future directions so
Casper um see a chungmu presenting right
after me Vlad is going to also present
about his version of Casper called
Casper CBC sharding so see my
presentation basically right at the end
of today though I will say that it's not
just about charting and it actually does
kind of get significantly broader than
that
also just all this long tail of kind of
eve of EVM upgrades much smaller
protocol upgrades now this is future
directions for the etherium blockchain
kind of course specifically there is now
a much larger list of future directions
for second layer architecture
intermediate tools systems that can be
built on top of aetherium this includes
scalability solutions like plasma this
includes all of the stuff that can be
built on top of ring signature but you
know elliptic curve multiplication
pairing CZK snarks this includes various
other privacy-preserving protocols this
includes like state channel systems and
all of these are also wonderful and
really important advancements that will
hope that we'll hear more about as well
so thank you and once again hope you
enjoy the conference
[Music]