Tác giả gốc: Adrian Chow

Đóng góp của Jonathan Yuen và Wintersoldier

Bản tóm tắt

• Oracles là không thể thiếu trong việc đảm bảo giá trị bị khóa của các giao thức DeFi. Trong tổng khối lượng DeFi bị khóa là 50 tỷ USD, 33 tỷ được đảm bảo bởi oracles.

• Tuy nhiên, độ trễ thời gian vốn có trong các bản cập nhật nguồn cấp dữ liệu giá của oracle dẫn đến một kiểu trích xuất giá trị phụ được gọi là Giá trị có thể trích xuất tối đa (MEV), được gọi là Giá trị có thể trích xuất của Oracle (OEV); OEV bao gồm việc chạy trước, chênh lệch giá và thanh lý không hiệu quả của oracle.

• Ngày càng có nhiều triển khai thiết kế có sẵn để ngăn chặn hoặc giảm thiểu hiện tượng chảy máu OEV tiêu cực, mỗi triển khai đều có những đánh đổi riêng. Bài viết này thảo luận về các phương án thiết kế hiện có và sự đánh đổi của chúng, cũng như đề xuất hai ý tưởng mới, đề xuất giá trị, các vấn đề mở và những trở ngại trong phát triển.

giới thiệu

Oracle có thể nói là một trong những hạ tầng quan trọng nhất trong DeFi hiện nay. Chúng là một phần không thể thiếu của hầu hết các giao thức DeFi, dựa vào nguồn cấp dữ liệu giá để giải quyết các hợp đồng phái sinh, đóng các vị thế không được thế chấp, v.v. Hiện tại, các nhà tiên tri đảm bảo giá trị 33 tỷ USD, chiếm ít nhất 2/3 tổng khối lượng khóa 50 tỷ USD trên chuỗi 1. Tuy nhiên, đối với các nhà phát triển ứng dụng, việc thêm oracle mang lại những vấn đề và sự đánh đổi rõ ràng trong thiết kế, xuất phát từ việc mất giá trị thông qua việc chạy trước, chênh lệch giá và thanh lý không hiệu quả. Bài viết này phân loại sự mất giá trị này là Giá trị có thể trích xuất của Oracle (OEV), phác thảo các vấn đề chính của nó từ góc độ ứng dụng và cố gắng minh họa việc bổ sung OEV an toàn và đáng tin cậy vào các giao thức DeFi dựa trên nghiên cứu của ngành.

Giá trị có thể trích xuất của Oracle (OEV)

Phần này giả định rằng người đọc có hiểu biết cơ bản về chức năng của oracle và sự khác biệt giữa oracle dựa trên đẩy và kéo. Nguồn cấp giá cho từng nhà tiên tri có thể khác nhau. Xem phần phụ lục để biết tổng quan, phân loại và định nghĩa.

Hầu hết các ứng dụng sử dụng nguồn cấp dữ liệu giá oracle chỉ yêu cầu đọc giá: các sàn giao dịch phi tập trung chạy mô hình định giá của riêng họ sử dụng nguồn cấp dữ liệu giá oracle làm giá tham chiếu; việc gửi tài sản thế chấp cho các vị thế cho vay được thế chấp quá mức chỉ yêu cầu đọc oracle Nhận giá để xác định các thông số ban đầu như giá trị khoản vay so với giá đóng cửa; ngoại trừ các trường hợp cực đoan như tài sản dài hạn mà việc cập nhật giá quá không thường xuyên, về cơ bản, sự chậm trễ trong việc oracle cập nhật nguồn cấp dữ liệu giá không quan trọng khi xem xét thiết kế hệ thống. Do đó, những cân nhắc quan trọng nhất đối với oracle là - tính chính xác của những người đóng góp giá và hiệu suất phi tập trung của nhà cung cấp oracle.

Nhưng nếu độ trễ trong cập nhật nguồn cấp dữ liệu giá là một yếu tố quan trọng cần cân nhắc thì cần chú ý nhiều hơn đến cách oracle tương tác với ứng dụng. Thông thường trong trường hợp này, sự chậm trễ như vậy dẫn đến các cơ hội khai thác giá trị, tức là chạy trước, chênh lệch giá và thanh lý. Loại MEV này được gọi là OE V2. Chúng tôi sẽ phác thảo các dạng OEV khác nhau trước khi thảo luận về các cách triển khai khác nhau và sự cân bằng giữa chúng.

kinh doanh chênh lệch giá

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ác giao dịch này được thực hiện dưới sự bất cân xứng thông tin và thường không có rủi ro gây thiệt hại cho các nhà cung cấp thanh khoản. Các giao thức OG DeFi như Synthetix đã phải vật lộn với vấn đề này kể từ năm 2018 và đã thử nhiều giải pháp khác nhau theo thời gian để giảm thiểu những tác động bên ngoài tiêu cực này.

Hãy để chúng tôi minh họa bằng một ví dụ đơn giản: sàn giao dịch phi tập trung hợp đồng vĩnh viễn xyz sử dụng nhà tiên tri Chainlink trên thị trường ETH/USD. Ví dụ sử dụng nguồn cấp dữ liệu giá ETH/USD để minh họa:

Hình 1: Ví dụ về chênh lệch giá bằng cách sử dụng oracle Chainlink

