MEV-Boost, giao thức sidecar hiện tại cho việc khai thác MEV trên Ethereum, phụ thuộc nhiều vào những tác nhân trung tâm được gọi là chuyển tiếp.

Chúng tôi đề xuất một kiến trúc thay thế cho phép giao tiếp trực tiếp, riêng tư về mặt mật mã giữa các nhà xây dựng và người đề xuất. Nó dựa trên một hình thức mã hóa ngưỡng "im lặng" mới, không tương tác có thể sử dụng các cặp khóa BLS hiện có của trình xác thực.

Cơ bản, chúng tôi tận dụng ủy ban xác nhận để đảm bảo quyền riêng tư và khả năng truy cập dữ liệu bằng cách mã hóa ngưỡng các đề xuất khối cho một phần nhỏ của những người xác nhận cho khe. Sự chứng thực của họ tạo thành khóa giải mã; sau khi ngưỡng mong muốn đã chứng thực, khối có thể được giải mã.

Công trình của chúng tôi giải quyết vấn đề quyền riêng tư giữa các nhà xây dựng và người đề xuất nhưng đó không đảm bảo độ hợp lệ của khối một cách độc lập. Nó có thể kết hợp với các cơ chế khác để hoàn toàn sao chép các chức năng được cung cấp bởi các chuyển tiếp - cả quyền riêng tư và độ hợp lệ của khối. Ví dụ, các kế hoạch chứng minh như Chứng minh Môi trường Thực thi Đáng tin cậy (TEE) hoặc Chứng minh Zero-Knowledge (ZK), hoặc cơ chế kinh tế mật mã để thế chấp cho các nhà xây dựng.

Bằng cách loại bỏ nhu cầu chuyển tiếp để cung cấp tính riêng tư cho người xây dựng và đảm bảo tính hợp lệ của khối, chúng tôi nhằm vào việc giảm độ trễ và cải thiện sự phân quyền và khả năng chống kiểm duyệt của Ethereum.

MEV-Boost và vai trò của Chuyển tiếp

MEV-Boost là một giao thức phụ trợ kết nối giữa người xây dựng khối và người đề xuất.vai trò chính of the Chuyển tiếp is to provide two guarantees:

• Quyền riêng tư cho người xây dựng: Relay đảm bảo rằng người đề xuất không thể xem nội dung khối và đánh cắp MEV do người xây dựng tìm thấy.
• An toàn cho người đề xuất: Chuyển tiếp đảm bảo rằng người xây dựng trả giá trị đã hứa cho người đề xuất trong đấu thầu của người xây dựng và khối là hợp lệ (ví dụ: tất cả các giao dịch đều trả gas nội tại).

Tuy nhiên, sự phụ thuộc vào rơle giới thiệu sự tập trung đáng kể. Khoảng 90% các khối trên Ethereum được phân phối chỉ thông qua một số ít các rơle. Điều này đặt ra một số rủi ro:

• Tập trung: Những người xây dựng có thể đạt được hiệu quả về độ trễ bằng cách đặt cùng với các chuyển tiếp thay vì phản ánh phân bố địa lý của các đề xuất. Điều này trực tiếp làm suy yếu tính phân tán địa lý và khả năng chống kiểm duyệt mà chúng ta sẽ đạt được nếu có một tập hợp xác nhận toàn cầu và phân tán lớn hơn.
• Doanh thu: Độ trễ xử lý khối từ đầu đến cuối trung bình của các chuyển tiếp hiệu quả khoảng 5-20 mili giây. Sau đó, có độ trễ giao tiếp giữa người đề xuất và người xây dựng. Bỏ qua các chuyển tiếp sẽ giảm độ trễ, giảm nguy cơ thực thi qua các miền (ví dụ: CEX/DEX), và cuối cùng là tăng phần thưởng MEV của người đề xuất.

TEE-Boost

Một trong những đề xuất hàng đầu để thay thế chuyển tiếp là “TEE-Boost“, which relies on TEEs (Trusted Execution Environments). Note that TEEs are not essential to our scheme; it’s just helpful to use TEE-Boost as a pedagogical example of the problems we aim to solve.

