> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/zh/canton-zk-evm/trust-model.md).

# 信任模型与限制

Ostia 早期发布版的检查、授权方、托管假设和限制。

Ostia 是在本地测试网络上的早期发布版本。它只有一个构建者、一个运营者和一个确认者。代码和 ZisK 1.3.1-alpha 尚未经过审计。tROME 是没有价值的测试代币。请勿将此版本用于任何有价值的用途。

本页介绍 commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. 请阅读完整的 [设计](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md) 和 [安全策略](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/SECURITY.md).

## 谁检查什么

| 部分        | 检查或权限                                                         |
| --------- | ------------------------------------------------------------- |
| 来宾        | 验证 EVM 区块并拒绝除 Ostia 编译规则之外的链配置。                               |
| 边车 `验证`   | 检查证明、固定的 programVK 和 rootC、已证明的区块哈希、区块头以及交易列表。                |
| 边车 `交易腿`  | 检查网关的账户和存储证明，并将有序附加的交易腿与已证明的网关哈希进行比较。                         |
| Daml `推进` | 检查边车的应答、父块、下一区块编号、gas 上限以及这些交易腿所使用的合约。它结算这些交易腿，并创建下一个头部和区块记录。 |
| Canton    | 通过消费链上的单一状态合约来对区块排序，并将交易的变更一并提交。它会拒绝不同的外部调用应答。                |
| 构建者       | 选择交易，检查其可见的 Canton 合约，获取证明并提交区块。它本身不能最终确定一个区块。                |

每位确认参与者旁都运行一个边车，包括运营者的参与者。每个边车仅根据发送到外部调用中的输入计算其应答。Daml 比较它们的应答；它本身不会执行密码学证明检查。该 [边车 README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/sidecar/README.md) 和 [Daml README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md) 说明这些检查和权限要求。

## 证明固定了什么

固定的程序密钥标识来宾及其链规则。证明承诺一个区块哈希。检查其区块头将状态根和交易根绑定在一起。随后，账户和存储证明将网关记录的交易腿哈希绑定到该状态根。

附加的交易腿必须与网关记录的字段和顺序完全一致。删除一条交易腿、添加一条，或更改接收方、金额、代币或标识符都会导致哈希比较失败。没有交易腿的区块也必须证明这一点的不存在。交易腿比较还依赖于 Keccak-256 的抗碰撞性。

链记录的创世状态根固定了网关代码。网关合约没有所有者、管理员密钥、升级或暂停功能。Canton 参与方仍对其持有的代币拥有托管权限。

## 运营者、确认者和网关权限

运营者和网关提出链的创世、固定值、gas 上限和构建者。确认者接受该提案。预计它会将固定值和创世网关代码与自身构建结果进行比较。所提供的本地脚本会提出匹配的值，并代表确认者立即接受该提案。

运营者、确认者和网关签署 `ZkChain`。它们是该链的信任根。存款和取款结算决策需要三者全部参与。付款结算需要运营者和确认者。 `推进` 在 Daml 设计下提供它们的共同权限。仅凭构建者本身无法执行这些结算决策。

网关参与方持有支撑 EVM 上封装代币的 Canton 代币。它托管在运营者的参与者上。运行该参与者的任何人都可以在不受提现规则约束的情况下转移被锁定的代币。网关合约没有管理员密钥，这并不限制该 Canton 参与方通过其参与者行事的能力。

代币登记是另一项信任决策。运营者和网关提出从一种 Canton 金融工具到一种 EVM 封装代币的映射，确认者接受该映射。网关使用其自身权限执行已登记代币的 Daml 转移代码。该 [网络 README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/network/README.md#the-canton-network) 描述参与者托管和登记检查。

## 什么会阻止区块

要包含一条交易腿，构建者需要读取其请求、条款、接受、分配、代币登记和网关持仓。若其无法看到某笔交易对应的 Canton 合约，它就会将该交易排除在外。

在构建者检查之后或在证明之后，分配可以被撤销。代币登记机构也可以依据其自身规则拒绝结算。随后 Canton 会拒绝该区块，且不会提交任何内容。对于构建者无法预见的登记拒绝，下一次运行需要 `--exclude`；构建者不会在多次运行之间记住该拒绝。

每次构建者运行处理一个区块；它不会循环处理连续的区块。构建者在证明之前不会限制执行步数。如果证明器无法完成一个区块，构建者运行就会停止。该 [构建器 README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#not-here) 记录这些限制。

## 此版本不提供什么

本地网络在各次运行之间不保留状态。它没有 Ledger API 身份验证或 TLS，且仅面向一台机器使用。该网络在外部调用中使用固定的 Canton 3.6 快照和快照版 Daml 编译器。它们的版本和哈希位于 [固定值](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS).

多个构建者、强制包含、公共 Canton 部署、隐私以及需要超出运营者参与者范围的托管均不在本版本范围内。没有吞吐量或区块时间目标。记录的演示在同一台机器上的 Canton 上，使用了在两个确认参与者上相同的边车实现。

读者可以重新检查区块证明，但 `BlockRecord` 不携带已结算的交易腿。浏览器的 Verify 按钮会检查证明、区块头和交易；它不会重复执行 Canton 交易腿结算检查。

## 报告安全问题

使用 GitHub 的私密漏洞报告功能提交 `canton-zk-evm`：打开仓库的 Security 选项卡并选择 **报告漏洞**。请勿为安全问题公开提交 issue。

请包含受影响的组件、提交、复现步骤和观察到的结果。如果发现内容包含证明或区块，请一并附上。该 [安全策略](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/SECURITY.md) 定义范围。没有漏洞赏金。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.rome.builders/zh/canton-zk-evm/trust-model.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.