Phân tích Rollup từ góc nhìn của Celestia: 6 biến thể của việc chống kiểm duyệt

Tác giả: NashQ, Nhà nghiên cứu Celestia; Trình biên dịch: Faust, Geek Web3

Ghi chú của người dịch: Để làm cho mô hình Rollup dễ hiểu và dễ phân tích hơn, nhà nghiên cứu Celestia NashQ đã chia trình sắp xếp thứ tự của Rollup (Sequencer) thành hai thực thể logic - trình tổng hợp và trình tạo tiêu đề. Đồng thời, ông chia quá trình đặt hàng giao dịch thành ba bước hợp lý: đưa vào, đặt hàng và thực hiện.

Dưới sự hướng dẫn của tư duy phân tích này, sáu biến thể quan trọng của Rollup chủ quyền trở nên rõ ràng và dễ hiểu hơn. NashQ đã thảo luận chi tiết về khả năng chống kiểm duyệt và hoạt động của các biến thể Rollup khác nhau, đồng thời cũng thảo luận về cấu hình tối thiểu của nút của từng biến thể Rollup ở trạng thái tối thiểu hóa độ tin cậy (nghĩa là để đạt được trạng thái Không tin cậy, người dùng phải chạy ít nhất loại Rollup nào nút).

Mặc dù bài viết này phân tích Rollup từ quan điểm của Celestia, khác với cách cộng đồng Ethereum phân tích mô hình Rollup, xem xét nhiều mối liên kết giữa Rollup Ethereum và Rollup chủ quyền của Celestia, cũng như ảnh hưởng ngày càng tăng của mô hình Rollup sau, điều quan trọng là Đối với Những người đam mê Ethereum, bài viết này cũng cực kỳ đáng đọc.

Tổng số là gì?

Tổng số là một chuỗi khối xuất bản "dữ liệu giao dịch" của nó sang một chuỗi khối khác và kế thừa sự đồng thuận và tính sẵn có của dữ liệu.

Tại sao tôi cố tình sử dụng từ "dữ liệu giao dịch" thay vì "chặn"? Điều này liên quan đến sự khác biệt giữa các khối tổng số và dữ liệu tổng số, với các bản tổng số nhỏ gọn nhất chỉ yêu cầu dữ liệu tổng số như biến thể đầu tiên bên dưới.

Khối Rollup là một cấu trúc dữ liệu đại diện cho sổ cái chuỗi khối ở một độ cao khối nhất định. Khối tổng số bao gồm dữ liệu tổng số và tiêu đề tổng số. Trong số đó, dữ liệu Tổng số có thể là một loạt giao dịch hoặc thay đổi trạng thái giữa một loạt giao dịch.

Biến thể 1: Tổng hợp bi quan / Tổng hợp dựa trên

Cách dễ nhất để xây dựng Rollup là cho phép người dùng xuất bản các giao dịch lên một chuỗi khối khác, mà chúng tôi sẽ gọi là lớp đồng thuận và dữ liệu sẵn có (Lớp DA) và tôi sẽ chỉ gọi nó là lớp DA trong phần sau (Ghi chú của người dịch: Nó tương tự như Layer 1 thường được nói trong cộng đồng Ethereum).

Trong biến thể Rollup đầu tiên mà tôi sắp giới thiệu, các nút của mạng Rollup phải thực hiện lại các giao dịch Rollup có trong lớp DA để kiểm tra trạng thái cuối cùng của sổ cái. Đây là Rollup bi quan!

Pessimistic Rollup là Rollup chỉ hỗ trợ các nút đầy đủ và các nút đầy đủ này cần thực hiện lại tất cả các giao dịch có trong sổ cái Rollup để kiểm tra tính hợp lệ của chúng.

Nhưng trong trường hợp này, ai đóng vai trò là Người sắp xếp thứ tự của Rollup? Trên thực tế, ngoại trừ các nút đầy đủ của Rollup, không có thực thể nào từng thực hiện các giao dịch có trong sổ cái Rollup. Nói chung, trình sắp xếp thứ tự tổng hợp dữ liệu giao dịch và tạo tiêu đề Tổng số. Nhưng Rollup bi quan được đề cập ở trên không có tiêu đề Rollup!

