Devcon 3 report: Day 3 – Dapp development

Other reports:

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

Sessions you should focus on and watch:

• uPort (will help solve end user access of Dapps)
• metamascara (metamask javascript client)
• Mist browser moon project (more secure Dapp engine)
• DappHub. Check out the DSAuth contract to handle Auth in a standard way.
• Real world smart contract development lessons

There were a bunch of sessions on Oracles today. Make sure you check out Microsoft’s version of it as well 😉 “Enterprise smart contracts” https://azure.microsoft.com/en-us/blog/enterprise-smart-contracts-resolving-the-truth-for-blockchains/

Intro to Solidity (2017 edition) – Hudson Jameson
https://hudsonjameson.com/speakingengagements/ slides here.
Solidity is like Javascript. Code is compiled to the EVM (Ethereum Virtual Machine)
Once deployed to EVM is completely isolated and cannot reach outside the EVM.
Easy to write contracts, hard to make sure they are secute
ERC20 is a standard to help with contract interoperability for tokens.
There is a `payable` modifier in solidity to mark that the function can take in Ether (helps protect against accidental ETH sending)
`constant` function modifier is being replaced with `view` and `pure` to be more specific.

Metamask + remix + etherscan demo
Metamask is a plugin that acts as a bridge between browser and Ethereum network https://metamask.io/
Remix is a solidity IDE, helps with debugging and static analysis https://ethereum.github.io/browser-solidity/
Etherscan is a blockchain explorer https://etherscan.io/
In the demo he opened up Remix, pasted in a contract, clicked deploy, Metamask opened and he confirmed the transaction, contract got mined/deployed, and could see it on Ethercan.
On Etherscan can see details about the contract, if it has any ETH in it. Can submit the source code to Etherscan, for transparency purposes of verifying what a contract does.
In Remix, can use the IDE to invoke methods on the contract. In Etherscan can see the data values updated in the contract.

IDEs you can use: Remix, Visual Studio, Visual Studio Code (see my blog post on setting that up), Vim, etc. https://davidburela.wordpress.com/2016/11/18/configuring-visual-studio-code-for-ethereum-blockchain-development/
Tools: Truffle, Ethereum Package Management, solgraph,
Solgraph takes your function code and shows you a graph of all the potential function calls and the dependencies, to see where the security boundaries are.

Flexibility in Solidity – Dr. Christian Reitwiessner
https://github.com/chriseth
Language design is a game of balances. Functionality / complexity / safety.
The path for Solidity, the initial goal was to create a usable high level language as fast as possible. They succeeded… but now it is time to evolve it and make changes to help make it safer.
Structs can now be passed into Solidity functions!! (This has been a massive pain point for me! Happy to see this)
And you can return an array of structs!!

Can use require() and assert() to make your function safer.
For formal verification can use SMTLib2 / Z3. Can prove certain things about a function. Like variables will be in certain ranges, there is a divide by 0, stuck in an infinite for loop.
Can enable it in your .sol by adding `pragma experimental SMTChecker;` If an assertion fails, it will tell you why it failed with sample data.
If you have a simple function that takes in (int a, int b) and do a+b you could get an overflow. Will show you the issue at compile time. So you could put a require at the front to have an upper limit on a and b.

Asserts in your code are fine. Asserts should never be reached. If it is reachable then that is a problem. Asserts help the verifier to make sure it never happens and your function works as expected.

Mist: towards a decentralized, secure architecture – Everton Fraga, Victor Maia
Mist is there to host the Web3 project. Which is the vision of having a peer to peer decentralised internet with a Blockchain backend.
At Devcon 1 there was the first version of the Mist Wallet. Could to transfer, execute transavtions. But was waay too complicated for average user.
Devcon 2, released the Mist browser beta. Works for enthusiast user, full web power for smart contracts and Dapps. But requiring that the entire blockchain gets downloaded and synced first is a bit of a hurdle.
Ethereum wallet & mist have been downloaded 2.6 millilon times
Held a Mist summit in 2017 to talk about and decide on the future of Mist

