feat: 添加Web3与区块链方向面试题
- Web3基础知识：区块链、共识机制、智能合约、预言机等 - DeFi协议与AMM：Uniswap、借贷协议、流动性挖矿、闪电贷 - 智能合约安全：重入攻击、整数溢出、访问控制、前置交易 - 高并发应用：Layer2扩容、Rollup、侧链、状态通道 - Golang开发：Geth、Cosmos SDK、P2P网络、共识算法 - Layer2扩容：Optimistic Rollup、ZK-Rollup、跨链桥 - 跨链技术：HTLC、原子交换、跨链桥安全 - 简历项目迁移：Web2经验到Web3的转化路径 针对性结合候选人简历： - 字节跳动大促活动 → Web3营销活动 - 生活服务营销表达 → DeFi收益聚合器 - 低代码平台 → Web3开发平台 - 预算管理 → DAO治理 - 策略增长 → DeFi激励机制
This commit is contained in:
931
questions/14-Web3与区块链/Layer2扩容方案.md
Normal file
931
questions/14-Web3与区块链/Layer2扩容方案.md
Normal file
@@ -0,0 +1,931 @@
|
||||
# Layer 2扩容方案
|
||||
|
||||
## 问题
|
||||
|
||||
1. 什么是Layer 1和Layer 2？为什么需要Layer 2？
|
||||
2. Layer 2扩容方案有哪些分类？
|
||||
3. Optimistic Rollup的工作原理是什么？
|
||||
4. ZK-Rollup的工作原理是什么？
|
||||
5. Optimism和Arbitrum有什么区别？
|
||||
6. zkSync和StarkNet有什么区别？
|
||||
7. 什么是状态通道？
|
||||
8. 什么是侧链？Polygon如何工作？
|
||||
9. 如何选择合适的Layer 2方案？
|
||||
10. Layer 2的未来发展趋势是什么？
|
||||
|
||||
---
|
||||
|
||||
## 标准答案
|
||||
|
||||
### 1. Layer 1 vs Layer 2
|
||||
|
||||
#### **对比表**
|
||||
|
||||
| 特性 | Layer 1（主网） | Layer 2（二层） |
|
||||
|------|---------------|----------------|
|
||||
| **定义** | 主区块链（如Ethereum） | 建立在L1之上的扩容方案 |
|
||||
| **安全性** | 独立安全性 | 继承L1安全性 |
|
||||
| **TPS** | 15-30 | 2000-20000+ |
|
||||
| **Gas费** | 高（$10-100） | 低（$0.01-1） |
|
||||
| **确认时间** | 12秒-数分钟 | 秒级 |
|
||||
| **独立性** | 完全独立 | 依赖L1 |
|
||||
| **代表** | Ethereum、Bitcoin | Arbitrum、zkSync |
|
||||
|
||||
---
|
||||
|
||||
#### **为什么需要Layer 2？**
|
||||
|
||||
```
|
||||
Ethereum的三难困境（Trilemma）：
|
||||
|
||||
去中心化
|
||||
↑
|
||||
|
|
||||
| ● (无法同时达到)
|
||||
|
|
||||
安全 --- 可扩展性
|
||||
|
||||
实际：
|
||||
- L1: 高安全性 + 去中心化，但低可扩展性
|
||||
- L2: 继承L1安全性，大幅提升可扩展性
|
||||
|
||||
需求：
|
||||
- DeFi爆发（2020年）
|
||||
- NFT热潮（2021年）
|
||||
- Gas费飙升（$100+ / 笔）
|
||||
- TPS瓶颈（15 TPS）
|
||||
|
||||
解决方案：
|
||||
- L1优化（EIP-4844等）→ 2-3倍提升
|
||||
- L2扩容（Rollup等）→ 100-1000倍提升
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. Layer 2扩容方案分类
|
||||
|
||||
```
|
||||
Layer 2扩容方案
|
||||
│
|
||||
├─── Rollup（主流）
|
||||
│ ├─ Optimistic Rollup
|
||||
│ │ ├─ Arbitrum
|
||||
│ │ ├─ Optimism
|
||||
│ │ └─ Base
|
||||
│ │
|
||||
│ └─ ZK-Rollup
|
||||
│ ├─ zkSync Era
|
||||
│ ├─ StarkNet
|
||||
│ ├─ Polygon zkEVM
|
||||
│ └─ Loopring
|
||||
│
|
||||
├─── 状态通道
|
||||
│ ├─ Lightning Network（Bitcoin）
|
||||
│ ├─ Raiden Network（Ethereum）
|
||||
│ └─ State Channels
|
||||
│
|
||||
└── 侧链
|
||||
├─ Polygon PoS
|
||||
├─ Gnosis Chain
|
||||
└─ Moonbeam
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### **技术对比**
|
||||
|
||||
| 方案 | TPS | Gas费 | 确认时间 | 通用EVM | 安全模型 |
|
||||
|------|-----|------|---------|---------|---------|
|
||||
| **Optimistic Rollup** | 2000-4000 | $0.1-1 | 7天 | ✅ | 欺诈证明 |
|
||||
| **ZK-Rollup** | 20000+ | $0.01-0.1 | 数小时 | 部分 | 零知识证明 |
|
||||
| **状态通道** | 无限 | $0 | 即时 | ❌ | 保证金锁定 |
|
||||
| **侧链** | 7000+ | $0.01 | 2秒 | ✅ | 独立验证者 |
|
||||
|
||||
---
|
||||
|
||||
### 3. Optimistic Rollup原理
|
||||
|
||||
#### **核心思想**
|
||||
|
||||
```
|
||||
假设交易有效，给予挑战期进行验证
|
||||
|
||||
流程：
|
||||
1. 用户在L2发起交易
|
||||
2. Sequencer收集交易
|
||||
3. Sequencer执行交易，计算新状态
|
||||
4. Sequencer将交易发布到L1（Calldata）
|
||||
5. 挑战期（7天）：任何人可以挑战
|
||||
6. 如果挑战成功，Sequencer被惩罚
|
||||
7. 如果无挑战，交易最终确认
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### **架构图**
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ Layer 1 (Ethereum) │
|
||||
│ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ Rollup合约 │ │ 挑战合约 │ │
|
||||
│ │ │ │ │ │
|
||||
│ │ - 存储状态根 │ │ - 验证证明 │ │
|
||||
│ │ - 验证批次 │ │ - 惩罚作恶 │ │
|
||||
│ └──────────────┘ └──────────────┘ │
|
||||
└─────────────────────────────────────────┘
|
||||
↑ 发布批次 ↑ 提交挑战
|
||||
│ │
|
||||
┌─────────────────────────────────────────┐
|
||||
│ Layer 2 (Arbitrum) │
|
||||
│ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ Sequencer │ │ 验证者 │ │
|
||||
│ │ │ │ │ │
|
||||
│ │ - 收集交易 │ │ - 监控L2 │ │
|
||||
│ │ - 执行交易 │ │ - 提交挑战 │ │
|
||||
│ │ - 发布批次 │ │ │ │
|
||||
│ └──────────────┘ └──────────────┘ │
|
||||
│ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ 用户A │ │ 用户B │ │
|
||||
│ │ 发送交易 ────┼────→│ 发送交易 │ │
|
||||
│ └──────────────┘ └──────────────┘ │
|
||||
└─────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### **代码实现（简化版）**
|
||||
|
||||
```solidity
|
||||
// SPDX-License-Identifier: MIT
|
||||
pragma solidity ^0.8.0;
|
||||
|
||||
contract OptimisticRollup {
|
||||
struct Batch {
|
||||
bytes32 stateRoot; // 状态根
|
||||
bytes32 transactionRoot; // 交易根
|
||||
uint256 timestamp; // 提交时间
|
||||
bool challenged; // 是否被挑战
|
||||
}
|
||||
|
||||
Batch[] public batches;
|
||||
uint256 public challengePeriod = 7 days;
|
||||
|
||||
// Sequencer提交批次
|
||||
function submitBatch(
|
||||
bytes32 stateRoot,
|
||||
bytes32 transactionRoot,
|
||||
bytes calldata transactions
|
||||
) public {
|
||||
batches.push(Batch({
|
||||
stateRoot: stateRoot,
|
||||
transactionRoot: transactionRoot,
|
||||
timestamp: block.timestamp,
|
||||
challenged: false
|
||||
}));
|
||||
|
||||
emit BatchSubmitted(batches.length - 1, stateRoot);
|
||||
}
|
||||
|
||||
// 验证者挑战
|
||||
function challengeBatch(
|
||||
uint256 batchIndex,
|
||||
bytes calldata fraudProof
|
||||
) public {
|
||||
Batch storage batch = batches[batchIndex];
|
||||
|
||||
require(!batch.challenged, "Already challenged");
|
||||
require(
|
||||
block.timestamp < batch.timestamp + challengePeriod,
|
||||
"Challenge period expired"
|
||||
);
|
||||
|
||||
// 验证欺诈证明
|
||||
if (verifyFraudProof(fraudProof)) {
|
||||
batch.challenged = true;
|
||||
|
||||
// 惩罚Sequencer
|
||||
slashSequencer();
|
||||
|
||||
emit BatchChallenged(batchIndex);
|
||||
}
|
||||
}
|
||||
|
||||
function verifyFraudProof(bytes calldata proof) internal pure returns (bool) {
|
||||
// 验证证明的有效性
|
||||
// 实际实现会更复杂
|
||||
return true;
|
||||
}
|
||||
|
||||
function slashSequencer() internal {
|
||||
// 没收Sequencer的质押
|
||||
}
|
||||
|
||||
// 7天后，如果无挑战，最终确认
|
||||
function finalizeBatch(uint256 batchIndex) public {
|
||||
Batch storage batch = batches[batchIndex];
|
||||
|
||||
require(
|
||||
block.timestamp >= batch.timestamp + challengePeriod,
|
||||
"Challenge period not ended"
|
||||
);
|
||||
require(!batch.challenged, "Batch was challenged");
|
||||
|
||||
// 更新L2状态
|
||||
updateState(batch.stateRoot);
|
||||
|
||||
emit BatchFinalized(batchIndex);
|
||||
}
|
||||
|
||||
function updateState(bytes32 stateRoot) internal {
|
||||
// 更新L2状态根
|
||||
}
|
||||
|
||||
event BatchSubmitted(uint256 indexed batchIndex, bytes32 stateRoot);
|
||||
event BatchChallenged(uint256 indexed batchIndex);
|
||||
event BatchFinalized(uint256 indexed batchIndex);
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### **提款流程**
|
||||
|
||||
```
|
||||
用户提款流程：
|
||||
|
||||
1. 用户在L2发起提款
|
||||
- 调用L2 Bridge合约
|
||||
- 销毁L2资产
|
||||
|
||||
2. 等待挑战期（7天）
|
||||
- 提交证明到L1
|
||||
- 7天挑战期
|
||||
|
||||
3. 在L1最终确认
|
||||
- 调用L1 Bridge合约
|
||||
- 验证通过后，发送L1资产给用户
|
||||
|
||||
总时间：7天
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 4. ZK-Rollup原理
|
||||
|
||||
#### **核心思想**
|
||||
|
||||
```
|
||||
使用零知识证明验证交易的正确性
|
||||
|
||||
流程：
|
||||
1. Prover在链下执行交易
|
||||
2. Prover生成零知识证明（SNARK/STARK）
|
||||
3. Prover将证明发布到L1
|
||||
4. L1验证证明（数学确定性）
|
||||
5. 如果证明有效，立即确认
|
||||
|
||||
关键优势：
|
||||
- 无需挑战期（数学证明）
|
||||
- 更高的隐私性
|
||||
- 更高的安全性
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### **零知识证明**
|
||||
|
||||
```
|
||||
零知识证明：我可以证明我知道秘密，但不透露秘密本身
|
||||
|
||||
示例：
|
||||
- 我知道私钥，但不告诉你
|
||||
- 我可以生成证明，证明我知道私钥
|
||||
- 你可以验证证明，确认我知道私钥
|
||||
- 但你仍然不知道私钥
|
||||
|
||||
在ZK-Rollup中的应用：
|
||||
- Prover执行交易
|
||||
- Prover生成证明："这批交易是有效的"
|
||||
- L1验证证明
|
||||
- L1无需重新执行交易，只需验证证明
|
||||
|
||||
优势：
|
||||
- 验证速度快（几毫秒）
|
||||
- 证明大小小（几百字节）
|
||||
- 数学保证，无法伪造
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### **ZK-SNARK vs ZK-STARK**
|
||||
|
||||
| 特性 | ZK-SNARK | ZK-STARK |
|
||||
|------|----------|----------|
|
||||
| **全称** | Zero-Knowledge Succinct Non-Interactive Argument of Knowledge | Zero-Knowledge Scalable Transparent Arguments of Knowledge |
|
||||
| **可信设置** | 需要 | 不需要 |
|
||||
| **证明大小** | 小（几百字节） | 大（几十KB） |
|
||||
| **验证速度** | 快（几毫秒） | 快（几毫秒） |
|
||||
| **抗量子** | 否 | 是 |
|
||||
| **代表** | zkSync、Loopring | StarkNet |
|
||||
|
||||
---
|
||||
|
||||
#### **代码实现（简化版）**
|
||||
|
||||
```solidity
|
||||
// SPDX-License-Identifier: MIT
|
||||
pragma solidity ^0.8.0;
|
||||
|
||||
contract ZKRollup {
|
||||
struct Batch {
|
||||
bytes32 stateRoot; // 状态根
|
||||
bytes32 commitment; // 承诺
|
||||
bytes proof; // 零知识证明
|
||||
bool verified; // 是否已验证
|
||||
}
|
||||
|
||||
Batch[] public batches;
|
||||
Verifier public verifier; // 验证合约
|
||||
|
||||
constructor(address _verifier) {
|
||||
verifier = Verifier(_verifier);
|
||||
}
|
||||
|
||||
// Prover提交批次
|
||||
function submitBatch(
|
||||
bytes32 stateRoot,
|
||||
bytes32 commitment,
|
||||
bytes calldata proof,
|
||||
bytes calldata publicInputs
|
||||
) public {
|
||||
// 验证零知识证明
|
||||
require(
|
||||
verifier.verifyProof(proof, publicInputs),
|
||||
"Invalid proof"
|
||||
);
|
||||
|
||||
// 证明有效，立即确认
|
||||
batches.push(Batch({
|
||||
stateRoot: stateRoot,
|
||||
commitment: commitment,
|
||||
proof: proof,
|
||||
verified: true
|
||||
}));
|
||||
|
||||
// 立即更新L2状态
|
||||
updateState(stateRoot);
|
||||
|
||||
emit BatchSubmitted(batches.length - 1, stateRoot);
|
||||
}
|
||||
|
||||
function updateState(bytes32 stateRoot) internal {
|
||||
// 更新L2状态根
|
||||
}
|
||||
|
||||
event BatchSubmitted(uint256 indexed batchIndex, bytes32 stateRoot);
|
||||
}
|
||||
|
||||
// 验证者合约（简化版）
|
||||
contract Verifier {
|
||||
// 实际使用Groth16或Plonk等验证算法
|
||||
function verifyProof(
|
||||
bytes calldata proof,
|
||||
bytes calldata publicInputs
|
||||
) public pure returns (bool) {
|
||||
// 验证零知识证明
|
||||
// 实际实现会调用预编译合约
|
||||
|
||||
// 简化版：总是返回true
|
||||
return true;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### **提款流程**
|
||||
|
||||
```
|
||||
用户提款流程：
|
||||
|
||||
1. 用户在L2发起提款
|
||||
- 调用L2 Bridge合约
|
||||
- 销毁L2资产
|
||||
|
||||
2. Prover生成证明
|
||||
- Prover执行提款交易
|
||||
- 生成提款证明
|
||||
|
||||
3. 在L1最终确认
|
||||
- 提交证明到L1
|
||||
- L1验证证明（几毫秒）
|
||||
- 立即发送L1资产给用户
|
||||
|
||||
总时间：几分钟到几小时
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5. Optimism vs Arbitrum
|
||||
|
||||
#### **对比表**
|
||||
|
||||
| 特性 | Optimism | Arbitrum |
|
||||
|------|----------|----------|
|
||||
| **推出时间** | 2021年1月 | 2021年8月 |
|
||||
| **挑战机制** | 单轮交互 | 多轮交互 |
|
||||
| **EVM兼容性** | 完全兼容 | 完全兼容 |
|
||||
| **语言** | Solidity | Solidity, any language |
|
||||
| **Gas费** | 稍高 | 稍低 |
|
||||
| **提款时间** | 7天 | 7天 |
|
||||
| **TVL** | $5亿+ | $10亿+ |
|
||||
| **生态项目** | 200+ | 300+ |
|
||||
|
||||
---
|
||||
|
||||
#### **技术差异**
|
||||
|
||||
**Optimism**：
|
||||
```
|
||||
- 单轮欺诈证明
|
||||
- 快速模式：2周后上线
|
||||
- Bedrock升级：降低Gas费，提升性能
|
||||
- 使用OVM（Optimistic Virtual Machine）
|
||||
```
|
||||
|
||||
**Arbitrum**：
|
||||
```
|
||||
- 多轮欺诈证明（二分查找）
|
||||
- AnyTrust: 数据可用性优化
|
||||
- Stylus: 支持Rust/C++编写智能合约
|
||||
- 使用ArbOS（Arbitrum Operating System）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 6. zkSync vs StarkNet
|
||||
|
||||
#### **对比表**
|
||||
|
||||
| 特性 | zkSync Era | StarkNet |
|
||||
|------|------------|----------|
|
||||
| **推出时间** | 2023年3月 | 2022年11月 |
|
||||
| **EVM兼容性** | 完全兼容（zkEVM） | 不完全兼容 |
|
||||
| **语言** | Solidity | Cairo |
|
||||
| **证明系统** | ZK-SNARK | ZK-STARK |
|
||||
| **账户模型** | AA兼容 | AA原生 |
|
||||
| **提款时间** | 几小时 | 几小时 |
|
||||
| **TVL** | $6亿+ | $1亿+ |
|
||||
|
||||
---
|
||||
|
||||
#### **技术差异**
|
||||
|
||||
**zkSync Era**：
|
||||
```
|
||||
- zkEVM：完全兼容EVM
|
||||
- 支持Solidity、Vyper
|
||||
- 账户抽象（AA）
|
||||
- 代币支付Gas费
|
||||
```
|
||||
|
||||
**StarkNet**：
|
||||
```
|
||||
- Cairo: 原生语言（类似Rust）
|
||||
- ZK-STARK: 抗量子
|
||||
- 账户抽象原生支持
|
||||
- StarkEx: 自定义Rollup
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 7. 状态通道
|
||||
|
||||
#### **原理**
|
||||
|
||||
```
|
||||
参与者在链下进行多笔交易，只在开启和关闭通道时与链交互
|
||||
|
||||
示例：支付通道
|
||||
|
||||
1. 开启通道
|
||||
Alice和Bob各存入1 ETH到智能合约
|
||||
状态：{Alice: 1 ETH, Bob: 1 ETH}
|
||||
|
||||
2. 链下交易
|
||||
Alice转0.5 ETH给Bob
|
||||
双方签名新状态：{Alice: 0.5 ETH, Bob: 1.5 ETH}
|
||||
不发布到链上
|
||||
|
||||
3. 重复链下交易
|
||||
可以进行无限次链下交易
|
||||
|
||||
4. 关闭通道
|
||||
提交最终状态到链上
|
||||
智能合约分配资金
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### **代码实现**
|
||||
|
||||
```solidity
|
||||
// SPDX-License-Identifier: MIT
|
||||
pragma solidity ^0.8.0;
|
||||
|
||||
contract PaymentChannel {
|
||||
struct Channel {
|
||||
address participant1;
|
||||
address participant2;
|
||||
uint256 balance1;
|
||||
uint256 balance2;
|
||||
uint256 nonce;
|
||||
bool closed;
|
||||
}
|
||||
|
||||
mapping(bytes32 => Channel) public channels;
|
||||
|
||||
function openChannel(address participant2) public payable {
|
||||
bytes32 channelId = keccak256(abi.encodePacked(msg.sender, participant2));
|
||||
|
||||
channels[channelId] = Channel({
|
||||
participant1: msg.sender,
|
||||
participant2: participant2,
|
||||
balance1: msg.value,
|
||||
balance2: 0,
|
||||
nonce: 0,
|
||||
closed: false
|
||||
});
|
||||
|
||||
emit ChannelOpened(channelId, msg.sender, participant2);
|
||||
}
|
||||
|
||||
function closeChannel(
|
||||
bytes32 channelId,
|
||||
uint256 balance1,
|
||||
uint256 balance2,
|
||||
uint256 nonce,
|
||||
bytes memory signature1,
|
||||
bytes memory signature2
|
||||
) public {
|
||||
Channel storage channel = channels[channelId];
|
||||
|
||||
require(!channel.closed, "Channel already closed");
|
||||
require(nonce > channel.nonce, "Invalid nonce");
|
||||
|
||||
// 验证签名
|
||||
require(
|
||||
verifySignature(channel.participant1, balance1, balance2, nonce, signature1),
|
||||
"Invalid signature1"
|
||||
);
|
||||
require(
|
||||
verifySignature(channel.participant2, balance1, balance2, nonce, signature2),
|
||||
"Invalid signature2"
|
||||
);
|
||||
|
||||
channel.closed = true;
|
||||
channel.balance1 = balance1;
|
||||
channel.balance2 = balance2;
|
||||
|
||||
// 分配资金
|
||||
payable(channel.participant1).transfer(balance1);
|
||||
payable(channel.participant2).transfer(balance2);
|
||||
|
||||
emit ChannelClosed(channelId, balance1, balance2);
|
||||
}
|
||||
|
||||
function verifySignature(
|
||||
address signer,
|
||||
uint256 balance1,
|
||||
uint256 balance2,
|
||||
uint256 nonce,
|
||||
bytes memory signature
|
||||
) internal pure returns (bool) {
|
||||
// 验证签名
|
||||
bytes32 messageHash = keccak256(abi.encodePacked(balance1, balance2, nonce));
|
||||
bytes32 ethSignedHash = keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", messageHash));
|
||||
|
||||
address recovered = recoverSigner(ethSignedHash, signature);
|
||||
return recovered == signer;
|
||||
}
|
||||
|
||||
function recoverSigner(bytes32 hash, bytes memory signature) internal pure returns (address) {
|
||||
// 恢复签名者地址
|
||||
// 实际实现使用ecrecover
|
||||
return address(0);
|
||||
}
|
||||
|
||||
event ChannelOpened(bytes32 indexed channelId, address participant1, address participant2);
|
||||
event ChannelClosed(bytes32 indexed channelId, uint256 balance1, uint256 balance2);
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 8. 侧链（Polygon）
|
||||
|
||||
#### **原理**
|
||||
|
||||
侧链是独立的区块链，有自己的共识机制，通过双向桥与主网连接。
|
||||
|
||||
```
|
||||
┌─────────────┐
|
||||
│ Ethereum │ 主网（L1）
|
||||
│ (L1) │
|
||||
└──────┬──────┘
|
||||
│ 桥接
|
||||
↓
|
||||
┌─────────────┐
|
||||
│ Polygon │ 侧链（L2）
|
||||
│ PoS │ 独立共识
|
||||
└─────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### **Polygon PoS架构**
|
||||
|
||||
```
|
||||
1. Heimdall层（验证层）
|
||||
- 检查点机制
|
||||
- 验证者集合
|
||||
- 惩罚机制
|
||||
|
||||
2. Bor层（执行层）
|
||||
- 兼容EVM
|
||||
- 生成区块
|
||||
- 执行交易
|
||||
|
||||
3. 桥接
|
||||
- 锁定L1资产
|
||||
- 在L2铸造等量资产
|
||||
- 反向：销毁L2资产，解锁L1资产
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### **代码实现**
|
||||
|
||||
```solidity
|
||||
// L1桥接合约
|
||||
contract L1Bridge {
|
||||
mapping(address => uint256) public lockedBalances;
|
||||
|
||||
event Locked(address indexed user, uint256 amount);
|
||||
event Unlocked(address indexed user, uint256 amount);
|
||||
|
||||
function lock() public payable {
|
||||
lockedBalances[msg.sender] += msg.value;
|
||||
emit Locked(msg.sender, msg.value);
|
||||
|
||||
// 触发L2 Mint
|
||||
// L2Bridge.mint(msg.sender, msg.value);
|
||||
}
|
||||
|
||||
function unlock(address user, uint256 amount) public {
|
||||
require(lockedBalances[user] >= amount, "Insufficient locked");
|
||||
lockedBalances[user] -= amount;
|
||||
|
||||
payable(user).transfer(amount);
|
||||
emit Unlocked(user, amount);
|
||||
}
|
||||
}
|
||||
|
||||
// L2桥接合约
|
||||
contract L2Bridge {
|
||||
mapping(address => uint256) public balances;
|
||||
|
||||
event Minted(address indexed user, uint256 amount);
|
||||
event Burned(address indexed user, uint256 amount);
|
||||
|
||||
function mint(address to, uint256 amount) public {
|
||||
require(msg.sender == bridge, "Only bridge");
|
||||
balances[to] += amount;
|
||||
emit Minted(to, amount);
|
||||
}
|
||||
|
||||
function burn(uint256 amount) public {
|
||||
require(balances[msg.sender] >= amount, "Insufficient balance");
|
||||
balances[msg.sender] -= amount;
|
||||
emit Burned(msg.sender, amount);
|
||||
|
||||
// 触发L1 Unlock
|
||||
// L1Bridge.unlock(msg.sender, amount);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 9. 如何选择Layer 2方案？
|
||||
|
||||
#### **决策树**
|
||||
|
||||
```
|
||||
1. 需要EVM兼容？
|
||||
├─ 是 → Optimistic Rollup（Arbitrum、Optimism）
|
||||
└─ 否 → ZK-Rollup（StarkNet）
|
||||
|
||||
2. 需要快速提款？
|
||||
├─ 是 → ZK-Rollup（几小时）
|
||||
└─ 否 → Optimistic Rollup（7天）
|
||||
|
||||
3. 需要极低Gas费？
|
||||
├─ 是 → ZK-Rollup（$0.01-0.1）
|
||||
└─ 否 → Optimistic Rollup（$0.1-1）
|
||||
|
||||
4. 需要完全兼容EVM？
|
||||
├─ 是 → Arbitrum、zkSync Era
|
||||
└─ 否 → StarkNet（需要学习Cairo）
|
||||
|
||||
5. 需要高吞吐？
|
||||
├─ 是 → ZK-Rollup（20000+ TPS）
|
||||
└─ 否 → Optimistic Rollup（2000-4000 TPS）
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### **场景推荐**
|
||||
|
||||
```
|
||||
场景1：DeFi协议
|
||||
推荐：Arbitrum
|
||||
理由：
|
||||
- 完全兼容EVM
|
||||
- 生态成熟
|
||||
- Gas费适中
|
||||
- TVL高
|
||||
|
||||
场景2：支付
|
||||
推荐：zkSync Era
|
||||
理由：
|
||||
- 极低Gas费
|
||||
- 账户抽象
|
||||
- 快速确认
|
||||
|
||||
场景3：游戏
|
||||
推荐：Polygon
|
||||
理由：
|
||||
- 高TPS
|
||||
- 低延迟
|
||||
- 成熟生态
|
||||
|
||||
场景4：NFT市场
|
||||
推荐：Optimism
|
||||
理由：
|
||||
- 完全兼容EVM
|
||||
- 生态丰富
|
||||
- 用户友好
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 10. Layer 2未来趋势
|
||||
|
||||
#### **技术发展**
|
||||
|
||||
```
|
||||
1. EIP-4844（Proto-Danksharding）
|
||||
- 降低Rollup数据存储成本
|
||||
- 提升L2吞吐量10-100倍
|
||||
- 2023年已上线
|
||||
|
||||
2. 完整Danksharding
|
||||
- 进一步降低成本
|
||||
- 2024-2025年上线
|
||||
|
||||
3. ZK-EVM成熟
|
||||
- zkSync Era、Polygon zkEVM
|
||||
- 完全兼容EVM
|
||||
- 零知识证明
|
||||
|
||||
4. 跨链互操作
|
||||
- LayerZero
|
||||
- CCIP（Chainlink）
|
||||
- 无缝跨链体验
|
||||
|
||||
5. 账户抽象（ERC-4337）
|
||||
- L2原生支持
|
||||
- 社交恢复
|
||||
- 批量交易
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### **生态发展**
|
||||
|
||||
```
|
||||
1. L2 War
|
||||
- Arbitrum vs Optimism
|
||||
- zkSync vs StarkNet
|
||||
- 竞争加速创新
|
||||
|
||||
2. 跨链桥安全
|
||||
- Wormhole、Ronin被黑后
|
||||
- 更安全的桥设计
|
||||
- 多签验证
|
||||
|
||||
3. 监管合规
|
||||
- MiCA（欧盟）
|
||||
- 美国监管
|
||||
- 合规化发展
|
||||
|
||||
4. 用户体验
|
||||
- 账户抽象
|
||||
- Gasless交易
|
||||
- 社交登录
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 结合简历的面试题
|
||||
|
||||
### 1. 大促系统 vs L2扩容
|
||||
|
||||
**面试官会问**：
|
||||
> "你做过双11大促系统，L2扩容和传统扩容有什么异同？"
|
||||
|
||||
**参考回答**：
|
||||
```
|
||||
传统扩容（Web2）：
|
||||
- 水平扩展：增加服务器
|
||||
- 垂直扩展：升级硬件
|
||||
- 分库分表：数据分片
|
||||
- CDN加速：静态资源
|
||||
|
||||
L2扩容（Web3）：
|
||||
- 链下计算：L2执行交易
|
||||
- 链上验证：L1验证证明
|
||||
- 批量处理：打包多个交易
|
||||
- 数据压缩：降低存储成本
|
||||
|
||||
共同点：
|
||||
- 提升吞吐量
|
||||
- 降低成本
|
||||
- 保持安全性
|
||||
|
||||
差异：
|
||||
- Web2：中心化扩展
|
||||
- Web3：去中心化扩展
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. 容灾设计 vs L2安全
|
||||
|
||||
**面试官会问**：
|
||||
> "你做过双机房容灾，L2如何保证安全性？"
|
||||
|
||||
**参考回答**：
|
||||
```
|
||||
双机房容灾（Web2）：
|
||||
- 主备机房
|
||||
- 数据同步
|
||||
- 自动切换
|
||||
|
||||
L2安全（Web3）：
|
||||
- 继承L1安全性（Rollup）
|
||||
- 数学证明（ZK-Rollup）
|
||||
- 欺诈证明（Optimistic Rollup）
|
||||
- 质押机制（验证者质押）
|
||||
|
||||
对比：
|
||||
- Web2：人工介入切换
|
||||
- Web3：自动验证，无需人工
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Layer 2面试加分项
|
||||
|
||||
### 1. 实战经验
|
||||
|
||||
- 在L2部署过合约
|
||||
- 熟悉跨链桥使用
|
||||
- 有L2 Gas优化经验
|
||||
- 了解L2生态项目
|
||||
|
||||
### 2. 技术深度
|
||||
|
||||
- 理解Rollup原理
|
||||
- 了解零知识证明
|
||||
- 理解欺诈证明
|
||||
- 了解EIP-4844
|
||||
|
||||
### 3. 架构能力
|
||||
|
||||
- 能选择合适的L2方案
|
||||
- 能设计跨链架构
|
||||
- 能优化Gas消耗
|
||||
- 能设计L2 DApp
|
||||
|
||||
### 4. 行业理解
|
||||
|
||||
- 了解L2生态发展
|
||||
- 了解L2 TVL排名
|
||||
- 了解跨链桥安全
|
||||
- 了解未来趋势
|
||||
Reference in New Issue
Block a user