[Theori]Patch Thursday — 온체인 옵션 거래소의 구조와 잠재적 위협: 3편

1. 온체인 옵션 거래소의 보안 고려사항

<중앙화 위험>

• 주문 장부 기반 거래소: 주문 장부 인터페이스 구현을 위해 오프체인(off-chain) 솔루션을 이용하는 과정에서 중앙화 위험 발생 가능
  -> 해결 방법: 외부 솔류션에 의존하지 않는 자체적인 주문 장부 인터페이스를 만들어 해결
• 구조화 상품 방식: 사용자가 옵션에 대한 매개변수를 직접 설정할 수 없고, 소수의 주체에 대해 이러한 권한이 집중되어 있어 중앙화 문제가 발생 가능
  -> 해결 방법: 라운드 종료와 시작 사이에 거버넌스 투표를 통해 결정하는 방법으로 유저에게 옵션 매개변수 관련 결정 권한을 부여하는 등의 방법으로 해결

*구조화 상품: 여러 기초 자산을 기반으로 하는 금융 상품 혹은 파생 상품ㅇ르 결합한 상품, 개인 선호도에 따라 투자 설계를 할 수 있는 상품

 

<온체인 구현 문제>
온체인 옵션 거래소 구현 과정에서 복잡한 보안 고려사항 발생, 잠재적인 위험 발생 가능

 

• 온체인 옵션 거래 환경이 상대적으로 덜 활성화되어 있기 때문에 그와 관련한 보안 사항들이 잘 알려져있지 않음
• 확장성을 개선하거나 MEV(Maximum Extractable Value) 문제를 해결하기 위해 자체적인 체인 개발 시에도 발견되지 않은 보안 문제 발생 가능

<시장 변동성과 유동성 관리>

자동화된 시장 조성자 방식: 유동성 유입이 쉬움 -> 높은 변동성

 

급격한 변동성으로 인한 위험 해소:

• 라이라 파이낸스는 블랙-숄즈(Black-Scholes) 알고리즘 연산에 들어가는 입력값 중 기초자산의 변동성에 대해 가중치를 부여하는 가격 연산 방식으로 문제를 해결함
• 이외 온체인 옵션 거래소: 유동성 풀 비율을 지속적으로 검증, 시간 가중 가격 모델을 쓰는 방법 등을 이용하여 문제를 해결함
• 위험 탐지와 대응을 통해 자동화된 써킷 브레이커(Circuit Breaker)를 운영하는 것 또한 해결책이 될 수 있음

 

 

---

2. 실제 취약점 및 해결 방안

<오핀>

취약점: 감마 프로토콜(Gamma Protocol)에서 시동변동성으로 의도하지 않은 프로토콜 자산 손실

 

오핀은 일부 콜 옵션에 한해서 기초자산과 유사한 다른 자산을 담보로 허용, 예를 들어 시장의 움직임에 의한 만기 시점까지 기초자산의 가격 상승분이 담보의 가격 상승분보다 클 경우, 옵션의 증거금(margin) 풀이 손실을 입는다.

 

공격자는 옵션 만기 시점에 시장의 흐름에 따라 자신에게 이익이 되는 수익 정산 방법을 선택

• 기초자산 가격의 상승분 > 담보 가격 상승분: 옵션을 소유하고 있는 공격자는 담보로 예치한 자산보다 더 많은 양의 자산을 청구할 수 있음 -> 공격자가 정산받는 총 금액 = (예치한 담보)X(기초자산 가격 상승분)/(담보 가격 상승분)
• 기초자산 가격의 상승분 <= 담보 가격 상승분: 옵션이 내가격으로 마감될 경우, 옵션 행사와 함께 볼트에 남아있는 담보를 청산하면 초기에 예치한 담보를 그대로 반환받을 수 있음

결과: 공격자는 어떠한 경우에서도 손해를 입지 않는 선택을 할 수 있음

 

 

<리본 파이낸스>

