架构讨论的适用范围
区块链技术公司架构涉及哪些技术概念，首先取决于公司提供什么服务。节点基础设施、钱包和区块浏览器涉及不同的数据访问需求。这里讨论支撑这些服务的软件技术架构；以太坊和比特币的实现各有特点，不能把某条链的设计直接视为所有公司的标准方案。
节点、客户端与网络连接
以太坊开发文档介绍，节点通过运行客户端软件加入点对点网络。执行客户端处理交易执行和状态数据，共识客户端负责权益证明共识相关工作；验证者软件承担额外的共识参与职责。全节点、归档节点与轻节点在数据保存和验证方式上也有区别。
理解这些概念，可以把企业架构拆成网络接入、执行、共识和数据服务等职责。运行节点不等于运行验证者，提供查询服务也不意味着必须参与出块。模块之间的边界应由实际服务需求确定。
区块、哈希与共识规则
比特币开发指南说明，区块通过前一区块头的哈希相连，交易通过默克尔树汇总到区块头。全节点独立验证规则，交易使用未花费交易输出，即UTXO；工作量证明及累计工作量参与有效链的选择。
这些机制分别回答数据如何关联、交易如何验证、出现竞争分支时如何选择历史等问题。哈希关联能让修改留下可检测的变化，但系统对历史修改的抵抗能力还依赖共识机制，不能仅凭使用哈希就认定数据绝对不可更改。
执行模型与数据服务如何衔接
以太坊的EVM执行与比特币的UTXO验证代表不同的处理模型。设计业务接口时，需要先明确目标网络怎样表达和验证状态变化，再确定应用读取哪些数据。
节点接口可作为应用访问链上数据的入口。常规状态查询与历史状态查询的要求不同：若服务需要频繁查询过去某一时点的状态，架构就要考虑历史状态的保留能力，而不能只确认节点已经同步。
适用条件与常见问题
是否每家公司都需要自建节点？取决于是否需要自行验证数据，以及能否承担节点维护。第三方接口也是接入方式，但会引入对服务提供方可用性和数据响应的依赖。
全节点是否等于归档节点？两者的数据保留目标不同，完整验证能力不代表所有历史状态都能直接查询。区块高度是否能唯一标识区块？分叉时同一高度可能出现多个区块，定位具体区块需要结合区块哈希。