DEVCON1 Understanding the Ethereum Blockchain Protocol – Vitalik Buterin

DEVCON1 Understanding the Ethereum Blockchain Protocol – Vitalik Buterin

Hello, everyone.
Welcome to the 3rd day of the conference:
deep dive into the Ethereum protocols…
So, we started off with the
wonderful presentation from Alex
on the protocol on top of which
the other Ethereum protocols run.
so it makes sense to follow that up
with a presentation on the Ethereum protocol.
So, you know, the idea behind Ethereum blockchain
first came around back at the end of 2013,
when people were getting
really excited about Bitcoin,
people were getting starting to get excited
about blockchain technology
and applications beyond currency,
and, those were public consensus
that blochains are useful for stuff,
and not just money.
So, you know, blockchains could be used
for asset issuance, crowdfunding,
domain registration, title registration,
gambling, prediction markets, IoT.
You know, people are coming up with some
new category of applications every week.
and so, the problem at the time is
that most exsisting blockchain protocols
were designed like this:
Single purpose tools that are specifically designed
around one particular application,
so, in Bitcoin’s case currency,
in Namecoin’s case domain name registration,
in Primecoin’s case trying to do a
scientific computing, and in my opinion
not doing a very good job of it.
So, then we had second generation protocols
that looked like this:
so we had protocols that had somewhere
around 55 different transaction types,
where one transaction type is something like
create a binary option, another one is
join a binary option,
then one for settling a binary option,
one for making a bet, one for settling a bet,
one for doing some kind of two-party dice game,
and every time someone came up with
a new kind of application that deemed
important enough to be worth including,
the people who were creating these protocols
were just adding another transaction type.
So, at the time we had protocols that had
55 transaction types, I even worked
for one of them for a few weeks,
and after I worked on one for a few weeks,
another two transaction types got added,
good old contracts for a difference…
so, even still it is pretty obvious,
especially from the standpoints
of our current generation, that this particular way
of doing things is just fundamentally limited.
So, what’s the solution?
Basically something like a smart phone,
so, the idea is that instead of… (laughing)
instead of having a protocol that is
designed around one very small set of use cases,
you just create a general prurpose operating system,
and you let people build whatever they
want as applications on top of it.
So, if you do that, then things suddenly
become better, maybe when you are inventing the
protocol, you might be thinking that ok,
people are going to use this for binary options,
contracts for difference, making two party bets,
doing domain registrations, and whatever
another 50 applications you are aware of at the time,
then you release the white paper, and six weeks later
you realise that people are inventing applications
that are going in a completely different direction,
and guess, your protocol does not even have to change
one single bit in order to handle them.
So, that’s the power of generality.
So, what is the concept behind Ethereum?
Well, it’s a blockchain.
Scene has been here for six years,
pretty boring.
With a few tiny additions…
So, the first important one is this concept
of a built in programming language.
So, in Ethereum there is a built in
Turing-complete scripting language.
It’s essentially a hybrid between kind of
standard virtual machine architectures,
Bitcoin script and a few other things,
and the point is that people can write programs
in this script, or more realistically
in high level languages
that compiled down to the script,
then people take their compiled scripts,
put them into transactions,
and send the transactions off
to the blockchain,
transaction gets confirmed,
an address gets generated,
and you have a special kind of accounts
at that address, called a contract.
So, two types of accounts: user accounts,
controlled by private keys,
the same old digital elliptic curve
signature algorithm we all know and love,
Second kind of account: contracts,
controlled by code.
So, these two types of accounts
in Ethereum essentially have
completely equal privileges.
Anything that humans have the right to do,
both have the right to do.
So, anyone can create an application
with any rules by defining it as a contract.
So, this is essentially the basic principle,
so, you know, the Hello World of Ethereum
is about creating a decentralised DNS system,
so basically the idea here is to create a system
where people can register addresses,
and addresses can be something dot something,
and if they own the address, they should be able to set
the IP address associated with that domain address.
So, the way the system works is fairly simple.
So, you see a sort of declaration at the top,
data domains, which is basically a mapping
between a domain name and a tuple
containing an owner and an IP address,
and two functions: one of them for
registering a domain, which basically says,
if this domain doesn’t have an owner yet,
then set the owner to whoever that send the transaction,
and you have another function set IP address,
which basically means,
if you own a domain, then you set
the IP address to whatever you want to set it to.
So, you know, a fairly simple rule set,
and real life DNS systems have substantially more
features to them, but the fundamental core
basically stays the same, and you could build a
more complex DNS system on top of it,
just by turning the IP address into a hash,
and throwing everything else on IPFS,
if you really want to,
but the point is: very simple logic,
you can write it in 10 lines of certain code
and publish it thru the Ethereum blochchain,
and there you have a system
that is basically like Namecoin.
So, this is basically the meaning of
“Anyone can create an application with any rules.”
Once this application gets created,
then anyone can interact with the application
by sending transactions that specify
the contract’s address as their destination address.
So, you send each transaction to a contract,
and that’s how you talk to an application,
that’s how you call functions, that’s how
you do whatever it is they want to do…
So, in Bitcoin the state is very simple,
it’s basically just a mapping of… a sort of…
well, technically speaking, a sort of list of
unspent transaction outputs, but whatever it means
in practice is the list of balances,
the list of the amounts of Bitcoins
that every person has,
and if you want a currency system,
then basically that’s all you need.
In Ethereum the state is kind of more complex,
it’s a sort of kind of key – value mapping,
going from addresses to account objects,
and there is two types of account objects:
one of them is the sort of simple accounts
controlled by private key,
in that case all you have is
a nonce and a balance,
the second kind is accounts that are controlled by code,
and in that case you have these extra two fields
that get filled up:
one of the is the code hash, so the hash of the code
of that particular account,
and the second is the storage trie root, which is
fairly intricate, and will be described later,
but basically represents the entire set
of storage of that particular account.
So, for example, if I create a contract
with this code, and then register a domain,
then the fact that one particular domain got registered
and got registered with me being the owner
and then I set the IP address to some particular value
– that information all goes
into this sort of persistent storage
of that particular account.
So, basically, a mapping from addresses
to blocks of this is the entire state
of the Ethereum system
at any particular time…
So, code execution.
Every transaction specifies a TO address
that it is sending to, so you know this is
fairly simple,
it’s a kind of logic that we all understand,
if you send a message, then you generally
specify who you are sending it to,
and you want to specify the contents.
So, what happens if you send a transaction
to a TO address?
Well, two options. One of them is that
the destination address is just
a private key controlled account.
In that case all you are doing is moving
Ether around,
so if you do that,
then it is basically just being a cryptocurrency.
What if you are sending to an account
that has code?
Then what that is doing is basically activating the code,
and it’s actually letting the code run some number of steps.
So, code in Ethereum could do three things:
number 1, you could just send Ether to other contracts,
number 2, you can read and write from the
contract’s own storage,
so, for example, if you are going here, then the way
that I would call the register function is
by sending a transaction with data
formatted in a particular way,
and what the transaction is going to do is
going to start running the code
that actually represents the register method,
and specify that
that is it sets a variable,
when that gets compiled to is
setting a particular key in the contract’s own storage.
Then the 3rd thing code can do is you can
call, or sort of create a certain virtual sort of
transactions, that go to other contracts.
So, theoretically I could create another contract
that has some different set of rules,
and that contract itself can actually interact
with this contract.
That contract itself can
register domains, set IP addresses of domains, thoretically it could do just about
anything that an account controlled by an address can do.
So, every full node on the blockchain
processes every transaction and stores the entire state,
just like Bitcoin.
It’s bold because it’s important.
So, this is one of those points that’s
important to make, because people often ask:
“Well, if I publish transactions to Ethereum,
who is actually is going to enforce the contract,
and how many nodes are running them, and so forth”,
for Ethereum 1.0 the answer is very simple:
every node in the network runs every transaction,
and that makes the process of running a transaction.
If that transaction goes to a particular contract,
it actually involves executing contract’s code,
and you know, setting the answer of changing the state
to whatever the state is changed
after the contract gets executed.
so, from that standpoint
you can actually think of it
as being a rather fairly simple system,
you know, you can think of this system
as a data base, and you can think of
each of these contracts as being programs,
that are sitting on one computer, except that
the computer is massively globally distributed,
it is actually a highly secure network,
backed by tens of thousands of computers
around the world.
So, it’s bold because it’s important.
So, gas. This is one of those key mechanisms
you rely on the security of Ethereum.
So when you tell people that you have
a Turing-complete programming language,
and that you let untrusted parties send code
that gets executed in the Ethereum system
on every single computer in the entire network,
the first thing that they’re going to ask, is
“Well, what about the halting problem?”
There is this very widely known result
in computer science, which basically says
that it is mathematically impossible
to create an algorithm which can tell,
whether or not any given program is just gonna
to keep on running for ever.
So, how does Ethereum prevent attackers
from creating programs that just keep on running
on everybody’s computer for ever,
and the answer is this concept of gas.
So what this basically means is that
Ethereum network charges a fee for every
computational step that a contract execution takes,
so the specific way it is implemented
is that every block in the Ethereum
block chain has a gas limit,
so basically a limit on the computational steps…
Right now the gas limit is set to 3’141’592,
which is a nice number that we picked
because we are totally not math geeks…
So, if you are a miner and you’re creating a block,
then chances are you want to fill it up with
the transactions that give you the most profit,
so every transaction specifies a gas price,
basically an amount of Ether it is willing to pay
per unit of gas,
and it specifies the maximum amount of gas
it is willing to take.
So a transaction might specify:
“I am paying 50 Shannons which is basically
50 billionth of an Ether per unit gas,
and I am going to consume up to 500’000 gas.”
Miners see all these transactions coming in,
they select the ones that have the highest
gas price, and include them their block.
So, once each transaction specifies
it is willing to spend up to 200’000 gas,
then two things could happen:
one of them is that execution takes up
less than 200’000 gas,
in which case everything happens normally, it’s ok,
the transaction pays only for the
computational steps that it uses,
second case: it goes over the limit.
If that happens, then all the execution
gets reverted, and the reason
why that has to be done is because
if execution could stop halfway through,
then you might be able to sort of
perform weird attacks on contracts,
which try to set… execution just to expire
when one half of the changes gets made
but the other half doesn’t get made,
and you know, we kind of prefer developers
just not to worry about that.
So, only execution gets reverted,
but the transaction still has to pay
for the gas anyway,
so don’t run out of gas!
There is also gas is just not a
1 computational step – 1 gas thing,
There are some operations,
operations for example that increase
the amount of storage
that every node has to store,
and those operations take up
a very large amount of gas,
so the gas system is also a sort of
fairly intricate set of incentives
that are designed in order to encourage
using the resources of the
Ethereum system responsibly.
So gas limit is the sort of counterpart
to the block size limit in Bitcoin.
How is the gas limit set? Fairly simple
voting mechanism right now:
if you mine a block, then you can upvote or
downvote the gas limit by a factor of 1/1024.
There is a default strategy that we currently instruct
every client to follow in the source code, which is:
you have a minimum of 3’141’592, and if the usage
starts bubbling up and hitting close to the gas limit,
then we target 150% of the long term
exponential moving average of the gas usage,
so, basically sort of targeted so that
if it does get filled up, the gas limit get
sort of just a bit higher then what blocks normally contain.
There are alternative strategies that worth exploring,
so one of them is for example targeting a specific
uncle rate,
what uncles are I’ll explain a bit later,
but the general concept is that
the more the blockchain gets clogged up,
then there are basically the more blocks
and the block are slower propagating,
so more block get lost and and doing not making
it into the main chain,
and as it turns out,
thanks to a feature of the Ethereum protocol,
you can calculate how much this is happening,
and so you can target a particular X amount
to which it is happening, and you can say:
“If we are seeing more that let’s say more then
20% waste from the blocks just falling off the network,
then the gas limit should go down.”
So there are other strategies that we were considering.
So, transactions contain basically
seven sets of values.
Number 1: nonce, so what a nonce does is basically,
every transaction has to have a unique incrementing
so the first transaction you sent from an account
has to have a nonce of zero, second transaction
you send has to have a nonce of one, etc.
And the reason this is done is to prevent
replay attacks.
So if Alice sends 10 Ether to Bob,
you don’t want Bob to take that transaction,
and reinsert into the blockchain 10 times
to own another 100 Ether, nonces fix that.
gasprice, the amount of Ether for unit gas,
we already covered that,
startgas, same thing,
to, the address of the account you are sending
the transaction to, or in order to call a contract,
value, the amount of Ether you are sending,
data, is just a field of data,
transaction senders can set the data
whatever they they want, it just an array of bytes,
no limits on length, but the more data
a transaction includes, there is actually
a fee for that in gas,
so you have to pay an extra 68 gas
for every byte of transaction data that you include.
v, r, s, the values in elliptic curve signature,
so if you are familiar with cryptography,
you’ve probably heard about,
you have seen the r and the s.
The v value is an extra flag needed
for public key recovery,
so basically, instead of checking the signature
against the public key, you actually derive
the public key from the signature.
So, there is this concept called receipts.
So receipts are objects that get kind of
hashed into the Ethereum blockchain,
and every transaction has a corresponding receipt.
So, these receipts have a few pieces of data.
One of them is an intermediate state root – once again,
I’ll describe the mechanism later,
but it’s a kind of hash that represents
the entire state after the transaction
gets executed.
Number 2, cumulative gas use, so the total amount
of gas used in that particular block,
including that transaction,
so those first two things are needed for the kind of
step-by-step accounting,
that actually makes it possible
to kind of checks the validity
of individual transactions very easily,
and the third thing is logs, so logs are
this special feature in Ethereum, that…
it’s kind of a different kind of storage,
so, in general, when you set variables,
that gets set in account storage,
and that can be read or written by contracts,
logs are basically append only, so if you have
a transaction in one particular block,
and it creates a log,
this log gets hashed into that particular block,
but they are not visible (for contracts),
they can not be accessed by contracts,
and they appear just in the block,
they are not in any kind of persistent state.
So, nodes can choose just not store logs,
and they can prune them.
Logs are also 10 times cheaper
in terms of gas consumption then storage,
and the purpose of logs is to allow efficient
light client access to that records.
So one example where you want to use a log is, if you
go back to the DNS example, you might want to add a
single line to create a log in the register method,
and in – let’s say – in the set_ip method.
And the reason why you want to do that
is basically in order to allow light clients
to very quickly scan through the logs,
and sort of see all the instances, at which
domains got registered, IP address got changed, etc.
So there are lots of applications that wants to be able
to sort of have a history of things that happened,
and logs are a convenient way of supporting that.
So, logs have a data field, and have up to 4 topics,
and there is a protocol that uses Bloom filters
to make it very easy for light clients to kind of
search through a log.
So basically if you create a log that has
a particular topic, then you can very easily
search through the entire blockchain
and sort of identify all of the logs
that matched a particular topic.
So, Ethereum Virtual Machine.
So, once again, as a I mentioned, it’s this sort of
combination of stack-based architecture
and traditional virtual machines.
So inside the virtual machine you have
the stack, basically 32 byte fields,
up to a max. of 1024 of them.
Memory, just, it’s an infinitely exapanding
byte array, but the more you expand the byte array,
the more gas you have to pay.
So, most of the limits in Ethereum,
they aren’t static, they are economic, and that’s
just a theme you’ll see again and again.
Storage, permanent contract storage
you can read and write to it,
Environment variables, so for example
the virtual machine can access
to the block number, the time,
the mining difficulty, previous block hash,
and a whole bunch of other data,
so one possible use case of that is what say,
if you have some kind of financial derivative,
that will be only processed or called after some
particular time, you can say in the contract,
you can check the current block timestamp
against some particular limit that you’ve set.
Logs, so the virtual machine can create these logs,
and there is an opcode by which the virtual
machine itself can call other contracts.
So this is basically the environment,
within which this contract code gets executed.
Now, you don’t have to write in virtual machine
byte code yourself. There are high-level languages,
and one of these high-level languages is called
Serpent, so this is one of them,
there is also Solidity which is used much more
right now,
there is one called LLL, which is
much more low-level,
if you want to go to really low-level code,
and be as efficient as possible, you might want
to use LLL,
although, in my opinion, you should probably
consider Serpent as well, because Serpent
allows you to go as low-level as LLL does,
and it has high level features as well.
So, basically you write code on these languages,
then you have compilers, then you compile the contract
into byte code,
and you can publish the byte code in a
transaction, going to the block chain.
The ABI.
So when you send a transaction, let’s say that
I want to call the register method of that
particular DNS contract that we keep on using as an example.
Function calls get compiled into transaction data,
so, in this case the way function call gets encoded is,

