Day info

In the evening there was a party up on the rooftop of Bar Rouge http://www.bar-rouge-shanghai.com/

It had a beautiful view over the Shanghai bund. Many people there, but plenty of space to fit everyone. There was some lovely very striking Chinese artwork on the walls (more in the album)

During the day Ethereum Tshirts were made available for sale. But less than 30 minutes later most sizes were completely sold out!

Sessions

Lots of formal verification sessions in the morning. The afternoon was more dev tools. I was excited about Truffle

Smart contract security
Showed the 1 line mistake that caused The DAO re-entry attack.
Pro tip: tag your untrusted accounts in the contract. e.g. Name the variable something like _untrusted_account
https://github.com/Consensys/smart-contract-best-practices
https://github.com/ethereum/wiki/wiki/Safety

Prepare for failure. Be aware that unknown exploits can be found. Put in escape hatches / kill switches
Roll out carefully and test "The strongest swords are forged by continuously putting them in the fire"
External calls to other contracts: Try to avoid calling untrusted contracts (one written by someone else). It only takes 1 mistake in an external contract to expose you. Either from a bug, or from your external contract then calling another malicious contract.
Use send(), avoid call.value()()
Handle errors in raw calls. Raw calls do not propogate exceptions. e.g. if(!address.send())
An attacker could construct a call to max out the call stack, so that when your contract tries to make any calls they fail.
Favour PULL over PUSH for payments

