基于星云链NAS智能合约的去中心化遗嘱系统设计与实现

简介：星云遗嘱系统是一套基于NAS区块链智能合约的去中心化应用，核心功能是让遗嘱在链上安全托管与执行，适合区块链、智能合约方向的毕设、课设或项目演示，也可供初学者快速理解DApp前后端开发流程。压缩包共53个文件，以15个js、14个jsx、8个scss为主，包含智能合约、前端页面、路由菜单、Docker部署与说明文档，整体体积约38KB。资源已通过测试运行，智能合约与前端联动完整，目录中smart_contract、src、docker等模块划分清晰，方便直接复现或二次开发。目前已有134人学习下载，可借助该项目掌握NAS链上合约编写、web交互实现及容器化部署流程，并在此基础上扩展其他自定义功能。

1. 基于星云链 NAS 智能合约的遗嘱系统到底解决什么问题

先说明一个容易踩的坑：标题里的 NAS 不是群晖、飞牛那种网络存储设备。这里的 NAS 是星云链（Nebulas）的原生代币缩写，整套系统跑在 Nebulas 智能合约上，跟nas存储、飞牛nas 定时重启这类检索词不是一回事。去中心化遗嘱，本质上是把“人出意外之后，链上资产怎么交接”这个现实问题搬上链：立遗嘱人把 NAS 或链上资产锁进合约，设置受益人名单和继承比例，平时通过心跳交易维持活跃状态；一旦超过预设窗口没有任何心跳，受益人就能触发合约，按比例领走资产。

这套设计的核心在于不依赖任何中心化机构判断“死亡”。它把生死问题转成一个可验证的链上约定：只要还能看到你的活跃交易，你就还“活着”。对普通持币者来说，这是私钥失联后的兜底方案；对团队冷钱包、多人共管资金池来说，这是交接预案。想研究 Nebulas 合约开发、或者想做时间锁类智能合约的从业者，都可以拿它当蓝本。

2. 星云遗嘱合约的状态机与 LocalContractStorage 存储设计

2.1 遗嘱对象的核心字段和继承比例建模

合约里要存的不是一份遗嘱文档，而是一组可以被链上代码判定的状态。我一般会把立遗嘱人、受益人、比例、活跃时间、公证人这些要素拆成以下字段：

继承比例不建议直接存小数。Nebulas 合约里 NAS 金额精度是 18 位，小数运算很容易引入浮点误差。常见做法是定一个大整数分母，比如1_000_000表示 100%，受益人写成300_000、700_000，代表三成和七成。链上分配时用“比例 × 合约余额 ÷ 分母”的整数运算，能保证不出现精度损耗。

2.2 生死判定逻辑：从“死后生效”到“超时未响应”

去中心化系统没有可靠的官方死亡证明接口，所以这套合约把继承触发设计成反向判定：默认立遗嘱人活着，直到他被证明没有持续活跃。判定条件只有一行核心逻辑：

canClaim = Blockchain.block.height > lastHeartbeat + timeoutWindow;

这个条件在claim函数中作为守卫，任何受益人都可以在超时后调用它。合约骨架采用 Nebulas 常见的对象式写法：

'use strict'; var WillContract = function () {}; WillContract.prototype = { init: function (owner, timeoutWindow) { this.owner = owner; this.timeoutWindow = timeoutWindow; this.lastHeartbeat = Blockchain.block.height; this.status = 'ACTIVE'; this.beneficiaries = '{}'; this.notaries = '[]'; this.notaryCount = 0; }, heartBeat: function () { if (Blockchain.transaction.from !== this.owner) { throw new Error('only owner can send heartbeat'); } this.lastHeartbeat = Blockchain.block.height; }, claim: function () { if (this.status !== 'ACTIVE') { throw new Error('will already closed'); } if (Blockchain.block.height <= this.lastHeartbeat + this.timeoutWindow) { throw new Error('owner still active'); } this._distribute(); } }; module.exports = WillContract;

代码里Blockchain.block.height取当前块高度，Blockchain.transaction.from取调用者地址。init传入的timeoutWindow表示立遗嘱人能忍受的失联高度数。注意heartBeat必须在每个窗口期内至少被调用一次，否则窗口一旦越过，任何知道合约地址的人都能调claim触发继承。这里也暴露出另一个问题：合约不能用“人活着”证明，只能用“未超时”来反推，所以心跳是整套系统的命脉。

2.3 LocalContractStorage 读写与地址精度踩坑

Nebulas 合约的持久化依赖内置对象LocalContractStorage，读写方式与普通键值对一致，但有几个细节容易踩。对象和数组必须先JSON.stringify再存，否则取出来会丢字段；字符串比较要用全等，地址格式不一致就会拒绝执行。

function _setBeneficiaries(beneficiariesMap) { LocalContractStorage.set('beneficiaries', JSON.stringify(beneficiariesMap)); } function _getBeneficiaries() { var raw = LocalContractStorage.get('beneficiaries'); return raw ? JSON.parse(raw) : {}; }

