Rollup thực sự là gì

Tiêu đề gốc: "Bạn không phải là Rollup thực sự :)"

Tác giả gốc: Jon Charbonneau

Bản tổng hợp gốc: ETH Chinese

Kelvin cho rằng ZK-rollup là giả, nhưng tôi nghĩ mọi "Rollup" đều không có thật, ít nhất là chưa. Vì vậy, làm thế nào để chúng ta biến chúng thành những bản tổng hợp thực sự?

Về cơ bản, các bản tổng hợp hiện tại cần có sự tin cậy và cho phép:

Nguồn: L2 Beat

Trong bài viết này, tôi sẽ cung cấp cái nhìn tổng quan về các khía cạnh sau:

Cơ chế đóng gói giao dịch bắt buộc ——Ngay cả khi nhà điều hành tổng hợp xem xét người dùng, người dùng cũng có thể buộc các giao dịch của mình phải có khả năng chống kiểm duyệt.

Phân cấp trình tự sắp xếp L2 và sự đồng thuận cục bộ (tùy chọn)  - trình sắp xếp trình tự đơn, PoA, bầu cử lãnh đạo PoS, đồng thuận PoS, đấu giá MEV, rollup dựa trên lớp cơ sở, PoE, v.v.

Trình sắp xếp trình tự được chia sẻ và tính nguyên tử chuỗi chéo  - Đây thực sự là một nội dung thú vị và hoàn toàn mới.

Thiết kế có thể ghi được MEV  - Tôi sẽ giới thiệu ngắn gọn một số thay đổi đối với FCFS (First Come First Served). Đối với nhóm giao dịch tiền điện tử, bạn có thể tham khảo bài đăng gần đây của tôi.

Nhiều yêu cầu khác để cải thiện bảo mật tổng hợp nằm ngoài phạm vi của bài viết này (chẳng hạn như giảm việc nâng cấp sức mạnh của khóa, cho phép chứng thực mạnh mẽ và không cần cấp phép, v.v.).

Cách hoạt động của tính năng Tổng hợp

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

Trước tiên, hãy xem xét ngắn gọn nguyên tắc hoạt động của SCR. Đây là bản tổng hợp phổ biến hiện tại của chúng tôi trên Ethereum. Ở mức cao, SCR về cơ bản bao gồm:

1. Một loạt mảng Đầu vào được sắp xếp ( trên L1 nên dữ liệu giao dịch phải được xuất bản ở lớp DA).

2. (phần mềm nút tổng hợp) mã chạy trên chúng.

3. Việc chạy một hàm trên các đầu vào này sẽ tạo ra một đầu ra xác định (blockchain cuộn lên).

cr: Cách thức hoạt động của Rollups *thực sự* - Kelvin Fichter

Cụ thể hơn, trình sắp xếp chuỗi truyền thống xuất bản gốc trạng thái của khối cuộn lên cho hợp đồng thông minh của nó trong L1 và calldata (cuối cùng trong dưới dạng một đốm dữ liệu) để tạo ra các cam kết cho các khối tổng hợp. Các khối mới liên tục được mở rộng bằng cách cuộn lên tiêu đề khối. Hợp đồng trên chuỗi chạy ứng dụng khách tổng hợp nhẹ và lưu giá trị băm của tiêu đề khối của nó. Sau khi nhận được bằng chứng về tính hợp lệ hoặc sau khi hết thời gian chống gian lận, hợp đồng thông minh sẽ hoàn tất việc giải quyết. Nếu một khối ORU chưa được hoàn thiện là không hợp lệ thì khối đó (và tất cả các khối tiếp theo) sẽ bị khôi phục do việc gửi cặp bằng chứng gian lận và cuối cùng trở thành khối mồ côi. Bằng chứng giúp bảo vệ cây cầu:

Việc gửi các lô giao dịch phải yêu cầu áp dụng một số loại Quy tắc ký quỹ/gửi tiền để hạn chế hành vi nguy hiểm. Ví dụ: khi một lô gian lận được gửi (tức là gốc trạng thái không hợp lệ), khoản tiền gửi sẽ bị hủy và phân phối cho người thách thức gian lận theo một tỷ lệ nào đó.

SCR có "sự đồng thuận hợp nhất" - một giao thức đồng thuận có thể được xác minh trên chuỗi. Giao thức Rollup có thể chạy hoàn toàn trong hợp đồng thông minh L1. Nó không ảnh hưởng đến bất kỳ quy tắc đồng thuận nào của chuỗi chính và không yêu cầu hỗ trợ từ các quy tắc này.

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 ý, sau đây là phiên bản Rất đơn giản , không liệt kê đầy đủ các loại giao thức đồng thuận khác nhau. Chẳng hạn như các giao thức không có người lãnh đạo):

1. Hàm hợp lệ khối - Hàm chuyển trạng thái. Tính hợp lệ của khối được thực hiện ngoài chuỗi và tính hợp lệ của nó sau đó được chứng minh thông qua cơ chế chứng minh tính hợp lệ hoặc bằng chứng gian lận.

2. Quy tắc lựa chọn ngã ba - Cách chọn giữa hai Chọn giữa các chuỗi hợp lệ ban đầu. Rollup được thiết kế để không phân nhánh theo kết cấu, vì vậy nó không yêu cầu nghiêm ngặt quy tắc lựa chọn phân nhánh phức tạp.

3. Thuật toán bầu chọn người lãnh đạo - Chọn một làm người lãnh đạo, người đó có thể mở rộng phần đầu chuỗi bằng cách thêm các khối mới, từ đó mở rộng chuỗi khối.

4. Cơ chế chống phù thủy - PoW, PoS , v.v.

Có thể coi là 1 và 2 đã được thực hiện nên để phân cấp một trình sắp xếp thứ tự Yêu cầu tối thiểu là một số hình thức kháng cự Sybil + bầu cử lãnh đạo.  Fuel Labs luôn là người ủng hộ chiến lược này. Họ tin rằng PoS:

Không nên sử dụng trong các giao thức đồng thuận đầy đủ ở dạng tổng hợp (tức là trình xác thực/trình tự tổng hợp sẽ bỏ phiếu trên các khối)

Chỉ nên sử dụng để bầu chọn người lãnh đạo trong danh sách tổng hợp

Tất nhiên, có những lập luận khác bác bỏ quan điểm của Fuel Labs rằng cần có sự đồng thuận của địa phương L2. Thêm về điều này sau.

Bản tổng hợp có chủ quyền (SR)

SR vẫn xuất bản dữ liệu giao dịch lên L1 cho DA và sự đồng thuận, nhưng SR sẽ xử lý việc "thanh toán" trong bản tổng hợp "Khách hàng ( James Prestwich nói gọi nó là "lớp định cư" có vẻ ngu ngốc. Tôi đã ngu rồi nên không sao cả). Lớp DA cho bạn biết rằng dữ liệu tồn tại nhưng nó không xác định chuỗi chuẩn nào được tổng hợp:

SCR - Chuỗi đặc tả tổng hợp được xác định bởi hợp đồng thông minh L1

SR - Không có hợp đồng thông minh L1 nào để xác định chuỗi đặc tả tổng hợp. Chuỗi chính Rollup có thể được xác định bởi chính nút rollup (kiểm tra L1 DA và sau đó xác thực các quy tắc lựa chọn ngã ba cục bộ).

Nguồn: Celestia

Lưu ý liên quan: Có người đưa ra một điểm thú vị, đó là không có chuỗi kinh điển toàn cầu (chỉ có cầu nối xác định chuỗi nào là chuỗi chính tắc), và một số người đưa ra phản bác mạnh mẽ về điều này. và các dòng tweet có liên quan khác minh họa sự cân bằng giữa chủ quyền và khả năng kết hợp (tự động) của tổng hợp. Tôi khuyến khích mọi người hãy xem những quan điểm này, cũng như dòng tweet dài gần đây về việc giới thiệu chủ quyền của Bitcoin.

Trong mọi trường hợp, khuôn khổ "chuỗi chuẩn" được thảo luận ở trên rất dễ hiểu và điều này không phải là trọng tâm của bài viết này nên tôi sẽ tiếp tục sử dụng thuật ngữ "chuỗi chuẩn". Để biết thêm thông tin cơ bản về kiến trúc tổng hợp, vui lòng tham khảo tại đây.

Trình sắp xếp chuỗi phi tập trung

Đóng gói giao dịch bắt buộc do người dùng thực hiện

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 phân nhóm các giao dịch 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ể tự chèn một số giao dịch trực tiếp vào hợp đồng:

Tất nhiên, điều này không hiệu quả và tốn kém, vì vậy người sắp xếp thứ tự sẽ chịu trách nhiệm phân nhóm các giao dịch và gửi các lô này cùng nhau theo quy trình thông thường. Điều này sẽ phân bổ chi phí cố định qua nhiều giao dịch, cho phép nén tốt hơn:

Đã xác định Trình sắp xếp chuỗi cam kết cuối cùng xuất bản các giao dịch này trên L1 và chúng tôi có thể tính toán kết quả đầu ra để có được xác nhận trước nhẹ nhàng hơn:

Khi trình sắp xếp thứ tự xuất bản các giao dịch này lên L1, đầu ra sẽ được hoàn tất:

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

Nếu tôi muốn rút tiền về L1, tôi có thể hủy nó trên L2 , và bảo L1 trả lại tiền cho tôi. L1 không biết chuyện gì đã xảy ra với L2 (L1 không thực hiện các giao dịch này) và do đó cần gửi bằng chứng cùng với yêu cầu mở khóa tiền của tôi trên L1.

Vì tôi đến từ L2 nên người sắp xếp thứ tự có thể bắt đầu yêu cầu rút tiền này và gửi nó đến L1. Tuy nhiên, làm như vậy đòi hỏi phải tin cậy vào khả năng chống kiểm duyệt (CR) của trình sắp xếp chuỗi L2, điều đó có nghĩa là không còn có được sự đảm bảo bảo mật tương tự như L1 nữa. Có thể trình sắp xếp chuỗi không thích bạn hoặc trình sắp xếp chuỗi không hoạt động nên bạn bị kẹt ở L2 mãi mãi.

Rollup có thể cải thiện CR cục bộ thông qua nhiều biện pháp khác nhau. Điều này có thể bao gồm một bộ đồng thuận L2 với mức đặt cược giá trị cao, một số biến thể của danh sách đóng gói giao dịch, thêm mã hóa ngưỡng, v.v. để giảm thiểu khả năng bị người dùng L2 kiểm duyệt. Điều đó thật tuyệt vời, nhưng lý tưởng nhất là chúng tôi vẫn muốn người dùng L2 có được những đảm bảo chống kiểm duyệt giống như L1.

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

Nguồn: Nghiên cứu về Starknet Escape Hatch

Tuy nhiên, nếu lựa chọn duy nhất của người dùng L2 là buộc giao dịch trực tiếp vào L1 thì điều này không lý tưởng . Điều này có thể không khả thi đối với nhiều người dùng có giá trị thấp, đặc biệt khi chi phí tương tác của L1 ngày càng cao. Các thiết kế tiên tiến hơn có thể khắc phục hạn chế này và buộc các giao dịch nguyên tử giữa các lần tổng hợp. Kalman Lajk  đang thực hiện một thiết kế hấp dẫn mà tôi khuyên bạn nên đọc. Nó muốn cho phép đóng gói giao dịch bắt buộc cuộn chéo trong các hệ thống có bằng chứng chung và các lớp DA được chia sẻ.

Tổng hợp chủ quyền

Việc đóng gói bắt buộc hoạt động khác trong SR vì như đã đề cập trước đó, chúng thực thi các quy tắc lựa chọn nhánh khác với SCR (Sovereign Labs đã viết một bài về điều này).

Trong SCR, hợp đồng thông minh L1 thực hiện các quy tắc lựa chọn nhánh của quá trình tổng hợp. Ngoài việc xác thực bằng chứng ZK, nó còn 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 đó (chứ không phải các nhánh bằng chứng khác) hay không và liệu nó có xử lý tất cả các giao dịch đóng gói bắt buộc có liên quan được gửi trên L1 hay không.

SR có thể xuất bản bằng chứng ZK của mình lên lớp L1 DA dưới dạng calldata/blobs Exseed cho mọi người (ngay cả khi L1 không xác minh họ). Sau đó, chỉ cần thêm quy tắc rằng bằng chứng mới chỉ hợp lệ nếu nó được xây dựng trên 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 sau đó nó yêu cầu người dùng quét lịch sử của chuỗi cho đến khối gốc hoặc một điểm kiểm tra nhất định.