Mặc dù ví dụ trên là một ví dụ đơn giản hóa quá mức và không tính đến các yếu tố như trượt giá, phí hoặc nguồn tài trợ, nhưng nó minh họa các cơ hội phát sinh từ việc thiếu mức độ chi tiết về giá do vai trò của ngưỡng sai lệch gây ra. Người tìm kiếm có thể theo dõi độ trễ của các cập nhật giá thị trường giao ngay và trích xuất giá trị không rủi ro từ Nhà cung cấp thanh khoản (LP) dựa trên bộ lưu trữ trên chuỗi của Chainlink.

Chạy phía trước

Chạy trước, tương tự như chênh lệch giá, là một hình thức trích xuất giá trị khác trong đó người tìm kiếm giám sát một mempool để cập nhật oracle và chạy trước giá thị trường thực tế trước khi đưa nó vào chuỗi. Bằng cách này, người tìm kiếm có thời gian để đặt giá thầu và giao dịch trước khi nhà tiên tri được cập nhật và giao dịch được hoàn thành ở mức giá có lợi cho hướng giao dịch của họ.

Các sàn giao dịch phi tập trung theo hợp đồng vĩnh viễn như GMX luôn là nạn nhân của hoạt động chạy trước độc hại; trước khi tất cả các oracle trong GMX được cập nhật thông qua giao thức phối hợp KeeperDAO, khoảng 10% lợi nhuận của giao thức đã bị mất cho hoạt động chạy trước 4 .

Điều gì sẽ xảy ra nếu chúng ta chỉ sử dụng mô hình kéo?

Một trong những đề xuất giá trị của Python là việc sử dụng Python dựa trên kiến ​​trúc Solana, nhà xuất bản có thể đẩy các cập nhật giá lên mạng cứ sau 300 mili giây5, nhờ đó duy trì nguồn cấp giá có độ trễ thấp. Do đó, khi một ứng dụng truy vấn giá thông qua giao diện lập trình ứng dụng (API) của Pyth, nó có thể truy xuất giá mới nhất, cập nhật giá đó vào bộ lưu trữ trên chuỗi của chuỗi mục tiêu và thực hiện mọi hoạt động xuôi dòng trong logic ứng dụng trong một giao dịch.

Như đã đề cập ở trên, các ứng dụng có thể truy vấn trực tiếp Python để cập nhật giá mới nhất, cập nhật bộ nhớ trên chuỗi và hoàn thành tất cả logic liên quan trong một giao dịch. Điều này không giải quyết hiệu quả vấn đề chạy trước và chênh lệch giá sao?

Đó không phải là tất cả - các bản cập nhật cho Pyth cung cấp cho người dùng khả năng chọn mức giá nào được sử dụng trong các giao dịch có thể dẫn đến lựa chọn bất lợi (một loại thuốc độc khác). Mặc dù giá phải được lưu trữ trên chuỗi theo thời gian, nhưng người dùng vẫn có thể chọn bất kỳ mức giá nào đáp ứng các ràng buộc này - nghĩa là vẫn tồn tại hoạt động chênh lệch giá vì nó cho phép người tìm kiếm xem giá trong tương lai trước khi sử dụng giá trong quá khứ. Tài liệu của Pyth6 gợi ý rằng một cách đơn giản để bảo vệ khỏi vectơ tấn công này là thêm kiểm tra tính cũ để đảm bảo rằng giá đủ gần đây - tuy nhiên, phải có một khoảng thời gian đệm nhất định trước khi cập nhật dữ liệu giao dịch trong khối tiếp theo, chúng tôi làm cách nào để xác định ngưỡng thời gian tối ưu?

Chúng ta hãy lấy sàn giao dịch phi tập trung hợp đồng vĩnh viễn xyz làm ví dụ để phân tích. Lần này họ đang sử dụng nguồn cấp dữ liệu giá Pyth ETH/USD và thời gian kiểm tra hết hạn là 20 giây, có nghĩa là dấu thời gian của giá Pyth phải được thực thi Trong vòng 20 giây kể từ dấu thời gian khối của giao dịch xuôi dòng:

Hình 2: Ví dụ về quy trình chạy trước sử dụng Pyth

Một ý tưởng trực quan là chỉ cần hạ thấp ngưỡng kiểm tra hết hạn, nhưng ngưỡng thấp hơn có thể dẫn đến phản hồi mạng không thể đoán trước tại thời điểm chặn, do đó ảnh hưởng đến trải nghiệm người dùng. Vì nguồn cấp dữ liệu giá của Pyth phụ thuộc vào cầu nối nên cần có đủ thời gian đệm để a) cung cấp thời gian cho những người bảo vệ Wormhole chứng minh giá và b) cho phép chuỗi mục tiêu xử lý giao dịch và đưa nó vào khối. Những sự đánh đổi này được trình bày chi tiết trong phần tiếp theo.

Đóng vị thế

Đóng vị thế là phần cốt lõi của bất kỳ thỏa thuận nào liên quan đến đòn bẩy và mức độ chi tiết của việc cập nhật nguồn cấp dữ liệu giá đóng vai trò quan trọng trong việc xác định hiệu quả của việc đóng vị thế.

Trong trường hợp push oracle dựa trên ngưỡng, khi giá giao ngay đạt đến ngưỡng nhưng không đáp ứng các thông số đặt trước trong nguồn cấp dữ liệu giá của oracle, thì mức độ chi tiết (hoặc thiếu chi tiết) của việc cập nhật giá sẽ dẫn đến cơ hội bị bỏ lỡ. đóng vị thế. Điều này tạo ra các ngoại tác tiêu cực dưới dạng thị trường kém hiệu quả.

