AlizehAli

@Dusk ‎ Hiến pháp khai sinh của một quốc gia tồn tại ngay từ khoảnh khắc quốc gia đó ra đời — không ai bỏ phiếu để “sinh ra” nó về sau; nó đơn giản là đã có từ ngày đầu tiên, và mọi thứ khác được xây dựng dựa trên nó.
‎
‎Các hợp đồng khai sinh (genesis) của Dusk hoạt động theo cách tương tự. Tài liệu kiến trúc của chính Dusk mô tả có hai loại: hợp đồng stake, theo dõi những provisioner nào đang stake, ghi nhận phần thưởng, và cho phép các hành động stake, unstake, và rút phần thưởng; và hợp đồng transfer, xử lý cả các lần chuyển Moonlight (công khai) và Phoenix (được che giấu), thanh toán gas, đồng thời đóng vai trò là điểm vào để thực thi giao dịch trực tiếp trên DuskDS.
‎
‎Vai trò nền tảng này còn lan rộng hơn chỉ riêng DuskDS, dù cơ chế cụ thể khác nhau theo từng lớp. DuskEVM, theo tài liệu riêng của Dusk, chuyển DUSK để trả gas thông qua bridge của nó sang Dusk's L1, cuối cùng được “settle” trở lại về DuskDS — một lộ trình liên quan nhưng khác với vai trò trực tiếp của hợp đồng transfer trong các giao dịch native trên DuskDS. Cả hai con đường đều quay về cùng một lớp nền tảng; chúng không phải là cùng một cơ chế. #dusk
‎
‎Tự phê bình: phép so sánh với hiến pháp có một giới hạn thực sự đáng gọi tên. Hiến pháp của một quốc gia có thể được sửa đổi một cách chính thức theo một quy trình xác định. Điều tôi chưa tìm thấy được là liệu các hợp đồng khai sinh của Dusk có tuân theo một “lộ trình sửa đổi” tương đương, rõ ràng hay không, hoặc liệu “genesis” ở đây về mặt chức năng chỉ có nghĩa là vĩnh viễn theo thiết kế — một câu hỏi về quản trị (governance) thực sự, vì giờ đây phần lớn lớp chồng đa tầng (multilayer stack) đang mở rộng của Dusk phụ thuộc vào việc hai hợp đồng này luôn đúng. $DUSK
‎
‎DUSK nên được đánh giá dựa trên việc liệu sự mơ hồ đó có được làm rõ trước khi cần cập nhật các hợp đồng này trong bối cảnh chịu áp lực thực tế hay không, chứ không phải sau khi đã xảy ra.
‎
‎
#dusk $DUSK @Dusk

@TermMax ‎I assumed exercising a profitable option on TermMax Alpha would work one fixed way — payout hits your wallet, done, same as any options platform I'd used before. $BEAT
‎
‎That assumption fell apart once I read that TermMax actually gives two distinct exercise paths. Exercise-Net-Settle closes the position and pays out the net profit directly. Exercise-Delivery instead settles by transferring the underlying asset itself, not cash — you end up actually holding the token your Long or Short position was based on. #TermMax
‎
‎This reframes what "winning" an options trade means here. On most platforms, exercising just means realizing a number. On TermMax, exercising can mean walking away with the actual asset, which matters specifically for early Binance Alpha listings where getting real exposure to the token — not just its price movement — might be the whole point of the trade. $TUT
‎
‎What the docs don't clarify is whether the choice between the two is always available to the trader, or whether it depends on the specific market's configuration at settlement time. $ENA
‎
‎The real test for TMX is whether traders actually understand this choice exists before they exercise, or default to whichever option the interface shows first.
‎
‎Has anyone actually used Exercise-Delivery instead of Net-Settle, and why?
‎

#termmax @TermMax

