x_Trader_

#dusk $DUSK @Dusk

Hãy đọc lại phần “implementation” của whitepaper hai lần trong tuần này. Lần đầu, tôi lướt qua luôn đoạn nói về “host functions”, cứ nghĩ đó chỉ là một chi tiết kỹ thuật nhỏ về cách VM được xây dựng. Lần hai, giả định đó không còn đúng nữa.

Tôi đã xem hai khẳng định “smart contracts chạy trong một VM” và “các thao tác mật mã chạy trong một VM” là cùng một chuyện. Không phải. Và khoảng cách giữa hai quan điểm đó chính là quyết định thiết kế thú vị.

Piecrust, VM của Dusk, chạy contract trên WebAssembly. Nhưng nó không thực hiện phần nặng nhọc về mật mã—băm (hashing), xác minh (verify) ZK proof, kiểm tra chữ ký—bên trong sandbox WASM đó. Thay vào đó, phần này được rút ra và xử lý “native” thông qua các hàm được cung cấp như verify_plonk và verify_groth16_bn254. Contract gọi đến chúng, nhưng phép toán tốn kém không hề đụng tới môi trường ảo hóa.

Vì sao điều này không phải là một chi tiết triển khai nhỏ. Các nghiên cứu về việc thực thi WASM mà whitepaper trích dẫn cho thấy mã được ảo hóa có thể chạy chậm hơn 45–255% so với mã native trong các phép toán phức tạp—độ trễ này được “nhồi” sẵn vào cách bộ nhớ và tập lệnh của sandbox hoạt động, chứ không phải thứ có thể tối ưu bỏ đi.

Vì vậy, các giao dịch bí mật (confidential transactions), vốn dựa vào xác minh ZK proof cho hầu như mọi thứ, sẽ phải “trả” khoản thuế thời gian đó cho mọi giao dịch nếu việc xác minh chạy trong VM giống như một lệnh gọi contract thông thường.

Đó là mối liên hệ quay trở lại với thiết kế về quyền riêng tư. “Quyền riêng tư có thể lập trình” không chỉ là một lựa chọn mật mã; nó cũng là một ràng buộc về hiệu năng—nếu việc xác minh proof chậm, “riêng tư và tuân thủ” một cách âm thầm sẽ trở thành “riêng tư và tuân thủ, cuối cùng thì không còn.” Việc kéo mật mã ra khỏi contract và đưa vào host functions là thứ giúp quyền riêng tư không trở thành một “khoản thu” thêm cho mọi giao dịch, thay vì là một thuộc tính của nó.

Có ai thực sự đã đo benchmark con số thực tế của Piecrust ở ngoài đời chưa, hay “tránh overhead WASM” vẫn chỉ dựa trên nghiên cứu chung được trích dẫn, chứ chưa có dữ liệu riêng cho Dusk?"

#dusk
Tôi từng giả định thiết kế rollup của DuskEVM về cơ bản là một chi tiết kỹ thuật — sequencer, batcher, base layer, gì thì gì. Sau đó tôi đem mô hình tranh chấp của nó đối chiếu với cách Arbitrum và Optimism xử lý, và giả định đó đã sụp đổ.
Rollup lạc quan (optimistic rollups) mặc định không tự xác minh. Chúng chỉ xác minh khi có “challenge”. Một sequencer đăng ký cam kết trạng thái. Bất kỳ ai cũng có thể gửi bằng chứng gian lận (fault proof) chống lại cam kết đó. Nếu bằng chứng đúng, trạng thái sai sẽ bị loại bỏ và trái phiếu (bond) của sequencer bị cắt. Nếu không ai thách thức kịp trong thời gian, nó sẽ được coi là cuối cùng (final) — cho dù thực sự có đúng hay không.
Đây là điều mà tôi chưa kịp nối lại cho đến khi đặt các con số cạnh nhau. Arbitrum và Optimism đều áp đặt cửa sổ rút tiền 7 ngày — không phải một hạn chế, mà là một “đệm” được thiết kế để đủ thời gian cho gian lận có thể được phát hiện và nổi lên. Còn zk-rollups thì bỏ qua điều đó: bằng chứng tính đúng (validity proof) được kiểm tra về mặt toán học ngay khi nộp, nên không còn gì để tranh chấp.
DuskDS hoàn tất các block ở base layer chỉ trong vài giây. Tôi tưởng tốc độ đó cũng tự động “chạy lên” tầng rollup. Không phải vậy. Cửa sổ tranh chấp vận hành theo một “đồng hồ” riêng, độc lập với việc lớp bên dưới kết toán nhanh đến mức nào.
Vì vậy, phép so sánh thực sự không phải là “DuskEVM vs. rollups của Ethereum.” Mà là “bảo mật dựa trên tranh chấp (dispute-based security) vs. bảo mật dựa trên toán học (math-based security),” và DuskEVM đã chọn cùng phía với Arbitrum và Optimism.
$DUSK
@Dusk
Cửa sổ challenge thực tế của DuskEVM là gì — có khớp với chuẩn 7 ngày hay ngắn hơn vì tính cuối cùng (finality) ở tầng bên dưới nhanh hơn?

