科普 | EIP-3074：改善以太坊用户体验

如果你是以太坊上的活跃用户，你很有可能会持有一些（ERC 20）代币来与以太坊生态中的各种 DeFi 项目进行交互。 不过这样做的前提是你必须持有ETH，因为ERC 20代币不能用来支付以太坊手续费。 此外，在向智能合约发送代币时，您通常需要执行两笔交易：一次允许目标合约使用您的代币，另一次将代币转移到目标合约。

EIP-3074 通过允许智能合约代表外部账户（即纯以太坊地址）发送交易来解决上述问题以及更多问题。

EIP 3074 引入了两条 EVM 指令，AUTH 和 AUTHCALL。 第一个命令根据 ECDSA 签名设置授权的环境变量，第二个命令发送授权调用。 这实质上是将外部账户的控制权授予了智能合约。

通过 AUTH 和 AUTHCALLEVM 指令（也称为操作码），智能合约可以根据签名消息获得外部账户的授权，并代表外部账户发送交易。 这开辟了许多可能性，例如：

与现有解决方案不同，EIP 3074 不需要智能合约钱包。 您可以将交易直接发送给负责执行交易的调用者（invoker）。 调用方是一个无状态、无信任的智能合约，不需要您事先将余额发送到智能合约。 EIP 3074 也没有引入新的交易类型。 从技术角度来看，EIP 3074 应该更容易实现，因为只引入了两条新的 EVM 指令。 遗憾的是，EIP 3074 仍在审核中，并且由于各种（安全）问题，目前还不知道何时会被激活。 如果你现在想尝试，可以使用浦西测试网。 在本文中，我将详细解释 EIP 3074 的工作原理。 如果你想看到 EIP 3074 的实际效果，我写了一个（批量）交易调用者合约作为例子。 单击下面的链接访问：请注意，此合同未经审计，只是概念证明。 不要在生产环境中使用。

AUTH 和 AUTHCALL 操作码

EIP 3074 定义了两个可以被智能合约调用的新操作码： 确认外部账户的授权需要来自该外部账户的签名消息。 调用AUTH的智能合约可以通过消息签名恢复signer，然后将其设置为authorizedEVM环境变量。 这样，每次智能合约调用AUTHCALL时，调用者都会被设置为授权地址。 当被调用的智能合约调用 CALLER（例如通过 Solidity 的 msg.sender）时，调用将由授权外部账户的地址执行以太坊的账户包含哪几个部分，而不是调用者（智能合约）的地址。 发送一个或多个交易的基本流程如下图所示：

- 上图显示了 EIP 3074 的基本流程，其中调用方合约发送多个交易 -

外部账户签署授权消息； 外部账户或其他gas payer发送交易数据和授权消息给caller contract； 调用方合约使用AUTH操作码进行授权，使用AUTHCALL操作码发送交易。 谁将交易发送给合约并不重要，只要外部帐户的签名有效即可。 因此，其他人（或账户）也可以发送交易。 请注意，目前无法使用 EIP 3074 从外部账户发送 ETH。这样做会极大地改变当前的一些重要假设，例如，检查交易是否有效。 调用方需要使用自己的 ETH 余额发送 ETH。 但是，您可以将 ETH 发送给调用者，调用者代表他们发送。 目前，AUTHCALL操作码中包含的valueExt字段必须硬编码为0。未来，如果找到合适的解决方案，我们可以更改此字段以允许调用者外部账户发送ETH。

授权消息和提交

为了执行授权，外部帐户必须签署特定格式的消息：

0x03 ||  || 

（注意：|| 用作字节连接运算符。）
这条消息包含三部分：一个魔法字节（0x03）、一个32字节的调用者地址（执行授权的智能合约的地址）和一个32字节的提交。


- 授权消息格式，包括提交示例 -
commit描述的是外部账户提交的数据，可以根据调用的某些属性计算出来，比如nonce的地址、值、hash等。 调用方合约可以根据属性重新计算提交，如果这些字段正确，则进行授权。 假设我们要发送以下交易（JSON 格式）：
[  {    "to": "0x6b175474e89094c44da98b954eedeac495271d0f",    "value": 123,    "nonce": 0  },  {    "to": "0x4bbeEB066eD09B7AEd07bF39EEe0460DFa261520",    "value: 123,    "nonce": 1  }]

我们可以散列这些字段（例如，以确定性方式连接它们，或使用 EIP 712 之类的规范）并将生成的散列用作提交。
我们可以提供要在智能合约中发送的交易和授权消息的签名，如 JSON 数据所示。 合约函数如下例所示：

function sendTransactions(Transaction[] calldata transactions, Signature calldata signature) external;

智能合约根据交易重新计算提交，并将此提交（连同签名）提供给 AUTH 调用。 这样做的目的是检索签名者的地址。 如果计算出的提交无效，则根据签名取回的地址将是错误的，这意味着交易将失败。 调用者对提交的安全性负全部责任。 您可以使用 0x0 作为提交对消息进行签名，并授予智能合约对外部帐户的完全访问权限。  EIP-3074之前的版本对commit的格式有更严格的要求，包括重放保护等，但后来为了提高灵活性已经去掉了。 这要求您在与呼叫者交互时相互信任。
限制和安全风险
EIP 3074 通过能够根据签名更改 CALLER，极大地改变了 EVM 的工作方式。 这给新合同和现有合同带来了潜在的漏洞。 因此，EIP 3074 已经正式审核。 下面解释了一些安全隐患。 出于各种原因，EIP 3074 建议只与受信任的呼叫者进行交互。 诸如 MyCrypto 之类的钱包接口提供了可信呼叫者的白名单。 使用此功能的用户只能为白名单中的来电者签署授权消息。
弱提交和重放攻击 如上所述，EIP 3074 没有定义提交的标准格式。 调用者可以以任何方式生成提交。 这意味着调用者有责任确保提交的安全性，例如防止重放攻击。 如果提交不包含某种随机数，攻击者可以轻松获取签名消息并将其再次发送给调用者。 恶意调用者可以在根本不验证提交的情况下获得对外部帐户的控制权。 每次签名时请小心。  EIP 3074 通过在授权消息中包含调用者的地址来提供最基本的防止重放攻击的保护。 这样，恶意调用者就无法重播来自其他调用者的授权消息。

可升级的调用者 EIP 3074 明确声明调用者程序不可升级。 如果调用程序是可升级的，攻击者可以部署另一个版本的调用程序，在不验证提交的情况下授予合约对外部帐户的控制权。
重入攻击 目前，智能合约可以使用 require(tx.origin == msg.sender) 来验证交易是否来自外部账户（而不是另一个合约）。 这提供了一些防止重入攻击的保护，因为它阻止了合约调用该函数。  EIP 3074 还允许 tx.origin 成为授权消息的签名者。 调用者执行的任何 AUTHCALL 都会导致 tx.origin == msg.sender 为真，即使此调用是由智能合约执行的，因此很可能会受到重入攻击。  EIP 3074 指出：“……尽管进行了详尽的搜索，但该 EIP 的作者未能找到任何此类重入攻击的示例。”
综上所述
EIP 3074 为以太坊带来了许多新的可能性。  AUTH 和 AUTHCALL 使外部账户能够将账户控制权授予智能合约调用者以太坊的账户包含哪几个部分，从而实现新的交易类型，例如批量交易和赞助交易。 然而，这个 EIP 也极大地改变了交易在以太坊上的工作方式，因此我们需要在主网上激活它之前更深入地考虑它的安全性。
联系我们
（结束）
（本文链接较多，可点击左下方“阅读原文”从EthFans网站获取）
原文链接：