Solana 并不依赖传统区块链中的“先共识后执行”模式，而是采用了“先执行后共识”流程，并利用 PoH（Proof of History）和 SVM（Solana Virtual Machine）在处理交易时实现了高效的并行执行。
关于 Solana 更多性能有关的知识，可以前往这篇博客：Solana 扩容机制分析：牺牲可用性换取高效率的极端尝试
交易的接收与发送：仅 Leader 处理
Solana 通过 PoS（Proof of Stake）和 PoH 机制，提前选出一系列未来的领导者节点，每个 Slot 由一个 Leader 负责收集并处理网络中的交易。为了确保交易被成功处理，交易必须发送到当前的 Leader 节点。如果交易被发送到非当前 Leader节点，该节点会将交易转发给当前的 Leader，以确保交易能够及时处理。
PoH 确定交易的全局顺序
Solana 利用 PoH（Proof of History）生成一种不可篡改的时间序列，标记每笔交易的到达顺序。PoH 的引入解决了在分布式环境下如何确定交易顺序的难题，并带来了一致的全局顺序。
当前的 Leader 节点会为每笔交易生成一个 PoH 时间戳，表示交易的到达顺序。所有验证者节点都能看到这些时间戳，这确保了所有节点在同一顺序下处理交易，而不需要额外的排序步骤。
SVM 的账户依赖分析与并行执行
Solana 的 SVM（Solana Virtual Machine）在执行交易前不会直接进行传统意义上的账户“锁定”，而是利用账户依赖分析来安排并行执行。在这一阶段，SVM 的主要任务是分析每笔交易涉及的账户，以最大化并行处理能力。
- 账户依赖分析：SVM 会检查每笔交易的账户依赖关系，找出哪些交易可以并行执行（即账户无交集），哪些交易需要按顺序执行（即共享可写账户）。
- 并行执行：对于没有账户冲突的交易，SVM 会分配到不同的线程并行执行，从而提升整体吞吐量。
- 顺序执行：对于共享可写账户的交易，SVM 会根据 PoH 的顺序安排顺序执行，确保数据一致性。
执行后的数据更新与结果缓存
交易的执行结果和状态更新暂时存储在内存缓存中，以减少频繁的写操作。
共识与区块确认：验证执行结果
在交易执行完成后，Solana 通过 PoS 机制进入共识阶段，以验证和确认区块的状态。
- 区块广播：领导者节点将打包好的区块和 PoH 时间戳广播到全网，由其他验证者节点进行验证。
- 共识达成：验证者节点检查 PoH 时间戳与交易执行顺序是否一致，确认交易的状态更新无误。共识达成后，区块中的交易被确认并写入区块链，完成永久存储。