摘要

本文以 Pharos 为主线，结合公开仪表盘的同口径数据与项目披露信息，回答机构与投资者最关心的三类问题：Pharos 的差异化路径是什么；相较主流高性能公链，它具体解决了哪些工程与运营痛点；这些技术选择如何转化为支付与 RWA 的可落地能力。

随着机构资金进入公链生态，评估重点正从峰值 TPS 转向可验证的最终性、可解释的安全边界、可落地的合规与隐私能力，以及面向真实资产与高频业务的端到端成本结构。本文选取 具有代表性的网络作为对照，在统一口径下对吞吐、最终性、去中心化指标与费用水平进行可视化比较；并从并行执行—存储下推—专用处理网络（SPN）的系统设计视角，解释 Pharos 的全栈并行路线及其机构级价值。

在该框架下，本文得到三点结论：第一，高频支付与清算更依赖确认时间分布与失败语义的稳定性，而非单次跑分的峰值 TPS；第二，RWA 的长期可运营性高度依赖数据层与索引 / 对账成本，存储与查询路径往往决定边际上链成本；第三，合规、隐私与专用计算不应停留在链外外挂，而应纳入可验证的结算闭环，使责任边界可条款化、风险可度量、事后可复盘举证。

关键词：Pharos；并行执行；模块化；SPN；最终性；资金安全；机构级公链

01

引言：机构在公链上真正买的是什么？

过去几年，稳定币成为链上结算的基础燃料，RWA 叙事从资产上链演进到结构化资产与现金流重构。这类需求对公链提出了不同于纯 DeFi 的工程约束：更强的对账 / 审计、更低的最终确认时间、更可控的数据层成本。Pharos 的全栈并行路线，正是在这一机构语境下提出的系统性解法。

机构进入公链生态时，购买的不是某条链的故事，而是一套可以被业务与风控系统消化的能力组合：确定性结算、可审计的数据访问、可控的合规边界，以及在拥堵与极端市场条件下仍可预测的运行曲线。具体来讲是一套可被审计、可被预测、可被风控的系统：能否稳定结算（Finality）、能否承载峰值负载（Throughput）、能否在极端情况下保持安全（Safety）以及能否在现实监管与商业约束下运作（Compliance）。

1.1 机构上链的生产约束不是抽象口号

机构将资产或结算流转移到公链时，更关注系统是否能够以可审计、可解释、可复盘的方式稳定运行于生产环境。这会带来三类硬约束：其一是审计与对账约束——交易完成意味着内部账、托管账与链上账可以一致对齐且可复核；其二是风险敞口约束——确认时间越不确定，业务系统就必须用更长缓冲与更高备付金覆盖不确定性；其三是合规与责任边界约束——哪些环节由链保证、哪些由外部模块保证、出了问题如何止损与举证，都必须能被写成条款与流程。

过去几年最典型的误区是把高 TPS 当成胜负手。机构的真实成本结构往往是：链上手续费只是冰山一角，更大的支出来自 RPC、索引、数据可用性、存储扩容、节点运维与安全合规。换句话说，机构要的是端到端吞吐与端到端成本，而不是某一层的理论峰值。

1.2 端到端吞吐 / 成本为什么才是机构的 KPI

把链当作生产系统来看，TPS 只是执行层的表面产出。机构实际消耗的是一条完整链路的能力：交易生成、签名与广播、排序与共识、执行与状态落盘、RPC 查询与索引服务、风控策略回写、以及链上 / 链下账务对齐。任何一个环节的瓶颈都会把峰值 TPS 折损成真实可交付吞吐。同理，机构的成本结构天然是端到端的：链上手续费之外，还包括高可用 RPC、索引与历史回溯、审计留存、节点运维与灾备、托管与多签体系，以及合规与安全成本。

Pharos 值得被单独讨论，并不在于其单点性能指标，而在于它试图回应一个更现实的问题：当支付、清算与真实资产进入链上生产环境时，执行性能、数据访问与合规能力能否被纳入同一条可审计、可结算的责任链路，而不是分散在多个链外组件之中。^[1]-[3]项目方在公开材料中披露，其测试网面向全球支付等场景，展示了高吞吐（例如 30,000 TPS）与约 1 秒级最终性的目标 / 表现。^[4][5] 本文不会把这些披露当作已被链上验证的事实，而是把它们当作 Pharos 的技术意图：它究竟想解决什么问题？与现有热门公链相比，关键差异在哪里？

