Binance Square
AF Trends
9.2k Bài đăng

AF Trends

Your Daily Guide to the Markets. Clear entries, zero hype, maximum focus.Trusted content creator AF Trends
345 Đang theo dõi
464 Người theo dõi
3.5K+ Đã thích
Bài đăng
PINNED
·
--
#termmax @termmax 1 con số có thể khiến một khoản vay lãi suất cố định trông có vẻ đơn giản: lãi suất. Nhưng tôi nghĩ con số quan trọng hơn là kỳ hạn. Đó là điều đã khiến tôi nhìn kỹ hơn vào @termmax . Với TermMax, chúng tôi thống nhất 2 điều ngay từ đầu: 1. Lãi suất vay 2. Ngày vị thế kết thúc Vì vậy chi phí không thay đổi liên tục và bạn biết chính xác khi nào cần phải hoàn trả khoản vay. Điều này nghe có vẻ đơn giản cho đến khi bạn so sánh với trải nghiệm DeFi thông thường. Lãi suất biến đổi mang lại sự linh hoạt — nhưng chi phí có thể biến động. Kỳ hạn cố định mang lại tính dự đoán trước — nhưng bạn phải đánh đổi một phần linh hoạt. Và đó là sự đánh đổi mà tôi thấy thú vị hơn. Nếu lãi suất bất ngờ chuyển sang có lợi cho bạn sau khi đã tham gia một vị thế lãi suất cố định, bạn không tự động nhận được mức lãi suất rẻ hơn. Nhưng nếu lãi suất đi ngược lại bạn, mức lãi suất đã thỏa thuận của bạn cũng không tự nhiên tăng vọt. Vì vậy, tôi không nghĩ câu hỏi thực sự là: “Lãi suất cố định có tốt hơn không?” Mà là: “Bạn sẽ đánh đổi bao nhiêu linh hoạt để biết chi phí VÀ điểm kết thúc ngay từ ngày đầu?” Đó là phần của @termmax mà tôi cứ suy nghĩ mãi. #TermMax
#termmax @TermMax
1 con số có thể khiến một khoản vay lãi suất cố định trông có vẻ đơn giản: lãi suất.

Nhưng tôi nghĩ con số quan trọng hơn là kỳ hạn.

Đó là điều đã khiến tôi nhìn kỹ hơn vào @TermMax .

Với TermMax, chúng tôi thống nhất 2 điều ngay từ đầu:

1. Lãi suất vay
2. Ngày vị thế kết thúc

Vì vậy chi phí không thay đổi liên tục và bạn biết chính xác khi nào cần phải hoàn trả khoản vay.

Điều này nghe có vẻ đơn giản cho đến khi bạn so sánh với trải nghiệm DeFi thông thường.

Lãi suất biến đổi mang lại sự linh hoạt — nhưng chi phí có thể biến động.

Kỳ hạn cố định mang lại tính dự đoán trước — nhưng bạn phải đánh đổi một phần linh hoạt.

Và đó là sự đánh đổi mà tôi thấy thú vị hơn.

Nếu lãi suất bất ngờ chuyển sang có lợi cho bạn sau khi đã tham gia một vị thế lãi suất cố định, bạn không tự động nhận được mức lãi suất rẻ hơn. Nhưng nếu lãi suất đi ngược lại bạn, mức lãi suất đã thỏa thuận của bạn cũng không tự nhiên tăng vọt.

Vì vậy, tôi không nghĩ câu hỏi thực sự là:

“Lãi suất cố định có tốt hơn không?”

Mà là:

“Bạn sẽ đánh đổi bao nhiêu linh hoạt để biết chi phí VÀ điểm kết thúc ngay từ ngày đầu?”

Đó là phần của @TermMax mà tôi cứ suy nghĩ mãi. #TermMax
·
--
Tăng giá
Tôi đã kiên nhẫn chờ đợi qua nhịp điều chỉnh dài, và cuối cùng thì kiên nhẫn cũng được đền đáp. Việc $BANK leo lên tốt trên biểu đồ nhắc tôi nhớ vì sao cứ vững vàng vượt qua giai đoạn tích lũy thì luôn thắng. Các nến xanh trông rất ổn, và các lệnh spot của chúng tôi đang phục hồi mạnh. Thiết lập giao dịch Điểm vào lệnh: 0.0385 đến 0.0390 USDT Chốt lời: 0.0435 USDT Cắt lỗ: 0.0365 USDT Tuyên bố từ chối trách nhiệm: Giao dịch tiền mã hóa mang rủi ro cao và điều kiện thị trường có thể thay đổi nhanh chóng. Hãy luôn quản lý rủi ro và giao dịch có trách nhiệm. Bấm vào biểu đồ bên dưới để giao dịch. {spot}(BANKUSDT) Nếu bạn thấy bản phân tích này hữu ích, hãy bấm Theo dõi để cập nhật tiếp theo.
Tôi đã kiên nhẫn chờ đợi qua nhịp điều chỉnh dài, và cuối cùng thì kiên nhẫn cũng được đền đáp. Việc $BANK leo lên tốt trên biểu đồ nhắc tôi nhớ vì sao cứ vững vàng vượt qua giai đoạn tích lũy thì luôn thắng. Các nến xanh trông rất ổn, và các lệnh spot của chúng tôi đang phục hồi mạnh.

Thiết lập giao dịch
Điểm vào lệnh: 0.0385 đến 0.0390 USDT
Chốt lời: 0.0435 USDT
Cắt lỗ: 0.0365 USDT

Tuyên bố từ chối trách nhiệm: Giao dịch tiền mã hóa mang rủi ro cao và điều kiện thị trường có thể thay đổi nhanh chóng. Hãy luôn quản lý rủi ro và giao dịch có trách nhiệm.

Bấm vào biểu đồ bên dưới để giao dịch.


Nếu bạn thấy bản phân tích này hữu ích, hãy bấm Theo dõi để cập nhật tiếp theo.
·
--
Tăng giá
$BANK đang cho thấy một cấu trúc phục hồi vững chắc trên khung thời gian thấp sau khi bật lên từ đáy gần đây quanh 0.0341 USDT. RSI hiện đang dao động quanh mức 66, cho thấy động lượng tăng mạnh đang hình thành nhưng vẫn chưa bị quá mua. Diễn biến giá đã vượt qua các đường trung bình động ngắn hạn, với EMA 9 cắt lên rõ ràng EMA 21 xác nhận rằng người mua đang quay trở lại nắm quyền kiểm soát. Khối lượng đang tăng lên khá tốt, qua đó củng cố thêm cho đợt tăng này. Thiết Lập Giao Dịch Điểm Vào Lệnh: 0.0385 đến 0.0390 USDT Chốt Lời: 0.0435 USDT Cắt Lỗ: 0.0365 USDT Lưu Ý: Giao dịch tiền mã hóa có rủi ro cao và điều kiện thị trường có thể thay đổi nhanh chóng. Luôn quản lý rủi ro của bạn và giao dịch một cách có trách nhiệm. Bấm vào biểu đồ bên dưới để giao dịch. {spot}(BANKUSDT) Nếu bạn thấy phần phân tích này hữu ích, hãy bấm Theo dõi để nhận cập nhật tiếp theo.
$BANK đang cho thấy một cấu trúc phục hồi vững chắc trên khung thời gian thấp sau khi bật lên từ đáy gần đây quanh 0.0341 USDT. RSI hiện đang dao động quanh mức 66, cho thấy động lượng tăng mạnh đang hình thành nhưng vẫn chưa bị quá mua. Diễn biến giá đã vượt qua các đường trung bình động ngắn hạn, với EMA 9 cắt lên rõ ràng EMA 21 xác nhận rằng người mua đang quay trở lại nắm quyền kiểm soát. Khối lượng đang tăng lên khá tốt, qua đó củng cố thêm cho đợt tăng này.

Thiết Lập Giao Dịch
Điểm Vào Lệnh: 0.0385 đến 0.0390 USDT
Chốt Lời: 0.0435 USDT
Cắt Lỗ: 0.0365 USDT

Lưu Ý: Giao dịch tiền mã hóa có rủi ro cao và điều kiện thị trường có thể thay đổi nhanh chóng. Luôn quản lý rủi ro của bạn và giao dịch một cách có trách nhiệm.

Bấm vào biểu đồ bên dưới để giao dịch.


