设计即可验证
购买证明如何把一个报价绑定到由受信任的见证者签名的状态上,以及哪些部分仍需信任。
在付款之前,你的钱包如何知道一个报价是真实的?
代币余额和预留都是在 Quantus 之上计算的。虚假的预留可能让买家为收不到的代币付款,所以负责签名的钱包在购买前,要求的不只是一个未签名的服务器响应。
从固定的检查点重放
QLYP 按顺序解释已公布的激活锚点之后的区块。锚点本身不计在内。相同的输入和规则产生相同的状态。暂定视图在链重组期间可能会变化;购买证明绑定的是已最终确认的检查点。
- 发送 3 QTC区块 #184,222
- 收到 12.5 QTC区块 #184,220
- 01 / 05
区块不断到来
新的 Quantus 区块可能是暂定的,并可能因链重组而被替换。配置的节点会同时报告它的最佳链头和已最终确认的检查点;本图压缩了两者之间的间隔。
- 02 / 05
已最终确认与暂定是分开的
见证证明描述的是已最终确认的状态。最终性由配置的节点报告,而不是在出现一个更新的区块后就默认成立。服务也可能提供暂定状态,这类状态在最终确认前可能发生变化。
- 03 / 05
从固定起点按顺序读取
重放从被排除的激活锚点处的空 QLYP 状态开始。下一个区块是首个解释区块;之后的已最终确认区块按顺序处理,不留空缺。
- 04 / 05
同一条链给出同一个结果
相同的区块和协议规则产生相同的状态。这使重放可复现,但并不能独立验证节点共识,也不能证明某个见证者实现是正确的。
- 05 / 05
见证密钥不是支出密钥
索引器不需要用户的支出密钥就能推导余额。见证者有自己的见证密钥,用于认证状态,无法动用用户账户中的资金。
最终性来自配置的节点。重放状态带来的是可复现性,而不是独立的共识验证。服务可以维护暂定状态,同时把持久保存的已最终确认的检查点与之分开。
两个受信任的见证者
开发部署提供 TypeScript 和 Python 两种见证者实现。购买策略要求两个已配置的见证者运营方对同一个状态根和已最终确认的检查点签名。每个见证者都使用 ML-DSA-87。该策略把公钥、网络、运行时、规则和时效限制绑定在钱包构建中;网站无法替换密钥。
实现彼此分开,降低了共有的实现风险。独立运营和分开的节点基础设施是部署要求,而不是仅凭代码就能确立的属性。签名证实的是这些见证者所证明的内容;它们不能证明见证者诚实,也不能取代链的共识。
新鲜、绑定、绝不回滚
每份见证声明都把它的状态根绑定到网络的创世、激活锚点、运行时、规则、已最终确认的区块,以及由你的钱包选择的一个新鲜的 256 位挑战值。一份声明的有效期最多为 60 秒。钱包还会记住它接受过的最高检查点,因此见证者之后无法向它出示更旧的状态,也无法在同一高度出示两个不同的状态。
选择性证明:只证明你要购买的部分
开发中
选择性证明(QPA2)正在一条开发线上与公开挂单(open listings)一同开发。
当前,钱包在完整的已签名状态中检查预留。下一种证明格式将该状态分为八个分区进行承诺(资产、余额、序列号、多签、用于预留的凭证、代币符号、铭文和挂单),每个分区都有自己的 SHA-512 默克尔树。见证者对一个根签名,这个根覆盖各分区根及其大小。随后你的钱包只接收它要购买的挂单、对应的资产以及它们的包含路径,而不是整个快照。
- 01 / 05
一个条目到达
钱包收到它即将购买的预留,以及检查它所需的证明数据。这棵小树演示了一个条目如何绑定到已签名的状态根上。
- 02 / 05
一个相邻条目加入
与挂单一同到来的,是树中每一层的一个哈希。钱包把挂单与它的相邻条目(紧挨着它的那个条目)一起做哈希。结果是一个同时代表二者的新哈希。
- 03 / 05
逐层重复
它重复这一步:把结果与收到的下一个哈希配对,如此一层一层向上。证明的大小随树的深度增长。这张图只有几个条目;它并不构成延迟保证。
- 04 / 05
到达根
顶端只有一个哈希,即根。它是钱包自己计算出来的,依据的正是它将要付款的那条挂单。它是整个市场的指纹,任何一个条目发生变化,它都会随之变化。
- 05 / 05
见证者的根必须一致
这个根必须与检查点一致,而该检查点由两位受信任的见证者分别用 ML-DSA-87 签名。被改动的条目无法通过证明检查。有效的签名认证的是见证者所证明的内容;见证者不诚实或实现被攻破的风险依然存在。
一条路径在树的每一层最多需要一个兄弟哈希,因此它随分区大小的对数增长:
- 单条路径中的兄弟哈希数(最多)
- 17
- 路径大小,SHA-512
- 1,088 字节
一个有 100,000 个条目的分区最多需要 17 个兄弟哈希。整个回复还包含头部、条目和签名,上限为 256 KiB。收集证明的服务不受信任:它无法替换见证者的密钥,条目缺失就是错误,绝不会被当作空余额。
每项检查都排除一种情况
| 检查 | 它排除了什么 |
|---|---|
| 来自编译进钱包的密钥的两个签名 | 网站或服务器凭空捏造一个状态 |
| 两个见证者对同一个根签名 | 单个出错或被攻破的重放引擎 |
| 新鲜的挑战值,不超过 60 秒 | 重放一份旧的、曾经为真的声明 |
| 已最终确认的区块,绝不早于上次见到的区块 | 在仍可能被链重组或回滚的状态上付款 |
| 在已签名的状态中找到该预留 | 被篡改或凭空编造的条目 |
| 购买交易按已证明的条款构建 | 网站更改价格、数量或收款方 |
钱包在付款前检查什么
- 对照编译进钱包的信任策略,检查所需的见证者签名。
- 在策略的时效限制内,状态根、已最终确认的检查点以及绑定的网络、运行时和规则一致。
- 预留证明和指定买家,然后通过钱包配置的 Quantus 节点,检查原生提案的确切调用、成员构成、批准状态和到期。
- 钱包所构建的购买交易与这些已承诺的条款相符,之后由你在钱包自己的界面上批准。
任何一项必需的检查失败,钱包都会拒绝这次购买。没有购买策略的构建会拒绝购买,并且见证者在主网上仍处于停用状态。有效的证明能证实一个经见证者证明的检查点;它无法保证之后的交易仍会成功。请查看交易的实际结果及其最终性。