先理解设计要解决的问题
区块链把交易记录与分布式协作规则结合起来。入门时可以沿着三个问题理解：数据怎样组织，什么样的更新才有效，节点意见不同时如何选择共同历史。这三个问题分别对应数据结构、验证规则和共识机制，不能只靠把数据串成链来解决。
数据结构：哈希链接与交易摘要
比特币开发者指南描述了两种关键关联：区块头引用前一区块头的哈希，交易则通过默克尔树汇总到区块头。修改历史交易会影响相关摘要及后续链接；默克尔路径可用于核验交易是否被收录。
理解这种结构时，要区分收录证明与有效性验证。证明一条记录存在于区块中，并不能单独证明它满足全部交易规则。设计数据接口时，也应明确接口返回的是原始记录、摘要，还是可供验证的证明。
交易模型：明确状态更新规则
比特币用未花费交易输出，即UTXO，描述可被后续交易使用的输出。同一输出不能在有效链中被重复花费。这个例子说明，交易验证需要结合已有状态，不能只检查消息格式。
入门设计应先说明系统记录什么状态，以及一笔交易可以怎样改变它。区块负责组织记录，状态规则负责判断更新是否合法。UTXO是具体模型，不宜直接当作所有区块链的统一结构。
共识：出块与分叉选择需要配合
以太坊共识文档将共识解释为协议、激励与规则的组合。工作量证明和权益证明承担抗女巫攻击及出块者选择等作用，完整机制还需要分叉选择。比特币比较有效链的累计工作量；以太坊的相关投票权重与质押余额有关。
因此，比较共识方案不能只看名称，还要问：参与者凭什么获得权重，节点如何独立验证，出现竞争分支时依据什么作出选择。复制一个出块流程，并不意味着已经得到完整的共识设计。
适用条件与常见问题
这些概念适合用于理解多个节点共同维护、独立验证记录的系统。具体项目采用什么交易模型、参与权限和安全假设，需要分别确认，不能把比特币或以太坊的机制直接推广到所有系统。
哈希相连是否意味着绝对不可修改？哈希让修改能够被检测，抵抗历史改写还依赖共识及其安全条件。区块高度能否唯一标识区块？分叉时同一高度可能出现不同区块。所谓最长链是否就是区块最多？在比特币语境下，应理解为有效候选链中累计工作量最大的链。