⌛Consensus Solutions
An overview of three potential methods of consensus and governance
This section delves into the complex world of Ordinals and the scalability and consensus challenges the technology is currently facing. We will examine three different strategies to tackle these issues:
Building a custom Layer 2 solution from scratch
Leveraging the Lightning Network's Layer 2 capabilities
Forking the open-source Hashgraph project
Introduction
At the moment, Ordinals is seeing insane volume with NFTs and BRC-20 tokens but it is plagued by scalability and consensus issues. Transactions are largely determined by a single entity leading to inefficiencies in block sensing, inscription numbering, and ownership validation. This paper aims to present solutions to these issues, underpinning the need for a decentralized consensus mechanism and transparent operations to replace the current centralized system.
Problems and Possible Solutions
To enhance adoption and scalability, the following problems need to be addressed:
Centralized consensus & source of truth
Speed of transactions
Cost of transactions
No standardization process
The most important aspect for the sustainability of Ordinals as a protocol is to establish a viable method of consensus and transparency, allowing the protocol to evolve into a system that doesn't require trust in any centralized entity.
For standardization information, see the Standardization Proposal page.
Consensus Mechanisms
Marketplaces largely rely on Unisat.io's indexer to determine ownership and past transactions, creating a single source of truth. I believe there's three major solution paths to building a decentralized replacement:
Building a Layer 2 from Scratch: This would involve creating more indexers and developing Ordinals own consensus mechanism. However, this could be slow and inefficient, potentially leading to infighting over conflicting ideologies.
Forking Lightning Network: This involves creating a system like the Lightning network based on the Ordinals protocol. This might not solve issues of BTC clogging from transaction load, potentially still leading to scalability issues.
Build Hashgraph of Inscribers / Validators: This option of an L2 would use a fork of another blockchain or hashgraph (I'd suggest hashgraph but I am bias). A DAO could be setup to validate transactions and write to the L2 as truth.
Let's go over these options with more detail about what would have to take place for each of them to be successful, along with some potential challenges for each solution.
1. Building a Proprietary Layer 2 for Ordinals: A Blueprint
Creating a Layer 2 solution specifically designed for Ordinals is an ambitious and complex task, given the lack of existing structure, standards, and consensus mechanisms. However, if approached methodically, it can yield a powerful, customized solution that addresses Ordinals' unique needs. This section outlines a high-level approach to building a Layer 2 solution from scratch.
Preliminary Considerations
Before diving into the technical development, it's crucial to establish the Layer 2's goals, which will guide its design and implementation. For Ordinals, these objectives might include:
Improving scalability by reducing transaction times and costs
Enhancing security to prevent attacks and ensure asset integrity
Facilitating better consensus that is decentralized and trustworthy
Building a Proprietary Layer 2: Key Steps
Designing the Architecture: The initial step involves planning the architecture of the Layer 2 solution. This involves outlining how the network nodes will interact, how transactions will be processed and validated, and how the Layer 2 will interact with the main Bitcoin blockchain.
Establishing Consensus Mechanism: A consensus mechanism that ensures transaction validity and network security needs to be implemented. This could be based on existing consensus algorithms (like Proof of Stake or Proof of Work) or be a completely novel approach tailored to Ordinals' requirements.
Developing Network Nodes: Network nodes will need to be developed to propagate transactions, reach consensus, and maintain the network's decentralized structure. The current indexers could transition to become these network nodes.
Incorporating Security Measures: Layer 2 will need to have robust security measures in place to prevent double-spending, front-running, and other types of attacks. This might involve transaction verification procedures, cryptographic security measures, and more.
Integration with Bitcoin: A critical aspect of the Layer 2 solution will be its interaction with the Bitcoin blockchain. This might involve mechanisms for transferring assets between the main chain and the Layer 2, possibly using wrapped BTC or similar solutions.
Implementing Governance: Finally, a governance model will be required to manage the Layer 2 solution, make decisions about its future development, and resolve disputes. This could involve a Decentralized Autonomous Organization (DAO) or similar decentralized governance structure.
Potential Challenges
Building a Layer 2 solution from scratch comes with several challenges:
Technical Complexity: Developing a Layer 2 solution requires significant technical expertise and resources, especially when starting from scratch and already in production.
Time Consumption: It could be a slow process, as everything from consensus mechanisms to governance structures needs to be built from the ground up.
Potential for Conflict: There might be conflicting ideologies within the community which could lead to infighting and slow down progress.
Despite these challenges, a custom Layer 2 solution could offer significant benefits by being tailor-made to suit Ordinals' specific needs and characteristics. It would require a dedicated and skilled team, a clear vision, and strong community support to become a reality.
2. Forking the Lightning Network: A Technical Approach
Forking the Lightning Network to work with Ordinals entails creating a system that operates like the Lightning Network but is based on the Ordinals protocol. This section provides a high-level overview of how such a fork might technically function.
Overview
The Lightning Network is a Layer 2 solution for the Bitcoin network that facilitates fast, cheap transactions. It achieves this by creating off-chain payment channels between parties. These channels allow for multiple transactions to be made between the parties without needing to record each transaction on the Bitcoin blockchain. Only the opening and closing transactions of the channel are recorded on the blockchain, saving time and transaction fees.
Forking Process
Source Code Acquisition: The first step to forking the Lightning Network would be to obtain the source code. The Lightning Network is open-source, meaning its code is freely available for use and modification.
Code Modification: The next step would be to modify the code to work with the Ordinals protocol. This could involve changing the way transactions are formatted and validated to conform to the rules of the Ordinals protocol.
Payment Channels: Just as in the Lightning Network, off-chain payment channels would be created between parties in the Ordinals network. These channels would allow multiple transactions to occur off-chain, increasing the speed and reducing the cost of transactions.
Consensus Mechanism: The forked Lightning Network would need to implement a consensus mechanism that aligns with the Ordinals protocol. This could involve validators, similar to the indexers in the Ordinals network, who validate transactions and maintain the integrity of the network.
Network Nodes: Network nodes would need to be set up to support the forked Lightning Network. These nodes would communicate with each other to propagate transactions across the network, ensure consensus, and maintain the network's decentralized nature.
Integration with Bitcoin: One of the key features of the Lightning Network is its close integration with the Bitcoin network. Similarly, the forked Lightning Network would need to have a mechanism for interacting with the Bitcoin network, such as through the use of wrapped BTC or other pegged tokens.
Potential Challenges
While forking the Lightning Network might seem like a promising solution, it could still potentially face the issue of Bitcoin's transaction load clogging the network, leading to scalability issues. Moreover, creating and maintaining a fork of the Lightning Network would require a significant amount of technical expertise and resources. It would also be essential to ensure that the forked network is secure and resistant to attacks, which could pose additional challenges.
3. Leveraging Open Source Hashgraph for Ordinals: A Consensus & Minting Approach
Hashgraph is a distributed ledger technology (DLT) that offers an alternative to blockchain. It's known for its speed, security, and fairness in transaction ordering. The following section outlines a high-level technical approach to how Ordinals could utilize open-source Hashgraph technology for consensus and minting.
Overview
Hashgraph utilizes a consensus algorithm known as the Gossip about Gossip combined with Virtual Voting to reach consensus quickly and securely. This consensus mechanism is Asynchronous Byzantine Fault Tolerant (ABFT), making it more secure than blockchain which typically uses Synchronous Byzantine Fault Tolerance. Hashgraph is a Directed Acyclic Graph (DAG), which gives it the advantage of reaching consensus with front running and sandwich attacks being nearly impossible.
Implementing Hashgraph
Forking Hashgraph: The first step is to fork the open-source Hashgraph. Forking allows Ordinals to create a new network based on Hashgraph's source code, tailoring it to the specific needs of the Ordinals protocol.
Incorporating Validators: In the new network, inscribers in the Ordinals network would become validators, similar to the nodes in a Hashgraph network. These validators would validate transactions and ensure consensus in the network.
Token Minting: The forked Hashgraph could be used for minting NFTs and other tokens directly on Layer 2, which references the inscription on the BTC blockchain as truth to fully tokenize the assets. This process would allow Ordinals to benefit from the speed and security of Hashgraph while maintaining the integrity and immutability of the BTC blockchain.
Staking Mechanism: To further secure the network and incentivize validators, a staking mechanism could be introduced. For example, a BRC-20 token could be allocated for staking to validators as proof of stake.
Transaction Rollups: To maintain a link with the BTC blockchain, transaction rollups could be written back to the BTC blockchain, providing proof and validity of ownership on the BTC chain.
Benefits of Hashgraph
Implementing a Hashgraph-based solution would offer Ordinals several advantages:
Speed: Hashgraph is known for its high speed, allowing for thousands of transactions per second.
Security: Hashgraph's ABFT consensus mechanism offers robust security, making it more secure than Ethereum's blockchain.
Cost-efficiency: Transactions on Hashgraph are relatively cheap, which could reduce costs for Ordinals users.
Fairness: Hashgraph's consensus mechanism ensures fairness in transaction ordering, which could prevent front running and other types of attacks.
Potential Challenges
While Hashgraph presents many advantages, there are also potential challenges to consider:
Adoption: For the network to be stood up and decentralized, adoption will be required. This could be achieved through incentives such as a pool created by miners to encourage validator creation.
Conversion to Wrapped BTC: Converting BTC to wrapped BTC on the new L2 would be a point of friction and potential point of attack.
Implementing Hashgraph in the Ordinals protocol could be a forward-thinking approach that brings benefits in terms of quick consensus, cheap fees, high security, and flexibility. It is a solid solution that could solve many of the issues currently facing the Ordinals protocol.
My bias leans towards the last solution, where inscribers fork an existing consensus mechanism and build a Layer 2 with inscribers becoming validators and staking to validators as POS which would create trust in the network.
Hashgraph would be a superb technology to adopt, though the most important determining factor for the consensus mechanism selected should be be what is most fully embraced by the ordinals community.
Governance Model
Regardless of the method chosen, the governance model will be crucial for trustless execution and best decentralized practices. A system that replicates the Bitcoin Whitepaper and current miners could make sense for conforming to the BTC model on the L2. The Lightning Network may also serve as a source of inspiration for governance and standards setting.
No current process for the submission of standards exists. This is greatly needed to solidify coding practices.
Ordinals will not be able to grow as a technology without clear guidelines and process for contributing development work and proposing fixes and updates. Tweet threads were the seeds, solid foundations are now needed for them to grow.
Last updated