원저자: Adrian Chow

제공: Jonathan Yuen 및 Wintersoldier

요약

• 오라클은 DeFi 프로토콜의 락업 가치를 보장하는 데 없어서는 안 될 존재로, 전체 DeFi 락업 규모 500억 달러 중 330억 달러가 오라클에 의해 보장됩니다.

• 그러나 오라클 가격 피드 업데이트에 내재된 시간 지연으로 인해 최대 추출 가능 가치(MEV)라는 가치 추출 하위 유형이 발생하며 이를 Oracle Extractable Value(OEV)라고 하며 OEV에는 오라클 선행 거래, 차익거래 및 비효율적인 청산이 포함됩니다.

• 부정적인 OEV 블리딩을 방지하거나 완화하는 데 사용할 수 있는 설계 구현의 수가 점점 늘어나고 있으며 각각 고유한 장단점이 있습니다. 이 기사에서는 기존 디자인 옵션과 그 장단점에 대해 논의하고 두 가지 새로운 아이디어, 가치 제안, 공개 문제 및 개발 병목 현상을 제안합니다.

소개

오라클은 오늘날 DeFi에서 가장 중요한 인프라 중 하나라고 할 수 있습니다. 이는 파생 상품 계약을 정산하고 담보가 부족한 포지션을 마감하는 등의 작업을 위해 가격 피드에 의존하는 대부분의 DeFi 프로토콜의 필수적인 부분입니다. 현재 오라클은 미화 330억 달러의 가치를 보장하며 이는 체인의 전체 락업 규모 미화 500억 달러 중 최소 2/3를 차지합니다 1 . 그러나 애플리케이션 개발자의 경우 오라클을 추가하면 선행 거래, 차익거래 및 비효율적인 청산을 통한 가치 손실로 인해 발생하는 명백한 설계 상충 관계 및 문제가 발생합니다. 이 기사에서는 이러한 가치 손실을 OEV(Oracle Extractable Value)로 분류하고, 애플리케이션 관점에서 주요 문제를 간략하게 설명하며, 업계 연구를 기반으로 DeFi 프로토콜에 OEV를 안전하고 안정적으로 추가하는 방법을 설명하려고 합니다.

Oracle 추출 가능 값(OEV)

이 섹션에서는 독자가 Oracle 기능과 푸시 기반 Oracle과 Pull 기반 Oracle의 차이점에 대한 기본적인 이해를 가지고 있다고 가정합니다. 개별 오라클의 가격 피드는 다를 수 있습니다. 개요, 분류 및 정의는 부록을 참조하세요.

오라클 가격 피드를 사용하는 대부분의 애플리케이션에는 가격 읽기만 필요합니다. 자체 가격 책정 모델을 실행하는 분산형 거래소는 오라클 가격 피드를 기준 가격으로 사용합니다. 초과 담보 대출 포지션에 대한 담보 예금에는 오라클 읽기만 필요합니다. 차용 가치와 같은 초기 매개변수를 결정하기 위해 가격을 가져옵니다. 가격 업데이트가 너무 빈번하지 않은 롱테일 자산과 같은 극단적인 경우를 제외하면 기본적으로 오라클이 가격 피드를 업데이트하는 지연은 시스템 설계를 고려할 때 중요하지 않습니다. 따라서 오라클에 대한 가장 중요한 고려 사항은 가격 기여자의 정확성과 오라클 제공자의 분산된 성능입니다.

그러나 가격 피드 업데이트의 대기 시간이 중요한 고려 사항이라면 오라클이 애플리케이션과 상호 작용하는 방식에 더 많은 주의를 기울여야 합니다. 일반적으로 이 경우 이러한 지연은 선행 거래, 차익거래 및 청산과 같은 가치 추출 기회로 이어집니다. MEV의 이러한 하위 유형을 OE V2라고 합니다. 다양한 구현과 그 장단점을 논의하기 전에 다양한 형태의 OEV에 대해 간략하게 설명하겠습니다.

중재

Oracle 선행 거래 및 차익 거래는 일반적으로 파생 상품 프로토콜에서 독성 흐름으로 알려져 있습니다. 왜냐하면 이러한 거래는 정보 비대칭 하에서 수행되고 유동성 공급자의 이익을 희생하더라도 위험이 없는 경우가 많기 때문입니다. Synthetix와 같은 OG DeFi 프로토콜은 2018년부터 이 문제를 해결하기 위해 노력해 왔으며 이러한 부정적인 외부 효과를 완화하기 위해 시간이 지남에 따라 다양한 솔루션을 시도했습니다.

간단한 예를 들어 설명하자면, 무기한 계약 분산형 거래소 xyz는 ETH/USD 시장에서 Chainlink 오라클을 사용합니다. 이 예에서는 ETH/USD 가격 피드를 사용하여 설명합니다.

그림 1: Chainlink 오라클을 사용한 차익거래의 예

