Binance Square
Toro_crypto
810 Bài đăng

Toro_crypto

Người nắm giữ BNB
Người nắm giữ BNB
Trader tần suất cao
{thời gian} năm
202 Đang theo dõi
382 Người theo dõi
447 Đã thích
Bài đăng
PINNED
·
--
#dusk $DUSK @Dusk_Foundation Hãy tưởng tượng một thị trường mà chi phí giao dịch—vốn có thể lên tới vài triệu bảng—là khoản chi phải được một ủy ban phê duyệt. Và sẽ không có gì khác biệt nếu đó là một nhóm khác được thông tin từ rất sớm trước khi quyết định được đưa ra. Nhưng còn một vấn đề khác. Làm sao điều này thỏa mãn “nếu bạn chọn ngẫu nhiên ai sẽ đưa ra quyết định, thì làm thế nào để đảm bảo rằng tất cả mọi người đều đồng ý về kết quả”. Chính đó là điểm độc nhất của toàn bộ vấn đề khi tôi đào sâu hơn vào Bằng chứng Ngắn gọn của Dusk (Dusk's Succinct Attestation). Giao thức sử dụng cơ chế bỏ phiếu. Trong mỗi vòng bỏ phiếu, các thành viên được chọn ngẫu nhiên cho các vai trò đề xuất (provisioners) sẽ đưa ra đề nghị đối với các ủy ban, bỏ phiếu và xác nhận (ratify) các khối. Khi một khối được xác nhận, mạng sẽ nhận được một loại “tính tất yếu” (finality) quyết định một cách xác định. Điều đó tạo ra một sự phân biệt thú vị: Áp lực chọn lọc không thể đoán trước không kéo theo một kết quả không thể đoán trước. Tuy nhiên, cái thứ nhất có thể khiến các biện pháp trở nên khó lường hơn. Còn cái thứ hai sẽ là một vấn đề. Một ví dụ về điều này là việc thanh toán bù trừ (clearing) cho một chứng khoán, nơi chứng khoán đã được token hóa một cách sâu rộng, bị phân mảnh và bị pha loãng. Nó hàm ý rằng mạng cuối cùng sẽ tạo ra một giá trị mà các bên tham gia có thể tin tưởng. Và, theo tôi, đó là điểm mà thiết kế đồng thuận trở nên hơn cả việc chỉ nói “Dusk sử dụng Proof-of-Stake (Bằng chứng Cổ phần)”. Câu hỏi không chỉ là: Nhưng, nếu vậy, ai là người cần được chọn. Mà còn là: Và do đó, nó theo như vậy là đã sẵn sàng để bước vào... vào đâu?? Trong động lực của một thị trường tài chính, sự khó lường như vậy có thể làm suy yếu các tham gia trong tương lai. Tuy nhiên, quyết định cuối cùng vẫn phải mang tính tất định đối với việc thanh toán (settlement). Vào thời điểm cơ sở hạ tầng của chính blockchain giao cắt với các tài sản thực của tài chính, “ngẫu nhiên” không còn đồng nghĩa với “không chắc chắn”. Thứ tôi muốn theo dõi theo thời gian sẽ là khả năng mở rộng. Cụ thể là khả năng mở rộng của mô hình khi mức độ hoạt động của các tổ chức tham gia rút ra cùng một kết quả đầu ra sẽ tăng lên.
#dusk $DUSK @Dusk
Hãy tưởng tượng một thị trường mà chi phí giao dịch—vốn có thể lên tới vài triệu bảng—là khoản chi phải được một ủy ban phê duyệt.

Và sẽ không có gì khác biệt nếu đó là một nhóm khác được thông tin từ rất sớm trước khi quyết định được đưa ra.

Nhưng còn một vấn đề khác.

Làm sao điều này thỏa mãn “nếu bạn chọn ngẫu nhiên ai sẽ đưa ra quyết định, thì làm thế nào để đảm bảo rằng tất cả mọi người đều đồng ý về kết quả”.

