Devcon 3 report: Day 1 - core systems

Other reports:

• Devcon 3 - Day 1
• Devcon 3 - Day 2
• Devcon 3 - Day 3
• Devcon 3 – Day 4

The 2 talks to watch are: “Regulatory update and look ahead” (covering a security is) & Vitalik’s talk at the end of the day on scaling/sharding & Ethereum 2.0.

Format for the week will be:
Day 1 is core tech
Day 2 is research
Day 3 is Dapps
Day 4 is ?

Ethereum team introduction

Vitalik - Founder
We are working on research into what the future of Ethereum will look like, to support the future of Dapps.
Working on Casper, scalability, etc.

Martin Swende - Security Lead
Is across all the projects, to try and keep across security issues. Especially the network protocol.

Peter Szilagyi - Geth team lead
Since Shanghai Devcon 2 last year.
Released mobile library.
Made a new P2P protocol for private networks
Released a light client version
Added Proof of Authority to the plugable consensus, and it is being used by one of the testnets
Focusing a lot on performance bottlenecks.
Reduced DB size by 50%, syncing time by 60%

Zsolt - Geth, Light Client dev
Made lots of progress on light client (syncing, log searching, p2p discovery, etc)
Looking forward to the production release

Dr. Christian Reitwiessner - C++ client / Solidity team lead
Looking to get C++ client working again
Snapshot syncing. Removing race condition bugs.
Improvements to EVM, v1.5
Working on ZK-Snarks

Yoichi Hirai - Formal verification Engineer.
Writes mathematical proofs
Followed the Metropolis changes, wrote test cases against the implementations.
Helping to prove Casper. Will talk further on this later today

Alex Beregszaszi - solidity, eWasm, ethereumJS
Solidity changes so far: Function types, contract metadata, new compiler interface
Solidity futures: new language, new formal verification checker (snt checker?)
EthereumJS - support for Byzanthian fork. Important as other projects rely on it like Remix.

Yann Levreau - C++/Remix developer
Remix is a web based IDE.
Working on improving UI and backend code.

Piper Merriam - Python team lead
Established a spec for packaging smart contracts, and looking to get that implemented across the ecosystem
Responsible for a lot of the Python tooling. Working on bringing it's quality up to par
Working on an alternative EVM called pyEVM
Looking to bring it online as a new light client

Viktor Tron - Swarm team lead
Swarm has grown beyond the intial scope of a flie store for Ethereum, now covers high bandwidth communication
Tomorrow session will be the main session on it
Developed a network simulation to check things like high node churn.
Main initial release will be around cloud storage to sync between their devices.
3rd party application uses, like live audio streaming.
Working on privacy and censorship resistance communication.

Vlad Gluhovsky - Whisper lead
Whisper is meant to deliver data. Want to make sure no data or metadata is leaked. Tomorrow will talk about this

Everton Fraga - Mist team lead
Been working on bonding some other projects into the Mist browser.
Working on making it more scalable. More info in Friday's session.

Fabian Vogelsteller - Mist, web3.js
Will do a session later in the week on the 1.0 refactor.
Proposed a new ERC 725 - around identity.

Regulatory Update and look ahead - Jerry Britto
HIGHLY suggest you watch this session if you plan an ICO or any serious Blockchain Dapp

Coin Centre seek to educate policy makers
Year in review:

• Uniform Law Commission - supplements the money transfer license. Helped define what "control" means, to help be clearer who needs a license. Only if the company "controls" the currency, helps with some exemptions. Defines who is an intermediary and need regulation
• Helped deliver a bill into congress around tax - examples like using ether to pay for a smart contract execution is technically taxable
  any transaction below $600 you don't need to track.
• FCC - talked about securities and tokens.
• Potential terrorist use of cryptocurrencies - put on a demo day to help educate members of congress. Conclusion at this point, it is a serious potential threat, but isn't an issue at this moment.

Characterizing issues on the horizons:

• TOKENS
• Regulatory hotspots around securities regulation & AML (Anti money laundering)
• AML law boils down to Is the token being used as a currency substitute. Is there a centralised issuer tho can also withdraw from circulation. If yes, they are an issuer. Otherwise they are an exchange (like Bitcoin/Ether)
• Securities law boils down to: is the thing being sold as an investment. Is there a person upon who investors rely?
  No one person is relied on around gold. But a share/stock of Apple is a security, as you rely on the company.
• Issuer vs. Network
  Money goes in, more goes oug -> Investment
  Money goes in, utility goes out -> Network

Super useful diagram of what is a security.
Coin Center is helping to suggest that FCC should focus on investments controlled by a single issuer, to help protect people, but leave the rest of the ecosystem open.

