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 http://imgur.com/tWmNTpE http://imgur.com/vB4spwH http://imgur.com/U8gSgu2 http://imgur.com/b2eXPzZ
During the day, Ethereum Tshirts were made available for sale. But less than 30 minutes later most sizes were completely sold out! http://imgur.com/iJR0FHd http://imgur.com/W6mgkDb
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
Swarm high level API. URL begins with the collection root hash (like IPFS) bzz:///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
Getting started guide https://www.reddit.com/ethereum/comments/4ws9um/rethereum_rules_and_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
Truffle Development Ecosystem and Future of Ethereum Development Tools
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
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