Giải thích chi tiết về đề xuất EIP-4844: giới thiệu "các giao dịch mang theo đốm màu" để giảm phí tổng hợp

Tiêu đề gốc: "Làm cách nào để giảm chi phí Lớp 2 xuống 100 lần? Tìm hiểu EIP-4844 trong một bài viết"

Tác giả gốc: Chuan Lin, AnT Capital

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, bao gồm các bản cập nhật cho giai đoạn The Surge sắp tới so với lộ trình trước đó được phát hành vào ngày 2 tháng 12 năm 2021. Chắc chắn là đáng chú ý nhất.

Như được hiển thị trong hình bên dưới, bản cập nhật ở giai đoạn này rõ ràng đã bổ sung thêm nhiều chi tiết hơn - chúng ta có thể thấy rõ rằng để đạt được "mở rộng Rollup cơ bản", The Cộng đồng Ethereum đề xuất EIP-4844: Proto-Danksharding. Đề xuất này sẽ được thực hiện từ tháng 5 đến đầu tháng 6 năm 2023, khi đó 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 của Ethereum L2. Sự 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.

Các vấn đề ban đầu liên quan đến Ethereum là gì? EIP-4844 sử dụng ý tưởng và giải pháp gì để 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.

Nếu bạn muốn cập nhật kiến trúc cơ bản của Ethereum và theo dõi các cuộc thảo luận của cộng đồng trong thời gian thực, vui lòng đừng bỏ lỡ bài viết này!

02 Văn bản

1. Nguồn gốc của EIP-4844: Nút thắt chi phí L2 do tính sẵn có của dữ liệu

1.1 Tình hình cơ bản hiện tại về tương tác dữ liệu L2 và L1

Hầu hết Ethereum L2 hiện tại sử dụng Rollup làm lộ trình kỹ thuật cơ bản. Vitalik thậm chí còn mô tả bản cập nhật của Ethereum là "Lộ trình lấy Rollup làm trung tâm", cho thấy Rollup về cơ bản đã thống nhất L2. Sông hồ.

(Để biết chi tiết, vui lòng tham khảo nghiên cứu trước đây của tác giả về L2: Bài viết dài 10.000 từ: Sáp nhập ETH, đánh giá và quan điểm về Layer2 )

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, kết quả thực hiện và dữ liệu giao dịch bản thân chúng được nén và gửi trở lại L1. , để người khác có thể xác minh tính chính xác của kết quả giao dịch. Rõ ràng, nếu người khác không đọc được dữ liệu thì việc xác minh không thể hoàn thành. Vì vậy, việc cho phép người khác lấy bản gốc là rất quan trọng dữ liệu của giao dịch hay còn gọi là “data Availability” (Tính khả dụng của dữ liệu).

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, khi Ethereum được thiết kế ban đầu, Calldata chỉ là một tham số của lệnh gọi hàm hợp đồng thông minh và đó là dữ liệu mà tất cả các nút phải tải xuống một cách đồng bộ. Nếu Calldata mở rộng, nó sẽ gây ra tải trọng cao cho các nút mạng Ethereum, do đó chi phí của Calldata tương đối đắt. Đây cũng là một yếu tố chính trong phí L2 hiện tại.

1.2 Ý tưởng cải thiện vấn đề

Bạn đọc có thể suy nghĩ xem, nếu được yêu cầu thiết kế một phương án tối ưu hóa cho vấn đề này thì 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 dữ liệu nén giao dịch của L2 được tải lên chỉ để cho phép người khác tải xuống và xác minh và không cần phải được thực thi bởi L1. Lý do khiến chi phí Calldata cao là vì với tư cách là một tham số của lệnh gọi hàm, nó có thể được thực thi bởi L1 theo mặc định, do đó nó cần được đồng bộ hóa bởi các nút trong toàn bộ mạng.

Điều này tạo ra sự không khớp: ví dụ: rõ ràng là tôi chỉ muốn chuyển dữ liệu sang đĩa mạng để những người khác có nhu cầu có thể tải xuống; kết quả là bạn đã đồng bộ hóa dữ liệu của tôi dữ liệu được phát só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 quá trình tải xuống trong một thời gian giới hạn, sau đó lại tính cho tôi 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.

Làm thế nào để cải thiện 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 những người khác có nhu cầu có thể truy cập và tải xuống trong một khoảng thời gian nhất định và không cần phải đồng bộ hóa toàn bộ mạng. Trên thực tế, điều này cũng đã được nhiều thành viên trong cộng đồng kỹ thuật Ethereum nghĩ đến.

Những cải tiến của 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 Blob

Nếu có thể tóm tắt những gì EIP-4844 đã làm trong một câu thì đó sẽ là: giới thiệu một loại giao dịch mới "giao dịch mang blob". Blob là những gì đã được đề cập ở trên, Một loại dữ liệu đặc biệt được thiết kế để truyền dữ liệu L2.

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