Một cách khác là liên kết calldata với tiêu đề khối L1 và Thêm câu lệnh "Tôi có đã 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 dựa trên bằng chứng hợp lệ mới nhất." Điều này trực tiếp chứng minh quy tắc lựa chọn ngã ba trong bằng chứng mà không yêu cầu thực thi từ phía khách hàng.

Vì bằng chứng đã được quét nên cũng có thể chứng minh rằng mọi giao dịch đóng gói bắt buộc đều đã được thực hiện đã quét. Bất kỳ ai cũng có thể xuất bản các giao dịch được bao bọc bắt buộc trực tiếp lên lớp L1 DA nếu họ muốn.

Mức độ hoàn tất giao dịch&ZK để hoàn tất nhanh

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 ZKR hiện tại (như StarkEx) có xu hướng chỉ phát hành STARK cho Ethereum cứ sau vài giờ. So với số lượng giao dịch, bằng chứng có xu hướng tăng rất chậm, do đó, việc phân nhóm các giao dịch theo cách này có thể tiết kiệm chi phí một cách hiệu quả. Tuy nhiên, thời gian dài như vậy để hoàn thiện là không lý tưởng.

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

Thông thường, các nút nhẹ chỉ dựa vào trình sắp xếp tập trung để xác nhận phần mềm. Tuy nhiên, ZKR có thể nhanh chóng tạo và phân phối bằng chứng ZK ở lớp p2p để tất cả các máy khách hạng nhẹ xem trong thời gian thực, 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 đệ quy theo nhóm và xuất bản lên L1.

Đây là điều Sovereign Labs dự định thực hiện và có những giải pháp tương tự khác, chẳng hạn như  ;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) để các máy khách nhẹ có thể đồng bộ hóa khá nhanh. Bằng cách sử dụng hai cấu trúc này, quá trình tổng hợp có thể bắt đầu hoàn thiện các khối ở tốc độ L1 thay vì chờ gửi các lô đến chuỗi để tiết kiệm chi phí. Tuy nhiên, hãy lưu ý rằng trong cả hai trường hợp, "thời gian gõ mạnh" chỉ giảm xuống mức tối thiểu tuyệt đối (tốc độ L1).

Các thiết kế trình sắp xếp khác nhau sẽ không bao giờ được hoàn thiện nhanh hơn thời gian khối L1. Điều tốt nhất mà các thiết kế trình sắp xếp khác nhau có thể làm là cung cấp xác nhận trước nhanh hơn thời gian khối L1 và các thiết kế khác nhau cung cấp các mức độ cuối cùng khác nhau (ví dụ: bạn có thể tin tưởng vào sự phân cấp với việc đặt cược trước xác nhận L2 có giá trị cao của bộ đồng thuận, thay vì trước xác nhận của một trình sắp xếp chuỗi duy nhất cần được tin cậy).

Patrick McCorry gần đây cũng đã làm rất tốt việc tổng hợp các lớp cuối cùng của thỏa thuận Trong bản tóm tắt. Bây giờ có lẽ bạn đã hiểu khái niệm cơ bản:

Giao dịch "cuối cùng" có nhiều cấp độ khác nhau, tùy thuộc vào ai đã cung cấp cam kết (và cấu trúc tổng hợp như thế nào)

Những người tham gia khác nhau sẽ có ý kiến về "sự thật" tại một thời điểm nhất định. Các cấp độ nhận thức khác nhau (ví dụ: , Máy khách nhẹ L2, nút đầy đủ và hợp đồng thông minh L1 sẽ tìm hiểu cùng một "sự thật" vào những thời điểm khác nhau)

Trình sắp xếp đơn

Hiện tại, hầu hết các bản tổng hợp đều có trình sắp xếp thứ tự được phép gửi các lô giao dịch. Điều này rất hiệu quả nhưng có khả năng chống kiểm duyệt và hoạt động theo thời gian thực kém. Với các biện pháp bảo vệ thích hợp được áp dụng, điều này có thể được chấp nhận trong nhiều trường hợp sử dụng:

CR —Như đã đề cập ở trên, cơ chế để người dùng buộc giao dịch trọn gói.

Tính sống động —Một số tùy chọn sao lưu nóng nếu một số trình sắp xếp chính bị hỏng (tương tự như bản sao lưu bằng chứng gian lận của ZKR và bản sao lưu bằng chứng gian lận ORU sẽ không được cấp phép). Nếu trình sắp xếp thứ tự sao lưu cũng bị hỏng thì bất kỳ ai cũng có thể can thiệp.

Ví dụ: trình quản lý danh sách tổng hợp có thể bầu chọn trình sắp xếp thứ tự dự phòng. Với thiết lập này, người dùng có được tính bảo mật, khả năng chống kiểm duyệt và tính sống động. Ngay cả về lâu dài, một trình sắp xếp chuỗi hoạt động duy nhất có thể 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. Các công ty hiện có thể quản lý và tối ưu hóa sản phẩm của họ nhiều như họ đã quảng cáo về blockchain doanh nghiệp, nhưng giờ đây nó thực sự có thể là một chuỗi không cần cấp phép, an toàn và có thể tương tác.

Base dự định cuối cùng sẽ phân cấp bộ trình tự sắp xếp của họ, nhưng điều quan trọng là họ không làm như vậy không hoàn toàn "yêu cầu" phân cấp, trong khi các giải pháp khác thì không (hoặc chỉ yêu cầu phân cấp ở một mức độ rất hạn chế, chẳng hạn như một bộ nhỏ các trình sắp xếp). Nói rõ hơn, điều này yêu cầu bản tổng hợp phải triển khai các bước cần thiết để đảm bảo rằng bản tổng hợp được an toàn và duy trì khả năng chống kiểm duyệt (loại bỏ mọi khả năng nâng cấp tức thì, triển khai chứng thực mạnh mẽ, buộc đóng gói giao dịch, đấu giá MEV, v.v.). Và bản tổng hợp hiện tại không an toàn.

Đây sẽ là một cải tiến lớn so với các sản phẩm tập trung/lưu ký, không phải là sự thay thế ở mức tối đa các sản phẩm phi tập trung có thể. Rollup chỉ mở rộng không gian thiết kế. Đây phần lớn là lý do tại sao việc phân cấp trình sắp xếp chuỗi không phải là ưu tiên hàng đầu đối với hầu hết các nhóm tổng hợp - các mục khác quan trọng hơn nhiều để đảm bảo an ninh cho người dùng, khả năng chống kiểm duyệt và giảm niềm tin vào các nhà khai thác tổng hợp.

Tuy nhiên, nếu người dùng/các bên khác cần can thiệp để duy trì tính sống động và "khả năng chống kiểm duyệt theo thời gian thực" (không giống như việc mua lại giao dịch đóng gói bắt buộc thông qua L1 "chống kiểm duyệt tối đa"), điều này vẫn chưa lý tưởng. Dựa trên cơ chế giao dịch gói bắt buộc, việc 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ế. Rolllup, vốn rất ưu tiên khả năng chống kiểm duyệt theo thời gian thực và đảm bảo tính tồn tại tối đa, sẽ tìm kiếm sự phân cấp. Cũng có thể có những cân nhắc về quy định khi vận hành một trình sắp xếp trình tự được cấp phép duy nhất.

Bằng chứng ủy quyền (PoA)

Một cải tiến trực tiếp so với một trình sắp xếp chuỗi đơn sẽ là cho phép triển khai một số lượng nhỏ trình sắp xếp chuỗi (có thể là các công ty có uy tín khác) được phân bổ ở các vị trí địa lý khác nhau. Trình sắp xếp thứ tự có thể chỉ cần xoay đều theo kiểu vòng tròn. Khiến họ đăng một trái phiếu sẽ giúp khuyến khích hành vi trung thực.

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

Đấu giá trình tự sắp xếp hay còn gọi là Đấu giá MEV (MEVA)

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

Nguồn: Sự phân cấp của ZK Rollups

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

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

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

Xác suất để bất kỳ ai cũng có được quyền sắp xếp khối = tỷ lệ cam kết của ta trên tổng số cam kết. Các hình phạt có thể được áp dụng đối với những trình sắp xếp sai/có hại thông qua các phần thưởng bị mất, hình phạt làm chậm và hình phạt cắt giảm.

Lưu ý rằng điều này không yêu cầu sự đồng thuận của người sắp xếp chuỗi vì những lý do đã nêu ở trên. Rollup sử dụng L1 làm sự đồng thuận nên không cần phải có sự đồng thuận cục bộ. Trọng số đặt cược đóng vai trò hàng đầu trong cơ chế xoay vòng, xác định trình sắp xếp 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 các trình sắp xếp khác đề xuất.

Điều này có thể cấp quyền sắp xếp cho các kỷ nguyên có độ dài bất kỳ. Một người tham gia nhất định có thể có quyền đặt hàng 100 khối cuộn 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ỉ cần một trình tự sắp xếp tại một thời điểm nhất định. Tuy nhiên, việc cấp phép độc quyền mở rộng cũng có thể mang lại những tác động bên ngoài khác. Ngoài ra, người lãnh đạo có thể luân phiên từng khối như L1 bình thường.

Kích thước

Dymension là một dự án như vậy. Dymension Hub sẽ là một L1 điển hình trong Cosmos sử dụng cơ chế PoS đa số trung thực. L2 ("RollApp") của nó sẽ sử dụng nó để giải quyết và đồng thuận, đồng thời dựa vào Celestia như một kho lưu trữ dữ liệu sẵn có (vì vậy các L2 này thực sự là "chuỗi lạc quan" chứ không phải là "cuộn lên").

Theo Litepaper của họ, việc đặt hàng RollApp phi tập trung sẽ yêu cầu đặt cọc DYM (Tài sản gốc Dymension) trong Trung tâm kích thước. Việc bầu chọn người lãnh đạo được xác định bằng số tiền đặt cược DYM tương ứng. Những người sắp xếp chuỗi này sẽ nhận được doanh thu (phí và MEV khác) từ các lần tổng hợp tương ứng của họ, sau đó thanh toán các chi phí cơ bản liên quan cho Dymension Hub và Celestia.

Do cơ chế này, gần như toàn bộ giá trị thu được trong ngăn xếp này sẽ tích lũy trực tiếp vào mã thông báo DYM. Và nếu mã thông báo gốc của một người được sử dụng trong danh sách tổng hợp được sắp xếp (như StarkNet dự định thực hiện với STRK, được mô tả bên dưới), giá trị sẽ được tích lũy vào mã thông báo của riêng họ. Trung tâm Dymension được thiết lập tương tự như các bản tổng hợp Ethereum chỉ có thể sử dụng ETH để bầu chọn trình tự sắp xếp.

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

Bầu cử lãnh đạo và PoS không cần cấp phép cho sự đồng thuận L2

Nếu cần, đặt cược L2 cũng có thể được sử dụng cho cuộc bầu cử trình tự sắp xếp và sự đồng thuận cục bộ L2 trước khi L1 được hoàn tất.

Bầu cử người lãnh đạo trình tự PoS —Như đã đề cập ở trên, một số hình thức bầu cử lãnh đạo là cần thiết.

Sự đồng thuận PoS —Khuyến khích người xác nhận L2 đạt được sự đồng thuận L2 tạm thời trước khi giao dịch được L1 hoàn tất, cung cấp khả năng xác nhận trước mạnh mẽ hơn. Như đã đề cập ở trên, đây không phải là yêu cầu bắt buộc nhưng nó 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 để:

Sự đồng thuận PoS của DA — được sử dụng để khuyến khích việc cung cấp các chuỗi DA thay thế (alt-DA, chẳng hạn như theo ý muốn), đòi hỏi sự đồng thuận riêng biệt.

Bằng chứng — Khuyến khích người chứng minh tạo ra STARK.

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

1. Trình tự —Trình sắp xếp trình tự sắp xếp các giao dịch và đề xuất một khối

2. Đồng thuận L2 —Giao thức đồng thuận StarkNet ký các khối được đề xuất

3. Tạo bằng chứng —Người chứng minh tạo ra bằng chứng cho khối đã đạt được sự đồng thuận

4. Cập nhật trạng thái L1 —Gửi bằng chứng tới L1 để cập nhật trạng thái

Để biết thêm chi tiết về kế hoạch StarkNet, vui lòng tham khảo loạt bài viết này.

Có cần phải có sự đồng thuận L2 hay chỉ là sự đồng thuận L1?

Như chúng ta đã thấy, L2 có thể hoặc không thể thực hiện sự đồng thuận cục bộ của riêng mình (tức là, người xác nhận L2 sẽ ký các khối của nó trước khi gửi đến L1 để có được sự đồng thuận cuối cùng). Ví dụ: hợp đồng thông minh L1 có thể phản ứng khác nhau dựa trên các quy tắc riêng của chúng:

Sử dụng PoS của các nhà lãnh đạo bằng cách sử dụng bầu cử lãnh đạo và đồng thuận địa phương - "Tôi chỉ chấp nhận các khối được ký bởi sự đồng thuận L2."

PoS sử dụng bầu cử lãnh đạo - "Hiện tại chỉ Trình sắp xếp được chọn mới có thể cam kết các khối."

Nếu quá trình tổng hợp không có sự đồng thuận của địa phương thì cần phải thực hiện. Công việc của nó là:

Làm cho quy trình đề xuất khối tổng hợp trở nên không cần cấp phép.

Tạo một số tiêu chí để chọn khối tốt nhất cho chiều cao khối nhất định

Hãy để các nút hoặc hợp đồng giải quyết thực thi các quy tắc lựa chọn ngã ba

Kế thừa sự đồng thuận và tính quyết định của 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 tổng hợp. Ngay cả khi mã thông báo L2 chỉ được sử dụng cho một số hình thức bầu cử lãnh đạo (thay vì bỏ phiếu đồng thuận), giá trị do quyền xếp hạng tạo ra vẫn sẽ được tích lũy vào mã thông báo L2.

Nhược điểm của sự đồng thuận L2 (chỉ bầu cử lãnh đạo)

Bây giờ chúng ta hãy thảo luận về sự cân bằng giữa việc có/không có sự đồng thuận cục bộ cho đến khi L1 được hoàn tất.

Một lập luận được nhóm Fuel Labs đưa ra là sự đồng thuận cục bộ của L2 làm giảm khả năng phản đối 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. Việc tổng hợp không yêu cầu PoS bảo vệ vì các đợt tổng hợp được bảo mật bởi Ethereum”. Như đã đề cập trước đó, các bản tổng hợp vẫn có thể cung cấp các giải pháp chống kiểm duyệt ngay cả khi trình sắp xếp thứ tự ở trong tình huống các giao dịch bị kiểm duyệt (ví dụ: buộc trực tiếp các giao dịch phải được đóng gói vào L1 hoặc một thiết kế phức tạp hơn như thiết kế mà Kalman Lajk đang thực hiện ).

Một cách nói khác là sự đồng thuận hoàn toàn chỉ là "không hiệu quả". Ví dụ:

Chỉ có một nhà lãnh đạo giải trình tự duy nhất chạy mọi thứ trong một hộp tại một thời điểm,

p>

Tại một thời điểm, chỉ có một nhà lãnh đạo đặt hàng duy nhất chạy mọi thứ trong một hộp duy nhất và sau đó tất cả các nút khác cần bỏ phiếu cho đề xuất và đạt được sự đồng thuận,

Cái trước đơn giản hơn nhiều so với cái sau.

Tất nhiên, điều này thay đổi rất nhiều tùy thuộc vào thiết kế trình tự sắp xếp cụ thể và cơ chế đồng thuận được chọn. .

Ngoài ra, xin lưu ý rằng một số người đã nêu lên mối lo ngại về việc sử dụng PoS trong các mối lo ngại về phân cấp trình tự sắp xếp, chẳng hạn như như ở đây và ở đây. Mối quan hệ phức tạp giữa L1 và L2 có thể khiến việc xử lý một số loại tấn công nhất định trở nên khó khăn hơn.

Ưu điểm của việc bổ sung sự đồng thuận L2 (cộng với việc bầu chọn người lãnh đạo)

Đối với trình sắp xếp chuỗi, mục tiêu lớn nhất có thể là cung cấp cho người dùng xác nhận Mềm nhanh hơn. Hãy xem Các yêu cầu cơ học của StarkNet:

"Hoàn thiện L2 mạnh mẽ và nhanh chóng là mục tiêu của StarkNet. Do trạng thái của StarkNet chỉ được hoàn thiện sau khi lô giao dịch được chứng nhận bởi L1 (có thể mất vài giờ), do đó, giao thức phi tập trung L2 nên thực hiện các giao dịch đã lên kế hoạch trước khi lô giao dịch tiếp theo được chứng nhận. Hãy đưa ra các cam kết có ý nghĩa theo trình tự. "

Việc bổ sung một số hình thức đồng thuận (được hỗ trợ bởi an ninh kinh tế được cung cấp bởi nhiều nhà giải trình tự) sẽ giúp ích trong việc này. giai đoạn (xác nhận trước các khối tổng hợp không có vấn đề gì):

"Sự đồng thuận của Starknet phải có tinh thần trách nhiệm cao, tức là vi phạm an ninh, sinh hoạt có thể bị trừng phạt bằng cách chém bất kỳ bộ phận nào của người tham gia (kể cả phần lớn các lời cam kết ác ý)."

Rollup cũng có khả năng linh hoạt để thử nghiệm các điểm cân bằng giữa các phổ cơ chế đồng thuận khác nhau, vì cuối cùng chúng luôn có thể quay trở lại tính bảo mật của Ethereum L1 và tính khả dụng linh hoạt.

L1 chịu trách nhiệm sắp xếp Rollup

Tất cả các phương pháp trên đều mang lại cho trình sắp xếp chuỗi đặc quyền để tạo các khối cuộn lên dưới một số hình thức. Ví dụ: PoS không được phép tham gia, nhưng trình sắp xếp L2 được chọn cho một vị trí nhất định là bên duy nhất có thể gửi khối tại thời điểm đó. Ngoài ra còn có các đề xuất liên quan đề xuất không cấp đặc quyền cho bất kỳ trình sắp xếp L2 nào. Những thiết kế này dựa vào chính L1 để đặt hàng giao dịch.

Hoàn toàn "vô chính phủ"

Vitalik đã đề xuất ý tưởng "tình trạng vô chính phủ hoàn toàn" này ngay từ năm 2021. Cho phép bất cứ ai gửi lô giao dịch bất cứ lúc nào. Giao dịch đầu tiên mở rộng danh sách sẽ được chấp nhận. Nó đáp ứng hai yêu cầu tối thiểu được thảo luận ở trên về cách phân cấp trình sắp xếp thứ tự:

Resistance Witch - Anti -khả năng phù hợp được cung cấp bởi L1 (tức là phí giao dịch và kích thước khối/giới hạn gas).

Bầu cử người lãnh đạo —Việc bầu cử người lãnh đạo là ngầm định và được trì hoãn.

Điều này là đủ vì L1 đã cung cấp bảo mật rồi. Nếu các khối L2 đã được xuất bản trên L1, chúng sẽ chỉ trở thành mồ côi 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 sự đảm bảo bảo mật như chính L1.

Vitalik đã chỉ ra rằng một vấn đề lớn với giải pháp này là nó sẽ rất kém hiệu quả. Nhiều người tham gia có thể gửi các lô song song và chỉ một lô sẽ được đóng gói thành công. Điều này gây lãng phí rất nhiều công sức khi tạo ra bằng chứng hoặc tốn rất nhiều công sức không cần thiết cho việc xuất bản các lô giao dịch. Thật cồng kềnh và không hiệu quả khi biết liệu giao dịch của bạn có được xử lý nhanh chóng hay không.

Bản tổng hợp dựa trên chuỗi cơ bản (Bản tổng hợp dựa trên)

Tuy nhiên, hiện nay có thể biến thiết kế vô chính phủ này trở nên khả thi thông qua PBS. Nó cho phép đặt hàng chặt chẽ hơn, với tối đa một khối cuộn lên mỗi khối L1, do đó không lãng phí gas. (Mặc dù có thể có sự tính toán lãng phí). Người xây dựng L1 chỉ có thể đóng gói khối tổng hợp có giá trị cao nhất và xây dựng khối đó dựa trên giá thầu đầu vào của người tìm kiếm, tương tự như bất kỳ khối L1 nào. Để tránh lãng phí tính toán, theo mặc định, cũng hợp lý khi đặt quy trình chứng minh ZK không được phép (với các cơ chế tương ứng để cho phép khôi phục không được phép).

Đây là Justin Drake được đề xuất gần đây "Cuộn lên dựa trên chuỗi cơ bản"   Triết lý cốt lõi. Anh ấy sử dụng thuật ngữ này để chỉ các bản tổng hợp trong đó L1 (lớp "cơ sở") chiếm ưu thế trong thứ tự. Những người đề xuất L1 chỉ cần đảm bảo rằng khối tổng hợp được bao gồm trong khối L1 của riêng họ (có thể là thông qua trình tạo). Đây là một thiết lập đơn giản cung cấp tính sống động và phân cấp L1 ngay lập tức. Họ có thể tránh được một số vấn đề phức tạp như giải quyết việc buộc phải đóng gói các giao dịch trong khi trình sắp xếp L2 đang xem xét chúng. Ngoài ra, một số chi phí gas có thể được giảm do không cần phải xác minh chữ ký trình tự.

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 đến một nơi nào đó để người tìm kiếm/người xây dựng L1 có thể nhận chúng và tạo các khối cũng như các đốm dữ liệu chống lại chúng. Chúng có thể được gửi đến:

Nhóm giao dịch L1  —Họ có thể được gửi đến những người tìm kiếm/người xây dựng "có hiểu biết" cùng với một số siêu dữ liệu đặc biệt để giải thích chúng. Tuy nhiên, điều này có thể làm tăng đáng kể tải trọng cho nhóm giao dịch L1

Nhóm giao dịch p2p mới cho mỗi L2 —Một số giải pháp theo hướng này có vẻ thuyết phục hơn. Ngoài các kênh thông thường của họ, người tìm kiếm/người xây dựng sẽ bắt đầu kiểm tra và giải thích các giao dịch từ các nhóm giao dịch mới này.

Một nhược điểm rõ ràng là Rollup dựa trên chuỗi cơ bản sẽ hạn chế tính linh hoạt của trình sắp xếp chuỗi. Ví dụ:

Giảm thiểu MEV —Có thể sử dụng tính năng tổng hợp FCFS sáng tạo, nhóm giao dịch tiền điện tử và các biến thể khác.

Xác nhận trước —Người dùng L2 thích "xác nhận" giao dịch nhanh hơn " ”. Việc tổng hợp dựa trên chuỗi cơ sở sẽ quay trở lại thời gian chặn L1 (tối đa là 12 giây) hoặc đợi lâu hơn để xuất bản toàn bộ lô giao dịch.

Thật thú vị, đây chính xác là những gì mà các nhóm tổng hợp ban đầu đang xây dựng

https://twitter.com/DZack23/status/1635503593070657536?s=20

Justin đã chỉ ra rằng việc đặt lại có thể hữu ích.

https://twitter.com/jon_charb/status/1635898303106756609?s=20

Đây là những lĩnh vực nghiên cứu của EigenLayer, ít nhất như đã đề cập trong sách trắng của họ. Không rõ liệu đây có phải là một giải pháp thực tế hay không. Để cải thiện một cách hiệu quả những thiếu sót này thông qua việc đặt lại, người ta có thể hy vọng rằng tất cả những người đặt cược sẽ chọn chạy nó. Do đó, có vẻ hợp lý hơn khi triển khai ý tưởng theo cách này: hãy để tập hợp con những người đặt cược muốn làm như vậy chọn tham gia vào một lớp đặt hàng được chia sẻ riêng biệt (sẽ nói thêm về điều này sau).

Bằng chứng về hiệu quả (PoE)

Năm ngoái, Polygon Hermez đã đưa ra một đề xuất có tên PoE . Đây là một biến thể giải trình tự L1 khác dành riêng cho ZKR. Trình sắp xếp thứ tự ở đây là một vai trò hoàn toàn mở, bất kỳ ai cũng có thể gửi các lô giao dịch (tức là hoàn toàn vô chính phủ/tổng hợp dựa trên chuỗi cơ bản, vì vậy nó có những hạn chế tương tự). Cơ chế PoE gồm 2 bước gồm 2 bên:

Sequencer

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

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

Bộ tổng hợp

Bộ tổng hợp ở đây đề cập đến người chứng nhận ZK. Một lần nữa, đây là vai trò không có giấy phép và bất kỳ ai cũng có thể cạnh tranh. Rất đơn giản:

Sắp xếp các lô mang dữ liệu giao dịch theo vị trí xuất hiện trên L1 Sắp xếp theo L1.

Hợp đồng thông minh PoE chấp nhận bằng chứng hiệu lực đầu tiên được cập nhật lên trạng thái hợp lệ mới nhất. Trạng thái hợp lệ này bao gồm một hoặc nhiều lô đề xuất chưa được xác minh. .

