Devcon 3 report: Day 2
Other reports:
Today’s sessions I suggest you watch are: “The future of token contracts” and “Raiden network” as you can start using µRaiden now in your apps (and there is a cool demo of them using payment channels to control a robot)
Developers, Developers, Developers - Peter Szilagyi
https://ethereum.karalabe.com/talks/2017-devcon.html
Ethereum is currently a developer tool written by developers. Isn't easy to get started.
Usually developers start doing Solidity in a browser
Then migrate to using a local dev framework work VS Code + Truffle
Then deploy to a test net (but test net has a bunch of issues with stability and spam attacks)
So spin up your own network which is "difficult" (Or you could just deploy a private testnet on Azure :-P )
They have built Puppeth to help make private networks locally.
Step 1. Genesis file
Genesis file is difficult to hand code.
With puppeth you can run the CLI wizard to generate it for you. Answer 5 questions, network name, consensus algorithm (PoW/PoA), etc.
Step 2. Config Ethstats
Use puppeth to deploy your own Eth server, and have it set the config files
Step 3. Boot the network
Deploy a bootnode to a new server using puppeth.
Step 4. Add some miners
Again, just use Puppeth to add a new network component, miner.
Step 5. Block explorer
Currently no open source block explorer that supports Geth, but there is one that uses Parity.
Use Puppeth to add an explorer to a new server.
Step 6. Give someone a wallet
Deploy a new network component, wallet. Deploys MyEtherWallet to your network. Configures it to have the web UI default to your network.
Step 7. Faucet
Deploy a new network component, faucet. Deploy it again to the same web server.
Configure how much ETH it gives out, per X minutes. e.g. 1ETH every 15mins.
Step 8. Allow external people to access
Deploy a network component, dashboard.
Select everything you want on the dashboard (faucet, wallet, ethstats, etc.)
Select to make it public
Gives a page on how to connect a Geth or Parity node, android apps, etc.
Walleth deep dive - Marcus Ligi
He likes Android. There wasn't a wallet that he liked. So he decided to make is own.
Spent first 5 mins explaining why he put it on Android and not iOS. Can link a Tezor hardware wallet. You can select day/night theme.
Status: Ethereum at the edges of the Network - Jarrad Hope
Status is a hybrid mobile messenger and dapp browser.
Decentralisation matters. In Catalonia during the vote, they put the storage on IPFS, but there was a main centralised HTTP website for the average user to access, which was blocked. So people needed to go download TOR to access.
Status tries to help 1st time users with nice welcome screens and walk throughs in the app.
Try to stay out of the way, don't get users to backup their key phrase, until it actually has value in it. At which point they explain to the user what to do and why.
To help users secure it, are releasing an open source standard for a hardware wallet. Java card based. Can sign, etc.
https://github.com/status-im/hardware-wallet
Have a discover protocol, to help sort through their contacts. Uses stats like how much they have interacted or chatted with a contact or Dapp to help build up it's reputation, to protect against phishing. By building webs of trust. Users Whisper for messaging transport. An issue with whisper is that both parties need to be online. If one is offline the message just goes nowhere. Have a status message box where users can select where to cache messages.
Are releasing desktop app version on MacOS & Windows.
Their next steps are to work on optimisations, security audit, identity, etc.
https://openbounty.status.im
Evolving devp2p - Felix Lange
Devp2p provides a lightweight abstraction layer for ethereum protocols. Covers node discovery, transport, application layer.
If you have a node that wants to join the network, it connects to the DHT to do discovery. Can see other nodes that have registered on there by their enode://. Then your node tries to do a TCP connection to one of the listed nodes.
They do a protocol handshake to check shared capabilities. Then check both are using same network id & genesis block. Chatty, requires lots of round trips. Network communication upgrades are tied to hardforks.
In the new version they want to achieve 2 things
Find nodes more efficiently, know more about nodes before attempting to connect.
In the DHT replace enode:// with an Ethereum Node Record which has location and capabilities.
Once you can put capabilities into ENR, then can experiment with other transports like IPFS/libp2p.
Want to add a requirement of endpoint proofs, to reduce dead/spam nodes listed in the DHT.
EVM-C: Portable API for Ethereum Virtual Machines - Pawel Bylica
There is the EVM, but there is a EVM API over the top of that that you interact with.
ECM-C is an API written in C to interact with it.
Wrote it in C as it can be ported to many platforms.
Allow you to switch EVM implementation at run time (e.g. v1 or v1.5)
Could allow run time smarts, like having a generic EVM that does JIT for contracts that are run infrequently. And an EVM that compiles bytecode into native code for faster execution, more upfront cost, but useful for frequently used contracts.
Point is to take the API calls and implement them, to make it easy to experiment with different EVMs
The EVM: Cleaner, Meaner, and Closer to the Metal- Dr. Greg Colvin
Works on possible successors to the EVM to help with performance.
Uses some standard benchmarks to check performance, around rc5 encryption, ecmul elliptic curve multiplication, and base EVM ops like add, sub, mul, div, exp. Just to give a base level to work from for each implementation.
What is causing the interpreters from reaching the native speed of the C++ implementation?
Interpretation, 256 bit registers. Unconstrained control flow.
EVM 1.5 restricts & extends current EVM. Provides opcodes for native scalar & SIMD vector types. Restricts unconstrained jumps which are hard to predict.
EVM 2.0 provides opcodes for structured control flow. More opcodes for scalar & SIMD. Validates control flow, type safety.
EVM 1.5 & 2.0 should be compatible. Can be transpiled between the 2 of them in linear time. Transpilers could live on the blockchain.
PANEL: Evolving the EVM
Talk about 64bit, 256bit, register sizes. Do pre-compiles help.
Academic arguments, talk was disjointed.
Transpiling is good/bad. Jitting will never be useful, yes it will.
Ethereum Security - Martin Swende
Security lead for Ethereum Foundation
Were lots of DoS attacks, testnet attacks, etc.
But by analysing the attacks after the fact they can learn from it.
Have added monitoring nodes to the network which graph stats. Through that found there were some inefficiencies around TX, which they have improved by 20-30x
Have put debugging features into the EVMs, so they can dump an opcode by opcode execution from them all, to confirm they are all implemented the same. To prevent consensus issues.
Created a transaction inspector, that allows them to see the memory contents of the EVM as they are executing. Helps to repro and analyse how attacks work. Allowing them to create fixes.
Started using fuzzing to randomly generate test cases. Execute across all EVMs, confirm with the dumps that all the clients are the same.
Clients are more tested now than ever before in history. Millions of evmlab/testeth-fuzz tests, billions of libfuzzer tests
Swarm Development Update
<warning, I get ranty about Swarm, my same arguments as last year. At bottom I add links to a comparison>
Swarm is a distributed file system. Takes a file, splits into 4k chunks, distributes over the nodes.
Swap is the incentive protocol.
Have released a PoC. Shows that the basic idea works, but it is slow. Frequent issues with trying to retrieve files.
Same question I had last year. We already have IFPS which has a solid tech, lots of mindshare. Why not just use IPFS tech, get the bonus networking effects of utilising IFPS servers for more chance of a file being available. Swarm team can just focus on the SWAP incentive protocol instead.
PSS is a message passing protocol. Messages are encrypted. The recipient can decrypt.
Is very similar to Whisper. In fact it uses Whisper under the covers. I asked the teams after why the duplication of Whisper & PSS. They said Whisper is like email, PSS is like instant messaging. Different speeds and guarantees.
https://github.com/Ethersphere/go-ethereum/tree/pss
https://github.com/Nolash/go-ethereum-p2p-demo
Built a FUSE extension to sync a filesystem directory to the cloud and to another device
They built an encryption system on top, encrypts the data and the merkle tree.
Swarm network simulator, to test what happens when nodes come on/offline. Consume without giving, bad behaviour, etc.
Upcoming swarm features: new syncing protocol. Complete rewrite of network layer. Are all breaking changes so everything will be wiped. Light swarm node. Extensible incentive system (swap, swear, swindle)
<<rant incoming>>
"people are using Github which is centralised. We want a plugin for swarm so it can host a decentralised git"
IPFS did this years ago.
"sync a folder / FUSE module"
IPFS had this years ago?
Swarm team seems to want to just build/rebuild their own stuff instead of just utilising what is out there. What is the reason behind all this?
IPFS can even read Ethereum blocks with the libp2p extensions
<<Rant update>>
Later I was forwarded this Swarm/IPFS comparison writeup done by the author of Swarm https://github.com/ethersphere/go-ethereum/wiki/IPFS-&-SWARM
Was a good write up. The swarm author very was fair.
Seems there is 90% overlap. Just organisational mismatch.
I do like the proposed integration points for the future:
· Layer the swarm incentives over IPFS, or make it simpler and compatible.
· Mounting IPFS over the transport layer (RLPx) of devp2p
Having network compatibility massively increases reach :) I hope that Swarm does implement some integration.
Scalable Responsive Đapps with Swarm and ENS - Daniel Nagy
Dapps. Large parts of the business logic are done on the client side.
Web based / mobile apps / IoT, front ends. With a backend of ETH node (or light client), swarm for files, whisper for node to node communication.
Consumers spend ETH or tokens. Have a high churn rate, have limited resources.
Suppliers earn credits, low churn, high availability, more resources.
Dapps are limited by Blockchain transaction speed. Need to pay to submit state changes.
Limited to how much work an individual node can do on behalf of a Dapp. Can't have all clients talking to same node.
For storage, keep data in swarm. Put the root hash in ENS.
Transaction bottleneck could be overcome with Raiden style updates to ENS.
Broadcast bottleneck, use PSS with pub/sub
Can combine these technologies to improve the perceived responsiveness of your Dapp.
If people are in a chat room, use message broadcasting to keep them live up to date. Then use the Blockchain for the eventual consistency for people who come and load the page later.
Could use root hash of all the chats sent, which are saved on swarm. Do aggregation on the client side, rather than complicated updates.
Can roll out new versions by pushing a new version of Dapp files to Swarm/IFPS. Then update ENS with new root hash.
The Future of Token Contracts: MiniMe, Governance, LiquidPledging & ERC223 - Jordi Baylina
https://github.com/Giveth/minime
MiniMe contract. Is an ERC20 token. Has been used by distroc0x, giveth, swarm city.
It tracks the token distribution history on the Blockchain. Means that the token is forkable. Means you can create a new token whose distribution is the same as the cloned token. After the fork, each token is independent of each other.
Example use case means you could take an existing token, clone it, have the cloned tokens as burnable votes whose distribution is the same as the original token holders. They can now vote.
Instead of voting, they could be discount coupons.
Means that you could upgrade tokens by cloning with a new code base, and deprecating the last token contract.
Future of tokens: ERC20 is a little broken. Look towards ERC223. Only pending issue is backward compatibility.
EIP672 is a proposal to look up capabilities of a contract. Means if you had an ERC223 contract, it may not support some ERC20 functions, but if you look up the capabilities, you can see there is a proxy contract that can handle that functionality.
MiniMe+ERc223 = Yoga Token.
He wants it to be the new Standard Ethereum Token. As it has the new ERC features, plus the MiniMe features of cloning.
Liquid Pledging.
It is a combination of Liquid democracy and fund management. You can manage your tokens, and someone else's tokens on their behalf. To handle voting.
Designing Future-proof Smart Contract Systems - Jorge Izquierdo
Aragon is a platform for Decentralised orgs. Allows extendibility via third party on-chain modules.
How to ensure that contracts are future proof. Dumb contracts are the best. EVM is expensive, optimise for gas savings. Contracts need to be upgraded eventually.
The goal is cheap, upgradable, and very simple contracts.
Upgrades need to think about governance. Not just 1 entity is in charge, let people vote on the upgrade.
Solidity libraries are one approach, but they are linked in at compile time, can't upgrade.
Instead you can link to a proxy library that would forward onto real library. But problem was you couldn't modify ABI to add new functionality.
Delegate Proxy. EIP211.
Static forwarders are another way to deploy cheap "clone contracts".
Solidity forwarders another.
Upgradeable Proxies (from Nick Johnson's upgradeable.sol)
They are using AragonOS. Has a tiny kernel contract, with upgradeable mini business logic contracts.
Panel: USCC – The Underhanded Solidity Coding Contest
Ran a competition to write smart contracts that look innocent but were malicious. The theme was token sales.
One entry used a feature where you can send a header without triggering contract execution? Used it to exploit the token sale contract he wrote, where the token cost was based on when
2nd entry Suicide bug. Crowd sale, the issuer gets 1ETH 1st week, 2ETH the 2nd week, 4ETh the 3rd week. So that they'll get paid based on performance. But it is based off this.balance so if you figure out where a contract will be deployed. Send ETH there first and THEN deploy a contract, funky things can happen.
3rd entry Exploiting something in the ABI, could make the parameter one value type, then pass in a different type. Use that value in a loop for dynamic arrays. It isn't exploitable using normal tools, needed to generate your own ABI to pass the data in.
Tips:
If you see this.balance, it is a red flag. May not be what you expect it to be.
Random numbers are a point of failure.
External calls are another security edge.
Don't build giant inheritance models, makes it more complex to reason about.
Think about miner front running.
Maybe we need analysis tools over the bytecode
Check the Consensys best practices guide https://consensys.github.io/smart-contract-best-practices/
Hardening Smart Contracts with Hardware Security - Nicolas Bacca
Maybe an incorrect title. The session was about secure hardware devices, and the low level details of how they work on the device CPUs for trusted execution.
Secure hardware is an isolated environment for secrets and security sensitive operations. Proof of execution on a hardware and of its health.
Unfortunately current hardware microcontrollers have NDAs or binary blobs which aren't auditable. No real open hardware yet. But are getting more open.
Spent time going through many slides showing how hardware security devices work. With isolated data, and on chip app domains that can only access their own secrets. Covering how ARM does it, SGX, etc. Too technical to write here.
Raiden network
Scalability solution for Ethereum. HTTP RESTful API.
Raiden is a separate process that communicates with an Ethereum node over RPC.
Currently only supports ERC20 token transfers.
Step 1 connect to a raiden network.
Tell it how many tokens it is allowed to use. It will handle the channel management automatically. But can handle manually if you need. Can then deposit more tokens, or close the channel.
Step 2 can make transfers
Just do a POST to make a transfer. Need to include your own identifier, to help both parties know what this payment was for.
Step 3 react to events happening on Raiden network
Transfer received, transfer sent, transfer failed
µRaiden (Micro Raiden)
https://demo.micro.raiden.network
https://github.com/raiden-network/microraiden/
seems µRaiden is a simpler cut down version of Raiden which you can start using now for your own use cases.
Example of a token fuelled robot.
Set up a few channels, one for each direction the robot could move (forward, back, left right).
When the payments go through, the robot would move. Robot could consume the tokens based on distance moved.
When finished closed the channel and got the payment on the blockchain.
Video of the robot from 3:57:40 https://youtu.be/aMs0wAFIu7I?t=3h57m40s
Towards a Permanent ENS Registrar - Nick Johnson
168,500ETH deposited.
8,500ETH lost through unrevealed bids and mistakes (0.3%).
1.4% of the owners own 50% of the names
One account own 17,500 ENS domains
Broad adoption across the ecosystem. In Metamask, My Ether wallet, etc.
Suggestion that instead of using ENS directly, users could go through a proxy contract that will filter out a blacklist of known phishing accounts.
Will be using DNSSEC so that people who own domains can own those domains on ENS?