Làm thế nào để đạt được trình tự giao dịch công bằng với MEV mô-đun?

Tác giả: Maven11

Trình biên dịch: Luffy, Foresight News

Trong hai phần đầu tiên của loạt bài này, chúng tôi tập trung vào các vấn đề kỹ thuật phát sinh khi tách ngăn xếp và những cải tiến cần được thực hiện trong thế giới mô-đun. Chúng tôi đã đề cập đến một số tiến bộ công việc để giải quyết các vấn đề phát sinh tự nhiên trong thiết lập tên miền chéo. Tuy nhiên, trong phần cuối 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 xem xét cách mô-đun hóa, 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. Chương cuối cùng của loạt bài này sẽ xem xét sự sáng tạo và khả năng thú vị và độc đáo trong mô-đun cho các nhà phát triển để tạo trải nghiệm người dùng Web2 với khả năng xác minh Web3.

Lý do đằng sau việc xây dựng mô-đun không chỉ là để phục vụ cho câu chuyện hoặc chỉ là 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 hơn. Khi xây dựng các hệ thống mô-đun và chuyên dụng, một số tính năng độc đáo xuất hiện. Một số trong số chúng là rõ ràng, trong khi những người khác ít rõ ràng hơn. Do đó, mục tiêu của chúng tôi là cung cấp tổng quan về các khả năng của hệ thống mô-đun mà bạn chưa biết, 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à mô-đun cung cấp cho các 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 dẫn đến 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 thiết lập các quy tắc hoặc sắp xếp lại thứ tự mà các giao dịch được thực hiện.

Đối chiếu có thể kiểm chứng (sau đây gọi là VSR) là một trong những cơ hội thú vị được cung cấp bởi phân loại có kiểm soát, đặc biệt là đối với các nhà phát triển quan tâm đến việc xây dựng các hệ thống giao dịch "công bằng hơn" về mặt thực hiện. Rõ ràng, mối quan hệ giữa tổn thất của Nhà cung cấp thanh khoản và 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 chạm vào quá nhiều điều này. Hãy nhớ rằng các cài đặt mà chúng tôi sẽ giải thích chủ yếu dành cho AMM chứ không phải cho mô hình sổ đặt hàng. Ngoài ra, CLOB (và thậm chí CEX) cũng 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ột thiết lập ngoài chuỗi, có một nhu cầu rõ ràng cho 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à phần lớn các nhà đầu tư bán lẻ chưa (hoặc không có khả năng) áp dụng phương pháp bảo tồn. Hầu hết các Ví / DEX cũng không triển khai mempool, RPC riêng 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 (cho dù đó là giao diện người dùng tổng hợp hay giao diện người dùng DEX). Do đó, trừ khi ứng dụng can thiệp trực tiếp vào các quy trình của nó và cách xử lý lệnh, người dùng cuối có thể gặp phải tình trạng thực thi kém thỏa đáng.

Khi chúng ta nghĩ về nơi chuỗi cung ứng giao dịch được đặt hàng, vai trò của VSR trở nên rõ ràng. Nó nằm ở nơi những người tham gia chuyên nghiệp sắp xếp (hoặc bao gồm) các giao dịch, thường dựa trên một số khoản phí đấu giá hoặc phí cơ bản. Trình tự này rất quan trọng vì nó xác định giao dịch nào được thực hiện và khi nào. Về cơ bản, người có thẩm quyền phân loại có khả năng trích xuất MEV, thường dưới dạng phí ưu tiên (hoặc tiền boa).

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

Ngoài ra, có một số MEV rất quan trọng, chẳng hạn như Arbitrage, thanh lý, v.v. Một ý tưởng là tạo ra một kênh "đường cao tốc" ở đầu khối, nhắm mục tiêu cụ thể đến các Arbitrageurs và người thanh lý trong Danh sách cho phép, 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ế các sàn giao dịch DEX đáng tin cậy với các đối chiếu có thể kiểm chứng", Matheus V., X. Ferreira và David C. Parkes đề xuất một mô hình trong đó trình tự của một khối phải tuân theo một loạt các ràng buộc thực hiện đối chiếu (và những ràng buộc đó có thể kiểm chứng được). Không tuân thủ các quy tắc đã đặt, người quan sát có thể tạo ra bằng chứng về sự thất bạ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 hợp lệ). Ý tưởng chính về cơ bản là cung cấp đảm bảo giá thực hiện cho người dùng cuối (nhà giao dịch). Đảm bảo này đảm bảo rằng giao dịch được thực hiện tốt như giao dịch duy nhất trong khối (rõ ràng, nếu chúng ta giả định lệnh mua / bán / mua / bán dựa trên cơ sở ai đến trước được phục vụ trước, có một số độ trễ nhất định liên quan ở đây). Ý tưởng cơ bản của các đề xuất trong bài báo là nếu chúng hoạt động ở mức giá tốt hơn giá có sẵn ở đầu khối, các đối chiếu này sẽ hạn chế người xây dựng (trong kịch bản PBS) hoặc trình sắp xếp chuỗi chỉ bao gồm các giao dịch theo cùng một hướng (nói bán / bán). Ngoài ra, nếu có tình huống bạn thực hiện bán vào cuối một loạt các giao dịch 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ể chỉ ra rằng người tìm kiếm (hoặc người xây dựng / trình tự) đang sử dụng các giao dịch mua này để đẩy giá có lợi cho họ. Điều này về cơ bản có nghĩa là các quy tắc của giao thức đảm bảo rằng người dùng sẽ không được sử dụng để cung cấp giá tốt hơn (tức là MEV) cho người khác hoặc khiến giá giảm do phí ưu tiên. Rõ ràng, lỗ hổng của quy tắc ở đây (trong trường hợp bán nhiều hơn mua và ngược lại) là bạn có thể nhận được giá đuôi dài tương đối kém.

