区块、哈希与默克尔树
区块链首先涉及记录如何组织和验证。比特币把交易放入区块，通过前一区块的哈希连接历史；区块内的交易哈希逐层汇总，形成默克尔树根。哈希可以理解为用于核对数据的摘要，默克尔树则支持验证某笔交易是否被包含在区块中。
这类验证回答的是“记录是否匹配、是否被收录”。例如，证明一条业务记录已经上链，与证明记录描述的现实事件真实发生，是两个不同的问题。
节点、共识与交易模型
比特币全节点独立验证区块，共识规则规定哪些记录可以接受。工作量证明让构造区块需要计算投入；出现竞争分支时，节点依据累计工作量选择有效链。其交易使用未花费交易输出，即UTXO，并限制同一输出被重复花费。
因此，交易被传播、被收录和获得后续区块支持，代表不同阶段。理解应用显示的状态时，需要先知道它对应哪个阶段，也不能将比特币的交易模型直接套用于所有区块链。
智能合约、虚拟机与Gas
在以太坊中，智能合约是位于特定地址的代码和状态。用户通过交易调用合约功能，程序经编译后由以太坊虚拟机执行；部署和执行涉及Gas资源计量及费用。合约还可以调用其他合约，形成组合功能。
可以把业务流程拆成输入、条件判断和状态更新：满足条件后，程序执行相应规则。这种自动化适合能够明确编码的逻辑，但代码是否准确表达业务要求，仍需要单独检查；“自动执行”本身不代表业务设计正确。
预言机与多签的适用条件
智能合约不能自行获取链外事件信息，依赖外部事实的应用需要预言机提供数据。多签合约则要求达到设定数量的有效签名才可执行，适用于需要多方共同授权的场景。
两者解决的问题不同：预言机连接外部信息，多签分配操作权限。理解一个应用时，可以分别追问数据由谁提供、操作由谁批准，避免把数据可靠性与授权安全混为一谈。
常见问题：上链是否意味着绝对可靠
不能仅凭“已经上链”作出这种判断。历史记录的验证机制、合约规则以及外部数据质量，需要分别理解。比特币的工作量证明与UTXO、以太坊的虚拟机与Gas都有各自适用范围；具体应用采用哪些机制，应以其实际设计为准。