1.3 理解 Pharos 的系统定位

理解 Pharos 的关键是把它看作一条可交付的链上生产流水线：执行层用并行框架提高稳定吞吐，存储层用下推与结构化查询降低数据与索引成本，区块阶段用流水线化压缩确认时间的抖动；当业务需要合规、隐私或专用计算时，再通过 SPN 把链外计算模块化并回到主网完成可验证结算闭环。

为了尽量避免口径不一致导致的伪比较，本文对性能类指标采用 Chainspect 的统一展示口径（如 1 小时窗口的 TPS、100 blocks 的 Max TPS、出块时间与最终性），对资产与交易活动采用 DefiLlama 的链维度面板口径。考虑讨论度、生态活跃与路线差异，本文选择 Solana、Sui、Aptos、Sei、NEAR、Avalanche、Ethereum 为主要对照。Ethereum 作为安全与去中心化基准，其余链代表当下高性能与新架构方向。对比指标与数据源主要包括：吞吐（Real-time TPS / Max TPS）、区块时间、最终性、验证者数量、Nakamoto 系数与平均交易费，主要来自 Chainspect 在 2026-01-06 的页面快照。^[6]-[12] Pharos 尚未被同源仪表盘全面追踪，本文对其在图表中的性能点采用公开披露。[4][5][13] 各类指标含义可以参照附录。

02

全景图：公链吞吐—最终性—去中心化的分布

本章的横向对比不是做公链排行榜，而是回答机构在评估一条新链时最常问的六个问题：它的确定性结算能否支撑支付与清算？它的数据层与索引成本能否长期可控？它的安全边界是否能被风控条款化？它对现有开发与审计体系是否友好？它是否为合规、隐私与专用计算预留了系统级接口？以及当业务规模上来时，是否仍能保持可预测的运行曲线。因此，我们把 Pharos 放回性能 × 确定性 × 可运营性的坐标系里，并以 Solana、Sui、Aptos 与 Ethereum 作为参照系，用同口径数据建立客观比较，再回到 Pharos 的工程抓手解释为什么。

注：Pharos 指标为公开披露的测试网 / 材料数据；其他链为 Chainspect 页面快照。

如图 1 所示，表中把性能、最终性与去中心化放在一个机构可读的坐标系里：吞吐决定上限，最终性决定结算确定性，而验证者与 Nakamoto 系数更接近安全边界能否被风控接受。对 Pharos 而言，横向对比的意义不是争夺某个单项第一，而是证明其全栈并行路线能同时改善端到端体验与可运营性。

2.1 吞吐与最终性

在宏观层面，同一口径的 Max TPS（100 blocks）与最终性（TTF）维度里，主流公链的性能版图与 Trade-off 如何分布。

图 2：吞吐与最终性对比

资料来源：Pharos Research

在机构视角下，吞吐 × 最终性是一张比 TPS 排行榜更有解释力的地图：吞吐决定系统上限，但最终性决定业务的敞口关闭速度。确认时间在拥堵、抖动与极端行情下的可预测性，往往比单点性能指标更具决策意义。因此，图 2 的价值在于把不同链的性能叙事拉回同一个问题：性能优势来自哪里？能否在高负载下仍保持确定性体验？

如图 2 所示，主流高性能公链在高吞吐 / 低最终性上各有侧重，但很少有链能够在共识、执行、存储与数据访问上同时把瓶颈拆干净。Pharos 的差异化叙事正是围绕这一点展开：以全栈并行（执行并行 + 存储下推 + 流水线化阶段并行）去换取更稳定的端到端体验，而不仅是某一次跑分的峰值。

把吞吐与最终性放在同一张图里，才能避免公链对比时最常见的误区：只盯 TPS。交易完成的确定性往往比峰值吞吐更关键，尤其在支付清算、抵押品管理与 RWA 资产操作里，业务系统需要的是可预测的确认时间和可控的失败率。Pharos 若主网上线后仍能稳定维持其披露的秒级最终性，并配合高吞吐，将更适配高频业务。^{[4][5][12][6]}

2.2 去中心化指标：验证者与 Nakamoto 系数

机构投资者通常会用验证者数量与 Nakamoto 系数进行第一道筛选。

图 3：验证者规模对比（对数坐标；Pharos 为测试网数据）

资料来源：Pharos Research

