Phần mềm của DoubleZero, như khi được phát hành, chứa các yếu tố tập trung. Khóa riêng Ngoài chuỗi) điều khiển các hợp đồng thông minh cốt lõi và cần thiết để vận hành các phần bắt buộc của hệ thống không nằm on-chain).
DoubleZero tuyên bố rằng thư không phản đối từ SEC xác nhận rằng việc phân phối Token 2Z cho những người đóng góp trên mạng DoubleZero không phải tuân theo các yêu cầu đăng ký theo Đạo luật Chứng khoán . Tuy nhiên, cách diễn đạt này dường như không nhất quán với hệ thống đang được triển khai.
Việc DoubleZero được SEC miễn trừ trách nhiệm dường như dựa trên những thông tin không nhất quán với hệ thống đang hoạt động hiện nay. Hệ thống được triển khai khác biệt đáng kể so với những thông tin mà nhóm DoubleZero đã cung cấp cho SEC và công chúng.
Thư của SEC chỉ áp dụng cho các hệ thống hoạt động phù hợp với các tuyên bố trong thư yêu cầu của DoubleZero. Trong trường hợp hệ thống thực tế của DoubleZero không phù hợp với thư đó, sẽ không có sự hỗ trợ nào được cấp.
Chúng tôi đã từng viết về những vấn đề tương tự liên quan đến yêu cầu thư không phản đối của DoubleZero nói chung.
Giờ đây, vì toàn bộ mã nguồn phần mềm của DoubleZero đã được công khai, chúng ta sẽ bắt đầu xem xét những điểm mà DoubleZero, khi được triển khai, không khớp với những tuyên bố mà nó đã đưa ra cho SEC trong yêu cầu thư không hành động của mình.
Đây là Phần 1 của N. Vụ việc DoubleZero rất phức tạp, và thậm chí chỉ một vấn đề liên quan đến những tuyên bố mà DoubleZero đưa ra cho SEC cũng có thể đủ để khiến việc SEC miễn trừ trách nhiệm trở nên không áp dụng được.
Người canh gác
Sơ đồ kiến trúc hệ thống không ghi nhãn thành phần này là “
“Người canh gác”:
Nhưng trong sơ đồ đó có một phần được dán nhãn "Những người đóng góp tài nguyên DZ" và nếu bạn đọc hướng dẫn trong phần "Khởi tạo yêu cầu kết nối trong DoubleZero", bạn sẽ thấy đoạn văn này :
Sử dụng lệnh request-validator-access để tạo tài khoản trên Solana cho yêu cầu kết nối. Trình tác vụ DoubleZero Sentinel sẽ phát hiện tài khoản mới, xác thực danh tính và chữ ký của tài khoản, sau đó tạo mã truy cập trong DoubleZero để máy chủ có thể thiết lập kết nối.
Agent Sentinel theo dõi các yêu cầu truy cập và thực thi chúng, tương ứng với chức năng được mô tả ở góc trên bên trái của sơ đồ kiến trúc.
Thật trùng hợp, mã nguồn của Sentinel có sẵn trong một kho lưu trữ có tên là doublezero-offchain , đây là một kho lưu trữ Github thuộc Quỹ DoubleZero, được mô tả là “Các thành phần Offchain cho Mạng DoubleZero” và có liên quan đến “Những người đóng góp tài nguyên DZ”. Một lần nữa, có rất nhiều sự trùng lặp về tên gọi giữa kho lưu trữ và sơ đồ.
Nếu bạn xem qua đoạn mã đó, bạn sẽ tìm thấy một biến "keypair" trong Sentinel:
/// Đường dẫn đến tệp cặp khóa được ủy quyền trong chương trình Passport trên Solana
/// và giữ số tiền trong sổ cái DZ để ghi có cho các trình xác thực được ủy quyền.
cặp khóa: PathBuf,
Cặp khóa đó được sử dụng để thiết lập quyền truy cập Solana và khởi chạy một đối tượng phần mềm có tên là PollingSentinel :
let sentinel = PollingSentinel {
dz_rpc_client: DzRpcClient::new(dz_rpc, keypair.clone(), serviceability_id),
sol_rpc_client: SolRpcClient::new(sol_rpc, keypair),
processed_cache: Arc::new(Cache::new()),
khoảng thời gian thăm dò: Thời lượng::từ_giây(15),
previous_leader_epochs: 0,
};Hãy lưu ý rằng các máy khách RPC sử dụng cặp khóa. RPC viết tắt của Remote Procedure Call (Gọi thủ tục từ xa). Điều này không phải là mới hoặc đặc biệt đối với web3 mà đã tồn tại từ lâu . Đây là cách một máy tính gọi một hàm tồn tại ở nơi khác.
Trong trường hợp này, đoạn mã chúng ta đang xem xét đang gọi các hàm nằm trên chuỗi khối. Chuỗi khối được xây dựng dựa trên khóa riêng và ý tưởng rằng việc sở hữu các khóa này đồng nghĩa với quyền sở hữu hoặc quyền kiểm soát. Các lời gọi RPC từ Sentinel sử dụng các khóa riêng, vốn thể hiện quyền sở hữu hoặc quyền kiểm soát đó. Điều này tuân theo các mẫu kỹ thuật phần mềm tiêu chuẩn được điều chỉnh cho các hệ thống chuỗi khối.
Việc này có tác dụng gì?
Như tên gọi cho thấy, PollingSentinel hoạt động theo vòng lặp để kiểm tra các yêu cầu truy cập mới như sau:
đối với access_id trong new_requests {
let request_pda = access_id.request_pda;
match self.handle_access_request(access_id).await {
Được rồi(_) => {
// Chỉ lưu vào bộ nhớ cache sau khi xử lý thành công
self.processed_cache.insert(request_pda, Instant::now(), CACHE_TTL).await;
}
Err(err) => {
lỗi!(?err, "đã xảy ra lỗi khi xác thực yêu cầu truy cập mạng; sẽ thử lại trong lần thăm dò tiếp theo");
// Không lưu trữ các lỗi - cho phép thử lại ở chu kỳ thăm dò tiếp theo
}
}
}Chúng tôi đã trích dẫn các đoạn mã tiêu biểu để minh họa cách thức hoạt động này.
Điều này có nghĩa là trích xuất các khối mã từ giữa các hàm. Một số đoạn mã thiết lập trong Rust có thể khó phân tích cú pháp nếu không có công cụ phù hợp , vì vậy chúng ta tập trung vào logic cốt lõi.
PollingSentinel theo dõi các yêu cầu truy cập và sử dụng các khóa riêng được truyền qua dòng lệnh để xử lý các yêu cầu thông qua hàm handle_access_request , hàm này thực hiện đúng như tên gọi của nó.
Ngay cả khi bạn không thể hiểu được mã nguồn, bạn vẫn có thể theo dõi các chú thích và thông báo nhật ký:
async fn handle_access_request(&self, access_id: AccessId) -> Result<()> {
let service_key = match &access_id.mode {
AccessMode::SolanaValidator(a) => a.service_key,
AccessMode::SolanaValidatorWithBackupIds { attestation, .. } => attestation.service_key,
};
info!(%service_key, request_pda = %access_id.request_pda, "đang xử lý yêu cầu truy cập");
let validator_ips = self.verify_qualifiers(&access_id.mode).await?;
nếu !validator_ips.is_empty() {
// Cấp quyền truy cập cho tất cả các trình xác thực (chính và dự phòng)
for (validator_id, validator_ip) in validator_ips {
rpc_with_retry(
|| bất đồng bộ {
self.dz_rpc_client
.issue_access_pass(&service_key, &validator_ip, &validator_id)
.chờ đợi
},
"issue_access_pass",
)
.chờ đợi?;
info!(%validator_id, %validator_ip, user = %service_key, "access pass issued");
}
let signature = rpc_with_retry(
|| bất đồng bộ {
self.sol_rpc_client
.grant_access(&access_id.request_pda, &access_id.rent_beneficiary_key)
.chờ đợi
},
"cấp quyền truy cập",
)
.chờ đợi?;
info!(%signature, user = %service_key, "yêu cầu truy cập được chấp thuận");
metrics::counter!("doublezero_sentinel_access_granted").increment(1);
} khác {
let signature = rpc_with_retry(
|| bất đồng bộ {
self.sol_rpc_client
.deny_access(&access_id.request_pda)
.chờ đợi
},
"từ chối truy cập",
)
.chờ đợi?;
info!(%signature, user = %service_key, "yêu cầu truy cập bị từ chối");
metrics::counter!("doublezero_sentinel_access_denied").increment(1);
}
Được rồi(())
}Điều quan trọng cần lưu ý là việc “xử lý yêu cầu truy cập” bao gồm rất nhiều logic và điều này luôn liên quan đến nhiều cuộc gọi RPC. Đó là các cuộc gọi đến các hàm nằm trên Solana hoặc chuỗi khối DoubleZero.
Đúng vậy, DoubleZero hoạt động dựa trên sự kết hợp giữa Solana và DoubleZero Ledger của riêng họ (một Fork từ Solana) , cùng với các phụ thuộc Ngoài chuỗi .
Các lệnh gọi đến dz_rpc_client (đến chuỗi DZ) và sol_rpc_client (đến Solana) trong hàm đó được ký bằng các khóa riêng cấp quyền truy cập vào chương trình passport. Vì vậy, khi đoạn mã này gọi grant_access() và issue_access_pass() và các hàm tương tự, tất cả đều Phái sinh vào việc người đang chạy Sentinel có quyền truy cập vào các khóa riêng phù hợp hay không. Quá trình này được kiểm soát bởi các khóa riêng. Ergo, nó được tập trung hóa. Một Sentinel hoạt động không thể được chạy nếu thiếu các khóa riêng cụ thể này.
Giờ hãy nhớ lại "tệp cặp khóa được ủy quyền trong chương trình Passport trên Solana" ở trên? Điều đó ngụ ý rằng có một chương trình Passport nào đó cũng biết về các khóa đặc biệt. Và thực tế là có. Nếu chúng ta xem xét kỹ hơn, chúng ta có thể thấy sự kiểm soát tập trung này ở phía chương trình Passport. Đây là một đoạn mã bên trong chương trình Passport xử lý các yêu cầu truy cập . Đây là phía bên kia của một số lệnh gọi RPC ở trên.
// 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 giám sát của Sổ cái DoubleZero.
//
// Cuộc gọi này đảm bảo rằng thiết bị giám sát của Sổ cái DoubleZero là một người ký và là
// Cùng một giá trị đánh dấu được mã hóa trong cấu hình chương trình.
let authorized_use =
VerifiedProgramAuthority::try_next_accounts(&mut accounts_iter, Authority::Sentinel)?;
Đoạn mã này đảm bảo rằng Sentinel (thành phần Ngoài chuỗi được mô tả ở trên) đã tham gia vào việc khởi tạo yêu cầu. Hơn nữa, nó kiểm tra xem Sentinel có được “mã hóa trong cấu hình chương trình [passport]” hay không. Điều này không phù hợp với một hệ thống mở, Không cần cho phép . Đoạn mã bao gồm các kiểm tra lồng nhau để đảm bảo rằng các khóa riêng cụ thể đã được sử dụng để khởi tạo các yêu cầu truy cập vào một mạng lưới tự xưng là mở và Không cần cho phép. Các khóa riêng này cung cấp quyền kiểm soát độc quyền đối với quy trình đăng ký.
Thay vì xem xét thêm mã nguồn, chúng ta có thể tham khảo tài liệu của chính DoubleZero, vốn đã nêu rõ điều này:
Khóa dịch vụ phải được người đóng góp tạo ra và lưu trữ an toàn trước khi gửi đến Tổ chức DoubleZero để được ủy quyền. Điều này đảm bảo rằng tất cả các tương tác CLI đều có thể được xác minh bằng mật mã và liên kết với tài khoản người đóng góp chính xác. [ ở đây ]
Bước 2 của bài viết “ Cách kết nối với DoubleZero ở chế độ IBRL — dành cho các node RPC ” nêu rõ:
2. Liên hệ với Tổ chức DoubleZero.
Tổ chức DoubleZero. Bạn cần cung cấp DoubleZeroID, ID Trình xác thực (ID nút) và địa chỉ IPv4 công cộng mà bạn sẽ sử dụng để kết nối.
Tài liệu hướng dẫn nêu rõ rằng người dùng phải liên hệ với Tổ chức DoubleZero như một phần của quá trình kết nối. Yêu cầu này không phù hợp với một hệ thống Không cần cho phép .
Ngay cả khi chính sách đã được DoubleZero tuyên bố là "không can thiệp" vào quy trình này, thì Tổ chức vẫn giữ quyền kiểm soát nó.
Tài liệu và mã nguồn cùng nhau chứng minh rằng:
- Một tham chiếu trực tiếp đến “tệp cặp khóa được ủy quyền trong chương trình hộ chiếu trên Solana” trong mã, sau đó tương tác một cách đặc quyền với chương trình hộ chiếu nói trên.
- Một tuyên bố rõ ràng rằng Quỹ thực hiện "sự ủy quyền".
- Một yêu cầu đặt ra là người dùng phải “cung cấp DoubleZeroID, ID Trình xác thực (ID nút) và địa chỉ IPv4 công cộng mà bạn sẽ kết nối đến” cho Tổ chức.
Chỉ cần xem tài liệu hướng dẫn là đủ hiểu rõ điều này, bất kể khả năng đọc hiểu mã nguồn của người xem ra sao.
Những tuyên bố của chính nhóm này gửi cho SEC chứng minh họ hiểu rõ những vấn đề này.
Thư không phản đối
Bức thư gửi cho SEC yêu cầu được miễn xử lý bao gồm đoạn văn sau:
Nhìn chung, các Nhà cung cấp Mạng là những nhà điều hành độc lập, có trình độ cao trong hệ thống này. Họ chịu trách nhiệm tích hợp các liên kết của mình với Mạng, cài đặt các thiết bị FPGA liên quan, thiết lập và đáp ứng các mức độ dịch vụ, duy trì các liên kết và cuối cùng là ngắt kết nối khỏi Mạng nếu họ muốn. Không có Nhà cung cấp Mạng nào là chi nhánh của Quỹ và cả Quỹ hay bất kỳ nhà đóng góp nào khác cũng không thực hiện những nỗ lực này thay mặt họ (ngoài việc đào tạo và phối hợp giữa các Nhà cung cấp Mạng).
Tài liệu này cũng bao gồm một chú thích cho đoạn văn đó như sau:
Quỹ đóng vai trò hạn chế trong việc hỗ trợ các nhà cung cấp mạng kết nối vật lý các đường cáp quang mới vào mạng. Quỹ không thu lợi nhuận từ các dịch vụ này và, tại thời điểm ra mắt, sẽ không có quyền quyết định chấp nhận hay từ chối các nhà cung cấp mạng. Quỹ dự định rằng quy trình này sẽ trở nên hoàn toàn Không cần cho phép theo thời gian.
Yêu cầu trong chú thích chỉ giới hạn rõ ràng ở việc hỗ trợ kết nối vật lý và chỉ đề cập đến hỗ trợ cơ sở hạ tầng vật lý.
Ngay cả khi hiểu "về mặt vật lý" một cách rộng rãi bao gồm cả các kết nối logic, cách biểu diễn này vẫn không nhất quán với hệ thống được triển khai.
Phần trước đã nêu rõ rằng Tổ chức phải thực hiện một số hành động nhất định để bất kỳ ai cũng có thể tích hợp các liên kết của họ vào Mạng lưới.
Để hệ thống hoạt động, cần có người vận hành chương trình Sentinel bằng một bộ khóa riêng cụ thể. Liệu có tồn tại sự tập trung hóa nào khác ngoài điều này hay không sẽ được đề cập trong phân tích tiếp theo.
Tạm thời cứ bỏ qua chuyện đó đi.
Bằng chứng cho thấy Quỹ là nhà cung cấp duy nhất của một số bước quan trọng trong quy trình tiếp nhận thành viên. Yêu cầu miễn trừ trách nhiệm pháp lý nêu rõ rằng Quỹ không phải là nhà cung cấp trung tâm các chức năng hệ thống quan trọng. Lá thư này đặc biệt loại trừ việc hỗ trợ kết nối vật lý, đồng thời nêu rõ ý định cuối cùng sẽ thực hiện việc này Không cần cho phép.
Nếu vấn đề này được đưa ra tòa, có thể phát sinh những câu hỏi liên quan đến việc liệu có nên cấp lệnh miễn trừ trách nhiệm dựa trên những tuyên bố về những thay đổi hệ thống trong tương lai hay không.
Hệ thống được triển khai thực tế, chứ không phải những dự định trong tương lai, mới là yếu tố quyết định xem các yêu cầu pháp lý có áp dụng hay không.
Có thể mô tả điều trên là "sự phối hợp giữa các nhà cung cấp mạng", nhưng sự phối hợp này diễn ra thông qua một hợp đồng được kiểm soát bằng khóa riêng của chủ sở hữu.
Nếu hình thức 'phối hợp' này được coi là phi tập trung, thì sự phân biệt giữa hệ thống tập trung và phi tập trung trở nên vô nghĩa đối với mục đích quản lý.
Mã ở đâu?
Đáng chú ý là không có liên kết nào đến các trình khám phá Block có con trỏ đến mã và các sự kiện on-chain . Điều đó là bởi vì, theo như chúng tôi biết, mã này chưa được xác minh trên Solana và không có danh sách công khai các địa chỉ triển khai.
Đây là chương trình phân phối doanh thu thuộc DoubleZero:
Mã nguồn chưa được kiểm tra trên trình duyệt công khai. Tài liệu không chứa địa chỉ hợp đồng và không có vị trí kho lưu trữ với các thành phần triển khai theo thông lệ. Ngoài ra, mã nguồn có thể nâng cấp được.
Địa chỉ hợp đồng được mã hóa cứng trong mã nguồn của kho lưu trữ doublezero-solana nên chúng ta biết:
- phân phối doanh thu: dzrevZC94tBLwuHw1dyynZxaXTWyp7yocsinyEVPtt4
- hộ chiếu: dzpt2dM8g9qsLxpdddnVvKfjkCLVXd82jrrQVJigCPV
Cả hai đều không được xác minh và cả hai đều có thể nâng cấp, và việc tìm kiếm thông tin này không hề dễ dàng.
Thông lệ tiêu chuẩn sẽ bao gồm các hợp đồng đã được xác minh với địa chỉ được ghi chép rõ ràng. Mặc dù thông tin này có thể được tìm thấy thông qua việc kiểm tra mã số, nhưng việc thiếu các quy trình lập hồ sơ tiêu chuẩn là điều đáng chú ý.
Cuộc thảo luận
Phân tích này chỉ ra rằng quyết định miễn trừ trách nhiệm đã được cấp có thể không áp dụng cho DoubleZero như khi được triển khai.
Việc bổ sung thêm ngữ cảnh là cần thiết vì yêu cầu của DoubleZero đã khiến Ủy viên SEC Peirce mô tả vai trò của SEC trong toàn bộ sự việc này như sau:
Nhiệm vụ của chúng tôi là hợp tác với các nhà đổi mới một cách thiện chí, lắng nghe cẩn thận khi họ giải thích cách thức hoạt động của các mô hình của họ, và áp dụng nhiệm vụ theo luật định một cách chu đáo và chính xác.
Cô ấy cũng mô tả dự án này là một dự án "phân phối token một cách lập trình cho người dùng tham gia mạng lưới theo các quy tắc của mạng lưới", điều này đúng ở một mức độ nào đó.
Tuy nhiên, do Quỹ kiểm soát quá trình phân phối, mức độ tập trung hóa dường như tương tự như các hệ thống tập trung truyền thống.
Tuyên bố của Pierce dường như chấp nhận cách DoubleZero tự mô tả mình là một 'mạng ngang hàng mở và phân tán' mà không tính đến các cơ chế kiểm soát tập trung đã được nêu ở trên.
Yêu cầu miễn trừ trách nhiệm có vẻ khác biệt đáng kể so với hệ thống DoubleZero thực tế được triển khai, tuy nhiên, sau khi SEC chấp thuận, DoubleZero đã công khai rộng rãi kết quả này.
Nếu những thông tin trình bày với SEC không nhất quán với hệ thống đã được triển khai, điều này sẽ đặt ra câu hỏi về quy trình không xử phạt và liệu việc Ủy ban cần làm rõ thêm có phù hợp hay không.
Chúng ta đều biết SEC chú trọng đến việc công khai thông tin chứ không phải xem xét lại.
Chúng tôi không kỳ vọng SEC sẽ xem xét liệu yêu cầu không hành động như thế này có phù hợp với hệ thống đang được đề cập hay không. Đó không phải là nhiệm vụ của SEC và thư không hành động, một cách chính đáng, bao gồm điều khoản này:
Quan điểm này dựa trên những thông tin mà bạn đã trình bày với Phòng trong thư của mình. Bất kỳ sự thật hoặc điều kiện nào khác có thể khiến Phòng đưa ra kết luận khác.
Cách tiếp cận dựa trên việc công khai thông tin của SEC không loại trừ việc giải quyết các trường hợp mà việc miễn trừ trách nhiệm có thể đã được đạt được dựa trên những tuyên bố không chính xác về mặt nội dung.
DoubleZero tiếp tục dựa vào sự miễn trừ trách nhiệm pháp lý trong các hoạt động quảng bá của mình. Bất kỳ hành động thực thi pháp luật nào trong tương lai có thể sẽ liên quan đến các câu hỏi về tính áp dụng của sự miễn trừ trách nhiệm pháp lý đối với hệ thống đang được triển khai.
Tình hình hiện tại càng kéo dài, sự phụ thuộc vào việc không cần hành động gì càng trở nên vững chắc.
Mã nguồn được công khai và có thể được phân tích. Có thể xác định được những điểm khác biệt đáng kể giữa yêu cầu không hành động và hệ thống đã triển khai.
Trong trường hợp hệ thống thực tế khác với những mô tả trong thư yêu cầu, biện pháp khắc phục có thể không được áp dụng. Niềm tin chủ quan của nhóm về khả năng áp dụng biện pháp khắc phục là khác biệt với vấn đề pháp lý về việc liệu biện pháp đó có được áp dụng hay không.
Điều quan trọng là nhóm đó có thể viện dẫn một lá thư không phản đối (no-action letter ) không áp dụng cho dự án của họ và đưa ra những tuyên bố mà người bình thường không thể nhận ra là sai sự thật vì họ thiếu kỹ năng để đưa ra quyết định như vậy.
Việc xử lý theo quy định nên dựa trên quá trình điều tra kỹ lưỡng chứ không phải dựa trên phân tích của bên thứ ba.
Việc Ủy ban đưa ra lời giải thích công khai về tính áp dụng của các thư không hành động khi các sự kiện thực tế khác với những tuyên bố sẽ vô cùng quý giá.
Việc làm rõ khi nào những thông tin không chính xác về mặt nội dung trong các yêu cầu miễn trừ có thể cần được xem xét kỹ lưỡng hơn sẽ giúp thiết lập ranh giới rõ ràng hơn. Nếu không có sự làm rõ như vậy, hiệu quả của quy trình miễn trừ trong việc xác định sự tuân thủ quy định có thể bị ảnh hưởng.
Bài viết "DoubleZero bị tập trung hóa và đánh lừa SEC: Phần 1 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.