#dusk $DUSK

Tôi nghĩ Piecrust, “máy ảo” của Dusk, chỉ đơn giản ở đó để chạy smart contract. Công việc tương tự như mọi VM khác — thực thi mã, lưu trạng thái, xong. Hóa ra đó có thể chỉ là một nửa những gì nó thực sự làm.

Đào sâu vào tài liệu, Piecrust cung cấp một tập các hàm host (hàm do hệ thống cung cấp).

là các operation mà VM chuyển giao sang code native thay vì chạy bên trong môi trường WASM được sandbox.
Hashing, qua Blake2b và Poseidon.
Xác minh các proof zero-knowledge PlonK và Groth16.
Xác thực chữ ký Schnorr và BLS.
Không cái nào trong số đó chạy như bytecode contract thông thường.

Tại sao một VM lại đi out of its way (đi out of its way) để chuyển hướng các thao tác cụ thể ra khỏi chính nó thay vì cứ chạy hết theo cách bình thường?

Hóa ra việc thực thi WASM có thể chậm hơn code native từ 45–255% đối với các tác vụ nặng về tính toán; phần chậm đến từ quản lý bộ nhớ được ảo hóa và việc xử lý thêm các chỉ lệnh mà môi trường sandbox yêu cầu.
Với một chain mà việc xác minh ZK proof không phải thỉnh thoảng, mà gần như diễn ra trong hầu hết mọi giao dịch, thì việc chạy phép tính đó trong WASM thay vì chạy native không phải là khoản phí nhỏ.
Nó tích lũy dần, block sau block.
Nguyên tắc tương tự được áp thẳng sang DuskEVM — lớp tương thích EVM, đưa các nhà phát triển Solidity đến với Dusk.

Hedger, module thực thi bí mật (confidential execution), dựa vào mã hóa đồng cấu (homomorphic encryption) kèm theo ZK proofs để giữ cho giao dịch được riêng tư; nhưng bản thân mọi thứ đó sẽ không đủ nhanh để tạo ra khác biệt nếu không có các native host functions phía dưới làm nặng đầu tiên.
Vì vậy Piecrust không chỉ là nơi hợp đồng được thực thi. Nó còn là làn đường nhanh dành cho đúng các phép toán mật mã @Dusk phụ thuộc vào nhiều nhất, được cố tình giữ ngoài “đường chậm”, và chính làn đường nhanh đó mới khiến lớp quyền riêng tư của DuskEVM trở nên khả thi — không chỉ cho các contract “native” của Dusk.

Điều này làm tôi tự hỏi — có bao nhiêu VM “đa năng” khác đang âm thầm ăn một khoản phí kiểm chứng proof mà không ai bận rộn đo lường?

#dusk $DUSK @Dusk
Hoàng hôn có hai mô hình giao dịch, và tôi cứ tiếp tục coi chúng như một hệ thống quyền riêng tư nhưng có hai cái tên.
Tôi đã quay lại xem tài liệu vì điều đó không hoàn toàn hợp lý. Hóa ra họ đang giải quyết hai vấn đề khác nhau.

MOONLIGHT là mô hình minh bạch: dựa trên tài khoản, có số dư hiển thị, người gửi, người nhận và số tiền. Phù hợp khi luồng giao dịch được cho là có thể quan sát được.

PHOENIX hoạt động hoàn toàn khác. Nó dựa trên UTXO, nên tiền tồn tại dưới dạng các ghi chú được che chắn (shielded notes) thay vì một số dư đang chạy có thể nhìn thấy. Thay vì tiết lộ chi tiết giao dịch, mạng sẽ xác minh một bằng chứng zero-knowledge rằng việc chi tiêu là hợp lệ, bao gồm cả việc số tiền tồn tại và không bị chi tiêu hai lần.

Phần tôi thấy thú vị hơn:
Không cái nào là phương án dự phòng cho cái kia.

Cả hai đều là mô hình giao dịch gốc trên DuskDS và cùng được đối chiếu (settle) trên một chuỗi. Một hồ sơ ví có thể quản lý đồng thời một tài khoản Moonlight và một tài khoản Phoenix.