如图 3 所示，成熟网络在验证者规模上往往形成数量级差异。对 Pharos 这类仍处于扩张阶段的网络，机构更应该关注的是路线与透明度：节点准入与激励是否清晰、运行与故障数据是否持续披露、是否具备面向机构的基础设施伙伴与托管 / 风控方案，而不是在早期就用绝对规模一票否决。

验证者规模是机构尽调里绕不开的一项基础指标，但它不应被简单解读为越多越安全。更准确的理解是：验证者规模与网络的抗审查性、抗单点故障能力、以及生态可持续性高度相关，同时还需要结合节点独立性、质押集中度与客户端多样性一起评估。

机构真正需要的是把链级风险翻译成可执行的风控动作。实践中，验证者规模与 Nakamoto 系数通常会进入三类机制：准入条款（达到阈值才允许更高敞口）、限额与渐进式上量（里程碑达成后逐步放大规模）、以及容灾与切换（确认分布显著恶化或关键基础设施故障时的降级路径）。这也是为什么对早期网络更重要的是路线与透明度：节点准入与激励是否清晰、运行与故障数据是否持续披露、基础设施伙伴与托管 / 风控方案是否可获得。

图 4：Nakamoto 系数对比（Pharos=0 表示未披露 / 未上线）

资料来源：Pharos Research

如图 4 所示，不同网络的集中风险差异明显。对 Pharos 而言，短期更重要的是把 Nakamoto 系数变成可跟踪、可披露、可改善的工程与治理指标：包括质押分布、节点地理分布、运营商多样性、以及关键软件实现的冗余度。机构在策略上也可以采取限额 + 渐进式上量的方式，把早期集中度风险转化为可控的敞口管理。

相比验证者数量，Nakamoto 系数更接近问题的核心：需要多少个独立实体协同（或同时故障）才可能影响网络安全边界？它是衡量集中风险的一个可读指标，在 Chainspect 快照里，Solana 约 796/19；Avalanche 约 727/29；Sui 126/19；Aptos 138/17；Sei 40/7；NEAR 383/10；Ethereum 988,900/2。[6]-[12] Pharos 主网上线后的验证者规模与质押分布将是机构需要持续跟踪的关键变量。[13]

2.3 费用水平：低 Gas 不等于低总成本

平均交易费是用户最直观成本，但机构更在意端到端 TCO。图 5 给出数量级对比。

图 5：平均交易费对比（Pharos 为测试网数据）

资料来源：Pharos Research

如图 5 所示，链间平均交易费差异很大，但并不能直接推出哪条链更适合机构。Pharos 之所以强调存储与流水线，是因为当业务进入高频与数据密集模式后，I/O、索引与证明生成才会成为真正的成本杠杆：它们决定了节点硬件门槛、审计对账难度及机构系统集成的长期负担。

讨论成本时最常见的陷阱，是把 Gas 单价当作总成本。实际运营中，总成本还包括交易失败与重试带来的隐性损耗、拥堵时的滑点与机会成本及链上数据访问与对账的工程成本。在支付与 RWA 场景里，成本最容易被低估的是数据访问成本：余额证明、交易回溯、风控追踪、合规报送与审计抽查都依赖稳定的 RPC 与索引服务。当状态膨胀快、查询路径重、索引更新昂贵时，机构会在手续费之外付出更高的基础设施账单与更复杂的工程维护成本。因此，图 5 应被理解为写入成本的一个侧面；Pharos 强调存储与流水线的意义，在于把长期成本杠杆从参数补贴转向数据路径的结构性优化。

2.4 资金安全：机构真正担心的是责任边界与失效模式

把资金安全只理解为黑客攻击会低估机构面临的真实风险。机构更关心失效模式：当链出现拥堵、停顿、分叉、客户端缺陷、排序攻击或跨域模块失效时，资产是否会进入不可控状态？责任边界是否清晰？是否能快速止损并完成审计举证？

在链层面，去中心化与集中风险指标决定了系统是否容易被少数实体影响或在故障时出现系统性停摆；在交易层面，最终性分布决定清算敞口何时真正关闭；在运营层面，数据层与索引成本决定机构能否持续、低成本地做链上对账与异常追踪。Pharos 相对其他公链的差别在于，它试图把资金安全从抽象口号落到可交付的系统能力与接口边界上：在不少公链实践中，合规校验、隐私计算、风控规则乃至部分索引 / 监控能力往往通过外部服务、联盟节点或应用侧组件实现，这能快速上线，但链上只保证账本一致性，链下服务负责业务正确性，一旦出现争议（为何拒绝 / 放行、为何结算异常），机构难以形成链上可验证的证据闭环，审计与合规举证成本会随规模上升而显著增加；而 Pharos 的主网 + Store + SPN 组合给出的答案是在结算侧提供可被风控调用的确认 / 终局状态与清晰的失败语义，在数据侧提供低成本、可复盘的查询与回溯能力，在扩展侧通过 SPN 将合规 /KYC/AML、隐私计算与专用风控模块化隔离，并把可验证的判定结果 / 证明回写主网，同时提供模块异常时的降级与止损路径，从而把失效模式转化为可被流程管理的风险。

