{"author":{"address":null,"user":"https://learnblockchain.cn/people/4862"},"content":{"body":"\u003c!--StartFragment--\u003e\r\n\r\n虽然RGBVM不受限但是RGB的“合约”编写实际上是受限的。因为在’合约代码“和VM中间还有个东西叫做Schema。\r\n\r\n\u003chttps://www.rgbfaq.com/glossary/schema-and-scripts/schema\u003e 官方解释的什么schema\r\n\r\nRGB Schema 通过编码定义了 Genesis（创世）的必要模板，并嵌入了所有可用合约操作的规则，代表了其业务逻辑，允许相关状态进行更新。\r\n\r\nRGB Schema 类似于面向对象编程（OOP）语言中的类。在使用这个类之前需要提供数据new一个类出来。因此，这样的结构用于定义 RGB 合约和资产的各种标准，例如：同质化资产、收藏品、数字身份等。\r\n\r\n**schema在语境中可以理解成蓝图。简单理解就是定义以后这个合约是什么运行和验证的。“合约代码”实际上是往蓝图上面添加具体信息然后他会生成对应的zk电路，验证代码和能被AluVM执行的代码。**\r\n\r\n在 RGB 上发行资产的发行者使用 Schema（并向公众提供），以在 Genesis 中定义编码的发行属性。这样，合约就可以被 RGB 钱包支持并完全运行。因此，当用户接收到有关 RGB 上某一资产的信息（数据和合约）时，他们必须根据该资产发行者分发的 Schema 进行验证。\r\n\r\n事实上，Schema 验证是用户在以任何方式与合约交互之前需要进行的第一步操作（例如，执行所需的合约操作）。\r\n\r\n从功能角度来看，Schema 构建解决了以下问题：\r\n\r\n* 拥有的状态和分配类型是什么？\r\n* 存在什么类型的权态（Valences）？\r\n* 合约具有什么全局状态？\r\n* Genesis 的结构是怎样的？\r\n* 可能的状态转换和状态扩展是什么？\r\n* 合约操作可以包含什么元数据？\r\n* 状态数据在状态转换中如何允许发生变化？\r\n* 什么样的交易顺序是合法的？\r\n\r\n[![](https://github.com/EthanShang8989/rgb-learning-doc/raw/master/schema.png)](https://github.com/EthanShang8989/rgb-learning-doc/blob/master/schema.png)\r\n\r\n**从技术角度来看，RGB Schema 是一个功能性的声明性文档，需要编译才能在 RGB 应用程序和钱包中有效使用。**\r\n\r\nschema还允许**对合约进行编程更新，而无需**修改基础设施软件，以便钱包和浏览器可以接受修改后的资产类型，而无需对各自的代码进行任何更改。\r\n\r\n即使 Schema 的这种架构选择看起来与基于区块链的合约（例如以太坊上实现的合约）非常不同。在后者系统中，合约本身是作为可执行代码提供的，该代码实现了更改和执行状态的规则，并最终直接存储到区块链中。相比之下，在 RGB 中，合约完全以声明式的方式进行编码。\r\n\r\n在客户端验证阶段执行的每个合约操作中，合约 Schema 始终被引用和检查。特别是在编译之后，Schema 可以提供执行由 Genesis 操作表示的合约发行所需的所有数据结构。\r\n\r\n如前所述，Schema 清楚地区分了合约开发者和发行者，发行者可能对编码和编程一无所知。这种方法广泛使用合约模板，可以立即供发行者使用，从而避免了实施阶段常见的编程错误。\r\n\r\n用户验证合约信息也是通过zk和Aluvm两块来验证的。\r\n\r\n每一个schema都需要对应的一套zk电路模板。因为schema为 RGB 的客户端部分嵌入**状态验证脚本**和相关函数。脚本通过 AluVM 引擎执行，该引擎代表了业务逻辑执行和验证的最基本部分。\r\n\r\n[zk入门资料整理](https://learnblockchain.cn/article/8337)\r\n\r\n\\*\\*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 指令实施约束。我不确定我的理解是否正确。）\r\n\r\n**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.\r\n\r\nOn 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\r\n\r\nAluVM is written in rust. You compile it via LLVM intermediate representation - and convert that into zk circuit using zk-LLVM. That's in brief.\r\n\r\nWhat 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.\r\n\r\nWell, the motivation is ultra-simple: reduce the size of the consignment and make them non-growing\r\n\r\n（RGB 不支持 RISC，因为在客户端验证中不存在随机存取内存的概念，而且 RISC 架构对于我们的需求来说过于复杂。AluVM 仅仅是一些简单的数学运算和有固定宽度的字节串操作，仅此而已。另一方面，AluVM 和验证逻辑可以通过 zk-LLVM 在 zk-SNARK 电路中实现，这也是我们今年和明年的工作方向。 AluVM 是用 Rust 编写的。你可以通过 LLVM 中间表示（IR）编译它，然后使用 zk-LLVM 将其转换为 zk 电路。简单来说就是这样。更难的部分是如何压缩一次性密封的历史证明 —— 这需要集成 zkSync 或使用新的第 1 层协议（如 Prometheus）。 我们的动机非常简单：缩小 Consignment 的规模，使其不再增长。）\r\n\r\n[![](https://github.com/EthanShang8989/rgb-learning-doc/raw/master/RGB_validation.png)](https://github.com/EthanShang8989/rgb-learning-doc/blob/master/RGB_validation.png)\r\n\r\n**LLVM**（Low-Level Virtual Machine） 是一个编译器框架，可以用于生成、优化和编译中间代码（intermediate code）到机器代码。它最早是作为一个虚拟机项目开始的，但发展成了一个强大且灵活的编译器基础架构，现在被广泛应用于多种编程语言。\r\n\r\n**zk-LLVM** 是一个基于 LLVM 的扩展工具，它将 LLVM 的编译功能与零知识证明（ZKP）集成在一起，目的是生成用于零知识证明的电路。通过 zk-LLVM，开发者可以用高级语言（如 Rust 或 C++）编写程序，然后将其编译成适用于零知识证明的 zk 电路。\r\n\r\n**Consignment**\r\n\r\n在受[客户端验证](https://docs.rgb.info/annexes/glossary#client-side-validation)约束的各方之间传输的数据。在 RGB 中，有 2 种类型的托运：\r\n\r\n* Contract Consignment：由合约发行者提供，包括有关合约设置的信息，例如 [Schema](https://docs.rgb.info/annexes/glossary#schema)、[Genesis](https://docs.rgb.info/annexes/glossary#genesis)、[Interface](https://docs.rgb.info/annexes/glossary#interface) 和 [Interface Implementation](https://docs.rgb.info/annexes/glossary#interface-implementation)。\r\n* Transfer Consignment：由付款人用户方提供，包含截至[当前路线最后一个tx](https://docs.rgb.info/annexes/glossary#terminal-consignment-consignment-endpoint)（原文是 terminal consignment）的所有状态转换历史记录。（终端的意思是DAG中叶子节点）\r\n\r\n**总的来说Schema合约模板，一般开发人员只需要输入构造函数参数就可以创建对应类型合约。类似erc20合约在构造函数输入对应name tick之类的就可以创建对应合约一样。**\r\n\r\n\u003c!--EndFragment--\u003e","title":"如何理解RGB合约schema"},"history":null,"timestamp":1726797056,"version":1}