Summary

Guys from Parity Technologies accumulated a huge experience on building blockchain nodes during development of their parity-ethereum, parity-bitcoin and parity-zcash clients. Amazingly, what they do next is that they provide the Substrate framework for building custom blockchains from scratch!

To build one was a quite hard task to accomplish, as before designing your own chain's Consensus rules, you need to solve out a lot of underlying basement stuff, to number a few:

  • Networking layer, i.e. how your nodes shoud communicate
  • Database, to store synced chain data
  • Cryptographic primitives, as to implement elliptic curve used for signatures, which hash function to use, etc.
  • Addresses format
  • Randomness function

With Substrate, you have the building blocks for all these parts, presented as Modules written in Rust. So you can build your chain basics (meta-layer) much more easier and concentrate more on what matters most - your own chain Consensus and Governance rules.

April 24-25 Parity took the sub-0, the first Substrate developers conference in Berlin, which I was lucky to visit. That was a happy time among Polkadot Substrate core-developers and first community projects building on it, willingly sharing their experience. I think it would be handy if I report some pieces of here in my blog.

Substrate Architecture: Runtime & SRML

Every chain build with Substrate has a Runtime: a WebAssembly binary blob with a number of entry-points known to the node. Those entry-points are grouped into API traits. Two core entry-points are execute_block and version. They are grouped into the Core API which is required by the Substrate spec by default. Any API beyond that may be provided to add\support various functionality of the blockchain client, e.g. runtime module metadata, block authoring, the transaction queue etc.

For building your own Runtime, Substrate gives you the SRML (Substrate Runtime Module Library), i.e. a collection of components with which you can compose your brand new custom Runtime.

Gavin Wood gave us a number of insights on these runtime modules, which I'll try to echo below:

(btw, the full list of SRMs could be found here along with the documentation for each one)

If you saw any Substrate presentation before, you've probably seen this apple-like Substrate architectire diagram, as here on the Gav's slide on SRML:

SRML slide

