Bitcoin Smart Contract Evolution RGB-Driven Web3 Revolution

Bitcoin Smart Contract Evolution RGB-Driven Web3 Revolution

Author: Infinitas; Waterdrip Capital; viaBTC Capital; Technical Support: Li Ning; Hong Shuning

Web3 technology has undergone vigorous development for more than a decade, giving rise to various levels of innovation. Bitcoin, while maintaining its decentralized nature and security, continues to enhance its privacy protection capabilities. It has achieved advanced features such as Schnorr signatures and Taproot, laying the foundation for subsequent technological innovations. At the same time, the evolution of on-chain smart contracts, represented by Ethereum, has given birth to the golden age of blockchain applications (such as DeFi), bringing about two bull markets. However, since 2022, the innovation in the Web3 industry has suddenly lost direction, and blockchain technology has always been unable to break free from the constraints of the impossible triangle, leading to the failure of large-scale blockchain applications. So, have we reached the limits of technology? Are there still deeper unknown territories waiting for us to explore? Perhaps, it is in the process of exploration that the Bitcoin Layer 2 protocol RGB is quietly waiting for the right moment, gradually maturing, to challenge the existing technological limitations and shine brightly.

Bitcoin: Establishing its position as the currency layer

The biggest difference between Web3 and Web2 lies in its built-in economic system, and any economic system is based on currency as its foundation, with protocol layer and application layer above the currency layer. The currency of Web3 is called cryptocurrency, which is issued through blockchain.

• Changtui The NFT market will recover, and we will usher in another epic, anti-gravity NFT bull market.
• Grayscale won, but not completely SEC can still reject BTC ETF
• Interview with Circle CEO by Fortune What role does stablecoin play in the cryptocurrency market?

Due to several key factors, Bitcoin is recognized as the most secure and stable cryptocurrency, and its value has gained global consensus:

Firstly, the Bitcoin network covers the whole world and has over 10,000 full nodes. These nodes work together to verify and record transactions. This decentralization makes it difficult for attackers to tamper with transaction history. Secondly, Bitcoin uses powerful hash computing power as proof of work mechanism, which is the cornerstone of network security. In block validation and mining, the consumption of large amounts of computing power makes it difficult for attackers to control the network. In addition, Bitcoin’s consensus rules have not undergone major changes in history, and this stability helps maintain network consistency and security. Compared to other blockchain projects, Bitcoin’s consensus rules are less susceptible to radical changes. The Bitcoin community pays close attention to network security and stability, focusing on the security of the core protocol. Modifications to the core protocol are carefully discussed and tested to ensure network stability. In short, Bitcoin is recognized as the most secure and stable among many blockchains, and it becomes the preferred choice for the currency layer of Web3 with its outstanding decentralization, consensus mechanism, stability, and community attention.

Bitcoin script: Ensuring security and simplicity in parallel

As an important role in the foundational currency layer of the Web3 world, Bitcoin’s script system is particularly worth noting during the gradual evolution of the core protocol through careful discussion and testing. The original intention of the Bitcoin script language is to ensure security and avoid potential risks, so it deliberately limits functionality while maintaining simplicity and security similar to chip instruction sets. The Bitcoin script is an execution language based on reverse Polish notation and stack-based. This script is designed to be executed on limited hardware.

In the mainstream Bitcoin node code, developers have placed some restrictions on the executable script types, only allowing certain types of transactions known as “standard scripts” to be executed. The most important of these is the P2SH (Pay to Script Hash) transaction, which actually allows any Bitcoin script to be executed, making it possible to execute scripts with certain complex functions on Bitcoin. For example, the Lightning Network has become the de facto standard for small, high-frequency Bitcoin payments.

With the introduction of the Schnorr signature proposal and the Taproot soft fork upgrade, Bitcoin has taken an important step, marking a significant milestone. This allows Bitcoin to better support the development of layer two protocols and further enhances its role in the future Web3 world.

Focus on Schnorr Signature and Taproot

Behind Schnorr signatures and Taproot, there are a series of technological innovations that create new opportunities for Bitcoin. First, Taproot introduces more flexible payment channels, allowing multiple types of transactions to be executed on the chain in a more privacy-protecting manner. By hiding complex multi-party signature scripts in a single script, Taproot makes various complex transactions appear as regular single-party payments, thereby enhancing privacy and security. The introduction of Schnorr signatures makes transactions on the Bitcoin network more compact, reducing transaction fees and improving scalability, which aligns closely with the efficient transaction requirements of the Web3 world.

