Bài báo này phân tích các công nghệ chính của trình sắp xếp thứ tự dùng chung: khả năng chống kiểm duyệt cao, dễ triển khai, có thể tương tác, xác định nhanh và tức thời. Lý thuyết tổng hợp cung cấp một viễn cảnh mới cho nó, và tích hợp dọc hướng dẫn sự phát triển hơn nữa của nó.
Tiêu đề gốc: "The Shared Sequencer"
Được viết bởi: MAVEN11
Biên soạn: Kxp, BlockBeats
Hãy tưởng tượng điều gì sẽ xảy ra nếu Rollup "sắp xuất xưởng" có thể đạt được mức độ chống kiểm duyệt cao, dễ triển khai, khả năng tương tác, tính hoàn thiện nhanh, tính sống động và dân chủ hóa của MEV. Điều đó có vẻ giống như một mục tiêu lớn, nhưng với sự ra đời của Shared Sequencer, nó có thể sớm trở thành hiện thực. Tuy nhiên, không phải tất cả các Rollup đều giống nhau, vì vậy chúng tôi phải xem xét cách phân phối phần thưởng và MEV trên mạng trình sắp xếp thứ tự được chia sẻ. Trong bài báo này, chúng tôi khám phá cách các mạng xếp hạng được chia sẻ được triển khai và các thuộc tính có thể đạt được.
Shared Sequencer Networks được giới thiệu chủ yếu bởi Alex Beckett, sau đó là Evan Forbes (và Radius) từ nhóm Celestia và Espresso, và một bài báo mới của Jon Charbonneau trình bày sâu hơn về chủ đề này. Josh, Jordan và nhóm Astria của họ đang xây dựng mạng trình tự chia sẻ sẵn sàng sản xuất đầu tiên. Mạng đặt hàng được chia sẻ của Astria là một chuỗi khối mô-đun tổng hợp và đặt hàng các giao dịch của Rollup mà không cần thực hiện chúng.
Trong thiết lập của Astria, bộ sắp xếp sẽ gửi các khối được sắp xếp theo thứ tự đến lớp DA và cả các nút Tổng số. Các bản tổng hợp nhận được các đảm bảo về tính hữu hạn mềm từ người đặt hàng và các đảm bảo về tính hữu hạn cứng từ lớp DA (sau khi các khối được hoàn thiện), và sau đó chúng sẽ thực hiện các giao dịch hợp lệ.
Mạng trình sắp xếp thứ tự được chia sẻ về cơ bản là một nhóm các trình sắp xếp tương thích với Rollup, như tên gọi của nó, nó có thể cung cấp dịch vụ cho các Rollup khác nhau. Điều này có nhiều sự đánh đổi và tính chất khác nhau, chúng tôi sẽ trình bày chi tiết sau. Đầu tiên, chúng ta phải mô tả các thuộc tính quan trọng nhất của bộ sắp xếp (hoặc tập hợp các bộ sắp xếp). Trong Rollup, yêu cầu chính đối với trình sắp xếp thứ tự hoặc nhóm trình sắp xếp thứ tự là khả năng chống kiểm duyệt hoặc tính sống động (một số trong số đó đến từ lớp cơ sở, cũng như tính bảo mật). Điều này có nghĩa là một giao dịch hợp lệ được gửi cho người đặt hàng phải được đưa vào chuỗi trong một khoảng thời gian hữu hạn (tham số thời gian chờ). Nhóm người đặt hàng được chia sẻ chỉ cần đảm bảo rằng các giao dịch được bao gồm trong các khối (tức là crLists).
Đáp ứng đồng thời khả năng chống kiểm duyệt và tính tức thời là khá khó khăn, như chúng tôi đã nêu trong Modular MEV Phần II. Trong một thuật toán đồng thuận như Tendermint, bạn có thể đảm bảo phục hồi sau một cuộc tấn công. Tuy nhiên, trong trường hợp bị tấn công, bạn sẽ mất ngay lập tức. Về cơ bản, việc yêu cầu tất cả những người đối chiếu khác ký vào một khối, thay vì chọn một masternode tùy chỉnh, có lẽ không phải là điều tối ưu. Mặc dù điều này cải thiện khả năng chống kiểm duyệt, nhưng nó phải trả giá bằng việc "tập trung hóa" và khai thác MEV cho một masternode duy nhất. Một cơ chế sắp xếp khác có sẵn có thể được so sánh với Duality's Multiplicity, đây là công cụ nhỏ của họ dành cho các mã không chính (hoặc bộ sắp xếp) để đưa các giao dịch khác vào các khối. Nhìn chung, khó đạt được khả năng chống kiểm duyệt và tính tức thời sau một cuộc tấn công trong hầu hết các giao thức đồng thuận.
Một thuật toán đồng thuận khác có thể được sử dụng là HotStuff 2, đảm bảo tính tức thời trong trường hợp bị tấn công.
Những gì nó cho phép là tránh chờ đợi độ trễ mạng tối đa (hết thời gian chờ) trong trường hợp kiểm duyệt hoặc không được ký để bầu một masternode mới. Lý do nó có thể là một thuật toán đồng thuận thú vị cho một nhóm người đặt hàng phi tập trung là vì nó giải quyết vấn đề tức thì trong sự đồng thuận mà không cần thêm một giai đoạn bổ sung. Nếu masternode biết mức khóa cao nhất (số lượng người tham gia đồng ý cao nhất về một đầu ra cụ thể) và có thể thuyết phục các bên trung thực, thì vấn đề sẽ được giải quyết. Nếu không, một masternode trung thực sau một thời điểm nhất định có thể chịu trách nhiệm đẩy, hỗ trợ masternode tiếp theo. Ví dụ: nút Hotstuff không cần xác nhận thông báo chuyển đổi trước khi thông báo cho chủ mới, nhưng có thể trực tiếp chuyển sang chế độ xem mới và thông báo cho chủ mới.
Sự khác biệt với Tendermint là mặc dù cả hai đều là hai pha (Hotstuff1 có ba, Hotstuff2 có hai), Tendermint có giao tiếp tuyến tính nhưng không phản hồi, trong khi Hotstuff2 có phản ứng. Nếu có một chuỗi các masternode trung thực, thì giao thức sẽ phản hồi tích cực, vì tất cả các bước ngoại trừ đề xuất của masternode đầu tiên đều phụ thuộc vào việc thu được lượng thông tin từ bước trước đó. Trong cài đặt trình đặt hàng được chia sẻ, điều này cho phép giao thức đạt được tính tức thời tốt hơn mà không cần quay trở lại lớp dưới cùng, đồng thời không loại bỏ khả năng này.
Xây dựng nhóm phân loại dùng chung
Một nhóm người đặt hàng được phép gửi giao dịch đến lớp thanh toán (lớp chứa Rollup). Bạn có thể tham gia nhóm đối chiếu này, miễn là đáp ứng một số yêu cầu nhất định và chưa đạt đến số lượng nhà sản xuất khối yêu cầu. Điều này tối ưu hóa độ trễ, thông lượng, v.v. Các yêu cầu này tương tự như yêu cầu để trở thành người xác thực chuỗi khối. Ví dụ: bạn phải đáp ứng các yêu cầu nhất định về phần cứng, cũng như khoản tiền gửi ban đầu, đặc biệt nếu bạn muốn cung cấp sự chắc chắn về điều kiện tài chính.
Nhóm người đặt hàng được chia sẻ (hoặc bất kỳ nhóm người đặt hàng phi tập trung nào) bao gồm một số thành phần hoạt động cùng nhau để đảm bảo xử lý giao dịch chính xác, bao gồm:
Cung cấp JSON-RPC cho mỗi Tổng số để gửi giao dịch (dành cho người vận hành nút không đầy đủ) tới nút dưới dạng nhóm bộ nhớ, sau đó xây dựng và sắp xếp. Trong mempool, cần có một số cơ chế để xác định hàng đợi, cũng như quy trình lựa chọn giao dịch, để đảm bảo việc xây dựng các khối hiệu quả.
Thuật toán xây dựng khối/lô, chịu trách nhiệm xử lý các giao dịch trong hàng đợi và chuyển đổi chúng thành khối hoặc lô. Bước này cũng có thể bao gồm nén để giảm kích thước khối kết quả (được gọi là nén dữ liệu). Như đã đề cập, điều này nên tách biệt với Người đề xuất, về cơ bản là PBS. Dữ liệu có thể được nén theo nhiều cách khác nhau, ví dụ:
Không có mã hóa RLP - tuy nhiên, điều này có thể yêu cầu một bộ đối chiếu phi tập trung để giúp bình thường hóa việc truyền dữ liệu giữa các nút, do đó tiết kiệm không gian.
Bỏ qua nonce (dữ liệu xác thực số duy nhất trong một khối cụ thể) - nó có thể được tính toán lại tại thời điểm thực thi bằng cách xem xét trạng thái trước đó của chuỗi.
Đơn giản hóa giá gas - đặt gas dựa trên một phạm vi giá cố định.
Đơn giản hóa gas - Ngoài giá gas còn có hệ thống đánh số gas.
Thay thế địa chỉ bằng chỉ mục - Tổng số có thể lưu trữ chỉ mục của địa chỉ được ánh xạ thay vì lưu trữ địa chỉ đầy đủ.
Các giá trị được biểu thị bằng ký hiệu khoa học - các trường giá trị trong các giao dịch Ethereum có mệnh giá bằng wei, vì vậy các giá trị lớn. Bạn không thể bỏ qua các trường số hoặc giảm chúng thành một bộ giá trị cố định. Tuy nhiên, bạn có thể viết nó dưới dạng ký hiệu khoa học để tối ưu hóa việc lưu trữ dữ liệu:
Bỏ qua các trường dữ liệu: Các trường dữ liệu không bắt buộc đối với các giao dịch đơn giản nhưng lại cần thiết đối với các giao dịch phức tạp hơn.
Thay thế chữ ký riêng lẻ bằng chữ ký tổng hợp BLS: Chữ ký là thành phần lớn nhất của giao dịch Ethereum. Thay vì lưu trữ từng chữ ký, bạn có thể lưu trữ chữ ký tổng hợp BLS cho một số lượng giao dịch cụ thể. Bạn cũng có thể kiểm tra chữ ký tổng hợp BLS đối với bộ thông báo và bộ người gửi để đảm bảo tính hợp lệ của nó.
Sử dụng trường Từ làm chỉ mục: Giống như trường Đến, bạn có thể sử dụng trường Từ làm chỉ mục để ánh xạ.
Một khái niệm thú vị về thiết kế "mô-đun" là bạn có thể thực hiện các điều chỉnh và đánh đổi nếu cần để làm cho nó hoạt động cho Tổng số của bạn.
Lớp ngang hàng sẽ cho phép người đặt hàng nhận giao dịch từ những người đặt hàng khác và truyền các khối sau khi xây dựng. Bước này rất quan trọng để đảm bảo rằng trình sắp xếp thứ tự được chia sẻ hoạt động hiệu quả trên nhiều lần tổng hợp.
Thuật toán xoay tổng thể cho các bộ đặt hàng được chia sẻ (không cần sự đồng thuận trong trường hợp bầu chọn tổng thể duy nhất). Bạn có thể chọn chỉ đặt thuật toán xoay vòng nút chính hoặc thực hiện lộ trình tạo khối đa đồng thời do Duality đề xuất.
Các thuật toán đồng thuận, chẳng hạn như Tendermint hoặc Hotstuff2 đã nói ở trên, có thể đảm bảo rằng các nút Tổng số đồng ý với trình tự do sổ cái đề xuất.
Ứng dụng khách RPC để gửi các khối/đợt lên lớp đồng thuận DA+ cơ bản để các khối/đợt có thể được thêm vào lớp DA một cách an toàn, đảm bảo tính hữu hạn "cuối cùng" và làm cho tất cả dữ liệu giao dịch có sẵn trên chuỗi.
Tách biệt vai trò của người xây dựng và nhà sản xuất khối để đảm bảo tính công bằng và nhất quán, đồng thời tránh hành vi trộm cắp MEV. Cũng loại bỏ sắp xếp được thực hiện, điều quan trọng để tối ưu hóa hiệu quả, giảm PGA và tăng CR.
*Các nút tổng số nhận các khối được sắp xếp theo thứ tự từ bộ sắp xếp để gửi mềm và nhận các khối lớp DA đã đặt hàng để gửi cứng. *
Calldata lần đầu tiên được xuất bản lên mạng cơ sở, nơi chạy sự đồng thuận để đảm bảo người dùng và các giao dịch Rollup. Sau đó, nút Tổng số thực thi giao dịch và gửi chức năng chuyển đổi trạng thái sang chuỗi Tổng số chính tắc. Một mạng lưới những người đặt hàng được chia sẻ cung cấp cho Rollup tính năng tức thời và khả năng chống kiểm duyệt. Các bản tổng hợp duy trì chủ quyền của chúng vì tất cả dữ liệu giao dịch được lưu trữ trong lớp cơ sở, cho phép chúng rẽ nhánh từ trình đặt hàng được chia sẻ bất cứ lúc nào. Gốc trạng thái của hàm chuyển đổi trạng thái Tổng số (STF) được tính toán từ gốc giao dịch (đầu vào) được gửi từ trình đặt hàng dùng chung đến lớp DA. Trong Celestia, gốc trạng thái được tạo khi dữ liệu được thêm vào chuỗi và đạt được sự đồng thuận. Vì bạn đã có gốc giao dịch (và tất cả dữ liệu có sẵn), Celestia có thể cung cấp cho các ứng dụng khách nhẹ (các nút Rollup chạy trên Celestia) với một bằng chứng nhỏ về việc đưa vào.
Để cung cấp trải nghiệm người dùng mà người dùng mong đợi, các nút Tổng số nhận các khối được sắp xếp theo thứ tự (các khối này cũng được gửi đến lớp DA). Điều này có thể cung cấp cho Rollup các đảm bảo xác định mềm - đảm bảo rằng các khối cuối cùng sẽ được sắp xếp theo thứ tự trên lớp DA, tại đó các nút Rollup thực hiện các giao dịch và cung cấp các gốc trạng thái mới.
Tạo khối và vị trí
Để xác định thời điểm tạo khối, trình sắp xếp chuỗi cần đặt vị trí. Trình sắp xếp thứ tự phải gửi các lô theo các khoảng thời gian cố định (thường là X giây), trong đó X là thời gian của khe. Điều này đảm bảo rằng các giao dịch được xử lý kịp thời và hiệu quả, bởi vì nếu không thì masternode cho một vị trí cụ thể sẽ hết thời gian chờ và mất phần thưởng ký kết (và phần thưởng thực thi). Ví dụ: thời gian tạo khối của Celestia (theo thông số kỹ thuật của GitHub) là khoảng 15 giây. Vì điều này đã được biết, nên chúng tôi có thể đưa ra một số giả định về số lượng "khe/khối" mà chúng tôi có thể có từ tập hợp các bộ điều phối dùng chung cho lớp DA và các nút Tổng số được tải vào các khối đã hoàn thiện. Về vấn đề này, chúng ta có thể tham khảo Tendermint hoặc Hotstuff2 đã được tối ưu hóa.
Trong cùng một vị trí, chúng tôi có thể gửi nhiều lô giao dịch, miễn là thiết kế bao gồm các cơ chế cho các nút đầy đủ Rollup để xử lý chúng một cách hiệu quả thành một khối duy nhất (trong khoảng thời gian đó và các thông số hết thời gian chờ). Điều này giúp tối ưu hóa hơn nữa việc tạo khối và đảm bảo các giao dịch được xử lý nhanh chóng. Ngoài ra, các vị trí cũng có thể được sử dụng để tạo thuận lợi cho việc bầu chọn các nút chính của bộ sắp xếp. Ví dụ: bạn có thể chọn ngẫu nhiên một nút chính của vị trí từ nhóm đặt cược dựa trên trọng số đặt cược. Làm điều này theo cách bảo vệ tính bảo mật và sử dụng một số thứ như bầu chọn thủ lĩnh bí mật để giảm thiểu kiểm duyệt là lựa chọn tốt nhất; hoặc thậm chí là thiết lập công nghệ trình xác thực phân tán, chẳng hạn như các giải pháp như Obol/SSV. Độ trễ và thời gian khe có tác động lớn đến việc gửi khối và xây dựng giao thức. Vì vậy, chúng ta cần xem xét điều này ảnh hưởng đến hệ thống như thế nào. Bloxroute có một số điểm nghiên cứu và dữ liệu tuyệt vời về Ethereum nói riêng. Trong MEV-Boost, các nhà sản xuất khối tham gia (trình xác thực hoặc trình sắp xếp thứ tự trong trường hợp Rollup) yêu cầu GetHeader từ rơle. Điều này mang lại cho họ giá trị giá thầu khối, là giá trị của một khối cụ thể. Đây có thể là khối giá trị cao nhất nhận được mỗi lần. Đối với mỗi vùng, trình xác nhận thường yêu cầu GetHeader khoảng 400 mili giây sau khi vùng bắt đầu - do số lượng lớn trình xác nhận, rơle thường cần gửi nhiều yêu cầu. Đây cũng là điều có thể xảy ra với các nhóm máy phân loại dùng chung lớn. Điều này có nghĩa là bạn cần có cơ sở hạ tầng để tạo thuận lợi cho quá trình này.
Rơle cũng giúp tạo điều kiện thuận lợi cho việc tách người xây dựng và nhà sản xuất khối, đồng thời xác minh rằng những người xây dựng đã xây dựng đúng khối. Họ cũng kiểm tra xem các khoản phí có được thanh toán chính xác hay không và đóng vai trò bảo vệ DoS. Ngoài ra, về cơ bản, họ là người giám sát các khối và xử lý việc đăng ký trình xác nhận. Điều này đặc biệt quan trọng trong kiến trúc của trình sắp xếp thứ tự không giới hạn, vì bạn cần theo dõi xem ai đã tham gia và ai không (ví dụ: lớp đồng bộ hóa đã thảo luận trước đó).
Về thời gian chặn (tức là các khối do người tạo gửi), chúng thường xảy ra trong khoảng 200 mili giây. Hầu hết chúng bắt đầu chạy trước/sau khoảng 200 mili giây, mặc dù giống như GetHeader, có sự khác biệt đáng kể. Nếu trình xây dựng gửi khối tới nhiều rơle, nó sẽ gây ra độ trễ đáng kể. Bloxroute cũng xem xét điều gì sẽ xảy ra khi các khối được gửi đến nhiều rơle. Như bạn có thể mong đợi, độ trễ cho việc truyền khối đến nhiều rơle hơn sẽ lớn hơn. Trung bình, lần chuyển tiếp thứ hai mất 99 mili giây để sử dụng khối, lần thứ ba là 122 mili giây và lần thứ tư là 342 mili giây.
Những gì chúng ta có thể đã học được trong vài tháng qua là RPC rất quan trọng đối với chuỗi khối. Đó là một gánh nặng lớn nếu không có cơ sở hạ tầng phù hợp và có một tùy chọn RPC phù hợp cũng rất quan trọng. Trong trường hợp này, RPC rất quan trọng đối với các nhà đầu tư bán lẻ gửi giao dịch của họ tới RPC (và bộ nhớ chung công khai). Bloxroute đã chạy một thử nghiệm nhỏ gồm 20 giao dịch được gửi đến các RPC khác nhau và đo thời gian cần thiết để mỗi giao dịch được đưa vào một khối.
Nguồn: Phòng thí nghiệm Bloxroute
Thật thú vị, một số RPC không bao gồm các giao dịch cho đến một số khối sau đó, tùy thuộc vào người xây dựng nào giành chiến thắng trong khối tiếp theo. Nếu RPC gửi giao dịch đến nhiều nhà xây dựng hơn, thì xác suất đưa vào nhanh sẽ cao hơn. Mặc dù những người khởi tạo giao dịch có thể tận dụng vị trí duy nhất của họ theo thứ tự dòng chảy để nhắm mục tiêu những người xây dựng cụ thể hoặc thậm chí xây dựng các khối của riêng họ.
Hiệu suất của chúng cũng rất thú vị trong số liệu thống kê hiệu suất chuyển tiếp của Ethereum. Điều này giúp chúng tôi hiểu sâu hơn về cách thức hoạt động của PBS trong một thế giới nhiều trình xác thực/trình tạo/chuyển tiếp, đó là điều chúng tôi hy vọng đạt được với bản nâng cấp Tổng hợp. Metrika có một số thống kê tuyệt vời về điều này và tất cả các điểm dữ liệu là do chúng.
Điều quan trọng cần lưu ý là bỏ lỡ giá thầu xảy ra khi người chuyển tiếp dự kiến sẽ đặt giá thầu, nhưng không đặt giá thầu. Kỳ vọng mục tiêu đến từ trình xác thực đã đăng ký với một chuyển tiếp cụ thể cho bất kỳ vị trí nhất định nào. Bản thân đây không phải là lỗi chuyển tiếp, cũng như không được xử lý theo cách đó ở cấp độ giao thức.
Nguồn: app.metrika.co
Nếu xảy ra lỗi (chẳng hạn như rơle phục vụ khối không hợp lệ) và nó phải chịu trách nhiệm, thì lỗi đó sẽ được tính là lỗi. Những điều này thường không xảy ra thường xuyên và chủ yếu là do lỗi tùy chọn đăng ký (tức là giới hạn gas hoặc phí không khớp với đăng ký cho một trình xác thực cụ thể). Thậm chí hiếm hơn là các lỗi của lớp đồng thuận, không phù hợp với các quy tắc của lớp đồng thuận Ethereum, chẳng hạn như các vị trí không chính xác hoặc các hàm băm gốc không được căn chỉnh với khối trước đó, v.v.
Về độ trễ (chẳng hạn như thời gian cần thiết để trình xác thực nhận tiêu đề khối do trình tạo tạo), dữ liệu rất nhất quán. Mặc dù có một số ngoại lệ, chẳng hạn như chuyển tiếp được yêu cầu ở một vị trí địa lý khác với trình xác thực đã chọn.
Nguồn: app.metrika.co
Về các nhà xây dựng, tổng số nhà xây dựng trên MEV-boost là khoảng 84, với ba nhà xây dựng hàng đầu xây dựng khoảng 65% số khối đã xây dựng. Mặc dù điều này có thể hơi gây hiểu nhầm vì đây cũng là những trình xây dựng hoạt động lâu nhất. Kết quả cũng tương tự nếu giảm khung thời gian. Số lượng người xây dựng đang hoạt động thực tế thấp hơn nhiều, 35 người trong 30 ngày qua và 24 người trong tuần qua. Cạnh tranh rất khốc liệt và thường thì người xây dựng mạnh nhất sẽ thắng. Một luồng đơn đặt hàng độc quyền có thể đã tồn tại, điều này sẽ chỉ làm trầm trọng thêm tình hình. Chúng tôi hy vọng việc phân phối các nhà xây dựng sẽ vẫn tương đối tập trung (vì đây là cuộc đua giành luồng đơn đặt hàng tối ưu và tối ưu hóa phần cứng) trừ khi chúng tôi thực hiện những thay đổi lớn đối với thiết lập. Mặc dù không phải là một vấn đề cơ bản, nhưng nó vẫn là một lực lượng tập trung trong ngăn xếp và chúng tôi rất muốn nghe các ý tưởng về cách thách thức hiện trạng ở đây. Nếu bạn muốn tìm hiểu sâu hơn về vấn đề (nghiêm trọng) này, chúng tôi thực sự khuyên bạn nên đọc các bài viết của Quintus về luồng đặt hàng, đấu giá và tập trung hóa.
Đối với vai trò Trình tạo trong ngăn xếp mô-đun trong tương lai, chúng tôi khá chắc chắn (ít nhất là trong thiết lập SDK Cosmos), chúng ta sẽ thấy thiết lập Mô-đun Trình tạo giống Skip/Mekatek. Một giải pháp khác là thiết lập loại SUAVE, chẳng hạn như chuỗi trình tạo toàn cầu cụ thể cung cấp dịch vụ xây dựng khối và ưu tiên giá thầu cho bất kỳ số lượng chuỗi nào để đảm bảo PBS. Chúng ta sẽ khám phá giải pháp này sâu hơn sau và cung cấp một số câu trả lời cho các câu hỏi không được đề cập ở đây.
Về rơle, chúng tôi thực sự khuyên bạn nên đọc một bài viết của Ankit Chiplunkar của Frontier Research và Mike Neuder của Ethereum Foundation có tên là rơle lạc quan và tìm chúng ở đâu. Bài đăng này trình bày chi tiết cách thức hoạt động của rơle trong MEV-boost, sự đánh đổi hiện tại và chi phí vận hành của chúng cũng như một số thay đổi có thể làm tăng hiệu quả. Thật thú vị, chạy một rơle trong MEV-Boost hiện có giá khoảng 100.000 USD/năm theo ước tính của Flashbot.
Xác định
Trước khi chúng ta nói về tính quyết định của các chuỗi khối mô-đun (như hiện tại), chúng ta hãy xem bài viết “MEV mô-đun” trước đây của chúng tôi. Lưu ý rằng đây không phải là chế độ xem "chính thức" hay toàn diện về thời hạn cuối cùng, nhưng chúng tôi tin rằng nó thể hiện chính xác nhất các sắc thái của thời hạn cuối cùng của Tổng số để dễ hiểu.
Đang chờ xử lý_Bật_L2: Trình đặt hàng tổng số thể hiện một cam kết mềm rằng giao dịch của người dùng cuối cùng sẽ được thực hiện và hoàn tất trên lớp bảo mật cơ sở của nó.
Finality_On_L2: Trình sắp xếp thứ tự đã cam kết với chức năng chuyển đổi trạng thái của Rollup và khối đã được thêm vào chuỗi chính tắc của Rollup.
Đang chờ xử lý_Bật_L1: Chức năng chuyển đổi đầu vào hoặc đầu ra/trạng thái của giao dịch đã được xuất bản lên L1, nhưng bằng chứng hợp lệ vẫn chưa được đưa ra hoặc thời gian phân xử chưa kết thúc - điều này yêu cầu Ethereum trong hai kỷ nguyên liên tiếp. Đây là thời điểm mà hầu hết các Bản tổng hợp lạc quan nói rằng chúng đã đạt đến điểm cuối cùng, nhưng vẫn có khoảng thời gian thử thách 7 ngày tùy ý tại thời điểm này theo cầu chuỗi chéo thông số kỹ thuật.
Finality_On_L1: Đối với Bản tổng hợp lạc quan, thời gian phân xử trọng tài đã kết thúc hoặc bằng chứng về tính hợp lệ đã được công bố và xác minh đã được xác nhận bởi đa số trong hai kỷ nguyên liên tiếp.
Bây giờ, trong Tổng hợp sắp xếp được chia sẻ có chủ quyền, điều này có vẻ hơi khác, hãy thử giải thích nó bằng sơ đồ:
Trong trường hợp này, về mặt lý thuyết, chúng ta có thể nhận được tính xác định trên L1 trước L2, v.v.? Vâng, trong trường hợp này, L2 có chủ quyền sau tất cả. Điều này giả định rằng không có bằng chứng gian lận và thời gian thử thách hoặc bạn đang sử dụng bằng chứng hợp lệ.
Vì vậy, làm thế nào để chúng ta đạt được những mức độ cuối cùng? Khối cuối cùng đạt được khi một khối được thêm vào chuỗi chính tắc, khối này không thể rút được. Tuy nhiên, có một số sắc thái ở đây, tùy thuộc vào các nút đầy đủ hoặc nhẹ. Trong trường hợp khối có thứ tự, nó có tính quyết định khi nó được đưa vào khối lớp DA. Các khối (có gốc trạng thái) được thực thi bởi các nút/trình xác nhận đầy đủ Rollup, điều này mang lại cho chúng sự đảm bảo về gốc trạng thái hợp lệ bắt nguồn từ các khối được sắp xếp theo thứ tự của lớp cơ sở. Đối với tính xác định ngoài các nút đầy đủ (chẳng hạn như đối với ứng dụng khách nhẹ hoặc cầu nối chuỗi chéo), bạn phải chắc chắn về tính hợp lệ của gốc trạng thái này. Tại đây, bạn có thể sử dụng một trong các phương pháp được mô tả bên dưới. Ngoài ra, một cách tiếp cận khác là làm cho những người xác thực chịu trách nhiệm về bằng chứng chính xác của gốc trạng thái (lộ trình Lạc quan), thông qua một trái phiếu và bằng chứng gian lận sau đó. Ngoài ra, bạn có thể cung cấp bằng chứng về tính hợp lệ (ZK).
Các cách khác nhau để đạt được tính hữu hạn của khối:
Thông qua Proof of Work (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) và các phương pháp xác suất khác.
Một phương pháp có thể chứng minh được bằng cách có đủ thành viên ủy ban ký kết các khối. (ví dụ: Tendermint 2/3, Hotshot2 hoặc các loại PBFT khác)
Phụ thuộc vào thứ tự của các giao dịch/khối trên lớp DA và các quy tắc của nó, cụ thể là quy tắc lựa chọn chuỗi và ngã ba chuẩn.
Chúng ta có thể đạt được các loại tài chính khác nhau thông qua các cơ chế khác nhau.
Một loại tài chính cuối cùng là "tài chính mềm" (chẳng hạn như đang chờ xử lý), có thể đạt được bằng một cuộc bầu cử lãnh đạo duy nhất. Trong trường hợp này, mỗi vị trí sẽ chỉ có một hoặc không có khối nào (được cam kết hay không) và lớp đồng bộ hóa có thể đảm nhận chuỗi giao dịch trong các khối này một cách an toàn.
Một loại tài chính cuối cùng khác là "tài chính có thể chứng minh được", mang lại sự đảm bảo mạnh mẽ hơn (về cơ bản là cuối cùng) so với tài chính mềm. Để đạt được mục đích cuối cùng có thể chứng minh được, phần lớn những người đặt hàng phải ký vào một khối, qua đó thể hiện sự đồng ý của họ rằng khối đó là hợp quy. Mặc dù cách tiếp cận này là tốt, nhưng nó có thể không cần thiết nếu một cuộc bầu cử lãnh đạo duy nhất đã được thực hiện, vì về cơ bản nó đảm bảo trật tự khối. Rõ ràng, điều này phụ thuộc vào thuật toán bầu chọn nhà lãnh đạo cụ thể đang được triển khai. Ví dụ: tỷ lệ thực hiện là 51%, tỷ lệ thực hiện là 66% hay do một nhà lãnh đạo duy nhất (tốt nhất là bầu chọn ngẫu nhiên (VRF) và bí mật). Nếu bạn muốn tìm hiểu thêm về thuyết tất định trong Ethereum, hãy đọc bài viết này mà chúng tôi rất khuyến khích và bài viết chúng tôi sẽ đề xuất sau cho các bộ sắp xếp không giới hạn.
được cấp phép, bán giấy phép hoặc không được phép
Để ngăn chặn các cuộc tấn công DoS tiềm ẩn, các rào cản kinh tế phải được thiết lập để tham gia nhóm người đặt hàng và gửi giao dịch đến lớp người đặt hàng. Trong các nhóm có giới hạn (số lượng máy sắp xếp hữu hạn) và không giới hạn (số lượng máy sắp xếp không giới hạn), các rào cản kinh tế phải được đặt ra để gửi các lô đến lớp DA nhằm ngăn chặn lớp đồng bộ hóa (truyền khối giữa các máy phân loại) bị chậm lại hoặc bị tấn công DDoS . Tuy nhiên, bản thân lớp DA cũng cung cấp một số biện pháp bảo vệ, bởi vì việc gửi dữ liệu tới lớp DA cần phải trả phí (da_fee). Khoản tiền đặt cọc bảo mật cần thiết để tham gia nhóm không giới hạn sẽ bao gồm mọi chi phí bổ sung cần thiết để ngăn lớp đồng bộ hóa bị spam. Mặt khác, mức ký quỹ cần thiết để tham gia một nhóm giới hạn sẽ phụ thuộc vào nhu cầu (được cân bằng từ góc độ chi phí/doanh thu).
Đối với một bộ sắp xếp không giới hạn, chúng tôi không thể đạt được kết quả cuối cùng có thể chứng minh được ở lớp sắp xếp (vì chúng tôi không bao giờ biết chính xác có bao nhiêu cử tri/người ký tên đang hoạt động). Mặt khác, trong một nhóm có giới hạn gồm những người đồng hành, tính hữu hạn có thể chứng minh được có thể đạt được bằng cách đa số những người đồng hành ký các khối. Điều này yêu cầu lớp đồng bộ hóa phải biết về lớp trình sắp xếp thứ tự và có bao nhiêu trình sắp xếp thứ tự đang hoạt động tại bất kỳ thời điểm nào, đây là một số chi phí bổ sung. Trong một tập hợp các trình sắp xếp có giới hạn (ví dụ: tối đa 100), bạn cũng có thể tối ưu hóa số lượng trình sắp xếp để cải thiện "hiệu suất", mặc dù phải trả giá bằng khả năng phân cấp và chống kiểm duyệt. Tầm quan trọng của các nhóm bị ràng buộc và đảm bảo kinh tế để cung cấp sự chắc chắn có thể chứng minh "nhanh chóng" cũng mang tính quyết định.
Các loại bộ sắp xếp không giới hạn và bộ sắp xếp có giới hạn cũng được phản ánh trong các chuỗi khối truyền thống.Ví dụ: PoS (Casper+LMD-GHOST) trong Ethereum sử dụng loại không giới hạn, trong khi chuỗi dựa trên Cosmos SDK/Tendermint sử dụng loại có giới hạn. Một suy nghĩ thú vị là, liệu chúng ta có mong đợi thấy tính kinh tế giống như bằng chứng cổ phần và các lựa chọn từ cộng đồng xung quanh những người đặt hàng được chia sẻ không? Về vấn đề này, chúng tôi đã thấy một phong trào hướng tới tập trung hóa một số thực thể (vì vậy việc không giới hạn không thực sự quan trọng nếu bạn đã có một số nhà cung cấp/nhóm bằng chứng cổ phần lớn). Mặc dù họ "che giấu" việc tập trung hóa, nhưng sau tất cả, bạn vẫn có thể khai thác nếu muốn. Từ quan điểm hệ tư tưởng, các lựa chọn hầu như luôn luôn không có giới hạn - nhưng hãy nhớ rằng các nguyên tắc kinh tế dù sao cũng làm cho chúng rất giống nhau. Bất kể người tham gia là ai, tính kinh tế của số tiền bạn trả vẫn phải như nhau, chẳng hạn như chi phí DA và chi phí phần cứng (mặc dù điều này có thể giảm đi do số lượng bằng chứng cổ phần mà bạn phân bổ và trải nghiệm, cũng như hiệu quả vận hành cơ sở hạ tầng). Ngay cả trong thế giới PoS có giới hạn, chúng tôi đã chứng kiến một nhóm các nhà cung cấp cơ sở hạ tầng trở thành những người xác nhận lớn nhất và phổ biến nhất trên hầu hết các chuỗi. Trên hầu hết các chuỗi Cosmos, sự phụ thuộc giữa các trình xác nhận đã rất lớn và điều này chắc chắn gây nguy hiểm cho khả năng chống phân cấp và kiểm duyệt của các chuỗi nói trên. Tuy nhiên, một thực tế rất khác là bất kỳ nhà đầu tư bán lẻ nào cũng có thể đặt cược bất kỳ số tiền nào với bất kỳ trình xác nhận nào mà họ chọn. Thật không may, điều này thường được xếp lên đầu danh sách và cuộc sống vẫn tiếp diễn. Chúng tôi hỏi lại: chúng ta có mong đợi một mô hình kinh tế tương tự trong một thế giới mô-đun không? Một mong muốn không phải như vậy, nhưng với chuyên môn hóa, bạn thường cần người phù hợp nhất - và họ có xu hướng trở thành nhà cung cấp bằng chứng cổ phần chuyên nghiệp. Chúng tôi cũng sẽ đề cập đến những vấn đề kinh tế này trong một chương riêng sau.
Tuy nhiên, một điều quan trọng cần nhớ trong tất cả những vấn đề này là điều quan trọng nhất là xác thực người dùng cuối, tính năng này có sẵn cho bất kỳ ai, bất kể họ ở đâu (ngay cả ở Giza) thông qua ứng dụng khách nhẹ và kim tự tháp DAS).
Nguồn: @JosephALChami
Dưới đây là những đánh đổi và lợi thế của bộ sắp xếp có giới hạn và không giới hạn:
Bộ sắp xếp không giới hạn:
*Bất kỳ ai có đủ trái phiếu/đặt cược đều có thể trở thành người phân loại = mức độ phân quyền cao
Không thể có một cuộc bầu chọn người lãnh đạo duy nhất, vì bộ sắp xếp về cơ bản là vô hạn.
Có thể bầu chọn người lãnh đạo không đơn lẻ thông qua VRF, nhưng rất khó để xác định các tham số VRF vì không biết sẽ có bao nhiêu người đặt hàng. Đây cũng nên là một cuộc bầu cử thủ lĩnh bí mật nếu có thể để tránh các cuộc tấn công DoS.
Không bầu người lãnh đạo = lãng phí tài nguyên Vấn đề: Xây dựng khối về cơ bản là một cuộc cạnh tranh tự do, ai gửi khối/lô hợp lệ đầu tiên sẽ thắng và những người khác thua cuộc. · · · Không có sự chắc chắn có thể chứng minh được ở cấp độ người đặt hàng, chỉ mang tính xác suất: ví dụ: LMD Ghost+Casper
Tính cuối cùng chỉ đạt được sau khi các lô được ghi vào lớp DA (chỉ giới hạn bởi thời gian khối cơ bản, 15 giây trong trường hợp của Celestia).
Các tập hợp không giới hạn có khả năng chống kiểm duyệt "tốt hơn" so với các tập hợp giới hạn.
Bộ sắp xếp có giới hạn:
Đây là một trong những giải pháp của Ethereum cho chủ nghĩa quyết định một vị trí và có một ủy ban siêu "đa số".
Có giới hạn về số lượng trình tự được phép tại bất kỳ thời điểm nào.
Tập hợp có giới hạn phức tạp hơn tập hợp không giới hạn.
Có thể thực hiện một cuộc bầu chọn người lãnh đạo duy nhất, mang lại sự đảm bảo chắc chắn mạnh mẽ cho lớp sắp xếp.
Lớp đồng bộ hóa cần hiểu tập hợp người đặt hàng để xác định khối nào hợp lệ.
Ghi bộ sắp xếp (hoặc thay đổi bộ) vào các khối của lớp giải quyết (chẳng hạn như quy tắc chọn ngã ba), được ghi vào lớp DA, cho phép lớp đồng bộ hóa xác định bộ sắp xếp một cách độc lập. Ví dụ: đây là những gì Sovereign Labs' Rollup thực hiện, các thay đổi của bộ sưu tập được ghi vào bằng chứng hợp lệ được xuất bản lên lớp DA.
Sự đảm bảo chắc chắn về tính hữu hạn của lớp đặt hàng có thể không cần thiết nếu lớp DA đủ nhanh (tuy nhiên, hầu hết các thiết lập lớp dàn xếp không được tối ưu hóa hiện tại đều có thời gian khối ít nhất hơn 10 giây).
Có không gian thiết kế đáng kể về cách giám sát các bộ sắp xếp này và các thành viên mới được thêm hoặc xóa. Ví dụ: điều này sẽ đạt được thông qua Quản trị Tokenholder (còn nhiều Token và Rollup khác nhau bằng cách sử dụng các bộ sưu tập thì sao?). Điều này có nghĩa là có thể thực hiện các thay đổi báo hiệu ngoài chuỗi thông qua sự đồng thuận xã hội (ví dụ: lấy Ethereum làm ví dụ). Tuy nhiên, hãy nhớ rằng sự đồng thuận trên chuỗi thực tế đã được thiết lập rõ ràng và các hình phạt cho việc vi phạm các quy tắc đồng thuận đã tồn tại.
Cơ chế kinh tế cho máy phân loại dùng chung
Tính kinh tế của việc chia sẻ một mạng lưới các trình tự giải mã cho phép một số tùy chọn thú vị. Như chúng ta đã thảo luận trước đó, trình xác thực trong mạng đặt hàng được chia sẻ không khác lắm so với trình xác nhận L1 điển hình. Mạng mà nó tham gia đơn giản là được tối ưu hóa hơn để thực hiện một nhiệm vụ, đó là nhận các ý định (trước đây là PBS), và do đó đề xuất và đặt hàng các giao dịch. Cũng giống như trình xác thực "thông thường", có các thành phần doanh thu và chi phí. Ở cả hai phía của phương trình, có rất nhiều tính linh hoạt trong các mạng mà trình xác thực tham gia, tương tự như L1 thông thường.
Doanh thu đến từ người dùng hoặc Tổng số mà cuối cùng họ muốn tương tác với việc trả một khoản phí nhất định để sử dụng trình sắp xếp thứ tự được chia sẻ. Phí này có thể là tỷ lệ phần trăm MEV được rút (việc nhập số có thể khó ước tính), chuyển giá trị chuỗi chéo, Gas hoặc phí cố định cho mỗi tương tác. Giải pháp doanh thu phù hợp nhất có thể là trả giá trị thấp hơn cho người đặt hàng được chia sẻ so với giá trị bổ sung thu được thông qua người đặt hàng được chia sẻ Tổng số, cùng với các lợi ích về bảo mật và thanh khoản được chia sẻ. Nhưng nhược điểm của điều này là rất khó để định lượng lợi ích phi tập trung của một phần khác của hệ thống. Tuy nhiên, khi mạng đặt hàng được chia sẻ phát triển thành hệ sinh thái riêng, khả năng trích phí có thể tăng lên. Điều này phần lớn là do khả năng tổng hợp vốn có của họ một cách dễ dàng, với quy mô kinh tế nhất định. Khi có nhiều Bản tổng hợp và ứng dụng tham gia vào mạng, ngày càng có nhiều MEV miền chéo có thể trích xuất.
Về chi phí, các mạng đặt hàng được chia sẻ cũng có các lựa chọn cạnh tranh. Họ có thể dễ dàng tài trợ cho việc sử dụng mạng của mình bằng cách tài trợ chi phí xuất bản trên lớp DA hoặc thậm chí là chi phí tương tác với các ứng dụng trên Rollup. Điều này tương tự như chiến lược được sử dụng bởi các công ty Web 2.0, trong đó bạn chịu lỗ ban đầu khi thu hút người dùng (hoặc tổng số), hy vọng rằng doanh thu dài hạn của họ sẽ lớn hơn phí. Một phương pháp mới lạ hơn hoặc có nguồn gốc từ tiền điện tử là cho phép Rollup thanh toán phí DA bằng Mã thông báo gốc của nó. Ở đây, lớp sắp xếp được chia sẻ chịu rủi ro về giá giữa Mã thông báo cần thiết để xuất bản dữ liệu trên lớp DA và Mã thông báo gốc của Rollup. Về bản chất, nó vẫn là chi phí trả trước của bộ sắp xếp được chia sẻ, nhưng nó tạo ra sự nhất quán của hệ sinh thái bằng cách lấy Mã thông báo của "nhà cung cấp" (tức là Rollup). Điều này hơi giống với việc xây dựng nhà kho mà chúng tôi đã giải thích trong bài viết về AppChain và các dạng DA khác nhau có thể được sử dụng để giảm chi phí. Các tầng DA khác nhau sẽ đưa ra mức giá khác nhau do việc sử dụng, khả năng xác minh dễ dàng của người dùng thông qua ứng dụng khách nhẹ hoặc đơn giản là đưa ra các lựa chọn kích thước khối khác nhau. Cuối cùng, người đặt hàng được chia sẻ cũng có thể giao dịch hàng loạt trước khi xuất bản lên lớp DA. Trong trường hợp của ZKR, điều này có thể giảm chi phí giao dịch thông qua một số số dư giao dịch nhất định và đối với ORU, bạn có thể thực hiện các tối ưu hóa Gas xử lý hàng loạt khác nhau mà chúng tôi hiện có thể thấy trên các Bản tổng hợp khác nhau. Điều này sẽ làm giảm lượng dữ liệu cần được xuất bản lên lớp DA, do đó giảm chi phí của mạng trình sắp xếp thứ tự được chia sẻ và tăng khả năng sinh lời của toàn bộ mạng. Điều này sẽ phải trả giá bằng việc hạn chế khả năng tương tác và thay đổi thời gian tồn tại của khối (tính xác định trên L1 như đã đề cập trước đó).
Nhìn chung, tính kinh tế của việc chia sẻ một mạng lưới các trình tự giải mã cho phép một số chiến lược khởi động và thử nghiệm thú vị. Chúng tôi ước tính rằng sự khác biệt chính sẽ là quy mô của hệ sinh thái, vì vậy số lượng MEV giữa các miền lớn hơn khía cạnh chi phí. Chúng tôi cũng khuyên bạn nên xem bài đăng trên blog của nhóm Espresso về những người đặt hàng được chia sẻ, chúng cũng đề cập đến sự cân bằng kinh tế (và mặt tích cực) của các loại mạng này. Để chỉ ra lý do tại sao Rollup được thúc đẩy để tận dụng các bộ sắp xếp được chia sẻ (bên cạnh tính kinh tế), chúng ta có thể xem xét nó từ góc độ lý thuyết tổng hợp.
Lý thuyết tổng hợp và bộ sắp xếp chia sẻ
Một cách khác để mô tả các thuộc tính do các bộ sắp xếp dùng chung mang lại là thông qua lăng kính của lý thuyết tập hợp. Lý thuyết tổng hợp đề cập đến khái niệm về cách một nền tảng hoặc trình tổng hợp tích hợp các nền tảng khác và người dùng của chúng theo cách có hệ thống để thu hút sự chú ý đáng kể của người dùng. Về cơ bản, bạn đang chuyển trò chơi từ việc phân bổ tài nguyên khan hiếm (ví dụ: không gian khối) sang nhu cầu kiểm soát nguồn tài nguyên dồi dào (một lần nữa, không gian khối có ý nghĩa trong ví dụ này). Lý thuyết tổng hợp thực sự tổng hợp các nhà cung cấp và sản phẩm (tức là Rollup và Blockspace) thành một trải nghiệm siêu người dùng để phục vụ cơ sở người dùng tổng hợp. Khi hiệu ứng mạng của các công cụ tổng hợp này phát triển, mối quan hệ này ngày càng trở nên độc quyền. Khi điều này xảy ra, trải nghiệm người dùng trở thành điểm khác biệt chính giữa các thiết lập tương tự. Nếu có các ưu đãi để thu hút người dùng mới (chẳng hạn như trải nghiệm người dùng tốt và khả năng tương tác tốt hơn), Rollup sẽ không chuyển sang mạng riêng hoặc thiết lập khác - vì hiệu ứng mạng thúc đẩy các nhà cung cấp mới và người dùng mới tham gia. Điều này tạo ra hiệu ứng bánh đà, không chỉ từ góc độ nhà cung cấp và người dùng, mà còn từ góc độ chống kiểm duyệt tổng hợp.
Nguồn: Aggregation Theory 2015, Ben Thompson
Trong lĩnh vực sắp xếp được chia sẻ, Lý thuyết tổng hợp có thể được coi là "sự kết hợp" và liên kết của nhiều Bản tổng hợp khác nhau, tất cả đều sử dụng các chiều dọc tương tự của ngăn xếp - trao quyền cho chính họ và những người khác trong khi cho phép người dùng có được trải nghiệm giống nhau.
Các nhà cung cấp (chẳng hạn như Rollup) về mặt lý thuyết không dành riêng cho bộ coorter được chia sẻ, nhưng trên thực tế, bộ coorter được chia sẻ, các rollup của nó và người dùng được hưởng lợi từ một loạt các hiệu ứng mạng dẫn đến việc sử dụng các rollup này tăng lên. Những lợi ích này giúp Rollup và người dùng tích hợp vào ngăn xếp được chia sẻ dễ dàng hơn vì họ sẽ mất nhiều hơn nếu không tham gia. Mặc dù khó có thể thấy được những lợi ích này khi bạn chỉ có hai Tổng số chia sẻ một bộ trình tự sắp xếp duy nhất, nhưng chúng sẽ trở nên rõ ràng hơn khi bạn thêm ngày càng nhiều Tổng số và Người dùng vào phương trình. Bộ sắp xếp dùng chung có mối quan hệ trực tiếp với người dùng, khi họ sắp xếp các giao dịch của mình, ngay cả khi bản thân người dùng không biết họ đang tương tác với chúng, vì theo quan điểm của họ, họ chỉ đang sử dụng Tổng số mà họ có lý do để tương tác ( Điều này có nghĩa là đặt hàng/phân loại trở thành độc quyền). Chi phí duy nhất của những bộ sắp xếp này thực sự là chi phí phần cứng để chạy chúng, miễn là không gian khối và mã thông báo bảo vệ nó có giá trị đối với người dùng cuối. Phí giao dịch được số hóa, thanh toán từ ví của người dùng và có lẽ trong tương lai, thậm chí có thể được trừu tượng hóa thông qua các tiến bộ như máy chủ thanh toán trong trừu tượng hóa tài khoản (tuy nhiên, ai đó sẽ phải chịu chi phí DA, đặt hàng và thực hiện).
Điều này có ý nghĩa hơn khi xem xét công ty trước đây của Josh và Jordan ở Astria - Google. Kể từ khi thành lập, các sản phẩm của Google đã lấy cảm hứng từ ý tưởng về AT, đặc biệt là trong Tìm kiếm của Google, được tạo bằng cách mô đun hóa các trang và bài báo riêng lẻ, giúp chúng có thể truy cập trực tiếp thông qua cửa sổ tìm kiếm toàn cầu.
Trong trường hợp một bộ sắp xếp được chia sẻ, những người dùng sử dụng Rollup (những người chia sẻ một bộ sắp xếp) có chi phí mua lại ngày càng thấp hơn, bởi vì khi số lượng nhà cung cấp (Rollup) tăng lên, họ có khả năng bị thu hút bởi bộ sắp xếp . Điều này có nghĩa là, trong hầu hết các trường hợp, một bộ tổng hợp (hoặc nhiều bộ tổng hợp) có thể có tác dụng đôi bên cùng có lợi, vì giá trị của một bộ tổng hợp tăng theo số lượng nhà cung cấp (tất nhiên là miễn là trải nghiệm người dùng tốt). Ngược lại, trên một mạng nối tiếp duy nhất, việc thu hút khách hàng bị giới hạn trong một mạng duy nhất và các ứng dụng của nó. Nếu người dùng muốn sử dụng ứng dụng Rollup trên một Rollup khác, họ sẽ phải (trong giới hạn hiện tại) đăng xuất hoàn toàn khỏi mạng. Điều này có nghĩa là độ gắn bó và giá trị của người dùng không cao lắm, và cũng có nghĩa là bất cứ lúc nào, nếu một hệ sinh thái Rollup khác được đánh giá cao (hoặc có nhiều ưu đãi hơn), vốn có thể bị thất thoát.
Thuộc tính và Tóm tắt Đánh đổi
Thuộc tính
Bộ sắp xếp được chia sẻ là một mạng tổng số tổng hợp và sắp xếp các giao dịch cho nhiều lần tổng số. Các Tổng số này chia sẻ cùng một bộ sắp xếp. Việc tổng hợp các tài nguyên này có nghĩa là Rollup có được khả năng chống kiểm duyệt và bảo mật kinh tế mạnh mẽ hơn, có thể cung cấp bảo đảm xác định mềm nhanh chóng và giao dịch Rollup chéo có điều kiện.
Ngay bây giờ, có rất nhiều ồn ào về tính nguyên tử giữa các Bản tổng hợp chia sẻ cùng một bộ sắp xếp, chủ yếu xoay quanh việc liệu nó có phải là nguyên tử theo mặc định hay không. Tuy nhiên, nếu các Tổng số được đề cập triển khai các hàm chuyển đổi trạng thái (STF) của nhau dưới dạng phụ thuộc giữa chúng, liên quan đến các giao dịch có điều kiện, thì chúng thực sự có thể đạt được tính nguyên tử giữa chúng - miễn là Sắp xếp vị trí/thời gian khối của chúng (như với các bộ sắp xếp được chia sẻ). Trong trường hợp này, để có được khả năng tương tác nguyên tử, bạn thực sự chỉ cần chạy một ứng dụng khách nhẹ của chuỗi B trên chuỗi A và ngược lại (tương tự như cách IBC hoạt động). Để tăng cường hơn nữa khả năng tương tác của các biện pháp bảo mật (ngoài việc tin tưởng một nút đầy đủ duy nhất làm nút nhẹ), bạn có thể triển khai ZKP (Proof of State) để giải quyết "vấn đề tiên tri" về đảm bảo tính chính xác của trạng thái. Điều này sẽ làm cho nó rõ ràng hơn để xem liệu một giao dịch có điều kiện hoặc một cái gì đó tương tự như vậy có đạt được cầu nối chuỗi chéo chính tắc giữa chúng hay không. Bằng chứng gian lận cũng có thể xảy ra, nhưng rõ ràng sẽ để lại một khoảng thời gian thử thách (có nghĩa là một bên thứ ba sẽ đến để trang trải chi phí cho rủi ro này). Ngoài ra, trong trường hợp máy khách nhẹ (chứ không phải nút đầy đủ), nó sẽ chậm hơn ít nhất một khối do chờ tiêu đề chữ ký + cửa sổ chống gian lận (nếu có).
Chúng tôi tin rằng vấn đề "cầu nối chuỗi chéo" rất có thể được giải quyết với các ứng dụng khách nhẹ và bằng chứng không có kiến thức. Thách thức với việc sử dụng ứng dụng khách nhẹ (chứ không phải hợp đồng thông minh) trong trường hợp này là các nhánh cứng (nâng cấp, v.v.) ở phía nút Rollup cần phối hợp với nhau để duy trì hoạt động của cầu nối (giống như IBC cần kích hoạt cùng một mô-đun trạng thái). Nếu bạn muốn tìm hiểu sâu hơn về chủ đề cụ thể này (và cách giải quyết nó), chúng tôi thực sự khuyên bạn nên xem bản trình bày này.
Lý do mà những người đặt hàng được chia sẻ mở rộng quy mô rất tốt là vì chúng không thực thi và lưu trữ bất kỳ trạng thái nào (như những người đặt hàng tập trung vẫn làm ngày nay). Điều tương tự cũng xảy ra với chính các nút Tổng số (trừ khi chúng muốn có tính nguyên tử giữa chúng - ví dụ: ứng dụng khách nhẹ/bằng chứng trạng thái). Các nút này chỉ thực hiện các giao dịch hợp lệ cho Rollup của chúng và bất kỳ giao dịch tên miền chéo có điều kiện nào hợp lệ đối với chúng. Nếu một nút Tổng số phải thực thi và lưu trữ trạng thái cho nhiều lần Tổng số, thì điều đó sẽ cản trở khả năng mở rộng và giảm tính phân cấp (và do đó khả năng chống kiểm duyệt). Điều này cũng củng cố khái niệm phân tách nhà sản xuất-nhà xây dựng khối (PBS). Mặc dù chúng ta vẫn cần tách biệt hoàn toàn các nhà xây dựng và nhà sản xuất khối. Trong thiết lập hiện tại, người đặt hàng về cơ bản là người xây dựng và sản xuất khối (mặc dù họ không thực hiện giao dịch). Một thiết lập lý tưởng có thể là một thiết lập mà người đặt hàng tồn tại chỉ để ký một cách mù quáng các khối từ thiết lập trình tạo được tối ưu hóa cao và đảm bảo rằng các khối được triển khai chính xác (đồng thời mang lại mức độ chắc chắn về kinh tế cao và khả năng chống kiểm duyệt đối với chứng nhận đó). Bằng cách này, họ có thể cung cấp mức độ bảo mật cao và cam kết đảm bảo tính hữu hạn mềm cho các nút Rollup.
Đối với các giao dịch có điều kiện tổng số chéo, chúng cũng tồn tại để giúp cho phép các nút tổng số (bộ thực thi) cung cấp gốc trạng thái trung gian, cho phép tính nguyên tử giữa các lần tổng số.
đánh đổi
Thông số thời gian chờ đã nói ở trên có một số tác động thú vị đối với MEV và bao gồm giao dịch, tùy thuộc vào cơ chế masternode/đồng thuận của tập hợp người đặt hàng. Ví dụ: nếu tham số thời gian chờ được mô tả là tương đối ngắn trong tài liệu chuỗi dành riêng cho ứng dụng của chúng tôi, thì điều quan trọng là các nhà sản xuất khối của một nhóm người đặt hàng phi tập trung xuất bản dữ liệu càng nhanh càng tốt. Trong một thế giới như vậy, bạn có thể thấy sự cạnh tranh giữa các "người xác thực", những người cạnh tranh để trở thành các nút chính và đặt giá thầu trên lớp DA cho không gian khối cho đến khi nó không còn sinh lãi nữa.
Như Evan đã trình bày trong bài đăng về người đặt hàng lười biếng ban đầu của mình trên diễn đàn Celestia, việc chờ đợi các giao dịch được xuất bản lên lớp cơ sở (trong trường hợp này là Celestia) trước khi thực hiện chúng là rất kém hiệu quả. Vì bây giờ bạn bị giới hạn bởi thời gian khối của lớp cơ sở - quá lâu để chờ đợi trải nghiệm của người dùng. Để có trải nghiệm người dùng tốt hơn, trình đặt hàng được chia sẻ cung cấp các Bản tổng hợp với các cam kết xác định mềm (như được mô tả trước đó), cung cấp cho người dùng trải nghiệm người dùng mà họ đã quen thuộc trong các Bản tổng hợp tập trung hiện có (đồng thời duy trì tính phi tập trung và khả năng chống kiểm duyệt cao). Các cam kết mềm về cơ bản chỉ là các cam kết đối với thứ tự giao dịch cuối cùng, nhưng được hỗ trợ bởi các bảo đảm kinh tế nặng nề và hoàn tất nhanh chóng sau khi được ban hành. Điều này cũng được bao phủ bởi các bằng chứng gian lận (như đã đề cập trong phần giới thiệu). Độ chính xác cứng thực tế đạt được sau khi tất cả dữ liệu giao dịch đã được xuất bản lên lớp cơ sở (có nghĩa là L1 thực sự đạt được độ cuối nhanh hơn). Nó phụ thuộc vào việc Rollup sử dụng bằng chứng gian lận hay bằng chứng không có kiến thức để xác minh bằng chứng chủ quyền - điều này xảy ra trên Rollup. Lý do muốn có sự tách biệt này là để loại bỏ nút cổ chai khổng lồ của quá trình chuyển đổi trạng thái khỏi bộ phân loại. Thay vào đó, các nút Rollup chỉ xử lý các nút hợp lệ đối với chúng (nghĩa là chúng tôi phải thêm các giao dịch có điều kiện, bằng chứng về trạng thái hoặc xác thực nút nhẹ để có khả năng tương tác phù hợp). Tính xác định cứng vẫn phụ thuộc vào lớp cơ sở (nhưng điều này có thể đạt tới 15 giây trên Celestia và cũng mang tính xác định trong Tendermint), điều này mang lại cho chúng tôi sự đảm bảo về tính xác định cứng tương đối nhanh trên Rollup.
Sử dụng bằng chứng không có kiến thức bên trong mạng để tối ưu hóa quá trình xác thực, quy mô giao dịch (ví dụ: chỉ xuất bản sự khác biệt về trạng thái - nhưng điều này sẽ thêm mức độ tin cậy cao hơn cho đến khi ZKP được xuất bản). Như đã đề cập trước đó, các bằng chứng trạng thái này có thể được sử dụng để cho phép các chuỗi/bản tổng hợp được kết nối có khả năng tương tác dễ dàng và nhanh hơn (không cần đợi các cửa sổ thử thách).
Nhược điểm của các giao dịch có điều kiện này là chúng có thể đắt hơn, đòi hỏi chi phí xác minh và phát hành cao hơn (chẳng hạn như chi phí xác minh tiêu đề khối Tendermint, được trợ cấp trên chuỗi Cosmos) và thêm một số độ trễ cho hệ thống ( nhưng vẫn nhanh hơn so với Bản tổng hợp biệt lập nhanh hơn nhiều). Tính nguyên tử đạt được nhờ tích hợp chia sẻ theo chiều dọc có thể bù đắp cho những vấn đề này.
Trong giai đoạn khởi động của một bản tổng hợp mới, việc sử dụng một bộ đối chiếu được chia sẻ rất có ý nghĩa và những lợi thế bạn có được với tư cách là nhà cung cấp có thể sẽ lớn hơn một số sự đánh đổi mà bạn có thể "buộc phải" thực hiện ở cấp độ hào. Tuy nhiên, đối với một Rollup đã trưởng thành, nơi có nhiều giao dịch và hoạt động kinh tế, có lẽ không hợp lý khi từ bỏ một phần của con hào.
Điều này đặt ra câu hỏi liệu chúng ta có cần phân phối lại MEV được trích xuất có trọng số kinh tế/giao dịch (mỗi lần tổng hợp) tương tự để tạo ra các Bản tổng hợp đã trưởng thành tham gia vào tập hợp được chia sẻ hay không - hoặc thậm chí ngăn các Bản tổng hợp cực kỳ trưởng thành tạo mạng riêng. Đây hoàn toàn là lý thuyết, nhưng chắc chắn đây là một quá trình suy nghĩ thú vị liên quan đến cách MEV trong các thế giới dọc được chia sẻ sẽ được thể hiện giữa nhiều Bản tổng hợp với các mức độ hoạt động khác nhau. Ví dụ: nếu một Tổng số duy nhất thúc đẩy giá trị chia sẻ một số lợi nhuận này với những người khác (có thể không mang lại nhiều "giá trị") thông qua Bộ trình tự sắp xếp, thì phải có thêm lý do để họ chuyển sang hệ thống riêng biệt của mình . Sreeram của EigenLayr cũng có một số suy nghĩ về điều này, chúng tôi cũng khuyên bạn nên đọc.
Điều này ngày càng trở nên quan trọng khi xem xét rằng có một chi phí kỹ thuật đáng kể cho những người tìm kiếm để phát triển các chuỗi mới, vì vậy việc tiêu chuẩn hóa và cung cấp một số chủ quyền đối với MEV "của họ" có thể là một nơi tốt để bắt đầu. Trên thực tế, trong MEV, giao diện (hoặc phần mềm) chiếm ưu thế có thể giành chiến thắng, nhưng thực tế việc kiếm tiền từ phần mềm đó bằng cách chạy các phần quan trọng của cơ sở hạ tầng là rất khó (dẫn đến tập trung hóa). Ở cấp độ thị trường, những gì một người đặt hàng được chia sẻ cung cấp về cơ bản là một bộ nhớ chung cho nhiều nhà cung cấp, với một cuộc đấu giá tập trung, điều này có thể dẫn đến sự cạnh tranh lành mạnh hơn.
Một mối quan tâm ở đây là nếu hai Tổng số đang chạy bộ sắp xếp trong tập hợp dùng chung, thì một Tổng số có giá trị "kém kinh tế hơn" (A) có thể được chọn để đề xuất một tổng số có lượng MEV + phí cao từ các khối Tổng hợp (B). . Theo quan điểm của Rollup B, về cơ bản, họ đã bỏ lỡ một số giá trị mà theo cách tiếp cận biệt lập, họ sẽ giữ cho riêng mình.
Giải quyết vấn đề đánh đổi khả năng tương tác
Một lưu ý khác về sự đánh đổi do khả năng tương tác thể hiện và một cách khác để giải quyết một số vấn đề sau:
Mục đích của mạng đặt hàng được chia sẻ là cung cấp sự đảm bảo chính tắc cho nhiều chuỗi, đây rõ ràng là một lợi thế lớn trong trường hợp này. Điều này có thể được kết hợp với một cơ chế để đảm bảo chuyển đổi trạng thái hiệu quả giữa các Rollup. Đây có thể là cách tiếp cận dựa trên ủy ban (ví dụ: PoS), bằng chứng được bảo mật (phương pháp Lạc quan) hoặc cách tiếp cận ưa thích của chúng tôi - ZKP được hỗ trợ bởi chữ ký của ủy ban. Bởi vì các bộ sắp xếp được chia sẻ "lười biếng", chúng chỉ tạo các siêu khối để sắp xếp các giao dịch của nhiều Bản tổng hợp và việc thực thi giao dịch cụ thể được dành cho một Bản tổng hợp cụ thể. Bằng chứng về trạng thái (tức là Lagrange, Axiom hoặc Herodotus, v.v.) đều là những giải pháp khả thi để có khả năng thu được bằng chứng về tính hữu hạn trong các lần tổng hợp có chủ quyền. Bạn thậm chí có thể thêm bằng chứng về tính hữu hạn được đảm bảo về mặt kinh tế thông qua những thứ như nhóm đặt cược, EigenLayr, v.v. Ý tưởng cơ bản là một bộ sắp xếp dùng chung cung cấp một sự đảm bảo kinh tế cho việc đặt hàng và bằng chứng hợp lệ được tạo ra từ sự sắp xếp này là xác định. Ý tưởng cơ bản là Rollup có thể thực hiện các giao dịch đồng bộ với nhau. Ví dụ: một mạng gồm hai nút Tổng số có thể biết một cách có điều kiện rằng cả hai lịch sử Tổng số đều hợp lệ, thông qua ZKP và dữ liệu có sẵn (dữ liệu được xuất bản lên lớp DA hiệu quả). Bằng cách xuất bản một tiền tố khối Tổng số duy nhất từ cả hai mạng A và B, một nút Tổng số có thể giải quyết hai lần Tổng số cùng một lúc. Một điều cần chỉ ra là các giao dịch cuộn chéo có điều kiện tiêu thụ tài nguyên từ hai hệ thống riêng biệt thông qua thực thi được chia sẻ, do đó, các giao dịch nguyên tử (hoặc đồng bộ) trong cuộn chéo có thể đắt hơn so với các giao dịch nội bộ cuộn lên một lần.
Succinct cũng đề cập đến các giao dịch "nguyên tử" xuyên chuỗi giữa Rollup với những người đặt hàng được chia sẻ (và các bằng chứng gian lận được chia sẻ) trong hệ sinh thái siêu chuỗi Optimism, có thể xem tại đây. Ngoài ra, như Bo Du của Polymer đã nói: "Các giao dịch nguyên tử xuyên chuỗi giống như có được các khóa giữa các phân đoạn cơ sở dữ liệu khi ghi".
Tương lai của hội nhập dọc
Các hoạt động bên trong có thể có của chuỗi SUAVE đã được Jon Charbonneau và cộng sự khám phá sâu, vì vậy chúng tôi sẽ không đi sâu vào chi tiết. Nếu bạn muốn mô tả chi tiết hơn, bạn có thể xem bài viết của anh ấy. Tuy nhiên, chúng tôi cho rằng tích hợp dọc xứng đáng được giới thiệu riêng, vừa để làm nổi bật cách chúng ta có thể trở thành mô đun (và tại sao) vừa để giới thiệu một số vấn đề và mối quan tâm liên quan đến tích hợp dọc.
Mặc dù sơ đồ đặt hàng được chia sẻ hiện tại của Astria, Espresso và Radius rất mô đun, nhưng những người đặt hàng vẫn đóng vai trò là người xây dựng và sản xuất khối (mặc dù trong trường hợp của Astria, họ không thực hiện giao dịch). Astria cũng đã tích cực xây dựng PBS thành kiến trúc của mình ngay từ đầu.
Nếu PBS không được tích hợp trong giao thức, thì có một số cách để triển khai PBS (mặc dù với các mức độ phân quyền khác nhau). Các sản phẩm như SUAVE, sử dụng các mô hình ngoại tuyến như MEV-Boost hoặc triển khai các mô-đun trình tạo như mô-đun SDK Cosmos do Mekatek và Skip xây dựng.
Điều đáng chú ý là không có phương pháp nào trong số này là loại trừ lẫn nhau. Bạn có thể linh hoạt sử dụng một số phương pháp khác nhau và để mọi người thể hiện sở thích của họ. Bằng cách đó, bạn có thể có những người thi hành cạnh tranh để lấp đầy những chỗ trống đó. Thêm nhiều tùy chọn hơn luôn tốt (và phù hợp với niềm tin của chúng tôi về tính mô đun). Tuy nhiên, các triển khai khác nhau sẽ có sự đánh đổi khác nhau. Ví dụ: trong trường hợp như SUAVE, bạn có thể thêm bảo vệ quyền riêng tư thông qua công nghệ SGX hoặc Crypto và thêm bảo mật kinh tế Crypto vào sự thật, thay vì dựa vào trình tạo PBS tập trung hoàn toàn đáng tin cậy. (Cảm ơn Jon Charbonneau vì phản hồi của anh ấy ở đây).
Tích hợp dọc vào chuỗi trình tạo đảm bảo tính công bằng mà không cần sử dụng lối tắt, làm tăng thêm độ trễ và làm giảm hiệu suất. Do đó, chuỗi trình tạo cần được tối ưu hóa cao và có thể yêu cầu phần cứng mạnh và đắt tiền (dẫn đến tập trung hóa). Điều này có nghĩa là để có được xác thực của người dùng cuối, chúng tôi có thể cần một số loại nút nhẹ (mặc dù họ phải tin tưởng vào các nút đầy đủ) hoặc sử dụng bằng chứng về thiết lập loại trạng thái để đảm bảo chuỗi và người dùng có bằng chứng rằng tùy chọn giá thầu được lấp đầy và các khối được xây dựng chính xác.
Một chuỗi như thế này có thể rất nặng về trạng thái (chúng tôi muốn tránh điều này), mặc dù các giao dịch nặng về trạng thái này sẽ được ưu tiên thông qua hợp đồng thông minh. Trong trường hợp giá thầu ưu tiên, nó sẽ được lấp đầy hoặc không được lấp đầy (trong một khoảng thời gian ngắn), vì giá thầu thường chỉ có hiệu lực trong một khoảng thời gian ngắn, tùy thuộc vào sở thích. Điều này có nghĩa là chúng tôi có thể triển khai hết hạn trạng thái rất hiệu quả (và sớm) cho giá thầu - điều này sẽ cho phép chúng tôi cắt bớt dữ liệu và giữ cho chuỗi "sạch". Ngày hết hạn này cần phải đủ dài để vẫn cho phép các giá thầu được lấp đầy trước, nhưng việc hạ thấp nó quá nhiều sẽ khiến việc đạt được các hợp đồng tương lai không gian khối chuyển tiếp gần như không thể. Chúng tôi không cần cập nhật và truy xuất các hợp đồng giá thầu đã hết hạn vì chúng không cần tồn tại mãi mãi (không giống như các ứng dụng) - điều này có thể được thực hiện bằng cách cung cấp bằng chứng trạng thái/lưu trữ khi giá thầu được lấp đầy hoặc bằng các giải pháp lưu trữ DAS (chẳng hạn như đề xuất bằng giải pháp Joachim Neu) để làm cho nó trở nên "an toàn" và đáng tin cậy hơn.
Như đã đề cập trước đó, nhu cầu xác minh "tính xác thực" của SUAVE có thể chỉ giới hạn ở "jusha" (người dùng nâng cao) của nền tảng, bởi vì hầu hết người dùng và khách hàng của SUAVE có thể thu được lợi ích kinh tế cao từ nó. Điều này có thể thúc đẩy chúng tôi chỉ cho phép mọi người chạy các nút đầy đủ nếu họ muốn xác thực - mặc dù điều này loại trừ đại đa số mọi người (bạn có thể nói rằng họ không cần xác thực). Điều này (theo ý kiến của chúng tôi) trái ngược với Crypto, nơi chúng tôi muốn triển khai xác minh SUAVE "không đáng tin cậy" thông qua các bằng chứng trạng thái hoặc triển khai thân thiện với khách hàng nhẹ.
Lý do điều này là cần thiết vì bạn muốn xác minh rằng mức độ ưu tiên giá thầu của bạn đã được điền chính xác và khối đã được điền thông tin chính xác khi thanh toán (để tránh hoàn trả và các lỗi khác). Đây thực chất là một vấn đề tiên tri - trên thực tế, nó có thể được giải quyết bằng một bằng chứng về trạng thái (như trường hợp của tất cả các SUAVE). Tuy nhiên, những bằng chứng trạng thái này đưa ra một vấn đề khác khi vượt qua các chuỗi, làm thế nào để chuyển tiếp thông tin này qua các chuỗi theo cách mà nó không bị giả mạo hoặc che giấu? Điều này có thể yêu cầu trải qua giai đoạn cuối cùng về kinh tế mạnh mẽ (chẳng hạn như do Lagrangian đề xuất), trong trường hợp đó, bạn có thể sử dụng trình xác nhận đặt lại của EigenLayr để chứng minh tính cuối cùng và tính xác thực của chuỗi, đồng thời có những hạn chế rất mạnh mẽ về kinh tế. Điều này sau đó làm nảy sinh một vấn đề khác (ví dụ: hợp đồng đấu thầu quy định rằng "máy tiên tri" - trong trường hợp này là bên cam kết lại - đã chỉ định Token được cam kết và cung cấp ràng buộc kinh tế - nhưng làm cách nào để tạo sự đồng thuận giữa Bên ngoài việc cắt giảm này? Trong khi bạn có thể viết các tiêu chí chặt chém, điều này không đồng thuận, có nghĩa là việc chặt chém xã hội sẽ bị khai thác thông qua hợp đồng thông minh (hầu như không bao giờ "công bằng" và có thể gây ra vấn đề). .
Vậy thứ này bỏ chúng ta ở đâu? Có thể, cho đến khi chúng ta vượt qua sự đồng thuận "không tin cậy" trên chuỗi, các chuỗi như SUAVE có thể cần các thuật toán đồng thuận và bảo mật kinh tế tiền điện tử của riêng họ để chứng minh các ưu tiên giá thầu và xây dựng sự chắc chắn của khối— Tuy nhiên, điều này có nghĩa là thêm nhiều vectơ tấn công kinh tế tiền điện tử hơn, đặc biệt nếu Rollup giá trị của các khối xây dựng của nó cao hơn nhiều so với bảo mật kinh tế tiền điện tử của chính nó.
Ngoài ra, vẫn còn rất nhiều không gian thiết kế trong các chuỗi loại SUAVE và MEV giữa các miền.Dưới đây là một số hướng nghiên cứu khả thi:
Kết hợp ý định và hệ thống dựa trên ý định
Tối ưu hóa lồi trong giao dịch đa tài sản
DSL
Phân bổ lại MEV
Trì hoãn chiến tranh
Vấn đề mở rộng quy mô với một nhóm diễn viên nhưng cần được xây dựng cho nhiều máy trạng thái Rollup
Biểu thức ưu tiên
Về biểu thức tùy chọn, để tương tác với hợp đồng thông minh trong EVM, cần gửi lệnh gọi hợp đồng (tin nhắn) đến một chức năng cụ thể tại địa chỉ của mã được triển khai có chứa lệnh thực thi. Trong khi người dùng cung cấp đầu vào, họ có thể không có quyền kiểm soát đầu ra do trạng thái có thể xảy ra.
Ngược lại, các hệ thống thiết kế biểu thức tùy chọn (chẳng hạn như SUAVE và Anoma) chỉ yêu cầu người dùng ký các tùy chọn bằng một trái phiếu, được trả cho các nhà xây dựng và nhà sản xuất khối nếu các tùy chọn của người tìm kiếm được đáp ứng. Đối với logic tổ hợp phức tạp, chẳng hạn như chuỗi giao dịch cho người tìm kiếm và người xây dựng MEV, có thể cần triển khai các ngôn ngữ và máy ảo khác nhau. Đây là không gian thiết kế mới nhận được nhiều sự quan tâm trong thời gian gần đây, đặc biệt là kiến trúc Anoma. Ngoài ra, chúng tôi đánh giá cao bài viết ngắn này.
Xem bản gốc
Nội dung chỉ mang tính chất tham khảo, không phải là lời chào mời hay đề nghị. Không cung cấp tư vấn về đầu tư, thuế hoặc pháp lý. Xem Tuyên bố miễn trừ trách nhiệm để biết thêm thông tin về rủi ro.
Trình sắp xếp chia sẻ chi tiết 4D: Nguyên tắc làm việc, Lý thuyết tổng hợp và Tích hợp dọc
Tiêu đề gốc: "The Shared Sequencer"
Được viết bởi: MAVEN11
Biên soạn: Kxp, BlockBeats
Hãy tưởng tượng điều gì sẽ xảy ra nếu Rollup "sắp xuất xưởng" có thể đạt được mức độ chống kiểm duyệt cao, dễ triển khai, khả năng tương tác, tính hoàn thiện nhanh, tính sống động và dân chủ hóa của MEV. Điều đó có vẻ giống như một mục tiêu lớn, nhưng với sự ra đời của Shared Sequencer, nó có thể sớm trở thành hiện thực. Tuy nhiên, không phải tất cả các Rollup đều giống nhau, vì vậy chúng tôi phải xem xét cách phân phối phần thưởng và MEV trên mạng trình sắp xếp thứ tự được chia sẻ. Trong bài báo này, chúng tôi khám phá cách các mạng xếp hạng được chia sẻ được triển khai và các thuộc tính có thể đạt được.
Shared Sequencer Networks được giới thiệu chủ yếu bởi Alex Beckett, sau đó là Evan Forbes (và Radius) từ nhóm Celestia và Espresso, và một bài báo mới của Jon Charbonneau trình bày sâu hơn về chủ đề này. Josh, Jordan và nhóm Astria của họ đang xây dựng mạng trình tự chia sẻ sẵn sàng sản xuất đầu tiên. Mạng đặt hàng được chia sẻ của Astria là một chuỗi khối mô-đun tổng hợp và đặt hàng các giao dịch của Rollup mà không cần thực hiện chúng.
Trong thiết lập của Astria, bộ sắp xếp sẽ gửi các khối được sắp xếp theo thứ tự đến lớp DA và cả các nút Tổng số. Các bản tổng hợp nhận được các đảm bảo về tính hữu hạn mềm từ người đặt hàng và các đảm bảo về tính hữu hạn cứng từ lớp DA (sau khi các khối được hoàn thiện), và sau đó chúng sẽ thực hiện các giao dịch hợp lệ.
Mạng trình sắp xếp thứ tự được chia sẻ về cơ bản là một nhóm các trình sắp xếp tương thích với Rollup, như tên gọi của nó, nó có thể cung cấp dịch vụ cho các Rollup khác nhau. Điều này có nhiều sự đánh đổi và tính chất khác nhau, chúng tôi sẽ trình bày chi tiết sau. Đầu tiên, chúng ta phải mô tả các thuộc tính quan trọng nhất của bộ sắp xếp (hoặc tập hợp các bộ sắp xếp). Trong Rollup, yêu cầu chính đối với trình sắp xếp thứ tự hoặc nhóm trình sắp xếp thứ tự là khả năng chống kiểm duyệt hoặc tính sống động (một số trong số đó đến từ lớp cơ sở, cũng như tính bảo mật). Điều này có nghĩa là một giao dịch hợp lệ được gửi cho người đặt hàng phải được đưa vào chuỗi trong một khoảng thời gian hữu hạn (tham số thời gian chờ). Nhóm người đặt hàng được chia sẻ chỉ cần đảm bảo rằng các giao dịch được bao gồm trong các khối (tức là crLists).
Đáp ứng đồng thời khả năng chống kiểm duyệt và tính tức thời là khá khó khăn, như chúng tôi đã nêu trong Modular MEV Phần II. Trong một thuật toán đồng thuận như Tendermint, bạn có thể đảm bảo phục hồi sau một cuộc tấn công. Tuy nhiên, trong trường hợp bị tấn công, bạn sẽ mất ngay lập tức. Về cơ bản, việc yêu cầu tất cả những người đối chiếu khác ký vào một khối, thay vì chọn một masternode tùy chỉnh, có lẽ không phải là điều tối ưu. Mặc dù điều này cải thiện khả năng chống kiểm duyệt, nhưng nó phải trả giá bằng việc "tập trung hóa" và khai thác MEV cho một masternode duy nhất. Một cơ chế sắp xếp khác có sẵn có thể được so sánh với Duality's Multiplicity, đây là công cụ nhỏ của họ dành cho các mã không chính (hoặc bộ sắp xếp) để đưa các giao dịch khác vào các khối. Nhìn chung, khó đạt được khả năng chống kiểm duyệt và tính tức thời sau một cuộc tấn công trong hầu hết các giao thức đồng thuận.
Một thuật toán đồng thuận khác có thể được sử dụng là HotStuff 2, đảm bảo tính tức thời trong trường hợp bị tấn công.
Những gì nó cho phép là tránh chờ đợi độ trễ mạng tối đa (hết thời gian chờ) trong trường hợp kiểm duyệt hoặc không được ký để bầu một masternode mới. Lý do nó có thể là một thuật toán đồng thuận thú vị cho một nhóm người đặt hàng phi tập trung là vì nó giải quyết vấn đề tức thì trong sự đồng thuận mà không cần thêm một giai đoạn bổ sung. Nếu masternode biết mức khóa cao nhất (số lượng người tham gia đồng ý cao nhất về một đầu ra cụ thể) và có thể thuyết phục các bên trung thực, thì vấn đề sẽ được giải quyết. Nếu không, một masternode trung thực sau một thời điểm nhất định có thể chịu trách nhiệm đẩy, hỗ trợ masternode tiếp theo. Ví dụ: nút Hotstuff không cần xác nhận thông báo chuyển đổi trước khi thông báo cho chủ mới, nhưng có thể trực tiếp chuyển sang chế độ xem mới và thông báo cho chủ mới.
Sự khác biệt với Tendermint là mặc dù cả hai đều là hai pha (Hotstuff1 có ba, Hotstuff2 có hai), Tendermint có giao tiếp tuyến tính nhưng không phản hồi, trong khi Hotstuff2 có phản ứng. Nếu có một chuỗi các masternode trung thực, thì giao thức sẽ phản hồi tích cực, vì tất cả các bước ngoại trừ đề xuất của masternode đầu tiên đều phụ thuộc vào việc thu được lượng thông tin từ bước trước đó. Trong cài đặt trình đặt hàng được chia sẻ, điều này cho phép giao thức đạt được tính tức thời tốt hơn mà không cần quay trở lại lớp dưới cùng, đồng thời không loại bỏ khả năng này.
Xây dựng nhóm phân loại dùng chung
Một nhóm người đặt hàng được phép gửi giao dịch đến lớp thanh toán (lớp chứa Rollup). Bạn có thể tham gia nhóm đối chiếu này, miễn là đáp ứng một số yêu cầu nhất định và chưa đạt đến số lượng nhà sản xuất khối yêu cầu. Điều này tối ưu hóa độ trễ, thông lượng, v.v. Các yêu cầu này tương tự như yêu cầu để trở thành người xác thực chuỗi khối. Ví dụ: bạn phải đáp ứng các yêu cầu nhất định về phần cứng, cũng như khoản tiền gửi ban đầu, đặc biệt nếu bạn muốn cung cấp sự chắc chắn về điều kiện tài chính.
Nhóm người đặt hàng được chia sẻ (hoặc bất kỳ nhóm người đặt hàng phi tập trung nào) bao gồm một số thành phần hoạt động cùng nhau để đảm bảo xử lý giao dịch chính xác, bao gồm:
Cung cấp JSON-RPC cho mỗi Tổng số để gửi giao dịch (dành cho người vận hành nút không đầy đủ) tới nút dưới dạng nhóm bộ nhớ, sau đó xây dựng và sắp xếp. Trong mempool, cần có một số cơ chế để xác định hàng đợi, cũng như quy trình lựa chọn giao dịch, để đảm bảo việc xây dựng các khối hiệu quả.
Thuật toán xây dựng khối/lô, chịu trách nhiệm xử lý các giao dịch trong hàng đợi và chuyển đổi chúng thành khối hoặc lô. Bước này cũng có thể bao gồm nén để giảm kích thước khối kết quả (được gọi là nén dữ liệu). Như đã đề cập, điều này nên tách biệt với Người đề xuất, về cơ bản là PBS. Dữ liệu có thể được nén theo nhiều cách khác nhau, ví dụ:
Bỏ qua các trường dữ liệu: Các trường dữ liệu không bắt buộc đối với các giao dịch đơn giản nhưng lại cần thiết đối với các giao dịch phức tạp hơn.
Thay thế chữ ký riêng lẻ bằng chữ ký tổng hợp BLS: Chữ ký là thành phần lớn nhất của giao dịch Ethereum. Thay vì lưu trữ từng chữ ký, bạn có thể lưu trữ chữ ký tổng hợp BLS cho một số lượng giao dịch cụ thể. Bạn cũng có thể kiểm tra chữ ký tổng hợp BLS đối với bộ thông báo và bộ người gửi để đảm bảo tính hợp lệ của nó.
Sử dụng trường Từ làm chỉ mục: Giống như trường Đến, bạn có thể sử dụng trường Từ làm chỉ mục để ánh xạ.
Một khái niệm thú vị về thiết kế "mô-đun" là bạn có thể thực hiện các điều chỉnh và đánh đổi nếu cần để làm cho nó hoạt động cho Tổng số của bạn.
Thuật toán xoay tổng thể cho các bộ đặt hàng được chia sẻ (không cần sự đồng thuận trong trường hợp bầu chọn tổng thể duy nhất). Bạn có thể chọn chỉ đặt thuật toán xoay vòng nút chính hoặc thực hiện lộ trình tạo khối đa đồng thời do Duality đề xuất.
Các thuật toán đồng thuận, chẳng hạn như Tendermint hoặc Hotstuff2 đã nói ở trên, có thể đảm bảo rằng các nút Tổng số đồng ý với trình tự do sổ cái đề xuất.
Ứng dụng khách RPC để gửi các khối/đợt lên lớp đồng thuận DA+ cơ bản để các khối/đợt có thể được thêm vào lớp DA một cách an toàn, đảm bảo tính hữu hạn "cuối cùng" và làm cho tất cả dữ liệu giao dịch có sẵn trên chuỗi.
Tách biệt vai trò của người xây dựng và nhà sản xuất khối để đảm bảo tính công bằng và nhất quán, đồng thời tránh hành vi trộm cắp MEV. Cũng loại bỏ sắp xếp được thực hiện, điều quan trọng để tối ưu hóa hiệu quả, giảm PGA và tăng CR.
*Các nút tổng số nhận các khối được sắp xếp theo thứ tự từ bộ sắp xếp để gửi mềm và nhận các khối lớp DA đã đặt hàng để gửi cứng. *
Calldata lần đầu tiên được xuất bản lên mạng cơ sở, nơi chạy sự đồng thuận để đảm bảo người dùng và các giao dịch Rollup. Sau đó, nút Tổng số thực thi giao dịch và gửi chức năng chuyển đổi trạng thái sang chuỗi Tổng số chính tắc. Một mạng lưới những người đặt hàng được chia sẻ cung cấp cho Rollup tính năng tức thời và khả năng chống kiểm duyệt. Các bản tổng hợp duy trì chủ quyền của chúng vì tất cả dữ liệu giao dịch được lưu trữ trong lớp cơ sở, cho phép chúng rẽ nhánh từ trình đặt hàng được chia sẻ bất cứ lúc nào. Gốc trạng thái của hàm chuyển đổi trạng thái Tổng số (STF) được tính toán từ gốc giao dịch (đầu vào) được gửi từ trình đặt hàng dùng chung đến lớp DA. Trong Celestia, gốc trạng thái được tạo khi dữ liệu được thêm vào chuỗi và đạt được sự đồng thuận. Vì bạn đã có gốc giao dịch (và tất cả dữ liệu có sẵn), Celestia có thể cung cấp cho các ứng dụng khách nhẹ (các nút Rollup chạy trên Celestia) với một bằng chứng nhỏ về việc đưa vào.
Để cung cấp trải nghiệm người dùng mà người dùng mong đợi, các nút Tổng số nhận các khối được sắp xếp theo thứ tự (các khối này cũng được gửi đến lớp DA). Điều này có thể cung cấp cho Rollup các đảm bảo xác định mềm - đảm bảo rằng các khối cuối cùng sẽ được sắp xếp theo thứ tự trên lớp DA, tại đó các nút Rollup thực hiện các giao dịch và cung cấp các gốc trạng thái mới.
Tạo khối và vị trí
Để xác định thời điểm tạo khối, trình sắp xếp chuỗi cần đặt vị trí. Trình sắp xếp thứ tự phải gửi các lô theo các khoảng thời gian cố định (thường là X giây), trong đó X là thời gian của khe. Điều này đảm bảo rằng các giao dịch được xử lý kịp thời và hiệu quả, bởi vì nếu không thì masternode cho một vị trí cụ thể sẽ hết thời gian chờ và mất phần thưởng ký kết (và phần thưởng thực thi). Ví dụ: thời gian tạo khối của Celestia (theo thông số kỹ thuật của GitHub) là khoảng 15 giây. Vì điều này đã được biết, nên chúng tôi có thể đưa ra một số giả định về số lượng "khe/khối" mà chúng tôi có thể có từ tập hợp các bộ điều phối dùng chung cho lớp DA và các nút Tổng số được tải vào các khối đã hoàn thiện. Về vấn đề này, chúng ta có thể tham khảo Tendermint hoặc Hotstuff2 đã được tối ưu hóa.
Trong cùng một vị trí, chúng tôi có thể gửi nhiều lô giao dịch, miễn là thiết kế bao gồm các cơ chế cho các nút đầy đủ Rollup để xử lý chúng một cách hiệu quả thành một khối duy nhất (trong khoảng thời gian đó và các thông số hết thời gian chờ). Điều này giúp tối ưu hóa hơn nữa việc tạo khối và đảm bảo các giao dịch được xử lý nhanh chóng. Ngoài ra, các vị trí cũng có thể được sử dụng để tạo thuận lợi cho việc bầu chọn các nút chính của bộ sắp xếp. Ví dụ: bạn có thể chọn ngẫu nhiên một nút chính của vị trí từ nhóm đặt cược dựa trên trọng số đặt cược. Làm điều này theo cách bảo vệ tính bảo mật và sử dụng một số thứ như bầu chọn thủ lĩnh bí mật để giảm thiểu kiểm duyệt là lựa chọn tốt nhất; hoặc thậm chí là thiết lập công nghệ trình xác thực phân tán, chẳng hạn như các giải pháp như Obol/SSV. Độ trễ và thời gian khe có tác động lớn đến việc gửi khối và xây dựng giao thức. Vì vậy, chúng ta cần xem xét điều này ảnh hưởng đến hệ thống như thế nào. Bloxroute có một số điểm nghiên cứu và dữ liệu tuyệt vời về Ethereum nói riêng. Trong MEV-Boost, các nhà sản xuất khối tham gia (trình xác thực hoặc trình sắp xếp thứ tự trong trường hợp Rollup) yêu cầu GetHeader từ rơle. Điều này mang lại cho họ giá trị giá thầu khối, là giá trị của một khối cụ thể. Đây có thể là khối giá trị cao nhất nhận được mỗi lần. Đối với mỗi vùng, trình xác nhận thường yêu cầu GetHeader khoảng 400 mili giây sau khi vùng bắt đầu - do số lượng lớn trình xác nhận, rơle thường cần gửi nhiều yêu cầu. Đây cũng là điều có thể xảy ra với các nhóm máy phân loại dùng chung lớn. Điều này có nghĩa là bạn cần có cơ sở hạ tầng để tạo thuận lợi cho quá trình này.
Rơle cũng giúp tạo điều kiện thuận lợi cho việc tách người xây dựng và nhà sản xuất khối, đồng thời xác minh rằng những người xây dựng đã xây dựng đúng khối. Họ cũng kiểm tra xem các khoản phí có được thanh toán chính xác hay không và đóng vai trò bảo vệ DoS. Ngoài ra, về cơ bản, họ là người giám sát các khối và xử lý việc đăng ký trình xác nhận. Điều này đặc biệt quan trọng trong kiến trúc của trình sắp xếp thứ tự không giới hạn, vì bạn cần theo dõi xem ai đã tham gia và ai không (ví dụ: lớp đồng bộ hóa đã thảo luận trước đó).
Về thời gian chặn (tức là các khối do người tạo gửi), chúng thường xảy ra trong khoảng 200 mili giây. Hầu hết chúng bắt đầu chạy trước/sau khoảng 200 mili giây, mặc dù giống như GetHeader, có sự khác biệt đáng kể. Nếu trình xây dựng gửi khối tới nhiều rơle, nó sẽ gây ra độ trễ đáng kể. Bloxroute cũng xem xét điều gì sẽ xảy ra khi các khối được gửi đến nhiều rơle. Như bạn có thể mong đợi, độ trễ cho việc truyền khối đến nhiều rơle hơn sẽ lớn hơn. Trung bình, lần chuyển tiếp thứ hai mất 99 mili giây để sử dụng khối, lần thứ ba là 122 mili giây và lần thứ tư là 342 mili giây.
Những gì chúng ta có thể đã học được trong vài tháng qua là RPC rất quan trọng đối với chuỗi khối. Đó là một gánh nặng lớn nếu không có cơ sở hạ tầng phù hợp và có một tùy chọn RPC phù hợp cũng rất quan trọng. Trong trường hợp này, RPC rất quan trọng đối với các nhà đầu tư bán lẻ gửi giao dịch của họ tới RPC (và bộ nhớ chung công khai). Bloxroute đã chạy một thử nghiệm nhỏ gồm 20 giao dịch được gửi đến các RPC khác nhau và đo thời gian cần thiết để mỗi giao dịch được đưa vào một khối.
Nguồn: Phòng thí nghiệm Bloxroute
Thật thú vị, một số RPC không bao gồm các giao dịch cho đến một số khối sau đó, tùy thuộc vào người xây dựng nào giành chiến thắng trong khối tiếp theo. Nếu RPC gửi giao dịch đến nhiều nhà xây dựng hơn, thì xác suất đưa vào nhanh sẽ cao hơn. Mặc dù những người khởi tạo giao dịch có thể tận dụng vị trí duy nhất của họ theo thứ tự dòng chảy để nhắm mục tiêu những người xây dựng cụ thể hoặc thậm chí xây dựng các khối của riêng họ.
Hiệu suất của chúng cũng rất thú vị trong số liệu thống kê hiệu suất chuyển tiếp của Ethereum. Điều này giúp chúng tôi hiểu sâu hơn về cách thức hoạt động của PBS trong một thế giới nhiều trình xác thực/trình tạo/chuyển tiếp, đó là điều chúng tôi hy vọng đạt được với bản nâng cấp Tổng hợp. Metrika có một số thống kê tuyệt vời về điều này và tất cả các điểm dữ liệu là do chúng.
Điều quan trọng cần lưu ý là bỏ lỡ giá thầu xảy ra khi người chuyển tiếp dự kiến sẽ đặt giá thầu, nhưng không đặt giá thầu. Kỳ vọng mục tiêu đến từ trình xác thực đã đăng ký với một chuyển tiếp cụ thể cho bất kỳ vị trí nhất định nào. Bản thân đây không phải là lỗi chuyển tiếp, cũng như không được xử lý theo cách đó ở cấp độ giao thức.
Nguồn: app.metrika.co
Nếu xảy ra lỗi (chẳng hạn như rơle phục vụ khối không hợp lệ) và nó phải chịu trách nhiệm, thì lỗi đó sẽ được tính là lỗi. Những điều này thường không xảy ra thường xuyên và chủ yếu là do lỗi tùy chọn đăng ký (tức là giới hạn gas hoặc phí không khớp với đăng ký cho một trình xác thực cụ thể). Thậm chí hiếm hơn là các lỗi của lớp đồng thuận, không phù hợp với các quy tắc của lớp đồng thuận Ethereum, chẳng hạn như các vị trí không chính xác hoặc các hàm băm gốc không được căn chỉnh với khối trước đó, v.v.
Về độ trễ (chẳng hạn như thời gian cần thiết để trình xác thực nhận tiêu đề khối do trình tạo tạo), dữ liệu rất nhất quán. Mặc dù có một số ngoại lệ, chẳng hạn như chuyển tiếp được yêu cầu ở một vị trí địa lý khác với trình xác thực đã chọn.
Nguồn: app.metrika.co
Về các nhà xây dựng, tổng số nhà xây dựng trên MEV-boost là khoảng 84, với ba nhà xây dựng hàng đầu xây dựng khoảng 65% số khối đã xây dựng. Mặc dù điều này có thể hơi gây hiểu nhầm vì đây cũng là những trình xây dựng hoạt động lâu nhất. Kết quả cũng tương tự nếu giảm khung thời gian. Số lượng người xây dựng đang hoạt động thực tế thấp hơn nhiều, 35 người trong 30 ngày qua và 24 người trong tuần qua. Cạnh tranh rất khốc liệt và thường thì người xây dựng mạnh nhất sẽ thắng. Một luồng đơn đặt hàng độc quyền có thể đã tồn tại, điều này sẽ chỉ làm trầm trọng thêm tình hình. Chúng tôi hy vọng việc phân phối các nhà xây dựng sẽ vẫn tương đối tập trung (vì đây là cuộc đua giành luồng đơn đặt hàng tối ưu và tối ưu hóa phần cứng) trừ khi chúng tôi thực hiện những thay đổi lớn đối với thiết lập. Mặc dù không phải là một vấn đề cơ bản, nhưng nó vẫn là một lực lượng tập trung trong ngăn xếp và chúng tôi rất muốn nghe các ý tưởng về cách thách thức hiện trạng ở đây. Nếu bạn muốn tìm hiểu sâu hơn về vấn đề (nghiêm trọng) này, chúng tôi thực sự khuyên bạn nên đọc các bài viết của Quintus về luồng đặt hàng, đấu giá và tập trung hóa.
Đối với vai trò Trình tạo trong ngăn xếp mô-đun trong tương lai, chúng tôi khá chắc chắn (ít nhất là trong thiết lập SDK Cosmos), chúng ta sẽ thấy thiết lập Mô-đun Trình tạo giống Skip/Mekatek. Một giải pháp khác là thiết lập loại SUAVE, chẳng hạn như chuỗi trình tạo toàn cầu cụ thể cung cấp dịch vụ xây dựng khối và ưu tiên giá thầu cho bất kỳ số lượng chuỗi nào để đảm bảo PBS. Chúng ta sẽ khám phá giải pháp này sâu hơn sau và cung cấp một số câu trả lời cho các câu hỏi không được đề cập ở đây.
Về rơle, chúng tôi thực sự khuyên bạn nên đọc một bài viết của Ankit Chiplunkar của Frontier Research và Mike Neuder của Ethereum Foundation có tên là rơle lạc quan và tìm chúng ở đâu. Bài đăng này trình bày chi tiết cách thức hoạt động của rơle trong MEV-boost, sự đánh đổi hiện tại và chi phí vận hành của chúng cũng như một số thay đổi có thể làm tăng hiệu quả. Thật thú vị, chạy một rơle trong MEV-Boost hiện có giá khoảng 100.000 USD/năm theo ước tính của Flashbot.
Xác định
Trước khi chúng ta nói về tính quyết định của các chuỗi khối mô-đun (như hiện tại), chúng ta hãy xem bài viết “MEV mô-đun” trước đây của chúng tôi. Lưu ý rằng đây không phải là chế độ xem "chính thức" hay toàn diện về thời hạn cuối cùng, nhưng chúng tôi tin rằng nó thể hiện chính xác nhất các sắc thái của thời hạn cuối cùng của Tổng số để dễ hiểu.
Đang chờ xử lý_Bật_L2: Trình đặt hàng tổng số thể hiện một cam kết mềm rằng giao dịch của người dùng cuối cùng sẽ được thực hiện và hoàn tất trên lớp bảo mật cơ sở của nó.
Finality_On_L2: Trình sắp xếp thứ tự đã cam kết với chức năng chuyển đổi trạng thái của Rollup và khối đã được thêm vào chuỗi chính tắc của Rollup.
Đang chờ xử lý_Bật_L1: Chức năng chuyển đổi đầu vào hoặc đầu ra/trạng thái của giao dịch đã được xuất bản lên L1, nhưng bằng chứng hợp lệ vẫn chưa được đưa ra hoặc thời gian phân xử chưa kết thúc - điều này yêu cầu Ethereum trong hai kỷ nguyên liên tiếp. Đây là thời điểm mà hầu hết các Bản tổng hợp lạc quan nói rằng chúng đã đạt đến điểm cuối cùng, nhưng vẫn có khoảng thời gian thử thách 7 ngày tùy ý tại thời điểm này theo cầu chuỗi chéo thông số kỹ thuật.
Finality_On_L1: Đối với Bản tổng hợp lạc quan, thời gian phân xử trọng tài đã kết thúc hoặc bằng chứng về tính hợp lệ đã được công bố và xác minh đã được xác nhận bởi đa số trong hai kỷ nguyên liên tiếp.
Bây giờ, trong Tổng hợp sắp xếp được chia sẻ có chủ quyền, điều này có vẻ hơi khác, hãy thử giải thích nó bằng sơ đồ:
Trong trường hợp này, về mặt lý thuyết, chúng ta có thể nhận được tính xác định trên L1 trước L2, v.v.? Vâng, trong trường hợp này, L2 có chủ quyền sau tất cả. Điều này giả định rằng không có bằng chứng gian lận và thời gian thử thách hoặc bạn đang sử dụng bằng chứng hợp lệ.
Vì vậy, làm thế nào để chúng ta đạt được những mức độ cuối cùng? Khối cuối cùng đạt được khi một khối được thêm vào chuỗi chính tắc, khối này không thể rút được. Tuy nhiên, có một số sắc thái ở đây, tùy thuộc vào các nút đầy đủ hoặc nhẹ. Trong trường hợp khối có thứ tự, nó có tính quyết định khi nó được đưa vào khối lớp DA. Các khối (có gốc trạng thái) được thực thi bởi các nút/trình xác nhận đầy đủ Rollup, điều này mang lại cho chúng sự đảm bảo về gốc trạng thái hợp lệ bắt nguồn từ các khối được sắp xếp theo thứ tự của lớp cơ sở. Đối với tính xác định ngoài các nút đầy đủ (chẳng hạn như đối với ứng dụng khách nhẹ hoặc cầu nối chuỗi chéo), bạn phải chắc chắn về tính hợp lệ của gốc trạng thái này. Tại đây, bạn có thể sử dụng một trong các phương pháp được mô tả bên dưới. Ngoài ra, một cách tiếp cận khác là làm cho những người xác thực chịu trách nhiệm về bằng chứng chính xác của gốc trạng thái (lộ trình Lạc quan), thông qua một trái phiếu và bằng chứng gian lận sau đó. Ngoài ra, bạn có thể cung cấp bằng chứng về tính hợp lệ (ZK).
Các cách khác nhau để đạt được tính hữu hạn của khối:
Thông qua Proof of Work (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) và các phương pháp xác suất khác.
Một phương pháp có thể chứng minh được bằng cách có đủ thành viên ủy ban ký kết các khối. (ví dụ: Tendermint 2/3, Hotshot2 hoặc các loại PBFT khác)
Phụ thuộc vào thứ tự của các giao dịch/khối trên lớp DA và các quy tắc của nó, cụ thể là quy tắc lựa chọn chuỗi và ngã ba chuẩn.
Chúng ta có thể đạt được các loại tài chính khác nhau thông qua các cơ chế khác nhau.
Một loại tài chính cuối cùng là "tài chính mềm" (chẳng hạn như đang chờ xử lý), có thể đạt được bằng một cuộc bầu cử lãnh đạo duy nhất. Trong trường hợp này, mỗi vị trí sẽ chỉ có một hoặc không có khối nào (được cam kết hay không) và lớp đồng bộ hóa có thể đảm nhận chuỗi giao dịch trong các khối này một cách an toàn.
Một loại tài chính cuối cùng khác là "tài chính có thể chứng minh được", mang lại sự đảm bảo mạnh mẽ hơn (về cơ bản là cuối cùng) so với tài chính mềm. Để đạt được mục đích cuối cùng có thể chứng minh được, phần lớn những người đặt hàng phải ký vào một khối, qua đó thể hiện sự đồng ý của họ rằng khối đó là hợp quy. Mặc dù cách tiếp cận này là tốt, nhưng nó có thể không cần thiết nếu một cuộc bầu cử lãnh đạo duy nhất đã được thực hiện, vì về cơ bản nó đảm bảo trật tự khối. Rõ ràng, điều này phụ thuộc vào thuật toán bầu chọn nhà lãnh đạo cụ thể đang được triển khai. Ví dụ: tỷ lệ thực hiện là 51%, tỷ lệ thực hiện là 66% hay do một nhà lãnh đạo duy nhất (tốt nhất là bầu chọn ngẫu nhiên (VRF) và bí mật). Nếu bạn muốn tìm hiểu thêm về thuyết tất định trong Ethereum, hãy đọc bài viết này mà chúng tôi rất khuyến khích và bài viết chúng tôi sẽ đề xuất sau cho các bộ sắp xếp không giới hạn.
được cấp phép, bán giấy phép hoặc không được phép
Để ngăn chặn các cuộc tấn công DoS tiềm ẩn, các rào cản kinh tế phải được thiết lập để tham gia nhóm người đặt hàng và gửi giao dịch đến lớp người đặt hàng. Trong các nhóm có giới hạn (số lượng máy sắp xếp hữu hạn) và không giới hạn (số lượng máy sắp xếp không giới hạn), các rào cản kinh tế phải được đặt ra để gửi các lô đến lớp DA nhằm ngăn chặn lớp đồng bộ hóa (truyền khối giữa các máy phân loại) bị chậm lại hoặc bị tấn công DDoS . Tuy nhiên, bản thân lớp DA cũng cung cấp một số biện pháp bảo vệ, bởi vì việc gửi dữ liệu tới lớp DA cần phải trả phí (da_fee). Khoản tiền đặt cọc bảo mật cần thiết để tham gia nhóm không giới hạn sẽ bao gồm mọi chi phí bổ sung cần thiết để ngăn lớp đồng bộ hóa bị spam. Mặt khác, mức ký quỹ cần thiết để tham gia một nhóm giới hạn sẽ phụ thuộc vào nhu cầu (được cân bằng từ góc độ chi phí/doanh thu).
Đối với một bộ sắp xếp không giới hạn, chúng tôi không thể đạt được kết quả cuối cùng có thể chứng minh được ở lớp sắp xếp (vì chúng tôi không bao giờ biết chính xác có bao nhiêu cử tri/người ký tên đang hoạt động). Mặt khác, trong một nhóm có giới hạn gồm những người đồng hành, tính hữu hạn có thể chứng minh được có thể đạt được bằng cách đa số những người đồng hành ký các khối. Điều này yêu cầu lớp đồng bộ hóa phải biết về lớp trình sắp xếp thứ tự và có bao nhiêu trình sắp xếp thứ tự đang hoạt động tại bất kỳ thời điểm nào, đây là một số chi phí bổ sung. Trong một tập hợp các trình sắp xếp có giới hạn (ví dụ: tối đa 100), bạn cũng có thể tối ưu hóa số lượng trình sắp xếp để cải thiện "hiệu suất", mặc dù phải trả giá bằng khả năng phân cấp và chống kiểm duyệt. Tầm quan trọng của các nhóm bị ràng buộc và đảm bảo kinh tế để cung cấp sự chắc chắn có thể chứng minh "nhanh chóng" cũng mang tính quyết định.
Các loại bộ sắp xếp không giới hạn và bộ sắp xếp có giới hạn cũng được phản ánh trong các chuỗi khối truyền thống.Ví dụ: PoS (Casper+LMD-GHOST) trong Ethereum sử dụng loại không giới hạn, trong khi chuỗi dựa trên Cosmos SDK/Tendermint sử dụng loại có giới hạn. Một suy nghĩ thú vị là, liệu chúng ta có mong đợi thấy tính kinh tế giống như bằng chứng cổ phần và các lựa chọn từ cộng đồng xung quanh những người đặt hàng được chia sẻ không? Về vấn đề này, chúng tôi đã thấy một phong trào hướng tới tập trung hóa một số thực thể (vì vậy việc không giới hạn không thực sự quan trọng nếu bạn đã có một số nhà cung cấp/nhóm bằng chứng cổ phần lớn). Mặc dù họ "che giấu" việc tập trung hóa, nhưng sau tất cả, bạn vẫn có thể khai thác nếu muốn. Từ quan điểm hệ tư tưởng, các lựa chọn hầu như luôn luôn không có giới hạn - nhưng hãy nhớ rằng các nguyên tắc kinh tế dù sao cũng làm cho chúng rất giống nhau. Bất kể người tham gia là ai, tính kinh tế của số tiền bạn trả vẫn phải như nhau, chẳng hạn như chi phí DA và chi phí phần cứng (mặc dù điều này có thể giảm đi do số lượng bằng chứng cổ phần mà bạn phân bổ và trải nghiệm, cũng như hiệu quả vận hành cơ sở hạ tầng). Ngay cả trong thế giới PoS có giới hạn, chúng tôi đã chứng kiến một nhóm các nhà cung cấp cơ sở hạ tầng trở thành những người xác nhận lớn nhất và phổ biến nhất trên hầu hết các chuỗi. Trên hầu hết các chuỗi Cosmos, sự phụ thuộc giữa các trình xác nhận đã rất lớn và điều này chắc chắn gây nguy hiểm cho khả năng chống phân cấp và kiểm duyệt của các chuỗi nói trên. Tuy nhiên, một thực tế rất khác là bất kỳ nhà đầu tư bán lẻ nào cũng có thể đặt cược bất kỳ số tiền nào với bất kỳ trình xác nhận nào mà họ chọn. Thật không may, điều này thường được xếp lên đầu danh sách và cuộc sống vẫn tiếp diễn. Chúng tôi hỏi lại: chúng ta có mong đợi một mô hình kinh tế tương tự trong một thế giới mô-đun không? Một mong muốn không phải như vậy, nhưng với chuyên môn hóa, bạn thường cần người phù hợp nhất - và họ có xu hướng trở thành nhà cung cấp bằng chứng cổ phần chuyên nghiệp. Chúng tôi cũng sẽ đề cập đến những vấn đề kinh tế này trong một chương riêng sau.
Tuy nhiên, một điều quan trọng cần nhớ trong tất cả những vấn đề này là điều quan trọng nhất là xác thực người dùng cuối, tính năng này có sẵn cho bất kỳ ai, bất kể họ ở đâu (ngay cả ở Giza) thông qua ứng dụng khách nhẹ và kim tự tháp DAS).
Nguồn: @JosephALChami
Dưới đây là những đánh đổi và lợi thế của bộ sắp xếp có giới hạn và không giới hạn:
Bộ sắp xếp không giới hạn:
*Bất kỳ ai có đủ trái phiếu/đặt cược đều có thể trở thành người phân loại = mức độ phân quyền cao
Bộ sắp xếp có giới hạn:
Đây là một trong những giải pháp của Ethereum cho chủ nghĩa quyết định một vị trí và có một ủy ban siêu "đa số".
Có không gian thiết kế đáng kể về cách giám sát các bộ sắp xếp này và các thành viên mới được thêm hoặc xóa. Ví dụ: điều này sẽ đạt được thông qua Quản trị Tokenholder (còn nhiều Token và Rollup khác nhau bằng cách sử dụng các bộ sưu tập thì sao?). Điều này có nghĩa là có thể thực hiện các thay đổi báo hiệu ngoài chuỗi thông qua sự đồng thuận xã hội (ví dụ: lấy Ethereum làm ví dụ). Tuy nhiên, hãy nhớ rằng sự đồng thuận trên chuỗi thực tế đã được thiết lập rõ ràng và các hình phạt cho việc vi phạm các quy tắc đồng thuận đã tồn tại.
Cơ chế kinh tế cho máy phân loại dùng chung
Tính kinh tế của việc chia sẻ một mạng lưới các trình tự giải mã cho phép một số tùy chọn thú vị. Như chúng ta đã thảo luận trước đó, trình xác thực trong mạng đặt hàng được chia sẻ không khác lắm so với trình xác nhận L1 điển hình. Mạng mà nó tham gia đơn giản là được tối ưu hóa hơn để thực hiện một nhiệm vụ, đó là nhận các ý định (trước đây là PBS), và do đó đề xuất và đặt hàng các giao dịch. Cũng giống như trình xác thực "thông thường", có các thành phần doanh thu và chi phí. Ở cả hai phía của phương trình, có rất nhiều tính linh hoạt trong các mạng mà trình xác thực tham gia, tương tự như L1 thông thường.
Doanh thu đến từ người dùng hoặc Tổng số mà cuối cùng họ muốn tương tác với việc trả một khoản phí nhất định để sử dụng trình sắp xếp thứ tự được chia sẻ. Phí này có thể là tỷ lệ phần trăm MEV được rút (việc nhập số có thể khó ước tính), chuyển giá trị chuỗi chéo, Gas hoặc phí cố định cho mỗi tương tác. Giải pháp doanh thu phù hợp nhất có thể là trả giá trị thấp hơn cho người đặt hàng được chia sẻ so với giá trị bổ sung thu được thông qua người đặt hàng được chia sẻ Tổng số, cùng với các lợi ích về bảo mật và thanh khoản được chia sẻ. Nhưng nhược điểm của điều này là rất khó để định lượng lợi ích phi tập trung của một phần khác của hệ thống. Tuy nhiên, khi mạng đặt hàng được chia sẻ phát triển thành hệ sinh thái riêng, khả năng trích phí có thể tăng lên. Điều này phần lớn là do khả năng tổng hợp vốn có của họ một cách dễ dàng, với quy mô kinh tế nhất định. Khi có nhiều Bản tổng hợp và ứng dụng tham gia vào mạng, ngày càng có nhiều MEV miền chéo có thể trích xuất.
Về chi phí, các mạng đặt hàng được chia sẻ cũng có các lựa chọn cạnh tranh. Họ có thể dễ dàng tài trợ cho việc sử dụng mạng của mình bằng cách tài trợ chi phí xuất bản trên lớp DA hoặc thậm chí là chi phí tương tác với các ứng dụng trên Rollup. Điều này tương tự như chiến lược được sử dụng bởi các công ty Web 2.0, trong đó bạn chịu lỗ ban đầu khi thu hút người dùng (hoặc tổng số), hy vọng rằng doanh thu dài hạn của họ sẽ lớn hơn phí. Một phương pháp mới lạ hơn hoặc có nguồn gốc từ tiền điện tử là cho phép Rollup thanh toán phí DA bằng Mã thông báo gốc của nó. Ở đây, lớp sắp xếp được chia sẻ chịu rủi ro về giá giữa Mã thông báo cần thiết để xuất bản dữ liệu trên lớp DA và Mã thông báo gốc của Rollup. Về bản chất, nó vẫn là chi phí trả trước của bộ sắp xếp được chia sẻ, nhưng nó tạo ra sự nhất quán của hệ sinh thái bằng cách lấy Mã thông báo của "nhà cung cấp" (tức là Rollup). Điều này hơi giống với việc xây dựng nhà kho mà chúng tôi đã giải thích trong bài viết về AppChain và các dạng DA khác nhau có thể được sử dụng để giảm chi phí. Các tầng DA khác nhau sẽ đưa ra mức giá khác nhau do việc sử dụng, khả năng xác minh dễ dàng của người dùng thông qua ứng dụng khách nhẹ hoặc đơn giản là đưa ra các lựa chọn kích thước khối khác nhau. Cuối cùng, người đặt hàng được chia sẻ cũng có thể giao dịch hàng loạt trước khi xuất bản lên lớp DA. Trong trường hợp của ZKR, điều này có thể giảm chi phí giao dịch thông qua một số số dư giao dịch nhất định và đối với ORU, bạn có thể thực hiện các tối ưu hóa Gas xử lý hàng loạt khác nhau mà chúng tôi hiện có thể thấy trên các Bản tổng hợp khác nhau. Điều này sẽ làm giảm lượng dữ liệu cần được xuất bản lên lớp DA, do đó giảm chi phí của mạng trình sắp xếp thứ tự được chia sẻ và tăng khả năng sinh lời của toàn bộ mạng. Điều này sẽ phải trả giá bằng việc hạn chế khả năng tương tác và thay đổi thời gian tồn tại của khối (tính xác định trên L1 như đã đề cập trước đó).
Nhìn chung, tính kinh tế của việc chia sẻ một mạng lưới các trình tự giải mã cho phép một số chiến lược khởi động và thử nghiệm thú vị. Chúng tôi ước tính rằng sự khác biệt chính sẽ là quy mô của hệ sinh thái, vì vậy số lượng MEV giữa các miền lớn hơn khía cạnh chi phí. Chúng tôi cũng khuyên bạn nên xem bài đăng trên blog của nhóm Espresso về những người đặt hàng được chia sẻ, chúng cũng đề cập đến sự cân bằng kinh tế (và mặt tích cực) của các loại mạng này. Để chỉ ra lý do tại sao Rollup được thúc đẩy để tận dụng các bộ sắp xếp được chia sẻ (bên cạnh tính kinh tế), chúng ta có thể xem xét nó từ góc độ lý thuyết tổng hợp.
Lý thuyết tổng hợp và bộ sắp xếp chia sẻ
Một cách khác để mô tả các thuộc tính do các bộ sắp xếp dùng chung mang lại là thông qua lăng kính của lý thuyết tập hợp. Lý thuyết tổng hợp đề cập đến khái niệm về cách một nền tảng hoặc trình tổng hợp tích hợp các nền tảng khác và người dùng của chúng theo cách có hệ thống để thu hút sự chú ý đáng kể của người dùng. Về cơ bản, bạn đang chuyển trò chơi từ việc phân bổ tài nguyên khan hiếm (ví dụ: không gian khối) sang nhu cầu kiểm soát nguồn tài nguyên dồi dào (một lần nữa, không gian khối có ý nghĩa trong ví dụ này). Lý thuyết tổng hợp thực sự tổng hợp các nhà cung cấp và sản phẩm (tức là Rollup và Blockspace) thành một trải nghiệm siêu người dùng để phục vụ cơ sở người dùng tổng hợp. Khi hiệu ứng mạng của các công cụ tổng hợp này phát triển, mối quan hệ này ngày càng trở nên độc quyền. Khi điều này xảy ra, trải nghiệm người dùng trở thành điểm khác biệt chính giữa các thiết lập tương tự. Nếu có các ưu đãi để thu hút người dùng mới (chẳng hạn như trải nghiệm người dùng tốt và khả năng tương tác tốt hơn), Rollup sẽ không chuyển sang mạng riêng hoặc thiết lập khác - vì hiệu ứng mạng thúc đẩy các nhà cung cấp mới và người dùng mới tham gia. Điều này tạo ra hiệu ứng bánh đà, không chỉ từ góc độ nhà cung cấp và người dùng, mà còn từ góc độ chống kiểm duyệt tổng hợp.
Nguồn: Aggregation Theory 2015, Ben Thompson
Trong lĩnh vực sắp xếp được chia sẻ, Lý thuyết tổng hợp có thể được coi là "sự kết hợp" và liên kết của nhiều Bản tổng hợp khác nhau, tất cả đều sử dụng các chiều dọc tương tự của ngăn xếp - trao quyền cho chính họ và những người khác trong khi cho phép người dùng có được trải nghiệm giống nhau.
Các nhà cung cấp (chẳng hạn như Rollup) về mặt lý thuyết không dành riêng cho bộ coorter được chia sẻ, nhưng trên thực tế, bộ coorter được chia sẻ, các rollup của nó và người dùng được hưởng lợi từ một loạt các hiệu ứng mạng dẫn đến việc sử dụng các rollup này tăng lên. Những lợi ích này giúp Rollup và người dùng tích hợp vào ngăn xếp được chia sẻ dễ dàng hơn vì họ sẽ mất nhiều hơn nếu không tham gia. Mặc dù khó có thể thấy được những lợi ích này khi bạn chỉ có hai Tổng số chia sẻ một bộ trình tự sắp xếp duy nhất, nhưng chúng sẽ trở nên rõ ràng hơn khi bạn thêm ngày càng nhiều Tổng số và Người dùng vào phương trình. Bộ sắp xếp dùng chung có mối quan hệ trực tiếp với người dùng, khi họ sắp xếp các giao dịch của mình, ngay cả khi bản thân người dùng không biết họ đang tương tác với chúng, vì theo quan điểm của họ, họ chỉ đang sử dụng Tổng số mà họ có lý do để tương tác ( Điều này có nghĩa là đặt hàng/phân loại trở thành độc quyền). Chi phí duy nhất của những bộ sắp xếp này thực sự là chi phí phần cứng để chạy chúng, miễn là không gian khối và mã thông báo bảo vệ nó có giá trị đối với người dùng cuối. Phí giao dịch được số hóa, thanh toán từ ví của người dùng và có lẽ trong tương lai, thậm chí có thể được trừu tượng hóa thông qua các tiến bộ như máy chủ thanh toán trong trừu tượng hóa tài khoản (tuy nhiên, ai đó sẽ phải chịu chi phí DA, đặt hàng và thực hiện).
Điều này có ý nghĩa hơn khi xem xét công ty trước đây của Josh và Jordan ở Astria - Google. Kể từ khi thành lập, các sản phẩm của Google đã lấy cảm hứng từ ý tưởng về AT, đặc biệt là trong Tìm kiếm của Google, được tạo bằng cách mô đun hóa các trang và bài báo riêng lẻ, giúp chúng có thể truy cập trực tiếp thông qua cửa sổ tìm kiếm toàn cầu.
Trong trường hợp một bộ sắp xếp được chia sẻ, những người dùng sử dụng Rollup (những người chia sẻ một bộ sắp xếp) có chi phí mua lại ngày càng thấp hơn, bởi vì khi số lượng nhà cung cấp (Rollup) tăng lên, họ có khả năng bị thu hút bởi bộ sắp xếp . Điều này có nghĩa là, trong hầu hết các trường hợp, một bộ tổng hợp (hoặc nhiều bộ tổng hợp) có thể có tác dụng đôi bên cùng có lợi, vì giá trị của một bộ tổng hợp tăng theo số lượng nhà cung cấp (tất nhiên là miễn là trải nghiệm người dùng tốt). Ngược lại, trên một mạng nối tiếp duy nhất, việc thu hút khách hàng bị giới hạn trong một mạng duy nhất và các ứng dụng của nó. Nếu người dùng muốn sử dụng ứng dụng Rollup trên một Rollup khác, họ sẽ phải (trong giới hạn hiện tại) đăng xuất hoàn toàn khỏi mạng. Điều này có nghĩa là độ gắn bó và giá trị của người dùng không cao lắm, và cũng có nghĩa là bất cứ lúc nào, nếu một hệ sinh thái Rollup khác được đánh giá cao (hoặc có nhiều ưu đãi hơn), vốn có thể bị thất thoát.
Thuộc tính và Tóm tắt Đánh đổi
Thuộc tính
Bộ sắp xếp được chia sẻ là một mạng tổng số tổng hợp và sắp xếp các giao dịch cho nhiều lần tổng số. Các Tổng số này chia sẻ cùng một bộ sắp xếp. Việc tổng hợp các tài nguyên này có nghĩa là Rollup có được khả năng chống kiểm duyệt và bảo mật kinh tế mạnh mẽ hơn, có thể cung cấp bảo đảm xác định mềm nhanh chóng và giao dịch Rollup chéo có điều kiện.
Ngay bây giờ, có rất nhiều ồn ào về tính nguyên tử giữa các Bản tổng hợp chia sẻ cùng một bộ sắp xếp, chủ yếu xoay quanh việc liệu nó có phải là nguyên tử theo mặc định hay không. Tuy nhiên, nếu các Tổng số được đề cập triển khai các hàm chuyển đổi trạng thái (STF) của nhau dưới dạng phụ thuộc giữa chúng, liên quan đến các giao dịch có điều kiện, thì chúng thực sự có thể đạt được tính nguyên tử giữa chúng - miễn là Sắp xếp vị trí/thời gian khối của chúng (như với các bộ sắp xếp được chia sẻ). Trong trường hợp này, để có được khả năng tương tác nguyên tử, bạn thực sự chỉ cần chạy một ứng dụng khách nhẹ của chuỗi B trên chuỗi A và ngược lại (tương tự như cách IBC hoạt động). Để tăng cường hơn nữa khả năng tương tác của các biện pháp bảo mật (ngoài việc tin tưởng một nút đầy đủ duy nhất làm nút nhẹ), bạn có thể triển khai ZKP (Proof of State) để giải quyết "vấn đề tiên tri" về đảm bảo tính chính xác của trạng thái. Điều này sẽ làm cho nó rõ ràng hơn để xem liệu một giao dịch có điều kiện hoặc một cái gì đó tương tự như vậy có đạt được cầu nối chuỗi chéo chính tắc giữa chúng hay không. Bằng chứng gian lận cũng có thể xảy ra, nhưng rõ ràng sẽ để lại một khoảng thời gian thử thách (có nghĩa là một bên thứ ba sẽ đến để trang trải chi phí cho rủi ro này). Ngoài ra, trong trường hợp máy khách nhẹ (chứ không phải nút đầy đủ), nó sẽ chậm hơn ít nhất một khối do chờ tiêu đề chữ ký + cửa sổ chống gian lận (nếu có).
Chúng tôi tin rằng vấn đề "cầu nối chuỗi chéo" rất có thể được giải quyết với các ứng dụng khách nhẹ và bằng chứng không có kiến thức. Thách thức với việc sử dụng ứng dụng khách nhẹ (chứ không phải hợp đồng thông minh) trong trường hợp này là các nhánh cứng (nâng cấp, v.v.) ở phía nút Rollup cần phối hợp với nhau để duy trì hoạt động của cầu nối (giống như IBC cần kích hoạt cùng một mô-đun trạng thái). Nếu bạn muốn tìm hiểu sâu hơn về chủ đề cụ thể này (và cách giải quyết nó), chúng tôi thực sự khuyên bạn nên xem bản trình bày này.
Lý do mà những người đặt hàng được chia sẻ mở rộng quy mô rất tốt là vì chúng không thực thi và lưu trữ bất kỳ trạng thái nào (như những người đặt hàng tập trung vẫn làm ngày nay). Điều tương tự cũng xảy ra với chính các nút Tổng số (trừ khi chúng muốn có tính nguyên tử giữa chúng - ví dụ: ứng dụng khách nhẹ/bằng chứng trạng thái). Các nút này chỉ thực hiện các giao dịch hợp lệ cho Rollup của chúng và bất kỳ giao dịch tên miền chéo có điều kiện nào hợp lệ đối với chúng. Nếu một nút Tổng số phải thực thi và lưu trữ trạng thái cho nhiều lần Tổng số, thì điều đó sẽ cản trở khả năng mở rộng và giảm tính phân cấp (và do đó khả năng chống kiểm duyệt). Điều này cũng củng cố khái niệm phân tách nhà sản xuất-nhà xây dựng khối (PBS). Mặc dù chúng ta vẫn cần tách biệt hoàn toàn các nhà xây dựng và nhà sản xuất khối. Trong thiết lập hiện tại, người đặt hàng về cơ bản là người xây dựng và sản xuất khối (mặc dù họ không thực hiện giao dịch). Một thiết lập lý tưởng có thể là một thiết lập mà người đặt hàng tồn tại chỉ để ký một cách mù quáng các khối từ thiết lập trình tạo được tối ưu hóa cao và đảm bảo rằng các khối được triển khai chính xác (đồng thời mang lại mức độ chắc chắn về kinh tế cao và khả năng chống kiểm duyệt đối với chứng nhận đó). Bằng cách này, họ có thể cung cấp mức độ bảo mật cao và cam kết đảm bảo tính hữu hạn mềm cho các nút Rollup.
Đối với các giao dịch có điều kiện tổng số chéo, chúng cũng tồn tại để giúp cho phép các nút tổng số (bộ thực thi) cung cấp gốc trạng thái trung gian, cho phép tính nguyên tử giữa các lần tổng số.
đánh đổi
Thông số thời gian chờ đã nói ở trên có một số tác động thú vị đối với MEV và bao gồm giao dịch, tùy thuộc vào cơ chế masternode/đồng thuận của tập hợp người đặt hàng. Ví dụ: nếu tham số thời gian chờ được mô tả là tương đối ngắn trong tài liệu chuỗi dành riêng cho ứng dụng của chúng tôi, thì điều quan trọng là các nhà sản xuất khối của một nhóm người đặt hàng phi tập trung xuất bản dữ liệu càng nhanh càng tốt. Trong một thế giới như vậy, bạn có thể thấy sự cạnh tranh giữa các "người xác thực", những người cạnh tranh để trở thành các nút chính và đặt giá thầu trên lớp DA cho không gian khối cho đến khi nó không còn sinh lãi nữa.
Như Evan đã trình bày trong bài đăng về người đặt hàng lười biếng ban đầu của mình trên diễn đàn Celestia, việc chờ đợi các giao dịch được xuất bản lên lớp cơ sở (trong trường hợp này là Celestia) trước khi thực hiện chúng là rất kém hiệu quả. Vì bây giờ bạn bị giới hạn bởi thời gian khối của lớp cơ sở - quá lâu để chờ đợi trải nghiệm của người dùng. Để có trải nghiệm người dùng tốt hơn, trình đặt hàng được chia sẻ cung cấp các Bản tổng hợp với các cam kết xác định mềm (như được mô tả trước đó), cung cấp cho người dùng trải nghiệm người dùng mà họ đã quen thuộc trong các Bản tổng hợp tập trung hiện có (đồng thời duy trì tính phi tập trung và khả năng chống kiểm duyệt cao). Các cam kết mềm về cơ bản chỉ là các cam kết đối với thứ tự giao dịch cuối cùng, nhưng được hỗ trợ bởi các bảo đảm kinh tế nặng nề và hoàn tất nhanh chóng sau khi được ban hành. Điều này cũng được bao phủ bởi các bằng chứng gian lận (như đã đề cập trong phần giới thiệu). Độ chính xác cứng thực tế đạt được sau khi tất cả dữ liệu giao dịch đã được xuất bản lên lớp cơ sở (có nghĩa là L1 thực sự đạt được độ cuối nhanh hơn). Nó phụ thuộc vào việc Rollup sử dụng bằng chứng gian lận hay bằng chứng không có kiến thức để xác minh bằng chứng chủ quyền - điều này xảy ra trên Rollup. Lý do muốn có sự tách biệt này là để loại bỏ nút cổ chai khổng lồ của quá trình chuyển đổi trạng thái khỏi bộ phân loại. Thay vào đó, các nút Rollup chỉ xử lý các nút hợp lệ đối với chúng (nghĩa là chúng tôi phải thêm các giao dịch có điều kiện, bằng chứng về trạng thái hoặc xác thực nút nhẹ để có khả năng tương tác phù hợp). Tính xác định cứng vẫn phụ thuộc vào lớp cơ sở (nhưng điều này có thể đạt tới 15 giây trên Celestia và cũng mang tính xác định trong Tendermint), điều này mang lại cho chúng tôi sự đảm bảo về tính xác định cứng tương đối nhanh trên Rollup.
Sử dụng bằng chứng không có kiến thức bên trong mạng để tối ưu hóa quá trình xác thực, quy mô giao dịch (ví dụ: chỉ xuất bản sự khác biệt về trạng thái - nhưng điều này sẽ thêm mức độ tin cậy cao hơn cho đến khi ZKP được xuất bản). Như đã đề cập trước đó, các bằng chứng trạng thái này có thể được sử dụng để cho phép các chuỗi/bản tổng hợp được kết nối có khả năng tương tác dễ dàng và nhanh hơn (không cần đợi các cửa sổ thử thách).
Nhược điểm của các giao dịch có điều kiện này là chúng có thể đắt hơn, đòi hỏi chi phí xác minh và phát hành cao hơn (chẳng hạn như chi phí xác minh tiêu đề khối Tendermint, được trợ cấp trên chuỗi Cosmos) và thêm một số độ trễ cho hệ thống ( nhưng vẫn nhanh hơn so với Bản tổng hợp biệt lập nhanh hơn nhiều). Tính nguyên tử đạt được nhờ tích hợp chia sẻ theo chiều dọc có thể bù đắp cho những vấn đề này.
Trong giai đoạn khởi động của một bản tổng hợp mới, việc sử dụng một bộ đối chiếu được chia sẻ rất có ý nghĩa và những lợi thế bạn có được với tư cách là nhà cung cấp có thể sẽ lớn hơn một số sự đánh đổi mà bạn có thể "buộc phải" thực hiện ở cấp độ hào. Tuy nhiên, đối với một Rollup đã trưởng thành, nơi có nhiều giao dịch và hoạt động kinh tế, có lẽ không hợp lý khi từ bỏ một phần của con hào.
Điều này đặt ra câu hỏi liệu chúng ta có cần phân phối lại MEV được trích xuất có trọng số kinh tế/giao dịch (mỗi lần tổng hợp) tương tự để tạo ra các Bản tổng hợp đã trưởng thành tham gia vào tập hợp được chia sẻ hay không - hoặc thậm chí ngăn các Bản tổng hợp cực kỳ trưởng thành tạo mạng riêng. Đây hoàn toàn là lý thuyết, nhưng chắc chắn đây là một quá trình suy nghĩ thú vị liên quan đến cách MEV trong các thế giới dọc được chia sẻ sẽ được thể hiện giữa nhiều Bản tổng hợp với các mức độ hoạt động khác nhau. Ví dụ: nếu một Tổng số duy nhất thúc đẩy giá trị chia sẻ một số lợi nhuận này với những người khác (có thể không mang lại nhiều "giá trị") thông qua Bộ trình tự sắp xếp, thì phải có thêm lý do để họ chuyển sang hệ thống riêng biệt của mình . Sreeram của EigenLayr cũng có một số suy nghĩ về điều này, chúng tôi cũng khuyên bạn nên đọc.
Điều này ngày càng trở nên quan trọng khi xem xét rằng có một chi phí kỹ thuật đáng kể cho những người tìm kiếm để phát triển các chuỗi mới, vì vậy việc tiêu chuẩn hóa và cung cấp một số chủ quyền đối với MEV "của họ" có thể là một nơi tốt để bắt đầu. Trên thực tế, trong MEV, giao diện (hoặc phần mềm) chiếm ưu thế có thể giành chiến thắng, nhưng thực tế việc kiếm tiền từ phần mềm đó bằng cách chạy các phần quan trọng của cơ sở hạ tầng là rất khó (dẫn đến tập trung hóa). Ở cấp độ thị trường, những gì một người đặt hàng được chia sẻ cung cấp về cơ bản là một bộ nhớ chung cho nhiều nhà cung cấp, với một cuộc đấu giá tập trung, điều này có thể dẫn đến sự cạnh tranh lành mạnh hơn.
Một mối quan tâm ở đây là nếu hai Tổng số đang chạy bộ sắp xếp trong tập hợp dùng chung, thì một Tổng số có giá trị "kém kinh tế hơn" (A) có thể được chọn để đề xuất một tổng số có lượng MEV + phí cao từ các khối Tổng hợp (B). . Theo quan điểm của Rollup B, về cơ bản, họ đã bỏ lỡ một số giá trị mà theo cách tiếp cận biệt lập, họ sẽ giữ cho riêng mình.
Giải quyết vấn đề đánh đổi khả năng tương tác
Một lưu ý khác về sự đánh đổi do khả năng tương tác thể hiện và một cách khác để giải quyết một số vấn đề sau:
Mục đích của mạng đặt hàng được chia sẻ là cung cấp sự đảm bảo chính tắc cho nhiều chuỗi, đây rõ ràng là một lợi thế lớn trong trường hợp này. Điều này có thể được kết hợp với một cơ chế để đảm bảo chuyển đổi trạng thái hiệu quả giữa các Rollup. Đây có thể là cách tiếp cận dựa trên ủy ban (ví dụ: PoS), bằng chứng được bảo mật (phương pháp Lạc quan) hoặc cách tiếp cận ưa thích của chúng tôi - ZKP được hỗ trợ bởi chữ ký của ủy ban. Bởi vì các bộ sắp xếp được chia sẻ "lười biếng", chúng chỉ tạo các siêu khối để sắp xếp các giao dịch của nhiều Bản tổng hợp và việc thực thi giao dịch cụ thể được dành cho một Bản tổng hợp cụ thể. Bằng chứng về trạng thái (tức là Lagrange, Axiom hoặc Herodotus, v.v.) đều là những giải pháp khả thi để có khả năng thu được bằng chứng về tính hữu hạn trong các lần tổng hợp có chủ quyền. Bạn thậm chí có thể thêm bằng chứng về tính hữu hạn được đảm bảo về mặt kinh tế thông qua những thứ như nhóm đặt cược, EigenLayr, v.v. Ý tưởng cơ bản là một bộ sắp xếp dùng chung cung cấp một sự đảm bảo kinh tế cho việc đặt hàng và bằng chứng hợp lệ được tạo ra từ sự sắp xếp này là xác định. Ý tưởng cơ bản là Rollup có thể thực hiện các giao dịch đồng bộ với nhau. Ví dụ: một mạng gồm hai nút Tổng số có thể biết một cách có điều kiện rằng cả hai lịch sử Tổng số đều hợp lệ, thông qua ZKP và dữ liệu có sẵn (dữ liệu được xuất bản lên lớp DA hiệu quả). Bằng cách xuất bản một tiền tố khối Tổng số duy nhất từ cả hai mạng A và B, một nút Tổng số có thể giải quyết hai lần Tổng số cùng một lúc. Một điều cần chỉ ra là các giao dịch cuộn chéo có điều kiện tiêu thụ tài nguyên từ hai hệ thống riêng biệt thông qua thực thi được chia sẻ, do đó, các giao dịch nguyên tử (hoặc đồng bộ) trong cuộn chéo có thể đắt hơn so với các giao dịch nội bộ cuộn lên một lần.
Succinct cũng đề cập đến các giao dịch "nguyên tử" xuyên chuỗi giữa Rollup với những người đặt hàng được chia sẻ (và các bằng chứng gian lận được chia sẻ) trong hệ sinh thái siêu chuỗi Optimism, có thể xem tại đây. Ngoài ra, như Bo Du của Polymer đã nói: "Các giao dịch nguyên tử xuyên chuỗi giống như có được các khóa giữa các phân đoạn cơ sở dữ liệu khi ghi".
Tương lai của hội nhập dọc
Các hoạt động bên trong có thể có của chuỗi SUAVE đã được Jon Charbonneau và cộng sự khám phá sâu, vì vậy chúng tôi sẽ không đi sâu vào chi tiết. Nếu bạn muốn mô tả chi tiết hơn, bạn có thể xem bài viết của anh ấy. Tuy nhiên, chúng tôi cho rằng tích hợp dọc xứng đáng được giới thiệu riêng, vừa để làm nổi bật cách chúng ta có thể trở thành mô đun (và tại sao) vừa để giới thiệu một số vấn đề và mối quan tâm liên quan đến tích hợp dọc.
Mặc dù sơ đồ đặt hàng được chia sẻ hiện tại của Astria, Espresso và Radius rất mô đun, nhưng những người đặt hàng vẫn đóng vai trò là người xây dựng và sản xuất khối (mặc dù trong trường hợp của Astria, họ không thực hiện giao dịch). Astria cũng đã tích cực xây dựng PBS thành kiến trúc của mình ngay từ đầu.
Nếu PBS không được tích hợp trong giao thức, thì có một số cách để triển khai PBS (mặc dù với các mức độ phân quyền khác nhau). Các sản phẩm như SUAVE, sử dụng các mô hình ngoại tuyến như MEV-Boost hoặc triển khai các mô-đun trình tạo như mô-đun SDK Cosmos do Mekatek và Skip xây dựng.
Điều đáng chú ý là không có phương pháp nào trong số này là loại trừ lẫn nhau. Bạn có thể linh hoạt sử dụng một số phương pháp khác nhau và để mọi người thể hiện sở thích của họ. Bằng cách đó, bạn có thể có những người thi hành cạnh tranh để lấp đầy những chỗ trống đó. Thêm nhiều tùy chọn hơn luôn tốt (và phù hợp với niềm tin của chúng tôi về tính mô đun). Tuy nhiên, các triển khai khác nhau sẽ có sự đánh đổi khác nhau. Ví dụ: trong trường hợp như SUAVE, bạn có thể thêm bảo vệ quyền riêng tư thông qua công nghệ SGX hoặc Crypto và thêm bảo mật kinh tế Crypto vào sự thật, thay vì dựa vào trình tạo PBS tập trung hoàn toàn đáng tin cậy. (Cảm ơn Jon Charbonneau vì phản hồi của anh ấy ở đây).
Tích hợp dọc vào chuỗi trình tạo đảm bảo tính công bằng mà không cần sử dụng lối tắt, làm tăng thêm độ trễ và làm giảm hiệu suất. Do đó, chuỗi trình tạo cần được tối ưu hóa cao và có thể yêu cầu phần cứng mạnh và đắt tiền (dẫn đến tập trung hóa). Điều này có nghĩa là để có được xác thực của người dùng cuối, chúng tôi có thể cần một số loại nút nhẹ (mặc dù họ phải tin tưởng vào các nút đầy đủ) hoặc sử dụng bằng chứng về thiết lập loại trạng thái để đảm bảo chuỗi và người dùng có bằng chứng rằng tùy chọn giá thầu được lấp đầy và các khối được xây dựng chính xác.
Một chuỗi như thế này có thể rất nặng về trạng thái (chúng tôi muốn tránh điều này), mặc dù các giao dịch nặng về trạng thái này sẽ được ưu tiên thông qua hợp đồng thông minh. Trong trường hợp giá thầu ưu tiên, nó sẽ được lấp đầy hoặc không được lấp đầy (trong một khoảng thời gian ngắn), vì giá thầu thường chỉ có hiệu lực trong một khoảng thời gian ngắn, tùy thuộc vào sở thích. Điều này có nghĩa là chúng tôi có thể triển khai hết hạn trạng thái rất hiệu quả (và sớm) cho giá thầu - điều này sẽ cho phép chúng tôi cắt bớt dữ liệu và giữ cho chuỗi "sạch". Ngày hết hạn này cần phải đủ dài để vẫn cho phép các giá thầu được lấp đầy trước, nhưng việc hạ thấp nó quá nhiều sẽ khiến việc đạt được các hợp đồng tương lai không gian khối chuyển tiếp gần như không thể. Chúng tôi không cần cập nhật và truy xuất các hợp đồng giá thầu đã hết hạn vì chúng không cần tồn tại mãi mãi (không giống như các ứng dụng) - điều này có thể được thực hiện bằng cách cung cấp bằng chứng trạng thái/lưu trữ khi giá thầu được lấp đầy hoặc bằng các giải pháp lưu trữ DAS (chẳng hạn như đề xuất bằng giải pháp Joachim Neu) để làm cho nó trở nên "an toàn" và đáng tin cậy hơn.
Như đã đề cập trước đó, nhu cầu xác minh "tính xác thực" của SUAVE có thể chỉ giới hạn ở "jusha" (người dùng nâng cao) của nền tảng, bởi vì hầu hết người dùng và khách hàng của SUAVE có thể thu được lợi ích kinh tế cao từ nó. Điều này có thể thúc đẩy chúng tôi chỉ cho phép mọi người chạy các nút đầy đủ nếu họ muốn xác thực - mặc dù điều này loại trừ đại đa số mọi người (bạn có thể nói rằng họ không cần xác thực). Điều này (theo ý kiến của chúng tôi) trái ngược với Crypto, nơi chúng tôi muốn triển khai xác minh SUAVE "không đáng tin cậy" thông qua các bằng chứng trạng thái hoặc triển khai thân thiện với khách hàng nhẹ.
Lý do điều này là cần thiết vì bạn muốn xác minh rằng mức độ ưu tiên giá thầu của bạn đã được điền chính xác và khối đã được điền thông tin chính xác khi thanh toán (để tránh hoàn trả và các lỗi khác). Đây thực chất là một vấn đề tiên tri - trên thực tế, nó có thể được giải quyết bằng một bằng chứng về trạng thái (như trường hợp của tất cả các SUAVE). Tuy nhiên, những bằng chứng trạng thái này đưa ra một vấn đề khác khi vượt qua các chuỗi, làm thế nào để chuyển tiếp thông tin này qua các chuỗi theo cách mà nó không bị giả mạo hoặc che giấu? Điều này có thể yêu cầu trải qua giai đoạn cuối cùng về kinh tế mạnh mẽ (chẳng hạn như do Lagrangian đề xuất), trong trường hợp đó, bạn có thể sử dụng trình xác nhận đặt lại của EigenLayr để chứng minh tính cuối cùng và tính xác thực của chuỗi, đồng thời có những hạn chế rất mạnh mẽ về kinh tế. Điều này sau đó làm nảy sinh một vấn đề khác (ví dụ: hợp đồng đấu thầu quy định rằng "máy tiên tri" - trong trường hợp này là bên cam kết lại - đã chỉ định Token được cam kết và cung cấp ràng buộc kinh tế - nhưng làm cách nào để tạo sự đồng thuận giữa Bên ngoài việc cắt giảm này? Trong khi bạn có thể viết các tiêu chí chặt chém, điều này không đồng thuận, có nghĩa là việc chặt chém xã hội sẽ bị khai thác thông qua hợp đồng thông minh (hầu như không bao giờ "công bằng" và có thể gây ra vấn đề). .
Vậy thứ này bỏ chúng ta ở đâu? Có thể, cho đến khi chúng ta vượt qua sự đồng thuận "không tin cậy" trên chuỗi, các chuỗi như SUAVE có thể cần các thuật toán đồng thuận và bảo mật kinh tế tiền điện tử của riêng họ để chứng minh các ưu tiên giá thầu và xây dựng sự chắc chắn của khối— Tuy nhiên, điều này có nghĩa là thêm nhiều vectơ tấn công kinh tế tiền điện tử hơn, đặc biệt nếu Rollup giá trị của các khối xây dựng của nó cao hơn nhiều so với bảo mật kinh tế tiền điện tử của chính nó.
Ngoài ra, vẫn còn rất nhiều không gian thiết kế trong các chuỗi loại SUAVE và MEV giữa các miền.Dưới đây là một số hướng nghiên cứu khả thi:
Về biểu thức tùy chọn, để tương tác với hợp đồng thông minh trong EVM, cần gửi lệnh gọi hợp đồng (tin nhắn) đến một chức năng cụ thể tại địa chỉ của mã được triển khai có chứa lệnh thực thi. Trong khi người dùng cung cấp đầu vào, họ có thể không có quyền kiểm soát đầu ra do trạng thái có thể xảy ra.
Ngược lại, các hệ thống thiết kế biểu thức tùy chọn (chẳng hạn như SUAVE và Anoma) chỉ yêu cầu người dùng ký các tùy chọn bằng một trái phiếu, được trả cho các nhà xây dựng và nhà sản xuất khối nếu các tùy chọn của người tìm kiếm được đáp ứng. Đối với logic tổ hợp phức tạp, chẳng hạn như chuỗi giao dịch cho người tìm kiếm và người xây dựng MEV, có thể cần triển khai các ngôn ngữ và máy ảo khác nhau. Đây là không gian thiết kế mới nhận được nhiều sự quan tâm trong thời gian gần đây, đặc biệt là kiến trúc Anoma. Ngoài ra, chúng tôi đánh giá cao bài viết ngắn này.