Recently has focused on hardened security. Did an extensive audit by Cure53. They found 22 issues of varying security levels. From that they improved their test suite, and then fixed.
Have Ethereum bounty program to help encourage community to track down more.
Now has swarm integration to upload files to swarm. Bzz://aacfee00123412…
Has DNS integration so can also do bzz://my.website
Has ENS support for wallets.
To help with syncing times, supports Geth light client. (currently uses v1 light client protocol, v2 coming soon).
Built in Remix IDE. Can debug the steps that a transaction did.
Solo network, can use Geth with –dev flag to run an empty blockchain on your own node for testing.
Added a Windows installer. (Maybe I should talk with them about getting it onto the Windows Store)
Account management, standalone transaction signer. Means now you can sign locally, and then submit to Infura, or
switch between nodes.
If the accounts are managed by mist, means they now support different ethereum clients.
Did a major refactor recently, to help make it easier to add new features.
For Dapp developers, isolating local storage between networks. Different scopes to work with.
Sync jumpstart. Just get current headers, then sync the rest in the background.

Futures: better integration with remix, improve private net integration, puppeth kickstarts.
Could there be a Dapp trust level? Should dapps have access to HTTP (can be used for unencrypted tracking)?

Ethereum wallet.
Previously it was the best way to do your ethereum development (for deploying contracts), but now have Remix. So deprecating advanced features like contract creation. Creating a new Wallet.sol contract.

Q: Where is the decentralised web?
Still using centralised servers for Dapps. With centralised APIs, etc.
Mist relies on a lot of software stacks above and below it. How can you ensure that it is secure when we are dealing with keys that control real money.

Need to worry about javascript libraries you use. If you import them, they may modify the global space and add in trackers or modify web3 connection.
Web3.js has a lot of dependencies (showed a slide of the 60+ .js dependencies)
The web isn’t ready for crypto 😦
we don’t need a browser. We need a new app to access the decentralised web.

Announcing the moon project.
http://moon-browser.org

Gave a live demoFunctions are pure. UI layouts are on IPFS. Can build up a new UI by importing those different Uis and composing them. dapps are stored on IPFS for future retrival. Can take the code and create your own spinoffs. The decentralised web is mixable.

It looks promising
Video of demo at 1:13:00 https://youtu.be/k42YNyvG8CU?t=1h3m00s

Dapp Development using Remix, Mist, and Geth – Yann Levreau, Rob Stupay
https://ethereum.github.io/browser-solidity/
Remix is a solidity editor, integrated runtime environment with web3, and code analysis.
Can go to the compile tab and see compiler errors.
Can go to the run tab and execute functions on the contract
Does some static analysis. Can warn if gas requirements are too high.
Just talked about generic features of Remix.
It is colour themable..

DappHubb – Andy Milenius
https://dapp.tools
https://dapphub.com

DappHub is a self organizing network of logicians, researches, designers and developers.
Inspired by the Unix design philosophy for small reusable components. Want to make lots of free composable tools for Ethereum.
They are sick of Dapps that are using useless tokens. We want to free the Dapps of useless tokens.
People could take the Dapp, fork it, and remove the useless tokens
Created an ergonomic Ethereum toolchain.
They used it with MakerDAO
Share their tools using the Nix package manager https://nixos.org
One of the basic components is seth, which is an Ethereum swiss army knife. Make it easier to interact with blockchain instead of using web3. means you can use seth and make it composable on the command line with other tools.

Dapp tool for quick builds, powerful tests, easy deployments. Stack tracing.

Provable standard library for Dapp development.
Brings the same philosophy across to the smart contracts. Small reusable provable components.
There are 2 concepts: boxes & mixins. Can mixin Auth and Math and then use throughout the app (to bring in features).
Boxes are prebuilt components that have been put into a usable Dapp that you can just use off the shelf

DSAuth mixin, abstracts your Auth logic away from your Dapp business logic. Provides a DSAuthority property. Gives a canCall function, acts as a guard on the function, based on any arbitrary business logic, e.g. whitelist, timeboxed, role based, voter veto.

Example:
DSToken Box, is of type DSAuth.
It is a token that has 4 functions: stop, start, mint, burn.
Thinks Tokens should just be tokens. Just a DB of who owns them. Move the auth out from the business logic by using DSAuth

A traditional token is complex

An easier way is to think of them as single reusable components.

Real-World Smart Contract Development Lessons – Raine Revere
Suggestions for Dapp development.
Central logging: If you have a multi contract system, use a central logging contract to make it easier to track.

Modular libraries: Deploy code once, that other contracts can use over and over.
Think about having a data sctruct that can be reused. Then when you are calling other libraries you can just pass in the pointer to the data contract that has the struct, so it can read it easier.

Arbitration: use the blockchain as a court system / arbitrator. Assume people will act in their best interest cooperatively and the happy case most of the time off chain. Use the smart contract to execute and be the arbitrator.

