Nhà nghiên cứu Celestia: Giải thích 4 lược đồ tổng hợp mới

Tác giả: NashQ, Celestia; Trình biên dịch: Link, "Geek web3"

Giới thiệu: Bài viết này bao gồm các bài phát biểu rải rác của nhà nghiên cứu Celestia NashQ về phân tích mô hình Rollup, bao gồm 4 biến thể Rollup mới. Trước đây, trong bài viết "Phân tích Rollup từ góc nhìn của Celestia: Kiểm duyệt kháng chiến và hoạt động của 6 biến thể", ông đã liệt kê 6 mô hình Rollup khác nhau và bài viết này là 4 danh mục mới được ông tóm tắt dựa trên mô hình Rollup này.

Trước đây, NashQ đã chia Sequencer thành hai mô-đun: trình tổng hợp + Nhà sản xuất tiêu đề. Bắt đầu từ vòng đời của các hướng dẫn giao dịch, nó giải thích nguyên tắc hoạt động của Rollup chủ quyền của Celestia, thảo luận về hoạt động chống kiểm duyệt và hoạt động của các biến thể Rollup khác nhau cũng như trải nghiệm người dùng .Cấu hình tối thiểu với tiền đề giảm thiểu Trust (nghĩa là để đạt được Trustless thì người dùng phải chạy ít nhất các loại node Rollup nào).

Biến thể 7: Tổng hợp dựa trên+Nhà sản xuất nhiều tiêu đề+"MEV giao thức cao nhất"

Trong biến thể Rollup này, người dùng mạng Rollup trực tiếp xuất bản dữ liệu giao dịch lên các khối lớp DA, sau đó Header Producer chịu trách nhiệm sắp xếp giao dịch và MEV được trích xuất bởi nó. Rõ ràng, quy trình tổng hợp/bao gồm giao dịch của Biến thể tổng số 7 giống như Tổng hợp dựa trên cơ sở đã giới thiệu trước đó, đây là trách nhiệm của lớp DA (người dùng trực tiếp gửi giao dịch đến lớp DA), nhưng thứ tự giao dịch khác với lớp DA. Tổng số và các nút lớp DA không chịu trách nhiệm Sắp xếp là trách nhiệm của HP (Nhà sản xuất tiêu đề).

Phần sau đây giả định rằng có ba HP cạnh tranh với nhau và tuân theo giao thức phân bổ MEV có tên là "Giao thức MEV cao nhất". Giao thức này được đề xuất bởi Giao thức Skip của hệ sinh thái Cosmos. được chấp nhận bởi Người xác thực. . Đồng thời, Giao thức SKIP đề xuất khái niệm "MEV có chủ quyền", dự định cho phép tất cả Người xác thực và cộng đồng trong mạng chuỗi công cộng có quyền tự chủ phân bổ MEV và giải quyết vấn đề mà Nhà xây dựng trong Ethereum PBS ngày càng trở nên phổ biến. tập trung hơn do hiệu ứng bánh đà (nhưng đây không phải là cốt lõi của bài viết này).

Trong biến thể Tổng số được giới thiệu trong bài viết này, các Nhà sản xuất Tiêu đề khác nhau cần khai báo số tiền boa trong Tiêu đề Lô do chính họ tạo và Tiêu đề Lô do HP trả nhiều tiền boa nhất sẽ tự động được các nút Tổng số chấp nhận (thông qua sổ cái được viết bằng mã nút Thuật toán lựa chọn ngã ba được thực hiện tự động).

Ngoài ra, Batch Header do HP phát hành phải có khả năng tương ứng với Batch lô giao dịch hoàn chỉnh trên lớp DA.

Ví dụ: nếu có lỗi trong Tiêu đề do HP cấp, kết quả thực hiện giao dịch Stateroot không chính xác hoặc giao dịch trong lô không được bao gồm (giao dịch bị mất), nút đầy đủ Rollup trung thực sẽ phát bằng chứng gian lận cho nút ánh sáng . Nhưng thông thường (một cách lạc quan), light node có thể chấp nhận Header do HP cấp và tin rằng không có vấn đề gì với nó.

