一、性能需求是否定义清楚
讨论区块链开发方案有哪些常见问题，首先要区分吞吐量、响应速度和最终确认时间。以太坊扩容文档将提升处理能力与保持安全、去中心化共同作为目标。开发方案如果只写“高性能”，便难以判断是否适合实际业务。
对于频繁提交操作的应用，应分别定义提交后的反馈时间、持续处理能力和业务认可的确认条件。界面显示已接收请求，不应直接代表链上操作已最终确定。
二、扩容方案是否混淆了安全边界
以太坊扩容文档区分链上扩容和链下扩容。Rollup、状态通道、侧链等方案的验证与结算方式不同；侧链使用自己的共识机制。方案能连接以太坊，并不意味着其全部安全条件都与主网一致。
选型时应说明由谁处理操作、如何验证结果，以及参与方失效后如何处理。适用性需要结合参与者范围、交互频率和结算需求判断，不能仅按处理速度排名。
三、数据可用性是否被忽略
Rollup与Validium的重要区别涉及数据保存位置：前者向第一层发布相关数据，后者将数据保留在链下。有效性证明和数据能否被取得，是评估方案时需要分别理解的问题。
如果应用依赖历史记录核验或状态恢复，就应明确需要哪些数据、从何处取得，以及数据无法访问时哪些功能会受影响。不能把“结果可验证”直接等同于“所需数据始终可读取”。
四、是否把区块收录视为绝对不可逆
比特币开发指南说明，网络可能暂时出现竞争区块，节点依据累计工作量选择有效链。因此，交易进入某个区块后仍可能受到链重组影响，同一高度也可能对应不同区块。
适用于比特币类确认机制的业务，应区分待确认、已收录和达到业务确认要求等状态，并设计重组后的记录更新流程。跨链开发时，也不能直接套用另一条链的确认规则。
五、账本索引和验证职责是否明确
比特币通过未花费交易输出约束重复花费，全节点独立验证区块；默克尔证明则用于核验交易是否包含在某个区块中。这些机制解决的问题不同，包含证明并不等同于对全部共识规则的验证。
开发方案应明确应用自行验证哪些内容、依赖节点提供哪些结果。保存区块记录时，应使用区块哈希识别具体区块，避免仅按高度认定其唯一性；处理交易记录时，则要保留与实际确认状态一致的业务关联。