Solana 与以太坊：为什么他们的交易速度不同？

共识机制架构

1. Solana 采用历史证明 (PoH)，这是一种可验证的延迟函数，可在交易进入共识层之前以加密方式为交易添加时间戳。这种预排序消除了验证者在区块生产期间协商排序的需要。

2. 以太坊依赖于提议者与构建者分离的权益证明（PoS），其中区块构建者竞争构建最佳区块，而提议者从中进行选择。交易顺序是在槽执行期间动态确定的。

3. PoH 使 Solana 验证器能够并行处理数千个交易，而无需交叉验证器协调开销，从而直接有助于亚秒级最终确定。

4.以太坊的共识设计优先考虑审查阻力和去中心化而不是原始吞吐量，需要顺序验证每个区块内的交易效果。

5. Solana 架构中缺乏全局状态锁定，允许跨非重叠帐户集并发执行，而以太坊的 EVM 则强制执行每个块的严格串行执行。

执行引擎设计

1. Solana 的 Sealevel 运行时通过在调度之前在指令级别分析读/写帐户依赖性来并行执行事务。

2. 以太坊的 EVM 按 Gas 排序顺序一次处理一笔交易，无论底层硬件功能如何，都使得执行本质上是线性的。

3. Sealevel 要求开发人员显式声明帐户访问模式，从而在执行开始之前启用确定性冲突检测。

4. EVM不需要此类声明；冲突仅在运行时出现，当发生状态不一致时强制重新执行或拒绝。

5. Solana 中的并行执行减少了每笔交易的平均延迟，但由于显式的并发管理，增加了智能合约开发的复杂性。

网络级吞吐量约束

1. Solana 的目标是在理想条件下达到 65,000 TPS，并由使用 GPU 和自定义加密库的硬件加速签名验证提供支持。

2. 以太坊当前的后 Deneb 容量仍限制在 L1 接近 100 TPS 的范围内，大多数大容量活动转移到独立于基础层瓶颈运行的汇总操作。

3. Solana 的验证器集在严格的硬件要求下运行 - 节点必须维持 10 Gbps 带宽和 NVMe 存储 - 以在其高频领导轮换中保持同步。

4. 以太坊验证器在具有宽松 I/O 需求的商品硬件上运行，以原始速度换取更广泛的参与和容错能力。

5. Solana 中的网络传播延迟通过 Turbine 最小化，Turbine 是一种块分发协议，可将块分割成更小的数据包，并跨地理区域同时多播它们。

交易失败动态

1. Solana 的交易失败率约为20% ，这主要是由于资源耗尽、时序违规以及峰值负载期间的帐户锁定争用造成的。

2. 以太坊的失败率接近0.1% ，反映了保守的 Gas 估算实践和从 EVM 设计继承的内置执行保障措施。

3. Solana 上失败的交易即使恢复也会消耗计算预算和网络带宽，从而给用户和验证者带来可衡量的成本。

4. 以太坊的 Gas 机制确保失败的交易仅消耗为其执行尝试支付的 Gas，从而限制对经济激励的附带损害。

5. Solana 上的高故障率与内存池拥塞和快速领导者过渡时期密切相关，从而暴露了架构对实时网络变化的敏感性。

零值转移行为

1. 所有 Solana 交易中大约7.6% 的交易价值为零，通常用于账户初始化、程序升级或 CPI 调用脚手架。

2. 以太坊仅记录了0.66% 的零价值转移，因为其交易模型将价值转移与执行意图紧密耦合。

3. Solana 的账户模型将每条指令视为一流的交易实体，从而无需原生价值移动即可实现原子多指令捆绑。

4.以太坊以交易为中心的模型即使对于简单的状态突变也需要明确的 ETH 转移或 ERC-20 批准，这不鼓励零价值使用模式。

5. Solana 上零值流量的盛行反映了应用程序与链状态交互方式与用户发起操作方式之间更深层次的结构差异。

常见问题解答

问：Solana 的高 TPS 是否是以去中心化为代价的？答：是的。 Solana 的验证器要求（包括高带宽连接、低延迟 NVMe 存储和 GPU 加速）排除了低资源参与者，导致验证器集明显小于以太坊。

问：为什么以太坊不能简单地采用 PoH 来提高速度？答：PoH 假设同步时钟和确定性网络延迟，这与以太坊在对抗性、异构网络条件下可靠运行的设计原则相矛盾。

问：Solana 的并行执行优势是否可供所有开发人员使用？答：不行。开发者必须手动注释账户访问模式和结构逻辑，以避免运行时冲突，与以太坊的即插即用 EVM 兼容性相比，提高了进入门槛。

问：以太坊如何在将规模委托给 L2 的同时保持安全性？答：以太坊通过呼叫数据发布和欺诈/有效性证明确保 L2 数据可用性，确保 L2 状态转换保持锚定于 L1 结算层并可由 L1 结算层验证。