DoubleZero는 중앙집권적이며 SEC를 속였다: N편 2부

이 기사는 기계로 번역되었습니다

원문 표시

이 시리즈의 1부 에서는 DoubleZero의 Sentinel 및 Passport 프로그램을 살펴보고 DoubleZero 재단이 이러한 프로그램을 통해 SEC의 면책 조항과 상충될 수 있는 방식으로 시스템에 대한 중앙 집중식 통제를 유지하는 방식을 살펴보았습니다.

2부에서는 보상 분배 과정을 살펴보고, 독점적인 중앙 서비스 제공업체가 있는 경우에도 어떻게 작동하는지 보여줍니다. 이 분석은 DoubleZero가 SEC에 제출한 설명이 실제 시스템 구조를 정확하게 반영하지 않을 수 있음을 시사합니다. 이는 단일 중앙 통제 지점에 관한 문제가 아닙니다. 2부에서는 중앙 집중식 권한을 중심으로 작동하는 것으로 보이는 두 번째 하위 시스템을 다룹니다.

이러한 차이에 대해서는 몇 가지 가능한 설명이 있습니다.

DoubleZero 팀은 시스템 아키텍처를 법률 고문에게 완전히 전달하지 않았을 수도 있습니다.
미국 증권거래위원회(SEC)에 제출된 서류에 제품 작동 방식에 관한 중요한 사실이 누락되었을 수 있습니다.
해당 팀은 면책 조항의 적용 가능성을 정확하게 반영하지 않는 방식으로 면책 조항을 인용하고 있을 수 있습니다.
SEC 검토 과정에서 의사소통 오류가 있었을 수 있습니다.

본 조사 결과를 검토해 주시길 바라며, 향후 추가적인 연구 결과를 기다리겠습니다.

2Z 리워드 분배 방식

DoubleZero의 토큰 보상 분배 방식은 복잡합니다. 하지만 이 분석에서는 간략한 개요만으로도 충분합니다. 1부와 마찬가지로 아키텍처 다이어그램 부터 시작하겠습니다.

여기에는 몇 가지 요소가 관련되어 있습니다.

원격 측정 : 기여자 활동을 추적합니다.
보상 계산 및 확정 : 사용량 데이터를 보상 금액으로 변환합니다.
기여자 보상 분배 : 보상을 분배합니다.

이러한 구성 요소는 오프체인 "DZ 리소스 기여자"(왼쪽 상단 파란색 부분)와 솔라나(Solana) (Solana)의 스마트 계약(왼쪽 하단 흰색 부분)을 조합하여 관리됩니다. 이 구성은 1부와 유사하며, 앞으로 설명하겠지만 이러한 시스템 구성 요소는 탈중앙화에 대한 의문을 제기합니다.

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 환경 변수가 설정되지 않았습니다")?;

 영역을 다음과 같이 설정하세요
 env::var("VALIDATOR_DEBT_AWS_REGION").unwrap_or_else(|_| "us-east-1".to_string());

이 코드는 "검증자 부채" 하위 시스템의 일부이며 작동하려면 AWS 구성 자격 증명이 필요합니다. 이 코드는 DoubleZero 재단이 아닌 Malbec Labs에서 관리하는 것으로 보입니다. 어느 쪽에서 자격 증명을 가지고 있든, 이 코드가 존재한다는 사실 자체가 면책 조치 적용 가능성에 대한 의문을 제기합니다.

이론적으로는 누군가가 AWS 종속성 없이 이 코드를 다시 작성하는 것이 가능할 수도 있지만, 이 코드 자체를 제외하고는 소프트웨어의 예상 동작에 대한 사양이 없습니다. 이러한 상황은 역공학을 통해 이해해야 하는 독점 파일 형식과 유사합니다.

또는 제3자가 자신의 AWS 키를 사용하여 이 코드를 실행하려고 시도할 수도 있습니다. 그러나 이를 위해서는 DZ 리소스 기여자 섹션의 여러 부분을 운영해야 하며 아래에서 논의하는 접근 제어 문제를 해결해야 합니다. 코드를 여러 번 복사하고 실행할 수 있다는 사실 자체가 시스템을 본질적으로 탈중앙화하는 것은 아닙니다.

프로토콜 문서에 관한 질문

이러한 구현 방식은 DoubleZero가 SEC의 면책 조항 범위 내에서 운영되고 있는지에 대한 의문을 제기합니다. VALIDATOR_DEBT_AWS_SECRET_ACCESS_KEY를 참조하는, 명목상 분산형 및 비허가형(Permissionless) 시스템의 코드를 공개한 것은 면밀한 조사가 필요합니다.

