Kiko奇科

#dusk $DUSK @Dusk

DuskEVM: Mang phát triển EVM đến với Dusk.

Điều gì xảy ra khi một L1 được thiết kế xoay quanh quyền riêng tư và hạ tầng tài chính, đồng thời cũng trao cho nhà phát triển khả năng tiếp cận mô hình phát triển của Ethereum?

Đó là vai trò của DuskEVM.

Tài liệu của Dusk mô tả DuskEVM như một môi trường thực thi tương thích EVM, nơi nhà phát triển có thể xây dựng bằng Solidity hoặc Vyper trong khi vẫn sử dụng các công cụ và hạ tầng quen thuộc của Ethereum. Bao gồm các wallet EVM JSON-RPC tiêu chuẩn và các framework phát triển như Foundry, Hardhat, viem và ethers.

Chi tiết kiến trúc quan trọng là DuskEVM không vận hành như một môi trường tách biệt. Việc thanh toán (settlement) và tính sẵn sàng dữ liệu đến thông qua DuskDS, trong khi DUSK đóng vai trò là tài sản gas gốc (native).

Điều này tạo ra một lộ trình phát triển thực tiễn cho các ứng dụng vốn đã được thiết kế dựa trên hệ sinh thái EVM. Dusk nêu rõ các trường hợp sử dụng như ứng dụng tài sản được mã hóa (tokenized asset), các giao thức DeFi, các AMM và hoạt động cho vay (lending).

Vì vậy, ý nghĩa không chỉ dừng lại ở việc đơn thuần thêm khả năng tương thích EVM. Đó là việc thu hẹp khoảng cách về công cụ giữa các thực tiễn phát triển Ethereum đã được thiết lập và hạ tầng nền tảng của Dusk.

Đối với @Dusk, điều này mang đến cho nhà phát triển một điểm bắt đầu quen thuộc mà không cần họ phải từ bỏ kiến trúc gốc của mạng lưới.

Liệu khả năng tương thích EVM có thể trở thành một trong những cây cầu quan trọng nhất giữa hạ tầng chuyên biệt của Dusk và một hệ sinh thái nhà phát triển rộng lớn hơn rất nhiều không?

DuskVM vs DuskEVM: Hai hướng đi cho nhà phát triển

Một blockchain có cần buộc mọi nhà phát triển phải đi vào cùng một môi trường thực thi không?

Dusk có một cách tiếp cận khác: cung cấp hai lộ trình smart contract, mỗi lộ trình được thiết kế cho một mô hình phát triển khác nhau.

DuskVM là lộ trình gốc. Nhà phát triển viết contract bằng Rust, biên dịch chúng thành WASM và thực thi trực tiếp trên Dusk L1. Nhờ đó, contract có quyền truy cập trực tiếp vào mô hình thực thi của Dusk L1, các mô hình giao dịch và giao thức, các protocol contract và năng lực cần được đặt sát lớp nền tảng, bao gồm cả tính năng bảo mật và khả năng zero-knowledge.

DuskEVM đi theo hướng tập trung vào khả năng tương thích. Nhà phát triển có thể sử dụng Solidity hoặc Vyper cùng với các thư viện và công cụ ví EVM quen thuộc. Việc settlement và cung cấp dữ liệu sẵn có được đảm bảo thông qua DuskDS, trong khi DUSK đóng vai trò là token gas gốc.

Vì vậy, sự khác biệt không nằm ở việc chọn môi trường nào tốt hơn, mà là ở việc khớp kiến trúc với yêu cầu của ứng dụng: DuskVM ưu tiên thực thi trực tiếp trên L1 và các năng lực đặc thù của Dusk. DuskEVM làm giảm rào cản cho các nhà phát triển vốn đã làm việc trong hệ sinh thái Ethereum.

Đối với Dusk, việc cung cấp cả hai lộ trình tạo ra một sự cân bằng thú vị giữa tính năng gốc và sự quen thuộc của nhà phát triển.

Việc hỗ trợ đồng thời thực thi gốc và tương thích EVM có thể là chiến lược phát triển mạnh mẽ hơn so với việc buộc một môi trường phổ quát không?

$DUSK

