RGB Docs
  • RGB Protocol Documentation
  • Distributed Computing Concepts
    • Paradigms of Distributed Computing
    • Client-side Validation
    • Single-use Seals and Proof of Publication
  • Commitment layer
    • Commitment Schemes within Bitcoin and RGB
    • Deterministic Bitcoin Commitments - DBC
      • Opret
      • Tapret
    • Multi Protocol Commitments - MPC
    • Anchors
  • RGB State and Operations
    • Introduction to Smart Contracts and their States
    • Contract Operations
    • Components of a Contract Operation
    • Features of RGB State
  • RGB Contract Implementation
    • Contract Implementation in RGB
    • Schema
      • Schema example: Non-Inflatable Assets
    • Interface
      • Standard Interfaces by LNP/BP Association
      • Interface example: RGB20
    • Interface Implementation
  • RGB over Lightning Network
    • Lightning Network compatibility
  • Annexes
    • Glossary
    • Contract Transfers
    • Invoices
    • RGB Library Map
Powered by GitBook
On this page
  1. RGB Contract Implementation

Interface Implementation

PreviousInterface example: RGB20NextLightning Network compatibility

Last updated 8 months ago

Interface Implementation

From the previous sections, it has been illustrated that every encoded piece of a (such as , and ) and are distinct entities that can be developed independently. In order to connect them, an additional piece of code is required. Interface Implementation represents a simple set of instructions that maps the semantics of the interfaces to the actual strict type data structure of the Schema.

As a distinctive characteristic, the Interface Implementation can explicitly map only a subset of the data structure or state operation both from the Schema side and from the Interface side. This way the interface implementation can restrict implicitly the functionality of some Schema from being accessed as well as it can restrict the use of some endpoints provided in the Interface.

In the following code section, we report the default Interface Implementation which associates to the . It is worth pointing out that the following piece of code is placed in the same as the NIA Schema, but that doesn't represent a mandatory choice as even Interface Implementation can be developed independently from both Schema and Interfaces.

fn nia_rgb20() -> IfaceImpl {
    let schema = nia_schema();
    let iface = Rgb20::iface();

    IfaceImpl {
        version: VerNo::V1,
        schema_id: schema.schema_id(),
        iface_id: iface.iface_id(),
        script: none!(),
        global_state: tiny_bset! {
            NamedField::with(GS_NOMINAL, fname!("spec")),
            NamedField::with(GS_DATA, fname!("data")),
            NamedField::with(GS_TIMESTAMP, fname!("created")),
            NamedField::with(GS_ISSUED_SUPPLY, fname!("issuedSupply")),
        },
        assignments: tiny_bset! {
            NamedField::with(OS_ASSET, fname!("assetOwner")),
        },
        valencies: none!(),
        transitions: tiny_bset! {
            NamedType::with(TS_TRANSFER, tn!("Transfer")),
        },
        extensions: none!(),
    }
}

As we can see from the block code above, the Interface Implementation:

  • References the Schema, nia_schema(), and Interface, Rgb20::iface() and commit to them through schema.schema_id() and iface.iface_id() statements.

The Interface Implementation is compiled separately from Schema and Interface producing a separate .rgb or .rbga file, which can then be imported in the wallet.

Contains a map between the strict type data structure of the contract (e.g. GS_NOMINAL ,GS_DATA,etc.) to those of the Interface defined via fname! statement (e.g. "spec" , "data", etc). The same type of mapping is performed for , in this case TS_TRANSFER is mapped to "Transfer".

Non-Inflatable Asset Schema
RGB20 Interface
file
contract
Schema
States
Operation
Interface
contract operations