User A uses the system and the counterparty does the right thing, execution is super simple.
User B uses it, has an issue. Raises a disupte, then does all the expensive logic and the bad party is punished by paying the costs.
Because the party behaving badly knows that they can be called out and will need to pay the costs, they are incentivised to just do the correct thing and everyone saves money.

Role analysis: who is interacting with the system
Buyer wants to buy, seller is putting up the assets, oracle is publishing the prices. Helps simplify code interactions

Context dependence
Send vs withdraw. Send is vulerable becaues the person you are sending it to could be doing something bad in the receiving code. But maybe you want to keep it simple. “it depends”. Think about the tradeoffs

MetaMask: Dissecting the fox – Aaron Davis, Frankie Pangilinan
~200k users
Team has grown from 4 to 10
Will support HD wallets.
Mustekala project. Ethereum on IPFS to help bridge the two

Dan came on stage dressed up as a T-Rex
V4 will have a new UI, token management and responsive layout.

Metamascara
It used to be difficult to be able to get Metamask working in your website. Was a bunch of JS to check Web3 context, etc.

Now much easier, only 4 lines (I missed taking slide photo).

But it will also allow you to not need to have the Metamask browser plugin installed. It will now do it in JS and redirect you to https://wallet.metamask.io to use your wallet.

Web3.js 1.0 – Fabian Vogelsteller
Web3.js is middleware to save you converting values and transaction calls between JS and a node. Handles ABI encoding
EVM only knows bytecode. Everything that goes into it needs to be converted.
1.0 is a serious refactor.

It now has promises.
Blockchains have a weird async operation where you need to wait until it mines and is a few confirmations deep. Can use Web3.js PromiEvent to say when to move on once you’ve received enough confirmations.
Subscriptions based on WebSocket or IPC socket, instead of polling.

Web3.eth.accounts can now create, decrypt, sign
Web3.bzz allows you to interact with swarm to download and upload.
Web3.shh communicate on whipser.
Web3.utils.soliditySha3 allows you to make sure you hash the same way solidity does (important because Ethereum uses an earlier variant of Sha3)

Missing Links in the Ethereum Stack – Jack Peterson
Is the lead developer on Augur
Wants to look at Ethereum tooling, call out what he thinks needs improving, and is offering bounties to incentivise it.
Ethereum is a young ecosystem, is missing tools you may be used to in general software engineering. It feels like it is at the old early stages of computer engineering.
Lack of incentive to build good tools. Prefer to just go do another token sale.

Wish list:
We need a better debugger. Remix is too much, it is a full IDE, awkward for large projects, doesn’t integrate with other tooling.
He wants to pull the remix debugger out to be portable (I agree, could bring it in as a VS Code extension)
Put a bounty of 2,000 REP for this https://augur.net/bounties/

Good code vs safe code. Need to think about how other safety critical software works. They do it via fewer features, less abstractions.
2nd bounty of 1,250 REP for a super simple solidity. That restricts things right down to not include inheritance, recursion, etc.
1,250 REP bounty to enable return values in transactions.

EthJS – Precision Ethereum Javascript Architecture for dApps – Nick Dodson
Ethereum in 2017 are a bunch of variants web3.js, EthereumJS, parity.js
He got frustrated with Web3.js and wrote ethJS
It follows Ethereum RPC specifications, and follows an identical provider model to web3.js
Metamask & mist are supported.
It is very similar, just with his opinionated improvements 🙂
ethjs-deploy, configurable contract deployment facility

Panel: Development Frameworks
On the panel is:
Creator of Embark
Jack Peterson, Augur
Andy, DappHub
Nick Dodson, Consensus, boardroom, Weifund, EthJS
Web3J, blk.io
Yann, Remix
Piper Merrium, python tooling ecosystem. Web3Py, populous, Ethereum Package management.

When they got started there were no tools, so they created their own tools.
DappHub: we wanted to solve problems in reusable ways
Nick Dodson: anger and confusion and questioning his own identity, spurred him on to create his own dev tools. Got frustrated with Web3 and wanted to do his own thing.
Lots of talk around how we lack a good package manager right now (EthPM later). We badly need one.
Nick: Don’t waste your time creating another bullshit token ICO that will have a 99% chance of failing. Go and help out with tooling and help the long term health of the eco system. *cheers*

Uport – Usable Key Management for Multiple Identities Across Multiple Chains
“we have built Ethereum’s user platform”
Can handle account management and login. Onboarding new users without Ether. KYC scnarios, etc