the first 4 bytes are function ID, the next
32 bytes are the first argument,
so this was the domain
that I wanted to change the IP address of,
and the 2nd argument is another 32 bytes,
which is the IP address that you want to set it to.
So, every time you call a function of a contract
in Ethereum, it actually gets compiled into a transaction,
which is encoded so as to use this algorithm,
which in simple cases looks like this, just 4 bytes,
32 bytes, keep on going with 32 bytes,
but there are some special cases, involving
sort of variable length lists, and so forth.
Everything in Ethereum relies on this one
serialization algorithm called RLP,
recursive length prefix encoding.
It is very simple, so basically… you know,
it’s recursive length prefix encoding,
so you take the thing,
so in this case you take
the “dog”, and you just hex encode it,
and you have 64, 6f, 67,
and you before it… you prefix it with the length.
In this case the length is 3, so you can see a 3 here.
Over here you have an empty string,
and so you have a length of zero.
Over here this is a list, it still has
a length of zero, but it has a different sort of
start flag, because it is meant to be a list and not a string.
This is the – for people who are set theoretic
geeks – this is the set theoretic representation
of number two,
it gets compiled to this… encoded to this, rather.
If you have a string, it gets compiled, it gets
realised into this.
There are like five implementations of this,
there is a much more detailed description on the Wiki,
but basically this algorithms is used for blocks,
transactions, network protocols, or everything
in Ethereum land.
Ethereum also has a cool new mining algorithm.
So it is called Ethash.
So the purpose of this is
to be GPU friendly and ASIC hard,
so its target is GPU as much as possible
and basically prevent the problem in Bitcoin,
where you have the sort of spell,
these specialised miners,
extremly large mining farms, taking up
huge percentages of the network,
so the algorithm uses memory hardness
to accomplish this goal,
so instead of traditional poof-of-work
algorithms like Bitcoin where the bottleneck is
how much computation you can do,
here the bottleneck is memory access.
And the theory behind this is, that memory is
something which is highly optimised,
and people spent billions of dollars
in existing computers to get optimised already,
and so the opportunity to make further optimisations
is theoretically smaller that it is for computation.
so, the way that it does by using this clever
multi-level DAG construction,
so basically the idea is, that you start off with a seed,
then from the seed with a memory-hard function
then create a cache, from the cache
you create a dataset,
and the dataset can be created in parallel,
so each individual piece of the dataset
gets created by hashing together 256 parents
that come from the cache,
and if you want to just actually run the algorithm once,
then all you have to do, is to take the data
you are mining on, turn it into a seed,
then you grab a random 64 nodes from
the pieces of the dataset, then you get the result.
So, what’s the point of this?
The point of this is that mining with this algorithm
actually is memory hard,
because if you want to mine,
and if you want to mine at any reasonable speed at all,
then you basically have to pregenerate this entire
1 Gbyte of dataset,
so that every time you pick a different nonce,
you can just sort of sample from it,
and that happens fairly quickly.
If you just want to verify blocks, then you
just don’t actually need the Gigabyte.
All you need is a cache,
and the reason why,
is basically that when you get to this stage,
you basically don’t need the entire thing,
you just figure out what 64 indices you want,
then from each of those 64 indices you just compute
it from the cache.
Now this does require to make 16384 hash calculations,
but as it turns out, that’s actually not that bad
if you are only doing it once.
So, because your verification only needs to
happen once, this kind of low memory, slow
verification process actually works.
But if you want to mine, then you want to do it
with a lot of speed, so you need to have the Gigabyte.
So, this is kind of the basic principle behind of
why mining was designed in that particular way
that it was in Ethereum.
So, uncles.
So, in general, Bitcoin has a 10 minute blocktime,
Ethereum has a 17 second block time.
Why is the block time not something even shorter,
like 1 second?
The problem with fast blocktime
is basically stale rate and network latency.
So, if the block time is extremely long,
like 10 minutes, you can think of network latency
as being negligeble by comparison,
you can think of it as basically being instant,
and so you basically don’t have problems.
Once you start pushing blocktimes down,
then your problem is that you have this risk,

