Polkadot Simplified Developer Update #1

TL;DR: TFW you really want to read developer updates but you can’t finish a sentence without googling half of it, AKA Dev Update for Non-Devs, etc.

The Web3 Foundation has crafted the piece below as an alternate version of the first Polkadot Developer Update from our friends at Parity Technologies. Much of this content is our annotated take on their publication with a less-technical perspective for users who are closely following the Polkadot project, but with room to learn along the way. In this and future less-technical Simplified Developer Updates, we’ll focus on breaking down the terms and processes being referenced as the Internet of Blockchains is constructed. With this perspective, we aim to welcome and to educate a broader audience along the way.

The initial version of the Polkadot specification (glossary), is available here: here: https://github.com/w3f/polkadot-spec/blob/master/spec.md. Further, a list of terms covered in each Simplified Developer Update will be available at the end of each post.


In the weeks since the Polkadot Fundraiser, the team has started to tackle some major initial building blocks, such as block headers and transaction format. For reference, block headers are the method by which distributed ledgers (blockchains) identify block position, number, or height, and notate where in the chain a block belongs. Block headers reference older blocks in their code which help to track the root from which each block was created. This root is identifiable and has a traceable history through a Merkle Tree, which is explained here.

The Parity team will speak to transaction format once further details are settled upon, but initial implementations are now being written in code. The first Proof of Concept, or PoC-1 (an early experimental version of our application that demonstrates feasibility and early functionality), will have all of the relay chain contracts (One of the contracts deployed on the Relay Chain that govern the behaviour of Polkadot) implemented in an open source programming language called Rust. In the following release, the aim is to allow the contracts to be compiled together with the rest of the codebase into native code. Later, contracts will be compiled to WebAssembly, a quick web-centric format that grew from javascript, and ran using Polkadot’s interpreter (a program that directly executes code without precompiling into another application).

Initial work has also begun on the Polkadot networking protocol, a protocol for exchanging blocks, transactions, block candidates, consensus messages, and more over the network. The first version is based on devp2p, but is designed to be based on libp2p in the future.

For some background, devp2p is the backbone of Ethereum, working as a secure networking system or communication layer that allows for peer-to-peer connection and more while remaining simple in nature. Libp2p is more feature rich than devp2p and backs a technology called IPFS (InterPlanetary File System; a distributed file system aimed at world-wide connection for use as a database or subsystem like HTTP with the potential to realize a serverless internet). This more advanced system seeks to power a distributed web that treats web data a bit like bittorrent handles files, allowing for separation and decentralization from our current server filled data centers.

PoC-1 will support syncing the relay chain in full mode (a complete validation state, akin to a full node on another chain) backed by devp2p and connectivity management (managing network connections to connect only to relevant parties: e.g. collators or validators) to be added later via libp2p.

Parity has also maintained the contracts repo, an open-source code repository, located on github, adding administration features to Proof of Authority (PoA). As explained on Parity’s github, Proof-of-Authority is a replacement for Proof-of-Work often used for private chain setups. 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. This is less secure from a standpoint of decentralization, but simplifies testing and improves speed in a non-distributed setting. These updates allow a specific contract to make non-standard state transitions or changes through log events. Additionally, developers are creating a contract that issues those log events upon the approval of the current set of authorities.

In other news, during an optimization sprint the team managed to reduce webassembly binaries by about 80%. This is significant as by reducing size, the size of the database and amount of network traffic is reduced. Additionally, binaries were made suitable for public networks with standard settings (for example, Kovan, Parity Technologies’ Ethereum test network). Changes were also made to improve ergonomics, stability, and documentation of the pwasm (parity WebAssembly) support libraries (-abi, -std, -test). Finally, their team has opened a public channel for parity wasm-related work, everybody from the field is welcome to join https://riot.im/app/#/room/#parity-wasm-public:matrix.org

Other pieces that Parity devs have been working on include the Rust port of libp2p. The initial architecture, a mechanism to subdivide a connection into multiple streams that will be used to connect devp2p to libp2p, and encrypted communication channels are already in place. Additionally the code can successfully interoperate with the echo example (meant to confirm communication in the case of different implementations, for example Rust and JavaScript). Developers are currently working on implementing the upper layers, like the ping protocol, which times the round-trip for sent and received messages, and Kademlia; a technology used to back file peer-to-peer sharing systems like IPFS and bittorrent using decentralization and denial of service resistance.

As the year draws to an end, we have lots to focus on, and we thank our friends Parity for their work. If you want to discuss anything in this update or join the conversation on all things Parity you can join our Riot channel: #polkadot-watercooler:matrix.org


Glossary

Block Headers — the method by with distributed ledgers (blockchains) identify block position, number, or height, and notate where in the chain a block belongs.

Connectivity Management — managing network connections to connect only to relevant parties: e.g. collators or validators

Contracts Repo — an open-source code repository, located on github, in which Polkadot keeps smart contracts used by the client.

Devp2p — the backbone of Ethereum, working as a secure networking system or communication layer that allows for peer-to-peer connection and more while remaining simple in nature.

Full Mode — a complete validation state, akin to a full node on another chain.

Interpreter — a program that directly executes code without precompiling into another application or machine learning program.

IPFS — a distributed file system aimed at world-wide connection for use as a database or subsystem like HTTP with the potential to realize a serverless internet.

Kademlia — a technology used to back file peer-to-peer sharing systems like IPFS and bittorrent using decentralization and denial of service resistance.

Kovan — a Parity Technologies-built public Ethereum test network.

Libp2p — a modular, feature rich networking stack (computer networking suite). It backs a technology called IPFS (InterPlanetary File System). This more advanced system seeks to power a distributed web that treats web data a bit like bittorrent handles files.

Multiplexing — mechanism that will be used to connect devp2p to libp2p.

Ping Protocol — times the round-trip for sent and received messages.

Polkadot Networking Protocol — a protocol for exchanging blocks, transactions, block candidates, consensus messages, and more over the network.

Proof of Authority (PoA) — 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 Concept (PoC-1) — an early experimental version of our application that demonstrates feasibility and early functionality.

Pwasm — Parity’s version of a WebAssembly environment which can be used for blockchain execution.

Relay Chain Contract — One of the contracts deployed on the Relay Chain that govern the behaviour of Polkadot.

Rust — an open source programming language similar to C++, but intended to provide better memory safety while maintaining performance.

WebAssembly (wasm) — a quick, web-centric coding language with roots in javascript, ideal for in-browser client-side use, with support for compilation from C and C++, and Rust among other languages.


Join us here:

Check out our newly published Polkadot Lightpaper: https://github.com/w3f/polkadot-light-paper/blob/master/Polkadot-lightpaper.pdf

Chat with us on Riot: https://riot.im/app/#/room/#polkadot-trenches:matrix.org

Community discussion on the subreddit: https://www.reddit.com/r/polkadot_market/

Follow our official updates on Twitter: https://twitter.com/polkadotnetwork