RWA 架构：代币化资产背后的系统

在一个现实世界资产平台里，代币合约是最小的一块。一名合格的工程师几周内就能写出并测试完一个受限代币。真正耗时的是围绕它的那些系统：持有人登记册、身份与资格校验、掌握铸造和冻结权限的密钥、用来证明链上与账簿一致的对账机制，以及处理分配和赎回的整套流程。

我们的立场是：RWA 平台应当首先按登记簿记系统来设计，其次才是区块链应用。第一个架构决策是哪一本账具有权威性，其余所有组件的存在，都是为了让其他记录与它保持一致。

可行的模型有两种。第一种以链下登记册为事实来源，链上只是它的同步映射。第二种以链上状态作为登记册，链下系统则是由事件构建出来的读模型。两种都行得通。行不通的是把这个问题悬而不决，因为第一笔有争议的余额出现时，团队就不得不在压力之下给出答案。

对于已经有登记机构、过户代理或法定登记册的资产，我们的默认选择是以链下登记册为事实来源，代币作为与之镜像的受限工具。这样可以处理更正、法院裁定的转让以及密钥丢失后的恢复，而不必假装链上记录是不可更改的法律。当法律结构明确承认链上登记册，并且持有人需要与其他合约进行原子结算时，链上登记册才是正确的选择。这个决定属于发行方及其法律顾问，架构跟随它而定。

带有资格规则的资产，不能做成一个不受限的 ERC-20 再把校验放在 Web 应用里。任何人都可以直接调用合约，所以只在界面层执行的规则等于没有执行。限制必须放在转账路径上，这也是 ERC-3643、ERC-1400 等许可型代币标准所采用的做法。

典型设计会把代币与身份注册表、规则模块分离开来。代币向规则模块询问一笔转账是否被允许，规则模块再去查询白名单以及适用的各项限额。个人数据留在链下：链上只保存钱包地址和资格标记或声明引用，绝不保存身份证明文件。

受限代币上的管理角色可以铸造、销毁、冻结和转移余额。谁控制了这些密钥，谁就控制了登记册。我们会在写合约之前先设计角色模型：铸造、合规操作和升级分别使用独立的密钥，存放在 HSM 或 MPC 方案中，配合多方审批，并对任何改动合约逻辑的操作加上时间锁。

代价是操作速度。一笔需要三位审批人的铸造不可能在几秒内完成，这对发行来说可以接受。但对开户阶段的白名单更新就不可接受，因此这个角色通常权限更窄、自动化程度更高，并带有速率限制。底层资产的托管是另一回事，由托管机构负责，平台与其对接，而不是取而代之。

两本账一定会出现偏差。一笔交易提交后被丢弃；一次链重组抹掉了索引器已经处理过的区块；登记册更新成功而对应的铸造失败。对账就是用来发现这些问题的控制手段，它理应获得与转账路径同等的工程投入。

我们把它做成三方比对：在已最终确定的区块上读取的链上余额、同一逻辑时点的链下登记册，以及托管机构或管理人对底层资产的记录。差异会被分类、指派并跟踪到关闭为止。索引器要等到最终性确认之后才把事件视为已结算，每一次链上写入都带有幂等键，确保重试不会造成重复铸造。

分配、赎回、拆分和登记日在传统登记体系里是例行事务，放到链上却相当棘手。一次分配需要在指定区块对持有人做快照，需要一套以确定性方式处理舍入的计算，还需要一个在部分失败后能够续跑的支付流程。持有人数量一旦增长，在单笔交易里向所有人推送付款就会失败，因此我们倾向于采用领取式模型，或由链下任务驱动的分批支付，并保留完整的审计轨迹。

估值数据、储备证明和参考利率通过数据馈送（data feed）到达链上。数据源的可信程度取决于它的发布方和签名密钥。我们把每一个数据源都当作带有失效模式的外部依赖：数值过期、签名方被攻破、发布方中断。合约在使用数值之前先检查它的时效，限定两次更新之间允许的变动幅度，并在数据源超出容差时停止依赖它的功能。

一个代币代表的是所有权、对发行方的请求权，还是根本无法强制执行的东西，取决于法律结构、发行文件和适用的监管规定。这些都不是由代码决定的。工程能做的，是让一个结构在软件层面可执行、在运营层面可审计，同时应当明确说明它并不创设底层权利。我们按照发行方及其法律与合规顾问设定的要求进行设计，不替代他们的角色。