Vì vậy, quyền riêng tư không phải là một tùy chọn bật lên một lần.
Nó là lựa chọn ở cấp độ giao dịch.
Muốn chuyển khoản hiển thị? Moonlight.
Cần che chắn cả số tiền lẫn các bên tham gia? Phoenix.

Và nếu một bên được ủy quyền cần bằng chứng sau này, Dusk hỗ trợ tiết lộ chọn lọc thông qua viewing keys.

Đó là một lựa chọn thiết kế khá khác so với việc lấy một mô hình giao dịch rồi gắn thêm một lớp quyền riêng tư vào nó.
Nhưng nó khiến tôi có một câu hỏi mà thực sự tôi đang tò mò:
Khi Dusk mở rộng quy mô, việc duy trì hai mô hình giao dịch hoàn toàn khác nhau có trở thành một thế mạnh hay sẽ là một gánh nặng kỹ thuật dài hạn?
Và trong sử dụng thực tế, các thị trường được quản lý có thực sự cần cả hai không — hay cuối cùng một cái sẽ làm phần lớn công việc?

#dusk $DUSK @Dusk
Tuần này hãy đọc lại phần “consensus” của whitepaper hai lần, liên tiếp. Nhưng lần đầu thì… chẳng có gì mới cả.
Lần thứ hai, một điều mà tôi đã hiểu sai cuối cùng cũng đã “click” ra.
Tôi đã từng coi “một khối đã được bỏ phiếu thông qua” và “một khối LÀ cuối cùng” như thể là cùng một sự kiện. Không phải vậy. Giữa chúng có một khoảng trống, và chính ở đó là phần tư duy bảo mật thú vị.
Một khối vượt qua xác thực và phê chuẩn (ratification) chỉ trở thành ĐƯỢC CHỨNG NHẬN (ATTESTED) khi mọi nỗ lực trước đó trong cùng lượt (round) đều đã thất bại một cách “sạch sẽ”. Nếu không, nó sẽ được “chấp nhận” (accepted), vốn là trạng thái yếu hơn. Về lý thuyết, một khối đã được chấp nhận vẫn có thể bị thay thế bởi một khối đối thủ từ một nỗ lực trước đó. Còn khối đã được chứng nhận thì không.
Sau đó, tính cuối cùng (finality) được hình thành theo từng giai đoạn.
Khối được chứng nhận sẽ được xác nhận (confirmed) khi các khối sau đó được xây dựng trên nó. Khối đã được chấp nhận cần nhiều lần xác nhận hơn để đạt cùng trạng thái, xấp xỉ gấp đôi số lần nỗ lực thất bại nằm phía sau nó.
Chỉ khi một khối đã được xác nhận, và tất cả những khối trước nó cũng đều đã cuối cùng, thì nó mới thực sự trở thành “final”.
Vậy “final” không phải là một sự kiện duy nhất xảy ra khi phiếu bầu thông qua. Đó là một ngưỡng được vượt qua theo từng khối, và tốc độ bạn chạm đến ngưỡng đó phụ thuộc phần nào vào mức độ “sạch sẽ” của round.
Đây là chỗ staking loops back lại.
Việc ai được chọn để bỏ phiếu, và ai trong một ủy ban có đủ tín dụng (credits) để ảnh hưởng đến một quorum, tác động đến việc các round có “trôi qua” sạch sẽ đến đâu. Một round lộn xộn không chỉ làm mọi thứ chậm lại theo kiểu mơ hồ. Nó đẩy mốc thời gian tính cuối cùng (finality timeline) ra xa theo một cách cụ thể, đếm được.
Không có hai cơ chế tách rời “chọn lọc” và “tính cuối cùng” nằm cạnh nhau trong whitepaper. Cơ chế thứ nhất quyết định ai sẽ bỏ phiếu. Cơ chế thứ hai quyết định khi nào phiếu của họ trở nên không thể đảo ngược.
Đó là phần tôi thấy thú vị.
Và tôi có hai câu hỏi mà tôi thật sự tò mò:
Việc phân tầng tính cuối cùng này có tạo ra một “cửa sổ rủi ro” đáng kể trong thực tế không, hay chủ yếu chỉ là một khác biệt mang tính lý thuyết?
Và với các chứng khoán được quản lý (regulated securities), “final trong vài khối” có thực sự đủ tốt, hay tài chính thực sự cuối cùng sẽ đòi hỏi một mức độ cuối cùng gần như ngay lập tức?