Khả năng chống phân tích kiểm duyệt: Có 2 điểm trong Bản tổng hợp này có thể tiến hành xem xét giao dịch. Cái đầu tiên tồn tại ở lớp DA, có thể kiểm duyệt nội dung giao dịch và từ chối các giao dịch liên quan đến một số người dùng nhất định. Vị trí thứ hai vẫn tồn tại trong lớp DA, lớp này có thể xem xét tiêu đề do HP gửi và từ chối đưa vào một tiêu đề nhất định, để nó có thể thông đồng với tiêu đề để độc quyền MEV thông qua các cuộc tấn công xem xét.

Đồng thời, HP chịu trách nhiệm sắp xếp các giao dịch, do có bằng chứng gian lận (có thể nhắm vào tình huống HP mất giao dịch), bản thân HP thường không tung ra các cuộc tấn công kiểm duyệt nhưng có thể mua chuộc các nút. của lớp DA để làm như vậy (hoặc tự chạy một số lớp DA) nút). Giải pháp cho vấn đề này là kéo dài khoảng thời gian cửa sổ để hoàn tất chuỗi giao dịch Tổng số, sao cho Tiêu đề bị các nút lớp DA độc hại từ chối có thể được đưa vào chuỗi bởi các nút lớp DA trung thực trước khi kết thúc khoảng thời gian cửa sổ, do đó tăng đánh giá nút lớp DA Độ khó của cuộc tấn công.

**Hoạt động:**L = L_da && ( L_hp1 || L_hp2 || L_hp3 )

Nếu lớp DA bị lỗi hoạt động, Rollup cũng sẽ bị lỗi hoạt động. Dựa trên điều này, Rollup sẽ không hoạt động chỉ khi tất cả HP không hoạt động.

Biến thể 8: Tổng hợp ZK của Trình tổng hợp được chia sẻ + Chứng minh phi tập trung

Biến thể 8 sử dụng trình tổng hợp được chia sẻ Shared Aggregator (SA) để bao gồm + sắp xếp giao dịch. SA xuất bản Batch trình tự giao dịch lên lớp DA. Sau khi trình tự giao dịch được gửi đến lớp DA, thứ tự giao dịch sẽ không thay đổi về mặt lý thuyết.

Trước khi Lô được gửi đến lớp DA, bộ tổng hợp chia sẻ SA trước tiên có thể truyền Tiêu đề Batch+ SA đến nút đầy đủ và Prover, đồng thời truyền Tiêu đề SA đến nút nhẹ, nhưng Batch không có trên lớp DA là lúc này vẫn chưa ổn định và có thể bị nghẽn bất cứ lúc nào.hãy thay thế.

Cần lưu ý rằng tiêu đề do bộ tổng hợp chia sẻ SA cấp không giống với tiêu đề lô do HP cấp. Tiêu đề SA chứa bằng chứng mật mã để đảm bảo rằng Lô được đọc bởi nút Tổng số từ lớp DA thực sự được tạo bởi SA, không phải do người khác giả mạo.

Prover đọc lô giao dịch Batch từ lớp DA (nó cũng có thể được đồng bộ hóa trực tiếp với bộ tổng hợp được chia sẻ), tạo ZK Proof+Batch Header và xuất bản nó lên lớp DA. Rõ ràng là Prover đã đóng vai HP.

Đối với các nút nhẹ của Rollup, sau khi nhận được ZKProof, chuỗi giao dịch có trong Lô này cuối cùng sẽ được xác nhận. Tất nhiên, Prover cũng có thể phát ZKP thông qua mạng Rollup p2p trong chuỗi lớp DA, để các nút ánh sáng có thể nhận được nó nhanh hơn, nhưng tại thời điểm này, ZKP chưa được gửi đến lớp DA và nó không có " tính chất dứt khoát".

