我们可以对这些字段进行哈希计算（例如，用确定性的方式将它们连接起来，或使用 EIP 712 之类的规范），并将得到的哈希值用作 commit。

　　我们可以在智能合约中提供要发送的事务和授权消息的签名，如 JSON 数据所示。合约函数就如下面这个例子所示：

　　``` *

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

　　智能合约根据 transactions 重新计算 commit，并将这个 commit （连同签名一起）提供给 AUTH 调用。此举的目的是找回签名者的地址，如果计算得到的 commit 无效，根据签名找回的地址将是错误的，也就是说事务将失败。

　　调用者对 commit 的安全性负全责。你可以将 0x0 作为 commit 来签署消息，并授予智能合约对外部账户的完整访问权。前几版 EIP-3074 对 commit 的格式要求更为严格，包括重放保护等，但是后面为了提高灵活性已经将其移除。这就要求你在与调用者进行交互时必须信任对方。

　　由于能够根据签名更改 CALLER，EIP 3074 极大地改变了 EVM 的运作方式。这会为新合约和现有合约引入潜在漏洞。因此，EIP 3074 已经经过正式审计。

　　下文解释了一些安全隐患。由于种种原因，EIP 3074 建议只与可信调用者交互。MyCrypto 等钱包界面提供可信调用者白名单功能。使用该功能的用户只能为白名单内的调用者签署授权消息。

　　正如上文解释的那样，EIP 3074 没有为 commit 定义标准格式。调用者可以通过任意方式生成 commit。这意味着，调用者有责任确保 commit 的安全性，例如，抵御重放攻击。

　　如果 commit 不包含某种随机数，攻击者就可以轻松获取已签署的消息，再一次发送给调用者。恶意调用者完全不需要验证 commit，就可以获得外部账户的控制权。每次签署消息时，请你务必谨慎。

　　EIP 3074 通过将调用者的地址包含在授权消息内，提供了最基础的重放攻击保护。这样一来，恶意调用者就无法重放其他调用者的授权消息。

　　EIP 3074 明确声明调用者程序不可升级。如果调用者程序是可以升级的，攻击者就可以部署另一个版本的调用者，在不验证 commit 的情况下授予合约对外部账户的控制权。

　　目前，智能合约可以使用 require(tx.origin == msg.sender) 来验证事务是否来自外部账户（而非另一个合约）。这样可以在一定程度上防止重入攻击，因为它可以防止合约调用该函数。

　　EIP 3074 也允许 tx.origin 成为授权消息的签名者。调用者执行的任何 AUTHCALL 都会导致 tx.origin == msg.sender 成真，即使这个调用是由智能合约执行的，因此很有可能遭到重入攻击。EIP 3074 指出：“……本 EIP 的作者并未找到任何有关这种重入攻击的例子，尽管没有进行详尽的搜索。” (责任编辑：admin)