Skip to main content

Layer 2 op-viem

文档​

https://www.theblockbeats.info/news/35019 https://sdk.optimism.io/ https://www.opviem.sh/ https://github.com/base-org/op-viem

代码​

https://github.com/wilsoncusack/op-stack-bridge-example/blob/main/components/Bridge.tsx

L1->L2 的跨链​

是的，这个跨链操作是从 L1（Layer 1，主链）转移到 L2（Layer 2，二层网络）的过程。在以太坊的背景下，L1 通常指的是以太坊主网，而 L2 指的是建立在以太坊之上的扩容解决方案，如 Optimism、Arbitrum 等。

大致的过程如下：

  1. 用户发起跨链请求：用户从他们的钱包发起一个交易，意图将资产从 L1 桥接到 L2。

  2. 在 L1 进行交易：用户的交易在 L1 上被打包和确认。这通常涉及将资产锁定在一个智能合约中，这个合约充当桥的一部分。

  3. 等待确认：用户需要等待 L1 上的交易被足够数量的区块确认，以确保交易的最终性。

  4. 提交证明到 L2：一旦 L1 上的交易得到确认，相关的证明（如 Merkle 证明）被提交到 L2。这个证明用来验证资产已经在 L1 上被锁定，并请求在 L2 上解锁相应的资产。

  5. 在 L2 处理交易：L2 网络接收到证明后，会在其系统中处理交易。这通常涉及到解锁或铸造等值的资产，允许用户在 L2 上使用它们。

  6. 用户在 L2 接收资产：完成上述步骤后，用户在 L2 上获得了等值的资产，可以开始在 L2 网络上进行交易或其他操作。

在这个过程中，可能还会有一些等待时间，因为从 L1 到 L2 的消息传递可能不是即时的。在某些 L2 解决方案中，可能还需要等待一个挑战期，这是一个安全措施，以确保在处理 L2 交易之前，所有的数据都是正确的。在上面的代码示例中，estimateMessageWaitTimeSeconds函数就是用来估计这个等待时间的。

estimateMessageWaitTimeSeconds 为什么可以估算等待时间​

estimateMessageWaitTimeSeconds 函数能够估算等待时间，是因为它基于特定的跨链桥或者 Layer 2 (L2) 解决方案的机制来计算从 Layer 1 (L1) 到 L2 消息传递所需的大致时间。不同的跨链桥接和 L2 解决方案有不同的确认和传递机制，这些机制通常会涉及以下几个方面：

  1. 块确认时间：L1 和 L2 的区块生成时间可能不同。例如，以太坊主网（L1）的平均区块时间大约是 13-15 秒，而某些 L2 解决方案可能有更快的区块时间。

  2. 批处理和提交周期：一些 L2 解决方案会批量处理交易，并且在固定的时间间隔内将这些交易的状态变化提交回 L1。这个周期可能是几分钟到几小时不等。

  3. 挑战期：许多 L2 解决方案为了确保安全性，会有一个挑战期，在这个期间内，允许用户对提交到 L1 的状态变化进行质疑。只有在没有有效质疑的情况下，这些变化才会被最终确认。

  4. 网络拥塞：网络的拥塞程度也会影响跨链消息的传递时间。如果 L1 或 L2 网络非常拥塞，那么交易的确认可能会被延迟。

  5. 历史数据：有些服务可能会通过分析历史数据来估算等待时间，包括过去的交易确认时间和消息传递延迟。

estimateMessageWaitTimeSeconds 函数通常会考虑上述因素中的一个或多个，以及特定跨链桥或 L2 解决方案的具体实现细节，来提供一个大致的等待时间估计。这个估计可以帮助用户了解他们的资产何时可以在 L2 上可用，但请注意这只是一个估计值，实际的等待时间可能会因实际网络条件或其他因素而有所不同。

L2->L1​

