账本、区块与哈希：记录如何关联
比特币开发者指南将区块链解释为有序记录交易的公共账本。区块通过前一区块的哈希相连；哈希可理解为数据的摘要。修改历史交易会影响相关区块及后续连接。默克尔树则把多笔交易的摘要逐层汇总，支持验证某笔交易是否包含在区块中。
放到应用语境中，这些术语回答的是记录如何组织、内容是否发生变化。核对一份文件的摘要，可以帮助判断内容是否一致；但文件描述的现实事件是否真实，仍需要其他证据。
节点、共识与工作量证明：规则如何一致
在比特币中，全节点独立验证区块，共识规则规定哪些记录有效。工作量证明要求区块满足计算难度条件；出现竞争分支时，节点在有效链中遵循累计工作量最大的链。UTXO指尚未花费的交易输出，用于判断哪些输出还能作为交易输入。
这些概念各有范围：UTXO描述比特币的交易记账方式，工作量证明描述其共识机制的重要组成部分。理解其他区块链应用时，需要核对实际采用的规则，不能直接套用比特币的全部机制。
智能合约、Gas与可组合性：规则如何执行
以太坊开发文档中的智能合约，是部署在链上特定地址的代码和状态。用户可通过交易调用其功能；部署和执行相关操作需要支付Gas费用。合约还能调用其他合约，这种能力称为可组合性。
理解业务中的合约，可以分别看输入条件、权限与状态变化。例如，一项审批规则需要说明谁能提交、谁能批准、批准后改变什么记录。代码自动执行的前提，是这些条件能够被程序明确判断；“智能”并不表示程序能够自行理解业务意图。
预言机与多签：外部信息和权限如何接入
智能合约不能自行获取链外现实事件，预言机负责把外部数据提供给合约。多签则要求达到约定数量的有效签名后才能执行操作，可用于多人共同管理权限。
两者解决不同问题：预言机涉及数据从哪里来，多签涉及由谁授权。若某项流程依赖现实中的交付结果，就需要可靠的数据输入；若关键操作需要共同批准，就需要明确签名门槛及密钥管理责任。
常见问题：上链是否意味着业务可信
上链能够提供按链上规则验证的记录，但记录来源、现实履约与责任认定仍需分别处理。多签也只能证明授权条件得到满足，不能单凭签名数量证明决定正确。
判断应用是否适用，应先明确需要共同核验什么记录、哪些规则可以自动执行，以及哪些信息必须依赖外部提供。术语只有对应到具体业务条件，才能帮助理解系统的作用与边界。