? EIP-4844：Proto-Danksharding与以太坊的可扩展性飞跃

ankitacode11 发布于 2025-06-19 阅读 2041

EIP-4844 (又名 Proto-Danksharding) 通过引入 blob 携带交易来降低 Layer2 Rollup 的数据成本。Blob 是临时的链下数据块，存储在以太坊共识层上约 18 天。它将L2的交易费用降低了 10-100 倍，提高了可扩展性，同时保持了去中心化，为完全 Danksharding 奠定了基础。

## Blob 交易如何改变以太坊以 Rollup 为中心的未来

- **EIP-4844**(Proto-Danksharding) 引入了**携带 Blob 的交易**，以降低 layer-2 (L2) rollups 的数据成本。
- Blob 是**临时的，链下的数据**块（每个 128 KB），存储在以太坊的共识层大约 18 天。
- 它削减了 L2 交易费用 **10-100 倍**，在保持去中心化的同时提高了可扩展性。
- 部署在 **Dencun 升级**（2024 年 3 月 13 日）中，这是 **full Danksharding** 的垫脚石。
- 开发者可以利用新的操作码和 API 来构建具有成本效益的 L2 应用程序。

## ? 为什么 EIP-4844 如此重要

以太坊的可扩展性长期以来一直是一个障碍。高昂的 gas 费用和有限的交易吞吐量（layer-1 上为 15 TPS）已将开发者推向 **layer-2 rollups**，例如 Optimism、Arbitrum 和 zkSync。这些 rollups 在链下批量处理交易，但依赖以太坊的 layer-1 (L1) 来实现 **数据可用性**——确保数据可以访问以进行验证。从历史上看，rollups 使用 **calldata** 将数据发布到 L1，这既昂贵（1,000 美元/MB）又永久存储，即使 rollups 仅需要临时数据（例如，用于欺诈证明）。

**EIP-4844** 或 **Proto-Danksharding** 通过引入 **携带 Blob 的交易** 来解决这个问题。Blob 是大型的、临时的以太坊数据块储存在以太坊的**共识层**（Beacon Chain），而不是执行层（EVM）。这大大降低了成本，使 L2 交易更便宜，并使以太坊能够处理更多数据——为 **full Danksharding** 铺平了道路，其目标是 **100,000 TPS**。

本文深入探讨了 EIP-4844 的机制、实施、代码示例及其对以太坊生态系统的变革性影响。

## ?️ EIP-4844 的工作原理

EIP-4844 引入了一种新的交易类型，**携带 Blob 的交易**，它携带 **blob**——存储在 Beacon Chain 上的临时 128 KB 数据块。以下是关键组件的细分：

### 1\. 携带 Blob 的交易

- **结构**：一种新的交易类型（类型 3），具有 `maxFeePerBlobGas` 和 `blobVersionedHashes` 等字段。
- **目的**：携带对 blob 的引用（通过 KZG 承诺），而不是将大量数据嵌入到 calldata 中。
- **限制**：每个区块最多 **6 个 blob**（约 768 KB），目标是 3 个 blob 以获得最佳定价。

```
// Example Blob Transaction Structure
struct BlobTx {
    uint256 chainId;
    uint256 nonce;
    uint256 maxFeePerGas;
    uint256 maxPriorityFeePerGas;
    uint64 gasLimit;
    address to;
    uint256 value;
    bytes data;
    AccessList accessList;
    uint256 maxFeePerBlobGas; // Fee for blob inclusion
    bytes32[] blobVersionedHashes; // KZG commitment hashes
    bytes signature;
}
```

### 2\. Blob 和临时存储

- **Blob**：固定大小（128 KB）的数据向量，具有 4096 个字段元素（每个 32 字节）。
- **存储**：存储在 Beacon Chain 上的 **blob sidecars** 中，而不是 EVM 中，并在大约 18 天（4096 个 epoch）后删除。
- **可访问性**：EVM 无法访问 Blob，从而降低了执行成本。**BLOBHASH** 操作码检索 blob commitment hashes。

### 3\. KZG 多项式承诺