最后，机构落地的资金安全通常会落实为权限、结算、观测与止损四类控制：多签与分级授权控制资金动作；确认策略与限额管理控制敞口；持续监控确认分布、失败率与关键基础设施可用性；以及在异常时具备清晰的降级路径（暂停、提高门槛、切换备选通道）并保证账务可对齐、审计可复盘。Pharos 通过全栈并行与 SPN 模块化，率先将机构资金安全的权限—结算—观测—止损闭环沉淀为可配置、可观测、可审计的基础设施能力，并用持续披露的运行数据把这些能力转化为可验证的生产级确定性，从而凸显其作为机构级底座的成熟度与差异化。

03

技术差异化：三条金融级基础服务抓手

Pharos 的路线更像以金融级基础设施为设计目标，把共识执行、存储与异构计算组合成一条可被机构使用的高效生产流水线。

3.1 抓手一：链级并行执行（Pharos VM：EVM + WASM 双规范）

Pharos VM 强调同时支持 EVM 与 WASM 两种规范，目标是让 Solidity/EVM 生态和高性能 WASM 生态在同一条链上汇合，同时通过并行执行框架提升吞吐。^[2]并行执行通常由冲突识别—并行分组—最小化回滚 / 重算—确定性提交几个步骤组成。只有把并行策略做成可演进的工程模块，并对开发者暴露清晰的约束与工具链，才能把性能收益稳定地转化为业务体验。双规范的价值不仅是开发者迁移成本更低：它意味着可以把高频、性能敏感的业务（撮合、清算、定价、风控）逐步下沉到更接近底层的执行环境，同时又不放弃 EVM 的资产与工具链。

并行执行真正困难的地方不在开更多线程，而在于在不牺牲确定性与可复现性的前提下，让不同节点对同一笔交易集合产生一致结果。机构最在意的是三类生产问题：冲突密度上升时系统是优雅降级还是回滚 / 重算风暴；失败语义是否稳定、是否可被业务系统捕获并自动化处理；以及审计复盘时能否在确定输入与区块序列下复现同样执行轨迹。因此，Pharos 在主网与试点中应持续披露冲突交易占比下的吞吐曲线、失败率 / 重试率随负载变化的稳定性，以及端到端确认时间分位数。

图 6：并行执行的核心抓手 

资料来源：Pharos Research

如图 6 所示，Pharos 将并行执行的关键抓手抽象为调度与执行的分工，并通过 Pharos VM（EVM + WASM）提供兼容性与扩展性：EVM 降低迁移门槛，WASM 为更高性能与更广语言生态预留接口。这意味着既能承接现有 Solidity 资产与审计经验，又能在需要时引入更高性能的执行路径，而不必彻底推翻技术栈。

3.2 抓手二：存储下推（Pharos Store）

存储与数据成本常是高性能链的长期瓶颈。Pharos Store 的思路是把部分传统由外部数据库承担的工作下推到存储层本身（ADS/pushdown），从而在吞吐与成本之间争取更好的全局最优。官方文档披露：在特定评测中，相比传统两层架构可实现 15.8× 吞吐提升，并节省 80.3% 成本。^[3] 这类指标对机构更可感知，因为它直指长期运营费用。

图 7：Pharos Store 公开披露的收益

资料来源：Pharos Research

如图 7 所示，Pharos Store 把收益表述为工程指标。其意义不止在跑分，更在长期运营：节点成本更可控、状态膨胀更可管理、查询与对账更高效，这类数据层改造往往比单点 TPS 更能决定一个系统是否值得上生产。

把存储当成只是落盘会低估它对性能与运营成本的决定性影响。高频业务里，状态更新往往触发读写放大、Merkle/ 证明相关结构更新与索引增量维护；越接近真实金融，对账与审计抽查越频繁，这类成本越不可忽视。Pharos Store 的价值应被转译为可验证工程输出：状态增长曲线、查询延迟分布、索引更新耗时，以及在审计回溯场景下吞吐的折损比例。