Khi thanh lý xảy ra, ứng dụng thường thanh toán một phần tài sản thế chấp thanh lý và đôi khi cung cấp phần thưởng cho người dùng đã khởi xướng thanh lý. Ví dụ: vào năm 2002, Aave đã trả 37,9 triệu đô la tiền thưởng thanh lý chỉ trên mạng chính 7 . Điều này rõ ràng đã bù đắp quá mức cho bên thứ ba và tạo ra hiệu suất kém cho người dùng. Ngoài ra, khi có giá trị có thể trích xuất được, các Cuộc chiến khí tiếp theo sẽ khiến giá trị thoát khỏi ứng dụng và do đó chảy vào chuỗi cung ứng MEV.

Không gian thiết kế và những cân nhắc

Xem xét các vấn đề trên, các giải pháp triển khai khác nhau dựa trên thiết kế đẩy, kéo và thay thế sẽ được thảo luận dưới đây, mỗi giải pháp đều có hiệu quả trong việc giải quyết các vấn đề trên và những đánh đổi liên quan; sự đánh đổi có thể ở dạng tập trung hóa bổ sung và các điều kiện tiên quyết về tin cậy hoặc trải nghiệm người dùng kém.

Đấu giá dòng lệnh (OFA) dành riêng cho oracles

Đặt giá thầu theo luồng đặt hàng OFA đã nổi lên như một giải pháp để loại bỏ các tác động bên ngoài tiêu cực do MEV tạo ra. Nói rộng hơn, OFA là dịch vụ đặt giá thầu có mục đích chung của bên thứ ba mà người dùng có thể gửi đơn đặt hàng (giao dịch hoặc ý định) và những người tìm kiếm trích xuất MEV có thể đặt giá thầu để giành độc quyền thực hiện các chiến lược theo đơn đặt hàng của họ. Một phần đáng kể doanh thu đấu giá được trả lại cho người dùng để bù đắp cho giá trị mà họ đã tạo ra trong các đơn đặt hàng này. Tỷ lệ chấp nhận OFA đã tăng lên gần đây, với hơn 10% giao dịch Ethereum được thực hiện thông qua các kênh riêng tư (RPC/OFA riêng tư) (Hình 3), được cho là sẽ thúc đẩy tăng trưởng hơn nữa.

Hình 3: Tổng hợp số lượng giao dịch Ethereum riêng tư hàng ngày. Nguồn: Blocknative

Vấn đề khi triển khai OFA phổ quát trong các bản cập nhật oracle là oracle không có cách nào để biết liệu bản cập nhật dựa trên các quy tắc tiêu chuẩn có tạo ra bất kỳ OEV nào hay không và nếu không, nó sẽ gây ra độ trễ bổ sung khi oracle gửi giao dịch vào cuộc đấu giá. Mặt khác, cách đơn giản nhất để hợp lý hóa OEV và giảm thiểu độ trễ là cung cấp tất cả luồng đơn hàng tiên tri cho một người tìm kiếm thống trị duy nhất. Nhưng điều này rõ ràng mang lại rủi ro tập trung lớn, có thể khuyến khích hành vi trục lợi và kiểm duyệt, đồng thời dẫn đến trải nghiệm người dùng kém.

Hình 4: OFA chung và OFA dành riêng cho Oracle

Cập nhật giá cho OFA dành riêng cho oracle không bao gồm các cập nhật dựa trên quy tắc hiện có vẫn được thực hiện trong mempool công khai. Điều này cho phép cập nhật giá của oracle và mọi giá trị có thể trích xuất được từ chúng vẫn tồn tại trong lớp ứng dụng. Là một sản phẩm phụ, nó cũng làm tăng độ chi tiết của dữ liệu bằng cách cho phép người tìm kiếm yêu cầu cập nhật nguồn dữ liệu mà không yêu cầu các nút oracle phải chịu thêm chi phí cho việc cập nhật thường xuyên hơn.

OFA dành riêng cho Oracle là lý tưởng cho việc thanh lý các vị thế vì nó có thể mang lại nhiều cập nhật giá chi tiết hơn, tối đa hóa lợi nhuận vốn cho những người vay có vị thế bị thanh lý, giảm phần thưởng giao thức trả cho người thanh lý và trong giao thức Giá trị được trích từ người đặt giá thầu được giữ lại trong người đặt giá thầu để phân phối lại cho người dùng. Chúng cũng giải quyết ở một mức độ nào đó - mặc dù không hoàn toàn - các vấn đề về chạy trước và kinh doanh chênh lệch giá. Trong quy trình đấu giá thầu kín và cạnh tranh hoàn hảo theo giá đầu tiên, kết quả của cuộc đấu giá phải là chi phí không gian khối gần với cơ hội thực hiện 8, được trích xuất từ ​​nguồn cấp dữ liệu OEV chạy trước. mức độ chi tiết về giá của các cập nhật nguồn cấp dữ liệu giá tăng lên.

Hiện tại, việc triển khai OFA dành riêng cho oracle yêu cầu phải tham gia dịch vụ đặt giá thầu của bên thứ ba (chẳng hạn như OEV-Share) hoặc xây dựng dịch vụ đặt giá thầu như một phần của ứng dụng. Lấy cảm hứng từ Flashbots, API 3 sử dụng chuyển tiếp OEV (Hình 5) làm API được thiết kế để thực hiện các dịch vụ bảo vệ DoS cho việc đặt giá thầu. Rơle này chịu trách nhiệm thu thập các siêu giao dịch từ các nhà tiên tri, đối chiếu và tổng hợp giá thầu của người tìm kiếm, đồng thời phân phối lại số tiền thu được theo cách không đáng tin cậy mà không kiểm soát giá thầu. Khi người tìm kiếm thắng giá thầu, việc cập nhật nguồn dữ liệu chỉ có thể dựa vào việc chuyển số tiền giá thầu sang hợp đồng proxy do giao thức sở hữu, sau đó cập nhật nguồn giá với dữ liệu đã ký do người chuyển tiếp cung cấp.

