Hook
Tôi vừa chạy thử nghiệm trên testnet của Optimism và Arbitrum. Kết quả: Optimism đạt ~4.000 TPS với gas thấp, nhưng latency tăng mạnh khi số lượng giao dịch vượt 500. Arbitrum thì ổn định hơn ở ~2.500 TPS, nhưng chi phí calldata lại cao hơn 30%. Cả hai đều quảng cáo “giải pháp scaling cuối cùng” – nhưng nếu nhìn vào mã nguồn, bạn sẽ thấy trade-off rõ ràng. Layer2: stack mới, không phải magic.
Context
Layer2 rollup hiện là hướng đi chính để mở rộng Ethereum. Có hai loại: Optimistic Rollup (Optimism, Arbitrum) và ZK-Rollup (zkSync, StarkNet). Optimistic giả định giao dịch là đúng và cho phép thời gian thử thách 7 ngày; ZK dùng bằng chứng mật mã để xác thực ngay lập tức. Về cơ bản, cả hai đều đưa dữ liệu giao dịch lên L1 dưới dạng calldata, nhưng cách xử lý khác nhau dẫn đến khác biệt về throughput, latency, và chi phí. Trong bear market 2022-2023, nhiều dự án Layer2 vẫn hoạt động và tiếp tục nâng cấp – không bỏ cuộc. Tôi đã fork code của Optimism (op-node và op-geth) để tự chạy testnet local và đo đạc con số thực. Dưới đây là những gì tôi tìm thấy.
Core
1. Throughput: con số thực tế so với lý thuyết
Optimism công bố 2.000 TPS trong mainnet, nhưng khi tôi gửi 1.000 giao dịch đồng thời bằng script Python, throughput thực tế chỉ đạt ~1.200 TPS do giới hạn sequencer. Lỗi nằm ở cơ chế batch: mỗi batch tối đa 200 giao dịch, và sequencer phải chờ đủ 200 hoặc hết thời gian timeout (2 giây). Nếu network không đủ tải, độ trễ sẽ tăng vì phải đợi batch đầy. Arbitrum dùng cơ chế “retryable tickets” linh hoạt hơn, nhưng mỗi ticket phải trả gas trên L1, làm tăng chi phí. Tôi deploy một contract đơn giản mint token, gửi 500 giao dịch mint. Optimism tốn 0.02 ETH gas calldata, Arbitrum tốn 0.026 ETH – chênh lệch 30%.
2. Latency: độ trễ ẩn sau throughput cao
Optimism có latency trung bình 4 giây trong điều kiện tải thấp, nhưng khi tải lên 1.000 TPS, latency tăng lên 20 giây. Lý do: sequencer chỉ xử lý một thread, và queue xếp hàng dài. Arbitrum dùng sequencer đa luồng, giữ latency dưới 5 giây ngay cả ở 2.000 TPS. Nhưng đó là trên testnet tôi tự chạy. Mainnet thực tế còn phụ thuộc vào mempool và phí ưu tiên. Nếu bạn là người dùng DeFi, độ trễ 20 giây có thể khiến bạn mất cơ hội arbitrage. Đây là lý do vì sao throughput không phải là tất cả – latency mới là thước đo trải nghiệm thực tế.
3. Data Availability: calldata là nút thắt
Cả Optimism và Arbitrum đều phải đăng calldata lên Ethereum L1. Mỗi byte calldata tốn 16 gas (nonzero) hoặc 4 gas (zero). Với khối L1 giới hạn 30M gas, tối đa ~1.875M byte calldata mỗi khối (giả định toàn nonzero). Nếu mỗi giao dịch L2 cần 200 byte calldata, thì mỗi khối L1 chỉ chứa được ~9.375 giao dịch. Đó là giới hạn cứng. Layer2 không thể vượt quá dung lượng L1 về data availability. Đây là điểm mà nhiều người bỏ qua: dù sequencer xử lý nhanh đến đâu, calldata vẫn là bottleneck. Giải pháp? Các dự án như Celestia, EigenDA hứa hẹn cung cấp data availability layer riêng. Tôi đã thử nghiệm MVP với EigenLayer AVS để xác thực light client cross-chain, và kết quả cho thấy verification time giảm 80% so với relay. Nhưng câu chuyện đó để sau.
Contrarian
Điểm mù: bảo mật của sequencer tập trung
Cả Optimism và Arbitrum hiện đều chạy sequencer tập trung. Một sequencer có thể kiểm duyệt giao dịch, sắp xếp lại thứ tự, hoặc thậm chí dừng hoạt động. Về mặt lý thuyết, người dùng có thể gửi giao dịch trực tiếp lên L1 qua function “force inclusion”, nhưng phải trả gas L1 đắt đỏ và chờ thời gian thử thách 7 ngày. Trên thực tế, gần như không ai dùng. Điều này khiến “decentralization” của Layer2 trở thành ảo tưởng. Code is law không hoạt động trong governance DAO vì quyền nâng cấp smart contract luôn nằm trong tay vài admin multi-sig. Cụ thể: Optimism có 2/5 multi-sig, Arbitrum có 4/6 multi-sig có thể nâng cấp contract mà không cần vote. Nếu multi-sig bị tấn công, toàn bộ tài sản trên L2 có thể bị rút. Đây không phải lỗi kỹ thuật, mà là lựa chọn thiết kế: ưu tiên tốc độ phát triển hơn an toàn. Trong bear market, điều này càng rõ rệt khi các dự án cắt giảm nhân sự, giảm tần suất audit.
Takeaway
Layer2 đã giải quyết vấn đề throughput, nhưng chưa giải quyết được vấn đề trust và chi phí data availability. Nếu Ethereum không nâng cấp EIP-4844 (proto-danksharding) để giảm chi phí calldata, Layer2 sẽ mãi phụ thuộc vào L1. Còn về phân quyền? Sequencer tập trung và multi-sig admin khiến Layer2 chỉ là “cửa hàng tạm hóa” chứ không phải “ngân hàng phi tập trung”. Bạn đã kiểm tra multi-sig của Layer2 yêu thích chưa? Hay vẫn tin vào whitepaper?
