一、应用需求是否适合区块链
研究应先说明需要解决什么问题，而不是先选技术。比特币开发者指南展示的是一种按顺序记录交易、由节点独立验证的公共账本机制。应用研究可以据此追问：参与方是否需要共同核验记录？是否需要识别重复使用同一笔资产的行为？
如果需求只是提高处理速度，不能仅凭“分布式”就认定区块链更合适。应先明确参与者、验证规则和可接受的等待时间，再判断这种账本机制是否匹配业务。
二、难以篡改是否等于事实真实
区块通过哈希关联，修改历史交易会影响后续关联；比特币还通过工作量证明提高改写历史的成本。因此，“不可篡改”不宜理解为任何条件下都绝对无法改变。
这里要区分两个问题：记录写入后是否容易被改动，以及记录描述的事情是否真实。交易验证规则不能直接证明现实世界中的商品、身份或事件；涉及这些对象时，研究还需单独交代信息如何进入系统、由谁核验。
三、共识是否意味着不会出现分叉
比特币网络可能同时出现相同高度的不同区块。节点在有效候选链之间依据累计工作量作出选择，因此区块高度不能作为全局唯一标识。
应用设计应区分“收到交易”“交易进入区块”和“达到所需确认程度”。研究报告如果只记录第一次出现交易的时间，就不足以说明后续处理所需的稳定性。
四、扩容应该比较哪些指标
以太坊扩容文档将提高交易处理能力与保持安全、去中心化联系起来。吞吐量关注单位时间处理多少交易，最终确认时间关注结果何时获得相应保障，两者不能混用。
比较方案时，应交代交易类型、网络负载和确认口径，同时考察费用与节点运行门槛。缺少这些条件，单一速度数字很难说明方案是否适合实际应用。
五、链下方案是否具有相同安全性
不能把所有链下处理都视为相同的第二层方案。Rollup在主链之外执行交易，并向主链提交相关数据；侧链采用自身的共识规则；Validium使用有效性证明，但数据不存放在主链上。
研究重点应落在信任条件：谁负责处理交易，数据能否取得，出现争议时如何验证。方案与主链发生交互，并不意味着其全部环节自动获得同等安全保障。
六、怎样形成有边界的研究结论
较完整的结论应同时写明解决的问题、成立条件和未解决的限制。例如，讨论降低费用时，也要说明确认与数据可用性的要求，而不能直接推导出全面优于其他方案。
技术机制能够支持什么，与某个具体系统是否正确实现，是不同层次的问题。应用研究应把机制解释、测试结果和部署条件分别表述，避免将一般原理写成具体项目已经验证的成效。