Full Breakdown About The Upcoming Pocket Version 1

After one year and a half of launching the Pocket Mainnet, a new era of blockchain infrastructure will begin with Pocket v1. Discover all the changes in the Pocket ecosystem and how this new version will boost quality and scalability for applications, node runners, and the entire realm of actors within Pocket.

The first chapter: A proven thesis with tremendous growth in less than 1.5 years

Pocket launched its Mainnet in mid-2020 to deploy a minimum viable product to test our hypothesis of Web 3 unification. The industry needed to have the right incentives and solutions to benefit both application developers and node runners.To achieve that goal quickly as a startup, we used Tendermint to launch our infrastructure stack and reach those goals. Since then, Pocket has grown to process billions of relays, support thousands of applications, and distribute millions in $POKT rewards.Pocket is, effectively, the first-ever generative finance system, where the growth of the protocol is interconnected to its token, usage, and rewards.Our thesis proved correct: Web 3 needed an anti-fragile, decentralized, reliable, and cost-effective solution to link applications and nodes.

A new era for Pocket: v1 Overview

A new chapter is beginning at Pocket, where the quality and scalability of our solution is the priority, helping us to cross the chasm into exponential adoption.Given our tremendous growth in a short time, Pocket became the largest Tendermint network in the market, but now it’s time to move into our own optimized stack geared towards a higher quality of service and scalability.Discover the main changes under Pocket v1.

Utility changes under v1: Scalability and quality with a new actor in the ecosystem

The primary goals of the change in our Utility Module are to increase its efficiency, quality of service, and scalability.We plan to do this by:

• Establishing better and aligned incentives for RPC nodes to work towards the highest service quality possible
• Increasing scalability by maximizing the number of relays the network supports while keeping costs low

How to achieve that quality of service under v1?

Our first approach, under v0, was to establish client-side validation mechanisms, which proved to lack adoption from the community. In 2021, we developed several layer-2 cherry-picking methods through the Pocket Portal as the launching pad for v1.Under v1, we’ll introduce an incentive mechanism directly on-chain, bypassing difficulties and external needs to offer superior quality control.Meet the Fishermen, the on-chain actors making sure quality of service is present 100% of the timeFishermen will be different from apps and servicers, and they will ensure the quality of service based on three standardized areas of control:

• Availability

We’ll introduce time-based sampling, where a null sample is recorded if there’s no signed response from the service provider. Each time this happens, it lowers the availability score for the service provider.

• Latency

Time-based sampling is used to disincentivize high-average latency between providers and applications (due to geographical distance).

• Consistency

Fishermen have to sample all node Servicers in a session at once while comparing the responses and consistency of data.

What about incentives to do so?

Fishermen will be incentivized by quality and not quantity. However, the test score given by Fishermen will impact the rewards for node runners.The rewards for node runners are still based on their output but are divided in proportion to their test scores.Solving the scalability issue with Optimistic Proofs of SamplesWe’re moving from “guilty until proven innocent” to a scenario where optimistic probability comes into place.The total reward pool for node runners will be proportional to the volume of relays performed on aggregate, meaning Fishermen calculate the probability of relay volume instead of calculating one by one.The network can be more scalable by reducing reporting output (e.g., frequency and size of relay proofs) and eliminating the need for Servicers to prove they work. They can focus on delivering the service instead of allocating time reviewing their own work.This new Utility model will come to life with a single DAO-governed Fisherman, with a multi-Fisherman DAO coming in the future. Discover all the phases of the Utility roadmap here.Learn all about the change in Utility under v1 from our recent community call.

Consensus changes: Introducing HotStuff BFT

Until now, Pocket used Tendermint as its Consensus protocol, but version 1 will move to an optimized choice for a consensus that can enable the growth and scale Pocket needs.With v1, Pocket will adopt a HotStuff BFT Consensus instead of a Tendermint BFT.Pocket network relies on the current state of the blockchain to move forward - match Servicers with applications - and the current consensus is not suitable for that model. Under the current consensus, if a block in the chain is fraudulent, the whole chain can continue with the next block until it becomes the “longest chain.” This model causes a reorganization and more confirmations needed, resulting in more time to conduct transactions.With BFT, validators wait before the next block is created, requiring consensus on the next block before moving forward with the chain. The “single state” approach works the best for the new Pocket model. This change leads to other modifications in leader selection processes and transaction validations.

What’s in it for Pocket network users?

By cutting the confirmations needed and time, Pocket can spend less bandwidth, resources, and storage usage, while block rewards for runners will be proportional to the staked amount.Introducing a “structured” Peer-to-Peer module for more efficiencyThe changes to the Peer-to-Peer (P2P) module under v1 work towards the same overall goals of this new transformation at Pocket: ensure efficiency in all processes.The P2P module handles how nodes communicate with each other when new transactions or new blocks are needed.Under v0, Peer-to-Peer models were randomly selected, increasing the capacity necessary to handle the exponential growth in nodes the network will serve. Much of the bandwidth used comes from inefficient processes like retrieving copies of information the nodes have already seen.In version 1, Pocket will introduce “structured communication” for the Peer-to-Peer module. The crucial difference with this model is the significant reduction in bandwidth while maintaining other aspects of the module serving their purpose (e.g., redundancy). Not only for node runners will this be advantageous, but for the entire network, operating in a more effective and scalable manner.The changes under this model have clear goals for the next age of the Pocket Network:

• More peers connected in the network with high efficiency and scalability
• The network’s operability despite breakdowns between nodes
• Effective communication between peers when they join or leave the network.

What enables the P2P module to become more effective?With Pocket’s v1, we had three goals in mind to achieve a better network:

1. The way Servicers communicate to the network when transactions are made
2. How validators communicate with other validators and the network when a block is added
3. Informing archival node of new blocks

Three sub-modules match these three goals under the main Peer-to-Peer module, which will see a change under v1.

• Event Dissemination: how nodes are paired to communicate with each other
• Membership and Churn: knowing when nodes are online or offline
• Transport Layer: Controlling the mechanism that sends and receives messages between peers

Learn more about the technical changes in the Peer-to-Peer module here.Increase speed and data access with the new Persistence moduleThe Persistence module ensures data persists over time, despite any new deployment or changes in the software.Under v0, Pocket used Tendermint, storing the data in Merkle trees, where the roots are included in each block, and the trees are stored as files within each block.Why are we changing the Persistence module? Mainly because of the cost of storage, as it undermines the role of node runners as the underlying force for applications in the network.However, the changes will benefit node runners and anyone interacting with the network, especially on speed and ease of accessing state data.Here are the benefits you can expect from the new module changes:

• Reduce blockchain data storage needs by 80%
• Go from 10+ seconds to milliseconds when querying state data
• Better data portability and more scalability
• More fault tolerance
• Easiness to scale Pocket horizontally

How is this achieved?On the technical side, this change involves introducing a SQL-based Tamper Proof Hybrid Mutable DB and decoupling the persistence layer, among other changes.

A bright future for Pocket

The Pocket v1 implementation is a key moment in our history, and we’re working closely with the community for every actor to understand the differences and start reaping the benefits of this change.To learn more about v1, check our recent community call where we cover all the details:https://www.youtube.com/watch?v=6e3wT5IqFCE