zkSync Era 的收费模式类似于以太坊，gas按计算生成本、链上发布数据生成本和存储效率收费。但是，zkSync Era 打包发布到L1 和证明生成的外部费用。

 由于发布数据（在L1上）的L1自然价格波动很大，因此所需要的L2数量gas是可变的。因此，对于每个块，zkSync Era定序器确定义了以下动态参数：

 A gasPrice：单位 gas 的价格，以 gwei 为单位。

B gasPerPubdatagas：在以太坊上发布了一个字节数据的量。

 重点

1 只有L2状态存储槽更新发布在L1上。

2 例如，如果同一个储槽在同一个汇总中更新了 10 次，则只有最后一次更新发布在以太坊上，因此只有一次 gas 费用。

 #收费模式概览

在 zkSync 时代，与每个操作码都有固定 gas 价格的以太坊不同，由于 L1 上 gas 价格的波动，存储写入费用保持动态。其他操作码价格不变，类似于以太坊。可以参阅zkSync 操作码文档了解Era如何计算它们。

 与以太坊一样，成为本最高的操作是存储更新。算术运算的操作相对方便，因为它只涉及计算而不需要更新存储。

 我们相对于optimistic rollups的一个相当大的优势是，zkSync Era不会将所有交易数据发布到L1，而只是发布状态差，因此向L1发布的数据要少得多。另一个优势是具有成本效益的合同重新部署。一个示例是 DEX，它具有用于不同 Pair 池的 PairFactory 合约。 Pair 的合约字节码仅在第一个实例部署时发布。 之后，后续部署只涉及更新一个存储槽，该存储槽在新部署的 Pair 地址上设置合约代码哈希。

 #设计建议

 1 尽可能少地更新存储槽：检查您的代码是否可以避免不必要的存储更新。

2 尽可能多地重新使用存储槽：只有最极端的状态差异才会在以太坊上发布。

3 尽可能重用合约代码：

4>在以太坊上，避免免费构造函数将其放入常量中可以减少少量合约部分时的一些气体成本。

5>在zkSync Era上恰恰相反：由于合约字节码只发布了一次，只更新构造生成函数就可以节省大量费用。

 想象一下能够为您的协议的用户支付费用！Paymaster是可以补偿其他账户交易的账户。paymasters 的另一个重要用例是方便使用 ERC20 代币支付费用。虽然 ETH 是 zkSync 中的gas代币，但 paymasters 可以提供将 ERC20 代币即时兑换成 ETH 的能力。

 如果用户想与付款人互动，他们应该在他们的 EIP712 交易中提供非零paymaster地址。paymaster 的 paymasterInput 字段中提供了 paymaster 的输入数据。

 #出纳员验证规则

 Tops:

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

l 即使您的Paymaster目前在工作，如果不遵守以下规则，将来也可能会停止工作。

 由于应该允许多个用户访问同一个paymaster，恶意 paymaster可以对Era的系统进行 DoS 攻击。为了解决这个问题，一个类似于EIP4337 信誉评分的系统将会被使用。

 与原始 EIP 不同，付款人可以接触任何存储槽。此外，如果满足以下任一条件，出纳员将不会受到限制：

 l API 节点验证通过后已经超过 X 分钟（X 的具体值将在后面定义）。

l 读取的槽的顺序与 API 节点上运行期间的顺序相同，并且值已更改的第一个槽是用户的槽之一。这是为了保护Paymaster免受恶意用户的侵害（例如，用户可能已经删除了 ERC20 代币的配额）。

 #内置Paymaster流程

 虽然一些付款人可以在没有任何用户交互的情况下进行简单的操作（例如，始终为用户支付费用的协议），但有些付款人需要交易发送者的积极参与。一个值得注意的例子是将用户的 ERC20 代币交换为 ETH 的 paymaster，因为它要求用户为 paymaster 设置必要的津贴。

 帐户抽象协议本身是通用的，允许帐户和付款人实现任意交互。然而，默认账户 (EOA) 的代码是不变的，但Era仍然希望它们能够参与自定义账户和付款人的生态系统。这就是为什么Era对paymasterInput交易领域进行了标准化，以涵盖 paymaster 功能的最常见用例。

 用户的账户可以自由实施或不实施对这些流程的支持。但是，强烈建议保持 EOA 和自定义帐户的界面相同。

正如上一篇已经提到的，每个帐户都应该实现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);

为了安全起见，NonceHolder 和 ContractDeployer 系统合约都只能使用特殊的 isSystem 标志来调用。  要使用此标志进行调用，应使用 SystemContractsCaller 库的systemCall/systemCallWithPropagatedRevert/systemCallWithReturndata 方法。

