Glzae & Jasmine：如果你还没有看过第一期，点这里。在第二期中我们将给大家带来区块链安全事故的分析。看完这一期的智能合约代码范例和常见框架介绍，或许你就可以独立编写简单的智能合约了。恭喜！你离一份区块链行业的工作更近了。
如果你喜欢本期内容，不妨在阅读后给我们点个⚡️ ，并订阅我们的 Newsletter
🔥 本周热点：Force DAO 安全事故
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 开发越来越复杂，开发者们会去复用其他项目的一些代码。然而这些项目代码在编写之初并没有考虑到被他人使用，因此文档不够完善。这种稀里糊涂使用别人的代码的行为在未来或许会导致更多的问题。
因此，作为一个智能合约开发者，只掌握开发技术是不够的，我们还需要了解基本的安全漏洞。如果注意这几点，一个智能合约应该可以规避绝大部分漏洞：
- 使用静态工具进行分析，例如 Slither。理解，评估静态工具生成的漏洞报告，这需要开发者熟悉常见的漏洞及其危害。
- 再三检查合约代码中跟钱有关的的逻辑。比如转账的数量，转账的前置条件等。
🏫 区块链 101
本期的区块链 101 将继续上期的内容，理论部分我们就上期中的共识机制展开来谈谈；实践部分我们鼓励大家跟着教程去写出自己的第一个区块链智能合约项目，相信我，这是个有趣而又令人兴奋的过程！
📖 区块链理论：共识机制
🤔 为什么需要共识机制
在传统的中心化银行体系中，用户之间的交易可以通过查账来消除疑虑，大家都相信银行这个中央机构不会造假，但在去中心化的区块链世界中，不存在中心化角色，各个节点是分散且平行的，如何维护区块链的正常运作？各个区块应该选择什么版本？挖矿奖励应该分配给谁？如何避开造假的恶意账本？解决这一系列问题的方法与过程就是共识机制。
提到区块链共识机制，不得不提经典的拜占庭将军问题与拜占庭容错算法，在阅读下面介绍各类区块链共识机制的内容前，我推荐你先了解一下拜占庭容错：Wikipedia | Bianance Academy
⛓️ 区块链主流共识机制：
工作量证明 (Proof of Work)
代表代币：BTC、ETH 1.0
在第一期中介绍的区块链就是采用 POW 机制的区块链，在竞赛中，最先算出哈希签名并通过全网验证的矿工获得代币奖励
优点：
- 最安全的公有链共识机制
- 机制简单、容易实行，攻击成本高（51%算力）
- 挖矿机制相对公平，投入的算力越多，获取打包权的概率越高
缺点：
- 消耗大量能源（电力），算力是通过能源消耗创造出来的
- 区块确认时间长，交易速度慢
权益证明 (Proof of Stake)
代表代币：ETH 2.0
与 POW 的高算力高收益不同，在 POS 机制下，打包用户的角色从“矿工“变成了”锻工“，拥有越多代币（权益）的用户越容易得到当前区块的写入权，因此 POS 机制又叫“伪选举机制”。参与 POS 竞争不需要高算力。POS 奖励打包用户的形式多种多样，有锁仓挖矿，又有锁仓获取收益+锦鲤抽签的形式。部分区块链会在早期采取 POW，产生一定量代币后转换到 POS 机制，ETH 就是一个例子。
优点：
- 不需要矿工持续挖矿产生区块记录、节省能源
- 竞争打包权的矿工必须先持有代币，理论上，为避免币蒸发，矿工更愿意保护系统正常运作
缺点：
- 为了更容易获取打包权，可能会造成囤币情况，降低货币流通量
- 获取到打包权的矿工能够轻易地改写出另一条假链，可能导致 Double Spending 攻击成功
- 执行与运作比 POW 机制复杂
代理权益证明（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，你将会学习到：
- Truffle 和 Hardhat 基础使用
- 智能合约的编写、编译
- 智能合约的本地部署与测试
- 将智能合约部署到公开的测试网络
- 升级智能合约
在编写智能合约的过程中，你将会使用 OpenZeppelin 库，它提供一系列经过实践测试的 API 来协助你开发安全可靠的智能合约，减少被攻击的风险。
🧰 区块链工具分享：开发框架
从 0 开始编写区块链智能合约是困难的，但借助开发框架，我们可以更轻松的写出高质量的代码，更好地完成开发工作
- Hardhat: 基于 JS，灵活可拓展的以太坊专业开发环境，容易上手，与 OpenZeppelin 的可升级智能合约插件直接集成
- Truffle：基于 JS，近几年以太坊智能合约的默认开发框架，功能与 Hardhat 类似；它是 Truffle Suite 中的一员，能够与姊妹工具 Drizzle 和 Ganache 很好的配合完成各项开发工作
- Brownie：基于 Python，简洁干净的智能合约开发框架，没有 JS 带来的各种麻烦，适合讨厌 JS 的开发者
- EmBark：基于JS，区块链 DApp 全栈框架，功能强大，自带 UI，可以通过 CLI 进行合约交互测试；模块化设计开发构建，可以选择想集成的功能、插件与工具；EmBark 有一定的上手难度
关于 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