@Dusk ‎Quay lại phần công bố kiến trúc của Dusk vào tháng 6 năm 2025, và phần khung nội dung đã thay đổi so với định vị trước đó của Dusk.
‎
‎Ba lớp, theo tài liệu hiện tại của Dusk: DuskDS ở lớp nền, đồng thuận, thanh toán, sẵn có dữ liệu, các mô hình giao dịch gốc. DuskEVM ở phía trên, dựa trên OP Stack, tương thích đầy đủ với Solidity. DuskVM đi kèm, các hợp đồng Rust/WASM chạy trực tiếp trên L1 để phục vụ các use case mang tính bản địa về quyền riêng tư. #dusk
‎
‎Điều gì đã thay đổi từ bản thông báo về sự phát triển năm 2025 ban đầu đến hiện tại: Lúc đó, DuskVM được mô tả là “sắp tới”. Tài liệu hiện tại mô tả nó như là hạ tầng đang hoạt động, không còn là một mục trong lộ trình. Riêng biệt, các cập nhật năm 2026 do chính Dusk công bố mô tả dApp chứng khoán được quản lý của NPEX đang được triển khai chủ động trên DuskEVM — tôi muốn nói thật chính xác rằng nội dung này được mô tả như một quá trình triển khai liên tục, chứ không phải thứ mà tôi có thể xác nhận là đã hoàn tất và đi vào vận hành đầy đủ. $DUSK
‎
‎Một chi tiết kết nối cả ba lớp một cách cụ thể, độc lập với trạng thái của quá trình triển khai đó: một token DUSK duy nhất cấp năng lượng cho mọi lớp, và một bridge gốc (do validator vận hành) chuyển giá trị giữa chúng mà không cần tài sản bọc hay bên lưu ký.
‎
‎Đó vẫn là một hệ thống đang phát triển, chưa phải là hệ thống hoàn thiện. Tài liệu của riêng DuskEVM xác nhận rằng hiện tại nó chỉ chạy sequencer-only, chưa có mempool công khai — một giới hạn cụ thể, có mốc thời gian, nằm bên dưới mọi thứ đang được triển khai “trên” nó ngay lúc này.
‎
‎Nếu ai đó đã theo dõi xem quá trình rollout của NPEX thực sự đang tiến triển như thế nào so với kiến trúc này trong thực tế, tôi muốn đối chiếu ghi chú với những gì tôi đã tìm được ở đây.
‎

#dusk $DUSK @Dusk

@TermMax ‎Mình đã dành một thời gian để lập bản đồ cơ chế các tùy chọn của TermMax Alpha, kỳ vọng hồ sơ rủi ro tùy chọn dạng mở thông thường.
‎
‎Nhưng không phải vậy. Going Long có nghĩa là mua một call, Short có nghĩa là mua một put — cả hai đều là giao dịch với một đối tác mà tài liệu gọi là Dual Investment — bên bán option. Max Cost được định nghĩa chính xác là mức phí bảo hiểm (premium) đã trả, chủ yếu được tính bằng USDT. Việc thanh toán diễn ra thông qua Exercise-Net-Settle hoặc Exercise-Delivery, và trong mọi trường hợp, khoản lỗ tối đa có thể xảy ra đã được khóa ngay khi vị thế được mở.
‎
‎Không có thuật ngữ nào trong số đó trông đặc biệt quan trọng khi đứng riêng. Nhưng bối cảnh ra mắt khiến mình phải dừng lại. TermMax Alpha chính thức ra mắt trên mainnet BNB Chain vào ngày 12 tháng 11 năm 2025, do Term Structure Labs xây dựng, được hậu thuẫn bởi Cumberland DRW — một công ty giao dịch theo quy mô tổ chức thực sự, không chỉ là chiêu “liệt kê token”.
‎
‎Sự hậu thuẫn này quan trọng vì sản phẩm thực sự giải quyết điều gì. Khi Binance Alpha niêm yết một token mới, các trader thường phải chờ nhiều tuần trước khi hợp đồng perpetual xuất hiện ở bất kỳ đâu. TermMax Alpha tồn tại đúng để lấp khoảng trống đó — tiếp xúc đòn bẩy với chi phí được giới hạn và đã biết, có sẵn ngay từ ngày token được niêm yết thay vì phải chờ vài tuần sau. #TermMax
‎
‎Điều làm mình chú ý là việc này khiến TermMax Alpha trở thành hạ tầng thực sự mang tính “nhạy thời gian” — mức độ liên quan của nó gắn với tốc độ các đợt niêm yết mới trên Binance Alpha tiếp tục diễn ra, chứ không phải một tính năng tĩnh tại ngồi yên.
‎
‎Mình chưa xác nhận có bao nhiêu thị trường Alpha đang hoạt động trực tiếp hiện tại, hoặc độ chặt chẽ của chênh lệch giá (spread) trên các đợt niêm yết mới nhất.
‎

‎
‎ Long hay Short?
‎
‎

#termmax @TermMax