Nếu bạn thấy phần phân tích này hữu ích, hãy bấm Theo dõi để nhận cập nhật tiếp theo.
#dusk $DUSK @Dusk_Foundation Càng nhìn kỹ việc tài chính được quản lý (regulated finance) trên on-chain, tôi càng nghĩ rằng phần khó không phải là đưa một tài sản lên blockchain. Mà là khiến blockchain hiểu lý do vì sao tài sản đó được phép di chuyển. Trước đây tôi từng nghĩ token hóa RWA chủ yếu là tạo ra một phiên bản kỹ thuật số của một tài sản tài chính hiện có. Khi nó đã lên on-chain, tôi cho rằng thách thức chính nằm ở giao dịch và thanh toán. Nhưng Dusk khiến tôi nhìn nhận khác đi. Một tài sản được quản lý có các quy tắc gần như cho mọi thứ: Ai có thể mua? Ai có thể nắm giữ? Tài sản có thể chuyển sang ví khác không? Cần phải công bố những gì? Điều gì nên được giữ riêng tư? Và việc thanh toán sẽ được thực hiện song song với tài sản như thế nào? Điều khiến tôi hứng thú là Dusk coi các yêu cầu này như một phần của hạ tầng, thay vì thứ mà các ứng dụng chỉ cần thêm vào sau. Kiến trúc của nó phản ánh hướng tiếp cận đó: DuskDS cung cấp settlement và khả năng sẵn sàng dữ liệu, trong khi DuskVM hỗ trợ thực thi native L1 và DuskEVM cung cấp môi trường tương thích EVM. Citadel bổ sung năng lực nhận dạng (identity) và công bố có chọn lọc (selective-disclosure) cho các quy trình được quản lý. Điều đó khiến tôi suy nghĩ lại về hạ tầng RWA. Có lẽ bước đột phá lớn hơn không chỉ là biến tài sản tài chính có thể chuyển nhượng trên on-chain. Có lẽ là khiến các quy tắc xung quanh những tài sản đó cũng trở nên có thể lập trình. Tất nhiên, Dusk vẫn phải chứng minh rằng cách tiếp cận này thực sự làm các thị trường tài chính trở nên đơn giản hơn, chứ không phải phức tạp hơn. Nhưng đó chính là điều tôi đang theo dõi. Nếu RWAs mở rộng quy mô, câu hỏi quan trọng có thể không chỉ là “Tài sản này có thể di chuyển không?” Mà có thể là “Nên di chuyển hay không, trong những điều kiện nào, và ai cần biết?” Liệu các quy tắc tài chính có thể lập trình quan trọng hơn chính bản thân token hóa không?
#dusk $DUSK @Dusk

Càng nhìn kỹ việc tài chính được quản lý (regulated finance) trên on-chain, tôi càng nghĩ rằng phần khó không phải là đưa một tài sản lên blockchain.

Mà là khiến blockchain hiểu lý do vì sao tài sản đó được phép di chuyển.

Trước đây tôi từng nghĩ token hóa RWA chủ yếu là tạo ra một phiên bản kỹ thuật số của một tài sản tài chính hiện có. Khi nó đã lên on-chain, tôi cho rằng thách thức chính nằm ở giao dịch và thanh toán.

Nhưng Dusk khiến tôi nhìn nhận khác đi.

Một tài sản được quản lý có các quy tắc gần như cho mọi thứ:

Ai có thể mua?
Ai có thể nắm giữ?
Tài sản có thể chuyển sang ví khác không?
Cần phải công bố những gì?
Điều gì nên được giữ riêng tư?
Và việc thanh toán sẽ được thực hiện song song với tài sản như thế nào?

Điều khiến tôi hứng thú là Dusk coi các yêu cầu này như một phần của hạ tầng, thay vì thứ mà các ứng dụng chỉ cần thêm vào sau.

Kiến trúc của nó phản ánh hướng tiếp cận đó: DuskDS cung cấp settlement và khả năng sẵn sàng dữ liệu, trong khi DuskVM hỗ trợ thực thi native L1 và DuskEVM cung cấp môi trường tương thích EVM. Citadel bổ sung năng lực nhận dạng (identity) và công bố có chọn lọc (selective-disclosure) cho các quy trình được quản lý.

Điều đó khiến tôi suy nghĩ lại về hạ tầng RWA.

Có lẽ bước đột phá lớn hơn không chỉ là biến tài sản tài chính có thể chuyển nhượng trên on-chain.

Có lẽ là khiến các quy tắc xung quanh những tài sản đó cũng trở nên có thể lập trình.

Tất nhiên, Dusk vẫn phải chứng minh rằng cách tiếp cận này thực sự làm các thị trường tài chính trở nên đơn giản hơn, chứ không phải phức tạp hơn.

Nhưng đó chính là điều tôi đang theo dõi.

Nếu RWAs mở rộng quy mô, câu hỏi quan trọng có thể không chỉ là “Tài sản này có thể di chuyển không?”

Mà có thể là “Nên di chuyển hay không, trong những điều kiện nào, và ai cần biết?”

Liệu các quy tắc tài chính có thể lập trình quan trọng hơn chính bản thân token hóa không?
·
--
Tăng giá
#dusk $DUSK @Dusk_Foundation Trước đây, tôi từng nghĩ rằng việc có nhiều môi trường thực thi trên một blockchain nghe giống như một sự phức tạp không cần thiết. Nếu các nhà phát triển đã có thể xây dựng smart contract, vậy tại sao không chỉ cung cấp cho mọi người một môi trường và giữ mọi thứ thật đơn giản? Nhưng khi tìm hiểu kỹ hơn về Dusk, tôi đã thay đổi quan điểm đó. Dusk tách phần thực thi ứng dụng khỏi phần chịu trách nhiệm thanh toán (settlement) và tính sẵn sàng dữ liệu. DuskEVM cung cấp cho nhà phát triển một lối đi quen thuộc với Solidity/EVM, trong khi DuskVM được thiết kế cho các ứng dụng cần truy cập trực tiếp vào Dusk L1 và các khả năng gốc của nó. Bên dưới tất cả là DuskDS, đóng vai trò nền tảng thanh toán và dữ liệu-độ-sẵn-sàng. Ban đầu, điều đó nghe như một kiến trúc mà nhà phát triển sẽ phải lo lắng. Rồi tôi bắt đầu suy nghĩ về các tài sản tài chính được quản lý. Một quỹ được token hóa có thể muốn được sử dụng công cụ EVM quen thuộc. Một ứng dụng khác có thể cần truy cập trực tiếp vào tài sản gốc, các tính năng riêng tư hoặc khả năng bảo mật bằng zero-knowledge. Và thị trường nền tảng vẫn cần một cơ chế thanh toán có thể dự đoán được, bất kể ứng dụng đang sử dụng môi trường nào. Điều đó khiến tôi suy nghĩ lại ý tưởng “một blockchain, một lớp thực thi.” Có lẽ hạ tầng tài chính không nhất thiết phải để mọi ứng dụng hoạt động theo đúng cùng một cách. Có lẽ nó cần những môi trường khác nhau có thể chuyên biệt hóa, nhưng vẫn chia sẻ cùng một nền tảng thanh toán. Tôi cũng thích việc Dusk không hề giả vờ rằng điều này tự động giải quyết mọi vấn đề. Nhiều lớp hơn có thể mang lại nhiều linh hoạt, nhưng đồng thời cũng có thể tạo ra nhiều phức tạp hơn, nhiều phụ thuộc hơn và nhiều thứ cần hoạt động đáng tin cậy cùng nhau. Vì vậy, câu hỏi mà tôi đang theo dõi không chỉ là liệu kiến trúc của Dusk có thực sự thông minh về mặt kỹ thuật. Mà là liệu sự tách biệt này có thể thực sự giúp việc xây dựng và vận hành các ứng dụng tài chính được quản lý trở nên dễ dàng hơn ở quy mô lớn hay không. Bởi vì nếu nhà phát triển nhận được sự linh hoạt nhưng các tổ chức lại phải đối mặt với sự phức tạp, thì kiến trúc đó vẫn chưa giải quyết được vấn đề cốt lõi. Bạn sẽ tin tưởng một blockchain tài chính hơn nếu nó có một lớp thực thi đơn giản, hay nếu các lớp khác nhau được xây dựng riêng cho những công việc khác nhau?
#dusk $DUSK @Dusk

Trước đây, tôi từng nghĩ rằng việc có nhiều môi trường thực thi trên một blockchain nghe giống như một sự phức tạp không cần thiết.

Nếu các nhà phát triển đã có thể xây dựng smart contract, vậy tại sao không chỉ cung cấp cho mọi người một môi trường và giữ mọi thứ thật đơn giản?

Nhưng khi tìm hiểu kỹ hơn về Dusk, tôi đã thay đổi quan điểm đó.

Dusk tách phần thực thi ứng dụng khỏi phần chịu trách nhiệm thanh toán (settlement) và tính sẵn sàng dữ liệu. DuskEVM cung cấp cho nhà phát triển một lối đi quen thuộc với Solidity/EVM, trong khi DuskVM được thiết kế cho các ứng dụng cần truy cập trực tiếp vào Dusk L1 và các khả năng gốc của nó. Bên dưới tất cả là DuskDS, đóng vai trò nền tảng thanh toán và dữ liệu-độ-sẵn-sàng.

Ban đầu, điều đó nghe như một kiến trúc mà nhà phát triển sẽ phải lo lắng.

Rồi tôi bắt đầu suy nghĩ về các tài sản tài chính được quản lý.

Một quỹ được token hóa có thể muốn được sử dụng công cụ EVM quen thuộc. Một ứng dụng khác có thể cần truy cập trực tiếp vào tài sản gốc, các tính năng riêng tư hoặc khả năng bảo mật bằng zero-knowledge. Và thị trường nền tảng vẫn cần một cơ chế thanh toán có thể dự đoán được, bất kể ứng dụng đang sử dụng môi trường nào.

Điều đó khiến tôi suy nghĩ lại ý tưởng “một blockchain, một lớp thực thi.”

Có lẽ hạ tầng tài chính không nhất thiết phải để mọi ứng dụng hoạt động theo đúng cùng một cách.

Có lẽ nó cần những môi trường khác nhau có thể chuyên biệt hóa, nhưng vẫn chia sẻ cùng một nền tảng thanh toán.