Hình 5: Bộ lặp OEV cho API 3

Ngoài ra, các giao thức có thể loại bỏ người trung gian và xây dựng dịch vụ đặt giá thầu của riêng họ để thu được tất cả giá trị được trích xuất từ ​​OEV. BBOX là một giao thức sắp ra mắt hy vọng sẽ đưa tính năng đặt giá thầu vào cơ chế thanh lý của nó để thu giữ OEV và trả lại cho ứng dụng cũng như người dùng của nó 9 .

Chạy một nút trung tâm hoặc Keeper

Một ý tưởng ban đầu xuất phát từ làn sóng sàn giao dịch phi tập trung hợp đồng vĩnh viễn đầu tiên để chống lại OEV là vận hành mạng Keeper tập trung (mạng gác cổng) để tổng hợp giá nhận được từ các nguồn của bên thứ ba (chẳng hạn như sàn giao dịch tập trung). một kế hoạch dự phòng hoặc cầu dao. Mô hình này đã được phổ biến trong GMX v1 10 và nhiều nhánh tiếp theo của nó, đồng thời đề xuất giá trị chính của nó là vì mạng Keeper được điều hành bởi một nhà điều hành duy nhất nên nó được bảo vệ tuyệt đối khỏi hoạt động chạy trước.

Mặc dù điều này giải quyết được nhiều vấn đề nêu trên nhưng rõ ràng vẫn có những lo ngại về sự tập trung hóa. 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 chính xác nguồn giá và phương pháp tổng hợp. Trong trường hợp GMX v1, Keeper không phải là một cơ chế minh bạch hoặc trực tuyến mà là một chương trình được ký bởi địa chỉ của nhóm chạy trên một máy chủ tập trung. Vai trò cốt lõi của Keeper không chỉ là thực hiện lệnh mà còn thực hiện các lệnh theo định nghĩa đặt trước của chính nó."Quyết định"Giá giao dịch, không có cách nào để xác minh tính xác thực hoặc nguồn gốc của giá thực hiện được sử dụng.

Mạng lưu trữ tự động và luồng dữ liệu liên kết chuỗi

Giải pháp cho các rủi ro tập trung nêu trên do mạng Keeper một nhà điều hành gây ra là sử dụng các nhà cung cấp dịch vụ bên thứ ba để xây dựng mạng tự động hóa phi tập trung hơn. Chainlink Automation là một trong những sản phẩm như vậy và nó cung cấp dịch vụ này cùng với Luồng dữ liệu Chainlink, một nhà tiên tri mới có độ trễ thấp, dựa trên lực kéo. Sản phẩm này mới được phát hành gần đây và hiện đang ở giai đoạn thử nghiệm kín, nhưng GMX v2 11 đã sử dụng nó và nó có thể dùng làm tài liệu tham khảo cho các hệ thống sử dụng thiết kế này.

Ở cấp độ cao, luồng dữ liệu Chainlink bao gồm ba phần chính: dữ liệu DON (mạng oracle phi tập trung), DON tự động và hợp đồng xác minh trên chuỗi 12 . Data DON là mạng dữ liệu ngoài chuỗi có kiến ​​trúc tương tự như cách Python duy trì và tổng hợp dữ liệu. DON tự động là một mạng lưới gồm những người bảo vệ được bảo mật bởi cùng một nhà khai thác nút của Data DON, được sử dụng để trích xuất giá từ Data DON trên chuỗi. Cuối cùng, hợp đồng xác thực được sử dụng để xác minh rằng chữ ký ngoài chuỗi là chính xác.

Hình 6: Kiến trúc luồng dữ liệu Chainlink

Hình trên cho thấy quá trình giao dịch gọi hàm giao dịch mở, trong đó DON tự động chịu trách nhiệm lấy giá từ DON dữ liệu và cập nhật bộ lưu trữ trên chuỗi. Hiện tại, các điểm cuối để truy vấn trực tiếp dữ liệu DON được giới hạn ở người dùng trong danh sách trắng, do đó, giao thức có thể chọn chuyển công việc bảo trì Keeper sang Automation DON (Automation DON) hoặc chạy Keeper của riêng nó. Nhưng khi vòng đời phát triển sản phẩm tiến triển, dự kiến ​​điều này sẽ dần dần chuyển sang cấu trúc không cần cấp phép.

Ở cấp độ bảo mật, các giả định về độ tin cậy dựa trên DON tự động cũng giống như giả định dành cho DON dữ liệu, đây là một cải tiến đáng kể so với một thiết kế Keeper duy nhất. Tuy nhiên, nếu quyền cập nhật nguồn cấp dữ liệu giá được trao cho DON tự động thì cơ hội trích xuất giá trị chỉ có thể được giao cho các nút trong mạng Keeper. Điều này có nghĩa là giao thức sẽ tin tưởng các nhà khai thác nút LinkToken (chủ yếu là các tổ chức) để duy trì danh tiếng xã hội của họ và không ngăn cản người dùng hoạt động, điều này tương tự như việc tin tưởng các nhà khai thác nút Lido Node để duy trì danh tiếng của họ chứ không phải để họ có thị phần lớn và độc quyền không gian khối