All Ethereum app accounts are in one easy place to manage.
Store credentials and badges
Create a completeuser profile store.
Mobile factor auth and signatures

Just because you lose your phone doesn’t mean you should lose access to everything.
Your identity is handled by a simple contract called a proxy.
The private keys are kept on the mobile device.
Can do things like social recovery, with other recovery mechanisms coming in future

Started off as just on a single blockchain. But realised there are many networks. So now supports multiple networks

uPort handles account management for older web 2.0 and newer web 3.0
uPort connect library that uses web3 library and sends messages to your phone to authenticate.
Identity is always handled by the end user.

Users want to use apps, not worry about networks and gas.
Guide them through account creation and joining correct network. Solving gas issue by making all transactions going through uPort contract which pays the gas on their behalf?

Developers want to issue badges and other credentials to users. Giving some form of attestation
If you achieve a certain certificate, are over 18, just personal things that you can attest. Can keep it off chain.
There are enough companies out there that are doing KYC. Integrating in KYC providers. User shares their KYC badge.
uPort credentials is generalisable as user centric data that forms the basis for reputation systems.
If using an decentralised AirBnB want to track reputation

Demo video at https://www.youtube.com/watch?v=FPHXbJPVVaA&feature=youtu.be&t=1h51m10s

Data is the Missing Link: Enterprise grade oracles
Thompson Reuteur
They knew that they could be disrupted with Blockchain. Realised they could become a trusted oracle, as people trust them currently.

Decided to focus on the high value, low volume space.
Focusing on things like share prices, FX rates.
Corda & Ethereum. Currently only on testnets. Will be free, but need to agree to T&Cs.
Show an example of using oracles to pump in prices for ERC20 tokens, and have people buy/selling
Had to architect things differently, to keep their content they license from other parties within the usage agreements.
Looking to expand data coverage. Electricity & natural gas prices requested.
Looking to expand to KYC as a service, for governance & transparency to unregulated markets. So they can help token sales for example.

Secure Decentralized Oracles: Applying Intel SGX and TownCrier to external data, payments and off-chain computation – Sergey Nazarov
Smart contracts are unable to connect with external data.
Blockchain middleware takes external data and provides them as inputs into the contract.
Want to connect smart contracts to widely accepted bank payments systems, so can pay in local currencies.
Connect smart contracts from different networks so they can interact.
Centralised oracles are a point of failure. One node as a trigger

Town crier. Is open source.
Run it as a decentralised oracle network.
Use trusted hardware (like intel SGX)

Intel SGX probably returns the execution outputs. Here the executed software is the town crier software.

Scalable Onchain Verification for Authenticated Data Feeds and Offchain Computations – Thomas Bertani

Oracilze wants to help be the general provider of data to smart contracts.
Help bring in data feeds and have multiple parties give authenticity proofs.
Is a more general Oracle offering over Town Crier which is for scoped use cases. Allows chains of trust, and bring back more than one proof of the claim.

Snopes meets Mechanical Turk on a Blockchain: Reality Keys, On-chain Truth Verification and Subjectivocracy – Edmund Edgar

https://Realitykeys.github.io/realitycheck
What is truth? It is a big issue at the moment with US politics embracing “alternative facts”.
Any paid advertise can push claims onto your screen. If you are faced with a claim, then you could spend time and effort trying to figure out the validity of a claim. But it is impossible to verify the constant barrage of bullshit so you just let it through. Get hit with enough stories again and again, start to take it as truth.

Created “reality check” Dapp. Is a mechanical turk for truth.
People who give correct answers get rewarded, incorrect get penalised. When answering you put down a deposit, returned if correct, taken if incorrect.
But what happens if someone gives incorrect biased answers, but puts down a MASSIVE deposit and makes it difficult for people to correct them. Can use an arbitrator to resolve it.

Mind the Gap: Application-driven evaluation of Smart Contract languages – Andrew Miller

Research papers. Compared the difficulty to develop apps on Bitcoin scripting vs Ethereum contracts

Devcon 3 report: Day 2

Other reports:

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

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 😛 )
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?

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

Writing Truffle tests with async/await

The documentation and sample projects with Truffle use promise chaining to write the test code.  As someone from the C# world, coming into the JS world it was getting really confusing to keep track (as well as all the variables I’d have to declare outside of the promise chain to use later).

