交易与状态：系统记录什么
区块链应用首先需要表示和更新状态。比特币开发者指南以未花费交易输出（UTXO）解释交易：输入引用已有输出，新的输出规定后续使用条件。钱包余额可以由多个尚未花费的输出组成。以太坊智能合约介绍则将合约描述为位于特定地址的代码与状态集合。
这两种机制提供了不同的理解入口：一种追踪哪些输出尚可使用，另一种关注账户和程序状态如何变化。解释具体应用前，需要先确定它采用的数据模型，不能把一种链的交易结构直接套用到另一种链上。
哈希、密钥与签名：如何验证授权
比特币指南中的公钥哈希支付示例涉及私钥、公钥、哈希和数字签名。交易标识与输出序号共同定位被使用的输出；脚本检查所提供的公钥与签名是否满足条件。
这些概念承担不同任务：定位记录、核对数据和验证授权。签名验证通过，说明相应密码学条件得到满足，不能单凭这一结果确认签署者的现实身份，也不能证明交易所涉及的商品或业务描述真实。
智能合约与执行环境：规则如何运行
以太坊合约可通过交易调用函数，由虚拟机执行编译后的程序；部署和执行涉及以Gas计量的资源消耗。合约之间还可以相互调用，形成组合功能。
自动执行的前提是规则已经写入代码，并且调用满足程序条件。例如，权限检查决定谁能修改某项记录，状态检查决定当前是否允许操作。程序能一致地执行规则，并不代表规则设计必然正确；组合多个合约时，也需要理解被调用部分的行为。
预言机与多签：外部信息和协作权限
以太坊智能合约不能自行获取链外事件信息，预言机用于将外部数据提供给合约。多签机制则要求达到指定数量的有效签名后才能执行操作。
两者适用的问题不同：需要依据现实事件运行的应用，必须考虑数据从哪里来、是否及时可靠；需要多人共同批准的应用，则要明确签署者及批准门槛。数据接入机制不能替代权限设计，多人批准也不能保证输入数据正确。
常见问题：记录可信是否等于事实可信
上链能否证明原始信息真实？仅凭记录进入链上，无法完成这种证明。若业务依赖现实世界的事实，还需要核查信息采集和提交环节。
智能合约能否自动处理所有争议？其处理范围取决于代码、可用数据与权限安排。理解区块链应用，应分别考察记录结构、授权条件、执行逻辑和外部依赖，避免将技术验证能力扩大为对整个业务的保证。