Hàm băm thân thiện với SNARK do chính đội ngũ của Dusk thiết kế, đặc biệt để băm không va chạm bên trong các mạch zero-knowledge.

5% được chuyển cho người thanh lý như tiền thưởng vì đã thực hiện việc thanh lý

@Dusk ‎Tìm hiểu điều thực sự xảy ra khi một bằng chứng zero-knowledge của Phoenix thất bại khi được kiểm tra, vì hầu hết các giải thích đều dừng ở “bằng chứng được kiểm tra.”
‎
‎Kiến trúc của Dusk xác nhận rằng bằng chứng phải chứng minh các tính chất cụ thể cùng lúc — quyền sở hữu đối với ghi chú đang được chi tiêu, tính toàn vẹn số dư giữa các đầu vào và đầu ra, và không có chi tiêu hai lần — tất cả đều được mã hóa trong cùng một bằng chứng, chứ không được đối chiếu qua các kiểm tra phụ riêng biệt. $DUSK
‎
‎Đó là phần đáng để ngồi với nó. Nếu bất kỳ một trong các tính chất đó không đúng, toàn bộ bằng chứng sẽ thất bại như một đơn vị duy nhất. Không có đường dẫn “được điểm một phần” nơi các kiểm tra số dư vẫn thông qua nhưng quyền sở hữu thất bại một cách âm thầm.
‎
‎Tôi đã đối chiếu ý nghĩa đó trong thực tế: một bằng chứng bị từ chối có nghĩa là giao dịch không bao giờ được đưa vào bất kỳ khối nào. Thời gian chạy không cố gắng “cứu vãn” hay xử lý một phần nó. Giao dịch đơn giản là không xảy ra, và mọi thứ liên quan đến lần thử thất bại đó không được ghi nhận như một thay đổi trạng thái. #dusk
‎
‎Điều tôi chưa xác nhận từ chính tài liệu của Dusk là liệu một bằng chứng thất bại có để lại dấu vết nào trong log mempool mà một người vận hành nút có thể xem lại sau này hay không, hay nó bị loại bỏ hoàn toàn mà không có bất kỳ bản ghi chẩn đoán nào.
‎
‎Bước tiếp theo tôi sẽ kiểm tra: liệu bộ công cụ ví hiện tại của Dusk có hiển thị một lý do cụ thể cho bằng chứng thất bại hay chỉ trả về một lần từ chối chung, vì sự khác biệt đó rất quan trọng đối với bất kỳ ai đang thực sự debug một giao dịch không được thông qua.

#dusk $DUSK @Dusk

@TermMax ‎Tôi đã dành một chút thời gian để lập bản đồ hệ thống ba token của TermMax, và một dòng trong tài liệu đã làm tôi hiểu ra toàn bộ: Giá trị Tài sản thế chấp (Collateral Value) bằng Giá trị GT (GT Value) cộng với chính Giá trị của khoản Vay (Value of the Loan) — trong đó Giá trị GT được định nghĩa là Collateral trừ đi Giá trị của Nợ (Value of Debt). Các token không chỉ là ba đối tượng rời rạc; chúng là những mảnh của một phương trình cần phải cân bằng.
‎
‎FT là một ERC-20, hoạt động như một trái phiếu không phiếu lãi — 110 FT-USDC được đổi lấy 110 USDC khi đáo hạn, vì vậy mua nó với 100 USDC sẽ khóa lợi nhuận 10% trong kỳ hạn một năm. Nhưng tài liệu nêu rõ con số này tỷ lệ theo thời gian đáo hạn, chứ không giữ nguyên cố định — một FT 180 ngày với cùng mức chiết khấu sẽ tương đương khoảng 20% tính theo năm, chứ không phải 10%. XT được định nghĩa còn chính xác hơn cả điều tôi mong đợi: nó không chỉ là “nửa còn lại”, mà là giá trị hiện tại của phần lãi suất mà bên vay phải trả, tách riêng khỏi phần gốc. GT là lớp bọc vị thế — ERC-721, theo dõi tài sản thế chấp và khoản nợ như một đơn vị, bị giới hạn bởi MLTV.
‎
‎Điều làm tôi chú ý là XT không phải “phần đệm” — nó là một công cụ tài chính riêng biệt, thể hiện rủi ro lãi suất một cách độc lập, và được định giá tách riêng với rủi ro phần gốc của FT. Việc tách phần gốc khỏi phần lãi ở cấp độ token là thứ khiến phương trình zero-sum của cả hệ thống giữ được — không có giá trị nào xuất hiện hay biến mất ở bất kỳ đâu trong chuỗi. #TermMax
‎
‎Mảnh ghép còn thiếu đối với tôi là độ sâu của thị trường thứ cấp thực sự dành riêng cho XT, vì nó đang định giá một thứ hẹp như rủi ro lãi suất ngắn hạn thôi.
‎
‎