I did a bit of research and found a way to do async/await in Truffle. I have put up a small simple repo by taking the truffle init project sample, and then doing a straight 1:1 conversion of their promise chaining tests over to the async/await format to help illustrate the difference. I really like the async/await version, as it is cleaner to read and much more compact (as you can see in the before/after screenshots below).

You can find the repo at https://github.com/DavidBurela/TruffleAsyncTests

 

before – promise chaining https://github.com/DavidBurela/TruffleAsyncTests/blob/master/test/metacoin.js

 

after – with async/await https://github.com/DavidBurela/TruffleAsyncTests/blob/master/test/asyncmetacoin.js

 

A shout out to Jim McDonald for pointing me to his GitHub repo where he had implemented async tests to get me started.

Ethereum DevOps with VSTS – easier now with new Truffle installer + npx

Last year I blogged about my first attempt to wrap a DevOps flow around Ethereum development. Since then there have been improvements in the way that Truffle is deployed with npm, the npx command that comes with npm 5.3.0 onwards, VSTS now supporting hosted Linux build agents, but also my familiarity with Linux, npm & Truffle have increased. I have spent a few weeks in my spare time trying to vastly streamline and simplify getting a basic pipeline going that provides: compilation, testing, migrating of solidity contracts using Truffle.

The steps I outline below will work on any build system, such as Jenkins or Team city that can run bash commands. But I have shown VSTS as that is what I am most familiar with.

Screenshot of the final result, with VTSTS showing Truffle test results for each build.

A video where I walk through the entire process end to end.

Example configured project

I have created a repository in GitHub where I have done the below steps. So if you want to just clone it and try it out on your own build server, that will make it easier for you

https://github.com/DavidBurela/truffledevops

1. Configure npm development packages for your Truffle project

Add Truffle, TestRPC, Mocha & Mocha JUnit plugin as DevDependencies in your packages.json. This will allow the build server to later install these packages and then execute Truffle commands.

# don't run npm init if your project already has a packages.json
npm init -y
npm install truffle mocha mocha-junit-reporter --save-dev

2. Configure truffle.js

a) remove development network. Truffle test will spin up its own temporary network if there isn’t a development network specified. Just make sure to remove the development network definition if one exists.

b) Mocha test reporter definition. We leave it as “spec” so that it will display the results in the console window while developing locally. Later on the build server we can change the reporter to JUnit, and the output file is already specified here ready for that.

module.exports = {
//...
// add a section for mocha defaults
mocha: {
reporter: "spec",
reporterOptions: {
mochaFile: 'TEST-truffle.xml'
}
}
};

 

3. Build server settings

This screenshot shows what the end result looks like. It can be summarised as: get the tests, install the npm packages, configure any environment variables, run the Truffle commands, and collect the test results.

a) Get sources

Define where your code is sitting (e.g. VSTS, Github, Bitbucket, etc.)

b) npm install

The default npm install task. Will look in packages.json and install our dev dependencies so later we can run Truffle, TestRPC, etc.

c) Shell script – environment details and config

An inline script that spits out useful environment information to help debug if things go wrong.

It also importantly replaces the line in our truffle.js to change the test reporter to the console UI, to output the results into a .xml file in JUnit format

# output version details for debugging
node -v
npm -v
npx truffle version

# string replace the mocha reporter to junit output
sed -i -e 's/reporter: "spec"/reporter: "mocha-junit-reporter"/g' truffle.js

d) Shell script – truffle commands

Inline script that executes the local version of Truffle with npx. I like have all 3 lines, so if something breaks we can see where it happened.

# check the contracts compile
npx truffle compile

# run unit tests
npx truffle test 

e) Publish test results

Default task. I have left the defaults

Report: Microsoft Australia DX hackfest (July)

An important part of being a Technical Evangelist at Microsoft is continuously upskilling and playing with different technologies. Taking 2 days out a month to sit down together and hack, gives us a chance to learn from each other. For example Simon briefly mentioned that he was playing with Xamarin Forms & Android development, but was having issues with the Intel Android emulators, so I was able to quickly show him the new Visual Studio ones that run on Hyper-V. Conversely I was having issues with NodeJS that Simon & Elaine were able to help me out with.

And of course, we took the time out for our usual #TacoTuesday 

Like our previous hacks, the Melbourne team were hosted by Frank Arrigo out at the Telstra Innovation Labs https://davidburela.wordpress.com/2017/05/25/report-microsoft-australia-dx-hackfest/. While we also had Azadeh joining in remotely from Sydney, and Hannes remotely from New Zealand. 

David (Me) – Meme classifier

