目录
当我们提 DApp 时，可能是 DeFi、NFT 或 GameFi 等等，这⼏个的安全⼤多是相同的，但会有⾃身的特别点。我们这⾥以 DeFi 为例先讲解下，当我们提 DeFi 安全时，到底指的是什么？业内⼏乎都只看智能合约部分，似乎智能合约安全了也就没事了。其实远远并⾮如此。

DeFi 安全⾄少包括如下⼏部分：

智能合约安全

区块链基础安全

前端安全

通信安全

⼈性安全

⾦融安全

合规安全

智能合约安全确实是安全审计最重要的切⼊点，对于⾼级玩家来说，如果智能合约部分本身安全性可控（⽆论是⾃⼰能安全审计还是读懂专业机构的安全审计报告），那么也就⽆所谓其他部分的安全了。可控是个很有差异的理解，有的得看玩家实⼒。⽐如说智能合约权限过⼤的⻛险，玩家是有要求的，除⾮项⽬⽅本身实⼒雄厚及⼝碑良好，完全中⼼化也都⽆所谓。但对于那些不⼤知名的、有争议的或新出现的项⽬，如果你说这个项⽬的智能合约有权限过⼤的⻛险，尤其是这种权限还可以影响你的本⾦或收益，你肯定就不愿意了。

权限过⼤这种⻛险是很微妙的，很多时候权限这东⻄是⽅便项⽬⽅做相关治理及⻛险应急的。但对我们来说，这就是⼈性考量了，万⼀项⽬⽅作恶呢？于是业内有了折中的实践：增加时间锁(Timelock)来解决⼀些权限过⼤的⻛险，⽐如：

Compound，这个⽼牌知名的 DeFi 项⽬，它核⼼的智能合约模块 Comptroller 及 Governance 的 admin 权限都加了 Timelock 机制： 

Comptroller(0x3d9819210a31b4961b30ef54be2aed79b9c9cd3b) 

Governance(0xc0da02939e1441f497fd74f78ce7decb17b66529) 

的 admin 地址是：Timelock(0x6d903f6003cca6255d85cca4d3b5e5146dc33925) 

链上可以直接看到 Timelock 的时间锁（delay 参数）是 48 ⼩时（172800 秒）：也就是说，如果 Compound 的 admin（项⽬⽅）需要变更⽬标智能合约的⼀些关键值时，这笔交易上链后会有记录，但必须等到 48 ⼩时后才可以最终完成执⾏。这意味着，只要你愿意，你是可以审计 admin 的每⼀次操作，你⾄少有48 ⼩时来反应。⽐如如果你不放⼼，你可以在 48 ⼩时内把资⾦撤⾛。
还有⼀种削弱项⽬⽅权限过⼤⻛险的做法是：将 admin 多签了，⽐如⽤ Gnosis Safe 进⾏多签管理，这样⾄少不会出现⼀⾔堂。这⾥需要注意的是，多签可以是“皇帝的新⾐”，⽐如⼀个⼈掌握了多把钥匙。所以⽬标项⽬的多签策略需要公示说明清楚，钥匙都由谁保管，保管钥匙的⻆⾊也⼀定是有⼝碑的。这⾥需要特别注意，任何安全策略，都可能出现“皇帝的新⾐”问题，表⾯做得好，实际上却不是，呈现出了⼀种虚假安全感。再举个例⼦，Timelock 这玩意，看去似乎挺好，实际上出现过有的项⽬⽅部署的 Timelock 是有后⻔的情况。⽤户⼀般也不会直接去看 Timelock 源码，⽽且也不⼀定看得懂，于是放了个后⻔在那，⼀时半会还真不⼀定有⼈留意到。

除了权限过⼤⻛险，智能合约安全的其他内容也都很关键，但理解⻔槛还是挺⾼的，这⾥就不展开了，我的建议是这样：⾄少可以逐步学会阅读安全审计报告，熟能⽣巧。

区块链基础安全指的是区块链本身的安全性，如：共识账本安全、虚拟机安全等。如果区块链本身安全性堪忧，其上运⾏的智能合约项⽬也可以直接喝⻄北⻛了。选择⼀条拥有⾜够安全及知名度的区块链，甚⾄⼤概率可以源远流⻓的区块链是多么的重要。

前端安全真是魔⻤，与⽤户⾛得太近了，特别容易让⽤户魔怔后上当受骗。可能⼤家主要的注意⼒都在⾃⼰的钱包上和⽬标项⽬的智能合约安全上了，前端安全⾮常容易被忽视。这⾥我需要再次强调，前端安全是魔⻤！我重点说。

前端安全⾥我最在意的点是：我怎么知道我在这个前端⻚⾯⾥的交互对象就是我以为的智能合约？造成这种不安全感主要是因为以下这两种⻛险：
内部作恶

第三⽅作恶

内部作恶很好理解，⽐如开发⼈员偷偷将前端⻚⾯⾥的⽬标智能合约地址替换为⼀个有后⻔的合约地址，或者直接植⼊个授权钓⻥脚本。当你访问该前端⻚⾯时，你钱包后续的⼀系列涉及加密货币的操作都可能是在陷阱⾥完成的。神不知⻤不觉，币没了。

第三⽅作恶，主要指的是两种：

⼀种是供应链作恶，⽐如前端依赖的第三⽅模块被植⼊了后⻔，随着打包发布⼀起被直接带⼊⽬标前端⻚⾯了。如 SushiSwap（仅仅举例⼦，并不代表截图⾥的项⽬有发⽣这个问题）：⼀种是前端⻚⾯引⼊的第三⽅远程 JavaScript ⽂件，如果这个 JavaScript ⽂件作恶或被⿊，那么⽬标前端⻚⾯可能就会被影响，如 OpenSea：

为什么这⾥说可能会被影响是因为，如果项⽬⽅在前端⻚⾯以下⾯这样的⽅式来引⽤第三⽅远程 JavaScript ⽂件的为什么这⾥说可能会被影响是因为，如果项⽬⽅在前端⻚⾯以下⾯这样的⽅式来引⽤第三⽅远程 JavaScript ⽂件的 

话，就可能不会被影响：

这⾥的关键点是 HTML5 的⼀个不错的安全机制：标签⾥的 integrity 属性（SRI 机制），integrity ⽀持 sha256,sha384, sha512，如果第三⽅ JavaScript 资源不满⾜ integrity 的哈希完整性校验，就不会加载，这个可以很好防⽌⾮预期的代码执⾏。但使⽤这个机制需要⽬标资源⽀持 CORS 响应。

等等，为什么我前⾯⼜提了“可能”，是因为有存在被绕过的场景。⾄于绕过⽅式我就不提了，因为⼤多情况下，你只需关注⽬标前端⻚⾯在引⼊第三⽅远程 JavaScript ⽂件时是否有 integrity 机制。可惜的是，OpenSea 没有，让我们祝福它。

返回目录     点击看下文

#区块链个人安全黑手册 #比特币 #区块链安全