wz爱喝牛奶

我看 TermMax V2 的 Smart Unwind 时，第一反应是：借款都还没到期，为什么还要提前给自己设置一个“退出价格”？

后来把资金路径拆开，我才发现这里解决的其实不是还款，而是**被固定期限卡住的流动性**。

TermMax 原来的固定期限借款有个天然问题：借出去的资产可能一路锁到 maturity。V2 的 Smart Unwind 则允许借款人在开仓时设置目标 APR 或价格条件，条件满足后，新的借款人或套利者可以接手原来的仓位，资金重新回到借贷池。

> 固定期限没有被取消，只是协议给仓位增加了一扇提前换手的门。

站在借款人角度，这个设计很有意思。

我原本锁了一笔固定融资。

如果市场后来按我的预期变化，继续抱着这笔仓位反而可能浪费机会。

Smart Unwind 让我提前设一个退出条件，达标就让别人接手。

我拿到预期收益，新的参与者拿到他认为还有价值的仓位，原本被锁住的资金也重新进入市场。

但代价同样明显。

你设置的退出条件不是保证成交。

市场没有人愿意接，你还是得继续扛到下一步。

所以 TermMax 真正解决的不是“固定期限太死”，而是让**固定期限里的仓位也有机会重新定价、重新换手**。

我觉得这才是 V2 真正有意思的地方。

你会愿意为了提前锁定一个退出目标，把自己的仓位交给市场重新接手，还是宁愿拿着固定融资一直到期，少折腾但也少一次主动退出的机会？@TermMax

#termmax

Khi tôi gần đây xem quy trình hoạt động của thị trường tài chính của Dusk, điều thực sự khiến tôi cảnh giác là một vấn đề rất truyền thống nhưng sau khi lên blockchain lại càng khó hơn:

**Chứng khoán đã được chuyển cho bạn, nhưng tiền vẫn chưa thực sự đến tay bên bán — phải làm sao?**

Giao dịch on-chain thông thường rất dễ khiến “chuyển giao tài sản” và “thanh toán” được hiểu như hai giao dịch độc lập.

Nhưng thị trường tài chính không vận hành như vậy.

Thiết kế hạ tầng thị trường chính thức của Dusk đặt asset leg và payment leg trong cùng một bài toán thanh toán, nhấn mạnh rằng các giao dịch tài sản được quản lý cần được phối hợp hai vế một cách có thể dự đoán, thay vì để bên này hoàn tất trước rồi bên kia từ từ bổ sung.

> Tôi nghĩ điều quan trọng ở đây không phải là “thanh toán nhanh hơn”, mà là đừng để các bên của giao dịch phải đối mặt với chênh lệch thời gian mà bên kia có thể vỡ nợ.

Đứng ở góc độ bên bán, tôi đương nhiên muốn rằng khi tài sản đã được chuyển đi, việc thanh toán cũng đã được xác định.

Bên mua cũng vậy.

Không ai muốn giao đồ của mình trước, rồi lại cầu mong rằng tiền của phía bên kia sẽ xuất hiện đúng lúc.

Đó chính là ý nghĩa của logic thanh toán kiểu DvP:

Cần xem xét đồng thời asset leg và payment leg.

Nhưng cái giá cũng rất rõ ràng.

Hệ thống không thể chỉ tối ưu một trong hai khoản chuyển — mà phải đồng thời xử lý tài sản, thanh toán, tư cách của người tham gia và trạng thái thanh toán cuối cùng.

Quy trình phức tạp hơn.

Luật lệ cũng nhiều hơn.

Tuy nhiên, với chứng khoán, quỹ hoặc các tài sản tài chính thực khác, tôi lại thấy sự phức tạp này là không tránh khỏi.

Bởi vì điều rắc rối nhất của tài chính truyền thống không bao giờ là “tài sản được chuyển như thế nào”, mà là:

**Ai giao trước, ai thanh toán trước, và khi nào cả hai bên mới được tính là hoàn tất thật sự.**

Nếu bạn là một nhà giao dịch tổ chức, bạn sẽ chấp nhận thêm một bộ quy tắc thanh toán để đổi lấy việc hai bên hoàn tất giao dịch cùng lúc; hay bạn vẫn muốn giữ quy trình đơn giản kiểu on-chain thông thường — “mỗi bên tự xử lý tài sản và thanh toán”? @Dusk

#dusk $DUSK

我最近看 TermMax 的到期机制时，反而卡在一个很现实的问题上：既然借款利率和期限都提前定死了，为什么协议还要给借款人设计 Roll 的出口？

按固定期限借款的直觉，到了 maturity 就还钱，事情结束。

可现实里最麻烦的恰恰是这一天。

本金可能还在抵押资产里。

仓位也没有坏。

只是你手上的现金，刚好没准备好。

TermMax 的固定期限设计天然存在这个“到期悬崖”：借款人到期要么一次性偿还，要么寻找新的融资来源。官方和 Morpho 的集成方案，就是把再融资这条路提前接进来，让借款人在接近到期时可以退出原来的固定利率头寸，再寻找新的资金来源。

> 我觉得这里真正需要管理的，不是利率，而是“时间到了以后，谁来给本金续命”。

这对借款人很重要。

因为固定利率给了你可预测的成本，却没有自动保证你到期那一天刚好有足够现金。

所以 TermMax 这里出现了一个很有意思的取舍：

固定期限让融资计划更清楚。

但期限越明确，到期日也越像一道硬门槛。

提前准备好再融资，仓位可以继续运转。

没准备好，就可能被迫退出原来的融资结构。

我现在反而觉得，固定利率真正难的部分不是“锁住利率”，而是**怎么安全地走出这笔期限交易**。

如果你是借款人，你更愿意接受一个利率稍高、但可以灵活续上的融资方案，还是宁愿锁住更低的固定成本，自己承担到期前找下一笔钱的压力？@TermMax

#termmax

我最近看 Dusk 的受监管资产设计时，真正让我停下来的是一个很小的区别：为什么“这个钱包能签交易”，还不能直接等于“这个钱包有资格买这项资产”？

普通代币逻辑很简单。

有余额。

有签名。

交易就走。

