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. RGB Smart contracts

Do you define the validity of a state transition with Schema?

PreviousHow does one program RGB smart contracts?NextRGB & โ‚ฟitcoin

Last updated 3 years ago

Was this helpful?

Yes. You always validate the state transition against the rules. A state transition is valid only if it follows and matches the Schema rules. Thus, RGB smart contract is in a valid state if all state transitions which you know about are in a valid state.

To compare, in Ethereum the state of a given smart contract is valid if it is mined on the blockchain, and the state change of a smart contract should also be mined on the blockchain. Thus, Ethereum smart contract has a defined state known to the whole world and valid by definition because it's a part of the blockchain history. In order to update that state you need to run a specific algorithm defined and implemented in the smart contract code at the moment of its creation. It makes the options of what contract can and cannot do very restricted.

RGB works differently. With RGB you define the evolution rules at the level of Schema, but you don't restrict the future operations of the whole smart contract by introducing a global algorithm to which every state should comply. You have only local operations performed by every node and both the state and the smart contract itself are valid until each of those historical operations matches the Schema-defined rules (but again, you're not restricting all the possibilities of evolution of the history of contract with a predefined algorithm). Basically, a contract can behave very differently, until each of the changes matches certain validation rules. So it's more like local rules instead of global algorithms. Ethereum has global algorithm and you always operate the whole state of the smart contract. In RGB you operate a local portion of the state with locally applied rules, which gives you much richer range of options.

๐Ÿ”–
Schema