上一篇文章讨论了如何保护 ETH 2.0 的取款密钥 （withdrawal key） ，并总的介绍了 ETH 2.0 验证者所使用的几个密钥 对 。在阅读本文之前，建议先阅读一下这篇文章。同样地，我们预设读者对验证者有最基本的了解，包括但不限于 “验证者是什么”，“他们为什么需要密钥”，以及 “他们通常需要什么操作” 等概念。
什么是验证者密钥？在 ETH 2.0 中，验证者密钥被用来确定相关消息是哪位验证者发出的 。验证者要发送这些消息才能获得奖励（并避免遭受惩罚）。
验证者密钥的风险很难衡量：验证者密钥本身无法用来访问资产。因此，即使攻击者获得了你的验证者密钥，也无法直接盗取资产。但是，他们可以通过敲诈勒索 1 等方式间接获利，更有甚者，比起自己获利，他们更想让你蒙受损失2。因此，我们通常认为验证者密钥的安全需求很高。
- 图 1 ：验证者的安全需求 -
但是，不像取款密钥那样 （你可以离线保存起来），验证者密钥要能够随取随用 ，因为验证者在每个 epoch （大约 6.5 分钟）都要签署多个消息。因此，验证者密钥的访问需求也很高。
- 图 2 ：验证者密钥的访问需求 -
因此，我们发现自己陷入了两难困境：从传统上来说，同时满足安全性和可访问性需求是很难实现的，因为提高安全性往往会降低可访问性，反之亦然。
- 图 3 ：验证者密钥的双重需求 -
为满足对安全性和可访问性的双重需求，我们需要采取更高级的措施，在不作重大妥协的前提 下，较高程度地满足这两方面的需求。这可以通过分层来实现。本文的目的是探究每一层所提供的功能，并了解哪些功能适用于或不适用于验证者设置。
Eth2 中的密钥对都有一把公钥和一把私钥。出于本文的写作目的，全篇所用的 “key（密钥）” 一词指代的都是通常叫做私钥的那把；如果指代的是公钥，会有明确的说明。
（译者注：validator key 和 withdrawel key 都是密钥对，都分公钥和私钥。公钥是用来在 Eth1 链上注册的，可公开；私钥则是验证者自己实际使用的，不可公开，公开则自己的资产和验证者都完全被他人掌控了。）
目标和分层首先，我们需要定义攻击者和用户的目标。在知道为什么要保护验证者密钥之后，我们就可以思考每个功能可以在多大程度上实现这一目标。首先， 攻击者的目标可以被定义成：
攻击者的目标是，签署某一条消息时能签出与目标验证者公钥相对应的签名（即能伪造验证者对某一条消息的签名）。
当然了，如果这是唯一的目标，那么直接毁掉验证者密钥就能阻止攻击者了。但是，这对用户来说一点帮助也没有。因此，我们需要考虑的第二个目标，也就是用户的目标，可以被定义成：
用户的目标是只签署理想消息，不签署不良消息。
就本文的目标而言，理想消息指的是能够获得奖励的消息，不良消息指的是会触发 罚没事件3的消息。
请注意，攻击者要想实现其目标，只需要签署任意一条消息即可，而用户的目标是持续性的。这种不对称性是安全系统的一大特征，即，攻击者只需赢一次就够了，而用户需要每次都赢。
为此，我们需要一个由不同分层或者说独立功能组成的系统，提供增强型安全性或增强型可访问性，而且可以将二者结合起来，共同达到较高水平。一个良好的安全模型需要具备多个分层，每个分层都会（单独或与其它分层结合起来）提供某种保障或其它分层的备份，并且有足够多的分层提供可访问性，从而确保用户的目标可以实现。请注意，本文聚焦于技术保护：其它层面（例如，操作层面和社会层面）上的安全性都不属于本文的讨论范围内， 虽然它们在任何安全模型中都是至关重要的部分，应该采取相应解决方案。
分层为了探讨验证者密钥的保护方式，我们先来做个简单的演示：
- 图 4 ：验证者密钥 -
与 ETH 2.0 的所有密钥一样，验证者密钥也是一串数字 4。如果验证者在不采取任何保护措施的情况下存储了验证者密钥，攻击者很容易就能获得该密钥并实现其目标。以下几类人能够获得验证者密钥：
-
任何有权访问运行验证者客户端的计算机账号的人
-
任何被授权访问运行验证者客户端的计算机的人
-
任何可以物理访问运行验证者客户端的计算机的人
-
任何有权访问运行验证者客户端的计算机的数据的人（例如，备份数据）
这样一来，用户就无法实现其目标（即，不签署不良消息）。因此，我们首先要通过加密的方式来保护验证者密钥：
- 图 5 ：加密验证者密钥 -
我们可以通过多种方式加密验证者密钥，例如， EIP-2335 标准 5。一旦验证者密钥被加密，除非攻击者掌握加密口令（passphrase） ，否则无法解密出密钥6。这样就可以很好地保护验证者密钥（无论是将它存储在验证者客户端还是数据备份内）。
乍看之下，攻击者似乎无法通过任何方式来实现其目标。然而，用户也没有办法实现其目标，因为他们再也无法签署理想消息：无论是对于用户还是攻击者来说，经过加密的密钥都是没用的，因为用户必须先将该密钥解密，然后才能用它来签署消息。这样一来，验证者进程就一定要包含访问解密口令这一步骤。即然验证者进程可以访问解密口令 ，那么攻击者也可以访问该口令 ，尤其是在解密口令被存储在验证者客户端的情况下，因为验证者客户端有可能遭到攻击。
因此，这种改变本身不算上策。不过，如果我们将它与第二层结合起来，就能提供更有力的保护：
- 图 6 ：远程口令 -
如果解密口令是远程存储的，加密验证者密钥会带来更强大的保护 7。由于口令不再存储于验证者客户端内，攻击者无法从磁盘数据中获得未加密的私钥。攻击者只能发动更加复杂的攻击，例如，从内存中获取解密后的密钥，或模仿验证者客户端进程来获得解密密钥。
虽然攻击难度更大了，但是复杂攻击依然有可能获得验证者密钥。此外，用户依然可能在不经意间签署不良消息。因此，我们可以通过增加一个远程签名器层来为用户提高安全性和可访问性。
- 图 7 ：远程签名器 -
远程签名器分离了验证者客户端的核心功能：确定要放到消息中的数据、签署消息并将该消息发送至 ETH 2.0 网络。第一个和第三个功能仍保留在验证者客户端手中，第二个功能由远程签名器来实现。远程签名器还引入了 罚没保护机制，可以确定哪些是理想消息，哪些是不良消息，并予以签署或拒绝。
如何阻止攻击者将攻击目标从验证者客户端转移到远程签名器呢？首先，签名器可以具备比验证者客户端更高的安全性。验证者客户端需要执行许多任务，包括与 ETH 2.0 网络的其它组成部分（如信标节点）通信。这些通信可以为攻击者提供信息和攻击界面 。由于签名器只与验证者客户端通信，它们的活动受到很多限制，这就为双方的服务器带来了更高的安全性。
其次，远程签名器为用户带来了其它好处。现在，同一个远程签名器可以与多个验证者客户端通信，使得我们能够创建具备高可用性的验证者客户端基础设施。远程签名器确保验证者客户端不会签署任何不良消息。
然而，事实上，远程签名器存在单点故障问题：如果远程签名器遭到攻击，或出现故障，用户就连理想消息也签名不了 。有没有一种方法可以让远程签名器更能抵抗攻击，同时又不会失去上述任一好处？
- 图 8 ：门限签名 -
我们还可以在上述层次的基础上再构建一层门限签名，进一步增强安全性和可访问性。验证者密钥需要用 Shamir 密钥分割流程来处理 ，即，使用验证者私钥生成多个密钥，然后将它们发送给远程签名器 。
