What is Gossamer and how does it compare to Substrate?

Question

Gossamer is a Go-lang implementation of the Polkadot host. What does this mean, and how does this compare to Substrate?

Could Gossamer be the Go-variant of Substrate for developers exploring ecosystems that do not primarily target Rust?

Answer 1

@Squirrel is correct that this is not strictly a Substrate question, but I still think it's a great question nonetheless ;-) As you said, @Afr, Gossamer is a Golang implementation of the Polkadot Host, but I'm happy to expand on this a bit.

In short, the concept of a "Polkadot Host" is very similar to the concept of a "client" in other blockchain ecosystems, with one important distinction - as @Squirrel points out, implementers of a Polkadot Host do not need to implement the Polkadot runtime. This is because of the way in which Polkadot's architecture cleanly separates runtime logic, which is supplied by platform-agnostic Wasm, and the other concerns of a blockchain client, such as its consensus engines, network layers, transaction pool, and more.

Parity Technologies maintains the reference implementation of the Polkadot Host, which is, of course, written using Substrate - a Rust-based framework for blockchain development. Substrate is arguably the most configurable and fully-feature blockchain framework out there, and, in addition to being used to build Parity's implementation of the Polkadot Host, it can also be used to build Polkadot parachains and even bespoke standalone chains. One of the things that makes Substrate so powerful is its FRAME system for runtime development, which is what is used to implement the Polkadot runtime.

As of this time, Gossamer development has primarily been focused on implementing the Polkadot Host, which means implementing various specifications, interfaces, and more. Although this has all been done with an eye towards building out a fully featured blockchain development framework in the future, I don't think it's fair to compare Gossamer to Substrate in that respect. For one thing, Gossamer cannot be used to implement Wasm runtimes at this time, due in part to the fact the reference implementation of Golang does not yet support compilation to Wasm.

Answer 2

(This is a polkadot, not a substrate question)

There's two distinct parts: The node which runs the chain which confusingly is called the 'client' and the on-chain wasm called the 'runtime'.

My understanding is that there are currently 3 different language implementations of the client and all follow the polkadot protocol.

As for on-chain wasm one could argue that it is more centralised in that it only really makes sense to have one codebase compiling to a particular wasm runtime (but that could in theory be done from any language that compiles to wasm. If the well known functions collectively called the 'runtime api' are in the wasm then it should work).

That said, there are many different parachains with their own runtimes and each runtime upgrade is typically elected via some form of governance - it could come from any fork potentially of the code as long as governance agrees.

The same is true of the relay chain but in order to improve scalability the relay chain code is gradually focusing on doing less and less (delegating functionality to system parachains and thus decentralising further).