Để thuận tiện cho việc thảo luận, chúng ta có thể chia trình sắp xếp thứ tự thành hai thực thể logic: Trình tổng hợp trình tổng hợp và Trình tạo tiêu đề. Để tạo Tiêu đề tổng số, trước tiên bạn phải thực hiện giao dịch, hoàn tất chuyển đổi trạng thái và sau đó tính toán Tiêu đề tương ứng. Nhưng đối với một bộ tổng hợp, nó không cần phải hoàn thành quá trình chuyển đổi trạng thái để tiếp tục bước tổng hợp.

Sắp xếp Sequencing là quá trình “tổng hợp + tạo Rollup Header”.

Tổng hợp là bước gộp dữ liệu giao dịch thành một đợt. Một lô thường chứa nhiều giao dịch (Ghi chú của người dịch: Lô là một phần dữ liệu trong khối Tổng số không phải là Tiêu đề).

Bước tạo tiêu đề là quá trình tạo Tiêu đề tổng số. Rollup Header là siêu dữ liệu về khối Rollup, ít nhất bao gồm cam kết về dữ liệu giao dịch trong khối (Lưu ý của người dịch: Cam kết được đề cập ở đây đề cập đến cam kết về tính chính xác của kết quả xử lý giao dịch).

Qua góc nhìn trên, có thể thấy ai chịu trách nhiệm từng phần của Rollup. Đầu tiên hãy nhìn vào phần của bộ tổng hợp Aggregator. Rollup bi quan đã nói ở trên không có quy trình tạo Tiêu đề và người dùng đăng giao dịch trực tiếp lên lớp DA, điều đó có nghĩa là mạng lớp DA về cơ bản hoạt động như một bộ tổng hợp.

Do đó, Bản tổng hợp bi quan là một biến thể Bản tổng hợp ủy quyền bước tổng hợp cho lớp DA, lớp này không có Trình sắp xếp trình tự trình tự. Đôi khi loại tổng số này được gọi là "tổng số dựa trên".

Bản tổng hợp dựa trên có khả năng chống kiểm duyệt và hoạt động giống như lớp DA (hoạt động đo tốc độ phản hồi của hệ thống đối với các yêu cầu của người dùng). Nếu người dùng của loại Rollup này muốn đạt được trạng thái tin cậy tối thiểu (gần với Trustless nhất), thì họ phải chạy ít nhất một nút nhẹ của mạng lớp DA và một nút đầy đủ của mạng Rollup.

Biến thể 2: Tập hợp bi quan bằng cách sử dụng trình tổng hợp được chia sẻ

Hãy thảo luận về tổng hợp bi quan bằng cách sử dụng trình tổng hợp được chia sẻ. Ý tưởng này được đề xuất bởi Evan Forbes trong bài đăng trên diễn đàn của anh ấy về thiết kế trình tự sắp xếp được chia sẻ. Giả định chính của nó là trình sắp xếp thứ tự được chia sẻ là cách chính thức duy nhất để sắp xếp các giao dịch. Evan giải thích những lợi ích của trình tự chia sẻ theo cách này:

"Để đạt được trải nghiệm người dùng tương đương với Web2, trình sắp xếp thứ tự được chia sẻ có thể cung cấp khả năng tạo nhanh các Cam kết mềm (đảm bảo không đáng tin cậy lắm). Các Cam kết mềm này cung cấp một số đảm bảo về lệnh giao dịch cuối cùng (nghĩa là lệnh giao dịch cam kết sẽ không Change), và bước cập nhật trạng thái sổ cái Tổng số có thể được thực hiện trước (nhưng Finalize vẫn chưa được hoàn thành tại thời điểm này).

Sau khi dữ liệu khối Tổng số được xác nhận và phát hành cho Lớp cơ sở của lớp cơ sở (ở đây nó nên đề cập đến lớp DA), cập nhật trạng thái của sổ cái Tổng số được hoàn thiện và hoàn thiện. "

Biến thể Rollup đã nói ở trên vẫn thuộc danh mục Rollup bi quan, bởi vì chỉ có các nút đầy đủ trong loại hệ thống Rollup này và không có nút nhẹ. Mỗi nút Tổng số phải thực hiện tất cả các giao dịch để đảm bảo tính hợp lệ của cập nhật trạng thái sổ cái. Bởi vì loại Tổng số này không có nút ánh sáng, nên nó không cần Tiêu đề tổng số cũng như không cần trình tạo Tiêu đề. (Ghi chú của người dịch: Nói chung, các light node của chuỗi khối không cần đồng bộ hóa các khối hoàn chỉnh, chỉ nhận các tiêu đề khối)