위의 예는 슬리피지, 수수료 또는 자금 조달과 같은 요소를 고려하지 않은 지나치게 단순화된 예이지만, 편차 임계값의 역할로 인한 가격 세분성 부족으로 인해 발생하는 기회를 보여줍니다. 검색자는 현물 시장 가격 업데이트의 대기 시간을 모니터링하고 Chainlink의 온체인 스토리지를 기반으로 유동성 공급자(LP)로부터 위험 없는 가치를 추출할 수 있습니다.

선두에 서는

차익거래와 유사한 선행 실행은 검색자가 오라클 업데이트를 위해 멤풀을 모니터링하고 체인에 커밋하기 전에 실제 시장 가격을 선행 실행하는 또 다른 형태의 가치 추출입니다. 이런 방식으로 검색자는 오라클이 업데이트되기 전에 입찰 및 거래할 시간을 갖게 되며, 거래 방향에 유리한 가격으로 거래가 완료됩니다.

GMX와 같은 영구 계약 탈중앙화 거래소는 항상 유독한 선행 거래의 피해자였으며, GMX의 모든 오라클이 KeeperDAO 조정 프로토콜을 통해 업데이트되기 전에 프로토콜 수익의 약 10%가 선행 거래로 손실되었습니다4.

풀 모델을 사용하면 어떨까요?

Python의 가치 제안 중 하나는 Solana 아키텍처 기반 Python을 사용하여 게시자가 300밀리초마다 네트워크에 가격 업데이트를 푸시할 수 있어 지연 시간이 짧은 가격 피드를 유지할 수 있다는 것입니다. 따라서 애플리케이션이 Pyth의 애플리케이션 프로그래밍 인터페이스(API)를 통해 가격을 쿼리하면 최신 가격을 검색하고 이를 대상 체인의 온체인 스토리지로 업데이트하며 단일 트랜잭션의 애플리케이션 로직에서 모든 다운스트림 작업을 수행할 수 있습니다.

위에서 언급했듯이 애플리케이션은 Python에 최신 가격 업데이트를 직접 쿼리하고, 온체인 스토리지를 업데이트하고, 관련된 모든 로직을 한 번의 트랜잭션으로 완료할 수 있습니다. 이것이 선점 및 차익거래 문제를 효과적으로 해결하지 않을까요?

그게 전부는 아닙니다. 사용자에게 거래에 사용되는 가격을 선택할 수 있는 기능을 제공하는 Pyth 업데이트는 역선택(또 다른 독극물)으로 이어질 수 있습니다. 가격은 시간이 지남에 따라 온체인에 저장되어야 하지만 사용자는 이러한 제약 조건을 충족하는 가격을 선택할 수 있습니다. 즉, 검색자가 과거 가격을 사용하기 전에 미래 가격을 볼 수 있으므로 차익 거래가 여전히 존재한다는 의미입니다. Pyth의 문서6에서는 이 공격 벡터로부터 보호하는 간단한 방법은 가격이 충분히 최근인지 확인하기 위해 부실 검사를 추가하는 것이라고 제안합니다. 그러나 다음 블록에서 거래 데이터를 업데이트하기 전에 특정 버퍼 시간이 있어야 합니다. 최적의 시간 임계값은 무엇입니까?

무기한 계약 분산형 거래소 xyz를 분석 예로 들어보겠습니다. 이번에는 Pyth ETH/USD 가격 피드를 사용하고 있으며 만료 확인 시간은 20초입니다. 이는 Pyth 가격의 타임스탬프가 실행 중이어야 함을 의미합니다. 다운스트림 트랜잭션의 블록 타임스탬프로부터 20초 이내:

그림 2: Pyth를 사용한 전면 실행 예제 프로세스

직관적인 아이디어는 단순히 만료 확인 임계값을 낮추는 것입니다. 그러나 임계값이 낮으면 차단 시간에 예측할 수 없는 네트워크 응답이 발생하여 사용자 경험에 영향을 미칠 수 있습니다. Pyth의 가격 피드는 브리징에 의존하기 때문에 a) Wormhole Guardians가 가격을 증명할 시간을 제공하고 b) 대상 체인이 거래를 처리하고 이를 블록에 포함할 수 있도록 충분한 버퍼링이 필요합니다. 이러한 장단점은 다음 섹션에서 자세히 설명합니다.

포지션 닫기

포지션 마감은 레버리지와 관련된 모든 계약의 핵심 부분이며, 가격 피드 업데이트의 세분성은 포지션 마감의 효율성을 결정하는 데 중요한 역할을 합니다.

임계값 기반 푸시 오라클의 경우 현물 가격이 임계값에 도달했지만 오라클 가격 피드의 미리 설정된 매개변수를 충족하지 않으면 가격 업데이트의 세분성(또는 세분성 부족)으로 인해 다음 기회를 놓칠 수 있습니다. 포지션을 닫습니다. 이는 시장 비효율성이라는 부정적인 외부효과를 낳는다.

