“专属技术”应如何理解
讨论区块链专属技术有哪些常见问题，首先需要明确范围：哈希、数字签名和访问控制并非区块链独有。区块链的特点在于组合使用这些技术，让多个参与者按照共同规则验证和维护记录。以下分别讨论比特币账本机制与以太坊智能合约，具体结论不宜直接套用到所有区块链。
记录不可篡改是否意味着绝对不能改变
比特币开发者指南描述了区块之间的哈希关联，以及工作量证明对重写历史的约束。修改旧交易会影响其所在区块及后续关联，攻击者需要面对重新构建竞争链的成本。
因此，“不可篡改”表达的是规则与成本形成的保护，不能理解为任何条件下都无法发生历史变动。它也不能保证写入内容符合现实：记录难以修改，与记录最初是否真实，是两个不同问题。
分叉是不是系统故障
比特币可能因矿工近乎同时产生区块而出现短暂分叉。节点在有效候选链之间依据累计工作量选择链；同一高度也可能存在不同区块，因此高度不能唯一标识区块。
这说明交易被某个区块收录，与其在后续链选择中持续保留，需要分别判断。短暂分叉本身不必然代表规则失效，也不宜将这套工作量证明机制视为所有区块链的共同实现。
交易包含证明能证明什么
默克尔树支持通过有限的中间哈希核验交易是否被某个区块收录。但“被收录”是有边界的结论：判断区块是否属于认可的链，以及交易是否满足完整规则，还需要相应验证。
设计查询或存证功能时，应明确所展示的是数据关联、区块收录，还是经过更完整检查的状态，避免把局部证明解释成对整个业务真实性的保证。
合约部署后为何仍有安全问题
以太坊智能合约安全文档强调访问控制、条件检查、测试和独立审查。公开可调用的函数如果缺少权限限制，可能使敏感操作暴露；管理密钥失陷也可能影响合约安全。
权限设计应匹配操作职责。角色分离与多签可以降低部分集中管理风险，但效果依赖角色配置和签名方的独立性。节点一致执行代码，并不意味着代码符合业务预期。
审计能否保证没有漏洞
测试与审计能够帮助发现缺陷，却不能保证覆盖所有情形。形式化验证的结论也受所选规范、模型及假设约束，不能扩大为整个系统绝对安全。
合约安全需要同时考虑正常流程、异常输入、权限边界和部署后的管理安排。对难以直接修改的已部署代码，开发阶段遗漏的设计问题尤其值得重视。