Polkadot Simplified Developer Update #2
A developer update for non-developers that tried to read the developer update.
Thank you to our friends and partners at Parity Technologies for their work and for the primary implementation of this post, and a happy new year from our team to all of our community members.
As mentioned in the Simplified Developer Update #1, this series is the Web3 Foundation’s annotated take on Parity Technologies’ Developer Updates, and is aimed at providing a less-technical brief for users who are closely following the Polkadot project. In these posts, we aim to define the terms and processes referenced as the Internet of Blockchains is constructed, and to educate a broader audience along the way. An overview of the technical Polkadot development can be found in the Overview Repository.
Parachains & Bridges
The first main focus today is in regard to Bridge development, which is ongoing. As a refresher, Polkadot will support both directly connected and fully sovereign but connectable chains. Parachains, or natively supported blockchains that gain consensus using the greater network’s consensus mechanism, benefit from Polkadot’s pooled security. Pooling security allows each parachain (and the relay chain) to utilize the entire network’s set of validators to secure the overall network, meaning each parachain benefits from the network effect of the total ecosystem. If a parachain is compatible with Polkadot, it can leverage the security of Polkadot’s consensus mechanism.
For other already existing projects with their own state-histories and methods of consensus, Bridges are the connecting layer that will allow them to link to Polkadot. The bridge will connect smart contract-capable blockchains to Polkadot without any modification to their native protocol. Parity Technologies’ initial work focuses on bridges connecting two Ethereum-like chains. It can for example transfer value (balances between two chains) from an Ethereum Proof-of-Work (PoW) chain to an Ethereum Proof-of-Authority (PoA) chain and back.
Developers have been working on making the bridge more secure, having already closed attack vectors, fixed bugs, written tests to seek out potential vulnerabilities, introduced solium linting (used to check for errors in code in Ethereum’s native coding language, Solidity), improved CI (meaning continuous integration, a term for regularly synchronizing developer states to a shared mainline), done some refactoring (restructuring existing code without changing its purpose, usually for efficiency, simplicity, or orderliness) and added other documentation that can be found here: (https://github.com/paritytech/parity-bridge/issues/54#issue-279212552).
Currently developers are making the bridge work with contract-based validator sets — groups of accounts permitted to participate in consensus, and which validate transactions and blocks. This is in preparation for the upcoming Kovan upgrade, which will introduce contract-based validator sets to Kovan — allowing validation if certain requirements and conditions are met. At the moment the bridge uses a fixed authorities list (a preset list of validating authorities), but switching to contract-based and dynamic validator sets is required to work with Polkadot later.
To have a detailed look at Parity Technologies’ work on the bridge, check out the github page: paritytech/bridge where there is a link to the repo (code repository), as well as explanations on the simple bridge between the Ethereum and Kovan networks.
Consensus Algorithm
In other news, developers have been continuing to focus on the core Polkadot protocol, mainly designing a consensus algorithm and staking incentives, which in a Proof-of-Stake system are the foundational motivating factors by which token-holders are incentivized with a high interest rate to lock their token-holdings into a contract that requires them to validate transactions in exchange for block rewards or transaction fees. A large majority of circulating tokens must be staked at any time to prevent bad-actors from obtaining a large enough percentage of network control to halt or attack the chain (akin to a 51% attack in Proof-of-Work).
Parity’s team is still working on integrating networking code into the rest of the codebase, adding tests and doing a test implementation of the blockchain and state databases. https://github.com/paritytech/polkadot
Javascript implementation
Aside from the bridge and consensus algorithm development, work has begun on a Polkadot JavaScript implementation (an effort to provide a collection of tools, utilities and libraries for interacting with the Polkadot network from JavaScript). At the moment this has two main parts: the JavaScript API (a set of tools for building software that includes rules for how said software should act) & JS Client implementations (where code is run on the client machine or in-browser). JavaScript interactions are the main means of interacting with the Polkadot network, and actions on the relay-chain and the initial parachain depend on them. You can check out the full overview here: https://polkadot.js.org/.
The skeleton is in place for the API (supporting both WebSockets & HTTP) and it has been tested with the Polkadot Rust client, but since the RPC layer (or “Remote Procedure Call layer”; a client-server layer where software will be coded to run tasks on non-local machines as if they were native/local operations) for the clients is way down the priority list, it (API) does not do much yet.
The JavaScript Client is very much a work in progress and less developed than the Rust implementation. It has an operational libp2p network layer that discovers other nodes and sends status messages between clients.
For Proof of Concept 1 (POC-1) in which the Polkadot Rust client will use DevP2p, communications between the clients won’t (yet) be possible (remember to see the Simplified Developer Update #1’s glossary for a refresher on the Polkadot Proof of Concept, Devp2p vs. libp2p, Rust & wasm and more!). However, libp2p will eventually be used in the Rust version as well, and you can see the progress on this on the dedicated github page. Currently the client work here is focussed on tracking the Rust WASM runtime implementation, and expanding the JS runtime to expose all the same methods. This means that things are implemented in one API and exposed in another (JS), and the focus is to bring the JavaScript implementation up to par with the Rust work. The initial target is to have a JS node (a client that stores the entire chain and which has the ability to receive and broadcast new blocks and transactions to the network) that can validate blocks & transactions generated by the Rust client.
If you would like to follow the daily musings on the Polkadot build, please join the dedicated Riot channel we have set up, and where you can follow the technical conversation in real time: #polkadot-technical:matrix.org.
If you would like to follow the progress of Polkadot, ask further questions, or meet others in the community, join us in our Polkadot Riot channel:
https://riot.im/app/#/room/#polkadot-watercooler:matrix.org
Join the Web3 Foundation Riot channel to learn more about what the Web3 Foundation is working on beyond Polkadot, and discuss decentralization.
Glossary
API — a set of tools for building software that includes rules for how said software should act.
Bridges — a connecting layer that will enable existing blockchains with their own state-histories and methods of consensus to link with polkadot without having to be a nativeparachain.
CI — continuous integration, a term for regularly synchronizing developer states to a shared mainline.
Client Implementation — code is run on the client machine or in-browser.
Codebase — the complete source code that is used to build an application, protocol, or any particular software.
Node — a client that stores the entire blockchain and which has the ability to receive and broadcast new blocks and transactions to the network.
Parachains — Polkadot’s natively supported blockchains that gain consensus using the greater network’s consensus mechanism, and which add to and benefit from pooled security.
Polkadot JavaScript implementation — an effort to provide a collection of tools, utilities and libraries for interacting with the Polkadot network from JavaScript.
Pooled Security — a feature native to Polkadot’s architecture allowing each parachain and the relay chain to utilize the entire network’s set of validators to add additional security and strength to the overall network, and to benefit from the network effect of the total ecosystem.
Proof-of-Authority — a replacement for Proof-of-Work often used for private blockchains. It does not depend on a distributed set of users and nodes to solve arbitrarily difficult mathematical problems (how Proof-of-Work functions), but instead uses a set of “authorities” — nodes that are explicitly allowed to create new blocks and secure the blockchain.
Proof-of-Stake — a consensus mechanism wherein participants (stakers) lock token-holdings into a contract that requires them to validate transactions in exchange for block rewards or transaction fees, thereby replacing the function of miners in a Proof-of-Work system by adding distributed security through a staking incentive (interest earned).
Proof-of-Work — a decentralised consensus mechanism by which participants (miners) are paid to solve blocks and to validate transactions using computing power to solve arbitrarily difficult mathematical equations.
Refactoring — restructuring existing code without changing its purpose, usually for efficiency, simplicity, or orderliness.
Repo — short for a git code repository.
RPC layer — “Remote Procedure Call layer”; a client-server layer where software will be coded to run tasks on non-local machines as if they were native/local operations.
Solidity — Ethereum’s native coding language.
Solium Linting — used to check for errors in code in Ethereum’s native coding language.
Staking Incentives — the foundational motivating factor by which token-holders are incentivized with a high interest rate to lock their token-holdings into a contract that requires them to validate transactions in exchange for block rewards or transaction fees.
Validator Sets — groups of accounts which are allowed to participate in consensus, and which validate transactions and blocks.
