Khám phá MEV: Phương pháp thiết kế và thách thức đối với các giải pháp OEV

Hầu hết tài liệu trong bài viết này được lấy từ "Khám phá không gian thiết kế và những thách thức đối với việc triển khai Oracle trong giao thức DeFi", với rất nhiều thay đổi trên cơ sở này

Tóm tắt:Oracles luôn đóng vai trò không thể thiếu trong hệ sinh thái DeFi Vì hợp đồng thông minh chỉ có thể truy cập dữ liệu trên chuỗi và không thể lấy trực tiếp thông tin từ bên ngoài chuỗi, nên oracle cần đóng vai trò trung gian để đưa dữ liệu ngoài chuỗi vào. chuỗi, để các hợp đồng thông minh có thể dựa trên chuỗi Tải xuống dữ liệu để xử lý giao dịch tự động. Hầu hết các giao thức DeFi đều dựa vào nguồn cấp dữ liệu giá oracle để xử lý các hợp đồng phái sinh, thanh lý các tài sản kém hiệu quả, v.v.

Khối lượng vốn hiện tại trong hệ sinh thái DeFi vượt quá 80 tỷ đô la Mỹ, hầu hết trong số đó đều có liên quan đến oracle theo một cách nào đó. Tuy nhiên, các oracle truyền thống đang cập nhật giá chậm hơn, điều này dẫn đến sự xuất hiện của một MEV đặc biệt dành cho oracle: OEV. Các tình huống phổ biến đối với OEV bao gồm lợi nhuận chạy trước, chênh lệch giá và thanh lý của oracle. Hiện nay, ngày càng có nhiều giải pháp được đề xuất để giảm thiểu tác động tiêu cực của OEV.

Bài viết này sẽ giới thiệu các giải pháp OEV hiện có khác nhau, thảo luận về ưu điểm và nhược điểm của chúng, đồng thời đề xuất hai ý tưởng mới để giải thích chi tiết về giá trị, vấn đề cần giải quyết và các yếu tố hạn chế của chúng.

MEV (OEV) do oracles tạo ra

Để giúp mọi người dễ hiểu nội dung chính của bài viết này hơn, trước tiên chúng ta thảo luận về push oracles và kéo Một sự phổ biến ngắn gọn của nhà tiên tri. Oracle kiểu đẩy đề cập đến máy oracle chủ động gửi dữ liệu đến hợp đồng thông minh trên chuỗi. Ví dụ: Chainlink chủ yếu là oracle kiểu kéo; máy oracle kiểu kéo chủ động yêu cầu dữ liệu từ DApp và máy oracle nhận được dữ liệu. yêu cầu. Cung cấp dữ liệu sau.

Sự khác biệt giữa hai chế độ này là push oracle có hiệu quả dữ liệu mạnh mẽ và phù hợp với các tình huống nhạy cảm với dữ liệu thời gian thực. Tuy nhiên, ở chế độ này, oracle cần phải làm như vậy. được cập nhật thường xuyên. Việc gửi dữ liệu lên chuỗi sẽ tiêu tốn nhiều gas hơn. Pull oracle linh hoạt hơn và chỉ cung cấp dữ liệu mới khi DApp cần dữ liệu. Điều này tiêu tốn ít gas hơn nhưng dữ liệu có độ trễ.

Vì nền tảng Defi yêu cầu các nhà tiên tri cung cấp dữ liệu về nguồn cấp dữ liệu giá, nên nếu việc cập nhật nguồn cấp dữ liệu giá bị chậm, MEV có thể bị thu thập bởi các robot chuyên kinh doanh chênh lệch giá. MEV dựa trên các nhà tiên tri này được gọi là OEV. Các kịch bản lợi nhuận chính liên quan đến OEV bao gồm chạy trước, chênh lệch giá và thanh lý. Trong phần thảo luận sau, chúng tôi sẽ phác thảo các kịch bản lợi nhuận khác nhau do OEV gây ra và khám phá các giải pháp OEV khác nhau, cũng như những ưu điểm và nhược điểm của chúng.

Cách tạo và nắm bắt OEV

Theo kết quả quan sát được trong thực tế, có ba cách chính để hiện thực hóa OEV:

< mạnh>1. Giao dịch chạy trước. Ví dụTrình tìm kiếm MEV trong mạng Ethereum sẽ giám sát dữ liệu giao dịch được tải lên chuỗi trong thời gian thực và tìm kiếm các cơ hội MEV. Máy oracle cần gửi dữ liệu đến chuỗi để cập nhật nguồn cấp dữ liệu giá. Những dữ liệu này sẽ được tích lũy trong nhóm giao dịch trước khi được tải lên chuỗi. Người tìm kiếm sẽ theo dõi các giao dịch đang chờ xử lý này, dự đoán những biến động giá sắp tới của chuỗi. tài sản trên chuỗi và là người đầu tiên cập nhật giá. Phục kích một số lệnh mua và bán.

