Giải thích chi tiết về MEV mô-đun: Làm thế nào để đạt được thứ tự giao dịch công bằng?

Tác giả gốc: Maven 11

Tổng hợp gốc: Luffy, Tin tức tầm nhìn xa

Trong hai phần đầu tiên của loạt bài viết này, chúng tôi tập trung vào các vấn đề kỹ thuật phát sinh khi chia tách ngăn xếp và những cải tiến cần thiết cho một thế giới mô-đun. Chúng tôi đã giới thiệu một số cải tiến trong công việc nhằm giải quyết các vấn đề phát sinh một cách tự nhiên trong cài đặt nhiều miền. Tuy nhiên, trong phần cuối cùng của loạt bài, chúng tôi muốn tập trung nhiều hơn vào trải nghiệm người dùng. Chúng tôi muốn kiểm tra xem tính mô-đun, tùy chỉnh và chuyên môn hóa có thể giúp tạo ra các ứng dụng tốt hơn như thế nào. Chương cuối cùng trong loạt bài này xem xét khả năng sáng tạo thú vị và độc đáo cũng như khả năng mô-đun hóa dành cho các nhà phát triển nhằm tạo ra trải nghiệm người dùng Web2 với khả năng chứng minh của Web3.

Lý do đằng sau việc xây dựng tính mô-đun không chỉ để phù hợp với một câu chuyện hay chỉ vì mục đích trở thành mô-đun mà bởi vì nó cho phép chúng ta xây dựng các ứng dụng tốt hơn, hiệu quả hơn và có thể tùy chỉnh nhiều hơn. Khi xây dựng các hệ thống mô-đun và được xây dựng theo mục đích, nhiều tính năng độc đáo sẽ phát sinh. Một số trong số này là hiển nhiên, trong khi những điều khác thì ít rõ ràng hơn. Do đó, mục tiêu của chúng tôi là cung cấp cái nhìn tổng quan về các khả năng của hệ thống mô-đun mà bạn không biết đã tồn tại, chẳng hạn như khả năng mở rộng.

Chúng tôi tin rằng một trong những khả năng mà tính mô-đun mang lại cho nhà phát triển là khả năng xây dựng các ứng dụng chuyên nghiệp có khả năng tùy chỉnh cao nhằm mang lại trải nghiệm tốt hơn cho người dùng cuối. Trước đây chúng ta đã thảo luận về khả năng đặt quy tắc hoặc sắp xếp lại việc thực hiện giao dịch.

Các quy tắc sắp xếp có thể kiểm chứng (sau đây gọi là VSR) là một trong những cơ hội thú vị mà việc đặt hàng có kiểm soát mang lại, đặc biệt đối với các nhà phát triển quan tâm đến việc xây dựng hệ thống giao dịch công bằng hơn về mặt thực thi. Rõ ràng, tổn thất của nhà cung cấp thanh khoản liên quan đến việc tái cân bằng (LVR) nằm ngoài phạm vi của bài viết này, vì vậy chúng tôi sẽ tránh đề cập quá nhiều đến khía cạnh này. Hãy nhớ rằng thiết lập mà chúng tôi sắp giải thích chủ yếu dành cho AMM chứ không phải mô hình sổ đặt hàng. Ngoài ra, CLOB (và thậm chí cả CEX) sẽ được hưởng lợi rất nhiều từ việc tận dụng các đối chiếu có thể kiểm chứng phù hợp với cài đặt cụ thể của họ. Trong môi trường ngoài chuỗi, rõ ràng cần có một số khái niệm về không có kiến ​​thức hoặc thực thi lạc quan được hỗ trợ bởi bảo mật kinh tế tiền điện tử.

VSR đặc biệt thú vị khi chúng tôi xem xét thực tế là hầu hết các nhà đầu tư bán lẻ vẫn chưa (hoặc khó có khả năng) áp dụng các phương pháp bảo tồn. Hầu hết các ví/DEX cũng không triển khai các mempool riêng tư, RPC hoặc các phương thức tương tự. Hầu hết các giao dịch được gửi trực tiếp thông qua giao diện người dùng (trang tổng hợp hoặc giao diện người dùng của DEX). Do đó, trừ khi ứng dụng can thiệp trực tiếp vào quy trình của họ và cách xử lý đơn hàng, kết quả thực thi mà người dùng cuối đạt được có thể sẽ kém lý tưởng.