很多公链的性能瓶颈并不在 CPU，而在存储读写放大：状态写入、历史版本访问、Merkle 化与索引更新会在高负载下迅速成为吞吐天花板。尤其在 RWA 场景，数据需要更强的可追溯性与更复杂的查询 / 对账，存储与索引的工程质量会直接影响机构的可运营性。

3.3 抓手三：SPN（Special Processing Networks）

在真实业务中，零知识证明、隐私计算、AI 推理等往往需要异构硬件或专用运行时。Pharos 提出 SPNs，将这些专用计算能力以网络化模块的方式接入，再回到主网完成结算与可验证性闭环。[1] SPN 的潜在意义是把链外计算从黑箱变成可治理、可组合、可审计的模块：计算在专用网络做，结果 / 证明回到主网。

SPN 的关键不在模块更多，而在于把链外计算纳入可治理边界：其一可验证，结果以证明或可验证形式回写主网；其二可隔离，不同业务域在专用网络中运行，降低相互摩擦；其三可止损，模块异常时主网具备明确降级策略（暂停、提高门槛、切换备选模块），而不影响核心账本安全。这也是图 8 需要清晰表达的边界：存储层属于主网核心，SPN 是外部专用处理网络，通过调用 / 结算与证明 / 结果回写与主网闭环协作。

图 8：Pharos 模块化主网 + SPN 的全栈并行思路

资料来源：Pharos Research

如图 8 所示，Pharos 用模块化主网 + SPN 的思路去回应这一诉求：在共享安全与统一价值网络之上，为不同业务域提供可定制、可隔离的专用处理网络，并纳入跨域互操作的设计。

3.4 SPN 的信任模型与运行假设

除 SPN 是否有能力之外，谁在运行 SPN、其信任假设是否清晰可控，才是决定其是否可被纳入生产风控体系的关键。与主网共识不同，SPN 并不被假设为完全无需信任的公共执行环境，而是一个受约束、可治理的专用计算域。

根据 Pharos 目前公开披露的信息，SPN 更接近一种模块化接入的专用网络：其节点运行主体、共识机制与安全假设可因业务域而异，而并非强制复用主网的验证者集合。这意味着，在实际部署中，SPN 由三类主体运行：其一是 Pharos 生态内的基础设施运营方；其二是具备合规资质的第三方服务商或机构联盟；其三是在特定业务场景下，由应用方或其指定托管方运行的专用节点集合。不同模式在去中心化程度、性能与合规可控性之间存在明确取舍。

需要强调的是，SPN 的安全边界并不等同于主网安全边界。其设计目标并非消除信任假设，而是将信任假设显式化、模块化，并通过可验证结果与主网结算进行隔离。具体而言，SPN 只对计算是否按规则完成负责，其输出以证明或可验证结果的形式提交主网；主网只对是否接受该结果进入结算状态负责，而不继承 SPN 内部的信任风险。

这一分层设计的关键价值在于可止损性：当 SPN 节点出现作恶、失效或合规争议时，主网可以通过暂停该 SPN 的结果接收、提高验证门槛或切换至备选模块来限制风险外溢，而不会影响核心账本的一致性与资产安全。对机构而言，这使得 SPN 风险可以被视为一种可配置、可替换的业务风险模块，而非不可控的链级系统性风险。

因此，在机构落地实践中，SPN 更适合作为受治理的专用计算网络进入风控框架，其运行主体、激励与惩罚机制、审计接口以及异常处置流程，应被明确写入业务条款与技术附录。

3.5 一张矩阵看 Pharos 的原生模块化优势

Pharos 的技术差异化更像原生模块化：并行执行、EVM 兼容、存储下推与 SPN 在网络启动阶段就完整统一进一套体系。

图 9：关键能力覆盖矩阵（定性归纳）

资料来源：Pharos Research

如图 9 所示，将关键能力放入同一矩阵后，Pharos 的主张可以概括为原生模块化优势：在同一个架构体系里从启动阶段就推进执行并行、存储优化、流水线与 SPN 扩展框架。原生性的价值在机构语境下非常现实——意味着更少的外部拼装、更清晰的责任边界，以及更可控的上线节奏。