"Token nào quan trọng nhất với bạn?"

#termmax

@TermMax

@TermMax ‎Tôi đã cho rằng việc thanh lý trên TermMax có nghĩa giống như mọi nơi khác tôi từng dùng — vượt qua đường nguy hiểm, mất toàn bộ vị thế chỉ trong một lần, không có khoảng trung gian.
‎
‎Giả định đó sụp đổ khi tôi đọc công thức thực sự. Kích hoạt thanh lý xảy ra theo một trong hai cách: LTV đạt hoặc vượt ngưỡng LLTV của thị trường, hoặc người vay bỏ lỡ khoản trả nợ theo kỳ hạn cố định, từ đó mở ra một khung thanh lý kéo dài hai giờ, bất kể giá. $ACE
‎
‎Đây là con số đã làm mọi thứ rõ ràng. Nếu nợ chưa thanh toán vượt quá 10.000 USD, người thanh lý bị giới hạn ở mức 50% giá trị tổng nợ cho mỗi sự kiện. Lượng tài sản thế chấp tối đa có thể bị thanh lý được tính bằng tổng tài sản thế chấp nhân với nợ được thanh lý, chia cho tổng nợ — một tỷ lệ được xây dựng sao cho LTV cải thiện sau mỗi lần thanh lý thay vì rơi về 0. Chỉ khi nợ giảm đúng bằng 0 thì thanh lý toàn phần mới xảy ra, và lúc đó phần tài sản thế chấp còn lại sẽ tự động được hoàn trả cho người vay.
‎
‎Hình phạt là 10% giá trị nợ bị thanh lý, được chia đúng làm đôi — 5% cho người thanh lý như phần thưởng, 5% cho vault dự trữ của giao thức.
‎
‎Điều mà tài liệu không nói là tỷ lệ bao nhiêu vị thế thực sự vượt mốc 10.000 USD nợ so với việc vẫn ở dưới mốc đó, nơi giới hạn thậm chí sẽ không được áp dụng. $CLO
‎
‎Thử nghiệm thực sự cho TMX là liệu giới hạn 50% đó có thực sự bảo vệ một cách có ý nghĩa cho các con nợ lớn hay chỉ biến một lần thanh lý thành hai lần nhỏ hơn liên tiếp. $CYS
‎
‎Ai đã theo dõi số lượt thanh lý một phần so với thanh lý toàn phần trên TermMax cho đến nay chưa?
‎

#termmax @TermMax

@Dusk ‎Đã kiểm tra cách Dusk định vị mình so với Ethereum một cách cụ thể, vì hầu hết các so sánh với chuỗi quyền riêng tư thường mặc định nhắc đến Zcash hoặc Monero.
‎
‎Trang chủ hiện tại của Dusk nêu mục tiêu một cách thẳng thừng: hạ tầng cho các tài sản số được quản lý, mặc định bảo mật, với các bằng chứng không kiến thức và khả năng hiển thị có kiểm soát cho mục đích kiểm toán và công bố tuân thủ theo quy định. Cách diễn đạt này sắc nét đáng kể hơn so với định vị công khai trước đó của Dusk, vốn tập trung nhiều hơn vào việc kết hợp các giao dịch công khai của Moonlight với mô hình bảo mật của Phoenix cho tài chính được quản lý nói chung, mà không nhấn mạnh mạnh tay vào sự đối chiếu trực tiếp với tính minh bạch của Ethereum.
‎
‎Điều gì đã thay đổi giữa các cách định vị đó là điều đáng để suy ngẫm. Mặc định của Ethereum — mọi số dư, mọi lệnh gọi, đều có thể nhìn thấy bởi bất kỳ ai — thì phục vụ tốt cho việc phối hợp công khai. DuskEVM của Dusk chạy tương đương đầy đủ với EVM, dùng cùng bộ công cụ mà các nhà phát triển Ethereum đã quen thuộc, đồng thời vẫn giữ lớp bảo mật “được che giấu mặc định” nằm bên dưới. Mô hình thực thi không bị loại bỏ. Mặc định về mức độ hiển thị là. $DUSK
‎
‎Trang web của Dusk liệt kê các đối tác chịu sự quản lý tại EU hiện đang chủ động xây dựng dựa trên định vị này — một nhà cung cấp hạ tầng thị trường có giấy phép thuộc Chế độ Thí điểm DLT, cùng với một địa điểm được quản lý tại châu Âu đang nghiên cứu việc phát hành trên chuỗi trực tiếp thông qua cách định vị này.
‎
‎Đó là sự dịch chuyển mang tính tổ chức thật sự, không chỉ là thông điệp — nhưng liệu điều đó có thực sự kéo theo sự di chuyển đáng kể của nhà phát triển rời khỏi các stack “Ethereum-first” cụ thể vì vấn đề minh bạch hay không thì một điều mà tôi chưa tìm thấy số liệu chấp nhận/triển khai để xác nhận theo hướng nào cả. #dusk
‎
‎Nếu ai đó đã theo dõi dữ liệu di cư thực tế gắn riêng với lập luận về tính minh bạch — thay vì gắn với “bài chào” tuân thủ rộng hơn của Dusk — thì tôi muốn đối chiếu điều đó với những gì được nêu công khai trong danh sách đối tác của chính Dusk.

