Tác giả gốc: Chuan Lin

tiêu đề cấp đầu tiên

01. Giới thiệu

Vitalik đã phát hành lộ trình Ethereum cập nhật vào ngày 5 tháng 11 năm 2022. So với lộ trình trước đó được phát hành vào ngày 2 tháng 12 năm 2021, bản cập nhật sắp tới của giai đoạn Surge chắc chắn là đáng chú ý nhất.

Như thể hiện trong hình bên dưới, bản cập nhật ở giai đoạn này rõ ràng sẽ bổ sung thêm nhiều chi tiết hơn - chúng ta có thể thấy rõ rằng để đạt được "sự mở rộng Rollup cơ bản", cộng đồng Ethereum đã đề xuất EIP-4844: Proto-Danksharding. Đề xuất này sẽ được triển khai từ tháng 5 đến đầu tháng 6 năm 2023, lúc đó chi phí Rollup sẽ giảm 100 lần, điều này sẽ tối ưu hóa đáng kể trải nghiệm người dùng Ethereum L2. Một tối ưu hóa lớn như vậy chắc chắn sẽ trở thành tâm điểm thảo luận và chú ý trong cộng đồng Web3.

Đâu là vấn đề liên quan đến Ethereum? EIP-4844 sử dụng ý tưởng và giải pháp nào để giải quyết vấn đề này? Bài viết này sẽ giúp bạn hiểu EIP-4844 một cách chính xác.

tiêu đề cấp đầu tiên

02. Văn bản

1. Nguồn gốc của EIP-4844: Tắc nghẽn phí L2 do tính khả dụng của dữ liệu

1.1 Thực trạng cơ bản về tương tác dữ liệu giữa L2 và L1

Hiện tại, hầu hết Ethereum L2 đều sử dụng Rollup làm lộ trình kỹ thuật cơ bản, Vitalik thậm chí còn mô tả việc cập nhật Ethereum bằng "Lộ trình Rollup-Centric", điều này cho thấy Rollup về cơ bản đã thống trị đấu trường L2.

Nguyên tắc cơ bản của hoạt động Rollup là thực hiện một gói giao dịch bên ngoài chuỗi chính Ethereum, sau khi thực hiện, bản thân kết quả thực hiện và dữ liệu giao dịch sẽ được nén và gửi lại L1 để người khác có thể xác minh tính đúng đắn của kết quả giao dịch.Rõ ràng, nếu không ai khác có cách đọc dữ liệu, thì việc xác minh không thể thực hiện được. Vì vậy, điều rất quan trọng là cung cấp dữ liệu giao dịch thô cho người khác, nó còn được gọi là "Tính khả dụng của dữ liệu".

Tuy nhiên, bị giới hạn bởi kiến ​​trúc hiện tại của Ethereum, dữ liệu được truyền từ L2 đến L1 được lưu trữ trong Calldata của giao dịch.Tuy nhiên, Calldata chỉ là một tham số của lệnh gọi chức năng hợp đồng thông minh khi Ethereum được thiết kế ban đầu và đó là dữ liệu mà tất cả các nút phải tải xuống đồng bộ. Nếu Calldata mở rộng sẽ gây ra tải trọng cao cho các nút mạng Ethereum, vì vậy chi phí của Calldata tương đối đắt đỏ. Đây cũng là yếu tố chính góp phần vào phí L2 hiện nay.

1.2 Ý tưởng cải tiến cho vấn đề

Độc giả có thể muốn nghĩ về nó, nếu bạn được yêu cầu thiết kế một kế hoạch tối ưu hóa cho vấn đề này, bạn sẽ cải tiến theo hướng nào?

Trên thực tế, chúng ta có thể quan sát thấy rằng việc tải lên dữ liệu nén giao dịch của L2 chỉ để cho phép người khác tải xuống và xác minh dữ liệu đó chứ không cần L1 thực thi. Lý do khiến chi phí Calldata cao là do một tham số của lời gọi hàm có thể được thực hiện bởi L1 theo mặc định, vì vậy nó cần được đồng bộ hóa bởi các nút trong toàn mạng.

Điều này tạo ra sự không phù hợp: ví dụ: tôi chỉ muốn chuyển dữ liệu sang đĩa mạng để những người khác cần có thể tải xuống trong một khoảng thời gian; cuối cùng, bạn đã biến dữ liệu của tôi thành Đồng bộ hóa phát rộng trên toàn mạng mà tôi không cần, buộc mọi người phải hoàn tất việc tải xuống trong một thời gian giới hạn, rồi đến lượt tôi lại tính một khoản phí cao cho dịch vụ này. Điều này rõ ràng là không phù hợp và cần cải thiện.