Kéo: Giải quyết chậm trễ

Một trong những thay đổi lớn nhất trong Synthetix perps v2 là việc giới thiệu nguồn cấp dữ liệu giá Python để thanh toán hợp đồng vĩnh viễn 13. Điều này cho phép các đơn đặt hàng được thanh toán ở mức giá Chainlink hoặc Pyth, miễn là chúng không sai lệch quá ngưỡng được xác định trước và dấu thời gian đã vượt qua quá trình kiểm tra hết hạn. Tuy nhiên, như đã đề cập ở trên, việc chỉ chuyển sang oracle dựa trên pull sẽ không giải quyết được các vấn đề liên quan đến OEV cho tất cả các giao thức. Để giải quyết vấn đề chạy trước, nó có thể được đưa ra dưới dạng đơn hàng bị trì hoãn."xem lần cuối"Cơ chế định giá, trên thực tế, cơ chế này chia trật tự thị trường của người dùng thành hai phần:

• Giao dịch số 1: Gửi on-chain để mở lệnh thị trường"chủ đích"và cung cấp các thông số lệnh tiêu chuẩn như kích thước, đòn bẩy, tài sản thế chấp và khả năng chịu trượt giá. Đồng thời, cần có thêm phí Keeper để thưởng cho Keeper khi thực hiện giao dịch số 2.

• Giao dịch số 2: Keeper nhận được đơn đặt hàng được gửi trong Giao dịch số 1, yêu cầu nguồn cấp dữ liệu giá Python mới nhất và gọi Synthetix để thực hiện hợp đồng trong một giao dịch. Hợp đồng sẽ kiểm tra các thông số được xác định trước như tính kịp thời và độ trượt giá. Nếu cả hai đề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ị trí sẽ được thiết lập. Người giữ sẽ tính phí để bù đắp lượng gas sử dụng để sử dụng và bảo trì mạng.

Việc triển khai này không mang lại cho người dùng cơ hội lựa chọn bất lợi các mức giá được gửi trên chuỗi, giải quyết hiệu quả các cơ hội chạy trước và chênh lệch giá cho giao thức. Tuy nhiên, sự đánh đổi của thiết kế này là trải nghiệm của người dùng: việc thực hiện lệnh thị trường này yêu cầu hai quy trình giao dịch, người dùng cần bù gas cho hoạt động của Keeper và chia sẻ chi phí cập nhật bộ lưu trữ trên chuỗi oracle. Mức phí trước đây là cố định 2 sUSD gần đây đã được thay đổi thành phí linh hoạt dựa trên Optimism gas oracle + premium, phí này sẽ thay đổi dựa trên hoạt động của mạng lớp 2. Trong mọi trường hợp, đây có thể được coi là một giải pháp để cải thiện khả năng sinh lời của LP nhưng phải trả giá bằng trải nghiệm của người dùng nhà giao dịch.

Kiểu kéo: Giải quyết lạc quan

Vì các đơn hàng bị trì hoãn sẽ mang lại thêm phí mạng cho người dùng (tỷ lệ thuận với phí DA của mạng lớp thứ hai), sau khi động não, chúng tôi đã đưa ra một mô hình giải quyết đơn hàng khác mà chúng tôi gọi là"quyết toán tích cực", mô hình này có khả năng giảm chi phí người dùng trong khi vẫn duy trì tính phân cấp và tính bảo mật của giao thức. Đúng như tên gọi, cơ chế này cho phép các 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 tích cực chấp nhận mọi mức giá và cung cấp cơ hội cho người tìm kiếm gửi bằng chứng cho thấy các lệnh được đặt có ác ý. Phần này phác thảo các phiên bản khác nhau của ý tưởng này, quá trình suy nghĩ của chúng tôi và các vấn đề chưa được giải quyết.

Ý tưởng ban đầu của chúng tôi là xây dựng một cơ chế cho phép người dùng gửi giá qua parsPriceFeedUpdates 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 bằng cách sử dụng dữ liệu nguồn cấp dữ liệu giá và hoàn thành giao dịch ở mức giá đó khi giao dịch được xác nhận. Khi thanh toán, bất kỳ chênh lệch âm nào giữa hai mức giá sẽ được đưa vào báo cáo lãi lỗ của người dùng dưới dạng trượt giá. Ưu điểm của phương pháp này bao gồm giảm gánh nặng chi phí cho người dùng và giảm rủi ro khi chạy trước. Người dùng không còn phải chịu phí bảo hiểm dành cho người bảo vệ và vì không biết giá thanh toán khi đơn hàng được gửi nên rủi ro của việc chạy trước vẫn có thể kiểm soát được. Tuy nhiên, điều này vẫn đưa ra quy trình giải quyết gồm hai bước, đây là một trong những hạn chế mà chúng tôi nhận thấy với mô hình giải quyết trả chậm của Synthetix. Trong hầu hết các trường hợp, nếu sự biến động giữa việc đặt lệnh và thanh toán không vượt quá ngưỡng có lợi nhuận do hệ thống xác định trước đó thì các giao dịch thanh toán bổ sung có thể không cần thiết.

Một giải pháp khác để khắc phục vấn đề trên là cho phép hệ thống chủ động chấp nhận đơn đặt hàng và sau đó mở một giai đoạn thử thách không được phép, trong đó có thể đưa ra bằng chứng chứng minh rằng độ lệch giá giữa dấu thời gian giá và dấu thời gian khối được phép tiếp tục. đang thực hiện các giao dịch.

