先明确业务需要的确认标准
讨论区块链创新系统需要注意哪些问题，首先要区分交易提交、被打包与最终确认。界面快速显示成功，并不能单独说明交易已经获得相应的结算保障。系统应明确每种状态的含义，以及何时允许后续业务依赖该结果。
吞吐量反映单位时间内处理交易的能力，确认时间反映结果需要等待多久。高频交互与最终结算关注的指标可能不同，设计时应分别评估，避免用单一速度指标概括整个系统。
扩容方案需要说明安全来源
以太坊扩容文档区分了依托主网安全的二层方案与采用不同安全机制的其他链外方案。Rollup将执行移到链外，并向主网提交相关数据；侧链则采用自身的共识规则。Validium使用有效性证明，但将数据放在主网之外。
因此，方案评估需要回答：谁验证状态变化，验证依赖哪些数据，参与者能否取得这些数据。存在跨链连接或兼容同一种执行环境，均不足以说明两个系统具有相同的安全保障。
保留独立验证能力
比特币开发指南说明，全节点按照共识规则独立验证区块，交易输出不能被重复花费，区块之间通过哈希关联。发生竞争分支时，节点在有效链中依据累计工作量选择链，因此区块高度不能充当全局唯一标识。
这些机制提示系统设计者：记录可以被查询，与记录通过规则验证，是两个不同要求。业务接口应清楚说明返回的是节点观察结果、区块收录状态，还是达到业务确认条件的结果，并为链重组预留状态修正机制。
数据与节点成本决定实际可用性
扩容还要考虑验证者需要承担的存储、带宽和计算负担。若提升处理能力的同时显著抬高节点运行门槛，独立参与验证的难度也会增加。对于依赖链外数据的设计，还需要明确数据由谁保存、如何获取，以及数据不可用时哪些操作会受影响。
面向多个应用的共享网络与专用网络具有不同的需求边界。评估成本时，应覆盖执行、数据提交和结算等环节，而不能只比较一次操作显示的费用。
常见问题与适用条件
链外处理是否都属于二层扩容？按上述以太坊文档的分类，需要看其是否从主网获得安全保障，不能仅凭执行位置判断。状态通道适用于参与方能够按通道规则进行链外交互、再向主网结算的场景，并非所有应用都适合这一模式。
区块链是否保证历史绝对无法改变？哈希关联和共识机制为改写历史设置约束，但系统仍需考虑分叉及相应的确认规则。创新方案应把这些条件写入技术说明和业务状态设计，使性能目标与实际保障保持一致。