Tôi cũng thích việc Dusk không hề giả vờ rằng điều này tự động giải quyết mọi vấn đề. Nhiều lớp hơn có thể mang lại nhiều linh hoạt, nhưng đồng thời cũng có thể tạo ra nhiều phức tạp hơn, nhiều phụ thuộc hơn và nhiều thứ cần hoạt động đáng tin cậy cùng nhau.

Vì vậy, câu hỏi mà tôi đang theo dõi không chỉ là liệu kiến trúc của Dusk có thực sự thông minh về mặt kỹ thuật.

Mà là liệu sự tách biệt này có thể thực sự giúp việc xây dựng và vận hành các ứng dụng tài chính được quản lý trở nên dễ dàng hơn ở quy mô lớn hay không.

Bởi vì nếu nhà phát triển nhận được sự linh hoạt nhưng các tổ chức lại phải đối mặt với sự phức tạp, thì kiến trúc đó vẫn chưa giải quyết được vấn đề cốt lõi.

Bạn sẽ tin tưởng một blockchain tài chính hơn nếu nó có một lớp thực thi đơn giản, hay nếu các lớp khác nhau được xây dựng riêng cho những công việc khác nhau?
#termmax @termmax 5–10 giao dịch cho một vị thế dùng đòn bẩy nghe có vẻ như một bất tiện nhỏ. Tôi không nghĩ vậy. Tôi cứ quay lại con số đó khi nhìn vào @termmax . Vòng lặp thông thường có thể nghĩa là nạp thêm tài sản thế chấp, vay mượn, hoán đổi, nạp lại và lặp lại. TermMax nói rằng động cơ đòn bẩy của họ nén toàn bộ quy trình đó thành một giao dịch duy nhất. Nhưng phần thú vị không thực sự nằm ở cái nút. Mà là chuyện gì xảy ra sau đó. Chi phí đòn bẩy được cố định ngay từ đầu, và vị thế có một thời hạn đáo hạn xác định. Vì vậy, thay vì liên tục quản lý một vòng lặp trong khi lãi suất và điều kiện cấp vốn thay đổi, bạn bắt đầu với một chi phí đã biết và một điểm kết thúc cụ thể. Điều đó không làm cho đòn bẩy an toàn hơn. Tài sản thế chấp, hướng đi của thị trường và thời hạn đáo hạn vẫn rất quan trọng. Nhưng nó khiến tôi phải đặt câu hỏi: chúng ta thường đo lường đòn bẩy DeFi “tốt hơn” như thế nào. Ít giao dịch hơn có phải là trải nghiệm người dùng (UX) tốt hơn, hay việc kết hợp tự động hóa + chi phí cố định + thời hạn kết thúc xác định tạo ra một cách căn bản khác để cấu trúc các vị thế dùng đòn bẩy? Đó là phần của @termmax mà tôi muốn theo dõi kỹ hơn. #TermMax
#termmax @TermMax
5–10 giao dịch cho một vị thế dùng đòn bẩy nghe có vẻ như một bất tiện nhỏ. Tôi không nghĩ vậy.

Tôi cứ quay lại con số đó khi nhìn vào @TermMax .

Vòng lặp thông thường có thể nghĩa là nạp thêm tài sản thế chấp, vay mượn, hoán đổi, nạp lại và lặp lại. TermMax nói rằng động cơ đòn bẩy của họ nén toàn bộ quy trình đó thành một giao dịch duy nhất.

Nhưng phần thú vị không thực sự nằm ở cái nút.

Mà là chuyện gì xảy ra sau đó.

Chi phí đòn bẩy được cố định ngay từ đầu, và vị thế có một thời hạn đáo hạn xác định. Vì vậy, thay vì liên tục quản lý một vòng lặp trong khi lãi suất và điều kiện cấp vốn thay đổi, bạn bắt đầu với một chi phí đã biết và một điểm kết thúc cụ thể.

Điều đó không làm cho đòn bẩy an toàn hơn. Tài sản thế chấp, hướng đi của thị trường và thời hạn đáo hạn vẫn rất quan trọng.

Nhưng nó khiến tôi phải đặt câu hỏi: chúng ta thường đo lường đòn bẩy DeFi “tốt hơn” như thế nào.

Ít giao dịch hơn có phải là trải nghiệm người dùng (UX) tốt hơn, hay việc kết hợp tự động hóa + chi phí cố định + thời hạn kết thúc xác định tạo ra một cách căn bản khác để cấu trúc các vị thế dùng đòn bẩy?

Đó là phần của @TermMax mà tôi muốn theo dõi kỹ hơn.
#TermMax
·
--
Tăng giá
#dusk $DUSK @Dusk_Foundation Tôi nghĩ điều thú vị nhất về Dusk có thể là thứ mà người dùng có lẽ không bao giờ để ý. Khi ai đó mua một tài sản tài chính, họ có thể không quan tâm cơ chế đồng thuận nào đang chạy bên dưới hay mạng xử lý giao dịch như thế nào. Họ quan tâm rằng tài sản đã được phát hành đúng cách, việc chuyển nhượng được cho phép, việc thanh toán đã diễn ra và hồ sơ sở hữu của họ là chính xác. Điều đó khiến tôi nhìn Dusk theo một cách khác. Có lẽ hạ tầng blockchain tốt nhất cho tài chính không phải là hạ tầng liên tục nhắc người dùng rằng họ đang dùng blockchain. Có lẽ đó là hạ tầng âm thầm xử lý những phần phức tạp ở bên dưới, trong khi trải nghiệm vẫn cảm giác giống một sản phẩm tài chính thông thường. Đó là một bài toán khó hơn nhiều so với việc chỉ làm giao dịch nhanh hơn. Và tôi tò mò liệu Dusk có thực sự làm cho hạ tầng blockchain “biến mất” sau trải nghiệm tài chính khi người dùng thật sự bắt đầu tham gia hay không. Bạn muốn biết rằng mình đang dùng blockchain, hay đơn giản là nhận được các lợi ích mà không cần nghĩ đến blockchain chút nào?
#dusk $DUSK @Dusk

Tôi nghĩ điều thú vị nhất về Dusk có thể là thứ mà người dùng có lẽ không bao giờ để ý.

Khi ai đó mua một tài sản tài chính, họ có thể không quan tâm cơ chế đồng thuận nào đang chạy bên dưới hay mạng xử lý giao dịch như thế nào.

Họ quan tâm rằng tài sản đã được phát hành đúng cách, việc chuyển nhượng được cho phép, việc thanh toán đã diễn ra và hồ sơ sở hữu của họ là chính xác.

Điều đó khiến tôi nhìn Dusk theo một cách khác.

Có lẽ hạ tầng blockchain tốt nhất cho tài chính không phải là hạ tầng liên tục nhắc người dùng rằng họ đang dùng blockchain.

Có lẽ đó là hạ tầng âm thầm xử lý những phần phức tạp ở bên dưới, trong khi trải nghiệm vẫn cảm giác giống một sản phẩm tài chính thông thường.

Đó là một bài toán khó hơn nhiều so với việc chỉ làm giao dịch nhanh hơn.

Và tôi tò mò liệu Dusk có thực sự làm cho hạ tầng blockchain “biến mất” sau trải nghiệm tài chính khi người dùng thật sự bắt đầu tham gia hay không.

Bạn muốn biết rằng mình đang dùng blockchain, hay đơn giản là nhận được các lợi ích mà không cần nghĩ đến blockchain chút nào?
Tôi nghĩ phần thú vị nhất trong đòn bẩy @termmax thực ra không nằm ở cái gọi là “một chạm”. Mà nằm ở việc một lần chạm đó thay thế điều gì. Một chiến lược DeFi dùng đòn bẩy có thể bao gồm việc nạp tài sản thế chấp, vay, hoán đổi, rồi nạp lại — và TermMax cho biết động cơ đòn bẩy của họ có thể tự động hóa những gì nếu làm thủ công sẽ mất khoảng 5–10 giao dịch. Nhưng chi tiết lớn hơn lại rất dễ bỏ sót: chi phí đòn bẩy được cố định ngay từ đầu và vị thế có một kỳ hạn xác định. Điều đó làm thay đổi câu hỏi mà tôi đặt ra. Tôi ít quan tâm đến “tôi có thể nhận được đòn bẩy bao nhiêu?” và quan tâm nhiều hơn đến “đòn bẩy tôi đang sử dụng có thể dự đoán được đến mức nào?” Tự động hóa loại bỏ ma sát. Chi phí cố định loại bỏ một lớp bất định. Kỳ đáo hạn được xác định buộc chiến lược phải có một điểm kết thúc. Tất nhiên, không có điều nào trong số đó khiến đòn bẩy trở nên không rủi ro. Tài sản thế chấp vẫn quan trọng, và kỳ hạn vẫn phải được quản lý. Nhưng tôi nghĩ đây là chỗ @termmax trở nên thú vị: nó không chỉ là làm cho việc thực thi đòn bẩy dễ hơn — mà còn cố gắng làm cho các vị thế dùng đòn bẩy trở nên có cấu trúc hơn. Nếu người dùng có thể chọn giữa đòn bẩy linh hoạt, liên tục thay đổi và một vị thế có chi phí và thời hạn kết thúc đã biết, thì mô hình nào sẽ giành ưu thế khi thị trường biến động? Đó là phần ở TermMax mà tôi đang theo dõi. #TermMax #termmax
Tôi nghĩ phần thú vị nhất trong đòn bẩy @TermMax thực ra không nằm ở cái gọi là “một chạm”.

