Exploring Alternative Tech Options for Building on Polkadot

Tech Talk
1

Overview

Hi everyone,

I am opening this thread hoping to share and discuss the current tech options for building on Polkadot, highlighting their strengths and weaknesses when it comes to onboarding new developers, what the community wishes to exist, and generally the direction the community is interested in seeing the tools evolve.

I assume that Polkadot’s infrastructure is primarily built using Polkadot-sdk / Rust, which is a powerful and feature-rich solution that offers extensive configuration and customization options. However, there are scenarios where a simpler, more accessible solution may be preferable, also onboarding new developers could benefit from a more streamlined process.

Furthermore, it’s essential for the ecosystem to offer alternatives, which ensure that there are no infrastructure components that could be a single point of failure and guarantee openness and accessibility to a broader developer audience.

I’m part of a team addressing some of these concerns by working on an alternative framework for building parachains in Go, Gosemble. While this framework is still in its early stages and not yet production-ready, I hope to outline its current state and gather insights into its potential future development.

Motivation

Here are some of the reasons for the existence of this project:

  • We view Polkadot as a more abstract layer that should not be bound to any specific tech stack. The current ecosystem and ongoing protocol improvements are focused on Polkadot-sdk / Rust, but having different implementations should lead to better abstractions and generalizations at the technical level.

  • We aim to streamline the building process, with an emphasis on simplicity and ease of use over configurability and feature richness, with a faster development cycle. Many parachain builders don’t utilize all the options available in Polkadot-sdk, and its steep learning curve can be a barrier.

  • Having different options will help mitigate the risks of single points of failure, where key infrastructure is supported by a single entity (e.g., the polkadot-js case).

  • We aim to make Polkadot more open and accessible to a wider developer audience, fostering a more decentralized and resilient network by enabling more people to contribute to the protocol.

Current State & Priorities

Our project is based on a custom Go toolchain and currently supports the most essential functionality (not app-specific). Ultimately, it should become a complete solution in Go for building parachains. However, there is still room for improvement, particularly concerning the integration between the Gosemble (Runtime) and the Gossamer (Host).

In addition to making it production-ready through improvements and extensive testing, our goal is to enhance its utility within the Polkadot ecosystem. Thus, we seek to align our vision and priorities with the community’s needs.

Here are some questions we aim to seek answers to:

  • What functionality would you like to see in this project?
  • What technological options is the community missing for building on Polkadot besides Polkadot-sdk?
  • What is worth building to bring more adoption, and what are the use cases the ecosystem should focus on (e.g., maybe providing services to other ecosystems like Ethereum, having the functionality available as parachains)?

I hope this is the right place to discuss and share such ideas?

1 Like