zkSync 2.0 进展-202301

2023-04-04 本文已影响0人雪落无留痕

zkSync 2.0目前主网上线仍是Baby Alpha 版本，代码尚未开源。将在 Fair Onboarding Alpha版本开源代码，预计在2023年第2季度。

基本概念

交易

zkSync 2.0 网络上的交易结构如下：

/// @notice Structure used to represent zkSync transaction. 
struct Transaction {
    // The type of the transaction.
    uint256 txType;   
    // The caller.
    uint256 from;
    // The callee.
    uint256 to;
    // The ergsLimit to pass with the transaction. 
    // It has the same meaning as Ethereum's gasLimit.
    uint256 ergsLimit;
    // The maximum amount of ergs the user is willing to pay for a byte of pubdata.
    uint256 ergsPerPubdataByteLimit;
    // The maximum fee per erg that the user is willing to pay. 
    // It is akin to EIP1559's maxFeePerGas.
    uint256 maxFeePerErg;
    // The maximum priority fee per erg that the user is willing to pay. 
    // It is akin to EIP1559's maxPriorityFeePerGas.
    uint256 maxPriorityFeePerErg;
    // The transaction's paymaster. If there is no paymaster, it is equal to 0.
    uint256 paymaster;
    // In the future, we might want to add some
    // new fields to the struct. The `txData` struct
    // is to be passed to account and any changes to its structure
    // would mean a breaking change to these accounts. In order to prevent this,
    // we should keep some fields as "reserved".
    // It is also recommneded that their length is fixed, since
    // it would allow easier proof integration (in case we will need
    // some special circuit for preprocessing transactions).
    uint256[6] reserved;
    // The transaction's calldata.
    bytes data;
    // The signature of the transaction.
    bytes signature;
    // The properly formatted hashes of bytecodes that must be published on L1
    // with the inclusion of this transaction. Note, that a bytecode has been published
    // before, the user won't pay fees for its republishing.
    bytes32[] factoryDeps;
    // The input to the paymaster.
    bytes paymasterInput;
    // Reserved dynamic type for the future use-case. Using it should be avoided,
    // But it is still here, just in case we want to enable some additional functionality.
    bytes reservedDynamic;
}

支持三种交易类型：传统交易类型，EIP1559, EIP712.
ergsLimit: 类似于以太坊交易中的gasLimit;
ergsPerPubdataByteLimit: 用户对每个Pubdata 字节愿意支持的最大 ergs.
maxFeePerErg: 类似于EIP1559中的maxFeePerGas.
maxPriorityFeePerErg: 类似于EIP1559中的maxPriorityFeePerGas.
payMaster: 用于支持采用ERC20支持交易手续费, 或者也可以支持由合约为用户支付手续费；
factoryDeps: 用于部署合约的字节码的hash.
paymasterInput: payMaster的输入

Operators: 负责产块，打包交易，向以太坊上提交验证的数据。

区块

L2的区块在提交到L1时，是将多个连续的块合并成一个Batch一块提交，以包含尽可能多的交易以降低交易手续费， l1BatchNumber 用于表示这个Batch 编号。

L2区块的Hash 计算方式为：keccak256(l2_block_number)，因为L2区块Hash对L1来说无意义。

系统合约

为了保证零知识证明电路尽可能简单，zkSync 实现一些系统合约，用以实现一些专用的目的，如部署合约等。目前只提供了接口，具体实现尚未开源。

ContractDeployer

主要利用create/create2部署新的合约，并生成新的合约地址，执行完还会发出 ContractDeployed 事件。

L1Messenger

用于从zkSync 向 Ethereum 发送信息，并发出L1MessageSent 事件。

NonceHolder

主要用来存放账nonces, 包含tx nonce 和 deployment nonce.

Bootloader

Bootloader 主要用来实现扩展，降低负载，方便实现account abstract 功能。

L1 合约

Diamond

主要用来管理Diamond 的存储：

    struct DiamondStorage {
        mapping(bytes4 => SelectorToFacet) selectorToFacet;
        mapping(address => FacetToSelectors) facetToSelectors;
        address[] facets;
        bool isFrozen;
    }

DiamondProxy

L1合约实现主要采用 EIP-2535 Diamond 代理方式，通过fallback 代理具体实现合约的调用。

DiamondInit

用于初始化Diamond 代理合约。

DiamondCutFacet

主要用来升级Diamond facets ，主要以下阶段：

proposeDiamondCut: 由gover 发起一个升级；
approveEmergencyDiamondCutAsSecurityCouncilMember: 安全委员会成员同意升级；
executeDiamondCutProposal: 完成升级过程。

GettersFacet

主要提升view和pure 方法；