Ethereum in 25 minutes - Vitalik

In 2013 blockchains are useful for 'stuff'. Not just money but for thigns like Asset issuance, crowdfunding, domain registration, IoT, voting, etc. More than just transferring BTC
Original Blockchains were single function.
Why not make a protocol that works like a programmable smart phone. So that a single blockchain can run multiple use cases / apps. General purpose computation.
Smart contracts that could control digital assets. When to release assets to other people.
Also to program other business logic, like voting, ENS, etc.
Every transaction specifies a TO address. The code at that address executes. Code can send ETH to other contracts, read/write storage, call other contracts
Every full node on the blockchain execute all transactions.
Halting problem was an issue (e.g. infinite loops). So gas was implemented to help constrain it. Charge a transaction fee per computational step.
Logs are an append only data, not readable by contracts. 10x cheaper than storage. Up to 4 topics for bloom searching. Intended to allow efficient light client access to event records (things happened)
You don't write in DVM bytecode, instead you code in Solidity, Viper, LLL, Bamboo.
The ABI describes the function calls available on a contract, so that clients can call into it.
Byzantium introduced some precompiled functions to verify: Ring signatures, ZK-SNARKS, RSA
Also added new functions like assert(), revert(), require()

Future directions for core Ethreum: Casper, Sharding, EVM & protocol upgrades.
Are still other things in broader ecosystem like Plasma, state channels.

Methods for deterministic parallelizing message processing - Martin Becze
Primea https://github.com/primea
Primea started in ewasm. Plan was to build off web assembly instruction set, to add in metering.
Issue was that you had to run transactions sequentially, not concurrently.
Is a layer that sits between VM instruction set and consensus mechanisms.
For scalability, need to apply locality.
Right now all contracts exist in the same namespace. One way to impose locality could be that each contract has subcontracts that only it can access. Means the subcontracts could all be executed in parallel as they can't effect others directly. Problems with nested contracts. Inflexible, inefficient.
Next approach Try to build up a graph of how contracts interact, then use that to define shard boundaries. Can create a bigraph from this.
Got very very technical from here on, about different messaging strategies to try and break tings up and be more async.

Practical applications of off-chain computation in the light Client ecosystem - Zsolt Felfoldi
Do computation, do a validation process to verify it.
One application is for event filtering for history searching. If we shard or do state channels, there is going to be a hierarchy of data that needs to be searched.
Currently uses bloom filters. But in a bloom filter you'd need to filter through 4million+ blocks reading all headers (currently 2.2GB). Light servers can search and present it to light clients, but clients need a way to validate it. Bloom trie root hashes can be interactively validated on chain.
Users want to observe multiple subchains (when sharding) and get notified by new events using a complex filtering criteria. Light clients can hire a full node (light server) to validate and certify a subchain. Client specific event filtering can be done server side.
Chain filters. Deterministic operations on an input chain.
Observer chain: belongs to a single node, processes multiple observed chains. Checks the current best heads of observed chains.
Building a filter hierarchy. Observers can build on top of other observed chains. Can have base ones filtering out bulk of stuff, and then further layers refine it further.
Build up a market of services for light clients.

Parity: A Light client for heavy chains - Robert Habermeier

Ethereum clients currently can be defined broadly as:
Full nodes - they check and verify everything. But storage and computation requirements are heavy.
Light client - verify block headers, but not checking transactions. So checking that mining consensus is working.
Thin client - isn't checking consensus, relies on others to do it for them.

Light clients check validity of headers. Does not check validity of state transitions. Might lead to some targeted attacks, attacks wouldn't work on full network which is validated, but targeted to a single client.
Protocol goals: minimize roundtrips and bandwidth required. Full nodes are serving data to light clients, need to think how to present denial of service
Put multiple requests into the same request package (I need block X and account Y).
Can use state proofs to get a subset of a state tree.
Metering system, using request credits. Each node can come up with their own pricing. Different requests have different costs.
The average person won't run a full node, but we need them to support the network of light clients. Needs an incentive system.
Pub/Sub for events. Reduces polling and excess work.
Warp sync: Users usually don't care about really ancient data. Can just jump to more recent blocks. Ancient block download can happen later (e.g. when on wifi).
RPC pitfalls: on light clients some RPC calls don't work.
Eth_getLogs can be very expensive if you are checking all history of everything. If just watching the head for events, is much cheaper.
Eth_get*ByHash the hash of the block has no info about the actual block number. So will need to search through the history and maybe forks or uncles. Lots of work to search
Eth_estimateGas need to check state proofs of multiple executions. Lots of computation to guess.
Lightclient+whisper+ecosystem. Light clients are viable for mobile devices (on wifi) whisper makes a powerful tool for messaging and medium latency state channels. Projects like status are already using this and showing how this can be done.
Looking at compiling light client into Web Assembly. Could embed into a web page.

 