在开发自定义帐户时实际上必须使用这个库，因为这是调用 NonceHolder 系统合约的非视图方法的唯一方法。 此外，如果你想让用户部署他们自己的合约，你将不得不使用这个库。 EOA账户的实现可以作为参考。

#扩展 EIP4337

为了给运营商提供 DoS 保护，EIP4337 施加了一些限制在新窗口中打开关于帐户的验证步骤。他们中的大多数，尤其是那些关于禁止操作码的，仍然是相关的。但是，为了更好的用户体验，已经取消了一些限制。

扩展允许的操作码

允许调用已经部署的/delegateCall/staticcall 合约。 与以太坊不同，Era无法编辑已部署的代码或通过 selfdestruct 删除合约，因此可以确定合约执行期间的代码是相同的。

 #扩展属于用户的槽集

在原始EIP中，AA的validateTransaction步骤允许账户只读取自己的存储槽。 然而，有些插槽在语义上属于该用户，但实际上位于另一个合约的地址上。 一个值得注意的例子是 ERC20 余额。

 此限制通过确保不同帐户用于验证的插槽不重叠来提供 DDoS 安全性，因此它们实际上不需要属于帐户的存储。

为了能够在验证步骤中读取用户的 ERC20 余额或津贴，在验证步骤中，地址 A 的帐户将允许使用以下类型的插槽：

1、属于地址 A 的插槽。

2、任何其他地址上的插槽 A。

3、任何其他地址上类型为 keccak256(A || X) 的插槽。 （覆盖映射（地址=>值），通常用于ERC20代币中的余额）。

#将来可以允许什么？

将来，Era甚至可能允许有时间限制的交易，例如允许检查它block.timestamp <= value是否返回false等。这种可信的方式将需要部署一个单独的文库，但它会大大增加帐户的能力。

 每笔交易都经过以下流程：

验证步骤

在验证步骤中，账户应决定是否接受交易，如果接受，则支付费用。如果任何部分验证失败，则该帐户不收取费用，并且该交易不能包含在区块中。

 Step 1.系统检查交易的随机数之前没有被使用过。可以在#保持随机数唯一章节中阅读有关保留随机数唯一性的更多信息。

 **Step 2.**系统调用validateTransaction账户的方法。如果它没有恢复，请继续执行下一步。

 **Step 3.**系统检查交易的随机数是否已被标记为已使用。

 Step 4.

1>（no paymaster）。系统调用payForTransaction账户的方法。如果它没有恢复，请继续执行下一步。

2>（paymaster）。系统调用prepareForPaymaster发送方的方法。如果此调用没有恢复，则validateAndPayForPaymasterTransaction调用 paymaster 的方法。如果它也没有还原，继续执行下一步。

 **Step 5.**系统验证引导加载程序至少收到了tx.gasPrice * tx.gasLimitETH 给引导加载程序。如果是这样，则认为验证完成，可以进行下一步。

 #执行步骤

执行步骤被认为负责交易的实际执行，并将任何未使用的gas的退款发送回用户。如果在这一步有任何回滚，交易仍然被认为是有效的，并将被包含在区块中。

 **Step 6.**系统调用executeTransaction账户的方法。

 Step 7.（仅在交易有 paymaster 的情况下）postTransaction调用 paymaster 的方法。此步骤通常用于向发送方退还未使用的 gas，以防 paymaster 被用来以 ERC-20 代币支付费用。

 #费用

在 EIP4337 中，可以看到三种类型的气体限制：verificationGas, executionGas, preVerificationGas，它们描述了区块中交易包含的不同步骤的气体限制。zkSync Era 只有一个字段，gasLimit涵盖了所有三个的费用。提交易时，确保gasLimit足以涵盖验证、支付费用（上面提到的 ERC20 转账）和实际执行本身。

默认情况下，调用estimateGas添加一个常量来覆盖 EOA 帐户的收费和签名验证。

 推荐每个账号实现IAccount时在新窗口中打开界面。它包含以下五个方法：

l **validateTransaction（验证交易）**是强制性的，系统将使用它来确定 AA 逻辑是否同意继续进行交易。如果交易不被接受（例如签名错误等），该方法应该恢复。如果调用此方法成功，则认为已实现的账户逻辑接受交易，系统将继续交易流程。

l **executeTransaction（执行交易）**是必填项，在向用户收取费用后由系统调用。此函数应执行交易的执行条件。

