Nâng cấp Dencun của Ethereum và các cơ hội tiềm năng
Tuyển chọn TechFlowTuyển chọn TechFlow
Nâng cấp Dencun của Ethereum và các cơ hội tiềm năng
Bài viết này sẽ giải thích các chi tiết kỹ thuật của bản nâng cấp Dencun bằng ngôn ngữ đơn giản, dễ hiểu.
Chuyên sâu báo cáo Web3Tác giả: Fishery Isla, cộng sự cốt lõi Biteye
Biên tập: Crush, cộng sự cốt lõi Biteye
Cộng đồng: @BiteyeCN
*Toàn văn khoảng 4500 chữ, thời gian đọc dự kiến 5 phút
Lên kế hoạch nâng cấp mạng Ethereum Dencun đã chính thức ra mắt trên mạng thử nghiệm Goerli vào ngày 17 tháng 1 năm 2024, và thành công triển khai trên mạng thử nghiệm Sepolia vào ngày 30 tháng 1. Việc nâng cấp Dencun đang ngày càng đến gần.
Sau khi hoàn thành đợt nâng cấp tiếp theo trên mạng thử nghiệm Holesky vào ngày 7 tháng 2, sẽ là bước chuyển sang nâng cấp mạng chính. Việc nâng cấp mạng chính của đợt phân nhánh (fork) Cancun hiện đã được xác định chính thức diễn ra vào ngày 13 tháng 3.
Mỗi lần nâng cấp Ethereum gần như đều đi kèm với một đợt tăng giá theo chủ đề. Nhìn lại lần nâng cấp trước đó của Ethereum là Shanghai vào ngày 12 tháng 4 năm 2023, các dự án liên quan đến POS đã thu hút mạnh mẽ sự chú ý từ thị trường.
Nếu theo kinh nghiệm trước đây, lần nâng cấp Dencun này cũng mang lại cơ hội đầu tư sớm.
Tuy nhiên, do nội dung kỹ thuật đằng sau nâng cấp Dencun khá phức tạp, không thể tóm gọn bằng một câu đơn giản như "Chuyển đổi Ethereum từ PoW sang PoS" như lần nâng cấp Shanghai, khiến việc xác định trọng tâm đầu tư trở nên khó khăn.
Do đó, bài viết này sẽ dùng ngôn ngữ dễ hiểu để giải thích chi tiết kỹ thuật của nâng cấp Dencun, giúp bạn đọc nắm rõ mối liên hệ giữa lần nâng cấp này với các lĩnh vực như khả năng truy cập dữ liệu (DA) và Layer 2.
01 EIP 4844
EIP-4844 là đề xuất quan trọng nhất trong lần nâng cấp Dencun này, đánh dấu bước tiến thực tế và quan trọng trên con đường mở rộng quy mô theo hướng phi tập trung của Ethereum.
Hiểu một cách đơn giản, hiện tại các mạng Layer 2 cần gửi dữ liệu giao dịch xảy ra trên Layer 2 vào phần calldata của mạng chính Ethereum để các nút có thể kiểm chứng tính hợp lệ của khối do mạng Layer 2 tạo ra.
Vấn đề đặt ra là, mặc dù dữ liệu giao dịch đã được nén tối đa, nhưng lượng lớn giao dịch từ Layer 2 nhân với chi phí lưu trữ cao ngất trên mạng chính Ethereum vẫn tạo thành gánh nặng đáng kể đối với các nút và người dùng Layer 2. Chỉ riêng yếu tố giá cả đã có thể khiến Layer 2 mất đi lượng lớn người dùng, buộc họ phải chuyển sang các sidechain.
EIP-4844 giải quyết vấn đề này bằng cách thiết lập một khu vực lưu trữ mới rẻ hơn gọi là BLOB (Binary Large Object - Đối tượng nhị phân lớn), sử dụng một loại giao dịch mới tên là "BLOB-Carrying Transaction" để thay thế cho việc lưu trữ dữ liệu giao dịch trong calldata như trước đây, giúp giảm chi phí Gas cho các Layer 2 trong hệ sinh thái Ethereum.
Lý do lưu trữ BLOB rẻ hơn
Ai cũng biết rẻ thì phải đánh đổi. BLOB dữ liệu rẻ hơn so với dữ liệu Calldata thông thường cùng kích thước vì lớp thực thi Ethereum (EL, EVM) thực tế không thể truy cập trực tiếp vào dữ liệu BLOB.
Thay vào đó, EL chỉ có thể truy cập tham chiếu (reference) của dữ liệu BLOB, còn dữ liệu BLOB thực tế chỉ được tải xuống và lưu trữ bởi lớp đồng thuận (CL - còn gọi là nút beacon). Việc lưu trữ này tiêu tốn ít bộ nhớ và tài nguyên xử lý hơn rất nhiều so với dữ liệu Calldata thông thường.
Hơn nữa, BLOB còn có đặc điểm chỉ lưu trữ trong một khoảng thời gian giới hạn (thường khoảng 18 ngày), không giống như sổ cái Ethereum có thể phình to vô hạn.
Thời hạn lưu trữ của BLOB
Khác với sổ cái blockchain vĩnh viễn, BLOB là nơi lưu trữ tạm thời, thời gian tồn tại là 4096 kỷ nguyên, tương đương khoảng 18 ngày.
Sau thời hạn này, hầu hết các client đồng thuận sẽ không thể truy xuất dữ liệu cụ thể trong BLOB. Tuy nhiên, bằng chứng về sự tồn tại trước đó của nó sẽ được giữ lại dưới dạng cam kết KZG trên mạng chính và được lưu trữ vĩnh viễn.
Tại sao chọn 18 ngày? Đây là sự cân bằng giữa chi phí lưu trữ và hiệu lực.
Đầu tiên cần xem xét đối tượng hưởng lợi trực tiếp nhất từ lần nâng cấp này là các Optimistic Rollups (ví dụ: Arbitrum và Optimism), vì theo thiết kế của Optimistic Rollups, có cửa sổ thời gian 7 ngày để đưa ra bằng chứng gian lận (Fraud Proof).
Dữ liệu giao dịch được lưu trong blob chính là tài liệu cần thiết khi khởi động khiếu nại trên Optimistic Rollups.
Do đó, thời hạn hiệu lực của Blob phải đảm bảo rằng bằng chứng gian lận của Optimistic Rollups luôn truy cập được. Để đơn giản hóa, cộng đồng Ethereum đã chọn số mũ 2^12 (4096 kỷ nguyên, mỗi kỷ nguyên khoảng 6,4 phút).
Mối quan hệ giữa BLOB-Carrying Transaction và BLOB
Hiểu rõ mối quan hệ giữa hai thành phần này rất quan trọng để nắm bắt vai trò của BLOB trong khả năng truy cập dữ liệu (DA).
Thành phần đầu tiên là toàn bộ đề xuất EIP-4844, là một loại giao dịch mới; thành phần thứ hai có thể hiểu là một vị trí lưu trữ tạm thời dành riêng cho dữ liệu Layer 2.
Mối quan hệ giữa chúng có thể hiểu như sau: phần lớn dữ liệu (dữ liệu giao dịch Layer 2) trong giao dịch mới được lưu trữ trong BLOB, trong khi phần còn lại - chính là cam kết (Commitment) của dữ liệu BLOB - sẽ được lưu trong calldata của mạng chính. Nói cách khác, Commitment này có thể được EVM đọc được.
Bạn có thể hình dung Commitment giống như việc xây dựng tất cả các giao dịch trong BLOB thành một cây Merkle, và chỉ có gốc cây Merkle (chính là Commitment) mới có thể được hợp đồng truy cập.
Bằng cách này, ta đạt được điều tinh tế: mặc dù EVM không thể biết nội dung cụ thể của BLOB, nhưng các hợp đồng EVM có thể xác minh tính xác thực của dữ liệu giao dịch thông qua Commitment.
02 Mối quan hệ giữa BLOB và Layer 2
Công nghệ Rollup đạt được khả năng truy cập dữ liệu (DA) bằng cách tải dữ liệu lên mạng chính Ethereum, nhưng mục đích không phải để các hợp đồng thông minh L1 đọc hoặc xác minh trực tiếp dữ liệu này.
Việc tải dữ liệu giao dịch lên L1 chỉ nhằm đảm bảo tất cả các bên tham gia đều có thể xem dữ liệu này.
Trước khi nâng cấp Dencun, như đã nói ở trên, Op-rollup sẽ đăng dữ liệu giao dịch dưới dạng Calldata lên Ethereum. Nhờ vậy, bất kỳ ai cũng có thể sử dụng thông tin giao dịch này để tái tạo trạng thái và kiểm chứng tính đúng đắn của mạng Layer 2.
Rõ ràng, dữ liệu giao dịch Rollup cần rẻ + công khai minh bạch. Calldata không phải là nơi lý tưởng để Layer 2 lưu trữ dữ liệu giao dịch chuyên biệt, trong khi BLOB-Carrying Transaction mới chính là giải pháp được thiết kế riêng cho Rollup.
Đọc đến đây, bạn có thể tự hỏi: những dữ liệu giao dịch này dường như không quan trọng, vậy chúng có tác dụng gì?
Thực tế, dữ liệu giao dịch chỉ được dùng trong một vài trường hợp hiếm:
-
Đối với Optimistic Rollup, dựa trên giả định tin cậy, có khả năng xảy ra hành vi thiếu trung thực. Lúc này dữ liệu giao dịch được tải lên mới phát huy tác dụng, cho phép người dùng sử dụng dữ liệu này để khởi động khiếu nại giao dịch (Fraud proof);
-
Đối với ZK Rollup, bằng chứng kiến thức không (zero-knowledge proof) đã chứng minh việc cập nhật trạng thái là chính xác. Việc tải dữ liệu lên chỉ nhằm cho phép người dùng tự tính toán trạng thái đầy đủ, để kích hoạt cơ chế thoát hiểm (Escape Hatch) khi các nút Layer 2 vận hành sai (cần cây trạng thái L2 đầy đủ - sẽ giải thích kỹ hơn ở phần cuối).
Điều này có nghĩa là, các kịch bản mà hợp đồng thực sự sử dụng dữ liệu giao dịch là rất hạn chế. Ngay cả trong khiếu nại giao dịch của Optimistic Rollup, chỉ cần cung cấp bằng chứng rằng giao dịch đó "từng tồn tại" (trạng thái), chứ không cần lưu sẵn chi tiết giao dịch đó trên mạng chính.
Vì vậy, nếu chúng ta đặt dữ liệu giao dịch vào phần tử BLOB, mặc dù hợp đồng không thể truy cập, nhưng hợp đồng mạng chính có thể lưu trữ Commitment của BLOB.
Trong tương lai, nếu cơ chế khiếu nại cần một giao dịch cụ thể, chúng ta chỉ cần cung cấp dữ liệu của giao dịch đó, miễn là nó khớp với Commitment. Như vậy đã đủ thuyết phục hợp đồng chấp nhận và sử dụng dữ liệu giao dịch cho mục đích khiếu nại.
Cách làm này vừa tận dụng tính công khai minh bạch của dữ liệu giao dịch, vừa tránh được chi phí gas khổng lồ khi phải lưu toàn bộ dữ liệu vào hợp đồng trước.
Bằng cách chỉ ghi lại Commitment, ta đạt được tính xác minh được của dữ liệu giao dịch đồng thời tối ưu hóa cực đại chi phí. Đây là một giải pháp thông minh và hiệu quả cho việc tải dữ liệu giao dịch trong công nghệ Rollup.
Cần lưu ý rằng, trong thực tế triển khai Dencun, không sử dụng phương pháp cây Merkle giống Celestia để tạo Commitment, mà dùng thuật toán KZG (Kate-Zaverucha-Goldberg - cam kết đa thức) tinh vi.
So với bằng chứng cây Merkle, quá trình tạo KZG Proof phức tạp hơn, nhưng kích thước bằng chứng nhỏ hơn, bước xác minh đơn giản hơn. Nhược điểm là cần thiết lập đáng tin cậy (ceremony.ethereum.org hiện đã kết thúc) và không chống được tấn công máy tính lượng tử (Dencun sử dụng phương pháp Version Hash, nếu cần có thể thay đổi phương pháp xác minh khác).
Đối với dự án DA nổi bật hiện nay là Celestia, họ sử dụng biến thể cây Merkle. So với KZG, mức độ phụ thuộc vào sự trung thực của nút cao hơn, nhưng giúp giảm yêu cầu ngưỡng tài nguyên tính toán giữa các nút, duy trì đặc trưng phi tập trung của mạng.
03 Cơ hội từ Dencun
EIP-4844 tuy giúp Layer 2 giảm chi phí và tăng hiệu suất, nhưng đồng thời cũng dẫn đến các rủi ro an ninh mới, từ đó mở ra cơ hội đầu tư mới.
Để hiểu rõ lý do, chúng ta cần quay lại nhắc đến cơ chế thoát hiểm (escape hatch) hay cơ chế rút tiền cưỡng chế (forced withdrawal).
Khi nút Layer 2 ngừng hoạt động, cơ chế này đảm bảo an toàn tài sản người dùng trở lại mạng chính. Điều kiện kích hoạt cơ chế này là người dùng cần có được cây trạng thái đầy đủ của Layer 2.
Theo bình thường, người dùng chỉ cần yêu cầu dữ liệu từ một nút đầy đủ (full node) Layer 2, tạo bằng chứng Merkle, rồi gửi lên hợp đồng mạng chính để chứng minh tính hợp lệ của việc rút tiền.
Nhưng đừng quên rằng người dùng muốn kích hoạt cơ chế thoát hiểm để rời khỏi L2 chính là vì nút L2 gian lận. Nếu nút đã gian lận, thì khả năng cao họ sẽ không cung cấp dữ liệu mong muốn.
Đây chính là kiểu tấn công giữ dữ liệu (data withholding attack) mà Vitalik thường nhắc đến.
Trước EIP-4844, dữ liệu Layer 2 được ghi lại vĩnh viễn trên mạng chính. Trong trường hợp không có nút Layer 2 nào cung cấp trạng thái off-chain đầy đủ, người dùng có thể tự triển khai một full node.
Full node này có thể lấy tất cả dữ liệu lịch sử do bộ sắp xếp (sequencer) Layer 2 đăng trên mạng chính Ethereum, từ đó người dùng có thể xây dựng bằng chứng Merkle cần thiết, gửi lên hợp đồng mạng chính và rút tài sản L2 một cách an toàn.
Tuy nhiên, sau EIP-4844, dữ liệu Layer 2 chỉ tồn tại trong BLOB của các nút đầy đủ Ethereum, và dữ liệu lịch sử trước 18 ngày sẽ bị xóa tự động.
Do đó, phương pháp ở đoạn trên - đồng bộ mạng chính để lấy toàn bộ cây trạng thái - không còn khả thi. Muốn có được cây trạng thái đầy đủ của Layer 2, người dùng chỉ còn cách nhờ vào các nút mạng chính thứ ba tình nguyện lưu trữ toàn bộ dữ liệu BLOB Ethereum (mà lẽ ra đã bị xóa sau 18 ngày), hoặc các nút gốc Layer 2 (rất hiếm).
Vì vậy, sau khi 4844 ra mắt, việc người dùng lấy được cây trạng thái đầy đủ của Layer 2 theo cách đáng tin cậy hoàn toàn sẽ trở nên cực kỳ khó khăn.
Người dùng không có kênh ổn định để lấy cây trạng thái Layer 2, sẽ không thể thực hiện thao tác rút tiền cưỡng chế trong điều kiện cực đoan. Do đó, 4844 gián tiếp tạo ra điểm yếu/thiếu hụt an ninh cho Layer 2.
Để khắc phục điểm thiếu hụt an ninh này, chúng ta cần một giải pháp lưu trữ không cần tin cậy (trustless) có chu kỳ kinh tế tích cực. Lưu trữ ở đây chủ yếu ám chỉ việc giữ lại dữ liệu trong Ethereum theo cách không cần tin cậy, khác biệt với các dự án lưu trữ truyền thống trước đây vì thêm yếu tố "không cần tin cậy".
Ethstorage có thể giải quyết vấn đề không cần tin cậy này, và đã nhận được tài trợ từ Quỹ Ethereum trong hai giai đoạn.
Có thể nói khái niệm này thực sự phù hợp/khắc phục điểm yếu của nâng cấp Dencun, rất đáng chú ý.
Trước hết, ý nghĩa trực quan nhất của Ethstorage là có thể kéo dài thời gian khả dụng của BLOB DA theo cách hoàn toàn phi tập trung, bù đắp điểm yếu an ninh lớn nhất của Layer 2 sau 4844.
Hơn nữa, phần lớn các giải pháp L2 hiện tại chủ yếu tập trung mở rộng khả năng tính toán của Ethereum, tức tăng TPS. Tuy nhiên, nhu cầu lưu trữ lượng lớn dữ liệu an toàn trên mạng chính Ethereum đang tăng vọt, đặc biệt do sự phổ biến của các dApp như NFT và DeFi.
Ví dụ, nhu cầu lưu trữ NFT trên chuỗi rất rõ ràng, vì người dùng không chỉ sở hữu token trong hợp đồng NFT mà còn sở hữu hình ảnh trên chuỗi. Ethstorage có thể giải quyết vấn đề tin cậy bổ sung khi lưu trữ hình ảnh này trên bên thứ ba.
Cuối cùng, Ethstorage còn giải quyết nhu cầu về giao diện (frontend) phi tập trung cho các dApp. Giải pháp hiện tại chủ yếu là lưu trữ trên máy chủ tập trung (kèm DNS), khiến website dễ bị kiểm duyệt và các vấn đề khác như DNS hijacking, hacker tấn công website hoặc sập máy chủ, sự kiện Tornado Cash là minh chứng rõ ràng.
Hiện tại Ethstorage vẫn đang trong giai đoạn thử nghiệm mạng lưới ban đầu, người dùng quan tâm đến tiềm năng của lĩnh vực này có thể trải nghiệm thử.
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
@BiteyeCN