I decided to make a system that could automatically classify Internet Memes. There are whole subcultures on Reddit dedicated to them, one of my favourites being https://www.reddit.com/r/AdviceAnimals/. I wanted to use the new Custom Vision service https://CustomVision.ai/ to train it on the different meme types, and be able to upload a meme and be told which category it is.

Training the custom AI was easy, I uploaded samples that I got off Reddit and clicked train. Testing it with other images correctly identifies them. Creating and training only took 10 minutes, I spent way longer browsing Reddit looking at memes ^_^;;

Next I wanted to build a chat bot and allow people to upload an image, and have the AI return back the category, and send a link to the correct page on Know Your Meme e.g. Success Kid. I decided it would be a great time to try out the Microsoft Bot Framework for NodeJS. I have used NodeJS & npm to download and use Blockchain toolchains, but never developed directly on it.
I have enough time to fully build out the chat bot, but I learned HEAPS about using VS Code and debugging NodeJS apps using VS Code. Lots of little gotchas when developing with NodeJS for the first time.

 

Azadeh (remote from Sydney)

turning on and off the light by chatting with a #bot. Magic #ifttt #webhooks #azurebot pic.twitter.com/jT0FriGUZ0

— Azadeh Khojandi (@azadehkhojandi) July 17, 2017

I wanted to solve the first world problem that most of us have! have I turned off my hair iron strengthener?
It turned out there are lots of people have the same problem, please read http://www.ismyhomesafe.ca/did-you-forget-to-turn-off-your-hair-straightener/ and https://www.honeywell.com/newsroom/news/2014/12/new-research-uncovers-fear-of-leaving-on-appliances-is-a-major-worry
to solve the problem I used wemo switch. I created two recipes/applets in ifttt for turning on and turning off the wemo switch. Basically, I got two endpoints for turning on and off the switch.
To make it more user-friendly and accessible, I used azure bot service and created a chat bot that can get commands to turn on and off the switch.
I used LUIS to understand intents and call the proper endpoint based on the command.
I hosted the source code on github and set continues integration to make sure after every push to master, the new code got deployed to azure bot service and updates the bot.
source code: https://github.com/Azadehkhojandi/WemoBot

 

Rian

I used Azure Cognitive Services Text Analytics to analyse Star Wars subtitles tracks. Topic Detection and Sentiment Analysis both seemed like good candidates.
Key Learnings:
1) Topic Detection doesn’t work well with many ‘documents’ of very small size (e.g. lines of subtitles), of as little as one word. A better approach was to approximate scenes and aggregate lines into larger documents.
2) Sentiment data is very noisy. A naive prediction is that such a sentiment analysis would track the cadence of the film. This is not at all the case, as you can see in the graph of the sentiment of the Phantom Menace.
3) Slang/ colloquialisms break topic detection, e.g. Jar Jar Binks’ lines like ‘mesa in trouble’. These should be excluded from the Topic Detection algorithm using Stop Words or Stop Phrases field in the request.

The plot below tracks sentiment across all pseudo-scenes throughout the film. You can see the data is highly variable and does not seem to follow the cadence of the film. A further research question might be to vary the size of pseudo-scenes (i.e. to aggregate lines into variable sized batches), and run sentiment analysis on all these pseudo-scenes. The result may better approximate the cadence of the film.

 

Hannes (remote from NZ)

The app is made using Unity, and the HoloToolkit.
You can see how far along progress currently is in this video.
The idea is to bounce a table tennis ball on a paddle that you drag around with your hand. It has a scoreboard that tracks your high score for the session.
When you open the game, you are presented with a paddle and a ball hanging in the air above it. To start the game, you simply tap and hold on the paddle, which starts the ball falling. Keep the paddle under the ball to make it bounce. You get a point for every time the ball bounces on the paddle. Releasing the paddle resets the position of the ball.

 

 

 

New releases of Truffle & TestRPC. Now easier to install.

I have mentioned previously that Truffle & TestRPC are my development tools of choice for Ethereum based development.

It is exciting to see that there have been new releases of both Truffle & TestRPC. I have been hanging out in the Truffle Gitter channel, and been fielding lots of questions about installation issues on Windows. As Tim has previously blogged, there have been a number of issues with installation. The installation issues were mostly due to compiling C based libraries, and requiring a number of build tools on the local machine. These issues have now been removed as Truffle & TestRPC are both now built, and then released as a completely pre-packaged release. This also means that installation times have dropped from 10 minutes, to 10 seconds! (Which means I’ll need to go back and update some of my old tutorials )

 

