A Sovereign Rollup and a Modular Future

For those of you who have been part of the POKT Network (or Pocket Network) community for a while, this is going to seem like a long overdue update on the status of “v1” (henceforth the Shannon Upgrade) – and it is that, but also much more!

What we are excited to announce is that we will be pivoting the development roadmap to adopt the Rollkit framework – an open modular framework for sovereign rollups. Equally exciting, the framework will leverage Celestia as the POKT Network’s consensus and data availability layer.

The goal of this post isn’t to overwhelm anyone with the technical details of the build – if you want to dive into that (as well as all the factors that went into the decision-making), then please head over to the Why POKT is Rolling with Rollkit blog, authored by Head of Protocol, Olshansky, with contributions from the POKT Network core protocol team and others – it’s memetastic!

For everyone else, this post is going to focus on what we at the Foundation see as the major benefits of this pivot for the future of the protocol, LFG!

Big Wins for POKT Network Utility

The rollup pivot represents the following wins for the protocol:

1. Modularity – we are building layers in a way that allows us to stay flexible, and dare I say, future-proof the long-term roadmap. Think of these layers as lego blocks, we can now safely swap out pieces without having to change the entire stack. This is the kind of “de-risking” I like. The issue with monolithic builds is that you have to throw the baby out with the bath water if one piece of the stack won’t scale up to your needs. Modular approaches in Web3 are addressing that and I am here for it. 🍿

1. Focus on our core Utility, but stay Sovereign – Developers building on Celestia can “define their own virtual execution environments; similar to virtual machines” – which is exactly what we were looking for in a rollup stack.  To quote Olshansky’s blog: ‘Instead of scaling validators, we can scale the number of relays that the network can handle. Instead of researching proof mechanisms for state transitions, we can focus on proving different types of relays (gRPC, websockets, etc…) and their quality of service, on-chain. Instead of designing permissionless sequencers, we can design trust and tokenomic mechanisms around permissionless portals (i.e. gateways). We have plenty of other ideas and are hoping to tightly collaborate with the teams behind the projects that we’ll be working with.’  Ultimately, we felt comfortable handing some parts off to these new partners so we can focus on our unique value add. We’re excited about the benefits of the collaboration. 🔬
2. Speed – One might argue that a completely optimized stack will almost always beat a less optimized one, but at what additional cost? For POKT Network’s Shannon Upgrade that cost has been time to market. We know we need to upgrade from the Morse Mainnet and we’re confident this pivot will help us dramatically improve development velocity due to maintaining focus on our Utility, particularly in relation to Shannon Upgrade features like permissionless gateways and advanced QoS functionality.  Why? It goes back to #2, our focus on POKT Network utility means we don’t have to worry about managing L1 blockchain infrastructure, coordinating upgrades and hard forks when we change something, or trouble shooting latency in transaction propagation ourselves.  One fantastic benefit of being a rollup on Celestia – since the DA layer decouples consensus from validation – is that we can update our protocol rules without the need for a Celestia main chain hard fork, that means we can get complex upgrades done faster! 🚴🏼‍♂️
3. Security – Each application on Celestia gets its own sovereign execution space (the rollup) while inheriting the security of Celestia’s consensus, which leverages a shared security model. This means that the security of the Celestia blockchain is inherited and evenly distributed across all the rollups that deploy on it, eliminating fragmentation. Rollups can then easily verify if their transactions were published. This shared security model provides a scalable and efficient way to bootstrap a blockchain ecosystem while enabling additional benefits like secure bridging. It also eliminates the need for new chains to bootstrap their own validator set, which can be a challenging process.
4. Censorship-resistance Often when projects choose to opt-in to a shared security model, they are trading one censorship vector for another – Celestia is designed to be censorship-resistant. This is a fundamental characteristic of decentralized blockchain systems. Celestia’s architecture ensures that once data is posted to the blockchain, it cannot be altered or removed by any single party. This is achieved through the use of a decentralized network of validators who independently verify and store the data.  Furthermore, Celestia’s unique design allows for the creation of many independent rollups, each with their own rules and governance. Celestia is only interested in providing rollups guaranteed ordering of data and its availability – since it decouples validation of transactions (essentially putting the onus back onto each rollup) it accepts all transaction in a “data blob” without attempting to validate them. Essentially Celestia is agnostic to the data being published onto it. Rollups validate their transactions after-the-fact to maintain the rollup state (ignoring any currently invalid transactions stored on the DA layer.)
5. Scaling – The monolithic approach causes some inherent problems with scaling, which includes expensive hardware, limited control, and high overhead for infrastructure operators (validators, etc.) Celestia scales by decoupling execution from consensus and introducing a new primitive it calls “data availability sampling.” Sampling is an efficient solution to the data availability problem by only requiring resource-limited light nodes to sample a small number of random data chunks from each block to verify that all of the data is available. Interestingly, ‘more light nodes that participate in sampling increases the amount of data that the network can safely handle, enabling the block size to increase without equally increasing the cost to verify the chain’. – Source: How Celestia Works (my bold) ⚖️. This pushes us further towards a future where POKT Network can successfully service trillions of relays while supporting millions of nodes without breaking a sweat.

Now that we understand the benefits, let’s take a slightly closer look at what that means for the protocol in relation to the original goals of the project and the work that has been going on for the last year.

Our Core Utility

POKT Network has always been working toward a comprehensive solution for the RPC Trilemma that posits applications need to give up at least one of the following attributes when choosing how to access RPC services that provide read and write capabilities for blockchain networks:

1. Reliability: Uptime, geo-political redundancy, censor proof, etc…
2. Performance: Quality of Service (QoS), latency, geographic decentralization, etc…
3. Cost: Web3 access, infrastructure maintenance, tokenomic incentivization & penalties etc…

Our position is that no application should have to give up any one of these attributes. This is the heart of our Utility module (as defined by the Shannon Specification) – and that won’t change post-pivot. There are additional modules like consensus, networking and persistence, but I like to think of them as the “supporting staff” to this Utility module.

The Shannon Specification

When I joined the Foundation, I spent the first few weeks ramping up on the Shannon Specification – hot take; it’s an incredibly solid, thorough, but extremely ambitious plan. It grew out of the need to update the original chain due to the massive adoption and success of the POKT Network protocol. In three years since Mainnet launch, the project has grown to all-time highs of more than 2B daily relays across 40+ blockchains (Don’t take my word for it, go see it on POKTSCAN 👀)

That said, I was a bit surprised by the breadth of the specification. Building an L1 blockchain from scratch is far from trivial. But, as Olshansky laid out in his post when giving background on the origins of the project: ‘Concepts like rollups, modularity, data availability, and even Ethereum as a Proof of Stake chain were mere visions on some distant horizon.’

That totally made sense to me – the team built off a fork of the original Tendermint Core (as did Polygon PoS Mainnet, the Binance Beacon Chain, and many others) which was basically the go-to Byzantine Fault Tolerant (BFT) State Machine Replication framework out there if you wanted to build anything back in the pre-rollup-scaling early days. Facing the limitations of the early tech and a growing ecosystem, the team had to start planning for the future, and the Shannon Specification was born.

The Specification concentrates on four distinct modules, namely:

• Utility – the core of the project, this module defines the rules of engagement during a session and the governing criteria for actors participating in them. This is what most of us talk about when anyone asks “What is POKT Network?” In technical terms, it defines an account-based state machine protocol that enables applications to permissionlessly access high-quality decentralized Web3 services without the need of maintaining blockchain clients themselves. Basically, this is the execution environment for POKT Network. We will focus here and build the Utility module as a rollup on Celestia.
• Consensus – this module defines a leader-based BFT replication & consensus protocol that is a modification of Hotstuff (a.k.a HotPOKT) to build a replicated state machines with that maintains liveness with fast finality. That’s a mouthful for a “semi-technical” post – TL;DR, lots going on here related to keeping public tabs on staking, burning, minting, slashing and proving – when we need to update an application’s POKT balance after a session or make sure Servicers have been paid, this is where the agreed upon data lives to facilitate that. In more general terms – this is the POKT Network data availability layer which will now be handled by Celestia.
• P2P Networking – (a.k.a RainTree) this module defines how messages move (gossiped) between all the nodes on the POKT Network – peer-2-peer message propagation is an on-going area of research and factors into mechanisms like block finality, node syncing, and time to consensus. Fortunately for POKT Network, we do not require crazy fast block times as a lot of the magic happens “off-chain” – all we really need to guarantee is that the data related to a session will propagate through to enough nodes on the network to fulfil consensus rules that ultimately gets that data published to the canonical version of the POKT Network blockchain. Celestia leverages the p2p layer of CometBFT therefore providing this networking “out-of-the-box.”
• Persistence – this is the “off-chain” module. All that really means is that it defines a specification for a database engine (built using PostgreSQL) and the subsequent rules that guarantee scalability, robustness, data integrity and security. The POKT Network core devs will continue to work on optimizing this module.

Decision Time

Building blockchain infrastructure from the ground up is hard work – and that isn’t the POKT Network team’s mission. Needless to say, I was incredibly excited when Olshansky and the team decided to hit the pause button on the current development path and do a research sprint focused on emerging rollup tech. The team evaluated, hacked, read, spoke with experts (again, all the details are in the technical blog) and in the end made the decision to build with Rollkit and Celestia.

What happens next?

With the decision made, it’s go time!

The team has already started prototyping the POKT Network’s Shannon Upgrade as a rollup using Rollkit with Celestia as the DA layer, and we are committed to bringing this to mainnet early next year. We will be back very soon with the following:

1. Update of the Shannon Specification – that focuses on Utility and the integrations
2. Update of the Shannon Roadmap with target delivery timelines
3. Testnet – ETA early December 2023
4. Mainnet – ETA Q2 2024

More about our new partners:

What is Rollkit?

Rollkit is a rollup framework that gives developers the freedom to deploy rollups throughout the modular stack, opening new possibilities for rapid experimentation and innovation.

The Rollkit framework features a modular node that can run rollups and exposes an ABCI-compatible client interface, which can be used as a substitute for CometBFT in any ABCI-compatible blockchain application. By default, the node utilizes Celestia as the data availability (DA) layer, however other data availability layers can be integrated.

More at https://rollkit.dev/

What is Celestia?

Celestia is a new technology that powers, scales and secures Web3 applications. To achieve this, Celestia introduces a new modular blockchain architecture that solves the core scaling problems of today’s blockchains. Modular blockchains introduce a new paradigm in blockchain design. Instead of one blockchain doing everything, modular blockchains specialize and optimize to perform a given function. This specialization provides breakthroughs in scalability, flexibility, and interoperability, enabling developers to build blockchain applications for mass adoption.

More at https://celestia.org/

‍