#dusk $DUSK @Dusk

@Dusk ‎trước đây đã sử dụng một bộ xác minh trên Dusk cần xem chi tiết giao dịch để xác nhận rằng nó là hợp pháp.
‎
‎Đó không phải điều xảy ra với Phoenix.
‎
‎Tôi lần theo những gì bộ xác minh thực sự nhận được, thay vì dữ liệu thô. Tài liệu kiến trúc nội bộ của Dusk xác nhận rằng Phoenix sử dụng các bằng chứng không kiến thức (zero-knowledge proofs) để chứng minh quyền sở hữu các đầu ra chưa chi tiêu (unspent outputs) và ngăn chặn chi tiêu hai lần—bộ xác minh kiểm tra bằng chứng, chứ không kiểm tra bản thân giao dịch.
‎
‎Hmm.
‎
‎Vậy rốt cuộc bằng chứng đó chứa gì, về mặt cơ chế?
‎
‎Tôi đã ngồi nghiền ngẫm vấn đề này một lúc. Người chi tiêu (spender) chứng minh họ biết đường đi đến gốc của cây Merkle (Merkle tree root), và biết phần mở (opening) của cam kết (commitment)—có nghĩa là bằng chứng về mặt toán học chứng minh rằng ghi chú (note) tồn tại trong cây và người chi tiêu thật sự biết nội dung của nó, mà không tiết lộ nội dung ghi chú hay vị trí của nó cho bất kỳ ai đang theo dõi.
‎
‎Việc chi tiêu bản thân lại cần một Khóa Bí mật (Secret Key) mà chỉ riêng chủ sở hữu của ghi chú mới biết—vì vậy bước tạo bằng chứng cũng không thể diễn ra nếu thiếu đúng mảnh thông tin mà không ai khác có.
‎
‎Đây là một đảm bảo lạ hơn so với cách nó nghe có vẻ ban đầu. Bộ xác minh không hề tin lời của người gửi. Nó cũng không tin bên thứ ba. Nó đang xác nhận một mệnh đề toán học—tính đúng của việc thuộc cây (tree-membership) cộng với kiến thức về cam kết (commitment-knowledge)—mà không cần tái tạo lại điều gì đã khiến nó đúng.
‎
‎Không nói rằng đó là kiểm tra yếu hơn. Nếu có, việc từ chối không nhìn còn là điểm chính—bộ xác minh không thể bị lừa bởi dữ liệu mà ngay từ đầu nó chưa bao giờ nhận được.
‎
‎Một hệ thống được thiết kế để xác minh tính thuộc cây và kiến thức về khóa bí mật, mà không bao giờ thấy các khoản tiền, có được niềm tin hơn một hệ thống xác minh bằng cách nhìn trực tiếp vào dữ liệu không?
‎

@Dusk #dusk $DUSK