Cụ thể, TEE-Boost cho phép nhà xây dựng sử dụng TEE để tạo ra các bằng chứng chứng minh tính trung thực của các đấu giá và tính hợp lệ của các khối của họ mà không tiết lộ nội dung khối thực tế cho người đề xuất. Người đề xuất có thể kiểm tra các bằng chứng này mà không chạy TEE trên phần cứng hàng hóa của chính họ.

Tuy nhiên, TEE-Boost có một vấn đề về sẵn có dữ liệu: người xây dựng chỉ chia sẻ bằng chứng TEE và tiêu đề khối với người đề xuất, không phải nội dung khối thực tế,^[1] và có thể chọn không phát hành nội dung khối ngay cả sau khi người đề xuất ký vào phần tiêu đề (ví dụ, nếu điều kiện thị trường thay đổi không thuận lợi). Các phương pháp đề xuất để giải quyết vấn đề DA này là:

• [ ] TEE-Escrow: Một TEE-escrow nhận khối từ người xây dựng trước khi người đề xuất ký và phát hành nó sau khi họ nhìn thấy phần đầu đã được ký.
• [ ] Lớp Khả dụng Dữ liệu: Người xây dựng đăng tải các dữ liệu khối được mã hóa lên một lớp Khả dụng Dữ liệu (DA).

Cả hai phương pháp đều có nhược điểm. Giải pháp TEE-escrow sao chép độ trễ tập trung tương tự như các re-lay hiện tại.^[2]Sử dụng một lớp DA bên ngoài đưa ra một giả định bổ sung về giao thức và mang theo động học độ trễ của giao thức bên ngoài đó (có khả năng cũng không thuận lợi).

1. Lý thuyết, nếu người đề xuất cũng có quyền truy cập vào TEE, người xây dựng có thể mã hóa các khối của họ đến một TEE được chạy bởi người đề xuất. TEE của người đề xuất chỉ giải mã khối sau khi họ đã ký vào đó. Tuy nhiên, chúng tôi nghĩ rằng TEE-Boost không xem xét thiết kế này vì điều đó sẽ yêu cầu người đề xuất (người xác minh) phải chạy TEE. Chúng tôi muốn người xác minh có thể chạy trên phần cứng hàng hóa.↩

2. Khi các người đề xuất chạy TEE-Escrow như một phần bên cạnh nút xác thực của họ, độ trễ có thể được tránh. Tuy nhiên, một lần nữa, chúng tôi không muốn yêu cầu các nhà xác thực chạy TEEs.↩

Mật mã ngưỡng để đảm bảo quyền riêng tư của người xây dựng

Chúng tôi đề xuất một giải pháp thanh lịch cho vấn đề DA của TEE-Boost: mã hóa ngưỡng đến ủy ban chứng thực. Cụ thể, người xây dựng mã hóa ngưỡng cho khối đến một phần tử nhất định của ủy ban chứng thực cho khe đó. Khi đủ chứng thực được thu thập, khối trở nên có thể giải mã và sẵn sàng.

Công nghệ kích hoạt cốt lõi là Mã hóa ngưỡng im lặng. Kỹ thuật mật mã này cho phép mã hóa ngưỡng mà không yêu cầu giai đoạn thiết lập Tạo khóa phân tán (DKG) tương tác, điều mà các cấu trúc trước đó yêu cầu. Thay vào đó, khóa công khai chung được tính toán xác định từ các khóa công khai BLS đã tồn tại của người đính kèm cộng với một số "gợi ý" (sẽ thảo luận sau).

Điều này đạt được giao tiếp trực tiếp một bước giữa người xây dựng và người xác minh với quyền riêng tư mật mã. Các nhà xác minh không yêu cầu chạy TEE hoặc quản lý bất kỳ chất liệu khóa mới nào.

Cơ khí:

Người xây dựng tạo một khối và mã hóa nó cho ủy ban chứng nhận.