Các thao tác cụ thể như sau:

1. Người dùng tạo đơn đặt hàng dựa trên giá thị trường hiện tại. Sau đó, họ chuyển giá cùng với dữ liệu byte nguồn cấp giá Python được nhúng dưới dạng giao dịch tạo đơn hàng.

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

3. Sau khi đơn hàng được xác nhận trực tuyến, sẽ có một giai đoạn thử thách để người tìm kiếm có thể gửi bằng chứng về lựa chọn bất lợi. Bằng chứng này sẽ xác nhận rằng các nhà giao dịch đã sử dụng dữ liệu nguồn cấp giá lỗi thời với mục đích kinh doanh chênh lệch giá trong hệ thống. Nếu bằng chứng được hệ thống chấp nhận, khoản chênh lệch sẽ được áp dụng cho giá thực hiện của nhà giao dịch dưới dạng trượt giá và giá trị vượt quá sẽ được trao cho Keeper như một phần thưởng.

4. Sau thời gian thử thách, hệ thống coi tất cả giá là hợp lệ.

Mô hình này có hai ưu điểm: Giảm gánh nặng chi phí cho người dùng, 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 mà không yêu cầu thanh toán bổ sung. Nó cũng ngăn chặn hoạt động chạy trước, bảo vệ tính toàn vẹn của nhóm thanh khoản và đảm bảo mạng Keeper lành mạnh với các khuyến khích tài chính để gửi bằng chứng cho hệ thống chứng minh hoạt động chạy trước.

Tuy nhiên, vẫn còn một số vấn đề cần giải quyết trước khi đưa ý tưởng này vào thực tế:

• sự định nghĩa"lựa chọn bất lợi": Làm thế nào để hệ thống phân biệt giữa người dùng gửi giá đã hết hạn do sự chậm trễ của mạng và người dùng cố tình chênh lệch giá? Ý tưởng ban đầu có thể là đo lường mức độ biến động trong khoảng thời gian kiểm tra hết hạn (ví dụ: 15 giây) và nếu mức độ biến động vượt quá phí thực hiện ròng thì lệnh sẽ được gắn cờ là một hành vi khai thác tiềm năng.

• Đặt khoảng thời gian thử thách thích hợp: Xét rằng dòng lệnh độc hại chỉ có thể được mở trong một khoảng thời gian ngắn, khoảng thời gian thích hợp để Người quản lý thách thức giá là gì? Việc kiểm chứng hàng loạt có thể hiệu quả hơn về mặt chi phí, nhưng do tính không thể đoán trước của luồng đơn hàng theo thời gian, rất khó để kiểm tra thời gian theo lô để đảm bảo rằng tất cả thông tin về giá đã được chứng minh hoặc có đủ thời gian để kiểm chứng.

• Phần thưởng kinh tế dành cho người nắm giữ: Để việc gửi bằng chứng trở nên hợp lý đối với những người nắm giữ được khuyến khích tài chính, phần thưởng liên quan đến việc gửi bằng chứng chiến thắng phải lớn hơn chi phí gas liên quan đến việc gửi bằng chứng. Do quy mô đơn hàng khác nhau nên giả định này có thể không được đảm bảo.

• Có cần cơ chế tương tự để đóng lệnh không? Nếu vậy, nó sẽ làm giảm trải nghiệm người dùng như thế nào?

• Đảm bảo rằng sự trượt giá “vô lý” không xảy ra với người dùng: Trong trường hợp xảy ra sự cố chớp nhoáng, có thể có chênh lệch giá rất lớn giữa việc tạo đơn hàng và xác nhận trên chuỗi. Có thể cần một số loại dự phòng hoặc ngắt mạch và cân nhắc sử dụng giá EMA của Pyth để đảm bảo sự ổn định của nguồn cấp giá trước khi sử dụng.

Bộ đồng xử lý ZK - Một hình thức tiêu thụ dữ liệu khác

Một hướng khác đáng để khám phá là sử dụng bộ xử lý phụ trợ ZK, được thiết kế để đạt được trạng thái trên chuỗi nhằm thực hiện các phép tính phức tạp ngoài chuỗi, đồng thời cung cấp bằng chứng về cách thực hiện các phép tính; phương pháp này có thể được sử dụng mà không được phép xác minh. Các dự án như Axiom cho phép các hợp đồng truy vấn dữ liệu blockchain lịch sử, thực hiện các phép tính ngoài chuỗi và gửi bằng chứng ZK chứng minh rằng kết quả tính toán được tính toán chính xác dựa trên dữ liệu hợp lệ trên chuỗi. Bộ xử lý thứ cấp mở ra khả năng xây dựng các oracle TWAP tùy chỉnh với khả năng phục hồi thao tác bằng cách sử dụng giá lịch sử từ nhiều nguồn thanh khoản gốc DeFi (chẳng hạn như Uniswap + Curve).

So với các nhà tiên tri truyền thống hiện chỉ có quyền truy cập vào dữ liệu giá tài sản mới nhất, bộ xử lý phụ trợ ZK sẽ mở rộng phạm vi dữ liệu được cung cấp cho dApp một cách an toàn (Pyth cung cấp giá EMA để các nhà phát triển sử dụng làm kiểm tra tham chiếu cho các dữ liệu mới nhất giá cả). Bằng cách này, các ứng dụng có thể giới thiệu nhiều logic kinh doanh hơn hoạt động với dữ liệu chuỗi khối lịch sử để cải thiện bảo mật giao thức hoặc nâng cao trải nghiệm người dùng.