Do không có bước tạo Tiêu đề tổng số nên trình sắp xếp thứ tự chia sẻ Tổng số nêu trên không cần thực hiện các giao dịch để cập nhật trạng thái (điều kiện tiên quyết để tạo Tiêu đề) mà chỉ bao gồm quá trình tổng hợp dữ liệu giao dịch. Nên tôi thích gọi nó là shared aggregator shared aggregator hơn.

Trong biến thể này, người dùng Tổng số ít nhất cần chạy các nút ánh sáng lớp DA + các nút ánh sáng của mạng tổng hợp được chia sẻ + Các nút đầy đủ của Tổng số ở trạng thái tối thiểu hóa độ tin cậy.

Tại thời điểm này, cần phải xác minh tiêu đề trình tổng hợp đã xuất bản (không phải Tiêu đề tổng số) thông qua các nút ánh sáng của mạng trình tổng hợp được chia sẻ. Như đã đề cập ở trên, trình tổng hợp được chia sẻ đảm nhận công việc sắp xếp các giao dịch.

Bằng cách này, người vận hành nút Tổng số có thể xác nhận rằng Lô hàng loạt nhận được từ lớp DA được tạo bởi trình tổng hợp được chia sẻ chứ không phải bởi những người khác.

• Bao gồm là quá trình bao gồm các giao dịch vào chuỗi khối.
• Sắp xếp Thứ tự đề cập đến quá trình sắp xếp các giao dịch trong chuỗi khối theo một thứ tự cụ thể.
• Thực thi đề cập đến quá trình xử lý các giao dịch trong chuỗi khối và hoàn thành cập nhật trạng thái.

Vì trình tổng hợp được chia sẻ đảm nhiệm việc đưa vào và sắp xếp, nên khả năng chống kiểm duyệt của Rollup phụ thuộc vào nó.

Nếu giả định rằng L_ss là hoạt động của trình tổng hợp được chia sẻ và L_da là hoạt động của Lớp DA, thì hoạt động của mô hình Tổng số là L = L_da && L_ss. Nói cách khác, nếu một trong hai phần bị lỗi hoạt động, thì Rollup cũng bị lỗi hoạt động.

Để đơn giản, tôi sẽ xem tính sống động như một giá trị bool. Nếu trình tổng hợp được chia sẻ không thành công, Rollup không thể tiếp tục hoạt động. Nếu mạng lớp DA bị lỗi, trình tổng hợp được chia sẻ có thể tiếp tục cung cấp Cam kết mềm cho các khối Tổng số. Nhưng tại thời điểm này, các thuộc tính của Rollup sẽ phụ thuộc hoàn toàn vào mạng tổng hợp được chia sẻ và các thuộc tính của mạng sau thường kém hơn nhiều so với lớp DA ban đầu.

Hãy chuyển sang khám phá khả năng chống kiểm duyệt của sơ đồ Tổng hợp ở trên:

Trong lược đồ này, lớp DA không thể xem xét một số giao dịch cụ thể (Ghi chú của người dịch: Việc xem xét giao dịch thường có thể từ chối cho phép một số giao dịch nhất định được tải lên chuỗi), nó chỉ có thể bắt đầu cho toàn bộ lô giao dịch được gửi bởi trình tổng hợp được chia sẻ Đánh giá giao dịch (từ chối cho phép đưa Batch vào lớp DA).

Tuy nhiên, theo quy trình làm việc Tổng số, khi trình tổng hợp được chia sẻ gửi Lô giao dịch đến lớp DA, nó đã hoàn thành việc sắp xếp giao dịch và thứ tự giữa các lô khác nhau cũng đã được xác định. Do đó, loại xem xét giao dịch này ở lớp DA không có tác dụng nào khác ngoại trừ việc trì hoãn xác nhận cuối cùng của sổ cái Rollup.

Tóm lại, tôi tin rằng điểm chống kiểm duyệt là để đảm bảo rằng không một thực thể đơn lẻ nào có thể kiểm soát hoặc thao túng luồng thông tin trong hệ thống, trong khi tính sống động liên quan đến việc duy trì chức năng và tính khả dụng của hệ thống, ngay cả khi có sự cố mất mạng và hành vi đối đầu. Mặc dù điều này mâu thuẫn với định nghĩa học thuật chính thống hiện nay, tôi vẫn sẽ sử dụng định nghĩa của khái niệm mà tôi đã trình bày rõ ràng.