但如果换成证券类资产，这套逻辑马上不够用了。Dusk 当前文档把 eligibility、身份、wallet binding 和 access control 单独放进资产工作流里。也就是说，链上要判断的不只是“谁在发起交易”，还包括“这个参与者是否符合这项资产的持有条件”。

> 我觉得这里真正被拆开的，是“控制钱包”和“拥有资格”这两件事。

站在投资者角度，这意味着一个地址即使掌握私钥，也不代表它天然可以接收所有受监管资产。

站在发行方角度，这反而是必要的。

因为证券上链以后，最怕的不是没人交易，而是资产被转给一个本来就不应该进入这个市场的地址。

Dusk 的 Citadel 作为身份与访问层，就是在处理这条边界，让资格和链上账户之间建立关系，同时又支持只披露必要的信息，而不是把整套身份资料摊在公网上。

代价也很明显。

普通代币只要钱包和签名没问题就能转。

受监管资产却多了一层资格判断。

体验没那么“无脑”。

但这恰恰可能是金融资产真正上链后逃不开的一笔账：

**开放的地址，不等于开放的资产资格。**

如果你是资产发行方，你会接受多一层身份和资格限制，换取资产真正进入合规市场；还是宁愿保持普通代币那种“谁有钱包，谁就能接”的简单规则？@Dusk

#dusk $DUSK

我看到 TermMax V2 有个设计，第一反应其实挺矛盾：一个主打“固定利率”的协议，为什么还要把没借出去的钱放进 Aave、Morpho、Venus 这种浮动利率市场？

按直觉，既然都来 TermMax 了，不应该把资金老老实实锁在固定收益里吗？

我把资金路径重新拆了一遍，才发现这其实是在解决一个很现实的 LP 问题。

固定利率订单最怕什么？

不是收益低。

而是**钱挂着，没人借。**

TermMax 的 Composable Base Yield 做的事情，就是让还没被匹配的资金先去底层收益协议产生基础收益，等固定利率订单真正成交，再回到 TermMax 的固定收益逻辑里。官方目前明确把 Aave、Morpho、Venus 作为这类底层收益来源。

> 我觉得这个设计真正解决的不是“收益更高”，而是把“等待成交”这段原本可能浪费掉的时间也拿来利用。

站在 LP 角度就很直观：

钱已经准备好了。

但借款人没出现。

如果只能干等，资本利用率天然被拖低。

TermMax 反过来把这段空档接到浮动收益市场上。

不过代价也很明确。

你追求固定收益，却不得不接受一部分资金在等待期间暴露于底层浮动利率和协议风险。

也就是说，TermMax 并没有消灭浮动利率，只是把它从“借款成本”挪成了“闲置资本的等待收益”。

这点我觉得比“固定利率”四个字本身有意思得多。

真正的问题变成：

**一个固定收益协议，到底该不该为了提高资金利用率，主动拥抱一点浮动收益风险？**

如果你是 LP，你会宁愿让资金躺着等固定订单，还是接受底层浮动收益，换取这段等待时间也不吃空窗期？@TermMax

#termmax

Khi lần này xem các quy tắc chuyển khoản tài sản của Dusk, tôi lại bị thu hút bởi một thao tác khá bình thường: vì sao trước khi giao dịch được nộp chính thức, nó lại phải kiểm tra và mô phỏng trước một lượt?

Trước đây khi xem các khoản chuyển trên chuỗi, tôi thường quen với quy trình: ký tên, gửi đi, rồi đợi kết quả.

Nhưng tài sản chịu sự quản lý nhà nước thì không chơi theo kiểu đó.

Một nhà đầu tư có thể có số dư, nhưng lại không đủ tư cách để nắm giữ một loại tài sản nhất định; một địa chỉ cũng có thể nhận được tiền, nhưng các quy định hiện hành lại không cho phép địa chỉ đó nhận loại tài sản này. Thiết kế chính thức của Dusk đưa những phần “đủ tư cách” và việc kiểm tra chuyển tiền vào ngay trong luồng, để giao dịch có thể được kiểm tra hoặc mô phỏng trước khi nộp chính thức.

> Tôi nghĩ bước này thực sự giải quyết không phải là hai chữ “giao dịch thất bại”, mà là ngăn cho các thao tác sai biến thành một “sự thật trên chuỗi” trước.

Nếu đứng ở vị trí bên phát hành hoặc sàn giao dịch thì sự khác biệt này rất lớn.

Logic truyền thống trên chuỗi giống như:

Gửi trước.

Thất bại rồi mới xử lý sau.

Còn Dusk muốn làm thì là:

Phán đoán trước.

Nếu không phù hợp quy tắc thì cố gắng chặn lại trước khi nộp.

Làm vậy đương nhiên sẽ tăng thêm một lớp logic kiểm tra, và việc chuyển tài sản sẽ không chỉ nhìn vào số dư và chữ ký như đối với token thông thường.

Nhưng đổi lại là việc đưa các phán đoán tuân thủ vốn trước đây phải dựa vào hậu trường con người để khắc phục, được “nhét sớm” vào chính quy trình trên chuỗi.

Tôi nghĩ đây mới là điểm Dusk thực sự thú vị.

Nó không chỉ đơn giản là “đưa chứng khoán lên chuỗi”, mà đang thử biến chính khái niệm “ai có thể chuyển, ai có thể nhận, trong trường hợp nào thì phải từ chối” thành một phần của quy tắc vận hành tài sản.

Nếu bạn là bên phát hành, bạn sẽ sẵn sàng chấp nhận thêm một bước kiểm tra được thực hiện trước, hay bạn muốn giữ quy trình đơn giản kiểu token thông thường: chuyển trước rồi xử lý ngoại lệ?@Dusk

#dusk $DUSK

Tôi lần này xem TermMax V2 với Atomic Order. Phản ứng đầu tiên của tôi thật ra hơi không thoải mái: Tại sao cùng một khoản USDC lại có thể đồng thời được đặt vào nhiều thị trường? Điều này nhìn như đang “thổi phồng” thanh khoản một cách vô căn cứ.

