Hyperliquid는 웹3 관련 언론에서 크게 다뤄지고 거래량도 상당한 유명한 무기한 선물 거래소입니다. 스스로를 탈중앙화 거래소라고 칭하지만, 흔히 그렇듯이 "탈중앙화"라는 합리적인 정의에 부합하지 않습니다. 이 시스템은 공식적으로 소스 코드가 공개되지 않은 비공개 시스템인데, 이는 투명하고 누구나 사용할 수 있다고 주장하는 시스템과는 상반되는 점입니다. 하지만 소스 코드를 공개하지 않더라도 운영팀이 사용자 자금을 완전히 독립적으로 관리하고 있다는 사실은 쉽게 알 수 있습니다.
그들의 무기한 선물 거래 플랫폼을 호스팅하는 "하이퍼리퀴드 L1"에 대해 자세히 조사할 필요는 없습니다. 소스 코드가 이미 공개된 몇 가지 스마트 계약만 살펴봐도 팀이 플랫폼을 완전히 장악하고 있다는 것을 증명하는 데 필요한 모든 정보를 파악할 수 있습니다. 늘 그렇듯이, 이 모든 것은 팀, 그리고 오직 팀만이 어떻게 공격을 실행하여 사용자 자금의 상당 부분을 탈취할 수 있는지에 대한 문제로 귀결됩니다.
자, 이제 본격적으로 살펴보겠습니다. 먼저 플랫폼의 작동 방식, 특히 브리지 기능에 대해 간략히 설명드리겠습니다. 그런 다음 아키텍처 논의와 중앙 집중화 논의를 연결하는 데 도움이 될 만한 몇 가지 데이터를 제공하고, 마지막으로 법적 상황에 대한 몇 가지 의견을 제시하겠습니다.
Hyperliquid는 어떻게 작동하나요?
Hyperliquid의 핵심 코드는 비공개 소스이지만, Arbitrum에서 해당 브리지 계약에 접근할 수 있어 Hyperliquid의 작동 방식에 대한 많은 정보를 얻을 수 있습니다. 특히 다음과 같은 사실을 증명할 수 있습니다.
- 이 다리는 ZK 설계에 의존하지 않으며, 사실상 전혀 신뢰할 수 없는 구조가 아닙니다.
- 분쟁 해결 메커니즘이 있습니다.
- 분쟁 기간이 있기 때문에 유효성 검증 절차가 아닙니다. 또한 ZK 설계도 아닙니다. 따라서 아마도 낙관적 롤업과 유사하거나 그와 비슷한 형태일 것입니다.
- 보안은 주로 비밀 유지에 달려 있는데, 분쟁 해결 기간이 200초에 불과하기 때문입니다. 200초라는 시간은 약 60억 달러를 확보하기 위해 필요한 비상 조치를 취할 수 있는 유일한 시간입니다. 분쟁 해결 기간이 약 1주일인 Arbitrum과 Optimism과 비교해 보세요.
- Hyperliquid 팀은 브리지를 적극적으로 관리합니다.
- Hyperliquid 팀은 모든 출금 요청을 승인해야 합니다.
- 폐쇄형 소스 Hyperliquid 체인의 검증자 집합은 브리지에서 인식하는 검증자 집합과 연결되어 있지 않거나, 적어도 밀접하게 연결되어 있지 않습니다. Hyperliquid는 이와 관련하여 용어를 남용하는 경우가 많습니다.
마지막으로, 200초라는 이의 제기 기간이 짧아 보일지 몰라도 외부인이 이의 제기 절차를 이용할 수 있는 것은 아니라는 점에 유의하십시오. 측정 기준이 없는 상황에서 무엇을 이의 제기할 수 있겠습니까? 이러한 "기술" 중 일부는 다소 우스꽝스럽습니다.
교량 설계
우리는 Hyperliquid 브리지의 Arbitrum 측 코드만 볼 수 있습니다. 따라서 제품을 분석하는 가장 간단한 방법은 Arbitrum 측의 동작 방식을 관찰하는 것입니다.
브리지는 분쟁 기간이 변경될 때 newDisputePeriodSeconds 필드를 포함하는 ChangedDisputePeriodSeconds 이벤트를 발생시킵니다. 이는 분쟁 기간이 존재하며, 아마도 분쟁 해결 절차가 있음을 알려줍니다. 또한 브리지가 errorCode 4를 포함하는 FailedWithdrawal 이벤트를 발생시켰기 때문에 이 분쟁 기간이 적용되고 있음을 알 수 있습니다. 코드를 살펴보면 getDisputePeriodErrorCode() 내부에서 다음과 같은 내용을 찾을 수 있습니다.
bool enoughBlocksPassed = (curBlockNumber - blockNumber) * blockDurationMillis > 1000 * disputePeriodSeconds;
만약 충분한 블록이 전달되지 않았다면 {
4를 반환합니다.
}
오류 코드 4와 함께 발생한 출금 실패는 출금 요청이 너무 빨리 이루어져 거부된 상황을 의미합니다. 분쟁 해결 기간이 존재한다는 것은 이 설계가 순수한 ZK 방식이 아니라는 것을 시사합니다. ZK 소유권 증명으로 출금이 제한된다면 분쟁 해결 절차가 필요 없기 때문입니다. Hyperliquid 자체의 설계에 대해 직접적으로 언급할 수는 없지만, 이러한 사실은 Hyperliquid가 ZK 기반 설계가 아니라는 것을 강력하게 시사합니다.
이 다리에는 다음과 같은 특이한 분쟁 해결 절차가 있습니다.
- 환불 요청이 접수되면 분쟁 기간이 시작됩니다.
- 관리자는 invalidateWithdrawals() 함수를 호출하여 보류 중인 출금을 차단할 수 있습니다.
- 분쟁 기간이 종료된 후에도 유효한 인출 요청은 진행될 수 있습니다.
이것은 분쟁 해결이라기보다는 중앙집권적 통제의 노골적인 형태에 가깝습니다. l2beat 용어로 말하자면, 이는 0단계에 해당합니다 . l2beat의 단계별 용어에 익숙하지 않은 분들을 위해 설명하자면, l2beat에서는 Hyperliquid를 L2로 분류한다면 중앙집권적이고 " 초보 단계 "에 있는 것으로 간주할 것입니다.
아래에서 살펴보겠지만, 하이퍼리퀴드 팀은 이러한 프로세스를 오프체인에서 운영하며, 관리의 모든 과정이 자율적으로 이루어지지 않습니다. 하이퍼리퀴드는 소프트웨어로 자동화되어 있지만, 모든 은행 소프트웨어가 자동화되는 방식과 동일합니다. 즉, 인간 수준의 제어와 배후의 마법사 같은 운영자가 개입하는 방식입니다. l2beat의 관점에서 이는 0단계의 특징이기도 합니다. 우리는 여기서 새로운 것을 창조하는 것이 아니라, 이미 널리 인정받는 프레임워크와 정의를 익숙한 요소들을 가진 제품에 적용하는 것뿐입니다.
하이퍼리퀴드란 어떤 종류의 물질인가요?
Hyperliquid는 스스로를 레이어 1 블록체인이라고 부릅니다. 하지만 모든 자산이 이더리움 레이어 2 블록체인인 Arbitrum 상의 단일 브리지 컨트랙트에서 나오기 때문에, 어떤 의미에서는 레이어 3이라고도 볼 수 있습니다. 그리고 위 분석에서 알 수 있듯이 ZK 롤업이나 Validium도 아닙니다. 그렇다면 Hyperliquid는 정확히 무엇일까요?
이로 인해 우리에게 남은 선택지는 몇 가지밖에 없습니다. 낙관적 롤업 방식이나 플라즈마 체인의 변형일 수도 있고, 사이드체인 방식일 수도 있습니다. 이러한 방식들을 혼합한 형태일 수도 있습니다. 하지만 분쟁 해결 절차는 존재하지만, 이러한 방식이 어떻게 작동하는지, 또는 정확히 무엇을 분쟁해야 하는지에 대한 공개적인 규정은 없다는 점에 유의해야 합니다.
설령 그 과정이 아주 일반적인 낙관적 롤업 방식이라 하더라도, 팀 외에는 누구도 이의를 제기할 수 없으므로 사실상 아무런 문제가 되지 않습니다. 실제로 이것은 팀이 완벽하게 제어할 수 있는 0단계 레이어 3 블록체인일 뿐입니다. 소프트웨어는 (다시 말하지만, 대부분 클로즈드 소스이며) 플라즈마나 사이드체인 등의 데이터 구조와 함수 이름을 사용할 수도 있지만, 실제로는 불필요한 코드가 추가된 커스터디얼 멀티시그일 뿐입니다.
팀의 관점에서 보면 그 코드는 필수적일 수 있습니다. 팀은 그 코드에 대해 매우 자부심을 느낄 수도 있습니다. 하지만 외부 관찰자에게는 그 어떤 것도 중요하지 않습니다. 왜냐하면 이러한 것들은 폐쇄적인 생태계 안에서 존재하기 때문입니다. 연구자가 분석을 위해 하이퍼리퀴드의 작동 방식을 추측해야 한다면 이미 문제가 있음을 암시하는 것입니다. 하지만 이론적으로는 자율적이고 분산된 블랙박스 시스템을 구축할 수 있습니다. 사용자는 적어도 형식적으로는 볼 수도 이해할 수도 없는 프로세스의 결과를 수용하는 데 동의할 수 있습니다.
선물거래소에서 이러한 계약이 얼마나 강제력을 가질지는 불분명하지만, 계약서 작성 자체는 어렵지 않습니다. 그러나 여기서 살펴보듯이, 관리자들이 블랙박스에 대해 행정적 조치를 취하는 경우가 있습니다. 이는 상황을 완전히 바꿔놓습니다. 이제 관리자들은 중앙 통제권을 갖고 있지 않다는 것을 입증해야 할 책임이 있습니다. 또는, 이 사례처럼, 우리는 그러한 주장을 차단하는 선제적 증거를 제시할 수도 있습니다.
교량 관리
Hyperliquid 팀이 브리지 계약에서 다음 5가지 관리 함수를 호출하는 것을 볼 수 있으며, 각 함수는 이름에서 알 수 있듯이 해당 기능을 수행합니다.
- changeDisputePeriodSeconds()
- modifyFinalizer()
- modifyLocker()
- voteEmergencyLock() 함수는 "일시 중지됨" 이벤트를 발생시킵니다.
- emergencyUnlock() 함수는 "Unpaused" 이벤트를 발생시킵니다.
이 브리지는 Hyperliquid 팀이 updateValidatorSet() 및 finalizeValidatorSetUpdate() 함수를 사용하여 조작할 수 있는 검증자 세트 정보도 유지합니다. 검증자 세트에 대한 유지 관리는 2023년 12월과 2024년 10월에 수행되었습니다. 그 후 2025년 4월 22일, Hyperliquid 팀은 검증자 세트를 확장한다고 발표했지만 , 이에 상응하는 RequestedValidatorSetUpdate 및 FinalizedValidatorSetUpdate 이벤트는 발생하지 않았습니다.
이는 브리지가 알고 있는 검증자 집합이 동시에 변경되지 않았음을 의미합니다. 몇 달이 지난 지금도 검증자 집합은 업데이트되지 않았으며, 이는 하이퍼리퀴드 블록체인과 브리지 간의 검증자 집합 동기화(신뢰할 수 있는 동기화)가 필수적이지 않다는 것을 입증합니다. 검증자 집합에 대한 공개적인 설명과 검증자 집합을 조작하는 기능의 실제 사용 사이에 차이가 있는 것으로 보입니다.
이는 용어 남용의 명백한 증거입니다. Arbitrum에서 호스팅하는 브리지 계약용 검증자 세트가 있고, Hyperliquid 플랫폼용 검증자 세트도 있습니다. 이 두 세트의 업데이트 내역을 비교해 보면 반드시 동일할 필요는 없다는 것을 알 수 있습니다. 여기에는 서로 다른 두 가지 "검증자 세트" 개념이 존재합니다. Hyperliquid에서 두 세트가 동일하다고 하더라도, 실제로 동기화되지 않고 있다는 것을 직접 확인할 수 있습니다.
팀에서 탈퇴를 승인했습니다
브리지 계약 활동을 살펴보면 다음과 같은 함수 호출이 지속적으로 발생하는 것을 확인할 수 있습니다.
- 배치된 허가를 받은 입금()
- batchedRequestWithdrawals ()
- batchedFinalizeWithdrawals ()
입금 절차는 입금자의 자금에서 브리지로의 이체를 시작합니다. 입금자가 이체에 필요한 충분한 자금을 보유하고 있으면 입금이 등록됩니다. 이 과정은 간단합니다.
하지만 출금 과정은 훨씬 더 복잡합니다. 출금이 성공적으로 이루어지려면 출금 요청과 최종 승인이 모두 필요하며, 두 단계 모두 충분한 수의 시스템 "검증자"의 서명이 필요합니다. 검증자 목록은 위에서 설명한 바와 같이 이 브리지의 관리 기능에 의해 제어됩니다. 이들은 이미 알려진 바와 같이 Hyperliquid 블록체인과 동기화되지 않은 Arbitrum 측 검증자들입니다.
입금은 사용자가 직접 시작하며, 중앙 Hyperliquid 기관 및 해당 기관의 소프트웨어 개입이 필요하지 않습니다. 시스템 출시 이후 300개 이상의 주소에서 입금이 이루어졌습니다. 반면, 출금은 요청이 접수되면 팀에서 일괄 처리하여 최종 승인합니다. Hyperliquid가 관리하는 4개의 주소가 모든 출금 요청 및 승인을 담당하며, 2025년 중반 이 데이터 작성 시점을 기준으로 각 주소당 약 20만 건의 출금 요청 및 승인이 처리되었습니다. 해당 주소는 다음과 같습니다.
주소 | 요청 | 최종 확정 |
|-------------------------------------------|---------|--------|
|0x58e1b0e63c905d5982324fcd9108582623b8132e | 201,581 | 194,557|
|0xef2364db5db6f5539aa0bc111771a94ee47637fc | 201,779 | 194,418|
|0x263294039413b96d25e4173a5f7599f8b3801504 | 201,294 | 194,508|
|0xda6816df552c3f9e0fb64979fb357800d690d79b | 200,921 | 195,196|
이 주소들은 명백히 팀에서 관리하는 주소인 0x1D4c01E15A637cB3cbaF86fFbb02E5A260D01fbc에 의해 검증자로 추가되었습니다. 이 모든 정보는 공개된 자료를 통해 확인할 수 있으며, 시스템의 비공개 소스 선물 거래소 측 정보는 전혀 필요하지 않습니다.
우리는 이 주소들이 모두 해당 팀의 주소라는 것을 확신합니다. 왜냐하면 출시 이후 처리된 모든 출금 요청이 이 주소들에 포함되어 있기 때문입니다. 이 주소들은 출시 후 몇 주 또는 몇 달 후에 점진적인 탈중앙화 과정 중에 추가된 주소들이 아닙니다. 현재 존재하는 주소는 이 주소들뿐입니다. 만약 팀이 존재한다면(그리고 분명히 존재합니다), 이 주소들은 Hyperliquid 팀의 일부로 간주되어야 마땅합니다. 왜냐하면 출금을 제한한 주소는 이 주소들뿐이기 때문입니다.
이러한 요청들은 충분한 수의 검증자 서명이 포함되어야만 브리지 계약에 의해 승인됩니다. 그리고 현재의 검증자 집합은 팀에 연결된 주소들에 의해 관리됩니다. 팀의 통제에 대한 유일한 제한은 관리 업데이트가 분쟁 기간 동안에는 확정될 수 없다는 것입니다. 이 분쟁 기간은 200초입니다. 만약 팀이 독단적으로 행동하기로 결정한다면, 이론적으로 누군가 어딘가에서 출금을 요청하거나 무언가를 무효화해달라는 요청을 제출할 수 있는 200초의 기간이 생길 수 있습니다. 하지만 이 과정 역시 공개되지 않습니다. 오직 검증자만이 이를 막을 수 있습니다. 다시 말해, "분쟁" 과정은 허울뿐이며, 이 모든 것은 거대한 다중 서명에 불과합니다.
이제 우리는 출금 기능이 Arbitrum의 팀 검증자 주소로만 제한된다는 것을 알게 되었습니다. 위의 분석이 이를 명확하게 입증하지만, 이 사실이 잘 숨겨져 있는 것은 아닙니다. Hyperliquid에 있는 팀의 검증자 주소는 공개적으로 기록되어 있으며, Arbitrum 측에서도 동일한 이름이 다른 주소를 사용하여 공개적으로 검증자로 표시되고 있습니다.
- 0xef2364db5db6f5539aa0bc111771a94ee47637fc
- 0xda6816df552c3f9e0fb64979fb357800d690d79b
- 0x58e1b0e63c905d5982324fcd9108582623b8132e
- 0x263294039413b96d25e4173a5f7599f8b3801504
그리고 해당 팀이 통제한다고 인정한 주소들이 유일한 검증자였던 이후로 시스템을 운영해 왔습니다.
위에서 설명했듯이, 분쟁 기간과 분쟁 해결 절차가 있습니다. 관리자가 요청된 출금을 무효화하지 않으면 요청 및 확정 기능 호출이 해당 절차의 시작과 끝을 장식합니다. 이러한 호출을 시작하는 주소는 EOA(Expression of Output Address)입니다. 따라서 이러한 호출은 수동으로 서명되거나 팀이 개인 키에 접근 권한을 부여한 오프체인 프로세스를 통해 서명됩니다. 이는 Hyperliquid의 운영이 완전 자동화되거나 탈중앙화되어 있지 않다는 것을 더욱 분명히 보여줍니다. 자동화되어 있을 수는 있지만, 마치 오븐 타이머처럼 사람이 설정하고 제어하며 끌 수 있는 자동화 방식입니다.
팀이 오프체인 프로세스를 통해 출금을 승인하는 이 단계는 DDoS 공격 및 유사한 공격에 취약하며, 위임 프로그램 참여자들이 사용하는 데이터 센터를 알고 있다면 공격이 더욱 쉬워집니다. Hyperliquid가 동일한 데이터 센터를 사용한다는 보장은 없지만, 공격자는 해당 데이터 센터를 먼저 살펴보는 것이 좋습니다. 아래에서 설명하는 것처럼 팀이 API 접근 문제를 경험한 적이 있으므로 이는 이론적인 문제가 아니라 실제 문제임을 알 수 있습니다.
또한 문서에 시스템이 "일본 도쿄"에서 실행된다고 명시되어 있는 것을 통해 데이터 센터의 위치를 짐작할 수 있습니다. 제공된 공용 IP 주소를 살펴보면 이 시스템은 도쿄에 있는 AWS 또는 Microsoft 데이터 센터(혹은 둘 다)에서 실행되고 있음을 알 수 있습니다.
2025년 7월 정전
2025년 7월 29일, Hyperliquid에 장애가 발생했습니다. 팀은 Discord를 통해 지원 및 정보를 제공했습니다. 창립자 중 한 명은 자신이 시스템 운영자임을 분명히 밝히는 방식으로 공개적으로 소통했습니다.
그들이 문제의 근원을 블록체인 노드가 아닌 API 서버로 지목하고 있다는 점에 주목하세요. 하지만 네트워크에 참여하기 위해 직접 코드를 컴파일하고 실행할 수 없다는 점에서 이는 사실상 차이가 없습니다.
또한 팀이 이러한 종류의 통제를 일상적으로 행사한다는 점도 주목할 만합니다.
시스템을 10분 동안 중단하는 것은 장애를 일으키는 근본적인 문제를 해결하는 것과 동일한 수준의 제어력을 보여줍니다. 특히 그 중단 시간이 팀에게 소프트웨어 문제를 수정할 기회를 제공한다면 더욱 그렇습니다. 때때로 팀원들이 자신들이 가진 제어력을 제대로 이해하지 못하는 것처럼 보일 때가 있습니다. 예를 들어, 많은 DEX 라우터는 관리자에게 시스템을 완전히 먹통으로 만들 수 있는 충분한 제어 권한을 부여하지만, 개발자 중 상당수는 아직 그 사실을 인지하지 못하는 것 같습니다. 하지만 Hyperliquid는 다릅니다. 이 팀은 자신들이 시스템을 제어할 수 있다는 것을 알고 있으며, 이를 일상적으로 활용합니다.
팀의 오프체인 인프라 대부분은 장애 발생 중에도 계속 작동했습니다. 여기에서 API 문제에도 불구하고 출금 승인이 계속되는 것을 확인할 수 있습니다.
이는 해당 팀이 자신들의 통제권을 이용해 거래를 악용할 수 있는 간단한 방법을 보여줍니다. 모든 사용자가 API를 사용할 수 없게 될 경우, 해당 팀은 다른 모든 사용자의 API 접근을 차단한 후 직접 거래를 진행할 수 있습니다. 거래 및 출금 승인 권한을 모두 장악함으로써, 해당 팀은 Arbitrum 측의 의심스러운 행위 없이 Hyperliquid의 시장을 조작하여 예치된 모든 담보금을 자신들이 차지할 수 있습니다. Hyperliquid는 폐쇄형 소스이며 투명성이 부족하기 때문에 외부 당사자가 이러한 사건 발생 시 상황을 재구성하고 입증하는 것조차 불가능할 수 있습니다.
만약 해당 팀이 선물 거래소 내 팀이 관리하는 주소로 담보금을 빼돌리기 위해 이 "공격"을 계획했다면, 전체 상황은 그저 극적인 ADL 공격과 몇몇 승자들이 탈중앙화 시스템에서 수익을 인출하는 것처럼 보일 수 있습니다. 그리고 이를 막을 수 있는 분쟁 해결 메커니즘도 없습니다.
중앙 제어
이로써 팀은 완전한 중앙 집중식 통제권을 확보하게 됩니다. 하이퍼리퀴드 플랫폼 블록체인의 탈중앙화 여부에 따라 검증자 세트를 업데이트할 필요가 없다는 점에 주목하십시오. 왜냐하면 하이퍼리퀴드 팀은 출금을 무효화하여 사전에 차단할 수 있기 때문입니다. 물론 팀은 남아 있는 모든 "유효한" 요청에 대해 오프체인에서 승인을 진행해야 합니다. 따라서 시스템의 클로즈드 소스 측면은 팀의 완전한 독립적인 통제권을 확립하는 데 논의 대상이 될 필요가 없습니다. 이 시스템은 팀이 자체 브리지 양쪽의 자금에 대해 완전한 독립적 통제권을 행사할 수 있도록 운영됩니다.
예를 들어, 플랫폼의 아비트럼 이외의 부분은 클로즈드 소스이며 팀에서 완전히 통제하기 때문에 시장 조작을 통해 사용자 자산을 훔칠 수 있는 등 추가적인 공격 경로가 존재한다는 것은 이러한 "탈중앙화"에 도움이 되지 않습니다.
정리하자면 다음과 같습니다.
- Hyperliquid 서비스 시작 이후 모든 출금 요청은 단 4개의 팀 관리 주소에서만 승인되었습니다.
- 팀에서 승인한 검증자만 Hyperliquid를 변경하거나 보류 중인 조치에 이의를 제기할 수 있습니다.
- 팀은 검증자 세트를 사실상 마음대로 변경할 수 있으며, 경우에 따라 짧은 지연 시간 동안에는 팀 외에는 누구도 변경을 적용할 수 없습니다.
- 해당 팀은 현재 약 60억 달러에 달하는 사용자 예치금을 여러 가지 방법을 통해 사실상 마음대로 훔칠 수 있습니다.
Hyperliquid는 검증자 집합에 대해 이야기 하고 특정 검증자 집합에 대한 지표를 보고합니다 . 다른 당사자들은 Hyperliquid에서 검증자가 되는 것에 대해 이야기합니다 . 심지어 Hyperliquid 검증자 협회처럼 보이는 것도 있습니다. 하지만 이 모든 것은 Hyperliquid의 비공개 소스 블록체인과 관련된 것이며, 실제 자금이 있는 Arbitrum 측과는 관련이 없습니다. Hyperliquid는 "검증자"라는 단어를 두 가지 다른 의미로 사용하면서도 그 차이를 명확히 구분하지 않습니다.
냉소적인 사람이라면 그들이 의도적으로 두 가지를 혼동시키고 있다고 말할지도 모릅니다. 다음번에 이런 사기 행각을 벌일 때는 기술적인 이유가 없더라도 공개적으로 보이는 부분, 즉 아비트럼(Arbitrum)의 검증자 설정과 비공개 부분의 변경 사항을 최소한이라도 조율하도록 권고합니다. 그렇게 조율한다면 탈중앙화라는 환상을 더 잘 유지할 수 있을 것입니다.
현재로서는 Hyperliquid 무기한 선물 거래소를 호스팅하는 폐쇄형 블록체인에서의 검증과 Arbitrum 스마트 계약 목적의 중앙 집중식 검증자 세트에 포함되는 것을 구분할 수 있습니다. 시스템 작동 방식을 이해하면 이 둘을 구별할 수 있습니다. 이 모든 소란은 기껏해야 시스템 작동 방식에서 주의를 분산시키려는 시도일 뿐입니다.
해당 팀은 시스템의 다른 부분에 대한 통제권을 인정하며 , 팀 문제로 인한 손실에 대해서는 환불까지 제안했습니다 . 하지만 아비트럼(Arbitrum) 상에서 팀이 관리하는 소수의 주소들이 프로젝트에 예치된 약 60억 달러 상당의 USDC를 완전히 독립적으로 통제하고 있는 상황에서, 왜 팀이 이러한 문제들을 특히 중요하게 여기는지는 불분명합니다. 선의는 물론 좋은 것이지만, 동시에 잘못을 인정하는 것으로 비춰질 수도 있습니다. 특히 그러한 선의가 또 다른 공격 경로를 드러낸 사건과 관련된 것이라면 더욱 그렇습니다.
전체 시스템은 싱가포르에서 운영되는 것으로 보입니다. Hyperliquid Labs가 자체 문서에 명시된 개발 주체이며, 이 회사는 싱가포르 에 등록된 회사 입니다. 또한 이 회사는 Hyperliquid를 대표하여 미국 상품선물거래위원회(CFTC)에 제출된 의견서에 서명했습니다.
그러니까 그 회사는 고객 자금을 보관하고, 단일 중앙 거점을 통해 전 세계에 KYC(고객 신원 확인) 없이 레버리지 거래를 제공하려는 거군요. 흥미롭네요.
Hyperliquid의 중앙 집중식 제어에 대한 글은 원래 Medium의 ChainArgos 에 게시되었으며, 독자들이 이 글을 강조 표시하고 댓글을 달면서 토론을 이어가고 있습니다.
