RGB Protocol, an Introduction

  • Introduction
  • Digital Assets
  • Alternatives
  • Goals
  • Design
  • Maturity
  • References
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Introduction

  • The RGB Protocol is an open-source, community driven development of standards and best practices to issue, transmit and store "Bitcoin-base non-bitcoin assets"[1]
  • The standard is being created to overcome major shortcomings of previous attempts to store digital assets on the blockchain.
  • The protocol is currently based on Bitcoin, and is meant to provide an acceptable level of scalability, confidentiality and standardization. [2]
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Digital Assets

  • Growing interest in a digital proxy for securities, utilities or collectibles. [2]
  • The current methods of issuing and transferring these assets is slow, expensive and inefficient. [2]
  • There is now more demand for digital assets. [3]
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Bitcoin-based (non-bitcoin) Assets

  • There are still many uses for the current methods of digital assets.
  • Putting digital assets on the blockchain presents its own list of problems:
    • Complex
    • New and not well understood technology
    • Regulatory issues, such as pseudo-anonymity / complete openness.
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

So Why Do It?

Asset Independence

  • The asset is completely independent from the centralized issuer right after the issuance moment.
  • Decentralized mechanisms enabling autonomous, trustless, and censorship-resistant mechanisms to enforce rights/benefits connected to the assets.
    • The "self-enforced-right" proposition is more interesting but still not realistic: applications of this kind are still far from any actual implementation. [2]
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Asset Blindness

  • To a certain degree, the issuer of the digital asset is "blind" to the exact asset when they act on it.
  • There may be legal ramifications such as KYC/AML [4] legislation.
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Asset Auditability

  • A blockchain based system would be fair towards end users.
  • It would make it difficult to inflate supply / change attributes / forge tokens / censor users.
  • This could move towards relaxing the current, expensive account/auditing requirements.
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Asset Standardization

  • Much easier to adopt an open standard on a wide scale, especially in the case of Bitcoin based protocols.
  • There can be standardized libraries to interact with this protocol.
  • With standardization comes liquidity, frameworks, APIs etc.
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Alternatives

  • Ethereum based ERC20 protocol, currently the most used standard.
  • Meta-protocols on Bitcoin, are not standardized.
  • Colored Coins, further exacerbate the fungibility issue of bitcoin and being on-chain leads to bloating.
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Goals For RGB

  • A new better proposal for blockchain-based asset management standard.
  • Meet the market requirements for standardization, auditability, blindness, independence.
  • Try and stay in Layer 2 scalability / fungibility strategies.
  • Leverage as much as possible from the current Bitcoin infrastructure.
  • Particular focus is paid to Lightning Network.
  • The protocol proposal will contain an additional, specific and native “layer 2” solution based on the "Proofmarshal" idea
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Design

Contract Engine

  • RGB enabled wallets must include software capable of analyzing contract conditions and comply with them.
  • Predefined behaviours can be defined using "blueprints" which allows RGB to be implemented in a modular fashion.
  • Popular contract blueprints to cover most of the use-cases.
  • Another more general purpose blueprint that embeds a meta-script executor, which allows very complex contract to be created.
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Extended URI

  • To keep within a standardized approach and implement the protocol within a Client Side Validation paradigm
    • Use address passing.
    • When a payee generates an address he transmits the coordinates of the selected Publishing Server.
    • He generates a number called the "dark-tag" and passes it to the payer along with the address and publishing information.
    • This feature can be developed by extending the BOLT Invoice Protocol. [5]
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Publisher Servers

  • The scheme requires additional, agreed-upon (at the transaction level) third parties which store the chain of encrypted proofs and accept related queries.
  • In the context of an issued asset, these "publisher" servers could be maintained by the issuer itself.
  • They can be maintained individually by the receivers, or by one or many independent third parties selected by the sender from a set defined by the receivers.
  • The proofs could be stored and communicated via decentralized systems, but there is extra complexity with that.
  • Proofmarshal Integration requires a centralized third party to be effectively leveraged for Lightning Network Integration.
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Lightning Network Integration

  • Because the protocol is UTXO-based, it will be possible to link one or more assets to a Lightning Network channel.
  • The channel becomes colored, exchanging state updates which are compliant with the asset scheme.
  • Asset distribution is guaranteed to be preserved in the case of non-consensual closures.
  • It can leverage off of the scalability and privacy features of the Lightning Network.
  • LN-enabled atomic swaps and LN-based path discovery for decentralized asset exchange.
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Proofmarshal Integration

  • The protocol will also include another L2 strategy for scalability / fungibility
  • An asset-specific implementation of the “Proofmarshal” concept, based on:
    • “Single-Use-Seals”
    • “Proof-of-Publication-Ledgers”
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Proofmarshal Benefits

  • A Publisher Server may also act as “sealer” whereby they can obfuscate transactions but not manipulate / forge or falsify
    • Achieved by committing multiple proofs from different anonymous users to a single UTXO.
  • This could decouple the anti-double-spending function of the Bitcoin blockchain from the specific asset transactions
    • Thereby "sealing" large amounts of transactions spent on a single Bitcoin UTXO.
© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

Maturity

The project is still in its infancy.

© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)

References

© Tari Labs, 2018-2021. (License : CC BY-NC-SA 4.0)