Parity's sub-0 highlights
sub0 is a cool conference held by Parity Technologies.
I share highlights of the very first sub0 in this post.
Summary
Folks 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 should 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 architecture diagram, as here on the Gav’s slide on SRML:
(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
Short-form account ID
- Maintains one index per active account
- Allows for account index to be used to ID account in transactions
Contract
WebAssembly Smart Contracts
- 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
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, decentralized 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?
- Same reasons we want autonomous (smart) contracts
- Machines are impartial, efficient, fast rule-followers. Decentralization 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.
- 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
The simplest option - total authoritarianism. The only person make decisions. Only one account can be the sudo key at a time.
Democracy
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 decisions 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
Alternative Governance mechanism (in addition to Democracy)
Role of the council
- To propose sensible referenda
- To cancel potentially dangerous or malicious referenda
- To represent passive stakeholders
Abilities of the council
- 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
Treasury
Useful for projects funding logic. Keeps account of the taxed cash and handles its deployment.
Why not Rough Consensus?
- 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
| 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/transparency | Clear accountability |
| Leads to vague and dumb processes, personality-driven decision-making | Leads to sophisticated, dynamic 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
- Smart Contract (ala Edgeware, Ethereum)
- Parallelized (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 = Trustless cross-chain logic
- Off-chain workers (IPFS, cloud, network, secure storage)
- Fee abstractions - option for fee collection 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 committed 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 painful, but you get rewarded.
References
- sub-0 conference presentations (outlined by me)
- Substrate developers docs
- <upd May 13>: sub-0 recordings on Parity’s youtube channel