近来以太坊上最火爆的领域便是 DeFi。首要的 DeFi 运用包含 ERC20 代币的借贷、质押和买卖。若想在 Uniswap、Aave 和 Yearn 等DeFi 协议上运用 ERC20 代币，你需求授权 dApp 来运用这些代币。这便是所谓的 *ERC20 授权* 。这些授权对于 DeFi 渠道的运作来说必不可少，可是假如不加以控制，那将是十分危险的。

ERC20 授权的必要性

有了以太坊上的原生代币 ETH，你就能够将 ETH 发送至该智能合约，一起调用智能合约功能。这是经过所谓的可支付函数（payable funtion）完成的。可是，由于 ERC20 代币自身便是智能合约，你无法经过直接将代币发送到智能合约来调用其函数。

因而，ERC20 规范让智能合约运用 transferFrom() 函数代表用户搬运代币。为此，用户需求答应智能合约代表他们搬运代币。

这样一来，用户就能够将代币“存入”智能合约，一起智能合约会更新其状态来显现这笔存款。相反，假如你将 ERC20 代币发送至该智能合约，则合约不会更新其状态（例如，将这笔存款记入你的账户）。

例如，假如你将 DAI “存入” Aave 来赚取利息，你首先要答应 Aave 合约从你的钱包中取出一些 DAI。然后你调用 Aave 合约里的函数，指定你想要存入的 DAI 的数量。然后，Aave 合约运用 transferFrom() 函数从你的钱包中取出相应数量的 DAI，并将同等数量的 aDAI 代币记入你的账户。

无限 ERC20 授权的损害

将特定数量的 ERC20 代币（如 100 DAI）存入合约时，你就能够挑选将授权额设成这个数量。可是，许多运用会向用户要求无限授权。

这会带来极好的用户体会，由于用户不需求在每次存款时从头授权。设置无限授权后，用户只需求同意一次，之后存款时就不会再重复这一过程。

可是，该设置存在很大的弊端。众所周知，即便是老练的项目，也有或许存在缝隙。一旦你给了这些渠道无限授权，不只是你的存款会陷入危险之中，你的钱包中的代币也是如此。

在 Devcon 5 上，我第一次与 Paul Berg 谈到了这个问题。在这次大会上，Paul 就本文所评论的问题做了陈说。在开发 Sablier 时，Paul 在他的智能合约中发现了一个缝隙（现已修复了！），不仅一切存入该智能合约的 DAI（100 美元）有危险，一切测验者的钱包中的 DAI（1 万美元） 也是如此！

实际危险

长期以来，无限授权的危险首要是理论上的。在 Paul 所开发的 Sablier 渠道正式上线之前，这个缝隙就被修复了。其时，还没有呈现运用 ERC20 授权的进犯，可是只需渠道持续要求无限授权，早晚会出状况。

上一年，咱们现已看到了几起运用 ERC20 授权的进犯事件。

意外缝隙

今年早些时候，Bancor 呈现了一个缝隙，危及用户资金。履行 ERC20 transferFrom() 函数的函数变成了 public 特点（不再是 private 合约私有特点），因而任何人都能够履行该函数，并取走用户钱包中的资金。Bancor 履行了一次白帽黑客进犯，控制了损失，并将资金还给了用户。

歹意运用缝隙

除了 Bancor 的意外缝隙之外，还有许多歹意运用缝隙的状况。在今年夏天的 DeFi 热潮中，人们都在为各种以食物命名的 DeFi 分叉产品狂欢，其间也包含一些骗局。即便人们为了规避危险只存入少量代币，他们钱包中的代币也会由于无限授权而陷入危险。

ZenGo 就在一个名为 UniCats 的项目中发现了可运用缝隙。人们能够存入 Uniswap（UNI）代币，然后经过流动性挖矿取得 MEOW 代币（MEOW 代币是无法假造的）。可是假如要存款，用户必须供给 无限授权。假如项目遭到进犯，进犯者不仅能够拿走项目的存款，还能够拿走用户钱包内的一切 UNI 代币。

另一个例子是 Degen Money 项目。Degen Money 项目选用了一种不怎么高超（但还挺 “有用”）的办法。这个项目没有开发自己的智能合约，而是创建了一个前端来进行两次授权买卖。一次是向一个运转中的智能合约，另一次是向彻底不同的地址。

由于许多人没有专门检查钱包地址，这就导致进犯者能够取走用户钱包中的代币。

那硬件钱包呢？

总的来说，硬件钱包比手机、手提电脑和根据浏览器的钱包安全的多。原因是，控制资金的私钥安全地存储在硬件钱包中，并且永远不会脱离该设备。因而，经过硬件钱包，你能够保证没人能盗取你的私钥。

ERC20 授权的问题在于，没人需求盗取你的私钥才能从你的钱包中取走代币。因而，硬件钱包也无法防范本文所评论的歹意运用缝隙问题。

运用硬件钱包仍然是一种好习惯，由于硬件钱包确实能保护你免受其它缝隙进犯。可是，你需求留意的是，硬件钱包不能抵挡授权缝隙和其它许多智能合约缝隙。

dApp 开发者能够做些什么？

在 Devcon 的讲话中，Paul 提到了一些关于无限授权问题的解决计划。这些计划各有优缺点。其间最有用的计划是即批即用形式。在这种形式下，运用只会要求用户授权确切的数额，而非不限额。

这种计划的用户体会确实会差一些，由于每当用户想要发送买卖时，都需求发送一笔新的授权买卖，不能再像无限授权那样一了百了。这个形式的缺陷是会添加买卖费本钱，假如买卖费像上一年那样暴涨，就会带来很大的费事。

另一种替代型计划是，能够让用户挑选仅授权当下需求花费的数额，仍是授权更高的数额以便后续进行更多买卖。现已有多个项目选用这种战略，例如 1inch.exchange 和 Curve.fi。

另一个削减买卖本钱的解决计划是，选用 EIP2612 之类的规范，让用户能够经过签署消息来（免费）设置其授权额度，无需再经过发送买卖的形式。可是，这类规范并未得到广泛选用，并且围绕该规范打造的东西也不多。

用户能够做些什么？

由于 ERC20 授权是许多智能合约所不可或缺的部分，彻底停止授权的计划并不可行。可是在或许的状况下，请尽量避免无限授权。

人们现已比一年之前更加了解这一问题，因而有些 dApp 能够让用户挑选只授权当前需求花费的数额，可是大多数 dApp 仍然不行。尽管如此，高端用户还能够经过 Metamask 的界面来下降其授权额度。

在运用 dApp 时，请你思考一下是否需求常常运用这个 dApp，以及你是否信赖这个项目（假如是，挑选无限授权），仍是说你只会偶尔运用这个 dApp，或者底子不信赖这个项目（假如是，挑选小额授权）。无论是哪种状况，你最好都要定期（如，每月）检查你的授权额度，并吊销对不再运用的 dApp 的授权。

为便于检查并吊销这些授权，我开发了一种名为 revoke.cash 的东西。经过这个东西，你能够检查地址的代币余额和授权额度，之后就能够垂手可得地吊销或下降授权。类似的东西还有 approved.zone 等。

结论

许多去中心化运用的运转都离不开授权，可是无限授权通常并不利于安全性。2020 年现已呈现过几起运用 ERC20 授权的缝隙事件，人们对这个问题的知道比一年前深得多。作为一名用户，你能够采取一些措施来下降上文所述危险，包含定期检查并吊销多余授权。

视野开拓

教育是一个探索的过程，是观念与经验间的不断对话。真理是有条件的，只有在它们能够用来解释和治理世界的时候，才能被人们接受。-《穿越小径分岔的花园》