近来以太坊上最火爆的领域就是 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 授权的漏洞事件，人们对这个问题的认识比一年前深得多。作为一名用户，你可以采取一些措施来降低上文所述风险，包括定期查看并撤销多余授权。