Người xây dựng xây dựng một bằng chứng TEE chứng minh ba điều với ủy ban chứng nhận: rằng đấu giá là trung thực, khối là hợp lệ và nó được mã hóa đúng cách.

Người xây dựng truyền thông khối được mã hóa ngưỡng và chứng minh TEE (bao gồm giá trị đặt cược) cho người đề xuất.^[3]

Người đề xuất ký vào khối được mã hóa của người xây dựng chiến thắng và chia sẻ đề xuất này đến tập hợp các bộ xác minh.

Một khi ủy ban người chứng thực cụ thể (ví dụ: n/2 hoặc 2n/3) n-chứng thực cho khe cắm chứng thực cho khối, nó sẽ được giải mã.

Khối được giải mã tiếp tục đến quá trình hoàn tất một cách bình thường.

1. Tác động lên yêu cầu băng thông của người đề xuất cần phải được nghiên cứu. Người đề xuất có băng thông thấp có thể giới hạn nhu cầu bằng cách xác minh chứng minh trước khi yêu cầu thân khối khối, hoặc với các kỹ thuật lọc heurisitic và tải về thông minh khác. Điều này là một câu hỏi mở và có vẻ không khó khăn hơn là giải quyết các vấn đề rác rưởi thông tin mempool thông thường.↩

Những điều cần xem xét

Hiệu suất

Các đặc điểm hiệu suất của Mã hóa Ngưỡng Im lặng khá thuận lợi. Ở đây

n là kích thước tối đa của ủy ban mà chúng tôi muốn hỗ trợ và t là ngưỡng cho quá trình giải mã.

Cả mã hóa và giải mã một phần đều có thời gian không đổi. Với một cài đặt ngây thơ, mã hóa mất ít hơn 7 ms - và điều này có thể được song song hóa. Giải mã một phần mất ít hơn 1 ms.

Kích thước văn bản mật mã là một yếu tố cộng hưởng hằng số, 768 byte, lớn hơn văn bản thô (đối với mọi n và t).

Tích hợp các giải mã một phần (tức là, giải mã) phụ thuộc vào kích thước của ủy ban. Với n = 1024, một cài đặt ngây thơ mất <200ms. Chúng tôi kỳ vọng rằng với n = 128 (kích thước của ủy ban chứng thực cho mỗi khe cắm), điều này sẽ giảm đi một hệ số 10 và cài đặt có thể được tối ưu hóa thêm.

Quan trọng là thời gian mã hóa là số hiệu suất chính để so sánh với độ trễ của chuyển tiếp. Đây là điều mà người xây dựng phải tính toán trong 'đường dẫn quan trọng' của việc sản xuất khối. Nó thấp hơn độ trễ xử lý khối của chuyển tiếp hiện có và tránh được việc truyền thông đa nhảy.

Xuất bản dữ liệu

Mã hóa Ngưỡng Im Lặng không hoàn toàn miễn phí. Điều này đòi hỏi một chuỗi tham chiếu chung dạng: (g,g^τ,g^τ2,…,g^τn−t) , tương tự như việc sử dụng cho hệ thống cam kết đa thức KZG.

Ngoài ra, mội validator với một khóa công khai BLS của dạng gsk đăng xuất một tập hợp các phần tử nhóm mà chúng ta gọi là “hints”: (g^sk⋅τ,...,g^sk⋅τn−t). Những gợi ý này chỉ cần để chuyển tiếp các khóa công khai và giải mã các đoạn văn bản đã được mã hóa. Việc mã hóa chỉ sử dụng một khóa công khai được tổng hợp với kích thước cố định.

Khi viết bài này, có khoảng 1 triệu trình xác thực. Nếu chúng ta đặt n=128 và t=n/2, mỗi trình xác thực cần đăng ≈ 3 KB gợi ý. Do đó, việc lưu trữ gợi ý của tất cả trình xác thực yêu cầu 3 GB.