#dusk
Dưới đây là một vài chi tiết về tài chính được quản lý khiến tôi ngạc nhiên hôm qua, khi tôi đang lướt qua tài liệu Dusk trong giờ ăn trưa.
Phần lớn hạ tầng blockchain được quản lý thực ra không phải là công khai.
Nó là được cấp phép.
Một sổ cái riêng, do một tổ chức vận hành, chỉ tình cờ sử dụng công nghệ dạng blockchain ở phía dưới. Nhìn thì có vẻ phi tập trung trong bản pitch deck.
Nhưng thực sự thì không.
Có một lý do cho điều đó — các cơ quan quản lý thận trọng với các chuỗi công khai, không cần cấp phép cụ thể.
Không có bên đơn lẻ nào kiểm soát được ai là người xác thực, ai có thể xem được gì, và ai có thể bị quy trách nhiệm nếu mọi thứ đi sai.
Đó là toàn bộ điểm của một chuỗi công khai, và cũng chính là điều khiến cơ quan quản lý lo lắng.
Vì thế, 21X đã thu hút sự chú ý của tôi.
21X là công ty đầu tiên nhận được giấy phép DLT-TSS theo quy định của châu Âu cho một thị trường chứng khoán được token hóa hoàn toàn. Giấy phép này làm được hai việc: cho phép họ gộp giao dịch và thanh toán thành một bước thay vì đối soát sau đó, và cho phép họ vận hành trên một chuỗi công khai, không cần cấp phép — không phải một chuỗi riêng được “đắp” để trông giống phi tập trung.
Đó là phần khiến tôi cứ phải suy nghĩ mãi. Hầu hết các nền tảng được quản lý đều xin cấp phép bằng cách giữ mọi thứ khép kín. 21X lại được phép dùng đúng “thứ thật”.
Vai trò của Dusk ở đây là quan hệ đối tác tham gia giao dịch — 21X dự định tích hợp DuskEVM như một trong các chuỗi mà họ hỗ trợ. Một bên là quyền truy cập vào miễn trừ theo quy định của họ, bên kia là hạ tầng của Dusk. Không bên nào có được toàn cảnh nếu chỉ nhìn từ phía mình.
Tokenization chưa bao giờ là phần khó.
Phần khó là được phép chạy trên hạ tầng mà không ai kiểm soát.
21X đã “bẻ khóa” được điều đó ở tầng quản lý.
Còn Dusk bẻ khóa ở tầng giao thức (thanh toán xác định, công bố chọn lọc).
Cùng một bức tường, nhưng nhìn từ phía khác.
Câu hỏi thật sự:
Giấy phép Công khai–Không cần cấp phép có phải là hiếm, hay quy định chỉ đang bắt kịp? Và nếu nhiều cơ quan quản lý theo chân 21X, liệu "tuân thủ" sẽ định nghĩa lại crypto, hay crypto chỉ trở thành một lớp hạ tầng vô hình?
$DUSK @Dusk

Đoán xem giấy phép của 21X có gì bất thường 🔍

Gần đây, thông báo chiến dịch về #dusk đã khiến tôi đặt câu hỏi về một trong những từ ưa thích của giới crypto: tính kết hợp (composability).
Chúng ta thường nói về tính kết hợp như thể càng “ghép” được nhiều thì tự động càng tốt.
Một token nên có thể di chuyển giữa các giao thức, trở thành tài sản thế chấp, tương tác với DeFi, bắc qua các chuỗi (cross-chain), cắm vào các ứng dụng mới...
Với một tài sản “bình thường” không yêu cầu cấp phép (permissionless) thì đúng là như vậy.
Nhưng hãy tưởng tượng làm điều đó với một trái phiếu được quản lý (regulated bond).
Trái phiếu có thể có các yêu cầu đủ điều kiện đối với nhà đầu tư, các hạn chế chuyển nhượng, quy tắc về thẩm quyền pháp lý và nghĩa vụ công bố thông tin.
Vì thế, cụm “làm cho nó có tính kết hợp với mọi thứ” đột nhiên nghe bớt ấn tượng.
Vấn đề thú vị là làm cho nó có tính kết hợp mà không cắt bỏ các quy tắc gắn liền với tài sản.
Đó là chỗ Dusk trở nên khá kỹ thuật.
Kiến trúc hiện tại của họ tách lớp thanh toán/dữ liệu, DuskDS, khỏi DuskEVM—một môi trường EVM dựa trên OP Stack. Các nhà phát triển có thể sử dụng bộ công cụ Solidity quen thuộc, trong khi các ứng dụng sẽ thực hiện thanh toán trở lại trên mạng nền tảng của Dusk. Hedger bổ sung các quy trình EVM bảo mật bằng mã hóa đồng cấu (homomorphic encryption) và bằng chứng không kiến thức (zero-knowledge proofs).
Ngoài ra còn phần khía cạnh pháp lý.
Thông qua mối quan hệ NPEX, Dusk cho biết hệ sinh thái có quyền truy cập các giấy phép MTF, Broker và ECSP, đồng thời giấy phép DLT-TSS đang trong tiến trình. Ý tưởng là đặt việc phát hành, đầu tư, giao dịch và thanh toán được quản lý vào một khung pháp lý và kỹ thuật dùng chung.
Và đây không chỉ là “kiến trúc” trên một slide.
Hiện Dusk báo cáo đã có hơn €300M phát hành được xác nhận với các tổ chức, mức độ tiếp cận nhà đầu tư 50K+, đã stake 210M+ DUSK và có thời gian tất toán tất định ~10 giây.
Điều đó thay đổi hoàn toàn câu hỏi của tôi.
Tôi ít quan tâm đến việc hỏi:
“Liệu RWA có thể có tính kết hợp không?”
Chúng ta đã biết là chúng có thể di chuyển qua lại.
Tôi muốn biết:
“Liệu một tài sản được quản lý có thể vẫn giữ được tính kết hợp trong khi mang theo danh tính, điều kiện đủ tư cách, quyền riêng tư và các quy tắc chuyển nhượng của nó không?”
Bởi vì nếu câu trả lời là “có”, thì nó bắt đầu giống ít hơn với việc đưa chứng khoán lên một blockchain...
và giống hơn với việc xây dựng lại “đường ống” (plumbing) tài chính xung quanh chúng.