청산이 발생하면 애플리케이션은 종종 청산 담보의 일부를 지불하고 때로는 청산을 시작한 사용자에게 보상을 제공합니다. 예를 들어, 2002년에 Aave는 메인넷에서만 청산 보상으로 3,790만 달러를 지불했습니다 7 . 이는 분명히 제3자에게 과잉 보상을 하고 사용자의 성과를 저하시킵니다. 또한 추출 가능한 가치가 있는 경우, 그에 따른 가스 전쟁으로 인해 애플리케이션에서 가치가 고갈되어 MEV 공급망으로 흘러갑니다.

디자인 공간 및 고려 사항

위의 문제를 고려하여 푸시, 풀 및 대체 설계를 기반으로 한 다양한 구현 솔루션이 아래에서 논의될 것이며, 각각은 위의 문제와 관련된 절충점을 해결하는 데 효과적입니다. 절충점은 추가적인 중앙 집중화의 형태일 수 있습니다. 신뢰 전제 조건 또는 열악한 사용자 경험.

오라클 전용 OFA(주문 흐름 경매)

주문 흐름 입찰 OFA는 MEV로 인해 발생하는 부정적인 외부 효과를 제거하기 위한 솔루션으로 등장했습니다. 광범위하게 말하면 OFA는 사용자가 주문(거래 또는 의도)을 보낼 수 있는 범용 제3자 입찰 서비스이며, MEV를 추출한 검색자는 자신의 주문에 대한 전략을 실행하기 위한 독점적 권리에 입찰할 수 있습니다. 경매 수익의 상당 부분은 사용자가 이러한 주문에서 창출한 가치를 보상하기 위해 사용자에게 반환됩니다. 최근 OFA 채택률이 급증하여 이더리움 거래의 10% 이상이 개인 채널(개인 RPC/OFA)을 통해 이루어졌으며(그림 3), 이는 성장을 더욱 촉진할 것으로 여겨집니다.

그림 3: 개인 이더리움 거래의 일일 통합 횟수. 출처: 블록네이티브

오라클 업데이트에서 범용 OFA를 구현할 때의 문제점은 오라클이 표준 규칙을 기반으로 한 업데이트가 OEV를 생성할지 여부를 알 수 없으며, 그렇지 않은 경우 오라클이 트랜잭션을 경매에 보낼 때 추가 지연이 발생한다는 것입니다. 반면, OEV를 간소화하고 대기 시간을 최소화하는 가장 간단한 방법은 모든 오라클 주문 흐름을 단일 지배적인 검색자에게 제공하는 것입니다. 그러나 이는 분명히 큰 중앙화 위험을 가져오고, 지대추구 행위와 검열을 조장하고, 사용자 경험을 저하시킬 수 있습니다.

그림 4: 일반 OFA 및 Oracle 특정 OFA

기존 규칙 기반 업데이트를 포함하지 않는 Oracle 관련 OFA에 대한 가격 업데이트는 여전히 공개 mempool에서 이루어집니다. 이를 통해 오라클의 가격 업데이트와 그로 인해 발생하는 추출 가능한 값이 애플리케이션 계층에 유지될 수 있습니다. 또한, 부산물로서 오라클 노드가 더 빈번한 업데이트에 따른 추가 비용을 부담하지 않고도 검색자가 데이터 소스 업데이트를 요청할 수 있도록 하여 데이터의 세분성을 높입니다.

Oracle 전용 OFA는 보다 세분화된 가격 업데이트를 제공하고, 포지션이 청산된 차용자에 대한 자본 수익을 극대화하고, 청산인에게 지급되는 프로토콜 보상을 줄일 수 있기 때문에 포지션 청산에 이상적입니다. 입찰자는 사용자에게 재분배하기 위해 입찰자에 유지됩니다. 그들은 또한 선점 및 차익거래 문제를 완전히는 아니지만 어느 정도 해결합니다. 완전 경쟁 및 1차 가격 봉인 입찰 경매 프로세스에서 경매 결과는 선행 OEV 데이터 피드에서 추출된 실행 기회 8에 가까운 블록 공간 비용뿐만 아니라 생성된 차익거래 기회의 감소여야 합니다. 가격 피드 업데이트의 가격 세분성이 높아졌습니다.

현재 오라클별 OFA를 구현하려면 제3자 입찰 서비스(예: OEV-Share)에 가입하거나 애플리케이션의 일부로 입찰 서비스를 구축해야 합니다. Flashbots에서 영감을 받은 API 3은 입찰에 대한 DoS 보호 서비스를 수행하도록 설계된 API로 OEV 릴레이(그림 5)를 활용합니다. 이 릴레이는 오라클로부터 메타 거래를 수집하고, 검색자 입찰을 대조 및 집계하며, 입찰을 제어하지 않고 무신뢰 방식으로 수익금을 재분배하는 역할을 담당합니다. 검색자가 입찰에 성공하면 데이터 소스 업데이트는 입찰 금액을 프로토콜 소유 프록시 계약으로 전송하는 데에만 의존할 수 있으며, 그런 다음 중계자가 제공한 서명된 데이터로 가격 소스를 업데이트합니다.