#dusk @Dusk

Hãy bình luận về ý tưởng của bạn

Đặt cược trên Dusk: DUSK đảm bảo mạng lưới như thế nào.

Đặt cược thực sự đóng góp gì cho một blockchain ngoài việc kiếm phần thưởng?

Trên Dusk, việc đặt cược được kết nối trực tiếp với cơ chế đồng thuận. Các provisioner đặt cược DUSK và tham gia vào quá trình đề xuất cũng như xác thực các khối. Các provisioner hoạt động có thể nhận phần thưởng từ phát hành token và phí giao dịch, khiến việc đặt cược trở thành một phần của cơ chế bảo mật của mạng lưới thay vì chỉ là một sản phẩm sinh lợi riêng.

Quá trình chọn lọc cũng rất quan trọng. Tuyển chọn xác định (deterministic sortition) của Dusk chọn ra các trình tạo khối và thành viên ủy ban bỏ phiếu thông qua một quy trình được cân theo lượng stake. Cơ chế này được thiết kế sao cho tần suất được chọn tỉ lệ thuận với lượng stake của một provisioner, đồng thời vẫn có thể tái tạo và không thể đoán trước trước thời điểm diễn ra.

Sau đó, đồng thuận tiếp tục qua việc xác thực đề xuất và phê chuẩn (ratification). Một provisioner được chọn đề xuất một khối ứng viên, một ủy ban đánh giá khối đó và một ủy ban khác xác nhận kết quả xác thực. Một đa số lớn các phiếu hợp lệ có thể tạo ra kết quả thành công.

Nhưng tham gia đi kèm trách nhiệm. Tài liệu hiện tại của Dusk phân biệt giữa hình phạt mềm cho trường hợp tham gia thất bại và hình phạt cứng cho hành vi đồng thuận được chứng minh là không hợp lệ, bao gồm chữ ký xung đột.

Điều này tạo ra mối liên hệ quan trọng giữa stake kinh tế và trách nhiệm của mạng lưới. DUSK không chỉ đơn thuần bị khóa; nó mang lại cho người tham gia một lý do kinh tế để vận hành đúng các hạ tầng đồng thuận.

Với <c-1/> @Dusk việc đặt cược vì vậy là một phần của chính kiến trúc bảo mật.

$DUSK #dusk

Việc gắn trực tiếp stake kinh tế với trách nhiệm đồng thuận có tạo ra động lực mạnh hơn để mạng lưới tham gia một cách tin cậy không?

DUSK: Hơn Cả Một Token.

Điều gì khiến một token blockchain bản địa có được giá trị sử dụng thực sự ngoài việc chỉ được giao dịch?

Với Dusk DUSK được tích hợp trực tiếp vào hoạt động của mạng. Tài liệu chính thức định nghĩa nó là token bản địa được dùng cho phí giao dịch và staking, kết nối tài sản với cả hoạt động của mạng và sự tham gia vào cơ chế đồng thuận.

Mỗi giao dịch đều cần tài nguyên mạng và DUSK đóng vai trò là tài sản gas dùng để thanh toán cho các tác vụ đó. Điều này bao gồm các hoạt động trong các môi trường thực thi của Dusk, với DuskEVM sử dụng rõ ràng DUSK làm token gas bản địa.

Vai trò thứ hai còn quan trọng và nền tảng hơn—staking.

Dusk sử dụng provisioners để tham gia vào cơ chế đồng thuận, với các provisioner hoạt động được chọn để đề xuất và xác thực các khối. Theo tài liệu hiện hành, staking trực tiếp yêu cầu vận hành một provisioner node và phần thưởng được dựa trên mức độ tham gia vào đồng thuận cùng với lượng stake đang hoạt động.

DUSK cũng kết nối các phần khác nhau của hệ sinh thái. Tài liệu mô tả sự di chuyển giữa Dusk L1 và DuskEVM, trong khi các nhà phát triển có thể xây dựng thông qua DuskVM hoặc DuskEVM tùy theo yêu cầu về môi trường thực thi và bộ công cụ của họ.

Vì vậy, điểm thú vị không chỉ dừng lại ở việc DUSK là tài sản bản địa của mạng. Giá trị sử dụng của nó được gắn chặt vào những cơ chế giúp mạng vận hành.