이 소프트웨어 아키텍처와 관련된 문제는 이것만이 아닙니다. Malbec Labs는 이것이 단지 프로토콜의 자체 구현일 뿐이며 다른 업체들도 다르게 구현할 수 있으므로 중앙 집중화에 해당하지 않는다고 주장할 수 있습니다. 우리는 위에서 이러한 유형의 주장에 대해 논의했습니다. 이는 Malbec Labs에게 두 가지 질문을 제기합니다.

이 키들을 공개적으로 게시해 주시겠습니까?
프로토콜 문서는 어디에 있습니까? 참조된 사양은 찾지 못했고, 기존 시스템만 발견했습니다.

시스템 구현과 프로토콜 정의 자체를 혼동하면 진정한 의미의 탈중앙화가 가능한지에 대한 의문이 제기됩니다. 소프트웨어 엔지니어링에서 "시스템"과 "프로토콜"이라는 용어는 서로 다른 의미를 가지며, 이를 혼동해서는 안 됩니다.

검증자 부채 및 기여자 보상

텔레메트리 인프라는 기여자에게 지급될 보상을 계산하기 위해 구축되었습니다. 이 작업은 검증자 부채(validator-debt)라는 오프체인 서브시스템에서 수행됩니다. 검증자 부채 시스템은 위에서 설명한 AWS 래퍼 코드를 사용하여 검증자 정보를 AWS S3 버킷에 기록하고, 이 정보는 나중에 보상 계산에 사용됩니다. 별도의 기여자 보상(contributor-rewards) 오프체인 서브시스템은 이 데이터를 읽어 보상을 계산합니다.

이 두 시스템은 위에서 설명한 AWS 개인 키를 통해 통신합니다. 시스템은 내부 통신에 AWS 개인 자격 증명을 사용합니다. 이는 블록체인을 매개로 하는 것이 아니라, 개방형 프로토콜이 아닌 기존 기업 시스템과 유사하게 두 소프트웨어 구성 요소가 비공개 내부 채널을 통해 통신하는 것을 나타냅니다.

또한, DoubleZero는 공개 참여가 제한된 다양한 목적으로 별도의 Solana 포크 체인을 운영하고 있습니다. 내부 원격 측정 통신은 해당 체인보다 접근성이 훨씬 떨어집니다. 검증자 부채와 기여자 보상이라는 두 가지 구성 요소는 DoubleZero가 SEC에 요청한 핵심 보상 계산에 사용됩니다. 그러나 이러한 구성 요소는 오프체인에 존재하며 작동을 위해 개인 자격 증명이 필요하므로 DoubleZero가 SEC에 보낸 서한과 모순되는 것으로 보입니다.

이러한 시스템에서 샤플리 계산 코드와 다양한 계측 및 통계 자료를 찾을 수 있고, 1부에서 보여준 것처럼 머클 루트를 온체인에 게시하는 것을 포함한 수학적 연산을 수행할 수 있지만, 시스템은 여전히 개인 키로 제어됩니다. 암호화 기술은 서로 다른 소프트웨어 구성 요소에서 수행되는 계산 결과가 일치하도록 보장합니다.

하지만 이 모든 소프트웨어는 동일한 조직에서 개발했으며, 해당 조직이 통제하는 비공개 채널을 통해 통신합니다. 만약 해당 조직이 계산 방식이나 검증 방법을 수정하고자 한다면, 암호화 기술은 그러한 변경에 대해 제한적인 보호만을 제공합니다. 소프트웨어가 완전히 무제한적인 것은 아니지만, 앞으로 살펴보겠지만, 분산형 프로토콜보다는 기존 기업 시스템과 더 유사한 방식으로 구성되어 있습니다.

보상 분배

솔라나(Solana) 에는 " 보상 회계 담당자 "를 포함하는 수익 분배 스마트 계약이 존재합니다. 이는 보상 분배 프로세스의 온체인 구성 요소, 즉 DoubleZero가 증권거래위원회(SEC)에 DePIN 제품의 일부로 분류해 줄 것을 요청했던 코드이며, 해당 제품은 증권으로 분류되지 않습니다.

온체인 구성 요소는 중앙 기관이 제어하는 오프체인 구성 요소에 종속된 시스템으로 작동하는 것으로 보입니다. 지정된 소스에서만 입력을 허용하며, 비허가형(Permissionless) 또는 개방형 접근 방식이 아니라 블록체인 기술을 활용하는 통제된 시스템입니다.

