RGB FAQ
  • Welcome to RGB!
  • 💡What is RGB?
  • 📚RGB Resources
  • ⚙️RGB design principles
  • 🎓RGB paradigms
    • Single-use seals
    • Cryptographic commitments
    • Client-side validation
    • Strict encoding
  • 🔖RGB Smart contracts
    • What is a smart contract?
    • What is contract schema?
    • How does one program RGB smart contracts?
    • Do you define the validity of a state transition with Schema?
  • ☣️RGB & ₿itcoin
    • Will RGB require a fork of Bitcoin or Lightning?
    • RGB testnet & mainnet
    • Taproot, Schnorr signatures and RGB
    • Does anything need to happen in Lightning or Bitcoin to enable Lightning on RGB?
    • Is there a plan to work on channel factories?
  • 🎨RGB NFT
    • RGB NFT vs other NFT
    • What's the difference between RGB design of NFTs and common NFT approach?
  • ❓FAQ
    • What is RGB?
    • What does 'RGB' stand for?
    • Is RGB a new blockchain?
    • What can I do with RGB?
    • Is it possible to create a DAO with RGB?
    • RGB vs alternatives
    • Is RGB Turing-complete?
    • Does RGB require Taproot?
    • What RGB is compatible with?
    • Will Simplicity be used in RGB?
    • Why there is no RGB MVP with updates rolling out after?
    • How is confidentiality reached in RGB?
    • How is safety reached in RGB?
    • What is client-side validation?
    • How scalable is RGB?
    • Is there an RGB "Hello World" guide?
  • 📖Glossary
    • Contracts
      • ContractId
      • NodeId
      • Node
      • State
      • State assignment
      • State transition
      • Assignment
      • Assignment variant
      • State data
      • State type
      • Metadata fields
      • Metadata
      • Data type
      • Genesis
    • AluVM
    • Bifrost
    • Client-side validation
    • Contractum
    • Deterministic Bitcoin commitments
      • Container construction/deconstruction
      • Container
      • Commitment
      • Commitment embedding
      • LockScript
      • Proof
      • Protocol-specific entropy
      • Supplement
    • Right
    • Schema & Scripts
      • Schema
      • Field type
      • Assignment type
      • Bit dimensions
      • ABI
      • Script library
      • Occurence boundaries
      • Script extensibility
      • Transition type
    • Single-use seals
      • Witness
      • Seal definition
      • Seal blinding
      • Multimessage commitments
      • Seal closing over message
    • Stash
      • Stash
      • Consignment
      • Disclosure
      • Anchor
      • Forget procedure
      • Merge procedure
      • Validate procedure
      • Conceal procedure
      • Consign procedure
    • Encodings
      • Merklization commitment encoding
      • Storage encoding
      • Strict encoding
      • Pedersen commitments
      • Blinding factors
      • Buletproofs
      • Conceal
      • Commitment encoding
  • 🙋Community
    • Developer calls
    • Presentation slides
    • YouTube
    • Getting familiar with RGB
    • Articles & interviews on RGB
Powered by GitBook
On this page
  • Types of networks in Bitcoin Ecosystem
  • So, does RGB have a testnet?

Was this helpful?

  1. RGB & ₿itcoin

RGB testnet & mainnet

To start with, it must be mentioned that in RGB there is no network and no blockchain, as it's a client-side validation technology, very different from the mentioned two.

Types of networks in Bitcoin Ecosystem

In Bitcoin you basically have two things, which are shared by the Bitcoin community and nodes. The first thing is - a blockchain (data). Blockchain is a database, present on each of the machines that participate in the Bitcoin network. This is the first common layer, common infrastructure of Bitcoin. In fact, in Bitcoin protocol you can construct different chains (blockchains) which are currently called networks (they are not exactly networks, but still that's the name being used). So, in Bitcoin there is:

  1. Mainnet - main Bitcoin blockchain, that covers the value-containing transactions and Bitcoin itself.

  2. Testnets - different blockchains based on the same Bitcoin protocol, but with slight modifications: - Testnet - uses Bitcoin's Proof-of-Work mining algorithm, but a different difficulty setting. - Regtest - can be established by anybody with a restricted and well defined set of nodes that can produce blocks. - Signet - kind of Proof-of-Authority network for Bitcoin (it doesn't run the Proof-of-Work mining algorithm).