Đối với @Dusk , giá trị sử dụng của token vì thế có liên hệ chặt chẽ với hạ tầng.

$DUSK #dusk

Một token bản địa sẽ trở nên có ý nghĩa hơn khi giá trị sử dụng của nó không thể tách rời khỏi các hoạt động cốt lõi của mạng hay không?

Citadel: Tiết lộ có chọn lọc cho danh tính số

Danh tính số thường tạo ra một lựa chọn khó khăn: hoặc tiết lộ mọi thứ để chứng minh bạn là ai, hoặc tiết lộ quá ít để có thể đáp ứng yêu cầu của ứng dụng.

Bình minh xám (Dusk) tiếp cận bài toán này bằng Citadel, được mô tả trong tài liệu của hãng như là lớp danh tính và kiểm soát truy cập của mạng cho việc tiết lộ có chọn lọc.

Sự khác biệt này rất quan trọng. Tiết lộ có chọn lọc không chỉ đơn giản là giữ thông tin danh tính ở chế độ riêng tư. Đó là việc thiết kế quyền truy cập dựa trên chính những thông tin thực sự cần được tiết lộ cho một tương tác cụ thể.

Điều này phù hợp một cách tự nhiên với kiến trúc tổng thể của Dusk. Mạng đã phân biệt giữa tài khoản công khai và tài khoản được che chắn, giúp các giao dịch có thể vận hành với các mức hiển thị khác nhau. Citadel mở rộng tư duy đó sang danh tính và quyền truy cập, thay vì chỉ dữ liệu giao dịch.

Tài liệu của Dusk cũng liệt kê “Citadel Self Sovereign Identities” trên Mạng Dusk như một bài nghiên cứu chuyên biệt, bên cạnh các công trình kỹ thuật liên quan đến các hệ thống mật mã không kiến thức (zero knowledge) và xác thực làm mù thuộc tính (attribute blinding).

Điều khiến tôi quan tâm ở đây là nguyên tắc kiến trúc: danh tính không nhất thiết phải trở thành một bản ghi công khai vĩnh viễn chỉ vì người dùng cần chứng minh điều gì đó.

Đối với @Dusk , tiết lộ có chọn lọc kết nối quyền riêng tư với cơ chế kiểm soát truy cập mang tính thực tiễn, đặc biệt phù hợp khi hạ tầng blockchain tương tác với các ứng dụng nơi danh tính và ủy quyền (authorization) quan trọng.

#dusk $DUSK

Liệu tiết lộ có chọn lọc có thể trở thành lớp thiếu giữa quyền riêng tư số và các yêu cầu danh tính của các hệ thống tài chính được quản lý không?

Quyền riêng tư mà vẫn không đánh đổi tính hữu dụng trong thực tế.

Quyền riêng tư trên blockchain trở nên khó khăn khi việc bảo vệ thông tin cũng khiến hệ thống trở nên khó sử dụng, khó xác minh hoặc khó tích hợp.

Dusk tiếp cận vấn đề này bằng cách đưa nhiều mức độ hiển thị giao dịch khác nhau vào cấu trúc của mạng.

Mô hình Moonlight của nó cung cấp các giao dịch dựa trên tài khoản công khai. Số dư của các địa chỉ công khai và hoạt động giao dịch có thể vẫn minh bạch, điều này hữu ích khi cần sự hiển thị và khả năng xác minh đơn giản.

Phoenix đi theo hướng ngược lại khi tính bảo mật giao dịch là quan trọng. Nó sử dụng các giao dịch dựa trên shielded UTXO được xây dựng xung quanh notes nullifiers và các bằng chứng kiến thức không đầy đủ (zero-knowledge proofs). Mạng có thể xác minh rằng giao dịch hợp lệ mà không cần công khai người gửi, người nhận hoặc số tiền được chuyển.

Nhưng quyền riêng tư trong Phoenix không chỉ đơn thuần là che giấu thông tin khỏi mọi người. Giao thức bao gồm view keys cho phép người dùng xác định các giao dịch được gửi đến cho họ trong khi vẫn bảo vệ quyền chi tiêu. Bản whitepaper cũng mô tả cách view keys có thể cho phép quét giao dịch được ủy quyền mà không trao cho bên được ủy quyền khả năng chi tiêu các notes.