l **payForTransaction（支付交易）*是可选的，如果交易没有 paymaster，系统将调用它，即账户愿意为交易付款。此方式需按账户支付费用。需要注意的是，如果帐户永远不会支付任何费用并且将始终依赖paymaster功能，则不必实施此方法。此方法必须至少将tx.gasprice * tx.gasLimitETH* 发送到引导加载程序地址。

l **prepareForPaymaster（paymaster准备）**是可选的，如果交易有paymaster，系统将调用它，即有一个不同的地址为用户支付交易费用。应该使用此方法来准备与paymaster的交互。它可以提供帮助的显著示例之一是批准paymaster的 ERC-20代币。

l executeTransactionFromOutside（外部执行交易），从技术上讲，这不是强制性的，但强烈建议这样做，因为在优先模式的情况下（例如，如果操作员没有响应），需要某种方式才能从“外部”使帐户开始交易（基本上这是对标准以太坊方法的回退，其中 EOA 是智能合约开始交易的地方）。

 #IPaymaster接口

 与 EIP4337 一样，zkSync账户抽象协议支持 paymasters：可以补偿其他账户交易执行的账户。

 每个paymaster都应该实施IPaymaster在新窗口中打开界面。它包含以下两个方法：

l validateAndPayForPaymasterTransaction是强制性的，系统将使用它来确定paymaster是否批准为此交易付款。如果付款人愿意为交易付款，则此方法必须至少发送tx.gasprice * tx.gasLimit给操作员。它应该返回context将成为该方法的调用参数之一的postTransaction。

l postTransaction是可选的，在事务执行后调用。需要注意的是，与 EIP4337不同，无法保证此方法会被调用。特别是，如果交易因错误而失败，则不会调用此方法out of gas。它有四个参数：由 返回validateAndPayForPaymasterTransaction、交易本身、一个指示交易执行是否成功的标志，以及 paymaster 可以退还的最大 gas 量。

#Transaction具有特殊含义的结构的保留字段

需要注意的是，上述每种方法都接受交易结构在新窗口中打开。虽然它的一些字段是容易理解的，但也有 6 个reserved字段，每个字段的含义由交易的类型定义。Era并没有给这些字段命名，因为在未来的某些交易类型中可能不需要它们。目前，惯例是：

**reserved[0]**是随机数。

**reserved[1]**是msg.value应该与交易一起传递。

 随着 2023 年 2 月发布的系统更新，该ergs概念仅由 VM 使用，而 API 层使用gas.

 #介绍

在以太坊上有两种类型的账户：外部拥有账户（EOAs）和合约账户。前一种类型是唯一可以发起交易的类型，而后者是唯一可以实现任意逻辑的类型。对于某些用例，例如智能合约钱包或隐私协议，这种差异使得难以实现。因此，此类应用程序需要 L1 中继器，例如EOA，以帮助促进智能合约钱包的交易。

 zkSync Era 中的账户可以发起交易，如 EOA，但也可以在其中实现任意逻辑，如智能合约。此功能称为“帐户抽象”(AA)，旨在解决上述问题。

 tips：

zkSync Era 是第一个实现原生账户抽象的 EVM 兼容链。当前正在评估该实施与测试网和主网上的 EVM 项目的配合情况。目前还没有发现不兼容的地方。

由于该功能处于早期阶段，可能会看到对帐户抽象 API/接口的一些重大更改。但是，鉴于帐户在 zkSync Era 中进行了版本控制，即使发布重大更改后，旧帐户仍然可以使用。

 #设计

zkSync 上的账户抽象协议与EIP4337非常相似，为了提高效率和更好的用户体验，两者协议仍然有有多不同。

 #保持随机数唯一

tips：

1 当前模型不允许自定义钱包同时发送多个交易并保持确定性排序。

2 对于 EOA，随机数预计会按顺序增长；而自定义账户则无法保证交易顺序。

3 将来，我们计划切换到一种模型，帐户可以在顺序或任意随机数排序之间进行选择。

 每个区块链的重要定量之一是每个交易都有一个唯一的哈希值。使用任意帐户抽象持有此属性并非微不足道，尽管帐户通常可以接受多个相同的交易。尽管根据区块链规则，这些交易在技术上是有效的，但索引器和其他工具很难处理违反哈希唯一性的问题。

 需要有一种协议级别的解决方案，既对用户来说成本低廉，又能在有恶意运营商的情况下保持稳定运行。确保交易哈希不重复的最简单方法之一是让一对 (sender, nonce) 始终唯一。

 使用以下协议：

 1 在每次交易开始之前，系统会查询NonceHolder以检查提供的 nonce 是否已被使用。