Tiếp tục đi sâu vào cơ chế, điểm mấu chốt lại không nằm ở chỗ “xuất hiện cùng lúc”, mà ở việc **sau khi khớp thì nó biến mất như thế nào**.

Atomic Order của TermMax cho phép cùng một khoản thanh khoản phục vụ đồng thời nhiều thị trường. Giả sử một Vault có một khoản vốn, nó có thể xuất hiện đồng thời trong các thị trường cho vay khác nhau, nhưng thực tế khoản tiền đó chỉ có thể được khớp đúng một lần. Khi một thị trường “ăn” lấy một phần, thì các hạn mức tương ứng ở những thị trường khác sẽ được rút đồng bộ ngay trong cùng một giao dịch.

Nhà phát triển thiết kế logic này như một thao tác nguyên tử.

> Giá trị thực sự không phải là làm cho một khoản tiền “trông có vẻ nhiều hơn”, mà là việc giao thức cho phép nhiều thị trường chia sẻ cùng một khoản tiền—nhưng không cho phép nó bị chi tiêu lặp lại.

Đứng ở góc độ người đi vay, giải pháp này giải quyết vấn đề với các đơn đặt hàng quy mô lớn.

Trước đây, khi thanh khoản bị chia tách ở các thị trường khác nhau, các lệnh lớn rất dễ gặp tình huống thiếu độ sâu ở một thị trường đơn lẻ. Giờ đây, giao thức có thể đưa thanh khoản khả dụng từ nhiều thị trường vào cùng một bộ logic thực thi, và chỉ sau một lần khớp, mới quyết định chính xác thị trường nào sẽ nhận được số tiền.

Nhưng cái giá cũng rất trực tiếp.

Thanh khoản “trên sổ sách” mà người dùng nhìn thấy không có nghĩa là mỗi thị trường đều sở hữu một phần vốn độc lập. Thứ bạn thấy là **hạn mức có thể cạnh tranh trong một bể dùng chung**.

Điều này đòi hỏi sự đồng bộ nguyên tử của giao thức phải thật sự đáng tin cậy.

Nếu không, “chia sẻ nhiều thị trường” không phải là hiệu quả sử dụng vốn, mà chỉ là thanh khoản giả.

Tôi nghĩ đây là một thiết kế khá dễ bị bỏ qua của TermMax V2: nó không đơn giản là tăng thêm vốn, mà là đang định nghĩa lại “độ sâu thị trường” thuộc về ai.

Nếu bạn là người vay số tiền lớn, bạn sẽ muốn đối mặt với một sổ lệnh nhìn có vẻ sâu hơn—nhưng dùng chung vốn—hay một thị trường có độ sâu nhỏ hơn, nhưng vốn ở mỗi thị trường hoàn toàn độc lập?@TermMax

#termmax

我这次看 Dusk 的交易生命周期时，真正让我停下来的，是它没有把“确认”和“最终完成”当成一回事。

官方文档把一笔交易拆得很清楚：先从 mempool 移除，再进入 confirmed，最后 block 达到 finality，交易才变成不可逆的最终状态。

乍看像是多做了一层状态。

但站在金融资产结算的人角度，这个区别其实很要命。

普通转账里，看到 confirmed，很多人可能就继续下一步了。

但证券、支付或者资产交割不一样。

你真正需要确认的不是：

“这笔交易大概率没问题。”

而是：

“这笔资产现在到底能不能当成最终结果记账？”

> 对金融市场来说，“大概率不会回滚”和“已经不可逆”不是一回事。

Dusk 的设计把这两个阶段拆开，就是把“先看到结果”和“结果已经锁死”分开处理。

这会带来一个很现实的成本。

等待 finality，意味着应用不能只盯着第一条确认状态就立刻把后续流程全部推进。

但换来的，是更明确的结算边界。

对于普通链上转账，这点差异可能没那么刺眼。

对于代币化证券、支付腿和资产腿同时推进的交易，结算边界一旦模糊，后面的交割、记录和权限判断都会跟着乱。

所以我现在越来越觉得，Dusk强调 deterministic settlement，不只是为了“快”。

它更在乎：

**什么时候可以真正把这笔交易从“发生了”变成“已经定了”。**

如果你是金融机构的后台，你会更在意几乎立刻看到成交，还是宁愿多等一个明确的 finality，再把整笔资产正式记入账？@Dusk

#dusk $DUSK

Trong mấy ngày nay tôi xem thiết kế Vault của TermMax, lại bị thu hút bởi một quyết định nhìn có vẻ “ngược với người dùng”: đã có thị trường lãi suất cố định ghi rất rõ lợi suất và kỳ hạn, vậy tại sao vẫn bắt người dùng giao tiền cho Curator?

Theo cách hiểu của tôi, cách chơi trực quan nhất là tự chọn thị trường, tự xem kỳ hạn, rồi tự mua FT và chờ đến khi đáo hạn.

Nhưng Vault của TermMax V2 lại đi theo hướng khác: người dùng gửi tài sản vào, sau đó vốn được Curator phân bổ theo chiến lược vào nhiều thị trường cho vay/bên vay có kỳ hạn cố định.

Hiện tại phía chính thức cũng đặt giới hạn dung lượng cho Vault, để một thị trường đơn lẻ không thể “hút” vốn vô hạn.

> Thực ra đây là lấy đi một phần quyền “tự mình quyết định”, để đổi lấy chi phí vận hành thấp hơn.

Xét từ góc độ người gửi tiền, tôi sẽ phải làm ít khâu sàng lọc hơn.

Không cần ngày nào cũng canh các ngày đáo hạn khác nhau.

Không cần tự so sánh nhiều lãi suất cố định.

Không cần mỗi khi thị trường biến động lại điều chỉnh danh mục.

Nhưng cái giá phải trả cũng rõ ràng:

Quyền phán đoán của bạn bị giao đi.

Nếu Curator chọn sai thị trường, hoặc bản thân chiến lược không phù hợp với bối cảnh lãi suất hiện tại, thì cuối cùng người chịu kết quả vẫn là người gửi tiền.

Vì vậy tôi nghĩ Vault của TermMax thực sự không bán “tiện lợi”, mà là **chuyên nghiệp hóa công việc khó nhọc là chọn thị trường**.