从 Layer 2 (L2) 回到 Layer 1 (L1) 的过程，也称为提款或解桥，通常比从 L1 到 L2 的桥接过程更复杂，因为它涉及到在 L2 上证明某些状态或资产的最终性，并将这些信息传递回 L1。以下是 L2 回到 L1 的一般步骤：

  1. 发起提款请求：用户在 L2 上发起一个提款请求，表示他们想要将资产转回 L1。

  2. 在 L2 上处理交易：L2 网络处理用户的提款请求，这可能涉及到在 L2 上烧毁或锁定相应的资产以防止双重花费。

  3. 生成证明：L2 网络生成一个证明，这个证明表明用户已经在 L2 上成功地完成了提款请求的处理。这个证明取决于 L2 的类型，对于 Rollup 类型的 L2，这通常是一个 Merkle 证明，证明了 L2 状态的有效性。

  4. 提交证明到 L1：一旦生成了证明，它必须被提交到 L1。对于某些 L2 解决方案，如 zk-Rollups，证明可以立即提交，因为它们提供了数学证明以确保数据的有效性。而对于 Optimistic Rollups，通常需要等待一个挑战期，以允许对提交的证明进行挑战。

  5. 等待挑战期：如果 L2 使用的是 Optimistic Rollup，那么在证明被接受之前，通常需要等待一个预定的挑战期（可能是一周左右），以便其他参与者对证明的有效性提出异议。

  6. 在 L1 上执行提款：一旦证明被接受（对于 zk-Rollups，几乎是立即的；对于 Optimistic Rollups，是在挑战期结束后），L1 上的智能合约会根据这些证明来解锁或者创建相应的资产，并将它们发送到用户指定的地址。

  7. 用户接收资产：用户最终在 L1 上接收到他们的资产。

从 L2 回到 L1 的过程通常需要更长的时间，特别是对于 Optimistic Rollups，因为挑战期是为了确保网络的安全性和数据的正确性。这个挑战期是一个安全机制，用于防止无效或欺诈性的状态转换回 L1。相比之下，zk-Rollups 因为提供了密码学证明，所以可以更快地完成资产的回桥过程。

OP viem method​

这些方法看起来像是跨链桥接服务中用于处理从 Layer 1 (L1) 到 Layer 2 (L2) 的资产转移和相反方向的方法。下面是每个方法可能的作用：

L1​

Public Actions

  • getL2HashesForDepositTx: 获取与 L1 存款交易相关的 L2 交易哈希。

  • getOutputForL2Block: 获取特定 L2 区块的数据，这可能与验证 L2 区块的状态或结果有关。

  • getSecondsToFinalizable: 计算直到一个 L1 交易可以被最终确定的剩余秒数。

  • getSecondsToNextL2Output: 计算直到下一个 L2 输出可用的剩余秒数。

  • readFinalizedWithdrawals: 读取已经在 L1 上最终确定的 L2 提现。

  • readProvenWithdrawals: 读取已经在 L1 上被证明的 L2 提现。

  • simulateDepositERC20: 模拟将 ERC20 代币从 L1 存入 L2 的交易。

  • simulateDepositETH: 模拟将 ETH 从 L1 存入 L2 的交易。

  • simulateDepositTransaction: 模拟一个通用的存款交易。

  • simulateFinalizeWithdrawalTransaction: 模拟最终确定 L2 提现到 L1 的交易。

  • simulateProveWithdrawalTransaction: 模拟证明 L2 提现到 L1 的交易。

L2​

Public Actions

  • estimateFees: 估算跨链交易的费用。

  • estimateL1Fee: 估算在 L1 上执行操作所需的费用。

  • estimateL1GasUsed: 估算在 L1 上执行交易所需的 gas 用量。

  • getProveWithdrawalTransactionArgs: 获取证明 L2 提现到 L1 交易所需的参数。

  • getWithdrawalMessages: 获取 L2 提现的信息。

  • simulateWithdrawERC20: 模拟从 L2 提现 ERC20 代币到 L1 的交易。

  • simulateWithdrawETH: 模拟从 L2 提现 ETH 到 L1 的交易。