Biến thể 3: Tổng hợp bi quan dựa trên Tổng hợp dựa trên và tổng hợp được chia sẻ

Mặc dù trình tổng hợp được chia sẻ mang lại lợi ích cho người dùng và cộng đồng, nhưng chúng ta nên tránh quá phụ thuộc vào nó và cho phép người dùng rút khỏi trình tổng hợp được chia sẻ để chuyển sang lớp DA. Chúng tôi có thể kết hợp hai biến thể Tổng số được giới thiệu trước đó, cho phép người dùng gửi giao dịch trực tiếp đến lớp DA trong khi sử dụng trình tổng hợp được chia sẻ.

Chúng tôi giả định rằng trình tự giao dịch Tổng số cuối cùng phụ thuộc vào trình tự giao dịch do trình tổng hợp được chia sẻ gửi và các giao dịch Tổng số do người dùng trực tiếp gửi trong khối lớp DA. Chúng tôi gọi đây là quy tắc lựa chọn ngã ba của Rollup.

Tổng hợp được chia thành hai bước ở đây. Đầu tiên, một công cụ tổng hợp được chia sẻ sẽ hoạt động, tổng hợp một số giao dịch. Sau đó, lớp DA có thể tổng hợp Lô được gửi bởi bộ tổng hợp được chia sẻ và các giao dịch do người dùng trực tiếp gửi.

Phân tích khả năng chống kiểm duyệt tại thời điểm này phức tạp hơn một chút. Các nút mạng lớp DA có thể xem xét lô do trình tổng hợp chia sẻ gửi trước khi khối lớp DA tiếp theo được tạo. Sau khi biết dữ liệu giao dịch trong lô, các nút lớp DA có thể trích xuất giá trị MEV và lần đầu tiên sử dụng chính chúng trên Rollup mạng Tài khoản bắt đầu giao dịch chạy trước và đưa giao dịch đó vào khối lớp DA trước, sau đó bao gồm lô do bộ tổng hợp chia sẻ Tổng số gửi.

Rõ ràng, tính chính xác của lệnh giao dịch được đảm bảo bởi cam kết mềm của loại biến thể Rollup thứ ba mong manh hơn so với loại biến thể Rollup thứ hai đã nói ở trên. Trong trường hợp này, trình tổng hợp được chia sẻ đã chuyển giá trị MEV cho các nút lớp DA. Về vấn đề này, tôi khuyên độc giả nên xem bài giảng nghiên cứu về khai thác lợi nhuận MEV đã được kiểm duyệt.

Hiện tại, một số sơ đồ thiết kế đã xuất hiện để giảm khả năng thực hiện các giao dịch MEV đó của các nút mạng lớp DA, chẳng hạn như chức năng "thời gian cửa sổ tổ chức lại", chức năng này sẽ trì hoãn việc thực hiện các giao dịch được gửi trực tiếp tới lớp DA bởi người dùng mạng Rollup . Sovereign Labs mô tả điều này một cách chi tiết trong đề xuất thiết kế của họ có tên là Dựa trên trình tự với xác nhận mềm, đưa ra khái niệm về "trình sắp xếp ưa thích".

Vì vấn đề MEV phụ thuộc vào lược đồ tổng hợp do Rollup chọn và quy tắc chọn nhánh tổng số, nên một số lược đồ sẽ không rò rỉ MEV sang lớp DA và một số lược đồ sẽ rò rỉ một số hoặc tất cả MEV sang lớp DA, nhưng đây là chủ đề khác.

Đối với tính sống động, lược đồ tổng số này có lợi thế hơn so với các lược đồ chỉ cho phép các trình tổng hợp được chia sẻ gửi giao dịch tới lớp DA. Trong trường hợp không hoạt động được trên bộ tổng hợp được chia sẻ, người dùng vẫn có thể gửi giao dịch tới lớp DA.

Cuối cùng, hãy nói về cấu hình tối thiểu của người dùng Rollup theo giảm thiểu tin cậy:

Ít nhất là chạy nút ánh sáng lớp DA + nút ánh sáng tổng hợp được chia sẻ + Nút đầy đủ cuộn lên.