These two innovations not only improve the performance and privacy of Bitcoin but also bring more possibilities for the ecosystem. More efficient script and signature technologies support cross-chain operations, Lightning Network scalability, and complex smart contracts. This will refocus Bitcoin on the core of Web3 and pave the way for building a more secure and efficient decentralized financial and application ecosystem.

The Impact of Schnorr Signatures

In the early design stage of the Bitcoin protocol, Satoshi Nakamoto needed to consider various factors of the signature algorithm, including signature length, openness, patent issues, security verification time, and performance. In the end, he chose the Elliptic Curve Digital Signature Algorithm (ECDSA) and specifically the secp256k1 elliptic curve based on its performance and security. However, besides ECDSA, there are other digital signature algorithms that meet the requirements, especially Schnorr Signature. The reason why Satoshi did not adopt this algorithm may be that the patent for Schnorr Signature had not expired at the time of Bitcoin’s birth. German mathematician and cryptographer Claus-Peter Schnorr applied for and obtained the relevant patent in 1990, so the open-source community could not adopt this technology during the patent’s validity period. Otherwise, Satoshi might have been able to adopt this signature mechanism in the initial version of the Bitcoin protocol.

Compared to ECDSA, Schnorr Signature is more in line with the essence of Bitcoin signatures. Not only does it have better performance and shorter signature length, but it also has linear properties, making key aggregation simple and no longer requiring special techniques for multi-signature. This linear property is easy to understand, and the keys of each participant are aggregated to form a new key through a simple mechanism. There are multiple ways to achieve aggregation, such as Blockstream’s proposed MuSig and the updated version MuSig2. In the MuSig2 scheme, multiple signatures can generate an aggregate public key from their respective private keys and jointly generate a valid signature for that public key, reducing the number of rounds of interaction from the original three rounds (MuSig) to just two rounds.

So, from the perspective of a 2-3 multi-signature transaction, the traditional way requires three public keys and two signatures to initiate a transaction.

However, in the Schnorr Signature scenario, on-chain transactions only require one aggregated public key and one signature, reducing a lot of transaction bytes and therefore reducing the cost of transfers.

Innovation of Taproot Script

Taproot is an innovative Bitcoin script structure that defines how to use and parse transaction addresses of the Taproot type. Taproot was initially inspired by Bitcoin developers’ research on Merkle Abstract Syntax Trees (MAST), so Taproot can be seen as a special implementation of MAST. Through Taproot, Bitcoin UTXOs with multiple different branch scripts can spend by exposing only one branch, while the remaining branches will never appear on the blockchain, greatly improving the privacy and efficiency of transactions. This technology makes the use of complex scripts more convenient and efficient, while maintaining security.

In the Bitcoin protocol, the conditions for receiving Bitcoin (UTXOs) are specified by the “locking script” (output script), and the manner of using Bitcoin (UTXOs) is specified by the “unlocking script” (input script), with the former being a lock and the latter being the corresponding key. In the Segregated Witness (SegWit) upgrade, Bitcoin’s script rules were comprehensively upgraded. Two new script rules were introduced, namely P2WPKH (Pay to Witness Public Key Hash) and P2WSH (Pay to Witness Script Hash), which allowed the use of addresses starting with bc1. P2WPKH is mainly used for regular addresses, while P2WSH is commonly used for multi-signature addresses.

In the Segregated Witness upgrade, the concept of version numbers was introduced to the script. The previous Segregated Witness rules were marked as version V0. Taproot further upgraded on the Segregated Witness framework, and the version number was updated to V1, which is the origin of the “SegWit V1” title in BIP 341. Therefore, this new set of script rules is called P2TR (Pay to Taproot), corresponding to P2WPKH and P2WSH.

In addition, combining Schnorr Signature and Taproot allows for various ways to construct multi-signature (multi-sig) schemes. For example, Steve Lee, a pioneer in the Bitcoin community, has introduced various methods in his speech, such as threshold signatures and Musig trees (Musig Keytree).