Điểm khác biệt lớn nhất so với DeFi truyền thống nằm ở đây.

Trước đây:

Tiền giao cho giao thức, chiến lược do nó tự làm.

Bây giờ:

Tiền giao cho Vault, chiến lược do Curator làm.

Và thứ mà TermMax thực sự cần chứng minh lại là:

Lợi nhuận do Curator tạo ra có thể bù đắp được phần rủi ro mà người dùng phải gánh khi từ bỏ quyết định tự chủ hay không?

Nếu là bạn, bạn muốn tự chọn thị trường lãi suất cố định, hay muốn giao quyền lựa chọn cho Curator và đổi lấy một kênh thu nhập cố định tiện hơn?@TermMax

#termmax

Khi lần này tôi đọc tài liệu phát triển của Dusk, thứ thực sự khiến tôi dừng lại không phải là các tính năng về quyền riêng tư, mà là lý do tại sao họ không làm luôn chỉ EVM.

Hiện tại Dusk đồng thời giữ DuskVM và DuskEVM: cái trước chạy trực tiếp trên Dusk L1, dành cho các hợp đồng Rust/WASM; còn cái sau cung cấp Solidity, Vyper và bộ công cụ EVM mà ai cũng quen.

Câu trả lời chính thức dành cho nhà phát triển thực ra rất thẳng thắn: hai con đường giải quyết không phải cùng một vấn đề.

> Trông có vẻ như xây dựng trùng lặp, nhưng thực chất là dùng “sự thuận tiện cho việc phát triển” để đổi lấy “năng lực gốc”.

Đứng trên góc nhìn của một nhà phát triển EVM thông thường, DuskEVM rõ ràng sẽ đỡ công hơn. Ví, ngôn ngữ, chuỗi công cụ đều quen thuộc, chi phí chuyển đổi thấp, và đội ngũ không cần phải học một cách phát triển hoàn toàn xa lạ từ đầu.

Nhưng nếu ứng dụng cần chạm trực tiếp vào tài sản gốc của Dusk, năng lực về quyền riêng tư, logic zero-knowledge, hoặc cần bám sát hơn môi trường thực thi gần L1, thì DuskVM lại có giá trị riêng.

Tài liệu chính thức cũng đã phân biệt rõ hai lộ trình này, chứ không ép mọi ứng dụng phải đi theo một con đường duy nhất.

Vấn đề nằm ở đây.

Hai môi trường thực thi đồng nghĩa độ phức tạp trong phát triển và bảo trì cao hơn, và các công cụ hệ sinh thái cũng khó có thể hoàn toàn thống nhất.

Tuy nhiên, nếu chỉ theo đuổi tương thích EVM, thì Dusk lại có thể khóa những năng lực đặc biệt nhất của mình trong một khung thực thi phổ thông.

Dần dần tôi càng cảm thấy rằng, thứ Dusk thực sự đánh cược không phải là “có nên tương thích với Ethereum hay không”, mà là:

**Liệu có thể để nhà phát triển bước vào trước bằng những thứ quen thuộc, rồi khi thực sự cần năng lực gốc, họ mới sẵn sàng đi sang lộ trình khác hay không.**

Nếu bạn là nhà phát triển, bạn sẽ chọn triển khai nhanh bằng EVM quen thuộc, hay vì quyền riêng tư và năng lực gốc mà chấp nhận chi phí học một môi trường thực thi mới?@Dusk

#dusk $DUSK

我这次看 Dusk 节点质押时，真正停下来的不是最低质押门槛，而是它为什么要把一笔 Staking 的钥匙拆成两种：Consensus Key 负责节点参与共识，Owner Key 负责解除质押和提取资金。

乍看很麻烦。

一把钥匙不就够了吗？

但站在节点运营者的位置，这其实是在处理一个很现实的问题：**“让机器能签块”，和“让资金能被拿走”，根本不该是同一件事。**

> 节点天天在线，热密钥要持续工作；质押资产却没必要跟着一起暴露。

如果共识密钥和资产控制权绑死，节点机器一旦成为攻击入口，风险就不只是“节点掉线”这么简单，资金控制权也可能被一起拖进去。

Dusk 的拆分思路很直接：

Consensus Key 管运行。

Owner Key 管资产。

机器负责干活，资金控制权留给另一套权限。

这套设计当然不是白赚的。

钥匙拆开后，节点运维更复杂，备份、恢复、权限管理都要多一道流程。对于小型节点来说，这甚至可能变成新的操作负担。

但我觉得这正是基础设施和普通钱包最大的区别。

普通用户最怕记不住助记词。

节点运营者更怕的是：

**一台长期在线的机器，顺手把自己的资金也变成在线资产。**

所以我现在更关注一个问题：

你会愿意为了少一道操作，把“签块权”和“提款权”绑在一起，还是宁愿多一点运维麻烦，也把机器和资金彻底隔开？@Dusk

#dusk $DUSK

Dusk 的节点，不靠算力靠抵押
聊 Dusk 的人都在说隐私，但很少人看它节点怎么跑。

我查了一下，它不做 PoW，也不走普通 PoS，而是用抵押加抽签的方式选验证者。DUSK 不押进去，节点身份都没有。押进去之后，出块权靠随机，不是谁钱多谁说了算。

这背后有个挺别扭的设计：你要帮全网验证交易，但你手里跑的那些交易，很多都是加密的。也就是说，作为验证者，你得确认一批你自己也看不清完整内容的交易合法。做不到？系统用零知识证明来补，验证者只需要确认证明成立，不需要看懂全貌。

但这件事的成本，最后压在质押的人身上。节点要稳定在线，要跑 Rusk 这套虚拟机，硬件和运维不便宜。出块奖励能否覆盖，官方文档里没有写死一个保证收益，这比多数 PoS 链更冷。

有意思的是，普通用户质押 DUSK，收益不是靠“参与治理”，而是你的币被系统当成安全垫。网络越需要隐私验证，对节点的要求就越高，要求越高，愿意跑节点的人越少。那收益从哪来？早期靠通胀，长期得靠网络的手续费。手续费上不来，节点会走。

我原本以为 Dusk 节点和别的链差不多，看完机制才发现，它把隐私成本转成了验证成本，又把这成本转给了质押者。

