一、把“3.0”当作统一技术标准
“区块链3.0”不能直接说明一个应用采用什么架构，也不能证明它具备更高性能或更强安全性。讨论这类应用时，应落实到交易如何执行、结果如何验证、数据如何提供等具体问题。这里围绕扩容与预言机解释通用技术边界，不把版本标签视为项目能力的证明。
二、把速度快等同于扩容成功
以太坊扩容文档强调，扩容需要兼顾吞吐量、最终确认速度、安全和去中心化。文档也区分了依托主网安全的Layer 2与采用独立共识的侧链。
因此，“每秒能处理多少交易”不足以完整描述体验。应用还需区分提交成功、执行完成与最终确认；比较性能时，要明确交易复杂度、网络负载和确认条件。节点运行门槛也是判断扩容代价的一部分。
三、把所有链外方案视为同一种Layer 2
交易发生在主链之外，并不意味着安全保障相同。Rollup、状态通道和侧链的验证方式、参与条件与结算机制存在差异，不能仅凭“链外处理”归为同一安全等级。
选择适用方案时，应追问谁能验证状态、验证所需数据在哪里、运营方停止服务后如何处理。频繁交互与通用应用执行的需求不同，技术名称本身不能替代这些条件。
四、认为接入预言机就获得绝对真实的数据
Chainlink数据馈送文档介绍了聚合外部数据并供应用读取的机制，同时要求关注更新延迟、服务中断及异常值。它还区分了不同馈送类型和自主管理部署的责任范围。
预言机解决的是外部数据进入合约的问题。多来源聚合不能让应用忽略数据口径、时间和适用场景。合约读取到一个值，也不代表这个值足够新，或适合当前业务判断。
五、认为智能合约上线后无需维护
自动执行仍然依赖正确的输入和有效的运行条件。对于依赖数据馈送的应用，异常值检查、更新状态监测以及服务中断时的处理逻辑，都属于系统设计的一部分。
常见问题是：使用代理合约后是否可以停止关注升级？代理可以降低底层聚合器更换对接入的影响，但应用仍需理解配置和权限。部署在Layer 2上的数据应用，还应考虑排序器中断及恢复阶段对业务执行的影响。