@TermMax trước đây từng nghĩ rằng một khoản vay chỉ đơn giản là xuất hiện dưới dạng một con số nằm trong một số dư tài khoản.
‎
‎càng tìm hiểu cách TermMax thực sự cấu trúc một vị thế, điều đó càng không còn đúng.
‎
‎một người vay khóa tài sản thế chấp. TermMax phát hành một Gearing Token (GT) chống lại tài sản đó—đây là ERC-721, không phải một mục sổ cái. token nợ, token thế chấp và ngày đáo hạn đều được cố định ở cấp độ thị trường trước khi GT đó thậm chí được tạo ra.
‎
‎bản thân GT ghi đúng hai thứ. lượng thế chấp đang nằm trong nó. số lượng Fixed-Rate Tokens đã được đúc dựa trên thế chấp đó, bị giới hạn bởi LTV tối đa của thị trường. chẳng hạn một MLTV là 0.8 sẽ biến 1 ETH thành tối đa 800 $USDC nợ có thể đúc. #TermMax
‎
‎không có một “quỹ chung”, không có đối trừ ròng, không có bất kỳ con số pha trộn nào trong thiết kế.
‎
‎hãy đọc lại phần “cô lập” đó hai lần. TermMax vận hành hơn 100 thị trường tính đến bản cập nhật tháng 3/2026, mỗi thị trường tách biệt hoàn toàn với các thị trường còn lại, nên một mức giá thế chấp xấu ở một thị trường sẽ không bao giờ ảnh hưởng đến các GT đang được đặt trong bất kỳ thị trường khác. không phải sổ sách. đó là một ranh giới.
‎
‎thanh toán trực tiếp bằng các token nợ, hoặc mua lại các FT trên thị trường mở rồi trả lại chúng. dù theo cách nào thì GT sẽ đóng lại và tài sản thế chấp được giải phóng, nhưng nó chưa từng được gộp vào con số của bất kỳ ai ngay từ đầu.
‎
‎vậy nên vay trên TermMax không phải là một con số đơn lẻ tăng lên hoặc giảm xuống. đó là bao nhiêu GT bạn đã mở, mỗi GT mang theo chính tài sản thế chấp của nó, chính khoản nợ của nó, chính ngày đáo hạn của nó—trên chính nó.
‎
‎việc theo dõi theo từng khoản vay có làm rủi ro trở nên rõ ràng hơn, hay chỉ khiến việc quản lý ở quy mô lớn trở nên khó hơn?
‎
‎@TermMax #termmax

@Dusk từng nghĩ “tiết lộ chọn lọc” chỉ là một cách nói dịu hơn cho “minh bạch”.

Ngồi xem thiết kế thực tế của Citadel một thời gian, và hóa ra không phải vậy.

Minh bạch hoàn toàn, loại mà Dusk nói rõ là chủ trương chống lại, nghĩa là mọi người quan sát đều nhìn thấy mọi thuộc tính gắn với một giao dịch hoặc danh tính — cho dù họ có cần hay không. Citadel làm điều hẹp hơn, và tôi lần ra cơ chế thực sự: ba bên riêng biệt, không phải hai. Một Người dùng yêu cầu cấp phép trên chuỗi từ Nhà cung cấp giấy phép. Khi được cấp, giấy phép đó cho phép Người dùng thiết lập một kết nối riêng tư, ngoài chuỗi với Nhà cung cấp dịch vụ — bên này xác minh yêu cầu chỉ bằng những gì được lưu trên chuỗi, mà không bao giờ biết danh tính nền tảng của Người dùng.

Hmm.

Vậy khi kiểm tra thông qua, Nhà cung cấp dịch vụ thực sự học được gì?

Chỉ biết rằng một tuyên bố đó là đúng — nơi cư trú, nhóm tuổi, chứng nhận, hoặc bất cứ thứ gì mà giấy phép bao phủ. Không phải dữ liệu nền đằng sau nó, không phải bất kỳ thuộc tính nào khác mà Người dùng sở hữu, không phải một định danh cố định dùng để liên kết lần kiểm tra này với lần kiểm tra trong tương lai.

Đó là một cam kết hẹp hơn nhiều so với điều mà minh bạch tạo ra. Một hệ thống minh bạch hoàn toàn cho mọi người biết mọi thứ, vĩnh viễn, dù có liên quan hay không. Cấu trúc ba bên của Citadel cho một Nhà cung cấp dịch vụ duy nhất một điều đúng — đã được đối chiếu với một bản ghi trên chuỗi — mà Nhà cung cấp dịch vụ đó không bao giờ chạm vào hồ sơ đầy đủ của Người dùng.