所以问题来了：你愿意拿着 DUSK 去质押，赚一份说不清的收益，同时替全网隐私交易扛成本吗？

还是说，宁可拿着币什么都不干，也不让自己成为那个“不知道在验什么却要负责”的人？@Dusk

#dusk $DUSK

Quyền riêng tư của bạn, công tắc không nằm trong tay bạn
Những người mua coin riêng tư đa phần chỉ muốn có một “món để ai cũng không tra ra tôi”. Nhưng trong hợp đồng XSC của Dusk, bên phát hành có thể giữ lại một chiếc chìa khóa cho bên kiểm toán. Nghe giống như backdoor, nhưng thực chất là “công bố tuân thủ” được viết rõ ràng trong thiết kế.

Ban đầu tôi cứ nghĩ rằng điểm đến của một chuỗi riêng tư là ẩn danh hoàn toàn. Sau đó tôi xem tài liệu của Dusk, thấy chuẩn XSC cho phép bên phát hành tài sản đặt “vai trò kiểm toán”—chỉ vai trò này, khi kích hoạt theo các điều kiện nhất định, mới có thể truy cập chi tiết giao dịch. Không phải ai cũng xem được, nhưng cũng không đến lượt bạn từ chối.

Điều này có nghĩa là gì? Quyền kiểm soát quyền riêng tư giao dịch của bạn không nằm trong tay bạn, mà nằm trong tay bên phát hành và bên kiểm toán. Bạn chỉ là người nắm giữ coin, nhưng “ai có quyền xem sổ cái của bạn” là một công tắc mà bạn không thể chạm tới.

Tại sao chính thức lại thiết kế như vậy? Vì tài sản tài chính khi lên chuỗi thì tổ chức phải qua KYC/AML, còn cơ quan quản lý cần xem sổ. Một chuỗi ẩn danh hoàn toàn thì tổ chức không dám tham gia, sàn giao dịch cũng có thể gỡ niêm yết. Dusk cược rằng: dùng một phần quyền riêng tư của người dùng để đổi lấy sự tồn tại tuân thủ của tài sản.

Chi phí thì rất rõ ràng: người nắm giữ phải đánh đổi “quyền riêng tư tuyệt đối” để lấy một lối đi có thể được chấp nhận rộng rãi. Lợi ích là, tài sản trên DUSK sẽ không bị coi như công cụ cho hoạt động xấu, rủi ro bị gỡ niêm yết thấp hơn; còn rủi ro là nếu vai trò kiểm toán bị lạm dụng, hoặc quy tắc thay đổi, bạn gần như không có quyền thương lượng.

Giờ câu hỏi trắc nghiệm đặt trước mặt bạn: bạn có sẵn sàng chuyển nhượng một phần quyền kiểm soát quyền riêng tư để tài sản tiếp tục ở lại bàn chơi; hay bạn thà chọn ẩn danh hoàn toàn, dù cuối cùng chuỗi này có thể bị cô lập?

Tôi không thay bạn quyết, nhưng tôi sẽ tự hỏi: nếu công tắc quyền riêng tư ví của tôi nằm trong tay người khác, tôi còn ngủ yên được không?
@Dusk

#dusk $DUSK

Trong vài ngày này tôi xem lại mô hình giao dịch của Dusk, và cuối cùng lại bị một thiết kế khá “ngược trực giác” làm kẹt lại: Tại sao họ không đơn giản biến mọi giao dịch thành giao dịch riêng tư hết?

Câu trả lời thực ra rất thực tế.

Hiện tại, Dusk tách việc luân chuyển tài sản gốc thành hai mô hình: Moonlight và Phoenix. Moonlight công khai tài khoản, số dư, bên gửi và bên nhận; còn Phoenix thì đưa tiền vào một Note được mã hoá, dùng bằng chứng không tri thức để xác minh giao dịch, đồng thời ẩn số tiền và mối liên hệ giao dịch, và khi cần thì vẫn có thể tiết lộ có chọn lọc thông qua viewing key.

> Đây không phải là vấn đề “riêng tư mạnh đến đâu”. Trong thị trường tài chính, có những thông tin căn bản không thể mãi mãi giấu đi được.

Chuyển khoản thông thường và các kịch bản quản lý một phần nguồn vốn cần có thể đối chiếu.

Giao dịch của tổ chức thì vừa không muốn đưa trực tiếp danh mục nắm giữ hay số tiền lên chuỗi.

Còn kiểm toán, giám sát thì càng không thể chấp nhận kiểu “không xem được gì”.

Vì vậy Dusk không đi theo hướng “ẩn danh một cách triệt để cho mọi thứ”, mà đặt **thanh toán công khai và thanh toán riêng tư vào cùng một mạng lớp nền**.

Điểm thú vị nhất ở đây, theo tôi, chính là Trade-off.

Tất cả công khai thì kiểm toán dễ, nhưng các tổ chức lại không muốn để mọi luân chuyển tài sản nhạy cảm bị phơi toàn bộ ra ngoài.

Tất cả riêng tư thì người dùng thấy thoải mái, nhưng tuân thủ và quản lý tài sản lại bị kẹt.

Giải pháp của Dusk thực ra rất “cứng”: để từng giao dịch tự lựa chọn cần phơi lộ bao nhiêu thông tin.

Điều này cũng giải thích vì sao họ luôn nhấn mạnh regulated onchain finance, chứ không chỉ bán một câu chuyện “chuỗi công khai riêng tư”. Kiến trúc hiện tại của Dusk bản thân đang được tách thành các module xoay quanh thanh toán, riêng tư, danh tính và tiết lộ có chọn lọc.

Tôi lại muốn xem một câu hỏi khác:

Nếu bạn là một tổ chức thật sự quản lý tài sản tài chính, bạn sẽ sợ rò rỉ thông tin trên chuỗi hơn, hay sợ hơn việc khi cơ quan quản lý cần kiểm tra thì không xuất trình được bằng chứng?@Dusk

#dusk $DUSK

Hôm qua khi xem lại cơ chế tham gia xác minh của Babylon, tôi vẫn luôn chú ý đến một vai trò dễ bị bỏ qua: những người thực sự chạy node và duy trì an ninh cho mạng lưới.