Vai trò của VSR trở nên rõ ràng khi chúng ta xem xét nơi xảy ra trình tự chuỗi cung ứng giao dịch. Nó nằm ở nơi những người chơi chuyên nghiệp đặt hàng (hoặc chứa) các giao dịch, thường dựa trên một số cuộc đấu giá hoặc phí cơ bản. Thứ tự này rất quan trọng vì nó quyết định giao dịch nào được thực hiện và khi nào. Về cơ bản, những người có quyền xếp hạng có khả năng rút MEV, thường dưới dạng phí ưu tiên (hoặc tiền boa).

Do đó, có thể sẽ rất thú vị khi viết các quy tắc về cách xử lý đơn đặt hàng để cung cấp khả năng thực hiện giao dịch công bằng hơn (trong cài đặt DEX) cho người dùng cuối. Tuy nhiên, nếu bạn đang xây dựng một mạng có mục đích chung, bạn nên cố gắng tránh tuân theo những quy tắc như vậy.

Ngoài ra, có một số MEV quan trọng, chẳng hạn như chênh lệch giá, thanh lý, v.v. Một ý tưởng là tạo một kênh “đường cao tốc” ở đầu khối, đặc biệt nhắm mục tiêu đến các nhà kinh doanh chênh lệch giá và thanh lý trong danh sách trắng, những người trả phí cao hơn và chia sẻ một phần doanh thu với giao thức.

Trong bài báo Thiết kế trao đổi phi tập trung đáng tin cậy thông qua các quy tắc đặt hàng có thể kiểm chứng”, Matheus V., Trong trường hợp không tuân theo các quy tắc đã đặt, người quan sát có thể tạo ra bằng chứng về lỗi (hoặc vì các ràng buộc có thể kiểm chứng được về mặt toán học, bạn cũng có thể tưởng tượng một mạch ZK với các ràng buộc này, sử dụng ZKP làm bằng chứng về tính hợp lệ). Ý tưởng chính về cơ bản là cung cấp cho người dùng cuối (người giao dịch) sự đảm bảo về giá thực hiện. Sự đảm bảo này đảm bảo rằng giao dịch được thực hiện ở mức giá tốt như giao dịch duy nhất trong khối (rõ ràng, có một số mức độ trễ liên quan ở đây nếu chúng ta giả sử lệnh mua/bán/mua/bán dựa trên nguyên tắc ai đến trước được phục vụ trước. ) ). Ý tưởng cơ bản của đề xuất trong bài viết là các quy tắc đặt hàng này sẽ hạn chế người xây dựng (trong kịch bản PBS) hoặc người đặt hàng chỉ bao gồm các giao dịch theo cùng một hướng nếu chúng thực hiện ở mức giá tốt hơn giá có sẵn ở trên cùng. của khối (ví dụ: bán/bán). Ngoài ra, nếu xảy ra trường hợp bạn bán khi kết thúc một chuỗi mua thì việc bán sẽ không được thực hiện (ví dụ: mua, mua, mua, bán), điều này có thể cho thấy rằng người tìm kiếm (hoặc người xây dựng) / người phân loại) sử dụng các giao dịch mua này để đẩy giá có lợi cho họ. Về cơ bản, điều này có nghĩa là các quy tắc giao thức đảm bảo rằng người dùng sẽ không bị lợi dụng để đưa ra mức giá tốt hơn cho người khác (tức là MEV) hoặc bị trượt giá do phí ưu tiên. Rõ ràng, nhược điểm của quy tắc ở đây (trong trường hợp bán nhiều hơn mua hoặc ngược lại) là bạn có thể nhận được mức giá dài hạn tương đối kém.