Original video of the speech: https://www.youtube.com/watch?v=fDJRy6K_3yo

For example, for the hot wallet of an exchange, a 2-3 multi-signature scheme can be used, involving three private keys: the exchange’s private key, a trusted third-party private key, and a cold wallet backup private key. In threshold signatures, multiple signers pre-build the receiving address using the MuSig mechanism. In actual transactions, only two signatures need to be aggregated to complete the transaction.

LNP/BP: The Maturity of “Bitcoin Protocol/Lightning Network Protocol”

In the previous article, we delved into the forward-looking nature of the Bitcoin network through the introduction of Schnorr signatures and Taproot soft fork upgrades. At the same time, as technological miracles never cease, the LNP/BP Standards Association has been quietly working behind the scenes, bringing more possibilities for innovation to the Bitcoin ecosystem, like a finely crafted piece of art. The LNP/BP codebase covers standards and best practices for Bitcoin’s second layer and above, which do not require blockchain-level soft or hard forks, and are not directly related to the content covered by the Lightning Network RFC (BOLTs). In short, the LNP/BP standards cover all aspects related to Bitcoin transactions, define the basic building blocks of second layer and above solutions, and describe complex use cases built on these modules. This provides possibilities for financial assets, storage, messaging, computation, and secondary markets that utilize the Bitcoin security model and Bitcoin as a payment method/exchange medium.

This article will not go into detail on each protocol within LNP/BP. For a comprehensive understanding of LNP/BP, please visit https://github.com/LNP-BP/LNPBPs.

Here, only a few key points that will have a significant impact on the future of Web3 will be introduced, such as key phase transactions in state channels, as well as some key protocols and technologies: bi-directional channels, PTLCs, eltoo, channel factories, discreet log contracts, high-frequency micro-payments, and Sphinx, etc.

Overview of Key Phase Transactions in State Channels

Funding Transactions: Funding transactions are the initial transactions used in the Lightning Network to create payment channels. They pool funds from all parties into a multi-signature address as collateral for the payment channel. Funding transactions ensure that participants have committed a certain amount of funds before they start conducting off-chain transactions on the payment channel. Funding transactions are the first step in creating a payment channel, ensuring the security and availability of the channel.

Partially Signed Bitcoin Transactions (PSBT): PSBT is a special format of Bitcoin transactions that allows multiple participants to collectively construct and sign transactions. In the Lightning Network, PSBT can be used to create, update, and close payment channel transactions. When both parties in a payment channel want to conduct a transaction, they can jointly construct a PSBT, each sign a portion, merge the partially signed transactions, and finally complete the transaction and submit it to the Bitcoin network. PSBT makes the process of multi-party cooperative transactions more flexible and efficient.

Base-Signed Bitcoin Transactions (BSBT): BSBT is a type of transaction used in the Lightning Network to build and update channel states. It contains the current state information of the channel and is signed by the channel owner. BSBT is used to record the latest state of the channel to ensure the correctness and security of the transactions. When the channel state changes, BSBT is created and updated to reflect the new channel state.

Key Technology of RGB Smart Contracts Supported by the Lightning Network

The Lightning Network is a second-layer solution built on top of Bitcoin that allows users to conduct fast and low-cost transactions through one or multiple bi-directional channels while maintaining the decentralization and security features of the blockchain. In the following content, we will delve into the strategies adopted by the Lightning Network when facing complex RGB smart contract requirements. From efficiency to scalability, we will analyze the underlying key technologies one by one, revealing whether the Lightning Network has the potential to support large-scale RGB smart contracts in its continuous evolution.

Bi-directional channels: As a special type of payment channel, bi-directional channels enable two participants to engage in bi-directional real-time interactions without executing transactions on the blockchain for each interaction. This channel can be likened to a private ledger between two individuals, allowing them to freely transfer and trade assets within the channel. The final state of the channel is only submitted to the blockchain when the channel is closed. In the Bitcoin network, the implementation of bi-directional channels relies mainly on Bitcoin scripts. For example, in the Lightning Network, users can make payments and asset transfers within the channel, and the final state of the channel will only be submitted to the Bitcoin blockchain when the channel needs to be closed. It should be noted that the core technologies of bi-directional payment channels in the Lightning Network include RSMC and HTLCs, which will not be elaborated on here.

