Conflux

IntroductionWelcome to our first post on the Conflux Developers Medium account! We’re excited to start a series of articles focused on Bitcoin (BTC) Scaling solutions. Our goal is to simplify and explain these technologies, showing how they can make blockchain faster and more efficient.We plan to cover everything from Lightning Network to rollups, sidechains and more, aiming to give you a clear understanding of how each one works, their benefits for speed and cost, and how they can scale. In this post, we will be focused on exploring <a href="https://rgb.tech/" rel="noopener noreferrer nofollow">RGB</a>’s Bitcoin Scaling Solution.Overview and VisionRGB is a cutting-edge smart contract platform that leverages the Bitcoin blockchain to enable the execution of smart contracts. It operates through a paradigm of client-side validation, ensuring that data is stored off the main blockchain and ownership managed with the robust security of Bitcoin scripts. This innovative approach aims to offer an advanced alternative to traditional Ethereum-based smart contract systems.By decoupling the roles of contract issuers, owners, and the evolution of contract states, RGB creates a multi-layered ecosystem that is not only scalable and private but also highly secure for managing digital assets and developing decentralized applications.Quick Scan for RGBIn this section, we’ll focus on the essentials and keep the technical details to a minimum, making the protocol’s workings easy to understand.<h2 id="header-0">The Basics</h2>Unspent Transaction Outputs (UTXOs) are a core concept in the Bitcoin universe. If you’re new to this term, you can dive deeper with this <a href="https://en.wikipedia.org/wiki/Unspent_transaction_output" rel="noopener noreferrer nofollow">wiki entry</a>. For now, let’s keep the explanation high-level.RGB’s design as a smart contract platform is intricately linked with UTXOs. To illustrate, imagine 100 units of an asset being issued on the RGB platform. These assets are then tied to a specific UTXO. When the UTXO owner spends that UTXO, he(or she) can dictate the flow of RGB assets within the transaction (this mechanism known in RGB as ownership). The diagram below provides a visual:<img src="https://miro.medium.com/v2/resize:fit:1400/0*b5C1Ub1xJiEGDs0v.png" />UTXO1 holds 100 RGB assets. Once spent, it transforms into UTXO2 and UTXO3 (indicated by black arrows). The transaction also outlines the transfer of RGB assets (red arrows), splitting the 100 units into 30 and 70 portions, respectively linked to UTXO3 and UTXO4.<blockquote>The RGB contracts are designed for versatility, allowing the logic to be independent of UTXO transactions. This means that the movement of RGB assets isn’t necessarily tied to the spending of UTXOs.</blockquote>Given that a UTXO can only be spent once, any RGB assets associated with it can only be transferred once as well. The security of Bitcoin ensures that UTXOs are safe from double-spending, and by extension, so are RGB assets, safeguarding the integrity of the protocol.<blockquote>This innovative approach is known in the RGB protocol as <a href="https://blackpaper.rgb.tech/consensus-layer/3.-client-side-validation/3.2.-single-use-seals" rel="noopener noreferrer nofollow">single-use seals</a>.</blockquote><h2 id="header-1">Indicating RGB Operations on Bitcoin</h2>To maintain privacy and enhance the capabilities of smart contracts, RGB doesn’t etch operations in plain text on the Bitcoin script. Instead, it submits a hash value associated with the actual operation to the blockchain (referred to as a “commitment”). The RGB protocol’s participants can then validate whether the commitment on the blockchain matches the intended operation off the chain.<blockquote>We won’t delve into the mechanics of how commitments are submitted here. However, it’s important to note that a corresponding commitment value will always be present on the blockchain.</blockquote>This approach ensures that RGB transactions are private. Non-participants of the RGB protocol can only see the following on-chain behavior:<img src="https://miro.medium.com/v2/resize:fit:1400/0*Qt7EYmGbmhsO1len.png" />As the hash value cannot be reversed to reveal the original RGB operation, those not involved with RGB transaction remain unaware of the assets’ existence.Moreover, since only the hash value of the operation is recorded on the blockchain, the data size submitted is consistently small. This approach enables complex off-chain operations while incurring only a minimal cost.<h2 id="header-2">Client-Side Verification</h2>At the heart of RGB’s security lies the submission of hash values to the blockchain. The process of verifying these hashes during transactions is crucial. RGB employs a strategy known as “client-side verification” to maintain the integrity of transactions. All data associated with RGB is stored off-chain, where it is managed by the parties involved in the transaction. These parties are responsible for the transmission of data, and upon receipt, they can verify the transaction’s legitimacy on their local client.Let’s look at a simplified illustration to understand the role of client-side verification (please note: this illustration is not an exact representation of all the intricacies of the RGB protocol).<img src="https://miro.medium.com/v2/resize:fit:1400/0*mDH8XmaPiZ2EN6DC.png" />Using the example from the <a href="https://github.com/conflux-fans/btcl2s/blob/main/articles/en/RGB/rgb-and-rgb-plusplus.md#the-basics" rel="noopener noreferrer nofollow">Basic Operation</a> section, Bob, the owner of UTXO1, wishes to transfer 70 RGB assets to Alice, who holds UTXO4.<ul><li>In the course of the transaction, additional data, data2, is created, and Alice receives all the data from Bob, including data0, data1, and the newly generated data2.</li><li>By examining the RGB data (data0, data1, and data2), Alice can track the status changes of the RGB assets (the blue dotted line).</li><li>Alice then checks for the presence of a hash of the RGB data (data2, data1, etc.) on the blockchain and confirms whether the associated transaction has been validated by the Bitcoin network, thus ensuring the data&#39;s authenticity (the green dotted line). Alice must confirm the validity of all RGB data from the deployment of the contract (corresponding to the on-chain transaction of data0, not depicted in the illustration) up to the most recent transaction. Bob performs an identical verification process upon Alice&#39;s receipt of the assets.</li></ul>The client’s approach to privacy is quite stringent. It’s worth noting that even the original deployer of the RGB contract, without access to data2, would be unable to discern the transaction between Bob and Alice.Trust and SecurityGiven the significance of security, we will discuss the various components of the protocol and applications that users must place their trust in, providing an analysis from the perspective of “trust.”Unless stated otherwise, we assume that the basic cryptographic algorithms used within the protocol are reliable, disregarding the potential impact of quantum computers.Users must trust the Bitcoin network:<ul><li>Transactions on the Bitcoin network should be secure from double-spending; otherwise, RGB assets could also be at risk.</li><li>Bitcoin transactions should remain uncensored; otherwise, RGB transactions might be blocked from being added to the chain.</li></ul>Users should trust the off-chain execution mechanism of RGB, including the virtual machine and the design of smart contracts. RGB assets are linked to UTXOs, and while only hash values of RGB operations are submitted to the blockchain, there is no direct interaction with Bitcoin scripts. Consequently, the blockchain cannot confirm the validity of RGB transactions in any way. If the off-chain execution mechanism encounters an error (such as a coding mistake in the engine or a flaw in the contract logic), it could result in the creation of invalid states off-chain or a discrepancy between the submitted hashes and the actual RGB status. In such cases, once the UTXO transaction is spent, the state in the user’s possession may not be verifiable, potentially leading to a loss of assets.The RGB protocol minimizes the trust required from users. Users can independently verify nearly every aspect of the protocol to ensure its proper functioning. However, this also imposes certain responsibilities on the users that they need to perform quite heavy data storage and verification locally.<h2 id="header-3">Virtual Machine</h2>RGB has developed a Turing-complete virtual machine known as <a href="https://www.rgbfaq.com/glossary/aluvm" rel="noopener noreferrer nofollow">AluVM</a>, enhancing its capabilities.<h2 id="header-4">Scalability</h2>RGB transactions are tied to Bitcoin transactions, which can affect the system’s throughput. To address this, the <a href="https://www.rgbfaq.com/glossary/bifrost" rel="noopener noreferrer nofollow">Bifrost protocol</a> has been introduced as an enhancement to the Bitcoin Lightning Network, facilitating RGB payments through the network.<h2 id="header-5">TVL</h2>Given the privacy features inherent in RGB, tracking Total Value Locked (TVL) is not feasible with current methods.RGB Overview: Pros and ConsPros:<ul><li>Privacy: RGB submissions on the chain are limited to hashes, ensuring transaction privacy through a system of client-side verification. Only the parties involved in the transaction have access to its details.</li><li>On-chain costs for complex contracts: Since only hash values are submitted to the chain, the associated on-chain costs are decoupled from the complexity of the contract.</li><li>Trust: The protocol demands minimal additional trust; users have the means to verify nearly every aspect of the protocol.</li></ul>Cons:<ul><li>Data storage: Users are responsible for storing RGB data associated with their transactions. If this data is lost, it can result in the loss of assets.</li><li>Transactions necessitate coordination among multiple parties. If a party is offline, the transaction cannot proceed, complicating client design.</li><li>High verification costs: With each transaction, clients must perform state verifications. As transaction volume grows, the associated verification burden can become significant, potentially increasing local storage requirements or network costs when interacting with RPC nodes or other services.</li></ul>These challenges associated with RGB can increase the complexity of client development and raise the barrier for user adoption.More DetailsIn this section, we will delve into aspects of the protocol that are less critical but still important for readers who wish to understand the technical intricacies.<h2 id="header-6">State Machine Replication and Off-Chain Computing Engines</h2>A fundamental challenge in blockchain technology revolves around ensuring that all nodes maintain a consistent ledger. We’ll begin by discussing a widely adopted approach known as “state machine replication”, which is used by Bitcoin and other blockchains to achieve fault tolerance. This method is extensively utilized in distributed systems to address the issue of consistency across multiple copies. For instance, both distributed databases and blockchains operate based on this principle. The process is straightforward:<ol><li>Each copy is initialized as a specific state as the starting point.</li><li>State transitions occur as follows:</li></ol>i. Before receiving new input, the state of each copy remains unchange.ii. Upon receiving input i in state s, the copy moves to a new state s&#39;. This transition is deterministic, meaning that given the same input i and state s, the resulting state s&#39; will be consistent across all copies.3. By ensuring that all copies begin with the same initial state s0 and process the same inputs (i0, i1, i2...in) in the same order, their final states will align.In the context of Bitcoin, we refer to this “state” as all the Unspent Transaction Outputs (UTXOs) within the system.<ol><li>Every Bitcoin node begins with the genesis block as its starting state.</li><li>State transitions are handled as follows:</li></ol>i. The ledger’s state remains unchanged until a new transaction (block) is received.ii. Upon the reception of a new transaction (block), the ledger transitions to a new state. This process is deterministic; given the same ledger state and transaction (block), the resulting ledger state will be consistent.3. By following this method, as long as all nodes start with the genesis block and process transactions (blocks) in the same sequence, their respective ledger states will eventually match.The key challenge lies in ensuring that all nodes agree on the order of transactions (blocks), which is the essence of consensus and the foundation for preventing double-spending attacks in blockchain.The off-chain computing engine of RGB leverages Bitcoin’s consensus mechanism to maintain the order of transactions, thereby preventing double-spending. States and transitions are managed off the main blockchain. This approach has the advantage of separating the execution layer from the consensus layer, allowing for functional expansion without the need for blockchain upgrades. However, this also means that the consensus layer does not perform logical validation during transactions. If the data submitted to the blockchain conflicts with the logic of the off-chain transaction engine, the transaction will not be rejected, potentially leading to asset loss. Some may argue that RGB is “parasitic” on Bitcoin, but it can also function on other blockchains that use UTXOs.Protocols like Inscription and Rune follow a similar model but face the additional challenge of a lack of standardized implementation in the ecosystem’s early stages. With different implementations of off-chain execution engines (indexers), verifying the results can be difficult.<h2 id="header-7">Commitment Schemes</h2>Commitment schemes are cryptographic concepts that allow an individual to commit to a value, hide it initially, and later reveal it. These schemes have two fundamental properties:<ul><li>The committed value corresponds to a SINGLE original value. In RGB, a commitment on the blockchain corresponds to a unique operation, ensuring that double-spending is prevented. This property is known as binding.</li><li>It is impossible for others to deduce the committed value from the commitment. In RGB, observers cannot determine the specific operation associated with a commitment on the blockchain, preserving privacy. This aspect is referred to as hiding.</li></ul>Hashing is a frequently used technique for designing commitment schemes. For example, the Merkle Tree, a well-known concept in blockchain technology, is a type of commitment scheme. Commitments are also commonly used in other blockchain applications, such as the two-stage registration process in ENS, which helps prevent others from front-running to register domain names.<h2 id="header-8">Proof of Publication</h2>A concern in RGB’s client-side validation could be that transaction participants may not have access to the overall state of assets. For example, while Bob may hold 100 assets, there could be 200 assets in circulation. How does the system ensure that contract execution does not lead to issues under such circumstances?RGB addresses this issue with a concept known as “proof of publication”. The central idea is that state verification in distributed systems does not require global execution by all participants. Instead, it involves the relevant parties verifying specific state transitions. In this approach, state transitions are not broadcast globally but are encoded into a brief cryptographic commitment once the involved parties acknowledge the change (e.g., through signatures). As illustrated in the diagram below, while contract G’s overall state includes all red and gray nodes (representing historical transactions), verifying the state of node P only requires examining the relevant red nodes.It’s important to note that this design also imposes certain requirements on the design of smart contracts.<img src="https://miro.medium.com/v2/resize:fit:1400/0*qLiN6utV5Y7Upsum.png" />

Exploring Bitcoin Scaling Solutions: RGB

Table of Contents

Conflux Network

Other articles published on Apr 17, 2024

This Is How Nearly 1 Billion Polygon (MATIC) Will Witness Profits

Cardano Sees Decline in Network Activity and Fee Reductions

Top Trending Cryptos on Solana Chain Today – Cheems, Megapix, Andrea Von Speed

Bitcoin Halving Hysteria: Will History Repeat Itself Or Are We Heading For A Market Meltdown?

Pups (Ordinals) Price Prediction: PUPS Pumps 25% As Traders Jump To This 2.0 Meme Coin For Its 10...

Merlin Chain Secures New Investments Co-led by Spartan Group and Hailstone Labs to Empower Bitcoi...

Join our free newsletter for daily crypto updates!