Nhiều nền tảng phái sinh đã phải chịu tác động tiêu cực của các giao dịch chạy trước, chẳng hạn như vì Do các giao dịch chạy trước thường xuyên nên lợi nhuận của GMX đã giảm 10%. Phải đến khi giao thức được cập nhật, GMX mới bàn giao các oracle được kết nối cho KeeperDAO để lập lịch thống nhất và vấn đề thu thập OEV mới được giảm bớt. Chúng tôi sẽ giải thích ngắn gọn về giải pháp được GMX áp dụng sau.

2. Kinh doanh chênh lệch giá: Sử dụng độ trễ trong cập nhật dữ liệu oracle để tiến hành chênh lệch giá không rủi ro giữa các thị trường khác nhau. Ví dụ: cập nhật giá tài sản trên một nền tảng phái sinh trên chuỗi nhất định có độ trễ 10 giây. Nếu giá giao ngay ETH của Binance tăng đột ngột và giá ETH trên chuỗi không thay đổi kịp thời, thì robot kinh doanh chênh lệch giá. có thể cập nhật ngay giá trên chuỗi. Mở một hợp đồng mua và đợi nguồn cấp dữ liệu giá Chainlink được cập nhật trước khi đóng vị thế để kiếm lợi nhuận.

Trường hợp trên đơn giản hóa tình hình thực tế, nhưng nó minh họa các cơ hội chênh lệch giá được tạo ra do cập nhật giá bị trì hoãn. Trọng tài có thể thu được OEV từ nền tảng Defi. Tất nhiên, những OEV thu được này sẽ. cuối cùng dẫn đến mất LP (lông đến từ cừu).

Hiện tượng oracle chạy trước và kinh doanh chênh lệch giá thường được gọi là "dòng độc hại" trong các giao thức phái sinh,vì có sự không nhất quán về thông tin đằng sau các giao dịch này. Một cách đối xứng, các nhà kinh doanh chênh lệch giá có thể nắm bắt được rủi ro-. lợi nhuận miễn phí, nhưng phải trả chi phí cho các nhà cung cấp LP/thanh khoản trong giao thức Defi. Các giao thức DeFi lâu đời như Synthetix đã bị cản trở bởi kiểu tấn công OEV này kể từ năm 2018 và đã thử nhiều phương pháp để giảm thiểu tác động tiêu cực của nó. Chúng tôi sẽ giải thích ngắn gọn các biện pháp đối phó như vậy sau.

3. Thanh lý: Đối với các hợp đồng cho vay, nếu việc cập nhật giá tài sản bị trì hoãn, sẽ có lợi cho một số nhà thanh lý phản ứng nhanh, Nắm bắt không hiệu quả thanh lý do cập nhật giá không kịp thời và kiếm thêm thu nhập. Những hành vi này sẽ làm suy yếu hiệu quả thị trường và có tác động tiêu cực đến tính công bằng của nền tảng Defi.

Thành phần thanh lý là trọng tâm trong bất kỳ giao thức DeFi nào liên quan đến đòn bẩy và mức độ chi tiết của các cập nhật nguồn cấp dữ liệu giá đóng vai trò chính trong hiệu quả thanh lý. Nếu push oracle dựa trên ngưỡng, tức là nguồn cấp dữ liệu giá chỉ được cập nhật khi giá thay đổi đạt đến một mức độ nhất định, điều này có thể ảnh hưởng đến quá trình thanh lý. Giả sử giá ETH ngoài chuỗi giảm và vị thế trên một thỏa thuận cho vay nhất định đã đạt đến ngưỡng thanh lý, nhưng mức độ biến động giá không đáp ứng ngưỡng để oracle cập nhật nguồn cấp dữ liệu giá, vì vậy oracle không cập nhật dữ liệu sẽ ảnh hưởng đến hiệu suất thanh lý công việc, điều này có thể gây ra hậu quả tiêu cực hơn nữa.

Đưa ra một ví dụ đơn giản, một vị thế tài sản thế chấp nhất định đang phải đối mặt với việc thanh lý do giá giảm khẩn cấp, nhưng do nhà tiên tri không cập nhật dữ liệu kịp thời nên giá trên chuỗi vẫn chưa thay đổi. Trong khoảng thời gian này, Người tìm kiếm gửi trước yêu cầu thanh toán giao dịch và trả Gas cao hơn để có được lợi thế ưu tiên cho việc đóng gói trên chuỗi. Khi giá trên chuỗi được cập nhật, Người tìm kiếm trực tiếp trở thành người thanh lý và kiếm lợi nhuận. Đồng thời, do cập nhật giá chậm trễ, chủ sở hữu tài sản thế chấp ban đầu không có thời gian để đảm bảo vị thế của mình và chịu thêm tổn thất.

