在 NEAR 上注册完一个账户，钱包余额为零是常态，而任何交互都要烧 Ⓝ 手续费——“先充钱才能干活”卡住了大量新用户。NEP-366 给出的解法写进了协议本身：第三方可以发起一笔交易并替你付手续费，官方称之为协议内元交易。规范列举的动机场景很具体：付酬做任务的应用（NEARCrowd、Sweatcoin 这类）、免费游戏，以及已经验证过中继商业模式的 Aurora Plus——它证明了中继者可以提供一定数量的免费交易，再走订阅制。规范同时交代了被否决的替代方案：给用户部署代理合约，代价是用户得先为这个合约付存储成本。
角色设定：用户与中继者互不信任
规范的信任前提只有一句话：用户和 Relayer（中继者）互不信任。所以整条流水线的每一步校验都不依赖对方的善意。参与方三方：用户（委托动作的签名人）、中继者（把委托塞进正经交易的人）、接收合约（最终要执行的目标）。
委托动作的七个字段
用户要签的是一个叫 DelegateAction 的结构：sender_id 是用户自己的账户、receiver_id 是最终接收动作的账户、actions 是一串 NEAR 原生动作的批量列表、nonce 用来防止中继者把同一份委托发两次（按公钥维度校验并递增）、max_block_height 是一个区块高度上限，低于它就作废、public_key 是签名这把委托的公钥。加上签名，合成 SignedDelegateAction，再以 DelegateActionMessage 的格式发给中继者。actions 支持批量的意义，规范点得很直白：创建账户、转入资金、部署合约、调用初始化函数可以在同一笔委托里一气呵成。
一次代付的完整流水
流程分三段。用户侧：签名并打包委托消息，交给中继者。中继者侧：先验算 DelegateAction 里的动作总成本、确认用户是否给自己留了奖励，然后把交易组装成接收方等于用户账户、动作列表装着这份 SignedDelegateAction 的正规交易，用自己的密钥签名并广播——同一笔交易里还可以夹带其他针对用户的动作。协议侧：交易正常处理生成收据；处理 SignedDelegateAction 时跑一遍校验（见下节），通过后在用户账户上执行，执行的效果是再生成一张“看起来就像用户自己发的”收据：前序者是用户账户，但签名人与公钥记的是中继者。
六道校验
规范逐条列出收据处理时的检查：一、委托的 actions 里不得再嵌套 DelegateAction；二、对委托哈希做签名验证，确认签名、公钥对得上；三、交易的接收方必须等于委托的 sender_id——中继者不能把它转投别家；四、max_block_height 必须大于处理时刻的当前区块高度，过期作废；五、sender_id 必须确实持有 public_key 这把密钥；六、委托的 nonce 必须大于该账户这把公钥的当前 nonce，执行后递增，重复投递挡死。
退款归属与限制
费用侧的规则写得很细：手续费（gas）无论用户账户存不存在，都按常规退还给中继者——它垫的；用户账户已存在时，随委托附带的押金（deposit）退回用户，账户尚不存在时这笔押金则被销毁。委托动作不得嵌套，中继者的报酬来自委托中预留的部分——它验算总成本时看的就是这个。顺带一提，带资产的函数调用在 NEAR 规则里会被当作真实用户动作处理，这层 yocto 闸门的思想在 NEAR 转 NFT 为什么要附 1 yocto：NEP-171 的异步模型差异 有展开；押金的来龙去脉可看 NEAR 上先交押金再登记：storage_deposit 与两条退钱的路。用户视角的底线核对：你签的委托里 max_block_height 就是你的时效签——填得太远等于给中继者一张长期有效的空白支票；nonce 对不上会整笔作废，多设备共用同一把公钥时尤其容易撞车。还要注意规范点明的一点：中继者提交的那笔交易里可以夹带针对你账户的其他动作（比如顺带调用某个合约函数），所以当钱包显示一笔来自中继者的交易含多条动作时，逐条对照你签过的 DelegateAction 清单再放行，别把“中继打包”当成“只会执行我那一条”的默认承诺。机制以 NEP-366 规范（Final，Category: Runtime）原文为准，涉及资产的代付与报酬都不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。