2 如果随机数尚未使用，则运行交易验证。在此期间，提供的随机数预计将被标记为“已使用”。

3 验证后，系统检查此随机数现在是否标记为已使用。

 用户将被允许使用任何 256 位数字作为随机数，他们可以在系统合约中的相应密钥下放置任何非零值。这已经被协议支持，但不在服务器端。

 一旦发布服务器端支持，将提供更多关于与NonceHolder系统合约的各种交互的文档以及教程。目前，建议只使用该incrementNonceIfEquals方法，它实际上强制执行随机数的顺序排序。

 #标准化交易哈希

未来，计划在 zkSync 上支持高效的交易包含证明。这将需要我们在引导加载程序中计算交易的哈希值。由于这些计算对用户来说不是免费的，因此在 AA 方法的接口中包含交易的哈希值是公平的（以防帐户出于某种原因可能需要此值）。IAccount这就是为什么下面描述的和接口的所有方法都IPaymaster包含交易的哈希值以及推荐的签名摘要（由 EOA 为该交易签名的摘要）。

尽管这可能是短期现实，但重要的是要考虑此设计背后的基本原理。 每个 L1 批处理（包含多个 L2 区块）都在单个 VM 实例中执行。VM一个接一个地执行事务，然后执行一些与最后一个事务无关与整个批处理无关的代码。目前，从手续费中收取的 ETH 是从 bootloader 正式地址转移到区块矿工地址。此传输发出一个事件（与任何其他传输一样），该事件包含在“空”L2 区块中，因此可以通过 API 访问它。

Era可以将它添加到L1批次的最新L2区块中，但想象一下以下场景：如果一个 L2 块被关闭，但它的 L1 批次没有关闭，并且该节点在一段时间内没有收到任何新交易，那么L1 批处理必须在超时前关闭。如果将事件添加到最近关闭的区块中，它将修改区块，从而导致某种重组。 为避免这种情况，Era构建了一个仅包含事件的纯虚构块。

#检索区块号和批号 在 zkSync API 中访问区块号与您在以太坊上的访问方式类似。例如，eth_blockNumber返回最新的 L2 区块的编号，并且eth_getBlockByNumber，给定一个区块号，返回有关请求的区块的信息。 对于 L1 批次，要检索最新的批次号，请使用 zkSync API 方法zks_L1BatchNumber。此外，通过查询一个区块，您可以看到包含该区块的批次的批号。在交易收据中，该字段l1BatchNumber是包含交易的批号。该字段l1BatchTxIndex返回一个批次中包含的所有交易中的交易位置。

#哈希值 zkSync 中的区块哈希值是确定性的，并且源自以下公式：“keccak256(l2_block_number)”。具有确定性区块哈希的原因是这些哈希不可证明（请记住，L2 块不会提交给 L1）。建议项目不要使用 L2 区块哈希作为随机源。

#区块号和时间戳注意事项 然而，使用任何 SDK 通过 API 检索的区块的编号和时间戳属性将引用 L2区块，并且block.number在block.timestampEVM 中（在智能合约上），分别返回 L1 批次的编号和时间戳。

#为什么我们从 API 返回 L2区块？ 在 zkSync Era 上，我们从 API 返回 L2区块，因为这是所有平台（包括 SDK、Metamask 和所有其他流行的钱包）可以感知我们的交易已处理的方式。预计交易一旦包含在区块中就会被处理。这就是为什么我们需要比 L1 批次更快地生成 L2区块。

#为什么我们在 EVM 中返回 L1 批次？ 目前，我们在 VM 中返回 L1 批次的编号和时间戳，因为与 L2 区块相关的值将无法证明。与包含对链状态的某种承诺的以太坊区块不同，在 zkSync Era 上，这些区块不会有这样的承诺，因为计算 Merkle 树的成本太高，每批次只能执行一次。 一种在 EVM 中检索 L2 块编号和时间戳的方法正在开发中。

 #zkSync Era的区块

 在 zkSync 中有两种区块的概念：L2 区块和 L1 rollup 区块。

L2 区块，或简称“区块”，是在 L2 上创建的区块，即在 zkSync Era 网络上，它们不包含在以太坊链中。

 另一方面，L1 rollup 区块是连续的 L2 区块批次，其中包含相同顺序的所有交易，从批次中的第一个区块到最后一个区块。

 顾名思义，L1 批次提交给以太坊。有这些不同概念的主要原因是一个区块可以包含最少数量的交易（或根本没有），因此可以快速处理，而在批处理中包含许多交易以分摊与之交互的成本。

 #区块属性