Thông thường các giao thức DeFi cung cấp một phần tài sản thế chấp được thanh lý làm phần thưởng cho những người thanh lý. Các giao thức DeFi lớn như Aave đã phân phối hơn 38 triệu đô la khuyến khích thanh lý chỉ riêng trên Ethereum vào năm 2022. Đây không chỉ là sự bù đắp quá mức cho những người thanh lý bên thứ ba. cũng gây hại cho người dùng. Ngoài ra, các cuộc chiến khí đốt sẽ mở rộng cơ hội nắm bắt MEV từ nơi có hiệu ứng MEV đến toàn bộ chuỗi cung ứng MEV.

Trong số đó, OEV bị bắt trong các cuộc tấn công và chênh lệch giá trực tiếp sẽ gây tổn hại đến lợi ích của các nhà cung cấp thanh khoản DeFi; trong khi OEV bị bắt trong quá trình thanh lý đối với người đi vay sẽ bị mất trong quá trình thanh lý đối với người cho vay. , sự chậm trễ trong báo giá oracle dẫn đến giá trị tài sản thế chấp thấp hơn dự kiến.

Tóm lại, dù nắm giữ OEV bằng cách nào thì cũng sẽ gây thiệt hại cho những người khác trên thị trường, cuối cùng chỉ có bản thân người nắm giữ OEV mới được hưởng lợi, điều này ảnh hưởng tiêu cực đến tính công bằng. và UX của DeFi.

Các giải pháp OEV hiện tại

Dưới đây chúng ta sẽ thảo luận về các phương thức tiên đoán đẩy, kéo và khác trong bối cảnh nói trên, cũng như các giải pháp OEV trên thị trường hiện tại tồn tại và được xây dựng dựa trên chúng, đồng thời phân tích tính hiệu quả của chúng, đồng thời khám phá sâu sắc sự đánh đổi mà các giải pháp này mang lại để giải quyết các vấn đề về OEV, bao gồm tăng mức độ tập trung hoặc giả định tin cậy hoặc hy sinh UX, v.v.

Điều gì sẽ xảy ra nếu chúng ta chỉ sử dụng pull oracles?

Chúng tôi đã đề cập đến máy pull oracle trước đó. Đặc điểm của nó là Dapp cần chủ động yêu cầu dữ liệu từ máy oracle. Là đại diện của pull oracles, một trong những ưu điểm của Pyth là nó có thể sử dụng TPS cao và độ trễ thấp của kiến ​​trúc Solana để tạo mạng Pythnet nhằm thu thập, tổng hợp và phân phối dữ liệu. Các nhà xuất bản trên Pythnet sẽ cập nhật thông tin về giá cứ sau 300 mili giây. Các DApp có nhu cầu có thể truy vấn dữ liệu mới nhất thông qua API và xuất bản nó lên chuỗi.

Ở đây cần lưu ý rằng nhà xuất bản cập nhật thông tin về giá cứ sau 300 mili giây, điều này nghe giống như logic của một nhà tiên tri đẩy. Tuy nhiên, logic của Pyth là "cập nhật đẩy, truy vấn kéo", nghĩa là, mặc dù dữ liệu đi vào Pythnet thông qua cập nhật đẩy, các ứng dụng trên chuỗi hoặc các mạng blockchain khác có thể sử dụng API Pyth hoặc lớp Wormhole cầu nối chuỗi chéo. để "kéo" dữ liệu mới nhất.

Tuy nhiên, chỉ sử dụng oracle kiểu kéo không thể giải quyết triệt để vấn đề chạy trước và chênh lệch giá. Người dùng vẫn có thể chọn mức giá đáp ứng các điều kiện cụ thể để giao dịch, dẫn đến vấn đề "lựa chọn đối thủ". Cụ thể trong trường hợp máy oracle, do việc cập nhật giá của máy oracle bị chậm trễ, Người tìm kiếm có thể chủ động chọn nút thời gian có lợi cho mình để giao dịch bằng cách theo dõi chênh lệch thời gian cập nhật giá trên chuỗi. nút thời gian này thường hết hạn nhưng sẽ không có sẵn trong tương lai. Giá được cập nhật không chính xác. Hành vi này dẫn đến giá thị trường không công bằng, cho phép người tìm kiếm lợi dụng sự bất cân xứng thông tin để thu được lợi nhuận không rủi ro nhưng gây tổn hại đến lợi ích của những người tham gia thị trường khác.

Nói cách khác, trong các pull oracle, các cuộc tấn công chênh lệch giá do sự chậm trễ về giá vẫn tồn tại. Trong tài liệu Pyth, người ta đề xuất ngăn chặn cuộc tấn công này thông qua "kiểm tra độ cũ". "Kiểm tra tính cũ"là cơ chế được sử dụng để đảm bảo tính tức thời của dữ liệu hoặc thông tin về giá được sử dụng trong giao dịch.

