区块链中文技术社区

了解以太坊和 Solana 在达成共识方面的差异。
众所周知，以太坊和 Solana 的共识机制均采用 PoS（权益证明）。它们都通过基于权益的验证器生成区块。尽管它们从根本上采用相同的共识，但以太坊目前记录的 TPS（每秒交易数）约为 30，而 Solana 则拥有 4000 TPS。这种差异间接表明了共识如何显著影响区块生成速度。本章将深入探讨这两条链之间的差异。

以太坊最初的共识

以太坊最初采用的是工作量证明（PoW）方式，比特币至今仍在使用这种方式。在 2022 年 8 月合并升级后，以太坊从工作量证明过渡到权益证明，现在采用上述的 PoS。

以太坊目前的共识

以太坊的核心是 PoS，但它特别采用了一种称为 Gasper 的共识算法。Gasper 是 Casper 友好最终性小工具 (Casper-FFG) 和 LMD-GHOST 分叉选择算法的组合。在深入研究 Gasper 之前，需要注意的是，以太坊最初是根据基于 PoW 的 Nakamoto 共识生成区块的。Nakamoto 共识遵循最长链规则，在分叉期间选择区块链中最长的链。因此，以太坊并没有完全放弃 PoW；它保留了 PoW 下的基本区块生成，同时在其上集成了 PoS 元素。

Casper (Casper-FFG) 是 Gasper 的一部分，它将某些区块升级为“最终确定”状态，确保网络参与者与常规链同步。它最初是在 Merge 升级期间为从基于 PoW 的链到 PoS 的过渡阶段提出的，现在部分贡献于更大的 Gasper 算法。LMD-GHOST（最新消息驱动最贪婪最重观察子树）是一种分叉选择算法，用于在各种分叉中选择最有效和最值得信赖的链。如果分叉生成多个新区块，验证者将通过证明消息进行投票，以确定将哪个区块附加到现有链。这些证明遵循从创世区块到最新区块（叶区块）的路径，选择由最新证明支持的区块。

Solana 的共识

Solana 中与以太坊各个共识算法对应的技术组件是什么？答案就在支持 PoS 的 Tower BFT 中。

首先，让我们了解一下 BFT 和 PBFT。BFT 是一种在分布式系统中实现节点间可靠共识的方法，源自“拜占庭将军问题”。即使某些节点是恶意的或不可靠的，它也能确保系统正常运行。PBFT 是 BFT 的一种实际实现，它通过确保所有节点之间对所有交易达成一致来保证系统的最终性和一致性。

Tower BFT 采用了 PBFT 的变体，但有一个根本区别：历史证明 (PoH) 在达成共识之前充当全局时钟。在 Solana 的实现中，PoH 用作网络时钟，用于安排区块、交易和数据的顺序。

以太坊经常会低效地更新其整个网络状态以用于特定交易，并且交易可能无法按顺序处理。相比之下，Solana 利用 PoH（历史证明）来支持 PoS。要确定两个事件之间的加密时间，需要一系列计算步骤。例如，考虑两张照片：一张是苹果，另一张是正在拍摄的照片。我们可以推断苹果的照片是先拍摄的。Solana 通过在数据中添加时间戳来跟踪它们的顺序，确保其结构不会混淆。

Tower BFT 使用 PoH，通过时间戳验证有效地确定区块、交易和数据的顺序。因此，验证者可以最终决定分叉，选择最受投票信任的链。以太坊缺乏像 PoH 那样的时间戳概念来进行整体状态同步，迫使验证者根据之前的哈希值进行计算以选择分叉。相反，基于 PoH 的 Solana Tower BFT 可以轻松达成共识，而无需进行完整的区块验证。

因此，比较可以总结如下：

概括

以太坊共识：基于 PoS 的 Gasper = Casper 友好最终性小工具（Casper-FFG）+ LMD-GHOST 分叉选择规则
Solana 的共识：基于 PoS 的 Tower BFT + PoH

原文：https://solana.com/developers/evm-to-svm/consensus

了解 Solana 和以太坊上的客户端之间的区别。
以太坊和 Solana 是独特的区块链，具有多个不同的验证器客户端来验证交易。拥有各种验证器客户端有助于防止特定客户端遇到问题时网络中断。在本章中，我们将介绍以太坊和 Solana 生态系统中的验证器客户端，并讨论存在的节点类型。

验证器客户端的类型