以下是当用任何 SDKgetBlock使用 API 中的方法时返回的区块属性

hash 区块的哈希值。如果待办中则为空

parentHash 它指的是 L2 中父块的哈希值

number 当前块的编号。如果待处理则为 null

timestamp 整理块时的 UNIX 时间戳

nonce 这是基于账户计数器的最新交易，它跟踪它做了多少交易。如果待处理则为 null

difficulty 当前区块难度返回 2500000000000000（zkSync 没有工作共识证明）

gasLimit 此块中允许的最大gas编码为十六进制，始终返回 2^32-1

gasUsed 该区块实际使用的gas

transactions 交易对象数组

baseFeePerGas 该区块的类似 EIP1559 的基本费用

 #处理时间

当在 zkSync Era 上进行交易时，它们会立即处理并添加到区块中，区块会立即生成。一旦 zkSync Era 完全去中心化，区块时间将需要几秒钟，因为相关节点需要达成共识。

 密封 L1 批次所需的时间取决于系统活动 - 系统活动越多，密封批次的速度就越快。密封一批会有几个标准。

 通常，在以下情况下，批次将被密封：

1 达到批量“容量”：容量包括使用的 L1 gas、消耗的 L2 gas体以及其他几个参数。

2 批处理超时已过。

3 提交后，区块将经历不同的阶段。

#先决条件

建议先阅读https://ethereum.org/en/developers/docs/accounts/了解以太坊账户。

#交易如何运作

当用户在以太坊上发起交易时，会创建一些特定数据：

收件人：收件人是账户收件交易的地址。收件人可以是合约账户，也可以是外部收件人。每笔交易都针特定的收件人。

Nonce：此字段显示基于帐户计数器的最近交易，该计数器跟踪它进行了多少次交易。网络使用交易随机数来确保交易以正确的顺序完成。

Gas Price：大部分交易都需要交易发起人支付费用。该组成本是按单位计算的。单位是Wei，一个比较小的以太单位。

Gas Limit：交易者指定交易使用的gas单位数量。这是可以消耗的气体总量。

Value：发送者账号希望传给接收者的Wei或Ether的数量。

数据：如果交易接收方是智能合约，则数据包含要执行的合约功能的信息。这包括具有不同长度的数据。

签名：签名表示通信的发送者。签名是在外部拥有的账户使用其私钥确认并签名交易时创建的。

#交易类型

简单或资产转移：这是指以以太币的形式从一个账户到另一个账户的常规代币转移。

合约部署交易：zkSync 上的合约部署与以太坊有很大不同。

l 以太坊：当用户向零地址 (0x000...000) 发送交易时，合约部署发生，交易的数据字段等于与构造函数参数连接的合约字节码。

l zkSync Era：要在 zkSync 上部署合约，用户调用 ContractDeployer 的创建函数并提供要发布的合约的哈希值以及构造函数参数。 合约字节码本身在 EIP712 交易的 factory_deps 字段中提供。 如果合约是一个工厂（即它可以部署其他合约），合约字节码应该包含在 factory_deps 中。

#什么时候交易被认为是最终完成？

交易最终性是指交易不能在区块链网络中被篡改。

在股权证明下，以太坊交易在正常情况下平均需要2.5个epochs（16分钟）完成：恢复该交易将花费以太坊总供应量的1/3。

一旦一个区块在zk rollups中被填充和加密，它的状态就会提供给太坊主链。然后开始证明阶段，为每个区块交易构建一个SNARK。一旦完成，SNARK将被发送到L1智能合约上进行验证，交易状态将在验证后成为最终状态。

从 zkSync 的角度来看，最终性发生在 L1 执行交易（SNARK 验证）时。此时，保证与同一个 L1 区块内的任何其他 L1 交易相同；发出的L1块越多，该交易被推翻的可能性就越来越小。

当用户传输交易时，zkSync 会等待整个区块被填充满，这意味着最终确定时间可能会更长，具体取决通于zkSync 发送的交易量。随着吞吐量的增加，最终确定时间将减少。

#operators到底是什么？

operator是执行基本ZK rollup 功能的参与者。他们负责任出块、打包交易、进行计算，并将数据提供给以太坊主链进行验证。

一些 zkSync Lite 的经验将有助于理解一些核心概念，例如最终性是如何工作的。从所有其他方面来看，zkSync Era 和 zkSync Lite 是非常不同的系统，在 zkSync Era 上构建不需要使用后者的经验。

#我需要什么来开始构建？