Visualising Security
https://github.com/Raineorshine/solgraph
How can you spot smart contract vulnerabilities
Static analysis can help analyse the code without executing it (like checking for null, then using a variable anyway). Builds up an AST (Abstract Syntax Tree) which can be explored.
Created solgraph to do this
Dynamic analysis is done by running unit tests (e.g. you can use the Ruby test runner from yesterday's presentation)

Ethereum Security Overview
Can try to manage risk by reducing the likelihood or impact.
Security concerns include things like wallets, gaming the system, denial of service

End users wallets isolation: Can reduce your impact by using a hot wallet with a small amount in it. Cold wallets to hold more of it securely
There are some hardware based wallets can help secure your wallets
Then frozen wallets to keep them offline.
Ethereum valut by @Arachnid. Multi sig wallets can help reduce the likelihood

Contracts: When calling another contract, if they use randomness WHERE do they source it from? Can it be gamed? Can anyone access it before you?
Sybil attacks (attacker using multiple identities) to game against you
Can anyone rage quit and lock up the contract by not interacting with it any more

DAPPS:
Use HTTPS, BUT DO NOT USE CDNs
Someone could inject malicious JS that will modify your DAAP and redirect payments to another address.
Have an upgrade path (for both code and data).
Check invariants, use escape hatches / emergency breaks
Many potential contract vulnerabilities (see previous talks)
Favour PULL over PUSH for payments

Formal verification for Solidity
Writing code correctly is hard. It is easy to test for desired behaviour (the happy path). Hard to check absence of undesired behaviour.
Formal verification can help find undesired behaviour.
The specifications are usually compiled down to why3 or f*
Showed a Why3 GUI that shows your code and highlights lines that are not passing (e.g. because a line doesn't satisfy the conditions that it can't integer overflow.

Microsoft released a research paper allowing the conversion of Solidity & EVM code to f*.

Parity's innovations
Written in Rust (type safe. Memory safe).
Is modular, you can tweak it or use preset config files. High transaction throughput. Low latency. Low footprint (suitable for IoT devices).
Unsafe APIs are disabled be default.
Advanced eafutures like state trie pruning (redued disk space) snapshotting, warp sync, private chains including PoA

Imandra Contracts: Formal Verification for Ethereum
Completely tuned out for this. It was very much like a sales pitch, just talking itself up.

Ether.camp annual summary
Released Ethereum Studio. Is available on Azure as an easily deployable Virtual Machine https://azure.microsoft.com/en-in/documentation/templates/ethereum-studio-docker-standalone-ubuntu/
Will help you write unit tests. Spin it up, execute, tear down.
A partnership with Santander. Ethereum Cash. You can tie an Ethereum account to a bank account. More info at http://www.coindesk.com/santander-vies-become-first-bank-issue-digital-cash-blockchain/
Created a virtual accelerator hack.ether.camp

Metamask - Bridging ethereum to browsers
Ease of adoption is their core goal
User flow. You download, generate a vault (with a deterministic keyphrase).
Enter phone number, credit card details, and you can get Ether directly into your metamask account.
Done 33 releaes. 12k users.
Extension currently runs on chrome. Is ready to be pushed to opera, firefox & Edge
RPC requests to a trusted node. Intercepts the RPC calls within the DAPP to redirect to Metamask
Feature Requests: Multiple account types (e.g. uPort, remote key stores), make the browser a light client

Building the Light Client Ecosystem
Quick sync (up to 0k headers/sec) 30 secs - 5mins for a full sync (dependant on CPU)
Low resource requirements (DB <100mb, RAM < 500mb)
RPC interface compatibile with full nodes. Mist already works with it
Because light clients rely on full nodes and put higher workload on them, there are some thoughts about having a basic throttled "free" service, and a paid priority system that will give more resources.
There are difficult future concerns around scalability. In a future sharded world, may need multiple full nodes to cover all the shards.
Future work: do complex operations on server side. Define a "SuperCM" that can answer any question about the chain. Generalised off chain computing for accessing data.

Import Geth: Ethereum from Go and beyond
Geth is one of the 3 origin clients. Evolved throughout the Ethereum prototyping. Needed to include everhtying to develop on top. Followed the Geth -> Mist -> Dapps architecture.
Using Geth as a library isn't a good option at the moment. has started to collect technical debt, from prototypes being rapidly iterated on.
Geth 1.5 is a concentrated effort to make Geth a library. Client side account management, Remote node APIs, native bindings to contracts, in-process ethereum client
Chain exploration, state querying and event subscription over IPC, HTTP or WebSocket.
Native contracts. Can generate a Ethereum ABI GO binding that GO code can use? Can create a solidity wrapper for go?
In process nodes lets you hose a node within your app. Saves you telling someone to "please go and install an ethereum node".
What about supporting this on iOS & Android? Geth 1.3 already ran on mobile platforms. Released an embeddable library in Dec 2015, but is really a proof of concept. Mobile in-process nodes. Easier to call API locally now.

Developing Scalable Decentralized Applications for Swarm & Ethereum
Web 2.0 has issues around scaling & centralised control.
When moving to Web 3.0 we need a general purpose distributed backend (swarm/bzz). Said there MAY be interoperability with IPFS. They hope that it will share a lot of the underlying principals with IPFS. I HOPE this happens! Well leverage network effects from IPFS.
Logic being pushed to clients (logic in JS in browser, in native mobile apps)

Swarm high level API.
URL begins with the collection root hash (like IPFS) bzz://<crypto hash>/imgs/example.jpg
Can do root hash registration to a friendly name (like IPFS's IPNS) bzz://some.friendly.name/imgs/example.jpg
Put static and dynamic data within swarm. Put global state changes onto the blockchain. Local client side only state changes can be stored locally (and optionally backed up to blockchain/swarm)
Execute logic locally, but verify it on chain.

Example Dapp Distributed photo album. Webapp resources & data hosted in swarm. Current root hash of collections published to blockchain.
Optimised image, thumbnails, etc. are generated client side before uploading (just like facebook, etc. do)
Possibility to instead do delegated computation, put the files in swarm, get someone else to process it.

Dapple Dev Workflow
https://github.com/nexusdev/dapple
https://github.com/nexusdev/dappsys
Dapple looks like a critical thing to integrate into your development suite! If you are into devops, I definitely recommend watching this vid later to see how you could integrate testing flows.
http://Dapphub.io
EVM Dev Multitool for helping with Dapp developments. Has EVM extensions
Has a shared data model "Dappfile". Is a package/dapp descriptor format.
Shared global runtime environment blurs line between code packages & deployed code objects.
Can chain fork, to help you when testing contracts.
Can find dependencies. Custom linker
Test harness to use a contract to test other contracts
Use the chain forking in your tests. Take live chain, fork, insert your test contract, fork before you call each test method.
Deploy: Wallet side scripting. Hijacks call and create, and redirects to side chains. So you can do some dry runs.

Solidity for Dummies
Solidity is a higher level language. Looks like Javascript, but with types. Shame they didn't just use TypeScript ;-) Maybe Solidity 2.0 can migrate to using TypeScript.
Solidity is compiled to EVM. Once it is in the EVM it is isloated.
Public functions are callable by anybody. That is your contract public surface area / exposed APIs.
Contract standards are beginning to emerge e.g. ERC20 interface for tokens. Having a standard for token meant that the community can do cool things, like etherscan.io that lets you look up tokens in the block chain, or EtherEx that is a decentralised token exchange.
Lots of IDEs & tools you can use with solidity. Ethereum Studio, Visual Studio, Vim. Solgraph, truffle, dapple, embark.

Getting started guide

New and future features of Solidity
Initial goals of solidity: statically typed. Easily readable. High level. Uses little gas.
What has happened in the last year? Build custom types. Internal library functions. Source mapping via AST, for solidity code to EVM, assists with debugging.
Future: Formal verification. Authenticated sources & binaries via swarm. Templates. Functions as 1st class citizen. New notation for parallel / async programs

How to create advanced Dapps using embark
Compatible with any build pipeline
Supports contracts TDD using JavaScript
Manages deployed contracts, deploys only when needed (and dependent contracts)
Manages different chanes (e.g. testnet, pribate net, livenet)
Support for both Solidity and Serpent
Contract instances, like inheritance.
Embark 2 goals. Facilitate communication between contracts. A cool dashboard, shows which contracts have been deployed, available services (geth whisper, IPFS)
EmbarkJS futures: promises and named parameters. Automatic type conversion. Communication abstraction, allows you to plug in supported providers like whisper, etc. Storage abstraction provider (swarm, etc.)

Truffle Development Ecosystem and Future of Ethereum Development Tools
http://truffleframework.com/
https://github.com/ConsenSys/truffle
Truffle is the most widely used Ethereum development framework. 17k+ downloads
In v1 Compiliation, deployment, bootstrapping, abstractions, unit testing, quick development. In v2 Network management, Migrations, Modularity, Documentation.

Going towards Truffle v3
Ethereumjs-testrpc allows instant mining, account creation, HD wallet support, deterministic. Allows you to fork from any available chain, for a new development chain (sounds like chain forking in Dapple). Take the live chain, fork it, then try developing against contracts in the live net on your dev fork.
Solidity unit testing
Npm integratoin "npm install my-package". Import sol contracts.
Webpack integration.
Ether-pudding allows you wo watch for events.

Futures: Solidity 0.4 support, better network management, more integrations, more boilerplate, more tutorials.

ENS: Ethereum (Domain) Name System
Why do we need "yet another name service". To allow you to name wallets, files, etc on top of Swarm & IPFS.
Existing name servies are ironically centralised within a single place or contract.

What makes a good name service? Separation of concerns, distributed authority, forward compatibility, efficient on-chain resolution.
Components: Registrars, ENS Registry, Resolvers.
ENS Registry maps the name (hack.eth, nick.hack.eth) to the resolver
Resolver is a simple contract that lets you set the address for a name, look up names, etc.
Registrars, let people be in charge of a TLD (.eth) and then allow people to register under them (automatically through a smart contract).
Initially an auction based registration. Only names under .eth are available.

Making Smart Contracts Smarter: Oyente
https://github.com/ethereum/oyente
Smart contracts == one-shot programs. Self executed, cannot patch. Solidity is similar but not the same as Javascript.
Original contract code is not always available (but the new solidity feature of putting onto swarm may fix this).
Too many smart contracts to manually decompile EVM and check them all.
Oyente is a new analyzer for smart contracts. Use cymbolic executions. Detects all popular bugs TOD (transaction ordering dependence), Timestamp dependence, re-entrancy, mishandling exceptions.
TOD: Observed state != execution state. The state may change between when you submit a transaction and it is executed. Someone can watch transactions being submitted looking for a critical execution, could quickly snipe and enter your own transaction into the transaction pool as well with a higher fee to try and get yours executed before the other person.
Timestamps: Can be manipulated by miners.
Oyente Symbolic execution. Can build a tree of every branch and possible execution and run over it.
Can detect bugs, test generation, and go over all possible paths.

Beyond the Bubble
Overcoming education and adoption challenges for the Blockchain industry.
He is a technical evangelist for blockchain. Last month went and spoke to US gov to advise FBI, CIA, etc.
Wants to help grow the blockchain beyond just us very early adopters.
Fintech is rapidly developing blockchain solutions.
IoT, energy & medical are looking towards adoption.
Longer term, governments & non profits.

Why do normal people care?
Internet still functions off 1970s tech: Our data is sent in plaintext, leaked by companies, our identities are stolen by hackers, our behaviour is mined and monetized by advertisers.
People are beginning to understand the need to have same privacy and security guarantees online as they do offline.
Things should be encrypted by default. "Own your own data"

Infura. Ethereum & IPFS infrastructure
https://infura.io/
How do devs ensure that users have access to Ethereum & IPFS. How to make it easier for users to jump in.
Didn't show anything. Just talked (only had 10 mins). There was a services called Ferryman that can talk to the IPFS/Ethereum network.
Apparently being used by Metamask, uport, regis, truffle.

Testing Ethereum Consensus
There are HEAPS of ethereum clients (Geth, Parity, etc). How can we ensure that they all come to the same consensus?
By using a suite of tests. State tests, Blockchain tests,
http://ethdocs.org/en/latest/contracts-and-transactions/ethereum-tests/

CarbonVote: A Gauge for Human Consensus
http://Carbonvote.com
"Machines serves human. Carbon over silicion. Consensus from community". (use people to make a decision, not computers). Machine consensus is just a tool for human consensus.

Sikorka – Ethereum meets the Outdoors
A system that facilities deploying smart contracts in real world locations.
Enables smart contracts to interface with environment.
Provide "proof of presence" that a user is indeed in correct location.
Potential uses: loyalty programs offering discounts to people visiting specific locations.
Proving attendance in a location for official purposes e.g. administrative, corporate, AR games.
Proof or Presence: using mobile phones and software - geolocation data (can be spoofed) use a challenge question (e.g. what is the last word on a monument's plaque). Scannable QR codes, RFID tags, beacons.
Sikorka works by deploying contracts that follow a specific interface. Interaction with contract only happens after PoP.

Remix and Other Ethereum Development Tools
https://github.com/ethereum/remix
smart contract debugging
Is a NPM module. Looks very early stage. Says it can be integrated into other tools like Dapple, truffle, ethereum studio, Visual Studio, etc.).

Mango: Git Completely Decentralized
https://Github.com/axic/mango
Git on Ethereum, IPFS & Swarm
Harder to take down a central repo (e.g. Github)
Proof of existence for source coode. Ethereum is a decentralised system. Its source code should be available in a decentralised manner.
Using IPFS or Swarm, the files are chunked up and stored. So if you have a large file that only changes a few bytes, it can de-dupe and only store the chunks with differences.
Git is a merkle tree. IPFS/Swarm directly store as a merkle tree/dag
(There are some good talks by Juan Bennet from IPFS talking about how you can do this)

Naïve implementation, store everything in a contract on a blockchain, would cost 50M ether
Useful implementation, store objects in IPFS or Swarm to store the data off chain. Then map the IPFS identifies to git identifiers. Save those identifiers on the blockchain so you know what to look up.

Hook it up so that a git push updates the commit hash to contract, then pushes to IPFS. Reduces gas cost to 140,000 down from 5m
Every git repo has its own contract.
Future work could let you expose your git repo via ENS (Ethereum Name Service) e.g. solidity.ethereum.mango.eth
Future of Mango: store release notes within git. Store issues within git. Store pull requests. Create user friendly web frontends