状态证明：把账户数值连接到可信区块根
状态证明能够核验特定字节是否被某个状态根承诺，却不能独自证明这个根来自研究者指定的规范链，也不能说明一个整数就是页面上标注的经济数量。完整证据包应把可信区块、加密路径和字段解释分开，再明确连接起来。
本题只完成一个账户数值与一个历史存储槽的核验。向归档节点询问旧余额是取数任务；拿到候选路径后，对照另行建立信任的区块根检查，才是这里讨论的证明任务。两者可能使用同一家服务，却不能因此被当作两份独立证据。
先把主张落实到确切键
收集证明前，写清网络、账户地址、区块身份和待测数量。“财库持有七个以太币”涉及账户原生余额；“财库在合约中拥有十二个申领单位”则涉及具体存储位置及其经济定义。界面将二者并排展示，不代表它们来自同一个字段。
EIP1186的摘要与Specification部分描述账户与存储证明如何连接区块状态根，返回值包括账户字段、证明节点及各请求存储键的独立路径。该提案标记为Stagnant，实际研究还须记录所用客户端是否支持有关方法和历史参数，不能把提案页面当成所有服务的兼容承诺。
保存原始请求和响应，包括地址字节、槽位字节、区块号、实际区块哈希与取回时间。仅保留显示金额不够：另一个账户或另一个历史区块可能拥有同样的金额，并且各自有完全有效的证明，却回答不了原问题。
区块根必须有独立信任路径
先确定要核验哪个区块，再接收提供方的候选数值。一个可采用的安排是从自行验证的链保存区块头，同时说明节点验证方式和最终性口径；使用其他安排时，也要把依赖的信任假设写出来。两个商业接口若共用上游，并不会自动提供两次独立确认。
把区块头中的状态根与区块哈希、网络身份绑定。时间戳可以帮助定位，却不能代替这种绑定。同一高度在重组后可能对应另一个哈希；若候选证明指向它，应先解决区块身份差异，再讨论余额是否改变。
不能向同一个不受信任接口同时索取证明和根，未核对根的来源就称作独立验证。那最多说明返回材料内部相容。研究者仍不知道这个根是否适用于指定网络和信息截止时点。
在证据表中，把“路径计算通过”和“根已按所述链规则确认”放在两列。前者通过、后者未知时，可以保留计算结果，但发布句子必须保留条件，不能将未知来源的根改写成已经最终确认的网络状态。
先核账户，再核存储槽
使用实现有关以太坊Trie规则的验证器，正确派生账户键、解码节点，并将路径与选定状态根比较。结果至少分为成员存在、有效不存在证明，以及材料缺失或格式错误。普通二叉Merkle树示例不能替代这里的Trie规则。
从已经证明的账户叶中解出nonce、原生余额、存储根和代码哈希，再与JSON便捷字段比较。提供方可能返回正确节点，却在旁边填错显示余额。路径认证的是叶中的内容，而不是任意相邻标签。
随后用这个账户叶承诺的存储根核验槽位路径。若直接拿响应中另行给出的存储根验证槽位，而不验证它属于该账户，就跳过了关键连接。正确链条是：可信状态根连接账户叶，账户叶连接存储根，存储根再连接目标槽。
字段若用于解释合约经济行为，还需要适用的存储布局与代码身份。已经认证的槽整数也可能是配置标志、压缩字段或内部计数，并不会因为显示成数字就自动成为客户资产。
另留存储键推导说明
映射余额的业务标识与实际存储位置不是同一个对象。客户地址可能参与槽位计算，却不能直接当作最终请求槽。应保存历史布局如何把所查持有人或申领标识转换成K的过程，再由Trie验证器检查K的路径。验证器不会替研究者发现应用映射规则。
同时区分应用层槽位置与Trie路径派生，防止前处理已经做过一次转换，验证器入口又被错误转换。输入字节长度、前导零和编码方式应能复查，不能只保留最终整数。若请求了旁边配置槽，即使其证明完全通过且数字恰好符合预期，也无法支持客户余额主张。
假设的两层证明包
设一个虚构测试环境有独立留存的区块头H，其状态根为R。在H下，账户A的原生余额为七乘十的十八次方wei，账户叶承诺存储根S，指定存储键K的整数为十二。这些都是明确假设，不是任何真实财库的数据。
| 核验步骤 | 候选输入 | 应得到的结果 |
|---|---|---|
| 区块身份 | H、网络和R | 与独立留存参照一致 |
| 账户路径 | A及账户证明 | 在R下有效 |
| 账户解码 | 被证明的账户叶 | 余额为七乘十的十八次方wei，存储根为S |
| 存储路径 | K及槽位证明 | 在S下对应整数十二 |
| 显示换算 | 原生余额除十的十八次方 | 恰为七ETH |
| 经济解释 | 历史布局和字段定义 | 确定十二代表什么，或保留未知 |
原生单位换算可以直接复算：7,000,000,000,000,000,000除以1,000,000,000,000,000,000，结果为七。槽整数需要单独的比例。若已核验的布局说明一个存储单位等于百分之一个申领单位，显示数量就是十二除一百等于零点一二，不能写成十二个整枚代币。
做一次改值反检验：保持H、R、A、K和所有节点不变，只把声称的槽值从十二改成十三。验证或与解码叶的比较必须失败。若工具仍显示成功，可能只是确认路径存在，却没有把待核整数与路径内容相连。
再做一次换根反检验：将相同材料放到无关状态根R二下。原本在R下有效的路径不能因格式正确就被接受。保存具体失败阶段，不能把这个人为制造的校验失败解释成真实资产已经减少。
第三个检查可以只改显示比例而不改节点。假设程序将百分之一单位误写成十分之一单位，路径仍会通过，但显示会从零点一二变成一点二。这说明加密完整性与量纲正确性需要分别验证；前者无法修复后者。
有效证明也可能证明错对象
假设提供方交回账户B的完整路径，而B恰好也有七ETH。每个哈希检查都能成功，财库A的主张仍没有得到支持。比较请求地址与实际被证明的键能发现错误，仅比较金额是否合理则发现不了。
另一种边界是代理合约升级。槽位在观察区块中确实为十二，但今天的实现已赋予该位置另一含义。解释必须匹配当时实现和布局。如果缺少这条历史联系，就发布已验证字节，并把字段含义标成未解决，不能用当前界面补齐过去定义。
有效不存在证明也不等于空响应。前者可以在选定根下支持账户或槽位缺失的结论；超时、历史状态已裁剪或方法不支持，只能说明这次没有取得材料。把失败直接填零，会把服务限制伪装成链上事实。
可执行核验表
| 操作 | 保存材料 | 应暂停的条件 |
|---|---|---|
| 确认选定链 | 网络、独立核过的区块头 | 根只存在于候选服务响应 |
| 检查账户身份 | 请求地址、派生键 | 被证明的键不一致 |
| 解码账户 | 叶字段、验证器输出 | JSON显示与叶冲突 |
| 接通两层路径 | 账户存储根、槽路径 | 槽只对照未绑定根 |
| 解释整数 | 历史布局、单位、代码身份 | 字段语义无法建立 |
| 保留重做能力 | 原始节点、参数、验证器版本和错误 | 只剩截图 |
最终结论应具体说明：哪些字节在独立选定的根下得到认证，哪些解释材料把它们连接为命名数量。链身份更正、验证器缺陷、布局修订或同键同根出现冲突材料，都应触发复核。后续区块值改变属于新观察，不应抹掉已经验证的旧状态。
常见问题
路径有效是否说明RPC服务可信？
它只认证已核对象与所选根的关系，不认证服务所有响应、历史覆盖或未经检查的根来源。
槽位证明取不到时能否记作零余额？
不能。应保留取回失败；零值或不存在结论需要对应状态证据和正确字段解释。