原生模块化是治理与上线节奏的现实约束：每多一个外部组件，就多一份供应商风险、多一个审计对象、多一条故障链路与责任扯皮空间。当底层链本身就把执行、存储与扩展模块纳入统一体系，机构就能用更少的外部拼装完成更完整的上链生产闭环，并把关键风险集中在可审计边界内。

当讨论从性能走向机构落地，评估维度会迅速扩展：合规、隐私、身份、数据可用性、跨域互操作、开发工具链、审计与风控接口，都会成为实际推进中的阻塞点。

04

场景落地：为什么这些能力对机构有用？

把前文的工程化抓手放回可落地的机构业务，才能看出 Pharos 的真正目标：把并行执行、存储与索引、以及模块化扩展网络组合成一套可运营的结算与资产系统。换句话说，机构并不缺更快的链，缺的是更确定、更易对账、更可控的链上工作流。

4.1 支付与清算：把 1 秒级最终性变成可运营的结算体验

支付与清算的核心是风险敞口什么时候关闭。最终性越慢、抖动越大，业务系统就必须用更长的缓冲、更高的备付金、更复杂的对账去覆盖不确定性。图 1 显示，主流网络在吞吐与最终性之间存在显著差异；对支付而言，真正的 KPI 往往是端到端确认时间分布（P50/P95/P99）与拥堵时的失败率 / 重试语义。

对支付与清算业务而言，真正的关键是风险敞口何时关闭、确认时间在高负载下是否仍可预测。当确认时间分布稳定、失败与重试语义清晰时，业务系统才能缩短缓冲周期、降低备付金占用，并将链上结算纳入自动化运营流程。

从流程上看，一笔机构级支付 / 清算通常包含：指令生成（合规校验与限额）→ 签名与广播 → 链上确认 → 内外部账务对齐 → 异常处理（失败、延迟、重复、冲正）。链的价值不只在确认更快，更在异常更可控：失败是否可解释？延迟是否可预测？重试是否幂等？这些决定了机构能否把链上交易纳入自动化运营。因此，建议在试点中把验收指标写到操作层：确认时间分位数、失败 / 重试率与错误类型稳定性、拥堵期费用与可用性曲线、以及故障恢复与对账可复盘性。

4.2 RWA：合规与隐私不是附加项，而是产品规格

RWA 的难点是把传统金融里隐含的制度结构搬到链上：谁具备持有资格、现金流如何分配、信息披露与审计如何完成、以及在合规前提下如何最小化敏感信息泄露。很多项目把合规与隐私当成外接服务，导致信任假设外溢、系统边界变得模糊。

在 RWA 场景中，合规与隐私的关键不在于是否支持，而在于其结果能否被纳入结算与审计闭环。只有当合规校验与风险判断具备可验证结果，并与资产结算状态直接关联时，机构才能在事后审计中解释每一次放行、拒绝与异常处置。这样做的价值在于：合规与隐私不再是流程承诺，而更接近可审计的系统行为。机构在评估时，应重点追问 SPN 的信任模型（谁运行、如何惩罚、如何隔离故障）、证明系统的可验证边界、以及当 SPN 异常时主网资产与业务的止损路径。

以 AquaFlux 为例，其将底层资产的现金流与风险分层拆成多种代币形态，用结构化资产的方式让不同风险偏好参与者在同一底层资产上形成可组合策略[26]。此类结构化模型往往意味着更复杂的状态更新、更频繁的合规检查与更高强度的对账需求：这也是为什么 Pharos 把 Store、Pipelining 与 SPN 组合成同一条主线，它瞄准的是结构化资产在链上的长期运营，而不仅是一次性的发行。

RWA 的复杂度来自生命周期运营：合规准入、现金流分配、信息披露、异常处置与审计举证。结构化资产越复杂，状态更新越频繁、查询维度越多、合规检查越密集。此时 Pharos Store 的意义不仅是更快写入，更是降低持续查询与持续对账的总成本；SPN 的意义不仅是能做 KYC/ 隐私，更是把合规 / 隐私计算结果纳入可验证闭环，使机构在审计中能够解释为何放行 / 为何拒绝。

4.3 交易与做市：并行执行只是起点，关键在数据层与失败语义

交易与做市类业务对链的要求通常同时出现：高并发、低延迟、可预测的失败 / 重试语义，以及可控的数据与索引成本。并行执行可以提升吞吐，但当交易密度上升、状态冲突增多时，真正影响做市体验的往往是冲突检测与回滚策略以及状态读写与索引更新的成本。

