1. 基础概念 (General Concepts)#

• Q: L1 与 L2 的区别是什么？

  • A:

    • L1 (Layer 1): 是底层区块链（如 Ethereum, Bitcoin），负责最终的安全性、共识和结算。它的吞吐量（TPS）有限，Gas 费较高。

    • L2 (Layer 2): 是建立在 L1 之上的扩展解决方案（如 Arbitrum, Optimism）。它在链下执行交易，将多笔交易**打包（Rollup）**压缩后，仅将状态根（State Root）和必要数据提交回 L1。

    • 核心: L2 继承了 L1 的安全性，但通过分担计算任务解决了扩展性问题。

• Q: 请解释工作量证明 (PoW) 与权益证明 (PoS)。

  • A:

    • PoW (Proof of Work): 依靠算力（哈希碰撞）竞争记账权。优点是极其去中心化且安全（需 51% 算力攻击）；缺点是能源消耗大，TPS 低。

    • PoS (Proof of Stake): 依靠质押代币的数量和时间竞争记账权。优点是节能、更快的最终性（Finality）；缺点是可能导致富者恒富（中心化风险）。以太坊在 “The Merge” 后转为了 PoS。

• Q: 什么是 Merkle Tree？作用是什么？

  • A:

    • 它是一种哈希二叉树。叶子节点是数据块的哈希，非叶子节点是子节点哈希的哈希。

    • 作用: 1. 数据完整性验证: 只要根哈希（Merkle Root）不变，整棵树的数据就未被篡改。2. 轻量级验证 (SPV): 轻节点不需要下载完整区块，只需通过 Merkle Proof（默克尔路径）即可验证某笔交易是否存在于区块中。

• Q: 私钥、公钥和地址是如何生成的？

  • A: 单向流程：私钥 -> 公钥 -> 地址。

    1. 私钥: 一个随机生成的 256 位整数。

    2. 公钥: 通过椭圆曲线算法 (ECDSA - secp256k1) 从私钥推导出来。

    3. 地址: 对公钥进行 Keccak-256 哈希，取最后 20 个字节（40个十六进制字符），并在前面加上 0x。

    • 注：无法反向推导。

• Q: 硬分叉与软分叉的区别？

  • A:

    • 硬分叉: 放宽了规则或改变了核心协议，旧节点无法验证新块。全网必须升级，否则会分裂成两条链（如 ETH 和 ETC）。

    • 软分叉: 收紧了规则，旧节点仍能验证新块（因为新块满足旧规则，只是更严格）。属于向前兼容。

2. 智能合约开发 (Solidity)#

• Q: view 和 pure 的区别？

  • A:

    • view: 可以读取状态变量（State Variables），但不能修改。

    • pure: 既不读取也不修改状态变量。通常用于纯数学计算。

    • 费用: 外部（链下）调用它们是免费的；但在合约内部（链上）调用时，依然会消耗 Gas。

• Q: delegatecall 和 call 的区别？(重点)

  • A:

    • call: 也就是常规调用。A 调用 B，代码在 B 的上下文中执行，修改的是 B 的存储，msg.sender 变为 A。

    • delegatecall: 委托调用。A delegatecall B，代码是 B 的，但在 A 的上下文中执行，修改的是 A 的存储，msg.sender 依然是原始调用者。

    • 场景: 它是实现可升级合约（Proxy Pattern）的核心。

• Q: Gas 优化技巧？

  • A:

    1. 存储优化: 避免频繁读写 Storage（最贵）。尽量使用 memory 或 calldata。

    2. 变量打包 (Variable Packing): 将多个小变量（如 uint64, uint128）放在一起，使其凑满一个 256 位的 Slot。

    3. 其他: 循环中避免修改状态变量；使用 unchecked 进行无需溢出检查的数学运算。

• Q: 重入攻击 (Reentrancy) 及防御？

  • A:

    • 原理: 攻击者合约在接收以太币的回调函数（fallback）中，再次调用受害者合约的提款函数，此时受害者合约还没来得及更新余额，导致资金被反复提取。

    • 防御:

      1. 检查-生效-交互 (Checks-Effects-Interactions): 先扣除余额（修改状态），再发送以太币（外部交互）。

      2. 互斥锁: 使用 OpenZeppelin 的 ReentrancyGuard (nonReentrant 修饰符)。

• Q: 如何实现合约可升级？

  • A: 使用 代理模式 (Proxy Pattern)。

    • 用户访问 Proxy 合约（负责存储数据）。

    • Proxy 将调用 delegatecall 给 Logic 合约（负责业务逻辑）。

    • 升级时，只需要将 Proxy 指向新的 Logic 合约地址，数据依然保留在 Proxy 中。

