Devcon2 — Summary of Day 2
These are my impressions and summary of Devcon2, the annual developer conference of Ethereum which was held in Shanghai 19–21st September.
What is Devcon?
Devcon is the conference for developers of the Ethereum protocol. The event took place from 19–21st September in Shanghai and was the third event of its kind. Almost all presentations where presented by the developers that work on behalf of Ethereum, directly on the protocol of the Ethereum blockchain. The content is therefore mainly about the protocol of the platform. What has been developed in the last 12 months and what is the state of the individual projects. Projects include the topics scalability, security and privacy.
Among the presenters are also companies or groups that work on issues that have to do directly with the platform but the companies are not commissioned by the Ethereum Foundation to do, such as Ethercamp (creating an environment around Smart Contracts and testing), Ethcore (an alternative client to the Ethereums own). In addition, a few applications presented as well.
Basically, every presentation was not more than 25 minutes, which made it an extraordinarily rapid change of topics and speakers. This summary does not comply with the order of the presentations, but I assigned them thematically, allowing for better readability and understanding of the topics. In addition, I had to research subjects in order to understand the content, so it takes a while to comment on all presentations that have been presented. I hope you understand that.
The second day.
The second day started with most of the participants having a slight hang-over, as the evening before had been used for networking, either in the hotel bar or in the Bar Rouge, a few meters from the Devcon2 hotel. Both locations, by the way, have a sensational view of the futuristic high-rise buildings on the opposite bank.
On the second day it was again interesting to see how many parties already work on solutions for topics such as formal verification or Dapp Development. The second day was perceived by many as more tangible, as concrete solutions were presented for different topics.
Smart Contract Security
The first lectures continued where the last day ended, discussing the issue of making Smart Contracts even more secure.
Now for the first time, the DAO was deliberately addressed (on the previous day, it was not directly mentioned even if it was subliminally present). In his speech, Joseph Chow introduced the code line, which became the disaster for the DAO. Chow has developed BTC Relay, a Smart Contract that allows to track Bitcoin transactions on the Ethereum Blockchain. He has designed a lot of Smart Contracts and presented his most important lessons in the lecture.
“Prepare for malfunctions. Be prepared to find also previously unknown attack surfaces. Integrate emergency exits, emergency switches, test a lot and produce cautiously. “
His main points are:
- Do not refer to Smart Contracts that you did not write yourself. They are not trustworthy.
- It just needs a mistake in an external contract to expose you. Either by an error, or by the external contract which in turn calls a malicious Smart Contract.
- Use send () and avoid call.value () ()
- Prefer PULL over PUSH for payments
If you are dealing with Smart Contracts, you will find a good website here, it is constantly updated.
Raine Revere presented a static method for testing a Smart Contract in one of the most comprehensible lectures of the day. Static testing in a nutshell means, the contract does not have to be executed directly in order to detect possible errors or weak points, but the code itself is analyzed. Raine explains that in the most common attacks that led to big problems (Array Griefing / Reentrancy / Underflow) they all had one one thing in common, the code “smells” always quite specifically. And if you look at this smell, you can find the errors without having to run the code. Raine has designed the Solidity Parser and the Solgraph, which together analyze the code and show a visualized result of the analysis. The result is so simple and self-explaining that you can quickly see if the code is correct or not.
At the end of the lecture, Raine used the stage for a special topic which was certainly a matter of the heart for her being transgender. She pointed out that the developer community consists of several cultures, but all of them have the same goal and therefore complement each other perfectly. This non-technological approach was an interesting and courageous change in the otherwise technically advanced presentations.
Christian Reitwiessner also gave another lecture on the formal verification of Smart Contracts. In the case of formal verification, it is important to find out whether the code contains any unforeseen behavior. It uses techniques to test a program for all possible inputs and states. E.g. Is the sum of all balances unchanged after the transfer.
Shortly after Christian Imandra presented his toolset for formal verification. Imandra has emerged to examine the complex algorithms of the financial industry. Now the Tool Set has been extended so that Solidity Smart Contracts can also be subjected to formal verification.
Another supplier who already has a solution for testing Smart Contracts is Oyente. The Oyonte system is capable of detecting all known faults (timestamp dependence, re-entrancy, mishandling exceptions and more). In a test in May 2016, they analyzed Smart Contracts and found that nearly 19% of the 19,000 Smart Contracts were marked as vulnerable. Here you get to the Github account of Oyente.
Oyente and Imandra, already have a solution for formal verification. Thus the issue of formal verification in the future should be solved in several ways.
Solidity for Dummies
After learning a lot about the auditing of Smart Contracts, Hudson Jameson and Piper Merriam took the time to elucidate about Solidity. The talk was addressing non developers which was great, even if the timing was not quite appropriate. We had already heard most of this in the lectures before, but still compressed here:
- Solidity is very similar to Java Script
- The code is compiled by the EVM
- Solidity is a simple language, but Smart Contracts are complex
- Public functions can be called by everyone
- Internal functions only from the contract itself
Standard contracts are evolving, such as the token contract with which everyone can develop their own coin on Ethereum and which can be used by many tools without further effort. As example from Etherscan, which can read transactions with the token and, of course, Mist, which can be used directly as wallet for any standard token.
In the future, Solidity will already have formal verification integrated. Swarm is also used to store authenticated sources and binary code. There will be templates and functions will be integrated as a first class object.
Why the talk about Distributed Ledgers can make sense
Henning Diedrichfrom IBM explains the difference between a Distributed Ledger and the Blockchain. For a Distributed Ledger, you do not need a Blockchain; you can make better use of other technologies for a tamper proof database. Especially if you do not use Smart Contracts or code, integrated into the chain. In the future, Diedrich sees that Smart Contracts still have a different use, not only to fulfill self-employed agreements and payments, but can also be used to parameterize complex work processes. Through parameterization, programs can be made more flexible in their application, without having to re-create the program. The values that can be set must be defined when the Smart Contract is created. Smart Contracts seem to slip into a role where they extend the possibility of digitally signed parameters to trustworthy scripts that can, for example, allow a more flexible control of the anonymous execution of analysis code against a given data stream with full transparency for the data provider and execution guarantee for the Code provider.
I must confess that I have not quite understood this speech. The text I have mostly taken from the program book (with small additions). My takeaway here is that in the future the Smart Contract will be able to create additional Smart Contracts independently, provided that the right parameters have been handed over to them. So to speak, a Blockchain form of machine learning, which would be quite close to AI (Artificial Intelligence). But I can also be wrong in my interpretation. Please discuss this in the comments.
Security in general
Now that we have learned a lot about solidity, Smart Contracts and their vulnerability, the new security lead for Ethereum Martin Holst Swende broadened the spectrum and explained how to increase the security in the general use of Ethereum. The points concern the entire ecosystem, Miners, Full Nodes, Exchange Trading, Smart Contract Developers, Dapp Users and Wallet Users. Martin looks back at how the web has developed and what we can learn from it.
Here are some tips on wallets:
- Hot Wallets (which have direct access to the Internet) can be used for daily use, but only with a small amount. Similar to handling cash.
- Cold Wallets (without constant Internet access) are better to store larger amounts and have rather a bank function.
- Definetly create a backup of the private keys and have it protected against fire, power failure, water, thieves, memory failure.
- Multi Sig Wallets (transactions must be signed by more than one owner) help reduce the probability of a security leak
Regarding the use of Smart Contracts, he also has some advice:
- Look closely at contracts. Currently, there are many gaming dapps that use a random number generator. It is worth looking into how the random generator works. Maybe this can be played out or someone has access (in time) before you have.
- Is it possible to terminate the contract unilaterally without you coming to your bets.
In the case of Dapps, these should use https and by no means Content Delivery Networks (CDN), as these can inject infected Java Script in your dapp that changes and redirects payments.
Further points in his lecture (unfortunately I do not have the slides) have already been mentioned in relation to the Smart Contracts.
External partners working on core core issues
Ethcore was founded by Gavin Wood, who is responsible for the yellow paper of the Ethereum Protocol. This time Arkadiy Paronyan was able to present Parity once again, especially the future of the client was the center of the presentation. Parity has a high transaction rate (2965 Tps), low latency and is particularly suited for use in IoT. Advanced properties are e.g. State Tree Pruning which requires less space, warp sync (faster retrieve of the Blockchain) and private chains including proof of authority.
Next, ENS (Ethereum Name System) was presented. A Blockchain alternative to the DNS (Domain Name System). The DNS is responsible to assign a name to an IP address (a number) on the Internet. The system prevents an IP from having multiple names. The decentralized ENS thus replaces the centralized DNS. Otherwise the functions are all the same. For the ENS, however, a Smart Contract replaces the new entries. Until now there are only top level domain names with the suffix .eth available.
Metamask is a browser based Ethereum Wallet with a strong focus on user friendliness. The wallet is currently running on any Chrome browser and will soon run on Firefox, Opera and Edge RPC. Metamask turns the browser into a Lightclient, which does not map the entire Blockchain and thus quicker available. Metamask currently has 12 thousand users.
After we had already presented Lightclient concept on the first day, Zsolt Felföldi told us on the second day how he envisions an entire ecosystem for the Lightclient. First, he explained once again what advantages the Lightclient has — fast synchronization (5 min for a full synchronization of the Blockchain) — low resource requirements. The Lightclient communicates with the Full Nodes via an RPC (Remote Procedure Call) interface. This communication increases the workload on the full nodes (they must now cover the requirements of the Light Clients) without being incentivized by them. Therefore, the idea for the RPC interface for Lightclients is to use a billing system. A free model that works throttled and a premium model that unlocks more full-node performance. With sharding the effort for the full nodes will increase as well.
The Geth Client is the original client already used in Ethereum prototype. Unfortunately, the client has accumulated some technical wild growth through too fast iterations, which does not offer an option to its actual function as a library. This is to change with the revised Geth 1.5, where it is to return to its origin as a library. This allows to integrate client-side account management, remote node interfaces, native integration into contracts and much more. In the process, a node could be inserted within an app so that the user of the app does not have to install an additional node before he can use the app. Furthermore, the use for mobile devices is to be expanded (Geth 1.3 already runs on Andoird and iOS).
Daniel Nagy explains in his lecture the process from Web 2.0 to Web 3.0 and how Swarm in this version will help DAPPS to be scalable and continue to function decentralized. As already shown on the first day of the Devcon2, the biggest problem with Web2.0 is that all applications are centrally controlled and a high level of user confidence is placed in the third party. With the Web 3.0 nothing changes in the front end for the user, but in the backend.
- User can customize his identity (depending on the service) and this is only stored in the browser, not in the application
- He can enter into binding legal or financial relationship
- Payments are traceable
A dapp would then work as follows:
- The root hash is stored in the Blockchain
- Dynamic and Static data are stored in Swarm
- Global status changes are stored in the Blockchain
- Local status changes are only stored locally (Backup option via Swarm or the Blockchain)
- Business logic is executed locally, but checked in the Blockchain
Very interesting are the 4 Dapp examples (photo album, distributed shared folders, social network and maps/knowledge database) which Daniel describes in the presentation, a must see for everyone.
A presentation that received the most media attention was that of Roman Mandeleil — Ether.camp — who announced his collaboration with Banco Santander. Ethercamp offers its so-called Ether Studio, an easy-to-use virtual machine that is provided on Micorsoft Azure. Ethercamp already works with many companies and helps you to develop your own applications, including Santander, who introduced their Cash Eth as part of the presentation. This makes Santander the first “big” bank to integrate a crypto currency into its products. Here is a video how CashEth works. Santander’s bank customers will be able to integrate an Ethereum account into a Santander bank account.
Furthermore, Ethercamp is very active in the developer community and started the first virtual hackathon which simultaneously also functions as an accelerator for the participants.
With Dapple, a competitor to Ethercamp was introduced, that also allows you to explore, develop, test, integrate and maintain your Dapp in a closed environment. An interesting function is the Chain Fork, which allows you to create a parallel chain to the live chain to test contracts. This can then test several versions of the Dapp simultaneously (A / B test and multivariate).
Another developer tool was introduced by Embark. Embark supports test development (TDD) using Java Script. It not only supports applications in Solidity, but also Serpent Contracts. An easy to understand user interface shows which contracts have been deployed.
Truffle says it’s the most widely used developer tool for Ethereum. Especially the 17,000 donwloads prove this. In the first version of the tool, it provides compilation, deployment, bootstrapping, abstractions, unit tests and fastest development. In version 2 management, migration, modularity and documentation. In the third version, Truffle allows instant mining, account opening, and HD Wallet support.
Like Dapple, Truffle also allows a split of the chain to have a development chain available. On the test chain you can test the Smart Contracts in a “live” environment.
In the future, Truffle will also offer Solidity 0.4 support, better network management, more integration possibilities and more tutorials.
With Remix, a NPM (Node package manager) was introduced, which can be integrated into all previously introduced developer tools (Dapple, Truffle, Ethereum Studio, Visual Studio and so on). Unfortunately, there was no presentation.
In the future, users will use the Ethereum Blockchain from different terminals using either full nodes, nodes or light clients. Infura would like to ensure that no matter which terminal is used, you always have the optimal access point, and that Swarm or IPFS and all other services can always be used. For this, they have created the Ferryman interface, which has already been integrated by many dapps, such as, for example, Metamask, uPort, Regis and Truffle.
Git is a free software for distributed version management of files and certainly well known by developers. Alex Beregszaszi , a developer of the Ethereum Foundation, wants to replace this software with a completely decentralized system. Mango. With the help of IPFS or Swarm, he creates a repository that, through the Ethereum Blockchain, transfers all its attributes for the data stored therein. An additional link via ENS also enables public access by assigning unique URLs to the files.
Ethereum consensus mechanism
A question often asked by bitcoiners is how Ethereum can make a real consensus when there are so many different clients. Dimitry Khokhlov has followed up on the question and here is his solution as an answer. He has designed a series of tests that can test the consensus. Status tests and Blockchain tests. http://ethdocs.org/en/latest/contracts-and-transactions/ethereum-tests/
CarbonVote had proposed a simple consensus mechanism, the human consensus. They advocate a community consensus that is made by people rather than computers. This is to be used for Blockchain management topics such as the DAO Hard Fork for example.
What can the Blockchain be used for?
Taylor Gerring, one of the founding members of Ethereum, showed in his non-technical lecture what must happen, in order for Blockchain to become mainstream. For that one must understand what the average consumer is actually interested in. For many, the Internet fulfills its purpose, although it is based on technologies from the 1970s. However, data leaks such as with Yahoo, Sony, and other large corporations are showing a lot of people that privacy is data security important. This is where the Blockchain can take advantage in and provide protection. However, the user is not interested in the fact that it is the Blockchain, but there must be an application that makes this privacy as easy and practical as possible.
Let us turn to a use case that might make this possible.
Based on Pokemon-Go, Sikorka App uses the natural environment to place Smart Contracts. The app has two users as a target group, on the one side the person that marks a location, and the other the player who visits the marked places.
If you want to mark a location, you deploy a predefined contract. To do this, you have to go to a location and point your camera on the spot to mark. On this location the Ethereum prism is placed virtually (probably this can be the company logo). After adding the name for the location, a question and a few functions into the Smart Contract, anyone who has the app can go to the location and answer the question. The user has to be on site. Only when the app registers, the so-called “Proof of Presence” (PoP), the Smart Contract allows interaction. Proof of Presence uses the features of the smartphone, such as geolocation data, QR codes, RFID tags or beacons. PoP even goes so far that it compares the recorded video data with the images during the interaction.
Through the Smart Contract, this can be excellently applied for loyalty programs (such as Foursquare) or for presence checks, Augmented Reality games, or promotional codes at the point of sale. The payment mechanism can be integrated as well.
This was the conclusion of the second day.
Please use the comments if you want to contribute to the topics, have questions, or just like it. As already described on the first day of the report, this is my way of processing the knowledge that was presented at Devcon. For that I have to go through each presentation again and look up many of the terms that were used, which was not possible during Devcon.
Bernd Lapp was on the Advisory Board of the Ethereum Foundation. Today he is the Business Hive Lead for Swarm City, a decentralized sharing economy platform using the Ethereum Blockchain.
Learn more about Bernd and Swarm City: https://thisis.swarm.city