Cụ thể, việc kiểm tra tính cũ sẽ xác minh xem dữ liệu giá được sử dụng có được tạo trong khoảng thời gian hợp lý hay không nhằm ngăn chặn các nhà giao dịch sử dụng thông tin giá đã lỗi thời để giao dịch, từ đó giảm thiểu tình trạng chênh lệch giá và các hoạt động giao dịch không công bằng.

Nhưng trong thực tế triển khai, rất khó xác định được ngưỡng thời gian tối ưu. Chúng ta có thể xem lại ví dụ trước để hiểu việc kiểm tra độ ổn định Giả sử rằng sàn giao dịch hợp đồng vĩnh viễn sử dụng nguồn giá ETH/USD của Pyth và đặt ngưỡng kiểm tra độ ổn định là 20 giây. Điều này có nghĩa là dấu thời gian của giá Pyth khác với. quá trình thực hiện xuôi dòng. Dấu thời gian khối của giao dịch chỉ có thể khác nhau 20 giây. Nếu vượt quá khung thời gian này, giá sẽ được coi là cũ và không có sẵn. Thiết kế này nhằm mục đích ngăn chặn việc chênh lệch giá khi hết hạn.

Việc rút ngắn ngưỡng thời gian kiểm tra độ cũ có vẻ là một giải pháp tốt, nhưng đây có thể dẫn đến việc khôi phục giao dịch trên mạng với thời gian chặn không chắc chắn, do đó ảnh hưởng đến trải nghiệm người dùng. Nguồn giá của Pyth dựa trên các cầu nối chuỗi chéo vẫn được sử dụng làm ví dụ. Nút Guardian của nó được gọi là "Wormhole Keeper". Oracle phải có đủ thời gian đệm để cho phép Wormhole Keeper xác nhận giá và cho phép chuỗi mục tiêu xử lý. giao dịch và ghi lại nó trong khối.

Đấu giá dòng lệnh Oracle (OFA)

Để giải quyết tác động tiêu cực của MEV, một giải pháp mới-Đấu giá độc quyền của Oracle Đấu giá trực tuyến (OFA) đang dần nổi lên và hiệu quả là rất đáng kể. OFA là dịch vụ đấu giá chung của bên thứ ba cho phép nhà tiên tri đóng dấu thông tin nguồn cấp giá mới nhất bằng chữ ký và gửi nó đến nền tảng đấu giá ngoài chuỗi và những người khác có thể gửi thông tin nguồn cấp giá cho chuỗi trên của họ thay mặt. Sau khi các hoạt động cập nhật nguồn cấp dữ liệu giá như vậy được tải lên chuỗi, các cơ hội MEV sẽ xuất hiện. Do đó, MEV Searcher sẽ giám sát thông tin nguồn cấp giá do máy oracle gửi tới nền tảng đấu giá và tận dụng tối đa các cơ hội.

Người tìm kiếm thường sẵn sàng đặt giá thầu và áp dụng để đẩy thông báo nguồn cấp dữ liệu giá đến chuỗi thay vì lời tiên tri. Sau đó, Người tìm kiếm tận dụng cơ hội này để xây dựng một giao dịch MEV và biến mình thành người thu được nhiều lợi nhuận nhất. Tất nhiên, Người tìm kiếm phải tham gia đấu giá. Trong quá trình đấu giá, anh ta sẽ trả một số tiền, số tiền này sẽ được nền tảng đấu giá phân phối cho oracle hoặc nhiều người hơn. Điều này tương đương với việc phân phối một phần lợi nhuận của người chơi MEV cho người khác. ., để giảm bớt vấn đề OEV.

Quy trình cụ thể của OFA như sau:

1. Gửi giao dịch

Tất cả luồng giao dịch đang chờ xử lý sẽ được chuyển đến nhóm giao dịch OFA riêng tư thay vì được gửi trực tiếp đến chuỗi. Để đảm bảo tính công bằng, nhóm giao dịch vẫn ở chế độ riêng tư và chỉ những người tham gia đấu giá mới có thể truy cập được.

2. Đấu giá đấu giá

Nhóm giao dịch là nền tảng nơi OFA tiến hành đấu giá. Giá đấu giá dựa trên giá trị dự kiến ​​​​được trích từ đơn đặt hàng, bao gồm các yếu tố như loại giao dịch, giá gas hiện tại và lợi nhuận MEV dự kiến.

3. Lựa chọn và thực hiện

Người tìm kiếm chiến thắng trả số tiền đấu thầu và nhận được quyền thực hiện giao dịch vì lợi ích riêng của mình. các quỹ có thể trích xuất MEV tối đa để sắp xếp các giao dịch và gửi chúng vào chuỗi.

4. Phân phối thu nhập