Đối với nền tảng hợp đồng thông minh nói chung, gần như không thể coi các quy tắc này là quy tắc xây dựng trên chuỗi thuần túy vì bạn không có quyền kiểm soát việc thực hiện và đặt hàng. Đồng thời, bạn đang cạnh tranh với nhiều người khác, vì vậy việc cố gắng ép những người đứng đầu khối phải trả phí ưu tiên sẽ tốn kém một cách không cần thiết. Một trong những tính năng của thiết lập mô-đun là nó cho phép các nhà phát triển ứng dụng tùy chỉnh cách hoạt động của môi trường thực thi của họ. Cho dù đó là đối chiếu, sử dụng một VM khác hay thực hiện các thay đổi tùy chỉnh cho VM hiện có (chẳng hạn như thêm mã hoạt động mới hoặc thay đổi giới hạn gas), điều đó thực sự tùy thuộc vào nhà phát triển và sản phẩm của họ.

Trong trường hợp Bản tổng hợp sử dụng tính khả dụng của dữ liệu, lớp đồng thuận và lớp thanh toán thanh khoản, các cài đặt có thể có như sau:

Một ý tưởng khả thi khác là chia tách thỏa thuận. Hãy tưởng tượng bạn có một nhóm giao dịch, làm thế nào để bạn thực hiện các giao dịch lệnh lớn (dẫn đến trượt giá nhiều)? Điều này có công bằng cho người dùng cuối không nếu giao dịch này được thực hiện trên các khối liên tiếp (hoặc ở cuối khối nếu tuân thủ VSR)?

Nếu người dùng cuối lo ngại về độ trễ thì người dùng đó có thể không muốn đơn hàng của mình bị chia nhỏ. Tuy nhiên, điều này ít phổ biến hơn và việc tối ưu hóa việc phân chia giao dịch cho các lệnh lớn hơn có thể sẽ mang lại hiệu quả khớp lệnh cao hơn cho đại đa số người dùng. Bất chấp điều đó, một mối lo ngại là người tìm kiếm MEV có thể biết về các giao dịch liên tiếp này và cố gắng định vị các giao dịch của chính họ trước hoặc sau các nhà giao dịch được đề cập ở trên. Tuy nhiên, do các giao dịch được chia nhỏ hơn trên một chuỗi khối nên tổng giá trị MEV được trích xuất có thể nhỏ hơn nhiều.

Một ý tưởng thú vị khác mà chúng tôi đã đề cập trong bài viết trước đó là sử dụng công nghệ do huyền thoại Eric Budish và các đồng nghiệp của ông tiên phong.Đấu giá hàng loạt thường xuyên (FBA), xử lý các giao dịch theo kiểu đấu giá hàng loạt thay vì theo kiểu nối tiếp. Điều này nhằm giúp xác định sự chồng chéo về nhu cầu (CoW) và kết hợp các cơ hội kinh doanh chênh lệch giá vào thiết kế cơ chế thị trường. Điều này cũng giúp chống lại các trò chơi có độ trễ trong các khối xây dựng liên tiếp (hoặc các cuộc chiến phí ưu tiên trong các khối nối tiếp). Cảm ơn Michael Jordan (DBA) đã khiến chúng tôi chú ý đến bài viết này cũng như công việc của anh ấy trong việc giảm bớt độ trễ. Việc triển khai nó như một phần của quy tắc đặt hàng và lựa chọn ngã ba của Rollup cũng là một tính năng thú vị mà các nhà phát triển có thể sử dụng. đạt được sức hút đáng kể trong năm qua, đặc biệt là với Penumbra và CoWSwap. Một thiết lập khả thi có thể trông như thế này:

Trong thiết lập này, không có cuộc chiến tranh khí đốt đến trước, được phục vụ trước hoặc ưu tiên mà thay vào đó là các cuộc đấu giá theo đợt cuối khối dựa trên các đơn đặt hàng tích lũy trong thời gian giữa mỗi khối.

Nói chung, trong một thế giới mà hầu hết giao dịch đã chuyển sang trên chuỗi không giám sát, FBA có thể là một trong những cách hiệu quả hơn để khám phá giá thực, tùy thuộc vào thời gian khối. Việc tận dụng FBA cũng có nghĩa là có ít hoạt động chạy trước hơn đáng kể vì tất cả các đơn đặt hàng số lượng lớn đều có số lượng lớn và không được tiết lộ cho đến khi phiên đấu giá kết thúc (giả sử một số mã hóa được thiết lập). Ở đây, giá thanh toán thống nhất là điều quan trọng vì không có ích gì khi sắp xếp lại các giao dịch.