Không nói rằng minh bạch ở đâu cũng sai. Phối hợp công khai thật sự được lợi từ việc ai cũng nhìn thấy cùng một sổ cái. Nhưng các hành động bị ràng buộc bởi danh tính — chứng minh đủ điều kiện mà không “tuồn” ra toàn bộ hồ sơ — cần một giao thức với ba vai trò tách biệt, chứ không phải hai, để thực sự hoạt động.

Chứng minh một điều đúng thông qua ba vai trò tách biệt có phải là một đảm bảo riêng tư mạnh hơn lời hứa của minh bạch kiểu “ai cũng thấy mọi thứ, nên không ai giấu gì” không?

@Dusk #dusk $DUSK

Kho lưu trữ riêng của Dusk nêu rõ rằng bộ triệt tiêu được tính toán một cách đặc biệt để một người quan sát bên ngoài không thể liên kết nó với bất kỳ ghi chú cụ thể nào.

@Dusk được giữ nguyên giả định rằng tư cách đủ điều kiện trên Dusk là thứ bạn đã đạt được một lần và giữ lại mãi, như một huy hiệu luôn ghim cố định.

thực ra có ba cơ chế tách biệt đang hoạt động cùng lúc, và chỉ cần một trong số chúng cũng có thể tước nó đi.

thứ nhất: số tiền đặt tối thiểu. tôi đã xác nhận rằng một provisioner của Dusk cần khóa 1000 DUSK, và dưới ngưỡng đó thì không có gì khác liên quan đến khoản stake còn ý nghĩa.

thứ hai: thời gian trưởng thành. ngay cả khi stake cao hơn mức tối thiểu thì vẫn phải nằm trong một số epoch cố định trước khi việc sortition của Dusk tính nó. $DUSK

thứ ba, và đây là điều tôi suýt bỏ sót: việc bị phạt. tôi phát hiện rằng các lỗi lặp lại không chỉ làm mất phần thưởng — mỗi lần bị đình chỉ liên tiếp sẽ chuyển một tỷ lệ stake tăng dần vào nhóm phần thưởng có thể được yêu cầu, bắt đầu từ 10% và tăng thêm 10% cho mỗi lần vi phạm tiếp theo.

tôi đã lần theo điều gì xảy ra khi cơ chế phạt này đẩy một stake xuống dưới ngưỡng 1000 DUSK. nó không chỉ làm stake “mất trọng lượng” trong sortition. tôi phát hiện rằng nó bị đóng băng hoàn toàn — cách duy nhất để quay lại Dusk là tháo phần còn lại đang bị đóng băng và stake lại phần mới.

vì vậy, tư cách đủ điều kiện không phải là một cánh cổng duy nhất mà provisioner vượt qua một lần rồi thôi. đó là ba cơ chế tách biệt — một “sàn”, một “cái đồng hồ”, và một lịch phạt — bất kỳ cái nào trong số đó cũng có thể âm thầm loại một provisioner của Dusk mà người đó tưởng mình vẫn đang hoạt động. #dusk

việc xếp lớp tư cách đủ điều kiện lên ba cơ chế độc lập khiến Dusk khó bị “gaming” hơn, hay nó chỉ làm cho một provisioner chân chính dễ mất tư cách mà không kịp nhận ra lý do ngay lập tức?

#dusk $DUSK @Dusk

Hoàng hôn đang hình thành xung quanh một vấn đề mà các blockchain minh bạch không phải lúc nào cũng có thể giải quyết một cách hiệu quả.

#dusk $DUSK

So sánh DuskVM với DuskEVM trên Mạng DUSK

@Dusk Lúc đầu tôi nghĩ việc chọn giữa DuskVM và DuskEVM chủ yếu phụ thuộc vào ngôn ngữ: Rust và WASM so với Solidity với bộ công cụ EVM mà ai cũng đã quen dùng. Tối nay tôi đã dành nhiều thời gian hơn dự kiến, và ở đâu đó trong quá trình đó, nó không còn trông giống một lựa chọn về ngôn ngữ nữa.

DuskVM nằm ngay ở lớp nền tảng của mạng, nên nó có quyền truy cập trực tiếp vào mảng quyền riêng tư và zero-knowledge mà Dusk thực sự được xây dựng xoay quanh. DuskEVM chạy các hợp đồng Solidity thông qua bộ công cụ EVM chuẩn, nhưng vẫn kết toán và công bố dữ liệu của nó trở lại thông qua cùng lớp DuskDS đó, và dù thế nào đi nữa thì đều trả gas bằng token DUSK giống hệt. Đó là một sự đối xứng kỳ lạ mà tôi cứ mãi quay lại: các đường thực thi khác nhau, nhưng cùng kết toán, cùng token nằm bên dưới cho cả hai.

