我们让链来批改自己的算术：升降级折算的零信任设计

先给答案：订阅用户在周期中途升级或降级时，旧套餐没用完的时间要折成一笔抵扣，冲抵新套餐的首期——总得有人算这个数。在你用过的每一个计费系统里，算的人是平台，数是多少全凭它说。在 Finality，后端提出折算数字，链上程序按已承诺的条款独立重算一遍；两边差一丝一毫，交易整体回滚。一次算错——或者一次做手脚——产生的不是一笔错误的扣款，而是没有扣款。这篇讲的是：我们为什么造了一个以"拒绝信任我们自己"为特征的系统。

那个最被信任、却没人验算的数字

折算是计费世界的小字。30 天周期的第 19 天升级，剩下 11 天该折成抵扣，冲进新套餐的第一笔账。每个订阅平台都做某个版本的这件事；几乎没有人审计它。数字出现在账单上，看着挺合理，生活继续。顾客信平台的代码。商户也信——被扣的是他的顾客、动的是他的营收，用的是一套他从没看过的算术。

这套安排一直没事——直到出事的那天，而那天没人能察觉。一个永远朝同一个方向舍入的 bug、一个吃掉一天抵扣的时区边界、一个周期交界处的差一错误：这些都是安静的 bug，发得出去、跑上几个月，最后以一条"是我疯了还是我被多扣了？"的论坛帖子浮出水面。

我们做订阅时，条款焊死在金库地址里，为的就是没有人需要信任一个数据库。在那样的架构上，再拧一个"所有人都信任我们那张表"的环节，就太奇怪了。

零信任在这里的具体含义

Finality 上的一次套餐变更，是顾客签一次名的单笔原子交易：旧金库关闭，连租金押金在内全额退回，新金库带着抵扣开启。在这笔交易内部：

1. 1我们的后端提出数字——剩余时间、抵扣金额、首期冲抵——因为总得有个角色把交易组装起来，这是一份工作，不是一项特权。
2. 2链上程序从零重算折算，只用旧金库里已承诺的条款和链自己的时钟——没有人能悄悄调整的输入。
3. 3任何不一致，整笔交易回滚。不是"记条警告日志"，不是"标记待人工复核"。升级干脆失败，一切原封不动，而那处差异从"安静地错着"变成"大声地摆着"。

这买到的性质，说出来简单，拥有的人极少：我们的 bug 是故障，不是损失。折算代码错了一分钱，没有人会被错扣一分钱——那笔交易拒绝存在。不诚实（或者平平常常的粗心）的失败模式，从"有人不声不响地亏钱"变成了"操作明明白白地不工作"——对别人的钱来说，这才是正确的失败模式。

"可你们两边可能错得一样"

尖锐的反问：后端和链上程序都是同一个团队写的，同一个 bug 不会住在两边吗？比听起来难，原因是结构性的：两次计算面对不同的约束、用不同的语言、跑在不同的环境里——一边为编排优化，一边为按承诺条款做链上校验优化。相关的 bug 有可能；安静的相关 bug 难得多，因为链上那一半是公开的。任何人——商户的审计师、较真的顾客、巴不得看我们出丑的同行——都能读那段程序，亲手验算。我们的算术不只被关进了笼子，还是一只公开展出的笼子。

这就是"我们会仔细复核"（每家正经公司都这么说）和"复核是一个会拦下交易的公开机制"（一个不用问我们就能验证的性质）之间的差别。

为什么这事的意义超出折算本身

折算很小，原则不小。天下的计费纠纷，归根结底都是谁的计算说了算——而天下的答案都是"平台的，你的救济渠道是客服工单"。我们想要一个让这句话失去指涉对象的系统：平台拿不了钱、keeper 超不了条款、商户扣不下佣金，以及——闭环的最后一块——平台赢不了算术之争，因为算术之争的结局是回滚，不是扣款。

叙事系列写到第四篇，那个我们从不同方向反复抵达的模式，可以给它一个名字了：凡是承诺要紧的地方，就移除那个本来不得不被信任的角色——哪怕那个角色是我们自己。尤其当那是我们自己。

FAQ

顾客能感知到这些吗？

他看到的是：升级要么严格按条款完成，要么干净地失败——不存在事后要争的错误扣款。机制平时隐形，想验证时全盘公开。

回滚发生时，运营上会怎样？

链上什么都没变——旧套餐照常运转。我们排查的是一个响亮、可复现的故障，而不是在几个月的账单里搜寻一处无声的差异。回滚丢人但便宜；无声的错误隐形但昂贵。我们选丢人。

只有升级适用吗？

双向的套餐变更——升级和降级——抵扣都按重算后的条款流动。外围的完整生命周期在订阅架构篇。

加密订阅升级具体怎么发生？

顾客签一次名的单笔交易：旧金库关闭（退回剩余与押金），新金库带着抵扣开启——而在这一切被允许发生之前，链先把抵扣重算一遍。

加密计费的按比例折算怎么算？

和刷卡计费同一套算术——未用时间折成抵扣——差别只有一个：平台报的数要过链上程序的复核，不符就回滚而不是扣款。这样做的加密折算，是唯一一种顾客永远不用自己审计的版本。

只能升级，还是也能中途降级？

双向都行——周期中途换套餐，价格向上向下都按同一套重算条款折抵。

我直接取消再重新订阅不行吗？

永远可以——取消退回一切，包括押金——但迁移流程一次签名就把抵扣算清，手动重订严格来说是多干活。

重算的成本谁出？

它在迁移交易的正常执行里跑完——没有额外费用，没有"改套餐手续费"。为"计费事件本身"再计一次费，是刷卡世界的习惯，我们没进口。

大多数计费系统请求你的信任；这一个每次都把作业交上去公开批改。在沙盒里跑一次套餐变更，看那一笔交易做完全部——关闭、抵扣、重开——或者整个拒绝。它只认识这两种结局。