Wallet Actions​

L1

  • writeContractDeposit: 向智能合约发送存款。

  • writeDepositERC20: 发起一个 ERC20 代币从 L1 存入 L2 的交易。

  • writeDepositETH: 发起一个 ETH 从 L1 存入 L2 的交易。

  • writeFinalizeWithdrawalTransaction: 发起最终确定 L2 提现到 L1 的交易。

  • writeOpStackL1: 在 L1 上执行与操作栈相关的写操作。

  • writeProveWithdrawalTransaction: 发起证明 L2 提现到 L1 的交易。

  • writeSendMessage: 发送从 L1 到 L2 的消息。

  • writeDepositTransaction: 发起一个通用的存款交易。

L2

  • writeOpStackL2: 在 L2 上执行与操作栈相关的写操作。

  • writeWithdrawETH: 发起一个 ETH 从 L2 提现到 L1 的交易。

  • writeWithdrawERC20: 发起一个 ERC20 代币从 L2 提现到 L1 的交易。

这些方法的具体实现和功能可能会根据所使用的桥接服务和 SDK 的具体版本有所不同。通常，这些方法会被分为两类：一类是用于读取信息和模拟交易的“Public Actions”，另一类是用于实际发送交易和与智能合约交互的“Wallet Actions”。在实际使用中，开发者应该参考具体桥接服务的文档来了解每个方法的详细行为和用途。

write ，这个如何理解​

在以太坊和许多其他区块链平台上，智能合约交互通常分为两类：read操作和write操作。这些操作对应于智能合约中的不同类型的函数调用。

  • Read 操作：这些操作不会改变区块链的状态，因此它们不需要进行挖矿或支付燃料费。Read 操作用于查询智能合约的状态，例如获取账户的余额、读取合约中的某个值等。这些操作通常是免费的，因为它们不需要在区块链上广播任何交易。

  • Write 操作：这些操作会改变区块链的状态。任何改变状态的操作都需要通过网络进行广播，并由矿工进行确认和打包到区块中。因此，write 操作需要支付燃料费（Gas Fee），以激励矿工将这些交易包含在区块中。Write 操作包括转账、调用修改状态的智能合约函数等。

在你提供的方法列表中，所有以write开头的方法都属于 write 操作，它们会在区块链上发起一个可能改变状态的交易。具体到这些方法：

  • writeContractDeposit：可能是一个方法，用于在合约中存入资金。
  • writeDepositERC20：用于存入 ERC20 代币到某个合约或地址。
  • writeDepositETH：用于存入以太币（ETH）到某个合约或地址。
  • writeFinalizeWithdrawalTransaction：用于在 L1 上最终确定一个从 L2 发起的提现操作。
  • writeOpStackL1：这个方法的具体作用可能需要查看相关的文档，但它似乎涉及在 L1 上的某种操作。
  • writeProveWithdrawalTransaction：用于在 L1 上提交证明提现操作的有效性的交易。
  • writeSendMessage：用于发送消息，可能是跨链消息或合约间的通信。
  • writeDepositTransaction：这可能是一个通用的存款方法，用于存入资金或代币。

每个方法的确切功能和使用方式应该在相应的 API 文档或智能合约文档中有详细描述。在实际编写和执行这些操作之前，应该仔细阅读并理解每个方法的工作原理、所需参数、可能的副作用以及费用。

OP Viem client config​

// import modules
import { createWalletClient, createPublicClient, custom, http } from 'viem'
import { privateKeyToAccount } from 'viem/accounts'
import { mainnet, base } from 'viem/chains'
import { baseAddresses } from 'op-viem/chains'
import { walletL1OpStackActions, publicL1OpStackActions, publicL2OpStackActions } from 'op-viem'

// create clients
export const opStackL1WalletClient = createWalletClient({
  chain: mainnet,
  transport: custom(window.ethereum)
}).extend(walletL1OpStackActions)