Chọn DuskVM không chỉ là chọn một ngôn ngữ, mà là chọn mức độ “gần kề” với chính các primitive quyền riêng tư. Chọn DuskEVM không chỉ là sự quen thuộc, mà là khoảng cách tới các primitive đó dành cho bộ công cụ mà phần lớn nhà phát triển đã biết. Đó là một sự “ma sát” tinh tế mà nhiều so sánh bỏ qua. #dusk

Có một lớp thứ ba nằm dưới cả hai mà tôi cứ quay lại mãi. Tài liệu của Dusk xác nhận rằng DuskEVM cho phép các ví EVM, cầu nối (bridges) và sàn giao dịch hiện có cắm vào với ít thay đổi mã nhất, nhanh hơn nhiều so với một tích hợp native. DuskVM không có lối tắt tương đương. Cần phải xây dựng công cụ cho nó, từ con số 0, mỗi lần như vậy. $DUSK

Tính tương đương về tính năng giữa hai bên không được đảm bảo chỉ vì cả hai cùng kết toán qua một lớp và dùng chung một token gas. Những gì trông giống như “tùy chọn” trên bề mặt thực ra là hai “đặt cược” khác nhau về nơi chi phí thực sự được trả: trả trước ở phần tooling, hay trả sau trong những gì mà môi trường không thể làm.

Vậy Dusk có thực sự đưa ra cho builder một lựa chọn ở đây, hay chỉ đơn giản quyết định giúp họ nơi mà sự ma sát sẽ xuất hiện? @Dusk

#dusk $DUSK

@Dusk trước đây tôi từng cho rằng một “chuỗi quyền riêng tư” có nghĩa là mọi giao dịch đều được ẩn mặc định, không có ngoại lệ.

rồi tôi đọc xem Moonlight thực sự làm gì trên Dusk.

Dusk chạy hai mô hình giao dịch gốc trên cùng một lớp thanh toán. Moonlight là kiểu dựa trên tài khoản, công khai; bên gửi, bên nhận và số tiền đều hiển thị. Phoenix là kiểu dựa trên note (ghi chú), được che chắn; tiền được giữ dưới dạng các note được mã hóa thay vì một số dư đang chạy—nó gần với các đơn vị có thể chi tiêu hơn so với tổng số theo dạng tài khoản. #dusk

đó là “mặc định” đã thay đổi cách tôi đọc hiểu phần này, và tôi quay lại đọc lại đoạn đó hai lần chỉ để chắc chắn.

một lần chuyển duy nhất sẽ chọn một trong hai mô hình, không pha trộn. gửi DUSK qua Moonlight thì nó hoàn toàn minh bạch, được thiết kế cho các luồng cần có thể quan sát—một ví dụ kiểu như ngân quỹ hay kịch bản báo cáo là những gì tài liệu hướng tới. gửi qua Phoenix thì số tiền, bên gửi và các note cụ thể nào đã được chuyển đi vẫn được giấu kín; tính đúng đắn được chứng minh bằng các proof zero-knowledge thay vì hiển thị ra trực tiếp, dù một “viewing key” có thể tiết lộ chính phần dữ liệu ẩn đó cho bất kỳ ai mà người staking chọn để hiển thị. $DUSK

một Transfer Contract xử lý cả hai, định tuyến từng payload tới đúng logic xác thực, giữ trạng thái toàn cục nhất quán dù theo cách nào.

vậy quyền riêng tư ở đây cũng không phải dạng nhị phân ở cấp giao thức: đó là một lựa chọn cho từng lần chuyển, và ngay cả lựa chọn che chắn cũng có cách được tài liệu ghi rõ để có thể trở nên hiển thị lại theo yêu cầu.

quyết định này nằm ở người gửi, không phải ở giao thức.

việc đưa cho người dùng một tùy chọn công khai có làm suy giảm “pitch” về quyền riêng tư không, hay quyền riêng tư tùy chọn và có thể thu hồi mới là thiết kế trung thực hơn cho các thị trường được quản lý?

quyền riêng tư tùy chọn còn là quyền riêng tư không?