that let’s say in Ethereum you have one block,
it is 2059, then at some point someone creates
another block, 2060,
that block takes time to propagate through the network.
And so someone else might make another block,
before hearing about this block.
So we have two blocks, built on top of the same block,
2059, and they’re kind of both competing with each other.
So this is called a fork, and the problem is that
one of the blocks has to eventually win,
and the block that doesn’t win, just gonna
get discarded, and the person that mined it
doesn’t get a reward.
So, this leads the centralisation risk, so basically
the issue is, that the more powerful you are as a miner,
the better you are getting high network connectivity,
and if you created the last block, then you
actually don’t have this risk, because you can
immediately start making the next block.
So, the more these network connectivity issues
become importance, the more problematic
the cetralisation issues become,
and you have this effect, where large miners
end up being more effective than smaller miners.
So, our solution is this mechanism of uncles,
which is basically that, if this happens,
then sure one of this blocks is going to win,
but whichever block looses, it gets kind of
reincluded in the blockchain, and it still receives
most of the reward.
So, the point of this is it basically cuts
the centralisation incentives by about 85%,
and it kind of allows the Ethereum blockchain
to continue to be relatively safe
under somewhat harsher circumstances,
both in terms of fast blocktime,
and in terms of high transaction load.
Merkle trees.
So how many people have seen the Economist cover
of Blythe Masters saying it’s all about the blockchain…
Well, my opinion is it’s all about the Merkle tree. (…)
So, the point of Merkle trees is that there is
a construction that allows for compact,
efficiently verifiable proofs
that a particular transaction
was included in a particular block.
So, the general principle is that – this is actually
existed in Bitcoin – if every block has a few hundred
then if you wants to verify, that one particular
transaction was included in a block,
then you don’t have to download the entire block.
All you have to do instead, you have to download
one sort of branch of this tree,
and the tree is a kind of a hash tree, where every single
set of the tree is actually a hash of the two nodes bellow it,
so, the way you do it is to download this branch,
you download the specific part of the tree that’s going
down to your particular transaction,
and you check the hashes
that are just going just up the branch.
You don’t check all the hashes, just the hashes
that are relevant to your particular branch,
and if all those hashes check out fine, then you know
that your transaction, that particular
transaction actually is in that particular tree,
and so is actually in that particular block.
So the reason why this mechanism exists
is basically for light clients.
So what a light client basically
is a client that accesses the blockchain
without processing every single block,
without downloading every single transaction.
Why you want this?
Why, it is pretty obvious.
You know, Bitcoin blockchain
right now is 30 GBytes, and a Mbyte
gets downloaded every 10 minutes,
it might be good enough for a high-powered laptop,
it’s probably not good enough for this,
and 30 Gbytes is probably too much for the devices
that is going to be creating.
So instead of that you use sort of clever tree
protocols, in order to allow these devices
to only verify the absolute minimum of information
that they have to, that has relevance
to their particular transactions.
So, in Ethereum the Merkle tree mechanism is quite
a lot more intricate that it is in Bitcoin.
So, the idea with Ethereum is, that it is
not just transactions that get stuck into Merkle trees,
it is also the state.
So, if you hear about the concept of a state root,
what it’s basically is is a sort of root hash,
and from this root hash you have another tree,
and this tree contains hashes of
hashes of hashes of hashes of data,
representing the state of basically
every single account in Ethereum.
So, you have these account objects,
somewhere at the bottom of the tree,
nonce, balance, code hash and storage,
and storage is yet another tree.
So, the point here is that, if one these
light clients, be it a phone or an IoT device,
or whatever else, wants to know,
what the status of one particular contract is,
it doesn’t have to process the entire blockchain,
it doesn’t have to trust anyone,
all that it needs to do is just ask for
a Merkle proof,
ask for the sort of branch
of the tree, and verify just that one particular branch.
So this basically the concept of the Ethereum
light clients, and there will be a presentation
about it I beleive right after lunch today.
So, every block header actually contains 3 trees,
transactions, states, and receipts.
So transactions are transactions,
we know what those are,
the state is the state of every account,
balance, storage, all the kind of static information
that you need to know,
and receipts are… they consist of the sort of
extra auditing information, and they have all the logs,
so if a light client wants to know,
particular logs are associated with a particular topic,
then the light client is going to ask
for Merkle proofs of logs.
So, future directions.
We talked quite a bit about this on Monday,
but the general categories are:
(1) proof of stake,
so where proof of stake is going
to fit is just at the top, so it’s just a change
to the consensus algorithm,
so instead of users having to verify proof of work,
they are going to verify validator signatures instead,
and the way you join the validators’ set is described
by submitting a security bond,
so that entire mechanism is going to either be
part of the protocol, or it’s sort of being specified
in one particular contract, not fully decided yet,
and from a user perspective all that’s going to change is
that instead of validating a proof-of-work nonce,
you are going to have a list of signatures that you validate instead.
Blockchain rent.
So the idea of blockchain rent is basically that right now
you can access storage, your code can set storage keys
and those storage keys remain there forever,
but that might present some sort of serious
long-term risks,
because the amount of storage that the Ethereum
blockchain stores could keep going up and up,
and there’s not enough incentives
in some people’s views to weed this storage.
There is a bit of incentive, because if you kind of
delete store, then you get a refund, but there is no
incentive not to use the storage like a bank.
So, blockchain rent is the idea that project have to pay
some amount per month for every storage key that it has,
so instead of storage being permanent, it could last
for 1 year, 2 years, 5 years.
If that’s going to happen, that’s going to be
as reasonable as possible, but that’s the kind of
basic principle.
Virtual machine upgrades.
So that’s not going to change any other semantics,
it’s going to swap out the virtual machine
the code runs on,
so in practice for developers it’s going to mean
very little, because theoretically you could still program
in the same languages,
will be a different compiler, or it compiles to a different
byte code, but if you want to do things faster,
then you could potentially even program
Ethereum code in things like C++ or Java.
Scalability, talked about it on Monday.
So you know the idea is not having every node
process every transaction, but right now,
as far as the Ethereum protocol goes, all this is basically at.
Thank you.

Add a Comment

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