帐户抽象仍然需要EOA签名？

Question

我的印象是，使用帐户抽象，我将能够直接启动智能契约调用而不需要EOA。然而，在阅读了zkSync的帐户抽象示例之后，情况并非如此。

  // The two owners of the multisig
  const owner1 = Wallet.createRandom();
  const owner2 = Wallet.createRandom();

您需要上述两个EOA的签名才能使用multisig发送任何事务。

const signature = ethers.utils.concat([
  // Note, that `signMessage` wouldn't work here, since we don't want
  // the signed hash to be prefixed with `\x19Ethereum Signed Message:\n`
  ethers.utils.joinSignature(owner1._signingKey().signDigest(signedTxHash)),
  ethers.utils.joinSignature(owner2._signingKey().signDigest(signedTxHash)),
]);

aaTx.customData = {
  ...aaTx.customData,
  customSignature: signature,
};

...

const sentTx = await provider.sendTransaction(utils.serialize(aaTx));

这与目前还没有实现帐户抽象的mainnet上的现有multisigs有什么区别呢？

Answer 1

目前，在Eth (没有任何类型的帐户抽象)中，EOA包含签名者(授权事务)和帐户/分类账(持有资产的地方)。帐户抽象的要点是将它们分开:您将拥有一个保存身份验证信息的实体(通常是私钥)和另一个保存资产的独立实体(通常称为帐户契约)。

因此，您的EOA只包含签名密钥(或您希望使用的任何其他机制以及帐户契约支持的其他机制)。账户契约是指拥有任何资产并包含验证其使用情况的逻辑的实体。

例如，帐户契约可以包含本机multisig。因此，它需要多个签名来执行一个操作--可能是执行涉及它所包含的资产的某些事务。如果没有帐户抽象，multisig是一个单独的契约，它包含资产，但是您的EOA也可以拥有不同的资产。我认为multisig不是帐户抽象的最佳用例。

帐户抽象的地方是类似于付费之类的东西。如果网络以本地方式支持帐户合同，则从帐户合同中收取支付费用。所以不管你发什么交易，他们的煤气费都是由账户合同支付的。这就带来了有趣的可能性:例如，您可以允许任何用户与该帐户合同交互一周，这样合同就可以支付所有的天然气费用。或者也许它每个星期二只付费用。

其他很酷的功能是，例如会话密钥:您授权帐户合同与其他(游戏)合同互动的下周，并支付最多50美元的燃气费总额。然后，你不需要发送批准一个星期，你可以直接与游戏合同互动无痛。

有很多选择，我觉得我们才刚刚开始理解帐户抽象的力量。

Answer 2

没有EOA签名的帐户抽象即将到来！

最新的帐户抽象标准ERC-4337允许验证逻辑是由钱包合同规定的的S validateUserOp()函数。

下面是一个简单帐户的示例，它将EOA指定为签名者，尽管它可以对任何方案进行扩展。EIP甚至还指定了一个助手Aggregator契约，它可以聚合钱包的签名(如BLS)。

Answer 3

在我看来: 4337帐户抽象并不是发明了什么，而是“标准化”了现有的技术：

• 加油站和付款人
• 离链交易接续器
• “智能账户”和“智能钱包”
• ..。

最后，我们将有标准用例：

• 智能契约现在可以通过将TXs发送到EntryPoint来启动TXs。
• 我们将能够使用其他auth.schemes (参见validateUserOp()函数)，而不是使用私有/公共密钥区进行身份验证。

所以回到你的问题：

我当时的印象是，使用帐户抽象，我可以直接启动智能合同调用而不需要EOA？

是的，使用AA智能合同将能够启动智能合同呼叫.