讨论范围：从技术能力判断扶持方向
这里的扶持主要指对公链研发、基础设施和应用建设的支持，不涉及具体补贴政策。以太坊扩容文档强调性能提升应兼顾安全与去中心化；比特币开发指南说明独立验证、共识规则和分叉处理的作用。两类技术材料可以帮助建立评估思路，但不能直接证明某项扶持措施有效。
误区一：吞吐量越高，发展质量就越好
每秒处理交易的数量只是性能的一部分，还需区分交易处理速度与最终确认时间。若扶持目标只围绕峰值吞吐量，便容易遗漏节点运行成本、安全条件与实际使用体验。评估时应说明测试负载、硬件要求和确认口径，避免把条件不同的结果直接比较。
误区二：扩容只能靠改造主链
扩容可以涉及主链协议，也可以把部分处理移到链外。扶持研发时，应先明确瓶颈位于执行、数据承载还是其他环节，再判断是否需要修改底层协议。对于应用建设，采用合适的扩容设施也是可考察的方向，不能把改动主链的规模当作技术价值的尺度。
误区三：连接主链就拥有相同安全性
以太坊扩容文档区分了从主网获得安全保障的二层方案，以及采用其他安全安排的方案。Rollup、侧链和Validium在验证与数据存放方式上存在差异。评估支持对象时，需要问清谁验证状态、数据在哪里、争议如何处理，不能仅凭“兼容”或“桥接”判断安全程度。
误区四：节点多就必然足够去中心化
节点数量需要结合独立验证能力和参与门槛理解。比特币全节点按共识规则验证区块，说明节点的作用并非单纯保存副本。支持基础设施时，除了部署数量，还应考察运行成本和控制权分布；同一主体管理的大量节点，不能仅凭数量证明参与主体足够分散。
误区五：交易入块就绝不可能改变
比特币开发指南解释了竞争区块和分叉选择，表明交易进入区块不等于立即排除后续重组的可能。扶持应用建设时，应要求应用按所用网络的确认机制设计状态提示和异常处理。不同共识机制的条件不同，不能把一种网络的确认经验直接套用到所有公链。
常见问题：如何确定支持重点
是否所有应用都需要最高吞吐量？应由实际需求决定，同时明确确认时间、费用和安全要求。是否一套扩容方案能够覆盖所有场景？不同方案的验证方式和适用条件存在区别，应逐项评估。较清晰的做法是先写明问题与约束，再检查方案能否在这些条件下提供可验证的改进。