Pharos 的差异化在于把数据层放到核心叙事里（见图 8）：通过存储下推与并行化的 ADS/Merkle 与索引路径，试图降低高频场景下的读写放大与对账负担。对做市与风控系统来说，这类优化会直接影响：数据查询延迟、历史状态访问成本、以及在极端行情下的恢复时间。机构在试点中应把这些工程指标纳入验收，而不是只看 TPS。

交易与做市场景建议用两类压测验证并行执行 + 数据层的真实收益：其一热点压测（集中访问同一类状态）观察吞吐折损与失败语义稳定性；其二查询压测（高写入同时高强度历史查询与索引更新）观察查询延迟分布与索引成本曲线。只有当这两类压测能被持续复现并稳定输出，链才具备承载准生产级交易系统的基础条件。

归根结底，场景落地的检验标准很简单：Pharos 是否能把可验证的并行能力转化为一套可交付的机构级产品能力，包括稳定的确认时间、可审计的数据访问、可插拔的合规与隐私模块，以及清晰的运营与风控接口。只要这些要素在真实业务里可被度量，网络效应与合作扩张才有机会被点燃。

05

结语：评估 Pharos 的关键，是验证一条增长曲线

如果把高性能公链的竞争看成更快的交易处理，那么讨论很容易陷入 TPS 的军备竞赛；但站在机构视角，真正的竞争对象其实是结算权：谁能在合规与审计约束下，把稳定币支付、清算对账与 RWA 结构化资产的链上工作流，变成一套可持续运行的系统。也正因为如此，Pharos 的差异化不应被简化为更快的链，而应被理解为一次面向机构场景的系统工程：其全栈并行路线最终需要接受的，是在真实业务负载下，对确定性结算、数据可运营性与责任边界的持续检验。

叙事是否成立不取决于描述是否动听，而取决于能否被验证、被复现、被运营。因此，Pharos 的第一组关键点是端到端确定性：在不同负载与拥堵条件下，确认时间的分布（P50/P95/P99）、交易失败率与重试语义是否稳定可预测；当出现网络抖动或极端行情时，系统是否能以清晰可解释的方式恢复与对账。支付与清算不会因为一条链平均很快就上线，机构要的是坏情况下仍可控。

第二组关键点是数据层与长期 TCO：高频与数据密集业务最终都会把成本压力推向状态存储、索引与历史访问。Pharos 把 Store 放到核心叙事里，意味着它押注的是把瓶颈前移并结构性优化，从而降低节点硬件门槛、降低数据访问与审计对账负担。机构评估时应把数据层指标写进验收：状态膨胀曲线、查询延迟、索引更新成本、以及在真实业务场景下的对账复杂度。

第三组关键点是模块化扩展的责任边界：SPN 的价值在于把合规核验、隐私计算、专用风控等能力从通用执行路径中隔离出来，并把结果以证明或可验证形式回写主网结算体系。

同时也需要看到，全栈并行路线在提升端到端性能与可运营性的同时，也可能带来新的工程与治理权衡。一方面，更复杂的执行与数据路径可能抬高节点的硬件与运维门槛，在网络早期阶段对验证者多样性与去中心化程度形成压力；另一方面，多层协同架构在极端负载或升级过程中，对系统稳定性、故障隔离与复盘能力提出更高要求。在评估 Pharos 相关能力时，仍需结合其节点准入机制、运行数据披露与异常处置路径，审慎判断这些风险是否可被量化与管理。

因此，对机构与投资者而言，最稳妥的判断路径是以可验证指标推动限额试点—阶段验收—渐进上量。只要 Pharos 能持续交付三件事：可预测的确定性结算、可控的数据层成本、以及可审计 / 可隔离的合规模块边界，其生态扩张与合作增长才可能进入可持续正循环，并把增长红利转化为可控的收益曲线。

附录 术语表

• Finality / TTF：交易被认为不可逆的时间尺度；机构用来估算清算敞口。

• Real-time TPS：单位时间内的实时吞吐（本文口径为 1 小时窗口）。

• Max TPS (100 blocks)：在最近约 100 个区块窗口内的峰值吞吐。

• Nakamoto Coefficient：衡量最少多少实体可联合影响共识的指标（口径依赖统计方法）。

• Parallel Execution：并行执行；通过减少全局锁与冲突放大吞吐。

• EVM：以太坊虚拟机；最成熟的合约与工具生态。

• WASM：WebAssembly；通用高性能执行环境，可支持多语言。