So, the second thing that we need to clarify is the concept of the network in Bitcoin, which is the peer-to-peer network created by full Bitcoin nodes connecting and talking to each other using Bitcoin wire protocol. While this is tightly related to blockchain, it is not the equivalent of it. Historically there were forks of Bitcoin blockchain (like BCash), that continued to use the same Bitcoin peer-to-peer network for propagating transactions (resulting in relay attacks and many others).

So, in terms of Bitcoin there are 2 concepts: Mainnet and Testnet, blockchain-based and peer-to-peer based networks. So, in fact, Testnet is running on one blockchain and Mainnet is running on another one.

The situation gets a bit more complex with Lightning Network, as there we do have a peer-to-peer networking, but unlike Bitcoin, we don't have a global state or consensus other than nodes gossiping about the structure of that peer-to-peer network. Lightning Network is composed of 2 others: Testnet and Mainnet, which are not linked to any blockchain (not even Bitcoin one). Lightning is a multiasset protocol and today nothing prevents you from adding Bitcoin to the Lightning mainnet or adding Bitcoin Testnet coins there. So, when we say 'network' in terms of Lightning mainnet or testnet, we don't imply a particular blockchain it's based on. Of course, usually when speaking about Lightning mainnet working on a blockchain we mean Bictoin mainnet, but technically there are no limitations to use any other one as a base layer, including the testnet one or even a fork of Bitcoin (e.g. Litecoin). What is reflected in Lightning Network by words 'testnet' or 'mainnet' is the fact whether the creators of the network consider the functionality stable/final or not. Testnet was, in fact, the version that was not adviced to be used for real payments and mainnet was said to still be in beta (while from Bitcoin point of view, if you are reckless enough, you could perform real-value payments already). And this situation is pretty natural for Lightning, as again, it's a multiasset protocol and it's about peer-to-peer networking, thus all the funds are managed by the channel peers, bidirectionally, inside a single channel, therefore all you are potentially risking to loose is the amount of funds in this channel.

After we have briefly described what are the differences between networks in Bitcoin and Lighting, we can ask if the same approach can be applied to the client-side validation world. And here the answer would be no. In RGB, as in any other client-side validation protocol, we have no peer-to-peer network, no nodes talking to each other (because you don't permanently propagate blocks of data or payments). Thus, you can't have a mainnet or testnet because there is no peer-to-peer network whatsoever. RGB is a direct acyclic graph (DAG) of state transitions, where the contracts are completely isolated from each other and nobody other than contract owners (or parties that the owners disclosed the information about the contracts to) even knows about its existence. And while we still need to pass the client-side validation data and use RGB for instant payments over Lightning, there is no need to have a separate RGB network for that, as RGB leverages Lightning peer-to-peer protocol and adds layers on top of it.

So, does RGB have a testnet?

Yes and no. 'No' in a sense that RGB doesn't have a peer-to-peer network, so there is no (and cannot be) testnet or mainnet in strict meaning of the terms. On the other hand, RGB is already working, though not yet production-ready, so you can say that RGB is in 'testnet' using quotation marks and meaning 'testing environment/mode' ( but not as in 'testing network'). At the moment of writing this text, RGB protocol already had 4 releases and it already allows you to make transactions and transfers, though none of those releases is yet final and every new one is not backward-compatible. By __finalization of the protocol or it being production-ready/in 'mainnet' we mean the version, in which we commit to not change RGB (client-side validation data, everything related to validation itself etc) anymore. Of course, if some security bugs or vulnerabilities are found they would be fixed, but the development of the protocol and its implementation would already be completed at that point. So, even though you can already make even real-value transfers on RGB using Bitcoin mainnet as a commitment layer (there are no technical limitations that can prevent you from doing it), we strongly do not recommend it, as with every new release of the protocol all the assets issued or transferred before and the sats that were moved, will be lost due to backport breaking changes. And on the final note, even when RGB is released 'in production', we would still not recommend to be too reckless and make high value transfers on it. In some way, the situation with RGB 'mainnet' release is similar to the one that took place with Lightning, where only time could show critical security vulnerabilities, so use it wisely.

PreviousWill RGB require a fork of Bitcoin or Lightning?NextTaproot, Schnorr signatures and RGB

Last updated 3 years ago

Was this helpful?

☣️