NEAR FunctionCall结构args字段格式判定及二进制解码方法问询

字段类型差异说明 #

near_primitives::views::FunctionCall 属于RPC视图层的结构定义，将args声明为String类型是为了适配HTTP API的传输要求，属于上层封装；链上实际存储的交易动作 transaction::Action::FunctionCall 对应的args字段为原生Vec<u8>字节数组，NEAR协议本身不对该字节数组的内容格式做任何强制校验。

1. args字段合法JSON/二进制格式的适用场景 #

• 合法JSON场景：绝大多数公开的NEAR生态合约都遵循官方开发规范，使用JSON作为参数编码格式，此时args可以被解析为合法JSON字符串。这类场景包括但不限于：使用near-sdk-rs/near-sdk-js默认参数解析接口开发的标准合约、官方生态的DEX/NFT/DeFi等合规合约、对外提供公开调用入口的服务类合约。
• 二进制格式场景：合约开发者为了优化链上存储成本、降低序列化/反序列化的Gas消耗、或者满足加密传参等特殊需求时，会选择自定义二进制编码格式，此时args就不是合法JSON。这类场景包括但不限于：高频交互的链游合约、需要加密传参的隐私类合约、追求极致性能优化的底层合约、使用Borsh/Protobuf/MsgPack等二进制序列化方案的合约。

2. 二进制格式的解码规则 #

• 编码格式完全由合约开发者自主决定：NEAR协议层不会对args字段的内容做任何格式校验，只要是合法的字节数组都可以上链，支持任意自定义的二进制格式，没有统一编码约束。
• 解码方案：
  • 首先需要获取对应合约的接口规范：如果合约公开了ABI/接口文档，优先按照文档指定的编码格式实现反序列化
  • 针对NEAR生态最常用的Borsh二进制序列化方案，可以通过合约公开的IDL文件生成对应结构的反序列化代码，直接传入args字节数组完成解码
  • 没有公开文档的自定义二进制格式，需要逆向合约执行逻辑，或者联系合约开发者获取编码规则后才能完成解码

内容的提问来源于stack exchange，提问作者Matt