详谈Solana的技术架构：为什么Solana没有被Ethereum杀死？

原文来源：Haotian，区块链安全从业者

在熊市的基底下，大家会冷静思考一些牛市可能忽略的东西，比如，重回公众视野的 Solana ，技术到底行不行，一句「中心化宕机」就能毁所有吗？

最近， MakerDAO 说 Solana 的 codebase 还不错， Visa 也宣布要和 Solana 试点合作，Solana 的 TVL 等数据指标也回暖不少，Solana 要迎来第二春吗？到底该怎么解读？

牛市正当时的时候，面对$SOL 突突上涨的币价，大家都说 Solana 的资本背景和 Community 生态很强，鲜有人能说清楚 Solana 的技术框架到底怎样。

不吹不黑，本文从科普角度浅析下 Solana 的背后的技术架构，以及为什么 Solana 没有被 Ethereum 杀死的原因。

Tips：仅本着技术科普的角度，带大家重新认识和理解 Solana，不做任何投资参考。

POH 共识机制

首先说说 POH 共识机制，即（Proof of history），它是 Solana 采用的特殊创新机制。 传统意义上区块时间和物理时间并没有关系（弱关联），比如比特币以太坊等公链的时间基准为块高度，时间流逝的表现载体也只是块高度的不断叠加，因此坎昆升级这种具体时间只能根据网络出块速率进行预估。

Solana 的 POH 创新点就在于把链的时间流逝和物理时间锚定了，比如：每个 POH 出块的间隔时间是固定的，连续的哈希运算会产生一个可验证的时间序列等等。

这样做可以避免「主观」时间带来的操纵和攻击问题，试想若出块时间不规律，节点之间很难快速达成共识，就容易产生回滚、重放等攻击，而物理时间的客观性是无法撼动的，节点无需回溯全部历史数据仅依据当前时间序列就能监测一些异常情况。

因此，POH 的创新就是为了强绑定物理时间，以促进 Solana 节点之间更好协作和达成共识。

在我看来，POH 机制还有一个优势：节点批量接收大量交易并进行排序（Pipeline），要等待 POH 时间戳来递交交易，等同于 layer 2 向 layer 1 Batch 交易一样，这种机制如同把 Rollup 的思想带入了 layer 1 中，为下面要说的高吞吐和并行处理等提供了先决条件。

存储和计算分离特性

其次来看「存储和计算分离」特性，它让 Solana 摆脱了 Data Availability 的瓶颈限制。

传统的区块链验证框架要依赖全节点发布大量历史数据来实现即时计算变更状态，这种计算和存储的耦合某种程度上会限制链的性能。比如以太坊要更新状态时要先同步全链数据然后执行历史记录计算，加之以太坊是顺序出块并不能串行因此出块时间和单区块容量都会受限。

而 Solana 将状态存储和交易执行进行了分离，有个单独的存储系统来保留状态，包括账户信息、签名者历史和交易记录等状态，有新交易执行时，Solana 会在 Pipeline 节点上高速运算，最后只更新状态到存储系统中。二者分离，可以确保账本系统快速运行，避免了 DA 校验状态时间+计算等待 DA 校验结果的时间损耗。要注意的是，网络计算和存储资源需要通过质押 SOL 获取。

通俗来比喻，以太坊的工人要到仓库取原材料再去车间加工，两份职责来回奔波效率低；而 Solana 两个车间都有专门的工人，搬运工只需要把临近使用的材料不定时搬到生产车间就好了，大大提升了效率。

高并发交易处理

再好好解析下「高并发交易处理」特性，这让 Solana 接轨 web2 市场需求有了可行性。

虽然 Solana 宣称自己有 70 万的 TPS 在其偶尔的宕机背景下被当成了笑话，但 MakerDAO 的 Endgame 选择，Visa 的选择某种程度上是对其性能极限的认可。那么，Solana 的高并发是如何做到的呢？

简单来说，是前边谈及的 POH 和计算存储分离等优势共同铸就的，便于让大家深刻理解，我试着把他和 Starknet 的高并发做一个对比。

Solana 收到用户 Alice 同时发出的 10 笔交易，节点会对交易进行排序，等到 POH 时间戳来 Batch 打包，然后等下一个时间戳到来时，节点会调用独立存储系统的状态数据，检测 10 笔交易是否存在状态冲突，若无冲突就可正常把 10 笔交易打包到一个区块中，若存在冲突，存在冲突的区块会被排除在本次打包之外。

不同的是，Starknet 网络的 Alice 由于在一套账户抽象模型下， 1 个账户发布的交易本身就不能存在状态冲突，可以同时执行 Approve 和 Transfer，因为他们修改的是合约不同的状态，Approve 对应 Allowance，Transfer 对应 Balance，但若同时执行两笔 Transfer 的话就要同时修改 Balance，就容易导致状态冲突导致计算错误。因此账户抽象特性是 Starknet 高并发的基础。

举个通俗的例子，Solana 的并行方式如同一个餐厅安排了多个服务员同时为客户点餐，每个服务员处理一个交易线程，点餐顺序也由服务员来协调，若有相同的菜品后厨可以并行上菜；而 Starknet 的并行方式则相当于用自助点餐机扫码点菜，客户可以同时在多个机器上接收订单，由后台中控系统统一协调订单。

总之，高并发的宗旨都是在网络秩序不紊乱的前提下合理高效利用系统资源。

Solana 的服务员就是被大家吐槽的高昂成本的节点运维系统，而 Starknet 的自助点餐机就是那套和合约兼容的账户抽象基础。

有了对 Solana 技术底层的深刻理解，再来看一些被诟病的问题，或许会有不同的答案。

在我看来，Solana 的问题出在技术实现逻辑过于复杂： 1）Solana 的节点运维成本过高，导致节点数量受限，其去中心化能力也受到牵制；2）POH+POS 的共识机制，需要节点有强大计算和带宽资源才能承载高并发，而资源成本越高，节点运维成本就越大；3）高并发处理时也难免存在状态冲突、网络负载等问题；

有人说，Solana 在用 web2 的思维做 web3 网络，它的技术创新起点高于已有区块链架构，如果把它的问题当成创新路上的容错率，或许会有不一样的评价。

创新的代价也许正如大家看到的那样，眼看他高楼起，眼看他楼塌了，但若创新的基底在，这塌方的楼会不会再次拔地而起呢？本人不持有 SOL，以上分析仅为技术+商业视角的冷静思考和观察，且在通俗化解读过程中存在不严谨之处，大家权当科普文看看，切莫作为投资参考。