Yêu cầu này có thể giảm đáng kể với kích hoạt MaxEB, cho phép người xác minh kiểm soát >32 ETH để giữ các số dư lớn hơn dưới cùng một cặp khóa (thay vì chia chúng thành nhiều khoản gửi 32 ETH). Việc giảm số lượng người xác minh kiểm soát sẽ được thực hiện là một vấn đề còn đang tranh luận. Có vẻ như chúng ta có thể giảm xuống cỡ ~1GB.

Cuối cùng, tùy thuộc vào các thay đổi trong kiến ​​trúc đồng thuận của Ethereum trong tương lai (ví dụ, giảm kích thước bộ xác nhận viên, hoặc phân phối cuối cùng thay thế), kích thước của các gợi ý cần phải được lưu trữ có thể giảm đi nữa.

Sự sống còn

Ethereum muốn tiếp tục hoạt động ngay cả trong điều kiện mạng bất lợi. Một vấn đề với hệ thống này là khả năng tồn tại các khối không thể giải mã do một phần tử của ủy ban bị ngắt kết nối.

Một giải pháp là cho phép người xây dựng quyết định phân số (t) chấp nhận được của ủy ban để giải mã. Có một sự cân bằng giữa quyền riêng tư (khả năng giải ngân và đánh cắp MEV) và khả năng ngưỡng ủy ban trực tuyến. Nó tối đa hóa doanh thu cho các nhà xây dựng để đưa các khối của họ vào thay vì phân nhánh, vì vậy họ nên tìm ra cài đặt ngưỡng được tối ưu hóa.^[4]

Ngoài ra, việc sử dụng hệ thống mã hóa này nên được chọn lựa. Trong điều kiện mạng xấu, khi không có ủy ban có kích thước chấp nhận được có sẵn một cách ổn định, người đề xuất và người xây dựng có thể chuyển sang sử dụng chuyển tiếp, tự xây dựng, hoặc bất kỳ cơ chế nào khác phù hợp với bản chất của môi trường bất lợi.

1. Quyền yêu cầu cụ thể ở đây là rằng làm sao cho việc một khối của người xây dựng bị phân nhánh ra đi (họ không nhận doanh thu từ đó) là giá trị kỳ vọng âm, và rất tiêu cực đối với việc bị gỡ ra khỏi gói. Nếu bạn cho người xây dựng khả năng chọn t trong [0,128], họ nên được khuyến khích tự nhiên để chọn t đủ cao sao cho có rất ít rủi ro bị gỡ ra khỏi gói và có khả năng cao được hài lòng (ít nhất t thành viên của ủy ban đang online). Một số khối có thể bị phân nhánh ra ngay cả trong điều kiện mạng bình thường, nhưng chúng ta sẽ ghi nhận rằng điều này đã xảy ra với các trò chơi thời gian, và sự sống còn của chuỗi vẫn chấp nhận được.↩

Khối không khả dụng

Hoặc, ủy ban có thể hoạt động trực tuyến, nhưng người xây dựng có thể tạo ra tình huống mà khối không thể được giải mã hoặc không hợp lệ sau khi giải mã (ví dụ, với chứng minh gian lận).

Từ quan điểm của giao thức, việc fork các khối này ra là hoàn toàn ổn. Bộ xác minh rộng lớn đơn giản không thể chứng minh cho chúng hoặc cho bất kỳ khối nào tham chiếu đến chúng. Cách tốt nhất để xử lý loại lỗi này có lẽ là làm cho khách hàng đồng thuận nhận thức được khả năng và có thể thất bại một cách nhẹ nhàng. Cần có nghiên cứu sâu hơn về cách thức cụ thể.

Cấu trúc thị trường

Người xây dựng chiến thắng biết nội dung của khối trước người khác cho đến khi ngưỡng được đạt đến, điều này có thể tạo ra lợi thế không công bằng trong các khe tiếp theo. Tuy nhiên, ủy ban chứng nhận được cho là phải hành động trước khi khe tiếp theo kết thúc, và phần lớn giá trị khối nằm ở cuối khe, vì vậy tác động của lợi thế này nên gần như là tối thiểu.