Vậy làm thế nào để cải thiện?Chúng ta có thể thiết kế một kiểu dữ liệu riêng cho dữ liệu được truyền từ L2 và tách nó khỏi Calldata của L1. Loại dữ liệu này chỉ cần người khác có nhu cầu sử dụng trong một khoảng thời gian nhất định là có thể truy cập và tải xuống, không cần phải đồng bộ hóa toàn mạng.Trên thực tế, điểm này cũng đã được nhiều thành viên trong cộng đồng kỹ thuật Ethereum nghĩ đến.

Việc cải tiến EIP-4844 thực sự được thực hiện xung quanh bối cảnh này.

2. Cốt lõi của EIP-4844: giao dịch với các đốm màu

Nếu bạn sử dụng một câu để tóm tắt những gì EIP-4844 làm, thì đó là: giới thiệu"Giao dịch với đốm màu"Loại giao dịch mới này. Blob là kiểu dữ liệu được thiết kế đặc biệt cho việc truyền dữ liệu L2 đã đề cập ở trên.

Do đó, nếu bạn hiểu rõ chi tiết về blob, có thể nói rằng bạn đã hiểu cơ bản về EIP-4844.

2.1 Blob ontology: một "khối dữ liệu lớn" được sử dụng để đặt dữ liệu nén L2, được lưu trữ trong các nút của lớp đồng thuận

Cái tên Blob thực chất là tên viết tắt của Binary Large Object, dịch sát nghĩa là "khối dữ liệu lớn nhị phân". Nó được thiết kế để mang dữ liệu nén của các giao dịch ban đầu của L2, tương đương với việc đưa dữ liệu của L2 vào Calldata trước đây, và bây giờ đưa nó vào Blob. So với Calldata, kích thước dữ liệu của Blob có thể rất lớn, lên tới 125 KB.

Các đốm màu được lưu trữ bởi các nút của lớp đồng thuận, thay vì được tải trực tiếp lên chuỗi chính như Calldata, điều này cũng mang lại hai tính năng cốt lõi của Blobs:

• EVM không thể đọc được như Calldata

• Có thời gian tồn tại và sẽ bị xóa sau 30 ngày

Chi tiết hơn, bản thân Blob là một vectơ (Vector) bao gồm 4096 phần tử. Mỗi chiều của vectơ này là một số rất lớn, có phạm vi dãy từ 0 đến 52435875175126190477474050818596525252527637826036999938584513 -số rất lớn này là số chất lượng, nó có hình bầu dục và hình bầu dục -thuật toán liên quan đến thuật toán Curve.

Và số lượng mỗi chiều của vectơ này có thể được coi là mỗi hệ số của đa thức trường hữu hạn không cao hơn bậc 4096. Ví dụ, số lượng của chiều thứ i là hệ số đứng trước w^i, trong đó w là một hằng số và thỏa mãn w^4096 = 1. Cấu trúc này được thiết kế để tạo thuận lợi cho việc tạo ra các cam kết đa thức KZG.

2.2 Thiết kế kiến ​​trúc liên quan đến Blob: Sidecar

Trước khi hiểu kiến ​​trúc Blob, một khái niệm cần được giải thích: Tải trọng thực thi. Sau khi hợp nhất Ethereum, Lớp Consensys và Lớp thực thi đã được tách ra, chịu trách nhiệm về hai chức năng chính: lớp trước chịu trách nhiệm về sự đồng thuận của PoS và lớp sau thực thi EVM. Tải trọng thực thi có thể được coi đơn giản như một giao dịch L1 thông thường trong lớp EL.

Sự tích hợp của Blob và kiến ​​trúc Ethereum hiện tại có thể được so sánh với mối quan hệ giữa thân xe máy và thùng xe gắn máy (Sidecar), như thế này: (cái bên trái là thùng phụ của xe máy)

Sidecar (xe gắn máy phụ) là một phép ẩn dụ chính thức. Ý nghĩa của nó thực sự là mặc dù hoạt động của Blob phụ thuộc vào chuỗi chính, nhưng nó cũng song song với chuỗi chính ở một mức độ nào đó và có sự độc lập đáng kể.

Như thể hiện trong hình bên dưới, chúng ta hãy xem qua quy trình thực thi liên quan đến Blob để hiểu rõ hơn về phép ẩn dụ này:

• Đầu tiên, L2 Sequencer xác định giao dịch và truyền kết quả của giao dịch cũng như các bằng chứng liên quan (phần màu vàng) và các gói dữ liệu (Blob, phần màu xanh) đến nhóm giao dịch của L1