Pointlocked Timelocked Contract (PTLC): When discussing the privacy issues of HTLC (Hash Time Locked Contract), we encounter a critical challenge: every hop along the path uses the same preimage, meaning that each HTLC in the entire path can only be unlocked by the same preimage. Does this mean that we have no other solution? In fact, we need to address the following issues:

Once the payment is completed, the payer (Alice) must be able to provide valid payment proof to the payee (Bob).

Each hop along the path must be able to provide a secret value s to unlock the conditional payment sent by the previous node.

In order to obtain the secret value s, each hop needs to send the conditional payment that needs to be unlocked using the secret value s’ to the next node in the path. This secret value s’ can be used to find the secret value s.

Although we can adopt a “simple” approach, which is to use the same secret value s throughout the entire path, as we do with HTLC, this is not the only solution. In fact, the secret values s and s’ do not have to be the same. The key is that as long as a node knows s’, it can know s. Therefore, we can construct the secret value to satisfy this condition. This is the core concept of PTLC (Pointlocked Timelocked Contract).

Below is an illustrative example:

Eltoo: Bitcoin and other blockchain-based systems have limitations in scalability. On-chain payments require all network nodes to verify and store, limiting overall throughput. To address this issue, second layer protocols (off-chain protocols) are considered feasible solutions. They re-negotiate and share states among a small number of participants, avoiding frequent broadcasting of state updates to the blockchain and reducing network burden. However, all second layer protocols face a core problem of ensuring that only the latest state is submitted to the blockchain.

In this context, Eltoo has become a remarkable alternative protocol. It introduces state numbering, a variant of enforceable on-chain sequence numbering. This solves the problem of submitting old states and ensures that only the latest state is recognized and recorded on the blockchain, improving system efficiency and security. This simple and powerful mechanism enhances the feasibility of second layer protocols and provides a strong solution for the scalability of Bitcoin and other blockchains.

Discreet Log Contracts: Although smart contracts are highly regarded in cryptocurrency systems like Bitcoin, they have not been widely used in the financial sector. Scalability and the challenge of incorporating external data into smart contracts are the two main obstacles to implementation and application. At the same time, the privacy of contracts has always been a concern. Discreet Log Contracts (DLC) is a system that addresses scalability and privacy issues while attempting to minimize the trust requirements for oracle providers that supply external data. These contracts maintain secrecy in their discreetness, making it difficult for external observers to detect their presence in transaction records. Additionally, these contracts rely on discrete log knowledge, which is an advantage.

SPHINX: In the Lightning Network, “path” refers to the route used by the payer to send payments to the payee through a series of payment channels. To enable users to relay payments along the path, the Lightning Network employs a mechanism called “Source-based Onion Routing,” commonly known as “SPHINX.” SPHINX is a tool used to ensure secure communication, requiring the payer to create multiple layers of encryption. During the message delivery process, these encryption layers are gradually stripped off by intermediate nodes until the intended payee receives the innermost message. During transmission, each intermediate node only knows its preceding and succeeding nodes. Through source routing, the payer is responsible for creating a payment path from their node to the payee’s node.

In summary, the Lightning Network can use bidirectional channels to complete payments and asset transfers without frequent broadcasting to the blockchain when facing complex RGB smart contract requirements. Point Time-Lock Contracts (PTLC) address the issue of using the same secret value in the payment path, improving privacy. Eltoo, as a new choice for second layer protocols, solves the problem of submitting old states by introducing state numbering. Additionally, Discreet Log Contracts (DLC) address the scalability and privacy issues of smart contracts while reducing the trust requirements for oracles. Finally, SPHINX, as a source-based onion routing mechanism, ensures secure communication for large-scale applications. These innovative technologies and strategies not only enhance the performance and functionality of the Bitcoin network but also lay the foundation for its important role in the future digital financial world.

Leading Change: Exploring the Mission of the RGB Protocol

RGB, as a powerful protocol, aims to combine the characteristics of Bitcoin as a base currency layer with the flexibility of smart contracts. Through RGB, we can create and manage various assets on the Bitcoin network, enabling broader financial and application innovation. From efficient and secure asset issuance to more complex contract logic, RGB injects new vitality into the Bitcoin network, making it play a more important role in the future digital ecosystem. Let’s explore the attractiveness of RGB and its role in driving the Bitcoin network forward.