Sự phân biệt này là quan trọng vì bảo mật thông tin cho hạ tầng tài chính trong thực tế không nhất thiết phải đồng nghĩa với việc từ bỏ quyền truy cập được kiểm soát.

Với @Dusk , do đó, quyền riêng tư nên được hiểu tốt hơn như một thuộc tính có thể cấu hình của các giao dịch hơn là một trở ngại đối với khả năng sử dụng.

$DUSK #dusk

Liệu khả năng hiển thị có chọn lọc có thể trở thành mô hình thực tế hơn cho tài chính blockchain, thay vì việc phải lựa chọn giữa minh bạch hoàn toàn và ẩn danh hoàn toàn?

Trăng Sáng vs Phượng Hoàng: Hai Mô Hình Giao Dịch.

Một trong những lựa chọn thú vị nhất trong Dusk là quyền riêng tư không được xem như quyết định “có hoặc không”.

Thay vào đó, Dusk cung cấp hai mô hình giao dịch với những mục đích khác nhau: Moonlight (Trăng Sáng) và Phoenix (Phượng Hoàng).
Moonlight là mô hình tài khoản công khai dựa trên nền tảng của Dusk. Mỗi tài khoản được liên kết với một khóa công khai và mạng duy trì số dư cũng như nonce giao dịch của tài khoản đó. Các giao dịch được ủy quyền thông qua chữ ký số, trong khi trạng thái tài khoản vẫn minh bạch đối với mạng.
Phoenix thực hiện một cách tiếp cận hoàn toàn khác. Đây là mô hình UTXO được che chắn (shielded) trong đó các UTXO được biểu diễn dưới dạng các ghi chú trong một cây Merkle. Khi một ghi chú được chi tiêu, một bộ vô hiệu hóa (nullifier) sẽ ngăn chặn chi tiêu hai lần mà không tiết lộ ghi chú cụ thể nào đã được sử dụng. Các giao dịch Phoenix sử dụng bằng chứng không kiến thức (zero-knowledge proofs) để mạng có thể xác minh rằng giao dịch tuân thủ các quy tắc giao thức mà không trực tiếp lộ các chi tiết giao dịch nền tảng.
Sự khác biệt này quan trọng vì các hoạt động tài chính khác nhau có thể cần những mức độ hiển thị khác nhau.
Một tài khoản công khai có thể cung cấp tính minh bạch dễ dàng, trong khi Phoenix có thể mang lại quyền riêng tư giao dịch mạnh hơn. Tài liệu của Dusk mô tả các mô hình này là những mô hình bổ sung cho nhau thay vì cạnh tranh với nhau.
Với @Dusk , ý tưởng kiến trúc sâu hơn là tính linh hoạt: người dùng không phải chọn giữa một blockchain hoàn toàn minh bạch và một blockchain hoàn toàn riêng tư.

$DUSK #dusk

Việc cung cấp cho người dùng cả hai mô hình giao dịch—minh bạch và được che chắn—liệu có trở thành một yêu cầu quan trọng cho hạ tầng tài chính nghiêm túc trên chuỗi không?

Xác nhận ngắn gọn: Làm thế nào Dusk đạt đến tính cuối cùng.

Blockchain thực sự cần gì để một giao dịch trở nên cuối cùng?

