Bản nâng cấp mạng Ethereum Phiên bản testnet Dencun đã được ra mắt trên mạng thử nghiệm Goerli vào ngày 17 tháng 1 năm 2024 và mạng thử nghiệm Sepolia đã được ra mắt thành công vào ngày 30 tháng 1. Việc nâng cấp Dencun ngày càng đến gần hơn.

Sau bản nâng cấp mạng thử nghiệm Holesky vào ngày 7 tháng 2, đây sẽ là bản nâng cấp mạng chính. Việc ra mắt mainnet của bản nâng cấp Cancun đã được xác định chính thức vào ngày 13 tháng 3 năm 2024.

Hầu hết mọi nâng cấp Ethereum đều đi kèm với các xu hướng thị trường quan trọng. Nhìn lại lần nâng cấp gần đây nhất vào ngày 12 tháng 4 năm 2023, được gọi là bản nâng cấp Thượng Hải, các dự án liên quan đến Proof-of-Stake (PoS) có nhu cầu thị trường tăng lên.

Nếu chúng ta làm theo những kinh nghiệm trước đây, có thể sẽ có cơ hội định vị chiến lược trước đợt nâng cấp Dencun sắp tới.

Tuy nhiên, do sự phức tạp về mặt kỹ thuật liên quan đến nâng cấp Dencun, nó không thể được tóm tắt ngắn gọn như nâng cấp Thượng Hải bằng một cụm từ duy nhất như “Ethereum chuyển từ PoW sang PoS”. Sự phức tạp này khiến việc nắm bắt các trọng tâm để định vị chiến lược trở nên khó khăn.

Vì vậy, bài viết này nhằm mục đích 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 và dễ hiểu. Nó sẽ hướng dẫn người đọc về những điểm phức tạp của bản nâng cấp này, nêu bật các kết nối của nó với tính khả dụng của dữ liệu (DA), các giải pháp Lớp 2 và các khía cạnh liên quan khác.

01. EIP 4484

EIP-4844 nổi bật là đề xuất quan trọng nhất trong bản nâng cấp Dencun, đánh dấu một bước tiến đáng kể cho Ethereum trong hành trình mở rộng quy mô phi tập trung của nó.

Theo thuật ngữ của giáo dân, các giải pháp Ethereum Lớp 2 hiện tại yêu cầu gửi các giao dịch xảy ra trên Lớp 2 tới calldata của mạng chính Ethereum. Dữ liệu cuộc gọi này sau đó được các nút sử dụng để xác minh tính hợp lệ của các khối trên mạng Lớp 2.

Tuy nhiên, cách tiếp cận này đặt ra những thách thức, vì bất chấp nỗ lực nén dữ liệu giao dịch, khối lượng giao dịch đáng kể trên Lớp 2, nhân với chi phí lưu trữ cao trên mạng chính Ethereum, vẫn gây ra chi phí đáng kể cho các nút và người dùng Lớp 2. Chỉ riêng chi phí cao này đã có thể dẫn đến việc người dùng chuyển sang sidechain.

EIP-4844 giới thiệu một giải pháp tiết kiệm chi phí bằng cách thiết lập một loại vùng lưu trữ mới gọi là Đối tượng lớn nhị phân (BLOB). Nó giới thiệu một loại giao dịch mới được gọi là “Giao dịch mang theo BLOB” để thay thế dữ liệu giao dịch được lưu trữ trước đó trong calldata trước khi nâng cấp. Cách tiếp cận sáng tạo này giúp hệ sinh thái Ethereum Lớp 2 tiết kiệm chi phí gas.

Tại sao lưu trữ BLOB lại tiết kiệm chi phí？

Như chúng ta đều biết, hiệu quả chi phí thường đi kèm với sự đánh đổi. Lý do tại sao dữ liệu BLOB phải chịu chi phí thấp hơn so với dữ liệu lệnh gọi Ethereum thông thường có kích thước tương tự là vì Lớp thực thi Ethereum (EL) 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 các tham chiếu đến dữ liệu BLOB và dữ liệu thực tế của BLOB chỉ có thể được tải xuống và lưu trữ bởi Lớp đồng thuận Ethereum (CL, còn được gọi là nút báo hiệu). Yêu cầu về bộ nhớ và tính toán để lưu trữ dữ liệu BLOB thấp hơn đáng kể so với dữ liệu cuộc gọi Ethereum thông thường.

Hơn nữa, BLOB có một tính năng đặc biệt – nó chỉ có thể được lưu trữ trong một khoảng thời gian giới hạn (thường là khoảng 18 ngày) và không mở rộng vô hạn như kích thước của sổ cái Ethereum.