그림 5: API 3용 OEV 리피터

또는 프로토콜은 중개자를 제거하고 자체 입찰 서비스를 구축하여 OEV에서 추출된 모든 가치를 포착할 수 있습니다. BBOX는 OEV를 포착하고 이를 애플리케이션과 사용자에게 반환하기 위해 청산 메커니즘에 입찰을 포함시키려는 향후 프로토콜 중 하나입니다 9 .

중앙 노드 또는 Keeper 실행

OEV에 맞서기 위한 영구 계약 탈중앙화 거래소의 첫 번째 물결에서 나온 초기 아이디어는 중앙집중형 Keeper 네트워크(게이트키퍼 네트워크)를 실행하여 제3자 소스(예: 중앙화 거래소)로부터 받은 가격을 집계한 다음 Chainlink와 같은 데이터 피드를 활용하는 것이었습니다. 비상 계획 또는 회로 차단기. 이 모델은 GMX v1 10과 그 이후의 많은 포크에서 대중화되었으며, 주요 가치 제안은 Keeper 네트워크가 단일 운영자에 의해 운영되기 때문에 전면 실행으로부터 절대적으로 보호된다는 것입니다.

이를 통해 위에서 언급한 많은 문제가 해결되지만 중앙 집중화에 대한 우려도 분명히 있습니다. 중앙집중형 Keeper 시스템은 가격 소스와 집계 방법에 대한 적절한 검증 없이 실행 가격을 결정할 수 있습니다. GMX v1의 경우 Keeper는 온체인이나 투명한 메커니즘이 아니라 중앙 서버에서 실행되는 팀 주소로 서명된 프로그램입니다. Keeper의 핵심 역할은 명령을 실행하는 것뿐만 아니라 자체 사전 정의에 따라 명령을 실행하는 것입니다."결정하다"거래 가격, 사용된 실행 가격의 진위나 출처를 확인할 방법이 없습니다.

자동화된 키퍼 네트워크 및 체인링크 데이터 흐름

위에서 언급한 단일 운영자 Keeper 네트워크로 인한 중앙화 위험에 대한 해결책은 제3자 서비스 제공업체를 활용하여 보다 분산화된 자동화 네트워크를 구축하는 것입니다. Chainlink Automation은 그러한 제품 중 하나이며, 새로운 풀 기반의 저지연 오라클인 Chainlink Data Streams와 함께 이 서비스를 제공합니다. 이 제품은 최근 출시되어 현재 비공개 베타 버전이지만 GMX v2 11에서는 이미 이를 사용하고 있으며 이 디자인을 사용하는 시스템에 대한 참조 역할을 할 수 있습니다.

높은 수준에서 Chainlink 데이터 흐름은 데이터 DON(분산형 오라클 네트워크), 자동화된 DON 및 온체인 검증 계약의 세 가지 주요 부분으로 구성됩니다 12 . Data DON은 Python이 데이터를 유지하고 집계하는 방식과 유사한 아키텍처를 갖춘 오프체인 데이터 네트워크입니다. 자동화된 DON은 온체인 데이터 DON에서 가격을 추출하는 데 사용되는 데이터 DON과 동일한 노드 운영자가 보호하는 가디언 네트워크입니다. 마지막으로 검증인 계약을 사용하여 오프체인 서명이 올바른지 확인합니다.

그림 6: 체인링크 데이터 흐름 아키텍처

위 그림은 오픈 트랜잭션 기능을 호출하는 트랜잭션 프로세스를 보여줍니다. 여기서 자동화된 DON은 데이터 DON에서 가격을 얻고 온체인 스토리지를 업데이트하는 역할을 담당합니다. 현재 데이터 DON을 직접 쿼리하기 위한 엔드포인트는 화이트리스트 사용자로 제한되어 있으므로 프로토콜은 Keeper 유지 관리 작업을 자동화 DON(Automation DON)으로 오프로드하거나 자체 Keeper를 실행하도록 선택할 수 있습니다. 그러나 제품 개발 수명 주기가 진행됨에 따라 점차 무허가형 구조로 전환될 것으로 예상됩니다.

보안 수준에서 자동화된 DON에 의존하는 신뢰 가정은 데이터 DON에 대한 가정과 동일하며 이는 단일 Keeper 설계에 비해 크게 개선되었습니다. 그러나 가격 피드를 업데이트하는 권한이 자동화된 DON에 부여되면 가치 추출 기회는 Keeper 네트워크의 노드에만 남을 수 있습니다. 이는 결국 프로토콜이 사회적 평판을 유지하기 위해 LinkToken 노드 운영자(주로 기관)를 신뢰하고 사용자의 운영을 선점하지 않는다는 것을 의미합니다. 이는 Lido 노드 노드 운영자가 명성을 유지하도록 신뢰하는 것과 유사하며 큰 시장 점유율을 가지고 있습니다. 블록 공간을 독점합니다.