취약점: Treasury의 사용자에게 프리미엄을 분배하는 지점에서 정산을 실제보다 더 적게 받거나 아예 받지 못함

 

리본 파이낸스의 Treasury와 Theta의 사용자는 각 볼트에 기초자산을 예치하고, 예치한 기촞사ㅏㄴ에 대한 지분을 증명할 수 있는 내부 토큰을 발급받을 수 있다.

• Theta: 기초자산과 프리미엄 지불에 동일한 자산을 사용하고 옵션 매수에 따라 발생하는 프리미엄을 그대로 볼트에 예치해 내부 토큰의 가치를 높이는 방식으로 분배
• Treasury: 기초자산이 특정 프로토콜의 거버넌스 토큰이기 때문에 USDC로 프리미엄을 지불할 수 있도록 하는 로직 존재

 

Treausry 프리미엄 분배 방식)

볼트 내 이용 가능한 내부 토큰의 총 개수 계산

totalSupply = totalSupply() - lastQueuedWithdrawAmount

• totalSupply(): 내부 토큰의 총 공급량
• totalBalance: 기초자산의 양
• pricePerShare: totalSupply() / totalBalance = 단위기초자산 당 내부 토큰의 수량, 초기에 1을 유지
• lastQueuedWithdrawAmount: pricePerShare 변수를 사용해 구할 수 있음

-> 위 공식에서 totalSupply()의 단위가 내부 토큰인 반면, lastQueuedWithdrawAmount 단위가 Treasury 기초자산인 거버넌스 토큰으로 서로 다른 단위를 가짐

 

공격 발생 가능 지점)

• 시장 상황에 따라 청산이 발생하거나, 누군가 직접적으로 Treasury에 토큰을 전송 -> pricePerShare의 비율이 깨져 문제 발생 가능
• pricePerShare < 1: lastQueuedWithdrawAmount의 값이 상대적으로 작게 계산되어 이용 가능한 내부 토큰의 총 개수가 더 크게 계산됨 -> 사용자들에게 더 적은 양의 프리미엄 지분이 분배
• pricePerShare > 1: 이용 가능한 내부 토큰의 총 개수가 더 작게 계산되어 사용자들에게 더 많은 양의 분배를 시도, 실제 수령한 프리미엄보다 많은 분배를 시도해 해당 트랜잭션이 실행 중단 -> 프리미엄 분배가 전혀 되지 않음

 

해결 방안: totalSupply()와 lastQueueWithdrawAmount가 서로 같은 단위를 사용

 

<도펙스>

취약점: 0dte에서 정산가 연산 과정에 대한 검사 부족

 

도펙스는 자체적으로 0dte을 운영, 이는 스프레드 전략을 사용해 옵션 판매자의 손실 위험을 낮추고 구매자의 프리미엄 부담을 감소시킴. 옵션 구매 시 정산가는 초기값이 0, 0dte 옵션 컨트랙트 내에는 옵션의 정산을 위해 2개의 함수 구현. 하나는 옵션의 정산가를 만기 시점의 시장 평균가로 최신화하는 함수, 다른 하나는 설정된 옵션의 정산가에 맞춰 사용자에게 옵션을 정산해주는 함수.

*스프레드 전략: 행사 가격과 만기가 다른 여러 매수/매도 포지션을 병행하여 운영해 손실 위험을 헤징하는 전략, 수익의 안전성을 높이기 위해 강세 스프레드 및 약세 스프레드 등의 다양한 스프레드 전략을 설계 가능

 

-> 옵션의 만기 도래 여부만 확인, 정산가의 최신화 여부를 확인하지 않음.

 

0dte는 옵션 구매 시 정산을 요청할 수 있는 증표로 NFT 발급

• expiryInfo: 사용자가 구매한 옵션의 만기일/정산가/NFT 토큰 ID 등의 정보를 저장하는 변수
• settlementPrice: expiryInfo 내의 옵션 정산가를 뜻함. 초기값이 0
• keeperSaveSettlementPrice(): 옵션의 정산가를 해당 시점의 시장 평균가로 최신화하는 함수
• expireSpreadOptionPosition(): 설정된 옵션의 정산가에 맞게 옵션을 정산받을 수 있음