金额和资产计算建议用字符串存，需要运算时再转成整型。直接拿 JS 的Number处理 18 位小数会在边界溢出，最终到账金额对不上。这个坑在分配逻辑里最常见，排查起来不难，但第一次跑测试网很容易被它拖慢进度。

另外说明一点：链上遗嘱不等于法律遗嘱。它只保证链上资产按代码执行，现实中如果要作为有效遗嘱，还需要线下公证或者其他合规流程配合，两者是互补关系。

3. 用 neb.js 在测试网部署 NAS 智能合约并写入受益人

3.1 环境准备：Node.js、nebulas SDK 与测试币

开发这类合约最顺手的路径，是用官方nebulasnpm 包在 Node.js 里完成部署和调用。先创建空目录再装依赖：

mkdir nebulas-will cd nebulas-will npm init -y npm install nebulas

装完后在脚本里直接引入客户端对象：

var Neb = require('nebulas').Neb; var neb = new Neb(); neb.setRequest(new Neb.HttpRequest('https://testnet.nebulas.io'));

这里的 RPC 地址是示例写法，实际使用哪个公共测试网节点以当前可用的官方文档为准。测试网开户后要从水龙头领测试币，因为部署合约和每次调用都要消耗 NAS 作为手续费。脚本要提前确认地址有余额，否则会报 gas 相关错误。

3.2 部署合约的完整脚本与 gas 参数

部署就是把合约源码作为参数提交到链上，等待返回交易哈希和合约地址。常见做法是把合约源码存到contracts/will.js，再交给neb.api.deploy：

var fs = require('fs'); var source = fs.readFileSync('./contracts/will.js', 'utf8'); var deployArgs = { chainId: 1001, from: process.env.WILL_OWNER, gasPrice: '1000000000', gasLimit: '200000', value: '0', contract: { source: source, sourceType: 'js', args: JSON.stringify([process.env.WILL_OWNER, '180']) } }; neb.api.deploy(deployArgs).then(function (resp) { console.log('txHash:', resp.txhash); }).catch(function (err) { console.error('deploy failed:', err); });

args对应合约init的参数，第一个是立遗嘱人地址，第二个是失联窗口高度数。示例里的 180 是方便快速验证的临时值，你可以按实际出块速度换算。gasPrice是每单位 gas 的价格，gasLimit是合约执行允许消耗的上限。合约源码大、初始化逻辑多时，gasLimit要放大，否则部署会中途失败。

部署交易上链后，需要等几个块确认，再通过txHash查询合约地址。这个地址是后续所有调用和查询的唯一入口，建议部署完立刻记到deploy.json里。

3.3 调用 setBeneficiary 与 heartBeat 的方法签名

合约部署完成后的写入操作，走neb.api.sendTransaction。以设置受益人比例为例，参数按顺序传给args数组：

var callArgs = { chainId: 1001, from: process.env.WILL_OWNER, to: process.env.WILL_CONTRACT, value: '0', gasPrice: '1000000000', gasLimit: '100000', contract: { function: 'setBeneficiary', args: JSON.stringify(['N1xxxxxx...', '300000']) } }; neb.api.sendTransaction(callArgs).then(function (resp) { console.log('txhash:', resp.txhash); });

setBeneficiary内部必须校验Blockchain.transaction.from是否等于this.owner，否则任何人都能把自己写成受益人。参数里value固定填'0'，资产进合约是在建遗嘱时单独转账完成的，不通过受益人接口附带。读取受益人列表则用neb.api.call走只读调用，不消耗 gas，适合前端展示。

部署和调用阶段的 gas 参数，建议按下表先跑通再调优：

3.4 查询合约状态的只读调用与失败排查

只读查询在 web 端也常用，除了 NebPay 支付流程之外，合约状态统一走call接口：

neb.api.call({ chainId: 1001, from: process.env.WILL_OWNER, to: process.env.WILL_CONTRACT, value: '0', gasPrice: '1000000000', gasLimit: '50000', contract: { function: 'getSummary', args: '[]' } }).then(function (resp) { var result = JSON.parse(resp.result); console.log(result); }).catch(function (err) { console.error('query error:', err); });

遇到查询失败或执行失败，优先看错误消息。大部分情况是合约主动throw，比如“owner still active”，说明当前还没越过失联窗口。如果错误是 gas 相关的，就检查地址余额和gasLimit。测试阶段可以把timeoutWindow设成 3 个高度，跑通整个主流程后再恢复成正式值。

4. 心跳、撤回与多签公证：NAS 智能合约的三层守卫机制

4.1 心跳续期的时间窗口设计

失联窗口如果按时间戳设计，容易被矿工通过操纵区块时间戳打边界攻击；按块高度则没有单点时间源问题，所以这里统一用lastHeartbeat + timeoutWindow。配置窗口时，要覆盖立遗嘱人可能出现的最大离线场景，比如出差、生病、忘记操作，一般建议按“出块速度 × 期望天数”换算，再乘 1.5 到 2 倍留余量。

心跳本身不涉及资金转移，只需要重写一次lastHeartbeat：