Truffle

Highlights: More reliable installation. Makes it easier for everyone to jump in and start playing!

https://github.com/trufflesuite/truffle/releases/tag/v3.3.0

TestRPC

Highlights: Installs quicker. Reduced memory consumption. Ability to persist the blockchain to disk, meaning you can suspend and then resume if you like  (I’ll still be using it mostly as a throw away in memory style dev environment).

https://github.com/ethereumjs/testrpc/releases/tag/v4.0.0

Whats next?

I’ve been waiting in suspense for these updated installers to drop for many months now. There have been a couple of projects on my backlog that had been blocked until this came out. A short list of what I’ll be working on in the near term are:

• Updated installation documentation (for Windows & Ubuntu) – DONE
  • https://davidburela.wordpress.com/2016/11/18/how-to-install-truffle-testrpc-on-windows-for-blockchain-development/
  • https://davidburela.wordpress.com/2017/05/12/how-to-install-truffle-testrpc-on-ubuntu-or-windows-10-with-windows-subsystem-for-linux/
• Video tutorials showing how to install and get started with Truffle & TestRPC
• New DevOps tutorials. The easier self contained install makes a couple of scenarios much easier now. – DONE  https://davidburela.wordpress.com/2017/09/06/ethereum-devops-with-vsts-easier-now-with-new-truffle-installer-npx/

Report: Microsoft Australia DX hackfest

An important part of being a Technical Evangelist at Microsoft is continuously upskilling and playing with different technologies. Each of us are usually off speaking to different customers or attending developer events, so to give us a chance to work together as a team and learn from each other we decided to set up a regular internal hackfest.

Last month we had our first, and the Melbourne team were hosted by Frank Arrigo at the Tesltra Innovation Labs. It is an awesome space, and we plan on hosting a LOT of future hackfests there. We also had our remote team mates working away and keeping in touch during the event.

Each of us hacked away on our own experiments, which gave us a chance to check out the latest toolchains and APIs. But it was great being able to just ask each other for advice.
At the end of the 2 days we all jumped onto a conference call and showed off what we were able to throw together. The valuable thing was just hearing the learnings from each person on the “gotchas” they discovered when working with the tools/tech.

Here is a little summary of what each of us worked on and learned:

David (me)

I wanted to build a little utility that utilised the Microsoft Graph https://developer.microsoft.com/en-us/graph/. The idea being that you want to compare what distribution lists you and your peers are on, as it may make suggestions on ones that you should join (like Azure insiders). I worked through the graph documentation and used the graph explorer https://developer.microsoft.com/en-us/graph/graph-explorer/ to figure out the set of queries I would need to pull out the data I needed:

https://graph.microsoft.com/v1.0/me/memberOf  – lists distribution lists that I am on
https://graph.microsoft.com/v1.0/me/manager – gets my manager
https://graph.microsoft.com/v1.0/users/<manager email from above>/directReports – returns who my peers are
https://graph.microsoft.com/v1.0/users/<peer email>/memberOf – loop through the returned list of peers, and get each of their DL subscriptions

I’d then be able to compare the DLs that I’m on, with the ones that my peers are on. And flag which ones we have in common, and which ones we don’t share as suggestions.
The next step was to build a web app to do this. I jumped onto the Microsoft Graph quickstart https://developer.microsoft.com/en-us/graph/quick-start to generate a skeleton app as my starting point. This required registering my app on https://apps.dev.microsoft.com/ which would allow my to request permissions from the user, to access the graph on their behalf.

I was able to get my application to authenticate, and query details about myself and my manager. However to retrieve what DLs other people are on requires the Directory.Read.All delegated permission, and because that can potentially leak sensitive information about your organisation, only Admins can great that permission. This meant I was stuck as I don’t think the Microsoft Admins will grant me permission for my dinky little utility to run on the corporate tenant 😉
But it was still a good exercise as I was able to see each of the pieces working, and got some basic queries working.

Azadeh

Wanted to learn more about how to use Unity (as a lot of our customers are using it now for things like Hololens). She built a 2D Tetris Game, by following the tutorial at https://noobtuts.com/unity/2d-tetris-game

Elaine

Wanted to play around with Conversations as a Platform and learn more about what is possible with bots.

On day 1 lost a fair bit of time with some visual studio 2017 issues. These seemed to be related to having a pre-release installed side by side with VS 2015 and then installing the full release version.
I intended to test more .Net core items but with the time lost I pivoted on to an area I was comfortable I could rapidly progress.

