Tác giả gốc | Taiko Labs
Biên soạn bởi | Odaily Planet Daily ( @OdailyChina )
Người dịch | Dingdang ( @XiaMiPP )
Lưu ý của biên tập viên: Bạn có còn nhớ sự phấn khích về việc phân mảnh không? Vào thời điểm đó, nó là mật khẩu giao thông trong ngành công nghiệp blockchain. Kết quả là, Ethereum đã suy nghĩ một cách bình tĩnh và từ bỏ củ khoai tây nóng này. Ngày nay, Rollup cục bộ đã trở lại. Bằng cách thực hiện các hợp đồng được biên dịch trước (EXECUTE Precompile) và tối ưu hóa cấu trúc xử lý khối Ethereum, Rollup không chỉ an toàn hơn và linh hoạt hơn mà còn mang lại sự mở rộng theo chiều ngang lớn cho Ethereum L1, mở đường cho các bằng chứng thời gian thực trong tương lai.
Sau đây là nội dung gốc do Taiko Lab phát hành và được Odaily Planet Daily dịch. Vì bài viết này có tính kỹ thuật cao nên để đảm bảo bài viết dễ đọc, Odaily đã xóa một số nội dung phù hợp và trình bày bài viết một cách rõ ràng và dễ hiểu nhất có thể.
giới thiệu
Phân mảnh là chủ đề nóng trong giai đoạn 2017 - 2020. Vào thời điểm đó, nhiều nhóm khác nhau như Harmony, Zilliqa và Elrond đã triển khai công nghệ phân mảnh trong blockchain của họ. Về cơ bản, công nghệ này chia mạng thành nhiều chuỗi nhỏ hơn chạy song song (gọi là “phân đoạn”) có thể xử lý các giao dịch đồng thời như một cách đơn giản để mở rộng quy mô hệ thống phân tán.
Sharding cũng là một chủ đề được cộng đồng thảo luận nghiêm túc trong kỷ nguyên Ethereum 2.0. Tuy nhiên, cuối cùng Ethereum đã quyết định không áp dụng giải pháp phân mảnh, chủ yếu dựa trên bốn thách thức sau:
1. Sự khác biệt về tư duy
Trong mô hình phân mảnh này, bản thân giao thức sẽ áp dụng số lượng phân mảnh chính xác từ trên xuống dưới. Các phân đoạn này là những chuỗi đơn chạy theo một mẫu được xác định trước, không có khả năng lập trình và về cơ bản chỉ là nhiều bản sao giống hệt nhau của L1 (chuỗi khối lớp 1).
2. An ninh lạc quan
Vào thời điểm đó, để đảm bảo tính trung thực của các mảnh vỡ, cần có các bằng chứng lạc quan, nhưng công nghệ không kiến thức (ZK) vẫn chưa hoàn thiện. Điều này có nghĩa là logic chống gian lận phải được quản lý một cách có hệ thống trên chuỗi.
3. Sự phức tạp
Việc triển khai phân mảnh ở lớp L1 làm tăng đáng kể độ phức tạp của giao thức, đặc biệt là trong việc quản lý hệ thống xác nhận trước nhanh và hệ thống xác nhận cuối chậm hơn, cũng như phối hợp các phân mảnh có các cấp độ bảo mật khác nhau.
4. Sự đồng thuận quá tải
Việc theo đuổi khả năng mở rộng cao hơn ở lớp L1 có thể làm tăng rủi ro tập trung hóa. Nếu phân mảnh được triển khai ở lớp cơ sở, rủi ro này có thể ảnh hưởng đến toàn bộ giao thức, thay vì chỉ giới hạn ở một L2 (giải pháp mở rộng lớp thứ hai) duy nhất như hiện nay.
Native Rollup về cơ bản có thể được coi là sự trở lại của phân mảnh, nhưng lần này thì khác. Chúng ta đã rút ra được bài học và được trang bị tốt hơn về công nghệ và kinh nghiệm.
Local Rollup là gì?
Hãy nhớ rằng Rollup bao gồm các mô-đun Dữ liệu, Trình tự và Thực thi. Local Rollup sử dụng trực tiếp môi trường thực thi của Ethereum (Môi trường thực thi) làm mô-đun thực thi. Chúng ta có thể gọi nó là phân đoạn thực thi có thể lập trình L1.
Việc hiểu cách sử dụng môi trường thực thi L1 dưới dạng Rollup có thể hơi phức tạp. Để sử dụng môi trường thực thi L1 trong Rollup, chúng ta cần có khả năng thực thi một EVM khác bên trong EVM (EVM bên trong EVM). Do đó, L1 cần có khả năng nhận biết sự chuyển đổi trạng thái của Rollup cục bộ trong mỗi khối. Để đạt được điều này, chúng ta cần một <hợp đồng biên dịch trước> để cung cấp hỗ trợ.
THỰC HIỆN hợp đồng đã biên dịch trước
Các hợp đồng được biên dịch trước EXECUTE cung cấp một cơ chế cho phép một ngữ cảnh EVM xác minh kết quả thực hiện của một ngữ cảnh EVM khác trong khi vẫn duy trì cùng các quy tắc thực hiện và logic chuyển đổi trạng thái.
Hợp đồng được biên dịch trước chấp nhận ba tham số đầu vào:
pre_state: trạng thái gốc 32 byte trước khi thực thi
post_state: trạng thái gốc 32 byte sau khi thực thi
witness_trace: theo dõi thực hiện, bao gồm bằng chứng truy cập trạng thái và giao dịch
Cốt lõi của hợp đồng được biên dịch trước là khẳng định : nó xác minh xem việc thực thi theo dõi từ pre_state có thể lấy được post_state hay không. Nếu hàm chuyển đổi trạng thái hợp lệ, hợp đồng được biên dịch trước sẽ trả về giá trị true.
Dấu vết thực thi cần phải có sẵn cho tất cả trình xác thực (dưới dạng blob hoặc calldata) để trình xác thực có thể thực hiện lại phép tính và xác minh tính chính xác của quá trình chuyển đổi trạng thái. Điều đáng chú ý là hợp đồng được biên dịch trước này không sử dụng bằng chứng làm đầu vào. Điều này có nghĩa là bản thân giao thức không áp dụng bất kỳ hệ thống bằng chứng cụ thể nào mà thay vào đó truyền bá các loại bằng chứng khác nhau thông qua các kênh Gossip của mạng p2p.
Mô hình thanh toán gas
Ethereum có tài nguyên tính toán hạn chế nên cơ chế Gas được sử dụng để quản lý các tài nguyên này. Hợp đồng được biên dịch trước EXECUTE triển khai mô hình thanh toán Gas để quản lý tài nguyên máy tính:
Chi phí cơ bản : Hợp đồng được biên dịch trước sẽ tính một khoản phí Gas cố định là EXECUTE_GAS_COST , cộng với Gas được sử dụng theo quỹ đạo thực hiện nhân với giá Gas hiện tại.
Giới hạn khí tích lũy : Tương tự như cơ chế EIP-1559, cơ chế này quản lý và định giá tổng lượng khí tiêu thụ của tất cả các cuộc gọi EXECUTE trong khối L1:
EXECUTE_CUMULATIVE_GAS_LIMIT: Giới hạn Gas tối đa cho tất cả các lệnh gọi EXECUTE trong một khối.
EXECUTE_CUMULATIVE_GAS_TARGET: Mục tiêu sử dụng Gas để định giá hiệu quả.
Mô hình này tương tự như cơ chế định giá theo tính khả dụng của dữ liệu (DA) trong blob.
Điều quan trọng cần nhớ là các khái niệm về Rollup cục bộ và SNARK hóa L1 thường bị nhầm lẫn. L1 được SNARK hóa là phương pháp mở rộng theo chiều dọc giúp cải thiện hiệu suất L1 bằng cách loại bỏ các hạn chế của Gas thông qua thực thi được SNARK hóa (như zkEVM) và sự đồng thuận (như Beam). Rollup cục bộ là L1 có khả năng mở rộng theo chiều ngang , có thể tạo bất kỳ số lượng bản sao EVM nào theo cách có thể lập trình để đạt được khả năng mở rộng cao hơn.
Tại sao Rollup cục bộ lại có lợi thế hơn?
1. Bảo mật
Thiết kế Rollup hiện tại yêu cầu Hội đồng bảo mật phải cập nhật chuỗi để giải quyết các lỗ hổng tiềm ẩn. Rollup cục bộ dựa vào <Social Consensus> của Ethereum để quản lý. Người vận hành không cần phải lo lắng về lỗ hổng bảo mật vì cộng đồng Ethereum sẽ chịu trách nhiệm bảo trì và sửa lỗi.
2. Đơn giản hóa khả năng kết hợp đồng bộ L1
Rollup dựa trên L1 gần đạt được khả năng kết hợp đồng bộ, nhưng yêu cầu các khối L1 và L2 phải được xây dựng đồng thời bởi cùng một trình xây dựng. Một Rollup cục bộ có thể trực tiếp xác minh trạng thái của một Rollup cục bộ khác thông qua hợp đồng được biên dịch trước EXECUTE mà không cần thêm giả định tin cậy nào.
3. Khả năng tương thích về phía trước
Khi L1 EVM phát triển, Rollup cục bộ sẽ tự động kế thừa mọi cải tiến mà không cần phải điều chỉnh riêng, do đó đạt được khả năng tương thích lâu dài với lộ trình phát triển của Ethereum.
Triển khai ban đầu: Thực hiện lại
Trong bối cảnh triển khai cục bộ, việc thực hiện lại được coi là triển khai ban đầu. Thực hiện lại đề cập đến việc trình xác thực trực tiếp thực hiện theo dõi giao dịch để xác minh xem quá trình chuyển đổi trạng thái của Rollup cục bộ có hợp lệ hay không, thay vì dựa vào bằng chứng SNARK. Nếu EXECUTE_CUMULATIVE_GAS_LIMIT được giữ ở mức nhỏ, trình xác thực vẫn có thể quản lý được việc thực thi lại này.
Tối ưu hóa thực hiện: Kiểm chứng thời gian thực
Ở chế độ thực hiện lại, trình xác thực phải tự xử lý tất cả các giao dịch, với thông lượng bị giới hạn bởi tham số EXECUTE_CUMULATIVE_GAS_LIMIT . Bằng chứng thời gian thực có thể cải thiện đáng kể giới hạn này vì người xác thực chỉ cần xác minh bằng chứng mà không cần thực hiện lại tất cả các giao dịch.
Khi ngành công nghiệp đang nhanh chóng chuyển sang chứng thực theo thời gian thực, chúng ta cần thực hiện các bước để mở rộng cửa sổ chứng thực cho các bản Rollup cục bộ . Để có thêm thời gian chứng minh, cấu trúc xử lý khối Ethereum hiện tại cần được điều chỉnh.
Làm thế nào để gia hạn thời gian chứng nhận?
Luồng xử lý khối Ethereum hiện tại
Theo cấu trúc hiện tại, tất cả các bước sau đây phải được hoàn thành trong vòng 12 giây (một giai đoạn sau mỗi 4 giây) trước khi vào khối tiếp theo:
Giao dịch được đề xuất của Block N
Trước khi có thể xác minh/xác nhận một khối, khối đó phải được hoàn thành:
Thực hiện tất cả các giao dịch
Tính toán các thay đổi trạng thái
Tính toán trạng thái gốc (stateRoot)
Tính toán biên lai giao dịch và nhật ký
Chỉ sau khi hoàn tất tất cả các bước trên thì khối mới có thể được xác minh và xác nhận.
Theo quy trình hiện tại, bằng chứng phải được hoàn thành trong vòng 4 giây nếu muốn đạt được khả năng kết hợp đồng bộ với L1. Tuy nhiên, công nghệ ZK vẫn chưa hoàn thiện và không thể tạo ra bằng chứng về các khối Ethereum trong vòng 4 giây, do đó chúng ta cần đưa tính linh hoạt hơn vào quy trình chứng minh.
Để cung cấp cho Rollup cục bộ nhiều thời gian kiểm chứng hơn, chúng tôi cần điều chỉnh cấu trúc xử lý khối hiện tại của Ethereum. Ví dụ:
Trì hoãn tính toán state_root: Xóa tính toán state_root khỏi đường dẫn quan trọng và thực hiện tính toán trong thời gian nhàn rỗi của trình xác thực.
Thực hiện trì hoãn: Tách xác minh khối khỏi thực hiện giao dịch, tối ưu hóa hiệu quả đồng thuận đồng thời cung cấp thêm thời gian cho việc tạo bằng chứng.
Câu hỏi thường gặp
Taiko sẽ sử dụng loại bằng chứng nào?
Không có một loại bằng chứng nào được sử dụng. Chúng tôi muốn có sự đa dạng giữa người chứng minh và khách hàng. Người xác minh có thể chủ động quyết định phương pháp chứng minh nào sẽ sử dụng dựa trên sự lựa chọn của riêng mình.
Xem EthProofs để biết nhiều loại bằng chứng khác nhau.
Ai là người tạo ra bằng chứng?
Bất cứ ai cũng có thể tạo ra bằng chứng. Ngay cả khi chỉ có một người chứng thực, chuỗi vẫn có thể hoạt động bình thường. Vẫn còn một câu hỏi chưa có lời giải: làm thế nào để khuyến khích người chứng minh ở cấp độ giao thức.
Liệu có sự đồng thuận giữa các bằng chứng không?
Sẽ không. Bằng chứng không được thống nhất trên chuỗi mà được truyền đi ngoài chuỗi. Tất cả những gì cần thiết trong mạng lưới là sự đồng thuận rằng bằng chứng hợp lệ tồn tại ở đâu đó.