GovernanceFacet

主要用来管理governor, validators 和一些系统参数；

MailboxFacet

主要用来处理L2<--->L1之间的通信过程，主要关注信息的传递，不涉及资产（ETH, ERC20, NFT）的转移。

对于 L1->L2 通信，主要是从L1发起在L2上的交易，用户从L1发起交易，添加到队列中，由validator执行，并在L1上进行标记，相关的函数有：

requestL2Transaction
l2TransactionBaseCost
serializeL2Transaction

对于每个L1->L2执行的交易，系统会发起 L2->L1的log.

对于L2->L1通信，主要通过调用Messenger 系统合约传递信息，而不是在L1上执行交易。

function sendToL1(bytes memory _message) external returns (bytes32 messageHash);

在L2上，有个zkEVM 字节码为l2ToL1Log，当将L2区块提交到L1上时，validator 会提交l2ToL1Logs.

ExecutorFacet

用于接收L2 区块，保证数据可用性，并检查零知识证明，主要分为以下三个阶段：

commitBlocks: 检查L2区块时间戳，处理L2日志，保存区块的数据；
proveBlocks: 用以验证零知识证明；
executeBlocks: 用于固化状态，标记L1->L2通信过程, 处理L2 日志。

Account abstraction

以太坊只有EOA账户能发起交易，对于智能合约钱包或Tornado cash 等隐私协议，只能通过relayers 发起交易，会导致诸多不便。

zkSync 2.0的账户能够以合约方式实现任意的逻辑，也能像EOA一起发起交易，这种功能即为·Account abstract.

抽象账户需要实现IAccount 接口，如下：

validateTransaction: 主要实现验证有效性验证的逻辑；
executeTransaction: 主要执行交易；
payForTransacton：可选的方法，在交易没有 paymaster 的情况下，用以支付交易的手续费；
prePaymaster: 可选的方法，在交易有paymaster的情况下，通过paymaster支付交易手续续；
executeTransactionFromOutside: 主要用于L2抗审查，即operator 无响应，可通过优先级模式发起交易。

Paymaster 接口

抽象账户支持paymasters, 主要用来支持其它账户交易的执行。paymaster 主要实现IPaymaster接口：

validateAndPayForPaymasterTransaction: 主要用来验证paymaster是否同意为对应的交易支付手续费；
postOp: 在交易执行后调用，主要用于交易手续的refund.

Transaction 保留的字段

reserved[0]: nonce;
reserved[1]: msg.value

Transaction flow

在交易的验证过程，账户会决定是否接收交易，并支付手续费；若交易验证失败，账户不会支付手续费，交易也不会打包进块中。

Step 1: 系统检查交易的nonce尚未被使用；
Step 2: 系统调用账户的validateTransaction 方法；
Step 3: 系统检查交易的nonce已经被标记使用；
Step 4: 若没有paymaster, 系统调用账户的payForTransaction方法支付手续费；
Step 4: 若指定paymaster, 系统调用发送者prePaymaster方法，然后调用paymaster 的validateAndPayForPaymasterTransaction方法；
Step 5: 系统验证 bootloader 接收了tx.ergsPrice * tx.ergsLimit 的ETH.

在执行过程中，主要是执行交易，并对未使用的ergs进行退款。若没有发生revert，则交易将会打包进块中。

Step 6: 系统调用账户的executeTransaction 方法；
Step 7: 对于存在paymaster的情况下，调用paymaster 的postOp方法，用于给发送者退回未使用的ergs。

采用 SystemContractCaller 库

为了提升安全，NonceHolder和ContractDeployer 合约只能通过 isSystem 的标签调用，需要采用SystemContractsCaller 库的方法：

systemCall
systemCallWithPropagatedRevert
systemCallWithReturndata

跨链桥

桥由两个合约实现，一个部署在L1上，一个部署在L2上。

Deposits (to L2)

用户调用L1 桥合约的deposit 方法，向L2 发起存款操作：

用户的L1 代币发送到L1 桥合约上，并被锁定；
L1桥合约发起一个向L2桥合约的交易；
在L2的交易中，将会mint相应的代币并发送到指定的地址上。
- 若相应的代币在zkSync尚未存在，将自动部署新的合约，合约地址是确定的（根据原始的L1合约地址，名称和符号）。
对于每个执行的L1-> L2交易，会有一个L2->L1日志用以确认执行。
最后调用finalizeDeposit 方法，完成存款操作。

对交易执行过程中失败，会有日志记录失败，用户可通过日志从L1桥发起退款：claimFailedDeposit。

Withdraws (to L1)

用户需要调用L2 桥合约的withdraw 方法，执行以下过程：