同是十六进制，表达对象可能不同
查阅rpc区块链资料时，可以先把通用JSON-RPC对象结构与具体链的字段规则分开。JSON-RPC规定请求和响应怎样组织；以太坊文档再说明一些参数和返回值的编码含义。本文只讨论文档阅读，不连接节点、发送交易或测试第三方接口。
以太坊执行客户端相关文档区分数量与未格式化字节数据。两者都用0x前缀，却不是同一种表示法。数量采用紧凑的十六进制形式，不能随意保留前导零；字节数据则按每个字节两个十六进制字符表示。判断格式前，应先找到该字段被定义成哪一类。
零值与空字节不是同一个写法
在上述约定中，数量零写作0x0；空字节序列可以写作0x。若把一个字节的零表示为字节数据，则写作0x00。它们看起来只差几个字符，但含义与长度条件不同，不能为了界面整齐而统一补零或统一删零。
例如，数量0x12表示十进制18；若字段要求两字节数据，0x0012保留的前置零字节就是内容的一部分。这是作者按编码规则构造的对照，不是链上实测响应。若某方法另外要求固定长度，还要继续核对该方法文档，不能只凭字符数为偶数便认定参数有效。
请求编号不是区块高度或交易身份
JSON-RPC 2.0中的id用于关联请求与响应，正常可识别请求的返回应带回对应值。它不自动承担交易哈希、区块号或业务流水号的含义。应用即使选择某个数字作id，也不能据此认定链上存在相同编号的对象；这是协议字段职责的区别。
这一点在批量调用中尤其重要。规范允许响应数组采用不同于请求数组的顺序，客户端应按id建立对应关系。假设发送两个请求分别标为readA和readB，先收到readB的结果并不说明数据串位；直接把数组第一项填入第一个展示框，才可能造成应用层错配。例子只是纸面说明，未运行请求。
没有编号的通知不提供确认回执
规范把没有id成员的请求定义为通知，服务器不应为通知返回响应。不能把“省略id”当作仍然能够获取确认结果的普通调用方式，也不能从没有响应反推操作一定成功。这里解释通用协议语义，不表示某个以太坊服务一定支持读者设想的通知用途。
因此，整理接口说明可分别记录字段类型、编码要求、方法支持范围和响应关联方式。这是作者的阅读清单，不是新的协议要求。十六进制字符串格式正确，只能解决编码这一层；id正确只能帮助配对，二者都不能单独证明业务结果、链上最终性或某个资产记录有效。