$DUSK @Dusk

#dusk $DUSK @Dusk

Trước đây tôi từng nghĩ “tính hoàn tất (finality) của blockchain” có ý nghĩa giống nhau ở mọi nơi. Nhưng không phải.
Trên nhiều chuỗi, việc một khối được thêm vào không hẳn là kết thúc câu chuyện. Nó vẫn có thể bị tổ chức lại (reorg) hoặc bị thay thế nếu sau đó xuất hiện một chuỗi dài hơn. Với một giao dịch chuyển nhượng thông thường, đó là rủi ro nền mà bạn gần như không bao giờ nghĩ tới. Nhưng với việc thanh toán tài chính thực sự, một khoản thanh toán trái phiếu, một giao dịch, bất cứ thứ gì có gắn trọng lượng pháp lý đi kèm, thì “có lẽ là đã hoàn tất” không thể là câu trả lời chấp nhận được.
Sự đồng thuận (consensus) của Dusk hoạt động theo ba bước. Một trình xác thực đề xuất một khối. Một ủy ban kiểm tra xem nó có hợp lệ không. Một ủy ban thứ hai xác nhận rằng việc kiểm tra đó thực sự đã diễn ra. Khi cả ba bước hoàn tất, khối coi như đã xong. Không phải “xong, có lẽ”, mà là xong. Không có chuyện vài khối sau lại còn chờ khả năng reorg.
Không ai viết tiêu đề về cơ chế đồng thuận. Nhưng đây là phần “không hào nhoáng” giúp một sàn giao dịch được quản lý có thể nói với khách hàng “đã thanh toán/đã hoàn tất” và nói điều đó theo đúng nghĩa đen, không phải “đã thanh toán, trừ khi có một sự kiện khó xảy ra xảy ra sau 3 khối nữa”.
Thanh toán tức thì chỉ thực sự quan trọng nếu nó thực sự là final. Đây là phần mà đa số các bản pitch về token hóa bỏ qua.
Poll:
Đoán xem điều gì xảy ra khi một khối đạt ngưỡng (quorum) trên Dusk 🧠

⏳ Vẫn có thể bị đảo ngược sau đó
✅ Đã final — không có reorg
📅 Chờ 2 ngày để làm sạch
⛽ Phụ thuộc vào giá gas