Thời hạn hiệu lực của việc lưu trữ BLOB

Ngược lại với sổ cái vĩnh viễn của blockchain, BLOB là bộ lưu trữ tạm thời có sẵn trong 4.096 kỷ nguyên, hoặc khoảng 18 ngày.

Sau khi hết hạn, hầu hết các máy khách đồ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ẽ vẫn còn trên mạng chính dưới dạng cam kết KZG và sẽ được lưu trữ vĩnh viễn trên mạng chính Ethereum.

Tại sao lại là 18 ngày? Đây là sự đánh đổi giữa chi phí lưu trữ và hiệu quả.

Trước hết, chúng ta phải xem xét những người hưởng lợi trực quan nhất của bản nâng cấp này, các bản tổng hợp lạc quan (chẳng hạn như Arbitrum và Optimism), bởi vì có khoảng thời gian Chứng minh gian lận 7 ngày trong Bản tổng hợp lạc quan. Dữ liệu giao dịch được lưu trữ trong Blob chính xác là những gì Optimistic Rollups cần khi khởi động một thử thách.

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 có thể truy cập được. Để đơn giản, cộng đồng Ethereum đã chọn 2 mũ 12 (4.096 kỷ nguyên có nguồn gốc từ 2^12 và một kỷ nguyên xấp xỉ 6,4 phút).

Giao dịch thực hiện BLOB và BLOB

Hiểu được mối quan hệ giữa hai điều này là rất quan trọng để hiểu được vai trò của BLOB đối với tính khả dụng của dữ liệu (DA).

Cái trước là đề xuất tổng thể của EIP-4484 và là một loại giao dịch mới, trong khi cái sau có thể được hiểu là vị trí lưu trữ tạm thời cho các giao dịch lớp 2.

Mối quan hệ giữa hai điều này có thể được hiểu là hầu hết dữ liệu ở phần trước (dữ liệu giao dịch lớp 2) được lưu trữ ở phần sau. Dữ liệu còn lại, tức là cam kết dữ liệu BLOB, sẽ được lưu trữ trong calldata của mạng chính. Nói cách khác, EVM có thể đọc được lời hứa.

Cam kết có thể được hình dung như việc xây dựng tất cả các giao dịch trong BLOB thành cây Merkle và sau đó chỉ có gốc Merkle, tức là Cam kết, mới có thể được truy cập bằng hợp đồng.

Điều này có thể đạt được một cách khéo léo: mặc dù EVM không thể biết nội dung cụ thể của BLOB nhưng hợp đồng EVM có thể xác minh tính xác thực của dữ liệu giao dịch bằng cách biết Cam kết.

02. Mối quan hệ giữa BLOB và lớp 2

Công nghệ cuộn lên đạt được tính khả dụng của dữ liệu (DA) bằng cách tải dữ liệu lên mạng chính Ethereum, nhưng nó không nhằm mục đích để các hợp đồng thông minh của L1 trực tiếp đọc hoặc xác minh những dữ liệu được tải lên này.

Mục đích của việc tải dữ liệu giao dịch lên L1 chỉ đơn giản là cho phép tất cả người tham gia xem dữ liệu.

Trước khi nâng cấp Dencun, như đã đề cập ở trên, Optimistic Rollups sẽ xuất bản dữ liệu giao dịch lên Ethereum dưới dạng calldata. Do đó, bất kỳ ai cũng có thể sử dụng những thông tin giao dịch này để tái tạo trạng thái và xác minh tính chính xác của mạng Lớp 2.

Không khó để nhận thấy rằng dữ liệu giao dịch tổng hợp cần phải rẻ, công khai và minh bạch. Calldata không phải là nơi tốt để lưu trữ dữ liệu giao dịch dành riêng cho Lớp 2 và Giao dịch mang BLOB được thiết kế riêng cho Rollup.

Tại thời điểm này, bạn có thể thắc mắc về tầm quan trọng của dữ liệu giao dịch.

Trên thực tế, dữ liệu giao dịch chỉ được sử dụng trong các tình huống cụ thể:

• Đối với Tổng hợp lạc quan, dựa trên giả định về độ tin cậy, có khả năng xảy ra sự không trung thực. Trong những trường hợp như vậy, hồ sơ giao dịch được tải lên bằng cách tổng hợp sẽ trở nên hữu ích, cho phép người dùng bắt đầu bằng chứng gian lận.
• Đối với ZK Rollup, bằng chứng không có kiến thức đã chứng minh rằng bản cập nhật trạng thái là chính xác. Việc tải lên dữ liệu chỉ nhằm mục đích cho phép người dùng tự tính toán trạng thái hoàn chỉnh. Khi nút Lớp 2 không thể hoạt động chính xác, cơ chế thoát thoát, yêu cầu cây trạng thái L2 hoàn chỉnh, sẽ được bật. Điều này sẽ được thảo luận trong phần cuối của bài viết này.

