작성자: Shew, 선량 GodRealmX
최근 시장의 큰 관심을 받고 있는 Hyperliquid는 가장 영향력 있는 온체인 주문장 거래소 중 하나로, TVL이 이미 20억 달러를 넘어섰습니다. Messari에서 "온체인 Binance"로 평가받은 동시에 이미 대중의 관심에서 멀어졌던 Layer3, 애플리케이션 체인 내러티브를 다시 주목받게 만들었습니다. 토큰 상장 1개월 만에 FDV가 300억 달러까지 상승하는 눈부신 성과를 거두면서 Hyperliquid는 일반 사용자부터 업계 종사자까지 폭넓은 관심을 받고 있습니다. 동시에 시장에는 Hyperliquid에 대한 다양한 리서치 보고서가 쏟아져 나왔지만, 이들은 주로 주문장 기능과 거래 메커니즘의 특징에 초점을 맞추고 있어 기술 구조와 보안 취약점에 대해서는 깊이 있게 다루지 않았습니다.
본 글의 저자는 이러한 공백을 메우고자 합니다. 순수하게 기술 구조와 보안 관점에서 Hyperliquid를 살펴보고, 이 스타 프로젝트의 구조와 원리를 더 많은 사람들이 이해할 수 있도록 돕고자 합니다. 우리는 Hyperliquid 크로스체인 브리지 계약의 구조와 취약점, HyperEVM과 HyperL1 이중 체인 구조 두 가지 측면에서 설명을 진행할 것입니다.
(현재 Hyperliquid는 Arbitrum의 USDC 총 공급량의 67%를 점유하고 있습니다.)
HyperLiquid 크로스체인 브리지 분석
HyperLiquid는 핵심 구성 요소를 공개하지 않았지만, 관련 브리지 계약은 공개했기 때문에 우리는 브리지 계약 측면의 위험에 대해 더 잘 알 수 있습니다. Hyperliquid는 Arbitrum에 브리지 계약을 배포하여 사용자가 예치한 USDC 자산을 보관하고 있으며, 브리지 구성 요소에서 Hyperliquid 노드의 일부 행동을 확인할 수 있습니다.
검증자 집합
노드 ID 구분 관점에서 Hyperliquid에는 4개의 검증자 그룹이 있습니다. 각각 hotValidatorSet, coldValidatorSet, finalizers, lockers로, 서로 다른 기능을 수행합니다. hotValidatorSet은 사용자 출금 작업 등 고빈도 작업에 사용되며, 일반적으로 핫 지갑을 사용하여 Hyperliquid 사용자의 출금 요청에 즉시 대응할 수 있습니다.
coldValidatorSet은 주로 시스템 구성 변경, 예를 들어 hotValidatorSet 또는 lockers 등 검증자 집합의 명단 변경, 또는 브리지 계약의 잠금 상태 처리 등의 작업을 수행합니다. 또한 coldValidatorSet은 특정 출금 요청을 무효화할 수 있는 권한이 있습니다.
lockers는 특별한 권한을 가진 검증자 그룹으로, Layer2에서 일반적으로 사용되는 "안전 위원회"와 유사한 역할을 합니다. 비상 상황 발생 시 투표를 통해 크로스체인 브리지의 일시적 중단을 결정할 수 있습니다. 현재 Hyperliquid 브리지의 lockers 집합에는 5개의 주소가 포함되어 있으며, 2명의 locker만으로도 브리지 계약의 실행을 일시 중단시킬 수 있습니다.
finalizers는 특수한 검증자 그룹으로, 크로스체인 브리지의 상태 변화를 최종 확인하는 역할을 합니다. 주로 사용자의 예치와 출금 확인이 이에 해당합니다. Hyperliquid의 크로스체인 브리지는 "제출-확인" 메커니즘을 사용합니다. 사용자가 출금을 요청하면 즉시 실행되지 않고, 일정 시간(분쟁 기간)을 기다려야 합니다. 분쟁 기간이 끝나면 finalizers 구성원이 출금 거래를 실행하여 출금이 정상적으로 처리됩니다.
만약 크로스체인 브리지에 문제가 발생하여, 예를 들어 어떤 출금 요청의 자금이 실제 사용자 잔액을 초과하는 경우, Hyperliquid 노드는 분쟁 기간 내에 lockers의 투표를 통해 크로스체인 브리지 계약의 실행을 일시 중단시킬 수 있습니다. 또는 coldValidatorSet이 직접 문제가 있는 출금 요청을 무효화할 수 있습니다.
현재 Hyperliquid에는 4개의 검증자 노드만 있기 때문에, hotValidatorSet과 coldValidatorSet은 각각 4개의 온체인 주소에 해당합니다. Hyperliquid는 초기화 시 hotValidatorSet 주소를 자동으로 lockers와 finalizers의 구성원으로 등록했으며, coldValidatorSet은 Hyperliquid 공식이 콜드 지갑으로 관리하고 있습니다.
예치
Hyperliquid의 브리지 계약은 EIP-2612의 Permit 방식을 사용하여 사용자의 예치 작업을 처리하며, 계약 내에서는 USDC 자산만 허용됩니다. Permit은 기존의 Approve-Transfer 방식보다 간단하며, 일괄 처리도 지원합니다.
Hyperliquid의 브리지 계약은 batchedDepositWithPermit 함수를 사용하여 다중 예치 작업을 일괄 처리합니다. 이 예치 작업은 비교적 단순하며 자금 안전성 위험이 없고, Permit 방식을 사용하여 UX를 최적화했습니다.
출금
예치와 달리 출금은 매우 위험한 작업이므로 로직이 훨씬 복잡합니다. 사용자가 출금 요청을 하면 Hyperliquid 노드가 브리지 계약의 batchedRequestWithdrawals 함수를 호출합니다. 이때 브리지 계약은 각 출금 요청에 대해 hotValidatorSet의 2/3 서명 가중치를 요구합니다. 많은 문서에서는 이를 "2/3의 서명을 모으는 것"으로 설명하지만, 실제로는 "2/3의 서명 가중치"를 확인하는 것입니다. 현재 HyperLiquid에는 4개의 동일한 가중치를 가진 노드만 있기 때문에, 서명 가중치 확인과 서명 수 확인이 일치하지만, 향후 HyperLiquid가 고가중치 노드를 도입하면 이 두 가지가 달라질 수 있습니다.
출금 요청이 이루어진 후에는 크로스체인 브리지가 계약이 통제하고 있는 USDC를 즉시 이체하지 않고, "분쟁 기간"을 가집니다. 이는 사기 증명 프로토콜의 "이의 제기 기간"과 유사합니다. 현재 Hyperliquid 브리지 계약의 분쟁 기간은 200초입니다. 이 기간 동안 두 가지 상황이 발생할 수 있습니다:
1. lockers가 현재 출금 요청에 심각한 문제가 있다고 판단하면 직접 투표하여 계약을 일시 중단/동결할 수 있습니다.
2. 일부 출금 행위에 문제가 있다고 판단되면 coldValidatorSet 구성원이 invalidateWithdrawals 함수를 호출하여 해당 출금을 무효화할 수 있습니다.
분쟁 기간 내에 문제가 발생하지 않으면, 분쟁 기간이 끝난 후 finalizers 구성원이 브리지 계약의 batchedFinalizeWithdrawals 함수를 호출하여 최종 상태를 확정합니다. 이 함수가 실행되면 USDC가 사용자의 Arbitrum 지갑으로 전송됩니다.
따라서 보안 모델 관점에서 볼 때, 악의적인 공격자가 Hyperliquid의 출금 프로세스에 개입하려면 세 가지 방어선을 뚫어야 합니다:
1. hotValidatorSet의 2/3 서명 가중치를 확보해야 합니다. 즉, 일정 수의 개인 키를 확보하거나 공모해야 합니다. 현재 HyperLiquid에는 4개의 검증자만 있어 공격자가 이를 달성할 가능성이 높습니다.
2. 분쟁 기간 내에 자신의 악의적인 거래가 발견되지 않도록 해야 합니다. 발견되면 lockers가 개입하여 계약을 잠글 수 있습니다. 이 부분은 아래에서 자세히 다룰 것입니다.
3. 최소 1명의 finalizers 구성원의 개인 키를 확보해야 합니다. 현재 finalizers 구성원과 hotValidatorSet 구성원이 거의 일치하므로, 위의 조건 1을 충족하면 이 조건도 자동으로 충족됩니다.
브리지 계약의 잠금
앞서 여러 차례 언급했듯이, Hyperliquid는 크로스체인 브리지 계약을 잠그는 기능을 설정했습니다. 구체적으로 lockers 구성원이 브리지 계약의 voteEmergencyLock 함수를 호출하여 투표하면, 현재 2명의 lockers가 투표하면 크로스체인 브리지 계약이 잠기고 일시 중단됩니다.
만약 Tendermint를 사용한다면, Hyperliquid는 초당 최대 20,000건의 주문을 처리할 수 있습니다. 중앙화 거래소의 속도를 달성하기 위해 HyperLiquid 팀은 HotStuff를 기반으로 HyperBFT 알고리즘을 개발했으며, Rust로 구현하여 이론적으로 초당 최대 200만 건의 주문을 처리할 수 있습니다.
아래 그림은 병렬 처리가 되지 않는 상황에서의 HyperBFT 합의 메시지 전달 방식을 보여줍니다. 모든 메시지가 리더에 의해 취합되어 일괄 브로드캐스트되므로, 노드 간 메시지 교환 단계가 생략되어 복잡도가 크게 낮아집니다.
간단히 말해, HyperBFT는 현재의 리더가 블록을 생성하고, 모든 노드가 투표에 참여하며, 투표 결과를 리더에게 일괄 전송하는 합의 프로토콜입니다. 실제로 Hotstuff와 Tendermint에는 더 복잡한 세부 사항이 포함되지만, 본 문서의 범위와 초점에 맞추어 자세히 다루지 않습니다.
개발자가 주목해야 할 사항
위에서 설명한 Precompiles 기반 데이터 읽기 메커니즘은 매우 완벽합니다. Solidity 개발자는 Hyper L1 상태를 읽을 때 별도의 코드를 작성할 필요가 없지만, msg.sender에 대해 주의해야 합니다. 대부분의 이더리움 2계층과 마찬가지로, HyperLiquid는 사용자가 Hyper L1 내부의 시스템 계약과 직접 상호 작용하여 HyperEVM 체인에서 트랜잭션 작업을 간접적으로 트리거할 수 있습니다. 이 경우 스마트 계약이 해당 트랜잭션에서 msg.sender 필드를 읽으면 사용자 주소가 아닌 HyperL1 시스템 계약 주소가 반환됩니다.
EVM과 L1의 상호 작용과 관련하여 개발자는 여러 가지 문제에 주의해야 합니다. 첫 번째 문제는 상호 작용의 비원자성 문제입니다. 사용자가 HyperEVM에서 앞서 언급한 이벤트 주소를 통해 간접적으로 L1에 주문을 걸었지만 L1에 충분한 자산이 없는 경우, 해당 트랜잭션은 실패할 것이지만 사용자가 이벤트 주소 함수를 호출할 때는 오류 반환이 없습니다. 상호 작용의 비원자성 문제로 인해 사용자 자산이 손실될 수 있습니다. 이 경우 개발자는 EVM 스마트 계약 측에서 주문 실패 상황을 수동으로 처리해야 합니다. 또한 EVM 내 스마트 계약에는 최종적으로 자금을 회수할 수 있는 기능이 있어야 합니다.
다음으로, EVM에 해당하는 계약 주소는 L1 내에 매핑 계정이 존재해야 합니다. 사용자가 EVM에 스마트 계약을 배포한 후에는 매핑 주소로 소량의 USDC를 전송하여 L1에 계정을 생성해야 합니다. 이 부분 작업은 HyperLiquid의 기본 합의와 관련될 수 있으며, HyperLiquid 문서에 명시되어 있습니다.
마지막으로, 개발자는 특수한 상황, 특히 토큰 잔액 상황에 주의해야 합니다. Hyper L1에는 자산 전송을 위한 특수 주소가 있지만, 사용자가 해당 주소로 자산을 보내면 자산이 L1에서 HyperEVM 체인으로 이동합니다. HyperLiquid 노드가 EVM 체인과 L1 체인을 동시에 실행하기 때문에, 사용자가 자산을 전송한 후에도 HyperEVM에서 블록이 오랫동안 생성되지 않을 수 있습니다. 이 경우 사용자는 EVM 체인에서 자신의 잔액을 확인할 수 없습니다.
요약하면, 이 경우 사용자의 자산이 크로스체인 브리지에 갇혀 있어 L1이나 EVM 체인에서도 확인할 수 없습니다. 개발자는 이러한 특수 상황을 처리하여 사용자의 불안감을 해소해야 합니다.
종합적으로 볼 때, HyperEVM은 Hyperliquid L1을 기반으로 하는 2계층과 유사합니다. HyperEVM은 Precompiles 코드를 통해 L1 상태를 읽으며, Events를 통해 Hyper L1과 상호 작용합니다. L1에는 사용자가 HyperEVM에서 트랜잭션을 트리거하거나 자산을 크로스체인하는 데 도움이 되는 시스템 계약이 있습니다. 일반적인 Layer1-Layer2 아키텍처와 달리, Hyperliquid는 HyperEVM에 더 높은 상호 운용성을 제공합니다.
참고 자료
Hyperliquid: The Hyperoptimized Order Book L1
hyperliquid-dex/contracts
The Not-So-Definitive guide to Hyperliquid Precompiles.
What is the difference between PBFT, Tendermint, HotStuff, and HotStuff-2?