#dusk
Tôi nghĩ đôi khi mọi người hiểu sai vấn đề quyền riêng tư trong tài chính được quản lý.
Nó không chỉ đơn giản là:
“Làm sao để ẩn giao dịch?”
Câu hỏi khó hơn là:
“Thực sự ai cần phải xem nó?”
Một nhà đầu tư không nhất thiết phải để lộ toàn bộ vị thế của mình cho mọi ví đang theo dõi chuỗi.
Nhưng một cơ quan quản lý có thể cần xác minh điều gì đó.
Một kiểm toán viên có thể cần bằng chứng.
Một tổ chức phát hành có thể cần kiểm tra quyền sở hữu hoặc tính đủ điều kiện.
Và chính thị trường vẫn cần những thứ có thể quan sát và được đối soát.
Đó là phần @Dusk mà tôi thấy thực sự thú vị.
Dusk không xử lý quyền riêng tư như một công tắc bật/tắt. Kiến trúc của họ tách các luồng công khai khỏi các luồng bảo mật, đồng thời cho phép thông tin được tiết lộ cho các bên được ủy quyền khi có lý do chính đáng để họ xem.
Cách đó với tôi còn hợp lý hơn cho các thị trường tài chính.
Vì việc đưa trái phiếu, quỹ hoặc chứng khoán khác lên onchain không phải là phần khó.
Phần khó là quyết định điều gì xảy ra khi những người khác nhau cần các mức độ minh bạch khác nhau đối với cùng một tài sản.
Đó là vấn đề mà phần lớn các cuộc trò chuyện về crypto không dành đủ thời gian để bàn.
Dusk đang xây dựng xoay quanh vấn đề đó.
Và với DuskEVM, cách tiếp cận này đang được đưa vào một môi trường tương thích EVM, với Hedger hỗ trợ các quy trình EVM bảo mật.
Đó là một “pitch” còn thú vị hơn nhiều so với “blockchain, nhưng riêng tư.”

$DUSK @Dusk

Trước đây tôi nghĩ rằng sự khó đoán trong một blockchain là một lỗi bạn chấp nhận, chứ không phải một tính năng bạn thực sự thiết kế.
Việc nghiên cứu Dusk đã thay đổi điều đó.
Hãy tưởng tượng bạn là một trình cấp phát. Bạn đã stake, bạn đủ điều kiện, bạn biết rằng mình có thể được chọn để tạo khối tiếp theo. Nhưng bạn không biết liệu mình có được chọn hay không. Không ai khác biết điều đó. Không phải các validator khác. Thậm chí không phải chính bạn, mười giây trước khi sự kiện xảy ra.
Điểm kỳ lạ nằm ở đây: hạt giống quyết định ai được chọn cho khối N+1 vẫn chưa tồn tại khi khối N đang được xây dựng. Nó được tạo ra từ chữ ký của bộ tạo khối của khối hiện tại — tức là dựa trên seed trước đó. Câu trả lời cho "ai là người tiếp theo" không nằm đâu đó sẵn — nó chưa hề được tính toán.
Tại sao điều này lại quan trọng? Vì ở đây, khả năng đoán trước là một rủi ro, không phải một sự tiện lợi. Nếu kẻ tấn công có thể xác định được hôm nay ai sẽ tạo khối 40, chúng sẽ có cả một khoảng thời gian dài để nhắm mục tiêu validator đó — hối lộ họ, DDoS họ, gây sức ép lên họ — trước khi khoảnh khắc xảy ra.
Sortition quyết định của Dusk đóng hoàn toàn cánh cửa đó. Bạn chỉ biết rằng mình là bộ tạo ngay khi điều đó đã trở thành sự thật.
Vì vậy, câu hỏi thiết kế thực sự không phải "làm sao để chọn một người lãnh đạo". Mà là "làm sao để chọn một người mà không bao giờ cho phép bất kỳ ai lên kế hoạch cho việc đó."
Đoán xem điều gì xảy ra ngay khi việc chọn khối trở nên có thể dự đoán sớm hơn một chút?

#dusk $DUSK @Dusk

Khảo sát:
Đoán xem điều gì sẽ hỏng đầu tiên nếu bạn có thể dự đoán bộ tạo khối tiếp theo
🎯 Hối lộ trở nên khả thi
🛑 DDoS trở nên khả thi
⚖️ Cả hai, cùng một lỗ hổng
🔒 Không có gì, vẫn an toàn

Có người trong phần bình luận đã hỏi tôi một điều mà tôi không thể gạt bỏ:
Làm sao bạn thực sự biết rằng một trái phiếu đã được token hóa trên Dusk vẫn được hậu thuẫn bằng tài sản thật sau sáu tháng kể từ khi ra mắt? Bằng chứng ZK sẽ không trả lời điều đó.
Chúng xác nhận một giao dịch đã tuân theo các quy tắc — số dư đúng, không gian lận chi tiêu kép.
Chúng không thể cho bạn biết liệu trái phiếu thật nằm sau token vẫn còn tồn tại hay vẫn đủ khả năng thanh toán.
Đó là một vấn đề niềm tin khác, và đó là lý do @Dusk hoạt động với Chainlink.
Khi một thứ đã được token hóa, vẫn có ai đó phải liên tục cập nhật dữ liệu thế giới thực lên chuỗi — giá cả, dự trữ, bằng chứng về sự hậu thuẫn — chứ không chỉ tại thời điểm phát hành.
Về cơ bản, đó là những gì một oracle (bộ tiên tri) làm: đường ống đưa sự thật bên ngoài vào một hệ thống vốn chỉ biết những gì được viết bên trong chính nó.
Trước đây tôi từng cho rằng "on-chain" có nghĩa là "mặc định đáng tin".
Không phải vậy.
Nó có nghĩa là được xác minh mặc định, và việc xác minh chỉ bao phủ những gì thực sự nằm trên chuỗi.
Bất cứ điều gì từ thế giới bên ngoài đều phải được đưa vào một cách chủ ý — và đó là phần mà mọi người bỏ qua khi họ nói về các RWA như thể đã xong.
Mật mã chứng minh rằng phép tính đúng.
Các oracle chứng minh rằng thế giới ở phía dưới nó chưa âm thầm thay đổi. $DUSK cần cả hai để "trái phiếu token hóa" có ý nghĩa sau nhiều tháng, chứ không chỉ vào ngày đầu.