export const opStackL1PublicClient = createPublicClient({
  chain: mainnet,
  transport: http()
}).extend(publicL1OpStackActions)

export const opStackL2PublicClient = createPublicClient({
  chain: base,
  transport: http()
}).extend(publicL2OpStackActions)

// perform an action
opStackL1PublicClient.getOutputForL2Block(blockNumber: 2725977n, ...baseAddresses)

这段代码看起来是用于与一个名为 "Viem" 的区块链服务进行交互的 JavaScript 代码。代码中使用了几个模块和函数，目的是为了创建不同类型的客户端，以便与区块链进行交互，并执行特定的操作。以下是代码的详细解释：

  1. 导入模块：代码首先导入了所需的模块，这些模块提供了创建区块链客户端和执行特定区块链操作的功能。

  2. 创建客户端：代码创建了三个不同的客户端，每个客户端都有不同的用途：

    • opStackL1WalletClient：这是一个钱包客户端，用于在 Layer 1（主网）上执行需要钱包权限的操作，例如发送交易。它通过用户的浏览器钱包（如 MetaMask）与区块链进行交互。
    • opStackL1PublicClient：这是一个公共客户端，用于在 Layer 1 上执行不需要用户钱包权限的查询操作，如获取区块信息。它通过 HTTP 传输与区块链进行交互。
    • opStackL2PublicClient：这是另一个公共客户端，用于在 Layer 2 上执行查询操作。与 Layer 1 的公共客户端类似，它也通过 HTTP 传输与区块链进行交互。

  3. 扩展客户端：每个客户端都通过 .extend() 方法扩展了特定的操作集。这些操作集可能是为了与特定的 Layer 1 或 Layer 2 解决方案（如 Optimism）进行交互而定义的。

  4. 执行操作：最后一行代码尝试执行一个操作，即通过 opStackL1PublicClient 客户端获取 Layer 2 区块的输出。getOutputForL2Block 函数需要一个区块号（在这个例子中是 2725977n）和一些基础地址（...baseAddresses）作为参数。

创建三个不同的客户端的原因是为了分离不同类型的操作和权限。钱包客户端需要用户的私钥或浏览器钱包进行交易，而公共客户端则用于那些不需要私钥的查询操作。此外，由于 Layer 1 和 Layer 2 可能有不同的接口和操作，因此为它们分别创建客户端可以简化与每一层的交互。

请注意，这段代码是示例性质的，并且 "Viem"、"op-viem" 和相关函数可能是特定于某个区块链项目或库的，而不是普遍存在的 JavaScript 库。因此，要完全理解这段代码的含义，你可能需要查看相关项目的文档或源代码。

OP Viem Deposit​

import { baseGoerliAddresses } from 'op-viem/chains';
import { account, l1PublicClient, l1WalletClient, l2PublicClient } from './config';

const depositTxHash = await l1WalletClient.writeDepositETH({
  args: {
    to: account.address,
    // in this case sending to an EOA, better to use estimateGas
    minGasLimit: 21000,
  },
  value: 1n,
  ...baseGoerliAddresses,
});

const txReceipt = await l1PublicClient.waitForTransactionReceipt({
  hash: depositTxHash,
});

const l2Hashes = await l1PublicClient.getL2HashesForDepositTx({
  l1TxReceipt: txReceipt,
});

// wait for tx to land on L2

const l2TxReceipt = await l2PublicClient.waitForTransactionReceipt({
  hash: l2Hashes[0],
});

