Aster是一個“去中心化”的永續合約交易所，但實際上它是中心化的，由團隊控制。這引發了關於偽去中心化永續合約交易所的廣泛討論。此外，Aster也與幾年前導致其關閉的幣安（Binance）的一些問題有幾分相似。
Aster 主要運行在BNB智能鏈上。而 BNB 智能鏈本身就有著一段不光彩的歷史，幣安曾對用戶資金行使近乎完全的獨立控制權。因此，Aster 中心化的第二個論點是，幣安此前曾利用特權凍結用戶資金，並阻止完全有效的私鑰在BNB智能鏈上運行。幣安聲稱這些措施是為了應對黑客攻擊，以保護用戶資金。好吧，也許吧，隨便吧。
當然，這意味著BNB智能鏈上的所有內容都處於幣安的掌控之下，幣安可以單方面決定某些操作是否符合用戶資金安全的最佳利益，並阻止幣安選擇的任何操作。這種說法在某種程度上是正確的，但也過於簡化。我們並非僅僅因為幣安支持 Aster 平臺、幣安控制BNB智能鏈以及BNB智能鏈包含以下代碼就斷言 Aster 是中心化的：
// 這是由於 Tendermint IAVL Merkle 證明驗證漏洞而引入的。
var NanoBlackList = []common.Address{
common.HexToAddress("0x489A8756C18C0b8B24EC2a2b9FF3D4d447F79BEc"),
common.HexToAddress("0xFd6042Df3D74ce9959922FeC559d7995F3933c55"),
// 測試賬號
common.HexToAddress("0xdb789Eb5BDb4E559beD199B8b82dED94e1d056C9"),
}
那麼，我們先來看看存放 Aster 大部分資金的 Vault 合約。這是一個可升級的代理合約，其配置方式使得團隊可以輕易地將所有資金取走。這不僅是事實，而且在平臺審計報告中也有書面記錄。報告大致內容是，在最初的設計中，一個地址就可以竊取 Vault 中的所有資金。後來，審計人員發現了這個問題，團隊承諾遷移到多重簽名機制。Aster 團隊在其網站上發佈的審計報告中也明確記錄了這一點。這足以證明其真實性。
接下來，我們將詳細介紹團隊可以用來操控平臺的各種控制手段。然後，我們將討論團隊（且僅團隊）如何利用這些控制手段來侵佔用戶資產。這一切都不需要偏離系統的預期功能。沒錯，這些行為構成盜竊，因此與團隊對平臺的既定目標不符。但是，銀行高管不會在申請表的“你為什麼想要這份銀行執照？”一欄寫上“這樣我們就可以偷錢了”。關鍵在於，所有這些“攻擊”都可以利用Aster系統中精心設計的控制機制來實現。
在有人說“但是DEX已經有了去中心化治理”之前，你需要知道，雖然未來確實有去中心化治理的計劃，但目前的情況如上所述：
所以這裡存在某種管理員，但它不是去中心化自治組織（DAO）。現在我們可以討論管理員的權限了。
首先，管理員可以暫停和恢復系統。這意味著，從總體上看，他們在提取資金時不會感到任何時間壓力。暫停按鈕使得協調、時機把握和同步都變得輕而易舉。
該團隊還能夠動態調整一系列參數，包括費用和未平倉合約限額。這意味著他們可以向用戶收取高於預期的費用，移除合約，並通過降低系統槓桿率來強制清算等，而這些操作往往是用戶無法預料的。
團隊還可以更改交易所的定價來源。那麼，我們是否可以合理地問，團隊是否經常使用此管理界面來執行此類操作？答案是肯定的。以下是一個EOA （非自動化、鏈下控制、人工操作的管理地址）持續發送配置更新的示例：
“批量更新…”調用會生成類似這樣的長串交易配置更新列表：
然後，“Execute Tp Sl or 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));
}
function setExecutionFeeUsd(uint256 executionFeeUsd) external override {
LibAccessControlEnumerable.checkRole(Constants.ADMIN_ROLE);
LibTradingConfig.setExecutionFeeUsd(executionFeeUsd);
}
…
function setMaxTpRatioForLeverage(address pairBase, MaxTpRatioForLeverage[] calldata maxTpRatios) external override {
LibAccessControlEnumerable.checkRole(Constants.PAIR_OPERATOR_ROLE);
require(pairBase != address(0) && IPairsManager(address(this)).getPairForTrading(pairBase).base != address(0), "TradingConfigFacet: 交易對不存在");
LibTradingConfig.setMaxTpRatioForLeverage(pairBase, maxTpRatios);
}
您可以看到每個函數開頭都調用了 checkRole(SOME_ROLE)。MONITOR_、ADMIN_ 和 OPERATOR_ 角色各有一個控件。這裡有一些不同的管理員角色以及一些相關的管理機制，我們這裡就不贅述了。
關鍵在於這裡存在特權管理員。沒錯，該系統可能很大程度上依賴多重簽名，因此許多控制措施需要多位執行官簽字才能進行更改。但這與上文提到的2024年9月審計報告中指出的問題完全相同。該系統的設計、構建、部署以及在實際運行中，其集中化程度與任何傳統的金融業務一樣，都需要多位經理簽字才能進行更改。
因此，就像 Hyperliquid 一樣，即使不去擔心繫統的鏈下部分在順境中是否誠實運行，團隊也可以強制系統部分將所有資金支付給鏈上指定的賬戶。
這具體如何運作呢？例如，團隊可以將定價來源重定向到團隊控制的預言機，然後確保團隊關聯的倉位能夠獲得所有資金。同樣，團隊對資金費率水平、槓桿限額以及各種清算相關參數都擁有足夠的控制權，從而能夠隨著時間的推移逐步收回存款。
聽起來是不是有點複雜，甚至有點牽強附會？你是不是忘了團隊可以輕易盜取大量用戶資產，而他們的審計人員發現了這一點，他們也承認了，並且最終還是把審計報告發布在了網站上？任何漏洞利用都比這複雜得多！這裡描述的最簡單的漏洞利用是“他們打開賬戶取走資金”，但實際情況遠比這複雜得多。而且，該團隊對平臺旗下的穩定幣 Aster USDF 也擁有類似的控制權，可以 完全凍結和扣押。沒錯， 另一份審計報告也指出了其中一些問題。
代碼呢？聞起來像BNB信標鏈
我們在上面詳細引用了代碼。但這些代碼片段主要來自區塊鏈瀏覽器。區塊鏈瀏覽器並非存放代碼的最佳場所——查看歷史記錄很困難——而且區塊鏈瀏覽器當然也無法託管非智能合約代碼。Aster 還有其他組件，所以……這是怎麼回事？
官方鏈接並未指向代碼：
就連審計結果也指向了一些隨機地點：
github.com/astherus-contract 倉庫裡有一些代碼，但不是最新的：
還有一個github.com/asterdexcom倉庫，其中包含一些智能合約代碼和較新的活動，但除此之外沒有太多其他內容：
如果你去查看其中一些倉庫的提交歷史，就會發現這些是開發倉庫，團隊成員全部都是像 alex-degen、cody-z 和 mark-c 這樣的化名。所以，這看起來又是一場荒謬的鬧劇：
那是現在已經關閉的BNB信標鏈，團隊在公開否認很久之後才承認該系統是閉源的。我們和 V 以及 zoro 之間有過很多公開的爭論，他們似乎也多次承認過這一點。
當時，大概是2022年末/2023年初，他們發佈了新的文檔和代碼，實際上承認了整個項目都是騙局。最終，一切都被關閉了。哦，對了，當時還有大量沒有抵押品的資產，這也是導致BUSD關閉的原因之一。
如果 cody-z 真的是 zorobytes，那大概不會有人感到震驚。畢竟， BNB Beacon Chain 的最初目標之一就是提供一個高吞吐量的去中心化交易平臺。就像 Aster 那樣。真的。這是 2022 年年中的情況：
在我們提出質疑後，團隊公開承認編寫了新的代碼和文檔。他們公開且書面承認，這是為了回應我們關於他們長期以來聲稱的開放系統的質疑：
當時的一系列問題，嗯，都被留待以後解決：
BNB信標鏈並沒有履行承諾，也沒有解決所有問題，而是在數據完全澄清之前就被關閉了。哦，對了，當時他們還承諾過未來會實現去中心化：
BNB Beacon Chain 的去中心化交易所（DEX）曾模仿過當時許多流行的 DeFi 產品。而它所宣稱的去中心化，看起來確實很像很多東西（提示：包括 Aster）。但它始終是一箇中心化的、部分閉源的、功能和行為怪異的系統。簡而言之：它是個騙局， BUSD被紐約州金融服務部（NYDFS）大幅削減，最終整個BNB Beacon DEX 項目被關閉。現在看來，Aster 似乎與這堆爛攤子有很多相似之處。
所以？
祝你們這次能順利把項目命名為 Aster，並且模仿 Hyperliquid，而不是像上次那樣模仿你們都非常喜歡的 2021/2022 年的 DEX。
此前， BNB Chain 團隊錯誤地將我們的問題描述為斷言，並且通常很難澄清一切都沒問題：
“你的程序運行後出現了 X 問題。你能解釋一下嗎？”這是一個事實陳述，後面跟著一個問題。請把以上內容看作是我們的問題。就像上次你發佈了新的代碼和文檔，然後在你的回答中附上鍊接，暗示我們沒有仔細閱讀，而實際上你的代碼有問題……請允許我們公開討論此事並附上時間戳。
正如我們多次解釋的那樣：本博客專門預測過去發生的事情。
Aster：一款偽 DEX最初發表在 Medium 上的ChainArgos 網站上，人們通過突出顯示和回應這篇文章繼續進行討論。
