Oracle bên dưới được thiết kế để trở thành một cách tối thiểu hóa sự tin cậy và Không cần cho phép để có được giá Token mà bất kỳ ai cũng có thể sử dụng.
Ở cấp độ cơ bản nhất, oracle hoạt động bằng cách yêu cầu một báo cáo viên gửi cả lệnh mua và lệnh bán giới hạn ở cùng một mức giá. Bất kỳ ai cũng có thể hoán đổi các lệnh này trừ một khoản phí nhỏ (không khớp lệnh một phần). Nếu không có ai khớp lệnh trong một khoảng thời gian nhất định, đó là bằng chứng về một mức giá tốt có thể được sử dụng để thanh toán. Nếu lệnh được khớp, người khớp cần đặt cọc bằng cả hai token, ngụ ý một mức giá mới, và bộ đếm thời gian sẽ khởi động lại.
Oracle sử dụng cơ chế leo thang thế chấp theo cấp số nhân trong các tranh chấp để tăng chi phí thao túng và cung cấp cho người dùng một số đảm bảo thống kê về tổng thời gian thanh toán và chi phí trì hoãn. Trong trường hợp trung bình, Vốn cần thiết để báo cáo giá chính xác có thể thấp hơn nhiều so với số tiền danh nghĩa được thanh toán theo giá được báo cáo. Mục tiêu là thay thế bộ trung gian Oracle tập trung và đáng tin cậy hiện tại để các ứng dụng DeFi có ít điểm lỗi hơn.
Thiết kế dựa trên 1 trong n người tham gia vì lợi ích cá nhân, không liên kết về mặt kinh tế với vị thế bên ngoài được giải quyết bởi oracle có giao dịch của họ được đưa vào trước thời hạn.
Một trong những hạn chế rõ ràng của thiết kế này là kiểm duyệt (gửi giá kém → tranh chấp kiểm duyệt → lợi nhuận). Điều này đặt ra giới hạn cứng về số tiền mà oracle có thể bảo đảm trên L2, và cho đến khi FOCIL ra mắt, chúng ta phải sử dụng thời gian thanh toán dài hơn trên L1 để giảm khả năng kẻ tấn công kiểm soát nhiều khối liên tiếp.
Dưới đây là một ví dụ đơn giản về vòng đời của Oracle:
Giả sử một ứng dụng muốn biết giá của WETH so với USDC. Trong yêu cầu giá, họ chỉ rõ
- token1: WETH
- token2: USDC
- token1Số tiền: 0,1 WETH
- Thời gian giải quyết: 10 giây
- hệ số nhân: 1,5x
- phần thưởng: 0,001 ETH
Số dư hợp đồng Oracle hiện là 0,001 ETH.
Yêu cầu giá này được đưa on-chain và bất kỳ ai cũng có thể báo cáo giá. Giả sử giá ETH là 3000 đô la. Bước tiếp theo là một báo cáo viên nộp báo cáo ban đầu, giành chiến thắng trong cuộc đua giành 0,001 ETH với tất cả những người khác.
Vì một ứng dụng đang sử dụng oracle để lấy giá, chúng ta sẽ giả định có hai người ở hai vị trí đối lập nhau. Nghĩa là, nếu giá được báo cáo cao hơn, một người được lợi và người kia chịu thiệt, và ngược lại. Giả sử một trong hai người hoàn toàn thụ động, nhưng giả sử người kia chủ động, và sẽ được lợi nếu oracle quyết định rằng WETH báo cáo không có giá trị. Vì vậy, giả sử người báo cáo ban đầu là người thao túng trong nhóm này, vì họ có thể trả giá cao hơn tất cả những người khác trong Block.
Trong báo cáo ban đầu, họ nêu rõ:
token1Số tiền: 0,1 WETH
token2Số tiền: 150 USDC
Số dư hợp đồng oracle hiện là 0,001 ETH, 0,1 WETH và 150 USDC.
Số dư báo cáo này ngụ ý giá ETH là 1500 đô la trong khi giá thực tế là 3000 đô la.
Sau khi thời gian giải quyết là 10 giây, giả sử không có ai tranh chấp báo cáo này, báo cáo có thể được giải quyết và có thể sử dụng cho ứng dụng, với mức giá rất cao. Tuy nhiên, việc tranh chấp này sẽ có lợi nhuận, vì vậy chúng tôi giả định rằng sẽ có người tranh chấp xuất hiện trước khi thời gian 10 giây kết thúc.
Trong tranh chấp, họ nêu rõ:
token1Số tiền mới: 0,15 WETH
token2Số tiền mới: 450 USDC
tokenToSwap: USDC
Họ quyết định hoán đổi với 150 USDC của người báo cáo ban đầu, nghĩa là họ chọn USDC làm Token để hoán đổi trong tranh chấp của mình. Token1AmountNew lớn hơn 50% so với quy tắc báo cáo ban đầu theo hợp đồng, sử dụng hệ số nhân 1,5x từ yêu cầu giá. Dòng Token như sau:
Hợp đồng oracle lấy 150 USDC từ bên tranh chấp, sau đó thêm số tiền này vào 150 USDC gốc của người báo cáo ban đầu và gửi toàn bộ cho người báo cáo ban đầu, tổng cộng là 300 USDC được gửi cho người báo cáo ban đầu.
Tiếp theo, hợp đồng oracle lấy 450 USDC và 0,05 WETH từ bên tranh chấp và thêm vào báo cáo.
Số dư hợp đồng hiện là 0,001 ETH, 0,15 WETH và 450 USDC và bộ đếm thời gian thanh toán được đặt lại thành 10 giây nữa.
Giả sử kẻ thao túng nhượng bộ và thời gian thanh toán 10 giây trôi qua, bất kỳ ai cũng có thể đến và thanh toán mức giá được báo cáo. Giá của Oracle là 3000 đô la trong khi giá thực tế là 3000 đô la.
Trong quá trình thanh toán, người thanh toán chỉ xác định báo cáo nào họ đang thanh toán. Thông thường, họ nhận được một số phần thưởng thanh toán bằng ETH do người yêu cầu giá thanh toán, nhưng chúng tôi giả định là 0 trong ví dụ này. Dòng Token trong quá trình thanh toán như sau:
Người báo cáo ban đầu (người thao túng) nhận được 0,001 ETH từ phần thưởng báo cáo ban đầu. Phần thưởng này phải được trừ vào chi phí gas khi trả giá cao hơn những người khác để trở thành người báo cáo ban đầu đầu tiên.
Người tranh chấp nhận lại 450 USDC và 0,15 WETH.
Số dư hợp đồng hiện bằng 0 trên tất cả ETH và token. Nếu chúng ta cộng các luồng giao dịch trên toàn bộ vòng đời của Oracle từ yêu cầu giá, báo cáo ban đầu, tranh chấp và thanh toán, chúng ta sẽ thấy như sau:
Phóng viên đầu tiên:
USDC: +150
WETH: -0,1
Người tranh chấp:
USDC: -150
WETH: +0,1
Giả sử phí gas và phần thưởng báo cáo ban đầu gần bằng 0. Giá thực của ETH là 3.000 đô la, do đó kẻ thao túng mất 150 đô la, người tranh chấp kiếm được 150 đô la, và giá oracle được xử lý công bằng để ứng dụng sử dụng. Nếu kẻ thao túng quyết định tiếp tục cố gắng thao túng giá bằng cách tranh chấp báo cáo của người tranh chấp trung thực, họ sẽ mất một khoản tiền tăng theo cấp số nhân, tỷ lệ thuận với sai số trong giá được báo cáo.
Việc triển khai oracle tham chiếu trong Solidity có nhiều tham số cần điều chỉnh hơn, như phí hoán đổi, dừng leo thang, độ trễ tranh chấp, chế độ thời gian (giây so với khối) và nhiều tham số khác, nhưng phiên bản đơn giản hóa chính xác hơn về cách thức hoạt động của các ưu đãi.
Phí hoán đổi là một tham số quan trọng đối với một phiên bản Oracle nhất định. Người báo cáo mới sẽ trả cho người báo cáo trước đó một khoản phí hoán đổi theo tỷ lệ phần trăm, được thiết lập tại thời điểm yêu cầu giá. Nếu phí hoán đổi quá thấp so với biến động thị trường nền trong thời gian thanh toán đã chỉ định, tổng thời gian thanh toán có thể kéo dài do các tranh chấp về việc đặt lại bộ đếm thời gian thường xuyên xảy ra. Mặt khác, nếu phí hoán đổi quá cao, người dùng thụ động của giá Oracle sẽ phải chịu lỗ chênh lệch giá vì một kẻ thao túng chủ động có thể cố gắng đưa giá về mức nằm trong giới hạn phí hoán đổi nhưng lại cách xa giá thực.
Vì vậy, có sự đánh đổi cơ bản giữa tổng thời gian hoàn thiện phiên bản oracle và tổn thất chênh lệch giá đối với người dùng cuối.
Xét về mức lỗ chênh lệch giá tối đa mà một người dùng cuối hoàn toàn thụ động phải chịu, con số này nhỏ hơn tổng phí hoán đổi oracle nội bộ mỗi vòng cộng với phí gas cộng với tổn thất nhảy cho người báo cáo. Chúng tôi gọi đây là phí hoán đổi hiệu dụng F (phí hoán đổi + phí gas + tổn thất nhảy). Chúng tôi giả định rằng nếu giá nằm ngoài F, nó sẽ bị tranh chấp bởi 1 trong n người tham gia vì lợi ích riêng. Vì chỉ có giá cuối cùng còn lại góp phần vào sai số giá trong một giá trị danh nghĩa bên ngoài, nên tổng giá trị có thể trích xuất là <= F.
Lỗ nhảy là một chi phí cho các phóng viên bất kể giá biến động theo hướng nào. Giá Token có thể dao động không liên tục vượt quá +/- F và phóng viên sẽ phải chịu phần chênh lệch so với phí hoán đổi độc lập sau khi có người tranh chấp và điều chỉnh giá. Hệ số nhân cao hơn khiến phóng viên phải chịu lỗ nhảy nhiều hơn mỗi vòng so với sai số giá tự nhiên của báo cáo trước đó.
Việc dừng leo thang là một thông số quan trọng khác. Sau thời điểm dừng này, tranh chấp có thể tiếp tục nhưng không cần phải đặt cọc số lượng tài sản thế chấp tăng theo cấp số nhân nữa. Bằng cách này, bạn có thể đảm bảo phiên bản oracle không leo thang vượt quá khả năng chịu đựng của mạng lưới tranh chấp trong khi vẫn áp dụng hình phạt cao đối với những kẻ thao túng.
Bạn có thể xem triển khai Solidity đầy đủ bên dưới. Lưu ý rằng các mục nhập hàm trực tiếp có thể được bổ sung bằng các biện pháp bảo vệ tổ chức lại hợp đồng/phát lại bên ngoài (ví dụ: nếu giao dịch không nằm trong số Block đã truyền và dấu thời gian được hoàn nguyên, hoặc thanh toán phải sử dụng yêu cầu giá khớp stateHash), điều này có thể giúp ích nhưng không loại bỏ được rủi ro.
Rất mong nhận được phản hồi hoặc góp ý về thiết kế, và rất sẵn lòng trả lời mọi thắc mắc! Chúng tôi hy vọng được đóng góp vào sự phát triển của các ứng dụng tài chính thực sự phi tín nhiệm.
