Aster는 "탈중앙화된" 무기한 선물 거래소로 알려져 있지만, 실제로는 팀에 의해 중앙 집중화되고 통제됩니다. 이는 가짜 탈중앙화 무기한 선물 거래소에 대한 더 큰 논의 의 일부입니다. 또한 Aster는 몇 년 전 폐쇄 및 서비스 중단 으로 이어진 바이낸스의 과거 문제점과 유사한 점이 있습니다.
Aster는 대부분 BNB 스마트 체인에서 운영됩니다. 이 블록체인 자체는 바이낸스가 사용자 자금에 대해 거의 완전한 독립적 통제권을 행사해 온 전례가 있습니다. 따라서 Aster가 중앙 집중식이라는 두 번째 주장은 바이낸스가 과거에 사용자 자금을 동결하고 완벽하게 유효한 개인 키가 BNB 스마트 체인에서 작동하지 못하도록 차단하는 특권적 지위를 행사 했다는 것입니다. 바이낸스는 이러한 조치가 해킹으로부터 사용자 자금을 보호하기 위한 대응이었다고 주장합니다. 뭐, 그럴 수도 있겠죠.
물론 이는 BNB 스마트 체인의 모든 것이 바이낸스가 사용자 자금 안전에 최선의 이익이 되지 않는다고 판단하여 일방적으로 차단할 수 있는 상황의 영향을 받는다는 것을 의미합니다. 이러한 주장은 어느 정도는 사실입니다. 하지만 이는 지나치게 단순화된 해석입니다. 우리는 단순히 바이낸스가 아스터 플랫폼을 지원하고, 바이낸스가 BNB 스마트 체인을 통제하며, BNB 스마트 체인에 이러한 코드가 포함되어 있다는 이유만으로 아스터가 중앙 집중식이라고 주장하는 것이 아닙니다.
// 이는 Tendermint IAVL Merkle Proof 검증 취약점 때문에 도입되었습니다.
var NanoBlackList = []common.Address{
common.HexToAddress("0x489A8756C18C0b8B24EC2a2b9FF3D4d447F79BEc"),
common.HexToAddress("0xFd6042Df3D74ce9959922FeC559d7995F3933c55"),
// 테스트 계정
common.HexToAddress("0xdb789Eb5BDb4E559beD199B8b82dED94e1d056C9"),
}
자, 그럼 Aster 내부에 많은 자금을 보관하는 Vault 계약부터 살펴보겠습니다. 이 계약은 업그레이드 가능한 프록시 계약 으로, 팀이 모든 자금을 가져갈 수 있도록 구성되어 있습니다. 이는 사실일 뿐만 아니라 플랫폼 감사 보고서에서도 공식적 으로 인정된 내용입니다. 감사 보고서에 따르면 초기 설계 단계에서는 단일 주소로 Vault에 있는 모든 자금을 훔칠 수 있는 구조였습니다. 감사 과정에서 이 문제가 발견되었고, 팀은 멀티시그 방식으로 변경하기로 결정했습니다. 이 내용은 Aster 팀이 자체 웹사이트 에 공개한 감사 보고서에 명시되어 있습니다. 이는 매우 확실한 증거입니다.
다음으로, 팀이 플랫폼을 제어하는 데 사용할 수 있는 다양한 제어 기능을 살펴보겠습니다. 그리고 나서 팀만이, 오직 팀만이 이러한 제어 기능을 이용하여 사용자 자산을 탈취할 수 있는 방법에 대해 논의하겠습니다. 이 모든 것은 시스템의 예상 기능에서 벗어나는 것을 요구하지 않습니다. 물론 이러한 행위는 절도에 해당하므로 팀이 플랫폼을 만든 의도와는 일치하지 않습니다. 하지만 은행 경영진이 "은행 인가를 받으려는 이유"라는 질문에 "돈을 훔치기 위해서"라고 적지는 않습니다. 중요한 것은 이러한 모든 "공격"이 Aster에 의도적으로 내장된 제어 기능을 사용하여 이루어질 수 있다는 점입니다.
그리고 누군가 "하지만 DEX는 탈중앙화된 거버넌스를 가지고 있지 않나요?"라고 말하기 전에, 향후 탈중앙화된 거버넌스를 도입할 계획이 있지만 현재는 위에서 설명한 바와 같다는 점을 알아두셔야 합니다.
그러니까 일종의 관리자가 있는데, DAO는 아닙니다. 이제 관리자의 권한에 대해 논의해 볼 수 있겠네요.
우선 관리자는 시스템을 일시 중지하거나 다시 시작할 수 있습니다. 즉, 자금을 인출할 때 시간적 압박을 전혀 느끼지 않는다는 뜻입니다. 일시 중지 버튼 덕분에 조정, 타이밍, 동기화가 모두 간편해집니다.
해당 팀은 수수료 및 미결제 약정 한도를 포함한 다양한 매개변수를 동적으로 조정할 수 있는 능력을 갖추고 있습니다. 즉, 사용자가 예상하지 못한 방식으로 시스템의 부채를 줄여 계약을 취소하거나 청산을 강제할 수 있다는 의미입니다.
또한 해당 팀은 거래소 운영에 사용되는 가격 정보 소스를 변경할 수 있습니다. 그렇다면 팀이 이러한 관리자 인터페이스를 사용하여 이러한 작업을 정기적으로 수행하는지 묻는 것이 타당할 것입니다. 네, 그렇습니다. 다음은 자동화되지 않고 오프체인에서 제어되지 않으며 사람이 직접 운영하는 관리자 주소인 EOA 하나가 구성 업데이트를 지속적으로 전송하는 예입니다.
"일괄 업데이트..." 호출은 다음과 같은 거래 구성 업데이트 의 긴 목록을 생성합니다.
그러면 "Tp Sl 또는 Liq 실행" 호출 수익률 변경 사항은 다음과 같습니다.
자, 이제 좀 더 명확하게 이해하기 위해 이러한 관리자 제어 기능이 어떻게 구현되는지 간단히 살펴보겠습니다. 복잡해서가 아니라, 오히려 매우 간단하고 쉽게 이해할 수 있기 때문입니다. TradingConfig의 몇 가지 제어 기능은 다음과 같습니다 .
함수 setTradingSwitches(
bool limitOrder, bool executeLimitOrder, bool marketTrade,
bool userCloseTrade, bool tpSlCloseTrade, bool liquidateTradeSwitch,
bool predictBet, bool predictSettle
) 외부 재정의 {
LibAccessControlEnumerable.checkRole(Constants.MONITOR_ROLE);
uint tradeSwitches = 0;
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.LIMIT_ORDER), limitOrder);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.EXECUTE_LIMIT_ORDER), executeLimitOrder);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.MARKET_TRADING), marketTrade);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.USER_CLOSE_TRADING), userCloseTrade);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.TP_SL_CLOSE_TRADING), tpSlCloseTrade);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.LIQUIDATE_TRADING), liquidateTradeSwitch);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.PREDICTION_BET), predictBet);
tradeSwitches = tradeSwitches.setOrClearBit(uint8(TradingSwitch.PREDICTION_SETTLE), predictSettle);
LibTradingConfig.setTradingSwitches(uint16(tradeSwitches));
}
함수 setExecutionFeeUsd(uint256 executionFeeUsd) 외부 재정의 {
LibAccessControlEnumerable.checkRole(Constants.ADMIN_ROLE);
LibTradingConfig.setExecutionFeeUsd(executionFeeUsd);
}
…
함수 setMaxTpRatioForLeverage(주소 pairBase, MaxTpRatioForLeverage[] calldata maxTpRatios) 외부 재정의 {
LibAccessControlEnumerable.checkRole(Constants.PAIR_OPERATOR_ROLE);
require(pairBase != address(0) && IPairsManager(address(this)).getPairForTrading(pairBase).base != address(0), "TradingConfigFacet: pair does not exist");
LibTradingConfig.setMaxTpRatioForLeverage(pairBase, maxTpRatios);
}
각 함수의 시작 부분에서 checkRole(SOME_ROLE)을 호출하는 것을 볼 수 있습니다. MONITOR_, ADMIN_, OPERATOR_ 역할에 대한 컨트롤이 각각 하나씩 있습니다. 여기에는 몇 가지 다른 관리자 역할과 이를 관리하는 관련 메커니즘이 있지만, 여기서는 자세히 다루지 않겠습니다.
핵심은 간단히 말해서 여기에 권한을 가진 관리자들이 있다는 것입니다. 그리고 시스템이 다중 서명에 크게 의존하기 때문에 이러한 제어 기능 중 상당수는 변경을 위해 여러 명의 권한 있는 관리자(EOA)의 서명이 필요합니다. 하지만 이는 위에서 언급한 2024년 9월 감사 보고서에서 지적된 문제와 정확히 동일합니다. 설계, 구축, 배포 및 실제 운영 방식 모두에서 이 시스템은 여러 관리자가 변경 사항에 서명해야 하는 기존 금융 회사와 마찬가지로 중앙 집중화되어 있습니다.
따라서 하이퍼리퀴드와 마찬가지로, 시스템은 오프체인 부분이 공정하게 운영되는지 여부에 대해 걱정할 필요 없이, 운영팀이 시스템 전체를 강제로 조작하여 선호하는 온체인 계정에 모든 자금을 지급하도록 할 수 있습니다.
어떻게 가능할까요? 예를 들어, 팀은 가격 정보 출처를 팀이 관리하는 오라클로 전환한 다음, 팀과 관련된 포지션이 모든 자금을 확보하도록 할 수 있습니다. 마찬가지로, 팀은 자금 조달 비율 수준, 레버리지 한도, 다양한 청산 관련 매개변수를 충분히 통제하여 시간이 지남에 따라 예치금을 회수할 수 있습니다.
좀 복잡하고 억지스럽게 들리지 않나요? 팀이 사용자 자산을 대량으로 빼돌리고, 감사인이 이를 알아채고 인정했는데도 감사 보고서를 웹사이트에 게시했다는 사실을 잊으셨나요? 모든 공격은 그보다 훨씬 복잡합니다! 여기서 설명한 가장 간단한 공격은 "금전함을 열어 돈을 빼돌리는 것"이고, 그보다 더 복잡한 방식이 있습니다. 그리고 이 팀은 플랫폼의 일부인 스테이블코인 Aster USDF에 대해서도 동결 및 압류 권한을 포함한 강력한 통제권을 가지고 있습니다. 그리고 다른 감사 보고서 에서도 이러한 문제점들이 지적되었습니다.
그리고 그 코드는요? BNB 비콘 체인 냄새가 나네요.
위 코드 조각을 길게 인용했지만, 이 부분은 주로 블록체인 탐색기에서 가져온 것입니다. 블록체인 탐색기는 코드를 보기에는 최적의 장소가 아닙니다. 이력을 확인하기 어렵고, 스마트 계약 이외의 코드는 저장할 방법이 없기 때문입니다. Aster에는 다른 구성 요소도 있는데… 도대체 무슨 문제일까요?
공식 링크는 코드로 연결되지 않습니다.
감사 결과조차도 다소 무작위적인 위치를 지적하고 있습니다.
github.com/astherus-contract 저장소에는 코드가 일부 있지만 최신 코드는 아닙니다.
스마트 계약 코드와 최근 활동 내역이 일부 포함된 별도의 github.com/asterdexcom 저장소가 있지만, 그 외에는 별다른 내용이 없습니다.
이 저장소들의 커밋 기록을 살펴보면, 이것들이 개발 저장소이고 팀 구성원들이 alex-degen, cody-z, mark-c 같은 가명으로만 이루어져 있다는 것이 분명합니다. 결국 이 어처구니없는 헛소리가 또다시 반복되는 것 같네요 .
지금은 폐쇄된 BNB 비콘 체인과, 그 팀이 시스템이 비공개 소스라고 공개적으로 주장한 지 한참 후에야 이를 인정했던 일이 있었습니다. 우리는 V와 zoro와 공개적으로 많은 설전을 벌였는데, 그들은 꽤 자주 사실을 시인하는 듯했습니다.
2022년 말/2023년 초쯤에 그들은 새로운 문서와 코드를 공개했는데, 그 내용이 사실상 전체 시스템이 사기였다는 것을 인정하는 것이었습니다. 결국 모든 것이 폐쇄 되었죠. 아, 그리고 당시에는 담보가 없는 자산이 많이 사용되었는데, 이것 때문에 BUSD가 폐쇄된 것도 사실입니다.
만약 코디-Z가 조로바이트였다는 사실이 밝혀진다 해도 아마 아무도 놀라지 않을 겁니다. 어쨌든 BNB 비콘 체인의 원래 목적 중 하나는 아스터처럼 높은 처리량을 제공하는 탈중앙화 거래 플랫폼을 구축하는 것이었으니까요. 정말입니다. 이건 2022년 중반에 나온 얘기입니다 .
저희의 의견 제시 이후, 해당 팀은 새로운 코드와 문서를 작성했음을 공개적으로 인정했습니다. 그들은 오랫동안 개방형 시스템이라고 주장해왔던 것에 대한 저희의 질문에 대한 답변으로 이러한 조치를 취했음을 공개적으로, 그리고 서면으로 인정했습니다.
당시에는 여러 가지 문제들이 있었는데, 음, 앞으로 해결해야 할 과제로 남아 있었습니다.
약속했던 대로 모든 문제를 해결하는 대신, BNB 비콘 체인은 데이터가 완전히 명확해지기도 전에 폐쇄되었습니다. 아, 그리고 당시에 는 미래의 탈중앙화를 약속하기도 했죠.
BNB 비콘 체인의 야심찬 탈중앙화 거래소(DEX)는 당시 인기 있던 여러 DeFi 제품들을 모방했습니다. 그리고 그 야심찬 탈중앙화는 (힌트: 아스터를 포함한) 여러 가지 다른 플랫폼과 매우 흡사해 보였습니다. 하지만 그것은 항상 중앙 집중식이었고, 부분적으로는 오픈 소스가 아니었으며, 이상한 기능과 동작 방식을 가진 시스템이었습니다. 간단히 말해서, 그것은 사기였고, BUSD는 뉴욕 금융감독청(NYDFS)에 의해 무자비하게 거래되었으며, 결국 BNB 비콘 DEX 전체가 폐쇄되었습니다. 이제 아스터는 그 실패작들과 매우 흡사해 보입니다.
그래서?
이번에는 '아스터'라는 이름을 붙이고 지난번에 여러분이 그렇게 좋아했던 2021/2022 DEX 대신 '하이퍼리퀴드'를 흉내 내는 걸 보니 행운을 빌어요.
이전에 BNB 체인 팀은 우리의 질문을 주장으로 잘못 표현했고, 모든 것이 항상 괜찮았다는 점을 명확히 하는 데 전반적으로 미흡한 모습을 보였습니다.
"당신이 만든 프로그램을 실행하면 X라는 결과가 나옵니다. 설명해 주시겠습니까?"는 사실을 진술한 후 질문을 던지는 형식입니다. 위 내용은 저희의 질문이라고 생각해 주십시오. 지난번처럼 당신은 새로운 코드와 문서를 게시하고 답변에 링크를 걸어 마치 우리가 제대로 읽지 않은 것처럼 보이게 했지만, 사실은 당신의 작업에 결함이 있었습니다. 따라서 이번에는 타임스탬프를 표시하여 공개적으로 문제를 제기하고자 합니다.
앞서 여러 차례 설명드렸듯이, 이 블로그는 과거에 대한 예측을 전문으로 합니다.
Aster: A Fake-D DEX는 원래 Medium의 ChainArgos 에 게시되었으며, 사람들은 이 글을 강조 표시하고 댓글을 달면서 계속해서 대화를 이어가고 있습니다.
