Gossamer: Into the Polkadot-verse Pt. 4
Authored by Dan Forbes
For anyone unfamiliar, Gossamer is a Go implementation of the Polkadot Host. Once ready, Gossamer will increase Polkadot client diversity and contribute to the resilience and security of the network. In the future, we hope it will also foster growth by providing a modular development framework on par with Substrate.
Working on a Polkadot client is a dynamic process, in part because the specification we're following is a moving target. But much progress has been made since our last update, and we're excited to share some of the key things we've been working on. Let's go!
Polkadot state trie
A critical part of our work on Gossamer involves the State Trie, a mechanism for storing data that makes it easy to find and retrieve specific pieces of information. Fun fact, "trie" is derived from the word "retrieval."
The Polkadot Protocol specifies a modified Merkle Patricia Trie. A Merkle Trie is a type of trie that uses hashes to verify data integrity. Patricia is an acronym for "Practical Algorithm to Retrieve Information Coded in Alphanumeric" and refers to the specific implementation the trie employs to facilitate information retrieval.
Why does it matter? This data structure allows a node participating in a blockchain network (like Gossamer) to efficiently verify changes in the network's state given a set of changes (e.g., transactions). This is why the trie is referred to as the "State Trie."
Updates
Polkadot was recently updated to specify an enhanced version of the State Trie. The old version was Version 0; the new version is Version 1. Parity's Rust implementation of the Polkadot Trie is in its own repository. The Version 1 features were implemented in this repository at the end of last year. Also, at the end of 2021, the changes from the trie repository were pulled into Substrate. As of v0.9.24, the Polkadot runtime is still using Version 0 of the State Trie.
The update adds four new types of nodes (elements) that can be used in constructing a trie (there were three types of nodes before this update). So now, there are seven total node types available. A node's type is declared in the "header."
Two of the new node types are used for storing "hashed subvalues," which is a way of storing data in a Merkle Patricia Trie that improves performance without sacrificing the cryptographic guarantees of the trie. The new trie version supports a number of use cases, including making it easier for blockchain client implementers to cache large values and only download updated values as needed. Aside from hashed subvalues, one of the other two new node types is designated for empty values, while the remaining node type is reserved for compact encoding.
We're actively working on this update, and you can track our progress here.
Parachain inherents
Another critical piece of the puzzle is parachain inherents. Substrate provides the ability for block authoring nodes to include "inherent" data in the blocks they author. Inherent data is similar to the data that's contained in signed transactions. However, whereas signed transactions are submitted via an RPC server and are attributed to the account used to sign the transaction, "inherents" are directly provided by block authors and attributed to the account used to author the block. This means that there's no need for them to be signed.
Looking at the bigger picture, the function of networks like Polkadot and Kusama is to support parachains by increasing their decentralization and providing shared services like message-passing.
To support parachain networks, Polkadot specifies certain parachain-related inherent data that block-authoring nodes must include. The parachain-related inherent data includes bitfields, backed candidates, dispute statements, and a parent header (all described in greater detail below). The propagation of this data also allows for the advancement of parachain consensus.
-
Bitfields are used by block-authoring nodes to communicate their view of the parachains' states to the other block-authoring nodes in the network.
-
Backed candidates allow block-authoring nodes to vouch for the validity of specific candidate parachain blocks.
-
Dispute statements support Polkadot's Disputes Subsystem, which is used to adjudicate disputes related to candidate parachain blocks.
-
The parent header is a reference to the previous block, and it's used for verifying state proofs.
You can track our progress toward implementing parachain-related inherent data on GitHub.
Other news
Sigma Prime recently audited Gossamer's consensus capabilities, and we're already well on our way to addressing the issues they turned up. Beyond that, we continue to work towards supporting the latest Polkadot runtime, along with memory and testing improvements.
To stay up to date on Gossamer, follow ChainSafe on Twitter. You can also dig into the Gossamer code here, read the docs, or join in the conversation on the #Gossamer-general channel on our Discord.
ChainSafe has also created a public guild dedicated to all things Polkadot.
About ChainSafe
ChainSafe is a leading blockchain research and development firm specializing in infrastructure solutions for web3. Alongside its contributions to major ecosystems such as Ethereum, Polkadot, Filecoin, Mina, and more, ChainSafe creates solutions for developers and teams across the web3 space utilizing our expertise in gaming, bridging, NFTs and decentralized storage.
As part of its mission to build innovative products for users and improved tooling for developers, ChainSafe embodies an open source and community-oriented ethos to advance the future of the internet. To learn more, click here.