풀(Pull): 정산 지연

Synthetix perps v2의 가장 큰 변화 중 하나는 무기한 계약 결제를 위한 Python 가격 피드 13의 도입입니다. 이를 통해 주문이 미리 정의된 임계값 이상으로 벗어나지 않고 타임스탬프가 만료 확인을 통과하는 경우 Chainlink 또는 Pyth 가격으로 주문을 결제할 수 있습니다. 그러나 위에서 언급한 것처럼 단순히 풀 기반 오라클로 전환한다고 해서 모든 프로토콜의 OEV 관련 문제가 해결되는 것은 아닙니다. 선점 문제를 해결하기 위해 지연 주문 형태로 도입될 수 있습니다."마지막으로 본"실제로 가격 책정 메커니즘은 사용자의 시장 주문을 두 부분으로 나눕니다.

• 거래 #1: 시장 주문을 개설하려면 온체인으로 제출하세요."의도", 크기, 레버리지, 담보 및 미끄러짐 허용 오차와 같은 표준 주문 매개변수를 제공합니다. 동시에 트랜잭션 #2를 실행한 Keeper에게 보상을 제공하려면 추가 Keeper 수수료가 필요합니다.

• 거래 #2: Keeper는 거래 #1에서 제출된 주문을 받고, 최신 Python 가격 피드를 요청하고, Synthetix를 호출하여 한 번의 거래로 계약을 실행합니다. 계약은 적시성, 가격 하락 등 사전 정의된 매개변수를 확인하며, 두 가지 모두 통과하면 주문이 실행되고 온체인 가격 저장소가 업데이트되며 포지션이 확정됩니다. 키퍼는 네트워크를 사용하고 유지하는 데 사용되는 가스에 대한 보상으로 수수료를 청구합니다.

이 구현은 사용자에게 체인에 제출된 가격을 반대로 선택할 수 있는 기회를 제공하지 않으며, 프로토콜에 대한 선행 거래 및 차익 거래 기회를 효과적으로 해결합니다. 그러나 이 디자인의 트레이드오프는 사용자 경험입니다: 이 시장 주문을 실행하려면 두 가지 트랜잭션 프로세스가 필요합니다.사용자는 Keeper 작업에 대한 가스를 보상하고 오라클 체인의 저장소를 업데이트하는 비용을 공유해야 합니다. 2sUSD의 고정 수수료였던 것이 최근 Optimism 가스 오라클 + 프리미엄을 기반으로 하는 동적 수수료로 변경되었으며 이는 레이어 2 네트워크 활동에 따라 변경됩니다. 어쨌든 이는 트레이더 사용자 경험을 희생하면서 LP 수익성을 향상시키는 솔루션으로 볼 수 있습니다.

풀 유형: 낙관적 결제

지연된 주문으로 인해 사용자에게 추가 네트워크 수수료(2계층 네트워크의 DA 수수료에 비례)가 발생하므로 브레인스토밍을 거쳐 우리는 또 다른 주문 정산 모델을 고안했습니다."긍정적인 정착", 이 모델은 분산화와 프로토콜 보안을 유지하면서 사용자 비용을 줄일 수 있는 잠재력을 가지고 있습니다. 이름에서 알 수 있듯이 이 메커니즘을 통해 트레이더는 시스템에서 모든 가격을 적극적으로 수용하고 검색자가 악의적으로 주문이 이루어졌다는 증거를 제출할 수 있는 창을 제공하여 시장 거래를 원자적으로 실행할 수 있습니다. 이 섹션에서는 이 아이디어의 다양한 버전, 사고 과정 및 해결되지 않은 문제를 간략하게 설명합니다.

우리의 초기 아이디어는 사용자가 시장 주문을 열 때parsePriceFeedUpdates를 통해 가격을 제출할 수 있는 메커니즘을 구축한 다음 사용자 또는 제3자가 가격 피드 데이터를 사용하여 정산 거래를 제출하고 다음과 같은 경우 해당 가격으로 거래가 완료되도록 하는 것이었습니다. 거래가 확인되었습니다. 정산 시 두 가격 간의 마이너스 차이는 사용자의 손익계산서에 슬리피지로 포함됩니다. 이 접근 방식의 장점은 사용자의 비용 부담을 줄이고 선행 실행 위험을 줄이는 것입니다. 사용자는 더 이상 방어자에게 보상하는 프리미엄을 부담할 필요가 없으며, 주문이 제출될 때 정산 가격을 알 수 없으므로 선점 위험은 여전히 ​​관리 가능합니다. 그러나 이는 여전히 2단계 결제 프로세스를 도입하는데, 이는 Synthetix의 이연 결제 모델에서 발견한 단점 중 하나입니다. 대부분의 경우 주문과 결제 사이의 변동성이 시스템에서 정의한 수익성 있는 선행거래 임계값을 초과하지 않는 경우 추가 결제 거래가 불필요할 수 있습니다.