Chính đó là điểm độc nhất của toàn bộ vấn đề khi tôi đào sâu hơn vào Bằng chứng Ngắn gọn của Dusk (Dusk's Succinct Attestation).

Giao thức sử dụng cơ chế bỏ phiếu. Trong mỗi vòng bỏ phiếu, các thành viên được chọn ngẫu nhiên cho các vai trò đề xuất (provisioners) sẽ đưa ra đề nghị đối với các ủy ban, bỏ phiếu và xác nhận (ratify) các khối. Khi một khối được xác nhận, mạng sẽ nhận được một loại “tính tất yếu” (finality) quyết định một cách xác định.

Điều đó tạo ra một sự phân biệt thú vị:
Áp lực chọn lọc không thể đoán trước không kéo theo một kết quả không thể đoán trước.

Tuy nhiên, cái thứ nhất có thể khiến các biện pháp trở nên khó lường hơn.
Còn cái thứ hai sẽ là một vấn đề.

Một ví dụ về điều này là việc thanh toán bù trừ (clearing) cho một chứng khoán, nơi chứng khoán đã được token hóa một cách sâu rộng, bị phân mảnh và bị pha loãng.

Nó hàm ý rằng mạng cuối cùng sẽ tạo ra một giá trị mà các bên tham gia có thể tin tưởng.

Và, theo tôi, đó là điểm mà thiết kế đồng thuận trở nên hơn cả việc chỉ nói “Dusk sử dụng Proof-of-Stake (Bằng chứng Cổ phần)”.

Câu hỏi không chỉ là:
Nhưng, nếu vậy, ai là người cần được chọn.

Mà còn là:
Và do đó, nó theo như vậy là đã sẵn sàng để bước vào... vào đâu??

Trong động lực của một thị trường tài chính, sự khó lường như vậy có thể làm suy yếu các tham gia trong tương lai.

Tuy nhiên, quyết định cuối cùng vẫn phải mang tính tất định đối với việc thanh toán (settlement).

Vào thời điểm cơ sở hạ tầng của chính blockchain giao cắt với các tài sản thực của tài chính, “ngẫu nhiên” không còn đồng nghĩa với “không chắc chắn”.

Thứ tôi muốn theo dõi theo thời gian sẽ là khả năng mở rộng. Cụ thể là khả năng mở rộng của mô hình khi mức độ hoạt động của các tổ chức tham gia rút ra cùng một kết quả đầu ra sẽ tăng lên.
PINNED
Đã xác minh
Hợp đồng thông minh có thể lập trình được nhưng điều đó không có nghĩa là toàn bộ quy trình tài chính đều được tự động hóa hoàn toàn. Điều này khiến tôi cân nhắc đến trường hợp đơn giản nhất: cách thức hoạt động khi có một chứng khoán được mã hóa (tokenized) trong đó các khoản thanh toán cổ tức phải được thực hiện. Lý do cho việc đó, thứ nhất, có vẻ nó quá đơn giản; Quy tắc onchain; hợp đồng phán quyết, sau đó phân phối. Nhưng có một chi tiết quan trọng: Lập trình được ≠ tự chủ. Việc điều này được dịch sang logic như sau: Không thể nhất thiết giả định rằng hệ thống có kiến thức rằng hành động doanh nghiệp ban đầu đã được thực hiện đúng cách, các nguồn quỹ cần thiết đã sẵn có hay một phép tính ngoài chuỗi (off chain) có hợp lệ. Tuy nhiên, sự khác biệt này có thể được nhấn mạnh hơn nữa trong một thị trường được quản lý. Dusk đã định nghĩa mô hình Confidential Security Contract (Hợp đồng Bảo mật Chứng khoán) từ các dòng tiền tài chính như thanh toán cổ tức và bỏ phiếu, thay vì coi chứng khoán như một token. Và chính ở đây, tôi thấy kiến trúc thật sự hấp dẫn. Điểm không phải là đưa thêm logic lên onchain. Mục tiêu là khớp tư duy đó với thực tế: các đặc tính của chính tài sản—các quy tắc về sở hữu, điều kiện đủ, dịch vụ, thanh toán và các công bố đã biết (đôi khi được gọi là “các dữ kiện”). Trên thực tế, một hệ thống tự động chỉ có thể tốt đến mức dữ liệu và các quy tắc làm nền tảng cho nó. Vì vậy, câu hỏi thú vị đối với tôi không phải là: Tài sản do nhà nước kiểm soát có thể được lập trình không? Chúng ta đã biết điều này có thể. Câu hỏi khó hơn là: Có thể tự động hóa một phần bao nhiêu của quy trình tài chính thực sự, và vẫn không loại bỏ hoàn toàn yếu tố con người—nơi yếu tố đó vẫn tồn tại—trong các thị trường được quản lý? Tôi muốn quan sát điều đó theo thời gian. #dusk @Dusk_Foundation $DUSK
Hợp đồng thông minh có thể lập trình được nhưng điều đó không có nghĩa là toàn bộ quy trình tài chính đều được tự động hóa hoàn toàn.

Điều này khiến tôi cân nhắc đến trường hợp đơn giản nhất: cách thức hoạt động khi có một chứng khoán được mã hóa (tokenized) trong đó các khoản thanh toán cổ tức phải được thực hiện.

Lý do cho việc đó, thứ nhất, có vẻ nó quá đơn giản;

Quy tắc onchain; hợp đồng phán quyết, sau đó phân phối.

Nhưng có một chi tiết quan trọng:
Lập trình được ≠ tự chủ.

Việc điều này được dịch sang logic như sau:

Không thể nhất thiết giả định rằng hệ thống có kiến thức rằng hành động doanh nghiệp ban đầu đã được thực hiện đúng cách, các nguồn quỹ cần thiết đã sẵn có hay một phép tính ngoài chuỗi (off chain) có hợp lệ.
Tuy nhiên, sự khác biệt này có thể được nhấn mạnh hơn nữa trong một thị trường được quản lý.

Dusk đã định nghĩa mô hình Confidential Security Contract (Hợp đồng Bảo mật Chứng khoán) từ các dòng tiền tài chính như thanh toán cổ tức và bỏ phiếu, thay vì coi chứng khoán như một token.

Và chính ở đây, tôi thấy kiến trúc thật sự hấp dẫn.

Điểm không phải là đưa thêm logic lên onchain.

Mục tiêu là khớp tư duy đó với thực tế: các đặc tính của chính tài sản—các quy tắc về sở hữu, điều kiện đủ, dịch vụ, thanh toán và các công bố đã biết (đôi khi được gọi là “các dữ kiện”).

Trên thực tế, một hệ thống tự động chỉ có thể tốt đến mức dữ liệu và các quy tắc làm nền tảng cho nó.

Vì vậy, câu hỏi thú vị đối với tôi không phải là:
Tài sản do nhà nước kiểm soát có thể được lập trình không?

Chúng ta đã biết điều này có thể.

Câu hỏi khó hơn là:
Có thể tự động hóa một phần bao nhiêu của quy trình tài chính thực sự, và vẫn không loại bỏ hoàn toàn yếu tố con người—nơi yếu tố đó vẫn tồn tại—trong các thị trường được quản lý?

Tôi muốn quan sát điều đó theo thời gian.
#dusk @Dusk $DUSK
Tôi đã suy nghĩ về việc “quyền sở hữu” thực sự có nghĩa là gì trong một thị trường tài chính thực tế. Giả sử bạn mua cổ phiếu của một công ty. Giao dịch được thanh toán bù trừ, và tài sản chính thức mang tên bạn. Trên giấy tờ, mọi thứ có vẻ đơn giản như vậy. Nhưng mọi chuyện sẽ trở nên rắc rối ngay khi thực tế ập đến. Một khoản cổ tức được công bố. Một cuộc bỏ phiếu của cổ đông được tổ chức. Hoặc một hoạt động doanh nghiệp thay đổi hoàn toàn tài sản. Lúc đó, câu hỏi không chỉ là: "Ai là người có quyền yêu cầu điều này?" Câu hỏi mang tính vận hành thực sự là: Tiêu đề đó sẽ kích hoạt điều gì bên trong hệ thống? Vì việc khóa một bản ghi trên sổ cái thì dễ. Còn việc triển khai đúng quy trình vận hành đằng sau nó lại là một “con thú” hoàn toàn khác. Giấy tờ nghe có vẻ đơn giản, nhưng khâu thực thi có nhiều mảnh ghép. Nhà đầu tư đúng cần phải được thanh toán. Người nắm giữ đúng cần phải thực hiện quyền bỏ phiếu. Mỗi lần chuyển nhượng đều phải vượt qua các quy tắc đủ điều kiện nghiêm ngặt. Và tất cả những điều này phải luôn được đồng bộ hoàn hảo, ngày này qua ngày khác. Đó là nơi nút thắt hình thành. Nếu quyền sở hữu nằm ở một hệ thống, tuân thủ đủ điều kiện ở hệ thống khác, và các hoạt động doanh nghiệp ở một hệ thống thứ ba, thì hồ sơ của bạn có thể hoàn hảo, nhưng quy trình thực tế vẫn phải chạy dựa trên việc đối chiếu thủ công kiểu “bù trừ” giữa các cơ sở dữ liệu tách rời. Vì vậy tôi thấy Dusk thật thú vị. Cách tiếp cận của họ với tài sản được quản lý không chỉ dừng lại ở việc gắn nhãn tiêu đề trên blockchain vì mục đích đó. Thử thách thực sự là liệu họ có thể gom quyền sở hữu, đủ điều kiện, chuyển nhượng và các hoạt động doanh nghiệp vào trong một quy trình tài chính duy nhất, thống nhất hay không. Một sổ cái tĩnh chỉ cho bạn biết ai sở hữu cái gì. Một hệ thống tài chính vận hành cần hiểu tài sản đó thực sự được phép làm gì. Và đó là phần tôi đang theo dõi: liệu quyền sở hữu theo pháp lý có thể thực sự trở thành quyền sở hữu theo nghĩa vận hành trong thực tế không? #dusk @Dusk_Foundation $DUSK
Tôi đã suy nghĩ về việc “quyền sở hữu” thực sự có nghĩa là gì trong một thị trường tài chính thực tế.
Giả sử bạn mua cổ phiếu của một công ty.
Giao dịch được thanh toán bù trừ, và tài sản chính thức mang tên bạn. Trên giấy tờ, mọi thứ có vẻ đơn giản như vậy.
Nhưng mọi chuyện sẽ trở nên rắc rối ngay khi thực tế ập đến.
Một khoản cổ tức được công bố. Một cuộc bỏ phiếu của cổ đông được tổ chức. Hoặc một hoạt động doanh nghiệp thay đổi hoàn toàn tài sản.
Lúc đó, câu hỏi không chỉ là: "Ai là người có quyền yêu cầu điều này?"
Câu hỏi mang tính vận hành thực sự là: Tiêu đề đó sẽ kích hoạt điều gì bên trong hệ thống?
Vì việc khóa một bản ghi trên sổ cái thì dễ. Còn việc triển khai đúng quy trình vận hành đằng sau nó lại là một “con thú” hoàn toàn khác.
Giấy tờ nghe có vẻ đơn giản, nhưng khâu thực thi có nhiều mảnh ghép. Nhà đầu tư đúng cần phải được thanh toán. Người nắm giữ đúng cần phải thực hiện quyền bỏ phiếu. Mỗi lần chuyển nhượng đều phải vượt qua các quy tắc đủ điều kiện nghiêm ngặt. Và tất cả những điều này phải luôn được đồng bộ hoàn hảo, ngày này qua ngày khác.
Đó là nơi nút thắt hình thành.
Nếu quyền sở hữu nằm ở một hệ thống, tuân thủ đủ điều kiện ở hệ thống khác, và các hoạt động doanh nghiệp ở một hệ thống thứ ba, thì hồ sơ của bạn có thể hoàn hảo, nhưng quy trình thực tế vẫn phải chạy dựa trên việc đối chiếu thủ công kiểu “bù trừ” giữa các cơ sở dữ liệu tách rời.
Vì vậy tôi thấy Dusk thật thú vị.
Cách tiếp cận của họ với tài sản được quản lý không chỉ dừng lại ở việc gắn nhãn tiêu đề trên blockchain vì mục đích đó.
Thử thách thực sự là liệu họ có thể gom quyền sở hữu, đủ điều kiện, chuyển nhượng và các hoạt động doanh nghiệp vào trong một quy trình tài chính duy nhất, thống nhất hay không.
Một sổ cái tĩnh chỉ cho bạn biết ai sở hữu cái gì.
Một hệ thống tài chính vận hành cần hiểu tài sản đó thực sự được phép làm gì.
Và đó là phần tôi đang theo dõi: liệu quyền sở hữu theo pháp lý có thể thực sự trở thành quyền sở hữu theo nghĩa vận hành trong thực tế không?
#dusk @Dusk $DUSK
Tôi lại nhìn về Dusk, và một điểm khác biệt cứ làm tôi băn khoăn: Một giao thức hoạt động ≠ một thị trường hoạt động. Ban đầu, rất dễ nhìn vào một blockchain có thể thực thi giao dịch, hỗ trợ các ứng dụng tài chính và xử lý phần kỹ thuật của các tài sản được quản lý, rồi nghĩ: “Được thôi, hạ tầng đang hoạt động.” Nhưng đó chỉ là một phần của câu hỏi. Điều thú vị hơn là điều gì xảy ra khi hạ tầng đó gặp một thị trường tài chính thực sự. Bởi vì một thị trường thật sự cần nhiều hơn công nghệ. Nó cần những tổ chức phát hành có thể tạo ra tài sản. Những nhà đầu tư có thể tương tác với chúng. Những quy tắc có thể được thực thi trong thực tế. Những việc chuyển giao tuân theo các quy tắc đó. Và hoạt động tiếp diễn theo thời gian. Sự khác biệt này quan trọng. Một giao thức có thể chứng minh rằng điều gì đó là khả thi về mặt kỹ thuật. Một thị trường phải chứng minh rằng con người và các tổ chức thực sự thấy nó hữu ích đến mức tiếp tục sử dụng. Đó là chỗ mà tôi nghĩ Dusk trở nên thú vị hơn để theo dõi. Kiến trúc của nó rõ ràng đang được thiết kế xoay quanh các trường hợp sử dụng tài chính được quản lý, nhưng câu hỏi khó hơn không phải là liệu công nghệ có thể hỗ trợ chúng hay không. Mà là liệu hoạt động tài chính thực tế có thể dần hình thành xung quanh hạ tầng đó hay không. Đó là phần tôi muốn quan sát theo thời gian: Khả năng kỹ thuật có trở thành hoạt động thị trường lặp lại hay không? Bởi vì một giao thức hoạt động là bằng chứng của kỹ thuật. Một thị trường hoạt động là bằng chứng của tính hữu dụng. Và hai thứ đó không phải là một. @Dusk_Foundation #dusk $DUSK
Tôi lại nhìn về Dusk, và một điểm khác biệt cứ làm tôi băn khoăn:
Một giao thức hoạt động ≠ một thị trường hoạt động.
Ban đầu, rất dễ nhìn vào một blockchain có thể thực thi giao dịch, hỗ trợ các ứng dụng tài chính và xử lý phần kỹ thuật của các tài sản được quản lý, rồi nghĩ:
“Được thôi, hạ tầng đang hoạt động.”
Nhưng đó chỉ là một phần của câu hỏi.
Điều thú vị hơn là điều gì xảy ra khi hạ tầng đó gặp một thị trường tài chính thực sự.
Bởi vì một thị trường thật sự cần nhiều hơn công nghệ.
Nó cần những tổ chức phát hành có thể tạo ra tài sản.
Những nhà đầu tư có thể tương tác với chúng.
Những quy tắc có thể được thực thi trong thực tế.
Những việc chuyển giao tuân theo các quy tắc đó.
Và hoạt động tiếp diễn theo thời gian.
Sự khác biệt này quan trọng.
Một giao thức có thể chứng minh rằng điều gì đó là khả thi về mặt kỹ thuật.
Một thị trường phải chứng minh rằng con người và các tổ chức thực sự thấy nó hữu ích đến mức tiếp tục sử dụng.
Đó là chỗ mà tôi nghĩ Dusk trở nên thú vị hơn để theo dõi.
Kiến trúc của nó rõ ràng đang được thiết kế xoay quanh các trường hợp sử dụng tài chính được quản lý, nhưng câu hỏi khó hơn không phải là liệu công nghệ có thể hỗ trợ chúng hay không.
Mà là liệu hoạt động tài chính thực tế có thể dần hình thành xung quanh hạ tầng đó hay không.
Đó là phần tôi muốn quan sát theo thời gian:
Khả năng kỹ thuật có trở thành hoạt động thị trường lặp lại hay không?
Bởi vì một giao thức hoạt động là bằng chứng của kỹ thuật.
Một thị trường hoạt động là bằng chứng của tính hữu dụng.
Và hai thứ đó không phải là một.
@Dusk #dusk $DUSK
Vài ngày trước, tôi lại xem DuskEVM và tự nhiên bắt gặp mình đang đưa ra một giả định mà có lẽ tôi không nên làm. Nếu các nhà phát triển có thể sử dụng Solidity và các công cụ quen thuộc của EVM, thì việc khiến họ xây dựng trên Dusk sẽ dễ hơn rất nhiều. Phần đó là đúng. Nhưng dễ để xây dựng trên ≠ thực sự đã được xây dựng trên. Và sự khác biệt đó quan trọng hơn tôi nghĩ lúc đầu. DuskEVM giảm đáng kể ngưỡng gia nhập cho những nhà phát triển đã hiểu ngăn xếp EVM. Họ không phải bắt đầu từ một môi trường phát triển hoàn toàn xa lạ. Hedger bổ sung thêm một lớp thú vị khác bằng cách đưa vào các chức năng hướng tới quyền riêng tư trong chính môi trường đó, trong khi kiến trúc Dusk rộng hơn nhắm tới những thứ như tài sản được token hóa, DeFi, cho vay và các ứng dụng tài chính. Trên giấy tờ, các nguyên liệu đã có. Nhưng hạ tầng sẵn sàng chỉ là một phần của phương trình. Điều tôi thực sự muốn thấy là chuyện gì xảy ra sau khi các nhà phát triển đã đến. Bao nhiêu hợp đồng được triển khai? Bao nhiêu hợp đồng vẫn hoạt động sau đợt kiểm thử ban đầu? Bao nhiêu ứng dụng tạo ra các giao dịch lặp lại? Và quan trọng hơn, bao nhiêu trong số hoạt động đó đến từ người dùng thật chứ không phải từ việc các nhà phát triển chỉ đơn giản thử nghiệm với hạ tầng? Đó là chỗ tôi nghĩ sự khác biệt giữa “tiếp cận của nhà phát triển” và “nhận con nuôi của nhà phát triển” trở nên quan trọng. Một testnet có thể chứng minh rằng một thứ gì đó hoạt động. Một nhà phát triển có thể chứng minh rằng một thứ gì đó có thể được xây dựng. Nhưng không cái nào tự động chứng minh rằng một hệ sinh thái đang hình thành. Điều đó không làm cho DuskEVM kém thú vị với tôi. Nếu có, nó còn cho tôi một chỉ số tốt hơn để theo dõi. Thay vì hỏi: “Các nhà phát triển có thể xây dựng trên Dusk không?” Tôi muốn hỏi: “Sáu tháng sau, các nhà phát triển vẫn đang tiếp tục xây dựng trên Dusk như thế nào?” Bởi vì hạ tầng sẽ thuyết phục hơn rất nhiều khi hoạt động không còn dừng ở mức bản demo và bắt đầu trở thành thói quen. Và đó là phần câu chuyện dành cho nhà phát triển của Dusk mà tôi tò mò nhất. @Dusk_Foundation #dusk $DUSK
Vài ngày trước, tôi lại xem DuskEVM và tự nhiên bắt gặp mình đang đưa ra một giả định mà có lẽ tôi không nên làm.
Nếu các nhà phát triển có thể sử dụng Solidity và các công cụ quen thuộc của EVM, thì việc khiến họ xây dựng trên Dusk sẽ dễ hơn rất nhiều.
Phần đó là đúng.
Nhưng dễ để xây dựng trên ≠ thực sự đã được xây dựng trên.
Và sự khác biệt đó quan trọng hơn tôi nghĩ lúc đầu.
DuskEVM giảm đáng kể ngưỡng gia nhập cho những nhà phát triển đã hiểu ngăn xếp EVM. Họ không phải bắt đầu từ một môi trường phát triển hoàn toàn xa lạ.
Hedger bổ sung thêm một lớp thú vị khác bằng cách đưa vào các chức năng hướng tới quyền riêng tư trong chính môi trường đó, trong khi kiến trúc Dusk rộng hơn nhắm tới những thứ như tài sản được token hóa, DeFi, cho vay và các ứng dụng tài chính.
Trên giấy tờ, các nguyên liệu đã có.
Nhưng hạ tầng sẵn sàng chỉ là một phần của phương trình.
Điều tôi thực sự muốn thấy là chuyện gì xảy ra sau khi các nhà phát triển đã đến.
Bao nhiêu hợp đồng được triển khai?
Bao nhiêu hợp đồng vẫn hoạt động sau đợt kiểm thử ban đầu?
Bao nhiêu ứng dụng tạo ra các giao dịch lặp lại?
Và quan trọng hơn, bao nhiêu trong số hoạt động đó đến từ người dùng thật chứ không phải từ việc các nhà phát triển chỉ đơn giản thử nghiệm với hạ tầng?
Đó là chỗ tôi nghĩ sự khác biệt giữa “tiếp cận của nhà phát triển” và “nhận con nuôi của nhà phát triển” trở nên quan trọng.
Một testnet có thể chứng minh rằng một thứ gì đó hoạt động.
Một nhà phát triển có thể chứng minh rằng một thứ gì đó có thể được xây dựng.
Nhưng không cái nào tự động chứng minh rằng một hệ sinh thái đang hình thành.
Điều đó không làm cho DuskEVM kém thú vị với tôi. Nếu có, nó còn cho tôi một chỉ số tốt hơn để theo dõi.
Thay vì hỏi:
“Các nhà phát triển có thể xây dựng trên Dusk không?”
Tôi muốn hỏi:
“Sáu tháng sau, các nhà phát triển vẫn đang tiếp tục xây dựng trên Dusk như thế nào?”
Bởi vì hạ tầng sẽ thuyết phục hơn rất nhiều khi hoạt động không còn dừng ở mức bản demo và bắt đầu trở thành thói quen.
Và đó là phần câu chuyện dành cho nhà phát triển của Dusk mà tôi tò mò nhất.
@Dusk #dusk $DUSK
Cách đây 2 năm về trước, tôi từng là 1 quản lý cấp cao của một công ty phần mềm. Tôi thường hay dùng thẻ của mình để vào khu vực làm việc, nhưng không thể mở cửa phòng server hay phòng lưu trữ hồ sơ. Ban đầu tôi nghĩ đó đơn giản chỉ là một hệ thống kiểm soát quyền truy cập. Nhưng sau này tôi nhận ra một điều thú vị: Một hệ thống tốt không đợi đến lúc dữ liệu bị lộ mới bắt đầu bảo vệ nó. Điều này khiến tôi nghĩ đến @Dusk_Foundation . Trong regulated finance, privacy cũng không nên là một lớp được thêm vào sau khi tài sản và giao dịch đã được đưa lên-chain. Nó cần được tính đến ngay từ cách hệ thống xử lý tài sản, identity và transaction. Đó là điều tôi thấy thú vị ở cách Dusk tiếp cận privacy. Với Phoenix cho confidential transactions và Moonlight cho transparent account-based transactions, privacy không nhất thiết phải là một lựa chọn “bật hoặc tắt” cho toàn bộ hệ thống. Các loại giao dịch khác nhau có thể cần những mức độ visibility khác nhau. Và với zero-knowledge proofs, một bên có thể chứng minh rằng một điều kiện cần thiết đã được đáp ứng mà không nhất thiết phải tiết lộ toàn bộ dữ liệu phía sau. Đối với regulated assets, điều này rất quan trọng. Một hệ thống tài chính không chỉ cần hỏi: “Dữ liệu này có được bảo mật không?” Mà còn phải hỏi: “Privacy đã được thiết kế vào infrastructure ngay từ đầu chưa?” Đó là điểm khiến tôi thấy khái niệm privacy by design đáng chú ý hơn rất nhiều so với việc đơn giản thêm một lớp privacy vào blockchain. Và có lẽ đây cũng là một phần lý do Dusk đang đi theo một hướng khá khác khi xây dựng infrastructure cho regulated finance. #dusk $DUSK
Cách đây 2 năm về trước, tôi từng là 1 quản lý cấp cao của một công ty phần mềm.
Tôi thường hay dùng thẻ của mình để vào khu vực làm việc, nhưng không thể mở cửa phòng server hay phòng lưu trữ hồ sơ.
Ban đầu tôi nghĩ đó đơn giản chỉ là một hệ thống kiểm soát quyền truy cập.
Nhưng sau này tôi nhận ra một điều thú vị:
Một hệ thống tốt không đợi đến lúc dữ liệu bị lộ mới bắt đầu bảo vệ nó.
Điều này khiến tôi nghĩ đến @Dusk .
Trong regulated finance, privacy cũng không nên là một lớp được thêm vào sau khi tài sản và giao dịch đã được đưa lên-chain.
Nó cần được tính đến ngay từ cách hệ thống xử lý tài sản, identity và transaction.
Đó là điều tôi thấy thú vị ở cách Dusk tiếp cận privacy.
Với Phoenix cho confidential transactions và Moonlight cho transparent account-based transactions, privacy không nhất thiết phải là một lựa chọn “bật hoặc tắt” cho toàn bộ hệ thống.
Các loại giao dịch khác nhau có thể cần những mức độ visibility khác nhau.
Và với zero-knowledge proofs, một bên có thể chứng minh rằng một điều kiện cần thiết đã được đáp ứng mà không nhất thiết phải tiết lộ toàn bộ dữ liệu phía sau.
Đối với regulated assets, điều này rất quan trọng.
Một hệ thống tài chính không chỉ cần hỏi:
“Dữ liệu này có được bảo mật không?”
Mà còn phải hỏi:
“Privacy đã được thiết kế vào infrastructure ngay từ đầu chưa?”
Đó là điểm khiến tôi thấy khái niệm privacy by design đáng chú ý hơn rất nhiều so với việc đơn giản thêm một lớp privacy vào blockchain.
Và có lẽ đây cũng là một phần lý do Dusk đang đi theo một hướng khá khác khi xây dựng infrastructure cho regulated finance.
#dusk $DUSK
Sau 4 ngày tìm hiểu TermMax, mình nhận ra mình đã nhìn nó sai ở một điểm. Ban đầu, mình cố tìm một tính năng nổi bật nhất. Fixed rate? RWA? Range Order? Liquidation? Nhưng càng tìm hiểu, mình càng thấy câu hỏi thú vị hơn không phải là: “TermMax có gì?” Mà là: “Những thứ đó kết nối với nhau để tạo ra điều gì?” Fixed-rate lending tạo ra khả năng dự đoán chi phí vốn. Tokenized assets mở thêm nguồn collateral có thể sử dụng on-chain. Range Order tạo ra một cách khác để liquidity tham gia vào việc hình thành rate. Và Physical Delivery Liquidation đặt ra một framework khác cho cách xử lý rủi ro khi vị thế đi ngược kỳ vọng. Nếu nhìn từng phần riêng lẻ, chúng chỉ giống những tính năng của một lending protocol. Nhưng khi đặt cạnh nhau, mình bắt đầu thấy một câu chuyện khác: Capital → Pricing → Liquidity → Collateral → Risk Đó không còn chỉ là câu chuyện về một khoản vay. Nó giống một nỗ lực xây dựng financial infrastructure có thể kết nối nhiều lớp của thị trường vốn on-chain. Và đây cũng là điều mình thích nhất ở cách @termmax tiếp cận vấn đề. Họ không chỉ hỏi: “Làm thế nào để người dùng vay?” Mà dường như đang đặt những câu hỏi rộng hơn: Làm thế nào để vốn có thể được định giá rõ ràng hơn? Làm thế nào để tài sản tokenized có thêm utility? Làm thế nào để liquidity được tổ chức quanh fixed-rate markets? Và khi mọi thứ đi sai, hệ thống sẽ xử lý risk như thế nào? Mình chưa nghĩ TermMax đã trả lời hoàn hảo tất cả những câu hỏi đó. Nhưng sau 5 ngày tìm hiểu, mình nghĩ đó mới chính là lý do đáng để tiếp tục theo dõi. Không phải vì TermMax có một feature nổi bật. Mà vì các mảnh ghép bắt đầu trông giống một hệ thống. #TermMax
Sau 4 ngày tìm hiểu TermMax, mình nhận ra mình đã nhìn nó sai ở một điểm.
Ban đầu, mình cố tìm một tính năng nổi bật nhất.
Fixed rate?
RWA?
Range Order?
Liquidation?
Nhưng càng tìm hiểu, mình càng thấy câu hỏi thú vị hơn không phải là:
“TermMax có gì?”
Mà là:
“Những thứ đó kết nối với nhau để tạo ra điều gì?”
Fixed-rate lending tạo ra khả năng dự đoán chi phí vốn.
Tokenized assets mở thêm nguồn collateral có thể sử dụng on-chain.
Range Order tạo ra một cách khác để liquidity tham gia vào việc hình thành rate.
Và Physical Delivery Liquidation đặt ra một framework khác cho cách xử lý rủi ro khi vị thế đi ngược kỳ vọng.
Nếu nhìn từng phần riêng lẻ, chúng chỉ giống những tính năng của một lending protocol.
Nhưng khi đặt cạnh nhau, mình bắt đầu thấy một câu chuyện khác:
Capital → Pricing → Liquidity → Collateral → Risk
Đó không còn chỉ là câu chuyện về một khoản vay.
Nó giống một nỗ lực xây dựng financial infrastructure có thể kết nối nhiều lớp của thị trường vốn on-chain.
Và đây cũng là điều mình thích nhất ở cách @TermMax tiếp cận vấn đề.
Họ không chỉ hỏi:
“Làm thế nào để người dùng vay?”
Mà dường như đang đặt những câu hỏi rộng hơn:
Làm thế nào để vốn có thể được định giá rõ ràng hơn?
Làm thế nào để tài sản tokenized có thêm utility?
Làm thế nào để liquidity được tổ chức quanh fixed-rate markets?
Và khi mọi thứ đi sai, hệ thống sẽ xử lý risk như thế nào?
Mình chưa nghĩ TermMax đã trả lời hoàn hảo tất cả những câu hỏi đó.
Nhưng sau 5 ngày tìm hiểu, mình nghĩ đó mới chính là lý do đáng để tiếp tục theo dõi.
Không phải vì TermMax có một feature nổi bật.
Mà vì các mảnh ghép bắt đầu trông giống một hệ thống.
#TermMax
Hồi trước tôi từng nghĩ một hệ thống càng dễ audit thì càng phải công khai càng nhiều dữ liệu. Nhưng càng tìm hiểu về tài chính, tôi càng thấy điều đó không hẳn đúng. Hãy tưởng tượng một auditor cần kiểm tra một giao dịch tài sản: Người tham gia có đủ điều kiện không? Giao dịch có tuân thủ quy định không? Tài sản có được chuyển đúng theo rule không? Để trả lời những câu hỏi đó, họ cần evidence. Nhưng điều đó không có nghĩa họ cần nhìn thấy toàn bộ số dư, lịch sử giao dịch hay thông tin riêng tư của tất cả participant. Đó là lý do tôi thấy cách tiếp cận của @Dusk_Foundation thú vị. Với regulated assets, bài toán không đơn giản là: “Dữ liệu có được công khai hay không?” Mà là: “Ai cần xác minh điều gì, và họ thực sự cần nhìn thấy bao nhiêu?” Zero-knowledge proofs có thể giúp một bên chứng minh một điều kiện là đúng mà không cần tiết lộ toàn bộ dữ liệu phía sau. Selective disclosure lại cho phép thông tin cần thiết được chia sẻ với đúng bên khi có lý do chính đáng. Vì vậy, tôi nghĩ: Auditability ≠ Full Transparency Một hệ thống tài chính tốt không nhất thiết phải biến mọi dữ liệu thành public data để chứng minh nó đáng tin cậy. Nó cần tạo ra đủ bằng chứng để được kiểm chứng, trong khi vẫn giữ lại phần dữ liệu không cần thiết phải lộ ra. Đó có lẽ là một trong những điều quan trọng để privacy và compliance thực sự cùng tồn tại on-chain. #dusk $DUSK
Hồi trước tôi từng nghĩ một hệ thống càng dễ audit thì càng phải công khai càng nhiều dữ liệu.
Nhưng càng tìm hiểu về tài chính, tôi càng thấy điều đó không hẳn đúng.
Hãy tưởng tượng một auditor cần kiểm tra một giao dịch tài sản:
Người tham gia có đủ điều kiện không?
Giao dịch có tuân thủ quy định không?
Tài sản có được chuyển đúng theo rule không?
Để trả lời những câu hỏi đó, họ cần evidence.
Nhưng điều đó không có nghĩa họ cần nhìn thấy toàn bộ số dư, lịch sử giao dịch hay thông tin riêng tư của tất cả participant.
Đó là lý do tôi thấy cách tiếp cận của @Dusk thú vị.
Với regulated assets, bài toán không đơn giản là:
“Dữ liệu có được công khai hay không?”
Mà là:
“Ai cần xác minh điều gì, và họ thực sự cần nhìn thấy bao nhiêu?”
Zero-knowledge proofs có thể giúp một bên chứng minh một điều kiện là đúng mà không cần tiết lộ toàn bộ dữ liệu phía sau.
Selective disclosure lại cho phép thông tin cần thiết được chia sẻ với đúng bên khi có lý do chính đáng.
Vì vậy, tôi nghĩ:
Auditability ≠ Full Transparency
Một hệ thống tài chính tốt không nhất thiết phải biến mọi dữ liệu thành public data để chứng minh nó đáng tin cậy.
Nó cần tạo ra đủ bằng chứng để được kiểm chứng, trong khi vẫn giữ lại phần dữ liệu không cần thiết phải lộ ra.
Đó có lẽ là một trong những điều quan trọng để privacy và compliance thực sự cùng tồn tại on-chain.
#dusk $DUSK
Một điều mình nhận ra khi tìm hiểu TermMax: Fixed-rate lending không chỉ cần người vay và người cho vay. Nó cần cả một thị trường để hình thành giá. Ban đầu mình nghĩ lãi suất fixed đơn giản là một con số được giao thức đưa ra. Nhưng nếu lãi suất có thể được khóa trong một khoảng thời gian cụ thể, thì lập tức xuất hiện một câu hỏi thú vị: Ai quyết định mức rate đó là hợp lý? Đây là lúc mình bắt đầu chú ý hơn đến Range Order của @termmax . Thay vì thanh khoản chỉ tập trung quanh một mức lãi suất duy nhất, Range Order cho phép liquidity được phân bổ theo các khoảng rate khác nhau. Điều này khiến mình nhìn fixed-rate market theo một cách khác. Lãi suất không chỉ là một con số để người vay nhìn vào. Nó là một mức giá được thị trường khám phá và giao dịch. Người cho vay có thể có mức yield mà họ muốn. Người đi vay có mức borrowing cost mà họ chấp nhận. Khoảng cách giữa hai bên chính là nơi market design trở nên quan trọng. Và đây cũng là điểm mình thấy TermMax thú vị hơn một lending protocol thông thường. Thay vì chỉ hỏi: “Lãi suất hiện tại là bao nhiêu?” Mình bắt đầu quan tâm hơn đến: “Thị trường hình thành mức lãi suất đó như thế nào?” Nếu fixed-rate lending muốn trở thành một lớp quan trọng của DeFi, việc tạo ra fixed rate có lẽ chưa đủ. Nó còn cần một cơ chế đủ linh hoạt để price discovery và liquidity cùng tồn tại. Đó là phần mình muốn tiếp tục đào sâu ở TermMax. #TermMax
Một điều mình nhận ra khi tìm hiểu TermMax:
Fixed-rate lending không chỉ cần người vay và người cho vay. Nó cần cả một thị trường để hình thành giá.
Ban đầu mình nghĩ lãi suất fixed đơn giản là một con số được giao thức đưa ra.
Nhưng nếu lãi suất có thể được khóa trong một khoảng thời gian cụ thể, thì lập tức xuất hiện một câu hỏi thú vị:
Ai quyết định mức rate đó là hợp lý?
Đây là lúc mình bắt đầu chú ý hơn đến Range Order của @TermMax .
Thay vì thanh khoản chỉ tập trung quanh một mức lãi suất duy nhất, Range Order cho phép liquidity được phân bổ theo các khoảng rate khác nhau.
Điều này khiến mình nhìn fixed-rate market theo một cách khác.
Lãi suất không chỉ là một con số để người vay nhìn vào.
Nó là một mức giá được thị trường khám phá và giao dịch.
Người cho vay có thể có mức yield mà họ muốn.
Người đi vay có mức borrowing cost mà họ chấp nhận.
Khoảng cách giữa hai bên chính là nơi market design trở nên quan trọng.
Và đây cũng là điểm mình thấy TermMax thú vị hơn một lending protocol thông thường.
Thay vì chỉ hỏi:
“Lãi suất hiện tại là bao nhiêu?”
Mình bắt đầu quan tâm hơn đến:
“Thị trường hình thành mức lãi suất đó như thế nào?”
Nếu fixed-rate lending muốn trở thành một lớp quan trọng của DeFi, việc tạo ra fixed rate có lẽ chưa đủ.
Nó còn cần một cơ chế đủ linh hoạt để price discovery và liquidity cùng tồn tại.
Đó là phần mình muốn tiếp tục đào sâu ở TermMax.
#TermMax
Kinh nghiệm nhiều không phải lúc nào cũng làm bạn an toàn hơn. Đôi khi nó khiến bạn chủ quan hơn. Hãy thử tưởng tượng một người đã giao dịch P2P hàng trăm lần. Họ biết phải mở Order ở đâu. Biết kiểm tra payment. Biết khi nào không nên Release. Những thao tác đó quen đến mức gần như thành phản xạ. Và chính điều này mới đáng để suy nghĩ. Khi làm một việc đủ nhiều lần, não bắt đầu tìm cách làm nó nhanh hơn. Bạn không còn đọc từng chi tiết. Bạn nhìn qua một vài thông tin quen thuộc, thấy mọi thứ giống như bình thường, rồi tiếp tục. Trong phần lớn các Order, điều đó có thể không gây ra vấn đề gì. Nhưng chỉ cần một Order có một chi tiết khác với thói quen, phản xạ cũ có thể khiến bạn bỏ qua nó. Một payment method khác. Một tài khoản thanh toán khác. Hoặc đơn giản là một điều kiện trong Order không giống những lần trước. Điều đáng sợ là người có kinh nghiệm không phải lúc nào cũng nhận ra mình đang chủ quan. Vì họ không nghĩ: “Mình đang bỏ qua bước kiểm tra.” Họ nghĩ: “Mình làm việc này quá nhiều rồi.” Vì vậy, mình có một nguyên tắc khá đơn giản khi giao dịch P2P: Kinh nghiệm nên giúp mình nhận ra điều bất thường nhanh hơn, chứ không phải giúp mình kiểm tra ít hơn. Mỗi Order vẫn có những điều kiện riêng. Mỗi payment vẫn cần được đối chiếu. Và mỗi lần Release vẫn phải dựa trên thông tin của chính giao dịch đó. Có thể điều khó nhất của việc giao dịch lâu năm không phải là học thêm một quy tắc. Mà là nhận ra lúc nào kinh nghiệm đang giúp mình và lúc nào nó đã biến thành thói quen. Biết quy trình là lợi thế. Nhưng vẫn thực sự nhìn vào từng Order mới là sự an toàn. @Binance_Vietnam #BinanceP2PAnToan
Kinh nghiệm nhiều không phải lúc nào cũng làm bạn an toàn hơn.
Đôi khi nó khiến bạn chủ quan hơn.
Hãy thử tưởng tượng một người đã giao dịch P2P hàng trăm lần.
Họ biết phải mở Order ở đâu.
Biết kiểm tra payment.
Biết khi nào không nên Release.
Những thao tác đó quen đến mức gần như thành phản xạ.
Và chính điều này mới đáng để suy nghĩ.
Khi làm một việc đủ nhiều lần, não bắt đầu tìm cách làm nó nhanh hơn.
Bạn không còn đọc từng chi tiết.
Bạn nhìn qua một vài thông tin quen thuộc, thấy mọi thứ giống như bình thường, rồi tiếp tục.
Trong phần lớn các Order, điều đó có thể không gây ra vấn đề gì.
Nhưng chỉ cần một Order có một chi tiết khác với thói quen, phản xạ cũ có thể khiến bạn bỏ qua nó.
Một payment method khác.
Một tài khoản thanh toán khác.
Hoặc đơn giản là một điều kiện trong Order không giống những lần trước.
Điều đáng sợ là người có kinh nghiệm không phải lúc nào cũng nhận ra mình đang chủ quan.
Vì họ không nghĩ:
“Mình đang bỏ qua bước kiểm tra.”
Họ nghĩ:
“Mình làm việc này quá nhiều rồi.”
Vì vậy, mình có một nguyên tắc khá đơn giản khi giao dịch P2P:
Kinh nghiệm nên giúp mình nhận ra điều bất thường nhanh hơn, chứ không phải giúp mình kiểm tra ít hơn.
Mỗi Order vẫn có những điều kiện riêng.
Mỗi payment vẫn cần được đối chiếu.
Và mỗi lần Release vẫn phải dựa trên thông tin của chính giao dịch đó.
Có thể điều khó nhất của việc giao dịch lâu năm không phải là học thêm một quy tắc.
Mà là nhận ra lúc nào kinh nghiệm đang giúp mình và lúc nào nó đã biến thành thói quen.
Biết quy trình là lợi thế.
Nhưng vẫn thực sự nhìn vào từng Order mới là sự an toàn.
@Binance Vietnam #BinanceP2PAnToan
Hồi còn đi làm, tôi từng sử dụng một hệ thống chấm công mà mỗi nhân viên chỉ có thể truy cập những chức năng phù hợp với vị trí của mình. Lúc đầu tôi nghĩ đó chỉ là một cách để công ty kiểm soát quyền truy cập. Nhưng sau này tôi nhận ra, một hệ thống tốt không phải là hệ thống cho phép hoặc từ chối tất cả mọi thứ. Nó phải biết ai cần quyền gì, và cần quyền đó ở mức nào. Điều này khiến tôi nghĩ đến @Dusk_Foundation Khi tài sản tài chính được đưa lên-chain, vấn đề cũng không chỉ là xác định ai đang sở hữu tài sản. Hệ thống còn phải biết ai đủ điều kiện sở hữu, ai được phép nhận hoặc chuyển tài sản, và bên nào thực sự cần được xác minh thông tin đó. Thay vì biến mọi dữ liệu thành thông tin mà tất cả participant đều có thể nhìn thấy, selective disclosure và zero-knowledge proofs có thể giúp một bên chứng minh điều cần thiết mà không phải tiết lộ toàn bộ dữ liệu phía sau. Tôi nghĩ điều này đặc biệt quan trọng với regulated finance. Một nhà đầu tư có thể cần chứng minh mình đủ điều kiện mua một tài sản. Nhưng điều đó không có nghĩa mọi bên trong transaction cần biết toàn bộ danh tính, tài sản hay lịch sử tài chính của người đó. Cùng một dữ liệu, nhưng không phải ai cũng cần cùng một mức độ truy cập. Đó là điều tôi thấy thú vị khi tìm hiểu Dusk: Một hệ thống tài chính tốt không phải là nơi mọi thứ đều được giấu kín. Cũng không phải nơi mọi thứ đều được công khai. Mà là nơi đúng người có thể xác minh đúng thông tin, vào đúng thời điểm, với lượng dữ liệu cần thiết. Có lẽ đó mới là cách privacy và compliance có thể cùng tồn tại trên-chain. #dusk $DUSK
Hồi còn đi làm, tôi từng sử dụng một hệ thống chấm công mà mỗi nhân viên chỉ có thể truy cập những chức năng phù hợp với vị trí của mình.
Lúc đầu tôi nghĩ đó chỉ là một cách để công ty kiểm soát quyền truy cập.
Nhưng sau này tôi nhận ra, một hệ thống tốt không phải là hệ thống cho phép hoặc từ chối tất cả mọi thứ.
Nó phải biết ai cần quyền gì, và cần quyền đó ở mức nào.
Điều này khiến tôi nghĩ đến @Dusk
Khi tài sản tài chính được đưa lên-chain, vấn đề cũng không chỉ là xác định ai đang sở hữu tài sản.
Hệ thống còn phải biết ai đủ điều kiện sở hữu, ai được phép nhận hoặc chuyển tài sản, và bên nào thực sự cần được xác minh thông tin đó.
Thay vì biến mọi dữ liệu thành thông tin mà tất cả participant đều có thể nhìn thấy, selective disclosure và zero-knowledge proofs có thể giúp một bên chứng minh điều cần thiết mà không phải tiết lộ toàn bộ dữ liệu phía sau.
Tôi nghĩ điều này đặc biệt quan trọng với regulated finance.
Một nhà đầu tư có thể cần chứng minh mình đủ điều kiện mua một tài sản.
Nhưng điều đó không có nghĩa mọi bên trong transaction cần biết toàn bộ danh tính, tài sản hay lịch sử tài chính của người đó.
Cùng một dữ liệu, nhưng không phải ai cũng cần cùng một mức độ truy cập.
Đó là điều tôi thấy thú vị khi tìm hiểu Dusk:
Một hệ thống tài chính tốt không phải là nơi mọi thứ đều được giấu kín.
Cũng không phải nơi mọi thứ đều được công khai.
Mà là nơi đúng người có thể xác minh đúng thông tin, vào đúng thời điểm, với lượng dữ liệu cần thiết.
Có lẽ đó mới là cách privacy và compliance có thể cùng tồn tại trên-chain.
#dusk $DUSK
Liquidation không chỉ là điểm kết thúc của một vị thế. Đây là phần mình bắt đầu chú ý hơn khi tìm hiểu @termmax . Trong DeFi, khi một vị thế không còn đủ an toàn, liquidation thường được nhìn khá đơn giản: Collateral giảm → vị thế bị thanh lý → người vay chịu thiệt hại. Nhưng mình nghĩ câu hỏi thú vị hơn là: Sau khi liquidation xảy ra, chuyện gì thực sự được xử lý? Đó là lý do mình muốn tìm hiểu sâu hơn về cơ chế Physical Delivery Liquidation của TermMax. Thay vì chỉ xem liquidation như một nút “đóng vị thế”, TermMax thiết kế cơ chế này xoay quanh việc xử lý thực tế mối quan hệ giữa collateral và debt. Điều này khiến mình nhìn liquidation dưới một góc khác. Một thị trường lending không chỉ cần cơ chế để mở vị thế. Nó còn cần một cơ chế đủ rõ ràng cho thời điểm thị trường đi ngược lại kỳ vọng. Đặc biệt khi có leverage, câu hỏi không còn đơn giản là: “Bạn có thể kiếm được bao nhiêu?” Mà còn là: “Nếu mọi thứ diễn biến xấu, hệ thống sẽ xử lý vị thế đó như thế nào?” Đây cũng là điểm mình thấy đáng nghiên cứu ở TermMax. Fixed-rate giải quyết một phần vấn đề về chi phí vốn. RWA mở thêm nguồn collateral. Nhưng liquidation mechanism mới là nơi mình muốn hiểu rõ cách toàn bộ cấu trúc đó chịu được stress của thị trường. Mình chưa nghĩ mình đã hiểu hết Physical Delivery Liquidation. Và có lẽ đó mới là phần thú vị nhất. Vì một giao thức tài chính đáng để nghiên cứu không chỉ nằm ở cách nó tạo ra lợi nhuận trong thị trường tốt. Mà còn ở cách nó xử lý khi thị trường không đi theo kế hoạch. #TermMax
Liquidation không chỉ là điểm kết thúc của một vị thế.
Đây là phần mình bắt đầu chú ý hơn khi tìm hiểu @TermMax .
Trong DeFi, khi một vị thế không còn đủ an toàn, liquidation thường được nhìn khá đơn giản:
Collateral giảm → vị thế bị thanh lý → người vay chịu thiệt hại.
Nhưng mình nghĩ câu hỏi thú vị hơn là:
Sau khi liquidation xảy ra, chuyện gì thực sự được xử lý?
Đó là lý do mình muốn tìm hiểu sâu hơn về cơ chế Physical Delivery Liquidation của TermMax.
Thay vì chỉ xem liquidation như một nút “đóng vị thế”, TermMax thiết kế cơ chế này xoay quanh việc xử lý thực tế mối quan hệ giữa collateral và debt.
Điều này khiến mình nhìn liquidation dưới một góc khác.
Một thị trường lending không chỉ cần cơ chế để mở vị thế.
Nó còn cần một cơ chế đủ rõ ràng cho thời điểm thị trường đi ngược lại kỳ vọng.
Đặc biệt khi có leverage, câu hỏi không còn đơn giản là:
“Bạn có thể kiếm được bao nhiêu?”
Mà còn là:
“Nếu mọi thứ diễn biến xấu, hệ thống sẽ xử lý vị thế đó như thế nào?”
Đây cũng là điểm mình thấy đáng nghiên cứu ở TermMax.
Fixed-rate giải quyết một phần vấn đề về chi phí vốn.
RWA mở thêm nguồn collateral.
Nhưng liquidation mechanism mới là nơi mình muốn hiểu rõ cách toàn bộ cấu trúc đó chịu được stress của thị trường.
Mình chưa nghĩ mình đã hiểu hết Physical Delivery Liquidation.
Và có lẽ đó mới là phần thú vị nhất.
Vì một giao thức tài chính đáng để nghiên cứu không chỉ nằm ở cách nó tạo ra lợi nhuận trong thị trường tốt.
Mà còn ở cách nó xử lý khi thị trường không đi theo kế hoạch.
#TermMax
Có một kiểu chủ quan trong P2P mà mình nghĩ nhiều anh em không để ý. Nó không bắt đầu bằng một người mua đáng ngờ. Mà bắt đầu bằng một giao dịch quá suôn sẻ. Bạn vừa giao dịch với một người. Thanh toán đúng số tiền. Tên tài khoản khớp. Không có vấn đề gì. Order hoàn tất bình thường. Một lúc sau, bạn mở thêm một Order khác với cùng người đó. Và trong đầu tự nhiên xuất hiện: “Người này vừa giao dịch với mình rồi, chắc lần này cũng ổn.” Nghe rất hợp lý. Nhưng chính suy nghĩ đó mới là thứ mình muốn cẩn thận. Vì giao dịch trước và giao dịch hiện tại vẫn là hai Order khác nhau. Mình vẫn phải kiểm tra lại: 🟢 Thông tin của Order hiện tại có đúng không? 🟢 Số tiền và phương thức thanh toán có khớp không? 🟢 Tài khoản thanh toán của giao dịch này có đúng với điều kiện hiện tại không? Không phải vì người kia đã từng làm đúng thì lần này chắc chắn có vấn đề. Mà vì lịch sử giao dịch tốt không phải là bằng chứng cho một giao dịch mới. Đây cũng là lý do mình không muốn để sự quen thuộc thay thế cho việc kiểm tra. Một người có thể hoàn thành 10 Order trước đó hoàn toàn bình thường. Nhưng Order thứ 11 vẫn là một giao dịch mới. Với mình, đây là một nguyên tắc khá đơn giản: Đừng chuyển sự tin tưởng từ giao dịch cũ sang giao dịch mới. Hãy chuyển dữ liệu của giao dịch mới vào bước kiểm tra. P2P an toàn đôi khi không phải là nhận ra một người đáng ngờ. Mà là nhận ra lúc nào mình đang quá yên tâm chỉ vì mọi thứ trước đó đã diễn ra tốt đẹp. @Binance_Vietnam #BinanceP2PAnToan $BNB
Có một kiểu chủ quan trong P2P mà mình nghĩ nhiều anh em không để ý.
Nó không bắt đầu bằng một người mua đáng ngờ.
Mà bắt đầu bằng một giao dịch quá suôn sẻ.
Bạn vừa giao dịch với một người.
Thanh toán đúng số tiền.
Tên tài khoản khớp.
Không có vấn đề gì.
Order hoàn tất bình thường.
Một lúc sau, bạn mở thêm một Order khác với cùng người đó.
Và trong đầu tự nhiên xuất hiện:
“Người này vừa giao dịch với mình rồi, chắc lần này cũng ổn.”
Nghe rất hợp lý.
Nhưng chính suy nghĩ đó mới là thứ mình muốn cẩn thận.
Vì giao dịch trước và giao dịch hiện tại vẫn là hai Order khác nhau.
Mình vẫn phải kiểm tra lại:
🟢 Thông tin của Order hiện tại có đúng không?
🟢 Số tiền và phương thức thanh toán có khớp không?
🟢 Tài khoản thanh toán của giao dịch này có đúng với điều kiện hiện tại không?
Không phải vì người kia đã từng làm đúng thì lần này chắc chắn có vấn đề.
Mà vì lịch sử giao dịch tốt không phải là bằng chứng cho một giao dịch mới.
Đây cũng là lý do mình không muốn để sự quen thuộc thay thế cho việc kiểm tra.
Một người có thể hoàn thành 10 Order trước đó hoàn toàn bình thường.
Nhưng Order thứ 11 vẫn là một giao dịch mới.
Với mình, đây là một nguyên tắc khá đơn giản:
Đừng chuyển sự tin tưởng từ giao dịch cũ sang giao dịch mới.
Hãy chuyển dữ liệu của giao dịch mới vào bước kiểm tra.
P2P an toàn đôi khi không phải là nhận ra một người đáng ngờ.
Mà là nhận ra lúc nào mình đang quá yên tâm chỉ vì mọi thứ trước đó đã diễn ra tốt đẹp.
@Binance Vietnam #BinanceP2PAnToan $BNB
Tôi từng nghĩ RWA về cơ bản chỉ là đưa một tài sản thật lên blockchain. Sau khi tìm hiểu kỹ hơn về Dusk, tôi bắt đầu nghĩ rằng giả định đó quá đơn giản. Một tài sản tài chính không chỉ có giá trị. Ai được phép sở hữu? Ai có thể nhận nó? Khi nào nó được chuyển nhượng? Điều gì xảy ra khi quyền sở hữu thay đổi? Và ai được phép thực hiện những hành động đó? Nếu những quy tắc này vẫn nằm ngoài blockchain, thì việc tạo ra một token có thực sự đưa tài sản vào on-chain không? Đây là phần khiến tôi chú ý ở @Dusk_Foundation Dusk không chỉ tiếp cận RWA từ góc độ tokenization. Với native issuance, ý tưởng thú vị hơn là đưa nhiều hơn vòng đời và logic của tài sản trực tiếp vào hạ tầng on-chain. Điều đó có nghĩa blockchain không chỉ ghi nhận rằng: “Đây là token của một trái phiếu.” Mà còn có thể trở thành nơi các điều kiện liên quan đến ownership, transfer và các hoạt động của tài sản được xử lý theo những rules đã được xác định. Đặc biệt với regulated assets, đây có thể là khác biệt quan trọng. Một trái phiếu không trở thành permissionless chỉ vì nó có token. Các yêu cầu về eligibility, transfer restrictions và compliance vẫn đi cùng tài sản. Vì vậy, câu hỏi tôi đang suy nghĩ không còn là: “Làm thế nào để token hóa một tài sản?” Mà là: “Làm thế nào để tài sản mang theo các quy tắc của chính nó khi bước vào blockchain?” Có lẽ đó mới là phần khó nhất của RWA. Tokenization tạo ra một representation. Nhưng nếu blockchain có thể hiểu và thực thi asset logic, chúng ta mới bắt đầu nói về một hệ thống tài chính on-chain thực sự. Đó là phần Dusk tôi đang muốn tìm hiểu sâu hơn. #dusk $DUSK
Tôi từng nghĩ RWA về cơ bản chỉ là đưa một tài sản thật lên blockchain.
Sau khi tìm hiểu kỹ hơn về Dusk, tôi bắt đầu nghĩ rằng giả định đó quá đơn giản.
Một tài sản tài chính không chỉ có giá trị.
Ai được phép sở hữu?
Ai có thể nhận nó?
Khi nào nó được chuyển nhượng?
Điều gì xảy ra khi quyền sở hữu thay đổi?
Và ai được phép thực hiện những hành động đó?
Nếu những quy tắc này vẫn nằm ngoài blockchain, thì việc tạo ra một token có thực sự đưa tài sản vào on-chain không?
Đây là phần khiến tôi chú ý ở @Dusk
Dusk không chỉ tiếp cận RWA từ góc độ tokenization. Với native issuance, ý tưởng thú vị hơn là đưa nhiều hơn vòng đời và logic của tài sản trực tiếp vào hạ tầng on-chain.
Điều đó có nghĩa blockchain không chỉ ghi nhận rằng:
“Đây là token của một trái phiếu.”
Mà còn có thể trở thành nơi các điều kiện liên quan đến ownership, transfer và các hoạt động của tài sản được xử lý theo những rules đã được xác định.
Đặc biệt với regulated assets, đây có thể là khác biệt quan trọng.
Một trái phiếu không trở thành permissionless chỉ vì nó có token.
Các yêu cầu về eligibility, transfer restrictions và compliance vẫn đi cùng tài sản.
Vì vậy, câu hỏi tôi đang suy nghĩ không còn là:
“Làm thế nào để token hóa một tài sản?”
Mà là:
“Làm thế nào để tài sản mang theo các quy tắc của chính nó khi bước vào blockchain?”
Có lẽ đó mới là phần khó nhất của RWA.
Tokenization tạo ra một representation.
Nhưng nếu blockchain có thể hiểu và thực thi asset logic, chúng ta mới bắt đầu nói về một hệ thống tài chính on-chain thực sự.
Đó là phần Dusk tôi đang muốn tìm hiểu sâu hơn.
#dusk $DUSK
Tokenizing a stock is not the finish line. It’s the starting line. Mình nghĩ đây là phần thú vị nhất của câu chuyện RWA. Khi một cổ phiếu được token hóa, nó đã có thể xuất hiện on-chain. Nhưng nếu nó chỉ được “đưa lên blockchain” rồi nằm đó, utility của nó vẫn khá hạn chế. Câu hỏi quan trọng hơn là: Sau khi được token hóa, tài sản đó có thể làm được gì? Đây là lý do mình chú ý đến cách @termmax tiếp cận RWA. TermMax đang mở rộng để các chứng khoán được token hóa của Ondo Global Markets có thể trở thành tài sản thế chấp cho khoản vay fixed-rate trên BNB Chain. Và điều này tạo ra một chuỗi khá thú vị: Tokenized stock → Collateral → Liquidity → Predictable borrowing cost Thay vì chỉ sở hữu một phiên bản on-chain của tài sản truyền thống, người dùng có thêm một cách để khai thác giá trị vốn của tài sản đó mà vẫn biết trước chi phí vay. Điểm mình thấy đáng chú ý ở đây không phải đơn giản là “RWA + DeFi”. Mà là: Tokenization tạo ra representation. Financial infrastructure tạo ra utility. Nếu RWA muốn tiến xa hơn việc đưa tài sản truyền thống lên blockchain, chúng cần những lớp cơ sở hạ tầng giúp chúng thực sự tham gia vào các hoạt động tài chính on-chain. Và fixed-rate lending là một trong những mảnh ghép đáng chú ý đó. Đó cũng là lý do mình nghĩ TermMax đang đứng ở một giao điểm khá thú vị giữa RWA, fixed-income và Defi. #termmax
Tokenizing a stock is not the finish line. It’s the starting line.
Mình nghĩ đây là phần thú vị nhất của câu chuyện RWA.
Khi một cổ phiếu được token hóa, nó đã có thể xuất hiện on-chain. Nhưng nếu nó chỉ được “đưa lên blockchain” rồi nằm đó, utility của nó vẫn khá hạn chế.
Câu hỏi quan trọng hơn là:
Sau khi được token hóa, tài sản đó có thể làm được gì?
Đây là lý do mình chú ý đến cách @TermMax tiếp cận RWA.
TermMax đang mở rộng để các chứng khoán được token hóa của Ondo Global Markets có thể trở thành tài sản thế chấp cho khoản vay fixed-rate trên BNB Chain.
Và điều này tạo ra một chuỗi khá thú vị:
Tokenized stock → Collateral → Liquidity → Predictable borrowing cost
Thay vì chỉ sở hữu một phiên bản on-chain của tài sản truyền thống, người dùng có thêm một cách để khai thác giá trị vốn của tài sản đó mà vẫn biết trước chi phí vay.
Điểm mình thấy đáng chú ý ở đây không phải đơn giản là “RWA + DeFi”.
Mà là:
Tokenization tạo ra representation.
Financial infrastructure tạo ra utility.
Nếu RWA muốn tiến xa hơn việc đưa tài sản truyền thống lên blockchain, chúng cần những lớp cơ sở hạ tầng giúp chúng thực sự tham gia vào các hoạt động tài chính on-chain.
Và fixed-rate lending là một trong những mảnh ghép đáng chú ý đó.
Đó cũng là lý do mình nghĩ TermMax đang đứng ở một giao điểm khá thú vị giữa RWA, fixed-income và Defi.
#termmax
Đang giao dịch bình thường mà đối phương tự nhiên đổi cách thanh toán? Đây là kiểu tình huống mình nghĩ anh em P2P rất dễ chủ quan. Order đã đặt. Thông tin đã kiểm tra. Hai bên đang giao dịch bình thường. Xong đối phương nhắn: “Tài khoản này đang lỗi, anh chuyển sang tài khoản khác giúp em nhé.” Nghe thì khá hợp lý. Nhưng vấn đề nằm ở chỗ: điều kiện giao dịch ban đầu đã thay đổi. Và đây là lúc mình sẽ không vội làm tiếp chỉ vì trước đó mọi thứ vẫn ổn. Một giao dịch đang bình thường không có nghĩa mọi thay đổi giữa chừng đều an toàn. Mình sẽ dừng lại và kiểm tra lại: 🟢 Thông tin thanh toán có còn đúng với Order không? 🟢 Tên tài khoản nhận/chuyển có khớp với thông tin giao dịch không? 🟢 Đối phương có đang yêu cầu mình thực hiện một bước khác với điều kiện ban đầu không? Nếu có thay đổi bất thường, đừng vì nghĩ: “Nãy giờ vẫn giao dịch bình thường mà.” mà bỏ qua. Đặc biệt, đừng tự ý chuyển sang Zalo/Telegram hoặc thực hiện thanh toán theo một thông tin mới chỉ vì đối phương thúc giục. Giữ giao dịch trong Order, giữ lịch sử chat và nếu có vấn đề thì dùng Appeal để Binance có đầy đủ thông tin đối chiếu. Mình thấy P2P có một cái bẫy khá dễ gặp: Cái nguy hiểm không phải lúc nào cũng xuất hiện ngay từ đầu. Đôi khi giao dịch hoàn toàn bình thường… cho đến khi một chi tiết nhỏ bị thay đổi. Vì vậy: Giao dịch đang bình thường ≠ có thể bỏ qua thay đổi giữa chừng. Thấy thay đổi → dừng lại → kiểm tra lại → rồi mới quyết định. Chậm vài giây để xác nhận vẫn tốt hơn nhanh vài giây rồi phải xử lý hậu quả. #BinanceP2PAnToan @Binance_Vietnam $BNB
Đang giao dịch bình thường mà đối phương tự nhiên đổi cách thanh toán?
Đây là kiểu tình huống mình nghĩ anh em P2P rất dễ chủ quan.
Order đã đặt.
Thông tin đã kiểm tra.
Hai bên đang giao dịch bình thường.
Xong đối phương nhắn:
“Tài khoản này đang lỗi, anh chuyển sang tài khoản khác giúp em nhé.”
Nghe thì khá hợp lý.
Nhưng vấn đề nằm ở chỗ: điều kiện giao dịch ban đầu đã thay đổi.
Và đây là lúc mình sẽ không vội làm tiếp chỉ vì trước đó mọi thứ vẫn ổn.
Một giao dịch đang bình thường không có nghĩa mọi thay đổi giữa chừng đều an toàn.
Mình sẽ dừng lại và kiểm tra lại:
🟢 Thông tin thanh toán có còn đúng với Order không?
🟢 Tên tài khoản nhận/chuyển có khớp với thông tin giao dịch không?
🟢 Đối phương có đang yêu cầu mình thực hiện một bước khác với điều kiện ban đầu không?
Nếu có thay đổi bất thường, đừng vì nghĩ:
“Nãy giờ vẫn giao dịch bình thường mà.”
mà bỏ qua.
Đặc biệt, đừng tự ý chuyển sang Zalo/Telegram hoặc thực hiện thanh toán theo một thông tin mới chỉ vì đối phương thúc giục.
Giữ giao dịch trong Order, giữ lịch sử chat và nếu có vấn đề thì dùng Appeal để Binance có đầy đủ thông tin đối chiếu.
Mình thấy P2P có một cái bẫy khá dễ gặp:
Cái nguy hiểm không phải lúc nào cũng xuất hiện ngay từ đầu.
Đôi khi giao dịch hoàn toàn bình thường…
cho đến khi một chi tiết nhỏ bị thay đổi.
Vì vậy:
Giao dịch đang bình thường ≠ có thể bỏ qua thay đổi giữa chừng.
Thấy thay đổi → dừng lại → kiểm tra lại → rồi mới quyết định.
Chậm vài giây để xác nhận vẫn tốt hơn nhanh vài giây rồi phải xử lý hậu quả.
#BinanceP2PAnToan @Binance Vietnam $BNB
Một người bạn từng hỏi tôi một câu khá đơn giản: “Nếu tôi sở hữu một phần của công ty, tại sao tôi không thể bán nó cho bất kỳ ai?” Thoạt nghe, câu hỏi đó có vẻ hợp lý. Nếu tài sản là của bạn, bạn bán nó cho người bạn muốn. Nhưng với cổ phần của một công ty tư nhân, mọi thứ không đơn giản như vậy. Một số cổ phần chỉ được chuyển cho nhà đầu tư đủ điều kiện. Lúc đó tôi nhận ra một điều: Quyền sở hữu không phải lúc nào cũng đồng nghĩa với quyền chuyển nhượng tự do. Điều này khiến tôi nghĩ đến @Dusk_Foundation Tôi thấy thú vị ở cách họ tiếp cận các tài sản tài chính được quản lý. Một tài sản on-chain không chỉ cần biết ai đang sở hữu nó. Hệ thống còn phải biết ai được phép sở hữu, ai được phép nhận và giao dịch nào cần bị từ chối. Dusk có thể kết hợp identity credentials, wallet binding và smart-contract logic để áp dụng các quy tắc về quyền sở hữu và chuyển nhượng. Đồng thời, selective disclosure cho phép bên được ủy quyền xác minh thông tin cần thiết mà không nhất thiết phải nhìn thấy toàn bộ dữ liệu của người dùng. Tôi nghĩ đây là một vấn đề rất quan trọng khi RWA bắt đầu kết nối với DeFi. Một trái phiếu không trở thành permissionless chỉ vì nó được đưa lên blockchain. Các quy tắc đi kèm tài sản vẫn phải đi cùng nó. Có thể tương lai sẽ là những tài sản vẫn có rules, nhưng các rules đó được thực thi trực tiếp trong workflow on-chain. Với tôi, đó mới là bước tiến đáng chú ý của regulated finance. Không chỉ đưa quyền sở hữu lên-chain. Mà đưa cả quyền sở hữu, eligibility, transfer restrictions và privacy vào cùng một hệ thống có thể xác minh. #dusk $DUSK
Một người bạn từng hỏi tôi một câu khá đơn giản:
“Nếu tôi sở hữu một phần của công ty, tại sao tôi không thể bán nó cho bất kỳ ai?”
Thoạt nghe, câu hỏi đó có vẻ hợp lý.
Nếu tài sản là của bạn, bạn bán nó cho người bạn muốn.
Nhưng với cổ phần của một công ty tư nhân, mọi thứ không đơn giản như vậy.
Một số cổ phần chỉ được chuyển cho nhà đầu tư đủ điều kiện.
Lúc đó tôi nhận ra một điều:
Quyền sở hữu không phải lúc nào cũng đồng nghĩa với quyền chuyển nhượng tự do.
Điều này khiến tôi nghĩ đến @Dusk
Tôi thấy thú vị ở cách họ tiếp cận các tài sản tài chính được quản lý.
Một tài sản on-chain không chỉ cần biết ai đang sở hữu nó. Hệ thống còn phải biết ai được phép sở hữu, ai được phép nhận và giao dịch nào cần bị từ chối.
Dusk có thể kết hợp identity credentials, wallet binding và smart-contract logic để áp dụng các quy tắc về quyền sở hữu và chuyển nhượng. Đồng thời, selective disclosure cho phép bên được ủy quyền xác minh thông tin cần thiết mà không nhất thiết phải nhìn thấy toàn bộ dữ liệu của người dùng.
Tôi nghĩ đây là một vấn đề rất quan trọng khi RWA bắt đầu kết nối với DeFi.
Một trái phiếu không trở thành permissionless chỉ vì nó được đưa lên blockchain.
Các quy tắc đi kèm tài sản vẫn phải đi cùng nó.
Có thể tương lai sẽ là những tài sản vẫn có rules, nhưng các rules đó được thực thi trực tiếp trong workflow on-chain.
Với tôi, đó mới là bước tiến đáng chú ý của regulated finance.
Không chỉ đưa quyền sở hữu lên-chain.
Mà đưa cả quyền sở hữu, eligibility, transfer restrictions và privacy vào cùng một hệ thống có thể xác minh.
#dusk $DUSK
Minh là một freelancer vừa nhận được một hợp đồng lớn. Khách hàng sẽ thanh toán sau 6 tháng, nhưng để bắt đầu dự án, Minh cần khoảng $10,000 để mua thiết bị và thuê thêm người. Nếu lãi suất vay thay đổi liên tục, Minh không biết chính xác chi phí vốn của mình sẽ là bao nhiêu khi dự án kết thúc. Đây chính là điều khiến mình chú ý đến @termmax Điểm cốt lõi của TermMax khá đơn giản: fixed-rate lending và fixed-term borrowing. Thay vì hoàn toàn phụ thuộc vào lãi suất thả nổi, người vay có thể biết trước mức lãi suất và kỳ hạn của vị thế. Với Minh, điều này tạo ra một khác biệt rất thực tế: Không phải cố đoán lãi suất sẽ đi đâu trong 6 tháng tới. Mà có thể lập kế hoạch chi phí vốn ngay từ khi bắt đầu. Nhưng điều thú vị là TermMax không chỉ đơn giản đưa fixed rate vào DeFi. Nó xây dựng cả một lớp hạ tầng xung quanh fixed-rate market: FT và XT giúp cấu trúc các khoản nợ có kỳ hạn cố định. Range Order cho phép thanh khoản được phân bổ theo các phạm vi lãi suất khác nhau, thay vì chỉ phụ thuộc vào một mức rate duy nhất. Các cơ chế như Smart Unwind và Order Aggregator hướng tới việc cải thiện khả năng thoát vị thế và tối ưu nguồn thanh khoản. Đó là lý do mình không nhìn TermMax đơn thuần như một lending protocol khác. Điểm đáng chú ý hơn là cách nó đưa sự có thể dự đoán của fixed income vào DeFi. Nhưng khi dòng vốn lớn hơn bước vào, một câu hỏi khác xuất hiện: Chi phí vốn có thể dự đoán được không? Nếu câu trả lời là có, fixed-rate lending không chỉ là một sản phẩm. Nó có thể trở thành một primitive quan trọng cho thị trường tín dụng on-chain. Và đó là lý do mình sẽ theo dõi TermMax kỹ hơn trong 5 ngày tới. #TermMax
Minh là một freelancer vừa nhận được một hợp đồng lớn.
Khách hàng sẽ thanh toán sau 6 tháng, nhưng để bắt đầu dự án, Minh cần khoảng $10,000 để mua thiết bị và thuê thêm người.
Nếu lãi suất vay thay đổi liên tục, Minh không biết chính xác chi phí vốn của mình sẽ là bao nhiêu khi dự án kết thúc.
Đây chính là điều khiến mình chú ý đến @TermMax
Điểm cốt lõi của TermMax khá đơn giản: fixed-rate lending và fixed-term borrowing.
Thay vì hoàn toàn phụ thuộc vào lãi suất thả nổi, người vay có thể biết trước mức lãi suất và kỳ hạn của vị thế.
Với Minh, điều này tạo ra một khác biệt rất thực tế:
Không phải cố đoán lãi suất sẽ đi đâu trong 6 tháng tới.
Mà có thể lập kế hoạch chi phí vốn ngay từ khi bắt đầu.
Nhưng điều thú vị là TermMax không chỉ đơn giản đưa fixed rate vào DeFi.
Nó xây dựng cả một lớp hạ tầng xung quanh fixed-rate market:
FT và XT giúp cấu trúc các khoản nợ có kỳ hạn cố định.
Range Order cho phép thanh khoản được phân bổ theo các phạm vi lãi suất khác nhau, thay vì chỉ phụ thuộc vào một mức rate duy nhất.
Các cơ chế như Smart Unwind và Order Aggregator hướng tới việc cải thiện khả năng thoát vị thế và tối ưu nguồn thanh khoản.
Đó là lý do mình không nhìn TermMax đơn thuần như một lending protocol khác.
Điểm đáng chú ý hơn là cách nó đưa sự có thể dự đoán của fixed income vào DeFi.
Nhưng khi dòng vốn lớn hơn bước vào, một câu hỏi khác xuất hiện:
Chi phí vốn có thể dự đoán được không?
Nếu câu trả lời là có, fixed-rate lending không chỉ là một sản phẩm.
Nó có thể trở thành một primitive quan trọng cho thị trường tín dụng on-chain.
Và đó là lý do mình sẽ theo dõi TermMax kỹ hơn trong 5 ngày tới.
#TermMax
Có một lỗi trong P2P mà tôi nghĩ nguy hiểm chính vì nó không bắt đầu bằng một khoản tiền giả. Tiền là thật. Nhưng bạn lại gán khoản tiền đó cho sai Order. Tôi từng gặp một tình huống tương tự khi xử lý hai khoản thanh toán gần nhau. Cả hai đều xuất hiện trong tài khoản, và vì một khoản vừa đến trước mắt nên phản xạ đầu tiên là nghĩ: “Đây chắc là khoản của Order mình đang mở.” Nhưng khi nhìn lại, tôi nhận ra mình đang dựa vào thứ rất dễ sai: Trí nhớ. Tôi đang nhớ mình vừa tạo Order nào, số tiền bao nhiêu và khoản nào đáng lẽ phải đến trước. Điều đó khiến tôi nghĩ lại cách mình kiểm tra một giao dịch trên Binance P2P. Nếu có nhiều Order hoặc nhiều khoản chuyển tiền diễn ra gần nhau, tôi không chỉ hỏi: “Tiền đã vào chưa?” Tôi hỏi thêm: “Khoản tiền này thuộc chính xác Order nào?” Tôi đối chiếu Order đang xử lý với số tiền thực nhận, thông tin người gửi và các chi tiết của khoản thanh toán. Nếu không thể xác định rõ mối liên hệ giữa khoản tiền và Order, tôi không tự suy đoán chỉ vì số tiền nhìn có vẻ đúng. Đây cũng là lý do tôi không muốn xử lý nhiều Order chỉ dựa vào trí nhớ hoặc thói quen. Khi dữ liệu nằm trước mắt, tôi muốn đối chiếu với chính Order hiện tại thay vì dựa vào những gì mình nghĩ mình vừa làm. Với tôi, đây là một khác biệt nhỏ nhưng rất quan trọng: “Tiền đã vào” chỉ cho biết có một khoản tiền xuất hiện. “Tiền này thuộc về Order này” mới xác nhận được giao dịch mà tôi đang xử lý. Đôi khi sai lầm không phải là nhận nhầm tiền. Mà là nhận đúng tiền, nhưng đặt nó vào sai giao dịch. #BinanceP2PAnToan @Binance_Vietnam $BNB
Có một lỗi trong P2P mà tôi nghĩ nguy hiểm chính vì nó không bắt đầu bằng một khoản tiền giả.
Tiền là thật.
Nhưng bạn lại gán khoản tiền đó cho sai Order.
Tôi từng gặp một tình huống tương tự khi xử lý hai khoản thanh toán gần nhau. Cả hai đều xuất hiện trong tài khoản, và vì một khoản vừa đến trước mắt nên phản xạ đầu tiên là nghĩ: “Đây chắc là khoản của Order mình đang mở.”
Nhưng khi nhìn lại, tôi nhận ra mình đang dựa vào thứ rất dễ sai:
Trí nhớ.
Tôi đang nhớ mình vừa tạo Order nào, số tiền bao nhiêu và khoản nào đáng lẽ phải đến trước.
Điều đó khiến tôi nghĩ lại cách mình kiểm tra một giao dịch trên Binance P2P.
Nếu có nhiều Order hoặc nhiều khoản chuyển tiền diễn ra gần nhau, tôi không chỉ hỏi:
“Tiền đã vào chưa?”
Tôi hỏi thêm:
“Khoản tiền này thuộc chính xác Order nào?”
Tôi đối chiếu Order đang xử lý với số tiền thực nhận, thông tin người gửi và các chi tiết của khoản thanh toán. Nếu không thể xác định rõ mối liên hệ giữa khoản tiền và Order, tôi không tự suy đoán chỉ vì số tiền nhìn có vẻ đúng.
Đây cũng là lý do tôi không muốn xử lý nhiều Order chỉ dựa vào trí nhớ hoặc thói quen. Khi dữ liệu nằm trước mắt, tôi muốn đối chiếu với chính Order hiện tại thay vì dựa vào những gì mình nghĩ mình vừa làm.
Với tôi, đây là một khác biệt nhỏ nhưng rất quan trọng:
“Tiền đã vào” chỉ cho biết có một khoản tiền xuất hiện.
“Tiền này thuộc về Order này” mới xác nhận được giao dịch mà tôi đang xử lý.
Đôi khi sai lầm không phải là nhận nhầm tiền.
Mà là nhận đúng tiền, nhưng đặt nó vào sai giao dịch.
#BinanceP2PAnToan @Binance Vietnam $BNB
Tôi từng nghĩ việc mở một công ty cùng vài người bạn khá đơn giản. Mỗi người góp một phần vốn, thống nhất tỷ lệ sở hữu, rồi bắt đầu kinh doanh. Nhưng khi công ty phát triển, câu hỏi không còn chỉ là ai góp bao nhiêu tiền? Ai đang sở hữu bao nhiêu? Cổ tức được phân phối cho ai? Và những thay đổi đó được ghi nhận ở đâu? Lúc đó tôi nhận ra một điều: Phát hành một tài sản chỉ là điểm bắt đầu. Điều này khiến tôi nghĩ đến @Dusk_Foundation Khi tìm hiểu Dusk, tôi thấy thú vị ở khái niệm native issuance. Tokenization thường được hiểu là tạo một token đại diện cho một tài sản. Nhưng với native issuance, chính tài sản có thể được tạo và quản lý on-chain, để các hoạt động như issuance, transfer, servicing và settlement được thiết kế quanh cùng một hệ thống. Điều này đặc biệt quan trọng với các tài sản tài chính được quản lý. Một trái phiếu hay equity không kết thúc vòng đời ngay sau khi được phát hành. Nó còn có quyền sở hữu, điều kiện chuyển nhượng, corporate actions, investor updates và reporting cần được xử lý theo thời gian. Dusk đang hướng tới việc đưa những workflow đó vào cùng một hạ tầng, thay vì để ownership, transfer và servicing nằm rải rác trên nhiều hệ thống khác nhau. Đó là phần tôi thấy thú vị. Blockchain không chỉ nên giúp chúng ta tạo ra một token. Liệu tài sản có thể được tạo, quản lý và chuyển giao on-chain trong suốt vòng đời của nó, trong khi privacy, compliance và settlement vẫn được duy trì? Với tôi, đó mới là ý nghĩa sâu hơn của việc đưa tài chính lên-chain. Không chỉ số hóa tài sản. Mà xây dựng một hạ tầng nơi vòng đời của tài sản có thể được quản lý ngay từ đầu. #dusk $DUSK
Tôi từng nghĩ việc mở một công ty cùng vài người bạn khá đơn giản.
Mỗi người góp một phần vốn, thống nhất tỷ lệ sở hữu, rồi bắt đầu kinh doanh.
Nhưng khi công ty phát triển, câu hỏi không còn chỉ là ai góp bao nhiêu tiền?
Ai đang sở hữu bao nhiêu?
Cổ tức được phân phối cho ai? Và những thay đổi đó được ghi nhận ở đâu?
Lúc đó tôi nhận ra một điều:
Phát hành một tài sản chỉ là điểm bắt đầu.
Điều này khiến tôi nghĩ đến @Dusk
Khi tìm hiểu Dusk, tôi thấy thú vị ở khái niệm native issuance.
Tokenization thường được hiểu là tạo một token đại diện cho một tài sản. Nhưng với native issuance, chính tài sản có thể được tạo và quản lý on-chain, để các hoạt động như issuance, transfer, servicing và settlement được thiết kế quanh cùng một hệ thống.
Điều này đặc biệt quan trọng với các tài sản tài chính được quản lý.
Một trái phiếu hay equity không kết thúc vòng đời ngay sau khi được phát hành. Nó còn có quyền sở hữu, điều kiện chuyển nhượng, corporate actions, investor updates và reporting cần được xử lý theo thời gian.
Dusk đang hướng tới việc đưa những workflow đó vào cùng một hạ tầng, thay vì để ownership, transfer và servicing nằm rải rác trên nhiều hệ thống khác nhau.
Đó là phần tôi thấy thú vị.
Blockchain không chỉ nên giúp chúng ta tạo ra một token.
Liệu tài sản có thể được tạo, quản lý và chuyển giao on-chain trong suốt vòng đời của nó, trong khi privacy, compliance và settlement vẫn được duy trì?
Với tôi, đó mới là ý nghĩa sâu hơn của việc đưa tài chính lên-chain.
Không chỉ số hóa tài sản.
Mà xây dựng một hạ tầng nơi vòng đời của tài sản có thể được quản lý ngay từ đầu.
#dusk $DUSK
Đă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