evan.network @ DevCon 4 in Prague
Last week, the annual Ethereum DevCon took place at the Prague congress center. Four days full of information and recent developments about the Ethereum ecosystem. We participated at the conference for all four days and wanted to share our insights on updates and new implementations, which also impact the developments for evan.network.
ERC725/ ERC735 — Identity and Claims
Many of the sessions and workshops were about identities and claims on the Ethereum blockchain. There are two different EIPs/ ERCs from Fabian Vogelsteller about generalizing identities and claims.
The following describes standard functions for an unique identity for humans, groups, objects and machines.
This identity can hold keys to sign actions (transactions, documents, logins, access, etc), and claims, which are attested from third parties (issuers) and self attested (#ERC735), as well as a proxy function to act directly on the blockchain.
Every individual (e.g. persons, machines or organziations) manages his identity on the blockchain via a smart contract. In this identity contract, he can manage different keys and also different claims, which can be self-issued or issued by third parties for the identity.
ERC735 describes the association of different claims to an ERC725 identity. Claims can be different, like a certificate for a given purpose or a KYC of a company, issued by a notary.
The following describes standard functions for adding, removing and holding of claims. These claims can be attested from third parties (issuers) or self-attested.
This standardised claim holder interface will allow ÐApps and smart contracts to check the claims about a claim holder. Trust is here transfered to the issuers of claims.
With the combination of these two ERCs it is possible to design trustful claim services based on Ethereum-located identities. The ERCs are adapted from different big companies, who have formed an alliance for it, named ERC-725 Alliance (https://erc725alliance.org/)
We at evan.network will also integrate the claims and identities on our enterprise services, especially the Identity Claims Service in the upcoming weeks. Also in the near future, we will transfer all our profiles (which are based on a different concept) to ERC-725 identities, to maximize the compatibility to different providers, which have also integrations for ERC-725.
Scaling and Sharding via zkSNARKS and beacon chains
One big topic in the current Ethereum space is the scaling and sharding of the Ethereum blockchain. On the main chain, TPS (Transactions per second) counts are currently around 20. This is a serious bottleneck when the ÐApp adoption and user base becomes larger and the number of transactions increases rapidly. To tackle this problem, Vitalik Buterin showed the current roadmap of the “Serentiy” release (alias Ethereum 2.0) in his keynote. The switch from proof of work to proof of stake will enable faster blocktimes, and the EWASM (Ethereum flavored WebAssembly) integration into the Ethereum EVM will increase the processing times for transactions on approximately factor 1,000. The release of Serenity will take place in 2020 or 2021. In the meantime, developers can use existing techniques to increase the transactions on the network with side chains, zkSNARKS and state channels.
Side chains are easy to set up with other specifications than the main chain. You can do faster transactions on the side chain and only have to synchronize specific states from the side chain to the main chain. You also have to deploy “bridges” to be able to synchronize data between the chains. Just keep in mind that with more side chains, the management of these chains becomes larger and larger as well.
A different approach for the side chains are “state” or “payment” channels, based on Ethereum smart contracts. This is a smart contract, in which the two parties deposit a given amount of coins. Now all “payments” between the parties are managed offchain. When all payments are done, both parties submit the current values of their remaining coins to the smart contract and the smart contract pays out the values to the accounts.
There are several projects, which will implement payment or state channels as open source projects, like connext (http://connext.network), perun (https://www.perun.network) or raiden (https://raiden.network).
On evan.network, we will support and implement both of these techniques. You will be able to set up your own side chain, which is connected to evan.network. Also, we will implement a payment channel service to enable micropayments between accounts. The first step on evan.network we will take is to implement a payment channel for the storage of files on the evan.network file storage.
SWARM — a decentralized storage system
On evan.network, we are currently supporting and implementing IPFS in combination with IPFS Cluster to create a decentralized storage system. The SWARM team gave an update on their current implementations and the future roadmap for SWARM.
Swarm is a distributed storage platform and content distribution service, a native base layer service of the Ethereum web3 stack. The primary objective of Swarm is to provide a decentralized and redundant store for ÐApp code and data as well as blockchain and state data.
SWARM itself is also a distributed storage system integrated as a service in the Ethereum code. Like IPFS, SWARM can store every type of data and associates it to a given Ethereum address. The networking protocol is the same as used by Ethereum and has a payment service for storing files on SWARM.
SWARM supports out-of-the-box encryption of uploaded files with a random key, so files are not stored in clear text on the server. Also, SWARM has implemented access control for all files, which are stored on SWARM. You can protect your file with a password created by the owner of the file. This means other accounts can access your file when you have shared the password for it. They have also implemented a security system based on Elliptic Curve private keys. EC private keys are identical to those used throughout Ethereum for accessing accounts. So you can share the file to given Ethereum accounts without re-encrypting the file when you share the access to a third or fourth party. In the future, it should be possible to pay for an “insurance” of an uploaded file. This means that the account pays for the hosting and availability of the file within the network
(Swap Swear and Swindle concept) https://swarm-gateways.net/bzz:/theswarm.eth/ethersphere/orange-papers/1/sw%5E3.pdf
In 2019, evan.network will also evaluate and support SWARM uploads, to have more decentralization of the files within the network.
Web3 design principles and design systems
A general problem, which was identified by the whole ÐApp and Ethereum community is the problem to design a simple straightforward user interface and user experience for ÐApps. The current problem is that every user has to install different browser extensions like metamask or something else to generate a mnemonic or account on the network. Also, the user has then to buy some Ether from an exchange and transfer the funds to his generated account. This approach unsettles users because they must do so many steps to only buy a cryptokitty or something else.
To get rid of different UIs and UX, Consensys started a web components framework called “Rimble” to create
adaptable components and design standards for decentralized applications.
The project is in a very early stage, but received a very big applause on the session to build a way where ÐApp developers can generate a consistent UI and UX feeling in their ÐApps (https://rimble.consensys.design/)
Also, the “Web3 design principles” were presented on the session. This is a checklist for ÐApp developers how to build a successful and user-friendly ÐApp
We will also follow this projects to get best practices with ÐApps and their UI and UX feeling.
It was the first DevCon, which we attended, and it was worth to join it. So many interesting talks and impressing concepts and techniques on how to get Ethereum and the ÐApps to a wide user basis. If you have any further questions on how evan.network adapts this concepts, feel free to contact the evan.network team via gitter or via our contact form.
For more information follow us on twitter!
