这两种方案，都必须在链上发布数据，因此会占用链上空间；而且，链上空间的大小，决定了 Rollup 系统在单位时间内的处理量（即 TPS）。想得更深一些，如果这些交易数据，能够发布在一个数据量的约束更小的地方，或者说，不去占用 Layer-1 区块的空间，则其处理量，能产生倍加的效果。如果这样的地方有很多，那还可以产生倍乘的效果。

这就是 「数据分片」 及 「以 Rollup 为中心的路线图」 的理念：让 Rollup 方案把交易数据都放到分片区块中，分片有多少个，处理量就能提升多少倍；当前的以太坊区块数据量大概是 20～30 KB，这个数据量显然是安全的，则，如果我们有 64 条分片，我们每 15 秒就能提供 64*30 = 1920 KB = 1.9 MB 的数据量。而且，使用端我提供了这么大的数据吞吐量，但它不会成为全节点的负担，因为这些数据你想下载就下载，不想下载就可以不下载（也就是 「分片」 的含义），大家你下载一点，我下载一点，节点的负担还是很轻的 —— 反正，验证这些 Rollup 合约的状态，并不要求我拥有该 Rollup 的所有历史交易数据。以太坊的状态仍然是安全的。

听起来很合理，但还是那句话，太乐观了，太多假设了：

（1）这种 「想下载就下载，不想下载就不下载」 的方法，在 ZK Rollup 上根本行不通：当 ZK Rollup 要更新状态根时，ZK Rollup 合约更新操作的验证者（也即 Layer-1 的全节点）在接受证明时也必须获得与该证明对应的交易数据，否则就无法通过验证。（不需要提供交易数据，仅验证证明就推进合约状态根的方案也有，叫 Validium，那不是 Rollup）。也就是说，如果仅考虑 ZK Rollup，那么 「数据分片」 的方法，从带宽上来说，与大区块没有任何分别。不管这些数据一开始被发到了谁手上、存到了哪里，全节点都要下载它们。

（2）对 Optimistic Rollup 来说，如果你愿意采取更乐观一点的假设，当然可以，你可以平时完全不下载交易数据，仅保留获得终局性的最新状态根，仅在发生争议时，再下载相关的交易数据，从全节点的角度看，并没有因此丧失对合约状态的验证能力；但是从用户的角度看，事情就完全不同了：你开始不确定自己到底是不是随时能够重构自己的状态，来完成取款。也就是说，用户将不能确定自己用的到底是 Optimistic Rollup，还是 plasma。本来，Optimistic Rollup 的方案就是保证了所有全节点都有历史交易的备份，所以用户可以容易地重建自己的状态，并提交状态证明（或断言）完成取款；但如果这一点保证失去了，你就不确定自己能不能重建状态了。Optimistic Rollup 的安全性也会受到影响：它的安全假设是，获得了交易数据的人之中至少有 1 个是遵守协议的；在数据分片模式下，你并不知道，有多少人会去请求这部分交易数据。 (责任编辑：admin)