# 以太坊DVT赛道-SSV机制详解与思考

By [damian-dyor.eth](https://paragraph.com/@damian-dyor) · 2023-03-06

---

> 0\. 前言
> ------

本来自己给这篇文章的标题是《关于SSV的一些思考》，主要是想和大家分享一下最近对于ssv的一些思考，但为什么又加上了对ssv机制详解这部分内容呢？一方面是想结合官方文档，和大家科普一下，另一方面也是想借着这个机会，更加详细的学习ssv的机制及逻辑，尽量去避免自己的观点有失偏颇，所以这篇文章将包含三部分的内容，分别为**ssv简介**、**ssv运作机制**，及文尾附上我**对于ssv的一些思考**，下面开始正文

> 1\. SSV 简介
> ----------

### 1.1 什么是 ssv.network

ssv.network 是一个完全去中心化的开源 ETH 质押网络，基于秘密共享验证器 (Secret Shared Validator) 技术。SSV 属于DVT的一种，即分布式验证器技术（Distributed Validator Technology），因为它提供了一个开放和简单的基础设施，可以将验证器的密钥拆分并将拆分后的密钥分发，以实现在多个非信任节点上运行以太坊验证器。有以下优点：

1.  可以有效降低单个验证器的离线风险，增加以太坊网络的鲁棒性
    
2.  为非托管的以太坊质押提供了技术支持
    
3.  完全去中心化，自由市场
    

### 1.2 参与方

*   **Stakers**：包括Lido之类的质押服务提供商、以太坊个人质押者等
    
*   **Operators**：提供硬件基础设施，运行 SSV 协议，并负责维护以太坊验证器和 ssv.network 的整体健康状况。 operators 自行确定提供这些服务的费用，并向 stakers 收取运营和维护其以太坊验证器的费用
    
*   **DAO**：对 ssv.network 拥有资金所有权及治理权
    

### 1.3 费用

ssv.network 的费用是对 staker 收取的，主要包括两部分：

**运营商费用（operator fees）**：operator 帮助 staker 运营以太坊验证器，staker需要给operator的费用，这个费用从目前的官方文档来看，是以 SSV 计价的，并且具体给多少是operator自己报价的，也就是说这里存在一个自由市场，当 operator 报价太高时，可能面临没有 staker 光顾的情况，而且该费用在报价时，通常是年费的形式来报，但是 staker 在实际操作中是按区块来付钱，即以太坊中每产生一个区块（12秒），staker 就需要给 operator 一笔“工资”

举个例子：若每天以太坊只产生100个新区块，且 operator的报价是365 SSV 一年，则：

    365SSV / （100 * 365） = 0.01 SSV per block
    

**网络费用（network fees）**：网络费是一笔固定的费用，由 DAO 决定的，支付的费用会直接进入 DAO 的金库，来资助和发展生态中已经投票通过的项目和活动

### 1.4 代币

根据官方文档，目前SSV代币可以用于支付 ssv.network 内的费用，用于 ssv.network 的治理，且可参加DAO的财富分配

![Fig 1. Operators receive SSV payments and generate ETH rewards for stakers. Stakers pay SSV and receive generated ETH rewards in return](https://storage.googleapis.com/papyrus_images/d40c166e3ed9069d8ba7b4e4086486df98a4669d6615e1b07f121cbbaa1793eb.png)

Fig 1. Operators receive SSV payments and generate ETH rewards for stakers. Stakers pay SSV and receive generated ETH rewards in return

### 1.5 技术概述

SSV可以被看作是一个拥有共识层的复杂多重签名钱包，是位于信标链和验证器客户端之间的中间层。 如果从用户的角度来看，它只是一个组件， SSV 配置的主要组件如下：

1.  **分布式密钥生成（Distributed Key Generation）**：运行 SSV 的 operators 会计算并生成共享的公钥和私钥集。 每个operator都拥有私钥的一部分，确保没有任何一个 operator 可以影响或控制整个私钥并私自操作账户
    
2.  **秘密共享（Shamir Secret Sharing）**：所谓[秘密共享](https://www.cnblogs.com/pam-sh/p/16994056.html)，即当收集到了一定数量的被拆分密钥后，就可以重构出密钥（比如密钥被拆分为5份，而当收集到其中任意3份，便可以重构出密钥），但并不会真的在各个 operator 之间共享这些密钥片段，否则会有密钥泄露的风险，而是共享用这些密钥片段进行的签名，最后利用 [BLS 签名](https://learnblockchain.cn/2019/08/29/bls)，组合多个签名以重新创建验证器密钥签名
    
3.  **伊斯坦布尔拜占庭容错共识（Istanbul Byzantine Fault Tolerance Consensus）**：SSV 的共识层基于伊斯坦布尔拜占庭容错 (IBFT) 算法。 该算法随机选择一个 operator 负责新区块的产生并与其他参与者共享信息。 一旦认为该区块有效的 operators 达到阈值（即发出密钥片段的签名），该区块就会被添加到链中
    

> 2\. SSV 运作机制
> ------------

### 2.1 账户与支付

每一个 ssv.network 的参与者都会在 ssv.network 的智能合约中拥有一个账户，账户中记录着所有参与者的账户余额，通过实时跟踪没个账户的流水来更新账户余额

![Fig 2. Contract payment flow](https://storage.googleapis.com/papyrus_images/2046b4d23f8f77ce64148f78de7503f4f2279ab53b7e16697a83000f26e8bf32.png)

Fig 2. Contract payment flow

Operator 收入包括：

    Earning(current) = Earning(previous) + (bc - bp) * f * v
    

*   Earning(previous)：先前累计收入
    
*   bc：当前区块的区块编号
    
*   bp：前一个区块的区块编号
    
*   f：每一个区块费用（SSV计价）
    
*   v：operator 管理的验证器个数
    

Staker 的费用就是 operator 收入的基础上，再加网络费用

### 2.2 清算

Staker 的账户余额由两个重要部分组成：**liquidation collateral** 和 **operational runway**，为了方便，我们定义而这两者之间的分界线就是清算线，当 staker 账户中的余额高于清算线时，账户可以正常给 operator 发“工资”，而当余额低于清算线时，就会有 liquidator 将账户标记为“不足以支付费用”，并且会将 liquidation collateral 全数没收，被没收的 liquidation collateral 则会被作为 liquidator 辛勤工作的奖励

![Fig 3. Account balance of staker](https://storage.googleapis.com/papyrus_images/3c1aacfef5be883699eb4d6761647ab9b21cbb9d5892a557ac98211bcc928b27.png)

Fig 3. Account balance of staker

当一个账户的余额不足以支付未来一段时期的费用时，该账户就变成了“可清算的”，而未来的这段时期被称为`liquidation_threshold_period`，这段时期以区块的数量来计

再引入一个概念：`burn_rate`：该 staker 账户在1个区块产生间隔内（12秒），所有的费用（付给管理其以太坊验证器的每一位 operator 的“工资”）与所有收入的差值

    liquidatable = balance < burn_rate * liquidation_threshold_period
    

*   `burn_rate`：1个区块间隔内，该账户所有的费用（付给管理其以太坊验证器的每一位 operator 的“工资”与网络费用）与所有收入的差值
    
*   `liquidation_threshold_period`：区块的数量
    

要注意的是清算是按账户来计算的，并不是按验证器来计算的，且由于每一个账户所选择的 operator 的数量及验证器的数量不同，所以每一个账户的清算线是不同的，都需要单独计算得到

一旦账户被清算，账户的状态就变成了非活跃状态，此时 operator 也不会继续再管理验证器，该账户不仅要受到 ssv.network 的惩罚，还要不断受到以太坊信标链的处罚，直至该账户被重新激活，那么如何重新激活账户呢？其实就是网账户中充入足够的金额（liquidation collateral）

    reactivation_balance > expense * liquidation_threshold_period
    

*   expense：1个区块间隔内，运行该账户中所有验证器的总费用（operator 的“工资” 加网络费用）
    
*   `liquidation_threshold_period`：区块的数量
    

\*\*算例：\*\*B（staker）在 ssv.network 上注册了验证器，operator 的报价是每年345个 SSV 代币，网络费为20个 SSV 一年，B 存入395个 SSV 到他的账户余额中，假设 liquidation threshold period 是30天（其实应该是以区块数量来计，这里为了方便，直接用天数），则 B 的 liquidation collateral 为：

    （345（operator fees）+ 20（network fees））* 30 / 365 = 30 SSV
    

一年以后，根据 B 账户的 burn\_rate = 1 SSV per day，则 B 的账户余额为395 - 365 = 30 SSV，在清算线以下，A（liquidator）持续监控网络参与者的账户，发现了 B 的账户在清算线以下，将 B 的账户标记为清算，协议也确认了 B 的账户“资不抵债”，并执行了清算，此时 B 的账户变为非活跃状态，且 operator 暂停管理其验证器，而A 则获得30 SSV 的奖励，在受到惩罚后，B 向账户中又充入了60 SSV（大于30 SSV，可以重新激活账户）

### 2.3 更新机制

Operator 报价可以在任何时间点进行更改，更改报价通常是出于获得竞争优势及与市场价格波动保持一致，为了保证报价更新的透明度及给予 staker 充分的调整时间（充值更多的余额防止被清算或者直接换另一位 operator），网络会使用 operator 费用变更周期，分为两步：

1.  声明新报价（Declaring a new fee）：向网络广播该 operator 已变更其报价
    
2.  执行新报价（Executing the declared fee） ：完成报价更新（在此之后新报价才生效）
    

![Fig 4. Operator fee update cycle](https://storage.googleapis.com/papyrus_images/0cad102ef00895077e8e178e0558fc7b57c11094402ad1975551bafda1acd4a5.png)

Fig 4. Operator fee update cycle

在上述两个步骤之间的时期，被称为 declaration period，是由 DAO 来确定，也就是说 operator 必须要等 declaration period 这么长时间，新的报价才会生效，且在第2步时，若operator 在 execution period 时间段内没有执行新的报价，那么新报价就失效了，此时如果需要改报价，就需要重新再回到第一步

为了保护 staker 免受由于费用突然大幅变化而导致的清算，ssv.network 对 operator 每次报价改变的幅度有限制，该限制的幅度由 DAO 决定

同样的，staker 也具有相当大的自由度，他可以自行确定运行验证器的 operator，当要更换 operator 时，staker 需要重新向每一位 operator 分发密钥片段，且只有在 staker 账户余额在清算线以上时（用新 operators 来计算），才可以更新 operator

### 2.4 退出机制

Operator 可以在任何时候选择退出网络，此时网络会立刻停止其获得收益，并将其从网络中移除，此过程是不可逆的，当其想要再返回网络是，就需要重新注册账户

同样的 staker 也可以随时选择退出网络，此时网络会将其验证器密钥的所有记录删除，且退出的验证器所对应的 liquidation collateral 会加到该账户的 operational runway 中，减小清算风险

### 2.5 评分机制

网络会根据每一个 operator 的表现情况，给每一位 operator 打分，评分 = 出勤次数 / 总应出勤次数，比如：一段时间内，operator A 应该出勤投票100次，但是由于种种原因，其只出勤98次，则评分为：98%

> 3\. 关于SSV的一些思考
> --------------

每次提到 SSV技术时，大家往往将更加去中心化挂在嘴边，刚开始学习 SSV 时的我半知半解，看到这种网络结构，也觉得这肯定是帮助以太坊更加去中心化了，这下 POW 和 POS 哪个更加去中心化应该有个定论了。可是当我更加深入的去学习和思考时，发现情况似乎并不是这么回事，基于以下两个原因：

1.  在主网上线后，推测大多数运行 SSV operator 节点的其实还是那些为Lido等质押服务提供商提供验证计算服务的运营商，虽然也会有更多的个人 operator 加入网络，但是由于个人计算机与专业做验证服务的计算机相比会有更多的离线时间，或者说是更大的离线风险（因为大多数人的计算机都不只是用来跑验证器的，还有其他很多用处，而专业做验证服务的计算机则用途单一，防离线的措施也更加到位），长此以往就会导致，个人 operator 的评分就会比较低，此时个人 operator 不得不采用更低的报价来赢得订单，而过低的利润，又会过滤掉一批个人 operator ，市场上的个人 operator 逐渐变少，主流的operator 还是那些大型运营商，那问题来了，在没有DVT技术前，大多数验证器就被控制在大型运营商手中，而有了DVT技术后，大多数验证器还是被控制在大型运营商手中，区别只不过是前者控制的验证器是确定的，而后者控制的验证器是随机分配的，而且单个大型运营商手中控制的验证器个数可能比没有DVT时更多，更加集中（现在SSV也要抽走一部分利润，利润更低，需要管理更多的验证器才能保证利润），从这个角度来看，DVT似乎并没有很好的解决中心化的问题
    
2.  Operator 的收入取决于它的报价与它所管理的验证器数量，在这样一个自由市场中，竞争非常激烈，如果 operator 报价过高，就没有 staker 会选择它，所以 operator 会尽可能的报低价来吸引 staker，同时为了保证利润，又会想要尽可能多的去管理验证器，这样一来，整个网络朝着更加中心化的方向发展
    

![Fig 5. SSV测试网一个operator管理1070个验证器](https://storage.googleapis.com/papyrus_images/d2ab609f8ce531918f58c1804ff85b3e74d443aff5ddc1bdcb24487e131ad75e.png)

Fig 5. SSV测试网一个operator管理1070个验证器

但如果 SSV 通过限制每个 operator 可以管理的验证器个数来达到一定程度的去中心化，由于趋利性，operators 会从网络中不断流失，而去加入那些不限制数量的 DVT 网络，所以从 SSV 的层面，很难解决这个问题，除非以太坊有相应的监控和惩罚措施。作为 SSV 的竞争对手，Obol labs 也意识到了质押中心化的问题，但并未在当前阶段提出具体的解决方案，以下文字摘自 Obol官网：

_“The network can be best visualized as a work layer that sits directly on top of base layer consensus. This work layer is designed to provide the base layer with more resiliency and promote decentralization as it scales._ **_As Ethereum matures over the coming years, the community will move onto the next great scaling challenge, which is stake centralization_**_. To effectively mititgate these risks, community building and credible neutrality must be used as a primary design principles.”_

> 4\. 结语
> ------

但这并不是说 SSV 技术就一无是处，虽然 SSV 对于以太坊的质押中心化问题并没有提出很好的解决方案，但是其对于质押服务提供商（比如Lido）的去中心化、非托管化提升却是巨大的，大大减小了监管的风险，这对于质押行业来说是绝对的刚需，且会大大提升以太坊网络的抗离线风险，增强在极端情况下网络的鲁棒性，所以SSV token 依旧是具有相当投资潜力的标的，只不过之前的我们，可能在 SSV 身上寄托了太多美好的期望

[Subscribe](null)

---

*Originally published on [damian-dyor.eth](https://paragraph.com/@damian-dyor/dvt-ssv-2)*