Mà nằm ở việc một lần chạm đó thay thế điều gì.

Một chiến lược DeFi dùng đòn bẩy có thể bao gồm việc nạp tài sản thế chấp, vay, hoán đổi, rồi nạp lại — và TermMax cho biết động cơ đòn bẩy của họ có thể tự động hóa những gì nếu làm thủ công sẽ mất khoảng 5–10 giao dịch.

Nhưng chi tiết lớn hơn lại rất dễ bỏ sót: chi phí đòn bẩy được cố định ngay từ đầu và vị thế có một kỳ hạn xác định.

Điều đó làm thay đổi câu hỏi mà tôi đặt ra.

Tôi ít quan tâm đến “tôi có thể nhận được đòn bẩy bao nhiêu?” và quan tâm nhiều hơn đến “đòn bẩy tôi đang sử dụng có thể dự đoán được đến mức nào?”

Tự động hóa loại bỏ ma sát. Chi phí cố định loại bỏ một lớp bất định. Kỳ đáo hạn được xác định buộc chiến lược phải có một điểm kết thúc.

Tất nhiên, không có điều nào trong số đó khiến đòn bẩy trở nên không rủi ro. Tài sản thế chấp vẫn quan trọng, và kỳ hạn vẫn phải được quản lý.

Nhưng tôi nghĩ đây là chỗ @TermMax trở nên thú vị: nó không chỉ là làm cho việc thực thi đòn bẩy dễ hơn — mà còn cố gắng làm cho các vị thế dùng đòn bẩy trở nên có cấu trúc hơn.

Nếu người dùng có thể chọn giữa đòn bẩy linh hoạt, liên tục thay đổi và một vị thế có chi phí và thời hạn kết thúc đã biết, thì mô hình nào sẽ giành ưu thế khi thị trường biến động?

Đó là phần ở TermMax mà tôi đang theo dõi.
#TermMax #termmax
#dusk $DUSK @Dusk_Foundation Trước đây tôi nghĩ rằng nếu một blockchain có thể xử lý giao dịch tài chính nhanh chóng thì hầu hết các phần việc khó khăn đã được giải quyết. Sau đó tôi bắt đầu xem xét điều gì xảy ra khi mạng phải hỗ trợ các thị trường tài chính thực sự. Giao dịch nhanh là hữu ích, nhưng nó không có ý nghĩa nhiều nếu mọi ứng dụng đều phải xây dựng lại cùng một logic xung quanh nó. Điều khiến tôi chú ý về Dusk là trọng tâm của họ vào việc làm cho chính mạng lưới phù hợp hơn với các ứng dụng tài chính, thay vì coi tài chính đã được quản lý như một thứ có thể chỉ cần đặt chồng lên một hạ tầng crypto thông thường. Sự khác biệt đó có vẻ rất quan trọng. Một trái phiếu, ETF hay tài sản được quản lý khác không chỉ cần một nơi để giao dịch. Mạng lưới phải xử lý các quy tắc, sự thay đổi quyền sở hữu, việc thanh toán và quyền riêng tư liên quan đến nó. Vậy có lẽ thử thách thực sự không phải là làm cho blockchain nhanh hơn. Có lẽ vấn đề là làm cho lớp hạ tầng nền tảng hiểu những gì mà một giao dịch tài chính thực sự đòi hỏi. Tôi vẫn đang tự hỏi liệu phần lớn độ phức tạp đó có thể được xử lý một cách thực tế ở cấp độ giao thức khi thị trường trở nên lớn hơn nhiều hay không. Bạn thà có một blockchain nhanh hơn, hay một blockchain được thiết kế xoay quanh những vấn đề mà các thị trường tài chính thực sự gặp phải?
#dusk $DUSK @Dusk

Trước đây tôi nghĩ rằng nếu một blockchain có thể xử lý giao dịch tài chính nhanh chóng thì hầu hết các phần việc khó khăn đã được giải quyết.

Sau đó tôi bắt đầu xem xét điều gì xảy ra khi mạng phải hỗ trợ các thị trường tài chính thực sự.

Giao dịch nhanh là hữu ích, nhưng nó không có ý nghĩa nhiều nếu mọi ứng dụng đều phải xây dựng lại cùng một logic xung quanh nó.

Điều khiến tôi chú ý về Dusk là trọng tâm của họ vào việc làm cho chính mạng lưới phù hợp hơn với các ứng dụng tài chính, thay vì coi tài chính đã được quản lý như một thứ có thể chỉ cần đặt chồng lên một hạ tầng crypto thông thường.

Sự khác biệt đó có vẻ rất quan trọng.

Một trái phiếu, ETF hay tài sản được quản lý khác không chỉ cần một nơi để giao dịch. Mạng lưới phải xử lý các quy tắc, sự thay đổi quyền sở hữu, việc thanh toán và quyền riêng tư liên quan đến nó.

Vậy có lẽ thử thách thực sự không phải là làm cho blockchain nhanh hơn.

Có lẽ vấn đề là làm cho lớp hạ tầng nền tảng hiểu những gì mà một giao dịch tài chính thực sự đòi hỏi.

Tôi vẫn đang tự hỏi liệu phần lớn độ phức tạp đó có thể được xử lý một cách thực tế ở cấp độ giao thức khi thị trường trở nên lớn hơn nhiều hay không.

Bạn thà có một blockchain nhanh hơn, hay một blockchain được thiết kế xoay quanh những vấn đề mà các thị trường tài chính thực sự gặp phải?
#termmax @termmax Điều gì xảy ra nếu vấn đề lớn nhất của DeFi không phải là lợi suất—mà là việc không biết các con số sẽ trông như thế nào vào ngày mai? Suy nghĩ đó khiến tôi nhìn kỹ hơn về @termmax . Điều tôi thấy thú vị là ý tưởng về các thị trường kỳ hạn cố định, nơi người đi vay và người cho vay có thể thỏa thuận trước về lãi suất và thời hạn. Điều này thay đổi cách tôi suy nghĩ về DeFi. Thay vì liên tục phản ứng trước những biến động của lãi suất, bạn có thể xây dựng một kế hoạch dựa trên chi phí và mốc thời gian được xác định. Và điều đó quan trọng không chỉ trong việc vay. Những thị trường dễ dự đoán hơn có thể giúp việc định hình chiến lược, quản lý vốn và suy nghĩ xa hơn trở nên dễ dàng hơn. Tôi vẫn đang tìm hiểu TermMax, nhưng đây là một trong những ý tưởng thật sự gây ấn tượng với tôi. Liệu các thị trường lãi suất cố định rồi có thể trở thành một phần tiêu chuẩn của DeFi không? #TermMax
#termmax @TermMax

Điều gì xảy ra nếu vấn đề lớn nhất của DeFi không phải là lợi suất—mà là việc không biết các con số sẽ trông như thế nào vào ngày mai?

Suy nghĩ đó khiến tôi nhìn kỹ hơn về @TermMax .

Điều tôi thấy thú vị là ý tưởng về các thị trường kỳ hạn cố định, nơi người đi vay và người cho vay có thể thỏa thuận trước về lãi suất và thời hạn.

Điều này thay đổi cách tôi suy nghĩ về DeFi.

Thay vì liên tục phản ứng trước những biến động của lãi suất, bạn có thể xây dựng một kế hoạch dựa trên chi phí và mốc thời gian được xác định.

Và điều đó quan trọng không chỉ trong việc vay.

Những thị trường dễ dự đoán hơn có thể giúp việc định hình chiến lược, quản lý vốn và suy nghĩ xa hơn trở nên dễ dàng hơn.

Tôi vẫn đang tìm hiểu TermMax, nhưng đây là một trong những ý tưởng thật sự gây ấn tượng với tôi.

Liệu các thị trường lãi suất cố định rồi có thể trở thành một phần tiêu chuẩn của DeFi không?

#TermMax
#termmax @termmax Càng nghiên cứu DeFi, tôi càng nhận ra rằng lãi suất biến động có thể âm thầm thay đổi cả một chiến lược. Bạn có thể có đúng tài sản thế chấp, đúng điểm vào và thậm chí đúng luận điểm — nhưng nếu chi phí vay cứ tiếp tục biến động, thì các con số bên dưới bạn có thể sẽ thay đổi. Đó là lý do khiến @termmax trở nên đặc biệt đối với tôi. Thay vì coi việc đi vay và cho vay như một thứ cần liên tục được định giá lại, TermMax đang xây dựng các thị trường lãi suất cố định, thời hạn cố định. Nghe có vẻ chỉ là một thay đổi nhỏ. Nhưng tôi nghĩ rằng việc xác định rõ chi phí và kỳ hạn cho vốn có thể giúp tài chính onchain dễ lên kế hoạch hơn rất nhiều. Câu hỏi lớn hơn đối với tôi là liệu các thị trường lãi suất cố định có thể trở thành một “khối xây dựng” bình thường của DeFi, thay vì chỉ là một mảng ngách. #TermMax
#termmax @TermMax

Càng nghiên cứu DeFi, tôi càng nhận ra rằng lãi suất biến động có thể âm thầm thay đổi cả một chiến lược.

