账本、哈希与共识
比特币开发者指南介绍了区块链接、默克尔树、工作量证明与未花费交易输出。区块通过前一区块的哈希相连，节点按共识规则验证记录；默克尔树支持交易包含证明，工作量证明使改写历史需要付出计算成本。
这些概念分别回答不同问题：哈希帮助识别数据变化，共识规则规定哪些记录有效，包含证明说明交易是否进入某个区块。应用设计需要区分这些能力，不能仅凭数据已经上链，就认定数据描述的现实事件真实。
交易状态与适用范围
理解应用还需要知道系统怎样表达状态。比特币的未花费交易输出模型，将可用价值表示为尚未被花费的输出；新的交易消耗旧输出并生成新输出，同一输出不能在有效链上被重复花费。
这一模型适用于理解比特币交易验证，不能直接套用为所有区块链应用的结构。分析其他应用时，应先明确它记录的对象、允许的状态变化，以及判断变化有效的规则。
智能合约与权限控制
以太坊智能合约安全文档强调访问控制、多重签名、条件检查、测试和独立审查。智能合约通过部署的代码执行规则，敏感功能需要明确授权；角色划分和多签可以限制管理权的使用方式。
应用中的关键问题包括：谁能修改参数、谁能暂停功能、哪些操作需要多人同意。角色分工有助于缩小权限范围，但多个角色若仍由同一主体控制，就不能据此认定管理已经分散。
异常处理与安全验证
合约除了处理正常输入，还需要拒绝不满足条件的操作，并检查应当始终成立的约束。例如，受限功能只能由获授权的调用者执行。异常处理机制为这些规则提供执行边界。
安全验证也有不同层次：单元测试检查具体场景，静态分析检查代码结构，模糊测试探索多种输入，形式化验证检查模型是否满足明确性质。形式化结论受模型、假设与规格范围约束，审计也不能保证发现全部缺陷。
常见问题：不可篡改是否等于安全
不可篡改并不意味着程序没有错误。规则若存在漏洞，可靠执行也可能产生不符合设计目标的结果。理解新型应用时，需要分别考察账本完整性、业务规则和管理权限。
区块确认也需要结合链的机制理解。比特币可能出现临时竞争分支，节点依据累计工作量选择有效链。因此，交易进入区块、所在分支被继续延伸，以及应用认定业务完成，是需要分别说明的状态。