2020 年 12 月 1 日，信标链发布，以太坊由此踏上了向 PoS (权益证明) 共识过渡的征程。虽然用户首次拥有了质押 ETH 的机会，但这个过程中仍然存在一些摩擦：
1、无法解锁质押：一旦质押了存款，在信标链启用转账功能之前，验证者都无法提出 ta 们的质押金。这意味着在未来的几个月甚至是几年里，参与质押都是一个单向的过程。
2、缺乏流动性：在质押的过程中，用户不能转移、交易 ta 们的 ETH，也不能使用其 ETH 作为抵押品参与 DeFi 协议。无法从信标链中提出质押金，这个代价是尤其大的。
3、高资本要求：用户质押的 ETH 数量只能是 32 及 32 的倍数，将余额较少或余额为奇数的用户排除在门槛之外。
4、操作上的负担：尽管以太坊核心开发者表示质押对硬件和正常运行时间的要求较低，但许多用户仍然偏向于提供资金，然后将运营工作外包给第三方。
我们很早就清楚地意识到，用户想要一个解决这些问题的方案，而我们也不是唯一试图解决这些问题的服务商。
第一个，同时也是最明显的竞争者是中心化交易所。对于它们来说，将用户的 ETH 集中起来 (解决问题 3)；为用户提供质押服务 (解决问题 4)；并发行流动性衍生品以替代用户的锁仓质押资产 (解决问题 1-2) 等等操作，都是轻而易举的事情。考虑到顾客获取和流动性对于交易所的业务是如此的重要，它们甚至可以免费为用户提供这项服务。
快进到今天，中心化交易所正成为以太坊质押领域的早期赢家。由 Kraken 或 Binance 等交易所运营的验证者节点成为占比最大的群体。像 Coinbase 这样不太显眼的交易所可能会在已质押的 ETH 中占据更大的份额。
图解以太坊质押服务占比：
然而，交易所已经成为以太坊最重要的用户之一；让它们成为最大的区块生产者可能会严重损害以太坊的去中心化特性。
因此，我们认为像 Lido 这样的去中心化质押池需要与中心化交易所的质押池进行抗衡。
以太坊质押池完全去信任为何如此关键？
1、以以太坊的安全为中心：如前所述，许多用户希望委托其质押服务。但由于以太坊不支持协议内委托，这为第三方质押服务商提供了一个机会。考虑到安全性对于以太坊来说是多么重要，去信任的质押池比需要信任的和中心化的质押池更为可取。
2、质押具有中心化力量：PoS 的 Staking (质押) 可能要比 PoW 的 Mining (挖矿) 更加中心化，支持更加少数、更加集中的赢家。这是因为质押池能够发行一个流动的质押衍生品 (如 stETH) 并以此创造一个强大的网络效应，而这是 PoW 所没有的。
在本文中，我们解释了 Lido 当前设计的想法来源以及我们将如何把 Lido 转变成一个完全去信任的基础设施。
创建一个去信任的质押池和衍生品
此前我们发布 Lido 时就实现完全去信任的质押池和衍生品是不可能的。所以我们必须在两者之间进行选择 a) 延期发布 b) 先提供目前替代交易所质押池的最佳方案，同时最小化信任
尽管第一种方法比第二种方法更加去信任，但延期发布会将竞争机会让给交易所 (因为它们不会对自己施以同样的要求)。我们并不清楚去信任的质押能否克服如此大的先发优势，因而对于团队来说，等待似乎是更危险的选择。
因此，我们选择了一种迭代的方法，允许我们与中心化交易所质押池竞争并获得市场份额，同时不断减少系统的信任特性 (当能够这样做时)。
那么，目前阻碍质押衍生产品完全去信任化的关键因素有哪些呢？下面，我们指出了阻碍 Lido 完全去信任化的主要三点：
1、2021 年 7 月 15 日之前的质押存款是托管的：在我们发布 Lido 时，不可能将智能合约设置为信标链验证者的所有者。所以 Lido 验证者的提款凭证由一群有声望的以太坊构建者组成的一个 6-of-11 多签控制。我们已经将托管转到一个智能合约中，但这个功能还未适用于现有的质押存款。
2、目前提款功能还不是无需许可的：由于提款凭证的设计方式，Lido 验证者目前必须手动解除质押。因此，stETH 持有者不能强迫 Lido 节点运营者解除质押，相反，ta 们必须相信节点运营者诚实作为而不是作恶。
3、目前成为一个节点运营者还不是无需许可的：目前只有 LDO 代币持有者控制的 Lido 注册中心可以添加新的节点运营者。因此，stETH 用户需要相信 LDO 持有者将继续支持合理的、分布式的验证者子集。
请注意，从信标链中提款的功能尚未启用，也就是说任何人 (包括 6-of-11 多签) 都无法从存款合约中提取资金。这也意味着目前 stETH 持有者无法从信标链中赎回 ETH，因此 ta 们不会受到攻击而损失资产。所以，上述的前两个问题目前还不会对用户造成影响。而我们之所以把这个两个问题也列出来，是因为一旦信标链启用了提款功能，这两个问题就会出现。
移除这些信任要求
将托管转到一个智能合约中
正如前面所说的，当 Lido 发布时无法将智能合约设置成信标链验证者节点的所有者。
智能合约提现地址格式已添加到信标链规范中，上周我们将Lido 新质押者的提款凭证转到一个智能合约中。
要想理解为什么这不能适用于现有的存款，我们需要先了解信标链中的提款凭证是什么：
1、如前所述，以太坊质押一开始仅支持一种提款凭证 0x0。这仅允许 BLS 地址类型成为验证者节点的所有者，甚至连以太坊地址都不可以。
2、2020 年 12 月，规范中引进了 0x01 以允许以太坊地址设置验证者节点。
3、要想转换现有验证者的提款凭证，必须要先解锁质押的 ETH，然后使用新的提款凭证重新质押。然而，在提款功能启用之前，任何人都无法解锁质押的 ETH 并重新质押。所以现在想要将提款凭证从 0x0 转为 0x01，需要采用第二种机制，这个机制允许验证者不需要解锁质押就能够转换 ta 们的提款凭证
我们用于新提款凭证的智能合约被实现为一个架构型的可升级智能合约。这样做是因为我们仍然缺少实现远程提款(即，智能合约触发验证者解锁质押) 的关键功能，因此我们需要在引入这些功能时保有可升级的选项。
在 2021 年 7 月 15 日进行了对智能合约提款凭证的升级，也就是说，Lido 上在此之后的任意新质押存款都是完全非托管的。
远程强制验证者解锁质押
如有用户现在就想解锁质押 (这行不通，因为存款合约中的 ETH 既不能提出来，亦不能重新质押)，Lido 将不得不向验证者发送信息。然后，该验证者必须手动解锁质押，从而允许 ta 们破坏甚至勒索 Lido 协议。为了缓解这一问题，到目前为止，我们一直在以许可的方式 (permissioned manner) 加入新的节点运营者。
最理想的情况是，我们可以通过允许 stETH 持有者远程触发验证者解锁质押来彻底解决这个问题。最近，以太坊研究人员提出了一个新提案，该提议将允许委托方强制其代理人解锁质押。这个地址临时标记为0x03，它可以作为一个独立凭证来实现，也可以在信标链提款功能启用后作为对 0x01 的修正来实现。
该提案通过在以太坊上引进一个新的“规范” Exit Contract (退出合约) —— 有点类似于 Deposit Contract (存款合约) —— 来实现。0x03 提款凭证的所有者将能够指定与其相匹配的任意验证者。然后信标链就会为该验证者触发“自愿退出”机制，作为信标链状态转换函数的一部分。这意味着该验证者接收了用户的远程解锁质押指令并执行。
开放验证者注册
正如我们所见，托管问题和 Griefing attack (损人不利己的攻击) 具有简单的技术解决方案。幸运的是，它们同时也是非常重要的问题，而解决这些问题是让 Lido 协议更加去信任的两个首要任务。
这给我们留下了一个问题：谁能够成为 Lido 的节点运营者。这是一个更为复杂的问题，其解决方案也没有那么简单。
首先，为什么 Lido 需要控制谁能成为节点运营者？
Lido 价值主张的核心部分是流动性质押 (liquid staking)，因此针对用户的质押存款发行 stETH 衍生品。在一个简单的实现中，针对不同验证者发行的衍生品应该以不同的市场价格进行交易，因为这些衍生品的性能和可靠性各不相同。然而，由此产生的代币不能相互替代，这使得为它们构建流动性变得更加困难。
相反，Lido 用户通过质押获得相同的可替代的 stETH 代币，允许交易所、借贷市场等来使用它们。
这种可替代性虽然非常可取，但也产生了一个新问题：它要求在所有 stETH 持有者中社会化那些劣质验证者节点的不良表现和罚没风险，即 stETH 持有者不仅仅是单个验证者的衍生品的持有者。比如，如果一个验证者被罚没，所有 stETH 持有者都会损失一点资产，而不是单个衍生品持有者损失一大笔资产。
如果质押衍生品相互不可替代，那么用户将不得不使用一些激励来吸引一些最好的节点运营者帮 ta 们运行节点，因为节点运行的质量直接影响其质押衍生品的价值。换句话说，节点运营者的质量控制将由市场来执行。但如果质押衍生品相互可替代，Lido 必须确保只有合格的节点运行者才能够接受用户的委托。
这种对于节点运营者进行的中央“质量控制”检查不是一个轻易的问题。我们列出了一些可能的解决方案，以下为解决方案的不完全清单：
中央注册 + 链下声望 (Central registry + off-chain reputation)：最简单的解决方案就是仅允许具有良好记录和法律追索权的顶级节点运营者参与，ta 们可以由 LDO 治理投票选拔出来。这是当前的解决方案，但是这可能会赋予协议治理过多的权力。如果 stETH 的网络效应变得太过强大，以至于尽管以太坊上出现一个更加去中心化的质押提供商，人们也愿意使用它，这时协议的治理权就变得无比大了。
由质押者管理的注册表 (Staker-curated registries)：一个更加去中心化和价值一致的解决方案是让质押者选择节点运营者集。这也不是一个轻易的问题，因为质押金具有流动性，而且质押者不必承担其行为的长期后果。然而，如果该问题得到了解决，Lido 协议将无需许可，并与质押者的利益高度一致。
债券解决方案 (Bonding)：Tezos 等其他区块链和 Rocket Pool 等其他质押池使用的一种方法是要求验证者提供保证金。例如，在 Rocket Pool 中，验证者必须与其委托方一齐质押。在一对一的保证金系统中，用户实际上没有罚没风险，因为系统也会首先罚没验证者的保证金。
然而，从以往加密历史上的经验告诉我们，资本效率非常重要。并且债券解决方案通常较晚上市，规模更小，而对于持有者来说，这个解决方案比非债券解决方案成本更高。按理说，同样的道理也适用于质押市场。更糟糕的是，这给那些托管的流动性质押池解决方案 (如交易所) 带来了相当大的优势，因为它们可以免费地使用其他人的代币在其他质押池中购买债券以赚取利益。
秘密共享验证者 (Secret Shared Validators)：以太坊基金会提出了一个新提案 Secret Shared Validators (SSV)，这个方法在不影响性能的情况下提高系统的容错性。
SSV 将单个验证者拆分为由不同实体控制的多签。然后，这些实体将首先通过链下投票协议达成共识，从而共同生产区块。虽然这种方案的代价是带来了更高的通信开销，但优点是：单个验证者无法自己造成任何故障，因为 ta 们可能控制 10 个验证者节点的 10%，而不是控制一整个验证者节点。
目前在 Lido 论坛上有讨论 SSV 的相关研究。
跟踪验证者的性能 (Tracking validator performance)：另一个容易实现的方案可能是跟踪验证者的协议内性能，并根据该信息在系统内分配 ETH。这个方案首先需要信标链公开验证者的统计信息 (例如其正常运行时间)，以便质押池的智能合约能够计算其链上性能。
验证者的链上数据可以用在几个方面。例如，性能较好的节点运营者更有可能被分配到新的质押 ETH。此外，当用户想要解锁质押其 ETH 时，系统能够移除性能最差的验证者，而不是随机移除。
保险 (Insurance)：Lido 可以将验证者的质检工作重新外包给市场，例如，通过拥有一个公共保险系统。这实际上是一个预测市场，Lido 将提供一些奖励，让用户预测哪些验证者的月度表现最佳。
节点运营者积分制 (Node operator score)：重申一下，Lido 需要对节点运营者进行质量控制检查。尽管如此，Lido 还是不希望以一种由 LDO 治理者或其他人决定的中心化方式来实现。
最佳的解决方案是，将上述许多想法与一个验证者积分系统结合。每当新的 ETH 排队等待质押时，得分较高的节点运营者将更容易获得 ETH 以进行质押，直到分配给其的 ETH 达到了安全限制。当系统上出现提款要求时，积分低节点运营者可能也会首先受到惩罚，如果 ta 们的积分低于最低阈值，甚至会被完全从系统中移除。
每一个新加入系统的节点运营者起始积分都为零，这意味着其信任度低并且接受委托的机会很小。然后，节点运营者可以通过执行各种提高信任度的操作来获取积分，例如：
成为 SSV 多名验证者的一部分
质押一些 ETH 保证金
给自己上保险
主要是随着时间的推移展示其良好的验证者性能
(这些只是对节点运营者进行评分的一些指示性方法。可能存在更多/更好的选择。)
在这样的系统中，任何人都可以成为节点运营者，但必须要表现良好，就像在市场中竞争获取用户的青睐一样。随着节点运营者逐渐积累良好的积分，ta 们可以开始减少其他成本，如保险或者 SSV 开销。这种系统还可以激励验证者尽可能地表现出色，因为这会使得 ta 们通过更多的质押金获取更多的奖励。
无论最佳解决方案是什么，我们都将尽最大的努力让 Lido 实现其去中心化的目标。
总结
我们相信获胜的以太坊质押池和衍生品将是一个最大限度去中心化和不可篡改的协议，而这就是 Lido 最理想的状态。
我们还相信，等待以太坊与类似这种方案百分百兼容无疑是将市场拱手让给那些不会以此标准约束自己的中心化交易所。因此，提供一个去信任的可替代方案最好的方法就是通过采用当时的最佳实践，然后逐渐迭代更改。
我们正努力使 Lido 协议变得完全非托管和去信任。我们的两个首要任务有明确的技术解决方案，并且我们正与以太坊开发者合作，或者在可能的情况下等待部署。
节点运营者的去信任问题是一个更为复杂的问题。尽管如此，我们仍将探索上述的解决方案以及我们尚未考虑过的其他解决方案，尽可能减少 Lido 协议对社区治理组织的依赖。
随着解决方案变得可行，我们将继续快速地进行迭代并减少 Lido 系统中所需的信任面。我们很自豪能够提供一种可以替代中心化交易所质押池的更好的方案，并构建完全去中心化、去信任的质押衍生品。
来源 | blog.lido.fi
作者 | Lido