위의 문제를 우회하는 또 다른 해결책은 시스템이 주문을 적극적으로 수락한 다음 가격 타임스탬프와 블록 타임스탬프 사이의 가격 편차가 진행되도록 허용된다는 증거를 제출할 수 있는 무허가 도전 기간을 열도록 허용하는 것입니다. 거래를 진행 중입니다.

구체적인 작업은 다음과 같습니다.

1. 사용자는 현재 시장 가격을 기준으로 주문을 생성합니다. 그런 다음 주문 생성 트랜잭션으로 내장된 Python 가격 피드 바이트 데이터와 함께 가격을 전달합니다.

2. 스마트 계약은 이 정보를 적극적으로 확인하고 저장합니다.

3. 온체인에서 주문이 확인된 후 검색자가 역선택 증거를 제출할 수 있는 도전 기간이 있습니다. 이 증거는 거래자가 시스템을 중재하려는 의도로 오래된 가격 피드 데이터를 사용했음을 확인합니다. 증명이 시스템에 의해 승인되면 그 차액은 트레이더의 실행 가격에 슬리피지로 적용되며, 초과된 가치는 키퍼에게 보상으로 주어집니다.

4. 챌린지 기간이 지나면 시스템은 모든 가격을 유효한 것으로 간주합니다.

이 모델은 두 가지 장점이 있습니다: 사용자의 비용 부담을 줄여줍니다.. 사용자는 추가 정산 트랜잭션 없이 동일한 트랜잭션에서 주문 생성 및 오라클 업데이트에 대한 가스비만 지불하면 됩니다. 또한 선행 실행을 방지하고 유동성 풀의 무결성을 보호하며 선행 실행을 증명하는 증거를 시스템에 제출하는 데 대한 재정적 인센티브를 통해 건강한 Keeper 네트워크를 보장합니다.

그러나 이 아이디어를 실행에 옮기기 전에 해결해야 할 몇 가지 문제가 아직 남아 있습니다.

• 정의"역선택": 시스템은 네트워크 지연으로 인해 만료된 가격을 제출하는 사용자와 고의적으로 차익거래를 하는 사용자를 어떻게 구별합니까? 초기 아이디어는 만료 확인 기간(예: 15초) 내의 변동성을 측정하는 것일 수 있으며 변동성이 순 실행 수수료를 초과하는 경우 해당 주문은 잠재적인 악용으로 표시됩니다.

• 적절한 이의 제기 기간 설정: 독성 주문 흐름이 짧은 기간 동안만 열릴 수 있다는 점을 고려할 때 키퍼가 가격에 이의를 제기할 수 있는 적절한 기간은 무엇입니까? 일괄 교정은 비용면에서 더 효율적일 수 있지만 시간이 지남에 따라 주문 흐름을 예측할 수 없기 때문에 모든 가격 정보가 입증되거나 이의를 제기할 충분한 시간이 있는지 확인하기 위해 일괄 교정을 수행하는 것이 어렵습니다.

• 키퍼를 위한 경제적 보상: 재정적으로 인센티브를 받는 키퍼에게 합당한 증거 제출을 위해서는 승리 증거 제출과 관련된 보상이 증거 제출과 관련된 가스 비용보다 커야 합니다. 주문 규모가 다양하기 때문에 이 가정은 보장되지 않을 수 있습니다.

• 주문 마감에도 유사한 메커니즘이 필요합니까? 그렇다면 사용자 경험은 어떻게 저하됩니까?

• 사용자에게 불합리한 미끄러짐이 발생하지 않도록 하십시오. 갑작스런 충돌이 발생하는 경우 주문 생성과 온체인 확인 사이에 매우 큰 가격 차이가 있을 수 있습니다. 일종의 대체 또는 회로 차단기가 필요할 수 있으며 사용하기 전에 가격 피드 안정성을 보장하기 위해 Pyth의 EMA 가격을 사용하는 것을 고려하십시오.

ZK 보조 프로세서 - 또 다른 형태의 데이터 소비

