底层系统需要解决什么问题
理解区块链底层，可以围绕三个问题展开：记录怎样组织，操作怎样验证，多台节点怎样接受一致的历史。密码学提供验证工具，数据结构组织记录，交易规则约束状态变化，网络与共识机制协调节点。不同区块链对这些问题有不同实现，不能把某条链的设计直接推广到所有系统。
哈希、区块与默克尔树
比特币区块头引用前一区块头的哈希，并通过默克尔根关联区块内的交易。哈希将数据映射为摘要；默克尔树逐层组合摘要，使交易包含关系可以借助一条验证路径检查。
这里需要区分两类验证：证明某笔交易被记录，与证明这笔交易符合规则。前者回答“是否包含”，后者还需检查交易输入等条件。哈希也不等于加密，数据经过哈希并不意味着原始记录获得保密性。
交易模型与账户状态
比特币使用未花费交易输出，即UTXO，描述可供后续交易使用的输出，已经花费的输出不能再次使用。以太坊则以账户组织余额等状态；账户nonce参与交易顺序约束，合约账户还关联代码与存储。
两类模型都需要判断一次操作能否从既有状态合法推进到新状态。区别在于验证所依据的数据组织方式：理解UTXO需要追踪输出的使用关系，理解账户模型需要关注账户字段及其变化。跨系统比较时，应先明确采用哪种状态模型。
节点、共识与历史确认
比特币全节点独立验证区块，并在有效候选链中依据累计工作量选择链。工作量证明要求区块头哈希满足目标条件；网络传播过程中可能出现暂时分叉。
因此，共识包含规则验证与历史选择两个层面。计算工作量不能替代交易有效性检查，收到区块也不等于永久确认。讨论历史修改难度时，需要结合具体共识机制及其安全条件，不能仅凭区块之间存在哈希连接，就断言记录绝对不可修改。
密钥、合约与常见边界
以太坊外部账户使用密钥签署交易，合约代码在执行环境中处理调用。钱包是与账户交互的应用界面。数字签名用于验证授权关系，合约逻辑规定调用能够产生哪些状态变化。
钱包、账户与链上资产记录分别属于交互工具、状态实体和账本信息，理解时应加以区分。同样，交易获得授权与执行符合规则也需要分别检查：有效签名不能自动保证余额充足或合约条件满足。学习底层系统时，将数据、授权、执行和共识串联起来，才能理解节点为何接受或拒绝一次状态更新。