Parano1d v2：从现存价值到有效权利

把一个钱包密钥交给自动化程序，意味着把这个密钥能做的事情一并交出去。真正的应用通常需要更细的授权：每次最多花多少，一个周期总共能花多少，何时允许领取下一笔款项，又由谁在期限之后收回余额。

这些条件描述的都是仍然有效的权利。它们来自过去的操作，但将来加入网络的人，不应该仅仅为了确认今天还剩下什么权利，就必须接收并重放所有旧操作。

在《跨越时间的去中心化》中，我讨论过将 proof-carrying State 从货币延伸到权利和义务。Parano1d v2 实现了一个具体的合约核心：活跃输出承诺程序、授权规则与当前计数器，每次被接受的变化都在统一递归区块关系中得到证明。

当前有效的权利，携带着产生它的有效演变路径。

这使合约在旧交互的交易体被裁剪后，仍然可以独立验证。应用能够使用可编程规则，而不必把每一次已经结束的交互，变成所有未来节点都要永久保存的记录。

这些合约同时沿用了 Parano1d 的后量子授权与证明体系。无论使用模板还是自定义程序，“谁有权调用”和“状态可以怎样改变”都在同一套安全模型内。下文会说明其中的密码学机制，以及公开安全评估所依赖的假设。

这里的“权利”有明确含义

普通输出把一笔金额绑定给所有者，花费时需要对完整交易提供有效授权。合约输出进一步承诺：哪些主体可以采取什么动作，款项可以付给谁，金额和高度满足什么条件，下一状态中的计数器应当如何变化。

这里所说的权利，是在满足条件时消耗一个确定活跃输出的协议权限。共识对原生价值执行这些规则。如果某项权利还意味着使用外部服务或完成现实中的义务，那层含义由具体应用定义。

于是，当前存在的价值、下一次允许的变化，以及某次过去变化的证据，就成为三个不同的对象。把它们区分开，才能在保留独立验证的同时，让当前状态承载更丰富的规则。

活跃状态中实际保留什么

全局活跃记录包含金额、所有者承诺和创建标识。对于合约，承诺绑定不可变的程序与策略，以及两个持久计数器。公开开示数据提供这个承诺背后的完整内容。

ABI 3 的规范开示长度为 699 字节，包括 16 条指令、计数器对、领取与恢复权限、对应的关闭收款人、期限高度和支付限制。程序、策略与对象状态使用不同的哈希域进行绑定，不需要另建一个带有永久操作历史的全局合约账户。

持续调用保持程序与策略不变，可以更新计数器。计数器改变会产生新的承诺，因而也可能产生新地址。钱包按照不可变条款把这些状态归为同一合约，方便用户理解；共识验证的仍然是具体状态的精确承诺。

输入还必须精确到实例。槽位释放后可以复用，因此 slot_index 不能独自标识一个旧输出。它与 creation_id 共同区分现在的实例和曾经占据同一位置的对象。

先定义条款，再注入价值

任何人都可以在本地构造、检查、保存和分享条款。保存程序本身无需广播注册交易，也不收取创建费用。

注资是一笔独立的普通付款，目的地址是合约承诺。它建立真正拥有价值的活跃实例。条款文件本身不能证明已经到账；钱包从经过认证的 State 查询资金，注资回执则保存这笔付款发生过的证据。

每次注资建立独立实例。向相同条款付款两次，并不会自动形成一个共享计数器或共享预算。两份资金各有自己的状态，一次调用只消耗一个实例。需要全局支出上限的应用，必须在设计时处理好这个边界。

活跃输出还必须有正金额。余额为零的合约不能继续占用一个免费的独立存储记录。

权限如何决定下一步

实际打包高度决定使用哪个授权分支：期限之前使用领取分支，从期限高度开始使用恢复分支。两个分支分别规定能否持续调用或关闭，不存在隐含的管理员权限。

具有对应权限的一方，通过新生成的授权胶囊证明自己知道花费秘密，胶囊绑定完整交易。即使拥有这个秘密，也不能绕开程序、任意修改不可变策略或更换关闭收款人。

输入价值必须完整分配给保留金额、付款和手续费。关闭时不再保留合约余额，接收方得到输入扣除手续费后的剩余部分。

执行为什么是 proof-native

钱包先展示具体调用，mempool 进行接收与冲突检查，出块者随后证明完整状态转移。合约规则就在这份转移关系中执行。

区块关系检查开示是否匹配被消耗的承诺、所选权限是否成立、整数程序如何执行、输出形式是否被允许，以及全局 State 的写入是否精确。新的 HistoryStep 同时把前序证明的有效性继续向前传递。

因此，合约执行的可信依据就是使区块状态转移成立的证明。提前进入 mempool 不能取代它，生产者宣称“程序执行成功”也不能取代它。