Tại thời điểm này, vẫn cần phải xác minh tiêu đề bộ tổng hợp do bộ tổng hợp chia sẻ cấp để nút đầy đủ của bản tổng số có thể phân biệt các lô giao dịch theo quy tắc lựa chọn ngã ba.

Biến thể 4: Tổng hợp dựa trên sự lạc quan và Trình tạo tiêu đề tập trung

Hãy thảo luận về một biến thể có tên là Tổng hợp dựa trên lạc quan và trình tạo tiêu đề tập trung. Giải pháp này sử dụng lớp DA để tổng hợp các giao dịch Tổng số, nhưng giới thiệu một trình tạo Tiêu đề tập trung để tạo Tiêu đề Tổng số nhằm kích hoạt các nút ánh sáng Tổng số.

Các nút Rollup light có thể gián tiếp kiểm tra tính hợp lệ của các giao dịch Rollup thông qua một vòng chứng minh gian lận duy nhất. Nút nhẹ sẽ lạc quan về trình tạo Tiêu đề tổng số và sẽ đưa ra xác nhận cuối cùng sau khi giai đoạn cửa sổ chứng minh gian lận kết thúc. Một khả năng khác là nó nhận được bằng chứng gian lận từ một nút đầy đủ trung thực mà trình tạo tiêu đề đã gửi dữ liệu sai.

Tôi sẽ không đi sâu vào chi tiết về cách thức hoạt động của bằng chứng gian lận một vòng ở đây, vì điều đó nằm ngoài phạm vi của bài viết này. Ưu điểm của một vòng chứng minh gian lận duy nhất là nó có thể rút ngắn thời gian cửa sổ chứng minh gian lận từ 7 ngày xuống một mức độ nhất định. Giá trị cụ thể vẫn chưa được xác định, nhưng thứ tự độ lớn nhỏ hơn so với tổng số lạc quan truyền thống. Các nút nhẹ có thể có được bằng chứng gian lận thông qua mạng P2P bao gồm các nút đầy đủ Rollup mà không cần chờ quá trình tranh chấp tiếp theo, bởi vì tất cả các tiêu chí đều được cung cấp đầy đủ trong một bằng chứng gian lận duy nhất.

Mô hình Rollup ở trên sử dụng lớp DA làm công cụ tổng hợp và kế thừa khả năng chống kiểm duyệt của nó. Lớp DA tại thời điểm này chịu trách nhiệm chứa và sắp xếp các giao dịch. Trình tạo Tiêu đề tập trung sẽ đọc chuỗi giao dịch Tổng số từ lớp DA và xây dựng Tiêu đề Tổng số tương ứng. Trình tạo Tiêu đề sẽ xuất bản Tiêu đề và Stateroot lên lớp DA. Các Stateroots này được yêu cầu khi tạo bằng chứng gian lận. Nói tóm lại, trình tổng hợp chịu trách nhiệm bao gồm và sắp xếp các giao dịch, và trình tạo Tiêu đề sẽ thực hiện giao dịch để cập nhật trạng thái để lấy Stateroot.

Giả sử rằng lớp DA (tại thời điểm này cũng hoạt động như một trình tổng hợp cho Rollup) đủ phi tập trung và chống kiểm duyệt. Ngoài ra, trình tạo tiêu đề không thể thay đổi chuỗi giao dịch Tổng số do trình tổng hợp xuất bản. Bây giờ, nếu trình tạo tiêu đề được phân cấp, thì lợi ích duy nhất là hoạt động tốt hơn, nhưng các thuộc tính khác của Rollup giống như Rollup dựa trên biến thể đầu tiên.

Nếu trình tạo tiêu đề không hoạt động, thì bản tổng hợp cũng sẽ không hoạt động. Các nút nhẹ sẽ không thể theo dõi tiến trình của sổ cái Tổng số, nhưng các nút đầy đủ thì có thể. Tại thời điểm này, Tổng số được mô tả trong Biến thể 4 thoái hóa thành Tổng số Dựa trên được mô tả trong Biến thể 1. Rõ ràng, cấu hình tối thiểu giảm thiểu độ tin cậy được mô tả bởi Biến thể 4 là:

Nút ánh sáng lớp DA + Nút ánh sáng Rollup.

Biến thể 5: Dựa trên ZK-Rollup và Thị trường chứng minh phi tập trung