heartBeat: function () { if (Blockchain.transaction.from !== this.owner) { throw new Error('only owner'); } if (this.status !== 'ACTIVE') { throw new Error('will not active'); } this.lastHeartbeat = Blockchain.block.height; Event.Trigger(Blockchain.contractAddress(), 'heartbeat', 'owner renewed alive'); }

Event.Trigger会把心跳事件广播到链上索引，前端靠监听这个事件来更新“最近活跃”状态。如果合约余额较大、心跳又频繁，要给心跳操作留预算，因为每次调用都消耗一笔 gas。用定时任务每天调一次最省，还能顺便检查地址余额是否足够后续操作。

4.2 立遗嘱人撤回与更换受益人

活着的时候一切都要可逆，这是遗嘱系统的基本约束。受益人名单可以随时改，遗嘱也可以整体撤回，撤回后合约内资产全部退回owner，合约状态置为REVOKED：

revoke: function () { if (Blockchain.transaction.from !== this.owner) { throw new Error('only owner can revoke'); } this.status = 'REVOKED'; Blockchain.transfer(this.owner, Blockchain.getBalance(Blockchain.contractAddress())); }

Blockchain.getBalance(Blockchain.contractAddress())取合约地址当前余额，返回的余额同样要按字符串或 BigNumber 处理，不能直接拿 JS 数字做全等判断。撤回之后如果想重新启用，只能重新部署一份合约再设置受益人，这种“不复活”的设计让状态机更简单，也避免合约里残留不可见字段。

4.3 多签公证人通道：不等超时的主动死亡确认

只靠超时被动触发有两个现实问题。一是资产要等窗口走完才能动，紧急情况下等不起；二是窗口期内 owner 的私钥若被他人控制，恶意续心跳就能永远锁住资产。所以我会加一个多签公证人通道：owner 预先指定几个可信地址，当签名数达到阈值时，合约立即结算，不用等超时窗口：

approveDeath: function () { var from = Blockchain.transaction.from; var notaries = JSON.parse(LocalContractStorage.get('notaries')); if (notaries.indexOf(from) < 0) { throw new Error('not a notary'); } var confirmed = JSON.parse(LocalContractStorage.get('confirmed') || '[]'); if (confirmed.indexOf(from) >= 0) { throw new Error('already confirmed'); } confirmed.push(from); LocalContractStorage.set('confirmed', JSON.stringify(confirmed)); if (confirmed.length >= this.requiredNotaryCount) { this._distribute(); } }

_distribute: function () { var beneficiaries = JSON.parse(this.beneficiaries); var totalBalance = Blockchain.getBalance(Blockchain.contractAddress()); var denominator = 1000000; // 按比例逐个转账，全部转完后将状态置为 CLAIMED for (var addr in beneficiaries) { var amount = new BigNumber(totalBalance).times(beneficiaries[addr]).dividedToIntegerBy(denominator); Blockchain.transfer(addr, amount.toString()); } this.status = 'CLAIMED'; }

_distribute里用BigNumber做乘除，避免浮点误差。denominator对应初始化时约定的比例分母。分配中即使某个地址转账失败，也不会回滚前面已经成功的交易，所以建议在分配前先用事件把受益人名单和快照余额记录下来，方便对账。

三种触发方式的适用场景可以按下表选型：

一般生产配置会把多签通道和超时通道同时打开：多签负责紧急处理，超时负责兜底。某个公证人失联也不会卡死流程，只要剩余公证人凑够阈值就能继续执行。

5. 资料包的目录组织、回归脚本与交付前安全检查

5.1 一份可被接手者直接复用的 zip 目录

拿到这类“全部资料+详细文档.zip”包，先看 README，再看 contracts 和 scripts。可维护的目录通常长这样：

docs/design.md // 状态机、字段、触发流程说明 contracts/will.js // 合约源码 scripts/deploy.js // 部署脚本 scripts/interact.js // 调用、查询、心跳脚本 test/regression.js // 最小回归验证脚本 frontend/ // DApp 页面与 NebPay 接入 README.md // 环境、命令、注意事项

5.2 用回归脚本验证窗口内的每一次状态迁移

接手后的第一件事是跑回归。把timeoutWindow调成 3 个块高度，循环执行“部署 → 设置受益人 → 心跳 → 等待超时 → claim → 检查余额”，全部通过再改回正式窗口。这个动作能把状态机边界、owner 校验、转账精度一次验证完。

5.3 交付前必查的 5 项合约安全检查

• 每个写方法都校验Blockchain.transaction.from，确认没有可被路人调用的敏感入口；
• 受益人比例加总必须等于分母，否则余额分配后会有资金滞留；
• claim执行前检查status，防止重复领取；
• 金额运算用字符串和整数，不用Number直接处理 18 位小数；
• Event.Trigger在领款前触发，保证链上可追踪到每笔分配。

交付文档里我会把成功跑通回归的 txhash 和 gas 实测值一起贴进 README，接手的人照着同样的命令复现一遍，才算真正验收完成。验收时把timeoutWindow调小跑通全流程，记录那次交易的 gas 消耗，再恢复正式窗口值，这个参数组合会成为后续每次改动后的回归基准。

本文还有配套的精品资源，点击获取