4D thảo luận về con đường phân cấp của Rollup Sorter

Foresight News

特邀专栏作者

2023-03-25 02:00

Bài viết này có khoảng 19261 từ, đọc toàn bộ bài viết mất khoảng 28 phút

Để "Rollup" trở thành một Rollup thực sự, việc phân cấp bộ sắp xếp là một bước quan trọng.

Tóm tắt AI

Mở rộng

Để "Rollup" trở thành một Rollup thực sự, việc phân cấp bộ sắp xếp là một bước quan trọng.

Tác giả gốc:Jon Charbonneau

Tác giả gốc:

Phần tổng hợp gốc: 0x11, Tin tức tầm nhìn xaKelvin nghĩ "ZK Rollup" không phải là ZK Rollup thật, tôi nghĩ tất cả đều là "Rollup"Không phải là Rollup thực sự

, ít nhất là chưa. Vì vậy, câu hỏi đặt ra là, làm thế nào để chúng tôi biến chúng thành Rollup thực sự?

Hầu hết các Tổng số hiện tại đều yêu cầu sự tin cậy và quyền:

Nguồn: L2 Beat https://l 2b eat.com/scaling/risk

Tôi sẽ phác thảo tình hình trong các lĩnh vực sau:
Cơ chế bao gồm giao dịch bắt buộc: Ngay cả khi nhà điều hành Tổng số đang kiểm duyệt người dùng, người dùng vẫn có thể buộc các giao dịch của họ được đưa vào để chống lại sự kiểm duyệt.
Phân cấp trình tự sắp xếp L2 và sự đồng thuận (Tùy chọn): Trình tự sắp xếp đơn lẻ, PoA, Lựa chọn nhà lãnh đạo PoS, Đồng thuận PoS, Đấu giá MEV, Dựa trên tổng số, Bằng chứng về hiệu quả, v.v.
Shared Sequencer & X-Chain Atomicity: Đây thực sự là một công cụ mới thú vị.

MEV-Aware Design: Tôi sẽ mô tả ngắn gọn một số biến thể của FCFS. Về nhóm bộ nhớ được mã hóa, bạn có thể tham khảo bài viết gần đây của tôi.

Rollup hoạt động như thế nào?

Tổng hợp hợp đồng thông minh (SCR)

Đầu tiên, một đánh giá ngắn gọn về SCR củanguyên tắc làm việcnguyên tắc làm việc

. Rollup được sử dụng trên Ethereum ngày nay đều là SCR. Ở cấp độ cao, SCR về cơ bản chỉ là:
Mảng đầu vào được sắp xếp theo thứ tự (trên L1, vì vậy dữ liệu giao dịch phải được xuất bản trên lớp dữ liệu sẵn có)
Đầu ra xác định dựa trên đầu vào (Chuỗi khối cuộn lên)

Mô tả hình ảnh

Nguồn: Tổng số thực sự hoạt động như thế nào - Kelvin Fichter https://www.youtube.com/watch?v=NKQz 9 jU 0 ftg

Cụ thể hơn, những người đặt hàng truyền thống gửi các khối Tổng số bằng cách xuất bản dữ liệu cuộc gọi và gốc trạng thái của họ tới các hợp đồng thông minh L1 được liên kết của họ và các khối mới được thêm vào đầu Tổng số. Hợp đồng trên chuỗi chạy ứng dụng khách nhẹ của Rollup, tiết kiệm hàm băm tiêu đề khối. Hợp đồng được xác nhận đã giải quyết khi nhận được bằng chứng hợp lệ hoặc sau khi kết thúc cửa sổ chứng minh gian lận. Nếu một khối ORU chưa hoàn thiện không hợp lệ, thì khối đó (và tất cả các khối tiếp theo) có thể bị loại bỏ bằng cách gửi bằng chứng gian lận về chuỗi khôi phục. Đã được chứng minh để giúp bảo vệ các cầu nối chuỗi chéo:

Gửi gói giao dịch nên yêu cầu một số loại tiền gửi bảo đảm để ngăn chặn hành vi nguy hiểm. Nếu một gói giao dịch gian lận được gửi (ví dụ: gốc trạng thái không hợp lệ), khoản tiền gửi sẽ bị đốt cháy và một số sẽ được phân phối cho kẻ thách thức đã gian lận bằng chứng.SCR có"Hợp nhất sự đồng thuận

” — một giao thức đồng thuận có thể kiểm chứng trên chuỗi. Đồng thuận tổng số có thể chạy hoàn toàn trong các hợp đồng thông minh L1. Nó không ảnh hưởng đến cơ chế đồng thuận của chuỗi chính, cũng như không yêu cầu bất kỳ sự hỗ trợ nào từ cơ chế đồng thuận của chuỗi chính.

Các giao thức đồng thuận phi tập trung thường bao gồm bốn tính năng chính (lưu ý rằng đây là sự đơn giản hóa và không minh họa rõ ràng giao thức đồng thuận đầy đủ, ví dụ: không có người lãnh đạo):
Chức năng hiệu lực khối - chức năng chuyển đổi trạng thái. Tính hợp lệ của khối được thực thi ngoài chuỗi, thông qua bằng chứng về tính hợp lệ hoặc bằng chứng gian lận.
Quy tắc lựa chọn ngã ba - cách chọn giữa hai chuỗi hợp lệ khác. Rollup được thiết kế để đạt được sự tự do rẽ nhánh bằng cách xây dựng, vì vậy các quy tắc lựa chọn rẽ nhánh không bắt buộc phải có.
Thuật toán lựa chọn leader - người được phép thêm khối mới vào blockchain.

Tấn công chống Sybil - PoW, PoS, v.v.

Cho rằng 1 và 2 vẫn còn gây tranh cãi, yêu cầu tối thiểu đối với một người đặt hàng phi tập trung là một số hình thức kháng cự Sybil + bầu chọn thủ lĩnh. Fuel Labs đã nghiên cứu vấn đề này và họ lập luận rằng PoS:
Không nên áp dụng cho Rollup có giao thức đồng thuận đầy đủ (trong đó người xác thực/người đặt hàng sẽ bỏ phiếu cho các khối)

Chỉ nên được sử dụng để lựa chọn người lãnh đạo trong Rollup

Ngoài ra còn có những lập luận tốt về lý do tại sao bạn nên có sự đồng thuận cục bộ L2, sẽ nói thêm về điều đó sau.

Rollup có chủ quyền (SR)

Bản tổng hợp có chủ quyền vẫn xuất bản dữ liệu giao dịch lên L1 để biết tính khả dụng và đồng thuận của dữ liệu (DA), nhưng chúng xử lý "quyết toán" phía khách hàng trong Bản tổng hợp. Các lớp DA cho bạn biết rằng dữ liệu tồn tại, nhưng chúng không xác định chuỗi chuẩn cho Tổng số:
SR - Không có hợp đồng thông minh L1 xác định chuỗi Rollup "chính tắc". Chuỗi Rollup Canonical có thể được xác định bởi chính các nút Rollup (kiểm tra L1 DA, sau đó xác minh cục bộ các quy tắc lựa chọn ngã ba).

Mô tả hình ảnh

Nguồn: CelestiaTrên một lưu ý liên quan: Có một lập luận thú vị rằng không có chuỗi chính tắc toàn cầu (chỉ cây cầu quyết định chuỗi nào được coi là chính tắc). đây là mộtphản biện, những người khác về sự đánh đổi của Rollup trước chủ quyền và khả năng kết hợpchủ đề twitter. Tôi khuyến khích bạn sàng lọc thông tin này, cũng như tìm hiểu về các。

đâyđây。

máy phân loại phi tập trung

Các giao dịch bắt buộc do người dùng bắt đầu bao gồm

Tổng hợp hợp đồng thông minh

Như đã đề cập ở trên, trình sắp xếp thứ tự thường chịu trách nhiệm đối với các giao dịch theo lô và xuất bản chúng lên hợp đồng thông minh L1. Tuy nhiên, người dùng cũng có thể trực tiếp chèn một số giao dịch vào hợp đồng:

Tất nhiên điều này là không hiệu quả và tốn kém, vì vậy người đặt hàng sẽ đóng gói các giao dịch và cam kết chúng lại với nhau. Điều này khấu hao chi phí cố định trên nhiều giao dịch và cho phép nén dữ liệu tốt hơn:

Trình sắp xếp thứ tự hứa hẹn cuối cùng sẽ xuất bản các giao dịch này trên L1, trong khi chúng tôi có thể tính toán đầu ra để xác nhận mềm:

Đầu ra được hợp nhất hơn nữa khi trình sắp xếp thứ tự xuất bản các giao dịch này lên L1:

Thông thường, người dùng sẽ chỉ bao gồm các giao dịch khi chuyển tiền từ L1 sang L2. Điều này đóng vai trò là đầu vào cho hợp đồng L1, cho L2 biết rằng nó có thể đúc tài sản trên L2 được hỗ trợ bởi tài sản bị khóa trên L1.

Nếu tôi muốn trả lại tiền của mình cho L1, tôi có thể hủy nó trên L2 và yêu cầu L1 trả lại tiền cho tôi. L1 không biết chuyện gì đã xảy ra với L2, vì vậy L1 cần gửi bằng chứng và yêu cầu mở khóa tiền của tôi trên L1.

Bởi vì tôi đến từ L2, bộ sắp xếp có thể bắt đầu yêu cầu rút tiền này và gửi nó tới L1. Tuy nhiên, bây giờ bạn tin tưởng vào khả năng chống kiểm duyệt (CR) của bộ phân loại L2. Bạn không còn được đảm bảo như trên L1 nữa, có thể họ không thích bạn hoặc người đặt hàng ngừng hoạt động và tài sản của bạn ở trên L2 mãi mãi.Rollup có thể thêm khả năng chống kiểm duyệt của riêng mình tại địa phương thông qua các biện pháp khác nhau. Điều này có thể bao gồm việc thiết lập sự đồng thuận L2 với giá trị cổ phần cao,bao gồm danh sách