Bước này là cốt lõi của OFA. Để có được cơ hội MEV, Người tìm kiếm sẽ trả thêm số tiền đấu thầu. sẽ được gửi vào hợp đồng thông minh và phân phối theo một tỷ lệ nhất định để bù đắp cho giao thức và người dùng giá trị bị mất trong OFA.

Từ quan điểm dữ liệu, OFA đã giảm bớt đáng kể các vấn đề về MEV và OEV Tỷ lệ áp dụng các giải pháp như vậy đã cho thấy xu hướng tăng nhanh hiện nay. Các giao dịch Ethereum Square được thực hiện thông qua các kênh riêng tư (bao gồm RPC và OFA riêng tư). Có thể thấy OFA có tiềm năng phát triển rất lớn trong tương lai.

Nhưng có một vấn đề khi triển khai sơ đồ OFA chung, đó là oracle không thể dự đoán liệu bản cập nhật có tạo ra OEV hay không và nếu không, OFA sẽ gây ra độ trễ bổ sung vì oracle cần thực hiện các hoạt động bổ sung để gửi giao dịch đến nền tảng đấu giá. Mặt khác, cách đơn giản nhất để tối ưu hóa OEV và giảm độ trễ là chuyển giao tất cả các luồng đơn hàng tiên tri cho người tìm kiếm thống trị, nhưng làm như vậy rõ ràng sẽ mang lại rủi ro tập trung đáng kể và khuyến khích việc khai thác tiền thuê một cách trá hình, cuối cùng sẽ gây thiệt hại cho trải nghiệm của người dùng.

Thông tin cập nhật của OFA thông qua giá đấu giá không bao gồm các thông tin cập nhật dựa trên quy tắc hiện có. vẫn đi qua vùng bộ nhớ chung. Cơ chế này đảm bảo rằng các cập nhật về giá của oracle và mọi doanh thu bổ sung được tạo ra từ đó vẫn nằm trong lớp ứng dụng. Đồng thời, cơ chế này cũng cải thiện mức độ chi tiết của dữ liệu, cho phép người tìm kiếm yêu cầu cập nhật nguồn dữ liệu mà nút oracle không phải chịu thêm chi phí cho việc cập nhật thường xuyên hơn.

OFA đặc biệt hiệu quả trong quá trình thanh lý vì nó có thể cung cấp thông tin cập nhật chi tiết hơn về giá, tối đa hóa vốn hoàn trả cho những người cầm cố đã thanh lý, giảm phần thưởng mà giao thức trả cho người thanh lý và Thu nhập tăng thêm từ cuộc đấu giá người thanh lý bị loại bỏ và trả lại cho người dùng.

Tuy nhiên,Mặc dù OFA đã giải quyết được vấn đề chạy trước và kinh doanh chênh lệch giá ở một mức độ nhất định nhưng nó vẫn để lại một số vấn đề chưa được giải quyết. Trong kịch bản cạnh tranh hoàn hảo và đấu giá kín một giá, cuộc đấu giá sẽ tạo ra doanh thu bổ sung từ các giao dịch chạy trước gần với chi phí không gian khối cần thiết để thực hiện hoạt động MEV này, đồng thời, mức độ chi tiết số lượng cập nhật giá tăng lên. Nó cũng sẽ làm giảm việc tạo ra các cơ hội kinh doanh chênh lệch giá.

Hiện tại, để triển khai OFA dành riêng cho oracles, bạn có thể chọn tích hợp với dịch vụ đấu giá của bên thứ ba (chẳng hạn như OEV-Share) hoặc trực tiếp sử dụng dịch vụ đấu giá dưới dạng ứng dụng DeFi và để nó xây dựng chính nó.

API3 sử dụng rơle OEV dựa trên khái niệm Flashbots làm API để cung cấp dịch vụ bảo vệ DoS khi tiến hành đấu giá. Người chuyển tiếp chịu trách nhiệm thu thập các giao dịch meta từ các nhà tiên tri, lọc và tổng hợp giá thầu của người tìm kiếm cũng như phân phối số tiền thu được trong một môi trường không đáng tin cậy. Người chiến thắng giá thầu cần chuyển số tiền giá thầu sang hợp đồng proxy do giao thức kiểm soát, sau đó dữ liệu chữ ký do rơle cung cấp sẽ cập nhật nguồn giá.

Một lựa chọn khác là giao thức không dựa vào một bên trung gian và trực tiếp xây dựng nó sở hữu dịch vụ Đấu giá gốc để nắm bắt và thoái vốn tất cả doanh thu bổ sung được trích từ OEV. Dự án BBOX có kế hoạch đưa các cuộc đấu giá vào cơ chế thanh lý của mình để thu giữ OEV và trả lại cho các ứng dụng và người dùng. Bằng cách này, giao thức có thể phân phối giá trị tốt hơn và giảm sự phụ thuộc vào dịch vụ của bên thứ ba, từ đó nâng cao tính tự chủ của hệ thống và cải thiện lợi ích của người dùng.

