Polkadot is releasing updates at an astonishing speed. We may think that this is the best way to add value: more features + optimization = more value. But does this logic still hold true?
Where does the value of Polkadot lie? The value of Polkadot lies in the willingness of parallel chain teams to build their businesses on Polkadot instead of choosing other platforms. Furthermore, there is hope to attract more excellent teams in the future.
Therefore, it is crucial to retain existing teams and attract new parallel chain teams. But how can we achieve this goal? I believe the key lies in creating value for them. This may sound simple, but it actually means that our decisions need to be guided by their business needs.
Ultimately, whether the value we provide is recognized largely depends on how we deliver that value.
What is our value proposition? Polkadot offers a pathway to resource access, which is referred to as “core time” or “block space”. Polkadot demonstrates its unique value by providing this resource to parallel chains.
In this process, Polkadot can adjust the allocation of this resource in multiple dimensions. The services we currently provide can be summarized as follows:
[Image]
Feedback collected by Parity from parallel chain developers indicates that this provisioning method does not meet their needs. Our services often introduce significant changes to their production code, whether for optimization or new features.
However, these significant changes are not without cost. Every time there is a major change, parallel chain teams evaluate the following factors: the opportunity cost of missing new features, the development cost of integrating the changes, and the risk of downtime due to code errors.
It has been proven that development costs and downtime risks are almost always higher than the opportunity cost of missing new features. This is a purely commercial observation. After all, parallel chain teams operate as economic entities.
New features are good, but if their benefits are not sufficient to outweigh the risks, what is their value? I believe that the content we provide should be more like the diagram shown below:
[Image]
That is, prioritize stability over development speed, ensuring that teams can more easily build businesses on Polkadot. They can trust Polkadot and not be frequently disrupted by new development decisions.
Making choices is indeed difficult, but this is also the decision that the Polkadot community ultimately needs to make. Other ecosystems that better meet the needs of developers are more than willing to embrace our “lost talent”.
Polkadot as a product
Polkadot’s development has so far mainly focused on the technical aspects. But to maintain its competitiveness, we need to shift our thinking and think more from a business perspective: what do parallel chain teams need? How can we help them stay profitable? How can we ensure they stay on Polkadot?
We must delve into these questions before making our development decisions.
Looking to the future
This is not only Parity’s task but also the collective task of all developers in the ecosystem.
However, Parity has set three goals to reduce the maintenance and integration costs of parallel chain teams: parallel chain full nodes, release process, and runtime integration testing.
But this may still not be enough. If you are a parallel chain developer, please provide more suggestions to make building on Polkadot easier.
Parallel chain full nodes
The Polkadot SDK provides a wide range of functionalities and interfaces. We have released approximately 380 crates (packages or libraries in the Rust programming language), which are considered interfaces for developers, making it difficult for parallel chain teams to ensure that they are using the correct versions or integrating updates correctly.
These were done for customizability. But in reality, only a few parallel chain teams truly need this level of customizability. For most teams, having a “normal use” node is sufficient.
Parallel chain full nodes aim to be a generic node that can be used for any parallel chain (as long as it does not rely on custom changes).
This can greatly reduce the number of interfaces we provide to developers and abstract away a lot of complexity.
What do parallel chain teams think about this?
New release process
We currently release three things: Polkadot SDK libraries (crates), relay + para nodes, and runtimes.
All of these are closely related to parallel chain developers. In order to introduce more stability, Parity proposes setting a 3-month long-term support (LTS) release cycle for SDK and node software. This means that major updates will only occur every three months. For details, please refer to: [link]
During this period, there will still be small version updates for bug fixes.
Since runtimes are managed by Fellowship, they may or may not follow this practice.
To make this not just an internal project list but a successful project, we need to confirm with parallel chain teams whether this meets their needs.
What do parallel chain teams think about this?
Runtime integration testing
Distributed systems are complex, and integration testing is unavoidable. Parity is currently hiring for this purpose.
Our idea is to establish an end-to-end parallel chain integration test (similar to [link]) to test before releasing runtime changes.
We hope to discover and resolve more cross-chain message (XCM) vulnerabilities, at least before these vulnerabilities affect production networks. If you want to participate in the discussion of this article, please feel free to share your opinions on the forum: [link]
For how to participate in the forum discussion, please refer to our guide: “How to Participate in Polkadot Discussions: Polkadot Official Forum Usage Guide”