Một số biến thể của , thêm mã hóa ngưỡng, v.v. để giảm thiểu khả năng kiểm duyệt người dùng L2. Đây đều là những phương pháp hay, nhưng lý tưởng nhất là chúng tôi cũng muốn người dùng L2 có được các đảm bảo chống kiểm duyệt giống như L1.

Nếu người dùng bị kiểm duyệt, họ cần một số cách để buộc thoát khỏi Rollup hoặc buộc giao dịch của họ vào L2. Đây là lý do tại sao người dùng L2 nên duy trì khả năng, ví dụ, bắt buộc đưa trực tiếp các giao dịch L2 của họ vào hợp đồng L1. Ví dụ: người dùng bị kiểm duyệt có thể gửi gói giao dịch một thao tác trực tiếp tới chính L1.

Nguồn: Nghiên cứu về Starknet Escape HatchĐiều này không lý tưởng nếu tùy chọn duy nhất cho người dùng L2 là buộc các giao dịch trực tiếp đến L1. Điều này không thân thiện với nhiều người dùng có giá trị thấp, đặc biệt khi tương tác với L1 ngày càng trở nên đắt đỏ. Một thiết kế nâng cao hơn có thể khắc phục hạn chế này bằng cách buộc các giao dịch nguyên tử giữa các lần Rollup. Ở đây Kalman Lajkó tiến hành một cuộc biểu tình hấp dẫn, mà tôi thực sự khuyên bạn nên đọc. Nó hy vọng sẽ cho phép các giao dịch bắt buộc Rollup chéo trong các hệ thống có lớp DA và bộ chứng minh được chia sẻ.

Rollup có chủ quyền