Các công cụ tổng hợp có thể miễn phí Thực hiện phân tích chi phí-lợi ích của riêng bạn để tìm ra tần suất cấp chứng nhận thích hợp. Nếu họ giành chiến thắng trong cuộc thi, họ sẽ nhận được một phần phí, nhưng nếu họ đợi lâu hơn để đưa ra bằng chứng mới, chi phí xác minh cố định của họ sẽ được khấu hao theo nhiều giao dịch hơn. Nếu trình tổng hợp xuất bản bằng chứng muộn (nó không chứng minh được trạng thái mới) thì hợp đồng sẽ chỉ thực hiện chức năng khôi phục. Người chứng minh lãng phí tính toán, nhưng họ sẽ tiết kiệm được phần lớn khí đốt.

Phí được phân bổ như sau:

Phí cho các giao dịch L2 sẽ được xử lý và phân phối bởi một công ty tổng hợp tạo ra bằng chứng về tính hợp lệ.

Tất cả phí giao dịch sẽ được gửi đến trình sắp xếp tương ứng cho từng đợt.

Phí mà người sắp xếp chuỗi ký gửi để được phép tạo một lô duy nhất sẽ được gửi đến đơn vị tổng hợp, bao gồm lô đó trong bằng chứng hợp lệ .

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

Rollkit SR có khái niệm rất giống về "quy tắc lựa chọn ngã ba thuần túy", như được mô tả ở đây. không có trình sắp xếp đặc quyền. Các nút được sắp xếp theo quy tắc của lớp DA và áp dụng quy tắc lựa chọn ngã ba "đến trước được phục vụ trước".

Xếp hạng L1 Kinh tế học

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

Thật khó để nói đây là điều tốt hay điều xấu:

Lợi ích —Điều này hơi giống một "liên minh kinh tế L1" (ví dụ: ETH có thể thu được nhiều giá trị hơn).

Nhược điểm - Một số người sẽ lo lắng về ưu đãi của lớp cơ sở này (ví dụ: rủi ro tập trung của các công cụ khai thác Bitcoin, nhưng có thể đã quá muộn).

Sử dụng tính năng sắp xếp L1 cũng có thể hiệu quả, đặc biệt là có thể bắt đầu tổng hợp dễ dàng hơn nhưng lại khiến họ phải từ bỏ Việc cung cấp rất nhiều MEV đến L1 (bản thân nó có thể bắt được những MEV này) là không thể. Một trong những lợi ích lớn nhất của việc tổng hợp thực sự là về mặt tài chính - khi lớp DA bắt đầu mở rộng quy mô, những chi phí đó sẽ giảm xuống và họ chỉ phải trả một khoản phí nhỏ cho L1. Thời gian chặn chậm hơn và cách tiếp cận MEV ban đầu cũng không lý tưởng cho người dùng.

Khuyến khích thế hệ ZK

Xin lưu ý rằng thị trường cạnh tranh được mô tả ở trên trong PoE có thể tập trung xung quanh công cụ tổng hợp nhanh nhất. Thị trường máy chuẩn ZK nhìn chung có hai vấn đề kinh tế cần được 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 này

Cách khiến việc gửi bằng chứng không cần được phép, khiến nó trở nên mang tính cạnh tranh và liều lĩnh Tuyệt vời thị trường (ví dụ: nếu Prover chính bị hỏng thì sẽ không ảnh hưởng đến mạng)

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

Thị trường cạnh tranh

Ở một thái cực, bạn có thể có một mô hình cạnh tranh mở. Trong thị trường người chứng minh không được phép, tất cả người chứng minh đều cạnh tranh để tạo ra bằng chứng cho khối được tạo ra bởi trình tự tổng hợp/đồng thuận. Người đầu tiên tạo bằng chứng có thể nhận được bất kỳ phần thưởng nào được giao cho người chứng minh. Mô hình này rất hiệu quả trong việc tìm ra người chứng minh tốt nhất.

Điều này trông rất giống với hoạt động khai thác bằng chứng công việc. Tuy nhiên, có một sự khác biệt duy nhất ở đây - bằng chứng là một phép tính xác định. Vì vậy, người chứng minh có lợi thế dù nhỏ nhưng nhất quán sẽ gần như “luôn” giành chiến thắng. Thị trường này có thể dễ dàng trở thành tập trung.

Trong khai thác PoW, có những thuộc tính tốt hơn về tính ngẫu nhiên - nếu tôi có 1% sức mạnh khai thác, tôi sẽ nhận được 1% phần thưởng.

Mô hình chứng minh cạnh tranh này cũng chưa tối ưu về mặt dư thừa tính toán - nhiều người chứng minh cạnh tranh với nhau và dành nguồn lực để tạo ra bằng chứng, nhưng chỉ một người sẽ thắng (tương tự để khai thác PoW).

Cơ chế dựa trên chuyển động xoay (chẳng hạn như trọng lượng cầm cố)

Ngoài ra, người ta có thể luân phiên giữa những người chứng minh, cho họ một cơ hội (ví dụ: dựa trên một số khoản đặt cược hoặc dựa trên danh tiếng). Điều này có thể được phân cấp nhiều hơn, nhưng có thể gây ra sự thiếu hiệu quả, chẳng hạn như sự chậm trễ trong việc chứng minh (một người chứng minh "chậm" sẽ có cơ hội tạo ra một bằng chứng, trong khi một người chứng minh khác có thể đã có khả năng tạo ra một bằng chứng nhanh hơn và hiệu quả hơn). Tuy nhiên, nó ngăn cản nhiều người chứng minh lãng phí tính toán bằng cách cạnh tranh để tạo ra một bằng chứng, vì cuối cùng chỉ có một bằng chứng có giá trị.

Hơn nữa, nếu người đến lượt mình không thể đưa ra được bằng chứng (dù có ác ý hay vô tình), một vấn đề xảy ra. Nếu một vòng rất dài (ví dụ: người chứng minh đến lượt nó có thể độc quyền tạo bằng chứng trong vài giờ) và người chứng minh không hoạt động thì giao thức sẽ khó phục hồi. Nếu vòng đấu ngắn, những người chứng minh khác có thể tham gia và bắt kịp khi người chứng minh chính không tạo được bằng chứng.

Bạn cũng có thể cho phép bất kỳ ai xuất bản bằng chứng, nhưng chỉ những người chứng nhận được chỉ định mới có thể Nhận phần thưởng trong thời gian đó giới hạn. Vì vậy, nếu những người chứng minh được chỉ định này bị loại, những người chứng minh khác có thể công bố bằng chứng nhưng họ không thể nhận được phần thưởng. Điều này mang tính vị tha vì tài nguyên được sử dụng cho việc tính toán mà không mang lại lợi nhuận.

Scroll đang khám phá nhiều phương pháp dựa trên xoay vòng hơn, gán dấu vết thực thi cho " con lăn" được chọn ngẫu nhiên ( người chứng nhận):

Ngoài ra còn có nhiều câu hỏi thú vị về cách tính phí chứng thực ở cấp độ người dùng khi sắp xếp. Bạn có thể tìm hiểu thêm thảo luận về các chủ đề này tại đây:

- Ye Zhang of Scroll ;Trong bài viết của anh ấy "Zk-Rollup phi tập trung", ông đã thảo luận về khả năng của một mạng lưới con lăn quay dựa trên việc đặt cược + đấu giá MEV để có được quyền phân loại mà không cần sự đồng thuận L2

- "Tổng quan về Kiến trúc cuộn" cung cấp thêm thông tin chi tiết về mô hình con lăn có thể có

- Giao thức phi tập trung Starknet IV - Bằng chứng trong giao thức

- Giao thức phi tập trung Starknet VI - Vấn đề về bộ đệm

Chia sẻ sắp xếp

Hầu hết các giải pháp ban đầu đều cho rằng mỗi lần tổng hợp sẽ cần tìm ra cách phân cấp chúng hoàn toàn trên trình sắp xếp thứ tự của chính nó. Nhưng trường hợp này không xảy ra, chẳng hạn như tùy chọn sắp xếp L1 đã đề cập ở trên. Nhiều bản tổng hợp có tùy chọn sử dụng trình sắp xếp thứ tự được chia sẻ (SS). Điều này có một số lợi ích tuyệt vời:

Nằm thẳng  — Đừng lo lắng về cách phân cấp trình sắp xếp thứ tự của bạn, thật khó! Chỉ cần nhúng tùy chọn này. Không cần phải tuyển dụng và quản lý một tập hợp con người xác nhận bổ sung. Mặc dù bạn sẽ luôn gặp phải nhiều bản giới thiệu tài chính dưới danh nghĩa "mô-đun", nhưng đây thực sự là một cách tiếp cận rất "mô-đun" - loại bỏ trình tự giao dịch thành một lớp riêng biệt. Trình tự chia sẻ thực chất là một công ty SaaS (Trình tự như một dịch vụ).

Kết hợp an ninh và phân cấp —cho phép một trật tự duy nhất lớp xây dựng an ninh kinh tế mạnh mẽ (xác nhận trước mạnh mẽ hơn) và khả năng chống kiểm duyệt theo thời gian thực, thay vì thực hiện nhiều ủy ban nhỏ cho mỗi lần tổng hợp riêng lẻ.

Xác nhận giao dịch nhanh —Trình tự tổng hợp một loại khác Máy chủ cũng có thể thực hiện việc này, nhưng lưu ý rằng người dùng cũng nhận được xác nhận trước về thời gian chặn L1 cực nhanh với thứ tự chia sẻ.

Tính nguyên tử của chuỗi chéo —Thực hiện các giao dịch đồng thời trên chuỗi A và chuỗi b (việc này phức tạp nên tôi sẽ đi sâu hơn vào phần trình bày bên dưới ).

Đơn giản chỉ cần sử dụng L1 cục bộ làm trình sắp xếp chuỗi cho nhiều L2 về cơ bản có một số nhược điểm:

Vẫn bị giới hạn ở thông lượng sắp xếp giao dịch và dữ liệu L1

Mất khả năng cung cấp cho người dùng L2 xác nhận giao dịch nhanh hơn thời gian chặn L1 (mặc dù có sự đảm bảo yếu hơn trước khi đạt được sự đồng thuận L1)

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

Vậy liệu chúng ta có thể thiết kế một lớp phân loại dùng chung chuyên dụng, hiệu quả hơn thay vì để L1 làm việc này không ...

Metro - Trình phân tích trình tự được chia sẻ của Astria

Metro là một đề xuất cho các lớp sắp xếp dùng chung. Bạn có thể tham khảo bài viết nghiên cứu của Evan Forbes, nói chuyện về tính mô-đun và cuộc nói chuyện tại Hội nghị thượng đỉnh về bảo mật chung để biết thêm chi tiết. Một nhóm Astria do Josh Bowen dẫn đầu đang làm việc để triển khai thiết kế của Metro.

Tách biệt thực thi khỏi sắp xếp

Nút Rollup hiện tại thực sự xử lý ba việc:

Thuộc tính quan trọng ở đây là "tách biệt việc thực thi và sắp xếp". Trong trường hợp này, trình sắp xếp thứ tự được chia sẻ:

Dành cho những người chọn sử dụng nó làm công cụ sắp xếp lớp cho nhiều thứ tự giao dịch khác nhau của chuỗi

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

Trình tự không có trạng thái  - các nút trình tự chia sẻ không còn cần lưu trữ trạng thái hoàn chỉnh cho tất cả các lần tổng hợp khác nhau. Họ loại bỏ các tính toán thực hiện. Những trở ngại lớn mà các trình sắp xếp chuỗi truyền thống hiện đang gặp phải không còn tồn tại nữa.

Khi việc thực thi được tách ra khỏi sự đồng thuận, hiệu quả của sự đồng thuận trở nên đặc biệt cao. Quá trình này chỉ giới hạn ở lớp phát tin nhắn (và do đó diễn ra rất nhanh). Các nút có thể rất hiệu quả nếu tất cả những gì chúng phải làm là tạo ra một khối giao dịch theo trình tự và đạt được sự đồng thuận về khối đó mà không cần thực hiện tất cả các thao tác. Việc thực thi và chứng minh có thể được thực hiện bởi một bên khác sau khi đạt được sự đồng thuận về mệnh lệnh.

Tính bảo mật và phân cấp trình tự tích hợp

Các nút trình tự được chia sẻ có thể vẫn tương đối nhẹ và thậm chí có quy mô theo chiều ngang (bằng cách chọn một tập hợp con ngẫu nhiên của các nút đồng thuận) Sắp xếp các tập hợp con giao dịch khác nhau). Kết quả - có khả năng làm cho lớp sắp xếp này trở nên phi tập trung hơn. Trình sắp xếp chuỗi truyền thống cần lưu trữ trạng thái lớn của chuỗi và thực hiện thực thi hoàn chỉnh chuỗi đó.

