先区分账本与应用执行
转向区块链发展涉及哪些技术概念，可以从两个问题入手：网络怎样共同确认记录，程序怎样依据记录执行规则。比特币的区块链机制适合说明前者，以太坊智能合约适合说明后者。两者用于解释不同技术层次，具体设计不能直接套用于所有区块链。
哈希、区块与默克尔树
比特币区块通过前一区块头的哈希建立关联，交易哈希则汇总为默克尔根并写入区块头。修改交易会改变相应的哈希关系。默克尔证明能够帮助验证某笔交易是否被纳入区块。
这里需要区分记录完整性与内容真实性：证明一条记录被收录，并不能单凭这一点证明其描述的现实事件真实。应用设计仍需明确数据来自哪里、由谁负责。
交易状态、共识与分叉
比特币用未花费交易输出，即UTXO，描述可被花费的交易输出；已花费输出不能再次花费。全节点独立检查规则，工作量证明为区块创建引入计算成本。出现竞争分支时，节点在有效链中依据累计工作量选择链。
理解共识需要同时考虑有效性与历史选择：符合规则是候选记录被接受的前提，分支选择解决的是采用哪段历史。区块高度表示位置，分叉时相同高度可能对应不同区块，因此不能作为全局唯一标识。
智能合约、虚拟机与执行成本
以太坊智能合约由链上代码和状态组成，可通过交易调用。Solidity、Vyper等语言编写的合约需要编译，供以太坊虚拟机执行；部署和执行涉及Gas。合约之间可以相互调用，形成组合功能。
开发时需要把业务条件转成明确规则，包括谁能调用、哪些状态允许改变、条件不满足时如何处理。自动执行的可靠程度取决于这些规则是否正确；代码能够执行，并不代表业务设计没有漏洞。
外部数据、权限与适用条件
智能合约自身不能直接获取链外事实，使用这类信息需要预言机。多签合约则通过多个有效签名共同授权执行，用于分配控制权。
二者处理不同问题：预言机涉及输入数据是否可信，多签涉及谁有权批准操作。涉及外部事件的应用需要审视数据来源，多方管理的应用需要明确授权门槛；这些条件应纳入系统设计。
常见问题：是否必须把业务全部上链
这些机制各有用途，不意味着每项业务都需要同时采用。需要共同验证历史时，应先理解账本与共识；需要执行共享规则时，再考虑合约及其权限。判断技术是否适用，应围绕共享哪些记录、如何验证输入、怎样处理失败展开，而不能只看是否使用了区块链。