• Modular Stack：模块化栈；把执行、存储、计算模块化组合。

• Pharos VM：Pharos 的执行层，强调 EVM+WASM 与并行执行框架。

• Pharos Store：Pharos 的存储层，强调 ADS/pushdown 降低数据与索引成本。

• ADS：Augmented Data Structures；增强数据结构，用于提升查询与索引效率。

• Pushdown：下推；将过滤 / 聚合等逻辑下推到更靠近数据的位置以降低总成本。

• SPN：Special Processing Networks；专用处理网络，用于 ZK/ 隐私 /AI 等异构计算模块。

• ZK：零知识证明；在不泄露信息的前提下证明某个陈述成立。

• MEV：矿工 / 验证者可提取价值；与排序、审查与交易成本相关。

• Subnet：Avalanche 子网；为不同业务提供隔离的性能与治理域。

• Sharding：分片；通过分区处理状态与交易实现扩容（如 NEAR 路线）。

• Restaking：再质押；将既有安全资本复用于新网络（Pharos 材料中提及 EigenLayer/Babylon）。

• TCO：总拥有成本；手续费 + 基础设施 + 数据 + 安全 + 合规的综合成本。

参考来源

[1] Pharos Docs – Pharos Modular Stack https://docs.pharosnetwork.xyz/architecture/pharos-modular-stack

[2] Pharos Docs – Pharos VM (EVM + WASM) https://docs.pharosnetwork.xyz/core-technologies/pharos-execution/pharos-vm

[3] Pharos Docs – Pharos Store (ADS pushdown) https://docs.pharosnetwork.xyz/core-technologies/pharos-store

[4] PRNewswire – Pharos launches Testnet (includes 30,000 TPS, ~1s finality claims) https://www.prnewswire.com/news-releases/pharos-launches-testnet-accelerating-global-payments-with-eigenlayer-and-babylon-restaking-302602484.html

[5] Pharos Blog – Pharos launches Testnet (performance and positioning) https://pharosnetwork.xyz/blog/pharos-launches-testnet-accelerating-global-payments-with-eigenlayer-and-babylon-restaking

[6] Chainspect – Solana metrics dashboard https://chainspect.app/chain/solana

[7] Chainspect – Sui metrics dashboard https://chainspect.app/chain/sui

[8] Chainspect – Aptos metrics dashboard https://chainspect.app/chain/aptos

[9] Chainspect – Sei metrics dashboard https://chainspect.app/chain/sei

[10] Chainspect – NEAR metrics dashboard https://chainspect.app/chain/near

[11]. Chainspect – Avalanche metrics dashboard https://chainspect.app/chain/avalanche

[12] Chainspect – Ethereum metrics dashboard https://chainspect.app/chain/ethereum

[13] Chainspect – Pharos (listing/placeholder) https://chainspect.app/chain/pharos

[14] Foresight News – Pharos testnet news (30,000 TPS, 1s finality mention) https://foresightnews.pro/news/detail/39840

[15] The Block – Pharos seed round news (background) https://www.theblock.co/post/277212/pharos-raises-8-million-seed-round-led-by-lightspeed-faction-hack-vc

[16] Solana Docs – Architecture / runtime overview (background) https://docs.solana.com/

[17] Sui Docs – Sui architecture and object model (background) https://docs.sui.io/

[18] Aptos Docs – Aptos architecture and Move/parallel execution (background) https://aptos.dev/

[19] Sei Docs – Sei network overview (background) https://docs.sei.io/

[20] NEAR Docs – NEAR protocol overview (background) https://docs.near.org/

[21] Avalanche Docs – Avalanche consensus and subnets (background) https://docs.avax.network/

[22] Ethereum.org – Ethereum proof-of-stake and finality (background) https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/

[23] EigenLayer – Restaking overview (background for Pharos testnet positioning) https://docs.eigenlayer.xyz/

[24] Babylon – Bitcoin staking / restaking overview (background) https://babylonchain.io/

[25] MetaEra/Paragraph – AquaFlux on Pharos (reference reading) https://paragraph.com/@metera/aquaflux-zh

[26] AquaFlux Launches on Pharos Testnet, Advancing Structured RWA

https://paragraph.com/@menews/aquaflux-launches-on-pharos-testnet-advancing-structured-rwa

核心贡献

作者：pixelpanda (X：@realgc193222)

审校：Colin Su、Grace Gui、NingNing、Owen Chen

设计：Alita Li