随着以太坊从 PoW（工作量证明）过渡到 PoS（权益证明），它采用了两种类型的验证器客户端：执行层 (EL) 和共识层 (CL) 客户端。执行客户端负责接收网络上广播的新交易、在 EVM 上执行它们以及维护所有以太坊数据的当前状态和数据库。另一方面，共识客户端实现 PoS 的共识算法，并根据来自执行客户端的已验证数据在网络上达成共识。这两种类型的客户端扮演着不同的角色，这就是为什么以太坊验证器节点通常同时运行执行客户端和共识客户端的原因。相比之下，Solana 将这两种功能结合在一个客户端中。

以下是以太坊的执行客户端列表：

以下是以太坊共识客户端列表：

现在，让我们看一下 Solana 的验证者客户端列表：

以太坊和 Solana 的节点数量

对于以太坊，您可以通过访问clientdiversity检查每个验证器客户端运行的节点数量。 对于 Solana，您可以从验证器健康报告中找到此信息。

节点类型

根据使用情况和所需条件，节点有多种形式。它们可以是存储所有数据的重量级节点，也可以是专注于处理交易的轻量级节点。
以太坊根据数据存储范围和参与共识的方式将节点分为三类：

• 全节点：全节点逐个区块验证区块链，下载并验证每个区块的数据。全节点有多种类型，有些从创世区块开始，验证整个区块链历史中的所有区块。其他全节点从最近的可信区块开始验证，通常维护最近 128 个区块的本地副本，并定期删除旧数据以节省磁盘空间。旧数据可以在需要时重新生成。
• 存档节点：存档节点验证并保存从创世块开始的所有块，从不删除任何数据。它们对于区块浏览器、钱包提供商和链分析等服务以及查询测试集（无需可靠地挖掘它们）至关重要。
• 轻节点：轻节点仅下载区块头，而不是整个区块链。轻节点所需的其他信息则向全节点请求。轻节点可以独立地根据区块头的状态根验证收到的数据。它们不需要高带宽或强大的硬件，因此可以通过手机或嵌入式设备参与以太坊网络。轻节点不参与共识，这意味着它们不能成为矿工或验证者，但它们提供与全节点相同的功能和安全保障，从而允许访问以太坊区块链。

对于 Solana 来说，节点根据其参与共识的方式分为两种类型：

• 共识节点：共识节点在网络中发挥着至关重要的作用，它们负责创建和向网络提交新区块，并对其他节点提交的新区块的有效性进行投票。它们是网络运行的核心。
• RPC 节点（远程过程调用节点）：RPC 节点对于在 Solana 区块链上构建的 dApp 至关重要，可充当区块链数据的网关。与共识节点一样，它们独立验证所有新区块和网络更改，但不参与投票。

Solana 从一开始就将 RPC 节点与共识节点区分开来。不过，RPC 节点不参与投票。以太坊的 RPC 节点通常基于完整节点或存档节点。

Solana 为什么这样对节点进行分类？与以太坊不同，Solana 每秒生成大量交易，由于交易量巨大，将整个区块链存储在每个节点上是不切实际的。目前，Solana 使用 Google Bigtable 存储数据，RPC 节点从那里访问数据。因此，Solana 不太注重在本地存储大量数据，这与以太坊的节点分类标准不同。

总而言之，比较如下：

RPC 服务列表

有同时支持以太坊和 Solana 的 RPC 服务，也有支持单链的 RPC 服务。Alchemy 和 Quicknode 等服务同时支持以太坊和 Solana。您可以在此处查看 Solana 的各种 RPC 服务。

概括

与以太坊一样，Solana 也拥有各种类型的验证器客户端。
虽然每个链的节点类型可能看起来不同，但它们从根本上为用户提供相同的功能。

简介

OP Succinct 使用 SP1 在 1 小时内将任何 OP 堆栈汇总转换为完整的 type-1 zkEVM Rollup。

文章介绍：https://blog.succinct.xyz/op-succinct/
github: https://github.com/succinctlabs/op-succinct
docs: https://succinctlabs.github.io/op-succinct/introduction.html
SP1介绍：https://blog.succinct.xyz/introducing-sp1/
客户用例：https://blog.conduit.xyz/op-succinct-zk-rollups/

该板条箱验证了使用 SP1 生成的 Groth16 证明，利用 Solana 的 BN254 预编译进行高效的加密操作。

github: https://github.com/succinctlabs/sp1-solana
文章介绍：https://blog.succinct.xyz/solana-sp1/

这是一个小的 Rust 程序，用于获取与给定地址关联的签名总数。签名数量与交易数量直接相关。

github: https://github.com/Eclipse-Laboratories-Inc/get-signatures-for-address