Further tested this github project which I have contributed to for generating a bot and tab for Microsoft Teams https://github.com/wictorwilen/generator-teams
I used this to generate a Tab and Bot and deploy it to one of my development O365 tenancies. 
This included hosting the Bot and Tab an Azure tenancy and deploying via a local Git repository (via this https://docs.microsoft.com/en-us/azure/app-service-web/app-service-deploy-local-git  ). This was a nice simple option that I hadn’t used before as had previously only used VSTS and full GitHub. This was exactly as easy as expected to get running so was a nice option to tick off the list.

As part of the testing of the Tab I confirmed that I could get the Tab Theme switching working (as per https://blogs.msdn.microsoft.com/richard_dizeregas_blog/2017/02/07/microsoft-teams-and-custom-tab-theme/ ).
This worked quite well although on a slow internet connection the event firing was delayed hence there would sometimes be a several seconds of the tab showing before it changed colours to match the teams client.

Also included Office UI Fabric (https://dev.office.com/fabric ) to check if that would have any issues working in a tab inside teams. I only had time to test a few elements including the spinner but these all worked well on the Tab. The main consideration is the theming may not  automatically flow through to these elements as the Teams Style sheets have very specific classes that they target hence things need to be wrapped in the elements for them to be able to change colour when needed.  This is especially important if you want your tab to work on the high contrast setting.

Finally I tried to extend the bot via  some deep linking scenarios following this https://msdn.microsoft.com/en-us/microsoft-teams/deeplinks , however was not as successful.   Asking the bot to send the url taken via manually grabbing a deep link for the tab worked well but that had a different format to the article.

Screenshots of playing with the themes

Simon

Simon being Mr. DevOps, wanted to explore combining VSTS with chat bots. Whenever a build was kicked off in VSTS, he wanted to report back if the build was successful or not, and allow users to instruct the bot to trigger Release Management to push the successful build to different environments.

He was able to get the chatbot reporting new events in a Microsoft Teams channel, and having the bot trigger certain things back on VSTS.

How to install Jekyll on Windows 10 with “Windows subsystem for Linux”

I previously wrote how to install Jekyll on Windows by installing the Windows version of Ruby and then installing the gems that way. I have found another way install Jekyll via the Ubuntu version of Ruby. This is my preferred way now, as the Linux version of these tools are updated more frequently than the Windows versions.

 

1. Install Ubuntu bash on Windows

1. Enable Windows subsystem for Linux.
   Follow this short guide on how to enable it https://msdn.microsoft.com/en-us/commandline/wsl/install_guide
   
2. After following the steps in the guide above. Simply start the Ubuntu bash shell
   

 

2. Install Ruby & Jekyll

# Get Ubuntu up to date and install Ruby
sudo apt-get update -y && sudo apt-get upgrade -y
sudo apt-get install -y build-essential ruby-full

# update ruby gems and install Jekyll
sudo gem update –system
sudo gem install jekyll bundler

Then you can do the standard ‘jekyll new foldername` and `jekyll serve` to host it.

FYI: the error message in the screenshot about Bash on windows, no longer applies. As the Windows 10 Creators Edition resolved this issue

Reghack “Down Under” event roundup

Reghack was a 3 day hackfest that ran in Melbourne, Australia https://reghack.org/

The problem statement asked:
Do you have an interest in helping solve regulatory issues in the Financial Services and the Energy Sector in Australia?
How do we use RegTech to make regulatory compliance a strategic advantage that’s a win for the regulator, market participants and the consumer?

The focus of the event was to try and invigorate local innovation in the energy & financial services sectors, by allowing people to come together and explore how Blockchain could be utilised in these areas. The event was the brainchild of Chami Akmeemana https://www.linkedin.com/in/chami1/ who is a director of ConsenSys, the largest Blockchain focused consulting company in the world. Chami came to Melbourne and asked for local community support to help him organise and run the event. I was lucky enough to be tapped by Chami and invited to assist. I helped out by providing sponsorship for the meals via Microsoft, and delivered training to help upskill the community beforehand (more about that below).

The event had around 90 participants, with many more volunteers on the day. In the end 14 teams pitched their ideas which ranged from energy trading systems, ways to authenticate documents, to ways to eliminate GST during B2B transactions.
A big thanks to Chami for organising it all, and to all the volunteers that helped make the event a resounding success.

Note: The roundup of the teams pitches are at the bottom of this post.