ChainSafe Systems: Introducing Gossamer, Update #0
gossamer: filaments from a web that was spun by a spider
Hello from ChainSafe Systems! As you may have heard, we recently received a grant to implement the Polkadot Runtime Environment (PRE) in Go. We’ve chosen the name Gossamer for our implementation. Gossamer is the fine material woven by spiders or it can refer to any sort of thin, sheer fabric. We feel this is a good description of what we’re building — a layer in the web of the Polkadot network. We found the word in a passage from William Gibson’s Neuromancer: “The thing was a kind of pilotless biplane of gossamer polymer, its wings silkscreened to resemble a giant butterfly.”
In this first update, we’ll introduce you to the team working on this, give you a brief overview of the PRE, outline our development milestones, and update you on our current progress.
The Team
We have five members of ChainSafe working on this project:
David Ansermino (github) / Elizabeth Binks (github, twitter) / Dustin Brickwood (github) / Priom Chowdhury (github, twitter) / Amer Ameen (github, twitter)
We are all very humbled and excited with the opportunity to work on a fundamental component of Web3. Feel free to reach out to any one of us if you’re interested in learning more or if you would like to get involved!
Overview of the Polkadot Runtime Environment
The Polkadot Runtime Environment is a framework which is used to build blockchains. Similar to how web frameworks, like Angular or React, help developers build web applications, the PRE will help developers build blockchains. When one of these blockchains is connected to the Polkadot Network, we call it a parachain (parallelizable chain).
The Polkadot Network consists of a relay chain and many parachains. Each parachain has its own extrinsics (i.e. transactions), state transitions, and consensus mechanism, while the relay chain coordinates consensus of the entire network and cross-chain messages. It’s also possible to create a parachain that functions like the relay chain with a network of parachains connected by it.
The PRE is designed to be modular. This means any of its parts can be customized for any desired functionality. Developers will have the option of changing a configuration file for minor customizations (e.g. block time), swapping plug-and-play modules for more significant customization (e.g. consensus mechanism), or writing custom modules for complete customization.
The PRE has three core layers: libp2p for networking, a WebAssembly (WASM) interpreter as the virtual machine, and the GRANDPA Proof-of-Stake (PoS) consensus mechanism. It also has a custom encoding scheme, SCALE, and a Trie database similar to Ethereum’s (for storage). When creating a new blockchain, implementing these components is a significant proportion of the effort required. With the PRE, developers will have a functional blockchain out-of-the box and can focus their efforts on customising it to their needs.
For example, a common scenario is creating a blockchain where the only change from the default configuration is the format of the extrinsics. An extrinsic can be thought of as a generalised transaction; it is data submitted to the blockchain that could possibly change the state of the chain. We normally think of transactions as having to, from and value fields, but we could customize them to include fields like PoS validators, votes on a proposal, or zero-knowledge proofs. In this case, the developer could focus on creating custom extrinsics and create their blockchain in a fraction of the time it would normally take.
The overarching idea of the PRE is to make blockchain development more efficient and accessible. Whether you’re new to the industry or an experienced blockchain developer, the PRE will help you create blockchains more effectively than ever before. Developers can focus on the unique aspects of their blockchain, like the logic (i.e. the runtime) without having to be experts in other areas like networking or consensus mechanisms.
Milestones
Looking over the Polkadot Runtime Environment specification, we’ve identified several key milestones in development. They are the completion of:
- SCALE Encoding: This is the package used to encode and decode data into a consistent form, for hashing, messaging, etc.
- Trie DB: This is the data structure used for the storage of the state and general storage.
- Networking: We will be using go-libp2p to facilitate node discovery and communication.
- Consensus: We will be implementing the Proof-of-Stake consensus mechanism GRANDPA. Read this article for a good introduction of GRANDPA and the formal specification for an in-depth technical description.
- WASM interpreter: We must implement a WASM interpreter because, as explained on Substrate’s readme, the state transition function is encoded in WASM (this is known as the “runtime”). This can specify things like the staking algorithm, transaction semantics, logging mechanisms, and procedures for replacing any aspect of itself or of the blockchain’s state (“governance”).
- Runtime module library: a set of libraries that can be used to create a custom runtime.
Project Updates
We began this project with a kickoff meeting to set expectations across the team and address any concerns or uncertainties off the bat. To start we focused on understanding and clarifying the Polkadot Runtime Environment specification. While it has been a challenge working with a spec that is a work-in-progress, it’s quite a privilege to work so closely with the talented team at the Web3 Foundation as it evolves.
We began development with the SCALE encoding as it’s a fundamental component of the PRE that much of the future development relies on. The equivalent to SCALE on Ethereum is RLP. SCALE stands for Simple Concatenated Aggregate Little-Endian. It’s used to encode everything from the Trie DB entries to extrinsics to the runtime data. The idea behind SCALE is simple: for a byte array, encode the length of the array, and place it at the front.
For more information, check out the Substrate docs.
We recently completed our initial implementation of the SCALE codec! Check out our repo to see what else we’re working on.
Next Steps
In order to confirm that our implementation of the SCALE codec in Go works as intended, we will be doing cross-client testing with the SCALE codec implemented by Parity in Rust. During testing, if our implementation produces the same output as the Parity implementation, then we can be confident that our SCALE implementation is complete and correct, and that the specification is sound.
We are also currently working on implementing storage (the Trie DB) and networking (libp2p).
Thank you for taking the time to read more about our progress with Gossamer, our Polkadot Runtime Environment. Look for another update from us in a couple of weeks!