Chúng ta đã thảo luận về Bản tổng hợp bi quan (Bản tổng hợp dựa trên) và Bản tổng hợp lạc quan, bây giờ là lúc xem xét ZK-Rollup. Gần đây, Toghrul đã có bài phát biểu về việc tách bộ tổng hợp (Sequencer) và trình tạo Header (Prover) (Tách trình tự-Prover trong Zero-Knowledge Rollups). Trong mô hình này, việc xử lý các giao dịch xuất bản dưới dạng dữ liệu Rollup sẽ dễ dàng hơn là State Diff, vì vậy tôi sẽ tập trung vào phần trước. Biến thể 5 là một Prover Market phi tập trung dựa trên zk-rollup.

Đến bây giờ, bạn đã quen với cách Rollup hoạt động. Biến thể 5 ủy quyền vai trò tổng hợp cho các nút lớp DA, thực hiện công việc bao gồm và sắp xếp các giao dịch. Tôi sẽ trích dẫn tài liệu của Sovereign-Labs, tài liệu này giải thích rõ ràng về vòng đời của một giao dịch trong biến thể 5:

Người dùng xuất bản một khối dữ liệu mới lên chuỗi L1 (lớp DA). Sau khi các khối dữ liệu này được hoàn thiện trên chuỗi L1, về mặt logic, nó sẽ là khối cuối cùng (không thể thay đổi). Sau khi các khối của chuỗi L1 bước vào giai đoạn hoàn thiện (nghĩa là chúng không thể được khôi phục), các nút đầy đủ của Rollup sẽ quét các khối này, xử lý tất cả các khối dữ liệu liên quan đến Rollup theo thứ tự và tạo gốc trạng thái Rollup mới nhất Stateroot . Tại thời điểm này, từ quan điểm của các nút đầy đủ Rollup, các khối dữ liệu này đã được hoàn thiện.

Trong mô hình này, trình tạo Header được thực hiện bởi Prover Market phi tập trung.

Quy trình làm việc của nút Prover prover (một nút đầy đủ chạy trong ZKVM) tương tự như quy trình của nút đầy đủ Rollup thông thường—quét chuỗi khối lớp DA và xử lý tất cả các lô giao dịch Rollup theo thứ tự—để tạo Bằng chứng không kiến thức tương ứng và xuất bản nó trên chuỗi lớp DA. (Nếu hệ thống Rollup muốn thúc đẩy người chứng minh, thì người chứng minh phải gửi bằng chứng ZK đã tạo tới chuỗi lớp DA, nếu không thì sẽ không thể xác định Người chứng minh nào đã gửi bằng chứng ZK trước). Sau khi bằng chứng ZK tương ứng với một lô giao dịch nhất định được phát hành vào chuỗi, lô giao dịch sẽ được hoàn thiện trước mắt của tất cả các nút Rollup (bao gồm cả các nút nhẹ).

Biến thể 5 có khả năng chống kiểm duyệt giống như lớp DA. Thị trường Prover phi tập trung không thể xem xét các giao dịch Rollup, vì lớp DA đã xác định thứ tự giao dịch tiêu chuẩn, chỉ để có được hoạt động tốt hơn và tạo thị trường khuyến khích, vì vậy trình tạo Header (ở đây đề cập đến Prover) là thay đổi phi tập trung.

Hoạt động ở đây là L = L_da && L_pm (Hoạt động của Prover). Nếu các ưu đãi của Prover Market không nhất quán hoặc có lỗi hoạt động, thì Rollup light node sẽ không thể đồng bộ hóa tiến trình của chuỗi khối, nhưng Rollup full node thì có thể. đến Tổng hợp dựa trên/Tổng hợp bi quan. Cấu hình tối thiểu để giảm thiểu tin cậy ở đây giống như trong trường hợp Rollup lạc quan, cụ thể là

Nút ánh sáng lớp DA + Nút ánh sáng Rollup.

Biến thể 6: Tổng hợp dựa trên kết hợp + Trình tạo tiêu đề lạc quan tập trung + Chứng minh phi tập trung

Chúng tôi vẫn để các nút lớp DA đóng vai trò là bộ tổng hợp Rollup và ủy thác công việc bao gồm và sắp xếp giao dịch cho chúng.

