duskds

Hôm nay mình đi ngang qua đây để nói với các bạn về DuskDS, một trong những lớp có lẽ là khó hiểu nhất trong kiến trúc của @Dusk 🌒 . Nhưng mình sẽ cố gắng giải thích cho các bạn theo cách đơn giản nhất có thể, không dùng quá nhiều thuật ngữ kỹ thuật.

Ở bài viết trước, chúng ta đã thấy DuskEVM là lớp nơi phát triển và thực thi các ứng dụng hoặc hợp đồng thông minh tương thích với EVM, trong khi DuskDS là một lớp khác của hạ tầng, giúp quản lý dữ liệu và các thao tác được thực hiện trên DuskEVM.

Nói một cách ngắn gọn, DuskDS giúp các thao tác được thực hiện trên DuskEVM có thể được ghi lại và liên kết với hạ tầng chính của Dusk (Dusk L1), từ đó tạo điều kiện cho việc thanh toán và cung cấp dữ liệu.

Cần lưu ý rằng DuskEVM và DuskDS không phải là hai token khác nhau hay hai blockchain khác nhau cạnh tranh với nhau. Đây là hai lớp khác nhau, thực hiện các chức năng khác nhau trong kiến trúc của $DUSK .

Ở bài viết tiếp theo, chúng ta sẽ nói về Dusk L1 và mối liên hệ của nó với các lớp mà chúng ta đã thấy trước đó.

#dusk #DuskEVM #DuskDS

@Dusk đang xây dựng một thứ gì đó thuộc lĩnh vực DeFi và tài chính được token hóa sẽ ngày càng cần: quyền riêng tư mà không đánh đổi tuân thủ. Các blockchain công khai mạnh mẽ vì giao dịch có thể minh bạch và được xác minh, nhưng các thị trường tài chính được quản lý không thể công khai mọi số dư, vị thế, chi tiết nhà đầu tư hoặc giao dịch. @Dusk tiếp cận thách thức này bằng cách kết hợp công nghệ zero-knowledge, chuyển tiền ẩn danh, tiết lộ có chọn lọc, kiểm soát truy cập và thanh toán tất định. �
Dusk +1
Điều khiến cách tiếp cận này thú vị là ý tưởng rằng quyền riêng tư không nhất thiết phải đồng nghĩa với việc che giấu mọi thứ. Các bên được ủy quyền có thể nhận được thông tin họ cần, trong khi dữ liệu nhạy cảm vẫn được bảo vệ khỏi việc bị phơi bày công khai không cần thiết. Điều này đặc biệt phù hợp với chứng khoán được token hóa, tài sản ngoài đời thực, DeFi dành cho tổ chức và các quy trình tài chính khác, nơi việc đủ điều kiện, báo cáo, hạn chế chuyển nhượng và quy tắc thanh toán có ý nghĩa quan trọng. �
DOCS +1
Dusk cũng sử dụng kiến trúc mô-đun, với #DuskDS tập trung vào thanh toán và tính sẵn sàng dữ liệu, #DuskVM cho việc thực thi native Rust/WASM, và #DuskEVM cho các ứng dụng tương thích EVM. Điều đó mang lại cho nhà phát triển nhiều hướng đi khác nhau tùy thuộc vào việc ứng dụng ưu tiên quyền riêng tư native, công cụ quen thuộc của EVM hay hạ tầng thanh toán tuân thủ quy định. �
DOCS
Với tôi, phần thú vị của Dusk không chỉ đơn thuần là “quyền riêng tư”. Đó là sự kết hợp giữa quyền riêng tư, tuân thủ và thanh toán có thể dự đoán trong cùng một hạ tầng tài chính. Nếu nhiều tài sản ngoài đời thực và các thị trường của tổ chức tiếp tục chuyển sang on-chain, thì những năng lực này có thể ngày càng trở nên quan trọng. #dusk $DUSK

Hôm nay tôi đã thêm một vị trí $DUSK nhỏ, nhưng hiện tại tôi đang theo dõi DuskEVM theo cách khác.

Điều làm tôi chú ý không chỉ là tính tương thích EVM—mà là cách Hedger làm cho các giao dịch riêng tư có thể được xem lại bằng cách sử dụng mã hóa đồng cấu và các bằng chứng ZK. Trước đây tôi coi quyền riêng tư là một tính năng dành cho người dùng; giờ tôi xem đó như một cơ chế giúp các ứng dụng được quản lý có thể được chấp nhận rộng rãi.

@Dusk cũng hỗ trợ việc thực thi trong khi DuskDS phụ trách thanh toán và tính sẵn sàng dữ liệu. Sự tách biệt này có vẻ quan trọng.

Tôi vẫn chưa chắc người dùng thực tế sẽ sớm tiếp nhận nó đến mức nào, nhưng kiến trúc đã thay đổi cách nhìn của tôi.

