DoubleZero 組織結構集中，誤導了美國證券交易委員會：第二部分（共 N 部分）

avatar
Stories by DataFinnovation on Medium
本文為機器翻譯
展示原文

在本系列的第一部分中，我們研究了 DoubleZero 的 Sentinel 和 Passport 項目，以及 DoubleZero 基金會如何通過這些項目對系統進行集中控制，而這種控制方式可能與其獲得美國證券交易委員會的無異議豁免不符。

在第二部分，我們將考察獎勵分配流程，並展示其如何在壟斷性中央服務提供商的運作下運行。分析表明，DoubleZero 向美國證券交易委員會 (SEC) 提交的陳述可能並未準確反映實際的系統架構。這並非單一中央控制點的問題。第二部分將探討第二個子系統，該子系統似乎圍繞著集中式權力運作。

對於這種差異，可能有以下幾種解釋：

  • DoubleZero團隊可能沒有向其法律顧問充分傳達系統的架構。
  • 提交給美國證券交易委員會的文件可能遺漏了有關該產品運行的重要事實。
  • 該團隊可能以一種未能準確反映不採取行動救濟措施適用性的方式援引了該救濟措施。
  • 美國證券交易委員會的審查過程中可能存在溝通不暢的情況。

我們提出這些發現供大家參考，並期待後續進展。

2Z獎勵分配計劃

DoubleZero 的代幣獎勵分配方案較為複雜。不過，本文只需提供一個簡化的概述即可進行分析。與第一部分一樣，我們首先來看他們的架構圖。

這裡涉及幾個重要因素：

  • 遙測數據：跟蹤貢獻者活動
  • 獎勵計算與最終確定：將使用數據轉換為獎勵金額
  • 貢獻者獎勵分配：分配獎勵

這些組件通過鏈下“DZ資源貢獻者”（左上角藍色部分）和Solana上的智能合約（左下角白色部分）進行管理。這種設置與第一部分類似，正如我們將要展示的，這些系統組件引發了關於去中心化的問題。

AWS 私鑰

一個重要的集中化問題涉及AWS憑證。問題不在於系統運行在AWS上，而在於部分代碼需要AWS訪問密鑰ID和秘密訪問密鑰對才能運行。沒有這些密鑰，代碼就無法運行。因此，誰控制了這些密鑰，誰就控制了對軟件的訪問權限。