这段代码是一个用于在 Layer 1（L1）链上执行存款操作，然后将资金转移到 Layer 2（L2）链上的示例。它使用了op-viem库，这是一个专门用于与 Optimism 网络（一个 Layer 2 扩展方案）进行交互的 TypeScript 扩展。以下是代码的步骤解释：

  1. 导入地址和配置：首先，代码从op-viem/chains模块导入baseGoerliAddresses，这可能包含了与 Goerli 测试网络相关的地址。然后，从./config文件导入了配置好的账户和客户端。

  2. 执行存款操作：通过l1WalletClient的writeDepositETH方法，代码执行一个存款操作。这个操作将以太币（ETH）从 L1 存入到 L2。该函数接受以下参数：

    • args.to：指定接收资金的地址，这里是account.address。
    • args.minGasLimit：设置交易的最小燃料限制，这里是21000，这是标准的以太坊交易所需的最小燃料量。
    • value：指定要存入的金额，这里是1n，表示 1 个以太币（ETH）。
    • ...baseGoerliAddresses：扩展操作符...用于传递 Goerli 测试网络的相关地址。

  3. 等待交易收据：使用l1PublicClient的waitForTransactionReceipt方法等待 L1 交易的确认，并获取交易收据。

  4. 获取 L2 交易哈希：通过l1PublicClient的getL2HashesForDepositTx方法，使用 L1 交易收据来获取与该存款操作相关的 L2 交易哈希。

  5. 等待 L2 交易确认：最后，使用l2PublicClient的waitForTransactionReceipt方法等待 L2 上相关交易的确认，并获取交易收据。

整个流程展示了如何使用op-viem库中的客户端和方法来执行一个跨层次（从 L1 到 L2）的存款操作。这通常是在使用 Layer 2 解决方案时，用户将资金从以太坊主网（Layer 1）转移到 Layer 2 网络（如 Optimism）的过程。这样做可以利用 Layer 2 的优势，比如更低的交易费用和更快的确认时间。

OP Viem Withdrawal​

import { baseGoerliAddresses } from 'op-viem/chains';
import { account, l1PublicClient, l1WalletClient, l2PublicClient, l2WalletClient } from './config';

const withdrawTxHash = await l2WalletClient.writeWithdrawETH({
  args: {
    to: account.address,
    amount: 1n,
    // in this case sending to an EOA, better to use estimateGas
    minGasLimit: 21000,
  },
});

const withdrawalReceipt = await l2PublicClient.waitForTransactionReceipt({
  hash: withdrawTxHash,
});

const withdrawalMessages = await l2PublicClient.getWithdrawalMessages({
  txReceipt: withdrawalReceipt,
});
const output = await l1PublicClient.getOutputForL2Block({
  l2BlockNumber: withdrawalMessages.blockNumber,
  ...baseGoerliAddresses,
});

const l2BlockNumber = await l2PublicClient.getBlockNumber();
const secondsToProve = await l1PublicClient.getSecondsToNextL2Output({
  ...baseGoerliAddresses,
  latestL2BlockNumber: l2BlockNumber,
});

// wait secondsToProve 🤣这里应该有个计时器啥的sleep
// https://github.com/wilsoncusack/op-stack-bridge-example/blob/main/components/Bridge.tsx
// 这个demo代码使用了定时器来不停的获取，直到获取到了confirm时候清理掉 timerIntervalId

const proveWithdrawalArgs = await l2PublicClient.getProveWithdrawalTransactionArgs({
  output,
  message: withdrawalMessages.messages[0],
});

const proveWithdrawalTxHash = await l1WalletClient.writeProveWithdrawalTransaction({
  args: proveWithdrawalArgs,
  ...baseGoerliAddresses,
});

await l1PublicClient.waitForTransactionReceipt({ hash: proveWithdrawalTxHash });

const provenWithdrawal = await l1PublicClient.readProvenWithdrawals({
  ...baseGoerliAddresses,
  withdrawalHash: withdrawalMessages.messages[0].withdrawalHash,
});
console.log('provenWithdrawal', provenWithdrawal);

const secondsToFinalize = await l1PublicClient.getSecondsToFinalizable({
  ...baseGoerliAddresses,
  withdrawalHash: withdrawalMessages.messages[0].withdrawalHash,
});