Verifying Casper - Yoichi Hirai
Casper is the planned Ethereum Proof of Stake protocol.
There will be a capser contract on each (divergent) fork. Validators deposit ETH, when they do the right thing they get rewards, bad they lose ETH. Validators can vote for a block. Can't double vote or they lose.
To avoid losing deposits, just need to be careful about what you sign. Will only really lose if you are doing bad things.
When a block has 2/3 votes from validators, then they are justified and later finalised.
Next 10 minutes is lots of mathematics diagrams. Track the ancestor blocks and votes and punish bad people who vote for divergent forks.

Sikorka: Proof of presence for Blockchain applications - Lefteris Karapetsas

Network of detectors that provide proof of presence. Different types of detecots exist. Contracts choose detectors depending on security requirements.
Users interact via a phone app.
Proving presence for bureaucratic reasons. AR games. Objects directly interacting with smart contracts (smart locks?)
Different detector types that the system can use, contracts select types based on security requirements.
One detector is the "Revealo temporal BLE tracker". Provides accurate location, uses temporal keys to preserve privacy.
A super cheap detector could be a screen somewhere that generates a new QR code every 10 seconds that you can scan to show you were there.
There is a central Sikorka smart contract controller that indexes all the contracts. And a contract interface you can use to hook into the system.
Basic usage could just use your phones GPS (but can be spoofed).
More secure uses a detector. You interact with the contract to show you are near the detector.

Julia: IR (Intermediate Representation) for Ethereum Contracts - Alex Beregszasci
Why do we need an IR?
Complexity of auditing solidity contracts. Helpers & optimisations of Solidity. Porting Solidity to other VMs.
Auditing that the compiler did convert solidity into the correct bytecode is difficult. EVM bytecode is very cryptic to read.
Compiler pipelines usually go in 3 stages: parse/analyse, optimise, create bytecode.
But the solidity compiler only really does the 1st and 3rd. Smooshes it all together. Julia will sit in the middle to help support other functions.
Benefits are that more of the compiler can be moved out of C++ and written in Julia, for simpler reading.
Also means it is simpler to optimise code before generating bytecode.
Julia currently supports: typed variables, functions, switch statements, if, loops.
Will support output to EVM, EVM 1.5, ewasm, others (like outputting into JS or C for integrating into UI side)
Could get your own DSL to compile into Julia, which could then output into EVM bytecode.

Package management for smart contracts - piper merriam
https://Github.com/pipermerriam

Last year they got togther and proposed ERC190 smart contracg package spec
ERC190 deterministically create a package that is immutable.
Packages can include: sull source code, compiled assets, compiler info, ABI, address of deployed contracts, link reference info
Useful for public chains, but also for private chains.
Example of the simple inheritable contract.
The .json file of the package defines metadata, and a location of the .sol source on IPFS.
Your contract can have its own package definition, that has a dependency on another pacakge.
Package could not just store the .sol, could embedd the compiled bytecode, or just the deployed address so you can link to it.
Could use it in a wallet, import the package and it will give you the ABI that you can interact with.
Could combine it with ENS and have package indexes that list source of truth for contracts.

Programable incentives: An intro to cryptoeconomics - Karl Floersch
Blockchains have open access. Anyone can deploy a contract or send a transaction.
Trusted execution. All smart contracts and transactions will execute as defined.
Now we have programmable money.
Designing incentives. You can't talk about blockchain consensus security without reasoning about economics.
So you can combine cryptography (hashing, signatures, etc) + economics (tokens, voting rights).
Want to use cryptoeconomics to enable good outcomes like trusted execution, and protect against censorship.

Example project: Market maker. A simple automated market maker contract.
Checklist

1. Design a mechanism
2. Analyze incentives
3. Make a website
4. Observe behaviour
5. iterate

Deploy a market maker contract with an initial deposit of ETH and tokens. Is an automated exchange to trade ETH for tokens. It will dynamically calculate token prices based on what is left in the contract. The contract owner will get some fees back.
Owner gets a passive fee income. But they have their capital locked up.
Token buyers are happy because they get small transaction fees, it is a trustless exchange.
Can come up with ideas, just deploy it out into production and see how it goes. Make sure you verify your source on Etherscan.
Allows anyone to just come up with ideas and get it out there.
Make sure you share your findings, so the ecosystem learns.

Casper the Friendly GHOST: A correct-by-construction blockchain - Vlad Zamfir
https://github.com/ethereum/cbc-casper