3. 前端与 DApp 交互#

• Q: 如何检测钱包连接/断开？

  • A: 使用 window.ethereum API。

    • 监听 accountsChanged 事件：当用户切换账户或断开连接时触发。

    • 监听 chainChanged 事件：当用户切换网络时触发（通常建议此时刷新页面）。

• Q: 签名 (Sign) vs 交易 (Transaction)？

  • A:

    • 签名: 纯链下行为，用私钥对数据加密，不广播到区块链，不消耗 Gas。常用于登录验证（Sign-in with Ethereum）或授权（Permit）。

    • 交易: 将数据广播到 P2P 网络，打包进区块，改变链上状态，消耗 Gas。

• Q: RPC 节点挂了怎么办？

  • A: * 前端应配置 RPC Provider 列表。

    • 实现轮询或回退机制 (Fallback)：如果主节点（如 Infura）超时或报错，自动切换到备用节点（如 Alchemy 或 QuickNode）。

• Q: 处理“最终性” (Finality)？

  • A: 前端不能仅凭“交易发出”就显示成功。

    • 需轮询 getTransactionReceipt。

    • UI 状态流: Pending (转圈) -> Included (进入区块，虽然成功但可能回滚) -> Safe/Finalized (达到一定确认数，如 12 个块，或者 L2 的 Batch 提交)。

4. 后端与基础设施 (DevOps / Backend)#

• Q: 如何索引数据 (The Graph vs 自建)？

  • A:

    • 问题: 链上数据是为写优化的，无法做 SELECT * FROM transfers WHERE user = X 这种查询。

    • The Graph: 去中心化索引协议，编写 subgraph.yaml 定义监听规则，虽然方便但有延迟且依赖第三方。

    • 自建索引 (Go/Rust): 通过 RPC 扫描区块 (eth_getBlock), 解析 Logs，存入传统的 SQL/NoSQL 数据库。适合对实时性和复杂查询要求高的企业级应用。

• Q: 以太坊 Events/Logs 机制？

  • A:

    • 智能合约 emit 事件后，数据存入区块头的 ReceiptsRoot 里的 Bloom Filter（布隆过滤器）。

    • Topics: 最多 3 个参数可以被 indexed（索引），这部分进入 Topics 数组，可以被快速检索。

    • Data: 未索引的参数经过 ABI 编码存入 Data 字段，无法直接检索，需解码查看。

• Q: MEV (最大可提取价值) 与 Flashbots？

  • A:

    • MEV: 矿工/验证者通过重新排序、插入或审查区块中的交易来获利（例如抢跑用户的买单）。

    • Flashbots: 一个私有的交易提交通道。套利机器人将交易直接发给矿工（附带贿赂费），而不经过公开内存池（Mempool），避免被其他机器人监测和抢跑。

5. Web3 安全与进阶#

• Q: 闪电贷 (Flash Loan) 原理？

  • A:

    • 在一个 Transaction（原子交易）内完成：借款 -> 使用资金 -> 还款 (+利息)。

    • 如果在交易结束时没有还款，EVM 会回滚整个交易，就像什么都没发生过一样。这使得无抵押巨额借贷成为可能。

• Q: ERC-20, 721, 1155 区别？

  • A:

    • ERC-20: 同质化代币（如 USDT），每个币都是一样的。

    • ERC-721: 非同质化代币（NFT），每个代币有唯一的 tokenId。

    • ERC-1155: 多重代币标准。可以在一个合约里同时包含同质化和非同质化代币，且支持批量转账（Batch Transfer），极大地节省 Gas。

• Q: 链上随机数为何难？

  • A:

    • 区块链是确定性的系统。如果用区块哈希或时间戳做种子，矿工可以预知或操纵这些值来作弊。

    • 解法: 使用 Chainlink VRF (Verifiable Random Function)。预言机在链下生成随机数和证明，链上合约验证证明的合法性，确保随机数未被篡改。

• Q: 零知识证明 (ZKP) 的原理与应用？

  • A:

    • 原理: 证明者 (Prover) 向验证者 (Verifier) 证明自己知道某个秘密（如私钥），但不需要向验证者透露这个秘密本身。

    • Web3 应用:

      1. 隐私: Tornado Cash（证明我有存款凭证，但不暴露是哪一笔存款）。

      2. 扩容 (ZK-Rollup): 在 L2 运行大量计算，生成一个极小的有效性证明（Validity Proof）提交给 L1，L1 只要验证这个证明即可，无需重跑计算。

建议： 如果你需要针对某个具体的题目进行代码层面的演示（比如写一个简单的 Reentrancy 攻击合约），请随时告诉我！