Chứng minh thuần túy từ học mật mã

Trong dài hạn, có thể thay thế các bằng chứng TEE bằng các bằng chứng Zero-Knowledge (ZK). Hiện tại, các bằng chứng ZK quá chậm, nhưng tiến bộ trong mật mã học, phần mềm và phần cứng chuyên dụng (ASICs) có thể làm cho việc tạo ra các bằng chứng ZK khả thi trong các ràng buộc độ trễ cần thiết. Đáng chú ý, các bằng chứng ZK kèm theo các khối đã tồn tại. Phần cốt lõi của lộ trình dài hạn của Ethereum.

Sự thông qua

Với kích thước hiện tại của bộ xác thực và tốc độ tăng trưởng, hệ thống này có thể không đáng giá số lượng dữ liệu yêu cầu phải được công bố trên L1. Tuy nhiên, Ethereum đã có kế hoạch giảm đáng kể số lượng bộ xác thực với MaxEB.

Cách tiếp cận tốt nhất có lẽ sẽ là một bản nâng cấp cùng hoặc sau MaxEB trong đó các client đồng thuận được thông báo về khả năng của ngữ nghĩa khối được mã hóa và các validator được khuyến khích để công bố gợi ý. Ví dụ, sau MaxEB, có thể yêu cầu các validator mới nhập hãy công bố gợi ý, và các validator cũ có thể được khuyến khích nâng cấp.

Các nhà xây dựng sẽ bắt đầu sử dụng cơ chế này khi một phần đủ đáng kể của bộ xác thực chấp nhận nó để có đủ kích thước ủy ban (tức là, đảm bảo tính riêng tư chấp nhận được và khả năng giải mã).

Nếu phương pháp của chúng tôi thực sự có độ trễ thuận lợi so với việc chuyển tiếp nhiều bước, thì thị trường nên áp dụng nó mà không cần giao thức buộc phải sử dụng hoặc bảo vệ một tham số cụ thể.

Lý do

Chuyển tiếp là một trong những nguồn gốc tập trung quan trọng nhất của Ethereum, tạo ra cơ hội để tìm kiếm thuê và làm biến dạng sự phân quyền địa lý của giao thức.

Chúng ta cần loại bỏ chuyển tiếp và nghĩ rằng đây là một cách tương đối lịch sự để làm như vậy. Điều này đòi hỏi sự thay đổi tại tầng đồng thuận, nhưng không cần phần cứng mới hoặc vật liệu khóa được yêu cầu từ phía các người xác minh.

Mặt trái là đó là một thay đổi phức tạp đối với lớp đồng thuận cho một cơ chế mà (nếu chọn tham gia, như đề xuất) có thể hoặc không được thị trường chấp nhận. Tuy nhiên, nhiều thay đổi tiềm năng đối với đường ống MEV đặt ra các câu hỏi tương tự về việc chấp nhận và tối ưu hóa doanh thu (ví dụ, ...danh sách bao gồm). Và có thể có các trường hợp sử dụng khác trong tương lai phụ thuộc vào bộ xác nhận có sẵn cơ sở hạ tầng mã hóa ngưỡng.

Tuyên bố miễn trừ trách nhiệm:

1. Bài viết này được tái bản từ [mô hình]. Tất cả bản quyền thuộc về tác giả gốc [Charlie NoyesGuru, Vamsi Policharla]. Nếu có bất kỳ ý kiến ​​phản đối nào về việc tái in này, vui lòng liên hệ Cổng Họcđội ngũ, và họ sẽ xử lý nó một cách nhanh chóng.
2. Miễn Trách Nhiệm Về Trách Nhiệm: Các quan điểm và ý kiến được thể hiện trong bài viết này chỉ là của tác giả và không tạo thành bất kỳ lời khuyên đầu tư nào.
3. Bản dịch bài viết sang các ngôn ngữ khác được thực hiện bởi nhóm Gate Learn. Trừ khi được đề cập, việc sao chép, phân phối hoặc đạo văn các bài báo đã dịch đều bị cấm.