The purpose of writing this article is to reflect on the gradual decentralization of Polkadot, which, in a sense, means that the community can decide “what Polkadot is.” I feel it’s necessary to share my vision of Polkadot.
In my view, Polkadot represents foresight, embodying the future world. I still vividly remember the spectacle when Dr. Gavin Wood demonstrated creating a blockchain in just fifteen minutes. To me, Polkadot signifies the pursuit of technological excellence, which is evident throughout the Polkadot community.
Of course, this is just my perception, and you may differ. However, I firmly believe that if we overly focus on concepts like block space, Rollups, L2, and DeFi, we won’t discover the truth. Instead, it will only dilute Polkadot’s forward-thinking nature. We should ponder what blockchain will look like in the next three years or what it ideally should be. Let’s erase those terms from our minds and start from scratch in designing blockchain.
Domainized Blockchain
So far, all monolithic blockchains are tightly coupled, and modular blockchains seek scalability within a tightly coupled system, which is architecturally contradictory. We aim to completely decouple blockchain, where each module is responsible for a specific type of task. It’s important to note that this is different from the architecture of frameworks like Substrate. Instead, it views the entire blockchain ecosystem as a single product.
Firstly, we need a state machine module, which you can think of as a node or a parachain, depending on your perspective. It accepts external inputs and changes its internal state. With numerous state machines and by the definition of blockchain, we require a module called consensus, which achieves consensus for the global state machine. As the state machine handles more and more data, leading to a state explosion, we no longer retain the complete state but instead place it into a data availability layer. This layer is akin to a computer’s memory, loading data when needed for computations and then freely discarding it. Of course, we also need a module for historical data storage, which requires only 1/Nth of the security. These modules form the infrastructure and domain layers of the blockchain.
Above this is the application layer, orchestrating different infrastructures and domains to accomplish actual business operations. We couple them through a message queue service. The message queue service obviously includes cross-chain protocols like XCM, and in fact, Polkadot, Bitcoin, etc., can also provide reliable message queue services. On top of this, we build a rich array of applications (Dapps) that are user-facing. The architecture is illustrated below:
Global Security
This is a very simple yet common architecture, especially if you are familiar with DDD. However, implementing this on blockchain is not easy. The crucial question is, compared to monolithic blockchains, how can loosely coupled domainized blockchains ensure security?
We need to add a definition of global security for the modules in a domainized blockchain: the system’s security should not be compromised by adding a module. Parachains sharing the security of the relay chain meet this requirement; Rollups inheriting the security of L1 also meet this requirement; another special module is the DA layer, where you don’t need to trust the validators of the DA layer itself, hence not impacting the system’s security. When a module meets this definition, we can say it has global security. This is a vital concept, indicating who can be a module in a domainized blockchain.
Application Layer Restructuring
The domainized blockchain is extremely flexible, and it will give birth to many blockchain paradigms. It’s hard to predict the future, but we can re-examine current design mechanisms. Rollup, closely resembling this concept, has gained widespread application due to its “inheritance of L1 security.” Rollup is a vast topic, but we will discuss one aspect: if we decouple the DA layer, in other words, Rollups built on Ethereum use a third-party DA, how to ensure data availability on Ethereum and maintain comparable security? Unfortunately, there is no satisfying solution yet.
We encounter the same problem when trying to expand inscriptions. Inscriptions are a very elegant design, essentially using L1 as a message queue, allowing all nodes to reach consensus without communication. However, its downside is also apparent; the message layer can only convey limited information, greatly limiting the scalability of inscriptions. For instance, we cannot deploy smart contracts (unless we trust a third party).
From the perspective of domainized blockchain, we can expand inscriptions while retaining their original appealing characteristics. We store data in the DA layer, and the message layer only needs to transmit data pointers. All nodes, after verifying data availability from the DA layer, download and run the data.
However, the DA layer can only guarantee data availability for a specific period (usually just one or a few blocks). All nodes can reach consensus on data availability through sampling only within this period. This introduces a type of long-range attack mode, where the adversary first hides the data, making it unavailable, and then releases it, causing later nodes to get inconsistent results.
To achieve consensus on data availability among all nodes, we call upon the consensus mechanism. Assuming Polkadot is aware of the data availability layer information, inscription participants first obtain data availability from Polkadot. If available, they download data from the DA layer; if not, they discard the message. Thus, we only need a simple message to deploy a smart contract:
{“create” : “melodot-12758”, “start” : “781”, “end” : “913”}
Furthermore, we could use Substrate to write a “parachain”, packaging multiple “externals” into the DA layer and transmitting pointers through the message queue. This gives birth to another operating mechanism for “parachains”, and we can operate the EVM similarly. In fact, this is no longer an inscription. You can also understand it as a type of Rollup without a settlement layer – a completely new design.
We can even go further. Through this method, we can even run another Polkadot, thereby obtaining a “recursive Polkadot.” Of course, this is a radical imagination and belongs to another topic.
Global Consensus Engine
In the previous section, we treated Polkadot as a consensus engine with global security. However, to ensure the scalability of each module, we need zero-knowledge leakage, meaning the consensus layer should not be aware of the DA layer’s existence. A naive solution is to synchronize data availability to the parachain through a DA bridge, thereby indirectly providing Polkadot with DA capabilities. But in this case, the system’s security depends on the bridge’s security, usually much less than the consensus layer’s security.
This doesn’t meet our definition of security for a domainized blockchain. We adopt another mechanism: re-staking. Theoretically, attacking the re-staking layer requires attacking the original consensus layer (in practice, it’s much more complex, but that’s another topic), thus obtaining a module with security approximating that of the consensus layer, essentially an adapter for the consensus module.
It’s essential to note that this is entirely different from the EngineLayer concept. EngineLayer allows validators to voluntarily run different tasks, some of which are heavy, like storing data as the DA layer itself. Its security is local, meaning: this task has a 1000 ETH stake, not: its security approximates the original consensus layer.
To achieve security close to the consensus layer, the re-staking layer needs to be designed light enough, and only cross-domain tasks can join. This allows us to better utilize validators’ idle resources and attract more validators.
More importantly, the underlying EngineLayer still requires some consensus, and this consensus’s security cannot approximate Ethereum itself. Fortunately, Polkadot’s shared security provides this capability, which is why Polkadot is the only choice as a global consensus engine.
Once we accomplish all this, the blockchain architecture changes. It’s no longer fragmented communities like Bitcoin, Ethereum, Polkadot, etc., but rather Bitcoin, Ethereum, Polkadot, or other chains as the message layer, a certain chain as the DA layer, a decentralized storage as the storage layer, etc.
Remember, the global consensus engine is not only important for Polkadot but for the entire blockchain. The following diagram shows Polkadot’s position in the future blockchain ecosystem:
- Message Queue: Bitcoin, Ethereum, and Polkadot itself can all serve as reliable message queue service layers, as well as the XCM protocol, cross-Rollup protocols, etc.
- Re-staking: A special type of parachain, acting as an adapter for Polkadot, enabling the consensus engine to communicate with the DA layer.
- Application Layer: Includes parachains themselves, orchestrating domain layers for various purposes. For example, a Rollup can use Ethereum as the settlement layer or a Polkadot parachain as the settlement layer, and obtain DA through the re-staking layer.
- Consensus Engine: Achieves consensus for various states, not concerned with the content of the consensus.
Discussion
- Under the concept of Domainized Blockchain, we have already built a data availability layer and are in the process of constructing a re-staking layer. I would like to hear the community’s thoughts on whether they prefer the core team to develop the re-staking module as part of the system chain. Is there a corresponding timeline for this? However, I believe that there are multiple design options for re-staking, and a market-oriented approach is more appropriate. Therefore, regardless, we will initiate the development of re-staking.
- From a market perspective, is the term “Domainized Blockchain” fitting and easy to understand? Similarly, is “Global Consensus Engine” an appropriate expression?