All the Ethereum proof of stake research projects are with the goal around finality safety.
Traditional consensus protocols decide on one block of transactions at a time.
Point of PoS is to incentive nodes to do the right thing. Need to prove that it is fault tolerant, and when there are faults, that it can recover (and penalise the bad actors).
Vlad just talks too fast and clicks back and forth through slides too fast to keep track of notes sorry.

Introducing the TrueBit Virtual Machine - Jason Teutsch
https://truebit.io

Is now deployed to testnet
Smart contracts can only handle limited computation execution time.
Truebit is a scaling solution for computation. Do the heavy work off chain. Uses interactive verification for large transactions. Help to bypass the gas limit.
Is an ethereum smart contract + a new off chain architecture.
Solver proposes the solution, submits it. Anyone can challenge it and put up a deposit. They play the verification game to see who was correct, loser loses deposit.
Computation runs in a TrueBit Virtual machine. Tasks must compile and run across all machines. The TVM breaks it down so that the smallest piece of execution can run on chain. For when there is a disagreement, the one step where people got a different result can be run on chain to determine the correct result.

Scaling Ethereum Smart Contracts - Joseph Poon
https://plasma.io

Many blockchains on a blockchain. Can bond your private chain to the public network.
Deploy a plasma smart contract to the main blockchain. Can now run your own child plasma chain. Periodically commit block hashes to the main chain contract.
Big changes can happen on the plasma chain, but just a tiny block hash is submitted onto main chain.
People can submit a merkalised proof if someone tries to commit an incorrect hash to the main chain.
If someone is withholding block data and isn't letting it continue, then you can exit the child chain, have eth roll back up to the main chain, and then create a new child plasma chain
Could credibly securely spin out these plasma chains to scale computation for specific use cases. Like a Reddit comment chain, ebay chain.
The point is to encompass all worldside computation. Computation can be done on child chains, with final state committed to the main root chain.

ZoKrates: A Toolbox for zkSNARKs on Ethereum - Jacob Eberhardt
On chain processing is submitted as a transaction. Is executed + validated on chain.
Off chain processing, the transaction is executed off chain. Just the validation happens on chain.
Means that private information can be used without revealing it.
Truebit is one way of doing this. Another is using zkSNARKS
zkSNARKS, verification cost is independent of computational complexity. Short & non-interactive proofs.
Define computation as mathematical circuits. But is very complex to create these yourself.
I like thinking of this as: Hashes lets you verify large pieces of data as a small hash value. zkSNARKS allows you to represent a large complex execution as a tiny proof.

ZoKrates wants to provide tooling to make it easy to support zkSNARKS from end to end. And to integrate easily into Ethereum. It has a DSL to specify your computation, has a compiler into provable constraint systems, support for the phases (setup, witness, etc), and a contract to verify the computation on chain.
On chain verification currently costs about 1.6m gas.

Designing Maximally Verifying Light Clients and Sharding- Vitalik Buterin

Watch this session.

Subtitled as "a modest proposal for Ethereum 2.0 over the next 4 years"
Ethereum works. Many applications. High adoption >460k tx/day. Which is about 7tx/sec
Ethereum nodes worldwide. US has 30%, Canada 5%, Australia 2.8%
The Byzantium fork added in privacy preserving features, that will enable zkSNARKS, ring signatures.
Scalability is still a current challenge. Right now every node runs every transaction. And transactions are not parallelisable.
Sharding is a way to split up the blockchain state. Only allow async calls between shards. Each node only processes transactions for a shard, so a small portion of all network transactions.
Governance & protocol evolution has been a challenge. Hard forks making deep changes are hard. Long time to code, test, and a high risk of consensus bugs.
But we want to make some big changes to enable Ethereum 2.0 (EVM upgrades, more precompiles, etc.). How do we handle the trade off.

1 blockchain 2 systems:

Have a Validator Manager Contract. Runs a PoS system. Would keep track of validators, to join and leave as a validator. Each validator can gets assigned to shards randomly, can make blocks. Block making protected by rewards and slashing.
Connecting the shards go through the contract via messages.
Gives a way to experiment with this as a contract, with less risk on the main chain, and doesn't require a hard fork.
Can evolve shards quickly, will letting main chain be more conservative.

Sharding roadmap

Having shards will allow experimentation with backwards incompatible upgrades:
EVM upgrades like EVM1.5 & ewasm.
Parallelisability
Stateless clients

For stateless clients, consensus nodes would not need to hold state, only state root.
Would only need to submit merkle branches to submit state changes.
Means you don't need to store and read state from disk any more. Makes it easy to shuffle validators around as they don't need to sync down entire state, just accept merkle branches for changes.
https://github.com/ethereum/sharding