账本、哈希与共识：建立共同记录
比特币开发者文档介绍了节点独立验证区块、通过前一区块哈希连接历史记录的机制。默克尔树将交易哈希逐层汇总，支持核验交易是否被某个区块收录。工作量证明与累计工作量相关的链选择规则，共同支撑网络对有效历史的协调。
这些概念分别回答记录如何关联、内容如何核验、出现竞争历史时如何选择的问题。讨论存证类应用时，应明确其证明对象：某份数据被记录，并不自动证明数据描述的现实事件真实。
交易与状态：明确系统记录什么
比特币采用未花费交易输出，即UTXO，描述可被后续交易使用的输出；已经花费的输出不能再次使用。这一约束用于防止同一输出被重复花费。
理解应用时，需要先确定记录对象和变更规则。例如，一项凭证的创建与后续状态变化，应有清楚的关联和有效性条件。不同区块链的数据模型存在差异，不能把UTXO视为所有系统的统一结构。
智能合约：让规则成为可执行程序
以太坊智能合约文档将合约解释为位于链上地址的代码与状态。用户通过交易调用其功能，执行涉及Gas资源计量；Solidity等语言编写的合约需要编译。合约之间还可相互调用，形成可组合的功能。
自动执行适合条件能够明确表达的流程。设计时需要回答谁能发起操作、满足什么条件、失败后如何处理。程序执行符合代码，并不意味着代码完整表达了参与者的真实意图。
预言机与多签：连接外部信息和协作权限
该以太坊文档还说明，合约自身不能直接获取链外事件，需要预言机提供外部数据；多签合约则要求达到指定数量的有效签名才允许执行，可用于多人共同管理权限。
两者处理的问题不同：预言机关系到输入信息的来源，多签关系到操作授权。应用若依赖现实世界信息，应说明数据采集与核验条件；采用多人授权时，应说明签署门槛与职责分配。
适用条件与常见问题
什么情况下值得考虑这些技术？当多方需要共享可核验记录，且关键流程可以表达为明确规则时，这些机制具有讨论价值。若核心争议在于原始信息真假，仅增加链上记录无法解决争议。
记录是否绝对不可改？哈希关联与共识机制增加修改历史的难度，具体保障仍取决于网络机制和安全条件。自动执行是否无需信任？应用仍需审视代码、外部数据以及权限管理，分别确认它们能够提供什么保障。