ToIP信任跨层协议
接上文, 本文说说ToIP的信任跨层协议。
我们知道信任跨层也就是第二层，整个操作过程见下图：
该协议的主要功能是，借助可信消息，在所有的端点系统之间构造通用的可信点到点通信。 这种架构选择基于以下考虑：
- 现有的互联网、本地网络和网状网络基础设施已经通过各种类型的传输机制支持通用的端到端通信。
- 这种形式的通信应该能够以最小的开销和限制在所有常见类型的端点系统上实现。
- 基于消息的通信是最小公分母，它为在更高层构建更复杂的信任功能提供了足够的基础。
该协议被设计为通用的：所有端点系统，无论其形式因素或实现方法如何，都可以使用标准的、保证信任的消息相互通信。
为了实现这种通用性，该协议应尽可能简单，以减轻实施挑战，并允许端点的所有变体具有最大的灵活性。因此，以下各节中的需求不仅是必要的，而且是充分的。 除非它们普遍有益，否则必须强烈建议不要向该协议添加其他功能。 还必须强烈优先考虑单一的通用协议规范，以实现最大的任意互操作性。
ToIP协议栈，以第二层为关注点的接口视图如下：
因此，ToIP信任跨层的组件规格需要指定：
- 如何生成和管理ToIP标识符
- 通用消息格式(满足总体设计目标)
- 如何使用底层传输协议来在端点系统之间送达消息
- 任何ToIP的第一层需要的支持功能
后续小节逐个描述。
标识符
互联网的标识符只需要能区分参与网络的设备就行，而ToIP协议栈需要指定机器背后的参与者，并且在这些参与者之间可信的传递消息。为了达到这个目标，ToIP的标识符就必须能够指定参与实体：无论是个人还是组织。因此，以下需求被定义:
- ToIP 标识符在其使用的上下文中必须是唯一的。 [REQ L2.2] 这意味着全球可解析的 ToIP 标识符需要是全球唯一的； 本地可解析的标识符需要在本地是唯一的。
- ToIP 标识符必须是可验证的标识符，即可验证地绑定到至少一组可通过相关发现协议发现的加密密钥。 [REQ L2.3]
- ToIP 标识符最好是分权式的：例如无需依赖中央的权威机构即可验证 [REQ L2.4]
- ToIP 标识符最好是自治的: 例如能够自我验证和完全可移植 [REQ L2.5]
- ToIP 标识符最好在其生命周期可以更换密钥 [REQ L2.6]
- ToIP 标识符可以更换为一个新的标识符，只要通过密码学能证明两个标识符后面的控制者相同 [REQ L2.7]
- ToIP 标识符最好能够：a. 与一个或多个ToIP端点系统的网络地址相关，以便在其控制范围内向1个或多个ToIP端点系统发消息; b. 如果控制者原意，这种相关性可以被发现 [REQ L2.8]
当ToIP标识符需要被证明与一个实体绑定时，需要特别考虑。为了达到身份信任的特定保证级别，这种身份绑定的证明可能是关键因素。这种证明可以由类似以下几种机制实现：
- 证明对ToIP 标识符相关密钥的控制
- 证明对描述身份的一个或多个可验证凭据的控制
- 证明拥有一个或多个身份所绑定的生物特性
这种证明可能需要以下支持（多个与、或关系的组合)：
- 1个或多个第1层功能
- 外部的支持系统
- 第3层的可信任务协议中的函数调用
当一个ToIP 标识符需要被证明与某种数字资源(例如文件，音频，视频)绑定时，需要另外的考虑。可通过内容寻址的方式或者自寻址的方式(通过内容的hash派生)来构造标识符。作为例子，可参照 ACDC (是一个IETF的草案规范)。
消息
消息是ToIP信任跨层的通用语言。为了满足设计目标，有下面的需求：
- ToIP 跨层协议必须定义如果构造和格式化消息，这些消息能够被密码学证明，拥有以下4个特征：
- 真实性：消息是由某个ToIP 标识符的控制者发出的。
- 完整性：发送者发出消息的内容对接收者来说不能被改变。
- 机密性：只有授权的相关方才能访问消息的内容。
- 隐私：消息内容的使用方式受相关方同意的条件所限。 [REQ L2.9]
- 在ToIP 端点系统中，ToIP 跨层协议的实现必须支持真实性和完整性。[REQ L2.10]
- 在ToIP 端点系统中，ToIP 跨层协议的实现可能支持机密性和隐私。[REQ L2.11]
- ToIP 跨层协议必须让高层的可信任务可以组合(例如合作协议)。[REQ 2.12] 组合特性的例子包括发现、多线程、超时，ACK和附件。当然这必须以下需求与取得平衡：只有广泛需要，才在这一层增加功能。
- ToIP 跨层协议必须支持可扩展的消息机制。 [REQ 2.13] 这样不同的可信任务可以在不改变基本格式的前提下被构造出来。
路由
正如前面的图所示，一个消息从发送者发送到接收者处理，分为3步：
- 地址解析 ，输入接收者的ToIP 标识符，解析为：a) 某个ToIP 端点系统的网络地址，支持接收者的第一层传输协议 b) 关联的密码学密钥。举例来说，如果一个ToIP 标识符是一个 DID，该DID的传输层是HTTP，那么一个DID 的解析器能够根据相关的DID方法解析该DID，获取该DID 文档。
- 传输 是 第一层的机制，用来发送消息到接收者的端点系统，或者通过中介系统最终送达该消息。在上面的例子中，HTTP是传输层。互联网上任何传输层协议都可能是合适的。其他情况可能会用其他的传输方式，例如蓝牙、二维码或者发布-订阅消息系统。
- 送达 是最终把消息送到接收者端点系统的第二层。这个步骤也许涉通过中介系统转发的子步骤。
这些步骤因而有以下的需求
- ToIP 跨层协议必须支持将ToIP 的标识符解析为 a) 接收者端点系统的网络地址 以及 b) 需要的密码学密钥。
- ToIP 跨层协议必须支持ToIP 第一层的传输接口。
- ToIP 跨层协议必须支持将消息送达到最终接收者的ToIP 系统对等第二层。
- ToIP 跨层协议必须支持通过中介系统转达消息。
- ToIP 跨层协议必须在消息路由的元数据层面支持机密性。
到第1层的接口
通过上面的第二层需求分析，第1层的信任支持函数接口包括如下部分：请注意第3层可信任务或者第4层可信应用程序也许可以直接调用这些接口(原文如此，笔者认为这个说法和前面说的沙漏模型冲突)
- 密钥管理系统，提供的接口包括生成高质量密码，随机数，以及协议所需要的密码学原语。
- 安全存储 ，提供的接口包括第2层可调用的机密或者秘密数据的增删改查。
- 传输 , 包括两个原语，一个能够让发送者通过第2层的实现提交消息传输；一个能够让接收者通过第1层的实现送达消息到第2层。
- 用户绑定 , 是指让第2层能够实现对用户生物特性的绑定请求或者其他类似的认证信息的绑定请求。
小结
本文内容来自ToIP的首个公开审查的技术架构规范的第8节，详细描述了整个4层中的第2层，也就是信任跨层的技术需求。到这里，读者应该能大致明白ToIP技术架构的目的了。ToIP野心勃勃，是想在目前的互联网(甚至其他传输领域)上直接通过嵌入“可信协议栈”的方式增加信任。与目前各种区块链的解决方案不同的是，ToIP的方式
- 对数字信任的需求建模
- 目标是全球广泛的部署
- 因此定义了更为一般性的ToIP 标识符策略和身份需求框架
ToIP能否比现在的区块链更为成功呢？我想，这个第2层(信任跨层)能否广泛部署是关键因素。另外，很显然，ToIP的第2层协议受到了 keri 项目的大量启发。而目前来看， keri 直接(或者在ietf RFC标准化之后)作为 ToIP的信任跨层的可能性极大。keri这个词，是“密码事件收据基础架构”的简写，keri的具体内涵是什么，本文不再介绍，有机会再专门写文章。
从另一个角度来思考问题，我发现“第一性原理”是无处不在的。在区块链世界，人们总是说不可能三角：
- 分权(decentralize)
- 性能和可扩展性
- 可靠性
但是早期的区块链设计是混合了共识和业务的，在这样的混合架构中，上面的不可能三角总是会出现的，人们通过打补丁的方式来克服问题，例如以太坊的各种L2解决方案。而ToIP却仔细的通过工程的方法去尝试解决现实的信任需求，也通过分层的方法来解决不同层面的需求，从长时间来看，应该更有价值。
第一性原理的另一个例子，涉及上面说的标识符的密钥更换甚至标识符本身的替换，与以太坊的地址相比，以太坊的地址本身是不能更改的，而这就会导致以太坊地址方案无法很好的解决以下问题：
- 当私钥泄漏后，更换无门(除非提前转移所有资产到新的地址)
- 量子计算机的攻击会大大增加一个地址的任何签名本身导致私钥泄漏的潜在风险
以太坊的地址是直接绑定椭圆曲线密钥对，是在假定椭圆曲线是安全的前提下才能做的设计，而随着时间的推移，量子计算将会大大威胁椭圆曲线的安全性。即使没有量子计算的威胁，以太坊的地址也没有考虑绑定到实体(人/机构/物/数字制品)本身，而这个是ToIP考虑信任问题必须的需求。
区块链宣称要解决信任问题，可是目前的各种方案揉合了过多的部分，反而导致了出现了类似上面所说的问题。把需求和解决方案分离，ToIP通过社区合作和工程化的方式，一步一个脚印来推进整个“信任协议栈”，我觉得走向成功的可能性很大。