Tuy nhiên, bộ xử lý phụ ZK vẫn đang trong giai đoạn phát triển ban đầu và vẫn còn một số điểm nghẽn, chẳng hạn như:

• Trong môi trường bộ xử lý phụ trợ, việc thu thập và tính toán lượng lớn dữ liệu blockchain có thể cần thời gian chứng minh lâu dài

• Chỉ cung cấp dữ liệu blockchain không giải quyết được nhu cầu liên lạc an toàn với các ứng dụng không phải Web3

Giải pháp không cần Oracle – tương lai của DeFi?

Một cách khác để giải quyết vấn đề này là loại bỏ nhu cầu về nguồn cấp dữ liệu giá bên ngoài bằng cách thiết kế nguyên thủy từ đầu, do đó

Giải quyết sự phụ thuộc của DeFi vào oracles. Sự phát triển mới nhất trong lĩnh vực này là việc sử dụng nhiều loại mã thông báo AMM LP khác nhau làm phương tiện định giá. Ý tưởng cốt lõi là vị trí LP của nhà tạo lập thị trường có chức năng không đổi là mã thông báo đại diện cho trọng số đặt trước của hai tài sản và có hai mã thông báo. Công thức định giá tự động (tức là xy=k). Bằng cách tận dụng mã thông báo LP (làm tài sản thế chấp, cơ sở cho vay hoặc trong trường hợp sử dụng gần đây, để di chuyển các vị trí LP v3 đến các điểm đánh dấu khác nhau), giao thức có thể thu được thông tin thường được lấy từ các nhà tiên tri. Kết quả là, một làn sóng giải pháp tiên tri mới không gặp phải những thách thức trên đã được hiện thực hóa. Các ví dụ ứng dụng dựa trên hướng này bao gồm:

Panoptic đang xây dựng một giao thức tùy chọn lâu dài, không cần oracle, tận dụng các vị trí thanh khoản tập trung Uniswap v3. Bởi vì vị thế thanh khoản tập trung được chuyển đổi 100% thành tài sản cơ bản khi giá giao ngay vượt quá giới hạn trên của vị thế LP, lợi nhuận cho nhà cung cấp thanh khoản rất giống với lợi nhuận cho người bán quyền chọn bán. Do đó, thị trường quyền chọn hoạt động bằng cách các nhà cung cấp thanh khoản gửi tài sản hoặc vị thế LP, đồng thời người mua và người bán quyền chọn vay thanh khoản và di chuyển nó vào hoặc ra khỏi phạm vi, từ đó tạo ra lợi nhuận quyền chọn động. Vì khoản vay được tính bằng vị thế LP nên không cần có lời tiên tri nào để giải quyết.

Infinity Pools đang tận dụng các vị thế thanh khoản tập trung của Uniswap v3 để xây dựng một nền tảng giao dịch có đòn bẩy không cần thanh lý và không có lời tiên tri. Các nhà cung cấp thanh khoản của Uniswap v3 có thể cho mượn token LP của họ và các nhà giao dịch gửi một số tài sản thế chấp, vay token LP và mua lại các tài sản liên quan đến giao dịch định hướng của họ. Các khoản vay khi mua lại sẽ được tính bằng cơ sở tài sản hoặc tài sản được báo giá, tùy thuộc vào giá khi mua lại và có thể được tính trực tiếp bằng cách kiểm tra thành phần LP trên Uniswap, loại bỏ sự phụ thuộc vào các nhà tiên tri.

Timeswap đang xây dựng một nền tảng cho vay có thời hạn cố định, không thanh lý, không có oracle. Đây là thị trường ba bên bao gồm người cho vay, người đi vay và nhà cung cấp thanh khoản. Không giống như thị trường cho vay truyền thống, nó sử dụng"cơ sở thời gian"thanh lý (dựa trên thời gian) thay vì"cơ sở giá"(dựa trên giá) đóng các vị thế. Trong các sàn giao dịch phi tập trung, các nhà cung cấp thanh khoản được thiết lập tự động để luôn mua từ người bán và bán cho người mua, trong khi ở Timeswap, các nhà cung cấp thanh khoản luôn cho người vay vay và vay từ người cho vay trên thị trường. Họ cũng phải chịu trách nhiệm về các khoản nợ không trả được và được ưu tiên nhận tài sản thế chấp bị tịch thu để bồi thường.

Tóm lại là

Dữ liệu về giá vẫn là một phần quan trọng của nhiều ứng dụng phi tập trung và tổng giá trị mà các oracle thu được tiếp tục tăng theo thời gian, điều này càng khẳng định sự phù hợp với thị trường sản phẩm của họ (p sản phẩm-thị trường phù hợp). Mục đích của bài viết này là cung cấp thông tin cho người đọc và cung cấp cái nhìn tổng quan về những thách thức liên quan đến OEV mà chúng tôi hiện đang gặp phải, cũng như không gian thiết kế trong quá trình triển khai dựa trên đẩy, kéo và các thiết kế khác sử dụng nhà cung cấp thanh khoản AMM hoặc phụ trợ ngoài chuỗi. bộ xử lý.

Chúng tôi rất vui khi thấy các nhà phát triển đầy nghị lực đang tìm cách giải quyết những thách thức thiết kế khó khăn này. Nếu bạn cũng đang thực hiện một dự án đột phá trong lĩnh vực này, chúng tôi rất mong nhận được phản hồi từ bạn!

