架构讨论的适用范围
区块链技术公司架构涉及哪些技术概念，首先取决于公司提供什么服务。运行基础设施、开发链上应用和提供历史数据查询，关注的技术环节各有侧重。这里讨论软件与基础设施架构；以太坊和比特币的机制用于说明概念，不能直接套用于所有区块链。
节点、客户端与网络通信
以太坊开发者文档将节点解释为联网运行的客户端实例。其节点由执行客户端与共识客户端协作：前者执行交易、维护状态，后者处理权益证明共识；参与验证者职责还需要相应软件。文档也区分全节点、归档节点与轻节点，并介绍通过接口访问节点的方式。
架构设计需要区分软件、运行实例和业务入口。客户端是协议实现，节点是运行这些软件的实例，应用通过接口使用节点能力。点对点网络承担节点间的数据传播，业务接口则承担应用与节点之间的交互，两者服务的对象不同。
哈希、账本与共识规则
比特币开发者指南说明，区块通过前一区块头的哈希连接，交易通过默克尔树汇总。全节点依据共识规则验证数据，交易输入引用未花费交易输出，即UTXO；工作量证明与链选择规则共同支撑交易历史的一致性。
这些概念分别回答数据如何关联、交易是否有效、不同节点如何选择共同历史等问题。默克尔证明可以用于核验交易是否被区块收录，但单凭收录证明，不能替代完整的交易与区块有效性验证。哈希连接也需要结合共识机制理解，不能据此推导出历史绝对不可改变。
执行状态与数据存储
交易记录描述发生了什么，状态表示执行后的结果。理解二者的区别，有助于拆分业务需求：查询某笔交易与查询某个历史时点的账户状态，对底层数据的要求并不相同。
需要频繁查询历史状态的服务，通常更适合配置归档能力；主要验证新区块和访问近期状态的服务，可以评估全节点。轻客户端通过较少数据和证明开展验证，其适用性取决于具体协议与实现，不能默认具备全节点的全部验证能力。
接口边界与常见问题
公司是否必须自行运行节点？这取决于独立验证、数据控制和维护资源等要求。第三方接口可以提供链上访问能力，自建节点则让业务直接使用自身验证的数据；两种方式形成不同的外部依赖。
节点是否就是验证者？二者不能等同，运行节点不必然承担区块提议或共识投票职责。全节点是否保存全部历史状态？也不能这样理解，历史状态保留范围受客户端配置和裁剪策略影响。明确这些边界，才能让接口功能、存储能力与业务需求相匹配。