Bạn có thể có đúng tài sản thế chấp, đúng điểm vào và thậm chí đúng luận điểm — nhưng nếu chi phí vay cứ tiếp tục biến động, thì các con số bên dưới bạn có thể sẽ thay đổi.

Đó là lý do khiến @TermMax trở nên đặc biệt đối với tôi.

Thay vì coi việc đi vay và cho vay như một thứ cần liên tục được định giá lại, TermMax đang xây dựng các thị trường lãi suất cố định, thời hạn cố định.

Nghe có vẻ chỉ là một thay đổi nhỏ.

Nhưng tôi nghĩ rằng việc xác định rõ chi phí và kỳ hạn cho vốn có thể giúp tài chính onchain dễ lên kế hoạch hơn rất nhiều.

Câu hỏi lớn hơn đối với tôi là liệu các thị trường lãi suất cố định có thể trở thành một “khối xây dựng” bình thường của DeFi, thay vì chỉ là một mảng ngách.

#TermMax
·
--
Tăng giá
#dusk $DUSK @Dusk_Foundation Trước đây, tôi cứ nghĩ phần khó nhất khi đưa tài sản được quản lý lên chuỗi sẽ là làm sao đưa tài sản đó lên được chuỗi ngay từ đầu. Càng tìm hiểu về Dusk, tôi càng tự hỏi liệu vấn đề khó khăn hơn có thể nằm ở giai đoạn sau khi phát hành hay không. Một trái phiếu không chỉ “nằm đó” một khi đã được token hóa. Quyền sở hữu có thể thay đổi, các hạn chế có thể được áp dụng, dịch vụ vẫn tiếp tục diễn ra, và cuối cùng vẫn cần có một bản ghi chính xác về thực tế đã xảy ra gì. Điều đó khiến cách tiếp cận của Dusk có cảm giác khác biệt đối với tôi. Phần thú vị không chỉ là tạo ra một phiên bản kỹ thuật số của một tài sản. Mấu chốt là liệu blockchain có thể giữ được bản sắc (identity), các quy tắc và vòng đời của tài sản được gắn kết với nhau khi nó di chuyển qua thị trường hay không. Nghe có vẻ hiển nhiên cho đến khi bạn nghĩ về việc có bao nhiêu hệ thống truyền thống chạm vào một tài sản tài chính. Tôi vẫn chưa thực sự tin rằng việc đưa mọi thứ lên chuỗi một cách tự động sẽ làm cho tài chính trở nên đơn giản hơn. Nhưng nếu tài sản có thể mang theo các quy tắc của nó thay vì phải dựa vào các hệ thống tách biệt để liên tục kiểm tra chúng, thì đó có thể là một thay đổi lớn hơn nhiều so với bản thân việc token hóa. Bước đột phá thực sự trong hạ tầng RWA nằm ở việc tạo ra các token — hay ở việc làm cho toàn bộ vòng đời của một tài sản có thể lập trình được?
#dusk $DUSK @Dusk

Trước đây, tôi cứ nghĩ phần khó nhất khi đưa tài sản được quản lý lên chuỗi sẽ là làm sao đưa tài sản đó lên được chuỗi ngay từ đầu.

Càng tìm hiểu về Dusk, tôi càng tự hỏi liệu vấn đề khó khăn hơn có thể nằm ở giai đoạn sau khi phát hành hay không.

Một trái phiếu không chỉ “nằm đó” một khi đã được token hóa. Quyền sở hữu có thể thay đổi, các hạn chế có thể được áp dụng, dịch vụ vẫn tiếp tục diễn ra, và cuối cùng vẫn cần có một bản ghi chính xác về thực tế đã xảy ra gì.

Điều đó khiến cách tiếp cận của Dusk có cảm giác khác biệt đối với tôi.

Phần thú vị không chỉ là tạo ra một phiên bản kỹ thuật số của một tài sản. Mấu chốt là liệu blockchain có thể giữ được bản sắc (identity), các quy tắc và vòng đời của tài sản được gắn kết với nhau khi nó di chuyển qua thị trường hay không.

Nghe có vẻ hiển nhiên cho đến khi bạn nghĩ về việc có bao nhiêu hệ thống truyền thống chạm vào một tài sản tài chính.

Tôi vẫn chưa thực sự tin rằng việc đưa mọi thứ lên chuỗi một cách tự động sẽ làm cho tài chính trở nên đơn giản hơn.

Nhưng nếu tài sản có thể mang theo các quy tắc của nó thay vì phải dựa vào các hệ thống tách biệt để liên tục kiểm tra chúng, thì đó có thể là một thay đổi lớn hơn nhiều so với bản thân việc token hóa.

Bước đột phá thực sự trong hạ tầng RWA nằm ở việc tạo ra các token — hay ở việc làm cho toàn bộ vòng đời của một tài sản có thể lập trình được?
·
--
Tăng giá
#dusk $DUSK @Dusk_Foundation Trước đây, tôi từng nghĩ rằng tuân thủ trên một blockchain chủ yếu là việc kiểm tra danh tính của ai đó trước khi họ được phép sử dụng một tài sản. Nhưng khi tìm hiểu sâu hơn về Dusk, tôi nhận ra phần khó hơn có thể thực sự xảy ra sau bước kiểm tra đó. Điều thu hút tôi là ý tưởng rằng một giao dịch chuyển tiền đã được quản lý có thể được kiểm tra trước khi được gửi — bao gồm việc giao dịch có được phép hay không, và nếu không thì vì sao nó sẽ thất bại. 🧐 Nghe có vẻ chỉ là một chi tiết nhỏ, nhưng nó thay đổi cách tôi nghĩ về việc đưa tài sản tài chính lên chuỗi. Một blockchain không chỉ cần biết bạn là ai. Nó có thể cần hiểu liệu giao dịch chuyển tiền cụ thể này có được phép theo các quy tắc đính kèm với tài sản hay không. Tính đủ điều kiện, các hạn chế chuyển nhượng, hạn mức và các điều kiện khác có thể trở thành một phần của quy trình thay vì là thứ mà bộ phận hậu kiểm phải kiểm tra sau khi giao dịch đã xảy ra. 🔍 Tôi thực sự thích ý tưởng này hơn việc chỉ nói “blockchain làm tài chính nhanh hơn.” Vì tốc độ không giúp ích nhiều nếu giao dịch vẫn phải dừng lại ở đâu đó để ai đó quyết định xem liệu nó có được phép hay không. Nhưng đồng thời, tôi cũng tự hỏi liệu các quy tắc này sẽ trở nên phức tạp đến mức nào khi các sản phẩm tài chính thực tế có hàng chục điều kiện và ngoại lệ. Việc đưa tuân thủ trực tiếp vào quy trình giao dịch có thực sự đơn giản hóa thị trường tài chính hay chúng ta chỉ đang chuyển độ phức tạp từ bộ phận hậu kiểm sang blockchain? @Dusk_Foundation #dusk $DUSK
#dusk $DUSK @Dusk

Trước đây, tôi từng nghĩ rằng tuân thủ trên một blockchain chủ yếu là việc kiểm tra danh tính của ai đó trước khi họ được phép sử dụng một tài sản.

Nhưng khi tìm hiểu sâu hơn về Dusk, tôi nhận ra phần khó hơn có thể thực sự xảy ra sau bước kiểm tra đó.

Điều thu hút tôi là ý tưởng rằng một giao dịch chuyển tiền đã được quản lý có thể được kiểm tra trước khi được gửi — bao gồm việc giao dịch có được phép hay không, và nếu không thì vì sao nó sẽ thất bại. 🧐

Nghe có vẻ chỉ là một chi tiết nhỏ, nhưng nó thay đổi cách tôi nghĩ về việc đưa tài sản tài chính lên chuỗi.

Một blockchain không chỉ cần biết bạn là ai.

Nó có thể cần hiểu liệu giao dịch chuyển tiền cụ thể này có được phép theo các quy tắc đính kèm với tài sản hay không.

Tính đủ điều kiện, các hạn chế chuyển nhượng, hạn mức và các điều kiện khác có thể trở thành một phần của quy trình thay vì là thứ mà bộ phận hậu kiểm phải kiểm tra sau khi giao dịch đã xảy ra. 🔍

Tôi thực sự thích ý tưởng này hơn việc chỉ nói “blockchain làm tài chính nhanh hơn.”

Vì tốc độ không giúp ích nhiều nếu giao dịch vẫn phải dừng lại ở đâu đó để ai đó quyết định xem liệu nó có được phép hay không.

Nhưng đồng thời, tôi cũng tự hỏi liệu các quy tắc này sẽ trở nên phức tạp đến mức nào khi các sản phẩm tài chính thực tế có hàng chục điều kiện và ngoại lệ.

Việc đưa tuân thủ trực tiếp vào quy trình giao dịch có thực sự đơn giản hóa thị trường tài chính hay chúng ta chỉ đang chuyển độ phức tạp từ bộ phận hậu kiểm sang blockchain?

