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

How does one program RGB smart contracts?

PreviousWhat is contract schema?NextDo you define the validity of a state transition with Schema?

Last updated 3 years ago

Was this helpful?

There is a big difference between the way you program RGB smart contracts and other types of blockchain-based smart-contracts (e.g. in Ethereum) aside from Bitcoin. In RGB there is a thing called RGB which is a set of rules that define how the states of the contract can evolve in time. But unlike Ethereum or any blockchain-based smart contract platform, you need to program the algorithm of operations. In RGB, you don't program the algorithm. Smart contract in blockchain world is an imperative (imperatively styled) written program, that defines a certain very restricting algorithm, which hardly can be called Turing-complete if we think of all the limitations of the underlying blockchain platforms. In RGB, we don't use imperative programming, we use a very special form of functional programming where the smart contract is defined declaratively. So the schema is the declarative definition of a smart contract, not imperative. So the shift of paradigm in programming RGB from programming Ethereum is the same shift of paradigm, which you need to do to move from normal imperative programming to functional programming or to declarative programming.

RGB smart contract is a direct acyclic graph (DAG) of the state changes, where you will always know only a portion of this graph - you don't have access to all of it. RGB schema (any smart contract under RGB) is basically a set of rules of the evolution of this graph, but not in terms of operating all the graph, but applied to a single node of it and describing in a declarative manner how it can change over time. Each of the nodes has its own rules and the resulting graph is the application of those rules. So in RGB you are not programming the way the whole graph evolves, you define how one node of the graph changes, which in turn leads to the overall evolution of the system. It's basically a cellular automata. Programming RGB smart contract is the same compared to programming .

πŸ”–
Schema
cellular automaton