Chạy các nút tập trung hoặc Người quản lý

Trong những ngày đầu của Web3, một trao đổi hợp đồng vĩnh viễn do các nhà tiên tri điều khiển đã được đề xuất để giải quyết vấn đề OEV. Ý tưởng cốt lõi của việc điều hành mạng lưới Keepers tập trung (các nút hoặc thực thể dành riêng cho giao dịch) là tổng hợp giá từ các nguồn của bên thứ ba như sàn giao dịch tập trung và sử dụng nguồn cấp dữ liệu Chainlink làm bản sao lưu. Mẫu này đã được phổ biến bởi GMX v1 và được sử dụng trong nhiều nhánh tiếp theo. Giá trị chính của nó nằm ở mạng Keeper được quản lý bởi một nhà điều hành duy nhất, điều này ngăn chặn hoàn toàn vấn đề chạy trước.

Tất nhiên, cách tiếp cận này có rủi ro tập trung rõ ràng. Hệ thống Keeper tập trung có thể xác định giá thực hiện mà không cần xác minh nguồn giá. Keeper trong GMX v1 không phải là một cơ chế minh bạch trên chuỗi mà là một chương trình chạy trên máy chủ tập trung theo địa chỉ nhóm của nó và không thể xác minh tính xác thực cũng như nguồn của giá thực hiện.

Để trích xuất OEV, người tìm kiếm sẽ giám sát "hướng dẫn cập nhật dữ liệu oracle" trong nhóm bộ nhớ và sử dụng cơ sở hạ tầng MEV để so sánh hướng dẫn giao dịch cập nhật dữ liệu oracle với các giao dịch được khởi tạo bởi chúng được nhóm lại với nhau và cuối cùng được thực thi để kiếmlợi nhuận. Tất nhiên, đối với các giao dịch chênh lệch giá và thanh toán bù trừ, OEV Searcher chỉ cần theo dõi độ lệch giữa giá trên chuỗi và giá ngoài chuỗi và cuối cùng đảm bảo rằng các giao dịch do nó khởi tạo trước tiên được thực hiện trên chuỗi thông qua cơ sở hạ tầng MEV.

Bất kể người tìm kiếm sử dụng quy trình nào, chúng ta có thể thấy rằng số tiền thu được từ OEV được phân phối cho cơ sở hạ tầng MEV và người tìm kiếm OEV, trong khi giao thức "bắt" giá trị OEV không nhận được đúng hạn . Một số lợi ích. (Theo một số dữ liệu, sự cố OEV trước đây đã khiến gần 10% lợi nhuận của nền tảng GMX bị lấy đi.) Để giải quyết vấn đề này, GMX đã đóng góp một lượng lớn giá trị OEV,Như một nền tảng giao dịch phái sinh trên chuỗi, được áp dụng theo cách Đơn giản:Cho phép một số người mà bạn chỉ định nắm bắt giá trị OEV, sau đó trả lại các giá trị OEV này cho nền tảng GMX càng nhiều càng tốt.

Về vấn đề này, GMX đã giới thiệu Rook và danh sách trắng. Nói một cách đơn giản, bản cập nhật oracle của GMX được thực hiện thông qua Rook và Rook sẽ thực hiện các hoạt động trích xuất OEV dựa trên các điều kiện thị trường hiện tại để có được OEV trên thị trường. 80% số OEV này sẽ được trả về giao thức GMX.

Tóm lại, GMX trao cho Rooks quyền cập nhật oracle thông qua whitelist, trích xuất OEV thông qua Rook để tránh bị người tìm kiếm khác trích xuất, đồng thời trả lại 80% OEV cho Hệ thống GMX. Quy trình này thực sự hơi đơn giản và thô thiển.

Trước những rủi ro tập trung do mạng Keeper của nhà điều hành duy nhất nêu trên gây ra, các nhà cung cấp dịch vụ bên thứ ba có thể được giới thiệu để xây dựng một mạng tự động hóa phi tập trung hơn. Sản phẩm đại diện là Chainlink Automation. Chainlink Automation hoạt động với Chainlink Data Streams, dịch vụ oracle có độ trễ thấp, dựa trên thao tác kéo mới của Chainlink. Nó đã được thông báo là sẽ ở giai đoạn beta kín vào cuối năm 2023, nhưng nó đã được đưa vào sử dụng thực tế trong GMX v2.

Chúng ta có thể tham khảo logic của hệ thống GMX v2 để khám phá cách tích hợp thiết kế Luồng dữ liệu Chainlink vào các ứng dụng DeFi thực tế.

