EDCON2019

EDCON 2019 kicked off, in Sydney Australia, with a pleasantly surprising ice breaker. Vitalik Buterin, Karl Floersch and Co. captured the audience with a live on-stage hip-hop performance; waxing lyrical about eth2.0, merkle proofs, plasma chains, zkSNARKs, eWASM and account abstraction.

The upbeat and playful community atmosphere continued throughout the entire conference. The days were not only filled with conference presentations. They were filled with lively community interactions, the sharing of ideas, collaborative coding opportunities and even physical puzzle challenges. There was a constant buzz, and the Ethereum researchers and contributors walked the floor during the breaks; sharing conversations and enjoying the amazing conference catering.

Casper CBC

After the initial opening performance Vitalik Buterin, who by now needed no further introduction, took to the stage with his contemplative presentation about correct-by-construction (Casper CBC). More specifically, how the Casper CBC family of consensus protocols would work in Ethereum 2.0.

One of the most interesting facts I discovered, during his talk, was that Casper CBC actually has no “in-protocol” fault tolerance threshold. Instead, safety is chosen on the client side. Essentially each Ethereum 2.0 client can nominate how they interact with the protocol by choosing their own time vs certainty requirements.

In point form:

  • Finality is client-side
  • There is no finality thresholds in the Ethereum 2.0 protocol

Here are a few more points which I also found very interesting:

  • Validators choose which chain is “canonical” based on a fork choice rule
  • Validators build blocks (on a particular chain) which reinforces that chain's dominance
  • Validators can not maliciously switch to another chain because this would produce a provable violation

These points are all part of a new school of safe-under-asynchrony BFT consensus which was originally invented by Vlad Zamfir.

Ethereum 2.0 validators

The roles and responsibilities of an Ethereum 2.0 validator became more and more apparent as the presentations went on. For example, becoming a validator requires a deposit of 32ETH (deposited to the appropriate contract on the main Ethereum 1.0 chain). Once the 32 ETH has been confirmed, the validator begins their life on the beacon chain. The beacon chain, which is the system chain for Ethereum 2.0, is where validators live, where random numbers are generated, where deposits are held and where slashing occurs.

Once a validator is chosen (using pseudo random sampling) they serve on the beacon chain for approximately 2 weeks. These validators take on responsibilities to, amongst other things, propose valid Ethereum 2.0 blocks, create crosslinks (communications between sharded chains) and vote on correct cross shard links.

Ethereum 2.0 validator rewards and penalties

Of course no staking system would be complete without penalties. Validator penalties include, but are not limited to, general inactivity, attesting to incorrect data and/or falsely attesting to data which is not actually available. All of the presentations, at this conference, were more about the overarching technical architecture and as such, did not go into actual details about the profitability of being a validator. If you are interested in more of these details, the penalty and reward quotients section of the official Ethereum 2.0 specification provides concrete values as well as an annual reward percentage, based on a particular assumption.

Ethereum Core Researcher Hsiao-Wei Wang, gave an excellent presentation which essentially outlined “a day in the life of an Ethereum Beacon Chain Validator”. Danny Ryan provided a great explanation of how sharding and proof of stake come together into a single design to create Ethereum 2.0. Danny also provided a simple overview diagram which I have included below.

Ethereum 2.0 roadmap (Phase 0)

Most of the presentations also referenced the Ethereum 2.0 roadmap. Specifically, the talks referenced the first phase of Ethereum 2.0 (commonly known as Phase 0). At this stage the specifications of Ethereum 2.0 are concrete. The path forward is now focused primarily on engineering and development. Sights are set on releasing the core system level proof of stake chain (beacon chain pictured above) by the end of this year.

The Phase 0 implementation is scheduled for Q4 of 2019.

The reason for the phased implementation of Ethereum 2.0 is to allow developers, testers and the community to take a more conservative approach. For example Phase 0 implements the beacon chain but does not facilitate externally owned user accounts or any user activity whatsoever.

Similarly, Phase 1 (which will of course come after Phase 0) will introduce sharded chains, but with test data only. Again, no user accounts or user activity. It is expected that the Phase 2 implementation of Ethereum 2.0 will eventually add accounts, smart contracts and so forth.

Ethereum 2.0 clients

Preston Van Loon, Co-founder & Tech lead at Prysmatic Labs, gave an excellent presentation entitled “How to Build a Production-ready Ethereum 2.0 Client”. Whilst it was originally thought that the existing Ethereum 1.0 clients could be updated/upgraded, developers have since learned that the Ethereum 2.0 clients have to be written from the ground up.

One of the upsides of this fresh approach, is that developers can now entertain completely new ideas without worrying about how they would have to integrate with existing Ethereum 1.0 clients.

