Modules, withdrawals, and decentralization of brc-20
Last updated
Last updated
The modular extension of brc-20 is achieved in the following way:
In the diagram above, we can see that each extension module exists independently of the core brc-20 protocol.
This approach has several advantages for brc-20:
Permissionless Development: Developing new modules for brc-20 is a permissionless process, and new modules start as black modules, being naturally separated from the core protocol and other modules.
Isolated Execution: If there are issues with the implementation of any module, the isolation between black modules ensures it does not affect the operation of the core protocol and other modules.
Consensus Upgrading: When the majority of indexers recognize and implement indexing for a specific module, it can transition to a white module, becoming a natural part of the brc-20 protocol.
However, the modular extension model has a drawback when a module is a black module, as it can not achieve free withdrawals, as illustrated in the image below:
This is because when a module operates as a black module, it means that major indexers do not acknowledge the reliability of its operation. To them, this module is a black box, and its internal state is not recognized as valid brc-20 state. Therefore, the calculated balances are not considered valid brc-20 balances, and assets within this module cannot be freely withdrawn to brc-20.
Imagine if black modules could arbitrarily extend the brc-20 protocol. Developers could create modules like brc20-100x, which would allow users to receive a hundred times the deposited amount. For instance, if you deposited 5 ordi, you would receive 500 ordi. Such unrestricted inflation is unacceptable for the core brc-20 protocol.
Hence, for responsible indexers, all unverified black modules and their internal mechanisms are deemed untrustworthy.
The behavior of a module gradually becomes reliable when it is understood and executed in the real world. This gradual acceptance by more indexers eventually allows its behavior to be considered reliable and transforms it into a white module, becoming part of the upgraded consensus.
Transitioning to a white module means that the balances it calculates are widely recognized and can be securely interacted with the brc-20 main network. In other words, users can safely, freely, and at any time withdraw to the brc-20 main network (as shown in the image below).
The fundamental difference between black module and white module, when compared, is whether they allow users to withdraw freely.
A system that only allows deposits but not withdrawals is unacceptable from a functional perspective.
To address this issue, we conducted in-depth research and were inspired by the matching mechanism in UniSat Marketplace's activities. We dynamically matched User A's deposit request with User B's withdrawal request, allowing the system to use deposit transactions to fulfill withdrawal needs.
The process is illustrated in the image below:
In the image above, User A initiates a withdrawal request of 80 ordi, while User B initiates a deposit request of 20 ordi.
At this point, the system dynamically matches their needs, using User B's 20 ordi deposit to fulfill part of User A's withdrawal request (20/80). User B can continue to wait for other users' deposits to achieve more withdrawals.
When brc20-swap operates as a black module, withdrawal requests can only be satisfied when users deposit assets from outside the module. In other words, if an asset lacks sufficient deposit requests, the corresponding withdrawal requests will be challenging to fulfill promptly, significantly impacting the user experience.
During the early stages of brc-20 development, UniSat provided users with a complete indexing service for transaction and balance inquiries, which led to general centralization concerns:
If the system were to rely on UniSat for rule interpretation and execution, would UniSat possess a form of centralized authority, potentially leading to the brc-20 protocol being controlled by a single development team?
Regarding this question, there are three levels of observation:
Non-mandatory: Indexing primarily involves the analysis and organization of on-chain data to make it more comprehensible to humans, and it depends on the predefined rules of the protocol. It operates on immutable data and has no chance to alter past transactions. UniSat's code for indexing and execution is open source, allowing anyone to inspect it to ensure it aligns with the brc-20 rules.
Competition and Robustness: With the emergence of multiple indexing service providers, there is increased reliability through redundancy. Errors in results from one index provider are more likely to be identified when compared to others. If any single indexer were to cease operations, it wouldn't impact the overall results. In fact, even if all indexers were to stop functioning, brc-20 could continue operating robustly and users would still have the ability to DEPLOY / MINT / TRANSFER as usual. No critical operations rely on indexing support.
Governance and Consensus: Given the participation of multiple indexers in the system, the module mechanism being implemented allows different service providers to effectively learn how to govern and extend the brc-20 protocol in a managable way.
When implementing the UniSat brc-20 indexer, we did not anticipate that other service providers would follow suit. Subsequently, different indexing providers independently began offering indexing services. This process was spontaneous and permissionless, making it a healthy evolution overall. The transition of brc20-swap from a black module to a white module, if successful, will be able to mirror this process.
Within the module architecture, the barrier for service providers to index data is further lowered. In the past, indexers needed to accurately process all network transactions to be considered a valid indexer. Now, indexing data only within their own black module is sufficient to commence providing indexing services, which requires significantly less effort compared to handling all brc-20 data on the network.
Therefore, with the widespread adoption of modules, it's reasonable to expect a substantial increase in the number of indexes, and some services may gradually evolve to offer comprehensive data indexing.