// wait secondToFinalize 🤣这里应该有个计时器啥的sleep

const { withdrawalHash, ...withdrawal } = withdrawalMessages.messages[0];
const finalizeTxHash = await l1WalletClient.writeFinalizeWithdrawalTransaction({
  portal: baseGoerliAddresses.portal,
  args: { withdrawal },
  account,
});
console.log('finalizeTxHash', finalizeTxHash);

当然可以，以下是从 L2 到 L1 提现的核心步骤，用更具体的描述来说明每一步：

  1. L2 上用户发起提现交易：用户使用l2WalletClient的writeWithdrawETH方法在 L2 上发起一笔提现以太币（ETH）的操作，指定接收地址为用户自己的地址account.address，提现金额为1n（即 1 个 ETH），并设置了最小燃料限制minGasLimit。

  2. 等待 L2 提现交易确认：用户通过l2PublicClient的waitForTransactionReceipt方法等待 L2 上提现交易被确认，并获取交易收据。

  3. 获取 L2 提现消息：用户利用l2PublicClient的getWithdrawalMessages方法，使用 L2 交易收据来获取提现相关的消息。

  4. 获取 L2 区块输出信息：用户使用l1PublicClient的getOutputForL2Block方法，获取 L2 区块的输出信息，这是为了在 L1 上证明提现操作的必要步骤。

  5. 计算 L1 上证明提现所需时间：用户调用l1PublicClient的getSecondsToNextL2Output方法，计算在 L1 上证明提现之前需要等待的时间。

  6. 等待证明提现时间：用户根据上一步计算出的时间等待相应的秒数，以确保 L2 区块输出已经可以在 L1 上进行证明。

  7. 获取证明提现所需参数：用户使用l2PublicClient的getProveWithdrawalTransactionArgs方法来获取证明提现所需的参数。

  8. 在 L1 上提交证明提现交易：用户使用l1WalletClient的writeProveWithdrawalTransaction方法，将提现证明提交到 L1 链上。

  9. 等待 L1 证明提现交易确认：用户使用l1PublicClient的waitForTransactionReceipt方法等待证明提现交易在 L1 上的确认。

  10. 读取已证明的提现信息：用户通过l1PublicClient的readProvenWithdrawals方法来检查提现是否已经在 L1 上被证明。

  11. 计算提现最终化所需时间：用户使用l1PublicClient的getSecondsToFinalizable方法来计算提现在 L1 上最终化前需要等待的时间。

  12. 等待提现最终化时间：用户根据上一步计算出的时间等待相应的秒数，以确保提现可以在 L1 上最终化。

  13. 在 L1 上提交最终化提现交易：用户使用l1WalletClient的writeFinalizeWithdrawalTransaction方法，提交最终化提现交易到 L1 链上。

  14. 输出最终化提现交易哈希：用户打印出最终化提现交易的哈希值，用于追踪和确认交易状态。

这个流程确保了用户能够安全地将资金从 L2 提现回 L1，尽管这个过程相较于简单的链内交易要复杂和耗时，但它是为了保障跨链资金操作的安全性和正确性。

Withdrawal ERC20 代币​

如果不止是 ETH 呢，其他 erc20 代币如果处理 对于 ERC20 代币的提现，处理流程与 ETH 的提现类似，但会有一些关键的差异。在使用 Layer 2 解决方案如 Optimism 时，你通常需要使用特定的方法来处理 ERC20 代币，因为它们需要与对应的智能合约进行交互。以下是处理 ERC20 代币提现的一般步骤：

  1. 批准代币：在 L2 上，首先需要批准 Layer 2 网络的代币桥接合约来转移你想要提现的 ERC20 代币数量。这通常通过调用 ERC20 代币合约的approve方法完成。

  2. 发起提现：在批准转移代币之后，你需要调用 Layer 2 网络的代币桥接合约的提现方法来发起提现流程。这个方法会与 ETH 的提现方法有所不同，通常是类似withdrawToken或者initiateWithdrawal之类的方法。

  3. 等待挑战期：与 ETH 提现类似，ERC20 代币提现也有一个挑战期，在这期间提现可以被证明是有效的或者是无效的。你需要等待这个挑战期结束。

  4. 证明提现：在挑战期结束后，你需要在 L1 上证明提现。这涉及到发送一个证明交易到 Layer 1 网络，这个交易会包括 L2 提现交易的数据。

  5. 最终确定提现：在证明提现之后，你需要等待 Layer 1 网络上的一个特定时间窗口，之后你可以发送一个交易来最终确定提现。这通常通过调用 Layer 1 上的桥接合约的方法来完成。

  6. 接收代币：一旦提现最终确定，你的 ERC20 代币将被转移到你在 L1 上指定的地址。

