Potential future issues under the current Blockspace mechanism:
For appchains with lower activity(long-tail appchains), the cost of purchasing blockspace may create an imbalance of value compared to the transactions they need to package, i.e., a lack of efficiency in fund utilization.
It may feel something like this: I spent $1 to purchase blockspace, and then only loaded transactions worth 10 cents.
In order to prevent a lack of fund utilization efficiency, lightweight appchains might be inclined to wait until the transaction value on the platform reaches their expected threshold. However, this waiting could impact the user experience of these appchains, as users would need to wait for a certain number of âfellow travellersâ to arrive before their transactions can be processed.
A possible solution:
I want to discuss a mechanism here that could solve the either-or problem of fund inefficiency or poor user experience for these long-tail appchains. By utilizing the Tanssi network to implement a Roll-up mechanism combined with blockspace, Polkadot could provide fast and inexpensive blockspace services for a large number of long-tail appchains.
The main difficulty in implementing Roll-up lies in the security mechanisms of the economic and game models, with ZK and OP using two different gaming methods to achieve their Roll-up implementations.
By introducing the Tanssi network, I believe it can effectively solve the issue of transaction gaming and economic model stimulation on Polkadot. Since the Tanssi network has its own governance and collateral models, the selection of its collators is itself a process of election through certain thresholds. Combined with the Tanssi networkâs penalty mechanism, the honesty and fairness of the underlying transaction collectors can be greatly guaranteed (similar to Polkadotâs shared security mechanism, which shares the integrity of nodes).
Having solved the node integrity issue, this provides a potential basis for appchain pre-mining. These appchains can set a custom block output mode that allows them to ignore the block rhythm of the relaychain and pre-produce a certain number of blocks. Then these blocks can be bound through block header data or timestamps, etc., to generate a Merkle tree, batch process this block information, and Roll-up it into a final state.
Finally, the relaychain accepts this final state and uses blockspace/coretime to process this final state, anchoring the final state of the appchain to the relaychain to obtain the final block data security.
For subsequent node information synchronization and verification, any node can start to verify the authenticity of block information according to the order of Merkle tree data recorded in the relay blockspace. That is, according to the sync block information block height, block timestamp, and block hash, to judge whether these blocks belong to the data set of this root and whether the order is reasonable, thereby realizing block re-synchronization.
The benefits of this approach:
This method allows long-tail application chains to enhance their fund utilization efficiency and reduce their usage costs while obtaining flexible and rapid user services, eliminating the need for either-or decisions. It makes Polkadot application chains easier to promote.
Possible extended issues:
Finally, in order to prevent system risks from reducing and to avoid overloading the blockspace provided by the core (excessive computational load in a single service), the compression rate of roll-ups should also be limited, restricting the number of blocks provided by Roll-up. Moreover, economically speaking, the block space handling Roll-up should have a certain cost increase (based on the roll-up ratio).
Of course, there might be some aspects I havenât thought of yet, which can be discussed further in here.