所有现有的以太坊 SDK 都可以开箱即用，将拥有与以太坊相同的体验。如果你想启用高级 zkSync 功能，如帐户抽象，则应使用 zkSync SDK。

唯一需要使用 zkSync SDK 的地方是在合约部署期间。这可以通过我们的 hardhat 插件轻松完成。

#zkSync 快速入门

l 如何安装 zkSync hardhat 插件并使用它部署智能合约。

l 如何使用该库为您的 dApp 构建前端zksync-web3。

#在 Metamask 上连接到 zkSync Era

为了将 zkSync Era alpha 主网网络添加到您的钱包，您需要输入以下详细信息：

1、登录您的 Metamask 钱包并单击顶部中心的网络：

2、单击添加网络。

3、向下滚动到网络列表的底部，然后单击手动添加网络。

4、填写 zkSync Era 主网或测试网网络详细信息：

主网网络信息

网络名字：zkSync Era Mainnet

远程过程调用网址：https://mainnet.era.zksync.io

链号：324

货币符号：ETH

URL：https://explorer.zksync.io/

WebSocket 网址：wss://mainnet.era.zksync.io/ws

测试网网络信息

网络名字：zkSync Era Testnet

远程过程调用网址：https://testnet.era.zksync.dev

链号：280

货币符号：ETH

URL：https://goerli.explorer.zksync.io/

WebSocket 网址：wss://testnet.era.zksync.dev/ws

点击“保存”

#为什么 Metamask 原生合约交互不起作用？

目前无法通过 Metamask 使用 EIP-1559 交易与 zkSync Era 智能合约进行交互。zkSync Era 不支持 EIP1559 交易。

当前版本的zkSync Era 解决了以太坊上大量应用程序的需求，并计划很快发布更多功能，zkSync Era 将为开发人员提供一个设计空间来试验目前在以太坊上不可能实现的应用程序。在这个版本中，将支持以下功能：

l 原生支持 ECDSA 签名：与第一版 zkSync 和大部分 ZK rollup 不同，注册用户私钥不需要特殊操作。任何帐户都可以在 L2 中使用与 L1 相同的私钥进行管理。

l Solidity 0.8.x 支持：部署您现有的代码库，几乎不需要更改。

l 除了少数例外，我们的 Web3 API 与以太坊完全兼容。这允许与现有索引器、浏览器等无缝集成。

l 支持以太坊加密语言：zkSync 原生支持keccak256, sha256, 和ecrecovervia 预编译。

l Hardhat 插件：支持在 zkSync 上轻松测试和开发智能合约。

l L1 → L2 智能合约消息传递：允许开发人员将数据从以太坊传递到 zkSync 上的智能合约，提供运行各种智能合约所需的信息。

我们希望在未来的升级中提供的一些功能未包含在我们当前的测试网中，其中包括：

zkPorter：最大和最重要的功能之一，zkPorter 将允许用户在具有最高安全性和比以太坊费用减少 20 倍的 zkRollup 帐户之间进行选择，或者在不同的 zkPorter 帐户中选择稳定的交易费用仅为几美分。安全模型（远高于侧链）。zkPorter 和 zkRollup 账户将能够在后台无缝交互。

#zkSync 比较

zkSync脱颖而出现有 L2 扩展解决方案的安全性和可用性。由于结合了尖端密码学和链上数据可用性，ZK rollups（zkSync 的核心网络）是唯一不需要任何操作活动来保证资金安全的 L2 扩展解决方案。例如，用户可以离线并在回来时仍然能够安全地提取他们的资产，即使 ZK rollup 验证器不再存在。

#zkSync 特性

l ETH 和 ERC20 代币转账在 L1 上具有即时确认和快速终结性。

l ERC20 代币和 ETH 转账的主网成本的交易费用极低。

l 支付给现有的以太坊地址（包括智能合约）可以方便地用正在转移的代币支付。

#zkSync时代的亮点

l 依赖于主网的安全性。

l 无需许可的 EVM 兼容智能合约。

l 标准 Web3 API。

l 保留关键的 EVM 功能，例如智能合约的可组合性。

l 引入新功能，例如帐户抽象。

如果你不熟悉rollups，你应该在学习 zkSync 之前先了解《关于zkSync Era必须要了解的知识第一篇》

#介绍

