Giải mã bài viết mới của Vitalik: Tại sao các Rollup không sử dụng hiệu quả không gian Blob lại rơi vào bế tắc phát triển?
Tuyển chọn TechFlowTuyển chọn TechFlow
Giải mã bài viết mới của Vitalik: Tại sao các Rollup không sử dụng hiệu quả không gian Blob lại rơi vào bế tắc phát triển?
Sau nâng cấp Cancun, hiệu năng đã sử dụng được rồi, nhưng Vitalik lại lo lắng sâu sắc về sự phát triển của Rollup.
Chuyên sâu báo cáo Web3Tác giả: Haotian
Làm thế nào để hiểu được suy nghĩ của Vitalik Buterin về mở rộng quy mô Ethereum trong bài viết mới nhất? Có người nói rằng Vitalik đang ủng hộ "Blobscription" (ghi dữ liệu vĩnh viễn trên Blob), thật là quá mức.
Vậy thì cơ chế hoạt động của gói dữ liệu Blob ra sao? Sau nâng cấp Cancun, tại sao không gian Blob lại chưa được sử dụng hiệu quả? Mẫu khả dụng dữ liệu DAS (Data Availability Sampling) có phải là bước chuẩn bị cho phân mảnh (sharding)?
Theo tôi, sau nâng cấp Cancun, hiệu năng đã đủ dùng, nhưng Vitalik lại lo lắng sâu sắc về sự phát triển của Rollup. Vì sao? Tiếp theo đây, tôi xin chia sẻ quan điểm của mình:
1) Như đã giải thích nhiều lần trước đó, Blob là một gói dữ liệu tạm thời tách rời khỏi EVM calldata, có thể truy xuất trực tiếp bởi lớp đồng thuận. Lợi ích rõ rệt là khi EVM thực thi giao dịch sẽ không cần truy cập vào dữ liệu Blob, do đó không phát sinh chi phí tính toán cao ở tầng thực thi.
Hiện nay, sau khi cân nhắc nhiều yếu tố, kích thước 1 Blob là 128KB; một Batch giao dịch gửi lên mạng chính tối đa mang theo 2 Blob. Trong trường hợp lý tưởng, mục tiêu cuối cùng của mỗi khối mạng chính là chứa khoảng 128 gói dữ liệu Blob, tương đương 16MB.
Do đó, các dự án Rollup cần cố gắng cân bằng giữa số lượng khối Blob, dung lượng TPS và chi phí lưu trữ nút Blob trên mạng chính để đạt được tỷ lệ hiệu suất/giá tốt nhất khi sử dụng không gian Blob.
Lấy Optimism làm ví dụ: hiện tại trung bình mỗi ngày xử lý khoảng 500.000 giao dịch, cứ trung bình 2 phút lại Batch một lần lên mạng chính, mỗi lần mang theo 1 gói Blob. Tại sao chỉ mang 1? Vì TPS hiện tại chỉ ở mức này, không cần dùng đến 2. Tất nhiên cũng có thể mang 2, nhưng mỗi Blob sẽ không đầy, mà vẫn làm tăng thêm chi phí lưu trữ — điều này là không cần thiết.
Nhưng nếu khối lượng giao dịch ngoài chuỗi của Rollup tăng mạnh, ví dụ như mỗi ngày cần xử lý 50 triệu giao dịch thì sao?
1. Nén (Compress) lượng giao dịch trong mỗi Batch, cố gắng lấp đầy không gian Blob với càng nhiều giao dịch càng tốt;
2. Tăng số lượng Blob;
3. Rút ngắn tần suất Batch giao dịch;
2) Do lượng dữ liệu mà khối mạng chính có thể chứa bị giới hạn bởi Gas Limit và chi phí lưu trữ, việc một khối chứa 128 Blob là trạng thái lý tưởng. Hiện tại chúng ta chưa cần đến mức đó — Optimism cứ 2 phút mới dùng 1 Blob. Vì vậy, không gian để các dự án Layer2 nâng cao TPS, mở rộng lượng người dùng và phát triển hệ sinh thái còn rất rất lớn.
Do đó, trong một thời gian ngắn sau nâng cấp Cancun, các Rollup chưa cạnh tranh gay gắt ("chưa卷") về số lượng, tần suất sử dụng Blob hay đấu giá không gian Blob.
Lý do Vitalik đề cập đến "Blobscription" là vì những loại ghi dữ liệu kiểu này có thể tạm thời làm tăng khối lượng giao dịch, dẫn đến nhu cầu sử dụng Blob tăng lên, từ đó giúp làm rõ hơn cơ chế vận hành của Blob. Nhưng nội dung thực sự mà Vitalik muốn truyền tải thì chẳng liên quan mấy đến "ghi dữ liệu".
Về mặt lý thuyết, nếu có dự án Layer2 thường xuyên gửi Batch giao dịch lên mạng chính với tần suất cao và dung lượng lớn, đồng thời luôn làm đầy các khối Blob, thì miễn là họ sẵn sàng chịu chi phí Batch giao dịch giả mạo cao, họ hoàn toàn có thể ảnh hưởng đến việc sử dụng Blob bình thường của các Layer2 khác. Nhưng trong thực tế hiện nay, điều này giống như việc ai đó mua sức mạnh băm (hash power) để tấn công 51% mạng BTC — về lý thuyết là khả thi, nhưng thiếu động lực lợi ích thực tế.
Do đó, phí gas của Layer2 sẽ ổn định ở mức "thấp" trong một thời gian dài, tạo ra một "cửa sổ vàng" để thị trường Layer2 tích tụ lực lượng và phát triển.
3) Vậy thì, nếu một ngày nào đó thị trường Layer2 phát triển đến mức cực thịnh, lượng giao dịch Batch lên mạng chính khổng lồ, khiến không gian Blob hiện tại không đủ dùng thì sao? Ethereum đã sớm đưa ra giải pháp: sử dụng kỹ thuật lấy mẫu khả dụng dữ liệu (DAS - Data Availability Sampling).
Hiểu đơn giản, là thay vì yêu cầu một nút lưu trữ toàn bộ dữ liệu, ta phân phối dữ liệu đó đồng thời lên nhiều nút khác nhau. Ví dụ: mỗi nút chỉ lưu 1/8 dữ liệu Blob toàn bộ, 8 nút tạo thành một nhóm để đáp ứng khả năng DA — như vậy, dung lượng lưu trữ Blob thực tế được mở rộng gấp 8 lần. Đây cũng chính là việc mà giai đoạn Sharding (phân mảnh) trong tương lai sẽ thực hiện.
Tuy nhiên, việc Vitalik nhiều lần nhấn mạnh điều này dường như hàm chứa ý nghĩa sâu xa, giống như đang cảnh báo các dự án Layer2: Đừng suốt ngày phàn nàn rằng khả năng DA của Ethereum quá đắt! Với TPS hiện tại của các anh, năng lực của Blob thậm chí còn chưa được khai thác tối đa. Hãy tập trung phát triển hệ sinh thái, mở rộng người dùng và khối lượng giao dịch đi, đừng lúc nào cũng nghĩ đến việc chạy trốn khỏi DA bằng những chiêu trò kiểu "tạo chuỗi một cú nhấp chuột".
Sau đó, Vitalik còn bổ sung thêm một câu: ông cho rằng trong các Rollup cốt lõi hiện nay, chỉ có Arbitrum đạt đến stage 1, mặc dù DeGate, Fuel và một vài dự án khác đã đạt stage 2, nhưng vẫn chưa được đại chúng biết đến rộng rãi. Stage 2 mới là mục tiêu cuối cùng về độ an toàn của Rollup. Rất ít Rollup đạt được stage 1, phần lớn vẫn đang ở stage 0 — có thể thấy sự phát triển của ngành Rollup thực sự khiến Vitalik vô cùng lo lắng.
4) Thực tế, xét riêng về vấn đề nút thắt mở rộng quy mô, giải pháp Rollup Layer2 vẫn còn rất nhiều tiềm năng cải thiện hiệu suất.
1. Nén dữ liệu để sử dụng không gian Blob hiệu quả hơn: OP-Rollup hiện có thành phần compressor chuyên biệt thực hiện việc này; ZK-Rollup bản thân đã nén dữ liệu thông qua việc submit chứng minh SNARK/STARK lên mạng chính — đó chính là hình thức "nén".
2. Giảm thiểu sự phụ thuộc vào mạng chính, chỉ sử dụng cơ chế xác minh theo hướng lạc quan (optimistic proof) trong các trường hợp đặc biệt để đảm bảo an toàn cho L2. Ví dụ: Plasma giữ phần lớn dữ liệu trên chuỗi, nhưng chỉ thực hiện gửi/rút tiền trên mạng chính, do đó mạng chính có thể cam kết về tính an toàn cho nó.
Điều này có nghĩa là Layer2 nên chỉ liên kết chặt chẽ với mạng chính ở những thao tác quan trọng như gửi/rút tiền, vừa giảm gánh nặng cho mạng chính, vừa tăng hiệu suất tự thân cho L2. Những phương án như khả năng xử lý song song của Sequencer, lọc, phân loại và xử lý sơ bộ hàng loạt giao dịch ngoài chuỗi, hay mô hình Rollup lai (hybrid Rollup) mà Metis đang thúc đẩy — giao dịch thông thường đi theo OP-Rollup, yêu cầu rút tiền đặc biệt đi theo tuyến ZK — đều xuất phát từ cùng một định hướng như vậy.
Trên đây
Có thể nói, bài viết của Vitalik về định hướng mở rộng quy mô Ethereum trong tương lai thực sự rất sâu sắc và giàu tính gợi mở. Đặc biệt là sự không hài lòng với hiện trạng phát triển Layer2, sự khẳng định lạc quan về tiềm năng hiệu năng của Blob, kỳ vọng về công nghệ phân mảnh trong tương lai, thậm chí còn tận tình chỉ ra những hướng tối ưu hóa dành cho các dự án Layer2.
Thực tế, giờ đây điều duy nhất còn bất định đã được chuyển giao hoàn toàn cho Layer2: Làm thế nào để tăng tốc phát triển đây?
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
Haotian | CryptoInsight
