Stellar的Project Thruput给出了每秒702万笔支付的早期基准，但这笔成绩尚未经过完整网络的共识路径。10月29日的报道确认，预览运行在FutureNet；公开的Whitney仓库则把测量边界写得更直接：执行器处理签名转账，区块提交到数据库和事件服务，路径里还没有共识与交易内存池。[2][3] 对支付应用而言，这项进展值得关注的原因，是同一账户的高并发可能获得新的处理方式；把它直接当成Stellar主网已经能承载的业务量，会跳过决定到账体验的其他环节。
先把八台执行主机放回测试环境
Whitney公布了两条横向扩展曲线。100个发送账户的高竞争负载，从一台执行主机的每秒118万笔升到八台的702万笔；一万个账户的低竞争参考负载，则从116万笔升到633万笔。每个值取三次独立新建集群运行的中位数，执行主机使用同一区域可用区中的指定云实例，另外还有发送器、数据库和事件服务三台支持主机。[2] 因此，八台指的是执行主机，不能写成整个验证者系统只需要八台机器。
这也解释了为什么两组结果应一起看。少量账户能刻意制造热点写入，适合检查多个交易争用状态时，执行方式是否仍能扩展；更多账户提供另一种负载分布。702万和633万是不同测试条件的结果，不能任取一个数字代表所有支付流量。哪组更贴近一家支付商，需要看其发送方、收款方以及合约状态访问的实际分布，账户数量本身不足以给业务真实性排次序。
两条曲线在执行主机增加到后段时，都没有维持与硬件数量同比增长的速度。[2] 这不抹掉扩展收益，但会改变运营预算：为了下一段吞吐增加的设备，可能带来更小的边际产出。判断单位支付成本，还需要实例价格、运行利用率及支持服务开销，不能只把峰值吞吐除以执行主机数就当作完整成本。
原文摘录排版，非网页截图。摘录来自Whitney仓库README，说明该基准衡量执行核心的扩展潜力，不是完整网络吞吐声明。[2]
热点账户能够并行，不意味着余额约束被取消
TokenPost对模型的说明是：交易从相同的账本快照开始，能够并行运行，包括触及同一状态的交易；提交时再合并兼容的变更。[3] 这给收付款密集的场景提供了不同的优化方向。许多用户同时向一个商户账户转账时，瓶颈可能来自共同更新同一余额。若系统可以表达和合并兼容更新，应用便不必先为了性能把一份业务状态拆散。
但“兼容”包含约束。用一个简单的假设说明：两笔支出分别在自己的执行视角里成立，并不能保证合并之后总支出仍小于可用资金。系统仍须决定哪些变化可以共同提交，哪些需要拒绝。这是机制解释，不是本次测试对所有边界情况的证明。真实合约还可能涉及限额、撤销和多个资产之间的条件，支付转账基准覆盖不了全部业务逻辑。
所以，工程评估需要把热点类型说清楚。只是同时增加同一个收款余额，与同时消耗一份有限库存，虽然都触及共享状态，冲突的经济含义不同。项目方提供的并行模型值得拿业务负载验证，但不能从一组转账成绩推定订单撮合、借贷清算和复杂组合交易都会取得相同倍数的提升。
相关下载： Binance全球顶级交易所 v3.22.3大小：306.0M
执行并行的概念插图，不代表实测设备数量、网络拓扑或已上线主网架构。
从执行完成到收款可用，还要补哪些证据
仓库说明测试包含签名转账，以及区块在数据库和事件服务中的开启、关闭与提交；同时明确，没有共识与交易内存池。存储采用tmpfs，主机扩展测试的每个区块包含400万笔交易。[2] 这些条件必须和性能数字放在一起读。内存型文件系统的处理结果，不能独自回答持久化介质、重启恢复与历史增长给长期运行带来多少负担。
完整支付能力要以端到端确认和业务可用为准，执行核心的峰值只是其中一段。客户端提交、流量接入、节点之间传递和达成一致，都可能限制最终服务能力。某段执行变快之后，系统瓶颈也可能移向另一段；这不是对该模型失效的断言，而是不能省略的验收条件。
大区块条件还提醒应用方区分吞吐和等待时间。单位时间完成很多交易，并不自动代表每笔交易都很快完成。对需要即时确认的商户，一组不同负载下的延迟分布、失败率和积压恢复时间，往往比单一最高值更能支持服务承诺。本次公开结果不足以据此填写商用到账时限，也没有给出现有主网已经采用同一执行路径的证明。
能够推翻谨慎判断的证据也很具体：完整网络条件下可重复的结果，真实持久化与故障恢复的测试，以及应用负载下的确认延迟。如果后续资料补齐这些部分，才有理由把执行潜力进一步换算为业务容量；在此之前，既不应把基准当作商业交付，也不必因它尚属预览就否定可测量的工程进展。
免费交易把关注点移向资源分配
性能之外，预览还介绍了另一项安排。根据TokenPost报道，模型不按每笔交易收取费用，但gas仍用于计量和限制单笔执行；当需求超过容量时，调度份额取决于账户未锁定的原生代币余额，存储数据需要可退还的代币锁定。[3] 这几项机制同时存在，意味着“没有逐笔收费”不能被理解成无条件占用资源。
对持续发起支付的企业，预算因此可能由按笔付费转向持有和锁定资源的资金安排。若一部分代币因存储而锁定，它与未锁定余额的调度作用就需要分别核算。实际需要持有多少、负载骤增时能得到多少份额、删除数据后怎样释放资金，都应由最终规则与业务实测确认。仅凭原则性介绍，还不能得出某种支付规模的资本需求。
相关下载： 欧易okx交易所 v6.195.1大小：549.4M
这也约束了代币估值推论。报道使用的是“原生代币”口径，预览没有提供主网推出日期。[3] 即使未来存在资源持有需求，需求大小仍取决于最终部署关系、可用容量、账户分配办法和应用使用情况。把702万笔直接写成XLM价值捕获已经增加，既缺少部署依据，也缺少从使用量到持币需求的量化链条。
当前更适合保存的是一份可复核的观察顺序：先确认代码与测试条件，再等待完整网络的结果，最后比较具体应用在高峰期的费用、资源占用与确认质量。Whitney已经把公开结果和复现说明放进仓库；本文核对了说明及结果表，没有运行云端复现实验。[2] 下一次值得更新结论的材料，是补上缺失环节的测量，而不是把同一个执行峰值换一种说法再报一遍。
用户评论