Với Dusk, câu trả lời bắt đầu từ Succinct Attestation—giao thức đồng thuận proof-of-stake của nó. Cơ chế này được thiết kế xoay quanh các ủy ban do người cung cấp (provisioners) được chọn ngẫu nhiên, cùng với một chuỗi các bước xác thực đề xuất và phê chuẩn (ratification).
Một provisioner khóa DUSK dưới dạng stake và sau đó có thể trở nên đủ điều kiện tham gia vào đồng thuận. Dusk’s deterministic sortition (phân loại tất định) sẽ chọn bộ tạo khối và các thành viên ủy ban bỏ phiếu thông qua một quy trình được cân theo stake, giúp việc chọn lựa có thể tái tạo trong khi vẫn giữ một mức độ khó đoán nhất định nhờ seed của giao thức.
Phần thú vị là điều gì xảy ra sau khi một khối được đề xuất. Một ủy ban sẽ xác thực nó trong khi một ủy ban khác phê chuẩn kết quả xác thực. Tỷ lệ phiếu hợp lệ siêu đa số tạo ra kết quả thành công, với các chữ ký BLS cho phép các phiếu được tổng hợp thành các xác nhận (attestations) gọn nhẹ.
Sau đó, Dusk sử dụng tính cuối cùng luân chuyển (rolling finality) thay vì coi mọi khối được chấp nhận đều là không thể đảo ngược ngay lập tức. Các khối sẽ tiến qua các trạng thái bao gồm: accepted (được chấp nhận), attested confirmed (được xác nhận qua attestation), và cuối cùng là final (cuối cùng). Một khối cuối cùng không thể bị thay thế theo các quy tắc tính cuối cùng của giao thức.
Kiến trúc này cho thấy tính cuối cùng không chỉ đơn thuần là tốc độ. Đó là việc phối hợp các thành phần tham gia mạng nhằm chứng minh sự đồng thuận và dần dần tăng mức độ tin cậy vào chuỗi.
@Dusk vì vậy đang biến đồng thuận thành một thành phần kiến trúc trong hạ tầng tài chính của mình, không chỉ là một cơ chế bảo mật.

$DUSK #dusk

Tính cuối cùng có thể dự đoán và có thể kiểm chứng quan trọng hơn đối với các blockchain tài chính so với việc chỉ tối đa hóa thông lượng giao dịch?

Điều gì xảy ra trước khi một blockchain có thể đạt được sự đồng thuận?

Trước hết, mạng cần một cách tin cậy để chuyển thông tin giữa các nút.
Đây là lúc Kadcast trở thành một phần quan trọng trong kiến trúc của Dusk.
Theo tài liệu whitepaper của Dusk, Kadcast là lớp truyền thông ngang hàng (peer-to-peer) chịu trách nhiệm phát quảng bá (broadcast) các khối (blocks), giao dịch (transactions) và các phiếu bầu cho sự đồng thuận (consensus votes). Nó được xây dựng trên bảng băm phân tán Kademlia (Kademlia distributed hash table) sử dụng khoảng cách XOR để tổ chức cách các nút giao tiếp.
Điểm thú vị nằm ở thiết kế phát quảng bá của nó. Thay vì để mọi nút chuyển tiếp (forward) tin nhắn đến tất cả các hàng xóm, Kadcast sử dụng các peer được chọn ở các khoảng cách tăng dần và tổ chức sự lan truyền thông qua các cây multicast. Mục tiêu là mở rộng phạm vi phủ sóng của mạng với ít lần truyền dư thừa hơn
Điều này quan trọng vì hiệu quả truyền thông trực tiếp ảnh hưởng đến tốc độ thông tin có thể lan truyền trong một mạng phi tập trung. Dusk đặc biệt thiết kế Kadcast cho các môi trường nơi tài nguyên mạng và giao tiếp độ trễ thấp là yếu tố then chốt. Whitepaper cũng ghi nhận rằng cấu trúc của nó có thể tự nhiên che giấu điểm nguồn của thông điệp bằng cách tránh các kết nối peer-to-peer trực tiếp.
Vì vậy, Kadcast không chỉ là một chi tiết về mạng lưới. Nó là một phần nền tảng kết nối lớp giao dịch (transaction layer) của Dusk với cơ chế đồng thuận (consensus mechanism).
Với @Dusk , truyền thông hiệu quả rốt cuộc là tạo ra các điều kiện cho sự phối hợp đáng tin cậy trên toàn mạng.

$DUSK
#dusk

Khi các mạng blockchain mở rộng quy mô, liệu kiến trúc truyền thông có trở nên quan trọng ngang bằng với chính sự đồng thuận không?

