先确定业务结构的讨论范围
区块链业务结构涉及应用如何接入网络、读取数据，以及依据链上状态更新业务记录。这里讨论技术与数据流程，不涉及企业股权或商业模式。设计时应先明确：需要查询当前状态、追溯历史，还是独立验证数据；不同需求对应不同的基础设施。
节点职责与业务职责如何划分
以太坊节点与客户端文档说明，执行客户端负责交易执行及状态维护，共识客户端负责共识相关工作；参与验证者职责还需要相应软件。运行节点与成为验证者是不同的角色。
业务架构可以据此划分接入、状态读取和业务处理的边界。节点验证协议规则，应用仍需定义自身的处理条件。例如，读到一条链上记录后，是否更新业务状态，需要应用明确判断，不能仅凭接口返回成功。
数据保留是否满足实际查询需求
节点能够验证数据，不代表它始终保存全部历史状态。以太坊文档区分全节点与归档节点，后者面向历史状态查询；不同客户端与配置的数据保留能力存在差异。
仅查询当前状态与频繁查询过去某个区块时的状态，属于不同需求。结构设计应把历史交易记录、历史状态和业务检索要求分别列清，再核对节点或服务的支持范围，避免把历史查询能力作为默认条件。
确认流程怎样应对分叉
比特币开发者指南说明，全节点独立验证区块，网络可能出现竞争分支，并依据有效链的累计工作量选择链。同一高度可能对应不同区块，因此高度不适合作为全局唯一标识。
业务流程应区分已提交、已纳入区块与满足确认条件等状态，同时考虑链重组后的记录校正。关联数据时可保留区块哈希，避免只按高度匹配。确认条件需要结合所接入网络的机制制定，不能直接把比特币规则套用于以太坊。
外部服务依赖与常见误区
自行运行节点能够增强独立验证能力，但需要承担维护与资源成本；第三方接口则引入服务可用性和数据访问方面的依赖。选择时应明确故障后哪些功能受影响，以及如何核对返回的数据。
常见误区是把多个接口等同于多个独立来源。如果接口依赖同一后端，故障仍可能同时发生。另一个误区是认为链上验证可以证明现实业务内容真实：协议验证约束链上记录的有效性，线下信息如何采集、由谁提交，仍需在业务结构中单独明确。