Rollup có chủ quyềnCác cơ chế bao gồm bắt buộc của Sovereign Rollup hoạt động khác và như đã lưu ý trước đó, chúng thực thi các quy tắc lựa chọn ngã ba khác với SCR (Sovereign Labs đã xuất bản trong）。

bài đăng tuyệt vời

Trong SCR, hợp đồng thông minh L1 thực thi các quy tắc lựa chọn fork của Rollup. Ngoài việc xác thực bằng chứng ZK, nó cũng kiểm tra xem bằng chứng có được xây dựng dựa trên các bằng chứng trước đó không (trái ngược với các fork khác) và nó đã xử lý tất cả các giao dịch bắt buộc có liên quan được gửi trên L1.

SR có thể xuất bản bằng chứng ZK của họ lên lớp L1 DA để tất cả mọi người xem dưới dạng calldata/blobs (ngay cả khi L1 không xác thực chúng). Sau đó, bạn chỉ cần thêm một quy tắc rằng bằng chứng mới chỉ hợp lệ nếu có bằng chứng hợp lệ trước đó. Quy tắc này có thể được thực thi ở phía máy khách, nhưng nó sẽ yêu cầu người dùng quét lịch sử của chuỗi.

Calldata có thể được liên kết trở lại tiêu đề khối L1 và có thể thêm một câu lệnh có nội dung "Tôi đã quét các bằng chứng của lớp DA (bắt đầu từ khối X và kết thúc ở khối Y) và bằng chứng này được xây dựng dựa trên hợp lệ gần đây nhất bằng chứng". Điều này chứng minh quy tắc lựa chọn ngã ba trực tiếp trong bằng chứng, thay vì thực thi nó ở phía khách hàng.

Vì bạn đã quét bằng chứng nên bạn cũng có thể chứng minh rằng bạn đã quét mọi giao dịch bắt buộc. Bất kỳ ai cũng có thể xuất bản các giao dịch bắt buộc trực tiếp lên lớp L1 DA khi cần.

Hệ thống cấp bậc của giao dịch cuối cùng và ZK Fast Finality

Việc xác minh bằng chứng trên chuỗi trên Ethereum thường rất tốn kém, vì vậy các ZKR hiện tại (chẳng hạn như StarkEx) có xu hướng phát hành STARK cho Ethereum cứ sau vài giờ. Các bằng chứng có xu hướng phát triển rất chậm so với số lượng giao dịch, vì vậy việc chia theo lô này có thể giúp tiết kiệm chi phí đáng kể. Tuy nhiên, thời gian hoàn thiện dài như vậy không phải là một trải nghiệm lý tưởng cho người dùng.

Nếu Rollup chỉ xuất bản sự khác biệt về trạng thái trên chuỗi (chứ không phải dữ liệu giao dịch đầy đủ), thì ngay cả các nút đầy đủ cũng không thể đảm bảo tính hữu hạn nếu không có bằng chứng. Nếu dữ liệu giao dịch đầy đủ của Rollup được đăng trên chuỗi, thì ít nhất bất kỳ nút đầy đủ nào cũng có thể làm điều đó với L1.

Thông thường, các nút nhẹ sẽ chỉ dựa vào người đặt hàng tập trung để xác nhận mềm. Tuy nhiên, ZKR có thể nhanh chóng tạo và phân phối bằng chứng ZK trong lớp p2p để tất cả các ứng dụng khách nhẹ có thể xem trong thời gian thực, đồng thời cung cấp cho chúng tính hữu hạn ở tốc độ L1. Sau đó, những bằng chứng này có thể được đóng gói đệ quy và xuất bản lên L1.

Đây là những gì Sovereign Labs dự định thực hiện và tương tự, Scroll có kế hoạch xuất bản các bằng chứng ZK trung gian trên chuỗi (nhưng không xác minh chúng), vì vậy các ứng dụng khách nhẹ có thể đồng bộ hóa khá nhanh. Theo cả hai cách, Rollup có thể bắt đầu hoàn thành ở tốc độ L1 thay vì chờ đợi để tiết kiệm chi phí xăng. Lưu ý rằng trong cả hai trường hợp, bạn chỉ giảm thời gian hoàn tất xuống mức tối thiểu (tốc độ L1).

Không có bộ sắp xếp nào đạt được kết quả cuối cùng nhanh hơn L1. Điều tốt nhất mà một thiết kế trình đặt hàng khác có thể làm là cung cấp cho bạn xác nhận trước nhanh hơn L1 với các mức độ chắc chắn khác nhau (ví dụ: xác nhận trước cho L2 với bộ đồng thuận phi tập trung nhanh hơn một thiết bị đặt hàng đáng tin cậy duy nhất đáng tin cậy hơn).Patrick McCorry gần đây cũng đã giao dịch cho Rollupmức độ hoàn thiện

Cung cấp một cái nhìn tổng quan tốt.
Có nhiều mức độ "kết thúc" giao dịch khác nhau tùy thuộc vào người cam kết với bạn (và cấu trúc tổng số là gì)

Các tác nhân khác nhau nhận thức được "sự thật" khác nhau tại một thời điểm nhất định (ví dụ: máy khách nhẹ L2, nút đầy đủ và hợp đồng thông minh L1 sẽ nhận thức được cùng một "sự thật" tại các thời điểm khác nhau)

máy phân loại đơn

Hầu hết các Rollup hiện tại đều có trình sắp xếp để gửi các gói giao dịch. Nó cải thiện hiệu quả, nhưng cũng mang lại ít khả năng chống kiểm duyệt và sống động theo thời gian thực hơn. Với các biện pháp bảo vệ thích hợp tại chỗ, điều này có thể được chấp nhận đối với nhiều trường hợp sử dụng:
Chống kiểm duyệt: Một cơ chế bao gồm các giao dịch do người dùng thực thi, như được mô tả ở trên.

Liveness: Một số loại tùy chọn dự phòng nóng khả dụng nếu người đặt hàng chính không thành công (tương tự cung cấp bản sao lưu cho chứng minh ZKR, trong khi chứng minh gian lận ORU không được phép). Bất kỳ ai cũng có thể tham gia nếu trình sắp xếp dự phòng cũng bị lỗi.

Ví dụ: những người đặt hàng thay thế có thể được bầu chọn theo cơ chế quản trị Rollup và người dùng có được sự bảo mật, khả năng chống kiểm duyệt và sự sống động. Ngay cả trong thời gian dài, một trình sắp xếp chuỗi hoạt động duy nhất là một lựa chọn khả thi.

Cơ sở có thể là sự khởi đầu của một xu hướng mới. Giờ đây, các công ty có thể quản lý và tối ưu hóa sản phẩm của họ một cách hào hứng cũng như hào hứng với chuỗi khối doanh nghiệp nhảm nhí, nhưng nó thực sự có thể là một chuỗi không được phép, an toàn và có thể tương tác ngay bây giờ.

Cuối cùng, Base dự định phân cấp tập hợp các bộ sắp xếp của họ, nhưng vấn đề là họ không nhất thiết phải làm điều này (hoặc họ có thể làm trong phạm vi rất hạn chế, ví dụ: các bộ sắp xếp nhỏ). Rõ ràng, điều này yêu cầu Rollup thực hiện các bước cần thiết để đảm bảo nó thực sự an toàn và duy trì khả năng chống kiểm duyệt (xóa mọi nâng cấp tức thời, thực thi bằng chứng về độ tin cậy, thực thi bao gồm giao dịch, đấu giá MEV, v.v.).

Đây sẽ là một cải tiến lớn so với các dịch vụ tập trung/lưu ký, không phải là sự thay thế cho các dịch vụ phi tập trung lớn nhất. Rollup chỉ đơn giản là mở rộng không gian thiết kế. Đây cũng là lý do chính khiến hầu hết các nhóm Rollup không đặt ưu tiên hàng đầu cho việc phân cấp người đặt hàng - các dự án khác chú trọng hơn vào bảo mật người dùng, khả năng chống kiểm duyệt và ít tin tưởng hơn vào các nhà điều hành Rollup.

Tuy nhiên, điều này vẫn không lý tưởng nếu người dùng/các bên khác cần can thiệp để duy trì hoạt động và "chống kiểm duyệt theo thời gian thực" (so với "chống kiểm duyệt cuối cùng", ví dụ: buộc giao dịch qua L1). Tùy thuộc vào cơ chế bao gồm giao dịch bắt buộc, sự can thiệp của người dùng có giá trị thấp có thể tốn kém hoặc không thực tế. Các bản tổng hợp có ưu tiên cao về khả năng chống kiểm duyệt theo thời gian thực và đảm bảo tối đa về tính sống động sẽ tìm cách phi tập trung hóa. Cũng có thể có những cân nhắc về quy định khi vận hành một trình giải mã trình tự được cấp phép duy nhất.

Bằng chứng về thẩm quyền (PoA)

Một cải tiến ngay lập tức so với một máy phân loại duy nhất là cho phép một số lượng nhỏ các máy phân loại được phân phối theo địa lý. Máy phân loại có thể được xoay một cách đơn giản và việc tạo kết nối giữa chúng sẽ giúp khuyến khích hành vi trung thực.

Khái niệm này không còn quá xa lạ - các cầu nối đa chữ ký thường có một số ít công ty đáng tin cậy hoặc các ủy ban tương tự, chẳng hạn như AnyTrust DA của Arbitrum. Nhưng quan trọng là, chúng có ít quyền lực hơn ở đây (bạn không dựa vào các trình đặt hàng Rollup để bảo mật, không giống như cách các nhà khai thác cầu nối chuỗi chéo đa chữ ký rút tiền bị khóa). Nhìn chung, kế hoạch này tốt hơn trong khả năng chống kiểm duyệt và sống động hơn so với đơn đặt hàng, nhưng vẫn chưa hoàn hảo.

Đấu giá Sorter hay còn gọi là Đấu giá MEV (MEVA)

Rollup cũng có thể chạy Đấu giá MEV (MEVA) trực tiếp thông qua hợp đồng thông minh, thay vì chỉ định quyền xếp hạng dựa trên cổ phần. Bất kỳ ai cũng có thể đấu giá quyền đặt hàng của các giao dịch và hợp đồng đấu giá trao quyền đặt hàng cho người trả giá cao nhất. Điều này có thể được thực hiện cho từng khối hoặc trong một khoảng thời gian dài (ví dụ: đấu thầu quyền trở thành người đặt hàng vào ngày hôm sau). Người sắp xếp chiến thắng vẫn phải nộp một khoản cam kết đảm bảo các hình phạt nếu sau đó họ gặp trục trặc hoặc hành động ác ý.

Nguồn: Phân cấp của ZK Rollup

Trên thực tế, MEVA bên ngoài giao thức là kết quả tự nhiên nhất nếu phiên đấu giá không được tích hợp trực tiếp vào giao thức. Nếu quyền phân loại được xác định dựa trên trọng số cổ phần, thì một số dạng hệ thống đấu giá kiểu MEV-Boost/PBS sẽ xuất hiện, tương tự như những gì chúng ta thấy ngày nay trên L1 Ethereum. Trong trường hợp này, phí/MEV có thể được phân phối cho những người đặt cược. Nếu phiên đấu giá được tích hợp vào giao thức, thì các khoản phí/MEV có thể sẽ được chuyển đến một số dạng kho bạc Rollup DAO.

PoS không cần cấp phép cho cuộc bầu cử lãnh đạo

Bạn có thể tham gia với tư cách là trình sắp xếp thứ tự mà không cần được phép, nhưng bạn phải đặt cọc mã thông báo (có thể là mã thông báo gốc của L2). Cơ chế đặt cược có thể được xây dựng trên lớp cơ sở thông qua hợp đồng thông minh hoặc trực tiếp trong Rollup. Bạn có thể sử dụng PoS này kết hợp với một số dạng ngẫu nhiên trên chuỗi để lựa chọn người dẫn đầu, giống như bất kỳ L1 nào. Xác suất bạn đặt mua một khối = phần của bạn trong tổng số cổ phần. Hình phạt có thể được áp dụng đối với trình tự sai/độc hại thông qua dấu gạch chéo, v.v.

Lưu ý rằng điều này không yêu cầu những người đặt hàng phải đạt được sự đồng thuận vì những lý do trên. Tổng số sử dụng L1 cho sự đồng thuận, vì vậy không cần có sự đồng thuận cục bộ. Đặt cược xác định những người đặt hàng nào có thể đề xuất các khối, nhưng họ không bắt buộc phải bỏ phiếu cho các khối do những người đặt hàng khác đề xuất.

Dymension

Quyền đặt hàng cũng có thể được cấp trong bất kỳ khoảng thời gian nào. Bạn có thể có quyền truy cập để sắp xếp 100 khối Tổng số liên tiếp hoặc 1000, v.v. Các chu kỳ dài hơn có thể hiệu quả hơn và chỉ yêu cầu một bộ giải trình tự tại một thời điểm nhất định. Tuy nhiên, việc trao độc quyền mở rộng có thể có những tác động bên ngoài khác.

Dymension là một dự án đưa những ý tưởng này vào thực tế. Dymension Hub sẽ là phần lớn PoS L1 trung thực điển hình trong Cosmos. L2 của nó ("RollApps") sẽ sử dụng nó để giải quyết và đồng thuận, trong khi dựa vào Celestia cho DA (vì vậy những L2 đó thực sự là "Chuỗi lạc quan", không phải "Rollups").Litepapertheo họ

, phân loại RollApp phi tập trung sẽ cần thế chấp DYM (tài sản gốc của Dymension) trên Dymension Hub. Việc lựa chọn nhà lãnh đạo sau đó phụ thuộc vào số lượng DYM tương đối được đặt. Các Sequencer này sẽ nhận được doanh thu (phí và MEV khác) từ Rollup tương ứng của họ, sau đó thanh toán các chi phí liên quan cho Dymension Hub và Celestia.

Do cơ chế này, hầu hết tất cả giá trị thu được trong ngăn xếp này được tích lũy trực tiếp vào mã thông báo DYM. Các bản tổng hợp sắp xếp bằng cách sử dụng mã thông báo gốc của riêng chúng (như StarkNet dự định thực hiện với STRK) sẽ tăng thêm giá trị cho mã thông báo của chính chúng. Cài đặt này truyền cảm hứng cho một câu hỏi: Ethereum Rollup có thể chỉ sử dụng ETH cho cuộc bầu cử sắp xếp không?

Theo tôi, điều này làm giảm đáng kể động cơ triển khai L2 trên lớp giải quyết như vậy. Hầu hết các nhóm L2 đều muốn mã thông báo của riêng họ tạo ra giá trị có ý nghĩa (thay vì chỉ được sử dụng để trả phí).

PoS không cần cấp phép cho cuộc bầu chọn lãnh đạo và sự đồng thuận L2

Đặt cược L2 cũng có thể được sử dụng để bầu chọn người đặt hàng và sự đồng thuận của địa phương nếu muốn. Đây chính xác là mô hình mã thông báo của gói StarkNet (STRK):
Đồng thuận PoS: Khuyến khích các trình xác nhận L2 đạt được sự đồng thuận L2 tạm thời trước khi hoàn thiện L1, mang lại sự xác nhận trước mạnh mẽ hơn. Đó không phải là một yêu cầu nghiêm ngặt, nhưng đó là một lựa chọn hấp dẫn.

Ngoài ra, STRK có thể được sử dụng dưới một số hình thức để:

Ngoài ra, STRK có thể được sử dụng dưới một số hình thức để:
Bằng chứng: Khuyến khích người tục ngữ tạo ra STARK.

Quy trình giao dịch như sau:

Quy trình giao dịch như sau:
Sắp xếp: bộ sắp xếp sắp xếp các giao dịch và cam kết một khối
Đồng thuận L2: Giao thức đồng thuận StarkNet ký các khối được đề xuất
Sản xuất bằng chứng: Prover tạo ra bằng chứng cho các khối được đồng thuận

Cập nhật trạng thái L1: Bằng chứng được gửi tới L1 để cập nhật trạng tháiĐể biết thêm chi tiết về chương trình StarkNet, bạn có thể tham khảo bài viết này。

bưu kiện

Đồng thuận L2 hay chỉ đồng thuận L1?

L2 có thể hoặc không thể triển khai sự đồng thuận cục bộ của riêng mình (nghĩa là trình xác thực L2 ký các khối của họ trước khi gửi dữ liệu tới L1 để có sự đồng thuận cuối cùng). Ví dụ: hợp đồng thông minh L1 có thể học hỏi từ các quy tắc của nó:
PoS cho bầu chọn lãnh đạo và sự đồng thuận: "Tôi chỉ có thể chấp nhận các khối được ký bởi sự đồng thuận L2."

PoS cho cuộc bầu chọn người lãnh đạo: "Đây là người đặt hàng đã chọn và các khối được phép cam kết tại thời điểm này."

Tổng hợp Nếu không có sự đồng thuận cục bộ, điều bạn cần làm là:
Làm cho các đề xuất chặn Tổng số không được phép.
Tạo một số tiêu chí để chọn khối tốt nhất để xây dựng cho một chiều cao nhất định
Có các nút hoặc hợp đồng thanh toán thực thi các quy tắc lựa chọn ngã ba

Kế thừa sự đồng thuận và tính hữu hạn từ L1

Lưu ý rằng trong cả hai trường hợp, giá trị của L2 có thể được tích lũy thành mã thông báo Rollup. Mặc dù mã thông báo L2 chỉ được sử dụng cho một số hình thức lựa chọn người lãnh đạo (không phải biểu quyết đồng thuận), giá trị của quyền đặt hàng vẫn được tích lũy cho mã thông báo L2.

Hạn chế của sự đồng thuận L2

Bây giờ, hãy thảo luận về sự đánh đổi của việc có/không có sự đồng thuận cục bộ trước L1.Một đề xuất của nhóm Fuel Labslý lẽNgười ta tin rằng sự đồng thuận L2 sẽ làm giảm khả năng chống kiểm duyệt. "Điều này cho phép phần lớn những người xác thực xem xét các khối mới, điều đó có nghĩa là tiền của người dùng có thể bị đóng băng. Không cần PoS để bảo mật Rollup, vì Rollup được bảo mật bởi Ethereum." Như đã đề cập trước đó, ngay cả những người đặt lệnh kiểm duyệt vẫn có thể cung cấp khả năng chống kiểm duyệt (ví dụ: buộc các giao dịch chuyển trực tiếp đến L1 hoặcthiết kế phức tạp hơnKalman Lajkó,Ví dụ

thiết kế đang nghiên cứu).

Một cách khác để nói điều này là việc đạt được sự đồng thuận hoàn toàn là "không hiệu quả". Ví dụ, trường hợp cũ dưới đây có vẻ dễ dàng hơn:
Một trình sắp xếp chính chạy mọi thứ cùng một lúc.

Trong một khoảng thời gian, người đặt hàng chính điều hành mọi thứ, sau đó tất cả các nút khác cần bỏ phiếu và đồng ý.

VàđâyVàđâyđây

Như đã nêu, một số người đã bày tỏ lo ngại về việc sử dụng PoS trong phân cấp người đặt hàng. Sự phức tạp của L1 và L2 có thể khiến việc đối phó với một số kiểu tấn công trở nên khó khăn hơn.

Ưu điểm của Đồng thuận L2

Có lẽ mục tiêu lớn nhất của trình sắp xếp thứ tự là cung cấp cho người dùng xác nhận mềm nhanh hơn trước sự an toàn và bảo mật đầy đủ của L1. Kiểm tra cơ chế của StarkNet:

"Tính cuối cùng của L2 mạnh mẽ và nhanh chóng - Trạng thái StarkNet chỉ trở thành cuối cùng sau khi gói giao dịch được chứng minh L1 (có thể mất hàng giờ). Do đó, các giao thức phi tập trung L2 nên thực thi trước khi gói giao dịch tiếp theo được chứng minh để thực hiện các cam kết có ý nghĩa."Sự đồng thuận được hỗ trợ bởi an ninh kinh tế của những người đặt hàng nhiều giúp cung cấp：

đảm bảo mạnh mẽ hơn

“Sự đồng thuận của Starknet phải chịu trách nhiệm giải trình, vì các hành vi vi phạm an toàn và tính sống động đều bị trừng phạt, cũng như bất kỳ bộ phận nào của người tham gia (bao gồm cả phần lớn độc hại).”

Rollup cũng có tính linh hoạt để thử nghiệm với các sự đánh đổi khác nhau trong phạm vi tùy chọn cơ chế đồng thuận, vì cuối cùng chúng luôn có thể quay trở lại với sự an toàn và tính khả dụng năng động của Ethereum L1.

Tổng số được sắp xếp trong L1

Các Rollup ở trên đều xây dựng các bộ sắp xếp cụ thể để tạo các khối Rollup ở dạng nào đó. Ví dụ: PoS có thể tham gia mà không được phép, nhưng tại một vị trí nhất định, chỉ những người đặt hàng L2 được chọn mới có thể gửi khối. Ngoài ra còn có các lược đồ liên quan không dựa vào bất kỳ bộ sắp xếp L2 nào, chúng sắp xếp các giao dịch thông qua chính L1.

hoàn toàn vô chính phủVitalik đã đề xuất điều này "hoàn toàn vô chính phủ

” suy nghĩ. Bất cứ ai cũng có thể gửi một gói giao dịch bất cứ lúc nào. Nó đáp ứng hai yêu cầu tối thiểu đối với một bộ phân loại phi tập trung đã thảo luận ở trên:
Khả năng chống Sybil: Khả năng chống Sybil (tức là phí giao dịch và kích thước khối/giới hạn gas) được cung cấp bởi L1.

Lựa chọn nhà lãnh đạo: Việc lựa chọn nhà lãnh đạo được thực hiện sau khi thực tế.

Điều này là đủ vì L1 đã cung cấp bảo mật. Nếu các khối L2 đã được xuất bản lên L1, chúng sẽ chỉ bị bỏ qua nếu chúng không hợp lệ hoặc được xây dựng trên các khối không hợp lệ (sẽ được khôi phục). Nếu chúng hợp lệ và được xuất bản lên L1, thì chúng có cùng độ bảo mật như chính L1.

Based Rollup

Vitalik đã chỉ ra một vấn đề quan trọng: sự kém hiệu quả. Nhiều người tham gia có khả năng gửi các gói giao dịch song song, nhưng chỉ một người có thể được đưa vào thành công. Điều này lãng phí rất nhiều nỗ lực tạo bằng chứng và/hoặc lãng phí gas khi xuất bản các gói giao dịch lên chuỗi.

Tuy nhiên, PBS hiện có thể làm cho thiết kế vô chính phủ này trở nên khả thi. Nó cho phép đặt hàng thường xuyên hơn, với tối đa một khối Tổng số trên mỗi khối L1 và không lãng phí Gas (mặc dù tài nguyên máy tính có thể bị lãng phí). Trình tạo khối L1 chỉ có thể bao gồm khối Tổng số có giá trị cao nhất và tạo khối dựa trên giá thầu do người tìm kiếm nhập, tương tự như bất kỳ khối L1 nào. Có thể hợp lý khi Z cho phép chứng minh ZK theo mặc định, để tránh lãng phí tính toán.Justin DrakeĐây làBased RollupsĐề xuất gần đây "

"Ý tưởng cốt lõi đằng sau đề xuất. Anh ấy sử dụng thuật ngữ này để chỉ một Rollup trong đó các giao dịch được sắp xếp theo L1 (lớp "cơ sở"). Những người đề xuất L1 chỉ cần đảm bảo rằng họ bao gồm các khối Tổng số trong các khối L1 của họ. Sơ đồ đơn giản này có thể ngay lập tức có sự sống động và phân cấp L1. Họ bỏ qua các vấn đề phức tạp như giải quyết việc đưa giao dịch bắt buộc vào trường hợp kiểm duyệt người đặt hàng L2. Ngoài ra, chúng loại bỏ một số chi phí gas vì không cần xác minh chữ ký của người phân loại.

Một câu hỏi thú vị là các giao dịch L2 này được xử lý ở đâu. Máy khách L2 cần gửi các giao dịch này ở đâu đó để người tìm kiếm/người xây dựng L1 có thể nhận chúng và tạo khối và khối. Chúng có thể được gửi đến:

L1 Mempool - Chúng có thể được gửi cùng với một số siêu dữ liệu đặc biệt mà những người tìm kiếm/nhà xây dựng "có hiểu biết" có thể diễn giải. Tuy nhiên, điều này có thể làm tăng tải trên nhóm bộ nhớ L1.

L2's p2p Mempools - Dòng suy nghĩ này có vẻ dễ hiểu hơn. Người tìm kiếm/người xây dựng sẽ bắt đầu kiểm tra và giải thích những điều này ngoài các kênh thông thường.

Một nhược điểm rõ ràng ở đây là Bản tổng hợp dựa trên giới hạn tính linh hoạt của bộ sắp xếp. Ví dụ:

Giảm MEV: Rollup có thể sáng tạo với các biến thể của FCFS, nhóm bộ nhớ được mã hóa, v.v.Xác nhận trước: Người dùng L2 thích "xác nhận" giao dịch nhanh. Thời gian "xác nhận" của giao dịch Tổng số dựa trên sẽ giảm xuống bằng với L1 (12 giây), hoặc chờ một thời gian lâu hơn trước khi。

Xuất bản gói giao dịch hoàn chỉnh

Thật thú vị, đây chính xác là những gì nhóm Rollup ban đầu đang làm:

Đây là những lĩnh vực nghiên cứu xung quanh EigenLayer, ít nhất là tronggiấy trắnggiấy trắng

đề cập trong. Không rõ liệu một giải pháp như vậy có thực sự giải quyết được vấn đề hay không. Để đặt lại có hiệu quả cải thiện những thiếu sót này, có thể mong muốn rằng tất cả những người đặt cược chọn chạy nó. Có vẻ hợp lý hơn khi mô phỏng ý tưởng này bằng cách yêu cầu những người đặt cược muốn thực hiện việc này vào một lớp đặt hàng được chia sẻ riêng biệt (sẽ nói thêm về điều đó sau).

Năm ngoái, Polygon Hermez đã đề xuất một dự án có tên là PoEđề xuất. Đây là một biến thể khác của ZK Rollup dành riêng cho sắp xếp L1. Điều phối viên ở đây là một vai trò hoàn toàn mở, nơi bất kỳ ai cũng có thể gửi các gói giao dịch (tức là hoàn toàn hỗn loạn). PoE có hai bên và quy trình được chia thành hai bước:

người phân loại

Trình sắp xếp thứ tự thu thập các giao dịch của người dùng L2 và tạo các gói giao dịch bằng cách gửi các giao dịch L1 bao gồm tất cả dữ liệu giao dịch L2 đã chọn. Người đặt hàng sẽ cam kết các khối dựa trên giá trị kinh tế nhận được hoặc đạt được dịch vụ tốt hơn cho người dùng (ví dụ: xuất bản gói giao dịch trong mỗi khối L1, ngay cả khi điều này làm cho giao dịch L2 đắt hơn nhưng người dùng muốn giao dịch nhanh hơn).

Người sắp xếp sẽ trả phí L1 Gas để xuất bản các gói giao dịch và giao thức xác định các khoản phí bổ sung phải trả trong MATIC. Sau khi được xuất bản, gói giao dịch chiến thắng ngay lập tức xác định đỉnh mới của chuỗi và bất kỳ nút nào cũng có thể tính toán một cách xác định trạng thái hiện tại. Bằng chứng về tính hợp lệ sau đó được yêu cầu để hoàn thiện trạng thái của các ứng dụng khách nhẹ (bao gồm cả hợp đồng thông minh L1).

tổng hợp

Các công cụ tổng hợp ở đây là những người chứng minh ZK. Một lần nữa, đây là một vai trò không được phép mà bất kỳ ai cũng có thể tham gia. Thật đơn giản:
Các gói giao dịch được sắp xếp với dữ liệu giao dịch được sắp xếp trên L1 theo vị trí xuất hiện của chúng trên L1.

Hợp đồng thông minh PoE chấp nhận bằng chứng hợp lệ đầu tiên để cập nhật trạng thái hợp lệ, bao gồm một hoặc nhiều gói giao dịch được đề xuất chưa được chứng minh.

Người tổng hợp có thể tiến hành phân tích lợi ích chi phí để tìm ra tần suất chính xác để đưa ra bằng chứng. Nếu họ giành chiến thắng, họ sẽ nhận được một phần phí, nhưng việc chờ đợi lâu hơn để đưa ra bằng chứng mới sẽ khiến chi phí xác minh cố định của họ lan rộng hơn đối với nhiều giao dịch hơn. Nếu trình tổng hợp trì hoãn xuất bản bằng chứng (nó không chứng minh trạng thái mới), thì hợp đồng sẽ thực hiện thao tác hoàn nguyên. Provers lãng phí tài nguyên tính toán, nhưng chúng tiết kiệm phần lớn gas.

Phí được phân bổ như sau:
Phí từ các giao dịch L2 sẽ được xử lý và phân phối bởi các nhà tổng hợp, những người tạo ra bằng chứng về tính hợp lệ.
Phí đặt cọc của người đặt hàng để tạo gói giao dịch được gửi đến bộ tổng hợp, bao gồm gói giao dịch này trong một bằng chứng về tính hợp lệ.

Quy tắc lựa chọn ngã ba thuần túy

RollkitSR có một "Quy tắc lựa chọn ngã ba thuần túy“Các khái niệm nhưđâyđây

đã nói, đề cập đến một Rollup không có trình sắp xếp đặc quyền. Các nút được sắp xếp theo lớp DA và áp dụng quy tắc lựa chọn ngã ba là "đến trước được phục vụ trước".

Tính kinh tế của phân loại L1

Các thiết kế đặt hàng L1 này có ý nghĩa kinh tế quan trọng, vì MEV của các giao dịch L2 hiện sẽ được nắm bắt ở cấp nhà sản xuất khối L1. Trong mô hình đặt hàng L2 "truyền thống", MEV của các giao dịch L2 được nắm bắt bởi cơ chế đấu giá/người đặt hàng/người tham gia đồng thuận L2. Trong trường hợp này, không rõ có bao nhiêu MEV rò rỉ vào L1.

Cho dù điều này là một điều tốt hay điều xấu là khó nói:Điều tốt: một số người thích "Liên minh kinh tế L1
điều xấu: người khácLo lắngLo lắng

Các ưu đãi ở lớp cơ sở (ví dụ: rủi ro tập trung cho các công cụ khai thác Bitcoin).

Loại lược đồ này có thể có ý nghĩa, đặc biệt là phương pháp khởi động tổng số dễ dàng hơn, nhưng thật khó để thấy hầu hết các bản tổng hợp từ bỏ rất nhiều MEV cho L1. Một trong những lợi ích tuyệt vời của Rollup thực sự là lợi ích kinh tế - một khi DA bắt đầu mở rộng quy mô và chi phí giảm xuống, họ sẽ chỉ phải trả rất ít cho L1. Thời gian tạo khối chậm và cạm bẫy của phương pháp MEV đơn giản dường như cũng không tối ưu cho người dùng.

Bằng chứng ZK khuyến khích

Lưu ý rằng cuộc cạnh tranh PoE đã nói ở trên có thể xoay quanh công cụ tổng hợp nhanh nhất. Thị trường chứng minh ZK có hai vấn đề kinh tế cần giải quyết:
Làm thế nào để khuyến khích người chứng minh tạo ra bằng chứng

Làm thế nào để làm cho việc nộp chứng thực không cần giấy phép, làm cho nó trở thành một thị trường cạnh tranh và mạnh mẽ

Hãy xem xét hai mô hình đơn giản của thị trường chứng minh ZK:

thị trường cạnh tranh

Một thị trường không cần xin phép, nơi những người chứng minh cạnh tranh để tạo ra các bằng chứng cho các khối do bộ đối chiếu/đồng thuận Rollup tạo ra. Người đầu tiên tạo ra bằng chứng có thể nhận được bất kỳ phần thưởng nào được chỉ định cho người chứng minh. Mô hình tìm thấy hiệu quả chứng minh phù hợp nhất cho công việc.

Điều này trông rất giống với khai thác PoW. Tuy nhiên, có một sự khác biệt duy nhất ở đây: bằng chứng là các phép tính xác định. Kết quả là một người chứng minh có lợi thế nhỏ nhưng nhất quán so với những người chứng minh khác hầu như luôn thắng. Thì thị trường này dễ bị tập trung hóa.

Trong khai thác PoW, có kết quả tốt hơn về mặt ngẫu nhiên - nếu tôi có 1% sức mạnh khai thác, tôi sẽ được thưởng 1%.

Mô hình bằng chứng cạnh tranh này cũng không tối ưu về mặt dự phòng tính toán - nhiều người chứng minh sẽ cạnh tranh và sử dụng tài nguyên để tạo ra một bằng chứng, nhưng chỉ một người sẽ giành chiến thắng (tương tự như khai thác PoW).

Bằng chứng theo lượt

Chứng thực có thể được tạo luân phiên giữa các người chứng thực (ví dụ: dựa trên mã thông báo đã đặt cọc hoặc danh tiếng). Cách tiếp cận này có khả năng phi tập trung hơn, nhưng kém hiệu quả hơn về độ trễ của bằng chứng (trong đó một người chứng minh có thể tạo bằng chứng nhanh hơn và hiệu quả hơn, một người chứng minh "chậm" khác cũng có cơ hội tạo bằng chứng). Tuy nhiên, nó tránh lãng phí tài nguyên máy tính khi chỉ một người chứng minh có thể tạo ra một bằng chứng.

Hơn nữa, nếu người chứng minh không cung cấp bằng chứng trong vòng (cố ý hoặc vô ý), mạng sẽ gặp sự cố. Nếu các vòng này kéo dài (ví dụ: một công cụ chứng minh nhất định giành được độc quyền trong vài giờ) và công cụ chứng thực đi xuống, thì giao thức sẽ khó phục hồi. Nếu thời gian chuyển đổi người cung cấp dịch vụ ngắn, người cung cấp dịch vụ khác có thể thay thế.

Cũng có thể cho phép bất kỳ ai đưa ra bằng chứng, nhưng chỉ những người chứng minh được chỉ định mới có thể được thưởng trong một thời gian nhất định. Vì vậy, nếu người chứng minh hiện tại không thành công, người chứng minh khác có thể đưa ra bằng chứng, nhưng họ không nhận được phần thưởng. Đó là một hành động vị tha dành tài nguyên để tính toán mà không nhận lại được gì.

Scroll đang khám phá một cách tiếp cận theo lượt hơn, phân phối các lần thực thi cho các "con lăn" (người chứng minh) được chọn ngẫu nhiên:

Cuộn quy trình làm việc

Ngoài ra còn có nhiều câu hỏi thú vị, chẳng hạn như cách tính phí bằng chứng ở cấp độ người dùng khi phân loại. Thảo luận thêm về các chủ đề này có thể được tìm thấy ở đây:Ye Zhang của Scroll trong "Tổng hợp ZK phi tập trung
《Khả năng của một mạng theo lượt như vậy dựa trên đặt cược + đặt hàng MEVA sẽ được thảo luận trong bài viết"Cung cấp thêm thông tin chi tiết về mô hình con lăn
Starknet Decentralized Protocol IV - Proofs in the Protocol
Starknet Decentralized Protocol VI - The Buffer Problem

sắp xếp chung

Hầu hết các giải pháp ban đầu đều giả định rằng mỗi Rollup sẽ cần tự tìm ra cách phân cấp bộ sắp xếp của chúng. Như chúng ta đã thấy trong sơ đồ sắp xếp L1, không phải vậy. Nhiều Rollup có thể chọn một Shared Sequencer (SS). Lợi ích của việc làm này là:
Tiết kiệm công sức: Không cần lo lắng về việc phân cấp trình tự sắp xếp, không cần tuyển dụng và quản lý người xác minh. Đây là một cách tiếp cận rất "mô-đun" - loại bỏ thứ tự của các giao dịch. SS đúng nghĩa là một công ty SaaS (Sequencer as a Service).
Kết hợp Bảo mật và Phân cấp: Hãy để một lớp đặt hàng xây dựng bảo mật kinh tế mạnh mẽ (xác nhận trước mạnh mẽ hơn) và CR thời gian thực thay vì tạo nhiều ủy ban nhỏ cho từng Rollup riêng lẻ.
Giao dịch nhanh: Những người đặt hàng Tổng số đơn lẻ khác cũng có thể làm điều này, nhưng lưu ý rằng bạn vẫn nhận được những xác nhận trước siêu nhanh đó tại đây.

Tính nguyên tử của chuỗi chéo - các giao dịch được thực hiện đồng thời trên chuỗi A và chuỗi B. (Cái này phức tạp nên mình sẽ đi sâu hơn sau).

Như đã đề cập trước đó, việc chỉ sử dụng L1 gốc làm bộ sắp xếp cho L2 về cơ bản có một số nhược điểm:
Vẫn bị giới hạn bởi dữ liệu L1 và thông lượng đặt hàng giao dịch

Mất khả năng cung cấp các giao dịch nhanh dưới thời gian khối L1 cho người dùng L2

Điều tốt nhất mà thứ tự L1 có thể làm là loại bỏ nút cổ chai tính toán của L1 (nếu việc thực hiện giao dịch là nút cổ chai thông lượng) và đạt được những cải tiến về độ phức tạp của giao tiếp.

Vậy chúng ta có thể thiết kế một SS chuyên dụng và hiệu quả hơn thay vì để L1 làm việc đó không...

Metro - Máy sắp xếp dùng chung cho AstriaMetro là một sơ đồ của lớp SS. Bạn có thể tham khảo thêm của Evan Forbes、Modular Insights talkbài nghiên cứuShared Security Summit talkVà

Tìm hiểu thêm. Nhóm Astria do Josh Bowen lãnh đạo đang nghiên cứu giải pháp Metro.

Tách thực hiện và đặt hàng

Nút Tổng số hiện tại thực sự thực hiện ba việc:

Chìa khóa ở đây là sự tách biệt giữa thực thi và đặt hàng. Và sắp xếp được chia sẻ có thể làm:
Giao dịch đặt hàng cho nhiều chuỗi chọn sử dụng nó làm lớp đặt hàng

không thực hiện (hoặc chứng minh) các giao dịch này và tạo ra các trạng thái kết quả

Sắp xếp là không trạng thái. Các nút SS không còn cần lưu trữ trạng thái hoàn chỉnh của tất cả các Bản tổng hợp khác nhau, chúng loại bỏ phép tính thực thi và nút cổ chai khổng lồ mà các bộ sắp xếp truyền thống gặp phải sẽ biến mất tại đây.

Khi việc thực thi bị loại bỏ khỏi sự đồng thuận, hiệu quả trở nên rất cao. Nếu tất cả các nút phải làm là tạo ra một khối giao dịch được sắp xếp theo thứ tự và đồng ý về khối đó mà không thực hiện mọi thứ, thì chúng sẽ rất hiệu quả. Việc thực hiện và chứng minh có thể được thực hiện sau khi thực tế bởi các bên khác nhau.

Cả bảo mật trình tự và phân cấp

Các nút SS có thể vẫn tương đối nhẹ và thậm chí mở rộng quy mô theo chiều ngang (bằng cách chọn một tập hợp con ngẫu nhiên các nút đồng thuận để đặt hàng các tập hợp con giao dịch khác nhau). Lớp sắp xếp phân cấp hơn so với lớp sắp xếp truyền thống, lớp này cần nắm bắt trạng thái phức tạp của chuỗi và chịu trách nhiệm thực hiện.

Hơn nữa, bằng cách tổng hợp các tài nguyên trên nhiều chuỗi, thay vì chia nhỏ sự đồng thuận của PoS trên nhiều Rollup, tất cả chúng được tổng hợp ở một nơi. So với nhiều Rollup triển khai bộ sắp xếp của riêng chúng, sơ đồ này có thể dẫn đến một bộ sắp xếp phi tập trung hơn không yêu cầu số lượng lớn tài sản đặt cọc. Điều này rất quan trọng bởi vì:
Xếp hạng: Dòng đầu tiên về khả năng chống kiểm duyệt theo thời gian thực (CR) và tính sống động cho người dùng Rollup.

Thực thi và Bằng chứng: Có thể được thực hiện sau khi thực tế xảy ra mà không cần phân cấp mạnh mẽ.

Sau khi thỏa thuận đặt hàng giao dịch, việc thực hiện (và bằng chứng) có thể được hoãn lại sau khi thực tế đến một chuỗi hoàn toàn khác:
Đồng thuận mềm và đặt hàng: Trình đặt hàng được chia sẻ cung cấp xác nhận trước nhanh chóng cho người dùng
Đồng thuận & Tính sẵn có của dữ liệu: Dữ liệu giao dịch được hoàn thiện ở lớp DA để mọi người cùng xem

Các lớp thực thi tiếp theo không cần phải phân cấp vì đây không phải là nguồn gốc của CR. Những người đặt hàng đơn lẻ không phải là ứng cử viên lý tưởng cho CR, nhưng không phải vì vai trò của họ là người thực thi, mà vì họ đặt hàng và bao gồm các giao dịch. Ở đây, SS đã cung cấp đầu vào giao dịch được đặt hàng, do đó CR. Sau đó, việc tính toán và so sánh các cam kết của nhà nước không cần phải được phân cấp.

thực hiện mềm

Người dùng thích khớp lệnh mềm nhanh:

Điều này yêu cầu một số hình thức đồng thuận (hoặc người đặt hàng tập trung) để cung cấp trải nghiệm người dùng tuyệt vời:

Nếu bạn chỉ dựa vào sự đồng thuận của một lớp cơ sở như Celestia, thì bạn không thể đưa ra những lời hứa nhẹ nhàng xung quanh việc đặt hàng và đưa vào. Nếu SS có một ủy ban phi tập trung với các tài sản có giá trị cao được đặt cược, thì nó có thể cung cấp các cam kết khá mạnh đối với các khối nhanh (dưới thời gian khối L1).

Lazy Rollup

Do đó, miễn là SS tạo một khối, người dùng có thể nhận được xác nhận mềm. Sức mạnh của xác nhận này phụ thuộc vào việc xây dựng SS (phân cấp, an ninh kinh tế, quy tắc lựa chọn ngã ba, v.v.). Sau khi dữ liệu thực sự được xuất bản lên lớp cơ sở, bạn có thể coi các giao dịch này là thực sự cuối cùng. Tính toán cuối cùng của gốc trạng thái và bằng chứng liên quan sau đó có thể được tạo và gửi.

"Lazy Rollup" rất đơn giản. Họ đợi cho đến khi tất cả các giao dịch được đặt hàng và xuất bản lên lớp DA, sau đó họ tải xuống các giao dịch đó, tùy ý áp dụng các quy tắc lựa chọn ngã ba để chọn một tập hợp con các giao dịch, thực hiện xử lý giao dịch và xác định trạng thái giao dịch. Các tiêu đề khối sau đó có thể được tạo.

Lưu ý rằng vì SS không thể tạo các khối theo cách yêu cầu quyền truy cập vào trạng thái đầy đủ nên chúng không kiểm tra các chuyển đổi trạng thái không hợp lệ. Do đó, máy trạng thái "Lazy Rollup" sử dụng SS phải có khả năng xử lý các giao dịch không hợp lệ. Khi một nút thực hiện các giao dịch đã đặt hàng để tính toán trạng thái kết quả, nút đó có thể chỉ cần xóa giao dịch không hợp lệ/được hoàn nguyên. Tổng số truyền thống thực thi ngay lập tức không có giới hạn này.

Các bản tổng hợp, yêu cầu quyền truy cập của nhà nước để xử lý giao dịch trước khi đưa nó vào chuỗi, sẽ không hoạt động ở đây. Ví dụ: nếu Rollup có quy tắc về tính hợp lệ của khối, thì tất cả các giao dịch có trong một khối là các giao dịch hợp lệ và không thể thất bại. Nếu một Rollup yêu cầu giả mạo giao dịch thay vì truy cập trạng thái, thì một SS đặc biệt có thể được tạo riêng cho loại Rollup này (ví dụ: tương tự như Fuel v2 hoặc Rollup với nhóm bộ nhớ riêng).

Để SS hoạt động, phải có một số cơ chế để người dùng thanh toán cho các giao dịch của họ. Bạn có thể chỉ cần sử dụng các chữ ký và địa chỉ hiện có đã được bao gồm trong hầu hết các loại giao dịch Tổng số để thanh toán gas trên lớp SS. Ngoài ra, thanh toán có thể liên quan đến một số giao dịch được bao bọc trên SS, nơi bất kỳ ai cũng có thể thanh toán cho dữ liệu tùy ý được bao gồm. Đây là một không gian thiết kế mở.

Quy tắc lựa chọn ngã ba

Rollup có thể kế thừa các quy tắc lựa chọn rẽ nhánh của SS mà chúng đang sử dụng. Khi đó, các nút đầy đủ của Rollup thực sự là các ứng dụng khách nhẹ của SS, kiểm tra một số cam kết để cho biết khối Rollup nào là chính xác ở một độ cao nhất định.

MEV

Tuy nhiên, kế thừa các quy tắc lựa chọn ngã ba của SS là tùy chọn - bạn có thể chỉ cần yêu cầu Rollup xử lý (không nhất thiết phải thực thi) tất cả dữ liệu giao dịch mà nó xuất bản lên lớp cơ sở. Nó sẽ kế thừa CR và sự sống động của lớp cơ sở một cách hiệu quả, nhưng bạn sẽ phải hy sinh rất nhiều tính năng SS mà người dùng yêu thích.

Giả sử rằng một Rollup muốn kế thừa các quy tắc lựa chọn rẽ nhánh của SS của nó và có được khả năng thực thi mềm nhanh chóng, SS đương nhiên sẽ ở một vị trí rất cốt lõi trong MEV. Nó xác định việc bao gồm và đặt hàng giao dịch Rollup.

Tuy nhiên, Rollup không nhất thiết phải thực hiện các giao dịch do SS cung cấp hoặc thực hiện các giao dịch theo thứ tự được cung cấp. Về mặt kỹ thuật, bạn có thể cho phép Tổng số của riêng mình thực hiện vòng xử lý thứ hai để sắp xếp lại các giao dịch do SS phát hành sau khi thực hiện. Tuy nhiên, như đã đề cập ở trên, điều này làm mất đi hầu hết các lợi thế của việc sử dụng SS.

Ngay cả trong trường hợp này, lớp SS vẫn có thể có MEV vì nó có quyền chứa các giao dịch. Nếu thực sự muốn, bạn thậm chí có thể cho phép Tổng số của mình loại trừ một số giao dịch nhất định trong vòng xử lý thứ hai, nhưng điều đó sẽ trở nên lộn xộn, giảm CR và mất hầu hết các lợi ích của SS.

Hoán đổi bộ sắp xếp được chia sẻ

Điều khó phân tách trong chuỗi khối là bất kỳ hình thức chia sẻ trạng thái giá trị nào. Hãy xem ETH so với ETC hoặc tương tự như ETH so với ETH POW, sự đồng thuận xã hội xác định "Ethereum thực sự" là gì. Trạng thái của "sự thật" mà tất cả chúng ta có thể đồng ý đều có giá trị.

Tuy nhiên, SS thực sự chỉ là một nhà cung cấp dịch vụ - chúng không có trạng thái có giá trị nào liên quan đến chúng. Một Tổng số sử dụng một SS nhất định vẫn có khả năng phân nhánh nó để hỗ trợ một số cơ chế phân loại khác, chỉ yêu cầu một phân nhánh cứng nhỏ (ví dụ: nếu SS trích xuất quá nhiều giá trị).

Espresso Sequencer (ESQ): Được đảm bảo bởi EigenLayer

EigenLayer giấy trắnggiấy trắng

SS phi tập trung đã được đề cập là một trong những trường hợp sử dụng tiềm năng để đặt lại cổ phần. SS này có thể được bảo mật bằng cách đặt lại ETH, điều này sẽ xử lý nhiều lệnh giao dịch L2 khác nhau.

Chà, Espresso vừa công bố điều này trong chương trình trình sắp xếp thứ tự được chia sẻ của họ. Nó có thể sử dụng việc đặt lại EigenLayer để đảm bảo sự đồng thuận của nó. Để cung cấp một hình ảnh trực quan đẹp mắt, Rollup hôm nay trông như thế này:

Đây là giao diện của chúng với SS như Espresso:

Espresso Sequencer (ESQ) nhìn chung có ý tưởng rất giống với Metro. Chúng hoạt động trên cùng một nguyên tắc cốt lõi - tách việc thực hiện giao dịch khỏi việc đặt hàng. Ngoài ra, ESQ cũng sẽ cung cấp dữ liệu sẵn có cho các giao dịch.

Đồng thuận HotShot và Espresso DA (Dữ liệu sẵn có)

Đối với nền tảng, Ethereum hiện đang sử dụng Gasper cho sự đồng thuận (Casper FFG làm công cụ hoàn thiện + LMD GHOST làm quy tắc lựa chọn fork). TLDR liên quan ở đây là khả năng tồn tại của Gasper ngay cả trong các điều kiện mà phần lớn các nút có thể ngoại tuyến (tính khả dụng động). Nó chạy hiệu quả hai giao thức (Casper FFG và LMD Ghost) cùng nhau duy trì một chuỗi động có sẵn với tiền tố cuối cùng. Gasper đánh đổi thuyết quyết định nhanh.

Nhìn chung, ESQ bao gồm:
HotShot: ESQ được xây dựng dựa trên giao thức đồng thuận HotShot, không giống như Gasper, giao thức này ưu tiên tính chính xác nhanh hơn tính khả dụng động. Nó cũng có thể mở rộng quy mô để hỗ trợ nhiều trình xác thực hơn, giống như Ethereum đã làm.
Espresso DA: ESQ cũng sẽ cung cấp DA cho các chuỗi chọn tham gia. Cơ chế này cũng được sử dụng để mở rộng sự đồng thuận chung của họ.
Hợp đồng Sequencer: Một hợp đồng thông minh hoạt động như một ứng dụng khách nhẹ để xác minh sự đồng thuận của HotShot và ghi lại các điểm kiểm tra. Ngoài ra, nó quản lý những người đặt cược cho sự đồng thuận HotShot PoS của ESQ.
Lớp mạng: Giao tiếp các giao dịch và thông báo đồng thuận giữa các nút tham gia HotShot và Espresso DA

Rollup REST API - API Rollup của L2 để tích hợp với trình sắp xếp Espresso.

Hệ thống này được xây dựng cho khả năng mở rộng, vì vậy ESQ muốn cung cấp DA rẻ hơn cho L2. Họ vẫn sẽ giải quyết bằng chứng và cập nhật trạng thái cho L1 Ethereum, nhưng lưu ý rằng điều này sẽ làm cho các chuỗi sử dụng ESQ theo mặc định không còn "Rollups" đầy đủ nữa (Ethereum L1 không đảm bảo DA của họ). Nó mạnh hơn so với việc triển khai đơn giản Ủy ban tính khả dụng của dữ liệu (DAC), nhưng sự đảm bảo của nó yếu hơn so với Rollup thực sự.

Quy trình giao dịch

Quy trình giao dịch
Hợp đồng trình sắp xếp thứ tự: HotShot tương tác trực tiếp với hợp đồng trình sắp xếp thứ tự L1 của nó. Nó xác thực sự đồng thuận của HotShot và cung cấp giao diện cho những người tham gia khác xem các khối được sắp xếp. Hợp đồng lưu trữ nhật ký bổ sung về việc gửi khối chứ không phải toàn bộ khối và bất kỳ ai cũng có thể xác minh khối dựa trên thông tin đã gửi.

Hợp đồng L2: Mỗi L2 sử dụng ESQ vẫn có hợp đồng Ethereum L1 Rollup của riêng mình. Để xác minh các cập nhật trạng thái được gửi tới mỗi Rollup (thông qua tính hợp lệ/bằng chứng gian lận), mỗi hợp đồng Rollup phải có quyền truy cập vào chuỗi các khối đã xác thực dẫn đến cập nhật trạng thái đã xác nhận quyền sở hữu. Họ tương tác với hợp đồng sắp xếp để truy vấn những thứ này.

Toàn cảnh luồng giao dịch:

Nguyên tử chuỗi chéo

Như đã nêu trong bài Espresso, SS có thể cung cấp một số trường hợp sử dụng thú vị cho tính nguyên tử chuỗi chéo:

Một lớp đặt hàng được chia sẻ trên nhiều Rollup hứa hẹn sẽ làm cho việc nhắn tin và kết nối chuỗi chéo rẻ hơn, nhanh hơn và an toàn hơn. Loại bỏ nhu cầu xây dựng ứng dụng khách nhẹ cho máy phân loại của chuỗi khác, tiết kiệm chi phí. Kết nối tổng số chéo cũng có thể giúp tiết kiệm chi phí hơn nữa bằng cách loại bỏ nhu cầu về một Tổng số nhất định để duy trì sự độc lập của sự đồng thuận trong thời gian thực với các Tổng số khác. Trình đặt hàng được chia sẻ cũng cung cấp một lợi thế an toàn cho việc bắc cầu: trình đặt hàng được chia sẻ đảm bảo rằng một giao dịch hoàn thành trong một lần tổng hợp khi và chỉ khi nó hoàn thành trong một lần tổng hợp khác. Ngoài ra, trình đặt hàng được chia sẻ nâng cao khả năng của người dùng để thể hiện sự phụ thuộc nguyên tử giữa các giao dịch trên các Tổng số khác nhau. Theo quy ước, Alice sẽ ký và xuất bản giao dịch Rollup-A t' độc lập với giao dịch Rollup-B t' của Bob. Trong trường hợp này, giao dịch của Alice có thể được đặt trước rất lâu trước giao dịch của Bob, khiến Bob có một lựa chọn dài hạn là hủy bỏ. Sự mất cân bằng về tính tùy chọn này được giảm thiểu bởi người đặt hàng dùng chung, trong đó Alice và Bob có thể gửi hai giao dịch cùng nhau dưới dạng một gói đã ký (nghĩa là người đặt hàng phải coi hai giao dịch là một giao dịch).

Điều này có ý nghĩa đối với MEV chuỗi chéo, vì hoạt động trên chuỗi cuối cùng sẽ phát triển. Một ví dụ điển hình là "chênh lệch giá nguyên tử". Cùng một tài sản được giao dịch ở hai mức giá khác nhau trên hai chuỗi khác nhau. Những người tìm kiếm muốn kinh doanh chênh lệch giá bằng cách thực hiện hai giao dịch cùng một lúc mà không gặp rủi ro. Ví dụ:
Giao dịch 1 (T 1 ) - Mua ETH với giá thấp trên Rollup 1 (R 1 )

Giao dịch 2 (T 2 ) - Bán ETH với giá cao trên Rollup 2 (R 2 )

T 1 được đưa vào dòng lệnh của R 1 khi và chỉ khi:
T 2 cũng được bao gồm trong dòng lệnh tới R 2

T 2 cũng được bao gồm trong dòng lệnh tới R 2

T 1 thực hiện trên R 1 khi và chỉ khi:
T 2 cũng thực hiện trên R 2

T 2 cũng thực hiện trên R 2

Tuy nhiên, điều này vẫn không đảm bảo khi bạn đang giao dịch trên một máy trạng thái dùng chung (ví dụ: hoàn toàn trên Ethereum L1). Như đã đề cập trước đó, SS không giữ trạng thái của các Rollup này, chúng không thực hiện các giao dịch. Bạn không thể đảm bảo hoàn toàn rằng một trong các giao dịch (trên R 1 hoặc R 2 ) sẽ không hoàn nguyên khi thực hiện.

Xây dựng các nguyên hàm cấp cao hơn trực tiếp trên đầu trang này là một vấn đề. Ví dụ: nếu bạn cố gắng xây dựng một cây cầu liên chuỗi chéo ghi và đúc ngay lập tức trên SS này, thì nó sẽ thực hiện đồng thời các thao tác sau ở cùng độ cao khối chính xác:
Hủy đầu vào trên R1

Tạo đầu ra trên R2

Bạn có thể gặp các trường hợp sau:
Phá hủy trên R 1 có thể gây ra lỗi không mong muốn, nhưng

Đầu ra trên R2 không bị vô hiệu hóa vì bất kỳ lý do gì, vì vậy nó thực thi hoàn toàn.

Đây sẽ là một vấn đề lớn.

Trong một số trường hợp, bạn có thể chắc chắn về kết quả dự kiến của cả hai giao dịch miễn là cả hai giao dịch đó đều được đưa vào luồng đầu vào và được thực thi, nhưng trường hợp này thường không xảy ra.
Đảm bảo: T 1 và T 2 sẽ được chứa trong các luồng tương ứng của chúng và (có thể) cả hai sẽ được thực thi.

Không đảm bảo: thực hiện thành công giao dịch và kết quả trạng thái mong muốn.

Những "sự đảm bảo" này có thể đủ cho một số thứ như kinh doanh chênh lệch giá nguyên tử, trong đó người tìm kiếm đã sở hữu tài sản cần thiết để thực hiện các giao dịch này trên mỗi chuỗi, nhưng rõ ràng đây không phải là khả năng kết hợp đồng bộ của máy trạng thái dùng chung. Đối với những thứ như khoản vay chớp nhoáng liên chuỗi, bản thân nó không cung cấp đủ sự đảm bảo.

Vẫn có thể hữu ích khi được kết hợp với các giao thức nhắn tin chuỗi chéo khác. Hãy xem cách các giao dịch hoán đổi nguyên tử NFT xuyên chuỗi có thể được hỗ trợ khi được sử dụng với giao thức nhắn tin Cross-Rollup:
T 1 chuyển ETH từ U 1 (Người dùng 1 ) sang SC 1 (Hợp đồng thông minh 1 ) trên R 1
T 2 chuyển NFT từ U 2 (Người dùng 2 ) sang SC 2 (Hợp đồng thông minh 2 ) trên R 2
SC 1 sẽ cho phép U 2 rút ETH khi và chỉ khi nhận được tin nhắn từ SC 2 xác nhận rằng NFT đã được ký gửi
SC 2 sẽ cho phép U 1 rút NFT khi và chỉ khi nó nhận được tin nhắn từ SC 1 xác nhận rằng ETH đã được ký gửi

Cả hai hợp đồng thông minh đều thực hiện khóa thời gian để nếu một trong hai bên thất bại, cả hai bên đều có thể lấy lại tài sản của mình

SS ở đây cho phép hai người dùng cam kết nguyên tử ở bước 1. Sau đó, bạn sử dụng một số hình thức nhắn tin chuỗi chéo để xác minh trạng thái kết quả của nhau và mở khóa nội dung để thực hiện trao đổi.

Nếu được thực hiện nguyên tử mà không có SS, hai bên có thể thỏa thuận về giá. Nhưng sau đó U 1 có thể gửi giao dịch và sau đó U 2 có thể đợi và quyết định xem nó có muốn hủy bỏ giao dịch hay không. Với SS, họ bị khóa trong giao dịch.

Điều này gần như sắp xảy ra đối với các trường hợp sử dụng nguyên tử chuỗi chéo SS. tóm tắt:
Sức mạnh và tính hữu ích chính xác của các bảo đảm được cung cấp ở đây vẫn chưa được chứng minh
Điều này có thể rất hữu ích cho kinh doanh chênh lệch giá nguyên tử xuyên chuỗi, cũng như các ứng dụng khác như hoán đổi chuỗi chéo và giao dịch NFT
Cung cấp bảo mật kinh tế tiền điện tử bổ sung (ví dụ: cung cấp trái phiếu làm tài sản thế chấp) để bảo lãnh một số loại giao dịch chuỗi chéo nhất định có thể hữu ích

Tuy nhiên, bạn không bao giờ có thể đảm bảo kết quả giao dịch một cách vô điều kiện (bạn có thể nhận được điều đó bằng cách thực hiện các giao dịch nguyên tử cùng nhau trên một máy trạng thái dùng chung)

Optimism's Superchain- Khám phá việc sử dụng SS trong chuỗi OP.
Anoma - Heterogeneous PaxosVàTyphonVà
là những cách tiếp cận rất khác nhau.Cross Rollup Forced Transactions。

Kalman đã nói ở trên

Tóm tắt bộ sắp xếp được chia sẻ

Nói chung, ý tưởng cơ bản của SS là:

Rõ ràng bản vẽ này không khoa học, mọi thứ đều mang tính chủ quan cao và phụ thuộc rất nhiều vào bản dựng chính xác. TLDR như sau:
Trình sắp xếp tập trung - Nếu bạn có toàn quyền kiểm soát hệ thống, thì thường dễ dàng thực hiện bất kỳ chức năng nào bạn muốn. Tuy nhiên, các khả năng xác nhận trước có sự đảm bảo dưới mức tối ưu, việc thoát khỏi lực lượng có thể không được mong muốn, độ sống động là dưới mức tối ưu, v.v.
Trình sắp xếp L2 phi tập trung: Một Tổng số với một trình sắp xếp cam kết phân tán mạnh mẽ hơn một Tổng số với một trình sắp xếp duy nhất. Tuy nhiên, các thiết kế khác nhau có sự đánh đổi trong những thứ như độ trễ (ví dụ: nếu nhiều nút L2 hiện cần bỏ phiếu trước khi xác nhận khối Tổng số).
Xếp theo L1: đảm bảo tối đa tính phân quyền, chống kiểm duyệt và hoạt động, v.v. Tuy nhiên, nó thiếu các tính năng như xác nhận trước nhanh, giới hạn thông lượng dữ liệu, v.v.

Bộ sắp xếp được chia sẻ: Có chức năng của Bộ sắp xếp phi tập trung mà không cần khởi động bộ Bộ sắp xếp của riêng bạn. Tuy nhiên, lược đồ này có các đảm bảo yếu hơn trong giai đoạn chuyển tiếp trước khi hoàn thiện L1 so với đặt hàng L1. Ngoài ra, một lớp dùng chung có thể tổng hợp nhiều ủy ban của Rollup, an ninh kinh tế, v.v. vào một nơi (có thể mạnh hơn nếu một Rollup duy nhất có ủy ban riêng).

SUAVE

Khi L1 được hoàn thiện, tất cả các Rollup sẽ đạt được 100% bảo mật L1. Cho đến khi đạt được sự an toàn và bảo mật đầy đủ của giải quyết L1, hầu hết các thiết kế của người đặt hàng chỉ cố gắng cung cấp các tính năng tốt, nhưng làm suy yếu các đảm bảo trong giai đoạn chuyển tiếp.

Trình tạo phi tập trung và trình phân loại được chia sẻSUAVESự khác biệt có thể trở nên rất khó hiểu khi chúng ta nói về các lớp được chia sẻ này đang cố xử lý các giao dịch từ nhiều chuỗi khác. Đặc biệt là khi SUAVE thường được gọi là "Lớp đặt hàng" hoặc các thuật ngữ khác như "Trình tạo khối phi tập trung cho Rollup". Để được rõ ràng,

Khác biệt đáng kể so với thiết kế SS ở trên.

Hãy quan sát cách SUAVE tương tác với Ethereum. SUAVE sẽ không được nhúng vào giao thức Ethereum dưới bất kỳ hình thức nào. Người dùng chỉ cần gửi các giao dịch của họ đến mempool được mã hóa của nó. Sau đó, một mạng gồm những người thực thi SUAVE sẽ tạo ra một khối (hoặc một phần của khối) cho Ethereum (hoặc bất kỳ chuỗi nào tương tự). Các khối này sẽ cạnh tranh với các khối xây dựng Ethereum tập trung truyền thống. Những người đề xuất Ethereum chọn giữa chúng.

Tương tự như vậy, SUAVE sẽ không thay thế cơ chế chọn khối của Rollup. Ví dụ: Rollup có thể triển khai bộ đồng thuận PoS hoạt động theo cách tương tự như Ethereum L1 hoạt động. Sau đó, những người đặt hàng/người xác thực này có thể chọn các khối mà SUAVE tạo cho họ.

Điều này rất khác so với SS được mô tả ở trên, trong đó Rollup có thể loại bỏ hoàn toàn nhu cầu về bộ phân loại phi tập trung. Họ thuê ngoài chức năng sắp xếp bằng cách chọn Metro hoặc ESQ, v.v. và họ có thể chọn kế thừa các quy tắc lựa chọn ngã ba của SS. Ethereum, Arbitrum, Optimism, v.v. sẽ không thay đổi quy tắc lựa chọn fork vì họ chọn thứ tự giao dịch SUAVE.

SUAVE không quan tâm quy tắc lựa chọn ngã ba của chuỗi của bạn là gì hoặc khối của bạn được chọn như thế nào. Nó có thể cung cấp sự phân loại có lợi nhất cho bất kỳ chuỗi nào. Lưu ý rằng không giống như các nút SS được mô tả trước đó, các bộ thực thi SUAVE thường có trạng thái đầy đủ (mặc dù chúng cũng có thể đáp ứng các tùy chọn nhất định không yêu cầu trạng thái). Họ cần mô phỏng kết quả của các giao dịch khác nhau để tạo ra một chuỗi tối ưu.

Để hiểu sự khác biệt, hãy xem xét một ví dụ trong đó người dùng muốn chạy chênh lệch giá nguyên tử giữa các chuỗi. Gửi tới SUAVE so với gửi tới SS, sự khác biệt giữa các đảm bảo mà họ có thể nhận được là gì:

SUAVE + trình sắp xếp chungBây giờ hãy nghĩ về nó, SUAVE tương tác với sắp xếp Tổng số như thế nào? Thậm chí có thể tương tác với SS? Espresso dường như tinSUAVE và ESQ

tương thích. ESQ được thiết kế để tương thích với các dịch vụ mempool riêng như SUAVE có thể hoạt động như một trình tạo. Nó trông tương tự như PBS chúng tôi sử dụng trên Ethereum ngay bây giờ:
người đề xuất được chia sẻ = người đặt hàng được chia sẻ

trình tạo được chia sẻ = SUAVE

Giống như PBS, các nhà xây dựng có thể nhận được các cam kết mù từ những người đề xuất (ở đây là những người đặt hàng) để đề xuất một khối nhất định. Người đề xuất chỉ biết tổng tiện ích (giá thầu của người xây dựng) từ khối được đề xuất chứ không phải nội dung.

Tóm lại, chúng ta hãy nhìn lại một người tìm kiếm muốn thực hiện kinh doanh chênh lệch giá chéo chuỗi. Bản thân SUAVE có thể tạo và gửi tới hai Bản tổng hợp khác nhau:
Khối 1 (B 1 ) bao gồm Giao dịch 1 (T 1 ) - Mua ETH với giá thấp trên Rollup 1 (R 1 )

Khối 2 (B 2 ) bao gồm Giao dịch 2 (T 2 ) - Bán ETH với giá cao trên Rollup 2 (R 2 )

Nhưng rất có thể B 1 thắng phiên đấu giá và B 2 thua (hoặc ngược lại). Điều gì xảy ra nếu bạn chọn hai Tổng số này vào cùng một SS.

Các nút SS không biết giao dịch thực sự đang làm gì, vì vậy chúng cần ai đó (như SUAVE hoặc một trình tạo nhận biết MEV khác) để xây dựng một khối đầy đủ cho chúng nếu chúng muốn hoạt động hiệu quả. Chà, một người thực thi SUAVE có thể cam kết cả B1 và B2 cho SS, miễn là cả hai khối đều được lấp đầy hoặc bị hủy (thực thi hoặc xóa cả hai theo cách nguyên tử).

Bây giờ bạn có thể nhận được sự đảm bảo tài chính rất tốt trong suốt quá trình:
SUAVE = Shared Builder = có thể đảm bảo với bạn trạng thái nào sẽ xảy ra nếu cả B1 và B2 đều được chứa và thực thi nguyên tử.