Brief Overview

The history of RGB has been detailed in recent articles, so here we will only provide a basic review.

In 2016, Peter Todd introduced the concept of single-use seals and client-side validation. Inspired by these important ideas, RGB was proposed in 2018. In 2019, core developer Orlovsky started promoting RGB and devoted himself to developing many parts that ultimately constitute the RGB protocol. Subsequently, the LNP/BP Association was established in Switzerland to develop guidelines related to these standards. After extensive development work, in April 2023, RGB released version v0.10, which was the first preliminary usable version and promised to maintain backward compatibility.

Interpreting RGB Smart Contracts

RGB smart contracts can be briefly summarized into two core elements: ownership and state validation. Therefore, RGB smart contracts can be seen as a distributed network. In this network, no one has a complete current state view, but due to the one-time seal technology based on Bitcoin’s proof of work (PoW) (possibly mediated through the Lightning Network) and the same client-side validation rules (architecture), it still maintains consensus globally. In this system, only owners can access the states they own and a branch of the state history directed acyclic graph (DAG) directly related to these owned states.

In RGB smart contracts, rights management involves defining specific types of operations that can only be executed by parties who own specific parts of the smart contract state. These operations include but are not limited to asset ownership, identity ownership, asset supply increase rights, sub-identity creation rights, and asset trimming/destruction rights.

In RGB smart contracts, users’ rights are enforced. The allowed types of rights are explicitly defined in the schema, which are called state types because each right must have some current state/value, even if it is “null”. Initial rights are allocated by the contract issuer during genesis, and with state transitions, rights can be transferred to new owners (carrying new state values). Ownership of rights (states) is controlled through Bitcoin scripts and the one-time seal mechanism. The next owner of a specific right is always defined by the current holder of that right (i.e., the state owner). Client-side validation requires that the transfer of rights must always be reverse validated by the new owner according to the validation rules.

The RGB smart contract implements the rules for rights transfer/state transition verification, which are defined by the Schema through two main tools: schema structure (used to determine the allocation of rights among descendants) and simple scripts (used to specify the evolution of certain rights states). For example, in terms of assets, the script requires that the sum of outputs must be equal to the sum of inputs. These rules can be further restricted (rather than expanded) at genesis and at each state transition. Within a specific subgraph of the state DAG, new owners can trace back and verify these rules until genesis. It is worth noting that violations of rights rules in one ownership branch of a smart contract will not affect the integrity of the smart contracts in other branches.

In terms of core security measures of RGB smart contracts, each right (i.e., state) cannot directly access the state information of other rights. If necessary, in some cases, rights can use metadata to achieve “shared state”. The permission for such sharing is explicitly specified in the schema and genesis files.

RGB Smart Contract Example:

When Web3 meets RGB

The technological innovation of RGB smart contracts empowers users with the ability to manage rights, providing greater flexibility from asset ownership, identity ownership to the issuance right of asset supply. In RGB smart contracts, the transfer of rights is controlled through Bitcoin scripts and a one-time seal mechanism, ensuring the secure transfer of rights.

At the same time, RGB smart contracts attempt to address the problem of old states by introducing the concept of state numbering. This allows the owners of rights to retrospectively verify rules, potentially improving system efficiency and security, providing stronger guarantees for contract transfer and state transition, ensuring that each transfer complies with verification rules. Overall, RGB smart contracts bring some exciting ideas, especially in terms of scalability, privacy, and rights management of smart contracts. This innovation is bound to have a positive impact on the entire Bitcoin network and bring more possibilities to the future Web3 field.

Unleash Infinity: A Brand New World Analogous to TCP/IP

In the Bitcoin network, the gradual implementation of proposals such as Schnorr signatures and Taproot, as well as the continuous maturity of second-layer protocols centered around LNP/BP and RGB, have outlined an exciting future. In this context, the development path of standard Web3 becomes increasingly clear, constructing a new pattern based on more complex decentralized technologies and cryptographic foundations. The Infinitas technical team believes that this pattern will be built on the foundation of the LNP/BP protocol, presenting a layered structure similar to the architecture of TCP/IP, organically integrating the three key layers of monetary layer, protocol layer, and application layer.