• Nút L1 (Beacon Proposer) nhìn thấy giao dịch, nó sẽ thực hiện giao dịch có liên quan trong đề xuất khối mới (Beacon Block) và phát nó; nhưng khi phát, nó sẽ tách Blob và để nó trong lớp đồng thuận CL, không đặt nó vào một khối mới trong lớp thực thi

• Các nút L1 khác (Beacon Peer) sẽ nhận được các đề xuất khối mới và kết quả giao dịch. Nếu cần trở thành người xác thực L2, họ có thể truy cập Blobs Sidecar để tải xuống dữ liệu liên quan.

Hình bên dưới là hình minh họa vòng đời của Blob từ một góc nhìn khác, chúng ta có thể thấy rõ ràng rằng dữ liệu blob sẽ không được tải lên chuỗi chính L1 mà chỉ tồn tại trong các nút của lớp đồng thuận và nó có vòng đời khác .

Vì vậy,Không khó để hiểu tại sao EVM không thể đọc trực tiếp Blob, nghĩa là hợp đồng thông minh L1: những gì có thể đọc được là những gì được chuyển đến lớp thực thi. không có chức năng như vậy bây giờ.Trên thực tế, sự tách biệt này là lý do tại sao có thể giảm chi phí Tổng số.

2.3 Lưu trữ Blob: Thị trường phí mới

Như đã đề cập trước đó, dữ liệu Blob sẽ được lưu trữ trong các nút lớp đồng thuận và có vòng đời. Nhưng rõ ràng dịch vụ này không miễn phí, vì vậy nó sẽ mang lại một thị trường phí mới độc lập với phí L1 Gas, cũng là Thị trường phí đa chiều do Vitalik chủ trương. Các chi tiết liên quan của Thị trường phí này vẫn đang được cải thiện lặp đi lặp lại. Để biết chi tiết, vui lòng tham khảo các cuộc thảo luận và cập nhật liên quan trên Github: https://github.com/ethereum/EIPs/pull/5707

Ngoài ra, nếu cấp nút chỉ có thể lưu trữ những dữ liệu này trong một thời gian ngắn, làm thế nào để đạt được lưu trữ lâu dài? Về vấn đề này, Vitalik cho biết thực tế có nhiều giải pháp. Bởi vì giả định bảo mật ở đây không yêu cầu cao, nó là "mô hình tin cậy 1 trong số N", miễn là ai đó có thể hoàn thành việc lưu trữ dữ liệu thực. Vào thời điểm mà phần cứng lưu trữ lớn chỉ có giá 20 đô la cho mỗi TB, 2,5 TB dung lượng lưu trữ dữ liệu mỗi năm là một vấn đề nhỏ đối với những người muốn. Ngoài ra, nhiều giải pháp lưu trữ phi tập trung khác cũng sẽ là một lựa chọn, nhưng Vitalik không đề cập đến các dự án cụ thể ở đây.

3. Tác động của EIP-4844

Ở cấp độ kiến ​​trúc, EIP-4844 giới thiệu một loại giao dịch mới, Giao dịch mang Blob, đây là lần đầu tiên Ethereum xây dựng một lớp dữ liệu riêng cho L2 và đây cũng là bước đầu tiên trong quá trình hiện thực hóa Full Danksharding.

Ở cấp độ mô hình kinh tế, EIP-4844 sẽ giới thiệu Thị trường phí mới cho các đốm màu, đây cũng sẽ là bước đầu tiên để Ethereum tiến tới Thị trường đa chiều.

Ở cấp độ trải nghiệm người dùng, cảm nhận trực quan nhất của người dùng là việc giảm đáng kể phí L2. Cải tiến quan trọng này ở lớp dưới cùng sẽ tạo nền tảng quan trọng cho sự bùng nổ của L2 và lớp ứng dụng của nó.

4. Triển vọng sau EIP-4844: Danksharding hoàn toàn

hiện tại,EIP-4844 rõ ràng đã được đưa vào chuỗi nâng cấp Ethereum Thượng Hải, theo thời gian biểu được đưa ra bởi các thành viên cộng đồng hiện tại, dự kiến ​​sẽ hoàn thành từ tháng 5 đến đầu tháng 6 năm sau.

Còn EIP-4844 chỉ là "Proto-Danksharding", nghĩa là nguyên mẫu của Danksharding. Ý tưởng về phiên bản đầy đủ của Danksharing được thể hiện trong hình bên dưới Mỗi nút có thể trực tiếp xác minh tính chính xác của dữ liệu L2 thông qua Lấy mẫu tính khả dụng của dữ liệu. Điều này sẽ cải thiện hơn nữa tính bảo mật và hiệu suất của L2.