浅谈：在ZK-rollup和以太坊上的帐户抽象

虽然今天我们的加密钱包可以用于访问和管理我们的加密货币，NFT，并进行质押，但我认为从账户的角度来看，还有很多事情是可以做的。StarkNet和zkSync遵循Vitalik的愿景推出了一项长期功能：帐户抽象。

抽象是什么?

抽象过程是隐藏信息的实践。这增加了计算机系统在更高层次上的使用能力，并会对底层的过程知之甚少。

在程序员PoV中，我们假设其隐藏了对象的所有数据，但只保留了其相关数据，这样会减少复杂性并提高效率。

账户抽象的定义

在以太坊网络上，目前有两种类型的账户。

EOA：外部账户是存在于EVM(以太坊虚拟机)之外的用于加密货币发送和接收的钱包：冷钱包，如 Ledger、MetaMask、Phantom 等。

合约帐户是存在于EVM中的“智能合约”。例如，Uniswap上的池基本上是智能合约。

以太坊帐户抽象的目标是将两种帐户类型减少到一种，即合约帐户。单一帐户类型将具有处理代币和合约的功能。开发人员和用户将不再需要区分帐户类型，因为交易将完全移入EVM，并脱离区块链协议。

外部账户精度

EOA有三个属性：

代表该账户可用ETH的余额。

确保每笔交易都是唯一的随机数。

唯一标识网络上帐户的地址。

值得一提的是，在以太坊上，每笔交易都必须从EOA发起。这意味着当由以太坊虚拟机(EVM)执行一笔交易时，被触及的第一个帐户必须是EOA，并且相应的账户必须向矿工支付费用以执行整个交易。

以太坊上的每个账户都与一个名为Keypair的加密对象相关联：

私钥：用于签署数字消息。

公钥：允许任何人验证给定的签名是否确实是其对应的私钥签名。

在StarkNet和zkSync上的帐户抽象

截止到今天，StarkNet和zkSync 2.0在帐户抽象方面是最先进的，它们都设法用特定方式实现帐户抽象。

账户抽象有两个主要目标：

签名抽象：允许不同的帐户合约使用不同的签名验证方案。

支付抽象：允许不同的交易支付模式。例如，由另一方/合约支付或使用ETH以外的其他代币进行支付。

StarkNet Account模型仍然用合约来表示，也就是所谓的“账户合约”。简单来说：任何部署在StarkNet上的Cairo智能合约都可以是一个Account，唯一的要求是它们必须符合一个特定的接口，该接口具有验证和执行交易的方法。

在zkSync端，一个帐户还需要实现两个函数：validateTransaction 和 isValidSignature。

通过这种抽象，我们可以直接看到：

使用多个密钥对来验证交易(简单地将多重签名集成在一起)。

更改我们的帐户Keypair。

使用与ECDSA不同的签名方案。

它能带来什么?

这可能是这个故事中最重要的部分：让我们更深入地讨论帐户抽象的用例。我们可以将这些用例分成两个不同的领域：

用户简化

技术用例

用户简化：会话密钥

假设我们正在玩一款链上游戏：目前我们需要自己签署每一笔交易。就是说每做一个动作（比如在收集奖励，移动角色，发送信息时），就需要签署一项交易。

会话密钥是授权玩家在特定时间内玩游戏的理念。我们生成了一个会话密钥，保存在浏览器的本地存储中，并且仅授权在10分钟内允许其签署交易。10分钟后，密钥将被撤销，我们将需要创建一个新的密钥并再次授权。

在这种扩展下，我们还可以想象创建批处理交易：与在超市中选择产品并在最后只支付一次费用的抽象相同。

用户简化：交易自动化和拆分权限

使用抽象账户，就可以实现更改给定钱包的主要签名密钥的功能，甚至可以管理多个签名密钥。我们可以将自己的管理密钥放在冷钱包中，而其他密钥就保存在不太安全的设备上，并且这些将只被授权执行某些操作。

一个很酷的例子:

我不怎么使用的最安全的密钥是唯一能够转移或发送超过1k美元到另一个账户的密钥，然而，我也可以在我的计算机上使用那些不安全的密钥来执行操作，例如在某些特定的dapp上领取奖励，或在链上游戏中执行任何交易。

现在让我们假设这些密钥保存在执行自动交易/运行我们自己的bot的服务器中：我们可以确保这些密钥只能用于执行自己设置的操作并提高安全性。

最后一个实用程序可能是一个协议，该协议代表我们将 DCA 确定为循环交易。

技术用例：为他人支付费用

这是我们可以使用帐户抽象做的最有趣的事情之一。想象一下，一个账户可以支付另一个账户的费用，该有多么的令人兴奋。

总结

我们已经看到帐户抽象如何可以成为区块链未来的游戏规则改变者。我个人深信，账户抽象将迎来一个新的用例时代，尤其是在视频游戏产业链上。