Giới thiệu:Bài viết này được tóm tắt bởi nhà nghiên cứu Celestia NashQ về các tuyên bố rải rác 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 “ Nhà nghiên cứu Celestia phân tích 6 biến thể Rollup: Sequencer=Aggregator+Header Generator “, anh liệt kê 6 mô hình Rollup khác nhau, và bài viết này là một sự trừu tượng mới của 4 loại mô hình Rollup dựa trên bài viết này.

Trước đây, NashQ đã chia nhỏ bộ ghi Sequencer thành hai module, Aggregator + Header Producer, và thực hiện qua vòng đời của các chỉ thị giao dịch để giải thích cách Celestia Sovereign Rollup hoạt động, khám phá sự chống đối từ chối và hoạt động của các biến thể Rollup khác nhau, cũng như cấu hình tối thiểu cho một người dùng để được tối thiểu hóa niềm tin (tức là, để không cần tin cậy, người dùng Rollup cần chạy loại nodes nào tối thiểu).

Biến thể 7: Dựa trên Rollup + Nhiều Nhà Sản Xuất Header + 'MEV Giao Thức Cao Nhất'

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

Giả sử rằng có ba HP đang cạnh tranh với nhau và tuân theo giao thức phân bổ MEV được gọi là "MEV giao thức cao nhất". Giao thức này được đề xuất bởi Giao thức bỏ qua của hệ sinh thái Cosmos, khác với sơ đồ Ether PBS ở chỗ các Nhà xây dựng khối trả thêm một "mẹo" cho Trình xác thực của mạng blockchain và các khối được xây dựng bởi các Trình tạo có nhiều tiền boa nhất được Người xác thực chấp nhận. Các khối được xây dựng bởi các Nhà xây dựng có nhiều tiền boa nhất sẽ được Người xác thực thông qua. Đồng thời, SKIP Protocol đưa ra khái niệm "Sovereign MEV", dự định cho phép tất cả các Trình xác thực và cộng đồng của mạng chuỗi công cộng có quyền tự chủ phân bổ MEV và giải quyết vấn đề tăng cường tập trung hóa các nhà xây dựng do hiệu ứng bánh đà trong Ethernet PBS (nhưng đây không phải là cốt lõi của bài viết này). ).

Trong biến thể Rollup được trình bày trong bài báo này, các Nhà Sản xuất Header khác nhau cần phải khai báo số lượng tiền tip trong Batch Header mà họ tạo, và Batch Header được đăng bởi HP có số tiền tip cao nhất sẽ được tự động chấp nhận bởi các node của Rollup (tự động thông qua thuật toán lựa chọn fork của sổ ghi chép được viết trong mã của node).

Ngoài ra, Batch Header được xuất bản bởi HP phải có khả năng tương ứng với một lô giao dịch hoàn chỉnh trên lớp DA.

Nếu có lỗi trong Phần tiêu đề được xuất bản bởi HP, như kết quả thực hiện giao dịch Stateroot không chính xác, hoặc nó không chứa một giao dịch cụ thể nào trong Batch (giao dịch bị mất), nút đầy đủ Rollup trung thực phát sóng chứng cớ gian lận Chứng cớ gian lận đến nút nhẹ. Tuy nhiên, thông thường (một cách lạc quan), nút nhẹ có thể chấp nhận Phần tiêu đề được xuất bản bởi HP và tin rằng nó không có Vấn đề nào.

Phân tích Kháng Censorship: 2 điểm tồn tại trong Rollup này nơi mà việc kiểm duyệt giao dịch có thể xảy ra. Điểm đầu tiên tồn tại tại lớp DA, nơi mà nó có thể xem xét nội dung giao dịch và từ chối bao gồm giao dịch của một số người dùng nhất định. Điểm thứ hai vẫn ở lớp DA, nơi mà nó có thể xem xét Header được gửi bởi HP và từ chối bao gồm một số Header nhất định, để nó có thể âm mưu với Header để độc quyền MEV thông qua cuộc tấn công kiểm duyệt.

Đồng thời, việc xếp thứ tự giao dịch được xử lý bởi HP, và do sự tồn tại của bằng chứng gian lận (có thể được sử dụng chống lại trường hợp HP loại bỏ giao dịch), HP chính nó thường không khởi xướng các cuộc tấn công kiểm duyệt, nhưng có thể hối lộ các nút lớp DA để làm điều đó (hoặc chạy một số nút lớp DA chính nó). Giải pháp cho vấn đề này là mở rộng thời gian cửa sổ trong đó chuỗi giao dịch Rollup được hoàn tất, để mà Header bị từ chối bởi nút lớp DA độc hại có thể được bao gồm trong chuỗi bởi nút lớp DA trung thực kịp thời trước khi kết thúc thời gian cửa sổ, điều này lại tăng độ khó của cuộc tấn công kiểm duyệt của nút lớp DA.

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