$ATM $BANK #DUSK #DUSKEVM #DuskDS #Web3

Bạn nghĩ điều gì quan trọng nhất đối với DUSK?

Tôi cứ mãi làm sai một điều khi nghĩ về Moonlight và Phoenix: tôi đang coi hình dạng của trạng thái cũng đồng thời quyết định tính kết thúc.
Giả định đó bắt đầu làm tôi bứt rứt.
Moonlight đến ở #DuskVM mang theo một mô hình public-account: Balances, Sender, Receiver, Amount và Nonce Progression.
Phoenix được xây dựng dựa trên một “dấu vết” hoàn toàn khác: Encrypted Notes, Shielded Outputs, Nullifiers và Private State.
Trực giác đầu tiên của tôi là hai hệ thống khác nhau như vậy có lẽ cũng cần hai cách khác nhau để trở thành “final”.
Nhưng có lẽ đó là nơi tôi đang tự làm tăng độ phức tạp mà thực ra không cần thiết.
Moonlight có thể giữ dạng account. Phoenix có thể giữ dạng note. #DuskVM không cần phải ép một trong hai hệ đó dẹt thành một định dạng trạng thái phổ dụng chỉ để quyết định lúc nào việc thực thi được xem là xong.
Điều đó cũng khiến tôi suy nghĩ lại #DuskDS .
Tôi đã từng cho rằng nó cần tạo ra một trạng thái dùng chung $DUSK nằm dưới cả hai mô hình. Giờ tôi không còn chắc về điều đó nữa.
Logic thực thi có thể vẫn chuyên biệt, trong khi Dusk L1 vẫn cung cấp cho trạng thái kết quả một ranh giới “finality” (tính kết cuối) xác định theo định tính.
Và nói thật, sự tách bạch này còn thú vị với tôi hơn cả bản thân các mô hình trạng thái riêng lẻ.
Những cách khác nhau để biểu diễn trạng thái không nhất thiết phải dẫn đến những câu trả lời khác nhau cho câu hỏi rằng trạng thái đó cuối cùng đã hoàn tất khi nào.
Điều tôi vẫn đang tự hỏi là sự tách bạch này sẽ “sạch” đến mức nào khi Moonlight và Phoenix trở nên phức tạp hơn.

#dusk $DUSK @Dusk

Cây cầu vẫn ngừng hoạt động và đó là điều khiến tôi cứ quay lại trong một khoảng thời gian.

@Dusk đã tạm dừng dịch vụ cầu vào ngày 16 tháng 1 sau khi việc giám sát phát hiện hoạt động không nhất quán với hoạt động vận hành thông thường — đó là một ví vận hành do nhóm quản lý, chứ không phải giao thức. Các khối của DuskDS không bao giờ dừng. Nhưng cây cầu vẫn bị đình chỉ trong lúc họ hoàn tất công việc gia cố khó khăn, và biện pháp giảm thiểu đã được triển khai là một danh sách chặn người nhận nằm trong Web Wallet. Đánh dấu một địa chỉ xấu, đưa ra cảnh báo, dừng việc gửi.

Chỉ có vậy. Đó là tấm lưới an toàn.

Và đây là điều tôi không thể ngừng nghĩ: nếu bạn đang chạy Rusk CLI hoặc công cụ do chính bạn tự xây dựng, thì cảnh báo đó sẽ không bao giờ được kích hoạt. Bạn hoàn toàn tự chủ — và hoàn toàn bị phơi bày. Nền mật mã ZK phía dưới là một công việc thực sự nghiêm túc. Không có phần nào trong số đó chạm tới bề mặt rủi ro thực sự của tuần này.

Tôi không nghĩ danh sách chặn là một lựa chọn sai. Về mặt thực dụng, nó đúng — che phủ nhanh nhất cho nhiều người dùng nhất, rồi sửa kiến trúc sau.

Nhưng $DUSK đang định vị rõ ràng cho các thị trường tổ chức được quản lý. Nếu kiểm soát an toàn dễ nhìn nhất nằm trong Web Wallet chứ không phải ngay chính trong giao thức, thì sẽ có một câu hỏi thực sự về điều gì xảy ra khi một đội tuân thủ đem toàn bộ ngăn xếp đó đi kiểm thử chịu tải.

Đó là khoảng trống mà tôi đang theo dõi. Không phải là mật mã — mà là cơ chế quản trị về nơi mà khả năng bảo vệ thực sự được đặt.

Nếu các tổ chức cần các cam kết ở cấp giao thức, chứ không phải cảnh báo ở giao diện, thì lộ trình hiện tại của Dusk có đang đi đủ nhanh theo hướng đó không?

#Dusk #DeFi #ZeroKnowledge #Bridge #DuskDS