2.1 Blob ontology: một "khối dữ liệu lớn" 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 theo nghĩa đen là "khối dữ liệu lớn nhị phân", được thiết kế để mang dữ liệu gốc của dữ liệu nén Giao dịch L2 tương đương với việc đưa dữ liệu trong L2 trước đây vào Calldata và bây giờ đưa 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 125KB.

Blobs được lưu trữ bởi các nút trong 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 đọc được như Calldata

Nó có vòng đời và sẽ bị xóa sau 30 ngày

(Nếu bạn chưa quen với mật mã và đại số trừu tượng thì hiểu bản thân mức độ blob này là đủ)

Chi tiết hơn, bản thân Blob là một vectơ bao gồm 4096 phần tử. Mỗi chiều của vectơ này là một số có thể rất lớn, dao động từ 0 đến 52435875175126190479447740508185965837690552500527637822603658699938581184513 - con số rất lớn này là số nguyên tố, liên quan đến thuật toán mật mã đường cong elip.

Các số trong mỗi chiều của vectơ này có thể được coi là các hệ số của đa thức trường hữu hạn bậc không lớn hơn 4096, chẳng hạn như i-th The số thứ nguyên là hệ số đứng trước w^i, trong đó w là 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, cần giải thích một khái niệm: Tải trọng thực thi. Sau khi sáp nhập Ethereum, Lớp Consensys và Lớp thực thi đã được tách ra, chịu trách nhiệm cho hai chức năng chính: lớp trước chịu trách nhiệm về sự đồng thuận PoS và lớp sau thực thi EVM. Tải trọng thực thi có thể được coi đơn giản là một giao dịch L1 thông thường trong lớp EL.

(Nguồn: OP in Paris: Protolambda của OP Lab hướng dẫn chúng tôi về EIP-4844)

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 thân xe máy và xe mô tô sidecar ( Mối quan hệ giữa Sidecar) là thế này: (Cái bên trái là Sidecar của xe máy)

Sidecar là một trò lố chính thức. Ý nghĩa của nó thực ra 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 độ nhất định và có tính độc lập đáng kể.

Như được hiển thị 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ề ẩn dụ này:

(Nguồn: OP ở Paris: Protolambda của OP Lab hướng dẫn chúng tôi về EIP-4844)

Đầu tiên, Trình sắp xếp L2 xác định giao dịch và truyền kết quả giao dịch cũng như các chứng chỉ liên quan (phần màu vàng) và các gói dữ liệu (phần Blob, phần màu xanh) đến nhóm giao dịch L1

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

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

Hình dưới đây minh họa vòng đời của Blob từ một góc độ khác. Chúng ta có thể thấy rõ 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 lớp đồng thuận và nó có vòng đời khác.

(Nguồn: OP ở Paris: Protolambda của OP Lab hướng dẫn chúng tôi về EIP-4844)

Do đó, không khó hiểu tại sao EVM không thể đọc trực tiếp Blob, tức là hợp đồng thông minh L1: tất cả những gì có thể đọc được đều được chuyển cho những thứ đi đến lớp thực thi, vì Blob chỉ nằm trong lớp đồng thuận nên chắc chắn nó không có chức năng này. Trên thực tế, sự tách biệt này là lý do tại sao chi phí Rollup có thể giảm xuống.

2.3 Bộ nhớ 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í nên nó sẽ mang đến một thị trường phí mới độc lập với phí L1 Gas, đây cũng chính 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 nhiều lần. Để biết chi tiết, vui lòng xem các cuộc thảo luận và cập nhật có 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ữ dữ liệu này trong một khoảng thời gian ngắn, làm thế nào để đạt được khả năng lưu trữ lâu dài? Về vấn đề này, Vitalik cho biết thực tế có rất nhiều giải pháp. Bởi vì giả định bảo mật ở đây không cao nên nó là "mô hình tin cậy 1 trong N" và chỉ ai đó mới 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 Mỹ mỗi TB, 2,5TB dữ liệu lưu trữ mỗi năm Đó chỉ là một vấn đề nhỏ đối với những ai quan tâm. 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 được giới thiệu Loại giao dịch mới Giao dịch mang Blob 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 triển khai Full Danksharding tiếp theo.

Ở 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 hướng tới Mô hình đa thị trường chiều. .

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

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

Hiện tại, EIP-4844 Nó rõ ràng đã được đưa vào chuỗi nâng cấp Ethereum Thượng Hải, theo lịch trình hiện tại do các thành viên cộng đồng đưa ra, 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. Concept phiên bản đầy đủ của Danksharing như trong hình bên dưới. Mỗi nút có thể trực tiếp xác minh theo thời gian thực về 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.

(Nguồn: Câu hỏi thường gặp Câu hỏi Viết bởi Vitalik Buterin)

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia