#建立自定义帐户

正如上一篇已经提到的，每个帐户都应该实现IAccount接口。

 AA接口实现的一个例子是实现EOA 帐户。请注意，此帐户与以太坊上的标准 EOA 帐户一样，无论何时被外部地址调用都会成功返回空值，而这可能不是用户希望帐户的行为。

 #EIP1271

如果您正在构建智能钱包，我们也强烈建议您实施EIP1271签名验证方案。这是 zkSync 团队认可的标准，它用于下面描述的签名验证库。

 #部署过程

部署账户逻辑的过程与部署智能合约的过程非常相似。为了保护不想被视为账户的智能合约，应该使用部署系统合约的不同方法来做到这一点。用户应该使用部署系统合约的createAccount/create2Account 方法，而不是使用create/create2。

以下是如何使用 zksync-web3 SDK 部署帐户逻辑的示例：

 import { ContractFactory } from "zksync-web3";

 const contractFactory = new ContractFactory(abi, bytecode, initiator, "createAccount");

const aa = await contractFactory.deploy(...args);

await aa.deployed();

 #验证步骤的局限性

注意

l 验证规则尚未完全执行。

l 即使您的自定义帐户目前有效，如果不遵守以下规则，它也可能在将来停止工作。

 为了保护系统免受 DoS 威胁，验证步骤必须具有以下限制：

 l 帐户逻辑只能接触属于该帐户的插槽。请注意，该定义远远超出了用户地址处的插槽。

l 帐户逻辑不能使用上下文变量（例如block.number）。

l 还要求用户的帐户将随机数增加 1。仅需要此限制以保持交易哈希抗冲突性。将来，将取消此要求以允许更通用的用例（例如隐私协议）。

违反上述规则的交易将不会被 API 接受，尽管这些要求不能在电路/VM 级别强制执行并且不适用于 L1->L2 交易。

 为了用户更快地试用该功能，Era决定在完全实施对帐户验证步骤的限制检查之前公开发布帐户抽象。目前，尽管违反了上述要求，用户的交易仍可以通过 API，但很快就会改变。

 #Nonce持有者合约

出于优化目的，tx nonce和部署nonce都放在NonceHolder系统合约内的一个存储槽中。为了增加用户帐户的随机数，强烈建议调用incrementNonceIfEquals函数并传递交易中提供的随机数的值。

这是白名单调用之一，允许帐户逻辑调用外部智能合约。

 #从账户发送交易

目前，仅支持 EIP712 交易。要从特定账户提交交易，您应该提供交易的 from 字段作为发件人的地址，并提供带有帐户签名的 customData 的 customSignature 字段。

 import { utils } from "zksync-web3";

 // here the `tx` is a `TransactionRequest` object from `zksync-web3` SDK.

// and the zksyncProvider is the `Provider` object from `zksync-web3` SDK connected to zkSync network.

tx.from = aaAddress;

tx.customData = {

  ...tx.customData,

  customSignature: aaSignature,

};

const serializedTx = utils.serialize({ ...tx });

const sentTx = await zksyncProvider.sendTransaction(serializedTx);