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相关的任何投资建议。
喜欢
收藏
评论
相关推荐