账本、哈希与共识
比特币开发者文档介绍了交易组成区块、区块通过哈希相连的结构。默克尔树把交易逐层汇总为一个根哈希，可用于核验交易是否被区块收录。全节点独立验证区块，比特币通过工作量证明和累计工作量处理有效链之间的竞争。
这些概念分别对应记录组织、完整性核验和网络协调。理解应用时，需要区分“某条记录被收录”和“记录描述的事情真实发生”：交易收录证明回答前一个问题，无法单独回答后一个问题。
交易与状态表示
比特币采用未花费交易输出，即UTXO：交易消耗已有输出并产生新输出，同一输出不能被重复花费。以太坊智能合约则具有地址、代码和状态，用户可以提交交易调用其中的函数。
两种结构说明，不同链记录和更新数据的方式存在差异。分析一个应用，应先弄清它记录的是可花费输出、账户余额还是合约状态，不能把一种链的数据模型直接套用到所有区块链。
智能合约与执行费用
以太坊开发者文档将智能合约解释为链上运行的程序。合约语言编写的代码需要编译，部署和执行涉及gas费用；合约之间还可以相互调用。
合约适合表达能够明确编码的规则，例如检查权限、核对输入条件和更新记录。自动执行的准确性取决于规则和程序本身；涉及现实判断时，还需要明确判断结果如何进入链上。
预言机与多签的适用条件
以太坊合约不能自行直接获取链外事件信息，预言机承担将外部数据提供给合约的作用。多签机制则要求达到约定数量的有效签名后才执行操作。
应用依赖现实事件时，重点在于外部数据的来源与可信程度；需要多人共同授权时，重点在于签名门槛和权限分配。数据输入与操作授权是两个不同问题，需要分别设计。
常见问题：上链是否等于可信
哈希关联和共识机制有助于发现改动、提高改写历史的成本，但不能保证最初输入的信息准确。多签可以分散单一密钥带来的风险，也不能自动消除合约错误或多人共同误操作。
以上概念以比特币和以太坊文档描述的机制为例。判断具体应用是否适用，需要核对其所在链的验证规则、数据模型和执行环境，不能仅凭“使用区块链”就推断其具备相同能力。