Đối với một nền tảng Hợp đồng thông minh nói chung, gần như không thể xây dựng các quy tắc này hoàn toàn trên chuỗi 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 cố gắng buộc những người ở đầu khối phải trả phí ưu tiên sẽ tốn kém 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 môi trường thực thi của họ sẽ hoạt động. Cho dù đó là đối chiếu, sử dụng một máy ảo khác hoặc thực hiện các thay đổi tùy chỉnh đối với máy ảo 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, tùy thuộc vào sản phẩm của họ.

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

Một ý tưởng khả thi khác là chia nhỏ giao dịch. Hãy tưởng tượng một nhóm các giao dịch, làm thế nào để thực hiện các giao dịch lệnh lớn (gây ra nhiều trượt giá) và 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), điều này có công bằng với người dùng cuối không?

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 đặt 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 để chia tách giao dịch các lệnh lớn hơn có thể dẫn đến việc thực hiện hiệu quả hơn cho đại đa số người dùng. Dù bằng cách nào, một mối quan tâm là những người tìm kiếm MEV có thể nhận thức được các giao dịch tuần tự này và cố gắng định vị giao dịch của họ trước hoặc sau các nhà giao dịch nói trên. Tuy nhiên, do các giao dịch phân tách quy mô nhỏ trên một loạt các khối, 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 trước đó trong bài đăng là sử dụng đấu giá số lượng lớn thường xuyên (FBA), được ủng hộ bởi huyền thoại Eric Budish và các đồng nghiệp của ông, để xử lý các giao dịch theo kiểu đấu giá số lượng lớn thay vì kiểu nối tiếp. Điều này là để giúp xác định nhu cầu chồng chéo (CoW) và tích hợp các cơ hội chênh lệch giá vào thiết kế cơ chế thị trường. Điều này cũng giúp "chiến đấu" với các trò chơi bị trì hoãn trong các bản dựng Khối liên tục (hoặc các trận chiến chi phí ưu tiên trong Khối nối tiếp). Cảm ơn Michael Jordan (DBA) đã đưa bài báo này đến sự chú ý của chúng tôi và vì công việc của anh ấy trong việc giảm thiểu Latency Roast. Triển khai nó như một phần của lựa chọn ngã ba và đối chiếu của Rollup cũng là một thiết lập thú vị mà các nhà phát triển có thể sử dụng và chúng tôi đã thấy lực kéo đáng kể của nó trong năm qua, đặc biệt là đối với Penumbra và CoWSwap. Một thiết lập có thể sẽ trông như thế này:

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

Nói chung, nơi hầu hết các giao dịch đã chuyển sang thế giới "on-chain" 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. Tận dụng FBA cũng có nghĩa là vì tất cả các đơn đặt hàng số lượng lớn là số lượng lớn và sẽ không được tiết lộ cho đến khi phiên đấu giá kết thúc (giả sử có một số thiết lập tiền điện tử), sẽ giảm đáng kể các giao dịch chạy trước. Giá thanh toán là chìa khóa ở đây, vì không có điểm nào trong việc sắp xếp lại các giao dịch.

Cũng cần lưu ý rằng vào năm 2018, các thiết kế như những thiết kế chúng tôi vừa đề cập đã được thảo luận trên các diễn đàn Ethresear.ch (xem tại đây). Trong bài đăng, họ đề cập đến hai bài báo cung cấp cơ chế đấu giá số lượng lớn trên Plasma (hơi giống phần tiền truyện của Rollups hiện đại), trong đó mỗi lô chấp nhận đơn đặt hàng để mua thêm Token ERC20 ở một mức giá giới hạn tối đa nhất định. Các lệnh này được thu thập theo các 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 Token. Ý tưởng tổng thể đằng sau mô hình này là nó sẽ giúp loại bỏ hiện tượng chạy trước phổ biến trong các AMM phổ biến.

