What is better than one ecosystem of ambitious teams, talented individuals, and bleeding-edge technology? Two such ecosystems. In this post, we provide the story of collaboration across the Starknet and interchain ecosystems that has been flourishing for a few months.

The organizations involved in this collaboration include StarkWare Industries, Starknet Foundation, and Informal Systems. At Informal specifically, we are using our expertise in productionizing and operating app-chains toward enabling Starknet to achieve two primary objectives: production-grade (1) decentralization and (2) interoperability.

In this post, we will cover two main points. First, we provide some background on how this collaboration emerged. Second, we will describe the strategic importance this work has both for the Starknet and interchain ecosystems.

Brief background

This collaboration started taking shape in the late spring of 2023 with technical discussions. The topic was trade-offs in the Tendermint consensus algorithm, seen from the perspective and requirements for decentralizing Starknet L2. Some of the original designs that the StarkWare team drafted on this topic can be seen on the Starknet forum, e.g., here and here. We brought to the table our expertise from maintaining CometBFT, which implemented the Tendermint algorithm.

Since then, the overlap in interests between the two teams has expanded, going beyond just the distributed algorithm details of Tendermint. The collaboration slowly grew over time to cover both decentralization protocol design and core engineering contributions for Starknet decentralization.

Presently, beyond the decentralized sequencer, we are also exploring how to apply our expertise in interoperability to expand the reach of Starknet applications and reduce ecosystem fragmentation through the IBC protocol. Let’s go into more detail in both of these areas.

Current status

1. Decentralized sequencer

We had two guiding properties for the design of the (decentralized) Starknet sequencer: fault-tolerance and censorship-resistance. Sequencer decentralization is an intense area of research across the broader industry, and it is important because it can ensure continuity — i.e., liveness — of transaction inclusion in L2 despite arbitrary failures, including censorship.

As mentioned above, the work between StarkWare and Informal started by revisiting the Tendermint algorithm to ensure it caters to the needs of a decentralized sequencer in a ZK-based L2. To be more precise, by ZK we mean here validity proofs. We then proceeded to plan for shipping and productionizing such a sequencer. This is still ongoing.

One key decision was that the most appropriate long-term solution for this sequencer would comprise multiple implementations of the protocol. This is essential for sequencer (node) diversity. Among these implementations, one is undergoing in Informal Systems.

A core component of each of the sequencer implementations is the Tendermint consensus algorithm, which grants the ability to reach consensus on a value in a Byzantine-fault tolerant (BFT) setup. This is key for fault-tolerance of the sequencer. Another important property is censorship-resistance. This will be the subject of a future technical post, suffice to say that the sequencer is designed with the ability to reconfigure its set of nodes. So even if sequencer nodes might misbehave by censoring transactions, this set of nodes will reconfigure by shedding or adding nodes, as prescribed in the L1, the source of truth. Additionally, Tendermint is a responsive consensus protocol, ensuring that its latency depends on actual network delays, not on preset conservative time-bounds.

The codename for Informal’s implementation is “Malachite”. We have been writing it in Rust. It is feature-wise similar to the consensus reactor in CometBFT. But internal APIs, module boundaries, concurrency model, and testability in Malachite are heavily inspired by the lessons we have learned while contributing to, maintaining, and operating CometBFT (and previously Tendermint Core) in the last years.

We have focused engineering efforts in Malachite so far on iterating fast on a design that is easy to extend and grow, as well as formal modeling, testing, and edge case handling. As with any distributed protocol, the edge cases are the most important ones, and they bring the most complexity. We have modeled the initial system implementation in Quint and adapted the code to run model-based testing based on traces generated from Quint. The main two challenges we faced so far were as follows. First, maintaining Malachite lean and testable throughout the multiple design sprints, ensuring that its various components remain cleanly separated. Second, iterating on the decentralization protocol while maintaining a rigorous understanding of its details.

We have presented some of these insights and the approaches we took to mitigate these challenges at StarknetCC on July 10th. In that presentation, we have also provided a high-level view of a sequencer node built using Malachite, and an overview of protocol modeling in Quint. The diagram below is from the presentation we gave, and shows Malachite comprising three components: VoteKeeper, Driver, and StateMachine. These implement the Tendermint consensus algorithm. We call Malachite a sequencer core given its very concise and efficient footprint. The concurrency architecture relies on the actor model.

We plan to open-source Malachite with the sequencer node as it is taking more concrete shape and is ready to be demo-ed.

Side note: Malachite <> CometBFT. Malachite is complementary to CometBFT. Consider that CometBFT is the state-of-the-art BFT consensus engine, it is written in Go, and comes with batteries included for an extremely broad range of use-cases. In contrast, Malachite will cover the opposite part of the spectrum: It is an adaptable core enabling the building of a sequencer for highly-specialized modular stacks, with a targeted range of applicability, high-performance, built in Rust, with a small number of moving parts. Despite a smaller footprint, importantly, we are designing Malachite as a lean core that is easy to extend. Whereas CometBFT is akin to Swiss army knife, Malachite will be akin to a surgeon’s scalpel. Both CometBFT and Malachite seek to be reliable and offer long-term maintenance guarantees.

2. Interoperability

The driving purpose of integrating IBC into Starknet is to enable application composability across the broader industry consisting of diverse L2s and L1s. As an open protocol, IBC is rapidly establishing itself as the interoperability standard, being used in 115 chains in production and enabling $30B+ in Annual Value Transfer. IBC will enable the flow of liquidity both ways between Starknet and the wider interchain, opening up avenues for collaboration across ecosystems.

In this work, we are starting with a focus on the fungible token transfer application (ICS 020). On the Starknet side, we are exploring how to run the Rust IBC modules (ibc-rs) as a sidecar to the Starknet stack, and trying to identify how much of the IBC machinery exactly needs to be proven in Cairo. We have identified three approaches to integrate IBC, and the sidecar one seems most promising.

On the interchain side, things are easier. The Cosmos SDK already integrates with IBC modules in Go (ibc-go). Nonetheless, we are scoping carefully and preferring pragmatic choices. We are trying to leverage the solo machine IBC client, which makes it easier to start integrating, and is feasible thanks to the current Starknet sequencer design. As soon as Starknet upgrades to a decentralized sequencer, this light client will need to be migrated to a different model. As the most probable integration counterparties in the interchain, we plan to aim for Osmosis, Neutron, Stride, and/or Cosmos Hub. It is possible a CosmWasm will be a prerequisite, given that we plan to leverage the IBC Wasm client.

On the relayer side, we plan to use Hermes v1 line, a state of the art implementation of IBC relayer in Rust by Informal Systems. Eventually, as the integration with the decentralized sequencer will ramp up, we plan to transition to using the Hermes SDK. This will allow us to instantiate a specialized version of an IBC relayer that is specific to Starknet and meets the performance, stability, and feature criteria needed for this L2.

Conclusion

We’re excited about the possibilities to be unlocked with the collaboration we’re working on with Starknet. Feedback is a vital part of any strong development process so please reach out and let us know your thoughts on our work. The StarkWare and interchain team at Informal are committed to building and growing our respective ecosystems for the benefit of both users and developers.

Many thanks to Isabel Chi, Abdel Bakhta, and Josef Widder for insightful comments and suggestions on earlier drafts of this post.