RGB Blackpaper
GitHubFAQTech talksReddit
  • RGB Blackpaper
  • General information
    • 1. Introduction
      • 1.1. Motivation
      • 1.2. Background
    • 2. Protocol design
      • 2.1. Design goals
      • 2.2. Design overview
  • Consensus layer
    • 3. Client-side-validation
      • 3.1. Proof of publication
      • 3.2. Single-use-seals
      • 3.3. Deterministic bitcoin commitments
        • 3.3.1. Tapret commitments
        • 3.3.2. Opret commitments
        • 3.3.3. Deterministic output selection
      • 3.4. Multi-protocol commitments
    • 4. Ubiquitous deterministic computin
      • 4.1. Strict types system
      • 4.2. AluVM virtual machine
    • 5. Contracts, state & operations
      • 5.1. Schema
      • 5.2. Contract state
      • 5.3. Contract operations
      • 5.4. Contract validation
  • Application layer
    • 6. Writing contracts. Scripting.
    • 7. Interacting with contracts
    • 8. P2P communications
    • 9. Wallet interaction
    • 10. Possible applications
      • 10.1. Bitcoin Finance (BiFi) on Lightning
      • 10.2. Non-financial applications
  • Other information
    • 11. Governance
      • 11.1. Organizations
      • 11.2. Ossification & upgradability
    • 12. Protocol properties
      • 12.1. Privacy
      • 12.2. Censorship-resistance
      • 12.3. Trust model
      • 12.4. Global state & avaliability
      • 12.5. Comparison to other systems
    • 13. History & acknowledgements
  • Appendices
    • References
    • Appendix A: Related standards
    • Appendix B: Reference implementation
    • Appendix C: Glossary
Powered by GitBook
On this page

Was this helpful?

Export as PDF

RGB Blackpaper

Turing-complete, Scalable & Confidential Smart Contract Layer for Bitcoin & LN

Maxim Orlovsky 1,2; Peter Todd 1; Giacomo Zucco 1; Federico Tenga 3; Olga Ukolova 1,2

1.LNP/BP Standards Association

2.Pandora Prime

3.iFinex Inc

Abstract

This paper proposes a novel “post-blockchain” smart contract system, named RGB. It is based on the concept of client-side-validation, separating contract state and operations from the consensus level. With this approach, contracts are sharded (each contract is a standalone shard), kept and validated only by contract participants, bringing native privacy and scalability mechanism, exceeding abilities of all existing blockchain-based smart contracts while not compromising on security or decentralization. RGB as a smart contract system doesn’t require any specific token/coin to operate and is implemented on top of bitcoin blockchain, as the most secure decentralized system. It also can operate on top of layer-2 protocols, such as sidechains, lightning network and other future protocols. It is fully compatible with all existing bitcoin technologies (scriptless scripts, DLCs, atomic swaps) and future possible bitcoin softforks and doesn’t require any changes to the base bitcoin layer. RGB uses specially-designed functional registry-based RISC virtual machine AluVM, which is Turing-equivalent* and is able to operate global state with the same availability guarantees as with existing blockchain-based systems. RGB has a strong privacy-preserving emphasize, using modified form of Blockstream’s confidential transaction technology (based on Pedersen commitments, enhanced with Bulletproofs++ range proofs) and cryptographic hash concealments for non-fungible state, such that even contract participants do not see full information about past contract history - while still be able to validate it. The paper presents an initial implementation of RGB technology and discusses possible applications of it for building rich, private, scalable and censorship-resistant applications on top of bitcoin and lightning network, including bitcoin finance (“BiFi”) and non-financial forms of smart contracts.

* in the same terms as EVM and WASM-based smart contracts, i.e. nearly computationally universal, bound by number of operation steps, measured by gas consumption in Ethereum-like systems, and by accumulated computational complexity measure in case of AluVM.

Next1. Introduction

Last updated 2 years ago

Was this helpful?