zkSync是一种ZK rollup，一种使用加密有效性证明在以太坊上提供可扩展和低成本交易的无信任协议。在 zkSync中，计算是在链下执行的，大多数数据也存储在链下。由于所有交易都在以太坊主链上进行证明，因此用户享有与以太坊相同的安全级别。

 zkSync Era看起来和感觉上都像以太坊，但费用更低。就像在以太坊上一样，智能合约是用 Solidity/Vyper 编写的，可以使用与其他 EVM 兼容链相同的客户端来调用。

 使用前无需注册单独的私钥，zkSync开箱即用地支持现有的以太坊钱包。目前，zkSync 仅由 zkSync 团队的服务器运行和操作，因此是中心化的。但是，这将很快过渡到去中心化系统。

#zkSync 概述

一般的rollup工作流程如下：

用户可以相互接收、存入和转移资产。

用户可以将自己控制的资产提供到L1地址。

Rollup操作需要操作员的协力，操作员将交易滚动同步进行，计算正确状态转换的零知识证明，并通过与rollup合约递交转换。要理解设计，我们需要研究zkSync rollup转换是如何工作的。

 zkSync操作分为rollup交易（由rollup账户在rollup内部发起）和优先级操作（由以太坊账户在主链上发起）。

 zkSync rollup操作流程如下：

 l 用户创建交易或优化操作。

l 处理完这个请求后，操作员创建一个集合总操作并将其添加到块中。

l 当区块完成，运营商将其作为区块承诺提供给zkSync智能合约。一些rollup操作的部分分配由智能合约检查。

l 区块证明作为区块验证提供给zkSync智能合约。如果验证成功，则新状态被看到为最终状态。

另外，在zkSync上，每个L2块将通过以下四个阶段进行，直到最终完成。

 Pending：操作员已经收到交易，但尚未处理。

Processed：交易由运营商处理并确认包含在下一个区块中。

Committed：表示该区域块的交易数据已经发布到太坊上。它并不能证明它已经以有效的方式进行操作，但它确实保证了块数据的可用性。

Finalized：表示交易的SNARK具有有效的证明已经表明交易并通过智能结合实验证明。在这一步之后，交易被认为最终完成。

在当前阶段，交易从Processed到的模型时间Finalized是几个小时。

请注意，为了方便开发人员，通常会将状态Processed视图Committed作为一个调整阶段Committed，因为它们与 UX/DexEx 的观点没有区别。

以太坊网络经常拥堵，导致交易缓慢和 gas 价格上涨。虽然这种情况已经持续了很长时间，但仍需要一种改进的解决方案：一种不会限制吞吐量，而是在不牺牲安全性的情况下实现高交易量的解决方案。这就是L2解决方案的亮点所在。

L2解决方案被设计为以太坊的扩展，并提供各种解决方案，有望成为以太坊固有网络拥塞的关键可扩展性组件。涵盖所有L2解决方案超出了本文档的范围。我们将在本文简要介绍rollups。

#什么是rollups？ Rollups 是最近的一项开发，旨在通过链下执行计算、将许多交易汇总到一个批次中，并通过单个操作将其发送到以太坊主链，从而提高以太坊的可扩展性。汇总操作员不是单独提交每笔交易，而是提交所需更改的摘要以代表一批中的所有交易。

为了能够进行rollups，资金需要锁定在第 1 层区块链上的智能合约中。这允许在没有与在主链上执行交易相关的所有数据的开销的情况下处理交易。Rollups 显着减少了相关的交易处理时间和gas费。

#汇总类别 目前，有两种类型的汇总主要用于扩展以太坊。

ZK Rollups（零知识证明）——例如：zkSync、starknet 等 Optimistic Rollups——例如：Optimism、Arbitrum 等 ZK Rollups和Optimistic rollups之间的主要区别在于这批交易成为最终交易的方式。

#什么是 ZK rollups？ 在 ZK rollups（“ZK”代表零知识）中，批量交易在以太坊网络上被验证为正确性。验证通过后，这批交易与任何其他以太坊交易一样被视为最终交易。这是通过加密有效性证明（通常称为零知识证明）的技术实现的。对于任何批次的链下交易，ZK rollups操作员都会为该批次生成有效性证明。一旦生成证明，它就会被提交给以太坊，使汇总批次最终确定。在 zkSync 中，这是通过SNARK-简洁的非交互式知识论证来完成的。

#什么是Optimistic Rollups？ 另一方面，Optimistic Rollups没有机制来证明链下交易的有效性。相反，他们被认为是“乐观的”，因为他们假设链下交易是有效的，除非另有证明。因此，他们依赖于欺诈证明，这是对提交给以太坊的状态的挑战。如果提交了这样的挑战，Optimistic rollup 运营商需要证明所质疑的状态和交易实际上是有效的。这是一个繁琐的过程，需要观察者确保 Optimistic rollup 操作员始终是诚实的。