@Dusk #dusk $DUSK
Điều tôi cứ mãi quay lại với Dusk là: quyền riêng tư dường như không chỉ đơn giản là che giấu mọi thứ. 🧐 Phần thú vị nằm ở ý tưởng giữ riêng các chi tiết giao dịch nhạy cảm, trong khi vẫn cho phép mạng chứng minh rằng các quy tắc đã được tuân thủ. Đây là một cách tiếp cận rất khác so với lựa chọn thông thường “blockchain công khai vs hệ thống hoàn toàn riêng tư”, và nó khiến tôi tự hỏi liệu quyền riêng tư có trở nên hữu ích hơn khi các tổ chức không phải đánh đổi việc tuân thủ để có được nó không. 🔍 Về mặt lý thuyết, tôi thích ý tưởng này, nhưng còn một câu hỏi lớn hơn: liệu quyền riêng tư chọn lọc thực sự làm cho blockchain dễ được các tổ chức áp dụng hơn, hay nó chỉ tạo thêm một lớp phức tạp mà họ phải hiểu? #dusk $DUSK @Dusk_Foundation
Điều tôi cứ mãi quay lại với Dusk là: quyền riêng tư dường như không chỉ đơn giản là che giấu mọi thứ. 🧐

Phần thú vị nằm ở ý tưởng giữ riêng các chi tiết giao dịch nhạy cảm, trong khi vẫn cho phép mạng chứng minh rằng các quy tắc đã được tuân thủ. Đây là một cách tiếp cận rất khác so với lựa chọn thông thường “blockchain công khai vs hệ thống hoàn toàn riêng tư”, và nó khiến tôi tự hỏi liệu quyền riêng tư có trở nên hữu ích hơn khi các tổ chức không phải đánh đổi việc tuân thủ để có được nó không. 🔍

Về mặt lý thuyết, tôi thích ý tưởng này, nhưng còn một câu hỏi lớn hơn: liệu quyền riêng tư chọn lọc thực sự làm cho blockchain dễ được các tổ chức áp dụng hơn, hay nó chỉ tạo thêm một lớp phức tạp mà họ phải hiểu?

#dusk $DUSK @Dusk
@Dusk_Foundation $DUSK Hôm nay tôi quay lại kiến trúc giao dịch của Dusk vì muốn hiểu một điều mà tôi đã bỏ sót. Ban đầu, tôi cho rằng một chuỗi tập trung vào quyền riêng tư hẳn sẽ có gần như một “cách riêng” để chuyển tài sản. Nhưng Dusk dường như không chọn như vậy. Nó có Moonlight cho các giao dịch chuyển công khai, theo kiểu tài khoản — và Phoenix cho các giao dịch chuyển được che chắn, dựa trên UTXO. Điều thu hút tôi là những cách này không phải là hai blockchain tách biệt. Chúng được quyết toán trên cùng lớp DuskDS. Điều đó thay đổi cách tôi nghĩ về Dusk. Phần thú vị không chỉ là: “Giao dịch có thể riêng tư không?” Mà là: “Giao dịch có thực sự cần phải riêng tư ngay từ đầu không?” Một luồng quản trị quỹ hoặc báo cáo có thể cần các số dư và giao dịch được nhìn thấy. Một quy trình tài chính khác có thể lại cần giá trị được che chắn kèm bằng chứng không kiến thức. Và cả hai có thể cùng tồn tại trong kiến trúc quyết toán đó. Chúng không phải là cùng một yêu cầu. Ban đầu tôi nghĩ quyền riêng tư là tính năng chính mà Dusk đang bổ sung cho tài chính blockchain. Giờ tôi bắt đầu nghĩ ý tưởng thú vị hơn chính là sự lựa chọn. Quyền riêng tư khi thông tin nhạy cảm không nên được công khai. Minh bạch khi khả năng hiển thị thực sự hữu ích. Câu hỏi thực sự có thể là: “Liệu một blockchain tài chính có nên ép mọi giao dịch vào cùng một mô hình hiển thị — hay ứng dụng nên quyết định thế giới sẽ được thấy gì?” #dusk $DUSK
@Dusk $DUSK
Hôm nay tôi quay lại kiến trúc giao dịch của Dusk vì muốn hiểu một điều mà tôi đã bỏ sót.
Ban đầu, tôi cho rằng một chuỗi tập trung vào quyền riêng tư hẳn sẽ có gần như một “cách riêng” để chuyển tài sản.
Nhưng Dusk dường như không chọn như vậy.
Nó có Moonlight cho các giao dịch chuyển công khai, theo kiểu tài khoản — và Phoenix cho các giao dịch chuyển được che chắn, dựa trên UTXO.
Điều thu hút tôi là những cách này không phải là hai blockchain tách biệt.
Chúng được quyết toán trên cùng lớp DuskDS.
Điều đó thay đổi cách tôi nghĩ về Dusk.
Phần thú vị không chỉ là:
“Giao dịch có thể riêng tư không?”
Mà là:
“Giao dịch có thực sự cần phải riêng tư ngay từ đầu không?”
Một luồng quản trị quỹ hoặc báo cáo có thể cần các số dư và giao dịch được nhìn thấy.
Một quy trình tài chính khác có thể lại cần giá trị được che chắn kèm bằng chứng không kiến thức.
Và cả hai có thể cùng tồn tại trong kiến trúc quyết toán đó.
Chúng không phải là cùng một yêu cầu.
Ban đầu tôi nghĩ quyền riêng tư là tính năng chính mà Dusk đang bổ sung cho tài chính blockchain.
Giờ tôi bắt đầu nghĩ ý tưởng thú vị hơn chính là sự lựa chọn.
Quyền riêng tư khi thông tin nhạy cảm không nên được công khai.
Minh bạch khi khả năng hiển thị thực sự hữu ích.
Câu hỏi thực sự có thể là:
“Liệu một blockchain tài chính có nên ép mọi giao dịch vào cùng một mô hình hiển thị — hay ứng dụng nên quyết định thế giới sẽ được thấy gì?”

#dusk $DUSK
·
--
Tăng giá
@Dusk_Foundation $DUSK Trước đây tôi từng nghĩ rằng quyền riêng tư trên blockchain có nghĩa là ẩn giao dịch và dừng lại ở đó. Sau đó tôi bắt đầu tìm hiểu cách Dusk xử lý vấn đề này. Điểm thú vị không chỉ đơn giản là Phoenix có thể ẩn người gửi, người nhận và số tiền. Mà là quyền riêng tư không nhất thiết có nghĩa là không ai có thể bao giờ nhìn thấy những gì đang xảy ra. Một tài khoản được che chắn (shielded) có thể giữ thông tin chi tiết của giao dịch ở chế độ riêng tư, trong khi một khóa xem (view key) có thể cấp cho người khác khả năng truy cập có kiểm soát vào những thông tin mà họ được ủy quyền để xem. Sự khác biệt đó đã gây ấn tượng với tôi. Bởi vì trước đây tôi nghĩ về quyền riêng tư như: “Ai có thể xem giao dịch?” Nhưng Dusk dường như đang đặt một câu hỏi hơi khác: “Ai nên được phép xem, và họ nên được phép xem đến mức nào?” Hai câu đó không phải là một. Và tôi nghĩ đây là chỗ mà quyền riêng tư trên blockchain trở nên thú vị hơn nhiều so với việc chỉ làm mọi thứ vô hình. Nếu các ứng dụng tài chính cần quyền riêng tư và khả năng tiết lộ chọn lọc, thì quyền riêng tư có nghĩa là phải ẩn tất cả — hay là quyết định chính xác những gì được tiết lộ và tiết lộ cho ai? #dusk $DUSK
@Dusk $DUSK

Trước đây tôi từng nghĩ rằng quyền riêng tư trên blockchain có nghĩa là ẩn giao dịch và dừng lại ở đó.

Sau đó tôi bắt đầu tìm hiểu cách Dusk xử lý vấn đề này.

Điểm thú vị không chỉ đơn giản là Phoenix có thể ẩn người gửi, người nhận và số tiền.

Mà là quyền riêng tư không nhất thiết có nghĩa là không ai có thể bao giờ nhìn thấy những gì đang xảy ra.

Một tài khoản được che chắn (shielded) có thể giữ thông tin chi tiết của giao dịch ở chế độ riêng tư, trong khi một khóa xem (view key) có thể cấp cho người khác khả năng truy cập có kiểm soát vào những thông tin mà họ được ủy quyền để xem.

Sự khác biệt đó đã gây ấn tượng với tôi.

Bởi vì trước đây tôi nghĩ về quyền riêng tư như:

“Ai có thể xem giao dịch?”

Nhưng Dusk dường như đang đặt một câu hỏi hơi khác:

“Ai nên được phép xem, và họ nên được phép xem đến mức nào?”

Hai câu đó không phải là một.

Và tôi nghĩ đây là chỗ mà quyền riêng tư trên blockchain trở nên thú vị hơn nhiều so với việc chỉ làm mọi thứ vô hình.

Nếu các ứng dụng tài chính cần quyền riêng tư và khả năng tiết lộ chọn lọc, thì quyền riêng tư có nghĩa là phải ẩn tất cả — hay là quyết định chính xác những gì được tiết lộ và tiết lộ cho ai?

