ERC-7893 디파이 지급여력 증명 표준 (DeFi Protocol Solvency Proof Mechanism)

Final · 금고·DeFi · 2025-01-30 작성

디파이 프로토콜이 자산과 부채를 온체인에 기록하고 빚을 갚을 능력이 얼마나 되는지(지급여력)를 누구나 같은 방식으로 조회하고 검증할 수 있게 하는 표준 인터페이스입니다.

왜 필요한가

지금은 디파이 프로토콜마다 자신의 재무 상태를 알리는 방식이 제각각입니다. 어떤 기준으로 자산과 부채를 계산했는지가 서로 달라 프로토콜끼리 비교하기 어렵고 실시간으로 상태를 확인할 길이 없어 가끔 나오는 수동 보고에 기대야 합니다. 상태가 나빠질 때 미리 알려 주는 표준화된 조기 경보도 없어서 문제가 커진 뒤에야 알게 되는 경우가 생깁니다. 감사를 하려면 과거 시점의 포지션을 일일이 다시 맞춰 봐야 해서 시간이 오래 걸리고 여러 프로토콜에 걸친 위험을 한데 모아 평가하는 일은 사실상 불가능합니다. 이 표준은 자산·부채 자료 구조와 계산식, 조회 함수, 경보 이벤트를 하나의 공통 인터페이스로 정해 이런 문제를 해결하려 합니다.

구현해야 하는 것

심층 설명

자산·부채 자료 구조와 값 표기

ProtocolAssets와 ProtocolLiabilities 구조체는 tokens(토큰 주소), amounts(토큰 자체 소수점 기준 수량), values(ETH 18자리 소수점 기준 가치), timestamp(마지막 갱신 시각)로 이루어집니다. 세 배열은 반드시 길이가 같아야 하며 모든 가치는 일관성을 위해 ETH 18자리 소수점으로 표기해야 합니다. 수량과 가치를 함께 추적하는 이유는 급변하는 시장에서도 상태를 견고하게 유지하고 과거의 가치 대비 수량 비율을 비교해 오라클 조작을 탐지하며 사후 분석에 쓸 감사 흔적을 남기기 위해서입니다.

오라클 권한과 갱신 규칙

updateAssets와 updateLiabilities는 승인된 오라클 주소만 호출할 수 있고 msg.sender가 승인된 오라클이 아니면 반드시 revert해야 합니다. 갱신할 때는 tokens, amounts, values 배열의 길이가 같은지 검증하고 timestamp 필드를 현재 블록 시각(block.timestamp)으로 갱신하며 성공하면 SolvencyMetricsUpdated 이벤트를 반드시 발행해야 합니다. 오라클 관리 함수(setOracle 등)는 선택 사항이며 제공한다면 권한 변경 시 이벤트를 발행하는 것이 권장됩니다. 오라클 구현 방식 자체는 표준이 정하지 않아 Chainlink, API3, 자체 오라클 등 어떤 것이든 쓸 수 있습니다.

지급여력 비율 계산

getSolvencyRatio는 비율을 (totalAssets × 10000) / totalLiabilities로 계산해 돌려줍니다. 즉 자산과 부채가 같으면 10000, 자산이 부채의 105%면 10500입니다. 부채가 0이면 최대 지급여력을 뜻하는 값을 돌려주거나 적절한 오류로 revert하는 것이 권장됩니다. verifySolvency는 비율이 최소 기준(원문 기준 105%, 즉 10500) 이상인지 나타내는 불리언과 현재 헬스 팩터를 함께 돌려줘 온체인과 오프체인 시스템 모두가 빠르게 상태를 판단할 수 있습니다.

위험 등급과 경보 체계

원문은 네 단계 위험 등급을 제시합니다. 비율이 105% 미만이면 CRITICAL(긴급 중지), 105%에서 110% 사이면 HIGH RISK(위험 경보), 110%에서 120% 사이면 WARNING(관찰), 120% 이상이면 HEALTHY(정상)입니다. 재무 지표가 갱신될 때는 SolvencyMetricsUpdated 이벤트를 반드시 발행해야 하고 위험 기준선을 넘으면 RiskAlert 이벤트를 발행하는 것이 권장됩니다. RiskAlert에는 위험 등급 문자열, 경보를 일으킨 현재 값, 넘어선 기준값, 시각이 담깁니다. 이 등급은 극단적 시장 하락(ETH 80% 하락 등)을 포함한 시뮬레이션 테스트로 검증했다고 원문은 설명합니다.

과거 기록 조회와 보존 정책

getSolvencyHistory(startTime, endTime)는 지정한 기간(경계 포함)에 기록된 모든 스냅숏의 시각, 비율, 자산·부채 상태를 돌려줘야 합니다. 구현체는 과거 지표를 보관해야 하지만 합리적인 보존 기간(예: 1년)이 지난 데이터는 삭제할 수 있습니다. 다만 그 경우 보존 정책과 조회 가능한 기간을 구현 문서에 명확히 적어야 합니다. 큰 기간을 조회하면 가스를 많이 쓸 수 있다는 점도 인터페이스 주석에 명시돼 있습니다. 참조 구현은 조회당 최대 100건 페이지네이션, 최대 8760건(약 1년) 저장, 최소 1시간 기록 간격 같은 패턴을 보여 줍니다.

ERC-165 인터페이스 감지

준수 구현체는 ERC-165의 supportsInterface 함수를 반드시 구현해야 하고 ISolvencyProof 인터페이스 ID에 대해 true를 돌려줘야 합니다. 이를 통해 다른 컨트랙트가 어떤 주소가 이 표준을 지원하는지 호출 전에 확인할 수 있습니다. 이 표준은 ERC-20과 ERC-165를 전제로 하며 기존 디파이 프로토콜과 호환되고 기존 토큰 표준을 바꿀 필요가 없습니다.

참조 구현이 보여 주는 보안 장치

원문의 참조 구현은 운영 환경을 위한 추가 장치를 제시합니다. 역할 기반 접근 제어(ORACLE_ROLE, EMERGENCY_ROLE, ADMIN_ROLE), 오라클당 5블록 간격의 속도 제한, 자산 총액이 한 번에 20% 넘게 변하면 1시간 자동 일시정지하는 서킷 브레이커, 3개 이상 오라클의 중앙값과 5% 넘게 벗어난 가격을 거부하는 다중 오라클 합의 검증, 업데이트당 최대 50개 토큰 제한, 가디언이 발동하는 비상 일시정지 등이 그 예입니다. 이는 표준의 필수 요건이 아니라 권장 구현 패턴입니다.

쓸 때 주의할 점

ERC 원문 · ← ERCs