Cũng cần chỉ ra rằng một thiết kế tương tự như thiết kế chúng tôi vừa giới thiệu đã được thảo luận trên diễn đàn Ethresear.ch vào năm 2018 (Xem ở đây). Trong bài đăng, họ đã đề cập đến hai bài báo cung cấp cơ chế đấu giá hàng loạt trên Plasma (giống như phần tiền truyện của Rollup hiện đại), trong đó mỗi lô chấp nhận đơn đặt hàng mua các mã thông báo ERC 20 khác với một mức giá giới hạn tối đa nào đó. Các đơn đặt hàng này được thu thập trong những khoảng thời gian nhất định và cung cấp giá thanh toán thống nhất cho tất cả các cặp giao dịch mã thông báo. Ý tưởng chung đằng sau mô hình này là nó sẽ giúp loại bỏ hiện tượng chạy trước thường gặp trong các AMM phổ biến.

Một điều quan trọng khác cần lưu ý là trong các cài đặt này, trình sắp xếp thứ tự có thể cần một số động lực để thực thi (và thực thi) các quy tắc trên. Điều này thường bị bỏ qua, nhưng phần lớn cơ sở hạ tầng của mạng blockchain được điều hành bởi các công ty chuyên nghiệp, có chi phí hoàn toàn khác so với những người tham gia tại nhà thông thường. Nhìn chung, các biện pháp khuyến khích là một thành phần quan trọng trong việc triển khai cơ sở hạ tầng an ninh. Người sắp xếp trình tự và người xây dựng cũng có nhiều khả năng nỗ lực nhiều hơn khi các biện pháp khuyến khích phù hợp với các quy tắc được thực thi. Điều này có nghĩa là cũng cần có một thị trường hoạt động cho những cài đặt này. Rõ ràng, những thị trường như vậy đang trở nên tập trung hơn vì chi phí vốn cho việc chuyên môn hóa có thể cao. Do đó, những người thông minh nhất (và giàu nhất) có khả năng hợp nhất và chuyên môn hóa để nắm bắt càng nhiều giá trị càng tốt. Ở đây, luồng đơn đặt hàng độc quyền có thể là một mũi tên giáng vào đầu gối đối với một số người chơi, dẫn đến sự tập trung hóa tăng lên. Một khoản phí chuẩn chung có thể là đủ, nhưng nó không thực sự thúc đẩy người chơi giải trình tự hướng tới sự chuyên môn hóa. Do đó, bạn có thể muốn giới thiệu một số khái niệm khiến các nhà giao dịch hài lòng với kết quả thông qua các biện pháp khuyến khích phù hợp với tình huống cụ thể của bạn.

Điều này hẳn là hiển nhiên đối với hầu hết mọi người, nhưng vẫn cần được đề cập khi thảo luận về trình tự cấp độ tổng hợp. Nếu bạn có thể kiểm soát thứ tự, bạn có thể trích xuất giá trị của giao thức dễ dàng hơn. Điều này là do bạn kiểm soát quyền sắp xếp lại các giao dịch, thường dựa trên phí ưu tiên trên hầu hết các L1 (thiết lập MEV-boost-esque). Nó cung cấp cho bạn các khoản phí ưu tiên được trả bởi những người tham gia phức tạp, những người trích xuất giá trị trên chuỗi. Những người chơi này thường sẵn sàng trả những khoản tiền đáng kể (cho đến khi nó không còn mang lại giá trị). Tuy nhiên, hầu hết các bản tổng hợp hiện đều áp dụng cơ chế ai đến trước được phục vụ trước. Hầu hết việc khai thác MEV xảy ra thông qua các cuộc chiến về độ trễ, điều này gây căng thẳng nghiêm trọng cho cơ sở hạ tầng Rollup. Vì những lý do trên, chúng ta có thể thấy ngày càng nhiều Rollups bắt đầu triển khai cấu trúc xếp hạng với khái niệm phí ưu tiên (chẳng hạn như cơ chế nâng cao thời gian của Arbitrum).