살펴볼 가치가 있는 또 다른 방향은 오프체인에서 복잡한 계산을 수행하기 위해 온체인 상태를 획득하고 동시에 계산이 수행되는 방법에 대한 증거를 제공하도록 설계된 ZK 보조 프로세서를 사용하는 것입니다. 이 방법은 허가 없이 사용할 수 있습니다. 확인하다. Axiom과 같은 프로젝트를 통해 계약은 과거 블록체인 데이터를 쿼리하고, 오프체인 계산을 수행하고, 계산 결과가 유효한 온체인 데이터를 기반으로 올바르게 계산되었음을 증명하는 ZK 증명을 제출할 수 있습니다. 보조 프로세서는 여러 DeFi 기본 유동성 소스(예: Uniswap + Curve)의 과거 가격을 사용하여 조작 탄력성을 갖춘 맞춤형 TWAP 오라클을 구축할 수 있는 가능성을 열어줍니다.

현재 최신 자산 가격 데이터에만 액세스할 수 있는 기존 오라클과 비교하여 ZK 보조 프로세서는 안전한 방식으로 dApp에 제공되는 데이터 범위를 확장합니다(Pyth는 개발자가 최신 자산 가격에 대한 참조 확인으로 사용할 수 있도록 EMA 가격을 제공합니다) 가격) . 이러한 방식으로 애플리케이션은 프로토콜 보안을 향상하거나 사용자 경험을 향상시키기 위해 기록된 블록체인 데이터와 함께 작동하는 더 많은 비즈니스 로직을 도입할 수 있습니다.

그러나 ZK 보조 프로세서는 아직 개발 초기 단계에 있으며 다음과 같은 병목 현상이 여전히 존재합니다.

• 보조 프로세서 환경에서는 대량의 블록체인 데이터를 획득하고 계산하는 데 오랜 시간이 걸릴 수 있습니다.

• 블록체인 데이터만 제공하면 Web3 이외의 애플리케이션과의 보안 통신에 대한 필요성이 해결되지 않습니다.

오라클 없는 솔루션 – DeFi의 미래?

이 문제를 해결하는 또 다른 방법은 기본 요소를 처음부터 설계하여 외부 가격 피드의 필요성을 없애는 것입니다.

오라클에 대한 DeFi의 의존성을 해결합니다. 이 분야의 최신 개발은 가격 책정 수단으로 다양한 AMM LP 토큰을 사용하는 것입니다. 핵심 아이디어는 상수 기능 시장 조성자의 LP 포지션이 두 자산의 사전 설정된 가중치를 나타내는 토큰이며 두 개의 토큰이 있다는 것입니다. 자동 가격 책정 공식(예: xy=k) LP 토큰을 활용하여(담보, 대출 기반 또는 최근 사용 사례의 경우 v3 LP 포지션을 다른 틱 포인트로 이동) 프로토콜은 일반적으로 오라클에서 얻을 수 있는 정보를 얻을 수 있습니다. 그 결과, 위의 과제에서 벗어난 새로운 오라클리스 솔루션의 물결이 실현되었습니다. 이 방향을 기반으로 한 적용 사례는 다음과 같습니다.

Panoptic은 Uniswap v3 중앙 집중식 유동성 포지션을 활용하여 영구적인 오라클 없는 옵션 프로토콜을 구축하고 있습니다. 중앙집중형 유동성 포지션은 현물가격이 LP포지션 상한선을 초과할 경우 100% 기초자산으로 전환되기 때문에 유동성 공급자에게 돌아가는 수익은 풋옵션 판매자가 받는 수익과 매우 유사합니다. 따라서 옵션 시장은 유동성 공급자가 LP 자산이나 포지션을 예치하고, 옵션 구매자와 판매자가 유동성을 빌려 범위 안팎으로 이동함으로써 역동적인 옵션 수익을 창출하는 방식으로 작동합니다. 대출금은 LP 포지션으로 표시되므로 결제를 위해 오라클이 필요하지 않습니다.

Infinity Pools는 Uniswap v3의 중앙 집중식 유동성 포지션을 활용하여 청산이나 오라클이 없는 레버리지 거래 플랫폼을 구축하고 있습니다. Uniswap v3의 유동성 공급자는 LP 토큰을 빌려줄 수 있으며 거래자는 일부 담보를 예치하고 LP 토큰을 빌리고 방향성 거래 관련 자산을 상환할 수 있습니다. 환매 대출은 환매 가격에 따라 자산 기준 또는 시세 자산으로 표시되며 Uniswap에서 LP 구성을 확인하여 직접 계산할 수 있어 오라클에 대한 의존도가 사라집니다.

Timeswap은 고정 기간, 청산 없음, 오라클 없음 대출 플랫폼을 구축하고 있습니다. 이는 대출자, 차용자 및 유동성 공급자로 구성된 3자 시장입니다. 기존 대출시장과 달리"시간 기준"(시간 기반) 청산보다는"가격 기준"(가격 기반) 포지션 마감. 탈중앙화 거래소에서는 유동성 공급자가 항상 판매자에게서 구매하고 구매자에게 판매하도록 자동 설정되는 반면, 타임스왑에서는 유동성 공급자가 항상 차용자에게 빌려주고 시장에서는 대출자로부터 차입하는 유사한 역할을 합니다. 그들은 또한 대출 불이행에 대한 책임을 지며 상실된 담보를 보상으로 받는 데 우선권을 갖습니다.