Như bạn có thể thấy trong hình bên dưới, cả ZK Rollup và Optimistic Rollup đều sử dụng cùng một lô giao dịch được đặt hàng trên lớp DA làm nguồn của sổ cái Rollup. Đây là lý do chúng tôi có thể sử dụng cả hai hệ thống bằng chứng cùng một lúc: lô giao dịch được đặt hàng trên lớp DA không bị ảnh hưởng bởi hệ thống bằng chứng.

Trước tiên hãy nói về tài chính. Từ quan điểm của nút đầy đủ Rollup, khi khối của lớp DA được hoàn thiện, lô giao dịch Rollup chứa trong đó sẽ được hoàn thiện và không thể thay đổi. Nhưng chúng tôi quan tâm nhiều hơn đến tính hữu hạn từ quan điểm của các nút ánh sáng. Giả sử rằng trình tạo Tiêu đề tập trung thế chấp một số tài sản, ký tên vào Tiêu đề tổng số được tạo và gửi Stateroot đã tính toán cho lớp DA.

Giống như biến thể 4 trước đó, nút nhẹ sẽ tin tưởng một cách lạc quan vào trình tạo tiêu đề, tin rằng tiêu đề mà nó đưa ra là chính xác và chờ bằng chứng gian lận từ mạng nút đầy đủ. Nếu giai đoạn cửa sổ của bằng chứng gian lận kết thúc và mạng nút đầy đủ chưa đưa ra bằng chứng gian lận, thì từ góc độ của nút Rollup light, khối Rollup sẽ được hoàn tất.

Điểm mấu chốt là nếu chúng tôi có thể nhận được bằng chứng ZK, chúng tôi không cần phải đợi cửa sổ chứng minh gian lận kết thúc. Ngoài một vòng chứng minh gian lận duy nhất, chúng tôi có thể thay thế bằng chứng gian lận bằng bằng chứng ZK và loại bỏ các tiêu đề sai do trình tạo tiêu đề độc hại tạo ra!

Khi các nút ánh sáng nhận được bằng chứng ZK cho một lô giao dịch Tổng số, lô đó sẽ được hoàn tất.

Bây giờ chúng tôi có Cam kết mềm nhanh và tài chính nhanh.

Biến thể 6 vẫn có khả năng chống kiểm duyệt giống như lớp DA vì nó dựa trên lớp DA. Đối với độ sống động, chúng tôi sẽ có L = L_da && (L_op || L_pm), có nghĩa là chúng tôi thêm các đảm bảo về độ sống động. Nếu trình tạo Header tập trung hoặc Prover Market phi tập trung gặp sự cố về tính sống động, chúng ta có thể chuyển sang cái còn lại trong cả hai.

Trong biến thể này, cấu hình tối thiểu để giảm thiểu sự tin cậy của người dùng là:

Một nút ánh sáng lớp DA + một nút ánh sáng Rollup.

Bản tóm tắt:

1. Chúng tôi chia vai trò chính của Rollup - Sequencer thành hai thành phần hợp lý:

Trình tổng hợp và trình tạo tiêu đề.

2. Chúng tôi chia công việc của Sequencer thành ba quy trình hợp lý: ngăn chặn, sắp xếp và thực thi.

3. Tổng số bi quan và tổng số dựa trên là một chuyện.

4. Tùy theo nhu cầu của mình, bạn có thể chọn các giải pháp trình tạo tiêu đề và trình tổng hợp khác nhau.

5. Mỗi biến thể Tổng số được giới thiệu trong bài đăng này đều tuân theo cùng một mẫu thiết kế:

Cuối cùng, tôi có một vài suy nghĩ. Xin hãy suy nghĩ về:

• Rollup cổ điển (ám chỉ Ethereum Rollup) được phân loại thành các biến thể trên như thế nào?
• Trong tất cả các biến thể, chúng tôi chỉ để trình tổng hợp chịu trách nhiệm đưa vào + sắp xếp và trình tạo Tiêu đề để thực hiện giao dịch. Điều gì sẽ xảy ra nếu trình tổng hợp chỉ chịu trách nhiệm bao gồm các giao dịch và trình tạo tiêu đề chịu trách nhiệm đặt hàng và thực hiện các giao dịch? Xem xét việc giới thiệu bước đấu giá trực tuyến, liệu chúng ta có thể tách biệt hoàn toàn ba bước này không?
• Thị trường nhà sản xuất tiêu đề được chia sẻ / Nhà sản xuất tiêu đề được chia sẻ là gì?
• Ai nắm bắt giá trị MEV? Người dùng có lấy lại được không?