Điều này ngụ ý rằng việc sử dụng dữ liệu giao dịch thực tế theo hợp đồng là rất hạn chế. Ngay cả trong bằng chứng gian lận của Optimistic Rollup, chỉ cần có bằng chứng cho thấy dữ liệu giao dịch “tồn tại” tại một thời điểm cụ thể và không cần phải lưu trữ trước chi tiết của từng giao dịch trên mạng chính.

Bằng cách đặt dữ liệu giao dịch vào BLOB, mặc dù hợp đồng không thể truy cập được, hợp đồng mạng chính có thể lưu trữ cam kết của BLOB.

Nếu cơ chế chống gian lận cần một giao dịch cụ thể trong tương lai, việc cung cấp dữ liệu cho giao dịch đó, miễn là phù hợp, có thể thuyết phục hợp đồng và cung cấp dữ liệu giao dịch cho cơ chế chống gian lận.

Điều này không chỉ tận dụng tính công khai và minh bạch của dữ liệu giao dịch mà còn tránh được chi phí gas khổng lồ khi nhập trước tất cả dữ liệu vào hợp đồng.

Bằng cách chỉ ghi lại cam kết, dữ liệu giao dịch có thể được xác minh đồng thời tối ưu hóa chi phí một cách đáng kể. Đây là giải pháp upload dữ liệu giao dịch thông minh và hiệu quả bằng công nghệ Rollup.

Cần lưu ý rằng trong hoạt động thực tế của Dencun, cây Merkle tương tự như Celestia không được sử dụng để tạo ra cam kết mà sử dụng thuật toán KZG (Kate-Zaverucha-Goldberg, Polynomial Commitment).

So với Merkle tree proof, quá trình tạo KZG Proof tương đối phức tạp nhưng khối lượng xác minh nhỏ hơn và các bước xác minh cũng đơn giản hơn. Tuy nhiên, nhược điểm là nó yêu cầu cài đặt đáng tin cậy (ceremony.ethereum.org, hiện đã kết thúc) và không có khả năng ngăn chặn các cuộc tấn công điện toán lượng tử (Dencun sử dụng phương pháp Version Hash và các phương pháp xác minh khác có thể được thay thế nếu cần thiết).

Đối với dự án DA phổ biến hiện nay Celestia, nó sử dụng một biến thể của cây Merkle. Không giống như KZG, ở một mức độ nào đó, nó phụ thuộc vào tính toàn vẹn của các nút nhưng giúp hạ thấp ngưỡng tài nguyên tính toán giữa các nút, duy trì tính chất phi tập trung của mạng.

03. Cơ hội ở Dencun

Mặc dù EIP-4844 giảm chi phí và tăng hiệu quả cho Lớp 2 nhưng nó cũng làm tăng rủi ro bảo mật và mang đến những cơ hội mới.

Để hiểu tại sao, chúng ta cần quay lại cơ chế cửa thoát hiểm hay cơ chế rút lui cưỡng bức nói trên.

Khi nút Lớp 2 bị vô hiệu hóa, cơ chế này có thể đảm bảo rằng tiền của người dùng được trả lại mạng chính một cách an toàn. Điều kiện tiên quyết để kích hoạt cơ chế này là người dùng cần có được cây trạng thái hoàn chỉnh của Lớp 2.

Trong các trường hợp thông thường, người dùng chỉ cần tìm nút đầy đủ Lớp 2 để yêu cầu dữ liệu, tạo bằng chứng merkle và sau đó gửi nó tới hợp đồng mạng chính để chứng minh tính hợp pháp của việc rút tiền của họ.

Nhưng đừng quên rằng người dùng muốn kích hoạt cơ chế thoát hiểm để thoát L2 một cách chính xác vì các nút L2 đã hoạt động ác ý. Nếu điều này xảy ra, khả năng cao là họ sẽ không nhận được dữ liệu mong muốn từ các nút.

Đây là điều mà Vitalik thường gọi là một cuộc tấn công che giấu dữ liệu.

Trước EIP-4844, các bản ghi Lớp 2 cố định đã được ghi lại trên mạng chính. Khi không có nút Lớp 2 nào có thể cung cấp trạng thái ngoài chuỗi hoàn chỉnh, người dùng có thể tự triển khai một nút đầy đủ.

