注：原文来自@raylin51发布长推。

2024年1月是我整个加密生涯中研究过最多项目的一个月。其中有老牌项目因为 BTC 热潮调整战略起死回生的，也有新设计的架构颇具新意的项目，当然最多的还是被批量制造的 BTC L2。整个一月最为困惑我的一个问题是: 究竟什么样的项目能在市场立足？

1. 叙事，快速迭代和安全的不可能三角

通常来说，在项目中存在一个不可能三角: 叙事，快速迭代和安全。

假设一个项目它的叙事非常宏大，架构中又有一些自创的部分，并且它新功能迭代又非常快速，往往意味着它在系统上会有一些有可能致命的问题。新架构新功能的引入需要一段时间的论证以及验证，看似美好的方案不一定是能解决所有 case 的银弹。

同样的，一个完全沿用已被验证过的架构来保证系统安全性的项目，要么有足够的时间来探索新叙事的可能性，要么在快速迭代的过程中沦为仿盘(例如各大公链的铭文)。

2. 既然不能全都要，那么到底要什么？

前几天在一场 space 中我问了大山总@shanshan521 一个问题: 一些号称是 L2 的项目的数据和验证都不在 L1 上做，仅仅只是在 L1 上进行挑战，那么安全性不依赖于 L1 的项目为什么能被称作 L2 呢？大山总的回答是: 当前环境下没有一个共识的 L2 方案，很难有一个标准来判断到底方案好不好。从投资的角度来说技术安全只是一方面，更重要的是叙事，营销能力以及投资回报（大意是这样，具体回答可以参考前几天大山总的 space 录音，如果有误请指正）。这句话就很像早几年工作同事们开玩笑说的: “安全问题在出问题之前都不是问题。”毕竟不是每个人都是开发者，也不是每个开发者都能在代码中找出漏洞（即使漏洞就在那里）。在不可能三角中如何选择实际上就演变成了项目方对于项目的路线图选择。要抢占市场风头，那必须舍弃一定安全性不断迭代以及增加新叙事来保持热度。要保证安全性，那就只能在热度上做一些牺牲，期望有融资或者社区支持来保证话题性。

3. 是不是舍弃一定的安全性就是有问题的？

“安全问题在出问题之前都不是问题”这句看似玩笑话其实在软件工程中是有大量的案例的。许多 0day 漏洞是由白帽发现并提交的，没有造成什么损失，如果硬说是个问题确实有些牵强。

但是一旦出了问题，例如某个 L2 把节点部署在了 aws 同一个可用区机房，机房又出了故障，那么社区开发者能通过 L1 上的数据来恢复这个 L2 的状态吗？还是说只能等机房恢复才能重新同步状态？再假设一个 BTC 跨链桥受到攻击，跨链桥的数据存储如果是中心化的情况下能在数据被销毁后重建数据状态吗？如果是去中心化的情况下能保证数据仍然可信吗？

虽然以上问题不一定都需要在系统设计上解决，也可以通过外部方式来解决，但是实际去考虑极端 case 是非常有必要的，在系统设计中不可能三角的安全性被舍弃以后，团队就应该更多地考虑如何从外部来解决一些极端 case，设计缺陷可以用预防措施来弥补。等安全问题成为问题了，可能对于市场又是一个巨大打击（特指 Luna 的虫洞套利 bug)

做产品有时候就像搭积木，搭积木时别忘了防熊孩子。