Nhìn chung, Luồng dữ liệu Chainlink bao gồm ba thành phần chính: DON dữ liệu, DON tự động và hợp đồng xác minh trên chuỗi. Data DON là mạng dữ liệu ngoài chuỗi có kiến ​​trúc bảo trì và tổng hợp dữ liệu tương tự như Python. DON tự động là mạng Keeper được duy trì bởi cùng một nhà điều hành nút với DON dữ liệu, được sử dụng để kéo giá trong DON dữ liệu lên chuỗi. Cuối cùng, hợp đồng xác minh trên chuỗi được sử dụng để đảm bảo tính chính xác của chữ ký ngoài chuỗi.

Hình trên minh họa quá trình gọi hàm giao dịch mở, trong đó DON tự động chịu trách nhiệm về Dữ liệu DON lấy giá và cập nhật bộ lưu trữ trên chuỗi. Hiện tại, chỉ những người dùng trong danh sách trắng mới có quyền truy vấn trực tiếp dữ liệu DON, vì vậy giao thức có thể chọn chuyển giao các nhiệm vụ bảo trì cho quá trình xử lý DON tự động hoặc tự chạy Keeper. Tuy nhiên, sản phẩm dự kiến ​​sẽ dần dần chuyển sang cấu trúc không được phép khi chu kỳ phát triển diễn ra.

Về mặt bảo mật, việc dựa vào DON tự động có cùng giả định về độ tin cậy như chỉ sử dụng dữ liệu DON, đây là một cải tiến rất rõ ràng so với thiết kế của một Keeper duy nhất. Tuy nhiên, việc trao quyền cập nhật giá cho DON tự động cũng có nghĩa là OEV sẽ độc quyền cho các nút trong mạng Keeper này tương tự như thái độ của Ethereum đối với các nhà khai thác nút Lido. Các nhà khai thác nút của Lido thường là các tổ chức có danh tiếng xã hội lớn hơn. Họ chiếm thị phần lớn hơn trong thị trường cam kết Ethereum. Ethereum sử dụng các ràng buộc của sự đồng thuận xã hội để ngăn chặn Lido thông đồng với nhau và hình thành hiệu ứng độc quyền.

Pull Oracle: Trì hoãn giải quyết

Sàn giao dịch hợp đồng vĩnh viễn phi tập trung Synthetix  v2 đã giới thiệu dữ liệu giá Pyth cho Hợp đồng thanh toán, đây là một cải tiến rất lớn. Đơn đặt hàng của người dùng có thể chọn giữa giá Chainlink hoặc Pyth, miễn là độ lệch giá không vượt quá ngưỡng xác định trước và dấu thời gian đã vượt qua quá trình kiểm tra độ ổn định. Tuy nhiên, chỉ thay đổi sang oracle dựa trên pull không giải quyết được tất cả các vấn đề liên quan đến OEV. Để xử lý các giao dịch chạy trước, nhiều giao thức DeFi đã đưa ra cơ chế định giá "cái nhìn cuối cùng" Lệnh bị trì hoãn này chia lệnh thị trường của người dùng thành hai phần:

1. . Người dùng Gửi "ý định" mở lệnh thị trường cho chuỗi, cùng với các thông số đặt hàng như quy mô, đòn bẩy, tài sản thế chấp và khả năng chịu trượt giá, đồng thời trả thêm phí giữ.

2.keeper nhận đơn đặt hàng, yêu cầu dữ liệu giá Pyth mới nhất và gọi Synthetix trong giao dịch để thực hiện hợp đồng. Hợp đồng sẽ kiểm tra các tham số được xác định trước, nếu tất cả đều vượt qua, lệnh sẽ được thực thi, việc lưu trữ giá trên chuỗi sẽ được cập nhật và vị thế sẽ được mở. Người quản lý nhận được phí do người dùng trả để bù đắp phí gas và chi phí bảo trì mạng mà họ sử dụng.

Phương pháp này tránh đưa các mức giá bất lợi cho người dùng vào chuỗi, giải quyết hiệu quả vấn đề chạy trước và chênh lệch giá trong giao thức. Tuy nhiên, thiết kế này tạo ra sự đánh đổi nhất định về trải nghiệm người dùng: việc thực hiện các lệnh thị trường như vậy yêu cầu hai giao dịch. Ngoài việc trả phí gas, người dùng còn phải trả tiền để cập nhật bộ lưu trữ trên chuỗi oracle.

Trước đây, phí cập nhật bộ lưu trữ trên chuỗi của oracle là phí cố định 2 đô la Mỹ, nhưng gần đây đã được thay đổi thành phí linh hoạt dựa trên phí bảo hiểm oracle gas của Optimism. thay đổi tùy theo hoạt động của Lớp 2. Tóm lại, giải pháp này cải thiện lợi nhuận của nhà cung cấp thanh khoản đồng thời hy sinh trải nghiệm người dùng nhất định cho nhà giao dịch.

Triển vọng cho các ý tưởng giải pháp OEV trong tương lai

Pull oracle: cơ chế giải quyết lạc quan