Nút đầy đủ này có thể lấy tất cả dữ liệu lịch sử được phát hành bởi trình sắp xếp thứ tự Lớp 2 trên mạng chính thông qua mạng chính Ethereum. Người dùng có thể xây dựng bằng chứng Merkle cần thiết và gửi bằng chứng cho hợp đồng trên mạng chính để hoàn tất việc rút tài sản L2 một cách an toàn.

Sau EIP-4844, dữ liệu Lớp 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ẽ tự động bị xóa.

Do đó, phương pháp trong đoạn trước để lấy toàn bộ cây trạng thái bằng cách đồng bộ hóa mạng chính không còn khả thi. Nếu bạn muốn có được cây trạng thái hoàn chỉnh của Lớp 2, bạn chỉ có thể dựa vào các nút mạng chính của bên thứ ba đã lưu trữ tất cả dữ liệu Ethereum BLOB (đáng lẽ phải được xóa tự động sau 18 ngày) hoặc các nút gốc của Lớp 2 (là hiếm).

Sau khi EIP-4844 đi vào hoạt động, người dùng sẽ rất khó có được cây trạng thái hoàn chỉnh của Lớp 2 một cách hoàn toàn đáng tin cậy.

Nếu không có cách ổn định để người dùng có được cây trạng thái Lớp 2, họ không thể thực hiện các hoạt động rút tiền bắt buộc trong các điều kiện khắc nghiệt. Do đó, EIP-4844 đã trở thành một thiếu sót về bảo mật cho Lớp 2 ở một mức độ nhất định.

Để bù đắp cho sự thiếu bảo mật này, chúng ta cần có một giải pháp lưu trữ không cần sự tin cậy với chu kỳ kinh tế tích cực. Lưu trữ ở đây chủ yếu đề cập đến việc lưu giữ dữ liệu trong Ethereum theo cách không cần tin cậy, khác với không gian lưu trữ trước đây vì có từ khóa “trustless” trong trường hợp này.

Ethstorage có thể giải quyết vấn đề không đáng tin cậy và đã nhận được hai vòng tài trợ từ Ethereum Foundation.

Trên thực tế, bản concept này thực sự có thể phát huy được tiềm năng mà bản nâng cấp Dencun mang lại và nó đáng để chúng ta chú ý.

Ý nghĩa trực quan nhất của Ethstorage là nó có thể kéo dài thời gian khả dụng của DA BLOB theo cách hoàn toàn phi tập trung, bù đắp cho những thiếu sót về bảo mật Lớp 2 sau EIP-4844.

Ngoài ra, hầu hết các giải pháp L2 hiện tại chủ yếu tập trung vào việc mở rộng sức mạnh tính toán của Ethereum, tức là tăng TPS. Tuy nhiên, nhu cầu lưu trữ một cách an toàn lượng lớn dữ liệu trên mạng chính Ethereum đã tăng lên, đặc biệt là 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 là rất lớn, bởi vì người dùng không chỉ sở hữu mã thông báo của hợp đồng NFT mà còn sở hữu hình ảnh trên chuỗi. Ethstorage có thể giải quyết các vấn đề tin cậy bổ sung đi kèm với việc lưu trữ những hình ảnh này cho bên thứ ba.

Cuối cùng, Ethstorage cũng có thể giải quyết các nhu cầu cơ bản của dApps phi tập trung. Hiện tại các giải pháp hiện có chủ yếu được lưu trữ bởi các máy chủ tập trung (có DNS). Thiết lập này làm cho các trang web dễ bị kiểm duyệt và các vấn đề khác như chiếm quyền điều khiển DNS, hack trang web hoặc sự cố máy chủ, bằng chứng là các sự cố như Tornado Cash.

Ethstorage vẫn đang trong giai đoạn thử nghiệm ban đầu và những người dùng lạc quan về triển vọng của con đường này có thể dùng thử.

Tuyên bố từ chối trách nhiệm:

1. Bài viết này được in lại từ [Biteye], Mọi bản quyền thuộc về tác giả gốc [Biteye]. Nếu có ý kiến phản đối việc tái bản này, vui lòng liên hệ với nhóm Gate Learn , họ sẽ xử lý kịp thời.
2. Tuyên bố miễn trừ trách nhiệm pháp lý: Các quan điểm và ý kiến trình bày trong bài viết này chỉ là của tác giả và không cấu thành bất kỳ lời khuyên đầu tư nào.
3. Việc dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài viết đã dịch đều bị cấm.