Trong Phần 1 của loạt bài này, chúng ta đã xem xét các chương trình Sentinel và Passport của DoubleZero và cách thức mà Quỹ DoubleZero, thông qua các chương trình đó, duy trì quyền kiểm soát tập trung đối với hệ thống theo những cách có thể không phù hợp với việc được SEC miễn trừ trách nhiệm .
Trong Phần 2, chúng ta sẽ xem xét quy trình phân phối phần thưởng và chứng minh cách thức hoạt động của nó với một nhà cung cấp dịch vụ trung tâm độc quyền. Phân tích này cho thấy rằng những tuyên bố của DoubleZero với SEC có thể không phản ánh chính xác kiến trúc hệ thống thực tế. Vấn đề không chỉ nằm ở một điểm kiểm soát trung tâm duy nhất. Phần 2 đề cập đến một hệ thống con thứ hai dường như xoay quanh quyền lực tập trung.
Có một số lời giải thích khả thi cho sự khác biệt này:
- Có thể nhóm DoubleZero đã không truyền đạt đầy đủ kiến trúc hệ thống cho cố vấn pháp lý của họ.
- Hồ sơ nộp cho SEC có thể đã bỏ sót những thông tin quan trọng về hoạt động của sản phẩm.
- Nhóm này có thể đang viện dẫn điều khoản miễn trừ trách nhiệm theo cách không phản ánh chính xác tính áp dụng của điều khoản đó.
- Có thể đã xảy ra sự hiểu lầm trong quá trình xem xét của SEC.
Chúng tôi trình bày những phát hiện này để xem xét và chờ đợi những diễn biến tiếp theo.
Chương trình phân phối phần thưởng 2Z
Sơ đồ phân phối phần thưởng Token của DoubleZero khá phức tạp. Tuy nhiên, một cái nhìn tổng quan đơn giản sẽ đủ cho phân tích này. Cũng như ở Phần 1, chúng ta bắt đầu với sơ đồ kiến trúc của họ.
Có một số thành phần liên quan ở đây:
- Telemetry : theo dõi hoạt động của người đóng góp
- Tính toán và hoàn tất phần thưởng : chuyển đổi dữ liệu sử dụng thành số tiền thưởng.
- Phân phối phần thưởng cho người đóng góp : phân phối phần thưởng
Các thành phần này được quản lý thông qua sự kết hợp giữa “Những người đóng góp tài nguyên DZ” ngoài chuỗi (phần màu xanh lam phía trên bên trái) và các hợp đồng thông minh trên Solana (phần màu trắng phía dưới bên trái). Cấu hình này tương tự như Phần 1, và như chúng ta sẽ chứng minh, các thành phần hệ thống này đặt ra những câu hỏi về tính phi tập trung.
Khóa riêng tư AWS
Một mối lo ngại đáng kể về sự tập trung hóa liên quan đến thông tin xác thực AWS. Vấn đề không phải là hệ thống chạy trên AWS, mà là một số phần của mã nguồn yêu cầu ID khóa truy cập AWS và cặp khóa bí mật để hoạt động. Nếu không có các khóa bí mật này, mã nguồn không thể hoạt động. Do đó, ai kiểm soát các khóa này sẽ kiểm soát quyền truy cập vào phần mềm.
Trong mã nguồn doublezero-offchain , chúng ta tìm thấy cấu hình này:
impl S3Config {
async fn new() -> Result<Self> {
hãy để xô = 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")
.Được rồi()
.and_then(|v| v.parse().ok())
.unwrap_or(12);
// Tải thông tin xác thực AWS từ các biến môi trường
let access_key_id = env::var("VALIDATOR_DEBT_AWS_ACCESS_KEY_ID")
.context("Biến môi trường VALIDATOR_DEBT_AWS_ACCESS_KEY_ID chưa được thiết lập")?;
let secret_access_key = env::var("VALIDATOR_DEBT_AWS_SECRET_ACCESS_KEY")
.context("Biến môi trường VALIDATOR_DEBT_AWS_SECRET_ACCESS_KEY chưa được thiết lập")?;
cho phép vùng =
env::var("VALIDATOR_DEBT_AWS_REGION").unwrap_or_else(|_| "us-east-1".to_string());Đoạn mã này là một phần của hệ thống con “validator-debt” và yêu cầu thông tin xác thực cấu hình AWS để hoạt động. Mã này cho thấy nó được kiểm soát bởi Malbec Labs chứ không phải DoubleZero Foundation. Bất kể bên nào nắm giữ các khóa, sự tồn tại của chúng đặt ra câu hỏi về khả năng áp dụng biện pháp miễn trừ không hành động.
Mặc dù về mặt lý thuyết, có thể ai đó viết lại mã này mà không cần phụ thuộc vào AWS, nhưng không có đặc tả nào về hành vi dự kiến của phần mềm ngoài chính mã nguồn này. Tình huống này tương tự như các định dạng tệp độc quyền, nơi việc hiểu được chúng đòi hỏi phải phân tích ngược.
Ngoài ra, bên thứ ba cũng có thể thử chạy mã này bằng khóa AWS của riêng họ. Tuy nhiên, điều này sẽ yêu cầu vận hành nhiều phần trong mục Người đóng góp tài nguyên DZ và giải quyết các vấn đề kiểm soát truy cập được thảo luận bên dưới. Khả năng sao chép và chạy mã nhiều lần không nhất thiết làm cho hệ thống trở nên phi tập trung.
Câu hỏi về tài liệu quy trình
Việc triển khai này đặt ra câu hỏi liệu DoubleZero có đang hoạt động trong phạm vi được SEC miễn trừ trách nhiệm hay không. Việc phát hành mã nguồn của một hệ thống được cho là phi tập trung và Không cần cho phép mà lại tham chiếu đến VALIDATOR_DEBT_AWS_SECRET_ACCESS_KEY cần được xem xét kỹ lưỡng.
Đây không phải là mối lo ngại duy nhất với kiến trúc phần mềm này. Malbec Labs có thể lập luận rằng điều này không cấu thành sự tập trung hóa vì đây chỉ đơn thuần là cách triển khai giao thức của họ và những người khác có thể triển khai nó theo cách khác. Chúng ta đã thảo luận về loại lập luận này ở trên. Điều này đặt ra hai câu hỏi cho Malbec Labs:
- Bạn có sẵn lòng công khai các khóa này không?
- Tài liệu hướng dẫn về giao thức nằm ở đâu? Chúng tôi không tìm thấy bất kỳ tài liệu tham khảo nào, chỉ có một hệ thống hiện có.
Khi việc triển khai hệ thống bị nhầm lẫn với chính định nghĩa giao thức, điều này đặt ra câu hỏi liệu việc phân quyền có ý nghĩa hay không. Trong kỹ thuật phần mềm, các thuật ngữ “hệ thống” và “giao thức” có ý nghĩa khác nhau và không nên bị nhầm lẫn.
Nợ của người xác thực & Phần thưởng cho người đóng góp
Hệ thống cơ sở hạ tầng đo lường tồn tại để tính toán phần thưởng trả cho người đóng góp. Công việc này được thực hiện trong một hệ thống con ngoài chuỗi có tên là validator-debt. Hệ thống validator-debt sử dụng mã bao bọc AWS được mô tả ở trên để ghi thông tin người xác thực vào một nhóm lưu trữ AWS S3 để sử dụng sau này trong việc tính toán phần thưởng. Một hệ thống con ngoài chuỗi contributor-rewards riêng biệt đọc dữ liệu này để thực hiện tính toán phần thưởng.
Hai hệ thống này giao tiếp với nhau thông qua các khóa riêng tư của AWS đã được đề cập ở trên. Hệ thống sử dụng thông tin xác thực riêng tư của AWS để liên lạc nội bộ. Điều này không được thực hiện thông qua blockchain mà chỉ đơn thuần là sự giao tiếp giữa hai thành phần phần mềm thông qua một kênh nội bộ riêng tư, tương tự như các hệ thống doanh nghiệp truyền thống hơn là các giao thức mở.
Ngoài ra, DoubleZero vận hành một chuỗi nhánh Solana riêng biệt cho nhiều mục đích khác nhau với sự tham gia hạn chế của công chúng. Việc truyền thông dữ liệu nội bộ thậm chí còn khó tiếp cận hơn cả chuỗi đó. Hai thành phần này, nợ của người xác thực và phần thưởng cho người đóng góp, tính toán phần thưởng là trọng tâm trong yêu cầu của DoubleZero gửi SEC. Tuy nhiên, các thành phần này nằm ngoài chuỗi và phụ thuộc vào thông tin xác thực riêng tư để hoạt động, điều này dường như không nhất quán với thư của DoubleZero gửi SEC.
Mặc dù chúng ta có thể tìm thấy mã tính toán Shapley và nhiều công cụ cũng như thống kê khác trong các hệ thống này, và chúng thực hiện các phép toán học, bao gồm cả việc công bố các gốc Merkle trên chuỗi, như đã được chứng minh trong Phần 1, hệ thống vẫn được kiểm soát bởi các khóa riêng. Mã hóa đảm bảo rằng các phép tính được thực hiện bởi các thành phần phần mềm khác nhau đều nhất quán.
Tuy nhiên, cùng một tổ chức đã viết toàn bộ phần mềm này và nó liên lạc thông qua các kênh riêng tư do tổ chức đó kiểm soát. Nếu tổ chức đó muốn sửa đổi phương pháp tính toán hoặc xác minh, mật mã học chỉ cung cấp sự bảo vệ hạn chế chống lại những thay đổi đó. Mặc dù phần mềm không hoàn toàn không bị hạn chế, như chúng ta sẽ thấy, nó được cấu hình theo cách giống với các hệ thống doanh nghiệp truyền thống hơn là các giao thức phi tập trung.
Phân phối phần thưởng
Trên Solana tồn tại một hợp đồng thông minh phân phối doanh thu chứa một “ kế toán phần thưởng ”. Đây là thành phần trên chuỗi của quy trình phân phối phần thưởng — đoạn mã phân phối phần thưởng mà DoubleZero đã yêu cầu SEC phân loại là một phần của sản phẩm DePIN không đủ điều kiện là chứng khoán.
Thành phần trên chuỗi (onchain) dường như hoạt động như một hệ thống phụ thuộc vào thành phần ngoài chuỗi (offchain) được kiểm soát bởi một bên trung tâm. Nó chỉ chấp nhận đầu vào từ các nguồn được chỉ định. Nó không phải là hệ thống Không cần cho phép hay truy cập mở mà là một hệ thống được kiểm soát sử dụng công nghệ blockchain.
Trong chương trình thưởng cho người đóng góp ngoài chuỗi, chúng ta tìm thấy đoạn mã này:
khớp với try_build_instruction(
&NHẬN DẠNG,
FinalizeDistributionDebtAccounts::new(&self.pubkey(), dz_epoch, &self.pubkey()),
&RevenueDistributionInstructionData::FinalizeDistributionDebt,
) {
Được rồi (hướng dẫn) => {
let recent_blockhash = solana_rpc_client.get_latest_blockhash().await?;
let message = Message::try_compile(
&self.signer.pubkey(),
&[chỉ dẫn],
&[],
băm khối gần đây,
)
.unwrap();
let finalized_transaction =
VersionedTransaction::try_new(VersionedMessage::V0(message), &[&self.signer])
.unwrap();
Ok(giao dịch đã hoàn tất)
}
Err(err) => Err(anyhow!(
"Không thể hoàn tất quá trình biên dịch hướng dẫn phân phối: {err:?}"
)),
}
Chức năng này khởi tạo một lệnh gọi đến hợp đồng thông minh Solana để thực thi RevenueDistributionInstructionData::FinalizeDistributionDebt. Đây là một trong nhiều bước trong quy trình hoàn tất phân phối phần thưởng. Chúng tôi sẽ không nêu chi tiết tất cả các bước ở đây để ngắn gọn.
Về phía Solana , chúng ta thấy cách xử lý thông báo hoàn tất phần thưởng như sau :
fn try_finalize_distribution_debt(accounts: &[AccountInfo]) -> ProgramResult {
msg!("Hoàn tất khoản nợ phân phối");
// Chúng tôi mong đợi các tài khoản sau đây đáp ứng yêu cầu này:
// - 0: Cấu hình chương trình.
// - 1: Kế toán nợ.
// - 2: Phân phối.
// - 3: Bên chi trả (bên tài trợ cho các khoản trợ cấp tái phân bổ).
// - 4: Chương trình hệ thống.
let mut accounts_iter = accounts.iter().enumerate();
// Tài khoản 0 phải là tài khoản cấu hình chương trình.
// Tài khoản 1 phải là tài khoản kế toán nợ.
//
// Cuộc gọi này đảm bảo rằng kế toán viên phụ trách khoản nợ là người ký tên và là cùng một người.
// Mã kế toán nợ được mã hóa trong cấu hình chương trình.
let authorized_use =
VerifiedProgramAuthority::try_next_accounts(&mut accounts_iter, Authority::DebtAccountant)?;
// Hãy đảm bảo chương trình không bị tạm dừng.
authorized_use.program_config.try_require_unpaused()?;Như ở Phần 1, chức năng này chỉ hoạt động khi được gọi bởi “kế toán nợ” được chỉ định. Tương tự như chương trình hộ chiếu và hệ thống giám sát, có sự hiện diện của blockchain, nhưng các chức năng chỉ được thực thi khi được gọi bởi các bên được phê duyệt.
Nếu điều này hoàn toàn nằm trên chuỗi khối và nội bộ trong một hệ thống phi tập trung hoàn toàn, thì có thể sẽ có chỗ cho tranh luận. Tuy nhiên, chúng ta có các thành phần ngoài chuỗi khối (trong một kho lưu trữ có tên là doublezero-offchain) gọi đến với quyền truy cập đặc quyền. Mặc dù có liên quan đến các thuật toán Merkle root và nhiều hình thức mã hóa khác nhau, nhóm phát triển vẫn có thể gửi dữ liệu đo từ xa thay thế và sửa đổi việc phân phối phần thưởng mà người tham gia không có quyền phản kháng.
Mặc dù công nghệ blockchain hiện diện và có những hạn chế nhất định trong việc phân phối phần thưởng, đảm bảo Persistence và nhất quán cho việc lưu trữ hồ sơ, nhưng chính bức thư của DoubleZero lại nêu rõ:
Một bộ hợp đồng thông minh kiểm soát nền kinh tế của Token giao thức (ví dụ: việc tạo ra token 2Z mới được thổi phồng) đã được triển khai trên blockchain Solana . Các nhà cung cấp tài nguyên được giao nhiệm vụ kích hoạt các hợp đồng thông minh này để chúng được thực thi, nhưng họ không có bất kỳ quyền kiểm soát nào đối với nền kinh tế hoặc khả năng nâng cấp các hợp đồng thông minh đó. Dự kiến quyền nâng cấp các hợp đồng thông minh này sẽ do Tổ chức kiểm soát khi ra mắt, mặc dù Tổ chức dự định sẽ phân quyền kiểm soát theo thời gian.
Quỹ thừa nhận rằng họ có thể sửa đổi quy trình này. Họ có thể thay đổi các quy tắc xác thực trong hệ thống này để xác nhận bất kỳ phương án phân phối Token mà họ lựa chọn.
Ngoài ra, chúng tôi còn có mã nguồn ngoài chuỗi sử dụng khóa riêng của AWS để thực hiện các chức năng này.
Điều này đặt ra câu hỏi liệu kiến trúc như vậy có đủ điều kiện để được hưởng sự đối xử theo luật chứng khoán như trường hợp của DoubleZero hay không.
Các phản hồi dự kiến
Một phản hồi có thể xảy ra là chúng ta hiểu sai cách thức hoạt động Solana . Có thể lập luận rằng các kiểm tra authorized_use, cả ở đây và trong Phần 1, đều thể hiện các thực tiễn thiết kế tốt tiêu chuẩn. Từ đó có thể suy ra rằng vì các hợp đồng thông minh chạy trên Solana, và Solana là phi tập trung, nên các hợp đồng thông minh cũng phải phi tập trung. Tuy nhiên, chính bức thư của họ thừa nhận rằng họ dự kiến sẽ duy trì quyền kiểm soát hệ thống trong một thời gian không xác định.
Một lập luận khác có khả năng là do quy trình trao thưởng cho trình xác thực sử dụng mật mã và công bố các gốc Merkle, nên ngay cả khi các chương trình này có quyền truy cập đặc quyền, quyền truy cập đó chỉ cho phép thanh toán đúng số tiền cần thiết.
Tuy nhiên, dữ liệu đo từ xa được thu thập thông qua các quy trình ngoài chuỗi. Vì sự kết hợp giữa Tổ chức (theo Phần 1, tổ chức này kiểm soát quyền truy cập để tham gia vào hệ thống) và Malbec Labs vận hành toàn bộ cơ sở hạ tầng đo từ xa ngoài chuỗi, nên họ có khả năng quan sát thấy các kết quả khác nhau và tính toán phần thưởng "chính xác" cho dữ liệu đo từ xa thay thế và phân phối chúng. Không có quy trình giải quyết tranh chấp rõ ràng nào tồn tại, cũng như không có cơ chế phản hồi nào cho những người tham gia tin rằng hệ thống hoạt động không đúng cách.
Theo tài liệu của họ, việc vận hành một node RPC cần được cấp quyền , ngăn cản việc thiết lập giao diện độc lập. Tài liệu thậm chí không cho phép người tham gia tự do thoát khỏi hệ thống, vì nó nêu rõ: “ Quan trọng: Vui lòng thảo luận với DZF và/hoặc Malbec Labs trước khi xóa LINK (Chainlink) sản xuất hiện có .”
Nhóm nghiên cứu cũng có thể lập luận rằng chúng ta đã hiểu sai đây là một hệ thống trong khi thực chất nó là một giao thức. Giao thức là một phương thức giao tiếp — một tập hợp các định dạng thông điệp và ý nghĩa được gán cho các thông điệp được định dạng đúng cách. Để được coi là “chỉ là một giao thức”, cần có hai điều: Thứ nhất, một đặc tả giao thức để đáp ứng yêu cầu “chỉ là một giao thức”. DoubleZero dường như chưa công bố một đặc tả như vậy. Thứ hai, chỉ cần tồn tại một đặc tả giao thức để đáp ứng yêu cầu “chỉ”.
Một bản đặc tả giao thức kèm theo một triển khai tham chiếu là điều chấp nhận được. Nếu triển khai tham chiếu đó chứa các điểm kiểm soát tập trung, điều đó cũng có thể được chấp nhận trong một số ngữ cảnh. Ví dụ, OAuth là một tập hợp các giao thức phức tạp , nhiều giao thức liên quan đến các cơ quan trung ương. Tuy nhiên, khi có một hệ thống triển khai hiện có trong đó một thực thể kiểm soát nhiều cơ quan trung ương, thì nó không còn chỉ là "một giao thức đơn thuần" nữa.
Cuộc thảo luận
Chúng tôi đã cố gắng làm cho bản phân tích này dễ hiểu nhất có thể đồng thời cung cấp bằng chứng rõ ràng. Như đã thảo luận trong Phần 1, chúng tôi thừa nhận rằng việc xác minh liệu yêu cầu miễn trừ trách nhiệm của một dự án có phù hợp với chi tiết triển khai phần mềm của họ hay không không phải là trách nhiệm của SEC.
Tuy nhiên, tuyên bố của DoubleZero rằng đây là một dự án blockchain cần được xem xét kỹ lưỡng. Sử dụng công cụ git-sizer của Git để phân tích cơ bản cho thấy những con số thú vị. Trong số ba kho lưu trữ thuộc sở hữu của Foundation: kho lưu trữ doublezero-solana (tất cả các thành phần trên chuỗi) có 123 tệp và kích thước xấp xỉ 1,23 MiB. Kho lưu trữ doublezero-offchain có 225 tệp và kích thước 24,5 MiB. Mã doublezero-ledger, dành cho Blockchain riêng tư thứ hai mà hệ thống sử dụng, có 3.230 tệp và kích thước 67 MiB. Ngoài ra, kho lưu trữ doublezero từ Malbec Labs, chịu trách nhiệm về mạng lưới, có 1.270 tệp và kích thước 30,5 MiB.
Mặc dù độ dài mã không hoàn toàn tương quan với tầm quan trọng, phần lớn hệ thống này tồn tại bên ngoài chuỗi khối công khai. Chúng ta biết rằng các thành phần nằm trên chuỗi khối Solana công khai được cấu hình để chỉ hoạt động với phần mềm ngoài chuỗi được chỉ định do các thực thể liên kết xây dựng.
Các khuyến nghị
Ủy ban Chứng khoán và Giao dịch (SEC) cần làm rõ rằng việc miễn trừ trách nhiệm dựa trên các tính năng mà hệ thống không có là:
- Không áp dụng cho hệ thống thực tế.
- Lãng phí nguồn lực của ủy ban.
- Có thể là yếu tố làm trầm trọng thêm tình hình trong các hành động thực thi pháp luật.
Việc không đưa ra tuyên bố cơ bản khẳng định lại rằng việc miễn trừ chỉ áp dụng cho các dự án có đặc điểm được mô tả trong đơn xin miễn trừ sẽ tạo ra sự không chắc chắn trên thị trường.
Các ủy viên đã đưa ra tuyên bố ca ngợi việc miễn trừ trách nhiệm như vậy nên xem xét liệu việc làm rõ có cần thiết để duy trì tính toàn vẹn của quy trình miễn trừ trách nhiệm hay không.
Bài viết "DoubleZero bị tập trung hóa và lừa dối SEC: Phần 2 của N" ban đầu được đăng trên ChainArgos trên Trung bình, nơi mọi người đang tiếp tục cuộc thảo luận bằng cách nêu bật và phản hồi về câu chuyện này.