• **Khả năng chống kiểm duyệt: **Trong biến thể 8, lớp DA không thể thực hiện các cuộc tấn công kiểm duyệt đối với một số giao dịch cụ thể mà chỉ có thể tiến hành các cuộc tấn công xem xét đối với toàn bộ lô giao dịch được gửi bởi trình tổng hợp được chia sẻ. Đồng thời, các công cụ tổng hợp được chia sẻ có thể từ chối đóng gói các giao dịch nhất định của người dùng.
• **Hoạt động: **L = L_da && L_sa && L_pm. Trong biến thể này, nếu bất kỳ phần nào bị lỗi hoạt động, Rollup sẽ bị lỗi hoạt động. Nếu Prover không thành công, các light node sẽ không thể đồng bộ hóa hiệu quả tiến trình của sổ cái Rollup. Tuy nhiên, vì nút đầy đủ đồng bộ hóa tất cả các lô trình tự giao dịch nên nó có thể theo kịp tiến trình của sổ cái. Tại thời điểm này, tất cả các nút sẽ không bị ảnh hưởng và tất cả các nút nhẹ sẽ bị lỗi, điều này tương đương với tình huống Tổng số dựa trên sử dụng bộ tổng hợp được chia sẻ đã giới thiệu trước đó.
• **Cấu hình tối thiểu để giảm thiểu độ tin cậy: **Nút ánh sáng lớp DA + nút ánh sáng mạng tổng hợp dùng chung + Nút ánh sáng cuộn lên

Biến thể 9: Trình tổng hợp được chia sẻ + Prover phi tập trung + ZK-Rollup với nhiều DA

Biến thể 9 thực sự dựa trên biến thể 8 ở trên, nhưng nó có nhiều hơn một lớp DA, có thể cải thiện hiệu quả hoạt động của Rollup. Trong Biến thể 9, trình tổng hợp dùng chung SA có thể xuất bản Batch chuỗi giao dịch lên bất kỳ lớp DA nào và có thể chọn các lớp DA khác nhau để xuất bản dữ liệu theo nhu cầu của mình, để có thể tự động tối ưu hóa các thông số liên quan của Rollup, chẳng hạn như: chi phí dữ liệu, bảo mật, tính sống động, độ trễ giao dịch và tính hữu hạn.

Theo nhu cầu của bên dự án Rollup, có thể tùy chỉnh Rollup rẻ nhất, an toàn nhất, tích cực nhất và tốc độ giải quyết và có thể chọn lớp DA có thông lượng cao nhất. Nói chung, các Lô có chiều cao khối Tổng số nhất định (chẳng hạn như thứ 10.000) không cần phải tồn tại trên các lớp DA khác nhau cùng một lúc, nhưng nếu chúng tồn tại, thì nội dung của chúng phải nhất quán. Nếu hai lô có cùng chiều cao và nội dung khác nhau xuất hiện trên các lớp DA khác nhau, điều đó có nghĩa là trình tổng hợp được chia sẻ cố ý phân nhánh sổ cái.

Ở đây, chúng tôi chọn cùng một Thị trường Prover phi tập trung như Biến thể 8, trong đó Prover đóng vai trò là Nhà sản xuất tiêu đề và phát hành Batch Header và ZKProof. Tại thời điểm này, Người cung cấp dịch vụ cần phải cạnh tranh thông qua cơ chế đấu giá tiền boa được đề cập trong Biến thể 7 (do Giao thức SKIP đề xuất).

Tốc độ giải quyết giao dịch (tốc độ xác nhận cuối cùng) của Biến thể 9 bị ảnh hưởng bởi lớp DA có khả năng tạo khối nhanh nhất.

Khả năng chống kiểm duyệt: Trình tổng hợp được chia sẻ có thể tham gia vào các cuộc tấn công kiểm duyệt, nhưng với nhiều lớp DA tùy chọn hơn, khả năng xảy ra các cuộc tấn công kiểm duyệt liên quan đến các lớp DA sẽ giảm đi.