#dusk $DUSK @Dusk

Đến lượt bạn: Đoán xem một oracle của Chainlink thực sự đưa gì vào Dusk
🔗 Dữ liệu giá/dự trữ ngoài thực tế
🔐 Bản thân bằng chứng ZK
🏦 Phê duyệt theo quy định
⚡ Xác nhận cuối cùng của giao dịch

Đây cũng là lý do tại sao thời điểm lại quan trọng — mainnet DuskEVM cần phải hoạt động ổn định và sẵn sàng trước khi một sàn giao dịch như NPEX có thể thực sự định tuyến các tài sản thực qua nó. Quan hệ đối tác và kế hoạch triển khai hạ tầng đang chạy theo cùng một tiến độ."
$DUSK

🧧 Bao lì xì đỏ hôm nay đã mở bán! 🧧
Miễn phí crypto, không ràng buộc—nhận ngay trước khi hết 🎁
⏰ Chỉ trong hôm nay
🔥 Số lượng bao lì xì có hạn

📰 Tóm tắt thị trường:
BTC đang giao dịch giảm trên diện rộng trong một phiên cuối tuần yên ắng, tiếp tục đà điều chỉnh đang hình thành kể từ báo cáo lạm phát của tuần này, với Bitcoin hiện quanh mức $62,800, giảm khoảng 1% trong 24 giờ và hơn 3% trong cả tuần.
Báo cáo CPI tháng 7 đúng như kỳ vọng—nhưng đợt “hồi phục” thường thấy lại chưa xuất hiện. Trong khi đó, SEC bất ngờ hủy bỏ cuộc bỏ phiếu vào thứ Sáu về các quy định huy động vốn crypto mới, với lý do trùng lịch trình, khiến ngành đang chờ các khả năng miễn trừ cho các startup tài sản số.
Ngày giảm vẫn là ngày để nhận. Lấy bao của bạn 🍀
$BTC

$ETH

$SOL

#Binance #redpacket #crypto #BTC #FreeCryptoEarnings

Hôm nay quay lại đúng nhóm chat đó mà mình đã tránh né, vì có người phản hồi lại rằng: "à được thôi, Moonlight và Phoenix thì hay đấy, nhưng chỉ là mảng lớp nền thôi.
Vậy cho mình hỏi: chuyện gì xảy ra khi một dev thực sự muốn xây dựng cái gì đó trên đó?"
Phản hồi đó cũng hợp lý, và lần trước mình đã không có câu trả lời đủ thuyết phục.
Hóa ra chính xác là khoảng trống mà DuskEVM được tạo ra để lấp đầy.
Đó là lớp ứng dụng tương thích với EVM nằm bên trên chuỗi lớp nền — nghĩa là một dev Solidity không cần phải học một ngôn ngữ hay bộ công cụ hoàn toàn mới để xây ở đây; họ vẫn có một điểm vào quen thuộc vào một chuỗi đã xử lý sẵn sự tách biệt về quyền riêng tư/tuân thủ ngay từ bên dưới.
Điểm mà mình chưa kịp nhận ra: các môi trường EVM thường mặc định là minh bạch — đó đơn giản là cách mà công cụ vận hành.
Vì vậy, việc gắn một chuỗi có "quyền riêng tư có thể được xem xét" vào một lớp tương thích EVM không hề miễn phí; ai đó phải thực sự giải quyết được khoảng giao tiếp đó.
Đó là Hedger — module quyền riêng tư của Dusk, được xây dựng riêng cho các quy trình EVM bảo mật, dùng mã hóa đồng cấu và các bằng chứng ZK để việc thực thi hợp đồng có thể được giữ kín nhưng vẫn được tiết lộ cho đúng người được ủy quyền để kiểm tra.
Vậy là, stack giờ bắt đầu trở nên rõ ràng theo hướng các lớp chồng lên nhau, chứ không chỉ là một tính năng đơn lẻ. Moonlight/Phoenix lo lựa chọn quyền riêng tư ở cấp giao dịch, DuskEVM cung cấp một lối đi bình thường để vào, và Hedger là phần đảm bảo lối đi đó không vô tình kế thừa mặc định "mọi thứ đều công khai" của EVM.