One of the challenges which this brings however, is that eventually all of these different new clients will need to align from an interoperability standpoint.

Over 100 people, from all over the world, are currently contributing to the development of almost a dozen different Ethereum 2.0 clients

It was really great to see so many different projects presenting so many different ideas. The community engagement and collaboration was a good fit for Second State. There was an overriding focus on providing innovative blockchain solutions. Dr Yuan demonstrated how SecondState can achieve new heights, providing solutions which are performant, yet still safe and user friendly.

How about Ethereum 1.x?

It is clear that Ethereum 2.0 is still months (or maybe even years) away from being useful. However, that does not mean current Ethereum users and developers are stuck with outdated and slow technology for a long period of time. Many innovations for Ethereum 2.0 are coming to fruition in today's Ethereum blockchain. For example,

  • One of the most common discussion topics throughout the conference is layer 2 networks. Layer 2 networks could scale the current Ethereum blockchain to tens of thousands of transactions per second (TPS). While various implementation efforts of Plasma clearly have the most mindshare, other solutions ranging from Liquidity Network to Celer Networks are debated and discussed in depth in the conference halls.

  • New developer tools are being created to improve Ethereum user and developer experience. Examples I found particularly interesting include the Embark Framework for integrated DApp development and deployment (see below), Amberdata for blockchain data visualization and query services, and Tokenscript for automated token related operations in wallet applications. Developer tools is also a focus of innovation for the Second State and Lity project. Stay tuned.

  • On-chain applications that store the entire application data on the blockchain are becoming part of the standard Ethereum infrastructure (see our previous article on this topic). That is especially true for Defi (Decentralized Finance) applications such as Uniswap, Kyber Network, and MakerDAO. For instance, since its launch 6 months ago, Uniswap now has $10M worth of ETH locked in liquidity pools, and reaches $2M in daily transactions. MakerDAO, on the other hand, has locked over $300M worth of ETHs in its deposit pools. Defi, including ERC220 token contracts, could well be the standard infrastructure of Ethereum.

  • Ethereum core developer Lane Rettig gave a talk on Ethereum 1.x roadmap. He discussed many interesting improvements that will happen on the current PoW Ethereum blockchain, including language improvements to Solidity and Vyper, as well as the new intermediate language between Solidity and the bytecode in preparation for Ethereum 2.0's new eWASM (Ethereum flavored WebAssembly) Virtual Machine. Those improvements will make the Ethereum platform more useable and performant in the virtual machine layer. Again, this is area where Second State is looking to make active contributions to the community (see below).

Lity and Second State

Our very own Dr. Yuan gave an engaging presentation which explained how Lity (an extension of Solidity) provides unprecedented features to blockchain programming.

For example:

  • compiler and runtime support
  • built-in functions such as safe random numbers
  • pure functions such as a JSON library
  • new data types such as safe integer (safeuint)
  • new constructs such as the blockchain rules engine

Blockchain Rules Engine - a declarative language for non-programmers

Smart contract code is rigid; once deployed the smart contract's logic is set in stone. Naturally, at the time of deployment only a finite set of possible conditions and logical outcomes are shipped. Many real world applications challenge this rigidity. Complex interactions require a more dynamic solution and this is where rules engines comes to the rescue.

Rules engines are already available in many “non-blockchain” enterprise programming languages and frameworks. For example the Drools, Jess and the Pega business rules platforms, to name a few. Rules engines already provide value to many industries including finance, commerce, travel and government. Dr Yuan cleverly introduced and then demonstrated with code, how rules engines can be used in the future of blockchain programming.

The rules engine provides modularity. This is an important feature because a large portion of business analysts who create the business logic, are not smart contract programmers. Modularity also allows for code re-usability as well as parallel development. The blockchain rules engine which Dr Yuan demonstrated, introduces a mechanism for business analysts to design and create rules without needing to write smart contract code. Dr Yuan walked the audience through a few real-world applications which helped explained the necessity for the rules engine to be a declarative language for non-programmers.

Dr Yuan gave many examples of the usefulness of rules engines. Perhaps the simplest to articulate, in this article, was the semi-complex fast food order in which, after some time, individual items on the menu begin to qualify as becoming part of a “combo”. Naturally, without the Rules Engine, the traditional smart contract code would be lengthy; difficult to write and comprehend. As you can see from the image below, the rules syntax is quite simple.

The rules engine provides a succinct solution (for non-programmers) which is easy to write, comprehend and maintain. The rules engine is robust. Once deployed, the rules engine employs the Rete algorithm; a pattern matching algorithm which is used to determine the correct order of rule execution.

Ethereum community collaboration