- **作用**：Blob 使用 **KZG (Kate-Zaverucha-Goldberg) commitment** 进行提交，从而实现紧凑、可验证的数据可用性证明。
- **为什么选择 KZG？**：支持 **data availability sampling (DAS)**，其中节点仅验证数据的一个子集，这对于 full Danksharding 至关重要。
- **Trusted Setup**：一个公共的 KZG 仪式（2023 年）生成了安全的参数，通过社区参与确保了无需信任。

### 4\. BlobGas 市场

- **机制**：一个单独的 **blob gas 市场**（受 EIP-1559 启发）动态地对 blob 包含定价。
- **目标**：目标是每个区块大约 3 个 blob (384 KB)。价格根据需求最多增加/减少 12.5%。
- **操作码**：**BLOBBASEFEE**（来自 EIP-7516）允许合约查询当前的 blob 基础费用（2 gas 成本）。

```
// Query Blob Base Fee
function getBlobBaseFee() external view returns (uint256) {
    return block.blobBaseFee; // Uses BLOBBASEFEE opcode
}
```

### 5\. 提议者/构建者分离 (PBS)

- **目的**：通过将区块构建外包给专业的 **构建者**，降低验证者硬件要求。
- **流程**：构建者处理 blob 并创建区块；提议者（验证者）选择出价最高的区块头。
- **优势**：通过保持验证者职责的轻量化来维持去中心化。

### 6\. 用于验证的预编译

- **Blob 验证预编译**：乐观 rollups 使用它来在欺诈证明期间验证 blob 数据。
- **Point Evaluation 预编译**：使 ZK-rollups 能够证明 KZG commitment 与他们自己的证明之间的等价性。

## ? 工作流程：从用户到 Blob

以下是 EIP-4844 如何集成到以太坊生态系统中：

