先确定讨论的是哪条链
智能合约是按照代码运行的链上程序，节点承担的验证任务则取决于所在网络的协议。以太坊合约包含代码与状态，可以通过交易调用；比特币全节点独立验证区块，并依据共识规则维护账本。两者可以帮助理解程序执行与账本验证，但不能将比特币的工作量证明规则直接套用于以太坊合约。
执行符合规则，不等于业务设计正确
判断合约时，需要分别考虑代码是否按预期执行，以及预期本身是否合理。例如，某个函数只允许指定账户调用，这能形成权限限制，却不能证明被授权者的每次操作都符合业务目标。节点遵守协议验证数据，也不能替代对合约权限和业务条件的检查。
合约之间可以相互调用，因此理解一个入口函数时，还需要考虑它依赖的其他合约。自动执行所保证的范围受代码条件约束，不能据此推断整个应用没有缺陷。
外部数据与执行成本有哪些限制
以太坊智能合约不能自行读取链外事件，使用现实世界信息通常需要预言机。由此需要区分两个问题：输入数据是否可信，以及合约收到数据后是否正确处理。链上执行的一致性不会自动证明外部信息真实。
部署合约需要支付执行费用，合约执行也受到资源规则约束。设计复杂功能时，应考虑计算与存储需求。不能因为某段逻辑可以写成代码，就认定它适合在链上无限规模运行。
节点验证为何要关注分叉
比特币网络可能出现同一高度的竞争区块。在候选链均符合规则的前提下，节点依据累计工作量选择链。因此，区块高度并非全局唯一标识，识别具体区块还需要区块哈希。
这也说明，观察到交易出现在某个区块中，与该区块持续保留在节点接受的链上，是不同层次的判断。应用解释查询结果时，需要考虑分叉，而不能仅凭高度把一条记录视为唯一且永久不变。
常见问题：公开和多签是否意味着安全
公开可调用并不意味着所有功能都对任何人开放，具体权限仍由合约代码决定。多签则通过签名门槛分配操作权，减少对单一密钥的依赖；它仍需要合理设置参与者与门槛，并管理好各自的密钥。
另一个常见误区是把自动执行理解为容易纠错。合约交互通常不能像普通后台记录那样直接撤销，因此应在设计阶段明确授权条件、失败处理和依赖关系。上述合约说明适用于以太坊语境；其他网络需要按其自身协议判断。