Developing Analog's Timechain: Why we chose Polkadot SDK

Analog is a one-stop interoperability hub, offering a suite of protocols that address native dapp developments in multi-chain and cross-chain environments. Analog’s foundational component is the Timechain, a custom-built blockchain utilizing Polkadot SDK. The Timechain serves as a fundamental accountability layer for all network operations.

In this post, we explain why we used Polkadot SDK instead of other development frameworks.

Background and context

Exactly two years ago, Analog proposed the Timechain, an interoperability-focused blockchain network designed to meet the native dapp development requirements in multi-chain and cross-chain ecosystems. Victor Young, Co-Founder and CEO of Analog, shared his belief that no single blockchain can solve everything. Instead, to unlock opportunities for a wide range of solutions in Web3, multiple siloed blockchains must be able to interact meaningfully with one another through interoperability.

Focusing on security, chain-agnosticism, and an all-in-one interoperability network, the Timechain would serve as a ledger for all the ecosystem activities—essentially acting as an accountability layer. Timechain is designed as a sovereign blockchain enabling dapps to connect to any other dapp or blockchain seamlessly and securely.

Obviously, selecting an appropriate technology framework for building the Timechain was our top priority. We understood that even slight differences in the problem we were solving could significantly impact the efficiency of the solution we intended to build, with the Timechain serving as an all-in-one interoperability hub being one key consideration.

Blockchain SDK considerations

From the start, we didn’t choose to build the Timechain from scratch because it would have been too complex and time-consuming. Instead, we considered using a pre-built open-source SDK. After carefully evaluating the available blockchain development frameworks, the choice was narrowed down to Polkadot SDK versus Cosmos SDK.

If you had been closely following the interoperability space at the time, you would have noticed that many similar projects, like Axelar and Zetachain, were being developed on top of Cosmos SDK. Cosmos SDK would have been the logical starting point for building the Timechain, especially since some of these protocols had already launched their testnets.

However, a few factors stopped us from pursuing this route after comparing Cosmos versus Polkadot SDKs. More specifically:

1. Did Golang in Cosmos SDK provide a real advantage over Rust language in Polkadot SDK?
2. Which framework provided better libraries and tooling for implementing a custom blockchain like the Timechain?
3. Which framework had better future compatibility and performance for the state transitions?
4. Which framework was more agile in terms of onchain governance and upgrades?

Why Polkadot SDK?

Early on in the development, we faced the challenge of designing a blockchain that was fully compatible with the Threshold Signature Scheme (TSS) while also utilizing its underlying Byzantine Fault Tolerant (BFT) capabilities. Finding different TSS design decisions, such as whether TSS nodes should function as onchain validators or offchain workers, proved particularly difficult.

Analog successfully integrated a TSS module in the Timechain by utilizing the concept of off-chain workers within the Polkadot SDK. This module allows the Timechain to interact seamlessly with external blockchains. Moreover, due to Polkadot's modular consensus layer, Analog was able to build an NPoS consensus framework compatible with TSS.

Based on these design decisions, we came up with different custom pallets. To start with, Analog implemented the shards pallet, which keeps track of the shard status (e.g., offline, online, or committed). This pallet hosts the logic of the Chronicle Nodes, which are off-chain validators that attest to external transactions.

Analog also developed other custom pallets, including:

• Elections pallet: Manages unassigned members and creates shards if enough members are online.
• Networks pallet: Facilitates the creation of new networks (i.e., blockchains).
• Task pallet: Provides several extrinsic for managing various operations.

Beyond enabling the TSS functionality, other reasons we found the Polkdat SDK helpful include:

• Security: While both Rust and Go are modern, high-performance languages, Rust’s robust memory management capabilities provide a greater degree of security.
• Forkless upgrades: Polkadot SDK allows us to update the runtime logic without creating a hard fork. This is possible because it includes the runtime WebAssembly (WASM) blob as a component in the blockchain’s runtime state.
• Future compatibility and performance: Because WASM is at the core of all the state transition functions in Polkadot SDK, which is stored on-chain, we are able to build a future-proof Timechain.

Takeaways

Building a blockchain from scratch can be complex, time-consuming, and resource-intensive. Polkadot SDK is a popular and battle-tested framework that has allowed Analog to build a future-proof blockchain. Thanks to the separation of the client (WASM executor) and the blockchain runtime (state transition function), as well as the modularity of the Polkadot SDK pallets, Analog has been able to build an interoperable protocol that addresses developers’ needs in multi-chain and cross-chain environments.

About Eric Wang

Eric oversees go-to-market and BD at Analog. Previously, he was the head of growth at Parity Technologies and a General Partner at ROK Capital. He is a Stanford PhD dropout and has a MS from Stanford and BS from UCLA.