Parity’s Polkadot Dev Update #2

Image for post
Image for post

First of all we would like to wish everyone a very Happy 2018 from the team at Parity Tech! The holiday break didn’t stop our devs from working away on the Polkadot build, so here is our update with the latest progress.

The foundations of the Bridge development (Ethereum-Like <-> Ethereum-Like) is ongoing. This will enable us to create parachains which provide their own consensus, instead of relying on Polkadot’s native security and will connect smart contract capable blockchains to Polkadot without any modification to their protocol. The Parity-bridge can transfer value from an Ethereum PoW chain to an ethereum PoA chain and back.

Additionally we have been making the bridge more secure: closed an attack vector, fixed bugs, wrote more tests, introduced solium linting, improved CI, did some refactoring and added documentation. ( Currently we are making the bridge work with contract-based validator sets to be ready for the Kovan hard fork 2, which will introduce contract-based validator sets to Kovan. At the moment the bridge uses a fixed authority list, switching to contract-based dynamic validator sets is required to work with Polkadot later.

To have a detailed look at Parity’s work on the bridge, check out the github page: paritytech/bridge where there is a link to the repo, in addition to explanations on the simple bridge between Ethereum and Kovan networks.

Besides working on the bridge, we have begun work on a Polkadot JavaScript implementation. At the moment the project has 2 main parts, JS API & JS Client implementations. You can check out the full overview here: The skeleton is in place for the API (supporting both WebSockets & HTTP) and it has been tested with the Polkadot Rust client, however since the RPC layer for the clients are way down the priority list, it does not do much yet. As methods get added to the client implementations, the API layer will follow and track.

The JS Client is very much a WIP and lagging behind the Rust implementation. It has an operational libp2p network layer that discovers other nodes and sends status messages between clients. For POC-1 where the Polkadot Rust client will use DevP2p, it means that comms between the clients won’t (yet) be possible. We will also be using libp2p in the Rust version as well, you can see the ongoing work on that by going to the dedicated github page on this. Currently the client work here is focussed on tracking the Rust WASM runtime implementation, expanding the JS runtime to expose all the same methods. Initial target is to have a JS node that can validate blocks & transactions generated by the Rust client.

In other news, we have been continuing our focus on the core Polkadot stuff, mainly designing a consensus algorithm and staking incentives. We are 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.

If you would like to follow the daily musings on the Polkadot build, please join the dedicated Riot channel we have set up for all the techie stuff:

And finally… if you would like to discuss anything in this update, ask any questions or join the conversation on all things Parity you can join our Riot channel:

Polkadot Network

Medium account/ publication of the Polkadot Network

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store