原理：让共享记录可以独立核验
区块链把交易组织成区块，并通过密码学引用连接历史。节点依据共同规则检查记录，共识机制则帮助网络确定接受哪条历史。它的核心能力，是让多个参与方能够核验同一套记录及其变化，而这种能力有明确的前提和成本。
架构：记录模型决定处理方式
比特币开发者指南描述了未花费交易输出模型：交易消耗已有输出并生成新输出，节点检查重复花费等问题；区块通过哈希关联，工作量证明与累计工作量参与历史选择。
以太坊开发文档描述了账户、共享状态和虚拟机：交易请求触发规则检查与合约执行，网络对状态变化达成共识；权益证明用于共识，计算需要支付资源费用。
两种架构分别展示了交易记录验证与可编程状态更新的路径。因此，讨论应用边界时，需要明确业务究竟要共享什么状态，以及这些状态能否用确定的规则验证。
适用条件：确实需要多方共同验证
当多个参与方需要核对记录顺序、状态变化和操作权限，并希望各自验证结果时，区块链的架构与需求较为匹配。规则清晰、输入可验证，是把业务逻辑交给链上执行的重要条件。
如果需求只是由单一管理者保存和修改内部数据，区块链的多节点验证与共识未必带来相应价值。选型应比较共享验证的必要性，以及为此承担的存储、通信和执行成本。
应用边界：共识不能替代事实核实
节点可以检查提交的数据是否符合协议，却不能仅凭这些检查判断链外事件是否真实发生。例如，登记一条货物交付记录，并不自动证明货物已经交付。此类应用仍需明确数据由谁采集、如何核验以及争议如何处理。
智能合约按代码条件运行，适合表达明确的状态转换；对于含糊条款、人工判断或链外履约，仍需另设处理机制。执行结果符合代码，也不等于代码完整表达了业务意图。
常见问题：不可篡改与复杂计算如何理解
不可篡改是否意味着绝对不能变化？哈希关联让历史改动能够被发现，共识机制提高改写历史的难度。安全性仍依赖机制的假设；出现竞争区块时，还需要按协议选择历史，不能把刚被收录简单理解为永久确定。
能运行合约，是否就适合承载所有计算？可编程能力不代表资源无限。链上执行需要网络验证并消耗资源，因此，复杂应用需要划清必须由链上共同验证的部分，避免把全部业务处理都视为共识任务。