polkadot

Building an Alternative Polkadot Client: Gossamer 2022 Year-in-Review

ChainSafe

ChainSafe

— 4 min read
Building an Alternative Polkadot Client: Gossamer 2022 Year-in-Review

It's been a busy year for team Gossamer! We started with an audit focused on Gossamer's consensus capabilities (i.e., the BABE block production algorithm and the GRANDPA block finalization algorithm) but that also uncovered areas for improvement in Gossamer's RPC layer and SCALE codec implementation.

At the end of November, Gossamer v0.7.0 was released! Throughout the year, the team worked hard to maintain compliance with the Polkadot Host specification, all while refactoring and improving existing code and tests along the way.

Below is a short guide for interacting with your own local Gossamer node today, as well as a retrospective from 2022 and a sneak peek of our plans for 2023 🚀

Demonstration - local Gossamer node

The following guide is meant to demonstrate Gossamer's current capabilities. Although we are still working towards our primary goal of being a DOT-earning validator on the Kusama and Polkadot Networks, it's possible to use Gossamer today as a host for standard local Polkadot test networks, which will be the focus of this guide.

The following steps, which are provided in greater detail as part of the Gossamer README, will demonstrate how to acquire and build Gossamer code, launch a local Gossamer test network using a standard Polkadot test configuration, and interact with that network by using the standard Polkadot-JS Apps UI to submit a signed transaction (token transfer).

Requirements

This guide is written for Unix-like terminals (Linux, macOS, WSL, etc.), and those who wish to follow along should be comfortable with the command line.

Git is required to obtain the Gossamer source code, and Make is used to build it. Building Gossamer requires version 1.18 of Golang. Note: any version of Golang other than 1.18 will not work.

Building Gossamer

First, use Git to clone the Gossamer repository and checkout the v0.7.0 release:

git clone git@github.com:ChainSafe/gossamer

cd gossamer

git checkout tags/v0.7.0

Then, use Make to build Gossamer

make gossamer

Starting Gossamer

Starting a Gossamer node is a two-step process. First, a data storage directory (used for runtime storage, block history, and more) is initialized; second, the node is started with parameters that provide the necessary information, such as the location of the data storage directory.

More details can be found in the Gossamer README.

Initialize the data storage directory:

./bin/gossamer init - force - config ./chain/westend-dev/config.toml

Start the node:

./bin/gossamer - config ./chain/westend-dev/config.toml

Using Gossamer

Once the node is started, it can be accessed by using standard tools, like Polkadot-JS Apps UI - use this URL to connect directly to the local Gossamer node. To test out the capabilities of the node, use the accounts tab to make a transfer between two of the test accounts.

Current limitations & future plans

One of the critical problems that the Gossamer team is working on right now is the memory consumption of the Gossamer Polkadot Host.

As of Gossamer v0.7.0, it's not practical to sync to the head of any official Polkadot-like public networks (i.e., Westend, Kusama, or Polkadot), which clearly limits Gossamer's ability to achieve its primary purpose. Addressing Gossamer's memory consumption to enable testing the behavior of Gossamer as a validator on a public test network like Westend is the most important problem that the Gossamer team is addressing at this time.

Another important limitation of the Gossamer v0.7.0 release is its inability to finalize blocks in a multi-node network. Identifying the cause of this bug and solving it will be a top priority for us in 2023.

In parallel with addressing Gossamer's memory issues, the Gossamer team will also work on improving our testing configuration and test environments - in particular through the use of ZombieNet, a testing framework provided by Parity Technologies.

As part of implementing ZombieNet compatibility, we'll focus on updating Gossamer tests to reduce the number of chain specifications present in the Gossamer repository.

2022 development highlights

Command-line interface

BABE (Block Production)

GRANDPA (Finalization)

Tests & CI/CD

Sigma Prime audit

The following items are a selection of the problems that were uncovered and solved as part of Sigma Prime's audit. A complete list of these issues can be found on GitHub.

  • GSR-08: Race Condition May Result in Mismatch of Runtime and TrieState (#2402)

  • GSR-10: Panic When Deleting Some Nonexistent Keys From Trie (#2402)

  • GSR-11: Duplicate Votes in GRANDPA are Counted as Equivocatory Votes (#2410)

  • GSR-17: VerifyBlockJustification() Does Not Verify Justification Hash Relates to Block Being Justified (#2414)

  • GSR-18: Casting of uint32 to int Will Overflow In 32-bit OS (#2415)

To stay up to date on Gossamer in 2023, 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 in our Discord👋

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, 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.

Website | Twitter | Linkedin | GitHub | Discord | YouTube | Newsletter

Read more