Rất nhiều cuộc thảo luận tập trung vào việc liệu người nắm giữ BTC có thể nhận được lợi nhuận hay không, nhưng đối với người xác minh, vấn đề hoàn toàn khác.

Họ không phải đối mặt với câu hỏi “có nên khóa một phần BTC hay không”, mà là:

Khi tiếp nhập một hệ thống an ninh mới, liệu chi phí vận hành của mình có tăng lên không?

Một nhà vận hành node quan tâm nhất là những điều rất thực tế.

Chi phí máy chủ.

Thời gian bảo trì.

Kiểm soát rủi ro.

Lợi ích có đủ bù đắp phần đầu tư hay không.

Babylon muốn kết nối an ninh kinh tế của Bitcoin, nhưng cuối cùng thiết kế này cũng cần có người tham gia để duy trì vận hành mạng lưới.

> Bất kỳ mô hình an ninh nào cuối cùng cũng không tránh khỏi một câu hỏi: liệu có đủ nhiều người sẵn sàng dài hạn gánh chi phí hay không.

Nếu lợi ích đủ hấp dẫn, nhiều người tham gia hơn sẽ vào cuộc và có thể tăng cường an ninh mạng.

Nhưng nếu ngưỡng vận hành tăng lên, hoặc lợi ích không bù đắp được chi phí thực tế, số người tham gia có thể giảm.

Đây cũng là mâu thuẫn mà nhiều hạ tầng cốt lõi trên chuỗi phải đối mặt.

An ninh càng mạnh thường đồng nghĩa với nhiều quy tắc và yêu cầu hơn.

Quy tắc càng nhiều thì chi phí tham gia cũng có thể tăng.

Tôi thấy điểm thú vị của Babylon không chỉ nằm ở việc tạo ra các kịch bản sử dụng mới cho BTC, mà còn ở nỗ lực phân bổ lại vai trò trong “thị trường an ninh” trên chuỗi.

Trước đây:

Một chuỗi cần tự đào tạo các người xác minh.

Bây giờ:

Người xác minh có thể tham gia vào một hệ thống an ninh rộng hơn theo những cách mới.

Nhưng rốt cuộc điều quyết định liệu mô hình này có thể vận hành lâu dài hay không không chỉ là thiết kế kỹ thuật, mà là liệu các nhà vận hành node trong thực tế có sẵn sàng tiếp tục đầu tư hay không.

Bởi vì trong thế giới blockchain, thứ thực sự chống đỡ cho an ninh chưa bao giờ là một khẩu hiệu hay một ý tưởng, mà là một nhóm người mỗi ngày duy trì máy móc và gánh chi phí.

Nếu tương lai hệ sinh thái Babylon mở rộng, theo bạn cuộc cạnh tranh quan trọng nhất sẽ là thu hút thêm nhiều BTC hay thu hút thêm những người sẵn sàng vận hành node dài hạn?

#baby $BABY

Hôm qua khi xem tình hình dự án hệ sinh thái Babylon được tích hợp, tôi đã luôn nghĩ về một câu hỏi: đối với một blockchain mới vừa khởi động, việc có Bitcoin Security rốt cuộc là một động cơ tăng tốc hay là một sự phụ thuộc mới?

Nhiều dự án trước khi ra mắt đều phải đối mặt với cùng một thực tế.

Tính năng có thể phát triển nhanh chóng.

Token có thể phát hành nhanh chóng.

Nhưng hệ thống bảo mật không thể xây dựng chỉ bằng quảng cáo.

Số lượng người xác thực, động lực kinh tế, và việc duy trì lâu dài—tất cả đều cần thời gian để tích lũy.

Vì vậy, giải pháp bảo mật BTC mà Babylon cung cấp với nhiều blockchain mới giống như một lối tắt.

> Nhưng phía sau lối tắt đó cũng là một lựa chọn: đạt trạng thái khởi động bảo mật nhanh hơn, hay kiên trì phát triển mạng xác thực của chính mình từ đầu.

Đứng ở góc độ đội ngũ blockchain mới, việc tích hợp nguồn bảo mật đã trưởng thành có thể giảm bớt áp lực “khởi động nguội” giai đoạn đầu.

Không phải ngay từ đầu đã gánh ngân sách bảo mật lớn, và cũng không cần chờ nhiều năm để xây dựng một hệ thống người xác thực đủ mạnh.

Nhưng ở chiều ngược lại, việc dựa vào một lớp bảo mật bên ngoài cũng đồng nghĩa rằng trong quá trình phát triển sau này sẽ cần tiếp tục phối hợp cả hai phía.

Nếu một blockchain ngày càng phụ thuộc vào lớp bảo mật bên ngoài, thì hệ thống bảo mật của chính nó còn có tiếp tục trưởng thành không?

Câu hỏi này không có đáp án đơn giản.

Vì xây dựng bảo mật hoàn toàn tự chủ cũng không hề miễn phí.

Nhiều blockchain mới cuối cùng thất bại không phải vì công nghệ kém, mà vì không có đủ quy mô kinh tế để hỗ trợ bảo mật.

Thiết kế của Babylon thực ra đang giải quyết một mâu thuẫn tồn tại lâu dài:

Các blockchain nhỏ cần bảo mật, nhưng bản thân bảo mật lại cần quy mô.

Bitcoin có quy mô.

Blockchain mới cần quy mô.

Và giữa hai bên đã hình thành một mối liên kết.

Theo tôi, điều thật sự thú vị ở Babylon không chỉ là đưa BTC tham gia bảo mật, mà là thay đổi con đường xây dựng niềm tin của blockchain mới.

Trước đây:

Một blockchain cần tự mình chứng minh an toàn từng bước.

Trong tương lai:

Nó có thể bắt đầu bằng cách dựa vào bảo mật kinh tế đã có sẵn, rồi dần dần xây dựng giá trị mạng lưới của riêng mình.

Nhưng bài toán cũng để lại cho thị trường:

Nếu một blockchain mới khởi đầu dựa vào Bitcoin Security, khi nó trưởng thành lên, theo bạn nó nên tiếp tục dựa vào bảo mật bên ngoài hay cuối cùng bắt buộc phải xây dựng một hệ thống bảo mật hoàn toàn thuộc về chính mình?

#baby $BABY

Gần đây tôi trò chuyện với vài người bạn chạy node và phát hiện ra một thay đổi khá thú vị.

Trước đây, khi mọi người thảo luận về một chuỗi PoS, điều mọi người quan tâm nhất là liệu node có thể kiếm được phần thưởng hay không.

Giờ khi nhắc đến Babylon, nhiều người bắt đầu hỏi một chuyện khác:

Nếu trong tương lai ngày càng nhiều mạng chia sẻ sự an toàn của Bitcoin, thì node vẫn có thể dựa vào điều gì để tạo lợi thế cạnh tranh cho chính mình?

Trước đây, các node cạnh tranh với nhau dựa vào phần cứng, độ ổn định và năng lực vận hành.

Dù những khác biệt đó vẫn tồn tại, nhưng quy tắc tương đối rõ ràng.

Nhưng một khi nguồn gốc của sự an toàn bắt đầu thay đổi, vai trò của node cũng sẽ dần biến đổi.

Sự an toàn không còn chỉ là do chính mình cung cấp.

Trong nhiều trường hợp, điều node cần suy nghĩ là:

Làm thế nào để phối hợp với hệ thống an toàn mới, thay vì lặp lại việc đổ thêm đầu tư.

Tôi nghĩ đây có thể là một điểm mà nhiều người dễ bỏ qua.

Mọi người luôn bàn về việc BTC có “giải phóng” thanh khoản hay không, nhưng lại rất ít khi thảo luận rằng hệ sinh thái node có thể vì thế mà được phân công lại hay không.

Một hạ tầng trưởng thành không nhất định sẽ làm node biến mất.

Khả năng lớn hơn là khiến node dành nhiều thời gian và công sức hơn cho các mảng như dịch vụ mạng, đồng bộ dữ liệu, hiệu suất vận hành—những nơi thực sự thể hiện giá trị.

Điều này thực ra khác hoàn toàn với lối phát triển trước đây, liên tục gia tăng quy mô đặt cược (staking).

Vì vậy, khi nhìn Babylon lúc này, tôi đã không còn chỉ chăm chăm vào TVL hay số liệu staking.

Thứ tôi muốn quan sát hơn là:

Trong tương lai, liệu người vận hành node có chủ động điều chỉnh vai trò của mình hay không.

Nếu câu trả lời là có, thì tác động của Babylon sẽ không chỉ dừng lại ở mức hiệu quả sử dụng tài sản BTC.

Nó còn có thể thay đổi cách vận hành của một phần các mạng PoS.

Thứ thật sự đáng theo dõi lâu dài có lẽ không phải là có bao nhiêu BTC đi vào giao thức.

Mà là ngày càng nhiều người tham gia trong hệ sinh thái bắt đầu tự định nghĩa lại vị trí của mình trong toàn bộ mạng.

#baby $BABY

Hôm qua khi nghiên cứu cơ chế BTC Staking của Babylon, tôi không tiếp tục đi sâu vào chi tiết kỹ thuật nữa mà chỉ tập trung vào một câu hỏi thực tế hơn: tại sao một người nắm giữ BTC lâu dài lại sẵn sàng chủ động thay đổi thói quen nắm giữ của mình?

Trong quá khứ, một điều mà nhiều người nắm giữ BTC coi trọng nhất chính là sự đơn giản.

Mua vào.

Chuyển sang ví lạnh.

Chờ đợi.

Họ tin Bitcoin, phần lớn là vì nó không có nhiều cổng kiếm lợi phức tạp và cũng không yêu cầu quá nhiều thao tác bổ sung.

Nhưng điều Babylon muốn làm lại chính là thay đổi thói quen đó.

Nó mong muốn biến lượng BTC nhàn rỗi tham gia vào an ninh trên chuỗi, để người nắm giữ có thêm một nguồn giá trị mới. Tuy nhiên, ở đây có một mâu thuẫn mà nhiều người dễ bỏ qua:

> BTC một khi bắt đầu tạo ra lợi nhuận, nó sẽ không còn chỉ là một tài sản “để đó” nữa, mà sẽ bước vào một thị trường nơi cần cân nhắc rủi ro và chi phí cơ hội.

Đối với giao thức, việc có nhiều BTC tham gia hơn sẽ đồng nghĩa với an ninh kinh tế mạnh hơn.

Nhưng với người dùng, lại nảy sinh một vấn đề mới:

Trong thời gian bị khóa, nếu thị trường xuất hiện cơ hội thì sao?

Nếu các mạng khác gặp sự cố thì sao?

Nếu lợi nhuận không đủ bù đắp rủi ro mà mình phải gánh thì sao?

Đó chính là thách thức thực sự mà Babylon phải đối mặt.

Về mặt kỹ thuật, việc để BTC tham gia vào hệ thống an ninh là một chuyện.

Nhưng để những người tin vào giá trị đơn giản của BTC sẵn sàng thay đổi hành vi lại là chuyện khác.

Tôi nghĩ đối thủ cạnh tranh thực sự của Babylon không phải là các dự án BTC khác, mà là “tuyến phòng thủ tâm lý” của chính những người nắm giữ BTC.

Vì nhiều người mua BTC không phải để tìm thêm nhiều thao tác, mà để giảm thao tác.

Babylon đưa ra một khả năng mới:

Biến BTC từ tài sản lưu trữ giá trị tĩnh thành vốn an ninh trên chuỗi.

Nhưng cái giá cũng rất rõ ràng:

Lợi nhuận tăng lên thì chi phí ra quyết định cũng tăng theo.

Trước đây vấn đề chỉ là:

“Có nên mua BTC không?”

Còn về sau có thể sẽ thành:

“BTC của tôi có nên tham gia vào việc đảm bảo an ninh của mạng khác không?”

Nếu trong tương lai Staking BTC dần trở nên phổ biến, bạn sẽ muốn để BTC hoạt động tạo lợi nhuận, hay cho rằng giá trị lớn nhất của BTC chính là mãi mãi giữ sự đơn giản?