Nếu lớp DA có lỗi hoạt động, thì Rollup cũng sẽ có lỗi hoạt động. Dựa vào điều này, Rollup sẽ chỉ có lỗi hoạt động nếu tất cả các HP đều có lỗi hoạt động.

Biến thể 8: ZK Rollup với Trình tổng hợp Chia sẻ + Bằng chứng viên phi tập trung

Biến thể 8 sử dụng Shared Aggregator (SA) để bao gồm và sắp xếp giao dịch, trong đó SA công bố lô giao dịch theo thứ tự lên tầng DA, và thứ tự giao dịch lý thuyết không thay đổi sau khi chuỗi giao dịch được gửi đến tầng DA.

Và trước khi Batch được gửi đến lớp DA, Shared Aggregator SA có thể trước tiên phát sóng Batch + SA Header đến nút đầy đủ và Prover, và SA Header đến nút nhẹ, ngoại trừ việc vào thời điểm này, Batch không ổn định trên lớp DA vẫn có thể bị thay thế bất kỳ lúc nào.

Điều quan trọng cần lưu ý là Tiêu đề được xuất bản bởi Trình tự Tập trung Chia sẻ SA không giống như Tiêu đề Lô được xuất bản bởi HP. Tiêu đề SA chứa các bằng chứng mật mã để đảm bảo rằng Lô mà nút Rollup đọc từ lớp DA thực sự được tạo ra bởi SA, không phải là giả mạo bởi nó.

Prover đọc lô giao dịch Batch từ lớp DA (và cũng đồng bộ trực tiếp với bộ tổng hợp được chia sẻ), tạo ra một Bằng chứng ZK+Tiêu đề Batch, và công bố nó cho lớp DA. Rõ ràng Prover hoạt động như HP.

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

Khá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 trên một số giao dịch cụ thể, nhưng chỉ có thể thực hiện cuộc tấn công kiểm duyệt hàng loạt trên toàn bộ lô giao dịch được gửi bởi bộ tổng hợp được chia sẻ. Đồng thời, bộ tổng hợp được chia sẻ có thể từ chối đóng gói một số giao dịch của người dùng.

Hoạt động: L = L_da && L_sa && L_pm. bất kỳ phần nào của biến thể này thất bại hoạt động thì Rollup sẽ thất bại hoạt động. Nếu Prover thất bại, thì nút nhẹ sẽ không thể đồng bộ tiến độ sổ cái Rollup hiệu quả. Nhưng vì nút đầy đủ đồng bộ hóa tất cả các giao dịch chuỗi Batch, nó có thể theo kịp tiến độ sổ sách. Lúc này, nút đầy đủ không bị ảnh hưởng và tất cả các nút nhẹ thất bại, điều này tương đương với trường hợp trước đây đã mô tả của Based Rollup với bộ tập hợp chung.

Cấu hình tối thiểu cho việc tối thiểu hóa niềm tin: các nút nhẹ DA tier + các nút nhẹ Mạng Tập hợp Chia sẻ + các nút nhẹ Rollup

Biến thể 9: Bộ tổng hợp chia sẻ + Đơn vị chứng thực phi tập trung + ZK-Rollup với nhiều DA

Biến thể 9 thực sự dựa trên việc mở rộng biến thể 8 ở trên, ngoại trừ việc nó có nhiều hơn một lớp DA, có thể cải thiện hiệu suất của Rollup một cách hiệu quả. Trong biến thể 9, trình tổng hợp SA có thể xuất bản chuỗi giao dịch Batch đến bất kỳ lớp DA nào, và nó 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 chính nó, để có thể tối ưu động các tham số liên quan của Rollup, như: chi phí dữ liệu, bảo mật, hoạt động, trì hoãn giao dịch và sự hoàn thiện.