공격 발생 가능 지점)

• expireSpreadOptionPosition(): 옵션의 만기 도래 여부만 확인, keeperSaveSettlementPrice() 함수로 옵션의 정산가가 최신화되었는지 여부를 확인하지 않음
  -> 공격자는 해당 지점을 이용해 keeperSaveSettlementPrice() 함수가 실행되기 전에 expireSpreadOptionPosition() 함수를 호출하여 공격을 수행할 수 있음
  -> 정산가가 0으로 설정된 상태에서 옵션을 정산받을 수 있기 때문에 옵션 구매로 얻을 수 있는 최대 이익을 발생시킬 수 있음

 

해결: 정산가가 업데이트되었는지 여부를 우선적으로 확인. 해결책 중 하나로는 expireSpreadOptionPosition() 함수 실행 시 settlementPrice가 0이 아니어야 한다는 조건을 붙이는 것이 있음.

 

 

<라이라 파이낸스>

취약점: Option Market에서 동작의 잘못된 구현 및 보안 검사가 구현되지 않아 발생하는, 옵션에 대한 값을 지불하지 않고 구매를 가능하게 함

• TradeInputParameters: 라이라 파이낸스가 옵션 포지션 개설부터 종료까지 해당 구조체 내의 필드를 변경하여 옵션을 관리함
• iterations, amount: TradeInputParameters 내 필드, 해당 필드를 이용한 동작이 잘못 구현

문제점)

• amount와 iterations의 값이 유사한 경우: 옵션 포지션 정산과 옵션 가격 연산 과정에 영향을 미침. 두 필드가 완전히 같을 경우, 옵션의 구매가가 0이 됨.
• iterations에 매우 큰 값이 들어가는 경우: 프로토콜 가격 결정 과정에서 반복 상태가 지속됨. iterations에 큰 값을 부여한 상태로 반복적으로 함수를 호출할 시 해당 횟수만큼 가격의 최신화 -> 실제 가격 최신화 및 정산 시스템에 영향, 프로토콜의 가용성 훼손
• 포지션에 대한 ID를 뜻하는 positionId의 값이 0인 경우: 사용자에게 옵션 포지션에 대한 증명 토큰을 발행하는데, 사용자가 포지션을 실제로 개설했는지 여부를 검사X -> 증거금 없이 옵션 포지션을 개설할 수 있음
• 블랙-숄즈 모델을 이용한 옵션 가격 결정 연산 중 의도하지 않은 내림이 발생 -> 옵션 프리미엄이 0이 되는 문제 발생

해결: TradeInputParameters 구조체 내 amount, iterations, positionID 필드에 대한 검증 필요, 옵션의 최종 가격과 프리미엄에 대한 검증 필요, 블랙-숄즈 모델을 이용한 연산 과정에서 의도하지 않은 내림이 발생하지 않도록 만들 필요

---

3. 외부 요인에 의해 유발할 수 있는 위험

• 키퍼 봇의 정상 동작 여부
• 옵션 포지션의 정상적 운영
• 유동성 급감으로 인한 거래 상대방 관련 위험
• 포지션 수립, 청산 과정에서의 의도하지 않은 지연
• 대량 청산에 대한 대비 상태

 

---

본 게시글은 아래의 링크 속 콘텐츠를 기반으로 작성.

https://theori.io/ko/blog/patch-thursday-%EC%98%A8%EC%B2%B4%EC%9D%B8-%EC%98%B5%EC%85%98-%EA%B1%B0%EB%9E%98%EC%86%8C%EC%9D%98-%EA%B5%AC%EC%A1%B0%EC%99%80-%EC%9E%A0%EC%9E%AC%EC%A0%81-%EC%9C%84%ED%98%91-3%ED%8E%B8

Patch Thursday — 온체인 옵션 거래소의 구조와 잠재적 위협 — 3편 - Theori 블로그