아래 오라클은 누구나 사용할 수 있는 토큰 가격을 얻는, 신뢰가 최소화되고 비허가형(Permissionless) 방식으로 설계되었습니다.
오라클의 가장 기본적인 기능은 리포터가 동일한 가격으로 매수 호가와 매도 호가를 모두 제출하도록 하는 것입니다. 누구든 소액의 수수료(부분 체결 불가) 없이 이러한 주문과 맞바꿀 수 있습니다. 일정 시간 동안 아무도 두 주문 중 하나를 수락하지 않으면, 이는 정산에 사용될 수 있는 적정 가격의 증거가 됩니다. 주문이 수락되면, 테이커는 두 토큰 모두에 담보를 제공하고 새로운 가격을 제시해야 하며, 타이머가 다시 시작됩니다.
오라클은 분쟁 발생 시 기하급수적인 담보 증가를 활용하여 조작 비용을 높이고 사용자에게 총 결제 시간과 지연 비용에 대한 통계적 보장을 제공합니다. 평균적으로 정확한 가격을 보고하는 데 필요한 자본 보고된 가격으로 결제된 명목 금액보다 훨씬 낮을 수 있습니다. 오라클의 목표는 기존의 중앙 집중식 및 신뢰할 수 있는 오라클 중개자를 대체하여 DeFi 애플리케이션의 장애 발생 지점을 줄이는 것입니다.
이 설계는 오라클이 정한 외부 입장과 경제적으로 일치하지 않는 n명의 이기적인 참여자 중 1명의 거래가 마감일 전에 포함된다는 가정에 의존합니다.
이 설계의 명확한 한계 중 하나는 검열입니다(불량 가격 제출 → 검열 분쟁 → 수익). 이는 오라클이 L2에서 확보할 수 있는 보안 수준에 엄격한 제한을 두며, FOCIL이 시행될 때까지 공격자가 여러 블록을 연속으로 제어할 가능성을 줄이기 위해 L1에서 더 긴 결제 시간을 사용해야 합니다.
다음은 오라클 수명 주기의 간단한 예입니다.
애플리케이션이 WETH와 USDC의 가격을 비교하고 싶어한다고 가정해 보겠습니다. 가격 요청에서 다음과 같이 지정합니다.
- 토큰1: WETH
- 토큰2: USDC
- token1금액: 0.1 WETH
- 결제시간: 10초
- 승수: 1.5배
- 보상: 0.001 이더리움(ETH)
오라클 계약 잔액은 현재 0.001 이더리움(ETH) 입니다.
이 가격 요청은 온체인으로 전송되며 누구나 가격을 보고할 수 있습니다. 이더리움(ETH) 가격이 3,000달러라고 가정해 보겠습니다. 다음 단계는 보고자가 초기 보고서를 제출하여 다른 모든 사람과 경쟁하여 0.001 이더리움(ETH) 획득하는 것입니다.
애플리케이션에서 오라클을 사용하여 가격을 계산했기 때문에, 서로 반대 위치에 있는 두 사람이 있다고 가정합니다. 즉, 가격이 더 높게 보고되면 한 사람은 이득을 얻고 다른 사람은 손해를 보며, 그 반대의 경우도 마찬가지입니다. 한 사람은 완전히 수동적인 반면, 다른 한 사람은 능동적인 상태이며, 오라클이 WETH 보고를 덜 가치 있다고 판단하면 이득을 볼 것이라고 가정해 보겠습니다. 따라서 최초 보고자가 이 집단에서 조작자라고 가정해 보겠습니다. 왜냐하면 그는 블록 내 다른 모든 사람보다 더 높은 가격을 제시할 수 있기 때문입니다.
최초 보고서에서는 다음 사항을 명시했습니다.
token1금액: 0.1 WETH
token2금액: 150 USDC
오라클 계약 잔액은 현재 0.001 이더리움(ETH), 0.1 WETH, 150 USDC입니다.
이 보고서 잔액은 실제 가격이 3,000달러일 때 이더리움(ETH) 가격이 1,500달러임을 의미합니다.
10초 동안 정산 후, 아무도 이 보고서에 이의를 제기하지 않는다고 가정할 때, 보고서는 정산되어 애플리케이션에서 사용 가능할 수 있지만, 엄청난 비용이 발생할 수 있습니다. 하지만 이 보고서에 이의를 제기하는 것이 유리하므로, 10초가 지나기 전에 이의 제기자가 나타날 것으로 가정합니다.
분쟁에서 그들은 다음과 같이 명시합니다.
token1금액신규: 0.15 WETH
token2AmountNew: 450 USDC
토큰 스왑: USDC
이들은 최초 보고자의 150 USDC와 교환하기로 결정했습니다. 즉, 분쟁에서 교환할 토큰으로 USDC를 선택했습니다. token1AmountNew는 가격 요청의 1.5배 승수를 적용한 계약별 최초 보고 규칙보다 50% 더 큽니다. 토큰 흐름은 다음과 같습니다.
오라클 계약은 분쟁 당사자로부터 150 USDC를 가져온 다음, 이를 최초 보고자의 원래 150 USDC에 더한 후 전부 최초 보고자에게 보냅니다. 즉, 최초 보고자에게 보낸 총 금액은 300 USDC입니다.
다음으로, 오라클 계약은 분쟁 당사자로부터 450 USDC와 0.05 WETH를 가져와 보고서에 추가합니다.
계약 잔액은 현재 0.001 이더리움(ETH), 0.15 WETH, 450 USDC이며 결제 시간 타이머는 10초로 재설정됩니다.
조작자가 양보하고 10초의 결제 시간이 지난다고 가정해 보겠습니다. 누구든 와서 보고된 가격을 결제할 수 있습니다. 오라클 가격은 3,000달러이고 실제 가격은 3,000달러입니다.
정산 과정에서 정산자는 정산할 보고서만 지정합니다. 일반적으로 정산자는 가격 요청자가 지불한 이더리움(ETH) 로 정산자 보상을 받지만, 이 예시에서는 0으로 가정합니다. 정산 과정에서 토큰 흐름은 다음과 같습니다.
최초 보고자(조작자)는 최초 보고 보상으로 0.001 이더리움(ETH) 받습니다. 이 금액은 최초 보고자가 되기 위해 다른 모든 사람을 제치고 입찰하는 데 드는 가스 비용에서 차감되어야 합니다.
분쟁자는 450 USDC와 0.15 WETH를 돌려받습니다.
모든 이더리움(ETH) 와 토큰의 계약 잔액은 이제 0입니다. 가격 요청, 초기 보고, 분쟁 및 정산의 전체 오라클 수명 주기에 걸쳐 흐름을 합산하면 다음과 같습니다.
최초 보고자:
USDC: +150
웨스: -0.1
분쟁자:
USDC: -150
웨스: +0.1
가스비와 최초 보고자 보상이 거의 0에 가깝다고 가정해 보겠습니다. 이더리움(ETH) 의 실제 가격은 3,000달러이므로 조작자는 150달러를 잃고, 이의를 제기한 사람은 150달러를 벌며, 오라클 가격은 애플리케이션에서 사용할 수 있도록 공정하게 결정됩니다. 만약 조작자가 정직한 이의 제기자의 보고에 이의를 제기하여 가격 조작을 계속 시도한다면, 보고된 가격의 오차에 따라 기하급수적으로 증가하는 금액을 잃게 될 것입니다.
솔리디티 에서 참조 오라클을 구현하는 데는 스왑 수수료, 에스컬레이션 중단, 분쟁 지연, 시간 모드(초 대 블록) 등 조정할 수 있는 매개변수가 더 많지만, 인센티브가 작동하는 방식과 관련해서는 단순화된 버전이 정확합니다.
스왑 수수료는 특정 오라클 인스턴스에서 중요한 매개변수입니다. 새로운 리포터는 가격 요청 시점에 설정된 스왑 수수료(%)를 이전 리포터에게 지불합니다. 지정된 결제 시간 동안 배경 시장 변동성에 비해 스왑 수수료가 너무 낮으면, 타이머를 재설정하는 분쟁이 더 흔해짐에 따라 결제까지 걸리는 총 시간이 길어질 수 있습니다. 반면 스왑 수수료가 너무 높으면, 오라클 가격을 수동적으로 사용하는 사용자가 차익거래 손실에 노출될 수 있습니다. 적극적인 조작자가 스왑 수수료 한도 내에서 실제 가격과는 다른 어딘가에 가격을 정산하려고 할 수 있기 때문입니다.
따라서 전체 오라클 인스턴스 마무리 시간과 최종 사용자의 차익 손실 사이에는 근본적인 상충 관계가 있습니다.
완전히 수동적인 최종 사용자가 노출되는 최대 차익거래 손실 측면에서, 이 수치는 라운드당 총 내부 오라클 스왑 수수료, 가스 수수료, 그리고 리포터의 점프 손실보다 훨씬 적습니다. 이를 유효 스왑 수수료 F(스왑 수수료 + 가스 수수료 + 점프 손실)라고 합니다. 가격이 F 범위를 벗어나면, n명의 이해관계를 가진 참여자 중 1명이 이의를 제기할 것이라고 가정합니다. 최종적으로 살아남는 가격만이 외부 명목 가격의 오류에 기여하므로, 총 추출 가능 가치는 F 이하입니다.
점프 손실은 가격 변동 방향과 관계없이 리포터에게 비용입니다. 토큰 가격은 불연속적으로 +/- F를 초과할 수 있으며, 리포터는 누군가 가격에 이의를 제기하고 가격을 정정한 후, 단독 스왑 수수료 대비 차액을 부담해야 합니다. 승수가 높을수록 리포터는 이전 리포터의 자연스러운 가격 오차에 비해 라운드당 더 큰 점프 손실을 부담하게 됩니다.
에스컬레이션 중단은 또 다른 중요한 매개변수입니다. 이 중단 후에도 분쟁은 계속될 수 있지만, 더 이상 기하급수적으로 증가하는 담보 금액을 제공할 필요는 없습니다. 이렇게 하면 오라클 인스턴스가 분쟁 네트워크의 예상 용량을 초과하여 에스컬레이션되지 않도록 보장하는 동시에 조작자에게 높은 페널티를 부과할 수 있습니다.
전체 솔리디티 구현은 아래에서 확인할 수 있습니다. 직접 함수 입력은 외부 계약 재구성/재생 가드(예: 거래 내역이 전달된 블록 번호 및 타임스탬프 내에 없는 경우, 반환 또는 정산 시 일치하는 가격 요청 상태 해시를 사용해야 함)로 보완될 수 있지만, 위험을 완전히 제거할 수는 없습니다.
디자인에 대한 피드백이나 비판을 환영합니다. 궁금한 점이 있으시면 언제든지 문의해 주세요! 저희는 진정으로 신뢰가 필요 없는 금융 애플리케이션 개발에 기여하고자 합니다.