Một ví dụ khác mà chúng tôi thích là Uniswap. Hiện tại, Uniswap với tư cách là một giao thức “tạo ra” rất nhiều sự kém hiệu quả. Những sự kém hiệu quả này bị khai thác bởi những người tham gia tìm cách trích xuất MEV (chênh lệch giá, gây thiệt hại cho các nhà cung cấp thanh khoản). Đồng thời, những người tham gia này đã trả khoản phí đáng kể để trích xuất giá trị, nhưng không có giá trị nào trong số đó lọt vào tay giao thức Uniswap cũng như chủ sở hữu mã thông báo của nó. Thay vào đó, một phần lớn giá trị trích xuất này được thanh toán thông qua MEV-Boost cho những người đề xuất (người xác thực) Ethereum để có quyền được đưa vào một khối cho phép nắm bắt giá trị tại một số điểm. Do đó, mặc dù có rất nhiều cơ hội MEV trong luồng đơn đặt hàng Uniswap nhưng không có cơ hội nào được Uniswap nắm bắt.

Nếu Uniswap có thể kiểm soát việc đặt hàng trong giao thức (và khả năng trích phí ưu tiên từ người tìm kiếm), thì nó có thể đạt được thương mại hóa và thậm chí có thể trả một số lợi nhuận đó cho chủ sở hữu mã thông báo, nhà cung cấp thanh khoản hoặc những người khác. Với những thay đổi đối với Uniswap (ví dụ: UniswapX, v.v.) hướng tới thực thi ngoài chuỗi (và Ethereum là lớp thanh toán), cơ chế này ngày càng có vẻ khả thi.

Nếu chúng tôi giả sử Rollup có cơ chế PBS một phần thì quy trình đặt hàng và thương mại hóa có thể như sau:

Từ đó, việc thương mại hóa người đặt hàng và người đề xuất Rollup có thể tuân theo công thức sau:

Khối lượng lưu hành (PoS) + thu nhập từ phí (+ưu tiên) - chi phí DA, state pub, storage

Bạn có thể tìm thấy một cách hay để xem giá trị hiện đang được trích xuất trên Ethereum (đặc biệt là chênh lệch giá) tại Mevboost.pics, nơi cung cấp cái nhìn tổng quan về số lượng giá trị thực sự có thể được trích xuất từ ​​​​sự kém hiệu quả.

Ngoài ra, việc tách các cuộc chiến khí gas có phí ưu tiên khỏi các cấu trúc ngoài chuỗi có thể giúp ngăn chặn sự gián đoạn chuỗi cung ứng bằng cách tách việc khai thác MEV vào môi trường thực thi. Tuy nhiên, xem xét rằng nếu cuộc bầu cử lãnh đạo diễn ra trên Rollup, hầu hết MEV sẽ được trích xuất trên Rollup, điều này sẽ tạo ra rất ít chỗ cho cấu trúc cơ bản trừ khi bao gồm lớp DA, phí ưu tiên của lớp thanh toán đến từ tích hợp thanh khoản hoặc các tính kinh tế khác của tỉ lệ.

Để làm rõ, nhiều cấu trúc trong số này có thể hoạt động như các cấu trúc hoàn toàn ngoài chuỗi mà không có bất kỳ cầu nối xác thực hoặc đảm bảo bảo mật mạnh mẽ nào. Tuy nhiên, có một số sự đánh đổi phải được thực hiện ở đó. Chúng ta bắt đầu thấy những thứ này xuất hiện nhiều hơn, cả hiện hữu lẫn vô hình. Một điều tôi muốn chỉ ra là thiết lập mô-đun không nhất thiết có nghĩa là một bản tổng hợp.

Các quy tắc đặt hàng ở trên là một ví dụ trong đó việc tinh chỉnh cơ sở hạ tầng có thể cải thiện đáng kể các ứng dụng được xây dựng trên cơ sở hạ tầng đó.