#baby $BABY

Tối qua khi đọc lại bản “white paper” Babylon bằng tiếng Trung, mình cứ bị kẹt ở một câu: “Bitcoin Security” chứ không phải “Bitcoin Consensus”. Hai cụm từ chỉ khác nhau vài chữ, nhưng thiết kế đằng sau thì hoàn toàn không phải chuyện tương tự.

Ban đầu mình nghĩ rằng, nếu Babylon muốn đưa Bitcoin vào mạng PoS, vậy liệu có nghĩa là BTC sẽ trực tiếp tham gia xác thực, sản sinh khối hay bỏ phiếu không? Nhưng càng đọc càng thấy phía chính thức cố tình tránh đi theo hướng đó.

Vai trò của BTC trong Babylon giống như một khoản bảo đảm kinh tế được công khai đặt ra, hơn là một “người thi hành” trong mạng. Những thực thể thực sự vận hành PoS vẫn là các nút xác thực vốn có. BTC cung cấp một lớp ràng buộc an ninh bổ sung nhằm làm chi phí cho hành vi xấu trở nên cao hơn, chứ không phải thay người khác thực hiện cơ chế đồng thuận.

> Mình bỗng nhận ra điều này hơi giống như gắn thêm bảo hiểm cho một tòa nhà, chứ không phải tháo toàn bộ kết cấu chịu lực để xây lại.

Nếu bắt Bitcoin phải gánh luôn quy trình đồng thuận của PoS, không chỉ sẽ bị giới hạn bởi khả năng của script Bitcoin và các đặc tính mạng, mà còn khiến hai cơ chế hoàn toàn khác nhau “kiềm chế” lẫn nhau. Babylon ngược lại vạch ranh giới rất rõ: BTC chịu trách nhiệm về bảo mật, còn chuỗi PoS tiếp tục chịu trách nhiệm về việc thực thi — mỗi bên giữ nguyên những lợi thế của mình.

Thiết kế này tất nhiên cũng không phải không có cái giá. Giao thức cần xây dựng thêm một loạt cơ chế để ánh xạ an ninh kinh tế của Bitcoin sang các mạng PoS khác nhau, khiến toàn bộ hệ thống trở nên phức tạp hơn so với mô hình staking truyền thống, đồng thời ngưỡng hiểu cũng cao hơn. Nhưng đổi lại, lợi ích là không cần thay đổi bản thân Bitcoin; vẫn có thể tận dụng giá trị mà nó tích lũy suốt hàng chục năm.

Trước đây mình cứ nghĩ đổi mới của Babylon chỉ là “BTC có thể được đem đi stake”. Giờ nhìn lại, thứ nó thực sự làm là biến Bitcoin — từ một tài sản có thể giao dịch — thành một nguồn tài nguyên an ninh có thể tái sử dụng.

Nếu trong tương lai ngày càng nhiều blockchain mượn “Bitcoin Security”, bạn nghĩ BTC có dần chuyển từ “lưu trữ giá trị” sang lớp an ninh nền tảng cho toàn bộ thế giới PoS không?

#baby $BABY

Hôm nay khi tôi thiết kế lại Babylon Genesis, tôi cứ mãi nhìn vào một câu hỏi: nếu toàn bộ giao thức xoay quanh tính an toàn của BTC, thì tại sao phía chính thức lại phát hành riêng BABY, thay vì để BTC gánh toàn bộ chức năng?

Tiếp tục xem thêm thì tôi nhận ra rằng ngay từ đầu phía chính thức chưa từng có ý định biến BTC thành một “tài sản vạn năng” trong mạng lưới.

Trong Babylon, BTC giống như một khoản ký quỹ đảm bảo an toàn. Nó cung cấp sự bảo đảm về mặt kinh tế, để các mạng PoS tích hợp có thể mượn “sự chứng thực về giá trị” của Bitcoin. Nhưng những gì thực sự vận hành mạng lại dựa trên một logic khác.

Các hoạt động tần suất cao như thanh toán Gas, bỏ phiếu quản trị và khuyến khích hệ sinh thái đều được giao cho BABY.

Sau đó tôi nhận ra điều này thực chất là cố tình tránh một mâu thuẫn: để một loại tài sản thiên về tích trữ giá trị lại phải đảm nhiệm những tác vụ vận hành tần suất cao.

Nếu mọi thao tác đều phụ thuộc vào BTC, thì mỗi lần tương tác với mạng sẽ trực tiếp gắn với chính bản thân tài sản Bitcoin—dù là trải nghiệm giao dịch hay thiết kế khuyến khích đều sẽ bị giới hạn. Babylon lựa chọn giao lớp thực thi cho BABY, còn lớp bảo mật giữ lại cho BTC. Về bản chất, đó là để hai loại tài sản làm tốt phần việc riêng của mình, thay vì thay thế lẫn nhau.

Tất nhiên, cách thiết kế này cũng có cái giá. Giao thức cần duy trì hai hệ thống kinh tế, ngưỡng hiểu của người dùng sẽ cao hơn, và quá trình xây dựng hệ sinh thái cũng phải đồng thời cân bằng giữa người nắm giữ BTC và người sử dụng BABY. Nhưng so với việc dồn toàn bộ trách nhiệm vào một loại tài sản, cách phân công này lại để lại nhiều không gian hơn cho khả năng mở rộng về sau.

Trước đây tôi thường nghĩ sự đổi mới của Babylon chỉ là “BTC có thể đặt cược nguyên bản”. Giờ nhìn lại, thứ nó muốn xây dựng thật sự là một kiến trúc tách biệt giữa lớp bảo mật và lớp thực thi, và sự tồn tại của BABY chính là một mắt xích quan trọng để sự phân công đó có thể vận hành lâu dài.

Nếu trong tương lai nhiều giao thức Bitcoin thuộc hệ sinh thái cũng áp dụng mô hình tương tự, bạn sẽ đánh giá cao hơn quan điểm “một loại tài sản phụ trách an toàn, một loại tài sản phụ trách vận hành”, hay vẫn giữ quan điểm rằng mọi chức năng nên tập trung hết vào BTC?

#baby $BABY