请注意，具体的方法名称和参数可能会根据不同的 Layer 2 解决方案和桥接合约而有所变化。因此，你应该查看你所使用的 Layer 2 平台的官方文档，以获取准确的方法名称和步骤。此外，交互过程中可能需要指定 ERC20 代币的合约地址以及其他相关的参数。

在实际编写代码之前，强烈建议查阅 Layer 2 解决方案的官方文档和 API，因为它们会提供必要的信息和示例，以确保你能够正确地与智能合约和桥接合约进行交互。

L1 与 L2 如何通信​

L1 发起交易​

L1 交易确认后能够获取到 L2 交易哈希，是因为 L2 解决方案通常会监听 L1 上的特定事件，并据此在 L2 生成相应的操作。在大多数 L2 解决方案中，尤其是那些使用 rollup 技术的，L1 作为数据和安全性的锚点，而 L2 则提供更高的吞吐量和更低的交易费用。

这里是一个更详细的解释，说明为什么一个 L1 交易确认后可以获取到一个 L2 交易哈希：

  1. 事件触发：当在 L1 上发起一笔交易（如存款到 L2）时，这笔交易会触发一个事件或产生一些日志，这些信息会被记录在区块链上。

  2. L2 监听：L2 节点或验证者会监听这些特定的 L1 事件。一旦 L1 交易被确认并且事件被记录在区块链上，L2 节点会检测到这个事件。

  3. 生成 L2 交易：L2 节点根据 L1 事件的细节（例如，存款金额和目标地址）在 L2 上生成一笔对应的交易。这笔 L2 交易将处理用户的存款请求。

  4. 关联哈希：由于 L2 节点是根据 L1 上的特定交易生成 L2 交易的，它们之间就存在了直接的关系。L2 节点可以将 L1 交易的详细信息与生成的 L2 交易哈希相关联，并公开这个信息，使得用户或其他服务可以查询。

  5. 查询哈希：用户或前端应用程序可以通过查询 L1 交易的详情来获取关联的 L2 交易哈希。这通常是通过与 L1 智能合约交互完成的，合约会记录下每笔 L1 到 L2 的映射。

  6. 跨层通信：这种跨层通信机制确保了 L1 和 L2 之间的数据一致性和同步。L1 交易的确认成为了触发 L2 处理的信号，并且提供了一个可追踪的路径，从而用户可以验证他们的资金在 L2 上已经被正确处理。

因此，尽管 L1 和 L2 是不同的系统，但通过设计好的跨层通信协议和事件监听机制，它们之间可以建立起直接的联系。这种设计是为了确保用户在 L1 上的操作能够无缝映射到 L2 上，并且能够被追踪和验证。

L2 发起交易​

