如何理解RGB合约schema

<!--StartFragment-->

虽然RGBVM不受限但是RGB的“合约”编写实际上是受限的。因为在’合约代码“和VM中间还有个东西叫做Schema。

<https://www.rgbfaq.com/glossary/schema-and-scripts/schema> 官方解释的什么schema

RGB Schema 通过编码定义了 Genesis（创世）的必要模板，并嵌入了所有可用合约操作的规则，代表了其业务逻辑，允许相关状态进行更新。

RGB Schema 类似于面向对象编程（OOP）语言中的类。在使用这个类之前需要提供数据new一个类出来。因此，这样的结构用于定义 RGB 合约和资产的各种标准，例如：同质化资产、收藏品、数字身份等。

schema在语境中可以理解成蓝图。简单理解就是定义以后这个合约是什么运行和验证的。“合约代码”实际上是往蓝图上面添加具体信息然后他会生成对应的zk电路，验证代码和能被AluVM执行的代码。

在 RGB 上发行资产的发行者使用 Schema（并向公众提供），以在 Genesis 中定义编码的发行属性。这样，合约就可以被 RGB 钱包支持并完全运行。因此，当用户接收到有关 RGB 上某一资产的信息（数据和合约）时，他们必须根据该资产发行者分发的 Schema 进行验证。

事实上，Schema 验证是用户在以任何方式与合约交互之前需要进行的第一步操作（例如，执行所需的合约操作）。

从功能角度来看，Schema 构建解决了以下问题：

• 拥有的状态和分配类型是什么？
• 存在什么类型的权态（Valences）？
• 合约具有什么全局状态？
• Genesis 的结构是怎样的？
• 可能的状态转换和状态扩展是什么？
• 合约操作可以包含什么元数据？
• 状态数据在状态转换中如何允许发生变化？
• 什么样的交易顺序是合法的？

从技术角度来看，RGB Schema 是一个功能性的声明性文档，需要编译才能在 RGB 应用程序和钱包中有效使用。

schema还允许对合约进行编程更新，而无需修改基础设施软件，以便钱包和浏览器可以接受修改后的资产类型，而无需对各自的代码进行任何更改。

即使 Schema 的这种架构选择看起来与基于区块链的合约（例如以太坊上实现的合约）非常不同。在后者系统中，合约本身是作为可执行代码提供的，该代码实现了更改和执行状态的规则，并最终直接存储到区块链中。相比之下，在 RGB 中，合约完全以声明式的方式进行编码。

在客户端验证阶段执行的每个合约操作中，合约 Schema 始终被引用和检查。特别是在编译之后，Schema 可以提供执行由 Genesis 操作表示的合约发行所需的所有数据结构。

如前所述，Schema 清楚地区分了合约开发者和发行者，发行者可能对编码和编程一无所知。这种方法广泛使用合约模板，可以立即供发行者使用，从而避免了实施阶段常见的编程错误。

用户验证合约信息也是通过zk和Aluvm两块来验证的。

每一个schema都需要对应的一套zk电路模板。因为schema为 RGB 的客户端部分嵌入状态验证脚本和相关函数。脚本通过 AluVM 引擎执行，该引擎代表了业务逻辑执行和验证的最基本部分。

zk入门资料整理

**Q:**Does RGB have a built-in ZKVM that supports RISC? My current understanding is that RGB uses aluvm for execution and then adds an extra layer to constrain the execution results, rather than implementing a constraint for each RISC instruction. I am not sure if my understanding is correct.（RGB 是否内置了支持 RISC 的 ZKVM？我目前的理解是，RGB 使用 aluvm 执行，然后添加额外的一层来约束执行结果，而不是为每条 RISC 指令实施约束。我不确定我的理解是否正确。）

A: RGB does not support RISC since in client-side validation there is no such concept as random access memory and RISC architecture is overly-complex for what we need. AluVM is simply math and few bound-width bytestring manipulations and that's it.

On the other hand AluVM and validation logic can be made in zk-SNARK circuit with zk-LLVM - the direction we will be working on this and next year

AluVM is written in rust. You compile it via LLVM intermediate representation - and convert that into zk circuit using zk-LLVM. That's in brief.

What is harder is to compress the historical proofs for single-use seals - that would require either zkSync integration - or use of new layer 1 like Prometheus.

Well, the motivation is ultra-simple: reduce the size of the consignment and make them non-growing

（RGB 不支持 RISC，因为在客户端验证中不存在随机存取内存的概念，而且 RISC 架构对于我们的需求来说过于复杂。AluVM 仅仅是一些简单的数学运算和有固定宽度的字节串操作，仅此而已。另一方面，AluVM 和验证逻辑可以通过 zk-LLVM 在 zk-SNARK 电路中实现，这也是我们今年和明年的工作方向。 AluVM 是用 Rust 编写的。你可以通过 LLVM 中间表示（IR）编译它，然后使用 zk-LLVM 将其转换为 zk 电路。简单来说就是这样。更难的部分是如何压缩一次性密封的历史证明 —— 这需要集成 zkSync 或使用新的第 1 层协议（如 Prometheus）。 我们的动机非常简单：缩小 Consignment 的规模，使其不再增长。）

LLVM（Low-Level Virtual Machine） 是一个编译器框架，可以用于生成、优化和编译中间代码（intermediate code）到机器代码。它最早是作为一个虚拟机项目开始的，但发展成了一个强大且灵活的编译器基础架构，现在被广泛应用于多种编程语言。

zk-LLVM 是一个基于 LLVM 的扩展工具，它将 LLVM 的编译功能与零知识证明（ZKP）集成在一起，目的是生成用于零知识证明的电路。通过 zk-LLVM，开发者可以用高级语言（如 Rust 或 C++）编写程序，然后将其编译成适用于零知识证明的 zk 电路。

Consignment

在受客户端验证约束的各方之间传输的数据。在 RGB 中，有 2 种类型的托运：

• Contract Consignment：由合约发行者提供，包括有关合约设置的信息，例如 Schema、Genesis、Interface 和 Interface Implementation。
• Transfer Consignment：由付款人用户方提供，包含截至当前路线最后一个tx（原文是 terminal consignment）的所有状态转换历史记录。（终端的意思是DAG中叶子节点）

总的来说Schema合约模板，一般开发人员只需要输入构造函数参数就可以创建对应类型合约。类似erc20合约在构造函数输入对应name tick之类的就可以创建对应合约一样。

<!--EndFragment-->