先把“特殊地址”转成明确问题
区块链特殊地址的设计文档怎么查，关键是先确定查询对象。“特殊地址”这个称呼本身不足以说明技术性质：需要查清所属区块链、网络，以及想了解的是地址如何生成、由谁控制，还是满足什么条件才能使用关联资产。
查询时可围绕“网络名称、技术机制、待确认问题”组织关键词。只凭地址外观或用途名称，很难确定应查账户规则、合约创建规则还是交易脚本。
以太坊：从账户类型查到生成机制
ethereum.org 的 Ethereum accounts 页面介绍了外部账户与合约账户，以及账户和钱包的区别。两类账户的地址都采用带有 0x 前缀的二十字节表示，因此仅凭长度无法区分控制方式。该页还说明，CREATE 的地址推导涉及创建者地址与 nonce；CREATE2 则涉及创建者地址、salt 和创建代码的哈希。
若问题是“为什么可以预先知道合约地址”，可以沿 CREATE2 这一机制继续查找对应规范；若问题是“谁能操作这个合约”，还需要核对具体合约逻辑。生成规则只能解释地址的来历，不能单独证明权限设置。
比特币：从地址追到输出脚本
Bitcoin Developer Guides 的 Transactions 页面以交易输入、输出和 UTXO 为基础，解释了资产使用条件。其 P2PKH 示例通过公钥哈希与签名验证授权，P2SH 部分则引入了脚本哈希机制。这提供了按输出脚本类型寻找设计说明的入口。
这一查询路径适用于研究比特币输出的授权条件。阅读时应区分地址编码、输出脚本和使用输出时提供的证明，不能把其中一种脚本的示例直接推广到所有地址类型。
让设计说明与具体对象对应
找到文档后，应核对它覆盖的机制、适用网络和版本范围，再确认待查对象是否采用该机制。通用开发文档适合理解模型；涉及具体地址的设计结论，还需要相应的部署记录、代码或交易输出作为依据。
常见问题是把“格式相同”理解成“行为相同”，或把“能提前计算地址”理解成“合约已经部署”。另一个误区是仅凭用途标签判断权限。可靠的解释应分别回答地址如何产生、控制条件是什么，以及有哪些证据能够支持具体判断。