keri-translate-2
KERI文献翻译-1
KERI white book
摘要
提出了一种基于身份系统的互联网安全覆盖层（如何理解？所有人都有身份？）。其主要信任根是自认证标识符。KERI提出了自治标识符 (AID) 和自治命名空间 (AN)的一种形式。AID与AN是自治身份系统 (AIS) 的一部分。KERI使用最小充分的设计原则，为互联网提供候选信任跨越层。与KERI相关的是去中心化的密钥管理基础设施(DKMI)。DKMI主要的信任根是自认证标识符，在发布时被强绑定到密钥对。这些是自包含的，直到控制需要转移到新的密钥对中。在这种情况下，只有被签名过的key event log提供可验证的控制来源。这使得介入的操作基础设施是可替换的，因为事件日志可以由任何基础设施提供，包括环境基础设施（ambient infrastructure）。环境基础设施上的可验证日志支持环境可验证性，即任何人都可以随时随地验证。
主要的密钥管理操作是通过一种新的密钥预轮换方案来进行的。两种主要的信任模式激发了设计，直接（一对一）模式（我要做1对1的方案）和间接（一对多）模式。间接模式依赖于见证密钥事件收据日志 (KERL) 作为验证事件的二次信任根。这就产生了密钥事件收据基础设施的缩写：KERI。在直接模式下，身份控制器通过验证控制密钥对的签名来建立控制。间接模式扩展了该信任基础，其使用用于验证事件的见证密钥事件收据日志(KERL)。间接模式的安全性和问责性保证由$KA^{2}CE$提供，用于在一组证人之间建立控制。
$KA^{2}CE$方法可能比依赖于总排序分布式共识账本的复杂的方法更具性能和可扩展性。然而，当有其他考虑时，KERI 可能会采用分布式共识账本。DKMI 的 KERI 方法允许更细粒度的组合。此外，由于 KERI 是事件流的，它使 DKMI 能够与数据事件流应用程序（例如 Web 3.0、IoT 等）同步运行。核心 KERI 引擎独立于标识符。这使得KERI成为通用可移植DKMI的候选者。
关键词：安全覆盖、信任跨越层、自治标识符(AID、自治身份系统(AIS)、自治命名空间。去中心化、密钥、管理、基础设施、密钥、事件、接收、预轮换、轮换、事件、流、DKMI、KERI、KERL、KEL、$KA^{2}CE$、KERI用于建立控制的协议算法、自我主权身份。
介绍
这项工作的主要动机是为互联网提供安全的去中心化信任基础，作为可信任的跨越层[7;24;42]。Internet协议设计的一个主要缺陷是它没有安全层。没有内置的安全机制。任何人都可以伪造IP (Internet Protocol)包。具体来说，IP包头包括一个源地址字段，来指示发送数据包的设备的IP地址[81]。由于源地址可能是伪造的，所以接收者可能不知道数据包是否被攻击者发送。这意味着必须互联网必须采取某种安全机制（被某安全机制覆盖）。
典型的互联网安全覆盖基于某种形式的身份系统，该系统利用非对称公钥密码学(PKI)的特性[117]。覆盖的目的是保证IP包中消息有效负载的真实性。下图显示了基本概念。
一般来说，使用这种安全覆盖层，IP 数据包内的消息包括由身份系统提供的唯一标识符，该标识符专属数据包的发送者。有效负载由私钥进行签名。此签名附加到数据包上。身份系统提供了一个目录，该目录将密钥对中的公钥映射到发送方标识符。有效签名验证数据包来自私钥的持有者。标识符和公钥之间的映射确定消息来自标识符的持有者。这种方法假设发送者是私钥的独占持有者或控制器。因此，数据包的接收者可以使用身份系统查找数据包载荷中给定的发送方标识符的相应公钥，然后使用该公钥对附加到有效载荷上的签名进行加密验证。
只有私钥的持有者才能生成这样一个可验证的有效负载。如果无法访问私钥，攻击者无法伪造可验证的有效负载。这种安全机制可以确定数据包中的有效负载来自正确的源。表面上，因为这种建立的强度取决于标识符和密钥对之间的映射的安全性。事实上，安全性取决于映射的安全性。
此外，当排序很重要时，有效载荷的其他内容(如序列号)可用于防止在不同数据包中重放相同的有效载荷。值得注意的是，通过签名安全地建立有效负载的真实性与通过加密确保有效负载内容的机密性是不相关的。加密是一项额外的任务。
绑定
身份系统安全覆盖的一个重要本质特征是它将控制器、标识符和密钥对绑定在一起。发送方控制器专门绑定到密钥对的公钥。公钥专门绑定到唯一标识符。发送方控制器也完全绑定到唯一标识符。这种基于身份的安全覆盖的强度源于支持这些绑定的安全性。
为了详细说明，通常相关的身份系统本质上是管理性的。这意味着来自这样一个身份系统的标识符最终由身份系统的相关管理员（行政组织）控制。从安全的角度来看，管理员最重要的功能是授权，并且通常独占地允许其他实体使用该标识符。我们把实体对标识符的允许使用称为实体与标识符之间的绑定。在这种意义上，管理员将控制器(用户)绑定到标识符。此绑定使控制器能够使用标识符来映射到资源(如IP地址)。管理员还将公钥绑定到此实体标识符。控制器持有私钥，并可以通过用私钥签名来证明其对标识符的允许使用。由于持有私钥，控制器被绑定到密钥对。
当标识符来自管理员时，它们的使用取决于管理员的持续许可（通常通过支付租金）。控制器和标识符之间绑定以及密钥对和标识符之间绑定的排他性和安全性基于对管理员的信任。因此，来自这种管理身份系统的标识符控制器只是标识符的租赁者，还必须依赖于管理员的基础设施的操作安全性。因此，控制器在其标识符中构建的任何值都取决于管理员的持续许可和管理员基本操作基础设施的信任。
总之，互联网安全机制总体上使用某种形式的身份系统安全覆盖。最著名的例子是具有证书颁发机构 (CA) 的域名系统 (DNS) [40; 54]。DNS 将控制器绑定到域名标识符。DNS还将诸如mail.example.com之类的域名映射到 IP 地址，例如54.85.132.205。CA 将具有域名的控制器与公钥绑定。基于 DNS 的 URL 命名空间将 URL 标识符映射到资源 [148]。除了 DNS、CA，其他基于标识符的安全机制也被广泛使用。例如使用用户名和密码以及 OAuth/OpenID Connect [113] 的 Web 平台访问控制系统。这些其他基于标识符的安全机制系统通常利用 DNS/CA。
因为 DNS 被绑定在 IP 上，CA 后来被绑定在 DNS 上，所以从安全的角度来看，它们没有很好地集成。这导致众所周知的漏洞 [69; 74]。为了减轻漏洞影响，各种安全机制开始出现，例如pinning、notaries和DNSSEC[44；52；55；71；76；126；128]。所有这些机制都需要信任管理操作的计算基础设施，因此存在相应的安全漏洞。最近证书透明度 (RFC6962) 在缓解 DNS/CA 安全覆盖利用方面取得了一些成功 [41]；57；70；95-97]。使用证书透明度的 DNS 服务器仅维护证书颁发机构活动（颁发与撤销）的审计日志。该日志检测CA不一致的行为，从而使使用相关域名服务器的客户端采取预防措施。尽管证书透明度的可以缓解风险，但 DNS-CA 安全覆盖仍然收到DNS劫持攻击的影响。[4;69;140]。一个相关的漏洞是使用AS路径中毒来劫持BGP，以欺骗ca的域验证过程[28-30；66]。这使攻击者能够诱导CA发出虚假但可验证的证书。在研究的时候，我们发现大多数互联网域名都容易受到这种攻击。这些类型的攻击利用了 DNS-CA 系统固有的密钥对和可信issuer标识符之间的弱绑定。
一般来说，当前互联网安全覆盖的主要弱点是，通过证书建立密钥对和标识符之间的绑定依赖于基本计算基础设施，这些基础设施本质上容易受到自身错误操作的影响。KERI 的设计目标是一个安全覆盖层，它不依赖于基本的操作基础设施，从而消除了这个弱点。
信任基础和信任域
在安全系统设计中，信任根是系统中其他组件或进程所依赖的某个组件或进程。信任根具有可信的安全属性，为信任系统中的其他组件或过程[119]提供了信任基础。系统可能有多个信任根。根据对给定的信任根的依赖程度，一些根可以被认为次要的。我们将主要和次要的信任根定义如下：
1 | 一个主要的信任根是不可替代的。(1.1)（自认证标识符） |
这意味着作为主要信任根的组件是系统中的重要组成部分。它提供了系统唯一必要的信任。
1 | 次要信任根是可替换的。(1.2)（分布式账本、数据库等） |
这意味着系统可以不需要次要信任根。它提供的信任也可以由其他组件冗余地提供。次要信任根可能发挥重要作用，但组件本身并不是在系统中建立信任的唯一必要条件，即次要信任根是可替换的。
主信任根的可利用弱点可能会破坏相关系统的安全性。因此，良好的安全设计从信任根的选择开始。通常，信任根一词被狭隘地指一些硬件设备，这些设备足够安全，可以始终被信任。需要明确的是，在这项工作中，我们将信任根的概念概括为包括所有可能被信任的操作元素，即使它们不是非常值得信任或值得信赖（如何理解？）。所有这些都构成了我们所说的信任基础。在互联网身份系统安全覆盖层中，我们这样定义信任基础：
1 | 信任基础绑定控制器、标识符和密钥对。(1.3) |
信任基础可能包括各种主要的、次要的信任根，以及其他操作组件或过程。当信任基础包括传统的管理基本操作基础设施时，绑定的安全性可能取决于管理员维护这些绑定的能力。在这种情况下，管理员可以被认为是绑定的信任根，因此可以控制标识符。
每个信任基础都与信任域相关联。信任域是使用互联网在实体之间的交互生态系统，该互联网依赖于信任基础来信任这些交互。信任域(生态系统)的可信赖性取决于其信任基础。因此，我们将信任域定义为：
1 | 信任域是依赖于信任基础的交互生态系统。(1.4) |
例如， Facebook 的社交互动生态系统是一个信任域，它依赖于 Facebook 的用户名/密码的身份系统作为其信任基础。下图显示了基于身份的安全覆盖中信任基础和信任域之间的关系：
信任基础的基本作用是可信的建立对标识符的控制。一个常见的误解是标识符的管理发布本质上是值得信赖的。仔细分析从信任根到可信互联网交互的过程，可以发现这个过程通常是可利用的（例如，有关 DNS/CA 系统，可以被攻击的）。如前所述，许多建立或证明标识符控制的管理方法的主要缺点：管理员是计算基础设施管理的信任根。详细点说，安全覆盖的目标是：控制器能够根据密钥对，使用签名来呈现数字加密可验证的声明。但是，这首先要求人们信任该标识符和密钥对之间的绑定。通常这种绑定，尤其是当标识符具有人类意义时，是由管理员自行断言的，因此管理员是计算基础设施的管理或治理的主要信任根[142；155]。因此，对管理员发出的标识符的信任要求我们对管理员的信任，当该绑定以数字方式发布时，我们需要信任用于发出该绑定的计算基础设施。此外，绑定可能基于手动建立过程，该过程可能需要与管理实体直接的物理交互，例如访问管理员的办公室以获得某种形式的凭证，凭证证明密钥对绑定到标识符。因此，对管理实体的信任来源至关重要。可信管理实体必须必须竭尽全力建立和维持可信的信任来源。
当用于在信任基础之间建立控制的机制不能以任何实质方式互操作时，对标识符安全控制的建立可能高度依赖于信任基础。对于管理标识符（管理员的标识符）来说尤其如此。在这种情况下，标识符被有效地印章到给定的信任基础上，因此依赖于用于确保可信安全绑定的管理员的操作基础结构，从而印章到信任域（如何理解？）。换句话说，绑定和标识符不能移植到其他信任基础。因此，附加到标识符的任何值都不能移植到其他信任域。此外，不同的信任基础依赖于广泛不同的机制来建立绑定的有效性，这可能会给任何希望在多个信任域中与其他人互操作的控制器(用户)带来很大的负担，因为控制器必须支持每个信任基础的不同建立机制。例如同一视频的 FaceBook 和 YouTube URL。
为了重申一下，当控制器、标识符、密钥对之间的绑定都被管理许可，并印章到相关的信任基础时，会出现绝大多数基于身份的安全机制的主要问题（问题指的是不同信任域直接不能互操作？）。因此，使用该标识符的控制器交互被印章到相关的信任域中。仅仅提供信任基础(以及域)之间的互操作性并不能解决管理权限问题。仅仅消除管理权限问题并不能解决信任域印章问题。因此，我们要设计一个系统，该系统提供安全的可互操作绑定，既可以在信任基础之间进行自我管理和移植，也可以提供信任域。系统的目标是创建绑定和标识符，这些绑定和标识符不被印章到给定的信任基础/域，而是允许控制器在可互操作的信任基础/域之间随意移动标识符。我们认为，这意味着可互操作的信任基础必须共享一个公共机制，以建立对这些绑定的控制，从而跨越支持信任基础和相关的应用信任域。（如何理解？）
去中心化
我们对去中心化的定义是关于控制而不是空间分布。在我们的定义中，去中心化不一定等同于分布式。分布式指活动发生在多个节点。因此，去中心化是关于控制，而分布式是关于地点。具体来说，当我们提到去中心化的基础设施时，我们指的是去中心化控制，而与空间分布无关。因此，去中心化基础设施是由多个实体控制的基础设施。实体不仅限于自然人，还可能包括团体、组织、软件代理、事物等。集中管理的身份系统可能处于单一管理组织的控制之下。治理组织在本质上也可能是分层的，有多个下属组织在更高级别组织的支持下运作。相关的操作基础设施本身可能是空间分布式的，尽管处于高度集中的控制之下。例如，虽然 DNS 是由一个单一的组织 IANA 管理的，但操作基础设施分布在全球范围内 [12]。
互联网基础设施的大部分操作本质上是去中心化的，但控制此基础设施的组织确是中心化的。控制的中心化给恶意管理员提供强烈的诱惑，因此，我们相信去中心化对于建立信任至关重要。因此，去中心化信任基础的一个密钥组成部分是一个可互操作的去中心化身份系统[10;132;133;152]。
在用作安全覆盖层的集中式身份管理系统中，管理员控制所有标识符。相比之下，在去中心化身份系统中，不同的实体都控制了一些标识符。每个实体可能有一组它控制的标识符(名称空间)，但仍可被其他实体识别。在这种情况下，如果标识符指的是其控制实体，那么该实体对自己的标识符以及与该标识符相关的标识具有主权。理想情况下，自我主权标识符是用户发布和控制的标识符，无需服从任何其他管理组织或获得任何其他管理组织的许可。相关的身份系统在这个意义上也是自我管理的。去中心化(自我管理)身份系统的这一特性催生了自我主权身份(SSI)一词[10;127;133;152]。
总而言之，基于安全覆盖的集中式身份系统对参与者的两个缺点是：
参与者通常需要付出一定代价才能获得管理员的许可。管理员可以谴责参与者（把参与者的标识符删掉）。
参与者必须信任管理员的操作基础设施（信任基础）。参与者产生的价值可能被印章在基础设施，或者由于管理漏洞而受到利用。
在任何一种情况下，参与者都不能最终控制参与者带给相关信任域的价值。信任基础的去中心化可以促进更具竞争力的生态系统，并实现基础设施提供商之间的可移植性[129;134]。
自认证标识符
我们认为，对标识符的完全去中心化和可信赖的控制，最好是通过基于自认证标识符属性的主要信任根的信任基础来实现的[68;90;102;103]。它建议文件系统与互联网url不依赖于集中式DNS证书颁发机构来建立安全控制。然而，这个概念在首次引入时从未取得采用。最近对互联网的日益集中及其随之而来的安全漏洞的担忧，使自认证标识符概念更具吸引力。我们在2015年初提出使用自认证标识符，用于自我主权身份[132;133]。最近，遵循新兴 W3C 去中心化标识符 (DID) 标准的标识符的一些变体是自认证的 [151]。可信计算组(TCG)使用术语“隐式身份”和“嵌入式证书颁发机构”来描述设备标识符由相关计算设备自动生成的过程[143]。这种机制称为设备标识符组合引擎 (DICE)。 DICE 生成 DICE 复合设备标识符 (DCI)。这些标准与IEEE 802.1AR-2018安全设备ID (DevID)标识符标准和IETF RATS标准兼容[3;118;124;154]。DICE还提供了一种自认证标识符。
基本概念
自认证标识符的最简单形式公钥或公钥的唯一指纹作为标识符中的前缀。由于公钥包含在标识符中，标识符安全地绑定到密钥对。这种加密安全绑定使标识符可以自认证[68;90;102;103]。
这种自认证特性是建立安全的去中心化可移植身份系统所需的密钥特征。私钥的持有者是唯一控制标识符的人，因为只有这个持有者可以签署声明，这些声明可以用绑定到该标识符的公钥进行加密验证。私钥的持有者是控制器，并且控制器隐含地绑定到标识符。只有私钥(控制器)的持有者可以通过用私钥签名，成功地响应任何挑战，来证明对标识符的控制。
1 | 自认证标识符以密码学方式将标识符绑定到密钥对。(2.1) |
自认证标识符中的主要信任根来自非对称公钥密码学的属性。更详细地说，私钥来源于一个随机种子，表示为一个非常大的随机数。随机性的程度或强度决定了其他人复制相同的大随机数的难度。这就是所谓的抗碰撞性。香农信息论使用熵来描述消息的不可预测性程度。熵以比特为单位测量。
同样，数字或消息的随机性可以通过数字中熵的位数来衡量。随机数的熵位数可能与数字位数相同。N 位数（基数为2）有$2^N$个不同的可能值。
最高级别的加密安全被称为信息论安全[79]。信息论安全的一种特殊情况被称为完全安全。完全安全意味着密文不提供关于密钥的信息[79]。具有这种安全级别的加密系统无法通过算法被破解。如果要打破它，就必须用暴力破解。暴力破解意味着为了保证成功，对手必须搜索种子/密钥的每一个组合。
对于完全安全的密码系统，基本参数是抵抗暴力攻击所需的熵比特数。换句话说，当一个大的随机数被用作种子/密钥，作为一个具有完美安全性的加密系统的输入时，要回答的问题是，这个随机数需要多大才能抵御针对加密系统输出的暴力攻击？假设非量子计算机，传统观点是，对于具有完全安全性的系统，种子/密钥输入需要具有 128 位（16 字节）的熵，以实际抵御给定输出的任何可能的暴力攻击。对于其他密码系统，种子/密钥的大小可能需要更大。在完全安全的情况下，攻击者需要尝试每个可能的值。因此，在 N 位随机数中具有 N 位熵，攻击者必须做出的尝试是$2^N$的数量级。理论上，使用渐近最优Grover算法的量子计算机能够暴力破解出$2^{N/2}$的熵[145]。因此，一旦实用的量子计算机存在，加密强度将从 128 增加到 256。
为了了解在给定可用计算能力的情况下，暴力攻击具有128位加密强度的系统有多困难，让我们假设攻击者可以的的算力是世界上所有超级计算资源。据估计，前500名超级计算机的总性能小于2 exaflops[145]。1 exaflop相当于每秒1千万亿次运算[63]。1千万亿大约等于$2^{50} = 1,125,899,906,842,624$。由于单个CPU核心每秒只能执行大约40亿次操作，所以最强大的超级计算机必须并行运行许多核心。假设对手可以使用超过一百万台($2^20 = 1,048,576$)次浮点运算能力的超级计算机。然后攻击者可以每秒尝试$2^{50} * 2^{20} = 2^{70}$个值(假设每次尝试只需要一个操作)。因此，这组超过一百万台百亿亿次的超级计算机每年可以尝试大约$2^{50 +20+25} = 2^{95}$个值。输入种子/密钥中有128位熵，对手需要8,589,934,592年才能猜出正确的值。因此，具有N = 128位密码强度的密码系统实际上是不可能被破解的。重申一下，128位的加密强度足够强大，任何对手都无法利用任何可能数量的计算资源通过暴力攻击来破解它。成功的攻击必须利用其他一些暴露私钥的漏洞，例如糟糕的私钥管理，社会工程的私钥泄露或数字签名计算基础设施中的侧通道弱点[22;130;137]。
随机数可以通过多种方式生成。一种常见的基于软件的方法是加密安全的伪随机数生成器(CSPRNG)[46]。更复杂的方法使用特殊用途的硬件，例如可信平台模块[146]。任何实体都可以捕获足够的熵来生成加密强随机种子。一旦实体捕获该熵，其他实体实际上就无法复制这个种子。这使得原始捕获实体成为该随机种子的唯一持有者。该种子的持有者通过获取熵而获得了对该种子的控制，而无需服从、许可或依赖任何其他实体或权威。这是真正的去中心化控制。
生成自认证标识符
鉴于当前的计算能力，在生成自认证标识符的过程中，每个加密操作不应保持不小于 128 位的加密强度。每个操作都是一种加密的单向函数[112]。单向函数在一个方向上相对容易计算，但很难反转(invert)[111]。具有128位安全性的单向函数需要进行$2^{128}$次运算才能反转。
ECC标量乘法是一种单向函数。椭圆曲线密码学(ECC)中的公钥生成使用椭圆曲线标量乘法作为从私钥生成公钥的一种方式。重申一下，公钥生成是一种单向函数。以Ed25519密钥为例，相对于它们的长度而言，它们相对较强，计算量相对较少[1;26;49]。以 Ed25519 为例（ECDSA等其他ECC密钥具有类似的特性[35;58;107;125]），Ed25519 个私钥用 256 位长（32 字节）数表示，其加密强度不小于 128 位 [26; 89]。具有 256 位标量乘法的加密强度仍然只有 128 位的原因是：存在攻击算法可以在$2^{N/2}$次独立试验中反转 N 位 ECC 标量乘法。这意味着底层字段的大小应该大约是安全参数的两倍。ECC 公钥实际上是带有 x 和 y 坐标的椭圆曲线上的点。每个坐标都是一个 32 字节数，总共 64 字节。然而，因为曲线本身是已知的，因此只需要x坐标和表示y坐标位于x轴哪一侧的符号位就可以恢复y坐标。因此，公钥在存储时只有32字节(x坐标和符号位)。
给定一个 128 位随机种子，生成自认证标识符的下一步是创建一个非对称密钥对。如果私钥所需的长度为 256 位（如 Ed25519 的情况），那么我们首先需要将随机种子从 128 位（16 字节）拉伸到 256 位（32 字节）。然后，该种子成为Ed25519 密钥生成算法 [49] 的输入。密钥拉伸是另一种单向函数。密钥拉伸的一个很好的算法是 Arguon2。一旦拉伸，这个256位种子就成为私钥。使用LibSodium代码库，我们可以创建关联的公钥。在底层，Ed25519代码在对结果执行标量乘法以计算公钥之前，对私钥/种子进行散列。但是这个散列值永远不会暴露给用户。然后可以对生成的32字节公钥进行编码并用于生成自认证标识符。
密码运算产生较大的二进制数。标识符最好表示为字符串。因此，为了使用公钥来创建标识符，我们首先需要将其转换为字符串。高度可互操作和相对紧凑的编码是Base-64 (URL安全)[87]。Base-64 将二进制数的每 3 个字节编码为 4 个 ASCII 字符。当 N 个字节二进制数不是 3 个字节的精确倍数时，在 Base-64 编码的末尾添加的 1 或 2 个字节的填充字符。32字节公钥将编码为 44 个 Base-64 个字符，其中包含一个尾填充字符。例如，以下 32 个字节的私钥：
1 | 0caac9c64711f66e6ed71b37dc5e69c5124fe93ee12446e1a47ad4b650dd861d |
被编码为以下 44 个字符 Base-64 字符串（包括一个尾填充字符）：
1 | DKrJxkcR9m5u1xs33F5pxRJP6T7hJEbhpHrUtlDdhh0= |
派生代码
为了正确提取和使用嵌入在自认证标识符中的公钥，我们需要知道密钥对使用的加密签名方案。在本例中，我们需要知道密钥对遵循 Ed25519 并用于签名。我们还需推断公钥的长度。这通常被称为密码套件和操作。一般来说，密码套件和操作还提供了用于派生自认证标识符的过程。此派生信息必须包含在标识符中。在标识符中包含派生信息的一种方法是用编码派生过程的特殊字符（派生码）替换填充字符。这称为派代码。由于需要此派生信息来正确解析编码的公钥，因此我们将派生代码添加到公钥之前，并删除填充字符。
结果的长度仍然是 44 个字符。例如，假设公钥带有尾填充字符的 44 个字符 Base-64 如下：
1 | F5pxRJP6THrUtlDdhh07hJEDKrJxkcR9m5u1xs33bhp= |
如果 B 是派生码的值，则生成的自包含字符串如下：
1 | BF5pxRJP6THrUtlDdhh07hJEDKrJxkcR9m5u1xs33bhp |
现在派生码是标识符的一部分。这将公钥及其派生过程绑定到标识符。因为字符串是有效的 Base-64，它可以在使用二进制操作解析之前转换为二进制，也可以在转换之前解析它。如果在转换之前解析，则必须从字符串的前面提取派生码。第一个字符告诉如何解析剩余字符。这允许加密材料的紧凑但可解析的链接。在将包含编码公钥的剩余字符转换回二进制之前，必须重新添加填充字符。第14.2节提供了KERI派生码的建议。提出的KERI派生代码集在第14.2节中提供。每个字符长度为1、2或4个字符，分别替换1、2或0个填充字符。这确保了每个自认证标识符字符串都符合 Base-64 规范（必须是 4 的倍数）。这允许在解析之前进行转换（这可能更有效）。这种编码派生过程的方法类似于多编解码器标准所遵循的方法，但更紧凑，因为它有效地利用了填充字节，且只需要支持KERI事件中的加密材料[105]。此外，KERI 设计目标是支持其事件中所有加密材料的灵活性。紧凑的派生码使得灵活性大大提高（如何理解？）。派生码不仅用于自认证标识符前缀，还用于密钥、签名和摘要。例如，上面第 2.2 节末尾私钥的 Base-64 表示可以用派生码进行编码，如下所示：
1 | ADKrJxkcR9m5u1xs33F5pxRJP6T7hJEbhpHrUtlDdhh0 |
这使得在整个用于支持KERI的密钥管理基础设施中，可以使用派生码来有效地表示密码材料。
初始声明
自认证标识符的实际使用可能需要一些初始配置数据。我们将此称为初始数据，并在有签名的初始声明中正式表示。初始数据必须包括公钥、从公钥派生出的标识符，还可以包括其他配置数据。标识符派生可以简单地由派生码表示。包含初始数据(带有用私钥生成的附加签名)的声明包括对标识符的派生和配置的加密承诺，该标识符可以由接收它的任何实体进行加密验证。它是完全自认证的。不需要额外的基础设施，即可验证标识符的派生和初始配置。标识符的初始信任基础只是签名的初始声明。基本初始声明示意图如图所示：
转移性
不幸的是，随着时间的推移，控制自认证标识符的私钥可能会暴露。在这种情况下，密钥管理的最佳实践表明需要更改密钥对。这称为密钥轮换。密钥轮换有效地将标识符的控制转移到不同的密钥对。可凭签署的轮换声明进行密钥轮换。然而，对于自认证标识符，在传输后，新的控制密钥对不再唯一地绑定到标识符（之前的旧密钥也绑定）。尽管如此，它的新绑定仍然是加密可验证的，因为一个人有一份转移声明的副本。轮换声明的日志是可验证的。这意味着日志可以通过任何接收到其副本的任何用户进行验证。不需要信任中间基础设施来验证日志并验证轮换链。由于只需要日志的副本，因此任何提供副本的基础设施都可以被选择。因此，用于维护轮换声明日志的基础设施只是标识符控制建立的次要信任根。这使得能够使用环境基础设施来提供日志的副本。环境基础设施提供的最终可验证日志的组合使环境可验证性成为可能，也就是说，任何人都可以随时随地进行验证。这种方法具有证书透明度、密钥透明度的一些特征，但不同之处在于每个标识符都有自己的一系列事件，这些事件植根于自认证标识符[93；97]（与证书透明度的不同）。
因此，有两种不同的自认证标识符的基本类别：可转移的（可轮换的）和非可转移的（不可轮换的）。标识符的可转移性类可以在派生码（参见第 14.2 节）或初始声明的配置数据中声明。当不可转移标识符的私钥被暴露时，控制器必须放弃标识符，因为它不再安全。而当可转移标识符的私钥暴露时，则可以将对标识符的控制转移到新的密钥对以保持安全性。自认证标识符的许多应用只需要临时使用，然后丢弃标识符，这些称为临时标识符。其他应用程序可能只给标识符附加有限的价值，这样替换标识符就不麻烦了。由于不可转移标识符在泄露的情况下不可恢复，因此唯一的办法是用另一个标识符替换该标识符。在某些应用程序中，考虑到维护密钥状态的相对简单性，这可能是可取的。在其他应用程序中，标识符及其附加值需要随着时间的推移持续存在。在这种情况下，需要一个可转移的自认证标识符。自认证标识符的早期实现以及最近的安全设备 ID 实现通常是不可转移的。KERI 的主要创新是它提供了一个通用的去中心化机制，既支持不可转移的标识符，也支持更重要的可转移的自认证标识符。
自认证标识符的类型
基本
基本的自认证标识符包括一个前缀，前缀由base-64派生码组成，该派生码附加到公钥的 Base-64 编码上。派生码表明派生是基本的，以及说明对应的签名方案的密码套件。前缀可以表示如下：
在前缀中包含派生码，可将派生过程以及公钥绑定到生成标识符。一个字符的派生码和一个32字节的公钥编码成一个44个字符的base-64字符串前缀如下：
1 | BDKrJxkcR9m5u1xs33F5pxRJP6T7hJEbhpHrUtlDdhh0 |
下图显示了从随机种子到基本自认证标识符前缀中的公钥的派生过程：
上述派生过程在第 2.2.1 节中详细描述。基本类型是最容易解析的。很容易直接从标识符前缀中提取派生码和公钥。此外，当派生码还表明标识符是不可转移的，那么初始配置数据可能是空的。这意味着永远不会有任何轮换声明，并且验证任何声明签名所需的一切都包含在标识符前缀中。这也意味着不需要初始声明。这为短暂的自认证标识符提供了非常紧凑的表示和信任基础。此外，当不可转移时，可以采用一种约定，允许将签名密钥对重新用于加密。例如，Ed25519签名密钥对可以转换为X25519加密密钥对，因为两条曲线是等效的[56,149]。X25519密钥对的公钥既可以用于匿名非对称公共加密，也可以与另一方的公钥交换，以创建Diffie-Hellman共享对称加密密钥。这将允许在任何双方之间建立一个安全的经过身份验证(签名)和加密的通信通道，每个方只有一个不可转移的基本自认证标识符，且不需要其他基础设施。一旦安全通道建立，双方就可以交换不可转移的标识符（短暂的通信）。
自寻址
当需要初始化配置数据时，初始化声明不会为空。在某些情况下，能够将初始声明强绑定到标识符，而不仅仅依赖于相关标识符的可加密验证的初始声明。初始数据和私钥之间的绑定可以通过用初始声明的内容摘要替换标识符前缀中的公钥来创建。此外，初始数据包括派生和公钥，那么摘要绑定到公钥，而公钥又绑定到私钥。这假设包含散列步骤的完整派生过程由任何验证者知道。
使用内容摘要不仅将初始声明绑定到标识符，而且还可以轻松使用标识符前缀从内容可寻址数据库中检索初始声明。这要求数据库将签名与初始数据一起存储，以便验证者可以验证初始数据。这种方法还支持特定内容或文档的自认证标识符。这为内容可寻址数据库提供了一种机制，将不可否认的唯一属性强加给作为控制器的内容创建者。这将内容与内容地址中的创建者绑定。不同的创建者意味着不同的地址。这使得机密（加密的）内容更易于使用，因为内容地址绑定到拥有解密密钥的控制器。
内容自寻址自认证标识符的前缀可以表示如下:
一个字符的派生码和一个32字节的公钥编码成一个44个字符的base-64字符串前缀如下：
1 | EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148 |
下面是从随机种子到前缀中初始数据的哈希的派生示意图，用于自寻址自认证标识符如下：
多签名自寻址
向派生添加内容摘要的步骤为自认证标识符提供了其他的派生可能性。例如，初始声明可以包含一组公钥，以便需要多个签名进行验证。多个签名可能会显着增加从初始内容派生的标识符建立控制权限的安全。假设任何验证者都知道派生中使用的多个签名方案。
前缀可以表示如下：
下图显示了从多个随机种子到多签名自寻址自认证标识符前缀中初始数据的哈希的派生过程:
委托自寻址
自认证标识符的一个重要用例是委托标识符，其中委托标识符授权其他标识符执行某些活动。可以通过在delegated前缀初始配置数据中包含delegating标识符前缀来创建delegated标识符前缀。这可以包括其他基本的delegating配置数据。这种包含将delegated前缀加密地绑定到delegating前缀和其他delegating配置，以及delegated前缀的控制密钥对和其他配置数据。前缀可以表示如下：
下图显示了委托自寻址自认证标识符的前缀中初始数据的哈希派生：
委托前缀也可以通过包含一组多签名公钥来实现多签名。
自签名
虽然在自寻址自认证标识符的前缀中使用内容摘要可以将标识符前缀绑定到初始数据，但它仍然需要附加签名进行验证。如果在前缀中使用初始数据的签名而不是内容摘要(哈希)，则不需要附加签名。这使标识符具有自包含的可验证性，即控制器(私有签名密钥的持有者)创建了签名。换句话说，这使得初始数据对内容可寻址存储进行自寻址和自签名。这种方法可能对文件或其他数字媒体特别有用，其中文档（或摘要）的内容包含在初始配置数据中。这使得内容可寻址标识符强绑定到文档上的可验证签名，该签名在文档进入数据库时建立对文档的控制。这种方法的缺点是：对于相同的加密强度级别，签名通常是摘要的两倍。此外，包括标识符前缀中的签名使初始声明总体上更加紧凑，但可能会使其他声明更长，因为标识符更长。
内容自寻址自认证标识符的前缀可以表示如下：
64字节长的签名编码为88个字符的Base-64字符串，其中包括2个pad字符。这意味着在这种情况下，派生代码是两个Base-64字符长。前缀的两个字符派生代码和64字节签名编码为88个字符的Base-64字符串的示例如下:
1 | 0BYbLIOlRx8xh5taCxW-_aCBoPboLAZjK5-d1DP4OZ9PWn13BpPCe12ZFVZfFlSsM3Pv-zljbsJnR6Adz7iE5ZAw |
下图显示了自寻址自认证标识符前缀中从随机种子到初始数据哈希的派生过程：
广义的
可以生成不同类型的自认证标识符。派生信息必须正确地指示派生的派生过程。给定派生码，标识符的任何接收者都可以验证标识符是从给定的私钥派生的，从而使带有附加签名的任何关联声明的接收者能够验证该声明对该标识符具有权威性。KERI提供的所有安全属性和支持都可以应用于这些通用的自认证标识符。这为未来类型的自认证标识符提供了通用的可扩展性。
广义自认证标识符的前缀可以由派生和所产生的Derivative组成。这可以抽象地表示如下：
下图显示了从一个随机种子到若干个单向函数再到最终派生的自认证标识符的派生过程：
密码信任基础
我们的可移植去中心化身份系统安全覆盖的设计可以通过其信任基础的三个重要属性来理解。这些是信任根、真相来源和控制位点。
信任的根
之前定义了信任根。自认证标识符的主要信任根是密码的，因为初始的派生过程在一个或多个签名密钥对和标识符前缀之间建立唯一的绑定。这种独特的绑定是用一个或多个单向函数建立的，该函数将控制器捕获的熵与标识符前缀绑定。控制器可以普遍唯一地发出与该熵相关的标识符。发行时的绑定是加密可验证的，不依赖于其初始建立的任何操作基础设施。这为安全发布标识符提供了完全去中心化的信任根。
数字签名密钥对和标识符之间绑定的加密信任根提供了信任属性。数字签名可验证声明提供了两个额外的信任属性，这些属性是完整性和不可抵赖性[110]。完整性意味着声明没有被篡改。不可抵赖性意味着除了私钥的持有者（控制器）之外没有其他实体可以创建签名。这意味着持有者不会否认该声明。这意味着密钥占有对于维护信任根至关重要。数字签名没有提供：信任已签署声明的事实的基础。非正式地说，这意味着它不提供对所说内容的信任，而只提供对说这话的人的信任。尽管如此，这是一个非常有用的属性，因为不可否认性可以实现consistent attribution。对说话人的consistent attribution是保持对说话人的信任的必要条件（如何理解？）。有了consistent attribution，人们可能会相信控制器做出了一组声明。如果这些声明在其内容中也是一致的，则存在信任的可能性。另一方面，如果声明的内容不一致，那么这些声明（控制器）的来源被证明是不一致的。不一致是不信任的基础。总而言之，consistent attribution是评估所说的是否值得信赖的基础。随着时间的推移，人们可能会在这个基础上建立更强的信任可能性，通过维护声明的历史并验证它们的一致性，以发现不一致（重复）。
真实性来源
真实性来源是可能做出权威声明的人或某事。信息系统设计的一种非常有用的方法是为系统中的任何信息项建立一个单一的或权威真实性来源[8;94;131]。在身份系统安全覆盖的情况下，我们希望为标识符建立加密可验证的真实性来源。因为在发布自认证标识符时，在标识符和密钥对之间建立了一个普遍唯一的加密强绑定，所以除了创建密钥对并因此持有私钥的控制器之外，可能没有其他可验证的真实性来源。
为了重申一下，创建自认证标识符的过程意味着只有控制器可以对标识符做出可验证的权威控制声明。因此，控制器绑定到标识符。这使得控制器成为唯一的真实性来源。一开始，自认证标识符只有一个信任根（捕获的熵？）和一个加密绑定在一起的单一真实源（控制器）。这个绑定为自认证标识符创建了我们所说的根权威（root-authority）。由于根权威与实体、控制器和执行该权威的私钥相关联，我们可以将根权限称为控制权和/或行使该权力的实体。
1 | 根权威对自认证标识符具有完全和独占的控制权(2.2) |
由于从捕获的熵创建标识符，这种独占的控制在自认证标识符在开始时就注入根权威。这种根权威首先在标识符的发布中表现出来。根权威可在以后通过可加密验证的声明通过行使该根权威来转移、委托或减弱。而在管理身份系统中，由于被指定为管理员，管理员对其发布的标识符拥有根权威，而绑定到这些标识符的私钥的持有者则没有根权威。
控制点
“控制点”一词指的是一个人觉得自己可以控制的生活范围。我们将控制点应用于身份系统，以回答谁控制什么的问题。
假设只有一个真实性来源，那么这个真实性来源可以独占地决定控制声明的顺序和控制声明之间的任何依赖关系。对排序的控制意味着支持和维护控制声明历史所需的基础结构类型可以得到简化，因为任何标识符的控制声明历史都可以独立于任何其他标识符的历史进行排序。对这一属性的认识直接导致了KERI的方法。控制声明主要用于建立和维护对标识符的控制。这包括以下类型的控制声明：
- 标识符的创建或发布。
- 标识符的操作。
控制操作声明可能包括以下内容：
- 控制权的转移(不可撤销)。这意味着将标识符的控制权转移到不同的密钥对或密钥对集以及不同的签名方案(如多重签名)。这也被称为轮换。轮换操作撤销当前的一组密钥，并用一组新密钥替换它们。
- 标识符的委托（可撤销）。这创建了一个具有自己一组密钥的新标识符，并授权（可撤销）一定程度的控制权限。
以下是这些控制声明组成的概念图：
一旦建立了标识符的当前控制权限，当前的控制权限可能会为与建立和/或维护其控制权限无关的目的提供额外的声明。这些声明可能包括通信加密密钥的授权，或路由通信的端点、服务端点或其他资源的授权，以及用于开展业务的签名事务。这些图示如下：
自治标识符（AID）
尽管 SSI 正在成为身份识别的重要新方法，但 SSI 的不同实现在去中心化和安全性方面有所不同。因此，需要更精确地定义一个归一化理论模型，该模型最能代表自我主权身份的理想。为了避免与其他变体混淆，我们选择使用术语自治身份系统 (AIS) 和自治标识符 (AID) 来命名这个更精确的模型。同样，术语自主计算 (AC) 表示某种类型的自我管理软件能力，例如自我配置、自我保障或自扩展 [6; 19; 51]。
通过这种方式，我们可以说自治标识符是一种具有自我管理或自我治理能力的标识符。这完全唤起了自我主权的含义。最重要的自我管理能力是自认证，它会导致自我管理。我们在 1.2 节中定义了自认证，在这里泛化了。
自治命名空间 (AN)
在身份系统中，标识符可以推广到命名空间。命名空间是一组相关对象的符号或标识符[108]。命名空间采用一些方案将标识符分配给命名空间的元素。一个简单的名称间距方案以分层方式使用一个或多个前缀来组成标识符。以下是美国内地址的命名空间方案的示例，该方案使用前缀层次结构：
1 | state.county.city.zip.street.number. (3.1) |
此命名空间中的一个示例元素可以用以下内容标识：
1 | utah.wasatch.heber.84032.main.150S. (3.2) |
其中每个前缀位置都被地址元素的实际值替换。命名空间提供了一种组织相关元素的系统方法。
我们正式定义一个自治命名空间 (AN) 是一个命名空间，它具有一个自认证的前缀。自认证前缀在其命名空间 [68; 90; 102; 103] 上提供了根控制权威的加密验证。来自自治命名空间的每个标识符包括一个标识符作为前缀，该标识符要么是公钥，要么是从公钥派生出来的。然后，控制器可以使用相关的私钥来权威（不可否认）签署声明，对自己进行身份验证并授权使用标识符。它是完全去中心化的自我主权身份系统中标识符的基本属性。
1 | 自治命名空间是自认证的，因此是自我管理的。(3.3) |
自治命名空间的自我管理能力最好地体现了与自我主权身份系统相关的自我管理属性[10;45;127;132;133;136]。同一自治命名空间 (AN) 中的所有派生自治标识符 (AID) 共享相同的信任根、真实性来源和控制位点。因此，命名空间的治理统一为一个实体，即拥有名称空间根权限的控制器。这种控制权限的统一简化了安全系统设计和分析。并催生出 KERI 的设计。
自治身份系统 (AIS) 的主要目的是使任何实体能够以独立、可互操作和可移植的方式对标识符命名空间进行控制。这种方法建立在身份元系统（identity meta-system）的思想之上[37;38;153]，它使暴露统一接口的身份系统之间的互操作成为可能。这最好地实现了可移植性，而不仅仅是互操作性。鉴于身份元系统系统中的可移植性，可能会发生传递信任，即上下文或域之间的信任传递。
命名空间语法
有很多名称间隔约定，用于在命名空间中分层组织标识符。在这些约定中，最广泛支持的是统一资源标识符 (URI) (IETF RFC-3986) 标准 [147; 148]。我们采用URI的分层路径、查询和片段语法来定义自治标识符 (AID)。在我们的概念定义中，标识符以aid开始，有助于指示方案。接下来是一个冒号，然后是之前定义的Base-64编码前缀。前缀包括派生代码和派生的自认证标识符。其他冒号分隔的前缀选项可能跟随其后，然后是 URI 组件。更正式地说，语法如下：
1 | aid:prefix[:options][/path][?query][#fragment] (3.4) |
使用 URI 组件的 AID 示例如下：
1 | aid:BXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148/path/to/resource?name=secure#really |
这不是一个完整的规范，但足以说明这个概念。前缀提供了一种身份验证方法。其他组件提供了一种访问资源的方法。任何引用和AID的已签署声明均可被核实为具有权威性，并可作为授权（如何理解？）。
属性
AID 有几个有用的属性。
- 通用唯一标识符 (UUID)。由于其前缀，AID 是独一无二的，因此它可以用作 RFC 4122 [5] 定义的 UUID。UUID 使分布式应用程序能够在没有中央标识符服务器的情况下创建唯一标识符。前缀名称间距（prefiexed name spacing，如何理解？）允许对诸如时间顺序、词法顺序、嵌套等属性进行排序和搜索。
- 对资源执行操作的最小语言 (ReST)。URI 组件与为 ReST 接口开发的工具兼容。这促进了在微服务和无服务器应用程序中的采用，且安全性是内置的，而不是附加的。
- 分层确定性派生的自认证标识符。使用 URI 组件，我们可以很容易地为标识符指定分层确定性的派生路径，该路径能够创建派生密钥对，而不必存储派生私钥，而是仅从标识符和根私钥重新派生它们。这有助于密钥管理。（如何理解？）一个例子如下：
1 | aid:selfcertroot:/path/to/data?key-path=parent/child/child/child |
这些特征使 AID 成为在整个计算系统中使用的通用标识符方案的候选者。这一系列工作将更深入地探索自治命名空间的设计及其相关的安全性和操作特征。在KERI中使用的加密标识符前缀与密钥透明度项目中的公共加密密钥之间存在一些相似之处[93]。相似性是，在KERI中，基本的自认证标识符是具有派生码的公钥，而密钥透明度是公钥的可验证目录，主要是公钥，尽管可以使用签名密钥。还有其他几个重要的区别。KERI 标识符前缀可能是任何自认证标识符类型，而不仅仅是公钥。此外，KERI 中的密钥事件对于每个标识符前缀都是可分离的，这支持GDPR被遗忘的权利[67]（我理解的是可以弃用某个标识符）。KERI使用预轮换进行密钥轮换(见后面)。KERI 的密钥事件日志允许锚定发布事件。最后，标识符派生代码支持自包含的加密敏捷性（crypto agility）。（如何理解？）
总之，KERI 是一个全功能的 DKMI，而密钥透明度是一个简单的可验证的公钥目录。
统一标识符模型
一般来说，我们希望有一个理论或模型，如何设计具有理想属性的标识符系统。从历史上看，标识符系统的设计没有任何统一的理论来指导设计者。这意味着许多标识符系统在很大程度上是针对给定的应用程序定制的。这可能是有问题的，尤其是当标识符系统没有明确定义的安全方法时。最近，明确地描述标识符属性作为标识符系统设计的先决条件得到了一些认可。例如，众所周知的 Zooko三角指标识符的三个不同期望属性之间的冲突[155]。这三个属性是人类有意义的、安全的和去中心化的。三引理指出，标识符可以具有三个属性中的任意两个，而不是全部三个属性。一些人声称通过使用混合标识符系统解决了三引理，其中人类有意义但不安全的标识符可以在分布式共识分类账上注册。注册过程本身使用的标识符是安全和去中心化的，但没有人类意义[142]。解决三引理问题需要的不是一个标识符而是多个标识符的组合，这暗示了其中所采用的标识符模型是不完整的。
然而，自治标识符 (AID) 模型提供了一对统一的标识符模型。该模型采用安全第一的3方法。该模型基于识别，如果标识符没有安全控制，标识符的所有其他属性的值都很小。从这个意义上说，AID 模型提供了标识符的正式理论。所有标识符都可以在该理论的框架内进行分类和描述。该理论为标识符系统设计提供了一种原则性的方法，可用于通知和指导标识符系统任何具体实现的设计和开发。
KERI 的功能是以加密安全和可验证的方式在标识符 (AID) 上建立控制权限。一旦建立了控制权限，验证者就可以安全地验证AID控制器发出的任何关联授权。这些授权具有签名授权声明的形式，其中声明通常包括发布授权的AID。然后，验证者可以通过使用发布授权时权威的密钥来验证附加签名来验证授权。这些授权的安全性取决于所建立的控制权限是否安全。授权从相关的AID继承他们的安全性。AID的信任域是一组声明，可以安全地验证这些声明是由该AID的控制器(以及任何相关的事务或交互)发出的。然后，授权驻留在此信任域并受其保护。换句话说，授权是在发布它们的AID(或相当于AID的控制器)的支持下进行的。
合法的人类有意义的标识符 (LID)
给定一个 AID，我们现在可以统一标识符的其他理想属性，即人类的意义。AID 中的加密材料使其具有非人类有意义。相比之下，人类意义的例子可能是容易识别的单词或名称，或者更相关的一些有效的分层组织的字符组合。人类意义有两个限制特征。第一个是稀缺性，例如名称抢注，或注册或以其他方式维护控制的竞争条件。更重要的是，人类有意义的标识符没有固有的安全属性。这使它们默认不安全。然而，给定一个 AID 的信任域，任何人类有意义的标识符都可以在该信任域中唯一授权、批准或合法化。由于只有AID的控制器才能发布与该AID相关的可验证授权，因此只有该控制器才能授权在其信任域的支持下使用任何有人类意义的标识符。相关的授权声明使该人类有意义的标识符在信任域中使用合法化。这产生了一类新的标识符，我们称之为合法化的人类有意义的标识符，并使用首字母缩略词 LID。LID的一个重要性质是可以对给定的AID进行验证。该对形成了一个新的标识符对，我们可以表示如下：
1 | aid|lid (3.5) |
其中|表示下一个id在前一个id的信任域内被授权。我们可以将这种关系绘制如下：
这种耦合是一种特殊的名称间距类型。例如，假设LID是一本书的库 Dewey Decimal 代码，例如：
1 | 625.127C125r (3.6) |
进一步假设AID前缀由下式给出：
1 | EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148 (3.7) |
那么AID|LID可以表示如下：
1 | EXq5YqaL6L48pf0fu7IUhL0JRaU2_RxFP0AL43wYn148|625.127C125r (3.8) |
AID 的信任域提供了一个上下文来解释任何 LID 。AID 由上下文隐含，这意味着 AID 不必预先添加或出现在 LID 中（如何理解？）。这允许 LID 的人类意义在不受到 AID 阻碍的情况下表现出来。然而，LID 的任何验证者都从给定的上下文中知道如何验证 LID 的合法性。因此，任何现有的人类有意义的标识符都可以通过与 AID 的信任域相关联转换为可验证 LID。这如下图所示：
为了详细说明，这个AID|LID耦合将所有理想的标识符属性统一为一个标识符系统模型。AID提供安全基础设施，而LID提供特定于应用程序的人类意义。两者之间的联系由 | 表示的可验证合法化授权提供。有了这个模型，不再有任何与给定LID相关的全球稀缺性（不用抢注），因为每个 AID 都可以有自己的 LID 副本。稀缺性只出现在每个AID的信任域中，完全由该信任域(AID)的控制器管理。
为了进一步解释这个概念，我们可以将AID|LID描述为由两类标识符组成，即主要和次要的。主要标识符是 AID，对加密的信任根进行自认证。次要标识符是 LID，不进行自认证的，但在关联的主标识符的信任域的保护下得到保护。
系统中使用的所有其他标识符都可以分为第三类标识符，该标识符没有外部安全属性，但在本地应用程序的范围内可能很有用。出现在应用程序用户界面或其他本地上下文中，但与信任根没有显式可验证连接的标识符是第三级标识符。三级标识符只能在内部使用，而主要标识符和次要标识符可以在外部使用，因为它俩都是通过与主要标识符的信任根相关的可验证授权来保护的。主要标识符可能单独出现，但次要标识符必须出现在授权主要信任域的已知上下文中，或者与主要标识符一起出现。
这个统一模型现在可用于指导任何标识符系统的设计。主要 AID 的设计可以根据应用程序的特定安全、性能和治理属性进行调整。且可以调整 LID 的设计以提供标识符的任何其他理想的人类有意义的属性。
分布式账本
去中心化密钥管理基础设施自治命名空间标识符的主要替代方法是在基于分布式共识算法的分类账上注册标识符，该分类帐为相关的密钥管理操作提供主要信任根和真相来源。换句话说，分类帐是去中心化密钥管理基础设施(DKMI)的信任基础。分布式共识算法有多种类型，具有不同的特性。许多分布式共识算法的一个有用特性是来自多个来源的事件的总（全局）排序。这允许相关分类帐上的所有事务彼此具有唯一的排序。例如，在密钥管理的情况下，总排序属性使得建立密钥初始和轮换事件的排序变得容易。然而，分布式共识分类账可能需要大量必须设置、操作和维护的基础设施。通常，依赖于分布式共识分类账的基础设施必须在成本、吞吐量和延迟之间进行权衡。因此，其可扩展性或性能可能不如不依赖于分布式共识分类账或最小化依赖的基础设施。
混合信任基础
实际上，许多所谓的 SSI 系统在标识符上提供了一定程度的自我主权。它们或多或少是去中心化的。SSI 的一种流行方法是使用共享的分布式共识分类账来提供控制器、标识符和密钥对之间的绑定。这些分类账的治理可以高度去中心化。信任基础涉及两种不同的主要信任根。第一个信任根是账本本身，因为账本上的交易对于身份系统来说是权威的。因此，第一个信任的根源是运营基础设施，尽管它对利用具有高度的抵抗力。第二个信任根是用户创建的地址（标识符），用于访问分类账。该标识符源自用户创建密钥对的公钥。因此，信任的第二个根是加密的，并且是上文第 1.3.2 节中描述的自认证标识符的形式。共享的分布式共识总是一个逻辑集中的结构，其验证器节点合作(即达成共识)来编写分类帐的副本。分类账可能以或多或少的去中心化方管理。对于验证器节点，有些分类账是无权限的（公共链），而有些则是许可的。受许可的分类账可以是私有的，也可以是公共的。通常，分类帐是开放的，供任何支付使用费用的参与者使用。即使在无权限分类账上，分类账向参与者(用户)出租空间，分类账节点作为一个整体也无法审查哪些用户可以提交和支付交易。公共许可的分类账可以对节点审查用户的能力提供制衡。
边缘注册
一般来说，注册过程如下：为了在分类账上输入交易，每个参与的用户首先创建一个密钥对。公钥用于创建一个特殊情况标识符，该标识符使用户能够访问分类帐上的交易。例如，Bitcoin 地址或Etherum 地址标识符源自公钥。用户通过使用关联的私钥签署交易来证明对公钥作为分类账访问标识符的控制。假设用户现在具有访问权限，那么用户现在可以在分类账上注册属于关联的基于身份系统的分类账的标识符。通常，这样的身份系统在分类帐上使用初始事务来注册控制器、标识符和一个或多个密钥对之间的绑定。注册标识符和注册密钥对可能与用于初始化注册事务的分类帐访问标识符(公钥)不同。然而，注册在分类帐访问标识符和分类帐注册标识符的控制器之间进行隐式绑定。此注册过程可能涉及两个公私钥对。第一个控制注册事务，第二个是证明对注册标识符的控制。作为特殊情况，它们可能是相同的密钥对。当它们不同时，第二个密钥将具有权威性。当它们相同时，注册事务有效地将访问/注册标识符的控制转移到注册事务中绑定的新密钥对。（如何理解？注册事务在注册标识符与其密钥对之间创建分类账上的绑定。）下图说明了这个过程。
重申一下，通过允许用户创建自己的访问密钥对来实现一种安全去中心化的注册形式，其中访问标识符来自该密钥对。此标识符的目的是使用户能够与分类账交互。用户通过与相关的私钥签名来证明控制其访问标识符。访问标识符与在分类账上注册的标识符不同。因此，这种方法有两个信任根。第一个是分类帐，它需要对其操作基础设施和治理的信任。第二个是用户的分类帐访问标识符，它是用户选择的公钥/私钥对的公钥。注册标识符和用户对它的控制之间的绑定基于这两个信任根。重要的见解是，尽管注册过程是去中心化的，但该注册的信任基础包括分类账及其相关的交易安全机制作为主要信任根。因此，注册的标识符被印章在分类账上，任何相关的可信任交互也因此被印章在分类账的信任域上。因此，注册的标识符本身不一定可以移植到其他信任域。
相比之下，自治标识符在信任基础和域之间是完全可移植的。分类帐可以与自治标识符一起使用，存储上述控制转移日志的副本。在这种情况下，标识符不会被印章到该分类帐中，因此分类帐只是一个二次信任根。KERI设计通过使用依赖于加密主信任根的信任基础，并仅使用操作基础设施作为辅助信任根，提供了具有标识符完全可移植性的身份系统安全覆盖层。
信任扩展层
任何实体在互联网上的投影表现在实体之间的数据流。事实上，由于互联网作为数字通信媒介，实体及其投影数据流无法区分（如何理解？别人与互联网实体交互，别人只能得到相互通信的数据流）。这些投影数据流的一个目的是使实体能够远程交互。这些交互可能具有价值，因此需要是值得信赖的。互联网的问题是，我们没有足够的人类基础来建立对这些数据流的信任 [45; 153）。因此，我们需要另一个信任基础。但正如引言中提到的，互联网并没有被设计成内置的安全机制来提供信任的基础。重申一下，这项工作试图通过普遍的安全覆盖为信任提供一个合适的互联网基础。
统一信任基础和信任域
理想的情况是建立一个通用的信任基础，它为所有互联网交互产生一个单一的信任域。然而，一种更实用的方法是互联网交互的可信跨越层[7；23；24；42]。跨越层的基本特征是它提供了一个单一的接口，通过该接口，它下面的所有支持基础设施以及它上面的所有支持的应用程序都可以互操作。在安全性方面，可信跨越层提供了一个单一的可互操作机制或协议，通过该协议，所有跨越的信任基都支持所有跨越的信任域（如何理解？）。这种单一机制简化了跨信任域中的参与者之间的交互。它必须为标识符与其控制之间的绑定以及标识符和相关资源的信任基础之间提供安全的可移植性。相关资源不仅包括 IP 地址，还包括任何支持相关的基础设施、服务，尤其是内容。我们相信具有环境可验证性的自治命名空间是提供该跨层协议的最佳候选者。
背景
建立了跨越层的概念来描述互联网协议之间依赖关系的沙漏形状[7；23；24；42]。下图说明了这种观点：
IP协议是互联网的跨层[7；23；24；42]。这可以更抽象地表示为沙漏中的一组层，其中沙漏的窄腰是IP层。
IP 既是互联网的跨越层，也没有构建安全机制，这使得互联网的安全性被破坏是显而易见的；它的跨越层是不安全的（不可信任的）；这个安全问题的一个解决方案是向 IP 添加可信任的安全覆盖，成为互联网信任的跨越层。
沙漏定理说明了一个跨越层的特征[23;24]。分层系统设计中的每一层都可能跨越其下方的层中的多个支持以及上面一层的多个应用程序。沙漏定理将层中的弱点定义为提供更少的功能（如何理解？）。与更强的层的复杂性相比，较弱层的简单性、通用性、资源限制和部署可扩展性往往会获得更广泛的采用。弱点导致层中的以下属性：
- 简单性意味着有一种方法可以通过跨层访问任何服务或资源。
- 通用性意味着跨层具有最丰富的可能应用程序集，而不会增加其逻辑复杂度。
- 资源限制意味着跨层限制支持的应用程序的资源访问。
- 部署可扩展性意味着广泛采用。
最小限度的跨越层是仍然支持必要应用程序的最弱层。下图说明了这一点：
我们相信，具有 KERI 的自治标识符 AID 形成了一个自治身份系统 (AIS)，它是互联网最低限度充分信任跨越层的可行候选者。它的自认证的主要信任根很简单，不需要操作基础设施来发布标识符。如下所述，KERI 提供了最小的二次信任根来支持控制转移到新的密钥对。由于身份系统安全覆盖必然使用IP层以上的协议，AIS不能在IP层跨越互联网，但必须跨越它上方的某个地方。这就产生了一个双腰部或腰部和颈部形状，其中安全覆盖层是颈部。这如下图所示：
在这种情况下，support是使用标准 KERI 声明集互操作的信任基础或平台，从而实现了应用程序信任域之间的可移植性。这如下图所示。
标识符到IP地址的映射
鉴于自治身份系统 (AIS) 可以作为 Internet 的信任跨越层，那么DNS的作用是什么呢？最初 DNS 可以充当 AIS 下面的层，具有将AID映射到DNS标识符的安全授权。然而，最终 AIS 可以通过将 AID 直接映射到 IP 地址来替换 DNS。回想一下，信任根意味着签名声明可以用作加密可验证的授权。在 DNS 中，标识符和 IP 地址之间的映射发生在一个区域文件中。如上所述，DNS 系统的安全弱点源于它对操作基础设施的正确管理的依赖。映射的来源受制于操作基础设施中的漏洞。AIS可以向自认证的信任根提供加密可验证的来源。
虽然这里没有提供，但这项工作的扩展将是为可以替换 DNS 的 AIS (KERI) 定义一个标准发现和解析系统。这将提供一个去中心化的安全通用开放标准覆盖层，允许任何控制器(用户)将自己选择的标识符映射到具有相关IP地址的计算设备。因此，标识符中固有的值将仅在用户的控制下。尽管 IP 地址是通过管理方式分配的，但互联网设计的初衷是让IP地址能够根据地理位置自由地、无歧视地分配给计算设备。不幸的是，最初的IPv4地址分配为一些实体保留了大块，这造成了过早的人为短缺，从而使它们不那么自由[81;82]。切换到IPv6将恢复IP地址分配的本质上自由的非歧视性质[83;84]。5G网络的部署也加速了这种转换[34]。向IPv6的过渡为“修复”互联网的信任层提供了一个独特的历史性机会。IPv6地址长128位，前缀64位，后缀64位。这意味着一个安全的直接标识符覆盖到IPv6，绕过DNS不仅是可能的，而且是迫在眉睫的实用。
如前所述，身份系统安全覆盖将控制器、标识符和密钥对绑定。这些绑定使系统能够安全地将标识符映射到相关设备的 IP 地址。使用 AIS，控制器可以通过可验证数字签名证明其标识符与其设备的 IP 地址之间的映射。鉴于控制器能够独立控制其标识符到 IP 地址的映射，控制器可以随意将这些标识符分配给具有IP地址的设备，然后根据需要重新分配它们。然后控制器还可以移动与这些标识符相关的资源或内容。然后，AID 的 URI 部分可以在设备之间透明映射，而不会破坏任何链接。这提供了控制器(用户)定义的指向内容和值的间接链接(标识符)。因此，在某种意义上，内容和价值也成为自主的。（如何理解？控制器可以控制标识符指向哪些内容。）
密钥管理
最小充分
在我们看来，最小充分一词意味着更好地契合沙漏定理中弱点的含义[23；24]。长期以来，我们一直使用最小充分手段作为设计美学[45；136]。这种设计美学引导我们将所提出的方法设计为互联网的信任跨越层（安全覆盖层）。同样，这种设计美学导致了更具可扩展性和性能的去中心化密钥管理基础设施(DKMI)，它不需要完全有序的分布式共识分类账，但如果有的话，仍然可以使用一个作为次要事实来源。它利用了这样一个事实，即只有私钥的持有者可以创建和排序事件，这些事件对密钥执行可验证操作。因此，二级的信任根和真实性来源只需要见证事件和它们的排序，而不提供排序。只要保留事件历史的完整可验证副本，就可以确定控制权限的来源。KERI 的主要目标是为可转移的自认证标识符提供标准机制，以验证控制密钥对的序列。这种机制是密钥事件收据的目击（有签名）日志，该日志提供了二级信任根和真实性来源，以实现对标识符当前控制权威的可验证性。
对于基于自认证标识符的去中心化身份系统，相关私钥的控制和管理是必不可少的。因为控制实体持有私钥，管理的主要负担属于该实体。身份的安全性是管理基础设施安全性的一个功能。如上所述，与中央管理实体控制所有标识符的集中式身份系统不同，去中心化身份系统可能有多种控制实体，每个实体控制一个或多个标识符。其中一些实体可能没有资源或专业知识来设计、构建和维护安全关密钥管理基础设施。因此，需要开放的可互操作的去中心化密钥管理基础设施（DKMI）。此外，去中心化身份的一些应用可能受益于可扩展且性能良好的 DKMI。示例应用程序包括数据流、物联网、以及多个控制实体中的数据出处很重要的其他应用程序，数据处理要求很高。组合可扩展和性能基础设施的一种设计方法是为每个密钥管理任务找到最小充分的方法。这是这项工作的主要动机，即确定对基本密钥管理任务的最小充分手段。
三个主要关密钥管理任务是密钥复制、密钥恢复和密钥轮换。我们称这些为密钥管理的三个 R [1]。这项工作的重点是密钥轮换，这通常是最困难的。
复制
密钥复制包括密钥对的创建和派生，以及私钥的相关跟踪和存储。总的来说，简化密钥复制任务的一种方法是使用分层确定的密钥派生算法，生成HD密钥或密钥链[9;73;91;136]。HD 密钥对通常源自高熵根以及一些确定性的密钥派生路径来派生。密钥路径可能是公开的。这意味着不需要存储派生的 HD 私钥，因为派生的私钥可以根据根密钥和公共派生路径的需求重新派生出来。
恢复
密钥恢复涉及安全备份或分发私钥的方法，以便可以在保持私钥的设备丢失或损坏的情况下恢复它们。密钥恢复方法将在别处讨论[136]。（因此有一个备份是很重要的哈）
轮换
从控制的角度来看，密钥轮换有效地将权威控制（根权威）从一组密钥对转移到另一组密钥对上。密钥轮换涉及安全撤销密钥对并用新密钥对替换它的方法。不替换的撤销可以通过轮换到空密钥来完成。（改进的方案目前不支持轮换到空密钥）因此，轮换可以被实现为主要操作，而撤销（没有替换）可以作为轮换的一个特例来实现。轮换到空密钥意味着不允许使用此标识符进行更多操作。标识符被丢弃。
目的
在去中心化的身份系统中，当自认证标识符的控制器需要无限期地维护对该标识符的持久控制时，密钥轮换是有用的。否则在被攻击者利用的情况下，控制器只能放弃该标识符，并创建一个新的密钥对的新标识符。密钥轮换的主要动机是防止、减轻或恢复由于暴露而导致的私钥利用。暴露的主要风险来自于使用私钥来签署声明。创建签名通常需要将私钥加载到生成签名的计算设备上。攻击者可以通过远程利用或物理捕获计算设备来获得对私钥的访问。此外，随着时间的推移，计算和密码学的进步可能会削弱给定密码系统的加密强度。因此，最佳实践是使用相同的密码系统或更强的密码系统，将给定密钥对的轮换到新的密钥对。
轮换历史
通过可转移的自认证标识符来进行轮换。不会更改从公钥派生的自认证标识符，而只更改用于签署声明的权威私钥。因此，为了验证属于可转移自认证标识符的声明，验证者必须知道该标识符的密钥轮换历史。回想一下，在自认证标识符中，它的前缀派生通过单向函数绑定到这个原始公钥。此原始私钥用于对声明进行加密签名，以证明在发布时对标识符的控制。原始公钥用于加密验证相关签名。这个初始密钥对是可以对标识符行使根权限。这个密钥对到一个新的密钥对的轮换本质上是转移可以执行根权限。这些轮换声明的历史记录可用于确定当前根授权密钥对的来源。这个历史形成了一系列操作（事件），可以称为根权威历史。
为了详细说明，可验证声明的每个轮换操作都会创建一个新的（公共的、私有的）密钥对。第一次轮换操作至少必须用原始私钥签名。轮换不会改变标识符。它仍然引用从原始公钥派生的前缀。然而，轮换后，权威声明现在用新的私钥签名，并用新的公钥进行验证。原始私钥已被撤销并替换为轮换操作中指定的新私钥。新的公钥包含在标识符的密钥轮换历史中。声明的验证首先需要对密钥轮换历史进行查找和验证。最终的轮换条目提供了用于签名和验证声明的当前密钥对。
用于控制标识符的数字签名密钥的密钥轮换历史为权威管理与标识符关联的任何其他数据提供了基础。一般来说，对与标识符关联的属性值的更改可以由使用权威签名密钥对的可验证签名断言来管理。因此，签名密钥对的管理能够管理附属数据，包括其他密钥等。
暴露后轮换
为了澄清这一点，定期轮换密钥降低了密钥暴露后标识符价值被窃取的风险。这可以主动用于升级数字签名密码系统，以跟上计算的进步。（我们的方案也可以更改密钥类型）更难以解决的问题是，在某个特定的漏洞可能已经发生之后(被攻破后)进行轮换（KERI用预轮转解决此问题）。在这种情况下，在原始控制器检测到漏洞之前，攻击者可以在利用者控制下对密钥对创建有效的签名轮换操作。因此，攻击者既可以“捕获”标识符，也可以创建一个冲突或竞争条件，其中创建了两个不一致但可验证的轮换事件。KERI使用预轮换的思想，以解决可能发生攻击后的安全轮换问题[136]。
命名和组件
KERI系统旨在与微服务或无服务器计算架构中的性能数据流或事件源应用程序兼容（如何理解？）。因此，每个函数都被模块化为可组合的功能原语或元素。系统的组成部分可以通过原语的递归组合来构建。因此，系统组件可以由这些可组合原语的组合组成。
下面是KERI中的组件。该基础设施包括下面描述的相关组件，例如控制器、验证器（validators）、验证器（verifiers）、见证人、监视者、陪审员（陪审员s）、法官、解析器及其相关的 KEL、KERL 和 DEL [135]。本节还提供了协议消息各个元素的术语定义和符号表示。
单向函数
如上所述，单向函数是一种在一个方向上易于计算但在反方向上难以反转或计算的加密过程[111];112]。单向函数提供了该协议的基本功能。
大整数编码
该协议使用的序列化编码标准是 RFC-4648 Base64 URL-Safe 编码标准 [88]。这用于对源自大整数的前缀、公钥、签名、摘要和其他元素进行编码。必须对它们进行编码，以便在存储、通过网络传输或包含在签名或散列的序列化数据结构中一致地表示。Base64使用一个高度可互操作的ascii字符集子集。它是最紧凑、可广泛互操作的编码。
合格密码材料
合格的密码材料例如标识符、公钥、摘要或签名，将材料派生过程的规范附加到材料上。合格的密码材料可以由数据结构或有序元组表示，其中包括密码材料及其派生。此类项目的更紧凑的形式是具有一个或多个前置派生代码字节的 Base64 编码。合格密码材料的上下文和位置决定了用于解释派生代码的派生代码的类型（如何理解？）。有两个重要的位置。第一个在密钥事件中，第二个是附加到密钥事件的签名。被攻击签名可以使用不同的派生编码，该编码包括当前签名密钥列表中的索引或偏移量，以便将签名与验证签名所需的公钥进行匹配。
合格的密码材料项目示例包括如下：
合格标识符（qualified identifier）是标识符的表达式，该标识符将其派生过程信息附加到唯一派生标识符材料中。该协议中使用了特殊术语前缀或标识符前缀来表示合格的自认证标识符。
合格的公钥是公钥的表达式，它将其派生过程信息附加到公钥。这可以以紧凑的形式提供，在Base64中添加一个前置的派生代码。Base64 编码格式可能与用于基本自认证标识符前缀类型的格式相同。
合格的摘要是加密强度单向散列过程的摘要输出的表达式，该过程将其派生过程信息附加到摘要上。这可以以紧凑的形式提供，在Base64中添加一个前置的派生代码。除非另有说明，本协议中所有摘要的表示都是合格的。
合格的签名是附加数字签名的表达式，该签名在其派生过程信息添加到签名中。这必须包括签名方案。这与标识符前缀中使用的签名不同。这可以以紧凑的形式提供，在 Base64 中带有前置派生代码。派生代码还可以包括验证签名所需的公钥的当前签名者(公钥)列表的索引，除非另有说明，否则该协议中的所有签名表达式都是合格的。
隐藏的合格密码材料项目是合格密码材料的表达式，其派生包括一个附加的单向散列步骤，该步骤生成公钥的摘要。该材料在项目中没有显式提供，而只是摘要。在这种情况下，实际材料被摘要隐藏。这可能有助于对将来可能披露的材料做出可验证的加密承诺。
隐藏的公钥是一个合格的公钥，其派生包括一个额外的单向散列步骤，该步骤产生公钥的摘要。在这种情况下，实际的公钥不会在限定的公钥中显式提供，而仅仅是摘要，因此是隐藏的。这可能有助于对将来可能披露的公钥做出可验证的加密承诺
隐藏签名阈值和公钥集是签名阈值与一组合格的公钥，其中集合的派生包括一个额外的单向散列步骤，该步骤生成序列化的阈值说明符和一组合格的公钥的摘要。在这种情况下，没有显式地提供实际的公钥，而只是提供摘要，因此是隐藏的。这可能有助于对一组将来可能公开的公钥做出紧凑的可验证加密承诺。
印章（seal）是一个合格的摘要，其派生代码指定使用哪种类型的散列函数，但不包含有关相关数据的任何其他信息。印章充当数据的锚。需要说明的是，实际数据并没有显式地提供在印章中，而仅仅是序列化数据的摘要，因此数据是隐藏的。这对于在事件位置对其他地方存储和/或公开的数据做出可验证的加密承诺可能很有用。
自认证标识符前缀
自认证标识符前缀/标识符前缀/前缀/标识符（即自认证标识符前缀=标识符前缀=前缀=标识符）是一种合格的加密材料，它包括通过包含一个或多个加密数字签名密钥对的一个或多个单向函数普遍唯一派生的材料（如何理解？）。派生过程以加密方式唯一地将生成的自认证标识符前缀绑定到这些密钥对。合格的前缀将其派生过程信息附加到其派生的唯一标识符材料上。前缀的派生过程规范(简称派生)必须指明用于数字签名方案的密码套件以及派生过程的其他部分。派生可以表示为数据结构，例如映射或有序元组，其中有序元组包括原始公钥的元素以及派生的其他部分。派生可以紧凑地编码为与 Base64 编码兼容的字符代码。因此，可以使用前置 Base64 派生代码以 Base64 中的紧凑形式提供合格的前缀。
标识符前缀是一种自认证标识符，用于创建标识符的名称空间。标识符前缀通过派生过程绑定到一组初始数据。除非另有说明，术语标识符前缀可能适用于从初始数据中定义的任何类型的派生过程。此外，由于其派生过程，前缀唯一地绑定到一个或多个初始密钥对。这些密钥对表示在前缀开始和发布时对前缀的根控制权限。它们构成了发布时前缀的控制密钥集。此外，前缀关联命名空间中的所有标识符都由与前缀相同的控制密钥对控制。因此，协议在建立控制权限时只需要考虑前缀。
自认证标识符的推广表示由派生和由此产生的唯一derivative组成，如下所示：
这些一起可以编码（BASE-64 URL Safe）到前缀的单个字符串中，如下所示：
1 | BDKrJxkcR9m5u1xs33F5pxRJP6T7hJEbhpHrUtlDdhh0 |
密码学将用户为各种密码学操作(如签名、加密和散列)选择的选项限制为一组均衡的协议集。这可以防止用户做错误的选择。许多密钥表示方案允许用户自由独立指定操作的特征，这通常是一个非常糟糕的想法[14;138;139]。用户不应该自定义组合不属于最佳实践密码套件的不同功能。每个自定义配置都可能容易受到潜在攻击向量的攻击。建议的方法是为每个操作严格指定单个密码套件系列和版本。如果发现了针对套件成员的漏洞并进行了修复，则该套件将完全更新为新版本。允许的密码套件的数量应该最小化到那些必需的兼容性。这种方法增加了表达能力，因为只需要一个语法元素来指定一个套件，而不是每个特性都需要不同的元素。
前缀中的派生元素指定了一个密码套件。一个很好的例子是用于 DID 文档身份验证部分中 W3C DID（去中心化标识符）类型字段的规范格式。这是一个包含密码套件族、操作和版本的字符串。例如，family=Ed25519，operation = verification，version = 2018，可以表示如下：
1 | Ed25519VerificationKey2018 (7.1) |
可以在收到签名初始声明后验证数字签名密钥对的控制权威。该声明包括标识符的派生过程规范、权威的公钥以及任何其他相关的配置信息。它由权威的私钥签名。
密钥对标签
密钥对标签约定使事件表达式更加清晰和更紧凑。作为标识符前缀的简写，表达式中的每个实体都可以用大写字母符号表示，例如 A、B、C 等。此外，每个自认证标识符都必须至少有一个初始控制密钥对在发布时绑定到它。在只有一个初始控制密钥对的情况下，密钥对可以用与实体的别名相同的字母符号来表示，但公钥使用大写，私钥使用小写。例如，具有密钥对(A,a)的实体 A，其中 A 表示公钥，a 表示私钥。通常上下文确定要使用密钥对的哪个成员。
如果使用一组多个控制密钥对，那么可以使用$\left(A^j, a^j\right)$来表示，其中j是索引，$A^j$ 和$a^j$分别是第 j 个公钥和私钥。可以使用一系列索引的公钥来表示密钥对的序列，如下所示：
有时，表示一类相似实体的单个成员可能会有用，这可以用带数字下标的大写字母符号表示。例如，令 C 表示控制器，则 $C_0$ 和 $C_1$ 分别表示来自两个不同控制器的密钥对。
此外，通过它在带有大写字母下标的事件中使用的性质来标记每个密钥对也有用。例如，对于标记为 C 的控制器，令 R 表示轮换事件中使用的密钥对，X 表示交互事件中使用的密钥对。这两个密钥对可以分别表示为 $C_R$ 和 $C_X$。
它们也可以组合起来使用。例如，上标表示事件索引（密钥事件索引），下标表示某控制器。或者，可以使用字母或字符串下标来表示事件类型，例如 $C_R^1$ 和 $C_X^2$。
因为协议表达式通常指的是给定的控制器，所以通常情况下可以省略类成员数字下标。例如，给定控制器C，事件序列的标记密钥对的使用顺序可以表示为：
有时，表明密钥对中的私钥已经暴露出来，可以使用例如$\dot{C}_R^1$与$\dot{C}_X^1$。有时，表明给定的公钥还未使用，可以使用例如$\underline{C}_R^1$。
序列化数据
具有有序字段的数据结构可以由元组表示，例如$(t,A,C)$。该数据结构的序列化版本用$\langle t, A, C\rangle$表示。
签名
数字签名是合格的密码材料类型，其中包括一串字符，该字符串是通过使用私钥对给定字符串字符（签名文本）进行加密操作生成的。合格的签名将其派生过程信息附加到摘要中。它的派生包括数字签名方案的类型。这可以用 Base64 中的紧凑形式提供，并带有派生代码。派生代码还可以在当前签名公钥列表中包含索引，该列表指定可以使用哪个公钥来验证签名。
数字签名有两个重要属性：（1）对于给定签名文本的密钥对，签名是唯一的；（2）签名是签名者不可否认的，也就是说，只有私钥的持有者才能创建签名。
数字签名操作可以用$\sigma$表示。使用密钥对$A^0$的实体 A 对序列化数据$\langle t, A, C\rangle$的数字签名可以表示如下：
一种等价的形式如下所示：
包含序列化数据结构和附加签名的消息可以表示如下：
具有两个附加签名的消息，分别来自实体 A 和 B ，可以表示如下：
可以简化表示如下：
也可以用更简化的形式：
可转移(不可转移)标识符
可转移的（不可转移的）标识符允许（不允许）通过轮换事件将其控制权限从当前控制密钥集转移到新（下一个）的密钥集。标识符可以在初始时在其派生代码和/或初始事件中声明为不可转移的。派生代码声明仅针对基本的自认证标识符定义（如何理解？）。可转移标识符上的轮换事件(操作)可以轮换到空密钥，从而不可逆地将其转换为不可转移的标识符。一旦标识符变得不可转移，该标识符不允许更多事件。从 KERI 的角度来看，标识符被放弃了。按照惯例，当标识符的不可迁移性在其派生代码中声明时，其权威（签名）密钥对可以转换为加密密钥对，以便仅使用不可传输标识符的交换来建立安全通信通道[56, 149]。尽管从 KERI 的角度来看放弃了不可转移的标识符，但它并不排除给定应用程序使用该标识符。它只是在标识符上不允许更多 KERI 中的事件（如何理解？虽然KERI崇尚使用可转移标识符，但使用不可转移标识符也是没有问题的）。在初始声明为不可迁移的标识符有且只有一个事件，即初始事件。从这个意义上说，不可转移的标识符是预先放弃的。这些标识符通常旨在用作临时标识符，或者当标识符被攻击者利用时，首选的方法是替换标识符而不是密钥轮换。
控制器
控制器是标识符的控制实体。在任何时候，标识符至少有一个但可能有不止一个控制实体。令 L 为控制实体的数量。这组控制实体构成了控制器。当控制实体集中只有一个成员时，标识符上的所有适当的密钥管理事件都必须包括来自此控制实体的签名。当使用集体签名方案时，此签名可以表示为单个集体签名。不失一般性，当上下文明确时，控制器可以指整个控制实体集或控制实体集的一个成员。通常，当有多个控制实体时，控制是通过 L 个签名建立的，每个实体一个（控制器），这简称为多签名（一个标识符由多个实体控制）。或者，使用 L 阈值控制方案的 K，其中 $K \leq L$，控制是通过任意一组至少 K 个签名来建立的。随后协议的描述假设最简单的个人签名而不是集体签名的情况，但协议可以扩展到支持集体多签名方案。
声明
声明是任何可以数字签名的数据。声明可用于对与该标识符关联的标识符或属性执行一个或多个操作。声明包括一个密码可验证的签名。在给定的上下文中，可以假设所有声明都是可验证的。
消息
协议使用的消息是具有一个或多个附加签名的序列化数据结构。数据结构必须序列化，以便进行数字签名。消息是一种可验证的声明。
事件
事件可以由与协议相关的消息表示，通常是与标识符相关的操作。事件消息是明确定义的可验证声明。该协议主要关注由消息传递的事件的创建、传输、验证和记录。给定事件与其消息之间的一对一关系，它们可以在上下文中互换引用。
版本
版本标识一组给定的协议规范。版本控制使协议具有可互操作的可扩展性。每个版本都表示一个明确定义的特征集。版本包括主版本号和次要版本号。每个事件都包含版本。版本字符串还包括用于编码事件的序列化编码（例如 JSON、CBOR、MessagePack 等），以及序列化事件的大小（如何理解？？）。这允许解析器确定如何解析消息并从附加的签名中提取消息。版本字符串也以终端分隔字符结束。这允许将来检测到版本字符串格式的变化。
一个紧凑的示例版本字可能如下：
1 | "KERI10CBOR0001c2" (7.10) |
其中 KERI 是 KERI 事件的标识符，1 是主要版本代码，0 是次要版本代码， CBOR是事件的序列化编码格式，0001c2 是序列化事件的大小。版本字符串提供了一种自包含的方法来确定序列化事件的编码和长度。
当使用 HTTP 等 Web 协议时，使用结构化语法后缀来指示编码以使用MIME类型标准的一种方法[65];72]（如何理解？）。KERI编码的建议mime类型是：
1 | application/keri+json, application/keri+cbor, application/keri+binary, application/keri+msgpack. |
事件摘要
密钥事件消息摘要或摘要是一个合格的摘要。它是一种合格的密码材料，它是密钥事件消息序列化的单向哈希函数的输出。加密摘要是消息的空间高效且唯一的指纹。合格的摘要将其派生过程信息附加到摘要中。它的派生包括哈希函数的类型。这可以以Base64中的紧凑形式提供，并附带派生代码。
一个合适的哈希函数和摘要格式的例子是由Blake3、Blake2b或Blake2s哈希函数产生的256位(32字节)的Base-64编码字符串[17;31;33;121]。它们的加密强度为128位。对于这种长度和强度的摘要，Blake3是目前性能最好的哈希函数[31]。
事件Ilk
密钥事件 ilk 表示密钥事件的类型 ，以帮助其解析。建议的ilk值和事件如下：初始事件的icp、轮换事件的rot、交互事件的ixn、委托初始事件的dip、委托轮换事件drt、委托轮换事件rt、事件收据消息rct、validator事件收据消息的vrc。
密钥事件
密钥事件是与给定标识符相关联的特殊类型的事件。序列中密钥事件的出现顺序由控制器决定。密钥事件可用于管理标识符的权威密钥对。正确的密钥事件消息是可验证的，因为它包括来自相关标识符的权威密钥对的签名。正确的密钥事件包括标准密钥事件头中的几个元素，例如版本、前缀、序列编号、事件摘要和 ilk。密钥事件还包括事件特定的配置数据与签名。抽象表示如下：
密钥事件序列
密钥事件序列是密钥事件消息的唯一有序序列。序列中的密钥事件消息链接在一起，因为除了第一个事件之外的每个事件消息都包含上一个密钥事件消息的摘要。一系列事件消息如下所示：
密钥事件序列号（sn）和事件标记
密钥事件序列中每个事件的序列号 (SN) 由唯一单调递增的非负整数表示。
如果密钥事件序列号达到上限，那么必须放弃相关标识符。上限是 128 位（16 字节）二进制数的编码版本的长度。实际上，64 位（8 字节）二进制数足以满足许多应用程序。
序列号的目的是支持对事件进行更方便、更高效的安全处理。序列号为序列中的每个事件提供唯一的数值索引。这可用于排序、索引事件。使用事件消息的签名内容中包含的索引可以保护通过索引访问或提供事件的应用程序编程人员接口(API)调用（如何理解？）。对于密钥事件消息的传输，16 字节二进制数编码为 24 个 Base64 个字符，包括 2 个 pad 字符。对于存储来说，索引必须是固定长度的字符字符串，而不是任意精度整数。
抽象地，使用$t_k$可以代表序列号，k代表序列号出现的顺序。最简单的话，$t_k$可以当作一个计数器，整数值从 0 开始，每个新事件递增 1，在这种情况下，每个序列号值$t_k$等于其数值下标 k ，即：
$\mathcal{E}$代表密钥事件，$\mathcal{\varepsilon}_k$代表第k个密钥事件。$\mathcal{E}_k^A$代表标识符A的第k个密钥事件。使用这种约定，标识符A的签名事件消息可能表示如下：
序列化消息$\left\langle t, A, A^0, A^1\right\rangle$的摘要可以表示为：
由序列化数据结构和附加签名组成的完整事件消息的摘要可以表示如下：
$\eta_k$表示第k个事件消息的摘要，其定义为（由于始终包含上一个事件）：
建立事件
建立事件是一类密钥事件，用于为标识符建立当前权威密钥对。建立事件的主要目的是帮助为标识符建立当前的控制权限，通常与密钥创建和轮换有关。建立事件中的配置数据包括指定支持基础设施（用于在标识符上建立和维护控制权限）。配置数据还声明下一个权威密钥集作为预轮换方案的一部分。建立事件的类型包括初始事件和轮换事件。下面给出了一个基本的建立事件消息：
初始事件
初始事件是一个建立事件，它表示标识符的创建操作，包括其派生、初始控制密钥集以及支持基础设施的其他初始或配置数据。在标识符上仅可以执行一个且只有一个初始事件操作。需要初始事件来控制建立。下面给出了一个基本的初始事件消息：
轮换事件
轮换事件是一个建立事件，它表示对标识符的轮换操作，该标识符将控制权从当前控制密钥集转移到新集合。轮换事件是一个建立事件。轮换操作可以看作撤销和替换密钥的组合。基本的轮换事件消息如下所示（可以看到与初始事件相比，多了一个payload）：
对于每个标识符（前缀），都有一个唯一的链式密钥事件消息的有序序列，该序列从一个初始事件消息开始。在这个密钥事件消息序列中是建立事件消息的子序列（如何理解？可能密钥事件消息序列不仅只有建立事件），它从初始事件消息开始，然后可能有一个或多个轮换事件消息。这个建立子序列可以称为标识符的建立或轮换(事件)历史。一个有效的密钥事件序列可能只包含建立事件。在这种情况下，建立事件子序列等于密钥事件序列。这如下所示：
非建立事件
非建立事件是一种密钥事件，它与建立事件子序列中的事件交织在一起，以便可以在非建立事件出现的交错序列顺序点上对当前控制机构(根权威密钥对)进行加密验证（如何理解？）。非建立事件包括一个事件特定的数据有效负载。下面给出了一个基本的非建立事件消息：（没有public key config与other config）
非建立事件不声明预先轮换的密钥（稍后定义），并且仅由当前权威的密钥集签名。回想一下，密钥事件历史由一个有序的链接密钥事件消息序列组成。事件消息被链接，因为除了初始事件之外，序列中的每个事件消息都包含序列中所有上一个事件消息的摘要。建立事件集包含一个子序列，该子序列交织在完整的密钥事件序列中。非建立事件之前的建立事件的子序列可用于建立非建立事件的当前控制权威，从而将非建立事件与其控制权威联系起来。具体来说，非建立事件与建立事件交织在一起，可以在发布非建立事件时对权威密钥对进行加密验证，其中事件的时间是通过其在序列中的出现顺序来度量的。这提供了非建立事件本身与用于建立其控制权威的密钥事件之间的可最终验证的安全绑定。在验证了授权密钥对之后，可以将非建立密钥事件的签名验证为正确。许多非建立事件可能发生在建立（密钥轮换）事件之间。尽管通过重复使用签名密钥对非建立事件进行签名，这将公开签名密钥，但是在最近的轮换事件中声明的预轮换后续签名密钥不会公开，并且可以通过以后的轮换来从受损的签名密钥中恢复。非建立事件中的数据有效载荷可能永远不会用于建立自己的标识符的根控制权威，但可以用来为其他目的制作可验证的权威声明。这些可能包括加密密钥的授权，或通信路线或服务端点等。
印章（seal）
印章是以加密摘要或哈希树根（Merkle 根）的形式加密承诺，该根将任意数据或任意数据的哈希树锚定到密钥事件序列中的特定事件 [104]。印章提供了真实性的证据。密钥事件序列提供了其中每个事件的当前控制权威的可验证证明。因此，从这个意义上说，事件中包含的印章提供了当前控制权威的证明，即锚定在事件序列中印章位置的数据的真实性（如何理解？）。印章是一个有序的自描述数据结构。抽象地说，这意味着印章的每个元素都有一个描述相关元素值的标签。到目前为止，有四种类型的印章，它们是摘要、根、事件和位置印章。
摘要印章包括外部数据的摘要。该值是完全合格的 Base64，带有一个附加的派生代码，该派生代码指示用于创建摘要的哈希算法的类型。
根印章提供外部数据的哈希树根。该值是完全合格的 Base64，带有前置派生代码，指示用于创建散列根的哈希算法的类型。为了防止pre-image攻击，用于KERI印章中的哈希树根的哈希树必须是稀疏的，并且具有类似于证书透明度的已知深度（为什么？）[47;70;95 - 97]。表示深度的一个简单方法是：稀疏树中的内部节点包括一个深度前缀，它在每一层递减，并且必须在叶子上保持非负[47]。
事件印章包括密钥事件日志中事件的标识符前缀、序列号和摘要。前缀、序列号和摘要允许定位事件日志数据库中的事件。事件印章将一个事件锚定到另一个事件。这两个事件可以在相同的密钥事件序列中，也可以在具有不同标识符前缀的两个不同的密钥事件序列中。因此，印章可以从其他密钥事件提供对某些密钥事件的加密承诺。
事件位置印章类似于事件印章。位置印章包括来自事件的前缀、序列号、ilk和先前的摘要（多了一个事件类型ilk）。这四个值唯一地标识事件在密钥事件日志中的位置。当两个不同事件中的两个印章相互交叉锚定时，位置事件很有用。这提供了一个事件到另一个事件的交叉引用，其中另一个事件的摘要必须在事件内容中包含印章，因此它不能包含第一个事件的摘要，而是包含前一个事件的摘要。为了澄清起见，摘要创建意味着只有其中一个交叉锚可以包含另一个事件的完整摘要，另一个交叉锚必须使用唯一的数据子集，例如事件的唯一位置。由于恢复的特殊情况，即轮换事件取代了交互事件，因此需要ilk（没看太懂）。位置印章在锚定到事件日志的外部数据中也很有用。位置印章允许外部数据包括对锚定外部数据内容的事件的引用。因为锚定事件包括一个带有外部数据摘要的印章，所以它是另一种交叉锚形式。
提供印章元素的数据结构必须具有规范的顺序，以便可以在事件元素的哈希中复制它（如何理解？）。不同类型的序列化编码可以提供不同类型的有序映射数据结构。一种通用规范排序数据结构是(label,value)的列表。每个(label,value)对的每个列表中的出现顺序都是标准化的，可用于生成相关值的序列化。
印章中与摘要或哈希树根相关的数据的解释与KERI无关，即 KERI 对锚定数据语义不可知。这更好地保留了隐私，因为印章本身不会泄露有关相关数据内容的任何信息。此外，由于哈希是一种内容地址，它们是自我发现的。这意味着无需为哈希提供任何类型的上下文或内容特定标签。使用 KERI 的应用程序可以通过哈希表（映射）找到哈希，其索引是哈希，表中的值是特定事件中哈希的位置。
更详细地说，数据的提供者理解目的和语义，并可以在必要时披露它们，但是验证权威控制的行为不依赖于数据语义，仅依赖于在事件中包含印章。在应用程序中使用语义时，由数据的提供者来声明或公开语义。该声明由使用KERI的某些外部API提供。通过这种方式，KERI为满足最小充足的跨层准则的应用程序提供了支持。印章只是提供了相关(锚定)数据的真实性的证据，无论这些数据是什么。
这种方法遵循上下文无关可扩展性的设计原则。因为印章是上下文无关的，所以上下文是 KERI 外部的。因此上下文可扩展性是外部的，因此独立于 KERI。上下文无关的可扩展性意味着 KERI 本身不是锚定数据上下文之间协调的轨迹。这最大限度地提高了去中心化性和可移植性。可移植性是在KERI之上的应用层提供的，通过引用KERI印章的特定于上下文的外部API来建立控制权限，从而确保锚定(摘要)数据的真实性。每个 API 提供上下文。这意味着 KERI 内的互操作性仅集中在控制建立的互操作性上。这种方法进一步反映了 KERI 设计美学的最小充分手段。
交互事件
交互事件是一种非建立事件，它与建立事件子序列中的事件交织在一起。
交互事件以一个或多个印章的形式包含事件特定的交互数据有效载荷。每个印章都充当了一个锚，为相关数据提供真实性证据和控制权限证明。有效载荷数组中的每个条目可以是单个交互的数据的哈希（基本印章），也可以是来自交互块数据的稀疏哈希树的 Merkle 根（根印章）。因此，所有交互数据都锚定到事件序列的交互事件中 [104]。使用 KERI 的应用程序可以通过哈希表在交互事件中找到哈希，其中表的索引是哈希，表中的值是哈希在特定事件的位置（在印章数组中的条目的偏移量，在相关哈希树中将路径应用于其叶子的位置）。基本交互事件消息如下所示：
合作委托
委托由一对事件提供。一个事件是delegating事件，另一个事件是delegated事件。最终任务需要在delegator和delegate之间进行合作。我们称这种任务为合作委托。在合作委托中，delegating标识符在delegated标识符上执行建立操作（初始或轮换）。delegating事件是一种事件，它在其数据有效负载中包含delegated事件的事件印章。delegated事件的印章就是delegated事件的哈希。
同样，delegated事件有一个delegating事件位置印章，其中包括delegating事件的唯一位置。
一般来说，我们将delegating事件印章与delegated事件印章都叫做delegation印章。delegation印章要么是事件印章，要么是事件位置印章。delegating事件印章则是一个事件位置印章，delegated事件印章是一个事件印章。
由于delegating事件的有效载荷是一个列表，所以单个delegating事件可能执行多个委托操作。
委托操作直接委托一个建立事件。因此，委托操作既可以委托一个初始操作，也可以委托一个轮换，这两种操作分别可以为delegated的自认证标识符前缀创建和轮换授权密钥。
delegated标识符前缀可以自寻址自认证（参见第 2.3.4 节）。这将delegated标识符与delegating标识符绑定。delegating标识符控制器在delegated标识符上保留建立控制权威，因为新的delegated标识符只能自己授权非建立事件。委托将可撤销的签名权限授权给其他自认证标识符。delegated标识符可以有自己的密钥事件序列，其中初始事件是delegated初始事件，轮换事件都是delegated轮换事件。因此，delegated标识符的控制权威需要对给定的delegated建立事件进行验证，而该事件又需要验证delegating标识符的建立事件子序列。
由于delegating事件的数据有效负载中的委托印章包括完整delegated事件的摘要，因此它为delegated标识符以及其关联事件中的任何权限或其他配置数据提供了前向加密承诺。delegated事件中包含的委托印章提供了对delegating事件唯一位置的向后引用。这唯一地确定了delegating事件日志中的哪个事件持有相应的印章（因为有ilk）。这提供了一种交叉引用类型，使验证者能够查找delegating事件并验证该delegating事件中的委托印章列表中是否存在该委托印章，然后验证事件印章摘要是否是delegated事件的摘要。
委托交互事件
委托交互事件是一种交互事件，它在其数据有效载荷中包含委托操作的印章，即包含delegated事件摘要的委托事件印章。同样，delegated事件具有委托事件印章，其中包含delegating事件位置的摘要。委托交互事件（delegating的事件序列中的）数据如下所示：
委托操作直接委托建立事件（delegated的事件序列中的），无论是初始还是轮换。如上所述，delegated建立事件包括一个委托事件印章。如下图所示：
下图显示了一系列委托操作，通过由delegator C 的delegating交互事件对，为delegate D创建delegated建立事件。
委托操作还可以授权delegated标识符进行自己的委托。
扩展轮换事件
扩展轮换事件是一种轮换事件，也包括作为印章数组的数据有效载荷。这使得轮换操作既能够为其标识符上的任何其他非建立操作提供真实性，也可以为delegated标识符上的授权建立操作提供真实性。这种方法为交互印章提供了增强的安全性，因为交互签名密钥就不会被重复使用。
为了澄清起见，扩展轮换事件的的交互数据有效载荷是一个印章数组。每个印章都充当了一个锚，为相关数据提供真实性证据和控制权限证明。数组中的每个条目可以是单个交互的数据的哈希，也可以是来自交互块的数据的稀疏哈希树的 Merkle 根。因此，所有相关的交互数据都锚定到轮换事件位置的事件序列 [104]。使用 KERI 的应用程序可以通过哈希表（映射）在扩展轮换事件中找到哈希，其中表的索引（哈希键）是哈希，表中的值是哈希在特定事件的位置（在印章数组中的条目的偏移量以及在相关哈希树中将路径应用于其叶子的位置）。
委托轮换事件
委托轮换事件是一种扩展轮换事件，在其数据有效负载中包含委托印章。通过将委托印章混合在轮换操作中，有效的委托签名密钥可以在轮换操作中第一次使用，从而更好地避免暴露。
下图显示了一系列委托操作，通过由delegator C 的delegating轮换事件对，为delegate D创建delegated建立事件。
为了方便起见，使用委托轮换而不是委托交互来提供更多的安全。
为委托使用轮换的一个原因是增强安全性。轮换事件是第一次使用预轮换密钥对事件签名。即使delegator 的密钥丢了，我也没有丧失对delegate的控制权。
多签名密钥对标签
上述示例假设当前在任何时间点对标识符的控制权威基于单个密钥对。增加标识符安全的一种方法是同时使用多个密钥对共同控制标识符的多签名方案。这需要多个控制器作为签名者授权或批准密钥事件。多个签名可能会使攻击变得更加困难。阈值多重签名可以降低丢失一个或多个私钥的风险，从而使密钥恢复更加健壮。然而，多重签名轮换可能更复杂。
回想一下，密钥对$\left(C^j, c^j\right)$表示由 C 控制的密钥对序列中的第 j 个密钥对。此外，让密钥事件序列的轮换事件子序列的每个成员（包括初始）用整个数字索引 l 表示。密钥事件序列可以由 k 索引。当密钥事件序列中只出现轮换操作时，轮换操作的序列等于密钥事件序列，$l = k$。每个轮换操作可能会改变标识符的控制密钥对集。当新的控制密钥对集是奇异（singular，如何理解？意思就是密钥对集中的密钥对数量是1）的时，每个轮换都会从密钥对序列中消耗一个新的密钥对。在这种情况下，密钥对序列和轮换子序列的索引将具有相同的值，即$ j = l$。因此，我们可以等效地使用 l 作为上标来表示由 C 控制的密钥对序列中的第 l 个密钥对$\left(C^l, c^l\right)$。
然而，当控制密钥对不是单数时（即多签名），那么每个轮换操作可能会从控制密钥对的序列消耗多个密钥对。在这种情况下，索引 j 和 l 可能并不总是相等的，即 $j \neq l$。设第 l 个轮换控制密钥对的消耗数量为 $L_l$。第 l 个轮换消耗的密钥序列可以表示如下：
其中 $r_l$ 是子序列中第一个密钥对的索引 j 的值。因此有：
原始密钥对的集合由创建标识符 C 的初始操作声明。初始操作可以被认为是轮换的一种特殊情况，即第0轮换操作，即$l = 0$。此外，有 $r_0 = 0$。那么有：
其中 $r_0 = 0$。
第 l 个轮换的公钥子序列可以表示如下：
例如，假设初始操作使用一个密钥对，即 $L_0 = 1$，以下三个轮换分别使用三个、三个和四个密钥对，即 $L_1 = 3$、$L_2 = 3$ 和 $L_3 = 4$。每个轮换子序列的密钥起始索引如下：
$\begin{aligned} & r^0=0 \ & r^1=\sum{i=0}^0 L_i=L_0=1 \ & r^2=\sum{i=0}^1 Li=L_0+L_1=4 \ & r^3=\sum{i=0}^2 Li=L_0+L_1+L_2=7 \ & r^4=\sum{i=0}^3 L_i=L_0+L_1+L_2+L_3=11\end{aligned}$
此外，每个轮换的公钥的结果子序列如下：
$\begin{aligned} & {\left[C^{r_0}\right]_0=\left[C^0\right]} \ & {\left[C^{r_1}, C^{r_1+1}, C^{r_1+2}\right]_1=\left[C^1, C^2, C^3\right]} \ & {\left[C^{r_2}, C^{r_2+1}, C^{r_2+3}\right]_2=\left[C^4, C^5, C^6\right]} \ & {\left[C^{r_3}, C^{r_3+1}, C^{r_3+2}, C^{r_3+4}\right]_3=\left[C^7, C^8, C^9, C^{10}\right]}\end{aligned}$
因此，使用上面介绍的命名法，我们可以更有效地描述协议中多重签名方案的使用。
Verifier
Verifier是一个实体或组件，可以验证事件消息上的签名。为了验证签名，Verifier必须首先确定在发出事件时，哪一组密钥是或曾经是标识符的控制集。对于自始至终声明为不可转移的标识符，此控制建立只需要标识符的初始事件副本。对于在开始处声明可转移的标识符，此控制建立需要完整复制标识符的密钥操作事件序列（初始和所有轮换），直到发出该声明的时间。
Validator
Validator是一个实体或组件，它确定与标识符相关的给定签名声明在其发布时是有效的。验证首先要求该声明是可验证的，即在其发布时具有来自当前控制密钥对的可验证签名。因此，Validator必须首先充当Verifier来建立密钥的根权威集。一旦验证，Validator可能会将其他标准或约束应用于声明，以确定其对给定用例的有效性。这种特定于用例的验证逻辑可能与交互事件声明相关联。
事件位置和版本
事件在其密钥事件序列中的位置由其先前的事件摘要序列号和 ilk 确定。为了澄清起见，事件版本包括事件类别（建立或非建立）。事件类型很重要的情况是同一位置的建立事件（例如轮换）可能会取代非建立事件事件（例如交互）。一般来说，见证策略是：事件的第一个被看到的版本总是获胜，也就是说，第一个被验证的版本被见证(签名、存储、确认，可能还会传播)，而所有其他版本都被丢弃。但也有例外，例如建立事件可以在一组被利用的非建立事件之后恢复。恢复过程可能会从恢复的主干中分叉一个分支。这个有争议的分支有被利用事件，而主干有恢复的事件。操作模式(参见第10节)和可问责性的双重阈值决定了争议分支中的哪些事件对控制器负责(参见第11.6节)。
证人
见证人是由标识符控制器指定的实体或组件。见证人的主要作用是验证、签名并保留与标识符相关的事件。见证人是它自身标识符的控制器。作为一种特殊的情况，控制器可以作为自己的见证人。见证人指定的操作包含在密钥（建立）事件中。因此，可以使用标识符的轮换历史来验证见证人的作用。当指定时，见证人成为支持基础设施的一部分，建立和维护此标识符的控制权限。因此，见证人是其信任基础的一部分，可以由其控制器控制。证人池的目的是保护控制器免受外部对其标识符的利用。见证人可以使用自己的标识符的控制密钥对来为它收到的事件消息创建数字签名，与某标识符相关联，且此标识符不一定在其控制下。为了阐明，见证人控制自己的标识符，并作为某些标识符的事件消息的见证。见证人可能会收到、验证和存储标识符上的事件。验证意味着在事件发布时使用事件的当前控制密钥对验证附加到事件的签名。因此，证人首先充当事件Verifier，它根据迄今为止为该标识符接收到的密钥(建立)事件序列确定事件标识符的当前控制权限。之后，对于如何处理可能接收到的事件的不同版本，简而言之，它总是优先考虑它接收到的事件的第一个版本（首先看到）。该见证人通过仅签署并保持其收到的事件的第一个成功验证版本来表示这一点。见证人永远不会在事件序列中标记同一事件的任何其他冲突版本上签名。
收据
收据是由消息传递的一种特殊类型的事件，该消息包含另一条事件消息上的一个或多个签名。收据还包括其他事件消息的副本或对该消息的引用。每个签名都可以由证人创建。事实上，证人的主要目的是为证人收到的事件的第一个经过验证的版本生成、存储和传播事件收据。Validator和Watcher也可以创建收据，分别表示为Validator收据或Watcher收据。
一个简单的见证收据消息传达了有关收据的信息。它可以包括唯一标识已收到事件的信息，例如事件本身或对事件的引用，该引用由所接收事件的标识符前缀、序列号和事件内容的散列以及所接收事件的一组一个或多个标签的见证签名组成。证人标签可以是证人的标识符。
收据中的签名将收据与事件的内容绑定。同样，收据的接收者可能知道发送证人的身份，从而知道其标识符前缀，从而知道其控制密钥对。尽管如此，除了签名之外，在收据中包含见证人前缀，可以使关联更容易。通常，密钥事件收据者已经具有相关密钥事件消息的副本。因此，可能不需要在收到消息中重新传输原始密钥事件的副本，而只需发送序列号和用于查找和确认的哈希。为了紧凑性，可以更方便地附加来自多个证人的前缀和签名。收据附有证人前缀和签名的示意图如下所示：
对于标识符前缀 C 的见证，其标识符前缀$W_0^C$绑定到$\left(W_0^C, w_0^C\right)$，其密钥事件收据消息可以表示为：
其中$\varepsilonk^C$是序列号为k的关联密钥事件的副本，$W_0^C$是证人标识符，$\sigma{W_0^c}^c$是见证人关联的密钥事件的签名。收到两个见证签名时，可以表示如下：
收据本身不需要由见证人签名，因为消息传递的唯一重要信息是证人的签名，这表明证人“见证”了相关的密钥事件。为了验证证人签名，收据的接收者需要拥有原始密钥事件消息的副本，并知道证人的公钥。接收消息中的事件标签和证人标识符可以方便地查找该信息。
一般来说，见证人可能对它见证的每个 KERL（密钥事件收据日志）使用唯一标识符。如果证人标识符的密钥被破坏，那么如果证人标识符是可迁移的，那么证人做轮换操作即可。如果证人标识符不能转移，那么它必须停止使用受损标识符。在后一种方法中，证人可以恢复作为证人的身份，但使用新的标识符。只要保留了原始收据的副本，就可以发现来自同一证人的不一致的收据。尽管这两种方法都可以工作，但后一种方法避免了KERL项的递归轮换验证(其中验证控制器的证人的KERL项，然后验证证人的证人的KERL项，以此类推)。递归验证使实现变得复杂。因此，在不损失通用性的情况下，在此工作中，证人只能使用不可转移(不可轮换)的标识符密钥。当密钥泄露时，它们必须创建一个新的标识符。
密钥事件日志（KEL）
密钥事件日志 (KEL) 是标识符控制器创建的密钥事件消息的有序链记录。它是一个仅附加日志。密钥事件是链接的，因为除了初始事件之外，每个事件消息都包含前一个事件消息的加密强度内容摘要。它必须包括所有密钥事件消息，包括建立事件和非建立事件。KEL可以是标识符的信任基础的一部分，并且可以充当次要信任根。
密钥事件收据日志
密钥事件收据日志 (KERL) 是一个 KEL，并且它还包括所有由相关见证人集创建的一致密钥事件收据消息。证人为他们创建收据的每个标识符保留一个单独的 KERL。每个见证人对标识符的 KERL 都是第一个可见验证一致事件的仅追加事件日志。见证人只会保留这些一致事件的事件和收据。见证人可以缓存无序事件或未完全签名的事件，直到它们被验证为一致或不一致为止。因为正确的事件消息包括控制器的签名，所以它可以被认为是一种特殊的自签名收据。因此，KEL 可以被认为是 KERL 的一种特殊类型。KERL 可能是标识符的信任基础的一部分，可能充当次要信任根。
观察者（watcher）
观察者是一个实体或组件，它为标识符保留 KERL 的副本，但控制器未将其指定为其见证人之一。为了澄清起见，观察者没有在相关标识符的密钥事件中指定。观察者是它自己的标识符的控制器。观察者可能是validator信任基础的一部分，也可能由validator的控制实体控制(但不一定如此)。观察者可能会签署 KERL 或 KERL 部分的副本，但由于观察者不是指定见证人，因此这些都不是证人收据。它们可以被认为是观察者收据。
陪审员（Juror）
陪审员是对事件和事件收据执行双工性检测的实体或组件。陪审员是其自身标识符的控制器，它可能与其本身标识符不同。陪审员会在检测到的关于重复性的声明上创建数字签名。陪审员通过保留其看到的任何事件的任何相互不一致的版本的副本来检测重复。然后，它可以提供一个事件的一组相互不一致的版本作为双工的证明。陪审员使用控制器、观察者或见证中的 KERL (KEL) 作为比较的参考，以确定是否存在双工。双工有两种形式。在前一种形式中，每当控制器产生与先前产生的另一个事件消息不一致的事件消息时，控制器就可以被认为是双工的。在第二种形式中，当一个见证人产生与先前产生的另一个事件收据不一致的事件收据时，它可能会被认为双工的。这样一来，双工就成了人们对控制器或其证人不信任的基础。总而言之，陪审员的主要作用是向validator提供控制器和/或其见证的双工性检测，以便validator可以免受控制器和/或其证人的利用。因此，在给定与 KERL 引用的不一致声明的情况下，任何validator在任何时候都可以验证双工性。陪审员可能是validator的信任基础的一部分，可能位于该validator的控制（但不一定如此）下。
重复事件日志（DEL）
重复事件日志 (DEL) 是给定控制器或证人根据给定KERL产生的不一致事件消息的记录。重复事件被索引到 KERL 中相应的事件。每个陪审员为每个控制器和所有指定的证人保存一个关于KERL的双重事件日志(DEL)。任何validator都可以通过检查 DEL 来确认重复。
法官（Judge）
法官是一个实体或组件，它检查给定标识符一个或多个 KERL 和 DEL 的条目，以验证事件历史来自非双工控制器，并且已被足够数量的非双工证人见证，从而可以被validator信任或不被信任。从这个意义上说，法官是控制器及其证人池的validator。因此，法官可以在关于 KERL 和 DEL 中被验证的声明上创建数字签名。法官可以从一个或多个见证人或观察者那里获得 KERL，并且可以从一个或多个陪审员那里获得 DEL。法官可能是validator的信任基础的一部分，也可能处于validator的控制之下。法官可以是与第一方控制器进行交易的第二方（法官可以由validator担任），也可以是包括控制器和其他validator在内的多方交易中的可信第三方。一个特定的实体可以扮演多重角色。validator可以通过充当观察者、陪审员和法官。（十分重要！！）
解析器（Resolver）
解析器是提供标识符发现的实体或组件。解析器是它自己标识符的控制器，它可能与它作为解析器的标识符不同（所有实体都有这个特点）。解析器主要将标识符映射到标识符信任基础组件的 URL 或 IP 地址。这些组件包括控制器、观察者、陪审员和法官。给定组件的 URL 或 IP 地址，用户可以从获取关联的事件历史（KEL、KERL 和 DEL），以便用户可以为标识符建立当前（根）控制权威。解析器可以缓存这些事件历史或密钥事件子序列，作为根控制权限的最终可验证证明。
KERI 解析器的合适架构可能基于分布式哈希表 (DHT) 算法，例如 Kademlia [50; 101]。可用于 KERI 发现的通用 DHT 系统的示例是 IPFS[80]（IPFS可用于解析器）。DHT 提供了两种类型的发现。第一种类型是发现承载 DHT 本身部分的节点。第二种类型是发现 DHT 的目标数据。关于 KERI中两种操作类标识符，即可转移标识符前缀和不可转移标识符前缀，发现的目标数据是不同的。在不可转移标识符前缀的情况下，例如见证或观察者的前缀（证人与观察者的标识符是不可转移的），目标数据可能包括从不可转移标识符前缀到服务端点 URL 的映射，或者直接到见证或观察者密钥事件收据日志 (KERL) 服务的 IP 地址。在这种情况下，validator可以查询生成的 IP 地址，以获得完整的证人或观察者存储的KERL副本。对于可转移标识符（控制器？），发现可以提供标识符前缀映射到其完整密钥事件日志 (KEL) 。从这个副本中，可以提取当前见证集的标识符前缀，然后访问这些见证人的 KERL。
时间戳
在消息或日志条目中包含时间戳可能很方便。一个众所周知的日期时间格式是 ISO-8601 标准 [85; 86]。具有微秒分辨率的 ISO-8601 时间区域感知 UTC 时间戳具有以下形式：
1 | YYYY-MM-DDTHH:MM:SS.mmmmmm+00:00 |
一个例子：
1 | 2000-01-01T00:00:00.000000+00:00 (7.27) |
安全考虑
此协议中的每个操作都通过加密可验证的事件表示。因此，成功的利用必须攻击和破坏事件的可用性和/或一致性。因此，安全性分析侧重于描述这些攻击的性质和时间，以及协议在受到攻击时如何保持事件的可用性和一致性。因此，我们根据这些特征描述了潜在的攻击。
第一个特征是live攻击与dead攻击。live攻击涉及对当前或最近事件的攻击。防止live攻击是当前维护运行安全的关键。防止live攻击的保护侧重于提供当前事件的充分可用性以及确保其一致性(非重复性)。相比之下，dead攻击涉及对过去事件的攻击。防止dead攻击主要由双工性检测提供。KEL (KERL) 的一个可验证副本足以检测任何其他可验证但不一致副本中的双工。通过冗余副本，可以相对容易减轻对过去事件可用性（dead攻击）的攻击。由于计算和加密技术(量子或其他)随着时间的推移而进步，数字签名可能会变得不那么安全，因此必须降低对已泄露签名密钥进行恶意利用的可能性。
第二个特征是对直接与间接操作模式的攻击。该协议可能以两种基本模式运行，称为直接和间接模式。两种模式的可用性和一致性攻击面是不同的。
第三个特征是恶意第三方与恶意控制器利用。前者攻击来自外部恶意攻击者，但控制器是诚实的。在后者中，控制器也可能是恶意的，在某种程度上可能与成功的恶意第三方无法区分。我们发现将这两种攻击分开考虑，对设计和分析防护都是有帮助的。
协议的主要参与者是控制器和validator。其他参与者，例如见证人、观察者、陪审员、法官和解析器，为两个主要参与者中的一个或两个提供支持，并可能受其控制。
对攻击的防护分析可以进一步分解为针对攻击的每种保护机制的三个属性，它们是：对攻击的敏感性、对攻击危害的脆弱性、对有害攻击的可恢复性。安全设计涉及在保护机制的这三个属性之间进行权衡。成功的攻击可能会在以下两种情况中任一种或两种情况下造成危害：
- 控制器的某些或全部控制权限都已损失，因此恶意实体可能会产生与控制器的愿望相反的一致可验证事件和/或阻碍控制器释放新密钥事件的能力。
- validator接受由恶意实体（控制器和/或第三方）产生的不一致可验证事件，因此validator可能会受到伤害。
保护包括预防或减轻两种伤害情况。控制器的主要保护机制包括：（1）维护根控制权威的最佳实践密钥管理技术；（2）通过支持组件对事件进行冗余确认以及对指定支持组件的行为进行双工性检测。验证器的主要保护机制是：对支持组件的行为双工性检测。我们将在下面根据攻击特征详细描述协议保护机制的属性。
预轮换
介绍
如前所述，密钥轮换的主要目的是防止或恢复攻击者对一个或多个私钥的成功利用。主要的密钥泄露攻击（dead攻击或live攻击），都是在私钥用于在某些计算设备上签署事件时，或者在私钥从某些安全存储设备传输到计算设备时捕获它。另一种dead攻击可能会在密钥对创建很久之后发起，这种攻击可以使用先进的计算技术，如量子计算，来反转用于导出公钥的单向函数（这种应该不考虑）。
给定一个可能暴露的私钥，必须使用不同的私钥授权安全轮换操作，否则攻击者可能会使用泄露的密钥来轮换到其控制下的密钥对，从而有效地允许其获取对标识符的控制权。一种常见的缓解是为轮换操作指定一个特殊的密钥对。这仍然存在一个漏洞，即随着时间的推移，轮换密钥对最终也会暴露，从而有被泄露的风险。然后，轮换密钥本身可能需要由另一个特殊的轮换密钥来轮换，依此类推。这种方法产生了复杂的多层密钥管理基础设施。
相比之下，这里介绍的方法称为预轮换，要简单得多[136]。如上所述，控制器的主要保护机制之一是维护根控制权限的最佳实践密钥管理机制。这种新颖的适应性预轮换方案是这些最佳实践之一。
预轮换方案提供了安全的可验证轮换，当一组密钥对在其创建和首次用于发布自认证标识符之后的某个时间被成功利用时，可以减少对给定签名私钥集的成功利用。换句话说，它假定私钥在第一次使用之前保持私有。更详细地说，该协议不解决一组私钥在面对侧信道或其他攻击时的加密安全性问题，这些攻击可能在密钥对创建后的时间段内捕获私钥，但时间点在相关标识符发布之前。相反，可以使用众所周知的密钥管理和签名基础设施最佳实践（此处未涵盖），以防止或减轻在创建密钥对或发布标识符之前捕获私钥的攻击（使用可信硬件？）。该协议通常还假定不存在暴力破解或其他可能破坏私钥的攻击，只要知道公钥和/或签名语句，直到控制器可以预防性地轮换到更强的签名方案为止。它还假设所有加密操作(包括签名方案)的加密强度不小于128位。该协议旨在通过可验证的声明解决从一组密钥对到另一组密钥对的安全传输问题，而不是所有保持私钥私有的问题。
如前所述，该协议减轻密钥泄露的主要风险是在使用私钥签署声明后才出现的。预轮换保护机制可以通过一组未公开的轮换密钥(即预轮换)从泄露的暴露签名密钥中恢复，新的密钥先前在加密承诺中指定。预轮换承诺也为预轮换提供了一定程度的后量子安全性。
后量子安全
后量子密码学表示：尽管受到量子计算机的攻击，但仍保持其加密强度[109;150]。因为目前实用的量子计算机尚不存在，所以后量子技术是对未来某个时间它们确实存在的展望。在实际量子计算机突然可用的情况下，后量子安全的单向函数不会降低安全性(抗反转)。一类后量子安全单向函数是哈希。D.J.Bernstein关对加密单向哈希函数的抗碰撞性的分析得出结论，量子计算与非量子技术在哈希函数破解上没有优势[25]。因此，提供某种程度的后量子安全的一种方法是将密码材料隐藏在此类散列函数创建的该材料摘要后面[141]。这直接适用于在预轮换中声明的公钥。它不是预先轮换对公钥进行加密预承诺，而是对该公钥的摘要进行预承诺。一旦在后来的轮换操作中公开公钥（不隐藏），摘要就可以得到验证。由于摘要是单向哈希函数的输出，因此摘要唯一地绑定到公钥。当预轮换的未暴露的公钥隐藏在摘要中时，关联的私钥也将受到保护，免受对这些公钥的后量子暴力反转攻击。
具体来说，使用量子计算实际上可以反转单向公钥生成(ECC标量乘法)函数的后量子攻击必须首先使用非量子计算（为什么反转摘要需要用非量子计算？）反转公钥的摘要。因此，量子前的加密强度不会在量子后被削弱。强单向散列函数，例如 256 位（32 字节）Blake2、Blake3 和 SHA3，具有128位的量子前强度，在量子后也保持该强度。此外，隐藏预轮换公钥不会对控制器施加任何额外的存储负担，因为控制器必须始终能够重现或恢复相关的私钥，以便为相关的轮换操作签名。然而，当预轮换隐藏其公钥时，后续轮换事件消息的长度增加，因为它必须提供实际的未隐藏的公钥。然而，先前轮换事件的长度会降低，因为它必须只提供公钥集的单个摘要。隐藏的公钥可以紧凑地表示为Base64编码的隐藏合格公钥，其中哈希函数在派生代码中表示。
基本预轮换
以下图表有助于说明预轮换是如何工作的。为了简单易懂，在本说明中，事件配置被简化为仅包含最相关的细节。同样，所有密钥集都被简化为只有一个密钥。
每个初始操作涉及两组密钥，每组密钥都在事件中发挥作用。这两个角色被标记为初始与下一个。初始操作创建了两组密钥对。第一组由绑定到标识符前缀的初始（原始）密钥对组成，作为当前根控制权限。第二组由预轮换密钥对组成。初始事件本身包括来自初始密钥对集的公钥，加密从下一组密钥对中公钥的摘要。一个简化的初始事件，每个集合都有一个密钥，一个隐藏的下一个密钥作为摘要，如下所示：
在初始事件发出后，初始密钥对成为标识符的当前权威签名密钥对。此外，为了验证权威性，初始事件必须由初始私钥签名。给定包含的初始公钥，可以根据附加的签名验证初始事件。初始事件提供了最初派生标识符前缀的信息（包括初始公钥）。
包含事件中的下一组公钥有效地对该集合执行预轮换操作，集合本身可以称为预轮换集或简称预轮换。初始化预轮换的自认证标识符时，初始事件的一个重要功能是声明、指定并执行下一个密钥集的预轮换。除了确认私钥的控制器授权了初始事件外，验证签名也证明了对标识符前缀的控制。此外，初始事件还对指定的预轮换下一个公钥集做出了可验证的承诺。
每个轮换操作涉及两组公钥，每个公钥都在事件中发挥作用。这两个角色被标记为当前（current）与下一个（next）。当前集是在最近的上一个轮换或初始中创建和声明的。一个新的下一个集合由轮转创建和声明。这些关密钥集可以描述如下：
现在当前的签名密钥集。
新的下一个签名密钥集。
若要具有权威性，轮换操作必须由当前的权威密钥集签名。因此，只有当前密钥暴露，下一个密钥集仍未暴露。每个轮换操作对其一组下一个预轮换密钥对做出有签名的承诺。
本质上，每个密钥集都遵循一个轮换生命周期，它随着每个轮换事件改变其角色。一个密钥集首先作为下一个（next）密钥集，然后在下一次轮换上变为当前（current）集，之后在下下次轮换中被丢弃。
由于前一组下一个(后续的)预轮换密钥隐藏在摘要后面，因此后续轮换必须包含关联的非隐藏公钥。轮换事件还将其下一个(随后的)轮换公钥隐藏在合格摘要后面。如下图所示：
为了帮助理解，下面一个示例。
安全性
对于许多漏洞利用来说，成功的可能性是持续监控或探测的函数。通过在时间、地点和方法上限制漏洞利用的暴露机会，特别是在时间和地点只发生一次的情况下，从而使漏洞利用变得极其困难。攻击者必须预测该暴露的时间和位置，或者必须对所有暴露进行持续的通用监测。通过声明初始事件中的第一个预轮换，其利用的窗口变得很窄。同样，每个后续轮换事件都是对前一个(预轮转)轮转密钥进行一次时间和地点的签名暴露。
因为每个预轮换都对一组一次性首次轮换密钥做出加密的未来承诺，后来利用当前的权威签名密钥可能无法捕获密钥轮换权限，因为它已经通过预承诺转移到新的未暴露的密钥集。为了详细说明，初始事件中的下一个预轮换密钥对在下一个轮换操作中充当一次性的首次轮转键。此后，这些密钥对可能被激活为新的当前(根)权威签名密钥，但不再具有轮换权限。同样，每个轮换事件也是如此。
在身份管理系统中，密钥、控制器和标识符之间的绑定可以由管理命令建立。因此，可以使用管理命令来充当受损管理密钥的恢复机制。这可能允许通过多次使用每个密钥进行更多的暴露，从而增加被利用的风险。相比之下，当密钥、控制器和标识符之间的绑定纯粹是密码的（分散的）时，例如该协议的情况，一旦完全捕获了根控制权威的密钥，就没有恢复机制。因此，这些密钥的安全性更为关键。因此，在此协议中，管理(建立操作)密钥是一次性的且第一次，作为管理密钥使用。
根据定义，dead攻击发生在给定轮转事件的创建和传播之后。成功的dead攻击必须首先破坏一些过去轮换事件的当前签名密钥集，然后创建该过去轮换事件的替代可验证版本，然后在原始事件有时间传播到该validator或validator可以访问的任何其他组件之前，将该替代事件传播到给定的validator。对下一组密钥的预承诺意味着不可能实现其他成功的dead攻击利用。后续的轮换事件如果没有使用先前轮换中预承诺的下一个密钥签名，将无法验证。有时，攻击成功地破坏一组密钥，从而创建一个替代但可验证的事件，只要事件的原始版本有时间传播到validator或其他组件（例如见证、观察者、陪审员、法官），validator或其他组件仍然可以受到保护。为了成功检测双工性，并受到保护，任何validator只需要将事件的任何后续副本与传播到它可能访问的任何组件的原始事件的任何副本进行比较。因此，攻击者必须赶在过去的轮转事件传播之前进行攻击。事件的原始版本是第一次公开的密钥的版本。因此，攻击者必须在很短的时间内提前传播。换句话说，为了使dead攻击成功，它必须完全避免被发现是双工的。为此，它必须防止validator访问密钥事件历史的任何原始副本，或者等效地必须首先破坏validator可访问的原始密钥事件历史的所有现存副本。这可能非常困难。此外，控制器只需要接收validator对其上次轮转事件的接收确认，以确保该validator免受未来的恶意利用。
总而言之，轮换事件的替代但可验证版本将与存储在原始密钥事件历史的任何副本（KEL/KERL）中的事件的原始版本明显不一致。因此，任何可以访问原始密钥事件历史的validator（或其他组件或实体）都不会受到损害。
为了进一步保护初始事件的初始密钥不被dead攻击，控制器可以同时创建初始事件和紧接着的轮转事件，然后将它们作为一个事件一起发出。（如何理解？？）这会最大限度地减少这些初始密钥对的暴露。
在图9.5中，事件密钥元素标有其密钥对序列的索引，例如，第2个密钥为$C^2$，其暴露为$\dot{C}^2$，若其私钥被攻击者知道，则为$\tilde{\tilde{C}}^2$。在dead攻击中，$C^2$在暴露一段时间后被攻击者知道私钥。暴露开始时间为$C^2$的出现时间，被攻击者知道私钥的时间是$\tilde{\tilde{C}}^2$的出现时间。攻击者可能会创建可验证的事件2的替代版本，并在攻击者的控制下使用新的下一个密钥$D^3$。但是原始事件 2 已经发出，因此validator可能已经可以访问原始事件 2 的副本，并将检测出替代事件 2 为双工事件，这可以防止dead攻击成功。为了成功，攻击者必须防止validator首先看到事件 2。攻击者必须首先看到事件 2，然后得到其私钥，然后创建事件 2 的替代版本。通过直接向validator或validator可能访问的其他组件(如witness)，控制器会阻止在以后的任何时间成功的dead攻击。
相比之下，live攻击被定义为在事件传播之前以某种方式危及来自最新轮转事件的未暴露的下一组密钥(预轮转)的攻击。这意味着攻击者必须在首次使用密钥对事件本身进行签名时或之前得到相应私钥。
此外，假设存在这样的攻击，双工性检测可能无法防止此攻击（live攻击）。这是因为live攻击能够在攻击者的控制下创建一个具有下一个密钥的新的可验证轮换事件，并在原始控制器创建的新轮换事件之前传播该事件。这种成功的live攻击可以有效地和不可逆地捕获标识符的控制。此外，在成功的live攻击下，来自原始控制器的新轮换事件对于已经接收到被利用的轮转事件的任何validator或其他组件来说都是双重的。防止live攻击的保护完全来自于第一次使用时或使用之前泄露一组密钥的难度。
为了详细说明，成功的live攻击必须破坏最新轮换中声明的公钥中未暴露的下一组私钥。假设私钥是保密的，那么在首次使用私钥签名轮换事件时，必须通过暴力破解反转或侧信道攻击来获得私钥。
鉴于密钥生成算法的加密强度，成功的暴力攻击可能实际上是不可能的。将未暴露的下一个(预轮转)公钥隐藏在摘要后面，不仅可以提供额外的保护，防止前量子暴力破解攻击，还可以防止意外的后量子暴力破解攻击。在这种情况下，暴力攻击首先必须反转用于创建摘要的抗后量子的单向散列函数，然后才能尝试反转单向公钥生成算法。此外，随着计算能力的提高，控制器只需要轮换到相应的强加密单向函数，包括后量子散列函数（哈希函数可以改变，我们的方案其实也可以，每一个密钥链不同）。
在图9.6中，第3个密钥以$C^3$表示，此密钥暴露（被使用）用$\dot{C}^3$表示，隐藏（变成摘要？）用$\underline{C}^3$表示。
live攻击要求密钥$\underline{C}^3$在事件3之前，其私钥就被攻击者知道。密钥暴露时间由$\dot{C}^3$的第一次出现表示，密钥被攻击者利用的时间由$\underline{\tilde{C}}^3$表示。攻击者可以创建可验证的事件3的替代版本，并在攻击者的控制下使用新的下一个隐藏密钥$\underline{D}^4$。尽管如此，鉴于$C^3$的私钥在暴露之前仍然是私有的，因此破坏$C^3$的唯一方法是使用其摘要反转$C^3$，并获得对应的私钥，这在实际中是不可能的。这可以防止live攻击成功。
总之，带有双重检测的预轮转可以保护validator免受dead攻击和live攻击的伤害。使用dead攻击，需要注意的是，为了使validator能够检测和丢弃任何后来伪造的备用轮换事件，它必须能够访问原始密钥事件历史记录的副本。但通过预轮换，任何可验证的备用轮转事件必须不可检测地替换validator可以从任何其他组件访问的每个副本中特定的预先存在的轮转事件（这个时候预轮换真的有用吗？）。这使得成功的dead攻击变得困难。即，成功的dead攻击不仅必须破坏给定的一组轮转密钥，而且还必须确保其版本是第一个传播到validator可以访问每个组件的版本。控制器只需要直接将任何新的轮换事件传播到validator或其他组件，例如见证，以保护validator免受任何dead攻击。另一方面，成功的live攻击必须在首次使用这些密钥时或之前破坏一组预轮转密钥。这使live攻击变得极其困难。
其他特征
除了增强安全性之外，预轮换方法还有一些其他有用的特征。在其最简单的形式中，预轮换不需要任何特殊的轮换密钥基础设施。这使得该方法自包含（如何理解？）。如前所述，密钥轮换管理的一种常见方法是具有特殊用途的轮换密钥对，其功能是授权签名密钥对上的轮换操作。这提出了一个问题，即在多次轮换后，管理轮换密钥变得暴露，可能容易受到利用。因此，可能需要另一个更高级别的管理轮换密钥来授权较低层管理轮换密钥的轮换，依此类推。相比之下，在最简单的形式中，预轮换只使用一层轮换密钥。而KERI的预轮换方案避免了连续更高层轮换密钥的无限回归。
这种方法背后的设计美学是最小充分的手段。密钥状态验证引擎可以使用这个单层架构作为组合原语。使用原语时，轮换密钥是一次性的第一次使用（轮换密钥在轮换这个功能上只使用一次），但随后可以选择性地将其重新用作签名密钥。然后可以通过将此原语组合成多层设计来支持更复杂的层次结构，而不是为每个架构构建一个定制的原语。以下部分将讨论如何使用核心原语组合具有不同功能的系统。为简单起见，以下小节中的示例使用事件的单签名版本。
重用的密钥模式
回想一下，通用交互事件的目的是实现控制器和validator之间的交互，而不是建立(密钥管理)事件，例如密钥轮转。这些交互事件使用当前签名密钥签名。通常，密钥轮换之间会出现许多交互事件。尽管这暴露了签名密钥，但预轮换的后续签名密钥不会暴露。
为了详细说明，密钥事件历史被描述为维护单个密钥对序列。每个密钥对在其生命周期中可能扮演两个不同的角色。密钥从生命周期开始，作为单个（第一次）用来签署建立（初始或轮换）操作的密钥。然后它可以选择性地继续其生命周期，作为被授权用于多种用途的重新使用的密钥，为任意数量的非建立(交互)操作签名。为了更好地理解这是如何工作的，请考虑由关联公钥序列表示的密钥对序列，如下所示：
例如 $C^0, C^1, C^2,…$。回想一下约定，当密钥对之前已经暴露出来时，即它的私钥过去已经被多次使用来创建签名，那么它的暴露（不是利用）可以用$\dot{C}^j$表示。进一步回忆一下，$C_I^j$、$C_R^j$与$C_X^j$分别表示初始、轮换和交互事件。使用此符号，简化的密钥事件历史可以图解如下：
初始事件为$C_R^0$，而$\dot{C}^0$表示其已经暴露。第一次轮换事件为$C_R^1$，之后$\dot{C}^1$表示其已经暴露。$C^2$还未暴露。关于上图的描述省略。
为了澄清，假设轮换事件后总共有 I 个连续的交互事件。每个交互事件都使用相同的签名密钥签名。假设在第 I 个交互事件之后，会发生新的轮换事件。在此轮换之后，必须丢弃以前用于签名交互事件的密钥，并且可以使用一个新的签名密钥(即新重新使用的轮换密钥)来签署另一组交互事件。该协议的一个主要目的是支持数据流应用程序，这些应用程序可能受益于性能更高的密钥支持基础设施，这些基础设施与流应用程序使用相同的计算基础设施（如何理解？轮换事件后面有正常的交互事件）。这种方法得到了预轮转模式的支持。管理密钥(轮换)和签名密钥只需要一个密钥支持基础结构。重新使用的预轮转密钥可以为许多数据流应用程序提供足够的安全性。这种方法为应用程序的便利性牺牲了安全性，在这些应用程序中，暴露交互事件的漏洞与重用签名密钥的便利性相比是可以接受的。
扩展轮换
然而，在一些关键的交互中，通过为多个交互事件重用签名密钥所产生的便利和安全性之间的权衡可能是不可接受的。在这种情况下，一种更安全的方法是通过向轮换事件添加有效载荷数据结构来将交互事件与轮换事件相结合。交互事件细节嵌入到轮换事件有效负载中。如前所述，这被称为扩展轮换事件。这不会改变轮换事件验证的语义，但只允许交互事件包含在轮换事件中。因此，签名键只使用一次，每次使用后轮换。因此，签名密钥就不会被重复使用。代价是为每个交互操作使用一组新的密钥。给定的应用程序可以将扩展轮换与非扩展轮换混合，以支持与某个密钥事件序列不同级别的安全交互工作流。对于更严格的安全性，应用程序可以在交互事件配置中声明，在密钥事件流中只允许建立事件。使用扩展轮换操作的简化密钥事件历史如下所示：
在一些密钥管理应用程序中，可能会首选轮换事件+交互事件的基础设施。这可能是由于性能或成本原因。这些应用程序可能包括由物联网 (IoT) 设备、微服务服务器或流数据处理工作流组成的支持基础设施。
委托模式
在管理身份系统的一些密钥管理架构中（传统方式），可以使用两种不同的密钥基础设施。一个用于签名管理操作的密钥，另一个用于签名交互(事务)的密钥。轮换或委托等管理操作可能更加安全，但发生的频率远低于交互事件。因此，尽管不太方便，但更安全的体系结构可能会在其基础设施中使用特殊的计算设备或组件来存储私钥和/或为管理操作创建签名。这些可能包括一个或多个安全enclave、硬件安全模块 (HSM)、可信平台模块 (TPM) 或某些类型的可信执行环境 (TEE)。
关键管理基础设施
当一个计算设备或组件同时支持管理和非管理的所有存储和签名操作时，我们将其称为一元体系结构或基础设施。当存储和签名操作在两个计算设备或组件之间分离时，我们将其称为二值体系结构或基础设施。当存储和签名在两个或多个关键计算设备或组件之间进行分割时，我们将其称为多价值体系结构或基础设施。不幸的是，二价或多密钥支持基础设施可能对上述重用的预轮换方法构成问题。对于每个轮换事件和交互事件，使用不同的密钥存储和签名设备，重用模式（轮换密钥接着用作交互密钥）将需要将轮换密钥从一个计算设备移动到另一个计算设备，以便重新利用为交互密钥。这既不方便又不安全。以下图表显示了密钥支持基础设施的不同价：
委托与多价
支持二价和多价的密钥支持架构由委托模式提供，可以描述为合作委托（cooperative delegation）（见 7.25）。委托涉及delegator和delegate的每个密钥事件日志中的一对事件。除了水平可扩展性（如何理解？）之外，合作委托的一个主要好处是任何仅损害delegate权威密钥的攻击者都不能捕获delegate的控制权限。delegate的任何利用都只能被delegator恢复。成功的攻击者还必须损害delegator的权威密钥。一组嵌套的委托级别可用于形成委托链或委托树。每个更高级别的负责所有较低级别密钥的恢复。这为密钥泄露恢复维护了根级别的安全性，一直到叶节点，尽管叶节点使用了不太安全的密钥管理方法。
通过委托模式，任何数量的delegated交互签名密钥序列都可以由一个delegating管理(建立)密钥序列来管理。更正式地说，一个控制器(delegate)从另一个控制器(delegator)接收对其标识符的控制权限。delegate的前缀是一种自寻址自认证前缀(参见2.3.4节)。这将delegate的前缀与其delegator的前缀绑定。设根控制器的标识符，delegator为 C。同样让delegated控制器的标识符，delegate为 D。delegating控制器有一个密钥对序列，它由关联的公钥表示，如下所示：
每个受控delegate也有一个密钥对序列，由相关的公钥表示，如下所示:
控制器 C 使用一个特殊的delegating密钥事件来委托交互签名权限标识符 D。委托为D创建了一个专用的不相交密钥事件序列和不相交的密钥序列（如何理解？）。delegator可以使用连续的委托操作来授权任意数量的delegate。因为两个密钥序列不相交，不仅绑定到不同的标识符，而且可能绑定到不同的控制器。
如前所述，委托可以通过委托交互操作或委托（扩展）轮换事件来执行。当体系结构是二价的时，即delegating密钥事件流驻留在专用安全计算基础设施(如安全enclave或TPM)中，然后使用delegating交互操作可以提供足够的安全性。在这种情况下，每个轮换密钥集都可以被重新用于执行delegating交互（如何理解？）。所有其他交互都是在不同计算平台上的delegated密钥事件流中执行的。delegating密钥事件仍然受到保护，不受重新利用的delegating交互事件密钥集的攻击，因为可从攻击中恢复下一个预先定义的密钥。
另一方面，使用delegating轮换操作可以为二价或单价架构提供增强的安全。在这种情况下，每个 delegating 操作只使用一组密钥一次。
一组delegated密钥（来自delegate密钥序列的子序列）可用于在delegate的事件序列中签名交互或其他非建立事件。通过这种方式，委托可能会授权其他一些标识符前缀及其相关的控制密钥对交互事件具有权威性。因此，除了仅仅启用二价密钥支持基础设施之外，应用程序还可以从其他优雅属性中受益，例如削弱控制权限的能力（如何理解？）。
Delegating 操作可以通过 deleating 交互或 deleating 轮换操作在 delegating事件流中执行。在后一种情况下，deleating 轮换操作是扩展轮换操作的一个特例。可以为该任务提供更好的保护，因为相关的密钥只暴露一次。
在任何一种情况下（deleating 交互或 deleating 轮换），事件有效载荷都包含delegated操作数据。delegated标识符的非建立操作只出现在delegated的事件序列中。在delegating事件流中，每个delegating事件都包含承诺，称为委托印章。委托印章包括delegated标识符的限定前缀和delegated事件的摘要。delegated事件印章为verifier在其事件流(历史、日志)中查找和验证delegated密钥事件提供了所需的信息，如下所示：
在delegated事件流中，delegated的建立事件也包括一个委托印章，该印章指向delegating事件的唯一位置。这种delegating事件位置印章包括delegating标识符的合格前缀、delegating事件在其事件序列中的序列号、事件的ilk 和先前事件的摘要。任何事件流中只有一个事件可能具有这四个值的给定唯一组合。印章为verifier提供了所需的信息，以便在密钥事件流（历史、日志）中查找delegating，如下所示：
然而，delegated交互事件不包括印章，因为它从事件流中最近的delegated建立事件继承其控制权限，如下图所示：
从支持事件流应用程序的角度来看，委托模式支持水平可扩展的密钥管理基础设施（如何理解水平可扩展？）。可将事件序列视为事件流。这样，主控制器密钥事件流可以将签名权限委托给一个或多个从标识符密钥事件流，从而形成密钥事件流的链式树。delegated密钥事件的verifier还必须从delegator事件流的密钥事件日志中查找和验证delegator的控制权限。使用印章，delegator和delegate的事件流被交叉链接在一起。delegated事件的摘要包含在delegator的事件中，将这两个流链接在一起。
来自同一delegator的多个delegate将形成一个树。下图显示了一个delegator(主)标识符及其相关的控制事件序列，以及几个delegate(从)标识符及其受控事件序列。
通过这种方式进行委托，在语义上创建了一个密钥层次结构。这提供了一个强大的新构建块，允许不同的组合。唯一需要的额外基础设施是支持委托初始和轮换事件的密钥事件状态验证引擎。这种方法的一个优点是：每个delegated密钥事件流都是一个专用的事件链，具有专用的序列号集和专用的摘要链，而不是交错的序列号和摘要链。这使得独立管理每个流变得更加容易。这也使得它更具可伸缩性，并且更容易适应每个delegated签名密钥事件流的不同密钥支持基础设施。
可以递归地应用委托以启用多级委托，从而创建密钥事件流的链式树。使用这种方法，可以通过组合委托事件来支持任意数量的层或级别的管理密钥。此外，除了初始化和轮换之外，委托还可用于管理其他类型的授权。
托管密钥管理
KERI的预轮换机制和委托使多价托管密钥管理成为可能。在这种方法中，委托的预轮换密钥由delegator持有或控制。delegate只控制当前签名密钥集。delegator可以在任何时候通过使用委托的预轮转密钥发布轮换来单方面撤销该签名能力。为了重新分配签名能力，delegator和新delegate执行两次连续的合作委托轮换。第一个轮换到由新delegate控制的预轮转密钥，第二个轮转到由delegator控制的预轮转密钥（如何理解？）。
因为在delegator在其事件日志中进行印章承诺之前，这两个轮换都是不可验证的，所以delegator可以等到两个轮换都制定好之后再提交第一个轮换。重要的一点是，在这种方法中，delegator与delegate永远不会共享私钥。每个人都维护自己的私钥集，它们只是对彼此关联的公钥做出连续的承诺。这保持了其密钥管理基础设施之间的分离。（在这里有一个问题？delegate的私钥由自己掌握，那么delegator如何撤销对delegate的授权？或者说，delegator如何主动控制delegate的密钥轮换？？）
总结
总之，KERI 设计方法是构建可组合的原语。因此，递归地应用时，该任务可用于组成任意复杂的分层（优雅）关键管理事件流树。这是一项非常强大的能力，可以为通用的通用分散密钥管理基础设施 (DKMI) 提供必不可少的构建块，这也与通用事件流应用程序的需求兼容。
协议操作模式
本节描述从控制器到validator的协议操作模式(传递密钥事件)。在许多情况下，我们可以合理地假设一个诚实的控制器。这意味着validator可以选择是否信任控制器。通常为了控制器的最大利益，控制器以一种值得信赖的方式对待自己的标识符，也就是它所控制的标识符，特别是那些持续高价值的标识符。此外，由于每个密钥事件必须由控制器不可否认地签名，任何validator最终都能检测到密钥事件的任何不一致的替代版本。这使得不一致的行为，即可检测的双工，对于控制器来说，即使成功检测的可能性很小，也是非常危险的。因为可检测的双工破坏了控制器对该标识符的可信度，以及它可能在该标识符中建立的任何价值。由于密钥轮转的主要目的是允许控制器保持对标识符的持久控制，因此可检测到的双工行为会消除对给定标识符的持久控制的任何好处。尽管如此，该协议仍然必须防止边缘情况，在这种情况下，双工为不诚实的控制器提供了一些暂时的好处。
在此协议中，当与其他控制器的标识符交互时，保护validator的所有主要活动(无论是验证、控制权限建立、双工性检测)都是基于重放该标识符的密钥事件序列(密钥事件历史或日志)的能力。提供这种重放功能有两种主要的操作模式，它们根据标识符控制器在创建和发布密钥事件时的可用性程度来区分。第一种是直接重放模式，另一种是间接重放模式。
通过直接模式，除非控制器连接到网络并能够直接与validator通信，否则将事件传播到validator不会发生。直接模式假设控制器可能具有间歇性的网络可用性。这并不排除使用网络缓冲区、缓存和其他缓解临时通信连接问题的机制，但它确实假设这些机制在发布密钥事件方面可能不受任何持久意义上的信任。尽管如此，直接模式很重要，因为它与使用手机等移动互联网设备兼容。间歇性可用性的假设意味着，为了让validator访问标识符(不是它自己的)的密钥事件历史，validator必须直接从标识符的控制器接收这些事件。直接模式与一对一交换或成对关系(每个关系一个标识符)的标识符兼容。使用间歇性进行直接通信的假设简化了保护标识符所需的可信支持基础设施集。下一节将提供直接模式的详细信息。
通过间接模式，即使控制器没有连接到到网络，也可以将事件传播到validator。间接模式支持密钥事件历史对任何validator的高(几乎连续的)可用性。这意味着当控制器不附加到网络时，必须信任其他组件来释放密钥事件。间接模式与一对多交换或任意关系的标识符兼容。单个间接模式标识符可用于公共服务或业务，或当在该标识符中建立品牌和声誉很重要时。间接模式标识符也可用于私有一对一或选择组，但不能容忍间歇可用性。高可用性的假设使安全标识符所需的可信支持基础设施集变得复杂。间接模式的详细信息将在下一节中提供。
直接模式
通过直接模式，一方是给定标识符的控制器，并希望使用该给定标识符与另一方validator交互。validator必须首先验证给定的标识符是在控制器的控制下。由于标识符（自我认证）通过相应的公钥绑定到一个或多个密钥对，因此控制器可以通过发送带有相应私钥签名的可验证初始操作事件消息来建立控制。从validator的角度来看，这个初始事件在发布标识符时建立了控制器的初始权限。该控制权限随后通过连续可验证的轮转操作事件来维护，该事件使用未公开的预旋转密钥签名。
控制器还建立了事件的顺序。由于只有控制器可能会产生可验证的密钥事件，因此仅控制器就足以建立事件的权威顺序，即它是事件的唯一真相来源。不需要其他关于排序的基本事实来源。控制器通过在除初始事件外的每个事件中包含对前一个事件内容的加密承诺(摘要)来建立事件序列。其次，每个事件还包括一个单调递增的序列号。计数器简化了用于管理和推理事件的应用程序编程接口(api)。包含对前一个事件内容的承诺（摘要）有效地将事件以不可变的序列向后链接在一起。
validator需要访问密钥事件消息的记录或日志，以便初步验证标识符当前控制密钥对的来源。这是一个密钥事件日志(KEL)。因此，只要validator在第一次接收原始事件序列时维护它的副本，它就会能够检测到任何试图更改该序列中的任何事件的后续利用。此外，使用链式密钥事件序列，仅拥有所有事件的最新摘要就可以检测到稍后提交给validator的密钥事件序列的任何其他副本中任何早期事件的篡改，即双工检测。这意味着validator不需要严格保持 KEL 的完整副本，而只需要保持最终事件，以便检测任何其他完整副本中的篡改。为了阐明，validator一开始仍然需要访问所有事件的副本，以便验证和建立控制权限，但validator应该在验证后丢掉完整事件日志，并且只维护它看到的最后一个事件，它可以通过从最后一个事件的摘要向后验证来重新建立对其他副本的有效性。在这种情况下，序列号允许validator更容易地确定不同的事件日志是否在其最后一个事件之前被篡改，方法是检查替代序列中具有相同序列号的事件，以查看其摘要是否相同，并根据其先前的事件进行验证，以此类推。
更详细的说，只要validator维护 KEL 的副本，攻击者就可能无法建立对标识符的控制，这是由于攻击利用了KEL中的某些早期事件。例如，原始密钥在后面如果被暴露出来，攻击者就可以伪造不同的初始事件。只要validator具有原始初始事件的副本，它就可以检测到伪造的初始事件并忽略它。同样，任何密钥如果后续被暴露出来，也可用于伪造不同的轮转事件。只要validator可以一次直接获得从原始初始事件开始的原始密钥轮转事件序列的副本，它就可以检测被攻击的轮转事件而忽略它们。在没有任何其他基础设施的情况下，为了使validator获得完整的事件日志，控制器必须确保validator按顺序接收每个轮转事件。这需要validator确认每个新轮转事件。为了确保发生这种情况，控制器和validator必须在传输时直接相互通信，即在线通信。如果任一方不可用，则交互暂停，另一方必须等待，直到双方在线恢复交互。
在接收到事件后，validator发送一条收据作为确认。收据包括相关密钥事件消息的validator的签名。控制器现在有一个已签名的收据，证明validator收到并验证密钥事件消息。因此，validator也充当事件的见证。控制器可以在密钥事件接收日志 (KERL) 中保留收据。这为带有validator的事务提供了信任基础。validator稍后可能不会拒绝其签名的收据，也不能在与控制器交互时引用不同的密钥事件历史。控制器通过选择直接与validator通信，隐式地将该validator设计为密钥事件流的见证。
每一方都可以建立自己的标识符，以便在这种成对交互中与另一方使用。因此，每一方都是自己标识符的控制者，也是对方标识符的验证者和见证者。每一方都可以维护另一方标识符的密钥事件日志，并从另一方接收密钥事件，从而保证每一方都不受攻击。包含签名密钥事件(由控制器签名)和密钥事件收据(由validator签名)的日志是密钥事件双签名收据的日志。每一个都隐含地指定另一个作为它自己的密钥事件的见证。因此，在记录的密钥事件历史维护的时间框架内，使用相关密钥进行的任何交易都可以根据密钥进行验证，而无需其他基础设施，如分布式共识分类帐。稍后将讨论有关如何验证相关交易事件。此外，validator可以保存直接从控制器发送到它的重复事件日志，例如重复事件日志 (DEL)。有了这个，validator可以证明控制器已经被利用。
这种方法实施的重要环节是初始事件的原始交换。然而，在直接交互中，控制器可以为关联的validator创建一个唯一的标识符，从而为该标识符创建一个唯一的起始事件。因此，只要validator保留原始初始事件的副本（或任何后续事件的副本），初始事件本身就不会因后续使用原始密钥对而暴露。实现这种功能的另一种方法是：每个成对关系中，每一方都可获得一组唯一的标识符和相关密钥对。
初始事件消息的交换也必须不受中间人攻击的影响(例如，通过使用多因素身份验证)，否则冒名顶替者(中间人)可以在其控制下创建不同的标识符，并混淆validator的正确标识符，以便在与真实控制器交互中使用。下面显示了直接模式基础设施的示意图：
间接模式
在间接重放模式中，validator可能在创建时无法接收和确认初始事件，或者在稍后的某个时间无法接收和确认任何其他密钥事件。因此，后来对相关密钥对的利用可能允许利用者建立替代的密钥事件历史，并将其提供给validator，从而抢占原始未利用的密钥事件历史。因此，从这样一个validator的角度来看，攻击者可以更容易地捕获标识符的控制。间接模式的目的是为标识符提供高度可用的可信服务，从而确保任何validator都可以访问密钥事件历史的原始版本的副本。通过间接模式，控制器可以指定一组证人（副本），这些证人存储密钥事件并将其转发给任何请求者。证人的这个功能可以被称为密钥事件发布服务。从控制器的角度来看，它可以提供密钥事件的容错、安全性和可用性。此类服务的简化图如下所示：
尽管作为密钥事件发布服务的见证集可以从控制器的角度提供容错可用性和安全性的保证，但由于它们是由控制器指定的，因此验证器可能不信任它们。然而，事件是端到端可验证的事实意味着validator可以自由地指定自己的一组监视器，这些监视器可以从validator的角度提供高可用性和安全性。这个监视器服务可以称为密钥事件确认服务。两种服务的简化图如下所示：
虽然去中心化的总排序分布式共识账本可以通过将发布和确认组合成一组节点来提供这种高度可用的可信服务（密钥事件历史），但它可能不是这样做的最小充分手段。如前所述，总排序分布式共识算法要么存在相对较高的延迟和较低的吞吐量，要么随着节点数量的增加而不能很好地扩展。它们的设置和操作可能相对复杂和昂贵。
这项工作描述了一种替代方法，该方法使用冗余不可变的密钥事件接收日志 (KERLS) ，以最小充分的方式提供这样一个高度可用的可信服务。将发布和确认分离为两个独立的控制位点，一个是控制器的，另一个是validator的，这简化了双方之间的交互空间。这在体系结构上分散了系统，并提供了更好的可伸缩性和性能。因此，服务功能可能具有比完全有序的分布式共识分类账更高的吞吐量、更低的延迟、更好的可扩展性、更低的成本和更低的复杂性。尽管这项工作消除了对完全有序的分布式共识账本的需求，但当其他因素或约束使其必要时，它仍然可能使用分布式共识账本。事实上，尽管 KERI 可能使用简单的见证人，但它的可移植性意味着：当需要时，可以使用更复杂的见证人，例如分布式共识分类账(即区块链)的预言机证人。在这种情况下，从 KERI 的角度来看，支持账本的节点池可能会作为一个见证人出现。但是，对于控制器和validator而言，一个见证人也可能会表现出足够高的安全性和可用性。控制器可以随时选择移动到不同的分类账或见证人集。这意味着标识符不是账本锁定的。下面的图中显示了，一个分类帐预言机作为见证与观察者的示例：
为了详细说明，将控制器和validator之间的位点控制分开的设计原则消除了总有序分布式共识算法的主要缺点之一，即对提供共识算法的节点池共享治理。删除强制共享治理的约束允许每个方、控制器和validator选择特定于其需求的安全、可用性、性能水平。可以进一步增强validator的确认服务以提供双工检测和其他保护。下图显示了这一点：
更详细地说，控制器的发布服务由一组 N 个指定的见证人提供。尽管见证人由控制器明确指定，但它们可能或可能不会在控制器的控制下。对证人的指定是通过建立事件中包含的可验证语句对见证人进行加密承诺。见证集的目的是更好地保护服务免受包括拜占庭故障在内的故障[36]。因此，该服务采用了一种拜占庭容错 (BFT) 算法。我们将此 KERI 的控制建立协议算法称为 ($KA^2 CE$)。$KA^2CE$算法的主要目的是保护控制器在外部攻击的情况下释放其密钥事件历史权威副本的能力。这包括保持足够的可用性程度，以便任何validator都可以按需获得权威副本。
关键的见解是，由于控制器是创建任何和所有密钥事件的唯一真相来源，它本身就足以对其自己的密钥事件进行排序。事实上，密钥事件历史不需要提供类似于帐户余额的双重支出证明，只需提供一致性即可。总的来说，密钥事件是幂等的授权操作，而不是非幂等的账户余额递减或递增操作。对于非等幂，全序或全局序可能是关键的，而对于等幂，局部序可能是足够的，特别是仅仅证明这些操作的一致性的时候（如何理解？）。这些见解的含义是，容错可以由见证人集提供，而不是像流行的BFT算法那样在副本池或其他总排序协议过程之间进行更复杂的多阶段提交[16;39;43;48;61;115;123;144]。事实上，$KA^2CE$ 实现的安全保证可以设计为接近其他 BFT 算法的安全保证，但没有它们的可扩展性、成本、吞吐量或延迟限制。如果其他算法可能被认为足够安全，那么$KA^2CE$也可以。此外，由于控制器是密钥事件的唯一真值来源，validator可能会要求控制器(无论受信任与否)对这些密钥事件负责。因此，该算法旨在使控制器能够为自己提供其认为必要的任何程度的保护。
依赖指定见证人集有几个好处。首先，标识符的信任基础不是锁定于任何给定的证人或一组证人，而是可以根据控制人的选择进行转移。这提供了可移植性。第二个是见证人的数量和组成也由控制器选择。控制器可能会改变这一点，以便在性能、可扩展性和安全性之间进行权衡。这提供了灵活性和适应性。第三，证人只需要提供验证（verification）和记录（logging）。这意味着即使是高成本或性能受限的应用程序也可以利用这种方法。
同样，鉴于控制器可能声明的任责任保证，validator可以通过指定一组观察者、陪审员和法官为自己提供它认为必要的任何程度的保护。具体来说，可以通过维护密钥事件历史的副本来保护validator，该副本是validator或validator信任的任何其他组件(观察者、陪审员、法官)首次看到的。该副本可用于检测密钥事件历史的任何不一致（重复）副本。然后，validator可以选择如何在检测到双重副本的情况下做出最佳响应，以保护自己免受伤害。特殊情况是恶意控制器，故意产生不一致的密钥事件历史。重要的是，维护密钥事件历史副本的组件，例如观察者、陪审员和法官，可能处于validator的控制之下。因此，任何validator都可以检测到恶意的重复事件历史。我们称之为环境双重检测(源于环境可验证性)。在这种情况下，validator仍然可以受到保护，因为它可能仍然让这样一个恶意的控制器对双重副本负责(信任或不信任)。validator有权决定是否将其原始副本视为相对于任何其他副本的权威副本，从而继续信任或不信任该原始副本。因此，恶意控制器以后可能无法替换它可能产生的任何替代副本而不受惩罚。此外，如上所述，创建替代事件历史记录的恶意控制器可能会危及它希望在关联标识符中保留的任何值。就标识符而言，它可能是完全自我毁灭的。恶意控制器产生可检测到的双重事件历史记录等同于可检测到的对其授权密钥及其见证集密钥的全面利用。这类似于对任何BFT分类账的完全但可检测的利用，例如对工作量证明分类账的可检测的51%攻击。一个可检测的完全漏洞会在漏洞点之后破坏该分类账中的任何价值。
为了重申，控制器可以指定其见证集，以提供任意程度的保护，以防止外部漏洞利用。尽管如此，在这种利用的情况下，validator可以选择不信任控制器，并要求其为双工性负责，从而停止信任标识符，或者将validator的密钥事件历史副本视为权威(忽略被利用的副本)，从而继续信任标识符。在检测到双工的情况下，这种对validator选择的依赖既会危及任何潜在的恶意控制器，也会保护validator。下面将更详细地讨论$KA^2CE$的细节。
控制建立的KERI共识算法
KERI的共识控制建立算法（$KA^2CE$）由标识符的控制器与控制器指定的一组 N 个证人一起运行，通过KERL提供密钥事件历史记录。使用密钥事件日志的一个动机是，冗余不可变（删除证明）事件日志的操作可以并行化，因此具有高度可扩展性（如何理解？）。KERL 是一个不可变的事件日志，它是由一组证人提供的，其中最多只有F个证人是恶意的。控制器还指定一个证人的阈值M，当N个目击者的任意子集（子集大小为M）确认该事件时，控制器接受对该事件的责任。此阈值表示在给定可能存在错误的证人数量F的情况下，控制器认为足够的确认证人的最小数量。该服务的目标是根据需要向任何validator提供可验证的KERL。与直接模式不同，在间接模式下，validator可能被视为隐式证人，而validator可能不是明确指定的提供服务的N个证人之一。
证人设计
控制器在初始事件中指定见证人tally和初始见证人集。tally 的目的是为确认事件的证人数量提供一个问责的门槛，这如下图所示。
随后的轮转操作可以修改见证集并更改 tally 。这使得控制器能够替换恶意的见证人和/或改变见证集的问责阈值。当轮转修改见证人时，需要提供新的tally，一组删除的证人和一组新添加的证人。这如下图所示。
证人策略
在这种方法中，给定标识符的控制器创建并将相关的密钥事件消息传播到 N 个见证人的集合。每个见证人验证它接收到的每个密钥事件的签名、内容和一致性。当经过验证的密钥事件是见证人收到的该事件的第一个版本时，它通过签名事件消息来创建收据来见证该事件，将收据存储在其日志 (KERL) 中，并将收据返回给控制器。根据传播策略，见证人也可能将其收据发送给其他见证人。这可能是广播协议，或者不使用广播协议。
回想一下之前的定义，事件在其密钥事件序列中的位置由其先前的事件摘要和序列号确定。在密钥事件序列中，对于给定位置的同一类事件的版本，如果其任何其他内容与同一位置/同一类别的其他事件不同，则该事件的版本与同一位置/同一类别的其他事件不同（如何理解？）。为了澄清起见，事件版本包括事件类别（建立或非建立）。类别问题的特殊情况是，在非建立事件被利用的情况下，同一位置的建立事件(例如旋转)可以取代非建立事件(例如交互)。这允许通过将建立事件旋转到未公开的下一组授权密钥，恢复对用于签署非建立事件的公开的当前授权密钥集。稍后将解释此恢复的具体细节(参见第11.6节)。一般来说，证人策略是，总是相信第一个看到的事件版本，即第一个经过验证的版本被见证（签名、存储、确认和传播），所有其他版本都被丢弃。这一规则的例外是，建立事件可以在一组被利用的非建立事件后恢复。恢复过程可能会从恢复的树干中取出一个分支。这个有争议的分支有被攻击的事件，主干有已恢复的事件。操作模式（见第 10 节）和可问责的双工性阈值决定了争议分支中的哪些事件由控制器负责(参见第11.6节)。
后来的消息或来自其他证人的收据不会改变日志KERL中的任何现有条目(日志只是附加的，即不可变的)。每个见证人还向其日志添加了从其他证人收到的一致收据中任何经过验证的签名。一致收据是指日志中已存在的事件的相同版本的收据。除恢复外，不一致的收据，即在同一位置的不同事件版本将被丢弃(不保存在日志中)。作为选项，控制器可以选择运行陪审员juror（与证人一起），juror保存证人收到的不一致收据的双工事件日志 (DEL)。KERL包括带有附加验证签名的事件，即控制器、证人的收据。
控制器向N个见证人发送收据（应该是事件）的初始传播可以使用控制器和每个见证人之间轮流交换的轮循协议，在网络带宽方面非常有效地实现。每次控制器连接到见证人发送新事件并收集新事件收据时，控制器还发送到目前为止收到的收据。这种循环协议可能需要控制器两次轮询证人集，并与其交互，以便对给定事件的所有其他见证人完全传播收据，这意味着每个事件最多需要2·N个交换，以便在每个见证人和控制器上创建一个完全见证的密钥事件接收日志(KERL)。因此，网络负载与见证人的数量成线性关系。当网络带宽受到约束较少时，八卦协议可以提供比轮询协议更低延迟的完全传播。八卦协议是一种相对高效的机制和规模，其复杂度为N·log(N)(其中N是见证人的数量)而不是2·N。有向无环图或其他数据结构可用于确定需要八卦的内容。
事件Escrow（我译为“托管”，就是证人帮忙保存日志）
KERI被设计成与协议高度无关，也就是说，控制器选择向其见证人发送事件的传输协议可能与实现相关。通常出于性能原因，这些协议中的一些可能会受益于证人。主要有两个用例：乱序事件和多签名事件。事件托管是控制器和证人之间实现的可选功能。见证人既可以使用无序来托管事件，也可以使用有序来托管事件。乱序事件可能首先保存在乱序缓存中，然后由有序缓存处理。
无序
当传输协议是异步的（例如 UTP）时，事件可能以无序状态到达见证人。乱序事件并不完全可验证，因为序列中没有紧接在前面的事件的副本，因此无法根据前面的事件验证事件摘要。此外，对于无序轮转（建立）事件，当先前的建立事件尚未收到并进入 KEL 时，新旋转的当前密钥集可能无法根据来自最近的先前建立事件的下一个密钥摘要进行验证。如果目击证人丢弃了一个可验证但无序的事件，那么该事件最终必须被重传。这增加了网络加载和延迟。我们可以在托管缓存中保存可验证但无序的事件，直到丢失的中间事件出现，这会在一定程度上优化异步协议中网络带宽和延迟。
如果未经验证的无序事件也会被缓存，那么恶意攻击者就可以伪造多个事件，从而填满缓存，造成拒绝服务攻击。
多签名
当 KEL 建立的标识符前缀使用具有一组权威密钥对的多签名方案时，可能存在一组相应的控制器，其中每个控制器持有该集合中的一个或多个密钥对。这称为多控制器的情况。这组控制器可以在它们之间使用收集协议，其中一个控制器首先收集足够的签名以达到多签名阈值，然后将带有签名的事件发送给见证人。除了会带来延迟之外，指定的收集控制器也可能成为单点故障。
在多控制器的情况下，收集签名的替代方法是证人直接从每个控制器收集事件，其中每个事件只有一个部分签名集。在这种情况下，该事件可以保存在托管中，直到缓存中有足够多的部分签名集。与在发送给见证人之前首先收集全套签名的两阶段协议相比，多签名阈值事件托管能力可能更具性能和可靠。
在这种情况下，如果附加的签名集至少包含一个可验证签名且没有不可验证签名，则可以在多签名事件托管缓存中保存有序但可验证的事件（为什么是有序的？）。这最大限度地减少了拒绝服务攻击的风险。
共识过程
在算法中使用 N 个指定见证人的目的是在见证人故障的情况下保证服务的可用性和安全性。除了无响应性和网络中断等故障外，允许的故障还包括拜占庭故障，如证人的恶意或不诚实行为。控制器故障是一种特殊情况，将在下面讨论。不诚实的证人可能会公布不一致的事件版本的收据，或忽视储存，或分发收据。无反应但诚实的证人可能无法签发收据。恶意见证人可能故意无响应。拜占庭协议 (BA) 用于描述一种算法，该算法在拜占庭错误的情况下提供了共识协议的某种保证，即拜占庭容错(BFT)[36]。与更传统的 BA 算法不同，$KA^2CE$ 不需要共识过程提供事件的总排序。该排序已经作为控制器的输入提供给算法（如何理解？）。$KA^2CE$ 中的共识协议过程的目的是为控制器发出的每个事件生成一个可验证协议，该协议以安全高度可用的方式收到来自足够数量的证人的收据。该算法仅对已排序的事件产生可验证的确认。这大大简化了算法。
传统 BA 算法中的共识协议保证通常以正确（correct）、安全（safe）和存活（live）术语为特征。这些保证存在于经过多个阶段来达成共识的算法中。这使算法变得复杂，因为一个阶段的协议可能不会传播到下一阶段。在该算法（$KA^2CE$）的情况下，共识过程是非常不同的，以至于没有正确（correct）、安全（safe）和存活（live）的定义，尽管 $KA^2CE$ 中的一些相关约束令人想起与这些术语相关的传统BA算法中的约束。为了更好地理解差异，我们首先在提供术语之前总结这些术语的常用定义。通常 F 被定义为任何时间内的最大故障节点数（任何类型的故障）。如果最多有 F 个故障节点，F + 1 个节点的共识协议是一致的，因为其中至少有1个节点是诚实的。因此，这种协议被称为正确的，但不能保证任何一组 F + 1 个节点将是一致的。促成或达成一致协议的一组节点称为法定人数quorum。在这种情况下，F + 1是正确协议的quorum大小。此外，假设 N = 2F + 1，其中 N 是节点的总数。然后保证正确的一致性，因为 N 个节点中至少有 F + 1 是诚实的，它们也形成所有节点的大部分，因此不可能达成其他协议。因此，这种协议被称为安全(safe)。但是不能保证达成协议的节点（quorum）在随后的一轮中达成一致，因为在给定的一轮中，多达F个达成协议的节点可能在下一轮中变得无响应。在多阶段算法中，这意味着尽管是安全的，但协议并不是存活的（live），因为协议不会传播到下一轮。假设 N = 3F + 1 ，那么像以前一样保证正确的一致性，但一致性将有 2F + 1 个节点（quorum 大小），尽管这些 2F + 1 个节点的一些 F 变得无响应，但剩余的 F + 1 个诚实和响应节点将能够传播正确安全协议下一轮。因此，N = 3F + 1 ，quorum大小为 2F + 1 ，保证了多轮的正确、安全和存活。
故障
在 $KA^2CE$ 中，我们将 F 定义为任何时候潜在的错误见证人的数量。故障行为可能是无响应或不诚实。证人故障可能是无意的，也可能是恶意外部攻击的结果。在这两种情况下，控制器都可以通过设计一个冗余的见证人集来提供容错。我们使用潜在的故障，因为它更好地描述了我们如何看待系统中的故障。我们可以将潜在的故障见证人分为诚实但无响应或恶意的。例如，假设在任何时候，最多A个证人可能是诚实的，但没有反应，B个证人可能是恶意的(要么没有反应，要么不诚实)，那么根据我们的定义：
$F=A+B$
恶意的B用户，我们可以进一步分割成恶意无响应或响应但不诚实。
一致性（Agreement）
回想一下，一个诚实的证人最多只能见证一个事件的一个版本(即创建、存储和确认收据)。必须首先验证该事件版本。经过验证的事件版本必须与先前的事件一致，并由控制器的权威密钥签名。见证行为取决于控制器首先创建一个可验证的事件版本。如果事件被见证并传播到另一个见证人，则该收据已被颁布（promulgated）。因此，控制器首先创建自己的事件收据，然后将收据事件颁给证人，以收集他们的颁布收据。在该算法中，一致性由具有来自控制器的可验证收据和一组证人的事件的特定版本组成(如何理解？)。对于一组证人来说，关于事件的一个版本的一致状态意味着该组证人中的每个证人都见证了该事件的相同版本，并且该组证人的收据已公布给该组证人中的所有其他证人。任何validator、观察员、陪审员(juror)或法官(judge)都可以通过可验证的事件副本的一致性来了解和证明该一致性状态。这样的副本可以从KERL获得。达成一致性的证人组成一组。该集合中的每个证人都是相关一致性收据的贡献者。同样，一项一致性的大小是指有贡献的证人的数目，也就是一致性中收据的数目。一致性示例如下图所示：
由于传播事件和传播事件收据都是控制器的责任，一致性过程总是取决于控制器（至少最初，如何理解？）。从控制器的角度来看，充分的一致性是这样的：证明在足够多的证人之间存在一致性状态，从而控制器可能对该一致性负责。同样，从validator的角度来看，充分的一致性可证明在足够大的一组证人之间的一致性状态，validator可以接受该一致性作为权威。对于控制器来说足够的东西对于validator来说可能并不足够。为了澄清起见，让 $M_C$ 表示从控制器的角度来看表示充分一致性的阈值大小，并让 $M_V$ 表示从validator的角度表示足够一致性的阈值大小。通常，$M_V \geq M_C$。阈值 $M_C$ 与上面定义的责任阈值 M 相同。
一个高度可用的系统需要一定程度的容错。责任阈值 (tally) 的目的是启用密钥事件服务对控制器或证人的错误行为的容错能力。主控制器故障表现为在使用其密钥时的双工行为。在这种情况下，阈值用作可问责的双工阈值。这个阈值让validator知道它何时可以让控制器对双工行为负责。如果没有阈值，validator可能会选择让控制器对任何双工行为负责，这些证据会使服务在存在此类错误行为时变得脆弱。validator让控制器负责的主要方法是停止相关标识符的任何使用。这将破坏标识符中的任何值，并且不允许控制器恢复。回想一下，轮转密钥(预轮转未曝光)的一个目的是能够从受损的交互签名密钥中恢复。受损的交互签名密钥可能在控制器部分表现为双工行为。可问责的双工阈值使validator能够区分潜在可恢复的双工性(如签名密钥被暴露)和不可恢复的双工性(如旋转密钥被暴露)。这更好地保护validator和控制器，并提高服务的鲁棒性。
控制器负责颁布一组相互一致的收据，即充分一致性大小满足$M \geq M_C$。回想一下，只有控制器持有可以创建事件并指定见证人的权威密钥。因此控制器是不可替换的，总体一致性过程取决于控制器的可用性，至少最初是这样。因此，算法在等待控制器时可能会无限暂停。无响应的控制器可能会无限期地延迟协议。同样，算法的共识协议保证可以分为两种情况：第一种情况是诚实的控制器，第二种情况是不诚实的控制器。当见证人还颁布事件时，尽管有一个无响应控制器，但一个无故障见证人见证了事件，那么一个事件可能会继续被颁布。不诚实的控制器还可以分为两种情况：第一种情况为，尽管控制器不诚实，但validator可能相信这是因为F个证人都发生故障所导致的。当见证人不在控制器的直接控制下时，可能会出现这种情况。此外，已经利用权威交互签名密钥的控制器可能看起来不诚实。这个子案例中的区别在于，尽管有一个不诚实的或同样被利用的控制器，但最多F个证人可能被利用了。第二种情况是，证人可能受到不诚实或被利用的控制器的控制，因此超过F个证人可能是错误的（如何理解？？）。
因为不诚实的控制器可以选择颁布事件的不一致版本，因此可能无法保证会出现充分的一致性。然而，从validator的角度来看，更重要的是，尽管控制器不诚实和/或一些不诚实的见证人，但它不会有任何损失。同样重要的是，一旦达成协议，任何validator（观察者watcher、陪审员或法官）都可以按需获得该协议的副本。
回想一下，对控制密钥对的live攻击可以捕获当前权威密钥集。接下来，我们扩展了live攻击的定义，以包括证人的共识过程。关于控制器，成功的live攻击用将阻止就任何新发布的事件达成充分一致性，即$M_C$。关于validator，成功的live攻击会将对任何新发布的事件产生无法检测到的双工但充分的一致性，即$M_V$。（无法阻止live攻击）相比之下，任何成功的dead攻击必须发生在达成一致之后的未来某个时间，与利用新事件达成一致的过程无关。共识算法的主要目标是提供一个一致性过程，以保护诚实的控制器和validator免受恶意利用。validator持有的任何先前存在的KERL副本，这些副本来防止后来的dead攻击。
适当的（Proper）
鉴于上述F的假设，一组F + 1证人的任何协议都意味着在协议过程中，控制器无过错，协议中至少有一个证人无过错(既诚实又有反应)。因为至少有一个见证人诚实，所以协议被认为是适当的。与适当协议相关的事件称为适当的事件。回想一下，见证人只会见证事件的第一个可见可验证版本。因此，产生任何包含诚实见证人的协议意味着所有见证人对该协议的一方都见证了该事件的相同版本。然而，不能保证任何一组 F + 1 见证人都会对事件的任何版本达成一致（为什么？）。尽可能多的F可能没有反应，或者尽可能多的F可能有反应但不诚实，或者控制器有故障。
显然，任何有用的充分一致性也必须是适当的。这就为tally M设置了一个下界，以达到充分一致，即，
M是$M_C$或者$M_V$。
有益的（Utile）
如果validator、观察者、陪审员或法官等任何请求者都可以获得至少一个正确的副本，则认为该协议（之前有的时候会翻译成一致性，在这里翻译成协议，英语是agreement）是有益的。根据我们对协议的定义，该协议中的每个见证人都必须向协议提供收据并收到协议的副本（完全收据事件的副本）。事实上，非故障控制器最终会从每个见证方收集收据，所有这些收据都将传播到所有见证人，从而确保每个非故障见证人都将拥有协议的副本。此外，由于适当的协议中至少有一个证人是非故障的，因此该协议的副本将通过该见证人获得。因此，任何适当的协议都是有益的，因为至少有一个非故障见证人将拥有副本并使其可供请求者使用。与有益的协议相关的事件称为有益的事件。
完整的（Intact）
非故障控制器希望选择证人 N 的总数，以确保确实会发生适当的协议。回想一下，最多 F 个见证人可能会出错。无故障的控制器不可能依赖任何有故障的证人来促成任何协议。将可能故障的证人从有助于达成充分一致的证人集中排除，使tally M相对于N有一个上界，即：
其中 N 是见证人的总数，M 可能是 $M_C$ 或 $M_V$。回想一下，必须有足够的一致性，即$M \geq F+1$。这给出了 M 的组合约束，如下所示：
适当的协议要求至少 F + 1 个见证人是一致的，因此适当协议的保证要求至少 F + 1 个见证人是非故障的。但是超过 F 的 N 个见证人中的任何一个都将是非故障的，并且依赖于非故障控制器来达到一致性。因此，N 必须足够大以，允许 F + 1 个非故障见证人和 F 个故障见证人。如果我们将$M \geq F+1$代入 eq.11.3 并求解 N，我们得到 N 的下界，即，
这种约束的满足使非故障控制器能够保证一组见证人之间的适当一致性。重要的是，由于非故障控制器只会颁布一个版本的事件，因此可以保证关于一个且仅一个版本的协议。回想一下，由于非故障控制器将从每个非故障见证人那里收集收据，因此非故障控制器最终将拥有一份协议副本，并将其分发给所有无故障证人。如果 N 满足这个约束，这种适当的协议的保证意味着协议被认为是完整的。与完整协议相关的事件可以称为完整事件。为了阐明，完整的协议是建立在非故障控制器的基础上的。鉴于这种偶然性，应保证至少F + 1名无故障证人拥有唯一一份适当协议的副本，这意味着他们都可以向任何请求方提供协议副本。因此，完整的协议也是有益的协议。
免疫（Immune）
然而，非故障(诚实)控制器的假设对于validator或原始控制器不能令人满意。考虑不诚实的控制器的情况，但见证人不在其控制之下，因此validator或原始控制器仍然可能相信不会有超过F个故障的证人。这相当于当前标识符的控制密钥集可能被泄露，但证人的密钥集没有泄露，或者泄露的证人密钥集最多只有F个。此外，考虑到对未暴露的下一个预旋转密钥进行live攻击的实际不可行性，唯一实际可行的攻击是对用于签署交互事件的当前控制器密钥进行攻击。原始控制器可以通过使用先前未暴露的预轮转密钥集颁布轮转事件来从此类利用中恢复。因此，在这种情况下，可建立一个可问责的双工阈值可以保护标识符中的价值，并通过轮换实现恢复。回想一下，对于任何足够的协议，控制器都可以是可问责的。允许不诚实或被利用的控制器创建多个但不一致的协议，并对其负责可能会给自身带来的问题。同样，validator希望保护自己免受此类攻击的伤害。在这种情况下，如果validator接受与另一个validator相关事件的不同版本，则可能会伤害自己。当在一个事件的多个版本上出现足够的协议（sufficient agreements）时，validator可能无法确定哪个版本是权威的，以便让控制器负责，或者与其他validator相协调。
在这两种情况下（控制器恢复或validator接受）的保护将是保证在任何事件的最多一个且唯一的版本上达成一致，或者根本不达成一致。这意味着任何validator都只能认为只有一个版本是权威的和接受的。要么协议只发生在一个事件版本上，任何validator都可以将其作为权威版本接受，要么协议永远不会发生，这意味着任何版本都不会被任何validator接受。对M、N和F的联合约束提供了这种保护。
考虑给定足够大的 N 的情况，不诚实的控制器可以通过颁布事件的不同版本来创建两个或多个足够的协议(就是上面图的数据结构)，每个协议都针对不相交的见证人子集，其中每个子集至少有M个见证人。当任意两个协议集的交集子集足够大到足以包含至少一个诚实见证人时，就可以防止这种情况。回想一下，诚实的见证人可能永远不会看到同一事件的两个不一致版本。因此，任何两个充分的协议，其交集包括一个诚实的证人，因此必须对该事件的同一版本达成一致。这确保了尽管控制器不诚实，但最多一个版本的事件将有足够的一致性，或根本没有充分的一致性。
我们可以根据 F 和 N 推导出对 M 大小的最小约束，以保证事件的至多一个版本可能有充分的一致性，或者根本没有达成一致性。在这种情况下，M 可以用作可问责的双工阈值。集合中的成员数量称为其基数（cardinality），由运算符$|*|$给出。设所有证人的集合记为$\widehat{N}$，其基数为，
设$\widehat{M}$代表一组充分一致（sufficient agreements）的证人。它的基数，可以表示为$|\widehat{M}|$。考虑任意两个协议集$\widehat{M}_1$和$\widehat{M}_2$。第一个约束条件是两个协议集的联合必须包括所有证人，即：
这确保了所有见证人都包含在一个集合中。它对协议集的大小设置了下限。由此，我们可以推导出基数之间的关系如下：
进一步，考虑两个协议集$\widehat{M}_1$和$\widehat{M}_2$的基数等于充分协议的阈值M，即:
现在回想一下，给定最多 F 个潜在故障见证人，任何大小至少为 F + 1 的集合都保证至少包含一个诚实的见证人。因此，这里的约束是交集必须至少包含一个诚实的见证人。这意味着$\widehat{M}_1$和$\widehat{M}_2$的交集的基数必须至少为 F + 1 ，即，
接下来我们将使用两个集合的基数和之间的关系，即，
我们可以代入并重写为等式得到：
可以推导得：
变成不等式，可以得到：
因为M一定是整数，所以它等于：
式中，$\lceil*\rceil$表示最小整数函数，即$\lceil x\rceil$定义为大于或等于x的最小整数。上述约束意味着，充分一致阈值M必须是N的多数。
M的上下约束可以组合为：
这种约束的满足保证了尽管控制器不诚实，但最多发生一次足够的一致性（sufficient agreement），或者根本没有出现任何一致性。这意味着协议是免疫的。详细地说，假设最多有F个潜在的故障证人，免疫协议要求M是N的足够多数，并保证服务可能只对每个事件的一个版本产生足够的一致性，或者即使有不诚实或被利用的控制器，也不会产生任何一致性。
这可以与上述公式中完整协议的约束结合使用。当M、N和F共同满足上述免疫约束时，则N和F同时满足上述先前完整约束。为此，重写上述公式，去掉M。那么可以得到：
取极限值，有：
这可以得到$N = 3F + 1$，这显然大于$N = 2F + 1$。这意味着当控制器诚实时，任何被认为免疫（immune）的一致性也可能被认为是完整的（intact）（没看懂）。因此，当控制器没有故障时，免疫约束（immune）意味着完整的（intact），这共同保证了一个和只有一个版本的事件确实会发生充分的一致性。回想一下，当完整（intact）时，一致性也是有益的（Utile）。此外，在通过泄露的当前权威密钥潜在地利用控制器，但最多有F个故障证人的情况下，免疫约束（immune）保证从这种利用中恢复可能成功。稍后将提供恢复的详细信息。
下表中提供了满足抗免疫约束的对于小 F 而言的 M、N 和 F 。
总之，当M、N和F满足上式时，尽管控制器不诚实，服务可能只产生有关事件的适当有益的（proper utile）协议，也可能根本不产生任何有用协议。或者等效地，在满足免疫约束的情况下，服务可能不会产生多个不同但正确的密钥事件接收日志(KERLs)。因此，任何服务用户，无论是validator、观察者、陪审员juror还是法官，都将能够从某个见证人那里获得关于需求的适当（proper）事件协议（那个数据结构）。任何具有适当协议（proper agreement）的非故障见证人将在其KERL中保留该协议并在需要时提供该协议。此外，为了被认为是适当的（proper），协议必须由作为该协议一方的每一个无故障证人核实为与所有先前事件一致。回想一下，完整的协议是适当协议的保证。因此，对任何事件的完整协议等于对所有先前事件的完整协议。这意味着包括完整事件在内的任何相关KERL都可以被认为是完整的（如何理解？）。因此，证人的适当事件的可用性等于与该证人事件一致的所有先前事件的适当日志 (KERL) 的可用性，从而保证服务的高可用性。
证人轮换
如上所述，指定证人集是在初始事件中指定的，然后由轮转事件更改。这可以被认为是轮转见证集。具体来说，轮转事件可能会最终改变见证集的大小和组成。这允许控制器修剪故障见证和添加新见证人。此功能使控制器能够使用旋转事件，不仅可以旋转权威签名密钥以便从利用中恢复，还可以替换可能变得无响应或故障的证人。由于轮换事件，证人数量或问责门槛可能随着证人集中证人的变化而变化。要使关联的事件协议具有免疫性，则此事件必须由新见证集中的多个证人（达到阈值）所见证。如果新见证集的成员与旧见证集明显不同，即大多数见证人都被删除了，那么validator可能会更难发现新事件和见证集，因为旧的见证人可能不再提供事件。改善这种影响的一种方法是要求足够数量的旧见证集也见证该事件。此时，validator更容易安全地发现和验证见证集的变化。换句话说，每个证人都必须见证将该证人从证人集中剔除的事件。
基本证人轮转
以下讨论详细说明了这种联合协议条件，即新旧见证集的充分一致性（sufficient agreement）。
让符号 $W_i$ 表示来自一组 N 个见证人的某个证人，其中下标 $i$ 表示特定的见证人。令符号$\widehat{W}_l$表示一组带有下标 $l$ 的见证人，其中下标$l$表示与第$l$个建立事件相对应的证人集。因此，初始见证集$W_0$在$l = 0$时由初始事件指定，可以表示为：
对于建立(旋转)事件，任何后续的见证集$\widehat{W}_l$可以表示为：
$\widehat{W}l$为当前第l次旋转产生的证人集，$\widehat{W}{l-1}$为前l-1次建立事件(开始或旋转)中产生的证人集，$\widehat{X}l$为从$\widehat{W}{l-1}$中新删除的证人集，$\widehat{Y}_l$为$\widehat{W}_l$中新添加的证人集。上述集合满足：
第l轮后证人总数$N_l$可按下列方法计算：
式中$N_{l-1}$为第$l−1$次旋转后的证人总数，$O_l$为第l次旋转中新删除的证人的数目，$P_l$为第l次旋转中新添加的见证人的数目。第l此旋转的tally（阈值）必须满足：$M_l \leq N_l$。$M_l$表示validator在接受关联的第l个事件之前必须从见证列表中获得足够的确认见证收据的数量。
联合确认证人轮转(Joint Confirmed Witness Rotation)
作为对控制器或validator的额外保护，更改证人集的旋转事件还必须确认收到来自先前 l-1 组的足够数量的证人的收据。这个数字由前面的 tally，即$M{l−1}$给出。改变证人集的旋转必须满足两个确认集的两个阈值，第一个来自 l-1 组的证人集，第二个来自第 l 组的证人集。设$\widehat{U}{l-1}$表示第l−1个旋转事件对应的证人收据的集合，那么必须至少有 $M{l-1}$ 个收据在$\widehat{U}{l-1}$中。这一要求可以表示为，$\widehat{U}{l-1} \subseteq \widehat{W}{l-1}$，$\left|\widehat{U}{l-1}\right| \geq M{l-1}$。
同样，让$\widehat{U}{l}$表示第 l 个旋转事件指定的第二组见证人收据的集合。$\widehat{U}{l}$中必须至少有$M_l$个收据。这一要求可以表示为：$\widehat{U}_l \subseteq \widehat{W}_l$，$\left|\widehat{U}_l\right| \geq M_l$。
可以得到：$\left|\widehat{U}{l-1} \cup \widehat{U}_l\right| \leq M{l-1}+M_l$。
从两个集合中确认证人的约束意味着：攻击者必须破坏来自先前和当前见证人集的足够数量的见证，以便验证事件。这可以防止产生旋转事件的替代版本的攻击者用故障见证人替换先前事件中的所有见证人。攻击者还必须从先前的建立事件中破坏足够数量的见证人，以便在被利用的事件中更改它们。需要澄清的是，除非两组证人都有足够数量的确认收据，否则validator可能不会接受轮换事件。这可能是一个可选的功能。它可能受益于为建立事件添加唯一的确认证人先验阈值。它可以使用来自先前建立事件的先验阈值作为默认值。然而，任何validator都可以选择自己的先验确认阈值。唯一的要求是，旧的诚实证人要见证删除它们的事件。这种联合确认的问题是，如果太多的见证人被破坏，那么先前的见证集确认永远不会达到阈值，并且validator不会接受恢复。标识符对validator来说是死的，也就是说，从validator的角度来看，控制器是无法恢复的。这相当于超过了允许的故障见证者的 F 阈值。这组额外的见证收据可以帮助validator协调任何密钥攻击，这些攻击意味着相关的旋转可以从中恢复。它还可以帮助协调死攻击，因为死攻击必须攻破两组密钥，而不仅仅是一组（为什么是两组？？之前的证人与现在的证人？）。
恢复
回想一下，密钥旋转的主要目的之一是能够从影响当前权威密钥集的实时利用中恢复。因为当前的权威密钥集已经通过使用签署一个或多个事件暴露了出来，因此存在被攻击的可能性。恢复是通过旋转到先前未曝光的密钥集来执行的，即预旋转的集合。未暴露的密钥被攻击实际上可能是不可行的。在密钥集被暴露的情况下，证人如何处理、验证、存储和发布事件的规则在这里解释。进一步回想一下，当该协议包含足够数量的收据 M 时，控制器才可能对该协议负责。
当旋转事件用作原始控制器颁布的恢复事件，以响应其检测到由一组受损密钥创建的被利用的交互事件时，证人用于见证的策略(即验证、存储和发布事件)是不同的。这不仅适用于间接模式，也适用于直接模式，在直接模式中，validator是一个伪见证者/观察者。这种情况的示意图如下：
我们将介绍上述 KERL 图中的示例，以说明它们的规则。图中的每个密钥事件都标有其序列号。每个密钥事件还有一个箭头，显示摘要链到序列中的前一个事件。有三种类型的事件、初始事件、旋转事件和交互事件。初始事件可以被认为是旋转事件的一个特例。可能只有一个初始事件。此外，由于初始事件不参与从利用中恢复，因此其没有特殊的恢复规则。事件也用颜色标记。绿色的事件是日志中的条目，它们有足够的收据来达到或超过问责阈值M。红色的事件没有足够的收据来达到问责阈值。该图表用两列显示事件。第一列包含未利用的事件，即使用未泄露密钥签名的事件。第二列包含利用的事件，即使用泄露密钥签名的事件。
标记为0到6的事件是正常的。注意，事件4是一个旋转事件，因此签名交互事件5和6的当前授权密钥首先在事件4中公开。事件4还提交下一组密钥，这些密钥可能直到后续的轮换事件才会公开。假设事件 4 中暴露的当前权威密钥在事件 6 之后被攻击者破坏。攻击者选择使用这些被破坏密钥创建可验证一致的交互事件 7,8 和 9。这些事件被颁布给创造证人收据的见证人。该日志所属的特定见证验证了所利用事件7、8和9的事件签名和一致性，作为这些事件的第一个可见版本，因此记录到日志中。该见证人还会收到并记录足够数量的被利用事件 7 和 8 的收据，以达到问责阈值 M。原始（真实）控制器注意到见证日志中利用的事件，并决定使用旋转恢复。该控制器在序列中创建自己的事件 7 版本作为旋转事件，并将其发送给见证人。这有效地对日志中已经存在的交互事件7、8和9进行了争议。
这里描述的特殊恢复规则是：旋转事件会取代具有相同事件序列号和摘要的交互事件。回想一下，同一位置的事件版本的定义还包括事件类型。为了澄清，事件版本不仅由事件的序列号和前一个事件的事件摘要定义，而且还由事件的类型(建立或非建立)定义。在这样做的过程中，证人在替换或重写旋转事件的位置创建一个fork。一个分支包含旋转事件和后续条目，另一个分支包含覆盖的交互事件和从它链接的后续交互事件。前一个分支是恢复的分支，后一个分支是争议的(已被攻击)分支。
这里描述的另一个特殊恢复规则是，一旦证人(validator作为代理证人)接受了替换的轮换事件，证人将不再接受任何类型的新事件进入有争议的分支。
有争议的事件只能是交互事件，可能处于两种状态之一，可问责与不可问责。如果见证人已经收到足够的收据来达到或超过问责阈值 M，则认为该事件是可问责的。在直接模式下，validator是代理证人，则可问责的阈值为1。这意味着，在直接模式下，所有有争议的事件都是可问责的。
这里介绍的另一个特殊规则是，可问责但有争议的（交互）事件被认为有效。换句话说，可问责事件（争议与否）都会被正常对待。然而，有争议的但不可问责的事件则被特殊对待。特殊情况是，当见证人的传播策略是：允许它直接向其他见证人发起传播收据（八卦），此时，证人专门处理争议但不可问责的事件，特别是停止向其他证人传播相关收据。然而，证人应要求提供其已记录的争议事件的收据。证人也将继续接受其他证人对有争议事件的收据。如果证人随后收到足够的争议事件收据以达到问责阈值，那么该事件就变成了一个可问责但有争议的事件，此时证人可以恢复其对该事件的正常传播政策。
处理有争议但尚未问责的事件，特别是不允许证人发起传播收据的做法，目的是为原来的真实控制器提供更多机会，在所有证人第一次看到有争议的事件之前，向他们传播恢复轮换事件。回想一下，一旦证人接收到替换的恢复旋转事件，它就停止接受任何新事件到由该旋转事件创建的新争议分支中。这也为控制器提供了更多的机会，让任何无响应或离线证人首先看到恢复旋转事件。停止证人传播的收据会导致有争议事件的（八卦）收据呈指数级下降。恢复可能会产生不可避免的竞争条件，但特殊规则最小化了该竞争条件的程度（如何理解？）。
”允许将可问责但有争议的事件接受为有效”的规则，可以防止不诚实但未被利用的控制器随后恶意干扰先前创建的事件。一旦事件收据达到了可问责的阈值，那么它们的有效性就变得不可变了。因此，控制器可以恢复对受损密钥的控制，但不能拒绝已经负责的交互事件。这可以保护validator免受不诚实控制器的攻击。此功能需要在安全性和便利性之间进行权衡。通过使用扩展的旋转事件来实现交互事件的功能，可以完全避免这种类型的攻击。在这种情况下，当前的权威签名密钥在每次使用后都将轮换为未公开的密钥。这是以更多的旋转为代价的，这在许多应用中可能不方便。
嵌套委托恢复(Nested Delegation Recovery)
委托标识符为恢复引入了额外的规则。在KERI委托中，委托是合作的(cooperative)，这意味着委托方和委托方都必须为委托做出贡献。委托方(delegator)通过委托建立事件(delegated establishment event)的seal在轮换事件或交互事件中创建加密承诺(如何理解？意思就是委托建立事件可以是交互事件或者是轮换事件)。被委托方（delegate）通过对委托事件(delegating event)的签名在其建立事件中创建加密承诺。每个承诺由其提交人签署。delegator为其delegating事件签名，delegate为其delegated事件签名。因此，为了伪造委托，攻击者必须同时获得delegate的预旋转签名密钥和委托事件为交互事件时delegator的当前签名密钥，以及委托事件为旋转事件时delegator的预旋转签名密钥。这种合作委托与事件的特殊替代恢复规则一起实现了合作恢复（如何理解？）。
委托标识符引入了额外的恢复规则。在 KERI 委托是合作的，这意味着委托人和委托人都必须对委托做出贡献。委托人通过密封委托建立事件在旋转或交互事件中创建加密承诺。委托人通过密封到委托事件在其建立事件中创建一个加密承诺。每个承诺分别由提交者签名。委托人签署其委托事件并委托签署其委托事件。因此，为了伪造委托，攻击者必须在委托事件是交互事件时损害委托方的预旋转签名密钥和委托方当前签名密钥，当委托事件是旋转时，委托方的预旋转签名密钥。这种合作委托以及事件的特殊超级恢复规则使合作恢复成为可能。
规则如下：旋转事件可能会取代delegator的密钥事件日志中的交互事件。替换的委托轮换（delegating rotation）或后续的委托交互（delegating interaction）可以为delegate的密钥事件日志中的替换轮换事件提供加密承诺，以恢复对delegate的KEL的控制。这种取代委托旋转可以取代旋转事件，而不仅仅是交互事件。（我的理解是可取代delegate日志中的轮换事件）因此，在delegated的密钥事件日志中，分叉可能不仅发生在交互事件中，也可能发生在旋转事件上。委托事件链决定了这样一个替代事件是否有效。特殊规则是delegator用于委托替代事件的密钥必须马上被轮换（这段话其实很长，但是没咋理解）。
这种替代规则可以递归地应用于多个级别的委托，从而允许通过下一个更高级别的替换轮换委托恢复在任何较低级别签名或预旋转的任何密钥集。这将更高级别密钥管理基础设施的安全性级联到较低级别。这是KERI中标识符合作委托的独特安全特征。
DDOS
无响应控制器可能不会向任何见证人发出新事件，从而延迟对其自己的密钥事件的协议（之前的数据结构）的产生。控制器部分的无响应可能是出于选择，也可能是控制器受到攻击的结果。因为控制器的无响应性，主要造成了对控制器的威胁，而不是对validator的威胁，所以控制器可能很少有动机造成自己的无响应性。然而，外部攻击者可能有很大的动机延迟新密钥事件的发布，特别是为了防止通过新的轮换事件进行恢复。攻击者可以通过获取控制器的网关或路由器的控制权来拦截控制器的网络访问。减轻这种攻击的一种方法是控制器使用多个不可预测的网络接入点。回想一下，控制器是根据其权威密钥对(而不是其域名或IP地址)进行自我身份验证的。因此，任何网络访问机制都可以被证人验证。类似地，攻击者可以使用分布式拒绝服务(DDOS)攻击干扰控制器的网络访问。这只有在控制器使用公共或已知的可解析域名或IP地址作为目标时才可行。使用动态选择的网络接入点同样可以减轻对控制器的DDOS攻击。一般来说，减轻网络访问攻击的机制是众所周知的，因此不是由该算法直接提供的。在任何情况下，该算法假设控制器可能遵循最佳实践，以确保对其需求的足够响应水平。
由于作为一个组的证人提供的服务可能是公共的，因此它们每个都可能需要一个可公开解析的域名或IP地址。因此，针对证人的分布式拒绝服务攻击可能不那么容易减轻。但是，请记住，证人是根据其公钥对而不是其IP地址进行自我身份验证的。因此，控制器在遭受到DDOS攻击时，可以在别的ip地址上克隆之前的证人。然后控制器可以将这些新地址发布给任何解析器。DDOS攻击不仅要攻击克隆出的证人，还要攻击解析器。控制器提供新克隆的速度可能比机器人化DDOS攻击快得多。一个控制器可能只指定几个证人，但却可以指定几十个证人的克隆。在最坏的情况下，这减慢了证人提供服务的速度，但并不能阻止它提供服务。DDOS攻击必须攻击大多数证人的所有克隆才能成功。DDOS的缓解可以通过每个证人的水平扩展来实现。这为KERI提供了抵抗DDOS攻击的能力。
例如，假设控制器指定7个证人，阈值为 5 个证人，最多有2名故障证人。该控制器还生成了每个证人的十个克隆实例。对一个见证人的成功 DDOS 攻击需要对其所有十个克隆进行成功的攻击。对事件的成功 DDOS 攻击需要对至少 3 个见证人的所有克隆进行成功的 DDOS 攻击。在克隆证人的情况下，即使增加少量证人以允许更多错误证人，难度也会成倍增加。
此外，控制器可能会创建地址不公开解析的克隆。然后，这些见证人可能会将他们的收据广播给仅记录收据日志的环境观察者（validators、观察者、陪审员、法官）（例如 IPFS）。观察者的数量可能非常大。除非DDOS攻击也针对观察者，否则使用观察者访问日志的validators可能不会被DDOS攻击所阻碍。潜在观察者的数量在KERI中不受约束，并有助于环境可验证性。这可能会使攻击成功的DDOS攻击变得非常昂贵。
安全考虑
如前一节所述，该算法假设有一个正常响应的控制器。缺乏响应主要是对控制器的威胁，而不是对validator的威胁（感觉对validator也有威胁啊？）。因此，提供足够的控制器响应是控制器的责任，而不是算法的责任。相比之下，响应灵敏但不诚实的控制器可能会对validator构成实时威胁（live threats），因为validator之前从未看到过新事件。该算法必须为validator提供保护自己免受此类威胁的方法。当控制器可以响应但不诚实时，它可能会创建不一致的事件版本，这些版本首先被不同的目击者子集所看到。在这种情况下，尽管控制者不诚实，但只有F个证人是故障的，validator可以通过要求充分的协议（sufficient agreement）或可问责的双工阈值($M_V$)来保护自己，这保证要么只有一个满足条件的协议，要么根本没有，也就是使服务免疫。重申一下，validator可以选择$M_V$以确保服务不受影响，这样服务要么提供且仅提供一个适当的（proper）密钥事件接收日志(KERL)，要么根本不提供。这保护了validator。
对validator的更大威胁可能是不诚实的控制器，而是与控制器其见证人串通，以颁布替代事件版本协议（alternative event version agreement），每个协议都具有足够的一致性(sufficient agreement)。但是这将违反最多 F 个故障见证人的假设。在这种情况下，证人共识过程，即算法，可能不会保护validator。保护机制来源于validator控制下的其他进程。在这种情况下，validator可以通过一组观察者（validator、观察者、陪审员、法官）进行双工检测来保护自己。在这种情况下，为了不可察觉地发布替代但可负责的事件版本协议，具有不诚实证人的不诚实控制器必须阻止任何validator与可能看到任何替代事件版本协议的任何其他观察者进行通信。如果有足够多的不同的观察者，这种攻击实际上可能是不可行的。一旦检测到双工，该标识符将失去其对任何检测validator的所有值。这将危及任何企图进行此类攻击的不诚实的控制器。
最后一个威胁是dead漏洞利用的威胁，在将来的某个时候，用于签署KERL中过去事件的暴露的密钥对可能会被攻破。然后，被破坏的密钥可用于创建替代的可验证事件历史。但是，请记住，适当的KERL允许在日志中验证关联标识符的控制密钥。一旦产生替代的可验证事件历史，任何保留了副本的观察者(验证者、观察员、陪审员或法官)都可以提供适当的KERL，而不仅仅是证人。控制器密钥的后续破坏和证人的被破坏可能不会使预先存在的适当KERL中的任何事件无效。
因此，为了欺骗validator接受错误的不同密钥事件历史，成功的攻击者必须伪造适当的 KERL，且具有不同的密钥事件序列。为此，攻击者不仅必须利用控制器在某些事件上权威的签名密钥，还必须利用该事件中N个指定证人密钥中的M个密钥。攻击者还必须防止validator从任何其他观察者（validator、观察者、陪审员、陪审员、法官）访问任何其他替代的适当 KERL。这些任务的组合使得这种利用极其难以实现。
因此，假设在极端的情况下，在未来的某个时候，控制器密钥和至少M个证人密钥的dead攻击发生了，以至于他们伪造了一个看似正确但不同的KERL，任何先前适当的KERL的副本都将能够检测和证明该dead攻击的可负责的双工性。在这种情况下，validator可以选择使用其先前副本或来自其信任的陪审员组的先前副本来确定哪一个KERL是权威的。这类似于证书透明度的工作原理[70;95;97]。为了使这种dead攻击成功，攻击者必须阻止目标validator访问备用KERL的任何其他副本。上面提到的环境可验证性的概念来自这样一个事实，即原始KERL可以分布在任意数量的监视器中，validator可以从中获得副本。在某种程度上，原始副本的可访问性基本上变得无处不在，此时可验证性可能被认为是环境（ambient）。给定环境可验证性（ambient verifiability），那么双工检测也同样变得环境（ambient）。详细地说，成功的dead攻击需要将validator与KERL的环境源隔离开来。一般来说，与环境源隔离的成本可能高得令人望而却步。因此，环境可验证性在攻击者和防御者之间提供了有利于防御者的不对称。事实上，这个自主身份系统的最终目标是实现环境安全性，即几乎任何人，任何地点，任何时间都可以成为可验证身份的可验证控制器，该身份受环境可验证性保护，因此可以检测相关KERL的双工性。
此外，validator和控制器之间的任何相互交互事件都可以提供优先级证明。在相互交互中，validator将控制器源的交互事件的副本或摘要包含在验证器源的事件中。控制器和所有见证人的完全妥协将无法在相互交互事件上伪造validator的签名。因此，即使在控制器及其所有见证人的完整的dead攻击的情况下，也可以使用任何相互交互事件的存在来证明优先级（这段没咋理解？啥是优先级？？我的理解是有两个不同的KERL，哪个更值得相信）。
或者，在完全dead攻击的情况下，validator和控制器可以共同同意使用其他一些更正式的机制来解决不同KERLs的优先级。这可能是一组相互信任的观察者最初收到收据的时间的中间值。或者，这可能是通过在分布式共识分类账上使用锚交易来实现的。后一种方法只需要最小限度地使用分布式共识分类账，以解决最极端和最不可能的完全dead攻击情况（指的是控制器与证人完全沦陷）（这一段也没太理解）。
最后，尽管不太可能，量子计算等密码攻击机制的后续改进可能在未来某个时间完全破坏所有暴露的密钥对。一种解决方案是市场运行一组受信任的陪审员，这些陪审员在未来的总沦陷的情况下存档 KERL。这些受信任的陪审员可以通过后量子密码学来保护他们的档案。因此，任何后量子攻击都可以通过诉诸这些档案中的一个或多个来检测。
事件语义和语法
以下部分将密钥事件的各种选项映射到单个通用语法和相关语义。这允许对服务器和客户端进行单一实现，同时又适应功能的特定应用程序调整。一般来说，具有多个签名、见证和交互数据有效负载的间接模式包括最通用的语法和语义集。所有其他变体都是特殊情况。约定缺失的元素都定义了默认值。给定的变体可以省略或留下空，但默认语义提供一致的解释。因此，任何事件的所有语法变体都可以映射到具有定义语义的单个等效通用语法表达式。这使得底层验证和验证逻辑的单一语义实现成为可能。以下部分描述了这些映射。
在形式上，下面定义的事件引用具有绑定到密钥对的标识符的实体。例如，控制器有一个标记为C的标识符前缀，该标识符前缀绑定到一个或多个密钥对，这取决于前缀的派生类型，最终为从$(C^0, c^0)$开始的密钥对序列。同样，validator有一个标记为V的标识符前缀，它绑定到一个或多个密钥对，这取决于前缀的派生类型，从$(V^0, v^0)$开始。一组由下标索引的证人每个都有一个标识符前缀$W_i \mid i=0,1,2, \ldots$，它绑定到一个或多个密钥对，这取决于派生类型，以$(W_i^0, w_i^0)$开头。有时候，绑定到密钥对的标识符可以简单地用非上标符号表示，例如，$C = C^0$，$V = V^0$和$W = W^0$。
在下面的事件描述中，索引 k 索引任何 ilk 的所有密钥事件。索引 l 索引从由 k 索引的序列中的建立（初始和旋转）事件的子序列。这意味着一般来说，第 k 个事件可能与第 l 个事件不相同。只有当所有事件都是建立事件时，k = l。初始事件是特殊的，它总是有 k = l = 0。初始事件可以被认为是旋转事件的一个特例。非建立事件可能在建立事件之间交错。
除了初始事件之外，所有事件都包含先前事件的摘要。初始事件没有摘要，因为它是序列中的第一个事件。摘要向后链接事件并使用序列号提供的序列排序。摘要序列和序列号必须对应。
通用初始事件
一般初始事件示意图如图所示：
初始事件的一般符号表达式如下：
其中，$\varepsilon_0^C$是标识符前缀 C 的事件流中的第一个事件，$ν_0^C$ 是协议版本（包括编码），C 是合格标识符前缀，$t_0^C$ 的值为 $t_0^C = 0$ 是该事件的唯一单调递增序列号，icp 是表示初始事件的事件 ilk(事件类型)，$K_0^C$为$L_0^C$个签名者从初始授权密钥对集合$\widehat{C}_0^C$中所需的签名阈值(sith)，其中：$\widehat{C}_0^C=\left[C^0, \ldots, C^{L_0^C-1}\right]_0^C$。
其中$\left[C^0, \ldots, C^{L0^C-1}\right]_0^C$是一组相关的合格公钥，这些公钥包含在前缀C的推导中，$K_0^C$可以是一个数字，或者当使用加权阈值方案时，它可以是一个列表或列表的列表，$\eta_0^C\left(\left\langle K_1^C, \widehat{C}_1^C\right\rangle\right)$是序列化数据$\left\langle K_1^C, \widehat{C}_1^C\right\rangle$的摘要，用于下一组权威密钥阈值与集合。其中$K_1$是下一个阈值，下一个密钥集为：$\widehat{C}_1^C=\left[C^{r_1}, \ldots, C^{r_1+L_1^C-1}\right]_1^C$。$M_0^C$是对事件的证人收据数量的可问责性阈值。而$\widehat{W}_0^C=\left[W_0^C, \ldots, W{N0^C-1}^C\right]_0^C$，它是总证人集$N_0^C$的子集，它是指定证人的标识符前缀的列表。[cnfg]是一个可选的初始配置数据元素，表示为有序映射的有序列表，根据序列化编码，它可以表示为(label,value)的有序列表，该列表提供派生出标识符C时使用的任何额外确认数据。例如，当[cnfg]的元素包含映射(“trait”， “EstOnly”)时，则在密钥事件流中只允许建立事件，这可以提供增强的安全性，最后，$\widehat{\boldsymbol{\sigma}}_0^C$是每个数字签名的集合，即：$\hat{\boldsymbol{\sigma}}_0^C=\sigma{C^{s0}} \ldots \sigma{C^{s_0^C-1}}$。
从某种意义上说，初始操作可以看作是旋转的一种特殊情况，即第0次旋转。初始化操作将子序列$\widehat{C}_1^C$预先旋转为随后的一组密钥对。初始事件通过一组签名$\widehat{\sigma}_0^C$来表示对标识符前缀C的控制，这些签名$\widehat{\sigma}_0^C$必须满足签名阈值$K_0^C$。
作为一个澄清的例子，假设初始事件是多重签名，即$K_0^C = 2, L_0^C = 3$。下一组密钥也是3中的2个作为阈值，即$K_1^C = 2, L_1^C = 3$。进一步，假设充分的证人收据为4个中的3个，即$N_0^C = 4,M_0^C = 3$。假设附加的签名来自$C^0$和$C^2$。相应的起始事件可以表示为：
作为澄清示例，假设初始事件是多重签名，即 K0C = 2 和 L0C = 3。下一组键也是 3 的 2，即 K1C = 2 和 L1C = 3 和。此外，假设足够的见证收据总共 4 个中有 3 个，即 N0C = 4 的 M0C = 3。假设附加签名来自 C0 和 C2。相应的初始事件可以表示如下：
其中$\eta_0^C\left(\left\langle 2,\left[C^3, C^4, C^5\right]\right\rangle\right)$是下一个集合阈值和密钥的摘要。
通用轮换事件
一般旋转事件示意图如图：
旋转事件作为建立事件子序列中的第l个事件出现，同时也是标识符前缀C的密钥事件序列中的第k个密钥事件，其一般表达式如下：
式中，$\varepsilonk^C$为标识符前缀C的事件流中的第k个事件，也是建立事件子序列中的第l个事件，$v_k^C$为协议版本(含编码)，C为限定标识符前缀，$t_k^C=k$为该事件唯一的单调递增序号，$\eta_k^C\left(\varepsilon{k-1}^C\right)$为前一个事件的摘要。rot为代表轮换事件的类型，$Kl^C$为当前授权密钥集的签名阈值，$\widehat{C}_l^C$则是当前密钥集，有：$\widehat{C}_l^C=\left[C^{r_l^C}, \ldots, C^{r_l^C+L_l^C-1}\right]_l^C$，其一共有$L_l^C$个签名者，每个签名者有一个密钥。其中，$r_l^C$是第l轮控制密钥对子序列的起始索引，$K_l^C$可以是一个数字，或者当使用加权阈值方案时，它可以是一个列表(参见第15节)，$\eta_l^C\left(\left\langle K{l+1}^C, \widehat{C}{l+1}^C\right\rangle\right)$是序列化数据的摘要，$\left\langle K{l+1}^C, \hat{C}{l+1}^C\right\rangle$表示下一组权威阈值和密钥，其中$K{l+1}^C$是下一组权威密钥对的$L{l+1}^C$个签名者所需的阈值，其密钥为：$\widehat{C}{l+1}^C=\left[C^{r{l+1}^C}, \ldots, C^{r{l+1}^C+L{l+1}^C-1}\right]{l+1}^C$。
其中，$r{l+1}^C$是第l+1次旋转的控制密钥对子序列的起始索引，$M_l^C$是事件的证人收据$N_l^C$总数中可问责的阈值，$\widehat{X}_l^C$是要从证人列表中删除$O_l^C$个证人的第l个删除列表，有：$\widehat{X}_l^C=\left[X_0^C, \ldots, X{Ol^C-1}^C\right]_l^C$。其中$\left[X_0^C, \ldots, X{Ol^C-1}^C\right]_l^C$是合格公钥的相关列表的集合。$\widehat{Y}_l^C$是新增证人的列表，集合为：$\widehat{Y}_l^C=\left[Y_0^C, \ldots, Y{P_l^C-1}^C\right]_l^C$。
[seal]是一个数组的零个或多个印章，每个印章都是有序映射，根据序列化编码可以表示为(label,value)的列表，可用于锚定交互事件数据或一个委托，最后，$\widehat{\boldsymbol{\sigma}}_{k l}^C$是第k个事件的签名，其对应的建立事件序号为l，使用的密钥集为$\widehat{C}_l^C$。
作为一个明确的示例，让我们重用上面的初始事件示例：
下一组键被提交到摘要中，$\eta_0^C\left(\left\langle 2,\left[C^3, C^4, C^5\right]\right\rangle\right)$，之后是旋转事件，
其中$\eta_l^C\left(\left\langle 2,\left[C^6, C^7, C^8\right]\right\rangle\right)$是下一组密钥的摘要。起始事件$\mathcal{E}_0$总是意味着$K_0 = 1, L_0 = 1, r_0 = 0$。假设初始事件初始密钥集有3个密钥，那么有$r_1 = 3$。初始事件还声明$K_1 = 2$，下一个密钥列表的长度为$L_1 = 3$。旋转事件$\mathcal{E}_1$声明当前的密钥集为$[C^3, C^4, C^5]$。旋转事件声明$K^2 = 2$，下一个密钥列表的长度为$L_2 = 3$。tally仍然是3。它删除一个证人，其公钥为$X_0 = W_1$，添加一个证人，其公钥为$Y_0 = W_4$，总共有4个证人。
通用交互事件
交互事件可能以三种不同的方式传达。这三种方式为：不同的交互事件消息、作为扩展轮换事件消息中的有效负载，以及不同的委托事件消息。有效负载可以表示单个交互或事务、一个交互块或一个交互块哈希树的默克尔根，从而锚定到交互事件位置的事件序列[104]。
一般交互事件示意图如图：
通用交互事件的一般表达式如下：
$\mathcal{\varepsilon}k^C$是事件流的第k个事件，其标识符前缀为C，其对应的最近的建立事件序号为l。$ν_k^C$是协议版本(包括编码)，C是合格的标识符前缀，$t_k^C=k$是这个事件的独特的单调递增序列号，$\eta_k^C\left(\varepsilon{k-1}^C\right)$是上一个事件的摘要。ixn代表这是一个交互事件，[seals]是一组一个或多个印章，每个印章提供了一个加密的承诺，承诺与该事件传达的实际交互相关的数据的细节。当前密钥集$\widehat{C}_l^C$，大小为$L_l^C$，密钥集细节如下：$\widehat{C}_l^C=\left[C^{r_l^C}, \ldots, C^{r_l^C+L_l^C-1}\right]_l^C$。
委托
本节定义了用于管理不同签名密钥集的委托起始和轮换操作。示例显示了支持的一个级别的委托。这些可以递归地扩展以支持多级委托。控制密钥用于建立(初始化和旋转)其他密钥的事件流，其他密钥的事件流可以进行签名。在这些定义中，标识符前缀标签是C代delegator，D代表delegate。两个密钥事件序列(一个用于delegator，另一个用于delegate)中的事件索引使用各自的前缀进行标记。回想一下，可以在委托密钥事件序列中使用委托交互事件或委托扩展旋转事件执行委托。相关的委托事件示意图如下:
与委托相关的事件包括所谓的委托印章。一对印章交叉锚定delegating和delegated事件对。印章的格式如下图所示：
delegated事件密封摘要是在完整的序列化delegated事件上计算的。delegating事件位置密封指示delegating事件的唯一位置。
初始事件委托
初始化的委托是通过delegator事件序列中的delegating事件来执行的。在delegating事件中，它的[seals]元素的值是一个由一个或多个委托印章组成的数组，每个印章是一个有序的映射数据结构，根据序列化编码，它可以表示为(label, value)对的列表，即seal $=\widehat{\Delta}_0^D$，其中$\widehat{\Delta}_0^D$称为delegator的初始delegating印章，它在委托事件流中委托事件0。这可以表示如下：
式中$\widehat{\Delta}_0^D$将D的第0个事件中的起始事件委托给C中出现的事件，$t_0^D$为delegated的起始事件的序号，即0，$\eta_k^C\left(\varepsilon_0^D\right)$为D的起始(第0个)事件的摘要，其中D的起始事件出现在C的第k个事件中。
delegated初始事件
D的密钥事件序列中的相关初始事件可以表示如下：
其中$\mathcal{E}0^D$为D的事件流中的第0个事件，$v_0^D$为起始事件的版本，D为标识符前缀，$t_0^D$为序列号，dip为委托起始的事件类型，$K_0^D$为委托授权密钥对集合中$L_0^D$个签名者所需的阈值，密钥对为$\hat{D}_0^D=\left[D^0, \ldots, D^{L_0^D-1}\right]_0^D$。$K_0^D$可以是一个数字，或者当使用加权阈值方案时，它可以是一个列表(见第15节)，$M_0^D$是对事件的证人收据数量的问责阈值，$\widehat{W}_0^D$是表示的证人列表：$\widehat{W}_0^C=\left[W_0^C, \ldots, W{N_0^C-1}^C\right]_0^C$。
[cnfg]是配置特征或选项的列表字符串，每个配置字符串的值必须唯一，最后，$\widehat{\Delta}_k^C$是delegate的初始delegated印章，它将C的第k个事件引用为delegating事件。$\widehat{\Delta}_k^C从C的第k个密钥事件中引用了D的delegating起始，可以表示为：
其中C是合格的前缀委托事件流，换句话说C指的delegator，$tk^C$是C的第k个事件的序列号，ilk是delegator的第k个事件类型(ixn或rot)，$\eta_k^C\left(\varepsilon{k-1}^C\right)$是delegator的第k-1个事件的摘要，$\widehat{\boldsymbol{\sigma}}_0^D$是一组数字签名。
delegated初始事件示意图如图所示：
轮换委托
旋转委托是通过扩展的旋转事件(即delegating事件)执行的。在delegating事件中，它的[seals]元素的值是由一个或多个委托印章组成的数组，每个印章是一个有序的映射数据结构，这取决于序列化编码，它可以表示为(label, value)的列表，即seal $=\widehat{\Delta}_k^D$，其中$\widehat{\Delta}_k^D$称为delegator的旋转委托印章，它委托D中的第k个事件，可以表示如下：
式中$\widehat{\Delta}_k^D$将D的第k个事件中的轮转事件委托给C中出现的事件（这里翻译可能不准确），$t_k^D$为delegated的轮转事件的序号，$\eta_k^C\left(\varepsilon_k^D\right)$为D的轮换事件的摘要，其中D的起始事件出现在C的第k个事件中，两个k可能不同。
delegated轮换事件
D的密钥事件序列中的对应的旋转事件可以表示如下：
其中$\varepsilonk^D$为D事件流中的第k个事件，$v_k^D$为旋转事件的版本，D为标识符前缀，$t_k^D$为序列号，$\eta_k^D\left(\varepsilon{k-1}^D\right)$为序列中第k−1个密钥事件的摘要，drt为delegated轮换事件的事件类型，$K_l^D$为授权密钥对的第l个委托集合中$L_l^D$签名者所需的阈值，其密钥集为：$\widehat{D}_l^D=\left[D^{r_l^D}, \ldots, D^{r_l^D+L_l^D-1}\right]_l^D$。
其中，$Kl^D$ 可能是数字，或使用加权阈值方案时，它可以是列表（参见第 15 节）。$M_l^D$ 是对见证收据次数的问责阈值，$\widehat{X}_l^D$是第 l 个证人删除列表，为：$\widehat{X}_l^D=\left[X_0^D, \ldots, X{O_l^D-1}^D\right]_l^D$。$\widehat{Y}_l^D$是添加证人列表。
[seals] 是一个印章列表。最后，$\widehat{\Delta}_k^C$是delegate的旋转delegated印章，指的是 C 的第 k 个事件作为delegating事件。$\widehat{\Delta}_k^C$可以表示如下：
其中C是合格的前缀delegating事件流，换句话说C指的delegator，$t_k^C$指的是序列号，ilk指的是delegator的第k个事件的类型(ixn或rot)，其他都与之前的差不多，就不重复说了。
delegated轮换事件示意图如下所示：
delegated交互事件
委托交互事件与非委托通用交互事件差不多，不同之处在于标识符前缀属于delegated事件序列。令 D 为delegated标识符前缀的标签。delegated通用交互事件的一般表达式如下：
其中元素定义如下。此事件如下：
生成委托事件的算法
考虑到在一对委托事件(delegating和delegated)之间使用委托印章的交叉锚定过程的复杂性，为了清晰起见，下面提供了生成委托事件的步骤的描述。
（1）创建部分delegating事件，可能是交互或是旋转。
（2）填充事件头中的前缀、sn、ilk 和摘要字段。
（3）使用上面delegating事件的头部的委托前缀sn、ilk和摘要字段创建一个delegating事件位置印章。
（4）创建一个完整的delegated事件，将其印章字段设置为上面创建的位置印章。
（5）计算序列化delegated事件的摘要。
（6）使用delegated前缀 sn 创建委托事件的delegated事件印章，并计算完整delegated事件的摘要。
（7）将delegated事件印章添加到delegating事件的数据字段列表 (seals)。
（8）对任何其他delegated事件重复步骤 4 到 7。
（9）完成delegating事件的创建。
事件收据消息
事件收据消息的结构取决于收据的签名者是否使用可转移或不可转移的标识符前缀。由于见证人和观看者使用非可转移的前缀，因此可以从他们的前缀中提取验证其收据签名的公钥。这简化了收据。这也适用于使用不可转移前缀的validator。在具有不可转移前缀的validator的情况下，需要不同的事件收据消息。
不可转移前缀的事件收据消息
一般来说，当使用不可转移的标识符前缀时，validator收据、证人收据或观看者收据都具有相同的格式，唯一的区别是创建收据的各自实体的标识符前缀。因此，所有实体都可以使用相同格式的收据消息。此外，见证人或观看者之间的通信可能受益于批量发送给定事件的多个收据（最耗时批处理发送，这样有利于通信）。批量收据可以通过收据消息更有效地传输，该收据消息允许给定事件的多个前缀和签名，而不是为相同的事件发送多个消息。此外，多收据消息只需要比单个收据版本稍微冗长一些，因此当只有一个收据时，它也可用。因此我们只需要实现一个多收据版本。
由于派生码允许解析连接的标识符前缀和签名，因此紧凑的多收据消息可以使用多个附加的数据格式，每个数据格式都有一个见证标识符和一个签名。这些数据格式的序列可以按照标识事件收据消息的先后来排列。下图说明了该格式。
因为控制器有事件消息的副本，所以由见证创建的紧凑收据消息不需要包括事件消息的副本，而可以只包括协议版本、控制器的标识符前缀、事件类型、见证的标识符和见证的签名。标识符前缀C的压缩流多收据消息可以表示为：
$\rho{\tilde{W}{l s}^C}^C\left(\varepsilonk^C\right)$是事件$\mathcal{E}_k^C$的多收据，$ν_k^C$是协议版本，C是控制器的标识符，$t_k^C$是事件$\mathcal{E}_k^C$的序列号，rct是代表事件收据的事件类型，$\eta_k^C\left(\varepsilon_k^C\right)$是多收据消息对应事件的摘要，$W{l 0}^C \sigma{W{l 0}^C}^C, \ldots, W{l N_s^c-1}^C \sigma{W_{l N_s-1}^C}^C$代表多个证人的签名。l 表示建立事件证人集，s 表示该收据中的证人集。
为了澄清，来自标识符前缀C的见证集(其中l表示该见证集的建立事件，i表示该集合中该见证的索引)的见证$W{l i}^C$可以通过使用其关联的密钥对$\left(W{l i}^C, w{l i}^C\right)$签名来创建事件收据。回顾一下，见证标识符前缀是不可转移的，并且派生自单个密钥对。收据签名可表示如下：$\sigma{W_{l i}^C}^C\left(\left\langle\varepsilon_k^C\right\rangle\right)$。
可转移前缀的事件收据消息
validator V可以通过使用其关联的密钥对签名来创建事件收据。考虑到具有单个密钥的不可转移前缀的简单情况，validator收据与上面的证人收据相同。但是，当validator使用可转移标识符时，收据需要包含validator最近建立事件的印章，以便使用正确的签名密钥集来验证收据签名。validator的标识符前缀可能使用多个密钥，因此需要多个签名。
仅使用单个签名时，来自 V 的对密钥事件$\varepsilon_k^C$的收据签名可以表示如下：
其中$\mathcal{E}k^C$是事件。特定的事件细节取决于事件本身。当validator使用多重签名方案时，将需要一组签名。该集合可以表示如下：$\widehat{\sigma}{V_l}^C$。
因为控制器有事件消息的副本，由validator创建的压缩收据消息不需要包括事件消息的副本，而是只包括协议版本、控制器的标识符前缀、事件类型vrc、事件摘要、validator的最近建立事件的事件印章和validator的签名。这样一个紧凑的事件收据信息$\rho_V^C\left(\varepsilon_k^C\right)$可以表示如下：
式中$\rho_V^C\left(\varepsilon_k^C\right)$为事件$\varepsilon_k^C$的收据，$\widehat{\Delta}_k^V$为validator最近一次建立事件的事件印章，表示如下：$\widehat{\Delta}_k^V=\left{V, \eta_k^V\left(\varepsilon_k^V\right)\right}$。
其中，V是validator的标识符前缀，$\eta_k^V\left(\varepsilon_k^V\right)$是validator最近的建立事件摘要。
实施
状态验证引擎
使用上面为三种事件类型(即初始、旋转和交互)提供的通用表示，可以制定通用状态验证算法或引擎。这将成为KERI验证器的核心，并可移植到所有应用程序中。状态验证器引擎维护当前已验证的状态。状态引擎处理事件流中的事件，并根据当前状态和经过验证的事件消息将状态从当前状态更新到下一个状态。处理主要是签名验证。该状态维护指定见证人列表，但不对事件收据数量进行任何验证。证人、观察者、法官、陪审员或validator应用程序将包括KERI状态引擎，以提供事件消息验证。控制器应用程序还使用一个状态生成器引擎来维护其状态副本，该引擎不是基于外部事件更新状态，而是基于内部生成的事件更新状态。KERI事件消息状态验证或状态引擎的示意图如下所示：
delegated状态验证引擎
delegated密钥事件流具有略有不同的验证引擎。它包括委托数据，需要验证delegator的delegating事件。其示意图如图所示：
实施选择
由于KERI被设计为与事件流应用程序兼容，因此其设计适合于具有紧凑和高效语法的简单状态验证引擎。此外，KERI 具有高级密钥管理功能。KERI提供了可重新配置的阈值多重签名方案，其中每次轮换都可能更改签名的阈值总数。预轮换对未公开的密钥对进行承诺。这允许在不牺牲安全性的情况下进行可重构。这些高级密钥管理特性本身就使KERI在可伸缩性和性能不那么重要的非数据流应用程序中也是可取的。同样，由于其他原因，许多应用程序需要分布式共识分类账。在这种情况下，最好的方法可能是使用KERI，但没有证人，并利用分布式共识节点提供的信任。像以太坊这样的智能合约系统(公共或私有)有能力支持链上KERI核心状态验证引擎的语义。或者，KERI可以作为一个侧状态通道实现，其中有一个Judge或Validator定期将当前状态锚定到分布式账本(如以太坊或比特币)上。这种侧通道方法将适用于大多数分布式账本。
作为一个具体的比较，考虑其他基于智能合约的系统，如使用ERC-1056标准创建的标识符[60;62]或使用以太坊上的Gnosis多签名钱包控制令牌化资产[106]。两者都容易受到通过被攻破的签名密钥对来失去安全性。在ERC-1056的情况下，只需要利用一个密钥对或多签名的阈值数量的密钥对。Gnosis 多签名钱包是一个智能合约，具有多个签名的高级功能。它允许更改阈值和签名数量，以及撤销和替换签名。从这个意义上说，它与KERI引擎的复杂性相当。然而，Gnosis 多签名钱包的关键限制是，暴露的签名密钥对数量达到阈值的攻击者可能会永久捕获钱包。而KERI的预轮换方案对未公开的密钥对进行承诺，这些密钥对可能不会通过利用任何公开的签名密钥对而被暴露。这意味着可以通过执行旋转来重新恢复密钥，而不是使用Gnosis多签名钱包。虽然Gnosis 多签名钱包具有ERC-1056所不具备的多重签名优势，但两者都没有从KERI的安全性中受益。
非分布式共识账本可从KERI的事件流设计中受益。一个示例实现目标可能是Apache Kafka[12]或Apache Flink[11]。Apache Kafka和Flink都为数据密集型应用程序构建可扩展的事件处理流提供了库。功能和语义可能有所不同。尽管如此，KERI核心状态验证引擎可以作为Kafka流应用程序或Flink过程函数来实现。这允许将KERI见证器和validator实现为Kafka或Flink流。KERI 法官的证人收据验证功能也可以作为Kafka或Flink流实现。因此，整个KERI DKMI可以托管在可扩展的Kafka或Flink集群上。类似地，KERI可以使用基于异步流的处理框架(如Ioflo[122])轻松实现。
派生码
如前所述，派生码的目的是对提取和验证标识符前缀中的加密材料所需的派生信息进行紧凑编码。通过在前缀中包含派生代码，我们以加密方式将派生方式绑定到标识符前缀。不同的派生方式产生不同的标识符。加密材料使用Base64-URLSafe[87]编码。Base64编码使用0、1或2个填充字符来消除编码的加密材料的二进制和BASE64长度的差异。前缀编码通过用适当长度的派生代码替换填充字符来利用它们。许多相关的加密材料格式的长度为32字节，编码为44个Base64字符，包括1个填充字符。在这种情况下，用一个字符派生代码替换填充字符可提供派生信息。同样，包含2个pad字符的Base64编码加密材料使用两个字符派生代码，这是长度为64字节的加密材料的情况。在极少数情况下，加密材料的长度导致0个填充字符(可被3整除)，此时则使用4个字符的派生代码。
如前所述，为了正确地提取和使用嵌入在自认证标识符中的公钥，我们需要知道围绕相关密钥对和其他配置材料的派生过程。这包括密码套件和操作。一般来说，这提供了用于派生自认证标识符的过程。因为需要这个派生信息来正确解析编码的公钥，而且惯例是从左到右解析，所以我们通过在派生码前面加上派生字符，然后从末尾删除填充字符来替换填充字符。因为字符串是有效的Base-64，它可以在使用二进制操作解析之前被转换为二进制，也可以在转换之前被解析。如果在转换之前进行解析，则必须从字符串的前面提取派生代码字符。第一个字符告诉如何解析剩下的字符(如果有的话)。在将组成编码公钥的其余字符转换回二进制之前，必须重新添加相应数量的填充字符。一旦转换，公钥的二进制版本就可以用于加密操作。下表提供了KERI的建议派生代码集。每个字符长度为1、2或4个字符，分别替换1、2或0个填充字符。这确保了每个自包含的标识符字符串都符合Base-64规范，该规范必须是4个Base-64字符的倍数。
有两种类型的派生码。第一类对与标识符前缀和密钥事件相关的元素的加密材料进行编码。第二类只编码附加的签名。
作为第一类的示例，假设加密材料是Ed25519公钥，用于基本自认证标识符的派生。Ed25519公钥长度为32字节。这将编码为44个Base64字符，其中包括1个填充字符。这就需要1个字符的派生代码。在1个字符派生表中有派生代码B。将包含填充字符的Base64编码的公钥表示如下：
DKrJxkcR9m5u1xs33F5pxRJP6T7hJEbhpHrUtlDdhh0=
那么带派生前缀的编码如下：
BDKrJxkcR9m5u1xs33F5pxRJP6T7hJEbhpHrUtlDdhh0
密码材料派生码
对于加密材料，1个字符派生表中的前12个条目是选择字符，这提供了对1、2和4个字符派生码的支持，以及将来对更长的代码解析的可扩展性。下面提供了相关表中一些条目的建议值。
密码材料派代码表
附加签名派生码
附加签名派生码的主要区别在于：派生代码包括一个索引或偏移量，到当前签名公钥列表中。这提供了一种自包含的方法，将签名与验证签名所需的公钥进行匹配（如何理解？）。这意味着附加的签名派生代码的最小长度是2个字符，第一个字符用于签名方案，第二个字符用于索引。一个Base64字符最多可以编码64个值(0-63)。因此，使用该方案最多可能有64个附加签名。在极不可能的情况下，超过64个附加签名，那么可以使用更长的派生代码。最常用的ECC签名方案使用64字节长度的密钥进行签名，转换为Base64后，有两个填充字符。这对于包含一个索引字符的两个字符派生代码来说是完美的。其他签名方案可能具有具有不同填充字节数的签名，因此需要不同的派生代码表。保留一些字符作为选择器代码以选择适当的表。
KERI的一个理想特性是它与传输协议无关。互联网协议主要有两种类型。这些是有帧的和无帧的(流)。在有帧协议中，每个数据包都有一个已知的边界。这意味着只要序列化事件都适合一个最大大小的数据包帧，就可以后跟任意数量的附加签名（如何理解？？）。解析附加的签名可以一直进行，直到到达帧的末尾。数据包解析器不需要事先知道附加签名的数量，因为一旦到达帧的末尾，它就会发现已经结束了。另一方面，在无帧协议中，没有定义良好的数据包边界，因此解析器不知道何时停止对附加签名的解析，并开始对下一个序列化事件进行解析。在这种情况下，显示在事件之后但在附加签名之前出现的附加签名的计数将会很有帮助。这个特性使得KERI协议与分帧无关。在两个主要的底层Internet协议中，UDP是帧协议，TCP是无帧协议。而HTTP向TCP添加帧，RTSP从UDP删除帧。KERI通过一个特殊的附加签名代码提供这种帧功能，该代码仅提供附加签名的计数。KERI还期望使用允许操作码或操作码表的特殊代码进行更复杂的附加签名处理。下面提供了相关表中一些条目。
附加签名派生代码表
加权门限多签名方案
本工作提出的阈值多重签名方案可以通过将阈值数(整数)更改为分数值列表以支持分数加权阈值。在单个列表的简单情况下，列表中的每个值都在0到1之间。在分数加权方案中，有效签名集是相应权重之和大于等于1的签名的任意子集。例如，对于以下有序签名者列表的阈值签名方案：
如果3个签名中的任意2个是有效的，则可以等价地表示为以下有序的分数权重列表：
其中两个或两个以上权重的任何组合之和至少为1。概括地说，令第l个控制签名者的有序集表示如下：
其中$\widehat{C}_l$表示第l个列表，$L_l$是列表中签名者的数量，列表中的每个$C_l^j$都是签名密钥对中的公钥。相应的权重列表可表示为：
其中$K_l$表示第l个列表，$L_l$为列表中权重的个数，列表中的每个$U_l^j$为对应签名者的权重。每个权值满足：
完整签名列表的一个子集可能附加到某个事件。假设为第k个事件。这个子集可以用一组基于零的索引(偏移量)来表示，索引列表可以表示为：
其中$\widehat{S}_k^l$表示附加到第k个事件的第l个签名者列表中的偏移量的有序索引列表，$S_k^l$是附加的签名者的数量，每个$s_i$是到$\widehat{C}_l$的基于零的偏移量。当相关权重之和大于等于1时，一组签名有效，例如：
其中$\bar{U}l$表示总和，总和中的i被赋值给偏移量列表中的连续值。$\widehat{S}_k^l=\left[S_0, \ldots, S{S_k^l-1}\right]_k^l$，若有$i \in \widehat{s}_k^l$，$U_l^i$是偏移量i处的权重。在使用浮点表示来解释总和中的浮点舍入误差时，必须小心（如何理解？）。避免这个问题的一种方法是使用有理数计算。一些编程库，如Python中的fractions模块，支持显式有理数计算。
在其最简单的形式中，如上面的例子所示，可以使该加权阈值方案等效于平凡的K阈值方案，方法如下：
其中$K_l$是传统K阈值方案中签名的阈值计数。然而，加权阈值方案的真正威力是通过不相等的权重来实现的。这允许签名者的不同组合达到一个有效的签名集。
例如，假设第 l 个权重列表如下：
在这种情况下，当前两个签名者都签名时，或者当前两个签名者中的任何一个签名者和后四个签名者中的任何两个或多个签名者签名时，或者当最后四个签名者中的所有四个签名者签名时，都会出现有效的签名集。这允许为签名者分配不同程度的签名强度或签名权限，以反映对签名者的不同信任程度。这允许分配基于角色的签名权限和分层权限。实际上，在上面的示例中，前两个签名者拥有与后四个签名者相同的权限。前两名可以是高层管理人员，后四名是低层管理人员。
这种方法可以进一步扩展，以支持多个分数加权阈值的满足真值的更复杂的逻辑与组合。在这种情况下，阈值表示为一个权重列表的列表，其中列表中的每个权重列表必须满足阈值1，其满足真值才被认为是真值，否则为假值。每个加权列表中的一个真值，通过逻辑与操作，以确定总体阈值的真值。例如，假设权重列表的复杂列表如下：
序列化
回想一下，每个事件都包含一个协议版本代码字符串。协议版本代码还包括用于对关联事件进行编码的序列化编码(如JSON、MessagePack、CBOR等)。这允许解析器确定如何解析消息。
序列化有两种方式。第1个是完整事件的序列化，第2个是从完整事件中提取的一组元素的序列化。前者的元素不需要有任何规范的顺序。后者的元素必须符合规范顺序，以便可以从完整事件中复制提取集合的摘要或签名（如何理解？为什么必须符合规范？）。
提取元素的规范形式
提供提取元素的数据结构必须具有规范的顺序，以便可以在事件的元素摘要中提取它。在不同类型的序列化编码中通用的提取元素的规范形式是所有值的串联。连接的顺序是按给定顺序对元素进行深度优先遍历（没理解？现在理解是，序列化是从左到右一点点序列化的）。
提取出的集合内容如下：
（1）用于派生自寻址前缀摘要的初始事件元素。
（2）用于派生自签名前缀签名的初始事件元素。
（3）用于导出具有阈值的下一个密钥集的摘要的事件元素
（4）用于导出委托前缀初始事件的印章的摘要的事件元素。
（5）印章元素。
序列化算法
KERI需要两种序列化算法。第一种是完整事件的序列化。第二种是从完整事件中提取的数据集的序列化。
在KERI中，为了创建每个事件的加密签名，需要序列化完整的密钥事件。为了创建每个事件的加密摘要，还需要对完整事件进行序列化。完整事件以签名序列化的形式在网络上传播。在网络传播之后，还需要对完整的事件进行反序列化，以便最终的反序列化保留事件中数据元素的语义结构。由于事件中的加密材料可能具有可变长度，因此固定字段长度的序列化不是可行的方法。因此，KERI必须支持可变长度字段序列化。此外，支持任意嵌套自描述数据结构的序列化编码为事件组合提供了未来的验证。值得注意的是，JSON、CBOR和MsgPack是众所周知的广受支持的序列化编码，它们支持任意嵌套的自描述数据结构。JSON是一种人类可读的ascii文本编码，虽然有些冗长，但通常用于web应用程序。另一方面，CBOR和MsgPack都是更加紧凑的二进制编码。支持所有三种编码(可能还有其他编码)将满足广泛的应用程序、传输和资源限制。重要的是，因为只有关联标识符前缀的控制器才能组成KERI事件，所以事件序列化中元素的顺序可能完全由该控制器决定。其他实体可以签署控制器提供的事件序列化，但不需要提供它们自己的序列化。
在KERI协议中，从完整KERI密钥事件中提取的数据元素的指定子集创建加密摘要和签名。因此，这些提取的数据集也需要序列化。然而，重要的是，提取的数据集序列化不需要在网络上传播。这意味着序列化不需要保留数据的语义结构。这使得提取的数据序列化编码得以简化。但是，提取数据的这些摘要需要能够被任何其他实体再现。这意味着必须精确指定序列化中数据元素的顺序。
总之，完整事件序列化的必要约束是支持具有可变长度字段的任意数据结构，这些字段可以多种格式进行序列化和反序列化，可再现的排序不是必要的约束。提取的数据元素集的必要约束是可再现的排序，但不需要反序列化。
相关代码库的开发和维护的便利性是有益的约束。考虑过但被拒绝的一种可能性是，对完整的事件序列化和提取的数据集序列化使用相同的序列化（使用相同序列化编码是有问题的）。这种方法的问题在于，在逐个事件的基础上，序列化编码可能会发生变化，也就是说，一个事件可能使用JSON编码，而另一个事件可能使用COBR编码。这将需要跟踪事件上使用的编码，以便再现地执行提取的数据序列化。更有问题的是，对于委托事件，一个事件中包含的提取数据集摘要可能来自从属于不同标识符的事件提取的数据。在这种情况下，跟踪编码带来了不便，它消除了对事件和提取的数据集使用相同编码的优点。在此基础上，可以使用简化但可重复的编码算法对提取的数据集进行序列化。简化是因为提取的数据集不需要反序列化。
提取数据集序列化的一个约束是元素的顺序必须精确指定。简化该规范的一种方法是在完整的事件序列化中使用数据元素的排序。但这意味着对整个事件序列化施加了排序约束。这样做的好处是，排序只对每个事件表示一次，而不是对每个提取的数据集表示一次。这更好地证明了协议，因为总是只有一个地方可以排序，那就是完整的事件元素排序。
对完整事件序列化进行排序的另一个好处是，通过要求序列化中的第一个元素是版本字符串元素，可以简化对事件中使用的序列化编码的自动自包含发现。然后，反序列化器可以通过检查任何序列化事件的前几个字节来明确地确定编码。这样可以更好地支持更广泛的传输协议和数据库。
直到最近，Javascript中的原生JSON序列化库还没有从映射 (Javascript的对象)数据结构中保留元素的逻辑顺序。唯一可能的排序方式是按字典顺序，按标签对映射中的字段进行排序。这意味着不可能对映射字段进行任意的逻辑排序，也不能对基于字段出现顺序的序列化施加任何语义意义。可以通过对字段名施加字典约束来近似地排序，但这会使字段名的可用性降低。有序映射通过保留映射中字段的创建顺序来支持逻辑排序。可以通过更改映射中字段的创建顺序来施加任意顺序。
幸运的是，Javascript ES6 (ES2015)及以后版本现在提供了一种机制，可以在JSON.stringify()序列化中强制改变顺序。最新版本的Javascript现在在序列化时本地保留属性创建顺序。这意味着反序列化将以与序列化相同的顺序自动重新创建属性。
其他语言，如Python、Ruby、Rust等，早就支持原生创建顺序，以保持有序映射的序列化。这些保持字段元素的创建顺序。这与最近的Javascript支持相结合，意味着KERI可以对完整事件数据元素施加排序约束，该约束可用于对完整事件和提取的数据元素集进行规范排序。
事件序列化算法
此算法指定每个事件元素的每个映射中的元素顺序，这包括嵌套元素。使用标准JSON、COBR和MsgPack库的序列化遵循嵌套元素的递归深度优先遍历。
使用JSON、COBR或MsgPack函数进行序列化/反序列化，将完整事件从有序映射序列化/反序列化到有序映射。每种编程语言可能以不同的方式命名函数以进行序列化/反序列化。在JavaScript中，它们是JSON.stringify/JSON.parse。在Python中，它们是json.dumps/json.loads。JSON序列化没有空格。
提取数据集序列化算法
提取的数据集序列化算法使用与关联事件相同的出现顺序序列化每个集合中的元素。嵌套元素使用深度优先遍历进行序列化。序列化在遇到每个元素时追加序列化后的值。每个元素值被序列化为UTF-8编码的字符串。每个实现都必须执行递归深度优先遍历。
JSON编码
用于序列化数据结构或元组的一种流行编码是JSON (JavaScript Object Notation)标准。然而，JSON的历史限制之一是序列化的JavaScript对象的字段顺序不规范，也就是说，JSON对象的有效JSON序列化不能保证反序列化产生的JavaScript对象中字段的出现顺序。此外，JSON序列化中处理空格是不规范的。JSON序列化器处理unicode字符串的方式也存在一些变化。因此，序列化和反序列化在JSON序列化器的所有实现中可能不相同，因此不会针对相同的加密签名进行验证。这就是所谓的规范化问题。有几种方法可以解决这个问题。ES6版本的JavaScript有一个内部方法[[ownPropertyKeys]]，它保留了JavaScript对象属性的创建顺序。这可以用于按照属性创建顺序序列化Javascript对象。大多数JSON序列化器都支持不使用空格的模式。这是最紧凑的JSON编码。因此，ES6或更高版本的JavaScript实现可以使用对象属性创建顺序进行规范化序列化。给定对空格的排序和控制，可以使序列化可重现。在使用JSON时，这个问题的另一个简单解决方案是，与签名关联的数据可能只由签名者序列化一次。数据的用户可以反序列化，但不能重新序列化，除非他们也重新签名。任何兼容的JSON反序列化都将产生一个等效的Javascript对象(相同的字段名称和值，但顺序和空白被忽略)。但是为了确保可重现性，字段顺序和空白都必须受到限制。
后面的并未翻译，感觉不重要。
总结
KERI是一种基于最小充分原则的去中心化密钥管理基础设施(DKMI)。KERI旨在与事件流应用程序兼容，但也可以用于分布式账本系统。事件流设计使其成为一个简单的状态验证引擎。语法紧凑而高效。尽管如此，KERI具有先进的密钥管理功能。主要的密钥管理操作是通过一种新的密钥预旋转方案进行密钥旋转。KERI提供了可重新配置的阈值多重签名方案，其中阈值和签名总数在每次轮换时都可能发生变化。KERI还提供分数加权多重签名方案。预轮换对未公开的密钥对进行承诺。这允许在不牺牲安全性的情况下进行重新配置。KERI还提供了证人大小的可配置指定，其中证人总数可能在轮换中发生变化。对未公开的密钥对的承诺意味着证人配置可能不会通过利用任何公开的密钥对而被撤消。KERI是我们所知道的唯一能够提供这种高级特性组合的具有事件流功能的系统。
KERI还提供了一个委托版本，它支持分层密钥管理，其中主控制器(标识符)密钥事件流可以将签名权限委托给一个或多个从标识符密钥事件流，从而形成一个链状的密钥事件流树。
KERI 可扩展设计支持多种用例。两种主要的信任模式激发了设计，直接（一对一）模式和间接（一对多）模式。在直接模式下，身份控制器通过控制密钥对的验证签名建立控制。间接模式扩展了该信任基础，其主要是证人的密钥事件接收日志 (KERL)。这导致密钥事件接收基础设施的缩写 KERI。间接模式的安全性和问责性保证由 $KA^2CE$提供，用于在一组证人之间建立控制。$KA^2CE$ 方法可能比依赖于总排序分布式共识账本的更复杂的方法更具性能和可扩展性。然而，当其他考虑使其成为最佳选择时，KERI 可能会采用分布式共识账本。换句话说，KERI 可以通过分布式共识分类账来增强，但不是必要的。KERI 适用于数据流、web3.0 和物联网应用中的 DKMI，其中性能和可扩展性很重要。KERI 的核心服务是独立的标识符。这使得 KERI 是一个简单的通用便携式 DKMI。
留言
- 文章链接: https://wd-2711.tech/
- 版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-ND 4.0 许可协议。转载请注明出处!