Điều gì thực sự tạo nên sự khác biệt của một kiến trúc blockchain?
Với Dusk, câu trả lời không nằm ở một tính năng đơn lẻ. Đó là cách nhiều lớp được thiết kế để phối hợp với nhau.
Ở nền tảng là DuskDS, lớp đồng thuận cuối cùng (consensus finality) và sẵn có dữ liệu của mạng. Ở phía trên, Dusk hỗ trợ hai nhánh thực thi khác biệt: DuskVM nơi các hợp đồng Rust/WASM được thực thi trực tiếp trên Dusk L1 và DuskEVM cung cấp môi trường EVM, đồng thời sử dụng DuskDS cho việc thanh toán (settlement) và sẵn có dữ liệu.
Lớp mạng cũng rất quan trọng. Dusk sử dụng Kadcast để lan truyền các khối, giao dịch và phiếu bầu đồng thuận. Cách tiếp cận có cấu trúc của nó được thiết kế nhằm giảm sự trùng lặp thông điệp và cải thiện hiệu quả truyền thông mạng.
Tiếp theo là lớp giao dịch. Moonlight cung cấp các giao dịch dựa trên tài khoản công khai, trong khi Phoenix cung cấp mô hình UTXO được che chắn (shielded). Điều này có nghĩa là quyền riêng tư không được xem như một phần “làm sau”; nó là một phần của kiến trúc giao dịch của giao thức.
Sự kết hợp đó là lý do khiến @Dusk
trở nên thú vị để phân tích. Thay vì ép mọi ứng dụng phải phù hợp với một mô hình thực thi duy nhất, Dusk tách riêng mạng, đồng thuận, thanh toán (settlement), thực thi và quyền riêng tư giao dịch thành các thành phần bổ trợ.
$DUSK nằm trong kiến trúc này như tài sản gốc (native asset) cho phí giao dịch và staking.
Câu hỏi sâu hơn là liệu kiến trúc mô-đun này có mang lại cho Dusk một lợi thế có ý nghĩa khi hạ tầng blockchain phát triển hay không?
#dusk

Tại sao tài chính truyền thống cần một blockchain được thiết kế khác ngay từ đầu?

Thách thức không chỉ đơn thuần là đưa tài sản tài chính lên chuỗi (on-chain). Các thị trường tài chính cần đồng thời: khả năng kiểm toán tính riêng tư (privacy auditability), tuân thủ quy định (regulatory compliance), khả năng mở rộng (scalability) và tính cuối cùng đáng tin cậy (reliable finality). Whitepaper của Dusk xem đây là một bài toán hạ tầng cốt lõi: thông tin tài chính nhạy cảm không phải lúc nào cũng có thể được công khai, nhưng các tổ chức vẫn cần những cơ chế hỗ trợ giám sát và tuân thủ.

Đó là lý do @Dusk
đưa ra một hướng tiếp cận kiến trúc khác.

Thay vì coi sự riêng tư như một lớp “bên ngoài”, Dusk tích hợp nó trực tiếp vào mạng thông qua các mô hình giao dịch. Moonlight cung cấp mô hình minh bạch dựa trên tài khoản (account-based), trong khi Phoenix sử dụng thiết kế dựa trên UTXO cho các giao dịch được che chắn (shielded transactions). Whitepaper cũng mô tả Succinct Attestation như một cơ chế đồng thuận được thiết kế để đạt tính cuối cùng trong vài giây, hướng tới yêu cầu độ trễ thấp của các thị trường tài chính.
Điểm quan trọng là Dusk không trình bày việc áp dụng blockchain như chỉ là một vấn đề thuần kỹ thuật. Nó đang cố gắng giải quyết các yêu cầu của tổ chức—những yếu tố quyết định liệu hạ tầng tài chính có thực sự vận hành được trên chuỗi hay không.

Điều đó khiến $DUSK trở nên thú vị để nghiên cứu vượt ra khỏi vai trò token: câu hỏi thực sự là liệu “quyền riêng tư, tuân thủ và thực thi-native trên blockchain” có thể cùng tồn tại mà không buộc các tổ chức phải thỏa hiệp với bất kỳ yếu tố nào trong số đó.

#dusk

Liệu hạ tầng blockchain có thực sự đáp ứng đồng thời cả tuân thủ của tổ chức lẫn quyền riêng tư của người dùng ở quy mô lớn không?