오프체인 기여자 보상 프로그램에서 다음 코드를 발견했습니다.

 매치 try_build_instruction(
 &ID,
 FinalizeDistributionDebtAccounts::new(&self.pubkey(), dz_epoch, &self.pubkey()),
 &수익분배지시데이터::분배부채 확정,
 ) {
 확인(지시사항) => {
 let recent_blockhash = solana_rpc_client.get_latest_blockhash().await?;
 메시지 = 메시지::try_compile(
 &self.signer.pubkey(),
 &[지침],
 &[],
 최근 블록해시,
 )
 .unwrap();

 let finalized_transaction =
 VersionedTransaction::try_new(VersionedMessage::V0(message), &[&self.signer])
 .unwrap();
 확인(거래 완료)
 }
 오류(err) => 오류(anyhow!(
 "최종 배포 명령을 빌드하는 데 실패했습니다: {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()?;

파트 1에서와 마찬가지로, 이 기능은 지정된 "부채 회계 담당자"가 호출할 때만 작동합니다. 여권 프로그램 및 센티널과 유사하게 블록체인이 존재하지만, 해당 기능은 승인된 당사자가 호출할 때만 실행됩니다.

만약 이 모든 과정이 온체인 내에서 순수하게 탈중앙화된 시스템 내부에서만 이루어진다면 논쟁의 여지가 있을 수 있습니다. 하지만 저희는 특권 접근 권한을 가진 오프체인 구성 요소(doublezero-offchain이라는 저장소에 있음)를 사용하고 있습니다. 머클 루트와 다양한 형태의 암호화 기술이 사용되고 있기 때문에, 개발팀은 참여자들이 대응할 수 없는 상황에서 대체 원격 측정 데이터를 제출하고 보상 분배 방식을 변경할 가능성이 있습니다.

블록체인이 존재하고 보상 분배의 특정 측면을 제한하여 기록 보관의 Persistence 과 일관성을 보장하는 것은 사실이지만, DoubleZero 측의 서한에는 다음과 같이 명시되어 있습니다.

프로토콜 토큰 경제(예: 새로 발행되는 2Z 토큰)를 제어하는 스마트 계약 세트가 솔라나(Solana) 블록체인에 배포되었습니다. 리소스 제공자는 이러한 스마트 계약을 호출하여 실행하는 역할을 하지만, 경제 자체를 제어하거나 스마트 계약을 업그레이드할 권한은 없습니다. 출시 시점에는 재단이 이러한 스마트 계약의 업그레이드 권한을 보유할 것으로 예상되지만, 재단은 시간이 지남에 따라 제어 권한을 분산화할 계획입니다.

재단은 이 프로세스를 수정할 수 있음을 인정합니다. 재단은 원하는 토큰 배포 방식을 확정하기 위해 이 시스템 내의 검증 규칙을 변경할 수 있습니다.

또한, 이러한 기능을 수행하기 위해 AWS 개인 키를 사용하는 오프체인 코드도 보유하고 있습니다.

이는 그러한 아키텍처가 DoubleZero가 받았던 증권법상 적용 대상이 되어야 하는지에 대한 의문을 제기합니다.

예상 반응

한 가지 가능성 있는 반응은 우리가 솔라나(Solana) 작동 방식을 오해하고 있다는 것입니다. 여기서와 1부에서 모두 언급된 authorized_use 검사는 표준적인 우수 설계 관행을 따른다는 주장이 제기될 수 있습니다. 솔라나(Solana) 에서 스마트 계약이 실행되고 솔라나(Solana) 탈중앙화되어 있으므로 스마트 계약 또한 탈중앙화되어야 한다는 주장이 나올 수도 있습니다. 그러나 그들 스스로도 시스템에 대한 통제권을 무기한으로 유지할 것이라고 명시한 서한을 보냈습니다.

또 다른 가능성 있는 주장은 검증자 보상 프로세스가 암호화를 사용하고 머클 루트를 공개하기 때문에, 이러한 프로그램들이 특권 접근 권한을 가지고 있더라도 그 접근 권한으로는 정확한 금액만 지급할 수 있다는 것입니다.

그러나 원격 측정 데이터는 오프체인 프로세스를 통해 수집됩니다. (1부에서 언급된 바와 같이 시스템 참여 접근 권한을 관리하는) 재단과 Malbec Labs가 오프체인 원격 측정 인프라 전체를 운영하기 때문에, 이들은 서로 다른 결과를 관찰하고 다른 원격 측정 데이터에 대해 "올바른" 보상을 계산하여 배분할 가능성이 있습니다. 명확한 분쟁 해결 절차나 시스템이 제대로 작동하지 않는다고 생각하는 참여자를 위한 피드백 메커니즘은 존재하지 않습니다.

문서에 따르면 RPC 노드 실행은 권한이 부여되어 있어 독립적인 인터페이스 설정이 불가능합니다. 또한 문서에는 참여자가 시스템에서 자유롭게 나가는 것조차 허용하지 않으며, " 중요: 기존 운영 링크(Chainlink) 삭제하기 전에 DZF 및/또는 Malbec Labs와 상의하십시오 ."라고 명시되어 있습니다.

해당 팀은 우리가 이것을 시스템으로 잘못 인식하고 있다고 주장할 수도 있습니다. 실제로는 프로토콜입니다. 프로토콜은 통신 방식, 즉 적절하게 형식화된 메시지에 할당된 메시지 형식과 의미의 모음입니다. "단순한 프로토콜"이 되려면 두 가지가 필요합니다. 첫째, "프로토콜"이라는 요건을 충족하는 프로토콜 명세가 있어야 합니다. DoubleZero는 그러한 명세를 공개하지 않은 것으로 보입니다. 둘째, "단순한" 요건을 충족하려면 프로토콜 명세만 존재해야 합니다.

참조 구현이 포함된 프로토콜 명세는 허용됩니다. 참조 구현에 중앙 집중식 제어 지점이 포함되어 있더라도 특정 상황에서는 허용될 수 있습니다. 예를 들어 OAuth는 중앙 기관이 많이 관여하는 복잡한 프로토콜 집합입니다 . 그러나 하나의 주체가 여러 중앙 기관을 제어하는 기존 배포 환경에서는 더 이상 "단순한 프로토콜"이 아닙니다.

논의

본 분석은 명확한 증거를 제시하면서도 최대한 이해하기 쉽게 구성하고자 노력했습니다. 1부에서 논의한 바와 같이, 프로젝트의 면책 요청 내용이 소프트웨어 구현 세부 사항과 일치하는지 여부를 확인하는 것은 SEC의 책임이 아님을 인정합니다.

하지만 DoubleZero가 블록체인 프로젝트라고 주장하는 것은 면밀한 검토가 필요합니다. Git의 git-sizer 도구를 사용하여 기본적인 분석을 해보면 흥미로운 비율들이 드러납니다. 재단 소유의 세 가지 저장소 중, doublezero-solana 저장소(모든 온체인 구성 요소 포함)는 123개의 파일로 약 1.23MiB 크기입니다. doublezero-offchain 저장소는 225개의 파일로 24.5MiB입니다. 시스템에서 사용하는 두 번째 프라이빗 블록체인인 doublezero-ledger 코드는 3,230개의 파일로 67MiB입니다. 또한, 네트워킹을 담당하는 Malbec Labs의 doublezero 저장소는 1,270개의 파일로 30.5MiB입니다.

코드 길이가 중요도와 완벽하게 상관관계가 있는 것은 아니지만, 이 시스템의 대부분은 퍼블릭 블록체인 외부에 존재합니다. 퍼블릭 솔라나(Solana) 블록체인에 있는 구성 요소들은 제휴 기관에서 구축한 지정된 오프체인 소프트웨어와만 연동되도록 구성되어 있습니다.

권장 사항

SEC는 시스템이 보유하지 않은 기능을 근거로 한 면책 조치가 무엇인지 명확히 해야 합니다.

실제 시스템에는 적용할 수 없습니다.
위원회의 자원 낭비
법 집행 과정에서 가중 요인이 될 수 있음

면책 조치가 구제 요청서에 명시된 특성을 가진 프로젝트에만 적용된다는 기본적인 성명을 발표하지 않으면 시장에 불확실성이 초래됩니다.

그러한 무조치 구제 조치를 칭찬하는 성명을 발표한 위원들은 무조치 구제 절차의 공정성을 유지하기 위해 추가적인 설명이 필요한지 고려해야 합니다.

DoubleZero는 중앙 집중화되어 있으며 SEC를 속였다: N의 2부는 원래 미디엄(Medium) 의 ChainArgos 에 게시되었으며, 사람들은 이 기사를 강조 표시하고 댓글을 달면서 계속해서 대화를 이어가고 있습니다.

Medium

면책조항: 상기 내용은 작자의 개인적인 의견입니다. 따라서 이는 Followin의 입장과 무관하며 Followin과 관련된 어떠한 투자 제안도 구성하지 않습니다.

라이크

즐겨찾기에 추가

코멘트