关于 Uniswap V3 的计算
机制改变Uniswap V3 采用了集中流动性(Concentrated Liquidity)。用户可以为自己的流动性设置一个价格区间。超出这个价格区间或低于这个价格区间,所有代币将被转换成两者中不值钱的那个。这一步转化造成的损失是无常损失。一个价格区间中的最小间隔叫 Tick,为 0.01%。 符号Swap添加流动性相关阅读:Uniswap V3 白皮书编辑于昨天 14:30文章被以下专栏收录* Blockchian;unblock256.com
矿工可提取价值
日渐增多的 MEV 可能导致了高昂的 Gas Fee在*上一期*的周报中我们为大家介绍了 Gas Fee , Gas Fee 越高,交易就越可能被矿工打包。本期我们就来讨论一下这种打包机制所产生的问题,Miner-extractable Value(MEV)。 MEV 指的是矿工重新排序交易后可以获得的利润。在实际情况中, MEV 可能并不是矿工推动。有可能是我付出了一个很高的 Gas Fee ,希望矿工优先打包我的交易。 希望矿工优先打包交易的原因有以下几种:抢跑(Frontrunning)主流的 DEX 都支持滑点,也就是成交价格的区间,假设当前下单价格 100 块,滑点是 5%,这意味着成交价格会在 95 - 105 之间。 宽松的价格区间让套利者有机可乘。 假如一个套利者在内存池中(没有打包的交易都会在内存池中)看到一笔大额买单(币价即将上涨)。根据 AMM 的模型,只要有买单成交,代币价格就会上升。因此,套利者可以通过高额的 Gas Fee 或者贿赂矿工来插入一笔买单,抢在代币价格上涨之前完成买入。套利者的抢跑行为将导致后续的那一笔大额买单以以更高的价格成交。 其实在现...
流动性挖矿(Yield Farming)
⚠️ 以下为非投资建议 (No Financial Advise) 内容,流动性挖矿存在投资风险。概念流动性挖矿是 AMM 协议下的提供流动性的更进一步,它是通过锁定流动性来获取代币奖励。 如何获取收益*上期*我们讲到在 AMM 协议下,流动性提供者可以通过从交易手续费中获取一定收益。流动性挖矿与单纯的提供流动性(LP)略有不同,它是将组好的 LP,注入到资金池中(矿池),以获取额外的不同的代币支付奖励。用于奖励的代币大多为矿场的代币。以 BSC 上的 PancakeSwap 的 Farm 作为例子,这是一个 $BUSD - $BNB 矿池,在 Stake(质押、注入)前,我们需要先为 $BUSD - $BNB 交易对提供流动性以及 Approve(授权使用代币)。 LP 组好后,我们就可以将我们的 LP Stake 进矿池,开始挖矿。 一段时间后,我们可以获得 $CAKE (PancakeSwap 的平台代币)作为奖励,通过 Harvest(收成)我们就可以把 $CAKE 收入囊中。与此同时,我们的 $BUSD - $BNB 还在努力的工作,持续产出 $CAKE。 又过了一段...
关于 Uniswap V3 的计算
机制改变Uniswap V3 采用了集中流动性(Concentrated Liquidity)。用户可以为自己的流动性设置一个价格区间。超出这个价格区间或低于这个价格区间,所有代币将被转换成两者中不值钱的那个。这一步转化造成的损失是无常损失。一个价格区间中的最小间隔叫 Tick,为 0.01%。 符号Swap添加流动性相关阅读:Uniswap V3 白皮书编辑于昨天 14:30文章被以下专栏收录* Blockchian;unblock256.com
矿工可提取价值
日渐增多的 MEV 可能导致了高昂的 Gas Fee在*上一期*的周报中我们为大家介绍了 Gas Fee , Gas Fee 越高,交易就越可能被矿工打包。本期我们就来讨论一下这种打包机制所产生的问题,Miner-extractable Value(MEV)。 MEV 指的是矿工重新排序交易后可以获得的利润。在实际情况中, MEV 可能并不是矿工推动。有可能是我付出了一个很高的 Gas Fee ,希望矿工优先打包我的交易。 希望矿工优先打包交易的原因有以下几种:抢跑(Frontrunning)主流的 DEX 都支持滑点,也就是成交价格的区间,假设当前下单价格 100 块,滑点是 5%,这意味着成交价格会在 95 - 105 之间。 宽松的价格区间让套利者有机可乘。 假如一个套利者在内存池中(没有打包的交易都会在内存池中)看到一笔大额买单(币价即将上涨)。根据 AMM 的模型,只要有买单成交,代币价格就会上升。因此,套利者可以通过高额的 Gas Fee 或者贿赂矿工来插入一笔买单,抢在代币价格上涨之前完成买入。套利者的抢跑行为将导致后续的那一笔大额买单以以更高的价格成交。 其实在现...
流动性挖矿(Yield Farming)
⚠️ 以下为非投资建议 (No Financial Advise) 内容,流动性挖矿存在投资风险。概念流动性挖矿是 AMM 协议下的提供流动性的更进一步,它是通过锁定流动性来获取代币奖励。 如何获取收益*上期*我们讲到在 AMM 协议下,流动性提供者可以通过从交易手续费中获取一定收益。流动性挖矿与单纯的提供流动性(LP)略有不同,它是将组好的 LP,注入到资金池中(矿池),以获取额外的不同的代币支付奖励。用于奖励的代币大多为矿场的代币。以 BSC 上的 PancakeSwap 的 Farm 作为例子,这是一个 $BUSD - $BNB 矿池,在 Stake(质押、注入)前,我们需要先为 $BUSD - $BNB 交易对提供流动性以及 Approve(授权使用代币)。 LP 组好后,我们就可以将我们的 LP Stake 进矿池,开始挖矿。 一段时间后,我们可以获得 $CAKE (PancakeSwap 的平台代币)作为奖励,通过 Harvest(收成)我们就可以把 $CAKE 收入囊中。与此同时,我们的 $BUSD - $BNB 还在努力的工作,持续产出 $CAKE。 又过了一段...
Share Dialog
Share Dialog

Subscribe to un.Block

Subscribe to un.Block
<100 subscribers
<100 subscribers
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。理解,评估静态工具生成的漏洞报告,这需要开发者熟悉常见的漏洞及其危害。
再三检查合约代码中跟钱有关的的逻辑。比如转账的数量,转账的前置条件等。
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。理解,评估静态工具生成的漏洞报告,这需要开发者熟悉常见的漏洞及其危害。
再三检查合约代码中跟钱有关的的逻辑。比如转账的数量,转账的前置条件等。
No activity yet