先按职责理解架构
区块链开发架构可以按几个问题来理解：数据如何记录，节点如何验证，业务逻辑在哪里执行，应用如何访问网络。这是一种阅读技术文档的方法，并非所有区块链都遵循同一套固定分层。理解术语时，应同时确认它解决什么问题、属于哪个系统。
账本层：交易、区块与哈希
比特币开发指南将区块链描述为有序的交易记录：区块通过前一区块头的哈希关联，交易哈希汇聚成默克尔根；可花费的交易输出称为UTXO。节点验证区块，并在有效分支中依据累计工作量选择链。
交易是账本记录的基本对象，区块负责组织记录，哈希用于建立可校验的关联。默克尔树支持用部分哈希验证交易是否被包含在区块中，但包含证明本身不等于对全部交易规则的验证。UTXO模型适用于比特币等采用此结构的系统，不能直接套用为所有区块链的余额模型。
网络层：节点、客户端与共识
节点是参与网络的运行实例，客户端是其运行的软件。共识涉及分布式参与者如何按照规则形成一致的账本视图；验证则回答某笔交易或某个区块是否满足规则。两者相关，但关注点不同。
区块高度表示区块在链上的位置。发生分支时，同一高度可能出现不同区块，所以高度不能独自充当全局唯一标识。讨论记录是否稳定，还需要结合具体网络的共识机制。
执行与接口：合约、EVM、Gas和JSON-RPC
以太坊开发文档涵盖账户、交易、EVM、Gas、智能合约及客户端接口。合约承载链上程序，EVM提供执行环境，Gas计量执行所需资源；JSON-RPC等接口让应用与节点交互，开发网络和框架支持测试与开发。
这些术语处于不同职责位置：合约表达逻辑，执行环境处理逻辑，资源计量约束执行成本，接口传递请求。JSON-RPC本身不承担共识职责；开发框架也不会替代节点对交易的验证。EVM相关概念应放在以太坊或兼容执行环境中理解。
常见问题：应用是否全部运行在链上
去中心化应用仍可包含前端、链下数据处理和存储组件。判断架构时，应明确哪些状态由链上规则维护，哪些信息来自外部服务。预言机处理外部信息进入链上的问题，存储组件处理数据保存问题，二者不能仅因都服务于应用就混为一谈。
本地开发网络适合调试和重复测试，但测试通过不代表已经覆盖公开网络的全部条件。阅读架构图时，把每个组件对应到记录、验证、执行或交互职责，再检查组件之间的依赖，通常比孤立记忆缩写更容易理解。