当在 L2 发起交易时，L1 不会自动知晓，因为 L2 通常运行在一个独立的环境中，它的状态更新不会直接反映到 L1 上。然而，为了保持 L1 和 L2 之间的一致性和安全性，L2 解决方案通常会定期将状态更新或交易批次提交回 L1。这个过程被称为“提交证明”（submitting proofs）或“数据提交”（data submission），它确保了 L1 上有 L2 状态的记录。以下是这个过程的一些关键步骤：

  1. 批次处理：L2 上的交易通常会被聚合成批次。这些批次包含了多个 L2 交易的数据和执行结果。

  2. 生成证明：对于某些 L2 解决方案，如 zk-Rollups，会为每个批次生成一个有效性证明（validity proof），证明这些交易是正确执行的，没有违反任何规则。对于 Optimistic Rollups，不需要立即生成这样的证明，而是假定所有交易都是有效的，除非有人提出异议。

  3. 提交到 L1：证明或批次数据会被提交到 L1 上的一个特定智能合约。这个智能合约负责接收和存储这些信息，并可能触发一些事件来通知网络中的其他参与者。

  4. 验证和最终确定性：对于 zk-Rollups，一旦有效性证明被提交到 L1 合约，L1 上的任何人都可以验证这个证明并确认 L2 批次的正确性。对于 Optimistic Rollups，提交后有一个挑战期（challenge period），在这段时间内，如果有人认为批次中的交易是无效的，他们可以提交一个欺诈证明（fraud proof）来挑战。

  5. L1 合约的作用：L1 智能合约起到了桥接的作用，它确保了 L2 的状态变化能够被记录和验证。这允许 L1 上的其他合约或服务根据需要查询这些信息。

  6. 事件和监听：L1 合约通常会触发事件来通知 L1 上的监听者 L2 的状态更新。这些事件可以被前端应用程序、监控服务或其他智能合约捕获，以响应 L2 的变化。

总之，L1 不会自动知晓 L2 上的每个单独交易，但通过 L2 向 L1 提交状态更新和/或证明的机制，L1 可以被间接地通知到 L2 的状态变化，并且可以验证这些变化的正确性。这种机制是 L2 解决方案的基础，它确保了跨层操作的安全性和可靠性。

L2 发起的交易，最后在 L1 上提现，L1 如何知道 L2 要提现多少？​

在 Layer 2（L2）到 Layer 1（L1）的提现过程中，L1 是如何知道 L2 要提现多少金额的问题，涉及到了跨链通信和数据验证的机制。这个过程通常是通过一系列的消息传递和验证来实现的。下面是简化的解释：

  1. 发起提现：当用户在 L2 上发起提现请求时，他们会指定提现的金额和目标地址。这个请求被打包进一个 L2 区块中，并生成一个特定的提现事务。

  2. 生成提现消息：L2 节点会处理这个提现事务，并生成一个包含所有必要信息的提现消息。这个消息包括提现的金额、目标地址、提现事务的哈希等信息。

  3. 提交到 L1：L2 会定期将一批事务的数据和状态更新提交到 L1。这些提交被称为“rollup blocks”或“state roots”，它们包含了 L2 区块的累积状态和相关的事务数据。提现消息也会在这些数据中。

  4. 等待挑战期：为了安全性，通常会有一个挑战期，在这段时间内，网络参与者可以对 L2 提交的数据进行挑战，以防止欺诈或错误。

  5. 验证提现消息：在 L1 上，有一个智能合约（通常是桥接合约或验证者合约）负责处理从 L2 来的消息。一旦 L2 到 L1 的数据提交被认为是最终的（经过了挑战期且没有被挑战），L1 上的合约会解析这些数据并找到提现消息。

  6. 证明提现：在某些情况下，用户可能需要在 L1 上提交一个证明，这个证明通过加密方法（如 Merkle proofs）证明提现消息确实是在 L2 上生成的。这个证明与 L2 提交的状态根或事务数据一起验证，确保了提现的合法性。

  7. 执行提现：一旦提现消息被验证为有效，L1 上的智能合约会执行提现操作，将指定的金额发送到用户在提现请求中指定的地址。

整个过程中，L1 是通过验证 L2 提交的数据和提现消息来知道 L2 要提现多少金额的。这个验证过程确保了只有在 L2 上有效发起的提现请求才能在 L1 上被执行。