Tài liệu tham khảo và lời cảm ơn

Cảm ơn Jonathan Yuen và Wintersoldier vì những đóng góp và cuộc trò chuyện của họ, đã góp phần rất lớn cho bài viết này.

Cảm ơn Erik Lie, Richard Yuen (Hailstone), Marc, Mario Bernardi, Anirudh Suresh (Pyth), Ugur Mersin (API 3 DAO) và Mimi (Timeswap) vì những nhận xét, phản hồi và đánh giá có giá trị của họ.

• https://defillama.com/oracles(14 Nov)  ↩︎

• OEV Litepaper https://drive.google.com/file/d/1wuSWSI8WY9ChChu2hvRgByJSyQlv_8SO/edit

• Frontrunning on Synthetix: A History by Kain Warwick https://blog.synthetix.io/frontrunning-synthetix-a-history/

• https://snapshot.org/#/rook.eth/proposal/0x523ea386c3e42c71e18e1f4a143533201083655dc04e6f1a99f1f0b340523c58  ↩︎

• https://docs.pyth.network/documentation/pythnet-price-feeds/on-demand↩︎

• https://docs.pyth.network/documentation/solana-price-feeds/best-practices#latency↩︎

• Aave liquidation figures https://dune.com/queries/3247324

• https://drive.google.com/file/d/1wuSWSI8WY9ChChu2hvRgByJSyQlv_8SO/edit

• https://twitter.com/bboexchange/status/1726801832784318563

• https://gmx-io.notion.site/gmx-io/GMX-Technical-Overview-47fc5ed832e243afb9e97e8a4a036353

• https://gmxio.substack.com/p/gmx-v2-powered-by-chainlink-data ↩︎

• https://docs.chain.link/data-streams↩︎

• https://sips.synthetix.io/sips/sip-281/

︎

ruột thừa

Định nghĩa: Oracle đẩy và kéo

Máy push oracle duy trì giá ngoài chuỗi trong mạng P2P và duy trì cập nhật giá dựa trên các nút trên chuỗi được xác định trước. Lấy Chainlink làm ví dụ, việc cập nhật giá dựa trên hai tham số kích hoạt: ngưỡng độ lệch (ngưỡng sai lệch) và nhịp tim (nhịp tim). Nguồn cấp giá Ethereum ETH/USD bên dưới sẽ được cập nhật bất cứ khi nào giá ngoài chuỗi chênh lệch 0,5% so với giá trên chuỗi mới nhất hoặc đồng hồ đếm nhịp tim 1 giờ về 0.

Trong trường hợp này, nhà điều hành oracle phải trả phí giao dịch cho mỗi lần cập nhật giá, đây là sự cân bằng giữa chi phí và khả năng mở rộng. Việc tăng số lượng nguồn giá, hỗ trợ các chuỗi khối bổ sung hoặc thêm các bản cập nhật thường xuyên hơn sẽ phải chịu thêm chi phí giao dịch. Do đó, những tài sản đuôi dài có thông số kích hoạt cao hơn chắc chắn có nguồn giá có độ tin cậy thấp. Hãy lấy CRV/USD làm ví dụ để minh họa điều này - để giá mới được cập nhật trên chuỗi, cần có ngưỡng sai lệch 1%, với nhịp tim là 24 giờ, nghĩa là nếu giá không sai lệch theo hơn 1% trong vòng 24 giờ, sau đó sẽ chỉ có một bản cập nhật giá mới cứ sau 24 giờ. Theo trực giác, việc thiếu chi tiết về nguồn giá cho các tài sản dài hạn chắc chắn sẽ dẫn đến việc các ứng dụng cần xem xét các yếu tố rủi ro bổ sung khi tạo thị trường cho những tài sản này, điều này giải thích tại sao phần lớn hoạt động DeFi vẫn xoay quanh những tài sản có tính thanh khoản cao nhất. với mã thông báo vốn hóa thị trường mạnh nhất, lớn nhất.

Ngược lại, pull oracles cho phép giá được kéo vào chuỗi theo yêu cầu. Pyth là ví dụ nổi bật nhất hiện nay, truyền các bản cập nhật giá ngoài chuỗi, ký từng bản cập nhật để bất kỳ ai cũng có thể xác minh tính xác thực của nó và duy trì giá tổng hợp trên Pythnet, một khối riêng dựa trên chuỗi mã Solana. Khi cần cập nhật, dữ liệu sẽ được truyền qua Wormhole, được xác minh trên Python và sau đó được đưa lên chuỗi mà không được phép.

Hình trên mô tả cấu trúc của nguồn cấp dữ liệu giá Pyth: Khi cần cập nhật giá trên chuỗi, người dùng có thể yêu cầu cập nhật thông qua Pyth API. Giá đã được xác minh trên Pythnet sẽ được gửi đến hợp đồng Wormhole. Hợp đồng Wormhole sẽ quan sát, tạo và gửi tên địa điểm VAA, có thể được xác minh trên bất kỳ blockchain nào nơi hợp đồng Pyth được triển khai.

Tuyên bố miễn trừ trách nhiệm: Bài viết này không phải là lời khuyên đầu tư. Người dùng nên cân nhắc xem mọi ý kiến, quan điểm hoặc kết luận trong bài viết này có phù hợp với tình huống cụ thể của họ và tuân thủ luật pháp cũng như quy định liên quan của quốc gia và khu vực nơi họ sinh sống hay không.