Anl_
128 Bài đăng
Anl_
Báo cáo
Chặn người dùng
Web3 😎
Giao dịch mở
Trader thường xuyên
4 tháng
32 Đang theo dõi
31 Người theo dõi
127 Đã thích
Bài đăng
Danh mục đầu tư
Tất cả
Trích dẫn
·
--
Xem bản dịch
#dusk $DUSK @Dusk_Foundation
So who decides whether you may hold a tokenized asset, and how is that checked without knowing everything about you?
I never thought about either half. I assumed the asset gets created, people buy it, and the paperwork happens somewhere out of sight.
The sequence runs the other way. Before anything trades, the issuer defines the asset, the eligibility requirements, and the rules governing its life. Only then does anything move. Issuance is really an act of rule-writing, and the token is close to a by-product.
That creates a problem I had not connected to it. If the rules depend on facts about a person, checking them normally means storing those facts. And in Europe, personal information carries rights, including in some cases the right to be erased. A ledger built so nothing can ever be erased sits awkwardly beside that.
The only clean resolution is to keep the personal data off the permanent record entirely and put a proof there instead. If the information was never written, the erasure question mostly answers itself.
Which brings in the third piece, and it decides whether any of this is realistic. Proofs are only useful if checking them is affordable. I had assumed serious cryptography and smart contracts were a bad match — possible, but too expensive for ordinary use. Dusk treats proof verification as a native capability rather than something each contract rebuilds.
What I still cannot judge is how this holds when an application genuinely needs to know something about a person to serve them, which describes most of regulated finance.
From here I read privacy claims differently. The strongest version is not stronger encryption. It is arranging things so the sensitive data was never recorded at all.
#dusk $DUSK @Dusk
So who decides whether you may hold a tokenized asset, and how is that checked without knowing everything about you?
I never thought about either half. I assumed the asset gets created, people buy it, and the paperwork happens somewhere out of sight.
The sequence runs the other way. Before anything trades, the issuer defines the asset, the eligibility requirements, and the rules governing its life. Only then does anything move. Issuance is really an act of rule-writing, and the token is close to a by-product.
That creates a problem I had not connected to it. If the rules depend on facts about a person, checking them normally means storing those facts. And in Europe, personal information carries rights, including in some cases the right to be erased. A ledger built so nothing can ever be erased sits awkwardly beside that.
The only clean resolution is to keep the personal data off the permanent record entirely and put a proof there instead. If the information was never written, the erasure question mostly answers itself.
Which brings in the third piece, and it decides whether any of this is realistic. Proofs are only useful if checking them is affordable. I had assumed serious cryptography and smart contracts were a bad match — possible, but too expensive for ordinary use. Dusk treats proof verification as a native capability rather than something each contract rebuilds.
What I still cannot judge is how this holds when an application genuinely needs to know something about a person to serve them, which describes most of regulated finance.
From here I read privacy claims differently. The strongest version is not stronger encryption. It is arranging things so the sensitive data was never recorded at all.
So who decides whether you may hold a tokenized asset, and how is that checked without knowing everything about you?
I never thought about either half. I assumed the asset gets created, people buy it, and the paperwork happens somewhere out of sight.
The sequence runs the other way. Before anything trades, the issuer defines the asset, the eligibility requirements, and the rules governing its life. Only then does anything move. Issuance is really an act of rule-writing, and the token is close to a by-product.
That creates a problem I had not connected to it. If the rules depend on facts about a person, checking them normally means storing those facts. And in Europe, personal information carries rights, including in some cases the right to be erased. A ledger built so nothing can ever be erased sits awkwardly beside that.
The only clean resolution is to keep the personal data off the permanent record entirely and put a proof there instead. If the information was never written, the erasure question mostly answers itself.
Which brings in the third piece, and it decides whether any of this is realistic. Proofs are only useful if checking them is affordable. I had assumed serious cryptography and smart contracts were a bad match — possible, but too expensive for ordinary use. Dusk treats proof verification as a native capability rather than something each contract rebuilds.
What I still cannot judge is how this holds when an application genuinely needs to know something about a person to serve them, which describes most of regulated finance.
From here I read privacy claims differently. The strongest version is not stronger encryption. It is arranging things so the sensitive data was never recorded at all.
10
·
--
Xem bản dịch
#dusk $DUSK @Dusk_Foundation
So when you buy something on-chain, who are you buying it from?
In ordinary crypto, the answer is nobody in particular, and that is treated as a feature. You interact with a contract, the trade executes, and the identity of the other party is irrelevant.
In regulated markets, that answer is unacceptable, and I did not appreciate how deeply until recently.
Institutions are required to know who they are dealing with. Not out of curiosity — because they carry obligations about who they are permitted to transact with, and those obligations do not disappear because the trade happened on a blockchain. An anonymous counterparty is not an efficiency for them. It is a compliance failure.
What caught my attention is how much this reshapes what a financial chain has to provide. It cannot only prove that a transaction is valid. It has to allow participants to establish that the other party is someone they are allowed to trade with, without exposing that person to everyone else watching the chain.
That is a harder problem than privacy alone, and a harder problem than transparency alone. It sits awkwardly between them.
I am still working out how much of that is genuinely solvable with cryptography and how much simply moves the question to whoever issued the credentials.
From here I stopped thinking about anonymity as the default good in finance. Sometimes the ability to know who is on the other side is exactly what makes the market possible.
#dusk $DUSK @Dusk
So when you buy something on-chain, who are you buying it from?
In ordinary crypto, the answer is nobody in particular, and that is treated as a feature. You interact with a contract, the trade executes, and the identity of the other party is irrelevant.
In regulated markets, that answer is unacceptable, and I did not appreciate how deeply until recently.
Institutions are required to know who they are dealing with. Not out of curiosity — because they carry obligations about who they are permitted to transact with, and those obligations do not disappear because the trade happened on a blockchain. An anonymous counterparty is not an efficiency for them. It is a compliance failure.
What caught my attention is how much this reshapes what a financial chain has to provide. It cannot only prove that a transaction is valid. It has to allow participants to establish that the other party is someone they are allowed to trade with, without exposing that person to everyone else watching the chain.
That is a harder problem than privacy alone, and a harder problem than transparency alone. It sits awkwardly between them.
I am still working out how much of that is genuinely solvable with cryptography and how much simply moves the question to whoever issued the credentials.
From here I stopped thinking about anonymity as the default good in finance. Sometimes the ability to know who is on the other side is exactly what makes the market possible.
So when you buy something on-chain, who are you buying it from?
In ordinary crypto, the answer is nobody in particular, and that is treated as a feature. You interact with a contract, the trade executes, and the identity of the other party is irrelevant.
In regulated markets, that answer is unacceptable, and I did not appreciate how deeply until recently.
Institutions are required to know who they are dealing with. Not out of curiosity — because they carry obligations about who they are permitted to transact with, and those obligations do not disappear because the trade happened on a blockchain. An anonymous counterparty is not an efficiency for them. It is a compliance failure.
What caught my attention is how much this reshapes what a financial chain has to provide. It cannot only prove that a transaction is valid. It has to allow participants to establish that the other party is someone they are allowed to trade with, without exposing that person to everyone else watching the chain.
That is a harder problem than privacy alone, and a harder problem than transparency alone. It sits awkwardly between them.
I am still working out how much of that is genuinely solvable with cryptography and how much simply moves the question to whoever issued the credentials.
From here I stopped thinking about anonymity as the default good in finance. Sometimes the ability to know who is on the other side is exactly what makes the market possible.
19
·
--
#dusk $DUSK @Dusk_Foundation
Vậy khi một giao dịch được "xác nhận", thực sự đã xảy ra điều gì?
Trước đây, tôi từng coi xác nhận và tính chung cuộc là cùng một từ. Tôi thấy một giao dịch được chuyển qua, chờ một lúc, rồi coi như mọi chuyện đã kết thúc. Nếu ai đó hỏi tôi liệu nó vẫn có thể bị đảo ngược không, tôi sẽ nói là không—mà không thật sự suy nghĩ vì sao.
Nhưng khi tìm hiểu kỹ hơn về cách Dusk mô tả phần thanh toán, tôi nhận ra mình đã gộp hai ý khác nhau lại với nhau.
Trên hầu hết các chuỗi, giao dịch sẽ an toàn hơn theo thời gian bạn chờ. Không có gì tuyên bố nó là vĩnh viễn. Bạn chỉ tiến tới một điểm mà việc đảo ngược nó sẽ quá tốn kém đến mức không ai hợp lý sẽ làm. Đó là xác suất, không phải lời hứa.
Dusk tiếp cận theo cách khác. Đồng thuận của nó được thiết kế để một khối được “thanh toán” theo chính các quy tắc của giao thức, thay vì dần dần trở nên an toàn hơn theo thời gian.
Điều tôi thấy đặc biệt đáng chú ý là vì sao sự khác biệt này lại quan trọng hơn trong tài chính nhiều hơn là trong các trường hợp sử dụng crypto thông thường. Nếu tôi gửi ai đó tiền và cần thêm một phút để cảm thấy an toàn, thì không có điều gì quan trọng xảy ra. Nhưng một hệ thống thanh toán không thể vận hành dựa trên “khả năng gần như chắc chắn là vĩnh viễn”. Ai đó phải chịu trách nhiệm cho khoảnh khắc một giao dịch chuyển từ có thể bị đảo ngược sang không thể đảo ngược, và khoảnh khắc đó phải là một sự thật chứ không phải một ước tính.
Điều này cũng giải thích một điều trước đó làm tôi băn khoăn. Việc xây dựng một lớp thanh toán từ đầu là công việc khổng lồ, trong khi đã có sẵn các phương án nhanh hơn. Chỉ có thể hợp lý nếu bản thân sự đảm bảo đó mới là sản phẩm.
Tôi vẫn chưa thể nói nó sẽ vận hành ra sao khi mạng chịu áp lực thực sự, chứ không phải trong điều kiện bình thường. Đó là nơi các thiết kế thường bộc lộ rõ ràng họ đã hứa điều gì thực sự.
Nhưng từ đây, tôi đã không còn đọc “xác nhận” như một ý nghĩa duy nhất. Có khoảnh khắc một giao dịch xảy ra, và có khoảnh khắc nó không còn có thể bị đảo ngược, và hai khoảnh khắc đó không phải lúc nào cũng giống nhau.
#dusk $DUSK @Dusk
Vậy khi một giao dịch được "xác nhận", thực sự đã xảy ra điều gì?
Trước đây, tôi từng coi xác nhận và tính chung cuộc là cùng một từ. Tôi thấy một giao dịch được chuyển qua, chờ một lúc, rồi coi như mọi chuyện đã kết thúc. Nếu ai đó hỏi tôi liệu nó vẫn có thể bị đảo ngược không, tôi sẽ nói là không—mà không thật sự suy nghĩ vì sao.
Nhưng khi tìm hiểu kỹ hơn về cách Dusk mô tả phần thanh toán, tôi nhận ra mình đã gộp hai ý khác nhau lại với nhau.
Trên hầu hết các chuỗi, giao dịch sẽ an toàn hơn theo thời gian bạn chờ. Không có gì tuyên bố nó là vĩnh viễn. Bạn chỉ tiến tới một điểm mà việc đảo ngược nó sẽ quá tốn kém đến mức không ai hợp lý sẽ làm. Đó là xác suất, không phải lời hứa.
Dusk tiếp cận theo cách khác. Đồng thuận của nó được thiết kế để một khối được “thanh toán” theo chính các quy tắc của giao thức, thay vì dần dần trở nên an toàn hơn theo thời gian.
Điều tôi thấy đặc biệt đáng chú ý là vì sao sự khác biệt này lại quan trọng hơn trong tài chính nhiều hơn là trong các trường hợp sử dụng crypto thông thường. Nếu tôi gửi ai đó tiền và cần thêm một phút để cảm thấy an toàn, thì không có điều gì quan trọng xảy ra. Nhưng một hệ thống thanh toán không thể vận hành dựa trên “khả năng gần như chắc chắn là vĩnh viễn”. Ai đó phải chịu trách nhiệm cho khoảnh khắc một giao dịch chuyển từ có thể bị đảo ngược sang không thể đảo ngược, và khoảnh khắc đó phải là một sự thật chứ không phải một ước tính.
Điều này cũng giải thích một điều trước đó làm tôi băn khoăn. Việc xây dựng một lớp thanh toán từ đầu là công việc khổng lồ, trong khi đã có sẵn các phương án nhanh hơn. Chỉ có thể hợp lý nếu bản thân sự đảm bảo đó mới là sản phẩm.
Tôi vẫn chưa thể nói nó sẽ vận hành ra sao khi mạng chịu áp lực thực sự, chứ không phải trong điều kiện bình thường. Đó là nơi các thiết kế thường bộc lộ rõ ràng họ đã hứa điều gì thực sự.
Nhưng từ đây, tôi đã không còn đọc “xác nhận” như một ý nghĩa duy nhất. Có khoảnh khắc một giao dịch xảy ra, và có khoảnh khắc nó không còn có thể bị đảo ngược, và hai khoảnh khắc đó không phải lúc nào cũng giống nhau.
Vậy khi một giao dịch được "xác nhận", thực sự đã xảy ra điều gì?
Trước đây, tôi từng coi xác nhận và tính chung cuộc là cùng một từ. Tôi thấy một giao dịch được chuyển qua, chờ một lúc, rồi coi như mọi chuyện đã kết thúc. Nếu ai đó hỏi tôi liệu nó vẫn có thể bị đảo ngược không, tôi sẽ nói là không—mà không thật sự suy nghĩ vì sao.
Nhưng khi tìm hiểu kỹ hơn về cách Dusk mô tả phần thanh toán, tôi nhận ra mình đã gộp hai ý khác nhau lại với nhau.
Trên hầu hết các chuỗi, giao dịch sẽ an toàn hơn theo thời gian bạn chờ. Không có gì tuyên bố nó là vĩnh viễn. Bạn chỉ tiến tới một điểm mà việc đảo ngược nó sẽ quá tốn kém đến mức không ai hợp lý sẽ làm. Đó là xác suất, không phải lời hứa.
Dusk tiếp cận theo cách khác. Đồng thuận của nó được thiết kế để một khối được “thanh toán” theo chính các quy tắc của giao thức, thay vì dần dần trở nên an toàn hơn theo thời gian.
Điều tôi thấy đặc biệt đáng chú ý là vì sao sự khác biệt này lại quan trọng hơn trong tài chính nhiều hơn là trong các trường hợp sử dụng crypto thông thường. Nếu tôi gửi ai đó tiền và cần thêm một phút để cảm thấy an toàn, thì không có điều gì quan trọng xảy ra. Nhưng một hệ thống thanh toán không thể vận hành dựa trên “khả năng gần như chắc chắn là vĩnh viễn”. Ai đó phải chịu trách nhiệm cho khoảnh khắc một giao dịch chuyển từ có thể bị đảo ngược sang không thể đảo ngược, và khoảnh khắc đó phải là một sự thật chứ không phải một ước tính.
Điều này cũng giải thích một điều trước đó làm tôi băn khoăn. Việc xây dựng một lớp thanh toán từ đầu là công việc khổng lồ, trong khi đã có sẵn các phương án nhanh hơn. Chỉ có thể hợp lý nếu bản thân sự đảm bảo đó mới là sản phẩm.
Tôi vẫn chưa thể nói nó sẽ vận hành ra sao khi mạng chịu áp lực thực sự, chứ không phải trong điều kiện bình thường. Đó là nơi các thiết kế thường bộc lộ rõ ràng họ đã hứa điều gì thực sự.
Nhưng từ đây, tôi đã không còn đọc “xác nhận” như một ý nghĩa duy nhất. Có khoảnh khắc một giao dịch xảy ra, và có khoảnh khắc nó không còn có thể bị đảo ngược, và hai khoảnh khắc đó không phải lúc nào cũng giống nhau.
6
·
--
#dusk $DUSK @Dusk_Foundation Trước đây, tôi cứ nghĩ một blockchain phải “chọn phe”: hoặc là permissionless (không ai bị gác cổng, bất kỳ ai cũng có thể giao dịch), hoặc là permissioned (một liên minh quyết định ai được tham gia). Công khai hay riêng tư. Một trong hai.
Nhưng càng đọc về Dusk, tôi càng thấy sự phân chia đó không mô tả đúng những gì đang được xây dựng.
Lớp nền là mở. Bất kỳ ai cũng có thể chạy node, bất kỳ ai cũng có thể stake, mã nguồn là công khai và không có ủy ban nào phê duyệt sự tham gia của bạn. Trong khi đó, các tài sản dự định tồn tại trên lớp đó lại hoàn toàn ngược lại: tính đủ điều kiện bị hạn chế, việc chuyển nhượng được kiểm soát và chỉ có thể nắm giữ bởi các bên đã được xác minh.
Điều tôi thấy đặc biệt đáng chú ý là hai phần này không hề mâu thuẫn, bởi chúng vận hành ở những lớp khác nhau. Mạng không cần biết bạn là ai để đưa giao dịch của bạn vào khối. Còn tài sản thì cần biết bạn là ai trước khi nó cho phép bạn nắm giữ. Sự mở ở lớp thanh toán, sự hạn chế ở lớp công cụ.
Các thị trường truyền thống đã hoạt động theo cách này, và hiếm khi chúng ta để ý. Hạ tầng internet mang theo một giao dịch cổ phần mà không có ý kiến gì về việc bạn có được phép sở hữu cổ phần đó hay không. Vận chuyển thì trung lập. Còn công cụ thì không.
Điều khiến việc này khó trên chuỗi là vì hầu hết mọi người đánh giá một chain như một thực thể duy nhất. Vì vậy họ hỏi liệu Dusk có permissionless hay không, nhận được câu trả lời một phần, rồi rút ra kết luận sai theo cả hai hướng.
Tôi vẫn chưa chắc điều này sẽ đứng vững thế nào khi một tài sản bị hạn chế “đi” đến nơi mà hạn chế đó không thể theo nó — đó mới là tình huống thực sự khó.
Từ đây, tôi ngừng việc tự hỏi liệu chuỗi có mở hay đóng. Câu hỏi hữu ích hơn là: tính “mở” nằm ở lớp nào, và liệu các hạn chế ở lớp phía trên có được thực thi bằng mã hay chỉ bằng sự thỏa thuận.
#dusk $DUSK @Dusk Trước đây, tôi cứ nghĩ một blockchain phải “chọn phe”: hoặc là permissionless (không ai bị gác cổng, bất kỳ ai cũng có thể giao dịch), hoặc là permissioned (một liên minh quyết định ai được tham gia). Công khai hay riêng tư. Một trong hai.
Nhưng càng đọc về Dusk, tôi càng thấy sự phân chia đó không mô tả đúng những gì đang được xây dựng.
Lớp nền là mở. Bất kỳ ai cũng có thể chạy node, bất kỳ ai cũng có thể stake, mã nguồn là công khai và không có ủy ban nào phê duyệt sự tham gia của bạn. Trong khi đó, các tài sản dự định tồn tại trên lớp đó lại hoàn toàn ngược lại: tính đủ điều kiện bị hạn chế, việc chuyển nhượng được kiểm soát và chỉ có thể nắm giữ bởi các bên đã được xác minh.
Điều tôi thấy đặc biệt đáng chú ý là hai phần này không hề mâu thuẫn, bởi chúng vận hành ở những lớp khác nhau. Mạng không cần biết bạn là ai để đưa giao dịch của bạn vào khối. Còn tài sản thì cần biết bạn là ai trước khi nó cho phép bạn nắm giữ. Sự mở ở lớp thanh toán, sự hạn chế ở lớp công cụ.
Các thị trường truyền thống đã hoạt động theo cách này, và hiếm khi chúng ta để ý. Hạ tầng internet mang theo một giao dịch cổ phần mà không có ý kiến gì về việc bạn có được phép sở hữu cổ phần đó hay không. Vận chuyển thì trung lập. Còn công cụ thì không.
Điều khiến việc này khó trên chuỗi là vì hầu hết mọi người đánh giá một chain như một thực thể duy nhất. Vì vậy họ hỏi liệu Dusk có permissionless hay không, nhận được câu trả lời một phần, rồi rút ra kết luận sai theo cả hai hướng.
Tôi vẫn chưa chắc điều này sẽ đứng vững thế nào khi một tài sản bị hạn chế “đi” đến nơi mà hạn chế đó không thể theo nó — đó mới là tình huống thực sự khó.
Từ đây, tôi ngừng việc tự hỏi liệu chuỗi có mở hay đóng. Câu hỏi hữu ích hơn là: tính “mở” nằm ở lớp nào, và liệu các hạn chế ở lớp phía trên có được thực thi bằng mã hay chỉ bằng sự thỏa thuận.
Nhưng càng đọc về Dusk, tôi càng thấy sự phân chia đó không mô tả đúng những gì đang được xây dựng.
Lớp nền là mở. Bất kỳ ai cũng có thể chạy node, bất kỳ ai cũng có thể stake, mã nguồn là công khai và không có ủy ban nào phê duyệt sự tham gia của bạn. Trong khi đó, các tài sản dự định tồn tại trên lớp đó lại hoàn toàn ngược lại: tính đủ điều kiện bị hạn chế, việc chuyển nhượng được kiểm soát và chỉ có thể nắm giữ bởi các bên đã được xác minh.
Điều tôi thấy đặc biệt đáng chú ý là hai phần này không hề mâu thuẫn, bởi chúng vận hành ở những lớp khác nhau. Mạng không cần biết bạn là ai để đưa giao dịch của bạn vào khối. Còn tài sản thì cần biết bạn là ai trước khi nó cho phép bạn nắm giữ. Sự mở ở lớp thanh toán, sự hạn chế ở lớp công cụ.
Các thị trường truyền thống đã hoạt động theo cách này, và hiếm khi chúng ta để ý. Hạ tầng internet mang theo một giao dịch cổ phần mà không có ý kiến gì về việc bạn có được phép sở hữu cổ phần đó hay không. Vận chuyển thì trung lập. Còn công cụ thì không.
Điều khiến việc này khó trên chuỗi là vì hầu hết mọi người đánh giá một chain như một thực thể duy nhất. Vì vậy họ hỏi liệu Dusk có permissionless hay không, nhận được câu trả lời một phần, rồi rút ra kết luận sai theo cả hai hướng.
Tôi vẫn chưa chắc điều này sẽ đứng vững thế nào khi một tài sản bị hạn chế “đi” đến nơi mà hạn chế đó không thể theo nó — đó mới là tình huống thực sự khó.
Từ đây, tôi ngừng việc tự hỏi liệu chuỗi có mở hay đóng. Câu hỏi hữu ích hơn là: tính “mở” nằm ở lớp nào, và liệu các hạn chế ở lớp phía trên có được thực thi bằng mã hay chỉ bằng sự thỏa thuận.
70
·
--
#dusk $DUSK @Dusk_Foundation Khi bạn nghe “privacy coin” (đồng tiền riêng tư), bạn nghĩ ngay đến Monero hay Zcash?
Tôi cũng vậy. Nhưng sự so sánh sẽ thú vị hơn khi bạn tự hỏi “quyền riêng tư” được cho là phải đạt được điều gì.
Monero theo lập trường cứng rắn: quyền riêng tư là bắt buộc. Người gửi, người nhận và số tiền được ẩn mặc định. Zcash linh hoạt hơn, với các giao dịch được che chắn (shielded) và các khóa xem (viewing keys) có thể tiết lộ thông tin một cách có chọn lọc.
Dusk đưa triết lý thứ hai này thẳng vào tài chính được quản lý.
Ý tưởng là quyền riêng tư kèm công bố có chọn lọc: hoạt động tài chính của bạn không cần phải công khai, nhưng một bên được ủy quyền — một kiểm toán viên, người giám sát hoặc tổ chức — có thể nhận được đúng bằng chứng cụ thể mà họ cần mà không phải xem mọi thứ khác.
Tôi hiểu vì sao các tổ chức sẽ thích điều này.
Các ngân hàng, tổ chức phát hành và thị trường được quản lý cần sự bảo mật, nhưng họ cũng không thể vận hành trong một hệ thống mà không thể chứng minh rằng việc tuân thủ là khả thi.
Những tranh cãi cũng hiển nhiên.
Với một người ủng hộ quyền riêng tư gốc crypto, “khả năng hiển thị có ủy quyền” có thể nghe ít giống quyền riêng tư và nhiều hơn như một cánh cửa hậu được kiểm soát. Nếu ai đó có thể được cấp quyền truy cập, thì lập luận chuyển sang vấn đề ai là người kiểm soát quyền truy cập đó và theo những quy tắc nào.
Rồi còn vấn đề về mức độ chấp nhận.
Áp lực quy định lên các tài sản tập trung vào tính ẩn danh không còn là giả thuyết. Kraken đã loại Monero khỏi danh sách cho khách hàng ở EEA, nêu rõ những thay đổi về quy định.
Điều đó khiến thỏa hiệp của Dusk trông có vẻ “dễ sống sót” hơn về mặt thương mại: ẩn thông tin khỏi công chúng nhưng vẫn cho phép kiểm chứng theo khuôn khổ được quản lý.
Nhưng “dễ được áp dụng hơn” không tự động đồng nghĩa với “quyền riêng tư tốt hơn”.
Có thể sự ẩn danh thuần túy bảo vệ nguyên tắc tốt hơn nhưng lại gặp khó khăn trong việc cấp quyền truy cập cho các tổ chức. Hoặc việc công bố có chọn lọc đánh đổi sự trong sạch về mặt ý thức hệ để làm cho quyền riêng tư có thể sử dụng trong hệ thống tài chính.
Và điều này để lại câu hỏi khó chịu:
Nếu quyền riêng tư vẫn có thể được chứng minh với “một ai đó”, thì nó có còn thật sự là quyền riêng tư — hay chỉ là khả năng hiển thị do quy định quản lý?
#dusk $DUSK @Dusk Khi bạn nghe “privacy coin” (đồng tiền riêng tư), bạn nghĩ ngay đến Monero hay Zcash?
Tôi cũng vậy. Nhưng sự so sánh sẽ thú vị hơn khi bạn tự hỏi “quyền riêng tư” được cho là phải đạt được điều gì.
Monero theo lập trường cứng rắn: quyền riêng tư là bắt buộc. Người gửi, người nhận và số tiền được ẩn mặc định. Zcash linh hoạt hơn, với các giao dịch được che chắn (shielded) và các khóa xem (viewing keys) có thể tiết lộ thông tin một cách có chọn lọc.
Dusk đưa triết lý thứ hai này thẳng vào tài chính được quản lý.
Ý tưởng là quyền riêng tư kèm công bố có chọn lọc: hoạt động tài chính của bạn không cần phải công khai, nhưng một bên được ủy quyền — một kiểm toán viên, người giám sát hoặc tổ chức — có thể nhận được đúng bằng chứng cụ thể mà họ cần mà không phải xem mọi thứ khác.
Tôi hiểu vì sao các tổ chức sẽ thích điều này.
Các ngân hàng, tổ chức phát hành và thị trường được quản lý cần sự bảo mật, nhưng họ cũng không thể vận hành trong một hệ thống mà không thể chứng minh rằng việc tuân thủ là khả thi.
Những tranh cãi cũng hiển nhiên.
Với một người ủng hộ quyền riêng tư gốc crypto, “khả năng hiển thị có ủy quyền” có thể nghe ít giống quyền riêng tư và nhiều hơn như một cánh cửa hậu được kiểm soát. Nếu ai đó có thể được cấp quyền truy cập, thì lập luận chuyển sang vấn đề ai là người kiểm soát quyền truy cập đó và theo những quy tắc nào.
Rồi còn vấn đề về mức độ chấp nhận.
Áp lực quy định lên các tài sản tập trung vào tính ẩn danh không còn là giả thuyết. Kraken đã loại Monero khỏi danh sách cho khách hàng ở EEA, nêu rõ những thay đổi về quy định.
Điều đó khiến thỏa hiệp của Dusk trông có vẻ “dễ sống sót” hơn về mặt thương mại: ẩn thông tin khỏi công chúng nhưng vẫn cho phép kiểm chứng theo khuôn khổ được quản lý.
Nhưng “dễ được áp dụng hơn” không tự động đồng nghĩa với “quyền riêng tư tốt hơn”.
Có thể sự ẩn danh thuần túy bảo vệ nguyên tắc tốt hơn nhưng lại gặp khó khăn trong việc cấp quyền truy cập cho các tổ chức. Hoặc việc công bố có chọn lọc đánh đổi sự trong sạch về mặt ý thức hệ để làm cho quyền riêng tư có thể sử dụng trong hệ thống tài chính.
Và điều này để lại câu hỏi khó chịu:
Nếu quyền riêng tư vẫn có thể được chứng minh với “một ai đó”, thì nó có còn thật sự là quyền riêng tư — hay chỉ là khả năng hiển thị do quy định quản lý?
Tôi cũng vậy. Nhưng sự so sánh sẽ thú vị hơn khi bạn tự hỏi “quyền riêng tư” được cho là phải đạt được điều gì.
Monero theo lập trường cứng rắn: quyền riêng tư là bắt buộc. Người gửi, người nhận và số tiền được ẩn mặc định. Zcash linh hoạt hơn, với các giao dịch được che chắn (shielded) và các khóa xem (viewing keys) có thể tiết lộ thông tin một cách có chọn lọc.
Dusk đưa triết lý thứ hai này thẳng vào tài chính được quản lý.
Ý tưởng là quyền riêng tư kèm công bố có chọn lọc: hoạt động tài chính của bạn không cần phải công khai, nhưng một bên được ủy quyền — một kiểm toán viên, người giám sát hoặc tổ chức — có thể nhận được đúng bằng chứng cụ thể mà họ cần mà không phải xem mọi thứ khác.
Tôi hiểu vì sao các tổ chức sẽ thích điều này.
Các ngân hàng, tổ chức phát hành và thị trường được quản lý cần sự bảo mật, nhưng họ cũng không thể vận hành trong một hệ thống mà không thể chứng minh rằng việc tuân thủ là khả thi.
Những tranh cãi cũng hiển nhiên.
Với một người ủng hộ quyền riêng tư gốc crypto, “khả năng hiển thị có ủy quyền” có thể nghe ít giống quyền riêng tư và nhiều hơn như một cánh cửa hậu được kiểm soát. Nếu ai đó có thể được cấp quyền truy cập, thì lập luận chuyển sang vấn đề ai là người kiểm soát quyền truy cập đó và theo những quy tắc nào.
Rồi còn vấn đề về mức độ chấp nhận.
Áp lực quy định lên các tài sản tập trung vào tính ẩn danh không còn là giả thuyết. Kraken đã loại Monero khỏi danh sách cho khách hàng ở EEA, nêu rõ những thay đổi về quy định.
Điều đó khiến thỏa hiệp của Dusk trông có vẻ “dễ sống sót” hơn về mặt thương mại: ẩn thông tin khỏi công chúng nhưng vẫn cho phép kiểm chứng theo khuôn khổ được quản lý.
Nhưng “dễ được áp dụng hơn” không tự động đồng nghĩa với “quyền riêng tư tốt hơn”.
Có thể sự ẩn danh thuần túy bảo vệ nguyên tắc tốt hơn nhưng lại gặp khó khăn trong việc cấp quyền truy cập cho các tổ chức. Hoặc việc công bố có chọn lọc đánh đổi sự trong sạch về mặt ý thức hệ để làm cho quyền riêng tư có thể sử dụng trong hệ thống tài chính.
Và điều này để lại câu hỏi khó chịu:
Nếu quyền riêng tư vẫn có thể được chứng minh với “một ai đó”, thì nó có còn thật sự là quyền riêng tư — hay chỉ là khả năng hiển thị do quy định quản lý?
1
1
151
·
--
Hầu hết các chuỗi proof-of-stake đều làm một việc sau khi một khối được đề xuất: một ủy ban bỏ phiếu, và nếu đủ phiếu được nhận, thì khối được tính.
@Dusk_Foundation làm điều đó hai lần, và vòng thứ hai là vòng mà chẳng ai giải thích.
Succinct Attestation chạy mỗi vòng theo ba bước. Một người đề xuất đề xuất một khối ứng viên. Một ủy ban được chọn ngẫu nhiên sẽ xác thực nó. Sau đó, một ủy ban thứ hai sẽ phê chuẩn — và điều nó xác nhận không phải là khối. Nó xác nhận kết quả xác thực.
Sự khác biệt đó đã khiến tôi mất một thời gian mới nhìn ra đúng.
Xác thực trả lời “khối này có hợp lệ không?”. Phê chuẩn trả lời “mạng thực sự đã đồng ý rằng nó đã được xác thực chưa?”. Đó là hai câu hỏi khác nhau, và câu hỏi thứ hai là nơi quyết định cuối cùng mang tính tất định xuất hiện. Không có nó, bạn chỉ có ý kiến của một ủy ban, được truyền đi khắp mạng, đến các nút khác nhau vào những thời điểm khác nhau. Với nó, bạn có một bản ghi đã được chứng thực rằng chính sự đồng thuận đó đã xảy ra.
Đó là sự khác biệt giữa “khối này rất có khả năng là cuối cùng” và “khối này là cuối cùng.” Với một chuỗi nhắm tới thanh toán chứng khoán, khoảng trống đó không phải là chuyện triết học. Đó là sự khác biệt giữa một cam kết đảm bảo thanh toán và một ước tính thanh toán.
Chi phí cũng là thật. Hai ủy ban đồng nghĩa với hai vòng ký, hai cơ hội để việc tham gia có thể không đạt, và phần thưởng được chia phản ánh điều đó — cả xác thực và phê chuẩn đều lấy một phần thưởng của khối, tách khỏi phần người tạo khối.
Liệu vòng thêm đó có đáng giá so với độ trễ và chi phí điều phối hay không là đúng kiểu thứ mà một cuộc kiểm toán không thể cho bạn biết. Bài đánh giá của Oak Security nói rằng giao thức được thiết kế tốt. “Được thiết kế tốt” và “phù hợp với tải thực tế” là những tuyên bố khác nhau.
Câu hỏi thật cho các nhà vận hành node ở đây: đã ai đo xem việc phê chuẩn có bị chậm nhiều hơn không — chứ không phải khâu xác thực không?
#dusk $DUSK #block
Hầu hết các chuỗi proof-of-stake đều làm một việc sau khi một khối được đề xuất: một ủy ban bỏ phiếu, và nếu đủ phiếu được nhận, thì khối được tính.
@Dusk làm điều đó hai lần, và vòng thứ hai là vòng mà chẳng ai giải thích.
Succinct Attestation chạy mỗi vòng theo ba bước. Một người đề xuất đề xuất một khối ứng viên. Một ủy ban được chọn ngẫu nhiên sẽ xác thực nó. Sau đó, một ủy ban thứ hai sẽ phê chuẩn — và điều nó xác nhận không phải là khối. Nó xác nhận kết quả xác thực.
Sự khác biệt đó đã khiến tôi mất một thời gian mới nhìn ra đúng.
Xác thực trả lời “khối này có hợp lệ không?”. Phê chuẩn trả lời “mạng thực sự đã đồng ý rằng nó đã được xác thực chưa?”. Đó là hai câu hỏi khác nhau, và câu hỏi thứ hai là nơi quyết định cuối cùng mang tính tất định xuất hiện. Không có nó, bạn chỉ có ý kiến của một ủy ban, được truyền đi khắp mạng, đến các nút khác nhau vào những thời điểm khác nhau. Với nó, bạn có một bản ghi đã được chứng thực rằng chính sự đồng thuận đó đã xảy ra.
Đó là sự khác biệt giữa “khối này rất có khả năng là cuối cùng” và “khối này là cuối cùng.” Với một chuỗi nhắm tới thanh toán chứng khoán, khoảng trống đó không phải là chuyện triết học. Đó là sự khác biệt giữa một cam kết đảm bảo thanh toán và một ước tính thanh toán.
Chi phí cũng là thật. Hai ủy ban đồng nghĩa với hai vòng ký, hai cơ hội để việc tham gia có thể không đạt, và phần thưởng được chia phản ánh điều đó — cả xác thực và phê chuẩn đều lấy một phần thưởng của khối, tách khỏi phần người tạo khối.
Liệu vòng thêm đó có đáng giá so với độ trễ và chi phí điều phối hay không là đúng kiểu thứ mà một cuộc kiểm toán không thể cho bạn biết. Bài đánh giá của Oak Security nói rằng giao thức được thiết kế tốt. “Được thiết kế tốt” và “phù hợp với tải thực tế” là những tuyên bố khác nhau.
Câu hỏi thật cho các nhà vận hành node ở đây: đã ai đo xem việc phê chuẩn có bị chậm nhiều hơn không — chứ không phải khâu xác thực không?
#dusk $DUSK #block
@Dusk làm điều đó hai lần, và vòng thứ hai là vòng mà chẳng ai giải thích.
Succinct Attestation chạy mỗi vòng theo ba bước. Một người đề xuất đề xuất một khối ứng viên. Một ủy ban được chọn ngẫu nhiên sẽ xác thực nó. Sau đó, một ủy ban thứ hai sẽ phê chuẩn — và điều nó xác nhận không phải là khối. Nó xác nhận kết quả xác thực.
Sự khác biệt đó đã khiến tôi mất một thời gian mới nhìn ra đúng.
Xác thực trả lời “khối này có hợp lệ không?”. Phê chuẩn trả lời “mạng thực sự đã đồng ý rằng nó đã được xác thực chưa?”. Đó là hai câu hỏi khác nhau, và câu hỏi thứ hai là nơi quyết định cuối cùng mang tính tất định xuất hiện. Không có nó, bạn chỉ có ý kiến của một ủy ban, được truyền đi khắp mạng, đến các nút khác nhau vào những thời điểm khác nhau. Với nó, bạn có một bản ghi đã được chứng thực rằng chính sự đồng thuận đó đã xảy ra.
Đó là sự khác biệt giữa “khối này rất có khả năng là cuối cùng” và “khối này là cuối cùng.” Với một chuỗi nhắm tới thanh toán chứng khoán, khoảng trống đó không phải là chuyện triết học. Đó là sự khác biệt giữa một cam kết đảm bảo thanh toán và một ước tính thanh toán.
Chi phí cũng là thật. Hai ủy ban đồng nghĩa với hai vòng ký, hai cơ hội để việc tham gia có thể không đạt, và phần thưởng được chia phản ánh điều đó — cả xác thực và phê chuẩn đều lấy một phần thưởng của khối, tách khỏi phần người tạo khối.
Liệu vòng thêm đó có đáng giá so với độ trễ và chi phí điều phối hay không là đúng kiểu thứ mà một cuộc kiểm toán không thể cho bạn biết. Bài đánh giá của Oak Security nói rằng giao thức được thiết kế tốt. “Được thiết kế tốt” và “phù hợp với tải thực tế” là những tuyên bố khác nhau.
Câu hỏi thật cho các nhà vận hành node ở đây: đã ai đo xem việc phê chuẩn có bị chậm nhiều hơn không — chứ không phải khâu xác thực không?
#dusk $DUSK #block
35
·
--
@termmax Trang tùy chọn Alpha cho biết khoản lỗ tối đa của bạn là phí bảo hiểm. Trang phí bổ sung thêm ba dòng cho điều đó.
Mở hoặc đóng một Lệnh Long hoặc Short sẽ tốn 7% của phí bảo hiểm đã trả.
Chốt lời sẽ bị tính trên giá trị danh nghĩa, không phải phí bảo hiểm — 1,9% vào ngày đầu tiên, giảm tuyến tính về thời điểm đáo hạn. Ví dụ trong tài liệu của họ: một hợp đồng 16 ngày đóng vào ngày 10 với giá trị danh nghĩa 10.000 USDT thì trả 47,5 USDT.
Sau đó là phí tài trợ. Bạn phải trả lãi trên giá trị danh nghĩa cho mỗi giây bạn giữ vị thế. Ví dụ của họ dùng lãi suất niên hóa 100% và tạo ra khoảng 1,37 USDT mỗi ngày trên 100 USDT giá trị danh nghĩa. Khoảng 10% phần lãi đó đi đến nền tảng, phần còn lại dành cho những người gửi tiền của Dual Investment.
Không có gì trong số này bị che giấu, và phí giao dịch được miễn trong chương trình tăng tốc.
Nhưng “chi phí tối đa là phí bảo hiểm” và “lãi được cộng dồn theo từng giây trên giá trị danh nghĩa” là hai câu khác nhau nói về cùng một giao dịch.
Khi bạn định giá một trong các khoản đó, bạn đang định giá phí bảo hiểm hay phí bảo hiểm cộng thêm phần carry?
#termmax @termmax
@TermMax Trang tùy chọn Alpha cho biết khoản lỗ tối đa của bạn là phí bảo hiểm. Trang phí bổ sung thêm ba dòng cho điều đó.
Mở hoặc đóng một Lệnh Long hoặc Short sẽ tốn 7% của phí bảo hiểm đã trả.
Chốt lời sẽ bị tính trên giá trị danh nghĩa, không phải phí bảo hiểm — 1,9% vào ngày đầu tiên, giảm tuyến tính về thời điểm đáo hạn. Ví dụ trong tài liệu của họ: một hợp đồng 16 ngày đóng vào ngày 10 với giá trị danh nghĩa 10.000 USDT thì trả 47,5 USDT.
Sau đó là phí tài trợ. Bạn phải trả lãi trên giá trị danh nghĩa cho mỗi giây bạn giữ vị thế. Ví dụ của họ dùng lãi suất niên hóa 100% và tạo ra khoảng 1,37 USDT mỗi ngày trên 100 USDT giá trị danh nghĩa. Khoảng 10% phần lãi đó đi đến nền tảng, phần còn lại dành cho những người gửi tiền của Dual Investment.
Không có gì trong số này bị che giấu, và phí giao dịch được miễn trong chương trình tăng tốc.
Nhưng “chi phí tối đa là phí bảo hiểm” và “lãi được cộng dồn theo từng giây trên giá trị danh nghĩa” là hai câu khác nhau nói về cùng một giao dịch.
Khi bạn định giá một trong các khoản đó, bạn đang định giá phí bảo hiểm hay phí bảo hiểm cộng thêm phần carry?
#termmax @TermMax
Mở hoặc đóng một Lệnh Long hoặc Short sẽ tốn 7% của phí bảo hiểm đã trả.
Chốt lời sẽ bị tính trên giá trị danh nghĩa, không phải phí bảo hiểm — 1,9% vào ngày đầu tiên, giảm tuyến tính về thời điểm đáo hạn. Ví dụ trong tài liệu của họ: một hợp đồng 16 ngày đóng vào ngày 10 với giá trị danh nghĩa 10.000 USDT thì trả 47,5 USDT.
Sau đó là phí tài trợ. Bạn phải trả lãi trên giá trị danh nghĩa cho mỗi giây bạn giữ vị thế. Ví dụ của họ dùng lãi suất niên hóa 100% và tạo ra khoảng 1,37 USDT mỗi ngày trên 100 USDT giá trị danh nghĩa. Khoảng 10% phần lãi đó đi đến nền tảng, phần còn lại dành cho những người gửi tiền của Dual Investment.
Không có gì trong số này bị che giấu, và phí giao dịch được miễn trong chương trình tăng tốc.
Nhưng “chi phí tối đa là phí bảo hiểm” và “lãi được cộng dồn theo từng giây trên giá trị danh nghĩa” là hai câu khác nhau nói về cùng một giao dịch.
Khi bạn định giá một trong các khoản đó, bạn đang định giá phí bảo hiểm hay phí bảo hiểm cộng thêm phần carry?
#termmax @TermMax
1
79
·
--
#dusk $DUSK
Ai cũng tranh luận về sự đồng thuận. Hầu như không ai nhìn sâu hơn một lớp.
@Dusk_Foundation không dùng tin đồn ngẫu nhiên để chuyển khối giữa các nút. Nó dùng Kadcast — một lớp phủ có cấu trúc, trong đó vị trí của từng nút quyết định ai là người được chuyển tiếp tới. Tài liệu đưa lý do trong một dòng: ít băng thông hơn, và độ trễ dễ dự đoán hơn.
“Dễ dự đoán” mới là từ quan trọng ở đây.
Gossip ngẫu nhiên thì bền vững nhưng ồn ào. Một thông điệp có thể đến bạn trong 200ms hoặc 900ms tùy vào may mắn. Với hầu hết các chuỗi, vậy là đủ. Nhưng với một chuỗi bán cho các tổ chức “tính cuối cùng tất định” khoảng 10 giây, thì sự dao động trong lan truyền không phải là chi tiết trang trí — đó là một phần của lời hứa về kết quả cuối cùng. Bạn không thể đảm bảo chính xác thời điểm cuối cùng trên một lớp vận chuyển vốn “phẩy tay” trước độ dao động đó.
Nửa sau là phần kiểm toán. Blaize đã rà soát phần triển khai Rust và chấm nó 9,8/10, nhưng phần đáng chú ý nằm ở các phát hiện: sự khác lệch so với đặc tả Kadcast ban đầu, các trường hợp biên bị bỏ sót trong xử lý nút rỗi, và cách xử lý mơ hồ đối với các trường được dành riêng trong tiêu đề thông điệp. Tất cả đã được khắc phục hoặc xác minh đúng, trừ hai mục mang tính thông tin.
Các trường dành riêng và các nút rỗi. Không hào nhoáng. Đúng là kiểu thứ ba năm sau sẽ biến thành một sự cố vận hành kỳ lạ.
Câu hỏi mở mà tôi cứ mãi suy nghĩ là: lớp phủ có cấu trúc nghĩa là cấu trúc liên kết có thể suy ra được chứ không phải ngẫu nhiên. Đó là thứ mang lại tính dự đoán. Liệu điều đó cũng khiến các mẫu lưu lượng dễ bị quan sát hơn đối với một chuỗi mà toàn bộ giá trị của nó là bảo mật? Thật lòng, tôi không biết, và tôi chưa tìm thấy một phân tích công khai trả lời câu hỏi này.
Với một chuỗi bảo mật — bạn có sẵn sàng đánh đổi một chút độ dự đoán của lan truyền để đổi lấy một mạng rối hơn, khó lập bản đồ hơn không?
#dusk $DUSK
Ai cũng tranh luận về sự đồng thuận. Hầu như không ai nhìn sâu hơn một lớp.
@Dusk không dùng tin đồn ngẫu nhiên để chuyển khối giữa các nút. Nó dùng Kadcast — một lớp phủ có cấu trúc, trong đó vị trí của từng nút quyết định ai là người được chuyển tiếp tới. Tài liệu đưa lý do trong một dòng: ít băng thông hơn, và độ trễ dễ dự đoán hơn.
“Dễ dự đoán” mới là từ quan trọng ở đây.
Gossip ngẫu nhiên thì bền vững nhưng ồn ào. Một thông điệp có thể đến bạn trong 200ms hoặc 900ms tùy vào may mắn. Với hầu hết các chuỗi, vậy là đủ. Nhưng với một chuỗi bán cho các tổ chức “tính cuối cùng tất định” khoảng 10 giây, thì sự dao động trong lan truyền không phải là chi tiết trang trí — đó là một phần của lời hứa về kết quả cuối cùng. Bạn không thể đảm bảo chính xác thời điểm cuối cùng trên một lớp vận chuyển vốn “phẩy tay” trước độ dao động đó.
Nửa sau là phần kiểm toán. Blaize đã rà soát phần triển khai Rust và chấm nó 9,8/10, nhưng phần đáng chú ý nằm ở các phát hiện: sự khác lệch so với đặc tả Kadcast ban đầu, các trường hợp biên bị bỏ sót trong xử lý nút rỗi, và cách xử lý mơ hồ đối với các trường được dành riêng trong tiêu đề thông điệp. Tất cả đã được khắc phục hoặc xác minh đúng, trừ hai mục mang tính thông tin.
Các trường dành riêng và các nút rỗi. Không hào nhoáng. Đúng là kiểu thứ ba năm sau sẽ biến thành một sự cố vận hành kỳ lạ.
Câu hỏi mở mà tôi cứ mãi suy nghĩ là: lớp phủ có cấu trúc nghĩa là cấu trúc liên kết có thể suy ra được chứ không phải ngẫu nhiên. Đó là thứ mang lại tính dự đoán. Liệu điều đó cũng khiến các mẫu lưu lượng dễ bị quan sát hơn đối với một chuỗi mà toàn bộ giá trị của nó là bảo mật? Thật lòng, tôi không biết, và tôi chưa tìm thấy một phân tích công khai trả lời câu hỏi này.
Với một chuỗi bảo mật — bạn có sẵn sàng đánh đổi một chút độ dự đoán của lan truyền để đổi lấy một mạng rối hơn, khó lập bản đồ hơn không?
Ai cũng tranh luận về sự đồng thuận. Hầu như không ai nhìn sâu hơn một lớp.
@Dusk không dùng tin đồn ngẫu nhiên để chuyển khối giữa các nút. Nó dùng Kadcast — một lớp phủ có cấu trúc, trong đó vị trí của từng nút quyết định ai là người được chuyển tiếp tới. Tài liệu đưa lý do trong một dòng: ít băng thông hơn, và độ trễ dễ dự đoán hơn.
“Dễ dự đoán” mới là từ quan trọng ở đây.
Gossip ngẫu nhiên thì bền vững nhưng ồn ào. Một thông điệp có thể đến bạn trong 200ms hoặc 900ms tùy vào may mắn. Với hầu hết các chuỗi, vậy là đủ. Nhưng với một chuỗi bán cho các tổ chức “tính cuối cùng tất định” khoảng 10 giây, thì sự dao động trong lan truyền không phải là chi tiết trang trí — đó là một phần của lời hứa về kết quả cuối cùng. Bạn không thể đảm bảo chính xác thời điểm cuối cùng trên một lớp vận chuyển vốn “phẩy tay” trước độ dao động đó.
Nửa sau là phần kiểm toán. Blaize đã rà soát phần triển khai Rust và chấm nó 9,8/10, nhưng phần đáng chú ý nằm ở các phát hiện: sự khác lệch so với đặc tả Kadcast ban đầu, các trường hợp biên bị bỏ sót trong xử lý nút rỗi, và cách xử lý mơ hồ đối với các trường được dành riêng trong tiêu đề thông điệp. Tất cả đã được khắc phục hoặc xác minh đúng, trừ hai mục mang tính thông tin.
Các trường dành riêng và các nút rỗi. Không hào nhoáng. Đúng là kiểu thứ ba năm sau sẽ biến thành một sự cố vận hành kỳ lạ.
Câu hỏi mở mà tôi cứ mãi suy nghĩ là: lớp phủ có cấu trúc nghĩa là cấu trúc liên kết có thể suy ra được chứ không phải ngẫu nhiên. Đó là thứ mang lại tính dự đoán. Liệu điều đó cũng khiến các mẫu lưu lượng dễ bị quan sát hơn đối với một chuỗi mà toàn bộ giá trị của nó là bảo mật? Thật lòng, tôi không biết, và tôi chưa tìm thấy một phân tích công khai trả lời câu hỏi này.
Với một chuỗi bảo mật — bạn có sẵn sàng đánh đổi một chút độ dự đoán của lan truyền để đổi lấy một mạng rối hơn, khó lập bản đồ hơn không?
1
16
·
--
Hai điều tôi cho rằng đã được cố định
Tôi vào tài liệu kiểm soát truy cập để tìm thứ khác và rồi đi ra với một danh sách ngắn hơn những thứ mà tôi gọi là “hằng số”.
Trước hết là oracle. Có hai hàm: một hàm gửi một nguồn giá mới cho một tài sản và một hàm chấp nhận nó. Cả hai đều nằm dưới vai trò quản trị mặc định. Như vậy, việc nguồn cấp dữ liệu quyết định liệu vị thế của bạn có đang lành mạnh hay không là một tham số.
Tiếp theo là phí. Một vai trò configurator có thể cập nhật tỷ lệ phí cho một lệnh cụ thể, và cập nhật cấu hình thị trường bao gồm địa chỉ treasury và các thiết lập phí.
Cả hai điều này đều không có gì bất thường. Mọi giao thức cho vay đều có các công tắc như thế này, và bạn muốn chúng có hiệu lực ngay vào ngày mà một nguồn cấp dữ liệu bắt đầu in ra dữ liệu rác. Morpho, Aave, tất cả đều vậy.
Thứ tôi không thể tìm thấy trên trang đó là thời gian chờ được nêu rõ giữa việc gửi một trong hai thứ này và việc chấp nhận nó. Tầng vault thì mô tả timelock của nó rất rõ ràng. Còn tầng này, tôi không chắc — và tôi thà nói rằng mình không chắc còn hơn là đoán.
Nếu bạn buộc phải có một độ trễ bắt buộc trên đúng một trong hai, bạn sẽ chọn nguồn cấp giá hay tỷ lệ phí?
#termmax @termmax $AAVE
Hai điều tôi cho rằng đã được cố định
Tôi vào tài liệu kiểm soát truy cập để tìm thứ khác và rồi đi ra với một danh sách ngắn hơn những thứ mà tôi gọi là “hằng số”.
Trước hết là oracle. Có hai hàm: một hàm gửi một nguồn giá mới cho một tài sản và một hàm chấp nhận nó. Cả hai đều nằm dưới vai trò quản trị mặc định. Như vậy, việc nguồn cấp dữ liệu quyết định liệu vị thế của bạn có đang lành mạnh hay không là một tham số.
Tiếp theo là phí. Một vai trò configurator có thể cập nhật tỷ lệ phí cho một lệnh cụ thể, và cập nhật cấu hình thị trường bao gồm địa chỉ treasury và các thiết lập phí.
Cả hai điều này đều không có gì bất thường. Mọi giao thức cho vay đều có các công tắc như thế này, và bạn muốn chúng có hiệu lực ngay vào ngày mà một nguồn cấp dữ liệu bắt đầu in ra dữ liệu rác. Morpho, Aave, tất cả đều vậy.
Thứ tôi không thể tìm thấy trên trang đó là thời gian chờ được nêu rõ giữa việc gửi một trong hai thứ này và việc chấp nhận nó. Tầng vault thì mô tả timelock của nó rất rõ ràng. Còn tầng này, tôi không chắc — và tôi thà nói rằng mình không chắc còn hơn là đoán.
Nếu bạn buộc phải có một độ trễ bắt buộc trên đúng một trong hai, bạn sẽ chọn nguồn cấp giá hay tỷ lệ phí?
#termmax @TermMax $AAVE
Tôi vào tài liệu kiểm soát truy cập để tìm thứ khác và rồi đi ra với một danh sách ngắn hơn những thứ mà tôi gọi là “hằng số”.
Trước hết là oracle. Có hai hàm: một hàm gửi một nguồn giá mới cho một tài sản và một hàm chấp nhận nó. Cả hai đều nằm dưới vai trò quản trị mặc định. Như vậy, việc nguồn cấp dữ liệu quyết định liệu vị thế của bạn có đang lành mạnh hay không là một tham số.
Tiếp theo là phí. Một vai trò configurator có thể cập nhật tỷ lệ phí cho một lệnh cụ thể, và cập nhật cấu hình thị trường bao gồm địa chỉ treasury và các thiết lập phí.
Cả hai điều này đều không có gì bất thường. Mọi giao thức cho vay đều có các công tắc như thế này, và bạn muốn chúng có hiệu lực ngay vào ngày mà một nguồn cấp dữ liệu bắt đầu in ra dữ liệu rác. Morpho, Aave, tất cả đều vậy.
Thứ tôi không thể tìm thấy trên trang đó là thời gian chờ được nêu rõ giữa việc gửi một trong hai thứ này và việc chấp nhận nó. Tầng vault thì mô tả timelock của nó rất rõ ràng. Còn tầng này, tôi không chắc — và tôi thà nói rằng mình không chắc còn hơn là đoán.
Nếu bạn buộc phải có một độ trễ bắt buộc trên đúng một trong hai, bạn sẽ chọn nguồn cấp giá hay tỷ lệ phí?
#termmax @TermMax $AAVE
84
·
--
Tôi mong đợi một giao dịch. Tôi đếm được ba.
Đó là một lần rút qua cầu DuskEVM, trực tiếp theo hướng dẫn từ chính Dusk:
1. Khởi tạo lệnh rút trên DuskEVM
2. Chứng minh trên Dusk L1
3. Hoàn tất trên Dusk L1
Ba hành động trên chuỗi, và phí ở cả hai phía: giao dịch nguồn, rồi thêm hai giao dịch nữa trên L1.
Chi tiết hướng dẫn mà tôi tôn trọng nhất là phần về thời điểm. Tài liệu nói rằng trạng thái sẵn sàng của việc rút phụ thuộc vào trạng thái mạng đã được công bố, độ “trưởng thành” của bằng chứng và các kiểm tra trong dispute-game, và rằng trường trạng thái của ví là nguồn có thẩm quyền — đừng suy ra độ sẵn sàng từ thời gian đã trôi. Dòng này tồn tại vì cửa sổ rút khỏi rollup không phải là đồng hồ; chúng là các state machine. Mọi tích hợp mà “hardcode” kiểu "chờ N phút rồi hoàn tất" cuối cùng đều sẽ vỡ: một đề xuất đến muộn, một kiểm tra chạy lâu hơn, và bộ hoàn tất gửi vào một trạng thái chưa sẵn sàng.
Chi tiết thứ hai nói nhiều hơn số bước. Hướng dẫn bảo bạn giữ đủ lượng DUSK không được che chắn trên L1 để chi trả cho cả giao dịch chứng minh và giao dịch hoàn tất. Hãy cân nhắc điều đó trên một chuỗi mà “chiêu bài” cốt lõi của nó là chuyển tiền bảo mật: đường rút lui khỏi lớp EVM của chính nó được định danh bằng số dư minh bạch. Lưu ý, và điều đó quan trọng — đây là hướng dẫn cho testnet, DuskEVM vẫn được gắn nhãn Testnet, vì vậy hình dạng trên mainnet có thể thay đổi.
Công bằng mà nói, chẳng có gì trong số này là phát minh của Dusk. Đây là thiết kế rollup optimistic tiêu chuẩn được kế thừa từ OP Stack, và mọi OP chain đều yêu cầu bạn thực hiện đúng ba hành động đó. Vì vậy, câu hỏi không phải là liệu Dusk có làm sai gì. Mà là UX chuẩn của rollup đã làm gì với một chuỗi mà toàn bộ khác biệt của nó là quyền riêng tư.
Các chuỗi ưu tiên quyền riêng tư có cần một thiết kế cầu về bản chất khác? Hay chi phí gas minh bạch ở lớp settlement là một mức giá hợp lý để đổi lấy ngăn xếp developer quen thuộc?
#dusk $DUSK @Dusk_Foundation
Tôi mong đợi một giao dịch. Tôi đếm được ba.
Đó là một lần rút qua cầu DuskEVM, trực tiếp theo hướng dẫn từ chính Dusk:
1. Khởi tạo lệnh rút trên DuskEVM
2. Chứng minh trên Dusk L1
3. Hoàn tất trên Dusk L1
Ba hành động trên chuỗi, và phí ở cả hai phía: giao dịch nguồn, rồi thêm hai giao dịch nữa trên L1.
Chi tiết hướng dẫn mà tôi tôn trọng nhất là phần về thời điểm. Tài liệu nói rằng trạng thái sẵn sàng của việc rút phụ thuộc vào trạng thái mạng đã được công bố, độ “trưởng thành” của bằng chứng và các kiểm tra trong dispute-game, và rằng trường trạng thái của ví là nguồn có thẩm quyền — đừng suy ra độ sẵn sàng từ thời gian đã trôi. Dòng này tồn tại vì cửa sổ rút khỏi rollup không phải là đồng hồ; chúng là các state machine. Mọi tích hợp mà “hardcode” kiểu "chờ N phút rồi hoàn tất" cuối cùng đều sẽ vỡ: một đề xuất đến muộn, một kiểm tra chạy lâu hơn, và bộ hoàn tất gửi vào một trạng thái chưa sẵn sàng.
Chi tiết thứ hai nói nhiều hơn số bước. Hướng dẫn bảo bạn giữ đủ lượng DUSK không được che chắn trên L1 để chi trả cho cả giao dịch chứng minh và giao dịch hoàn tất. Hãy cân nhắc điều đó trên một chuỗi mà “chiêu bài” cốt lõi của nó là chuyển tiền bảo mật: đường rút lui khỏi lớp EVM của chính nó được định danh bằng số dư minh bạch. Lưu ý, và điều đó quan trọng — đây là hướng dẫn cho testnet, DuskEVM vẫn được gắn nhãn Testnet, vì vậy hình dạng trên mainnet có thể thay đổi.
Công bằng mà nói, chẳng có gì trong số này là phát minh của Dusk. Đây là thiết kế rollup optimistic tiêu chuẩn được kế thừa từ OP Stack, và mọi OP chain đều yêu cầu bạn thực hiện đúng ba hành động đó. Vì vậy, câu hỏi không phải là liệu Dusk có làm sai gì. Mà là UX chuẩn của rollup đã làm gì với một chuỗi mà toàn bộ khác biệt của nó là quyền riêng tư.
Các chuỗi ưu tiên quyền riêng tư có cần một thiết kế cầu về bản chất khác? Hay chi phí gas minh bạch ở lớp settlement là một mức giá hợp lý để đổi lấy ngăn xếp developer quen thuộc?
#dusk $DUSK @Dusk
Đó là một lần rút qua cầu DuskEVM, trực tiếp theo hướng dẫn từ chính Dusk:
1. Khởi tạo lệnh rút trên DuskEVM
2. Chứng minh trên Dusk L1
3. Hoàn tất trên Dusk L1
Ba hành động trên chuỗi, và phí ở cả hai phía: giao dịch nguồn, rồi thêm hai giao dịch nữa trên L1.
Chi tiết hướng dẫn mà tôi tôn trọng nhất là phần về thời điểm. Tài liệu nói rằng trạng thái sẵn sàng của việc rút phụ thuộc vào trạng thái mạng đã được công bố, độ “trưởng thành” của bằng chứng và các kiểm tra trong dispute-game, và rằng trường trạng thái của ví là nguồn có thẩm quyền — đừng suy ra độ sẵn sàng từ thời gian đã trôi. Dòng này tồn tại vì cửa sổ rút khỏi rollup không phải là đồng hồ; chúng là các state machine. Mọi tích hợp mà “hardcode” kiểu "chờ N phút rồi hoàn tất" cuối cùng đều sẽ vỡ: một đề xuất đến muộn, một kiểm tra chạy lâu hơn, và bộ hoàn tất gửi vào một trạng thái chưa sẵn sàng.
Chi tiết thứ hai nói nhiều hơn số bước. Hướng dẫn bảo bạn giữ đủ lượng DUSK không được che chắn trên L1 để chi trả cho cả giao dịch chứng minh và giao dịch hoàn tất. Hãy cân nhắc điều đó trên một chuỗi mà “chiêu bài” cốt lõi của nó là chuyển tiền bảo mật: đường rút lui khỏi lớp EVM của chính nó được định danh bằng số dư minh bạch. Lưu ý, và điều đó quan trọng — đây là hướng dẫn cho testnet, DuskEVM vẫn được gắn nhãn Testnet, vì vậy hình dạng trên mainnet có thể thay đổi.
Công bằng mà nói, chẳng có gì trong số này là phát minh của Dusk. Đây là thiết kế rollup optimistic tiêu chuẩn được kế thừa từ OP Stack, và mọi OP chain đều yêu cầu bạn thực hiện đúng ba hành động đó. Vì vậy, câu hỏi không phải là liệu Dusk có làm sai gì. Mà là UX chuẩn của rollup đã làm gì với một chuỗi mà toàn bộ khác biệt của nó là quyền riêng tư.
Các chuỗi ưu tiên quyền riêng tư có cần một thiết kế cầu về bản chất khác? Hay chi phí gas minh bạch ở lớp settlement là một mức giá hợp lý để đổi lấy ngăn xếp developer quen thuộc?
#dusk $DUSK @Dusk
2
2
63
·
--
Đã xác minh
Đã 2 giờ sáng và khoản vay @termmax vừa đáo hạn. Không có khoản thanh toán nào được chuyển tới. Trong hai giờ tiếp theo, bất kỳ ai cũng có thể tất toán khoản đó — rồi khung thời gian sẽ đóng lại.
Điều này khá lạ nếu bạn đã quen với các lần thanh lý kích hoạt bởi LTV. Ở đây, bộ kích hoạt là đồng hồ, không phải giá. Mức phạt 10% đối với nợ bị thanh lý thực ra không hẳn là một khoản phí — một nửa đi cho người đóng vị thế, nửa còn lại vào quỹ dự trữ của giao thức. Đó là một khoản thưởng để đảm bảo một bot luôn sẵn sàng đúng thời điểm đó, chứ không phải bất cứ khi nào giá tình cờ thay đổi.
Phù hợp cho ETH hoặc một stablecoin. Còn với token PT hoặc một LRT mỏng thì câu chuyện khác. Hai giờ là đủ để định tuyến qua một pool thanh khoản sâu. Thời gian này không nhiều để tháo gỡ khối lượng thực sự lớn trong tài sản thế chấp mà ngày thường giao dịch khá èo uột.
Cơ chế giao hàng vật lý của TermMax được cho là sẽ trao cho người cho vay một phần tài sản thế chấp theo tỷ lệ (pro-rata) nếu khung thời gian đóng lại mà không có một lần thanh lý “sạch”. Điều tôi chưa chắc là quá trình “trao tay” tự động đó thực sự diễn ra như thế nào — đó là phần tài liệu tôi cứ đọc đi đọc lại.
Dù sao, rủi ro không biến mất khi vừa qua mốc hai giờ. Rủi ro sẽ chuyển từ bên thanh lý sang bên cho vay.
Vậy khi khung thời gian đó mở ra, bạn sẽ không muốn nắm giữ loại tài sản thế chấp nào, và vì sao?
#termmax @termmax
Đã 2 giờ sáng và khoản vay @TermMax vừa đáo hạn. Không có khoản thanh toán nào được chuyển tới. Trong hai giờ tiếp theo, bất kỳ ai cũng có thể tất toán khoản đó — rồi khung thời gian sẽ đóng lại.
Điều này khá lạ nếu bạn đã quen với các lần thanh lý kích hoạt bởi LTV. Ở đây, bộ kích hoạt là đồng hồ, không phải giá. Mức phạt 10% đối với nợ bị thanh lý thực ra không hẳn là một khoản phí — một nửa đi cho người đóng vị thế, nửa còn lại vào quỹ dự trữ của giao thức. Đó là một khoản thưởng để đảm bảo một bot luôn sẵn sàng đúng thời điểm đó, chứ không phải bất cứ khi nào giá tình cờ thay đổi.
Phù hợp cho ETH hoặc một stablecoin. Còn với token PT hoặc một LRT mỏng thì câu chuyện khác. Hai giờ là đủ để định tuyến qua một pool thanh khoản sâu. Thời gian này không nhiều để tháo gỡ khối lượng thực sự lớn trong tài sản thế chấp mà ngày thường giao dịch khá èo uột.
Cơ chế giao hàng vật lý của TermMax được cho là sẽ trao cho người cho vay một phần tài sản thế chấp theo tỷ lệ (pro-rata) nếu khung thời gian đóng lại mà không có một lần thanh lý “sạch”. Điều tôi chưa chắc là quá trình “trao tay” tự động đó thực sự diễn ra như thế nào — đó là phần tài liệu tôi cứ đọc đi đọc lại.
Dù sao, rủi ro không biến mất khi vừa qua mốc hai giờ. Rủi ro sẽ chuyển từ bên thanh lý sang bên cho vay.
Vậy khi khung thời gian đó mở ra, bạn sẽ không muốn nắm giữ loại tài sản thế chấp nào, và vì sao?
#termmax @TermMax
Điều này khá lạ nếu bạn đã quen với các lần thanh lý kích hoạt bởi LTV. Ở đây, bộ kích hoạt là đồng hồ, không phải giá. Mức phạt 10% đối với nợ bị thanh lý thực ra không hẳn là một khoản phí — một nửa đi cho người đóng vị thế, nửa còn lại vào quỹ dự trữ của giao thức. Đó là một khoản thưởng để đảm bảo một bot luôn sẵn sàng đúng thời điểm đó, chứ không phải bất cứ khi nào giá tình cờ thay đổi.
Phù hợp cho ETH hoặc một stablecoin. Còn với token PT hoặc một LRT mỏng thì câu chuyện khác. Hai giờ là đủ để định tuyến qua một pool thanh khoản sâu. Thời gian này không nhiều để tháo gỡ khối lượng thực sự lớn trong tài sản thế chấp mà ngày thường giao dịch khá èo uột.
Cơ chế giao hàng vật lý của TermMax được cho là sẽ trao cho người cho vay một phần tài sản thế chấp theo tỷ lệ (pro-rata) nếu khung thời gian đóng lại mà không có một lần thanh lý “sạch”. Điều tôi chưa chắc là quá trình “trao tay” tự động đó thực sự diễn ra như thế nào — đó là phần tài liệu tôi cứ đọc đi đọc lại.
Dù sao, rủi ro không biến mất khi vừa qua mốc hai giờ. Rủi ro sẽ chuyển từ bên thanh lý sang bên cho vay.
Vậy khi khung thời gian đó mở ra, bạn sẽ không muốn nắm giữ loại tài sản thế chấp nào, và vì sao?
#termmax @TermMax
4
4
80
·
--
Ai cũng bán việc vay lãi suất cố định như sự chắc chắn. Sau vài giờ đọc tài liệu, tôi nghĩ cách diễn đạt đó thực ra đã đánh giá thấp thứ mà @termmax đã xây dựng — và nó che giấu một câu hỏi mà không ai trong chiến dịch này đang hỏi.
Đây là đoạn tôi bị mắc ở chỗ này. Trên #termmax , nợ của bạn không chỉ là một con số nằm trong một hợp đồng. Nó được định danh bằng FT, token lãi suất cố định, và việc thanh toán có thể được thực hiện bằng cách mua FT trên thị trường mở thay vì trả đúng mệnh giá.
Hãy ngồi với ý đó một giây.
Bạn khóa tài sản thế chấp vào một Gearing Token, đúc FT dựa trên nó, bán phần “lãi” (interest leg), rồi rời đi với thanh khoản theo một mức lãi suất đã thỏa thuận ngay từ ngày đầu. Toàn bộ lãi suất của cả kỳ hạn được “nhét” sẵn vào khoản nợ ngay từ block đầu tiên. Không phát sinh lũy kế, không reset, không trôi dạt trong lúc bạn ngủ.
Rồi lãi suất thị trường tăng. Mọi FT trong thị trường đó — kể cả FT đại diện cho chính khoản nợ của bạn — bắt đầu được giao dịch với mức chiết khấu sâu hơn. Và vì khoản nợ được tính bằng FT, bạn có thể mua lại nó với giá thấp hơn mệnh, rồi tất toán với ít hơn mức lãi suất bạn ban đầu đã khóa.
Vì vậy, lãi suất cố định không phải là “chi phí cố định”. Nó là một trần (ceiling). Được khóa ở phía trên, còn phía dưới thì mở.
Giờ chuyển sang bên cho vay. Họ nắm một khoản yêu cầu chiết khấu bằng lãi suất 0-coupon, đến đáo hạn sẽ được hoàn trả 1:1. Khi lãi suất tăng, FT của họ sẽ có giá trị thấp hơn nếu họ muốn thoát vị thế sớm, và giữ đến đáo hạn thì lợi nhuận đúng bằng mệnh giá. Trần và sàn là cùng một con số. Người vay có tính lồi (convexity). Bên cho vay thì không.
Sự bất đối xứng đó không biến mất chỉ vì không có dashboard nào hiển thị. Nó được “trả tiền” ở đâu đó. Hoặc nó đã nằm sẵn trong mức chiết khấu mà bên cho vay đòi hỏi khi phát hành — nghĩa là lãi suất cố định mà người vay thấy thực chất đang âm thầm mang theo một khoản “phí quyền chọn” (option premium) — hoặc nó chưa được định giá chút nào, và người vay đang giữ một “quyền chọn lãi suất miễn phí” mà các curators và makers đang tài trợ mà không dán nhãn.
Phiên bản thứ hai mới là phiên bản tôi muốn bị loại trước khi mở rộng quy mô vào một vault. Các đường cong lãi suất trong DeFi thường được thiết lập từ mức sử dụng (utilisation) và kỳ vọng lợi suất, chứ không phải từ tính chất “có quyền chọn” (optionality).
Vậy câu hỏi thực sự dành cho bất kỳ ai đặt lệnh cho vay theo dải (lending range orders) ở đây là: bạn có mở rộng đường cong của mình cho người vay khi họ mua lại khoản nợ của mình với giá rẻ không, hay điều đó vẫn vô hình trong cách bạn định giá?
Ai cũng bán việc vay lãi suất cố định như sự chắc chắn. Sau vài giờ đọc tài liệu, tôi nghĩ cách diễn đạt đó thực ra đã đánh giá thấp thứ mà @TermMax đã xây dựng — và nó che giấu một câu hỏi mà không ai trong chiến dịch này đang hỏi.
Đây là đoạn tôi bị mắc ở chỗ này. Trên #termmax , nợ của bạn không chỉ là một con số nằm trong một hợp đồng. Nó được định danh bằng FT, token lãi suất cố định, và việc thanh toán có thể được thực hiện bằng cách mua FT trên thị trường mở thay vì trả đúng mệnh giá.
Hãy ngồi với ý đó một giây.
Bạn khóa tài sản thế chấp vào một Gearing Token, đúc FT dựa trên nó, bán phần “lãi” (interest leg), rồi rời đi với thanh khoản theo một mức lãi suất đã thỏa thuận ngay từ ngày đầu. Toàn bộ lãi suất của cả kỳ hạn được “nhét” sẵn vào khoản nợ ngay từ block đầu tiên. Không phát sinh lũy kế, không reset, không trôi dạt trong lúc bạn ngủ.
Rồi lãi suất thị trường tăng. Mọi FT trong thị trường đó — kể cả FT đại diện cho chính khoản nợ của bạn — bắt đầu được giao dịch với mức chiết khấu sâu hơn. Và vì khoản nợ được tính bằng FT, bạn có thể mua lại nó với giá thấp hơn mệnh, rồi tất toán với ít hơn mức lãi suất bạn ban đầu đã khóa.
Vì vậy, lãi suất cố định không phải là “chi phí cố định”. Nó là một trần (ceiling). Được khóa ở phía trên, còn phía dưới thì mở.
Giờ chuyển sang bên cho vay. Họ nắm một khoản yêu cầu chiết khấu bằng lãi suất 0-coupon, đến đáo hạn sẽ được hoàn trả 1:1. Khi lãi suất tăng, FT của họ sẽ có giá trị thấp hơn nếu họ muốn thoát vị thế sớm, và giữ đến đáo hạn thì lợi nhuận đúng bằng mệnh giá. Trần và sàn là cùng một con số. Người vay có tính lồi (convexity). Bên cho vay thì không.
Sự bất đối xứng đó không biến mất chỉ vì không có dashboard nào hiển thị. Nó được “trả tiền” ở đâu đó. Hoặc nó đã nằm sẵn trong mức chiết khấu mà bên cho vay đòi hỏi khi phát hành — nghĩa là lãi suất cố định mà người vay thấy thực chất đang âm thầm mang theo một khoản “phí quyền chọn” (option premium) — hoặc nó chưa được định giá chút nào, và người vay đang giữ một “quyền chọn lãi suất miễn phí” mà các curators và makers đang tài trợ mà không dán nhãn.
Phiên bản thứ hai mới là phiên bản tôi muốn bị loại trước khi mở rộng quy mô vào một vault. Các đường cong lãi suất trong DeFi thường được thiết lập từ mức sử dụng (utilisation) và kỳ vọng lợi suất, chứ không phải từ tính chất “có quyền chọn” (optionality).
Vậy câu hỏi thực sự dành cho bất kỳ ai đặt lệnh cho vay theo dải (lending range orders) ở đây là: bạn có mở rộng đường cong của mình cho người vay khi họ mua lại khoản nợ của mình với giá rẻ không, hay điều đó vẫn vô hình trong cách bạn định giá?
Đây là đoạn tôi bị mắc ở chỗ này. Trên #termmax , nợ của bạn không chỉ là một con số nằm trong một hợp đồng. Nó được định danh bằng FT, token lãi suất cố định, và việc thanh toán có thể được thực hiện bằng cách mua FT trên thị trường mở thay vì trả đúng mệnh giá.
Hãy ngồi với ý đó một giây.
Bạn khóa tài sản thế chấp vào một Gearing Token, đúc FT dựa trên nó, bán phần “lãi” (interest leg), rồi rời đi với thanh khoản theo một mức lãi suất đã thỏa thuận ngay từ ngày đầu. Toàn bộ lãi suất của cả kỳ hạn được “nhét” sẵn vào khoản nợ ngay từ block đầu tiên. Không phát sinh lũy kế, không reset, không trôi dạt trong lúc bạn ngủ.
Rồi lãi suất thị trường tăng. Mọi FT trong thị trường đó — kể cả FT đại diện cho chính khoản nợ của bạn — bắt đầu được giao dịch với mức chiết khấu sâu hơn. Và vì khoản nợ được tính bằng FT, bạn có thể mua lại nó với giá thấp hơn mệnh, rồi tất toán với ít hơn mức lãi suất bạn ban đầu đã khóa.
Vì vậy, lãi suất cố định không phải là “chi phí cố định”. Nó là một trần (ceiling). Được khóa ở phía trên, còn phía dưới thì mở.
Giờ chuyển sang bên cho vay. Họ nắm một khoản yêu cầu chiết khấu bằng lãi suất 0-coupon, đến đáo hạn sẽ được hoàn trả 1:1. Khi lãi suất tăng, FT của họ sẽ có giá trị thấp hơn nếu họ muốn thoát vị thế sớm, và giữ đến đáo hạn thì lợi nhuận đúng bằng mệnh giá. Trần và sàn là cùng một con số. Người vay có tính lồi (convexity). Bên cho vay thì không.
Sự bất đối xứng đó không biến mất chỉ vì không có dashboard nào hiển thị. Nó được “trả tiền” ở đâu đó. Hoặc nó đã nằm sẵn trong mức chiết khấu mà bên cho vay đòi hỏi khi phát hành — nghĩa là lãi suất cố định mà người vay thấy thực chất đang âm thầm mang theo một khoản “phí quyền chọn” (option premium) — hoặc nó chưa được định giá chút nào, và người vay đang giữ một “quyền chọn lãi suất miễn phí” mà các curators và makers đang tài trợ mà không dán nhãn.
Phiên bản thứ hai mới là phiên bản tôi muốn bị loại trước khi mở rộng quy mô vào một vault. Các đường cong lãi suất trong DeFi thường được thiết lập từ mức sử dụng (utilisation) và kỳ vọng lợi suất, chứ không phải từ tính chất “có quyền chọn” (optionality).
Vậy câu hỏi thực sự dành cho bất kỳ ai đặt lệnh cho vay theo dải (lending range orders) ở đây là: bạn có mở rộng đường cong của mình cho người vay khi họ mua lại khoản nợ của mình với giá rẻ không, hay điều đó vẫn vô hình trong cách bạn định giá?
2
3
52
·
--
#dusk $DUSK @Dusk_Foundation Thiết lập bảo mật của Dusk thực sự chạy trên hai luồng riêng biệt. Trên DuskDS, mô hình Phoenix biểu diễn giá trị dưới dạng các ghi chú (note) được cam kết vào một cây Merkle — việc chi tiêu một ghi chú không chỉ ra ghi chú nào đang được chi tiêu. Thay vào đó, người gửi công bố một nullifier và một bằng chứng không kiến thức (zero-knowledge) chứng minh rằng việc chi tiêu là hợp lệ, quyền sở hữu là có thật, và không có giá trị nào được tạo ra từ hư vô mà không tiết lộ ghi chú gốc. Song song với đó, Moonlight vận hành như một mô hình minh bạch dựa trên tài khoản (account-based) trên cùng một chuỗi.
Trên DuskEVM, tuy nhiên, quyền riêng tư đến từ một bộ công cụ hoàn toàn khác — một module tên là Hedger, kết hợp mã hóa đồng hình dựa trên ElGamal với các bằng chứng không kiến thức, cùng với cấu trúc kết hợp giữa UTXO và tài khoản (hybrid). Ở đây, người dùng tương tác với hợp đồng thông qua một địa chỉ EVM chuẩn, trong khi một địa chỉ Hedger riêng sẽ xử lý các số dư đã được mã hóa, với yêu cầu tuân thủ được đảm bảo thông qua danh sách cho phép (allowlisting).
Đây không phải là hai phiên bản của cùng một ý tưởng. Phoenix là một hệ thống bằng chứng dựa trên ghi chú; Hedger tính toán trực tiếp trên các số dư đã mã hóa, được xác thực thông qua các bằng chứng không kiến thức. Lý do có thể cho sự tách biệt này là quyền riêng tư dựa trên ghi chú không phù hợp một cách tự nhiên với cấu trúc EVM dựa trên tài khoản, nên cần một hướng tiếp cận khác.
Chạy song song hai ngăn xếp quyền riêng tư mật mã độc lập đồng nghĩa với bề mặt tấn công lớn hơn và chi phí kiểm toán (audit) nặng hơn. Đồng thời cũng chưa rõ cam kết về quyền riêng tư được duy trì như thế nào khi giá trị chuyển động giữa hai lớp.
Việc duy trì hai “cỗ máy” bảo mật (confidentiality engines) riêng biệt có làm chi phí kiểm toán tăng lên theo tỷ lệ, hay việc cả hai cùng dựa vào các bằng chứng không kiến thức có nghĩa là chi phí gia tăng của “engine” thứ hai thực sự thấp hơn mức trông đợi?
#dusk $DUSK @Dusk Thiết lập bảo mật của Dusk thực sự chạy trên hai luồng riêng biệt. Trên DuskDS, mô hình Phoenix biểu diễn giá trị dưới dạng các ghi chú (note) được cam kết vào một cây Merkle — việc chi tiêu một ghi chú không chỉ ra ghi chú nào đang được chi tiêu. Thay vào đó, người gửi công bố một nullifier và một bằng chứng không kiến thức (zero-knowledge) chứng minh rằng việc chi tiêu là hợp lệ, quyền sở hữu là có thật, và không có giá trị nào được tạo ra từ hư vô mà không tiết lộ ghi chú gốc. Song song với đó, Moonlight vận hành như một mô hình minh bạch dựa trên tài khoản (account-based) trên cùng một chuỗi.
Trên DuskEVM, tuy nhiên, quyền riêng tư đến từ một bộ công cụ hoàn toàn khác — một module tên là Hedger, kết hợp mã hóa đồng hình dựa trên ElGamal với các bằng chứng không kiến thức, cùng với cấu trúc kết hợp giữa UTXO và tài khoản (hybrid). Ở đây, người dùng tương tác với hợp đồng thông qua một địa chỉ EVM chuẩn, trong khi một địa chỉ Hedger riêng sẽ xử lý các số dư đã được mã hóa, với yêu cầu tuân thủ được đảm bảo thông qua danh sách cho phép (allowlisting).
Đây không phải là hai phiên bản của cùng một ý tưởng. Phoenix là một hệ thống bằng chứng dựa trên ghi chú; Hedger tính toán trực tiếp trên các số dư đã mã hóa, được xác thực thông qua các bằng chứng không kiến thức. Lý do có thể cho sự tách biệt này là quyền riêng tư dựa trên ghi chú không phù hợp một cách tự nhiên với cấu trúc EVM dựa trên tài khoản, nên cần một hướng tiếp cận khác.
Chạy song song hai ngăn xếp quyền riêng tư mật mã độc lập đồng nghĩa với bề mặt tấn công lớn hơn và chi phí kiểm toán (audit) nặng hơn. Đồng thời cũng chưa rõ cam kết về quyền riêng tư được duy trì như thế nào khi giá trị chuyển động giữa hai lớp.
Việc duy trì hai “cỗ máy” bảo mật (confidentiality engines) riêng biệt có làm chi phí kiểm toán tăng lên theo tỷ lệ, hay việc cả hai cùng dựa vào các bằng chứng không kiến thức có nghĩa là chi phí gia tăng của “engine” thứ hai thực sự thấp hơn mức trông đợi?
Trên DuskEVM, tuy nhiên, quyền riêng tư đến từ một bộ công cụ hoàn toàn khác — một module tên là Hedger, kết hợp mã hóa đồng hình dựa trên ElGamal với các bằng chứng không kiến thức, cùng với cấu trúc kết hợp giữa UTXO và tài khoản (hybrid). Ở đây, người dùng tương tác với hợp đồng thông qua một địa chỉ EVM chuẩn, trong khi một địa chỉ Hedger riêng sẽ xử lý các số dư đã được mã hóa, với yêu cầu tuân thủ được đảm bảo thông qua danh sách cho phép (allowlisting).
Đây không phải là hai phiên bản của cùng một ý tưởng. Phoenix là một hệ thống bằng chứng dựa trên ghi chú; Hedger tính toán trực tiếp trên các số dư đã mã hóa, được xác thực thông qua các bằng chứng không kiến thức. Lý do có thể cho sự tách biệt này là quyền riêng tư dựa trên ghi chú không phù hợp một cách tự nhiên với cấu trúc EVM dựa trên tài khoản, nên cần một hướng tiếp cận khác.
Chạy song song hai ngăn xếp quyền riêng tư mật mã độc lập đồng nghĩa với bề mặt tấn công lớn hơn và chi phí kiểm toán (audit) nặng hơn. Đồng thời cũng chưa rõ cam kết về quyền riêng tư được duy trì như thế nào khi giá trị chuyển động giữa hai lớp.
Việc duy trì hai “cỗ máy” bảo mật (confidentiality engines) riêng biệt có làm chi phí kiểm toán tăng lên theo tỷ lệ, hay việc cả hai cùng dựa vào các bằng chứng không kiến thức có nghĩa là chi phí gia tăng của “engine” thứ hai thực sự thấp hơn mức trông đợi?
1
93
·
--
#dusk $DUSK @Dusk_Foundation
Tôi đã đi tìm hiểu xem phần thưởng staking của DUSK thực sự được tài trợ như thế nào, kỳ vọng sẽ giống với hầu hết các chuỗi PoS mà tôi từng thấy — hoặc là một tỷ lệ lạm phát cố định cao ở giai đoạn đầu, hoặc phần thưởng được chi trả gần như hoàn toàn bằng phí giao dịch ngay từ ngày đầu. Nhưng những gì Dusk làm thì không phải như vậy.
Phần thưởng được tài trợ bằng một cơ chế phát hành (emission) 500 triệu DUSK, được giải phóng trong 36 năm, theo một đường cong suy giảm theo cấp số nhân (geometric decay), cứ khoảng mỗi bốn năm lại giảm một nửa. Đó là kiểu giảm dần dài và chậm, chứ không phải “tập trung thưởng” ngay từ đầu hoặc một cú rơi/phân bổ mạnh sớm kiểu “cliff” gắt.
Điều khiến tôi phải dừng lại là sự không khớp giữa mốc thời gian phát hành đó và tốc độ mà crypto thường vận hành. Hầu hết lịch trình thưởng token được thiết kế để vượt qua vài năm biến động đầu tiên — khởi động nhanh, giảm dần nhanh, rồi để phí giao dịch nhanh chóng đảm nhiệm vai trò chính. Một đường cong 36 năm lại gần với khung thời gian của một quỹ hưu trí hơn là chương trình khuyến khích của một validator điển hình, và điều này giống như một tín hiệu hơn là một sự thiếu sót: giao thức đang đặt cược vào kiểu chấp nhận nào. Đó là cơ sở hạ tầng tài chính được quản lý (regulated financial infrastructure), vốn thường chuyển động theo năm tháng và hàng thập kỷ, hơn là theo các chu kỳ thị trường.
Sự giằng co nằm ở khoảng cách giữa “bây giờ” và “sau này”. Việc tổ chức chấp nhận chứng khoán được mã hóa (tokenized securities) và thanh toán on-chain tuân thủ (compliant on-chain settlement) không diễn ra trong một sớm một chiều, và doanh thu phí giao dịch từ hoạt động như vậy có lẽ vẫn còn ở giai đoạn sớm so với thời điểm mà giao thức cuối cùng muốn dựa vào nó. Trong lúc đó, các validator đang được trả phần lớn từ emissions (phát hành) hơn là từ việc sử dụng, đây là trạng thái bình thường ở giai đoạn đầu của một chuỗi PoS, nhưng lại là một điều khá “lạ” để phải đối chiếu với thiết kế có chân trời 36 năm.
Tôi không nghĩ rằng một đường cong phát hành dài là điểm yếu cố hữu — những mốc dài là trung thực với thực tế rằng tài chính được quản lý thường tiến triển chậm. Nhưng nó cũng đặt ra câu hỏi: liệu các kinh tế staking được thiết kế cho một quỹ đạo chấp nhận mang tính thể chế kéo dài hàng thập kỷ có thể giữ chân các validator trong những năm trước khi quỹ đạo chấp nhận đó thực sự xuất hiện dưới dạng doanh thu phí hay không.
#dusk $DUSK @Dusk
Tôi đã đi tìm hiểu xem phần thưởng staking của DUSK thực sự được tài trợ như thế nào, kỳ vọng sẽ giống với hầu hết các chuỗi PoS mà tôi từng thấy — hoặc là một tỷ lệ lạm phát cố định cao ở giai đoạn đầu, hoặc phần thưởng được chi trả gần như hoàn toàn bằng phí giao dịch ngay từ ngày đầu. Nhưng những gì Dusk làm thì không phải như vậy.
Phần thưởng được tài trợ bằng một cơ chế phát hành (emission) 500 triệu DUSK, được giải phóng trong 36 năm, theo một đường cong suy giảm theo cấp số nhân (geometric decay), cứ khoảng mỗi bốn năm lại giảm một nửa. Đó là kiểu giảm dần dài và chậm, chứ không phải “tập trung thưởng” ngay từ đầu hoặc một cú rơi/phân bổ mạnh sớm kiểu “cliff” gắt.
Điều khiến tôi phải dừng lại là sự không khớp giữa mốc thời gian phát hành đó và tốc độ mà crypto thường vận hành. Hầu hết lịch trình thưởng token được thiết kế để vượt qua vài năm biến động đầu tiên — khởi động nhanh, giảm dần nhanh, rồi để phí giao dịch nhanh chóng đảm nhiệm vai trò chính. Một đường cong 36 năm lại gần với khung thời gian của một quỹ hưu trí hơn là chương trình khuyến khích của một validator điển hình, và điều này giống như một tín hiệu hơn là một sự thiếu sót: giao thức đang đặt cược vào kiểu chấp nhận nào. Đó là cơ sở hạ tầng tài chính được quản lý (regulated financial infrastructure), vốn thường chuyển động theo năm tháng và hàng thập kỷ, hơn là theo các chu kỳ thị trường.
Sự giằng co nằm ở khoảng cách giữa “bây giờ” và “sau này”. Việc tổ chức chấp nhận chứng khoán được mã hóa (tokenized securities) và thanh toán on-chain tuân thủ (compliant on-chain settlement) không diễn ra trong một sớm một chiều, và doanh thu phí giao dịch từ hoạt động như vậy có lẽ vẫn còn ở giai đoạn sớm so với thời điểm mà giao thức cuối cùng muốn dựa vào nó. Trong lúc đó, các validator đang được trả phần lớn từ emissions (phát hành) hơn là từ việc sử dụng, đây là trạng thái bình thường ở giai đoạn đầu của một chuỗi PoS, nhưng lại là một điều khá “lạ” để phải đối chiếu với thiết kế có chân trời 36 năm.
Tôi không nghĩ rằng một đường cong phát hành dài là điểm yếu cố hữu — những mốc dài là trung thực với thực tế rằng tài chính được quản lý thường tiến triển chậm. Nhưng nó cũng đặt ra câu hỏi: liệu các kinh tế staking được thiết kế cho một quỹ đạo chấp nhận mang tính thể chế kéo dài hàng thập kỷ có thể giữ chân các validator trong những năm trước khi quỹ đạo chấp nhận đó thực sự xuất hiện dưới dạng doanh thu phí hay không.
Tôi đã đi tìm hiểu xem phần thưởng staking của DUSK thực sự được tài trợ như thế nào, kỳ vọng sẽ giống với hầu hết các chuỗi PoS mà tôi từng thấy — hoặc là một tỷ lệ lạm phát cố định cao ở giai đoạn đầu, hoặc phần thưởng được chi trả gần như hoàn toàn bằng phí giao dịch ngay từ ngày đầu. Nhưng những gì Dusk làm thì không phải như vậy.
Phần thưởng được tài trợ bằng một cơ chế phát hành (emission) 500 triệu DUSK, được giải phóng trong 36 năm, theo một đường cong suy giảm theo cấp số nhân (geometric decay), cứ khoảng mỗi bốn năm lại giảm một nửa. Đó là kiểu giảm dần dài và chậm, chứ không phải “tập trung thưởng” ngay từ đầu hoặc một cú rơi/phân bổ mạnh sớm kiểu “cliff” gắt.
Điều khiến tôi phải dừng lại là sự không khớp giữa mốc thời gian phát hành đó và tốc độ mà crypto thường vận hành. Hầu hết lịch trình thưởng token được thiết kế để vượt qua vài năm biến động đầu tiên — khởi động nhanh, giảm dần nhanh, rồi để phí giao dịch nhanh chóng đảm nhiệm vai trò chính. Một đường cong 36 năm lại gần với khung thời gian của một quỹ hưu trí hơn là chương trình khuyến khích của một validator điển hình, và điều này giống như một tín hiệu hơn là một sự thiếu sót: giao thức đang đặt cược vào kiểu chấp nhận nào. Đó là cơ sở hạ tầng tài chính được quản lý (regulated financial infrastructure), vốn thường chuyển động theo năm tháng và hàng thập kỷ, hơn là theo các chu kỳ thị trường.
Sự giằng co nằm ở khoảng cách giữa “bây giờ” và “sau này”. Việc tổ chức chấp nhận chứng khoán được mã hóa (tokenized securities) và thanh toán on-chain tuân thủ (compliant on-chain settlement) không diễn ra trong một sớm một chiều, và doanh thu phí giao dịch từ hoạt động như vậy có lẽ vẫn còn ở giai đoạn sớm so với thời điểm mà giao thức cuối cùng muốn dựa vào nó. Trong lúc đó, các validator đang được trả phần lớn từ emissions (phát hành) hơn là từ việc sử dụng, đây là trạng thái bình thường ở giai đoạn đầu của một chuỗi PoS, nhưng lại là một điều khá “lạ” để phải đối chiếu với thiết kế có chân trời 36 năm.
Tôi không nghĩ rằng một đường cong phát hành dài là điểm yếu cố hữu — những mốc dài là trung thực với thực tế rằng tài chính được quản lý thường tiến triển chậm. Nhưng nó cũng đặt ra câu hỏi: liệu các kinh tế staking được thiết kế cho một quỹ đạo chấp nhận mang tính thể chế kéo dài hàng thập kỷ có thể giữ chân các validator trong những năm trước khi quỹ đạo chấp nhận đó thực sự xuất hiện dưới dạng doanh thu phí hay không.
1
1
20
·
--
Có một kiểu tĩnh lặng nhất định xuất hiện trong các dự án hạ tầng, và đáng để học cách đọc nó cho đúng. Nó không giống như thất bại. Nhưng cũng chẳng hẳn là thành công một cách hiển nhiên.
Bình minh hoàng hôn (Dusk) đã có mặt trên mainnet được một thời gian rồi. Về mặt kỹ thuật, các hợp đồng thông minh bảo mật (confidential) liền mạch, tiêu chuẩn XSC, công bố có chọn lọc (selective disclosure) — tất cả đều được xây dựng xoay quanh một vấn đề cụ thể, có thật mà tài chính được quản lý thực sự đang gặp phải. Thế nhưng, khi nhìn vào hoạt động mạng thực tế, phần lớn điều đang diễn ra lại là hoạt động staking. Các hợp đồng bảo mật, việc phát hành chứng khoán thật — vẫn khá hiếm, theo hầu hết những tín hiệu sẵn có.
Khoảng cách giữa những gì hạ tầng có thể làm và những gì thực sự đang vận hành trên đó xứng đáng được ngồi với nó, thay vì vội vàng giải thích cho qua.
Vài điều thì vẫn có lợi, và đáng gọi tên thẳng thắn. Việc vesting sớm đã hoàn tất, nên không có sự kiện mở khóa (unlock) đang treo lơ lửng có thể làm méo kỳ vọng về nguồn cung. Các đối tác là các sàn/đơn vị được cấp phép giúp cho vị thế tuân thủ có được một nền móng vững hơn thay vì chỉ là kỳ vọng. Và theo đa số đánh giá kỹ thuật, chính lớp hạ tầng không phải điểm yếu — điều này không giống một câu chuyện
Câu hỏi khó hơn nằm ở sự đồng bộ về động lực (incentive alignment). Các tổ chức có vị thế tốt nhất để thực sự sử dụng loại hạ tầng quyền riêng tư và tuân thủ này có thể sẽ không bao giờ cần nắm giữ số lượng lớn token; phạm vi tiếp xúc của họ có thể chỉ ở mức tối thiểu, đủ cho mục đích vận hành. Trong khi đó, những người nắm giữ token lại đang tiếp nhận lượng phát hành phát sinh liên tục, chờ đợi khối lượng (volume) mà cho đến nay vẫn chưa xuất hiện với quy mô đáng kể. Hai mối quan hệ rất khác nhau với cùng một tài sản, nhưng không có cơ chế rõ ràng nào kéo hai phía vào sự đồng thuận
Điều này không phải là lời chỉ trích thiết kế. Nó chỉ là một mô tả thẳng thắn về tình trạng hiện tại: về mặt kỹ thuật thì có thể làm được, nhưng về mặt tài chính vẫn đang chờ bằng chứng.
Câu hỏi mà không ai thực sự có thể trả lời được — kể cả chính dự án — là: việc "hạ tầng đã sẵn sàng" có thể tiếp tục là một câu trả lời thỏa đáng trong bao lâu trước khi thị trường bắt đầu đòi hỏi rằng hạ tầng phải đang được sử dụng.
@Dusk_Foundation #dusk $DUSK
Có một kiểu tĩnh lặng nhất định xuất hiện trong các dự án hạ tầng, và đáng để học cách đọc nó cho đúng. Nó không giống như thất bại. Nhưng cũng chẳng hẳn là thành công một cách hiển nhiên.
Bình minh hoàng hôn (Dusk) đã có mặt trên mainnet được một thời gian rồi. Về mặt kỹ thuật, các hợp đồng thông minh bảo mật (confidential) liền mạch, tiêu chuẩn XSC, công bố có chọn lọc (selective disclosure) — tất cả đều được xây dựng xoay quanh một vấn đề cụ thể, có thật mà tài chính được quản lý thực sự đang gặp phải. Thế nhưng, khi nhìn vào hoạt động mạng thực tế, phần lớn điều đang diễn ra lại là hoạt động staking. Các hợp đồng bảo mật, việc phát hành chứng khoán thật — vẫn khá hiếm, theo hầu hết những tín hiệu sẵn có.
Khoảng cách giữa những gì hạ tầng có thể làm và những gì thực sự đang vận hành trên đó xứng đáng được ngồi với nó, thay vì vội vàng giải thích cho qua.
Vài điều thì vẫn có lợi, và đáng gọi tên thẳng thắn. Việc vesting sớm đã hoàn tất, nên không có sự kiện mở khóa (unlock) đang treo lơ lửng có thể làm méo kỳ vọng về nguồn cung. Các đối tác là các sàn/đơn vị được cấp phép giúp cho vị thế tuân thủ có được một nền móng vững hơn thay vì chỉ là kỳ vọng. Và theo đa số đánh giá kỹ thuật, chính lớp hạ tầng không phải điểm yếu — điều này không giống một câu chuyện
Câu hỏi khó hơn nằm ở sự đồng bộ về động lực (incentive alignment). Các tổ chức có vị thế tốt nhất để thực sự sử dụng loại hạ tầng quyền riêng tư và tuân thủ này có thể sẽ không bao giờ cần nắm giữ số lượng lớn token; phạm vi tiếp xúc của họ có thể chỉ ở mức tối thiểu, đủ cho mục đích vận hành. Trong khi đó, những người nắm giữ token lại đang tiếp nhận lượng phát hành phát sinh liên tục, chờ đợi khối lượng (volume) mà cho đến nay vẫn chưa xuất hiện với quy mô đáng kể. Hai mối quan hệ rất khác nhau với cùng một tài sản, nhưng không có cơ chế rõ ràng nào kéo hai phía vào sự đồng thuận
Điều này không phải là lời chỉ trích thiết kế. Nó chỉ là một mô tả thẳng thắn về tình trạng hiện tại: về mặt kỹ thuật thì có thể làm được, nhưng về mặt tài chính vẫn đang chờ bằng chứng.
Câu hỏi mà không ai thực sự có thể trả lời được — kể cả chính dự án — là: việc "hạ tầng đã sẵn sàng" có thể tiếp tục là một câu trả lời thỏa đáng trong bao lâu trước khi thị trường bắt đầu đòi hỏi rằng hạ tầng phải đang được sử dụng.
@Dusk #dusk $DUSK
Bình minh hoàng hôn (Dusk) đã có mặt trên mainnet được một thời gian rồi. Về mặt kỹ thuật, các hợp đồng thông minh bảo mật (confidential) liền mạch, tiêu chuẩn XSC, công bố có chọn lọc (selective disclosure) — tất cả đều được xây dựng xoay quanh một vấn đề cụ thể, có thật mà tài chính được quản lý thực sự đang gặp phải. Thế nhưng, khi nhìn vào hoạt động mạng thực tế, phần lớn điều đang diễn ra lại là hoạt động staking. Các hợp đồng bảo mật, việc phát hành chứng khoán thật — vẫn khá hiếm, theo hầu hết những tín hiệu sẵn có.
Khoảng cách giữa những gì hạ tầng có thể làm và những gì thực sự đang vận hành trên đó xứng đáng được ngồi với nó, thay vì vội vàng giải thích cho qua.
Vài điều thì vẫn có lợi, và đáng gọi tên thẳng thắn. Việc vesting sớm đã hoàn tất, nên không có sự kiện mở khóa (unlock) đang treo lơ lửng có thể làm méo kỳ vọng về nguồn cung. Các đối tác là các sàn/đơn vị được cấp phép giúp cho vị thế tuân thủ có được một nền móng vững hơn thay vì chỉ là kỳ vọng. Và theo đa số đánh giá kỹ thuật, chính lớp hạ tầng không phải điểm yếu — điều này không giống một câu chuyện
Câu hỏi khó hơn nằm ở sự đồng bộ về động lực (incentive alignment). Các tổ chức có vị thế tốt nhất để thực sự sử dụng loại hạ tầng quyền riêng tư và tuân thủ này có thể sẽ không bao giờ cần nắm giữ số lượng lớn token; phạm vi tiếp xúc của họ có thể chỉ ở mức tối thiểu, đủ cho mục đích vận hành. Trong khi đó, những người nắm giữ token lại đang tiếp nhận lượng phát hành phát sinh liên tục, chờ đợi khối lượng (volume) mà cho đến nay vẫn chưa xuất hiện với quy mô đáng kể. Hai mối quan hệ rất khác nhau với cùng một tài sản, nhưng không có cơ chế rõ ràng nào kéo hai phía vào sự đồng thuận
Điều này không phải là lời chỉ trích thiết kế. Nó chỉ là một mô tả thẳng thắn về tình trạng hiện tại: về mặt kỹ thuật thì có thể làm được, nhưng về mặt tài chính vẫn đang chờ bằng chứng.
Câu hỏi mà không ai thực sự có thể trả lời được — kể cả chính dự án — là: việc "hạ tầng đã sẵn sàng" có thể tiếp tục là một câu trả lời thỏa đáng trong bao lâu trước khi thị trường bắt đầu đòi hỏi rằng hạ tầng phải đang được sử dụng.
@Dusk #dusk $DUSK
4
4
39
·
--
Một con số đã chặn tôi: sức chứa hơn 17 tỷ lá, từ một cái cây chỉ sâu 34 tầng.
Mô hình Phoenix của Dusk sử dụng một cây Merkle nhị phân để lưu trữ bằng chứng cho mọi nốt nhạc, và đó chính là “chiêu” thật sự — sức chứa tăng theo cấp số nhân trong khi đường dẫn chứng minh chỉ tăng theo tuyến tính. Từ độ sâu 34 lên 35 thì sức chứa tăng gấp đôi, nhưng đường dẫn bằng chứng chỉ dài thêm vài phần trăm. Sự bất đối xứng này rất quan trọng đối với một chuỗi tập trung vào quyền riêng tư, vì mọi giao dịch đều mang theo một bằng chứng zero-knowledge; bằng chứng càng nhỏ thì càng tốt.
Tuy nhiên, kích thước của con số chỉ là một giới hạn lý thuyết. Trên thực tế, điều quyết định thời gian sức chứa đó kéo dài bao lâu là tốc độ các bản ghi chú mới được tạo ra. Ở thông lượng giao dịch thấp, cây có thể mất hàng chục năm mới đầy. Nếu mức độ ứng dụng tăng vọt, cùng một sức chứa đó có thể chịu áp lực thực tế chỉ trong vài tháng.
Điều này đặt ra câu hỏi thú vị hơn — khi cây bắt đầu đầy thì chuyện gì sẽ xảy ra? Lưu trữ lưu trữ, chi phí tạo bằng chứng, đồng bộ trạng thái — liệu các thứ này có mở rộng “mượt mà” song hành với việc tạo bản ghi chú không, hay có thứ gì đó bắt đầu bị căng trước? Một con số khổng lồ nhìn thì ấn tượng trên giấy tờ, nhưng khả năng sử dụng lâu dài phụ thuộc vào việc con số đó được dùng như thế nào, chứ không chỉ vào việc nó lớn ra sao.
Việc sở hữu một sức chứa cực kỳ lớn về mặt toán học có đồng nghĩa với việc vận hành vẫn thoải mái sau nhiều năm sử dụng thực tế không?
#dusk $DUSK @Dusk_Foundation
Một con số đã chặn tôi: sức chứa hơn 17 tỷ lá, từ một cái cây chỉ sâu 34 tầng.
Mô hình Phoenix của Dusk sử dụng một cây Merkle nhị phân để lưu trữ bằng chứng cho mọi nốt nhạc, và đó chính là “chiêu” thật sự — sức chứa tăng theo cấp số nhân trong khi đường dẫn chứng minh chỉ tăng theo tuyến tính. Từ độ sâu 34 lên 35 thì sức chứa tăng gấp đôi, nhưng đường dẫn bằng chứng chỉ dài thêm vài phần trăm. Sự bất đối xứng này rất quan trọng đối với một chuỗi tập trung vào quyền riêng tư, vì mọi giao dịch đều mang theo một bằng chứng zero-knowledge; bằng chứng càng nhỏ thì càng tốt.
Tuy nhiên, kích thước của con số chỉ là một giới hạn lý thuyết. Trên thực tế, điều quyết định thời gian sức chứa đó kéo dài bao lâu là tốc độ các bản ghi chú mới được tạo ra. Ở thông lượng giao dịch thấp, cây có thể mất hàng chục năm mới đầy. Nếu mức độ ứng dụng tăng vọt, cùng một sức chứa đó có thể chịu áp lực thực tế chỉ trong vài tháng.
Điều này đặt ra câu hỏi thú vị hơn — khi cây bắt đầu đầy thì chuyện gì sẽ xảy ra? Lưu trữ lưu trữ, chi phí tạo bằng chứng, đồng bộ trạng thái — liệu các thứ này có mở rộng “mượt mà” song hành với việc tạo bản ghi chú không, hay có thứ gì đó bắt đầu bị căng trước? Một con số khổng lồ nhìn thì ấn tượng trên giấy tờ, nhưng khả năng sử dụng lâu dài phụ thuộc vào việc con số đó được dùng như thế nào, chứ không chỉ vào việc nó lớn ra sao.
Việc sở hữu một sức chứa cực kỳ lớn về mặt toán học có đồng nghĩa với việc vận hành vẫn thoải mái sau nhiều năm sử dụng thực tế không?
#dusk $DUSK @Dusk
Mô hình Phoenix của Dusk sử dụng một cây Merkle nhị phân để lưu trữ bằng chứng cho mọi nốt nhạc, và đó chính là “chiêu” thật sự — sức chứa tăng theo cấp số nhân trong khi đường dẫn chứng minh chỉ tăng theo tuyến tính. Từ độ sâu 34 lên 35 thì sức chứa tăng gấp đôi, nhưng đường dẫn bằng chứng chỉ dài thêm vài phần trăm. Sự bất đối xứng này rất quan trọng đối với một chuỗi tập trung vào quyền riêng tư, vì mọi giao dịch đều mang theo một bằng chứng zero-knowledge; bằng chứng càng nhỏ thì càng tốt.
Tuy nhiên, kích thước của con số chỉ là một giới hạn lý thuyết. Trên thực tế, điều quyết định thời gian sức chứa đó kéo dài bao lâu là tốc độ các bản ghi chú mới được tạo ra. Ở thông lượng giao dịch thấp, cây có thể mất hàng chục năm mới đầy. Nếu mức độ ứng dụng tăng vọt, cùng một sức chứa đó có thể chịu áp lực thực tế chỉ trong vài tháng.
Điều này đặt ra câu hỏi thú vị hơn — khi cây bắt đầu đầy thì chuyện gì sẽ xảy ra? Lưu trữ lưu trữ, chi phí tạo bằng chứng, đồng bộ trạng thái — liệu các thứ này có mở rộng “mượt mà” song hành với việc tạo bản ghi chú không, hay có thứ gì đó bắt đầu bị căng trước? Một con số khổng lồ nhìn thì ấn tượng trên giấy tờ, nhưng khả năng sử dụng lâu dài phụ thuộc vào việc con số đó được dùng như thế nào, chứ không chỉ vào việc nó lớn ra sao.
Việc sở hữu một sức chứa cực kỳ lớn về mặt toán học có đồng nghĩa với việc vận hành vẫn thoải mái sau nhiều năm sử dụng thực tế không?
#dusk $DUSK @Dusk
7
·
--
Mình đã kéo các con số hiện tại trước khi viết bài này, nên đây là những gì thực sự đang có trên băng ngày hôm nay: DUSK đang giao dịch quanh $0.065–0.066, khoảng $32–33M vốn hóa theo lượt đọc của CoinMarketCap, với khối lượng 24h nằm trong khoảng $3.5–4.8M tùy theo bạn tin vào bộ tổng hợp nào — CoinGecko lấy từ 45 sàn và 51 thị trường, còn CoinCodex gần hơn với $4.8M. Chỉ riêng phần chênh lệch này đã nói lên điều gì đó: thanh khoản mỏng đến mức việc bạn kiểm tra nguồn dữ liệu nào sẽ làm câu chuyện thay đổi tới 30%.
Các ước tính về cung lưu hành cũng không đồng nhất — CMC để nó gần 497M, CoinGecko lại gần 590M — trong khi tổng cung tối đa là 1B, tức là ở đâu đó giữa 1/2 và 60% tổng cung đã được mở khóa và đang giao dịch.
Nhìn rộng hơn thì diễn biến giá kể một câu chuyện “thô” hơn so với bản tường thuật về nền tảng cơ bản. DUSK đã phá một xu hướng giảm kéo dài 8 tháng vào tháng 1/2026, vọt lên trên $0.30 sau khi mainnet, rồi trả lại gần như toàn bộ — đến cuối tháng 4 thì giá rơi xuống gần $0.10, và bây giờ đang tích lũy quanh vùng $0.06. Đó là mức thoái lui xấp xỉ từ 80% trở lên so với đỉnh tháng 1, trong khi câu chuyện phát triển thực tế — mainnet đã hoạt động, DuskEVM testnet đang tiến triển, quá trình token hóa NPEX đang diễn ra — vẫn tiếp tục chạy về cơ bản không bị gián đoạn.
Sự lệch pha đó mới là câu chuyện thực sự, không phải bản thân giá. Tốc độ phát triển và tốc độ giá đã bị tách ra mạnh vào đâu đó quanh Q1, và đến nay vẫn chưa hội tụ lại. Hoặc thị trường đã định giá sẵn mọi thứ mà lộ trình hứa hẹn và giờ chỉ đang chờ TVL được triển khai, hoặc câu chuyện RWA đơn giản là chưa đủ “lỏng” để có thể đẩy một tài sản có vốn hóa $32M chỉ dựa trên các chỉ báo nền tảng.
Bạn nghĩ phía nào trong khoảng trống đó sẽ được lấp trước — liệu khối lượng NPEX thực sự cuối cùng có xuất hiện trên chuỗi, hay giá cứ tiếp tục trôi dạt cho tới khi điều đó xảy ra?
#dusk $DUSK @Dusk_Foundation
Mình đã kéo các con số hiện tại trước khi viết bài này, nên đây là những gì thực sự đang có trên băng ngày hôm nay: DUSK đang giao dịch quanh $0.065–0.066, khoảng $32–33M vốn hóa theo lượt đọc của CoinMarketCap, với khối lượng 24h nằm trong khoảng $3.5–4.8M tùy theo bạn tin vào bộ tổng hợp nào — CoinGecko lấy từ 45 sàn và 51 thị trường, còn CoinCodex gần hơn với $4.8M. Chỉ riêng phần chênh lệch này đã nói lên điều gì đó: thanh khoản mỏng đến mức việc bạn kiểm tra nguồn dữ liệu nào sẽ làm câu chuyện thay đổi tới 30%.
Các ước tính về cung lưu hành cũng không đồng nhất — CMC để nó gần 497M, CoinGecko lại gần 590M — trong khi tổng cung tối đa là 1B, tức là ở đâu đó giữa 1/2 và 60% tổng cung đã được mở khóa và đang giao dịch.
Nhìn rộng hơn thì diễn biến giá kể một câu chuyện “thô” hơn so với bản tường thuật về nền tảng cơ bản. DUSK đã phá một xu hướng giảm kéo dài 8 tháng vào tháng 1/2026, vọt lên trên $0.30 sau khi mainnet, rồi trả lại gần như toàn bộ — đến cuối tháng 4 thì giá rơi xuống gần $0.10, và bây giờ đang tích lũy quanh vùng $0.06. Đó là mức thoái lui xấp xỉ từ 80% trở lên so với đỉnh tháng 1, trong khi câu chuyện phát triển thực tế — mainnet đã hoạt động, DuskEVM testnet đang tiến triển, quá trình token hóa NPEX đang diễn ra — vẫn tiếp tục chạy về cơ bản không bị gián đoạn.
Sự lệch pha đó mới là câu chuyện thực sự, không phải bản thân giá. Tốc độ phát triển và tốc độ giá đã bị tách ra mạnh vào đâu đó quanh Q1, và đến nay vẫn chưa hội tụ lại. Hoặc thị trường đã định giá sẵn mọi thứ mà lộ trình hứa hẹn và giờ chỉ đang chờ TVL được triển khai, hoặc câu chuyện RWA đơn giản là chưa đủ “lỏng” để có thể đẩy một tài sản có vốn hóa $32M chỉ dựa trên các chỉ báo nền tảng.
Bạn nghĩ phía nào trong khoảng trống đó sẽ được lấp trước — liệu khối lượng NPEX thực sự cuối cùng có xuất hiện trên chuỗi, hay giá cứ tiếp tục trôi dạt cho tới khi điều đó xảy ra?
#dusk $DUSK @Dusk
Các ước tính về cung lưu hành cũng không đồng nhất — CMC để nó gần 497M, CoinGecko lại gần 590M — trong khi tổng cung tối đa là 1B, tức là ở đâu đó giữa 1/2 và 60% tổng cung đã được mở khóa và đang giao dịch.
Nhìn rộng hơn thì diễn biến giá kể một câu chuyện “thô” hơn so với bản tường thuật về nền tảng cơ bản. DUSK đã phá một xu hướng giảm kéo dài 8 tháng vào tháng 1/2026, vọt lên trên $0.30 sau khi mainnet, rồi trả lại gần như toàn bộ — đến cuối tháng 4 thì giá rơi xuống gần $0.10, và bây giờ đang tích lũy quanh vùng $0.06. Đó là mức thoái lui xấp xỉ từ 80% trở lên so với đỉnh tháng 1, trong khi câu chuyện phát triển thực tế — mainnet đã hoạt động, DuskEVM testnet đang tiến triển, quá trình token hóa NPEX đang diễn ra — vẫn tiếp tục chạy về cơ bản không bị gián đoạn.
Sự lệch pha đó mới là câu chuyện thực sự, không phải bản thân giá. Tốc độ phát triển và tốc độ giá đã bị tách ra mạnh vào đâu đó quanh Q1, và đến nay vẫn chưa hội tụ lại. Hoặc thị trường đã định giá sẵn mọi thứ mà lộ trình hứa hẹn và giờ chỉ đang chờ TVL được triển khai, hoặc câu chuyện RWA đơn giản là chưa đủ “lỏng” để có thể đẩy một tài sản có vốn hóa $32M chỉ dựa trên các chỉ báo nền tảng.
Bạn nghĩ phía nào trong khoảng trống đó sẽ được lấp trước — liệu khối lượng NPEX thực sự cuối cùng có xuất hiện trên chuỗi, hay giá cứ tiếp tục trôi dạt cho tới khi điều đó xảy ra?
#dusk $DUSK @Dusk
2
22
·
--
Tôi đã sẵn sàng để đầu tư, nhưng tôi đã rút lui sau khi nhìn thấy những dấu hiệu cảnh báo.
Tôi đã sẵn sàng để đầu tư, nhưng tôi đã rút lui sau khi nhìn thấy những dấu hiệu cảnh báo.
bro_sf
·
--
Đêm qua tôi không ngủ được, nên tôi đang tự hỏi nên làm gì. Mình nên xem phim hay làm một chút việc? Rồi tôi nghĩ mình sẽ xem thị trường crypto, thế là tôi mở các ứng dụng coinmarketcap. Sau đó tôi thấy hôm nay thị trường BTC giảm 0.72%. Rồi tôi thấy token $BABY đang tăng 3.5% ở mức 0.01199$. Giá đang đi lên, vốn hóa 51.22m, khối lượng giao dịch 24h là 52.11m, xếp thứ 24 và khối lượng tăng 475%. Tôi cứ nghĩ mình có thể quyết định chỉ bằng việc nhìn vào giá. Nhưng trong vài ngày nay, @BabylonLabs_io lại hiện ra trước mắt tôi hết lần này đến lần khác, nên tôi muốn xem thêm chi tiết về dự án. Rồi tôi vào trang kiểm toán của Certik.Skynet. Sau đó tôi thực sự bị sốc khi thấy điểm số. Điểm đánh giá AA 89.58 có vẻ vẫn đang ở tình trạng tốt trong phần bảo mật. Ngoài ra còn có một vài cuộc kiểm toán từ bên thứ ba. Nhìn xuống thêm một chút trên trang Certik, tôi thấy kiểm toán của Certik vẫn chưa được hoàn tất, không có xác minh đội ngũ, và phần đánh giá cũng đang hiển thị là dạng một phần. Thế là trong đầu tôi nảy ra một câu hỏi. Nghe có vẻ khá mạnh. Nhưng tôi vẫn còn nghi ngờ trong lòng tại sao những mục đó lại chưa hoàn thành dù dự án này có vẻ tốt đến vậy. Tôi thấy từ trang Certik rằng việc kiểm toán vẫn chưa được hoàn tất. Có lẽ có những lý do đủ sâu phía sau mà chúng ta không biết, nhưng với tư cách là một người dùng bình thường, điều này đã khơi dậy sự tò mò của tôi. Vậy theo bạn, liệu có tốt hơn nếu những phần đó đã được hoàn tất/được thể hiện đầy đủ trong chủ đề này không? Hay phần thông tin ít ỏi như vậy là đã đủ?
#baby $BABY
#baby $BABY
1
1
82
·
--
?
?
bro_sf
·
--
Giảm giáKhi xem xét tokenomics của Babylon, có một điều thật sự thu hút sự chú ý của tôi. Theo thông tin hiện có, tổng cung là 10,98 tỷ, với khoảng 4,03 tỷ token đang được lưu hành. Nhưng đối với một dự án có quy mô như vậy, thật bất ngờ là trong tokenomics chính thức lại không có đề cập rõ ràng về tổng cung tối đa. Điều này khiến tôi tự hỏi: đó chỉ đơn giản là một sự thiếu sót hay có lý do nào đó khiến thông tin này vẫn chưa được công bố rõ ràng? Việc biết tổng cung tối đa là quan trọng vì nó giúp nhà đầu tư đánh giá lượng token sẽ được phát hành trong tương lai, khả năng lạm phát và định giá dài hạn. Vì vậy, luôn đáng để dành thời gian đào sâu vào các tài liệu chính thức thay vì chỉ dựa vào tin đồn hoặc sự thổi phồng. Ý kiến của bạn là gì? Bạn nghĩ việc thiếu thông tin về tổng cung tối đa chỉ là một sự thiếu sót, hay có thể có một cách giải thích khác?
@BabylonLabs_io #baby $BABY $BTC
@BabylonLabs_io #baby $BABY $BTC
7
·
--
tốt 😊
tốt 😊
bro_sf
·
--
Có một số câu hỏi cứ hiện lên trong đầu tôi về Babylon. Thứ được thể hiện ra bên ngoài và những gì đang diễn ra bên trong không giống nhau. Nhiều người đã nghĩ rằng đợt airdrop này là một phần thưởng dành cho cộng đồng, nhưng khi nhìn vào phần phân bổ thì nó có vẻ hơi khác. Nhiều ví đã rời đi sau một thời gian ngắn canh tác để nhận phần thưởng, còn những người đã thực sự ở đó trong thời gian dài lại không nhận được nhiều. Vì vậy, câu hỏi của tôi không phải là ai đã nhận được, mà là ai mới thực sự ở lại sau khi phần thưởng kết thúc. Một điều nữa là cụm từ “chỉ Bitcoin”. Nó nghe có vẻ hay, nhưng khi xem các tài liệu thì rõ ràng ngoài Bitcoin, Ethereum và một số ứng dụng DeFi cũng đang được dựa vào ở đây. Vẫn còn đó cơ chế quản trị và multisig khẩn cấp. Tôi không nói rằng thiết kế là xấu, nhưng có một chút khác biệt giữa những gì được marketing và thực tế. Cuối cùng, câu hỏi là: liệu mọi người có tiếp tục khóa Bitcoin khi đã biết tất cả điều này hay không, hay sự quan tâm cũng sẽ biến mất khi lợi nhuận giảm xuống. Tôi nghĩ đó chính là bài kiểm tra thực sự.
@BabylonLabs_io #baby $BABY
@BabylonLabs_io #baby $BABY
4
Đăng nhập để khám phá thêm nội dung
Tham gia cùng người dùng tiền mã hóa toàn cầu trên Binance Square
⚡️ Nhận thông tin mới nhất và hữu ích về tiền mã hóa.
💬 Được tin cậy bởi sàn giao dịch tiền mã hóa lớn nhất thế giới.
👍 Khám phá những thông tin chuyên sâu thực tế từ những nhà sáng tạo đã xác minh.
Email / Số điện thoại
Chủ đề thịnh hành
TheoDõiFOMC
99,282 lượt xem
590 đang thảo luận
Cục Dự trữ Liên bang (Fed) đã tăng lãi suất lần đầu tiên kể từ năm 2023 trong bối cảnh lạm phát dai dẳng. Các nhà hoạch định chính sách của Fed đã bỏ phiếu 12-0 để nâng lãi suất quỹ liên bang từ 3,5% lên 3,75%, với mức mục tiêu mới là 3,75% đến 4%. Mức tăng 25 điểm cơ bản này đánh dấu lần điều chỉnh lãi suất đầu tiên kể từ tháng 7/2023 và diễn ra sau khi Fed giữ nguyên lãi suất trong năm cuộc họp đầu tiên trong năm nay. #TheoDõiFOMC #45NgayTuDoTaiChinh #DotPlotSignalsOneMoreHikeIn2026 $NVDAB $AAPLB $NVDA.US #45NgayTuDoTaiChinh #FedHikes25BpsUSStocksClose #
kynfoolishupdate
·0 lượt thích
·184 lượt xem
45NgayTuDoTaiChinh
936,773 lượt xem
3,257 đang thảo luận
TinFed
83,687 lượt xem
398 đang thảo luận