Tùy thuộc vào nhu cầu của máy chiếu Rollup, Rollup rẻ nhất, an toàn nhất, hoạt động nhất và giải quyết nhanh nhất có thể được tùy chỉnh, và lớp DA có tốc độ xử lý cao nhất có thể được lựa chọn. Nói chung, Batch của một chiều cao khối Rollup cụ thể (ví dụ: Batch 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 họ làm, nội dung của họ phải giống nhau. Nếu hai Batch cùng chiều cao và nội dung khác nhau hiện diện trên các lớp DA khác nhau, điều đó có nghĩa là bộ hợp nhất chia sẻ đang cố ý tham gia vào một cái cày.

Ở đây, chúng tôi chọn Prover Market phi tập trung giống như trong biến thể 8, nơi Prover đóng vai trò là Header Producer và xuất bản Batch Header và ZKProof. tại thời điểm này, Prover cần cạnh tranh thông qua cơ chế đấu giá tiền boa được đề cập trong biến thể 7 (do SKIP Protocol đề xuất).

Tốc độ thanh toán 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 nhanh nhất mà nó sử dụng trong các khối.

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

Hoạt động: L = ( L_da1 || L_da2) && L_sa && L_pm.

Biến thể 9 hoạt động mạnh hơn so với các biến thể trước đó. Miễn là không có lỗi hoạt động trong tất cả các mạng lớp DA, mọi thứ đều có thể tiến hành bình thường.

Cấu hình tối thiểu cho việc tối thiểu hóa niềm tin: các nút nhẹ ở các lớp DA khác nhau + các nút nhẹ mạng tổng hợp chia sẻ + các nút nhẹ Rollup.

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

Biến thể 10: Hai ZK-Rollups + Prover Phi tập trung với một nút nhẹ trên chuỗi tới nhau (có thể kết nối cầu)

Biến thể 10 là một phần mở rộng của Biến thể 5 với mục tiêu tạo ra 2 ZK-Rollups có thể kết nối với nhau. So với Biến thể 5 (Dựa trên Rollup+ZKP+Prover Phi tập trung), Biến thể 10 có vai trò bổ sung của một Repeater Relayer, nói chung gói Batch Header+ZK-Proof vào một giao dịch duy nhất. Chỉ cần gửi giao dịch này đến nút nhẹ Rollup1 nơi Rollup2 đang chạy chứng minh rằng một Batch ở độ cao nhất định là hợp lệ. Tất nhiên, Rollup2 cũng cần chạy nút nhẹ của lớp DA.

Điều này là tiên quyết để giữ cho niềm tin của cầu giao mạng giảm thiểu. Tuy nhiên, nếu ai đó đang vượt qua từ một Ether Rollup (một SC Rollup dựa trên hợp đồng thông minh) sang Ether, không cần phải chạy nữa nút sáng DA-layer của Rollup, vì DA-layer chính là Ether. Điều này rất khác biệt so với Celestia's Sovereign Rollup, nơi Rollups phải chạy nút sáng DA layer của nhau để vượt qua lẫn nhau.

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

Repeater của Rollup 2 sẽ nhận Batch Header và ZKP của Rollup 2 và gửi lại cho Rollup 1. Rollup 1 cũng có một nút nhẹ cho Rollup 2 và một nút nhẹ cho lớp DA.

Chúng ta có thể làm cho mô hình đơn giản hơn. Giả sử hai Rollups sử dụng cùng một Bộ tập hợp và Nhà sản xuất Header Chia sẻ, tức là họ sử dụng các lớp DA trùng lắp.

Trong trường hợp này, Relayer có thể bị cấm trực tiếp. Khi Batch Header và ZK Proof đã được xuất bản bởi HP tới 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 phải được chuyển đến Trình tự chung thông qua Relayer nữa.

Rõ ràng, Rollups sử dụng cùng lớp DA không cần phải phụ thuộc vào Relayers (nhiều cầu nối cross-chain phụ thuộc vào các nút relay). Điều này có thể giải quyết vấn đề bảo mật của các cầu nối cross-chain (từ góc độ này, việc chuyển đổi giữa SC Rollups trên Ethernet an toàn hơn việc chuyển đổi giữa các chuỗi công cộng khác nhau).

Tại thời điểm này, cấu hình tối thiểu để giảm thiểu sự tin cậy: một nút nhẹ DA tier + một nút nhẹ Rollup.

Tuyên bố:

1. Bài viết này được sao chép từ [[Geek Web3](https://mp.weixin.qq.com/s/Wi4FPTCZli5g8UGVkYFnlw) ], bản quyền thuộc về tác giả gốc[NashQ, Celestia], nếu bạn có bất kỳ ý kiến ​​nào về việc sao chép, vui lòng liên hệ đội ngũ Gate Learn, nhóm sẽ được xử lý theo quy trình liên quan trong thời gian sớm nhất.
2. Lời từ chối trách nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này đại diện cho quan điểm cá nhân của tác giả và không đại diện cho bất kỳ lời khuyên đầu tư nào.
3. Các bài viết bằng ngôn ngữ khác được dịch bởi nhóm Gate Learn và không thể tái sản xuất, phân phối hoặc sao chép mà không có sự tham khảo đến Gate.