#L1 和 L2：有什么区别？ L1用于指代底层主链，例如以太坊网络或比特币。L1确定协议规则和交易最终性，并执行基于它们构建的应用程序的基础级功能。

L2用于描述在第 1 层链之上运行的覆盖应用程序或网络。这些通常是为了提供进一步的可扩展性解决方案而构建的，通过承担一部分基于交易的任务来减轻对L1链的影响，加快交易时间并降低gas费。

zkSync 是一个 L2，其中 L1 是主要的以太坊区块链。

别再错过下一个天王级项目zksync

之前很多人错过了arb，很fomo很焦虑，不知道该怎么下手又不想再错过搞钱的机会

那今天手把手喂饭级别教你zksync交互

什么是 zkSync？

zkSync 是第 2 层无信任协议，可在由 zkRollup 技术支持的以太坊上提供可扩展的低成本支付。项目实施零知识技术，保证用户资金的充分安全，同时优化主链的可扩展性、透明性等特性。

zkSync 解决方案对用户和开发人员来说都是令人兴奋的。降低费用的前景、增强加密钱包和服务的用户体验方面以及探索的各种 DeFi 增强功能只是该项目为何如此重要的几个例子。它消除了对第三方的需求，即时确认，高达 99% 的费用减免，并确保可以对现有的以太坊地址和智能合约等进行支付。

zkSync 是如何工作的？

zkSync 是建立在 ZK Rollup 之上的 L2 协议。它使用零知识证明和链上数据可用性来确保资产在 L1 和 L2 之间的无缝转移。要完全理解这一点，您需要知道什么是汇总。

扩展解决方案 zkSync 在费用方面比主要的以太坊区块链（第 1 层）更实惠且速度更快。zkSync 是基于 ZK（零知识）Rollup 架构的 L2 协议。作为一个聚合体，它在以太坊主链 (L1) 之外执行交易，然后将数据放在 L1 上。在第 1 层和第 2 层之间转移资产的过程几乎是无摩擦的。

谁是 zkSync 的幕后推手？

2020 年，总部位于德国的 Matter Labs 创建了一个零知识汇总，以提高以太坊的可扩展性。Matter Labs 于 2019 年开始该项目的工作，直到他们最终在 2020 年发布了 zkSync 的第一个版本，称为 zkSync 1.0，如下所述。

zkSync 1.0：zkSync 的历史始于 2020 年的 zkSync 1.0。这种以太坊扩容技术每秒可处理多达 3,000 笔交易（TPS）。然而，随着网络的扩展，对更高吞吐量的需求导致了一个新版本：zkSync 2 0。

zkSync 2.0：最近，Matter Labs 推出了 zkEVM 测试网，这意味着 zkSync 是第一个执行以太坊原生智能合约的 zk-Rollup。zkSync 2.0 版及其 alpha zkEVM 基础设施比之前的版本 zkSync 1.0 有了更好的改进。

zkSync 使用 zkRollup 技术来保证用户的资金安全。在确保最佳安全性方面，它已被证明是一个很有前途的汇总。

好了大致情况既然了解了，那就话不多说，我们开始zks1.0教程

1、准备工作：

第一步：进入官网：https://zksync.io/

第二步:点击“Wallet Portal”进入钱包，选择以太坊钱包，选择以太坊主网链，连接小狐狸；

第三步：充值一些ETH进去，可以跨链桥，也可以地址转账，到账需要等待一些时间。

二、创建NFT

第一步：Mint NFT,第一次需要授权，授权完需要填写hash或者CID;

第二步：需要创建CID，需要下载ipfs,找到相应的电脑版本，

链接：https://github.com/ipfs/ipfs-desktop

下载完成后，导入并复制CID，粘贴到Mint NFT，然后点击Mint;

显示Mint成功；到这里你就创建了一个专属的NFT；

三、nft跨链回L1，等待验证成功后，开始NFT跨链

点击Withdraw NFT to L1,然后授权转移；

四、Swap，打开zigzag官网，开始交易；

链接钱包，BAY\SELL,换几个交易对，任意买卖，多刷几次交易，一周两次，贵在坚持；

五、跨链桥

点击跨链桥，L1-L2，L2-L1，一周两次，贵在坚持；

那今天这期教程在zks1.0版本所做的空投教程基本上就差不多啦，后续会发布计划zks2.0教程以及其他相关汉化教程

想要继续了解整个zk生态的全貌的话，记得点赞+关注获取更多zk最新前沿资讯。