Glzae & Jasmine：如果你还没有看过第一期，点这里。在第二期中我们将给大家带来区块链安全事故的分析。看完这一期的智能合约代码范例和常见框架介绍，或许你就可以独立编写简单的智能合约了。恭喜！你离一份区块链行业的工作更近了。
如果你喜欢本期内容，不妨在阅读后给我们点个⚡️ ，并订阅我们的 Newsletter
Force DAO 是最近的 DEFI 明星项目，但它一上线就发生了严重的安全事故。目前 FORCE DAO 空投已经暂停。本期本周热点将会为你介绍区块链安全，以及回顾 FORCE DAO 的安全漏洞。
安全是个有人在意，有人不在意的问题。随着互联网的兴盛，各种数据泄露，黑客攻击也层出不穷。相比过去的小打小闹，现在的黑客行动有着更加明确的目标，强大的破坏力。在区块链中，安全是重中之重。因为区块链与钱的连接更加紧密，黑客们更有攻击的动力。一个严重的安全问题可能导致一个区块链项目的失败。有关区块链给安全带来的独特挑战，我们有机会再介绍。
从项目方的披露中我们可以了解攻击的流程。受到攻击的是 xFORCE Vault。这个合约负责 xFROCE 代币的生成和销毁。正常的逻辑是用户抵押 FORCE 代币，收到 xFORCE 代币。漏洞是没有校验 FORCE 代币的转账结果。这导致攻击者可以让 FORCE 代币转账失败，但仍旧收到 xFORCE 代币。
没有校验函数返回值是智能合约中很常见的问题。在此次事件中，攻击者就是利用了合约并没有处理 FORCE 代币 transferFrom 的返回值，凭空铸造了很多 xFORCE。然后将 xFORCE 销毁，换回 FORCE。合约认为 transferFrom 必定成功，即使用户并没有真的把 FORCE 转给智能合约。漏洞在ForceProfitSharing.sol L43 。
在开发过程中我们可以添加代码来处理 transferFrom 的返回值。我们也可以使用 SafeERC20 的 safeTransferFrom。使用 safeTransferFrom 时，如果转账失败整个交易会进行回滚。
我个人觉得这是一个十分容易发现的漏洞。不需要人工审计，静态分析器也能发现这个问题。很有可能项目方没有进行正规的代码审计。
在报告中他们提到 xFORCE vault 代码来自 xSUSHI，FORCE 来自 Aragon Minime。xSUSHI 代码假设转账操作失败会回滚，然而 FORCE 并没有实现转账失败回滚的功能（缝合失败）。我们可以理解为项目方借用了其他项目的代码，但并没有弄清楚这些代码运行的前提。
DEFI 开发越来越复杂，开发者们会去复用其他项目的一些代码。然而这些项目代码在编写之初并没有考虑到被他人使用，因此文档不够完善。这种稀里糊涂使用别人的代码的行为在未来或许会导致更多的问题。
因此，作为一个智能合约开发者，只掌握开发技术是不够的，我们还需要了解基本的安全漏洞。如果注意这几点，一个智能合约应该可以规避绝大部分漏洞：
本期的区块链 101 将继续上期的内容，理论部分我们就上期中的共识机制展开来谈谈；实践部分我们鼓励大家跟着教程去写出自己的第一个区块链智能合约项目，相信我，这是个有趣而又令人兴奋的过程！
在传统的中心化银行体系中，用户之间的交易可以通过查账来消除疑虑，大家都相信银行这个中央机构不会造假，但在去中心化的区块链世界中，不存在中心化角色，各个节点是分散且平行的，如何维护区块链的正常运作？各个区块应该选择什么版本？挖矿奖励应该分配给谁？如何避开造假的恶意账本？解决这一系列问题的方法与过程就是共识机制。
提到区块链共识机制，不得不提经典的拜占庭将军问题与拜占庭容错算法，在阅读下面介绍各类区块链共识机制的内容前，我推荐你先了解一下拜占庭容错：Wikipedia | Bianance Academy
工作量证明 (Proof of Work)
代表代币：BTC、ETH 1.0
在第一期中介绍的区块链就是采用 POW 机制的区块链，在竞赛中，最先算出哈希签名并通过全网验证的矿工获得代币奖励
优点：
缺点：
权益证明 (Proof of Stake)
代表代币：ETH 2.0
与 POW 的高算力高收益不同，在 POS 机制下，打包用户的角色从“矿工“变成了”锻工“，拥有越多代币（权益）的用户越容易得到当前区块的写入权，因此 POS 机制又叫“伪选举机制”。参与 POS 竞争不需要高算力。POS 奖励打包用户的形式多种多样，有锁仓挖矿，又有锁仓获取收益+锦鲤抽签的形式。部分区块链会在早期采取 POW，产生一定量代币后转换到 POS 机制，ETH 就是一个例子。
优点：
缺点：
代理权益证明（Delegated Proof of Stake）
代表代币：EOS
DPOS 可以理解为 POS + POW，参与者将打包工作委托给一小群数量固定的验证者，参与者通过投票选出验证者代表，投票采用 POS 机制，被选出的验证者之间存在密钥计算竞赛，采取 POW 机制来决定谁负责打包。在 DPOS 机制下，被委托的验证人会和他们的支持者共享获得的奖励的
优点：
缺点：
关联阅读：What is Delegated Proof of Stake?
学完了 Solidity 的基础，你是否迫不及的的想写出自己的第一个智能合约呢？
现在你可以阅读 OpenZeppelin 的智能合约开发教程，从零开始，一步一步地完成自己的第一个 Smart Contract Project 。
通过阅读 Developing Smart Contracts Tutorial，你将会学习到：
在编写智能合约的过程中，你将会使用 OpenZeppelin 库，它提供一系列经过实践测试的 API 来协助你开发安全可靠的智能合约，减少被攻击的风险。
从 0 开始编写区块链智能合约是困难的，但借助开发框架，我们可以更轻松的写出高质量的代码，更好地完成开发工作
关于 TypeScript 和 JavaScript：虽然目前的主流框架基于 JavaScript，但在实际开发中开发者更倾向于采用 TypeScript 来编写 Deploy 脚本与测试用例，JS 这玩意儿真的是一言难尽...
📘 文章推荐
文章推荐栏目将和大家分享一些我们最近在阅读的优质内容，最近我们比较关注新上线的 UNISWAP V3 以及持续高热度的 NFT 话题
这篇文章介绍了 Uniswap V3 中的 Pool和 Swap，从理论的角度解释 Uniswap 的资金利用率、流动性、swap 费用等问题 👇
🦄️ 深入理解 Uniswap V3 原理：从技术白皮书开始
这篇文章分析了 Uniswap V3 用 NFT 取代 LP Token 的弊端，并提出了解决方案 👇
🧾 金融 NFT 缺乏流动性怎么办？ 票据型资产协议了解一下
🚏Find us
提问&纠错&反馈：
Email：unblocketh@gmail.com
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。