Một điều quan trọng khác cần lưu ý là trong các thiết lập này, trình sắp xếp chuỗi có thể cần một số ưu đãi để 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 ngành, chi phí khá khác so với người tham gia hộ gia đình trung bình. Nói chung, ưu đãi là một phần quan trọng trong việc triển khai cơ sở hạ tầng bảo mật. Người sắp xếp trình tự và nhà xây dựng cũng có nhiều khả năng nỗ lực hơn khi các ưu đãi phù hợp với các quy tắc được thực thi. Điều này có nghĩa là các thiết lập này cũng phải có một thị trường hoạt động. Rõ ràng, loại thị trường này đang trở nên tập trung hơn, vì chi phí vốn cho chuyên môn hóa có thể cao. Do đó, Satoshi (và giàu có 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, dòng lệnh độc quyền có thể là một mũi tên trên đầu gối đối với một số người tham gia, dẫn đến sự gia tăng tập trung. Một khoản phí Benchmark chung có thể là đủ, nhưng nó không thực sự thúc đẩy những người tham gia xếp hạng theo hướng 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 ưu đãi phù hợp với tình huống cụ thể của bạn.

Điều này rõ ràng đối với hầu hết mọi người, nhưng nó vẫn cần được đề cập khi thảo luận về thứ tự các cấp độ Rollup. Nếu bạn có thể kiểm soát thứ tự, việc "trích xuất" giá trị của giao thức sẽ 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 (cài đặt MEV-boost-esque) trên hầu hết các L1. 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 tham gia này thường sẵn sàng trả một số tiền đáng kể (cho đến khi nó không còn có thể cung cấp giá trị). Tuy nhiên, hầu hết các bản tổng hợp hiện tại chủ yếu dựa trên cơ sở ai đến trước được phục vụ trước. Hầu hết các hoạt động khai thác MEV được thực hiện thông qua các cuộc chiến tranh bị trì hoãn, điều này gây căng thẳng nghiêm trọng cho cơ sở hạ tầng Rollup. Do những điều trên, chúng ta có thể thấy ngày càng nhiều bản tổng hợp bắt đầu thực hiện cấu trúc sắp xếp với khái niệm phí ưu tiên (ví dụ: cơ chế tăng cường 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ự thiếu hiệu quả. Những sự thiếu hiệu quả này được khai thác bởi những người tham gia tìm cách trích xuất MEV (Arbitrage với chi phí của Nhà cung cấp thanh khoản). Đồng thời, những người tham gia này phải trả rất nhiều phí để trích xuất giá trị, nhưng không có giá trị nào trong số đó rơi vào tay giao thức Uniswap hoặc chủ sở hữu Token của nó. Thay vào đó, một phần đáng kể của giá trị trích xuất này được trả một khoản phí ưu tiên cho những người đề xuất Ethereum (người xác nhận) thông qua MEV-Boost để 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 cho các luồng lệnh Uniswap, nhưng không có cơ hội nào trong số đó bị 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 xuất phí ưu tiên từ người tìm kiếm), nó có thể được thương mại hóa và thậm chí có thể trả một số lợi nhuận này cho chủ sở hữu Token, 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.) chuyển sang thực thi ngoài chuỗi (và Ethereum như một lớp thanh toán), cơ chế này ngày càng có khả năng.

Nếu chúng ta giả sử một bản tổng hợp với cơ chế PBS một phần, luồng đặt hàng và quy trình thương mại hóa có thể trông như thế này:

Do đó, việc thương mại hóa các trình tự tổng hợp và người đề xuất có thể tuân theo công thức sau:

Phát hành (PoS) + Thu nhập phí (+ ưu tiên) - Chi phí DA, quán rượu nhà nước, lưu trữ

Một cách tốt để xem bao nhiêu giá trị hiện đang được rút trên Ethereum (đặc biệt là Arbitrage) có thể được tìm thấy trên Mevboost.pics, cung cấp một cái nhìn tổng quan tốt về bao nhiêu giá trị thực sự có thể được trích xuất từ sự thiếu hiệu quả.

Ngoài ra, việc tách cuộc chiến khí đốt phí ưu tiên khỏi 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 cô lập 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ử đơn vị chỉ huy diễn ra trên Bản tổng hợp, phần lớn MEV sẽ được rút ra trên Bản tổng hợp, điều này để lại 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ừ hợp nhất thanh khoản hoặc các nền kinh tế theo quy mô khác.

Để 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ần bất kỳ cầu nối xác minh hoặc đảm bảo an ninh 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 nhiều thứ này xuất hiện, cả tồn tại và vô hình. Một điều tôi muốn chỉ ra là mô-đun không nhất thiết có nghĩa là rollup.

Đối chiếu ở trên đại diện cho một ví dụ trong đó tinh chỉnh cơ sở hạ tầng có thể cải thiện đáng kể ứng dụng được xây dựng trên nó.