![](https://img.learnblockchain.cn/2025/06/27/1noQBpP0PpRtg76dThVPe6w.png)

- **Rollup**：批量处理交易并准备一个 blob。
- **Blob 存储**：Rollup 检查 blob gas 价格并提交一个带有 KZG commitment 的 **BlobTx**。
- **以太坊 L1**：将 commitment 存储在链上，并将 blob 存储在 sidecar 中。
- **验证者**：使用 KZG 证明验证数据可用性。
- **确认**：Rollup 向用户确认交易。

## ?‍? 开发者的代码片段

### 1\. 提交 Blob 交易 (Ethers.js)

```
// SPDX-License-Identifier: MIT
import { ethers } from 'ethers';

async function sendBlobTx() {
    const provider = new ethers.providers.JsonRpcProvider('https://mainnet.infura.io/v3/YOUR_API_KEY');
    const wallet = new ethers.Wallet('PRIVATE_KEY', provider);
    const blobData = ethers.utils.hexlify(ethers.utils.randomBytes(128 * 1024)); // 128 KB blob
    const kzgCommitment = '0x...'; // Generated off-chain (KZG ceremony output)

const tx = {
        type: 3, // Blob transaction type
        to: '0xYourContractAddress',
        value: ethers.utils.parseEther('0.01'),
        data: '0x',
        maxFeePerGas: ethers.utils.parseUnits('30', 'gwei'),
        maxPriorityFeePerGas: ethers.utils.parseUnits('1', 'gwei'),
        maxFeePerBlobGas: ethers.utils.parseUnits('1', 'gwei'),
        blobVersionedHashes: [kzgCommitment],
        gasLimit: 21000
    };
    const sentTx = await wallet.sendTransaction(tx);
    console.log('Blob Transaction Hash:', sentTx.hash);
}
```

> **注意**：Blob 数据在链下提交到共识层；只有 commitment 包含在交易中。

### 2\. Blob 交易处理程序 (Solidity)

```
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract BlobTransactionHandler {
    event BlobProcessed(bytes32 commitment);
    struct BlobData {
        bytes32 commitment;
        uint256 timestamp;
    }
    mapping(bytes32 => BlobData) public processedBlobs;
    function processBlob(bytes32 _commitment) external {
        require(_commitment != bytes32(0), "Invalid commitment");
        require(block.blobBaseFee <= 1 gwei, "Blob gas price too high");
        processedBlobs[_commitment] = BlobData({
            commitment: _commitment,
            timestamp: block.timestamp
        });
        emit BlobProcessed(_commitment);
    }
    function getBlobBaseFee() external view returns (uint256) {
        return block.blobBaseFee; // Query blob gas price
    }
}
```

## 3\. 测试 Blob 处理程序 (Hardhat/Chai)

```
const { expect } = require('chai');
const { ethers } = require('hardhat');

describe('BlobTransactionHandler', function () {
    let handler, owner;
    beforeEach(async function () {
        const BlobHandler = await ethers.getContractFactory('BlobTransactionHandler');
        handler = await BlobHandler.deploy();
        [owner] = await ethers.getSigners();
    });
    it('Should process blob commitment', async function () {
        const commitment = ethers.utils.formatBytes32String('test_blob');
        await expect(handler.processBlob(commitment))
            .to.emit(handler, 'BlobProcessed')
            .withArgs(commitment);
        const blobData = await handler.processedBlobs(commitment);
        expect(blobData.commitment).to.equal(commitment);
        expect(blobData.timestamp).to.be.gt(0);
    });
});
```

## ? 架构图

![](https://img.learnblockchain.cn/2025/06/27/1u11tHJR7CfT8mcj3tw5zBQ.png)

- **蓝色**：L2 rollup 组件（批处理和定价）。
- **绿色**：以太坊 L1（blob 存储和验证）。
- **橙色**：Blob gas 市场（动态定价）。

## ? 对以太坊生态系统的影响

EIP-4844，部署在 **Dencun hard fork**（2024 年 3 月 13 日）中，已经重塑了以太坊的可扩展性格局：

1. **成本降低**：

- 与 calldata 相比，Blob 交易将数据发布成本降低了 **10-100 倍**。
- 示例：由于费用降低，L2 rollup **Base** 在 Dencun 之后 **交易量增加了 224%**。

**2\. 可扩展性提升**：

- 支持 0.375 MB/slot（12 秒），使 L2 能够处理 **_1,000 TPS_**。
- 为 full Danksharding 的 **100,000 TPS** 目标做准备。

**3\. L2 采用**：

- 更便宜的费用吸引了更多用户使用 Arbitrum、Optimism 和 Starknet 等 rollups。
- 鼓励 DeFi、NFT 和游戏领域的 dApp 开发。

**4\. 挑战**：

- **Fork Rates**：Dencun 之后，fork rates 增加（3.097 到 6.707 slots/2,000），可能是由于 blob 处理（~56 ms 的同步时间）。
- **Blob 市场**：高需求可能导致拥塞，从而提高费用。
- **用户延迟**：一些 rollups（例如，Optimism）报告了更长的结算时间。

## ? 安全性和去中心化

EIP-4844 在可扩展性与以太坊的核心原则之间取得了平衡：

- **数据可用性**：KZG commitment 确保 blob 在 ~18 天的保留期内可验证，这对于欺诈证明（乐观 rollups）和有效性证明（ZK-rollups）至关重要。
- **去中心化**：**Proposer/Builder Separation (PBS)** 保持了较低的验证者要求，防止了中心化。
- **安全性**：KZG trusted setup 仪式 (2023) 是公开透明的，确保了密码学完整性。

## 需要解决的挑战

- **拥塞**：高 blob 需求可能会导致费用飙升，需要 rollups 优化批处理。
- **Fork 风险**：需要通过网络优化来缓解 fork rates 的增加。
- **归档**：虽然 blob 会过期，但第三方服务（例如，blob 档案）可能会出现以进行长期存储。

## ? 通往 Full Danksharding 的道路

EIP-4844 是通往 **full Danksharding** 的 **过渡步骤**，它将：

- 将 blob 容量增加到 **16-32 MB/区块**。
- 实施 **data availability sampling (DAS)**，其中节点仅验证 blob 数据的一部分。
- 使用 **erasure coding** 来减少每个节点的验证负载。
- 实现 **大规模可扩展性**（100,000+ TPS），同时保持去中心化。

使用 EIP-4844 的 Rollups 将需要进行最少的更改才能适应 full Danksharding，从而确保平稳过渡。

## ?‍? 开发者注意事项

1. **批量优化**：

- 使用 `BLOBBASEFEE` 监控 blob gas 价格。
- 动态调整批量大小以平衡成本和延迟。

```
## Python: Optimize Batch Size
def optimize_batch_size(current_price, target_delay):
    cost_per_byte = current_price / (128 * 1024)  # 128 KB blob
    optimal_size = min(
        MAX_BATCH_SIZE,
        max(MIN_BATCH_SIZE, calculate_size_for_delay(target_delay, cost_per_byte))
    )
    return optimal_size
```

**2\. 集成**：

- 使用 **Ethers.js** 或 **Web3.js** 提交 blob 交易。
- 在链下实施 KZG commitment 生成（需要 KZG 库支持）。

**3\. 测试**：

- 在主网部署之前，在 **测试网**（例如，Sepolia）上测试 blob 交易。
- 模拟 blob gas 定价以优化成本。

## ?‍? 最后的想法

EIP-4844 是以太坊的 **游戏规则改变者**。通过引入携带 blob 的交易，它削减了 L2 成本，提高了吞吐量，并为 full Danksharding 奠定了基础。开发者现在可以构建更经济实惠的 dApp，用户可以享受更便宜的交易，以太坊也越来越接近其 **可扩展的、去中心化的世界计算机** 的愿景。

**下一步是什么？**

- **实验**：在测试网上部署基于 blob 的合约。
- **监控**：跟踪 blob gas 价格并优化 rollup 策略。
- **贡献**：加入以太坊社区，共同塑造通往 full Danksharding 的道路。

>- 原文链接： [medium.com/@ankitacode11...](https://medium.com/@ankitacode11/eip-4844-proto-danksharding-and-ethereums-scalability-leap-a11e6a1398e2)
>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～

Blob 交易如何改变以太坊以 Rollup 为中心的未来

EIP-4844(Proto-Danksharding) 引入了携带 Blob 的交易，以降低 layer-2 (L2) rollups 的数据成本。
Blob 是临时的，链下的数据块（每个 128 KB），存储在以太坊的共识层大约 18 天。
它削减了 L2 交易费用 10-100 倍，在保持去中心化的同时提高了可扩展性。
部署在 Dencun 升级（2024 年 3 月 13 日）中，这是 full Danksharding 的垫脚石。
开发者可以利用新的操作码和 API 来构建具有成本效益的 L2 应用程序。

? 为什么 EIP-4844 如此重要

以太坊的可扩展性长期以来一直是一个障碍。高昂的 gas 费用和有限的交易吞吐量（layer-1 上为 15 TPS）已将开发者推向 layer-2 rollups，例如 Optimism、Arbitrum 和 zkSync。这些 rollups 在链下批量处理交易，但依赖以太坊的 layer-1 (L1) 来实现 数据可用性——确保数据可以访问以进行验证。从历史上看，rollups 使用 calldata 将数据发布到 L1，这既昂贵（1,000 美元/MB）又永久存储，即使 rollups 仅需要临时数据（例如，用于欺诈证明）。

EIP-4844 或 Proto-Danksharding 通过引入 携带 Blob 的交易 来解决这个问题。Blob 是大型的、临时的以太坊数据块储存在以太坊的共识层（Beacon Chain），而不是执行层（EVM）。这大大降低了成本，使 L2 交易更便宜，并使以太坊能够处理更多数据——为 full Danksharding 铺平了道路，其目标是 100,000 TPS。

本文深入探讨了 EIP-4844 的机制、实施、代码示例及其对以太坊生态系统的变革性影响。

?️ EIP-4844 的工作原理

EIP-4844 引入了一种新的交易类型，携带 Blob 的交易，它携带 blob——存储在 Beacon Chain 上的临时 128 KB 数据块。以下是关键组件的细分：

1. 携带 Blob 的交易

结构：一种新的交易类型（类型 3），具有 maxFeePerBlobGas 和 blobVersionedHashes 等字段。
目的：携带对 blob 的引用（通过 KZG 承诺），而不是将大量数据嵌入到 calldata 中。
限制：每个区块最多 6 个 blob（约 768 KB），目标是 3 个 blob 以获得最佳定价。

// Example Blob Transaction Structure
struct BlobTx {
    uint256 chainId;
    uint256 nonce;
    uint256 maxFeePerGas;
    uint256 maxPriorityFeePerGas;
    uint64 gasLimit;
    address to;
    uint256 value;
    bytes data;
    AccessList accessList;
    uint256 maxFeePerBlobGas; // Fee for blob inclusion
    bytes32[] blobVersionedHashes; // KZG commitment hashes
    bytes signature;
}

2. Blob 和临时存储

Blob：固定大小（128 KB）的数据向量，具有 4096 个字段元素（每个 32 字节）。
存储：存储在 Beacon Chain 上的 blob sidecars 中，而不是 EVM 中，并在大约 18 天（4096 个 epoch）后删除。
可访问性：EVM 无法访问 Blob，从而降低了执行成本。BLOBHASH 操作码检索 blob commitment hashes。

3. KZG 多项式承诺

作用：Blob 使用 KZG (Kate-Zaverucha-Goldberg) commitment 进行提交，从而实现紧凑、可验证的数据可用性证明。
为什么选择 KZG？：支持 data availability sampling (DAS)，其中节点仅验证数据的一个子集，这对于 full Danksharding 至关重要。
Trusted Setup：一个公共的 KZG 仪式（2023 年）生成了安全的参数，通过社区参与确保了无需信任。

4. BlobGas 市场

机制：一个单独的 blob gas 市场（受 EIP-1559 启发）动态地对 blob 包含定价。
目标：目标是每个区块大约 3 个 blob (384 KB)。价格根据需求最多增加/减少 12.5%。
操作码：BLOBBASEFEE（来自 EIP-7516）允许合约查询当前的 blob 基础费用（2 gas 成本）。

// Query Blob Base Fee
function getBlobBaseFee() external view returns (uint256) {
    return block.blobBaseFee; // Uses BLOBBASEFEE opcode
}

5. 提议者/构建者分离 (PBS)

目的：通过将区块构建外包给专业的 构建者，降低验证者硬件要求。
流程：构建者处理 blob 并创建区块；提议者（验证者）选择出价最高的区块头。
优势：通过保持验证者职责的轻量化来维持去中心化。

6. 用于验证的预编译

Blob 验证预编译：乐观 rollups 使用它来在欺诈证明期间验证 blob 数据。
Point Evaluation 预编译：使 ZK-rollups 能够证明 KZG commitment 与他们自己的证明之间的等价性。

? 工作流程：从用户到 Blob

以下是 EIP-4844 如何集成到以太坊生态系统中：

Rollup：批量处理交易并准备一个 blob。
Blob 存储：Rollup 检查 blob gas 价格并提交一个带有 KZG commitment 的 BlobTx。
以太坊 L1：将 commitment 存储在链上，并将 blob 存储在 sidecar 中。
验证者：使用 KZG 证明验证数据可用性。
确认：Rollup 向用户确认交易。

?‍? 开发者的代码片段

1. 提交 Blob 交易 (Ethers.js)

// SPDX-License-Identifier: MIT
import { ethers } from 'ethers';

async function sendBlobTx() {
    const provider = new ethers.providers.JsonRpcProvider('https://mainnet.infura.io/v3/YOUR_API_KEY');
    const wallet = new ethers.Wallet('PRIVATE_KEY', provider);
    const blobData = ethers.utils.hexlify(ethers.utils.randomBytes(128 * 1024)); // 128 KB blob
    const kzgCommitment = '0x...'; // Generated off-chain (KZG ceremony output)

    const tx = {
        type: 3, // Blob transaction type
        to: '0xYourContractAddress',
        value: ethers.utils.parseEther('0.01'),
        data: '0x',
        maxFeePerGas: ethers.utils.parseUnits('30', 'gwei'),
        maxPriorityFeePerGas: ethers.utils.parseUnits('1', 'gwei'),
        maxFeePerBlobGas: ethers.utils.parseUnits('1', 'gwei'),
        blobVersionedHashes: [kzgCommitment],
        gasLimit: 21000
    };
    const sentTx = await wallet.sendTransaction(tx);
    console.log('Blob Transaction Hash:', sentTx.hash);
}

注意：Blob 数据在链下提交到共识层；只有 commitment 包含在交易中。

2. Blob 交易处理程序 (Solidity)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract BlobTransactionHandler {
    event BlobProcessed(bytes32 commitment);
    struct BlobData {
        bytes32 commitment;
        uint256 timestamp;
    }
    mapping(bytes32 => BlobData) public processedBlobs;
    function processBlob(bytes32 _commitment) external {
        require(_commitment != bytes32(0), "Invalid commitment");
        require(block.blobBaseFee &lt;= 1 gwei, "Blob gas price too high");
        processedBlobs[_commitment] = BlobData({
            commitment: _commitment,
            timestamp: block.timestamp
        });
        emit BlobProcessed(_commitment);
    }
    function getBlobBaseFee() external view returns (uint256) {
        return block.blobBaseFee; // Query blob gas price
    }
}

3. 测试 Blob 处理程序 (Hardhat/Chai)

const { expect } = require('chai');
const { ethers } = require('hardhat');

describe('BlobTransactionHandler', function () {
    let handler, owner;
    beforeEach(async function () {
        const BlobHandler = await ethers.getContractFactory('BlobTransactionHandler');
        handler = await BlobHandler.deploy();
        [owner] = await ethers.getSigners();
    });
    it('Should process blob commitment', async function () {
        const commitment = ethers.utils.formatBytes32String('test_blob');
        await expect(handler.processBlob(commitment))
            .to.emit(handler, 'BlobProcessed')
            .withArgs(commitment);
        const blobData = await handler.processedBlobs(commitment);
        expect(blobData.commitment).to.equal(commitment);
        expect(blobData.timestamp).to.be.gt(0);
    });
});

? 架构图

蓝色：L2 rollup 组件（批处理和定价）。
绿色：以太坊 L1（blob 存储和验证）。
橙色：Blob gas 市场（动态定价）。

? 对以太坊生态系统的影响

EIP-4844，部署在 Dencun hard fork（2024 年 3 月 13 日）中，已经重塑了以太坊的可扩展性格局：

成本降低：

与 calldata 相比，Blob 交易将数据发布成本降低了 10-100 倍。
示例：由于费用降低，L2 rollup Base 在 Dencun 之后 交易量增加了 224%。

2. 可扩展性提升：

支持 0.375 MB/slot（12 秒），使 L2 能够处理 1,000 TPS。
为 full Danksharding 的 100,000 TPS 目标做准备。

3. L2 采用：

更便宜的费用吸引了更多用户使用 Arbitrum、Optimism 和 Starknet 等 rollups。
鼓励 DeFi、NFT 和游戏领域的 dApp 开发。

4. 挑战：

Fork Rates：Dencun 之后，fork rates 增加（3.097 到 6.707 slots/2,000），可能是由于 blob 处理（~56 ms 的同步时间）。
Blob 市场：高需求可能导致拥塞，从而提高费用。
用户延迟：一些 rollups（例如，Optimism）报告了更长的结算时间。

? 安全性和去中心化

EIP-4844 在可扩展性与以太坊的核心原则之间取得了平衡：

数据可用性：KZG commitment 确保 blob 在 ~18 天的保留期内可验证，这对于欺诈证明（乐观 rollups）和有效性证明（ZK-rollups）至关重要。
去中心化：Proposer/Builder Separation (PBS) 保持了较低的验证者要求，防止了中心化。
安全性：KZG trusted setup 仪式 (2023) 是公开透明的，确保了密码学完整性。

需要解决的挑战

拥塞：高 blob 需求可能会导致费用飙升，需要 rollups 优化批处理。
Fork 风险：需要通过网络优化来缓解 fork rates 的增加。
归档：虽然 blob 会过期，但第三方服务（例如，blob 档案）可能会出现以进行长期存储。

? 通往 Full Danksharding 的道路

EIP-4844 是通往 full Danksharding 的 过渡步骤，它将：

将 blob 容量增加到 16-32 MB/区块。
实施 data availability sampling (DAS)，其中节点仅验证 blob 数据的一部分。
使用 erasure coding 来减少每个节点的验证负载。
实现 大规模可扩展性（100,000+ TPS），同时保持去中心化。