#dusk $DUSK
@babylonlabs_io Tôi không thể ngừng suy nghĩ về một phần trong bản demo Aave mới nhất của Babylon. BTC của bạn vẫn nằm trên Bitcoin. Nhưng Aave vẫn có thể coi vị thế được BTC hậu thuẫn đó như tài sản thế chấp. Nghe có vẻ đơn giản cho đến khi bạn hỏi Aave thực sự đang nhìn thấy gì. Vì bản thân Bitcoin không bao giờ trở thành một token Ethereum thông thường. BTC vẫn bị khóa bên trong vault phía Bitcoin. Vì vậy, tôi đi tìm xem điều gì kết nối vault đó với phía cấp tín dụng (lending). Đó là lúc tôi tìm thấy vaultBTC. Và đây là phần mà trước đây tôi chưa hiểu hết. Nó trông giống như một ERC-20 đối với các hợp đồng được ủy quyền ở phía Aave, nhưng nó không phải là một token bình thường mà bạn có thể gửi đi. Bạn không thể chuyển nó sang một ví khác. Không có thị trường thứ cấp cho nó. Nó không nằm trong ví của bạn. Nó tồn tại như một biểu diễn kế toán nội bộ của lượng BTC thực sự đang bị khóa trong vault. 1 vaultBTC đại diện cho 1 BTC. Điều đó khiến toàn bộ thiết kế “khớp” với tôi theo cách khác. Babylon không đưa BTC lên Ethereum rồi yêu cầu Aave giả vờ đó là Bitcoin. Babylon giữ BTC ở nơi BTC thuộc về, đồng thời tạo ra một biểu diễn bị hạn chế mà hệ thống cho vay có thể hiểu. Vì vậy, phần thú vị không thực sự là: “BTC chuyển sang Aave bằng cách nào?” Nó không chuyển. Câu hỏi đáng chú ý hơn là: “Làm sao Aave nhận ra tài sản thế chấp là BTC mà bản thân BTC không trở thành một tài sản Ethereum?” Điều này giống như bài toán khó hơn mà Babylon thực sự đang giải. Và giờ tôi đang tự hỏi: Nếu Bitcoin vẫn ở trên Bitcoin, nhưng một chuỗi khác vẫn có thể nhận ra giá trị tài sản thế chấp của nó, thì tài sản thế chấp thực sự nằm ở đâu — trong vault của Bitcoin, trong giao thức lending, hay trong liên kết giữa chúng? @babylonlabs_io #baby $BABY
@BabylonLabs_io

Tôi không thể ngừng suy nghĩ về một phần trong bản demo Aave mới nhất của Babylon.
BTC của bạn vẫn nằm trên Bitcoin.
Nhưng Aave vẫn có thể coi vị thế được BTC hậu thuẫn đó như tài sản thế chấp.
Nghe có vẻ đơn giản cho đến khi bạn hỏi Aave thực sự đang nhìn thấy gì.
Vì bản thân Bitcoin không bao giờ trở thành một token Ethereum thông thường.
BTC vẫn bị khóa bên trong vault phía Bitcoin.
Vì vậy, tôi đi tìm xem điều gì kết nối vault đó với phía cấp tín dụng (lending).
Đó là lúc tôi tìm thấy vaultBTC.
Và đây là phần mà trước đây tôi chưa hiểu hết.
Nó trông giống như một ERC-20 đối với các hợp đồng được ủy quyền ở phía Aave, nhưng nó không phải là một token bình thường mà bạn có thể gửi đi.
Bạn không thể chuyển nó sang một ví khác.
Không có thị trường thứ cấp cho nó.
Nó không nằm trong ví của bạn.
Nó tồn tại như một biểu diễn kế toán nội bộ của lượng BTC thực sự đang bị khóa trong vault. 1 vaultBTC đại diện cho 1 BTC.
Điều đó khiến toàn bộ thiết kế “khớp” với tôi theo cách khác.
Babylon không đưa BTC lên Ethereum rồi yêu cầu Aave giả vờ đó là Bitcoin.
Babylon giữ BTC ở nơi BTC thuộc về, đồng thời tạo ra một biểu diễn bị hạn chế mà hệ thống cho vay có thể hiểu.
Vì vậy, phần thú vị không thực sự là:
“BTC chuyển sang Aave bằng cách nào?”
Nó không chuyển.
Câu hỏi đáng chú ý hơn là:
“Làm sao Aave nhận ra tài sản thế chấp là BTC mà bản thân BTC không trở thành một tài sản Ethereum?”
Điều này giống như bài toán khó hơn mà Babylon thực sự đang giải.
Và giờ tôi đang tự hỏi:
Nếu Bitcoin vẫn ở trên Bitcoin, nhưng một chuỗi khác vẫn có thể nhận ra giá trị tài sản thế chấp của nó, thì tài sản thế chấp thực sự nằm ở đâu — trong vault của Bitcoin, trong giao thức lending, hay trong liên kết giữa chúng?

@BabylonLabs_io
#baby $BABY
·
--
Tăng giá
@babylonlabs_io Tôi cứ nghĩ cơ chế “slashing” của Babylon chủ yếu là để bắt một validator làm điều gì đó sai. Sau đó tôi bắt đầu xem xét thực tế là chuyện gì xảy ra khi một Finality Provider ký hai khối xung đột. Chính tại đó thiết kế trở nên thú vị hơn đối với tôi. Babylon sử dụng một thứ gọi là Chữ ký Một lần Có thể Trích xuất (Extractable One-Time Signature), hay EOTS. Ý tưởng cốt lõi nghe có vẻ gần như ngược lại lúc đầu. Một Finality Provider cam kết một dữ liệu ngẫu nhiên trước khi ký. Nếu sau đó họ dùng cùng dữ liệu ngẫu nhiên đó để ký hai khối khác nhau ở cùng một độ cao, hệ thống có thể trích xuất khóa riêng EOTS của họ. Vì vậy việc ký đôi không chỉ là bằng chứng rằng đã có điều gì đó sai xảy ra. Chính sai lầm đó có thể lộ ra khóa bí mật khiến hậu quả trở nên có thể. Điều đó khiến tôi phải suy nghĩ lại ý nghĩa của “slashing” ở đây. Trước đó tôi hình dung nó như là: Ai đó phát hiện hành vi xấu → ai đó quyết định trừng phạt nó. Nhưng càng tìm hiểu về EOTS, tôi càng thấy một mối quan hệ khác. Các quy tắc ký được thiết kế sao cho một hành vi xung đột nào đó tạo ra một hệ quả mật mã. Và đó là phần mà tôi chưa thực sự đánh giá cao. Câu hỏi thú vị không chỉ là: “Babylon phát hiện một Finality Provider không trung thực như thế nào?” Mà là: “Khi nhà cung cấp đó chứng minh rằng họ đã vi phạm các quy tắc, điều gì xảy ra với khóa mật mã?” Đối với tôi, đây mới là một thiết kế thú vị hơn nhiều. Bởi vì Babylon không chỉ cố gắng nói với các validator rằng “đừng ký đôi”. Nó đang tạo ra một hệ thống trong đó hành động ký đôi có thể trở thành một phần của cơ chế giúp việc slashing trở nên khả thi. Và bây giờ tôi tự hỏi: Cơ chế slashing mạnh nhất là cơ chế trừng phạt hành vi xấu—hay là cơ chế mà chính hành vi xấu đó tạo ra bằng chứng cần thiết để trừng phạt nó? @babylonlabs_io #baby $BABY
@BabylonLabs_io

Tôi cứ nghĩ cơ chế “slashing” của Babylon chủ yếu là để bắt một validator làm điều gì đó sai.
Sau đó tôi bắt đầu xem xét thực tế là chuyện gì xảy ra khi một Finality Provider ký hai khối xung đột.
Chính tại đó thiết kế trở nên thú vị hơn đối với tôi.
Babylon sử dụng một thứ gọi là Chữ ký Một lần Có thể Trích xuất (Extractable One-Time Signature), hay EOTS.
Ý tưởng cốt lõi nghe có vẻ gần như ngược lại lúc đầu.
Một Finality Provider cam kết một dữ liệu ngẫu nhiên trước khi ký.
Nếu sau đó họ dùng cùng dữ liệu ngẫu nhiên đó để ký hai khối khác nhau ở cùng một độ cao, hệ thống có thể trích xuất khóa riêng EOTS của họ.
Vì vậy việc ký đôi không chỉ là bằng chứng rằng đã có điều gì đó sai xảy ra.
Chính sai lầm đó có thể lộ ra khóa bí mật khiến hậu quả trở nên có thể.
Điều đó khiến tôi phải suy nghĩ lại ý nghĩa của “slashing” ở đây.
Trước đó tôi hình dung nó như là:
Ai đó phát hiện hành vi xấu → ai đó quyết định trừng phạt nó.
Nhưng càng tìm hiểu về EOTS, tôi càng thấy một mối quan hệ khác.
Các quy tắc ký được thiết kế sao cho một hành vi xung đột nào đó tạo ra một hệ quả mật mã.
Và đó là phần mà tôi chưa thực sự đánh giá cao.
Câu hỏi thú vị không chỉ là:
“Babylon phát hiện một Finality Provider không trung thực như thế nào?”
Mà là:
“Khi nhà cung cấp đó chứng minh rằng họ đã vi phạm các quy tắc, điều gì xảy ra với khóa mật mã?”
Đối với tôi, đây mới là một thiết kế thú vị hơn nhiều.
Bởi vì Babylon không chỉ cố gắng nói với các validator rằng “đừng ký đôi”.
Nó đang tạo ra một hệ thống trong đó hành động ký đôi có thể trở thành một phần của cơ chế giúp việc slashing trở nên khả thi.
Và bây giờ tôi tự hỏi:
Cơ chế slashing mạnh nhất là cơ chế trừng phạt hành vi xấu—hay là cơ chế mà chính hành vi xấu đó tạo ra bằng chứng cần thiết để trừng phạt nó?