Scalability and Efficiency Improvement: The LNP/BP protocol can introduce more second-layer solutions, such as the Lightning Network, to the Bitcoin network, thereby improving transaction speed and throughput, reducing transaction costs, and promoting more efficient capital flow.

Privacy and Security Enhancement: The development of RGB smart contracts will achieve a higher level of privacy and security in second-layer protocols, allowing users to transact and execute contracts in a more private environment, protecting personal information and asset security.

Scalability and Efficiency Improvement: The LNP/BP protocol can introduce more second-layer solutions, such as the Lightning Network, to the Bitcoin network, improving transaction speed and throughput, reducing transaction fees, and promoting more efficient capital flow.

Privacy and Security Enhancement: The development of RGB smart contracts will achieve a higher level of privacy and security in second-layer protocols, allowing users to transact and execute contracts in a more private environment, protecting personal information and asset security.

Richer Functionality: RGB smart contracts introduce more smart contract functionality to the Bitcoin ecosystem, supporting operations such as asset ownership, identity management, and asset issuance, promoting the development of more types of financial and non-financial applications.

Reduced Blockchain Burden: The development of second-layer protocols can transfer most transactions from the main chain to the second layer, reducing the burden on the main chain and allowing it to focus more on security and core functions.

Developer Innovation: The development of the LNP/BP protocol and RGB creates a broader space for developer innovation, enabling the construction of more diverse applications and services, and promoting the diversification and prosperity of the Web3 ecosystem.

The Development History of TCP/IP

To better understand this new paradigm, let’s quickly review the development history of traditional computer networks. In this field, the development history of the TCP/IP protocol stack plays a crucial role. It went through a process from initial fragmentation to gradual complexity, and finally to standardization and ease of use. In the early stages of the late 1960s and early 1970s, different research institutions attempted and developed various protocols and communication methods. In 1969, the Advanced Research Projects Agency Network (ARPA) of the US Department of Defense was established, using the NCP protocol for communication. Then, in 1972, Vint Cerf and Bob Kahn proposed the TCP protocol, and ARPA began adopting the TCP protocol in 1973, marking the embryonic form of the TCP/IP protocol stack. In 1977, the standardization stage began to emerge, with Vint Cerf and Jon Postel publishing RFC 791, which defined the IPv4 protocol. Subsequently, core protocols such as TCP and IP were gradually standardized, forming the basic framework we have today. In 1989, Tim Berners-Lee invented the World Wide Web, introducing HTTP and HTML, making the internet more user-friendly and visual.

Fascinating Narrative

The correct development path of Web3 is built on more complex decentralized technologies and cryptographic foundations, which evolves with the development of protocols such as LNP/BP and RGB. Similar to the development of the TCP/IP protocol stack (the core of Web2), Web3 must also go through several key stages and require more great contributions, although this journey is long, it is essential. Infinitas, as an innovative solution based on Bitcoin smart contracts, extends and implements core technologies such as payment universal addresses, Contractum language smart contract development environment, immutability of schemas, and multi-level secure storage based on RGB client verification data (proofs, etc.) on the basis of LNP/BP and RGB protocols. Pursuing perfection in every detail to make smart contract development more efficient and reliable. The integration of these technologies constitutes the distributed Infinitas platform, providing a solid foundation for the development of large-scale Web3 applications.

The Brilliant Future of Web3 Development

Through the in-depth exploration in this article, we can see a development path similar to the TCP/IP protocol, and there is reason to believe that with the continuous maturity of the LNP/BP protocol and the RGB protocol, people’s unlimited imagination of the metaverse is becoming a reality. The Web3 world will become more diverse and enriched, and we will soon see:

• Decentralized finance being widely adopted;

• Emergence of blockchain games: high-performance competitive games, strategy games, casual games, etc;

• Diverse social applications on the blockchain: media, dating, video, etc;

• Deep integration with AI to avoid malicious activities;

• Integration with wearable devices and sensors.

The RGB protocol puts us at a brand new starting point, witnessing a future with unlimited possibilities, similar to Bitcoin. As participants and witnesses of this process, we look forward to a more open, inclusive, and innovative Web3 future it brings.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!