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

Was this helpful?

  1. FAQ

Is RGB a new blockchain?

No. Even taking into account the fact that RGB is based on bitcoin transaction graph (which, in turn, is based on bitcoin timechain), RGB itself is not a 'blockchain'. It’s a form of a DAG, where you don’t have the data on a complete state of the network, ever. From the moment you create a smart contract and transfer the state to some other party, you have neither the control over that state (only the new state owner has it), nor the information on how that state actually evolved.

For example, as an asset issuer you will never know, who are the owners of your issued assets. When you assign the state of the asset to some bitcoin transaction output, you don’t know which output it is, because the party that receives that data, provides you with the information about transaction output, blinded with random data. Taking into account that you don’t know that random data used for blinding, you can’t say which output you are paying to or transferring some rights to.

This is very different from the blockchain-based smart-contract paradigm, where you store the complete history of the blockchain. This is why we say that RGB is a partial-state smart-contract system (the first of its kind). It is still globally consistent, not contradicting the fact of this state partiality, due to the usage of single-use seals that enable reaching consensus on state validation. As a user, whenever I receive some state into my ownership and even without knowing the whole state of the system, I am still able to validate: - that this state of the system was not faked - that it has been uniquely committed - that there were no double spending events (even up to genesis of the asset issuer).

Social consensus on the client-side validation rules also makes it possible to be sure that every further owner of the asset will apply the same validation rules as I do. How? Every asset/state validation rules are defined by Schema at genesis level, meaning that every further owner of the asset still uses the same Schema to validate the history against. Thus, here Schema is actually the means to guarantee the social consensus on the validation.

PreviousWhat does 'RGB' stand for?NextWhat can I do with RGB?

Last updated 4 years ago

Was this helpful?

❓