Ngoài ra, chúng tôi tập hợp các nguồn lực trên nhiều chuỗi - không cần phải cuộn lại giữa nhiều Split Sự đồng thuận PoS giữa. Nhận tất cả chúng ở một nơi. So với nhiều bản tổng hợp triển khai một tập hợp con các trình sắp xếp chuỗi, cách tiếp cận này có thể dẫn đến một tập hợp con các trình sắp xếp chuỗi phi tập trung hơn (chống kiểm duyệt) mà trên đó đặt cược nhiều giá trị có thể cắt giảm hơn (chống tái hợp). Điều này quan trọng vì:

Sắp xếp  - cung cấp khả năng chống kiểm duyệt theo thời gian thực cho người dùng tổng hợp. tuyến phòng thủ cho tình dục và hoạt động.

Thực thi và chứng minh  - có thể được thực hiện theo cách sắp xếp mà không cần yêu cầu phân quyền mạnh mẽ. Tất cả những gì chúng ta cần là một đảng trung thực.

Sau khi đạt được sự đồng thuận về thứ tự giao dịch, việc thực hiện (và chứng thực) có thể được trì hoãn hoàn toàn Chuỗi khác nhau để tiến hành:

Đồng thuận và đặt hàng mềm —Trình sắp xếp được chia sẻ cung cấp cho người dùng khả năng chuẩn bị nhanh chóng xác nhận

Sự đồng thuận đã được xác nhận và DA —dữ liệu giao dịch đã được hoàn thiện trên lớp DA để mọi người có thể xem

Thực thi và chứng minh dễ dàng —Bất kỳ ai cũng có thể thực thi và tạo bằng chứng về trạng thái giao dịch đã được xác nhận

Công việc được thực hiện ở lớp thực thi không cần phải được phân cấp vì đây không phải là nguyên nhân gây ra sự phản đối kiểm duyệt. Trình sắp xếp chuỗi đơn không phải là giải pháp lý tưởng để chống lại sự kiểm duyệt, nhưng nhược điểm không liên quan gì đến luồng thực thi của trình sắp xếp chuỗi. Quyền kiểm duyệt của họ đến từ khả năng sắp xếp và đóng gói các giao dịch. Ở lớp thực thi, trình tuần tự được chia sẻ đã cung cấp các đầu vào giao dịch được sắp xếp và do đó cung cấp khả năng chống kiểm duyệt. Khi đó việc tính toán, so sánh các cam kết của nhà nước sau này không cần phải phân cấp như vậy.

Thực thi mềm

Bước đầu tiên để thực thi mềm nhanh chóng là điều người dùng thích:

p>

Điều này đòi hỏi một số hình thức đồng thuận (hoặc một trình tự sắp xếp tập trung) để mang lại trải nghiệm tuyệt vời cho người dùng:

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

Vì vậy, khi trình sắp xếp được chia sẻ tạo một khối, người dùng sẽ nhận được xác nhận mềm. Bất kỳ ai cũng có thể tải xuống các giao dịch đồng thuận và áp dụng trước cho tiểu bang. Độ mạnh của xác nhận này phụ thuộc vào việc xây dựng trình sắp xếp chung (phân quyền, an ninh kinh tế, quy tắc lựa chọn nhánh, v.v.). Các giao dịch này có thể được coi là hoàn tất sau khi dữ liệu thực sự được phát hành lên lớp cơ sở. Sau đó, tính toán cuối cùng của các nghiệm trạng thái và các bằng chứng liên quan có thể được tạo ra và gửi đi.

Bản tổng hợp lười biếng

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

Lưu ý rằng vì trình sắp xếp được chia sẻ không thể tạo khối theo cách truy cập trạng thái hoàn chỉnh nên chúng không được kiểm tra. Chuyển đổi trạng thái không hợp lệ chức năng. Do đó, một máy trạng thái sử dụng tính năng "lazy rollup" của trình sắp xếp được chia sẻ phải có khả năng xử lý các giao dịch không hợp lệ. Các nút có thể chỉ cần xóa các giao dịch không hợp lệ/khôi phục trong khi thực hiện các giao dịch đã đặt hàng để tính toán trạng thái kết quả. Các bản tổng hợp truyền thống triển khai thực thi đúng lúc không gặp phải hạn chế này.

Nếu quá trình tổng hợp yêu cầu quyền truy cập vào trạng thái để nén các giao dịch trước khi đóng gói chúng trên chuỗi thì đây là không thể nào. Ví dụ: ở đây tổng hợp có quy tắc hợp lệ khối trong đó tất cả các giao dịch có trong khối đều hợp lệ. Nếu một bản tổng hợp yêu cầu các giao dịch nén nhưng không có quyền truy cập trạng thái thì một trình sắp xếp được chia sẻ đặc biệt có thể được tạo riêng cho loại bản tổng hợp này (ví dụ: một cái gì đó như Fuel v2 hoặc một bản tổng hợp có nhóm giao dịch riêng tư).

Trả tiền gas

Hãy để trình sắp xếp được chia sẻ này chạy, phải có có một số cơ chế để người dùng thanh toán cho các giao dịch của họ được đóng gói trong L1. Bạn có thể chỉ cần sử dụng chữ ký và địa chỉ hiện có đã có trong hầu hết các loại giao dịch tổng hợp để thanh toán chi phí gas của lớp đặt hàng chung. Điều này sẽ yêu cầu trình sắp xếp được chia sẻ phải hiểu trạng thái tối thiểu được yêu cầu bởi các triển khai khác nhau, chẳng hạn như: phân tích chữ ký, nonces, trừ gas khỏi tài khoản, v.v. Ngoài ra, các khoản thanh toán có thể liên quan đến một số giao dịch được đóng gói trên một trình sắp xếp được chia sẻ, trong đó bất kỳ ai cũng có thể thanh toán cho việc đóng gói dữ liệu tùy ý. Đây là một không gian thiết kế mở.

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

Bản tổng hợp có thể kế thừa lựa chọn phân nhánh của trình sắp xếp thứ tự được chia sẻ mà chúng sử dụng quy tắc. Sau đó, các nút đầy đủ của tổng số thực sự là các máy khách nhẹ của trình sắp xếp được chia sẻ và chúng kiểm tra một số lời hứa nhất định để cho biết khối tổng hợp nào là chính xác với chiều cao khối nhất định.

Tuy nhiên, việc kế thừa các quy tắc lựa chọn nhánh của trình sắp xếp thứ tự được chia sẻ là tùy chọn—bạn Bạn có thể chỉ cần yêu cầu tổng hợp để xử lý (không nhất thiết phải thực thi) tất cả dữ liệu giao dịch được gửi đến lớp cơ sở. Nó sẽ kế thừa một cách hiệu quả khả năng chống kiểm duyệt và tính sống động của lớp cơ sở, nhưng phải trả giá bằng nhiều tính năng mà người dùng yêu thích về trình sắp xếp được chia sẻ.

MEV

Giả sử một bản tổng hợp muốn kế thừa các quy tắc lựa chọn nhánh của trình sắp xếp thứ tự được chia sẻ của nó và đạt được sự thực thi mềm nhanh chóng, Từ Về phía MEV, trình sắp xếp được chia sẻ này đương nhiên sẽ ở một vị trí rất tập trung. Nó xác định việc đóng gói và sắp xếp giao dịch nào mà bản tổng hợp sẽ tuân thủ.

Tuy nhiên, điều đó không có nghĩa là việc tổng hợp phải thực hiện giao dịch được cung cấp bởi trình sắp xếp thứ tự được chia sẻ hoặc như được cung cấp bởi thực hiện theo trình tự. Về mặt kỹ thuật, bạn có thể cho phép nút toán tử cuộn lên 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 trình sắp xếp thứ tự chia sẻ xuất bản sau khi thực hiện. Tuy nhiên, như đã đề cập ở trên, bạn sẽ mất hầu hết các tính năng hay của việc sử dụng trình sắp xếp được chia sẻ ngay từ đầu, vì vậy điều này dường như khó xảy ra.

Ngay cả trong trường hợp này, MEV vẫn có thể tồn tại trong lớp đặt hàng dùng chung vì nó có Gói thỏa thuận. Nếu thực sự muốn, bạn thậm chí có thể cho phép danh sách tổng hợp của mình loại trừ một số giao dịch nhất định khỏi vòng xử lý thứ hai (ví dụ: sử dụng một số điều kiện hợp lệ để loại trừ một số loại giao dịch nhất định), nhưng điều này tất nhiên sẽ trở nên khó hiểu và ít bị phản kháng hơn. mất đi lợi ích của trình sắp xếp được chia sẻ.

Trao đổi trình tự chia sẻ

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

Tuy nhiên, trình sắp xếp được chia sẻ thực sự chỉ là nhà cung cấp dịch vụ - họ không có trạng thái có giá trị liên quan. Một bản tổng hợp sử dụng trình sắp xếp được chia sẻ nhất định sẽ duy trì khả năng phân nhánh, chỉ yêu cầu một phân nhánh nhỏ hơn để hỗ trợ các cơ chế đặt hàng khác (ví dụ: khi xảy ra tình huống trong đó trình sắp xếp được chia sẻ trích xuất quá nhiều giá trị). Điều này hy vọng sẽ giữ cho các trình sắp xếp được chia sẻ có tính cạnh tranh.

Hiệu ứng mạng có thể khiến việc này trở nên khó khăn hơn. Nếu nhiều lần cuộn bắt đầu sử dụng trình sắp xếp được chia sẻ và chúng đạt được hiệu ứng mạng rất lớn (ví dụ: nếu chúng đạt được giá trị có ý nghĩa từ tính nguyên tử chuỗi chéo tiềm năng của nhiều chuỗi), thì trừ khi các lần cuộn khác cũng sẵn sàng di chuyển, nếu không thì điều đó có thể gây đau đớn để thoát khỏi hiệu ứng mạng này.

Espresso Sequencer, ESQ—bảo mật được đảm bảo bởi EigenLayer

Bạn có thể đã xem Sách trắng EigenLayer đã đề cập Trình sắp xếp trình tự chia sẻ tập trung là một của những người tiêu dùng tiềm năng của việc đặt lại. Trình sắp xếp chuỗi được chia sẻ này có thể được bảo mật bởi các bên liên quan lại ETH và nó có thể xử lý thứ tự giao dịch cho nhiều L2 khác nhau.

À, Espresso vừa công bố công khai kế hoạch của họ về trình tự chia sẻ. Nó có thể tận dụng các trình khôi phục EigenLayer để cung cấp bảo mật cho sự đồng thuận của nó. Để hình dung rõ hơn, hình ảnh sau đây cho thấy bản tổng hợp hiện tại trông như thế nào:

Hình ảnh bên dưới cho thấy quá trình tổng hợp trông như thế nào với một trình sắp xếp được chia sẻ như Espresso:

Ý tưởng chung của Espresso Sequencer (ESQ) rất giống với Metro. Nó hoạt động theo cách tương tự - loại bỏ việc thực hiện giao dịch ra khỏi đơn đặt hàng. Ngoài ra, ESQ sẽ cung cấp dữ liệu sẵn có cho các giao dịch.

Sự đồng thuận HotShot và tính sẵn có của dữ liệu Espresso (DA)