**活性：**L = ( L_da1 || L_da2) && L_sa && L_pm。

Biến thể 9 hoạt động mạnh hơn biến thể trước đó. Miễn là không phải tất cả các mạng lớp DA đều gặp sự cố trực tiếp, mọi thứ sẽ hoạt động tốt.

Cấu hình tối thiểu để giảm thiểu độ tin cậy: nút ánh sáng của các lớp DA khác nhau + nút ánh sáng mạng tổng hợp dùng chung + Nút ánh sáng cuộn lên.

Rõ ràng, chúng ta càng áp dụng nhiều lớp DA, chúng ta càng phải chạy nhiều nút nhẹ hơn. Nhưng lợi ích của việc làm như vậy có thể lớn hơn chi phí.

Biến thể 10: Hai ZK-Rollups+Prover phi tập trung, với một nút ánh sáng trên chuỗi (có thể kết nối) với nhau

Biến thể 10 là phần mở rộng của Biến thể 5 để tạo 2 ZK-Rollup có thể kết nối lẫn nhau. So với Biến thể 5 (Bản tổng hợp dựa trên + ZKP + Chứng minh phi tập trung), Biến thể 10 có vai trò chuyển tiếp bổ sung, bao gồm Tiêu đề hàng loạt + Chứng minh ZK thành một giao dịch. Miễn là giao dịch này được gửi đến nút ánh sáng Rollup1 chạy trên Rollup2, nó có thể chứng minh rằng một độ cao nhất định của Batch là hợp lệ. Tất nhiên, Rollup2 cũng yêu cầu các light node chạy lớp DA.

Đây là điều kiện tiên quyết để giữ niềm tin trên các cầu chuỗi ở mức tối thiểu. Nhưng nếu nó là chuỗi chéo từ Ethereum Rollup (SC Rollup dựa trên hợp đồng thông minh) sang Ethereum, thì không cần chạy nút ánh sáng lớp DA của Rollup, vì lớp DA chính là Ethereum. Điều này rất khác so với Rollup có chủ quyền của Celestia, Rollup của chúng trải dài với nhau và phải chạy các nút ánh sáng của lớp DA của bên kia.

Khi Relayer gửi một giao dịch chuỗi chéo, nó sẽ được xử lý bởi Bộ tổng hợp 2 và HP2 của Rollup2. Chúng tôi thêm cả hai vào biểu đồ để hiểu cách các nút của Rollup2 xử lý các giao dịch trên Rollup.

Người chuyển tiếp của Rollup2 sẽ nhận Batch Header và ZKP của Rollup 2 và gửi chúng trở lại Rollup1. Rollup 1 cũng có nút ánh sáng Rollup 2 và nút ánh sáng lớp DA.

Chúng ta có thể làm cho mô hình đơn giản hơn. Giả sử rằng hai Rollup sử dụng cùng một bộ tổng hợp được chia sẻ và Header Producer, nói cách khác, các lớp DA mà chúng sử dụng chồng lên nhau.

Trong trường hợp này, Relayer có thể bị cấm trực tiếp. Vì Batch Header và ZK Proof đã được HP xuất bản lên cùng một lớp DA, dữ liệu như Header và ZKP của một Rollup khác có thể được đọc trực tiếp trên lớp DA và không còn cần phải chuyển đến trình tổng hợp được chia sẻ thông qua Người chạy tiếp sức.

Rõ ràng, Rollup sử dụng cùng một lớp DA không cần phụ thuộc vào Relayer (nhiều cầu nối chuỗi chéo dựa vào các nút chuyển tiếp). Điều này có thể giải quyết vấn đề bảo mật của cầu nối chuỗi chéo (từ quan điểm này, nhịp chéo giữa SC Rollup của Ethereum an toàn hơn chuỗi chéo giữa các chuỗi công khai khác nhau).

Tại thời điểm này, **cấu hình tối thiểu của giảm thiểu tin cậy: **Nút ánh sáng lớp DA + Nút ánh sáng cuộn lên.