本文总结了 Lighthouse 客户端用户调查的结果,调查内容包括用户使用时长、使用的其他客户端、用途、节点位置、硬件配置、更新频率、资源使用、支持反馈、操作系统、容器化、云服务提供商、CPU核心数、内存大小、验证器数量、备用节点、MEV-boost使用情况和中继选择等方面。调查结果为 Lighthouse 的未来发展方向提供了参考。
在 UTC 时间 2023 年 11 月 27 日 3:18,我们发布了我们的第一次 Lighthouse 用户调查。 我们要对所有花时间提交回复的人表示衷心的感谢。
尽管我们将利用这些调查的结果来为我们未来的开发工作提供信息,但我们要承认,这些结果中会存在一种选择偏差,即倾向于经常访问 Lighthouse Discord 服务器 或密切关注 SigP 在 X(正式名称为 Twitter)上的动态 的用户。
因此,我们预计结果会偏向严肃的、业余的单人质押者,而远离大型机构质押者和可能只在遇到问题时才进行检查的更随意的质押者。
大多数用户报告说他们使用 Lighthouse 超过 2 年了。 这可能意味着他们中的很大一部分自 创世 以来一直在进行质押。
只有 15% 的用户使用 Lighthouse 不到一年(欢迎我们的新用户!)。 这可能意味着 Lighthouse 在过去 12 个月中看到的使用量增长主要来自机构质押者。
超过 30% 的用户至少使用过 1 个其他客户端,其中 Prysm 是最受欢迎的替代方案。 这些用户中的很大一部分可能 पहले 使用 Prysm 进行质押,然后切换到 Lighthouse(可能是为了支持 客户端多样性)。
正如预期的那样,质押是 Lighthouse 最流行的用例,超过 90% 的受访者表示他们使用它进行质押。
同样正如预期的那样,欧洲和北美在地域多样性方面占据主导地位,几乎 90% 的受访者从这些地点运行 Lighthouse。 除此之外,除了南美洲之外,所有大洲都有受访者。
有趣的是,Mini-PC 外形是运行 Lighthouse 最流行的机器,几乎 50% 的受访者使用它作为他们的主要 Lighthouse 机器。
然而,Single-Board PC 的受欢迎程度明显较低,这可能是由于硬件要求不断提高。 值得注意的是,只有 8.4% 的受访者表示他们正在使用云服务器。
1: 我只在遇到重大错误或有硬分叉时才更新。
5: 我一有新版本就更新。
大多数用户表示他们更新非常频繁,只有 10% 的用户更新速度低于 4/5。
大多数用户从 Github 下载版本,只有 28% 的用户从源代码构建二进制文件。 Docker Hub、Eth Docker 和其他来源(如 Rocket Pool、Dappnode 和 Ethereum on ARM)占受访者的 26%。
只有 7.3% 的用户使用 Siren,40% 的受访者表示他们根本没有听说过 Siren。
所以对于那些不知道的人:Siren 是 Lighthouse 的用户界面 我们之前在 之前的博客文章 中写过它,供那些感兴趣的人参考。
几乎 70% 的受访者表示他们希望 Lighthouse 减少磁盘使用量。 虽然我们没有区分磁盘读/写操作和磁盘使用量,但很可能大多数用户希望他们的节点占用更少的磁盘空间。
但是,目前还不清楚用户是否区分了 Lighthouse 使用的磁盘使用量和执行层使用的磁盘使用量。 通常,执行层占用明显更多的磁盘空间,因此很可能大多数用户指的是他们的整个质押设置。
但是对于那些希望 Lighthouse 特别占用更少空间的人来说,有一个好消息! Lighthouse 正在进行一些改进,以改进名为 Tree States 的项目中的磁盘使用量和状态管理。 Tree States 将大大减少所有 Lighthouse 节点的磁盘需求,尤其是那些运行归档节点的节点。
在撰写本文时,Tree States 仍处于实验阶段,但可以在此处尝试 最新的 alpha 版本。
对我们的 Discord 服务器 的反馈非常积极,只有 15% 的用户对他们收到的支持的评分低于 4/5。
质押不是一件容易的任务,而且软件可能会变得很复杂,因此我们很高兴听到绝大多数用户都感到受到照顾。
正如预期的那样,Linux 的使用完全主导了其他操作系统,只有不到 4% 的用户在非 Linux 机器上运行 Lighthouse。
大多数用户不使用任何类型的容器化软件。 对于那些使用的人来说,Docker 是最流行的,只有一小部分人使用 LXC 或 Kubernetes。 应该注意的是,Rocket Pool Smart Node 软件使用 Docker。
这个问题专门针对在云环境中运行的用户。
Hetzner 是最受欢迎的提供商,其次是 AWS。 值得注意的是,没有受访者使用 Google Cloud Platform、Linode 和 DigitalOcean。
在云服务器上运行 Lighthouse 的大多数用户没有利用任何类型的容器化,尽管相对于在本地运行的用户而言,这个多数较小,更大比例的用户使用 Docker 和其他容器化软件。
最流行的 CPU 核心数是 8 个,其次是 4 个,超过 70% 的用户拥有 8 个或更少的核心。
当然,核心数只是故事的一部分。 CPU 频率和 IPC(每时钟周期指令数)是考虑 CPU 性能时要考虑的其他重要因素。 此外,英特尔的性能/效率核心二分法使情况更加复杂。
但是,我们 可以 使用核心数作为 Lighthouse 通常在用户系统上运行多少线程的代理。 这可以为我们在 Lighthouse 内部应该如何积极地追求其他多线程处理提供依据。
几乎一半的用户报告说使用 32GB 的 RAM,而 64GB 和 16GB 又占了 43%。 值得注意的是,没有用户报告说使用 8GB 的 RAM,只有不到 2% 的受访者使用少于 16GB 的 RAM,这表明用户不认为 8GB 足够。
略多于一半的质押用户在其节点上运行少于 6 个验证器,而少于 10% 的用户运行 100 个或更多。
这对我们来说是一个重要的问题,因为我们可以为运行许多验证器的用户做一些优化,但会对运行少量验证器的用户产生负面影响。 根据这些数据,我们目前均衡的方法似乎是合适的。
有趣的是,大多数质押用户不运行备份节点。 确切地知道原因会很有趣。 用户是否对 Lighthouse 的稳定性充满信心,以至于不需要后备? 还是害怕被削减,以至于大多数用户都不愿意尝试设置后备解决方案?
更有趣的是,确实运行后备节点的大多数用户只使用 Lighthouse 节点。 这一点值得注意,因为如果 Lighthouse 中存在导致共识错误的严重错误,这些用户将不会受到保护。
超过 75% 的用户正在使用构建器软件,例如 mev-boost
。
这里需要注意的是,这并不一定意味着 25% 的区块提议没有提取 MEV。
由于网络的大部分是为利润而优化的质押池的一部分,因此 MEV 提取可能更普遍地存在于整个网络中。
有关 MEV 提取和构建器的最新统计信息,请参阅 mevboost.pics。
Ultra Sound, Flashbots 和 bloXroute Max Profit 是最受欢迎的中继,60% 的启用 MEV 的质押者选择将其中一个包含在他们的中继列表中。 我们注意到,bloXroute 已经宣布他们的中继将在 2023 年 12 月 拒绝包含 OFAC 交易的区块, 这发生在调查结束后。 因此,这个问题的结果可能会发生变化,因为质押者可能会删除 bloXroute 中继,以努力支持以太坊网络的抗审查性质。
- 原文链接: blog.sigmaprime.io/light...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!