결론적으로

가격 데이터는 많은 분산형 애플리케이션에서 중요한 부분으로 남아 있으며 오라클이 얻는 총 가치는 시간이 지남에 따라 계속 증가하여 제품 시장 적합성(p 제품 시장 적합성)을 더욱 확증합니다. 이 기사의 목적은 독자들에게 현재 우리가 직면하고 있는 OEV 관련 과제에 대한 개요를 제공하고 푸시, 풀 및 AMM 유동성 공급자 또는 오프체인 보조 장치를 사용하는 기타 설계를 기반으로 구현되는 설계 공간을 제공하는 것입니다. 프로세서.

우리는 이러한 어려운 설계 문제를 해결하려는 열정적인 개발자들을 보게 되어 매우 기쁩니다. 만약 당신이 이 공간에서 파괴적인 프로젝트를 진행하고 있다면, 우리는 당신의 의견을 듣고 싶습니다!

참고자료 및 감사의 말

이 기사에 큰 도움을 준 Jonathan Yuen과 Wintersoldier에게 감사드립니다.

귀중한 의견, 피드백 및 리뷰를 제공해 주신 Erik Lie, Richard Yuen(Hailstone), Marc, Mario Bernardi, Anirudh Suresh(Pyth), Ugur Mersin(API 3 DAO) 및 Mimi(Timeswap)에게 감사드립니다.

• 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/

︎

부록

정의: 푸시(Push) 오라클과 풀(Pull) 오라클

푸시 오라클 머신은 P2P 네트워크에서 오프체인 가격을 유지하고 사전 정의된 온체인 노드를 기반으로 가격 업데이트를 유지합니다. Chainlink를 예로 들면, 가격 업데이트는 편차 임계값(편차 임계값)과 하트비트(하트비트)라는 두 가지 트리거 매개변수를 기반으로 합니다. 아래의 이더리움 ETH/USD 가격 피드는 오프체인 가격이 최신 온체인 가격에서 0.5% 벗어나거나 1시간 하트비트 타이머가 0에 도달할 때마다 업데이트됩니다.

이 경우 오라클 운영자는 각 가격 업데이트에 대해 거래 수수료를 지불해야 하며 이는 비용과 확장성 간의 균형입니다. 가격 소스 수를 늘리거나, 추가 블록체인을 지원하거나, 업데이트를 더 자주 추가하면 추가 거래 비용이 발생합니다. 따라서 트리거 매개변수가 높은 롱테일 자산은 필연적으로 신뢰성이 낮은 가격 소스를 갖게 됩니다. 이를 설명하기 위해 CRV/USD를 예로 들어 보겠습니다. 체인에서 새 가격을 업데이트하려면 24시간 하트비트와 함께 1% 편차 임계값이 필요합니다. 즉, 가격이 24시간 이내에 1% 이상 상승한 경우 24시간마다 한 번만 새로운 가격 업데이트가 이루어집니다. 직관적으로 볼 때, 롱테일 자산의 가격 소스에 대한 세분성이 부족하면 애플리케이션이 이러한 자산에 대한 시장을 만들 때 추가적인 위험 요소를 고려해야 하는 결과가 필연적으로 발생하며, 이는 대부분의 DeFi 활동이 여전히 가장 유동적인 자산을 중심으로 이루어지는 이유를 설명합니다. 가장 강력하고 가장 큰 시가총액 토큰으로.

이와 대조적으로 풀 오라클을 사용하면 요청 시 가격을 체인에 끌어올 수 있습니다. Pyth는 오늘날 가장 눈에 띄는 사례로 가격 업데이트를 오프체인으로 전송하고, 각 업데이트에 서명하여 누구나 진위 여부를 확인할 수 있도록 하며, 솔라나 코드 체인을 기반으로 한 프라이빗 블록인 Pythnet에서 집계된 가격을 유지합니다. 업데이트가 필요할 때 데이터는 Wormhole을 통해 전송되고 Python에서 검증된 다음 허가 없이 체인으로 끌어옵니다.

위 그림은 Pyth 가격 피드의 구조를 설명합니다. 체인의 가격을 업데이트해야 할 경우 사용자는 Pyth API를 통해 업데이트를 요청할 수 있습니다. Pythnet에서 확인된 가격은 Wormhole 계약으로 전송됩니다. Wormhole 계약은 Pyth 계약이 배포된 모든 블록체인에서 확인할 수 있는 장소 이름 VAA를 관찰, 생성 및 전송합니다.

면책조항: 이 기사는 투자 조언이 아니며, 사용자는 이 기사에 포함된 의견, 견해 또는 결론이 자신의 특정 상황과 일치하는지 고려해야 하며, 자신이 위치한 국가 및 지역의 관련 법률 및 규정을 준수해야 합니다.