Khi đơn hàng bị trì hoãn giới thiệu các khoản phí bổ sung cho người dùng và các khoản phí này tăng tỷ lệ thuận với phí DA của L2, ai đó đã nghĩ ra một mô hình giải quyết đơn hàng thay thế được gọi là "giải quyết lạc quan" nhằm mục đích giảm chi phí người dùng, đồng thời duy trì tính phân cấp và bảo mật giao thức. Như tên cho thấy,Cơ chế thanh toán lạc quan cho phép nhà giao dịch thực hiện giao dịch thị trường một cách nguyên tử, với hệ thống chấp nhận tất cả các mức giá một cách lạc quan và cung cấp khoảng thời gian để người tìm kiếm gửi bằng chứng để tiết lộ liệu lệnh có được tạo với mục đích xấu hay không.

Bài viết này sẽ phác thảo một số lần lặp lại của ý tưởng này, trình bày quá trình suy nghĩ trong quá trình thực hiện và phác thảo các vấn đề còn phải giải quyết theo hướng suy nghĩ này.

Ý tưởng ban đầu là để người dùng gửi giá thông qua ParsePriceFeedUpdates khi mở lệnh thị trường, sau đó cho phép người dùng hoặc bất kỳ bên thứ ba nào gửi giao dịch thanh toán và sử dụng dữ liệu giá để hoàn tất xác nhận giao dịch. Khi thanh toán, nếu có chênh lệch âm giữa hai mức giá, chênh lệch này sẽ đóng vai trò là sự trượt giá đối với lãi và lỗ của người dùng.

Ưu điểm của phương pháp này là giảm gánh nặng chi phí cho người dùng và giảm thiểu rủi ro của các giao dịch chạy trước. Tuy nhiên, phương pháp này cũng đưa ra quy trình xử lý gồm hai bước, đây là một thiếu sót mà chúng tôi nhận thấy trong mô hình xử lý bị trì hoãn của Synthetix. Các giao dịch thanh toán bổ sung có thể dư thừa trong hầu hết các trường hợp, đặc biệt khi biến động giữa việc đặt lệnh và thanh toán không vượt quá ngưỡng chạy trước do hệ thống xác định.

Một giải pháp khác để khắc phục vấn đề trên là cho phép hệ thống chấp nhận đơn đặt hàng một cách lạc quan và sau đó mở ra một giai đoạn thử thách không được phép. Trong khoảng thời gian này, bất kỳ ai cũng có thể gửi bằng chứng chứng minh sự chênh lệch giá giữa dấu thời gian giá và dấu thời gian khối, tạo ra cơ hội sinh lời trước. Cơ chếlạc quan làm giảm hiệu quả tình trạng chênh lệch giá tiềm ẩn trong hệ thống và tăng tính minh bạch và công bằng của quá trình giao dịch bằng cách đưa ra một giai đoạn thử thách.

Quy trình cụ thể như sau:

1. Người dùng tạo lệnh thị trường theo giá thị trường hiện tại và thêm giá này. và dữ liệu giá Pyth được nhúng Được gửi cùng nhau dưới dạng giao dịch tạo đơn hàng.

2. Hợp đồng thông minh xác minh và lưu trữ thông tin này một cách lạc quan.

3. Sau khi đơn hàng được xác nhận trên chuỗi, sẽ có một khoảng thời gian thử thách, trong đó Người tìm kiếm có thể gửi bằng chứng cho thấy người giao dịch có mục đích xấu. Bằng chứng này cần bao gồm bằng chứng cho thấy nhà giao dịch đã sử dụng giá trong quá khứ với mục đích kinh doanh chênh lệch giá. Nếu hệ thống chấp nhận bằng chứng, chênh lệch sẽ được áp dụng cho giá khớp lệnh của nhà giao dịch dưới dạng trượt giá và số tiền thu được từ OEV ban đầu sẽ được trao cho Keeper như một phần thưởng.

4. Sau khi thời gian thử thách kết thúc, tất cả giá sẽ được hệ thống coi là hợp lệ.

Mô hình lạc quan này có hai ưu điểm: Thứ nhất, nó giảm gánh nặng chi phí cho người dùng chỉ cần trả phí gas cho việc tạo đơn hàng và cập nhật oracle trong cùng một giao dịch. phí thanh toán giao dịch bổ sung được yêu cầu. Thứ hai, nó ngăn cản các giao dịch chạy trước và sử dụng cơ chế khuyến khích kinh tế để gửi bằng chứng về các giao dịch chạy trước trong một mạng lưới giám sát lành mạnh, từ đó bảo vệ tính toàn vẹn của nhóm thanh khoản.

Mặc dù ý tưởng này có tiềm năng rất lớn nhưng nếu muốn triển khai thì vẫn còn một số vấn đề ngỏ cần giải quyết:

Xác định bài toán 'lựa chọn đối thủ' :