OTP-001：支持的接口
本建议书推荐了一种自省智能合约并找出它们支持哪些接口的方法。
动机
现在，我们无法猜测用户想用合同做什么，也无法弄清交易的内容，因为没有明确的方法找到合同的内容。 在大多数情况下，人类需要记住或猜测这是怎么回事。
指南
当人类试图签署一项交易时，他们需要清楚地了解自己在做什么：铸币、代币转移、盯盘、DAO 投票。 虽然以太坊钱包支持签署任意结构，但仍不清楚您签署的是什么以及这样做的影响。 同样，探险家也无法以漂亮的形式展示正在发生的事情。
与具体合同打交道的开始就是进行反省—弄清合同对自身的声明是什么。 当应用程序知道这份合同的内容时，它就可以建立一个良好的用户界面，显示交易历史，并验证人类试图签署的内容。
该提案描述了一种报告合同支持哪些接口的方法。
接口是以自由格式的规范定义的。 与其他大多数方法不同的是，本提案不仅将接口定义为合约的技术接口（获取方法、内部信息等），还将其定义为合约行为的描述。 附加合同技术接口的散列表示可能会导致不同标准之间的冲突，因此该提案对接口的定义比较松散。 此外，它还能使接口更加流畅，例如，无法传输的令牌可以只是一个合约，它必须获得返回 “false “的方法 “can_transfer”，这将意味着该令牌根本不支持传输，而无需实现该方法。
接口 ID 是反向域名的哈希值（就像 Java 中的软件包），这样可以避免不同团队之间的名称冲突，如果他们只想为自己构建一些东西的话。
规格
为了支持自省，合约必须实现 supports_interface GET 方法：
(int...) supported_interfaces()
返回支持的接口代码列表。 第一个值必须是 hash("org.ton.introspection.v0") = 123515602279859691144772641439386770278。
如果第一个值不正确，应用程序必须停止尝试反省合同。
示例
_ supported_interfaces() method_id { return (123515602279859691144772641439386770278);}接口的哈希值定义为截断为 128 位的 SHA256。
缺点
这项建议并不能保证合约对接口的正确执行，也不能保证避免不同接口之间的名称冲突。 这不是本提案的目标。
这项建议与特定的技术接口无关。 这可能导致多个接口做同样的事情，但 ID 不同。 这不是本提案的目标，因为集中式注册表对现有接口非常有用，而自定义注册表则主要在内部使用。
理由和替代方案
- 为什么是 128 位？ 我们需要在不发生冲突的情况下保留一个全局命名空间，我们不能使用小得多的命名空间，因为发生冲突的可能性会高得多。 我们正在研究类似 UUID 的熵，它正好是 128 位，并且经过时间验证。 超过 128 太浪费了。
- 为什么是自由形式？ 如前所述，定义一些 ID 更容易尽早开始工作，然后最终建立一个标准。 此外，接口（如 ERC20）通常不仅仅是一个技术接口，还包括一些如何使用它的规则。
- 为什么不通过反编译找出合同支持什么？ 在开放世界场景中，明示总比暗示好。 我们不能依靠自己的 “拆解 “能力来进行反省，即使是很小的错误也可能是致命的。
- 为什么不是散列代表？ 目前还没有编译器支持这一点，而且这项建议是面向未来的。 如果有人想构建更自动化的东西，他们可以很容易地按照自己的规则构建自己的哈希值，对外部观察者而言，一切保持不变。