在doublezero-offchain代碼中，我們發現了以下配置：

 impl S3Config {
 async fn new() -> Result<Self> {
 讓桶 = env::var("VALIDATOR_DEBT_S3_BUCKET")
 .unwrap_or_else(|_| "malbeclabs-data-metrics-dev".to_string());

 let max_consecutive_failures = env::var("VALIDATOR_DEBT_S3_MAX_CONSECUTIVE_FAILURES")
 。好的（）
 .and_then(|v| v.parse().ok())
 .unwrap_or(12);

 // 從環境變量加載 AWS 憑證
let access_key_id = env::var("VALIDATOR_DEBT_AWS_ACCESS_KEY_ID")
 .context("未設置 VALIDATOR_DEBT_AWS_ACCESS_KEY_ID 環境變量")?;

 let secret_access_key = env::var("VALIDATOR_DEBT_AWS_SECRET_ACCESS_KEY")
 .context("未設置 VALIDATOR_DEBT_AWS_SECRET_ACCESS_KEY 環境變量")?;

令 region =
 env::var("VALIDATOR_DEBT_AWS_REGION").unwrap_or_else(|_| "us-east-1".to_string());

這段代碼是“驗證器債務”子系統的一部分，需要AWS配置憑證才能運行。代碼表明，該子系統由Malbec Labs而非DoubleZero基金會控制。無論密鑰由哪一方持有，它們的存在都引發了關於不採取行動豁免條款適用性的疑問。

理論上，或許有人可以重寫這段代碼而不依賴 AWS，但除了代碼本身之外，並沒有關於軟件預期行為的規範。這種情況類似於專有文件格式，理解這些格式需要進行逆向工程。

或者，第三方也可以嘗試使用自己的 AWS 密鑰運行此代碼。但是，這需要操作 DZ 資源貢獻者部分的多個組件，並解決下文討論的訪問控制問題。能夠多次複製和運行代碼本身並不能使系統實現去中心化。

關於協議文件的問題

這種實現方式引發了人們對 DoubleZero 是否在其獲得美國證券交易委員會 (SEC) 不採取行動豁免的範圍內運營的質疑。發佈一個據稱是去中心化且無需許可的系統的代碼，卻引用了 VALIDATOR_DEBT_AWS_SECRET_ACCESS_KEY，這理應受到審查。

這並非該軟件架構唯一的隱患。Malbec Labs可能會辯稱，這並不構成中心化，因為這僅僅是他們對協議的一種實現，其他人也可以採用不同的實現方式。我們已在前面討論過這類說法。這引出了Malbec Labs需要回答的兩個問題：

  1. 您願意公開這些密鑰嗎？
  2. 協議文檔在哪裡？我們沒有找到任何相關的規範，只有一個現有的系統。

當系統的實現與協議定義本身混淆時，就會引發關於真正意義上的去中心化是否可能實現的質疑。在軟件工程中，“系統”和“協議”這兩個術語有著截然不同的含義，不應混為一談。

驗證者債務與貢獻者獎勵

遙測基礎設施用於計算支付​​給貢獻者的獎勵。這項工作在一個名為 validator-debt 的鏈下子系統中完成。validator-debt 系統使用上述 AWS 封裝代碼將驗證者信息寫入 AWS S3 存儲桶，以便後續用於獎勵計算。另一個獨立的 contributor-rewards 鏈下子系統讀取這些數據以執行獎勵計算。

這兩個系統通過上文討論的AWS私鑰進行通信。該系統使用私有AWS憑證進行內部通信。這並非基於區塊鏈，而是兩個軟件組件通過私有內部通道進行通信，類似於傳統的企業系統，而非開放協議。

此外，DoubleZero 還運營著一條獨立的 Solana 分叉鏈，用於各種用途，公眾參與度有限。其內部遙測通信的訪問權限甚至比這條鏈還要低。驗證者債務和貢獻者獎勵這兩個組件負責計算 DoubleZero 向美國證券交易委員會 (SEC) 提交的申請中涉及的核心獎勵。然而，這些組件位於鏈下，並且依賴於私有憑證才能運行，這似乎與 DoubleZero 致 SEC 的信函內容不符。

雖然我們可以在這些系統中找到 Shapley 計算代碼以及各種工具和統計信息，而且它們確實執行數學運算（包括如第一部分所示在鏈上發佈默克爾根），但系統仍然由私鑰控制。密碼學確保不同軟件組件執行的計算結果一致。

然而，所有這些軟件都由同一組織編寫，並通過該組織控制的私有通道進行通信。如果該組織希望修改計算或驗證方法，加密技術只能提供有限的保護來抵禦此類更改。雖然該軟件並非完全不受限制（我們將在下文中看到），但它的配置方式更類似於傳統的企業系統，而非去中心化協議。

獎勵分配

Solana上存在一個收益分配智能合約，其中包含一個“ 獎勵會計”。這是獎勵分配流程的鏈上組件——DoubleZero 請求美國證券交易委員會將其歸類為 DePIN 產品的一部分，該產品不符合證券的定義。

鏈上組件似乎作為鏈下組件的依賴系統運行，並由中心化方控制。它只接受來自指定來源的輸入。它並非無需許可或開放訪問的系統，而是一個利用區塊鏈技術的受控系統。

在鏈下貢獻者獎勵計劃中，我們發現了以下代碼：

匹配 try_build_instruction(
 ＆ID，
 FinalizeDistributionDebtAccounts::new(&self.pubkey(), dz_epoch, &self.pubkey()),
 &收入分配指令數據::最終確定分配債務,
 ) {
好的（指令）=>{
 let recent_blockhash = solana_rpc_client.get_latest_blockhash().await?;
 let message = Message::try_compile(
 &self.signer.pubkey(),
 ＆[操作說明]，
 &[]，
 recent_blockhash，
 ）
 .unwrap();

 let finalized_transaction =
 VersionedTransaction::try_new(VersionedMessage::V0(message), &[&self.signer])
 .unwrap();
好的（最終交易）
 }
錯誤(錯誤) => 錯誤(無論如何！(
 “構建最終分發指令失敗：{err:?}”
 )),
 }

此函數會調用Solana智能合約來執行 RevenueDistributionInstructionData::FinalizeDistributionDebt 函數。這是最終獎勵分配流程中的眾多步驟之一。為簡潔起見，此處不再贅述所有步驟。

在Solana端， 我們可以看到獎勵最終確認消息是如何處理的：

 fn try_finalize_distribution_debt(accounts: &[AccountInfo]) -> ProgramResult {
 msg!("最終確定分配債務");

 // 此指令需要以下賬戶：
 // - 0：程序配置。
 // - 1：債務會計師。
 // - 2：分佈。
 // - 3：付款人（重新分配進口的資金提供方）。
 // - 4：系統程序。
 let mut accounts_iter = accounts.iter().enumerate();

 // 賬戶 0 必須是程序配置。
 // 賬戶 1 必須是債務會計。
 //
 // 此調用確保債務會計師是簽字人，並且是同一人。
 // 債務會計師編碼在程序配置中。
 let authorized_use =
 VerifiedProgramAuthority::try_next_accounts(&mut accounts_iter, Authority::DebtAccountant)?;

確保程序未暫停。
 authorized_use.program_config.try_require_unpaused()?;

與第一部分一樣，此功能僅在指定的“債務會計”調用時才會運行。與護照計劃和哨兵系統類似，這裡也存在區塊鏈，但這些功能僅在獲得授權方調用時才會執行。

如果這完全是鏈上操作，並且是純粹去中心化系統的內部操作，或許還有討論的空間。然而，我們有鏈下組件（位於名為 doublezero-offchain 的代碼庫中），它們擁有特權訪問權限。雖然其中涉及默克爾根和各種加密技術，但團隊有可能提交替代遙測數據並修改獎勵分配，而參與者卻無能為力。

雖然區塊鏈技術確實存在，並且限制了獎勵分配的某些方面，以確保記錄的Persistence和一致性，但 DoubleZero 自己的信函中指出：

一套控制協議代幣經濟（例如，鑄造新發行的 2Z）的智能合約已部署到Solana區塊鏈上。資源提供者負責調用這些智能合約以執行它們，但他們對經濟運作沒有任何控制權，也無法升級這些智能合約。預計在項目啟動時，這些智能合約的升級權限將由基金會控制，但基金會計劃隨著時間的推移逐步分散控制權。

基金會承認其可以修改此流程。它可以更改此係統中的驗證規則，以確認其選擇的任何代幣分發方案。

此外，我們還有使用 AWS 私鑰的鏈下代碼來執行這些功能。

這就引發了一個問題：這種架構是否應該符合DoubleZero所受到的證券法待遇。

預期反應

一種可能的解釋是，我們誤解了Solana 的運作方式。有人可能會認為，無論是此處還是第一部分中提到的 authorized_use 檢查，都代表了標準的良好設計實踐。由此可能會有人聲稱，由於智能合約運行在Solana上，而Solana是去中心化的，因此智能合約也必然是去中心化的。然而，Solana 自己的信函也承認，他們希望無限期地保持對系統的控制權。

另一個可能的論點是，由於驗證者獎勵過程使用密碼學並公佈默克爾根，即使這些程序擁有特權訪問權限，該訪問權限也只允許支付正確的金額。

然而，遙測數據是通過鏈下進程收集的。由於基金會（根據第一部分所述，該基金會控制著參與系統的權限）和 Malbec Labs 共同運營著所有鏈下遙測基礎設施，他們可能會觀察到不同的結果，並根據不同的遙測數據計算出“正確”的獎勵，然後進行分配。目前沒有明顯的爭議解決機制，也沒有任何反饋機制供認為系統運行不當的參與者使用。

根據相關文檔，運行 RPC 節點需要獲得許可，這阻止了獨立接口的建立。文檔甚至不允許參與者自由退出系統，其中指出：“重要提示：刪除現有生產鏈接前，請務必與 DZF 和/或 Malbec Labs 進行溝通。”

該團隊可能還會辯稱，我們錯誤地將其視為一個系統，而它實際上是一種協議。協議是一種通信方法——一組消息格式以及分配給格式正確的消息的含義。要“僅僅是一個協議”，需要滿足兩個條件：首先，需要一個協議規範來滿足“協議”的要求。DoubleZero 似乎並未發佈這樣的規範。其次，只有協議規範才能滿足“僅僅是”的要求。

帶有參考實現的協議規範是可以接受的。如果參考實現包含集中式控制點，在某些情況下也可以接受。例如，OAuth是一套複雜的協議集，其中許多協議都涉及中心化機構。然而，當現有部署中一個實體控制多箇中心化機構時，它就不再僅僅是“一個協議”了。

討論

我們力求在提供清晰證據的同時，使這份分析儘可能易於理解。正如第一部分所述，我們承認，美國證券交易委員會（SEC）沒有責任核實項目的不採取行動豁免申請是否與其軟件實現細節相符。

然而，DoubleZero 自稱是一個區塊鏈項目，這一點值得商榷。使用 Git 的git-sizer工具進行基本分析，可以發現一些有趣的比例。在基金會擁有的三個代碼倉庫中：doublezero-solana 倉庫（包含所有鏈上組件）有 123 個文件，大小約為 1.23 MiB；doublezero-offchain 倉庫有 225 個文件，大小為 24.5 MiB；doublezero-ledger 代碼（用於該系統使用的第二條私有區塊鏈）有 3,230 個文件，大小為 67 MiB；此外，Malbec Labs 的 doublezero 倉庫（負責網絡部分）有 1,270 個文件，大小為 30.5 MiB。

雖然代碼長度與重要性並非完全相關，但該系統的絕大部分代碼都存在於公共區塊鏈之外。我們知道，位於公共Solana區塊鏈上的組件都配置為僅與關聯實體構建的指定鏈下軟件協同工作。

建議

美國證券交易委員會應澄清，基於系統並不具備的功能而給予的不採取行動的豁免是：

  1. 不適用於實際系統
  2. 這是對委員會資源的浪費。
  3. 在執法行動中，這可能構成加重處罰的因素。

未能發佈一份基本聲明，重申不採取行動的救濟措施僅適用於救濟申請中描述具有相應特徵的項目，這會給市場帶來不確定性。

發表聲明稱讚這種不採取行動的救濟措施的委員們應該考慮是否有必要進行澄清，以維護不採取行動救濟程序的完整性。

DoubleZero 是中心化的，並且誤導了美國證券交易委員會：N 的第二部分最初發表在 Medium 上的ChainArgos上，人們正在那裡通過突出顯示和回應這篇文章來繼續討論。

Medium
免責聲明：以上內容僅為作者觀點，不代表Followin的任何立場，不構成與Followin相關的任何投資建議。
喜歡
收藏
評論
相關推薦