I was fortunate enough to sit with Hayden Adams (the creator of Uniswap) and discuss one of my recent ideas. The idea is to store multiple values inside a single uint256 integer.

The logic behind this idea is as follows. A single uint256 data slot can store any value between 0 and 115792089237316195423570985008687907853269984665640564039457584007913129639935 and as such it may be feasible to create a pattern which obeys a certain convention which ultimately allows many application variables to be stored in one single slot. The pseudo code (design pattern) for the idea, which I have dubbed micro-slots is shown below.

1

((_value % (10 ** _position)) - (_value % (10 ** (_position - _size)))) / (10 ** (_position - _size));

I also very briefly ran this idea past Vitalik, showing him my pseudo code during one of the breaks, and was pleased to hear that this pattern could be implemented in not just Solidity but also in Ethereum's Vyper programming language.

There was more than enough room at EDCON2019 for developers to sit down and code so I took a small window of opportunity to write and test the design in both Solidity and Vyper.

Solidity

1
2
3
4
5
6

contract uintTool {
    function getInt(uint256 _value, uint256 _position, uint256 _size) public pure returns(uint256){
        uint256 a = ((_value % (10 ** _position)) - (_value % (10 ** (_position - _size)))) / (10 ** (_position - _size));
        return a;
    }
}

Vyper

1
2
3
4
5

@public
@constant
def getInt(_value: uint256, _position: uint256, _size: uint256) -> uint256:
    a: uint256 = ((_value % (10 ** _position)) - (_value % (10 ** (_position - _size)))) / (10 ** (_position - _size))
    return a

I am hopeful that this design may be useful for Uniswap version 2.0 and as such I will continue to research and develop the idea and its implementation in the very near future. The next step (as per Hayden's advice) is to research the gas efficiencies of this design.

Conclusion

There were so many amazing presenters, teams and projects at this conference. Just before we conclude, I would like to quickly mention a couple of projects as well as an idea; all of which I found inspirational and interesting.

Embark

Originally released in 2015, Embark is an Ethereum development framework which provides developers with the ability to create private blockchains, debug smart contracts and much more. From my understanding “Embark saves time”. Embark has a powerful CLI, a web UI dashboard, an explorer, its own code editor, and also integrates with decentralized services such as IPFS. Embark is a fully open source effort, created for developers, by developers.

Ethereum Classic Labs

Ethereum Classic Labs gave a great presentation which introduced me to a clever project called Open RPC. In my view, this project will help to provide a ubiquitous communication protocol which will greatly improve the Ethereum DApp development environment. Ethereum Classic Labs also offer incubator programs to provide startups with funding. There seemed to be an overriding message that whilst most development is created by the Ethereum Classic Labs (ETC), it is intended to be used by the wider Ethereum (ETH) community.

Ethereum Cat Herder

The Ethereum Cat Herder project is an effort to provide decentralized project management support for a large collaboration like Ethereum. The speaker recalled early days of Ethereum when decisions are centralized and funds were spent carelessly, much like many crypto projects today. The evolution of Ethereum into a highly organized project with many conflicting stakeholders is testmony to the power of the community, and serves as a good example for other projects that follow it.

Virgil Griffith - Parametric insurance (insurance based on a measurable condition)

The Special Projects Lead at the Ethereum Foundation, Virgil Griffith, gave a great talk about decentralized insurance protocols and products. Virgil gave examples of how real-world outcomes could automatically invoke payment. One example was weather insurance whereby the purchaser of the insurance policy would automatically receive an insurance payout based on a simple metric such as wind speed. For example instant payouts are triggered when the wind speed registered by weather stations (in proximity to the insured property) exceed a threshold.

No insurance assessors and no delays.

Another example was that of flight delay insurance whereby a payout is issued based on how long the flight is delayed.

No paperwork, no waiting.

This particular talk made me revisit Dr Yuan's presentation about the blockchain Rules Engine. In his talk Dr Yuan gave the example of how the Rules Engine could resolve complex issues such as accounting for rewards in complex situations. For example a passenger achieving Gold frequent-flyer status shortly after take-off, but not soon enough to have redeemed the rewards for that particular flight.

I am imagining scores of real-world scenarios in the field of parametric (parameter based) insurance (and other parametric services); partly harvested crops, health insurance and much more. In my mind it boils down to the fact that Business analysts (and other professionals who create policies, models and contracts) work at a very high level of abstraction. On the other hand, blockchain developers and engineers work at an extremely niche level; writing and building decentralized infrastructure. The Rules Engine approach allows the high level business logic to seamlessly make its way into the decentralized application (DApp) layer.

All in all, EDCON2019 was a highly productive, yet friendly and relaxed community event.