所有应用共享解释器与冻结的区块矩阵。符合现有核心的新程序无需生成专属矩阵，也无需为每个合约额外构造独立的执行证明。交易授权仍然提供自己的新钱包证明，这两层职责不能混为一谈。

旧交易体最终可以被裁剪，当前 State 与递归认证的连续性继续保留。后来加入的节点验证这种连续性，无需重放合约存在以来的每次调用。当然，它仍需下载活跃状态并验证链的排序；证明不会免除当前数据和工作量证明本身。

长期有效的权利，也需要后量子保护

金库可能锁定多年，恢复权限可能直到期限届满才首次使用，受益人也可能分很多次领取款项。这些安排要求参与者的权限和约束资金的规则持续有效。对这样的合约而言，后量子安全直接关系到将来还能否按原定条件行使权利。

授权采用 Parano1d 的无签名所有权机制。授权方地址通过 Poseidon2b 绑定一个 256 位秘密。调用时，钱包生成新的随机化零知识证明，证明自己知道对应秘密，并将授权绑定到这笔确切的交易。秘密不会公开；替换收款人、金额、手续费或输入集合都会使授权失效。领取和恢复两条路径都使用这套机制，无需椭圆曲线花费签名。

区块证明进一步约束策略与程序的执行。因此，安全分析同时覆盖伪造权限和证明非法状态转移的攻击。整数程序只是在共享递归关系中增加确定性约束，无需为每个应用另建一套密码学协议。只要程序在现有核心范围内，自定义应用就与内置模板使用同一套经过分析的授权和执行机制。

公开的 v2 安全模型给出在明确假设下达到 NIST PQC Category 1 的资源评估。这些假设涉及证明根之间的组合、理想编译器、固定的 Poseidon2b 实例、量子攻击资源计量，以及对已认证旧矩阵的诚实预处理。推导文档把钱包授权、递归历史和允许移除旧矩阵的归约一并纳入计算。删除旧数据，并不会把对应的密码学风险从分析中一笔勾销。

这为应用提供了共同的后量子基础：支出额度、延后领取和到期恢复，都可以直接表达为经过证明的状态转移。证明严格执行的是已经承诺的程序，因此开发者仍需正确设定规则，参与者仍需保管秘密，并保存后文恢复流程所需的公开条款与回执。

一个有具体数字的预算

假设自动化客户端得到一个注入了 100 NOID 的实例。策略把单次付款限制为 3 NOID，另设手续费上限、保留余额和独立恢复权限。程序再加一层限制：一个高度周期内，付款加手续费最多消耗 10 NOID。

两个持久计数器分别保存剩余预算与下一个周期边界。客户端在本周期内支付 2 NOID，并支付 0.01 NOID 手续费。成功后，实例余额为 97.99 NOID，本周期预算剩余 7.99 NOID。两个数值含义不同，却由同一次转移共同证明。

下一次调用不能重新声明预算仍有 10 NOID，因为它的开示必须对应上一操作产生的活跃承诺。超过单次限额的付款会失败；重复消耗同一实例会失败；替换程序也会失败。

到达保存的周期边界后，下一次成功调用重置预算，并把新边界设为本次打包高度加周期长度。未使用额度不累积。这是由调用启动、以高度计量的窗口，应用不应把它描述成每天午夜自动重置。

即使这些旧调用体已经删除，当前 7.99 的预算仍由承诺和递归证明认证。未来节点不用寻找保存了第一笔付款的档案服务，也能确认当前状态来自有效执行。

这个例子只适用于一个注资实例。两个实例就是两份独立预算，应用必须明确决定是否允许这种并行授权。

一个小而真实的执行核心

程序预算为 16 条顺序指令、两个持久 u64 计数器和两个临时寄存器。临时寄存器每次调用从零开始，后续指令能读取前面指令的写入结果。

操作包含复制、经过检查的加减法、最小值与最大值、比较和断言。操作数可以引用寄存器、整数常量、打包高度、金额与手续费、分支标记、收款人承诺的组成字，以及精确的实例和槽位标识。谓词决定某条指令是否执行。

溢出、下溢、失败的断言或非布尔谓词都会拒绝调用。核心没有循环、无限存储和外部网络访问，因此执行成本可以被纳入固定的区块关系预算。

自定义程序尤其要注意物理输出位置。持续调用的输出 0 是后继合约，输出 1 是付款；关闭时，输出 0 已变成付给关闭收款人的金额，输出 1 不存在。处理两种模式时必须正确使用 terminal 标记，不能把 RPC 界面中的语义“付款”直接等同于程序的输出 1 操作数。

关闭仍然执行程序并遵守手续费上限，但持续付款的金额上限和最小保留金额，不会自行限制关闭时提取全部余额。编写策略时，应检查每个允许的分支，特别是恢复与关闭路径。

六种模板，面向实际用途