(Sorry for the slides quality. I hope better slides and video from the conference will be available soon from Parity team. upd May 13: video finally available on Parity's youtube channel)

Indicies

Crate's Spec

Short-form account ID

Indicies slide

  • Maintains one index per active account
  • Allows for account index to be used to ID account in transactions

Contract

Crate's Spec

WebAssembly Smart Contracts

Contract slide

  • Resource tracking
  • Sandboxed execution
  • Dispatch calls in runtime
  • Call other contracts
  • Enlightened state rent
  • UA-storage

Interesting concept here is an Enlightened state rent - it assumes you don't have to send funds to the contract, while the contract can use the amount needed from your account itself.

Balances

Crate's Spec

Handles accounts and balances

  • Supports vesting
  • Existential Deposit (ED) concept: if account balance fell below the ED, Balances module reaps the account
  • NPoS = Nominated PoS consensus: pretty much like DPoS, but separates validators from stakeholders

Chain Governance

Another part of Gav's presentation was devoted to the crucial part of chain logic - Governance model. Substrate offers quite a complete toolkit of modules to implement a variety of governance schemes. All we have to do now - #BUIDL a lot of them and let the time show which model performs best through passing the natural selection (evolutionary) process among blockchains.

So Governance is

  • About changing standard or protocol
  • Rules over the system not within the system
  • Not about individual contracts but about the law
  • Autonomous governance != Coinvoting
  • Governance is to ensure valuable evolution

In few years, decentralised worldwide companies will operate with billions of dollars, just like today's corporations as Google and Apple do. But instead of a single CEO, these new economic players will rely on the proper governance model.

Decentralised crypto economic systems will become the new states in the internet world

Governance is critical for management outward relationship (between jurisdictions)

-- Gav Wood

Why we need autonomous Governance?
Governance slide

  • Same reasons we want autonoumous (smart) contracts
  • Machines are impartial, efficient, fast rule-followers. Decentralisation and crypto prevent corruption
  • We should use them. Obviously.

Interesting, that Polkadot itself hasn't selected exact Governance Model yet (hopefully they would before the Release this Autumn). Anyway, there is some vision of it presented by Gav.

Referenda: upgrading the Polkadot runtime.
Referenda slide

  • All changes to the protocol must be agreed upon by stake-weighted referenda
  • Polkadot introduces Adaptive Quorum Biasing (see explanation of it below in Democracy module)

There are three basic modules for Governance building in Substrate: Sudo, Democracy and Council. Let us have a briefly look on each of them.

Sudo

Crate's Spec

The simplest option - total authoritarianism. The only person make desisions. Only one account can be the sudo key at a time.

Democracy

Crate's Spec

Democratic system: Handles administration of general stakeholder voting.

  • LockableCurrency-based: a currency whose accounts can have liquidity restrictions.
  • has a Prioritized Queue of proposals (which are Dispatches)
  • implements Lock-voting (is not coin-voting): where not only the amount staked matters, but although the period of time it has been locked for. This approach should mitigate the voting attack risks.
  • Proxy/Delegation voting: Who is able to vote for whom
  • Delayed enactment: the decsicions taken by the referendum are being enacted with some delay, again, to mitigate attack risks
  • Adaptive Quorum Biasing (AQB) model for approvals: allows to deal with Positive (or Negative) Turnout Biases; e.g. if all 100% stakeholders voted, then it's enough just 50% votes to approve the decision; but the less turnout the more % of votes needed for approval.

Council

Crate's Spec

Alternative Governance mechanism (in addition to Democracy)

Role of the council Council Role slide

  • To propose sensible referenda
  • To cancel potentially dangerous or malicious referenda
  • To represent passive stakeholders

Abilities of the council Council Abilities slide

  • To propose referenda more quickly
  • Better and faster coordination
  • Referenda proposed by council pass with negative turnout bias
  • Ability to veto proposals once

Sample council election Sample election slide

Treasury

Crate's Spec

Useful for projects funding logic. Keeps account of the taxed cash and handles its deployment.

Why not Rough Consensus?

What is Rough consensus?

Rough consensus slide

  • Implemented in a non-algorithmic manner. It is vague, opaque and exclusive
  • Leads to slow decision making = deadlock
  • Because good change != popular change and bad change != contentious change

Metaprotocol Model

The basic rules should be the same for all chains

The Metaprotocol Model: traditional vs polkadot

Metaprotocol slide 1

Metaprotocol slide 2

Traditional (e.g. Bitcoin) Metaprotocol (e.g. Polkadot)
No requirements of formal rules Rules must be formalised
No means to guarantee process and rules are respected Processes are autonomously enforced/executed
No means to ensure accountability/transparancy Clear accountability
Leads to vague and dumb processes, personality-driven decision-making Leads to sophisticated, dymanic processes and ability to tune consensus/speed of evolution
Risk of stagnancy, fragmentation and "silent coup d'etats" Risk of volatility & collapse
Can always "fall back" onto traditional model in dire straits

Chain Ideas from Gav

Chain Ideas slide

  • Smart Contract (ala Edgeware, Ethereum)
  • Parallelised (ala Blink/Blitz)
  • ZK-Proof Currency (and ZK-Contract ZK-Polkadot)
  • Transient-chain Hub-chain (ala Plasma)
  • Oracles: both off-chain data providers and human readable formal contracts languages
  • Homogeneous multi-chain (ala Shasper)

More Features:

  • Trust Wormholes = Trustlsess cross-chain logic
  • Off-chain workers (IPFS, cloud, network, secure storage)
  • Fee abstractions - option for fee colletion logic: split, calculation on various metrics, etc
  • On-chain parallelism: to be implemented in v.2 (or even v.3) of Substrate

Excerpts from AMA with Gavin

Questions are written exactly as they were asked (they are stored in sli.do). Answers are my rough paraphrase. Hopefully, the video of the AMA session will be published soon, and we'll get the exact wordings. upd May 13: video finally available on Parity's youtube channel

Q: How do you plan your week/day? What are your productivity tips and tricks?
A: I actually don't plan, and have a meeting allergy. Meetings kill productivity

Q: What person in the space gets too little credit?
A: Aaron, he commited a lot in Ethereum early development

Q: What do you think Polkadot will look like two years from now?
A: I don't know. But it will work) and will have some economy, but specific details are yet unclear

Q: What's the biggest challenge in building Polkadot?
A: Networking. Opposite to the way we developed Ethereum (with the Yellow Paper as the exact specification), in Polka what we have is only our vision. This project is 50% research and 50% development. This is hard and takes more time.

Q: What factors do you think can lead to the failure of Polkadot, and more broadly the decentralized vision we're after?
A: It may turn out that the parachain paradigm is unviable. We don't know yet. There will be a competition of paradigms. Polkadot may fail with wrong Governance.

Q: Are there any projects related to Security Tokens developed on Substrate? Would you consider such a project valuable to Polkadot?
A: I think yeah, why not, securities on Substrate would be valuable.

Q: In the context of a multichain future, why is polkadot apparently positioning itself as a "central" relay chain?
A: I just have no idea how to implement it in other way. But I'm open to suggestions.

Q: What would you recommend for someone to do who is looking to get started building with Substrate?
A: Substrate-technical matrix room, Substrate docs and tutorials. Try new things and ask questions.

Q: ED prunes accounts with a small balance. Some accounts may have a low balance but being valuable in terms of identity. Could ED take that into account?
A: ED is for token value. System doesn't understand passports and stuff. System only understands DOT amount account has.

Q: Why Rust?
A: Rust language forces to think about stuff. It is like forcing yourself to go to the gym or set on a diet. It is painfull, but you get rewarded.

References

  1. sub-0 conference presentations (outlined by me)
  2. Substrate developers docs
  3. upd May 13: sub-0 recordings on Parity's youtube channel