Để cung cấp thông tin cơ bản ngắn gọn, Ethereum hiện sử dụng Gasper làm cơ chế đồng thuận (Casper FFG làm công cụ hoàn thiện + LMD GHOST làm lựa chọn phân nhánh luật lệ ). Khía cạnh "quá dài để đọc" có liên quan là Gasper duy trì hoạt động của mạng ngay cả trong những điều kiện bi quan khi hầu hết các nút có thể thoát khỏi mạng (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 có sẵn động với các tiền tố cuối cùng. Nhưng trong khi duy trì tính năng hoạt động theo thời gian thực của mạng, Gasper đã hy sinh tính chất cuối cùng của giao dịch nhanh chóng (khả năng xác nhận giao dịch nhanh nhất mà mạng cho phép).

Nói chung, ESQ bao gồm:

HotShot —ESQ được xây dựng trên giao thức đồng thuận HotShot, ưu tiên tính hữu hạn nhanh (khả năng phản hồi lạc quan) hơn là tính khả dụng linh hoạt, Không giống như Gasper. Giống như Ethereum, nó cũng có thể mở rộng số lượng trình xác thực được hỗ trợ lên mức đáng kinh ngạc.

Espresso DA —ESQ cũng cung cấp các tùy chọn DA tùy chọn cho chuỗi. Cơ chế này cũng được sử dụng để mở rộng sự đồng thuận của họ.

Hợp đồng thông minh Sequencer —Hợp đồng thông minh này hoạt động như một ứng dụng khách đơn giản để xác minh sự đồng thuận của HotShot và Ghi lại các điểm kiểm tra (cam kết về điểm vào nhật ký giao dịch đã sắp xếp). Ngoài ra, nó còn quản lý những người đặt cược sự đồng thuận HotShot PoS của ESQ.

Lớp mạng —cho phép giao dịch và giao dịch giữa các nút tham gia HotShot và Espresso DA Truyền đạt sự đồng thuận tin nhắn.

API REST cuộn lên —API cuộn lên L2 để tích hợp với trình sắp xếp thứ tự Espresso.

Chúng ta hãy xem xét kỹ hơn tình hình DA. Trong trường hợp lạc quan, các nút có băng thông cao sẽ cung cấp dữ liệu cho tất cả các nút khác và tính khả dụng của từng khối riêng lẻ cũng được hỗ trợ bởi một ủy ban nhỏ được chọn ngẫu nhiên. Do nguy cơ xảy ra DDoS và các cuộc tấn công hối lộ nhằm vào các ủy ban nhỏ, Phân tán thông tin có thể xác minh (VID) sẽ được sử dụng để cung cấp đường dẫn dự phòng đáng tin cậy (nhưng chậm hơn) nhằm đảm bảo DA miễn là tỷ lệ tất cả các nút đủ cao (Tính theo cổ phần) có không bị tấn công.

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

Quy trình giao dịch

Hợp đồng trình sắp xếp trình tự —HotShot tương tác trực tiếp với hợp đồng trình sắp xếp trình tự L1 của nó. Hợp đồng này xác nhận 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 mà nó đã đặt hàng. Hợp đồng lưu trữ nhật ký cam kết khối chỉ bổ sung, không phải khối hoàn chỉnh. Tuy nhiên, bất kỳ ai cũng có thể xác thực bất kỳ khối nào theo cam kết.

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

Các giao dịch được chuyển tiếp đến trình sắp xếp thứ tự được chia sẻ sẽ được sắp xếp theo trình tự và sau đó được gửi trước khi hoàn tất trên L1 Quay lại người thực thi và người chứng minh của rollup. Trình sắp xếp trình tự được chia sẻ cũng gửi một cam kết tới khối tới hợp đồng trình sắp xếp trình tự L1 của nó, cùng với chứng chỉ được sử dụng để xác thực khối. Điều này cho phép hợp đồng tổng hợp L1 so sánh bằng chứng cập nhật trạng thái tổng hợp với các cam kết khối được chứng nhận là đầu ra đồng thuận.

Toàn cảnh quá trình giao dịch:

Tính nguyên tử chuỗi chéo

Như đã đề cập trong bài viết về Espresso, trình sắp xếp trình tự được chia sẻ có thể cung cấp một số trường hợp sử dụng thú vị liên quan đến tính nguyên tử của chuỗi chéo:

p>

"Một lớp đặt hàng được chia sẻ trên nhiều lần tổng hợp hứa hẹn sẽ giúp 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. Không cần phải tùy chỉnh thứ tự cho một chuỗi khác. Ở đó là một lợi ích miễn phí cho trình sắp xếp chuỗi xây dựng ứng dụng khách nhẹ, không mất phí, tạo ra khả năng tiết kiệm trước mắt. Việc kết nối giữa các bản tổng hợp cũng cho phép tiết kiệm liên tục bằng cách loại bỏ nhu cầu về một bản tổng hợp nhất định để đồng bộ hóa sự đồng thuận một cách độc lập với các bản tổng hợp khác. Trình sắp xếp chuỗi được chia sẻ cũng cung cấp một lợi thế bảo mật cho cầu nối: nó đảm bảo rằng một giao dịch sẽ được hoàn tất trong một bản tổng hợp nếu và chỉ nếu (hoặc thậm chí cùng lúc) giao dịch đó được hoàn tất trong một bản tổng hợp khác.

Ngoài ra, trình sắp xếp được chia sẻ sẽ nâng cao khả năng của người dùng trong việc thể hiện sự phụ thuộc nguyên tử giữa các giao dịch tổng hợp khác nhau. Thông thường, Alice sẽ ký và xuất bản giao dịch rollup-A t của mình bên cạnh 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 thực hiện từ lâu trước giao dịch của Bob, khiến Bob có tùy chọn hủy bỏ dài hạn (ví dụ: hủy bỏ giao dịch). Sự mất cân bằng tùy chọn này có thể được giảm thiểu bằng trình sắp xếp thứ tự được chia sẻ, trong đó Alice và Bob có thể gửi hai giao dịch cùng nhau dưới dạng một gói đã ký (tức là trình sắp xếp thứ tự phải coi hai giao dịch là một). ”

Khi hoạt động trên chuỗi cuối cùng cũng bắt đầu phát triển (tôi hy vọng), cặp chéo này -domain MEV  ;có ảnh hưởng. Một ví dụ điển hình là "arbitrage nguyên tử". Cùng một tài sản được giao dịch trên hai chuỗi khác nhau ở hai mức giá khác nhau. Người tìm kiếm hy vọng kiếm được lợi nhuận từ việc này bằng cách thực hiện hai giao dịch cùng lúc mà không gặp rủi ro khi thực hiện. Ví dụ:

Giao dịch 1 (T1)—Thấp khi tổng số tiền 1 (R1) Mua ETH với giá cao

Giao dịch 2 (T2)—Bán ETH với giá cao trong Rollup 2 (R2)

Để đạt được chênh lệch giá nguyên tử = cả hai giao dịch đều được thực hiện hoặc không được thực hiện. Nếu cả hai tập hợp chọn vào cùng một trình sắp xếp được chia sẻ, nó có thể đạt được sự chênh lệch nguyên tử này cho người tìm kiếm. Việc chia sẻ trình tự sắp xếp ở đây đảm bảo rằng:

T1 được bao gồm trong trình tự tới R1 In luồng lệnh, nếu và chỉ nếu:

T2 cũng được bao gồm trong luồng lệnh tới R2

Giả sử rằng máy ảo tổng hợp thực hiện tuần tự tất cả các giao dịch trong các luồng tương ứng (tức là không có hướng dẫn không hợp lệ, nhưng một số hướng dẫn có thể ném lỗi, nhưng không ảnh hưởng đến trạng thái), thì chúng tôi cũng có thể đảm bảo:

T1 nằm trong R1 Thực thi trên R2 khi và chỉ khi:

T2 cũng thực thi trên R2

Tuy nhiên, điều này vẫn không đảm bảo giống như giao dịch trên máy trạng thái dùng chung (ví dụ: hoàn toàn trên Ethereum L1). Như đã đề cập trước đó, các trình sắp xếp được chia sẻ không giữ trạng thái cho các lần tổng hợp này và chúng không thực hiện các giao dịch. Do đó, không có gì đảm bảo hoàn toàn rằng một giao dịch (trên R1 hoặc R2) sẽ không bị khôi phục khi được thực hiện.

Việc xây dựng các nguyên hàm cấp cao hơn trực tiếp trên nền tảng này là một vấn đề. Ví dụ: nếu bạn cố gắng xây dựng một hàm cầu nối chuỗi chéo "burn-mint" nhanh chóng trên đầu trình sắp xếp được chia sẻ này, thì hàm này sẽ đồng thời thực hiện các thao tác sau ở cùng một chiều cao khối:

Ghi đầu vào trên R1

Truyền đầu ra trên R2

Bạn có thể gặp phải tình huống này:

Hành vi hủy trên R1 có thể gây ra lỗi không mong muốn, chẳng hạn như bị vô hiệu bởi việc thực hiện giao dịch khác, nhưng hành vi truyền trên R2 sẽ không hợp lệ vì bất kỳ lý do gì, vì vậy nó sẽ là được thực hiện hoàn toàn.

Bạn có thể thấy đây sẽ là một vấn đề lớn.

Có thể trong một số trường hợp, kết quả mong đợi của cả hai giao dịch có thể được xác định miễn là cả hai giao dịch đều được đưa vào luồng đầu vào và do đó được thực thi, nhưng trường hợp này thường không xảy ra. Một câu hỏi mở là quy trình này có thể:

Đảm bảo —T1 và T2 sẽ có trong luồng riêng và (có thể) cả hai sẽ được thực thi.

Không có gì đảm bảo —việc thực hiện thành công cả hai giao dịch và trạng thái mong đợi đạt được.

Sự "bảo đảm" này cho hoạt động kinh doanh chênh lệch giá nguyên tử (người tìm kiếm đã có Nó có thể đủ cho tài sản cần thiết cho các giao dịch này), nhưng rõ ràng khả năng kết hợp không được đồng bộ hóa của các máy trạng thái dùng chung. Đối với những thứ như cho vay flash xuyên chuỗi, chỉ đảm bảo này là không đủ.

Tuy nhiên, khi kết hợp với các giao thức nhắn tin chuỗi chéo khác, điều này trong các cài đặt khác vẫn có thể xảy ra hữu ích. Hãy xem cách tạo điều kiện thuận lợi cho việc trao đổi NFT nguyên tử chuỗi chéo khi được sử dụng với các giao thức nhắn tin cuộn chéo:

- T1 chuyển ETH từ U1 (người dùng 1) sang SC1 (hợp đồng thông minh 1) trên R1

- T2 chuyển NFT Di chuyển từ U2 (Người dùng 2) tới SC2 (Hợp đồng thông minh 2) trên R2

- Nếu và chỉ khi SC1 lần đầu tiên nhận được tin nhắn từ SC2 xác nhận rằng NFT đã được gửi, nó sẽ Cho phép U2 để đổi ETH

- SC2 sẽ cho phép điều này nếu và chỉ nếu lần đầu tiên nó nhận được tin nhắn từ SC1 xác nhận rằng ETH đã được gửi U1 đổi NFT

- Cả hai hợp đồng thông minh đều thực hiện khóa thời gian để nếu có. Nếu một bên thất bại, tất cả các bên có thể khôi phục tài sản của họ

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

Nếu không có trình tự sắp xếp chung để biến nó thành nguyên tử, cả hai bên có thể thỏa thuận về giá. Nhưng U1 có thể gửi giao dịch của họ và U2 có thể đợi và quyết định xem họ có muốn hủy giao dịch hay không. Với trình sắp xếp thứ tự được chia sẻ, các giao dịch của họ sẽ bị khóa.

Đó là về tính nguyên tử chuỗi chéo được thực hiện bởi các trình sắp xếp trình tự được chia sẻ. Tóm tắt:

Sức mạnh chính xác và tính hữu ích của những đảm bảo được đưa ra ở đây vẫn chưa được chứng minh

p>

Điều này có thể hữu ích cho hoạt động kinh doanh chênh lệch giá nguyên tử xuyên chuỗi và cũng có thể hữu ích cho các ứng dụng khác như hoán đổi chuỗi chéo và giao dịch NFT (có thể kết hợp với các giao thức nhắn tin khác)

Việc cung cấp thêm các đảm bảo về kinh tế tiền điện tử (ví dụ: gửi tài sản thế chấp) để đảm bảo một số loại giao dịch xuyên chuỗi có thể hữu ích

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

Để biết các chủ đề thú vị khác về tính nguyên tử chuỗi chéo, tôi khuyên bạn nên xem qua:

Siêu chuỗi của Optimism  - Họ cũng đang khám phá cách sử dụng các trình sắp xếp phổ biến trên các chuỗi OP. Trình sắp xếp chuỗi được chia sẻ có thể đạt được sự đồng thuận và sau đó cố gắng đạt được các giao dịch chuỗi chéo nguyên tử.

Anoma - Paxos không đồng nhất và Typhon là những cách tiếp cận rất khác nhau.

Như đã đề cập trước đó, tính năng cuộn chéo của Kalman thực thi việc đóng gói các giao dịch.

Tóm tắt trình tự chia sẻ

Tóm lại, ý tưởng cơ bản của trình sắp xếp được chia sẻ là:

Rõ ràng sơ đồ tọa độ này không phải là một quy luật, mọi thứ đều mang tính chủ quan cao và nó phụ thuộc rất nhiều vào cấu trúc chính xác. Nhưng nói chung, việc so sánh có thể được thực hiện như sau:

Trình sắp xếp tập trung —— Thông thường dễ dàng nhất để triển khai bất kỳ chức năng nào bạn muốn nếu bạn có toàn quyền kiểm soát hệ thống. Tuy nhiên, có những đảm bảo dưới mức tối ưu về cường độ xác nhận trước, việc thoát ra bắt buộc có thể không được mong muốn, tính sống động cũng có thể dưới mức tối ưu, v.v.

Trình sắp xếp chuỗi L2 phi tập trung —so với một trình sắp xếp chuỗi duy nhất Thay vào đó, một tập hợp phân tán có giá trị có ý nghĩa được đặt cược nên tăng tính mạnh mẽ của rollup. Tuy nhiên, tùy thuộc vào cách triển khai, điều này có thể phải trả giá bằng độ trễ (ví dụ: nhiều nút L2 có thể cần bỏ phiếu trước khi xác nhận khối tổng hợp).

L1 chịu trách nhiệm sắp xếp - phân quyền tối đa, chống kiểm duyệt, hoạt động chờ đợi, v.v. Tuy nhiên, nó thiếu một số tính năng (ví dụ: xác nhận trước nhanh, giới hạn thông lượng dữ liệu).

Trình sắp xếp được chia sẻ  - nơi bạn có thể nhận được chức năng của trình sắp xếp thứ tự phi tập trung; Hưởng lợi từ việc chia sẻ trình sắp xếp thứ tự với những người khác (đạt được một số mức độ nguyên tử); không cần phải bắt đầu tập hợp con của trình sắp xếp chuỗi của riêng bạn, v.v. Tuy nhiên, khoảng thời gian tạm thời trước khi hoàn tất L1 có mức độ đảm bảo yếu hơn so với đặt hàng L1. Ngoài ra, lớp đặt hàng được chia sẻ có thể tổng hợp các ủy ban, an ninh kinh tế, v.v. từ nhiều bản tổng hợp vào một nơi (có khả năng mạnh hơn nếu mỗi bản tổng hợp có ủy ban riêng).

Cuối cùng, sau khi khối được hoàn tất ở L1, tất cả các bản tổng hợp sẽ trở lại mức bảo mật 100% L1 tình dục. Hầu hết các thiết kế trình sắp xếp thứ tự chỉ cố gắng cung cấp cho người dùng chức năng rất tốt trong khoảng thời gian tạm thời trước khi đạt được mức độ bảo mật hoàn toàn cho việc giải quyết L1, nhưng với sự đảm bảo yếu về trạng thái. Tất cả họ đều có sự đánh đổi khác nhau.

SUAVE (Đấu giá thống nhất duy nhất để thể hiện giá trị)

Trình tạo phi tập trung so với trình sắp xếp được chia sẻ

Khi chúng ta thảo luận về những điều này Sự khác biệt ở đây có thể nhận được rất khó hiểu khi cố gắng có một lớp chia sẻ xử lý các giao dịch cho nhiều chuỗi khác. Đặc biệt, SUAVE với tư cách là thành phần "lớp tuần tự" thường xuất hiện cùng với các thuật ngữ khác, chẳng hạn như một thành phần khác là "trình tạo khối phi tập trung cho các bản tổng hợp". Nói rõ hơn - SUAVE rất khác với thiết kế trình sắp xếp chung được mô tả ở trên.

Hãy xem SUAVE hoạt động như thế nào với Ethereum lắp ghép. SUAVE không được ghi 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 giao dịch của họ đến nhóm giao dịch được mã hóa. Sau đó, mạng thực thi SUAVE có thể tạo một khối (hoặc một phần khối) cho Ethereum (hoặc bất kỳ chuỗi nào khác tương tự). Các khối này sẽ cạnh tranh với các khối từ các nhà xây dựng tập trung Ethereum truyền thống. Những người đề xuất khối Ethereum có thể lắng nghe cả hai loại khối và chọn loại khối mà họ muốn đề xuất.

Tương tự, SUAVE không thay thế cơ chế tổng hợp để chọn các khối của nó. Ví dụ: rollup có thể triển khai một tập hợp con của sự đồng thuận PoS, có thể hoạt động theo cách tương tự như Ethereum L1. Sau đó, các trình sắp xếp/trình xác thực này có thể chọn các khối được SUAVE tạo cho chúng.

Điều này rất khác với trình tự chia sẻ được mô tả ở trên. **Trong các thiết kế trình sắp xếp được chia sẻ, việc tổng hợp có thể loại bỏ hoàn toàn nhu cầu về trình sắp xếp chuỗi phi tập trung. Họ chỉ cần thuê ngoài chức năng sắp xếp này bằng cách thêm các tùy chọn như Metro hoặc ESQ và tùy ý kế thừa các quy tắc lựa chọn nhánh của các lớp sắp xếp được chia sẻ này. **Ethereum, Arbitrum, Optimism, v.v. sẽ không thay đổi quy tắc lựa chọn nhánh của họ để chọn SUAVE cho tất cả các đơn đặt hàng giao dịch.

SUAVE không quan tâm đến quy tắc lựa chọn ngã ba trong chuỗi của bạn là gì, cũng như không quan tâm đến việc thực hiện như thế nào được chọn. Nó được thiết kế để cung cấp thứ hạng có lợi nhất cho bất kỳ tên miền nào. Lưu ý rằng không giống như các nút trình tự chia sẻ được mô tả trước đây, trình thực thi SUAVE thường "có trạng thái đầy đủ" (mặc dù chúng cũng có thể đáp ứng một số 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 thứ tự tối ưu.

Để hiểu sự khác biệt giữa hai điều này, đây là người dùng muốn thực hiện chuỗi chéo ví dụ về chênh lệch giá nguyên tử. Họ gửi giao dịch tới SUAVE so với trình sắp xếp được chia sẻ, với các đảm bảo sau:

SUAVE + Bộ tuần tự được chia sẻ

Vậy bây giờ chúng ta thảo luận về cách SUAVE tương tác với các trình sắp xếp tổng hợp phi tập trung hoặc thậm chí các trình sắp xếp được chia sẻ? Espresso dường như tin rằng SUAVE tương thích với ESQ, như họ mô tả trong bài viết của mình. ESQ được thiết kế để tương thích với các dịch vụ nhóm giao dịch riêng tư như SUAVE, có thể đóng vai trò là người xây dựng khối. Nó trông tương tự như PBS mà chúng tôi sử dụng trên Ethereum:

Người đề xuất được chia sẻ  = Trình sắp xếp được chia sẻ

p>

Shared Builder = SUAVE

Giống như PBS, người xây dựng có thể có được một cam kết từ người đề xuất (người sắp xếp trong trường hợp này) để đề xuất một khối nhất định. Người đề xuất chỉ biết tổng tiện ích thu được từ khối được đề xuất (giá thầu của người xây dựng), chứ không biết nội dung giao dịch của khối.

Bây giờ hãy ghép chúng lại với nhau, chúng ta hãy nhìn lại hoạt động kinh doanh chênh lệch giá xuyên chuỗi mà chúng ta muốn thực hiện do Ví dụ về người tìm kiếm. Bản thân SUAVE có thể được xây dựng và gửi đến hai bản tổng hợp khác nhau:

Chứa Khối giao dịch 1 (T1) 1 (B1) của - Mua ETH ở mức thấp trong Rollup 1 (R1)

Khối 2 (B2) của Giao dịch 2 (T2) - —Bán ETH ở mức cao giá trong Rollup 2 (R2)

Nhưng rất có thể B1 thắng cuộc đấu giá và B2 thua (hoặc ngược lại). Sau đó, hãy nghĩ xem điều gì sẽ xảy ra nếu hai tập hợp này được chọn vào cùng một trình tự sắp xếp chung.

Chia sẻ các nút trình tự sắp xếp về cơ bản là ngu ngốc.

Họ không hiểu giao dịch thực sự đang diễn ra như thế nào, vì vậy họ cần ai đó (như SUAVE hoặc một nhà xây dựng MEV khác) để xây dựng một hoàn thành một khối cho họ nếu họ muốn nâng cao hiệu quả. Sau đó, người thực thi SUAVE có thể gửi B1 và B2 tới trình sắp xếp chuỗi được chia sẻ, miễn là cả hai khối có thể được lấp đầy hoặc hủy bỏ (tức là thực thi hoặc loại bỏ cả hai khối một cách nguyên tử).

Bây giờ bạn có thể nhận được sự đảm bảo tài chính tuyệt vời trong toàn bộ quá trình:

SUAVE = người xây dựng được chia sẻ = có thể đảm bảo rằng cả B1 và B2 đều được bao gồm và thực hiện kết quả trạng thái nguyên tử.

Trình sắp xếp được chia sẻ = Người đề xuất được chia sẻ = Đảm bảo rằng cả B1 và B2 đều được đưa vào và thực thi nguyên tử.

Bản tổng hợp được đặt lại

Gần đây tôi đã đăng một bài viết trên diễn đàn Flashbots về mô hình an ninh kinh tế tiềm năng của SUAVE. Tôi đã lập luận tại sao việc triển khai có thể là một lựa chọn tốt hơn cho SUAVE về lâu dài so với việc đặt lại.

Hasu cũng nhắm mục tiêu tái đặt cược Có một số phản hồi rất chu đáo về sự đánh đổi với tổng số tiền mà tôi khuyến khích mọi người đọc. Dưới đây là bản tóm tắt phản hồi của anh ấy:

Bản tổng hợp được bảo mật/chống kiểm duyệt/ bởi L1 Liveness đảm bảo , nhưng SUAVE không được hưởng lợi từ nó giống như hầu hết các chuỗi vì chuỗi SUAVE không được thiết kế cho người dùng thông thường. Trên thực tế, Flashbots đang nghiên cứu cách chủ động hạn chế nhu cầu kết nối nội dung với SUAVE với tư cách là người dùng. Lý tưởng nhất là một chuỗi chủ yếu yêu cầu người tìm kiếm/người xây dựng duy trì đủ vốn hoạt động ở đó. Con số này có thể thấp hơn nhiều so với số lượng tài sản bị khóa trong một bản tổng hợp truyền thống dành cho người dùng. Ngoài ra, việc buộc chuyển đổi trạng thái thông qua L1 có thể không có giá trị đối với người tìm kiếm/người xây dựng trong chuỗi này so với chuỗi nhắm đến người dùng thông thường.

Tính sẵn có của dữ liệu (DA) rất đắt, ít nhất là ở thời điểm hiện tại. Chúng ta sẽ xem EIP-4844 đóng vai trò như thế nào trong vấn đề này và sau đó nhu cầu về DA có thể tăng lên. Ngược lại, tôi muốn nhắc rằng việc đặt cược lại có thể “đắt” hơn đối với chủ sở hữu mã thông báo (tức là nếu thu nhập từ phí thấp và cần phải cấp thêm mã thông báo cho những người đặt cược lại ETH để khuyến khích hình thành một nền kinh tế đủ an toàn người mẫu ). Một loại đắt hơn đối với người dùng và loại kia đắt hơn đối với người nắm giữ mã thông báo. Việc lựa chọn cái nào phụ thuộc phần lớn vào thời gian của bất kỳ chuỗi tiềm năng nào và mức độ trưởng thành của lớp DA của Ethereum tại thời điểm đó.

SUAVE cần báo cáo quá trình chuyển đổi trạng thái từ các miền khác trở lại chuỗi chính (để có thể mở khóa thực hiện thanh toán có điều kiện của thiết bị). Về khả năng đọc trạng thái từ Ethereum L1 và các bản tổng hợp khác, các bản tổng hợp có đặc tính giảm thiểu độ tin cậy rất lớn.

Nhưng tôi có một ý tưởng mới - thực hiện cả hai thì sao? Đặt cược lại.

Điều này không giải quyết được tất cả các vấn đề mà Hasu đã đề cập, nhưng nó vẫn rất thú vị những lựa chọn mới, đặc biệt là về lâu dài.

So với chỉ người cầm cố lại của EigenLayer (giống như chính nó vay trong L1 để cung cấp đảm bảo an ninh, tổng hợp có thể tận dụng các bên liên quan lại EigenLayer này để duy trì sự đồng thuận cục bộ, nhưng chuỗi sau đó sẽ quay trở lại Ethereum (tức là nó xuất bản dữ liệu và bằng chứng của mình lên Ethereum).

Như đã đề cập trước đó, tổng hợp có thể quyết định triển khai sự đồng thuận cục bộ của chính mình để có thể sử dụng nó trong L1 thực tế Trước khi quyết toán, hãy thực hiện các đảm bảo mạnh mẽ hơn về xác nhận trước ngắn hạn và khả năng chống tái cơ cấu. Vì vậy, tại sao chúng ta không biến tập hợp con đồng thuận tổng hợp này thành một nhóm gồm các bên liên quan lại Ethereum? Bây giờ bạn có cả hai:

Tính cuối cùng trước L1 – giá trị cao, phi tập trung Sự đồng thuận tái cam kết cung cấp sức đề kháng mạnh mẽ cho việc tái tổ chức trong ngắn hạn.

Vòng chung kết sau L1 – vẫn là một bản tổng hợp! Nó xuất bản dữ liệu của mình lên Ethereum và có thể xuất bản bằng chứng ZK/lừa đảo.

Sau khi L1 được hoàn tất, đây là mức bảo mật giống như bất kỳ bản tổng hợp nào. Đây chỉ là một biến thể của bản tổng hợp thực hiện sự đồng thuận của chính nó. Chỉ có điều, thay vì có tập hợp con các trình xác thực riêng trong danh sách như đã mô tả trước đây, được bảo mật bằng mã thông báo gốc của chính nó, thay vào đó, nó đã chọn để các bên liên quan lại của Ethereum thực hiện sự đồng thuận.

Tương tự như vậy, nếu Celestia có thể triển khai một số hình thức đặt cược lại trong giao thức của mình, thì đó sẽ là Một điều thú vị (kế hoạch hiện tại là L1 của Celestia rất nhỏ và không có chức năng hợp đồng thông minh). Trước đây tôi đã viết rằng các bản tổng hợp được ghi vào giao thức sẽ là một hướng đi thú vị cho Celestia và việc đặt cược lại gốc sẽ là một công cụ hấp dẫn khác để cho phép thị trường tự do quyết định những tính năng nào họ muốn đưa vào. Việc đặt cược lại cũng giúp ích cho khía cạnh an ninh kinh tế của Celestia, vì mô hình tích lũy giá trị cho lớp DA có thể thay thế vẫn chưa được chứng minh.

Các cân nhắc khác về MEV

Cách đơn giản nhất ở đây (việc tổng hợp thường được thực hiện hiện nay) là chạy một trình sắp xếp chuỗi duy nhất với các quy tắc FCFS đơn giản (đến trước được phục vụ trước). Trình sắp xếp thứ tự chỉ cần gửi các giao dịch theo thứ tự chúng được nhận. Bạn có thể tin tưởng một cách hợp lý vào một trình sắp xếp chuỗi duy nhất tuân theo các quy tắc đặt hàng của FCFS, nhưng nó vẫn sẽ khuyến khích các cuộc chạy đua về độ trễ và các tác động tiêu cực bên ngoài liên quan đến các vấn đề khác (không triển khai PoW để cố gắng giải quyết nó). Do đó, ngay cả các trình sắp xếp tập trung cũng cần phải đối phó với MEV hiệu quả hơn.

Một số giải pháp nêu trên Điều này vấn đề đã được giải quyết ngầm (ví dụ: tổ chức một cuộc đấu giá công khai hoàn toàn miễn phí), nhưng dường như không có công ty nào muốn người dùng của họ bị kẹp. Vì vậy, chúng ta có thể cần một chút sáng tạo. Việc kết hợp lợi ích của đấu giá với quyền riêng tư có thể lập trình khiến nó càng trở nên thú vị hơn.

Đây là lý do tại sao các nhà sắp xếp chuỗi tập trung hiện nay cũng thích sử dụng nhóm giao dịch riêng tư - để cố gắng đảm bảo Người dùng không thực hiện các giao dịch chạy trước, v.v. Nhưng đạt được sự phân quyền không hề dễ dàng. Nếu mở cho nhiều trình sắp xếp thứ tự, bạn có tin tưởng họ chạy nhóm giao dịch riêng của họ không? Ngay cả khi bạn tin rằng điều đó có thể có vấn đề nếu mỗi trình sắp xếp chuỗi có nhóm giao dịch riêng và bạn cần bắt đầu luân phiên các nhà lãnh đạo trình tự đang hoạt động.

Các nhóm giao dịch tiền điện tử là một lĩnh vực nghiên cứu hấp dẫn nhằm giải quyết những vấn đề này. Bây giờ tôi chỉ giới thiệu cho bạn những thông tin liên quan của bài đăng tôi vừa đăng:

https:/ /twitter.com/jon_charb/status/1635837710605639683?s=20

Trong bài đăng này, tôi sẽ chỉ cung cấp thông tin tổng quan ngắn gọn về một số biến thể của đề xuất FCFS.

Trong bài viết này, tôi sẽ phác thảo ngắn gọn một số biến thể của đề xuất FCFS.

Tăng thời gian

Nhận thức được những hạn chế và ngoại tác tiêu cực của FCFS đơn giản, Arbitrum bắt đầu khám phá các biến thể mới của nó. Gần đây, họ đã đề xuất cơ chế Time Boost. Nguyên tắc cơ bản:

Trình sắp xếp tập trung cần được tin cậy sẽ tiếp tục vận hành Nhóm giao dịch riêng

Trình sắp xếp thứ tự đánh dấu thời gian của mỗi giao dịch khi nó được nhận

Theo mặc định, các giao dịch sẽ được thực hiện trong vòng 500 mili giây kể từ khi nhận

Người dùng có thể chọn thanh toán thêm phí đóng gói ưu tiên cho các giao dịch của mình, việc "tăng thời gian" cho Giao dịch này có thể giảm tới 500 mili giây

Tăng thời gian Công thức tính như sau:

Ở đâu:

F = Phí đóng gói ưu tiên của giao dịch

g = Có sẵn Tăng tốc thời gian tối đa (500 mili giây)

c = hằng số được xác định

Hiện tại, người tìm kiếm có thể chỉ bày tỏ sở thích của họ đối với việc đóng gói nhanh cho trình sắp xếp chuỗi bằng cách giảm thiểu độ trễ đối với trình sắp xếp chuỗi Arbitrum (mở nhiều kết nối, khoảng cách vật lý với nó, đầu tư vốn vào cơ sở hạ tầng, v.v.). Thay vào đó, Time Boost làm giảm động lực đầu tư vào các lợi ích về độ trễ được đề cập ở trên, vì giờ đây người tìm kiếm có thể bày tỏ sở thích của họ đối với việc đóng gói nhanh thông qua việc đặt giá thầu phí đóng gói ưu tiên.

Đây là một cải tiến rõ ràng so với FCFS đơn giản, nhưng theo tôi vẫn còn một số thiếu sót:

Điều này làm giảm động cơ gây ra sự tranh chấp chậm trễ, nhưng không loại bỏ được nó. Việc giảm thiểu độ trễ luôn cho phép người tìm kiếm trả giá thấp hơn đối thủ cạnh tranh và đường cong của biểu đồ trên cho thấy lợi thế về độ trễ đặc biệt có ý nghĩa đối với các cơ hội MEV có giá trị cao.

Không rõ làm thế nào quyền riêng tư và dấu thời gian của nhóm giao dịch có thể được phân cấp một cách hiệu quả.

Giá thầu của người tìm kiếm thiếu hiệu quả khác. Người tìm kiếm chỉ có thể đặt giá thầu để đóng gói nhanh hơn, nhưng họ không thể thể hiện các sở thích phức tạp hơn, điều này sẽ xảy ra với các phiên đấu giá rõ ràng linh hoạt hơn (chẳng hạn như Ethereum L1 hiện tại).

Có liên quan, nếu được thực hiện ở cấp độ này, sẽ không có khả năng thu hồi các giá thầu không thành công.

FBA-FCFS

Năm ngoái, Xin từ Flashbots đã đề xuất một giải pháp thay thế cho Arbitrum (FBA-FCFS). Điều này triển khai một biến thể của kiểu đấu giá hàng loạt thường xuyên cho Themis. Trong sơ đồ này:

Các nút báo cáo một phần mệnh lệnh cho người lãnh đạo, người sau đó tổng hợp chúng thành một lệnh chưa được sắp xếp. lô hàng. Trong một khoảng thời gian lô đã đặt "mức độ chi tiết vừa phải" (ví dụ: có thể là 500 mili giây), tất cả các giao dịch được giả định xảy ra cùng một lúc.

Người lãnh đạo sau đó giải quyết vấn đề đặt hàng yếu trong lô thông qua một số hình thức đấu giá.

Tương tự như đề xuất Tăng thời gian, có một số nỗ lực nhằm đảm bảo thời gian đóng gói tương đối nhanh (được khuyến nghị nhỏ hơn 500 ms, nhưng có thể thay đổi) và ngăn chặn việc chạy trước thông qua các nút đáng tin cậy. Tương tự như vậy, nó làm giảm động cơ trì hoãn cạnh tranh (mặc dù không loại bỏ hoàn toàn mọi lợi thế) bằng cách cho phép người tìm kiếm thể hiện sở thích của họ (cơ chế phí đóng gói ưu tiên).

Đối với "người tìm kiếm nhanh", ở cuối một đợt nhất định, người còn lại "chậm người tìm kiếm" Lợi thế về độ trễ mà "người tìm kiếm nhanh" không thể cạnh tranh vẫn tồn tại:

Nguồn: Mối lo ngại về cuộc chạy đua vũ trang có độ trễ trong thị trường không gian khối

Đây là một khía cạnh nổi tiếng của loại hình đấu giá này. Thời gian xử lý hàng loạt dài hơn càng làm giảm tỷ lệ phần trăm thời gian mà lợi ích độ trễ này có liên quan, mặc dù giá trị của lô có thể cao hơn. Thời gian chặn dài hơn có thể có những tác động khác đến MEV (ví dụ: giá biến động).

Tóm tắt lợi thế về sự chậm trễ này:

Tăng thời gian - Độ trễ thấp hơn luôn có lợi (độ trễ thấp hơn = giá thầu trung bình luôn thấp hơn).

FBA-FCFS - độ trễ thấp hơn đôi khi có lợi (khi khoảng cách nhỏ giữa người tìm kiếm "chậm" và "nhanh" cho thấy thông tin tương quan).

Về độ trễ thời gian:

Tăng thời gian - Tất cả các giao dịch của người dùng được nhận với độ trễ mặc định là 500 mili giây.

FBA-FCFS - Thời gian xử lý hàng loạt là 500 mili giây, do đó, có thể bao gồm các giao dịch của người dùng nhận được trong khoảng thời gian đó, trung bình <500 tính từ mili giây ở giữa

FBA-FCFS có nhiều biến đổi hơn (ví dụ: các giao dịch có thể thay đổi dựa trên thời gian nhận hàng chuyển sang đợt tiếp theo), nhưng thời gian đóng gói trung bình của các giao dịch người dùng thông thường không trả phí đóng gói ưu tiên sẽ thấp hơn. Trong mô hình Time Boost, thời gian là liên tục (không có khái niệm về khối), trong khi ở mô hình FBA-FCFS, thời gian là rời rạc. Nhìn chung:

Trì hoãn và phân cấp

Điều này Bài viết đã rất dài và tôi rất mệt mỏi, vì vậy hãy đọc bài viết của Phil cho phần này. Cảm ơn:(

Kết luận

Tôi hy vọng độc giả bây giờ đã có một khuôn khổ rõ ràng hơn về con đường phân cấp trình tự sắp xếp và những trở ngại liên quan. Đây là một trong nhiều vấn đề tổng hợp những thách thức sẽ cần phải giải quyết khi nó phát triển trong những năm tới.

Một số lĩnh vực khác Các lĩnh vực thú vị cần quan tâm khám phá bao gồm:

Tương tác của các lớp khác nhau - chúng khác với chuỗi cung ứng giao dịch như thế nào khi các trình sắp xếp chuỗi trở nên phi tập trung Tương tác một phần? Loại đấu giá nào (ví dụ: SUAVE) nên được đưa vào một tập hợp con phi tập trung của trình sắp xếp chuỗi (ví dụ: trình sắp xếp được chia sẻ)?

Cơ chế phí giao dịch - định giá tài nguyên đa chiều và xác định trạng thái

Thị trường phí L2 - thu phí "bản địa L2" (chẳng hạn như phí tắc nghẽn L2) và phí "bản địa L1" (chẳng hạn như phí tắc nghẽn L2) dưới dạng Phí sẵn có dữ liệu L1)

Thị trường ZK Prover - Cách khuyến khích hợp lý việc phân cấp và không cần cấp phép Thị trường chứng minh ZK. Đây là một tập hợp con quan trọng của phí L2 và sẽ có liên quan trong các bối cảnh khác.

Mô hình kinh doanh của Rollup – cách các mã thông báo Rollup và các nhóm xây dựng chúng tích lũy giá trị và nhận ra Tính bền vững.

Khả năng nâng cấp và quản trị - phân cấp các thành phần này và giảm các giả định về niềm tin trong khi vẫn duy trì tính linh hoạt của Hệ thống.

Bằng chứng gian lận/ZK - Xây dựng cơ chế mạnh mẽ hơn, chẳng hạn như sử dụng nhiều cơ chế chứng minh.

Liên kết gốc

Chào mừng bạn tham gia cộng đồng chính thức của BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm Telegram thảo luận: https://t.me/BlockBeats_App

Tài khoản Twitter chính thức: https://twitter.com/BlockBeatsAsia