模板把常见需求编译到同一个整数核心。模板名称只是钱包的便利入口，并不是共识中的应用许可名单。

单次限额与周期预算不能互相替代。定期付款不会补发所有错过的周期，新期限是成功领取高度加周期长度。分期解锁则从原定的到期高度向前推进一个周期，所以遗漏的份额可以逐次调用领取。

这些计划都需要有人提交授权交易。钱包、机器人或服务可以负责提交，共识不会运行一个自动唤醒并付款的定时器。界面中 1 NOID 的 max call fee 表示允许的手续费上限，保存条款本身不会因此收取 1 NOID。

当前状态、过去回执、本地记录

一个常见误解，是把这三类信息当成同一本全网账本。它们实际回答不同的问题。

回执证明过去发生过某次调用，不保证其输出今天仍未花费。当前 State 可以显示某个已知承诺下是否还有资金，却不需要提供该承诺的完整历史过程。

用户可以把付款或调用回执交给服务方，由服务方自己的节点验证，再决定是否开放外部资源。这种应用层衔接很有用，但并不意味着 v2 程序本身能读取任意历史回执、调用其他合约或访问预言机；当前核心没有这些操作。

一方离线之后如何恢复

Alice 建立条款并注资，再把公开文件交给 Bob。Bob 检查自己的角色和当前余额后保存合约。在线钱包观察已知条款时，可以保留双方发起的相关调用。

Alice 离线期间，Bob 完成了一次改变计数器的合法调用，并保存回执。Alice 回来时，原交易体可能已经被裁剪。她的节点仍能验证当前 State，但仅凭旧承诺无法找回自己不知道的后继开示。哈希可以验证别人提供的数据，不能重新创造所有人都未保留的数据。

Bob 可以发送合约回执，或附带该更新的合约文件。Alice 验证并导入后继条款或关闭证据，再查询当前状态。导入会合并已验证信息、按交易 ID 去重，同时保留她自己的操作记录和本地名称。旧开示不会覆盖已知的较新活跃状态。

共享合约文件只包含条款及最多一张匹配回执，并非整个操作日志的同步格式。其他需要交换的记录应逐张导出回执。普通付款回执，包括注资，使用普通回执接口；合约交互回执使用合约工作流。

备份因此必须同时覆盖钱包秘密与公开合约资料。秘密恢复权限，条款与回执恢复行使权限所需的信息。如果所有持有者都丢失了开示，又没有保留的交易体或回执可以补充，承诺本身无法还原程序。

从核心到可操作的产品

官方 GUI 的入口是 F7 Contracts。Create 用于选择模板或编写程序，并检查注资；My Contracts 提供已保存合约、余额、操作、规则和日志；Open File 接收条款、更新和合约回执。设置移到 F8。

CLI 与 RPC 提供相同的主要流程。应用集成应围绕“审阅后的调用”展开：previewObjectCall 返回具体输入、费用、输出、后继状态及提交校验条件。链顶变化可能改变打包高度、授权分支、输入可用性或输出位置。交易内容改变后，调用方需要重新审阅并授权。

提交还不等于确认。冲突调用可能先消耗同一实例，允许范围内的重组也可能替换近期确认。钱包据规范链区块头和当前状态重新检查，不能把一个旧界面标签当成最终证据。网络维持 18 个区块的终局边界和最多 17 个区块的回滚。

GUI 指南、API 指南和核心及 ABI 文档给出了具体入口。在现有核心范围内增加应用，无需向某个注册机构申请，也无需为网络更换矩阵。

明确的能力与容量边界

V2 两类区块均允许 63 次调用和 504 个有效输入。Small 有 63 个用户页，Large 有 206 个。每次调用用掉一页和一个输入，因此 Large 能在同一输入上限内，容纳 63 次调用加 143 笔单页付款。需要额外强制系统页时，它会占用一个位置。

按 30 秒目标，调用上限为每秒 2.1 次。程序没有跨合约调用、任意状态数据库或原位升级代码的机制。规则允许的转账可以把价值移入新条款；新增核心操作语义则需要进一步的共识变更。

最适合立即构建的，是状态小、权限清楚、支出有边界，而且参与者愿意保存证据的已注资协议。更复杂的服务可以在核心之外协调多项权利，同时让每个链上实例的授权和价值限制分别受到验证。

让可验证的当下具有程序含义

现在，State 可以表示尚未用完的授权预算、有效的恢复路径、下一次付款期限或受益人尚未领取的份额。每一种当前状态都与遵守规则的先前转移相连。

这为证明原生应用提供了实际起点：有效义务占据活跃状态，已经履行的义务不必自动成为所有未来节点的永久执行档案。需要证据的人与服务保留证据，后来加入者仍可自行确认当前网络的有效性。

现存价值是起点。有效权利让同一个可独立验证的当下，拥有了可编程的使用规则。