@BabylonLabs_io
#baby $BABY
·
--
Tăng giá
@babylonlabs_io Hôm nay tôi đang lục tìm tài liệu về Kho Bitcoin không cần niềm tin của Babylon, và có một chi tiết làm tôi dừng lại. Một kho Bitcoin không thể bị tịch thu một phần. Lúc đầu, điều đó nghe như một giới hạn. Kho BTC là một UTXO Bitcoin duy nhất. Nếu giao thức cần thanh lý nó, thì nó không thể chỉ lấy 30% của một kho UTXO đó. Nó phải lấy toàn bộ. Nhưng rồi tôi nhận ra Babylon đã xử lý giới hạn đó như thế nào. Thay vì xem toàn bộ BTC trong một vị thế như một “bể” lớn, nó có thể chia vị thế thành các kho tách biệt. Một kho có thể được đặt trước làm kho hi sinh. Kho còn lại có thể nằm phía sau như kho được bảo vệ. Và đột nhiên thiết kế trở nên hợp lý hơn rất nhiều. Nếu xảy ra thanh lý, Babylon không cần phải phá hủy toàn bộ vị thế. Nó có thể đi lần lượt qua các kho và lấy các kho nguyên vẹn tối thiểu cần thiết để khôi phục sức khỏe của vị thế. Vì vậy, câu hỏi thú vị không chỉ còn là: “Bitcoin có thể được dùng làm tài sản thế chấp không?” Mà là: “Khi tài sản thế chấp trở nên không lành mạnh, thì Bitcoin nào sẽ bị phơi ra?” Sự khác biệt này rất dễ bị bỏ qua. Ban đầu tôi nghĩ phần khó của việc cho vay BTC bản địa là làm sao giữ cho Bitcoin vẫn tự lưu ký trong khi lại có thể dùng ở nơi khác. Nhưng vấn đề thanh lý còn thú vị hơn gần như như thế. Tài sản thế chấp kiểu Ethereum có thể được chia nhỏ. Còn các UTXO Bitcoin thì không. Vì vậy Babylon không chỉ đang cố đưa BTC vào DeFi. Nó đang thiết kế để phù hợp với một quy tắc mà chính Bitcoin từ chối thỏa hiệp. Và giờ tôi tự hỏi: Nếu BTC của bạn phải được xem như những “mảnh” nguyên vẹn, bạn sẽ muốn một kho bảo vệ tất cả—hay cố tình chọn kho nào sẽ chịu đòn trước? @babylonlabs_io #baby $BABY
@BabylonLabs_io

Hôm nay tôi đang lục tìm tài liệu về Kho Bitcoin không cần niềm tin của Babylon, và có một chi tiết làm tôi dừng lại.
Một kho Bitcoin không thể bị tịch thu một phần.
Lúc đầu, điều đó nghe như một giới hạn.
Kho BTC là một UTXO Bitcoin duy nhất. Nếu giao thức cần thanh lý nó, thì nó không thể chỉ lấy 30% của một kho UTXO đó.
Nó phải lấy toàn bộ.
Nhưng rồi tôi nhận ra Babylon đã xử lý giới hạn đó như thế nào.
Thay vì xem toàn bộ BTC trong một vị thế như một “bể” lớn, nó có thể chia vị thế thành các kho tách biệt.
Một kho có thể được đặt trước làm kho hi sinh.
Kho còn lại có thể nằm phía sau như kho được bảo vệ.
Và đột nhiên thiết kế trở nên hợp lý hơn rất nhiều.
Nếu xảy ra thanh lý, Babylon không cần phải phá hủy toàn bộ vị thế.
Nó có thể đi lần lượt qua các kho và lấy các kho nguyên vẹn tối thiểu cần thiết để khôi phục sức khỏe của vị thế.
Vì vậy, câu hỏi thú vị không chỉ còn là:
“Bitcoin có thể được dùng làm tài sản thế chấp không?”
Mà là:
“Khi tài sản thế chấp trở nên không lành mạnh, thì Bitcoin nào sẽ bị phơi ra?”
Sự khác biệt này rất dễ bị bỏ qua.
Ban đầu tôi nghĩ phần khó của việc cho vay BTC bản địa là làm sao giữ cho Bitcoin vẫn tự lưu ký trong khi lại có thể dùng ở nơi khác.
Nhưng vấn đề thanh lý còn thú vị hơn gần như như thế.
Tài sản thế chấp kiểu Ethereum có thể được chia nhỏ.
Còn các UTXO Bitcoin thì không.
Vì vậy Babylon không chỉ đang cố đưa BTC vào DeFi.
Nó đang thiết kế để phù hợp với một quy tắc mà chính Bitcoin từ chối thỏa hiệp.
Và giờ tôi tự hỏi:
Nếu BTC của bạn phải được xem như những “mảnh” nguyên vẹn, bạn sẽ muốn một kho bảo vệ tất cả—hay cố tình chọn kho nào sẽ chịu đòn trước?

@BabylonLabs_io
#baby $BABY
·
--
Tăng giá
@BabylonLabs_io Tôi đã đọc tài liệu của Babylon vào nửa đêm, và tôi dừng lại ở một điều mà trước đó tôi đã từng nhìn thấy mà không thật sự để ý. Quá trình gỡ khóa (unbonding). Ban đầu, tôi nghĩ đó là điều khá đơn giản. Bạn đặt cược BTC của mình, và cuối cùng bạn muốn lấy lại. Nhưng càng tìm hiểu cách Babylon xử lý quy trình đó, tôi càng thấy nó không hề đơn giản. BTC không chỉ nằm đó chờ ai đó bấm một nút “mở khóa”. Các script đặt cược của Bitcoin xác định các “đường chi tiêu” khác nhau tùy theo điều đang diễn ra. Gỡ khóa bình thường có một đường. Cưỡng chế (slashing) có một đường khác. Và các điều kiện cho những đường đó lại là một phần của chính logic phía Bitcoin. Điều này khiến tôi phải suy nghĩ lại về ý nghĩa của “staking tự lưu ký (self-custodial staking)” ở đây. Tôi trước giờ vẫn nghĩ nhiều đến câu hỏi hiển nhiên: Ai đang nắm giữ BTC? Nhưng bên dưới còn có một câu hỏi khác: Những điều kiện nào quyết định khi nào BTC đó có thể di chuyển? Chúng không phải là cùng một câu hỏi. Càng đọc, tôi càng bắt đầu nhìn thiết kế staking của Babylon ít như việc chỉ “khóa Bitcoin” và nhiều hơn như là lập trình những tình huống để số Bitcoin bị khóa đó có thể rời đi. Và thật lòng mà nói, phần thú vị hơn chính là ở đó. Bởi khi BTC bị khóa để đảm bảo cho một mạng lưới khác, câu hỏi quan trọng không chỉ là ai sở hữu các khóa. Mà là: Ai là người định nghĩa các quy tắc quyết định điều gì sẽ xảy ra với BTC sau khi nó đã được khóa? @babylonlabs_io #baby $BABY
@BabylonLabs_io

Tôi đã đọc tài liệu của Babylon vào nửa đêm, và tôi dừng lại ở một điều mà trước đó tôi đã từng nhìn thấy mà không thật sự để ý.
Quá trình gỡ khóa (unbonding).
Ban đầu, tôi nghĩ đó là điều khá đơn giản.
Bạn đặt cược BTC của mình, và cuối cùng bạn muốn lấy lại.
Nhưng càng tìm hiểu cách Babylon xử lý quy trình đó, tôi càng thấy nó không hề đơn giản.
BTC không chỉ nằm đó chờ ai đó bấm một nút “mở khóa”.
Các script đặt cược của Bitcoin xác định các “đường chi tiêu” khác nhau tùy theo điều đang diễn ra.
Gỡ khóa bình thường có một đường.
Cưỡng chế (slashing) có một đường khác.
Và các điều kiện cho những đường đó lại là một phần của chính logic phía Bitcoin.
Điều này khiến tôi phải suy nghĩ lại về ý nghĩa của “staking tự lưu ký (self-custodial staking)” ở đây.
Tôi trước giờ vẫn nghĩ nhiều đến câu hỏi hiển nhiên:
Ai đang nắm giữ BTC?
Nhưng bên dưới còn có một câu hỏi khác:
Những điều kiện nào quyết định khi nào BTC đó có thể di chuyển?
Chúng không phải là cùng một câu hỏi.
Càng đọc, tôi càng bắt đầu nhìn thiết kế staking của Babylon ít như việc chỉ “khóa Bitcoin” và nhiều hơn như là lập trình những tình huống để số Bitcoin bị khóa đó có thể rời đi.
Và thật lòng mà nói, phần thú vị hơn chính là ở đó.
Bởi khi BTC bị khóa để đảm bảo cho một mạng lưới khác, câu hỏi quan trọng không chỉ là ai sở hữu các khóa.
Mà là:
Ai là người định nghĩa các quy tắc quyết định điều gì sẽ xảy ra với BTC sau khi nó đã được khóa?

@BabylonLabs_io
#baby $BABY
Đă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
Sơ đồ trang web
Tùy chọn Cookie
Điều khoản & Điều kiện