Lưu ý giống lần trước: DuskEVM mainnet hiện vẫn chưa chạy; nó sẽ được ra mắt. Lời khẳng định của Hedger về "quyền riêng tư có thể được xem xét, không chỉ bị giấu" là mục tiêu thiết kế cho đến khi có các hợp đồng thực sự được chạy qua đó và ai đó đã thực sự kéo cần công tắc tiết lộ trong một quy trình làm việc ngoài đời.

Thật sự tò mò mọi người nghĩ gì nhỉ:
Nếu bạn đang xây dựng trên một chuỗi như thế này, điều gì làm bạn lo nhất?
🔧 Độ trưởng thành của công cụ
🔍 Việc tiết lộ thực sự diễn ra như thế nào
⏱️ Lộ trình mainnet
🤝 Liệu dev có thực sự đến tham gia không

#dusk $DUSK @Dusk

🧧 Cảnh Báo Phong Bao Lì Xì! 🧧
Mình đang thả một Phong Bao Lì Xì của Binance — crypto miễn phí, không có bẫy! 🎁
💰 Nhận ngay trước khi nó biến mất
⏰ Chỉ giới hạn trong thời gian ngắn
🔥 Ai đến trước phục vụ trước
👉 [Dán liên kết/mã Phong Bao Lì Xì của bạn vào đây]
Mới tham gia Binance? Đăng ký và nhận trong vài giây. Chúc may mắn! 🍀
#Binance #crypto #redpacket #FreeCryptoEarnings

#dusk $DUSK @Dusk
Hôm nay quay lại đúng nhóm chat đó vì có ai đó phản hồi lại: "Ừ, Moonlight và Phoenix thì hay đấy, nhưng đó chỉ là các lớp nền tảng. Vậy khi một dev thực sự muốn xây dựng thứ gì trên đó thì sao?"😅
Phản hồi cũng hợp lý, và lần trước tôi đã không có câu trả lời thật sự thuyết phục.
Hóa ra chính xác là khoảng trống mà DuskEVM dành cho. Đây là lớp ứng dụng tương thích EVM nằm ở phía trên chuỗi nền — nghĩa là một dev Solidity không cần phải học một ngôn ngữ hay bộ công cụ hoàn toàn mới để xây ở đây; họ có một điểm bắt đầu quen thuộc trên một chuỗi đã xử lý sẵn tách biệt về quyền riêng tư/tuân thủ một cách tự nhiên ngay từ bên dưới.

Phần tôi chưa nhận ra: môi trường EVM thường mặc định là minh bạch, đó là cách bộ công cụ hoạt động.
Nên việc nhét một chuỗi có "quyền riêng tư có thể được kiểm tra" vào một lớp tương thích EVM không phải chuyện miễn phí—ai đó phải thực sự vá được cái khe nối đó.

Đó là Hedger — module quyền riêng tư của Dusk được xây dựng riêng cho các luồng EVM bí mật, dùng mã hóa đồng cấu và các bằng chứng ZK để việc thực thi hợp đồng có thể vẫn riêng tư nhưng vẫn có thể được công bố cho đúng những người được ủy quyền để kiểm tra.

Vậy nên, stack giờ bắt đầu sáng tỏ hơn như các lớp chồng lên nhau, chứ không phải chỉ là một tính năng: Moonlight/Phoenix xử lý lựa chọn quyền riêng tư ở cấp giao dịch, DuskEVM đưa cho người xây dựng một lối vào bình thường, và Hedger là mảnh ghép đảm bảo rằng lối vào đó không vô tình thừa hưởng mặc định "mọi thứ đều công khai" của EVM.

Lưu ý, giống lần trước: mainnet của DuskEVM vẫn chưa hoạt động, nó sẽ sớm ra mắt. Lời khẳng định của Hedger rằng "có thể xem xét được, chứ không chỉ bị ẩn" là mục tiêu thiết kế cho đến khi các hợp đồng thực sự chạy qua nó và ai đó đã gạt đúng cần công bố trên một luồng vận hành trực tiếp.

Thật sự tò mò mọi người nghĩ gì:
Nếu bạn đang xây dựng trên một chuỗi như thế này, điều gì sẽ khiến bạn lo lắng nhất?