Binance Square
maryamnoor009
1.3k Bài đăng

maryamnoor009

483 Đang theo dõi
971 Người theo dõi
1.7K+ Đã thích
Bài đăng
·
--
Đúng một phần
Tuần trước tôi lục lọi mô hình giao dịch bí mật của DUSK và bị kẹt ở một điều ít được nhắc đến: cấu trúc phí gas giữa giao dịch được che chắn và giao dịch minh bạch không đối xứng, và sự bất đối xứng đó nói lên rất nhiều về việc họ thực sự đang xây cho ai. $DUSK ,#dusk @Dusk_Foundation Điều khiến tôi chú ý là các giao dịch bảo toàn quyền riêng tư trên Dusk tốn chi phí tính toán nhiều hơn; và thay vì giả vờ rằng điều đó không đúng, mô hình phí chỉ phản ánh nó một cách trực tiếp. Hầu hết các chuỗi khi gắn thêm tính năng quyền riêng tư đều tìm cách làm mượt vấn đề này hoặc trợ giá từ sớm để trông có vẻ cạnh tranh. Dusk thì không. Nếu bạn đang chuyển một chứng khoán đã được quản lý thông qua logic thanh toán kiểu Zedger, bạn đang trả cho phần chi phí xác minh để đảm bảo tuân thủ, chứ không chỉ là "ẩn danh". Đó là một triết lý thiết kế khác so với đa số L1 đang chạy theo các con số thông lượng để thu hút người dùng phổ thông. Tôi đã kiểm tra một vài giao dịch trên testnet và khoảng cách giữa các lệnh chuyển đơn giản và các giao dịch được giữ kín là khá rõ rệt, không phải chỉ là mức chênh “nhỏ”. Điều đó khiến tôi nghĩ rằng chain này không tối ưu cho người dùng muốn các giao dịch hoán đổi rẻ và nhanh; họ đang tối ưu cho các tổ chức cần quyền riêng tư có thể kiểm tra/audit được và sẵn sàng trả tiền để đảm bảo đúng đắn. Chuyện đặt cược vào việc ai xuất hiện trước là đúng hay sai thì hiện tại tôi vẫn chưa biết.
Tuần trước tôi lục lọi mô hình giao dịch bí mật của DUSK và bị kẹt ở một điều ít được nhắc đến: cấu trúc phí gas giữa giao dịch được che chắn và giao dịch minh bạch không đối xứng, và sự bất đối xứng đó nói lên rất nhiều về việc họ thực sự đang xây cho ai. $DUSK ,#dusk @Dusk
Điều khiến tôi chú ý là các giao dịch bảo toàn quyền riêng tư trên Dusk tốn chi phí tính toán nhiều hơn; và thay vì giả vờ rằng điều đó không đúng, mô hình phí chỉ phản ánh nó một cách trực tiếp. Hầu hết các chuỗi khi gắn thêm tính năng quyền riêng tư đều tìm cách làm mượt vấn đề này hoặc trợ giá từ sớm để trông có vẻ cạnh tranh. Dusk thì không. Nếu bạn đang chuyển một chứng khoán đã được quản lý thông qua logic thanh toán kiểu Zedger, bạn đang trả cho phần chi phí xác minh để đảm bảo tuân thủ, chứ không chỉ là "ẩn danh". Đó là một triết lý thiết kế khác so với đa số L1 đang chạy theo các con số thông lượng để thu hút người dùng phổ thông. Tôi đã kiểm tra một vài giao dịch trên testnet và khoảng cách giữa các lệnh chuyển đơn giản và các giao dịch được giữ kín là khá rõ rệt, không phải chỉ là mức chênh “nhỏ”. Điều đó khiến tôi nghĩ rằng chain này không tối ưu cho người dùng muốn các giao dịch hoán đổi rẻ và nhanh; họ đang tối ưu cho các tổ chức cần quyền riêng tư có thể kiểm tra/audit được và sẵn sàng trả tiền để đảm bảo đúng đắn. Chuyện đặt cược vào việc ai xuất hiện trước là đúng hay sai thì hiện tại tôi vẫn chưa biết.
Đúng một phần
Điều thu hút sự chú ý của tôi khi đọc qua cấu trúc quản trị thực tế của Dusk Network là có một khoảng trống giữa cách định khung và cơ chế vận hành. $DUSK , được mô tả ở khắp mọi nơi như chìa khóa cho quản trị on-chain, nơi người nắm giữ biểu quyết các tham số giao thức, nhưng khi tôi xem cách các đề xuất thực sự được xử lý, luồng vận hành lại đi qua một Core R&D Team và một Governance Council riêng trước tiên—theo kiểu RFC: các bản nộp được rà soát về tính khả thi kỹ thuật và mức độ phù hợp về quy định—rồi sau đó, bất cứ điều gì giống như một cuộc bỏ phiếu của cộng đồng mới đi vào bức tranh. Trong khi đó, quản trị on-chain đầy đủ cho người nắm giữ token vẫn được liệt kê là sẽ triển khai trong tương lai chứ chưa hoạt động. #dusk , đang định vị mình như hạ tầng cho tài chính được quản lý, vì vậy việc sắp xếp như vậy có lẽ không phải ngẫu nhiên: bạn không thể trao quyền biểu quyết “thô” cho một đám đông khi kết quả phải đáp ứng các nghĩa vụ theo MiCA. Nhưng điều đó cũng có nghĩa là "tăng trưởng do cộng đồng dẫn dắt" hiện nay mang tính kỳ vọng nhiều hơn là vận hành; vai trò của cộng đồng vào lúc này trông giống với việc đề xuất và theo dõi hơn là quyết định. Tôi không xem đó là một sự phê bình, mà là một câu hỏi về thời điểm. Điều tôi chưa chắc là liệu @Dusk_Foundation ,roadmap thực sự có chuyển trọng lượng quyết định sang người nắm giữ token vào sau này hay không, hay tầng rà soát sẽ trở thành vĩnh viễn vì tính bắt buộc.
Điều thu hút sự chú ý của tôi khi đọc qua cấu trúc quản trị thực tế của Dusk Network là có một khoảng trống giữa cách định khung và cơ chế vận hành. $DUSK , được mô tả ở khắp mọi nơi như chìa khóa cho quản trị on-chain, nơi người nắm giữ biểu quyết các tham số giao thức, nhưng khi tôi xem cách các đề xuất thực sự được xử lý, luồng vận hành lại đi qua một Core R&D Team và một Governance Council riêng trước tiên—theo kiểu RFC: các bản nộp được rà soát về tính khả thi kỹ thuật và mức độ phù hợp về quy định—rồi sau đó, bất cứ điều gì giống như một cuộc bỏ phiếu của cộng đồng mới đi vào bức tranh. Trong khi đó, quản trị on-chain đầy đủ cho người nắm giữ token vẫn được liệt kê là sẽ triển khai trong tương lai chứ chưa hoạt động. #dusk , đang định vị mình như hạ tầng cho tài chính được quản lý, vì vậy việc sắp xếp như vậy có lẽ không phải ngẫu nhiên: bạn không thể trao quyền biểu quyết “thô” cho một đám đông khi kết quả phải đáp ứng các nghĩa vụ theo MiCA. Nhưng điều đó cũng có nghĩa là "tăng trưởng do cộng đồng dẫn dắt" hiện nay mang tính kỳ vọng nhiều hơn là vận hành; vai trò của cộng đồng vào lúc này trông giống với việc đề xuất và theo dõi hơn là quyết định. Tôi không xem đó là một sự phê bình, mà là một câu hỏi về thời điểm. Điều tôi chưa chắc là liệu @Dusk ,roadmap thực sự có chuyển trọng lượng quyết định sang người nắm giữ token vào sau này hay không, hay tầng rà soát sẽ trở thành vĩnh viễn vì tính bắt buộc.
Tôi đã mất cả một giờ lần theo xem $TMX thực sự xuất hiện ở đâu bên trong Ten (#TermMax , @termmax ) ngoài các màn hình đổi chác, và điều khiến tôi chú ý là mức độ “yên lặng” của “tính năng tiện ích” so với cách nó được tô đậm trong phần đóng khung. Token được giới thiệu như governance-plus-incentive-plus-fee-layer, nhưng trong luồng nhiệm vụ thực tế, việc staking và tham gia governance lại giống như một mạch riêng mà gần như chẳng ai theo — hầu hết hoạt động lại tập trung ở phía có thể giao dịch, thứ mà token được cho là “hơn” so với nó. Một lựa chọn thiết kế nổi bật: các hàm tiện ích tồn tại và vẫn hoạt động về mặt kỹ thuật, nhưng chúng không phải là đường đi mặc định mà một người dùng mới được hướng tới, nên “beyond trading” (vượt ra ngoài giao dịch) lại giống như một tuyên bố trong lộ trình hơn là hành vi hiện hữu. Điều đó khiến tôi tự hỏi liệu tiện ích mà phải tự tìm mới thấy có được tính là tiện ích không, hay chỉ là tiềm năng đang được “chia thì” như hiện tại. Có lẽ khoảng cách này sẽ được lấp đầy khi governance trưởng thành. Hoặc có lẽ đó là cách mọi token đều bắt đầu. Khó mà biết chắc chỉ từ một lần rà soát.
Tôi đã mất cả một giờ lần theo xem $TMX thực sự xuất hiện ở đâu bên trong Ten (#TermMax , @TermMax ) ngoài các màn hình đổi chác, và điều khiến tôi chú ý là mức độ “yên lặng” của “tính năng tiện ích” so với cách nó được tô đậm trong phần đóng khung. Token được giới thiệu như governance-plus-incentive-plus-fee-layer, nhưng trong luồng nhiệm vụ thực tế, việc staking và tham gia governance lại giống như một mạch riêng mà gần như chẳng ai theo — hầu hết hoạt động lại tập trung ở phía có thể giao dịch, thứ mà token được cho là “hơn” so với nó. Một lựa chọn thiết kế nổi bật: các hàm tiện ích tồn tại và vẫn hoạt động về mặt kỹ thuật, nhưng chúng không phải là đường đi mặc định mà một người dùng mới được hướng tới, nên “beyond trading” (vượt ra ngoài giao dịch) lại giống như một tuyên bố trong lộ trình hơn là hành vi hiện hữu. Điều đó khiến tôi tự hỏi liệu tiện ích mà phải tự tìm mới thấy có được tính là tiện ích không, hay chỉ là tiềm năng đang được “chia thì” như hiện tại. Có lẽ khoảng cách này sẽ được lấp đầy khi governance trưởng thành. Hoặc có lẽ đó là cách mọi token đều bắt đầu. Khó mà biết chắc chỉ từ một lần rà soát.
Đã xác minh
Thứ đọng lại trong tôi không phải là lịch phát hành như vậy, mà là việc chỉ có rất ít trong nguồn cung đang lưu hành của DUSK thực sự đi qua những cơ chế mà tài liệu nhấn mạnh. Khi đọc phần thiết kế staking và mở khóa của Dusk cho,#dusk , $DUSK , @Dusk_Foundation , câu chuyện tập trung vào động lực cho trình xác thực và an ninh mạng dài hạn, nhưng đường cong mở khóa trong ngắn hạn lại kể một câu chuyện khác: các phân bổ sớm cho đội ngũ và quỹ hệ sinh thái được lịch trình hóa theo cách dồn thanh khoản lên sớm, trước khi việc tham gia staking kịp trưởng thành. Một lựa chọn thiết kế nổi bật: khoảng cách giữa thời điểm token trở nên chuyển nhượng được và thời điểm mạng thực sự thấy được giá trị sử dụng (các smart contract bảo mật, việc thanh toán tài sản được quản lý) có mức độ áp dụng đáng kể không phải là nhỏ. Nó không hẳn là một cờ đỏ, mà hơn là sự lệch nhịp: token đến theo một lịch cố định, còn việc sử dụng thì đến theo một quỹ đạo không chắc chắn. Tôi cứ so sánh biểu đồ cung với lộ trình và nhận ra chúng thực sự không nói chuyện với nhau. Điều này khiến tôi tự hỏi: có bao nhiêu câu chuyện “token tiện ích” thực ra chỉ là lịch mở khóa khoác lên mình một tình huống sử dụng.
Thứ đọng lại trong tôi không phải là lịch phát hành như vậy, mà là việc chỉ có rất ít trong nguồn cung đang lưu hành của DUSK thực sự đi qua những cơ chế mà tài liệu nhấn mạnh. Khi đọc phần thiết kế staking và mở khóa của Dusk cho,#dusk , $DUSK , @Dusk , câu chuyện tập trung vào động lực cho trình xác thực và an ninh mạng dài hạn, nhưng đường cong mở khóa trong ngắn hạn lại kể một câu chuyện khác: các phân bổ sớm cho đội ngũ và quỹ hệ sinh thái được lịch trình hóa theo cách dồn thanh khoản lên sớm, trước khi việc tham gia staking kịp trưởng thành. Một lựa chọn thiết kế nổi bật: khoảng cách giữa thời điểm token trở nên chuyển nhượng được và thời điểm mạng thực sự thấy được giá trị sử dụng (các smart contract bảo mật, việc thanh toán tài sản được quản lý) có mức độ áp dụng đáng kể không phải là nhỏ. Nó không hẳn là một cờ đỏ, mà hơn là sự lệch nhịp: token đến theo một lịch cố định, còn việc sử dụng thì đến theo một quỹ đạo không chắc chắn. Tôi cứ so sánh biểu đồ cung với lộ trình và nhận ra chúng thực sự không nói chuyện với nhau. Điều này khiến tôi tự hỏi: có bao nhiêu câu chuyện “token tiện ích” thực ra chỉ là lịch mở khóa khoác lên mình một tình huống sử dụng.
Điều đọng lại với tôi không phải là chính kiến trúc quyền riêng tư, mà là cấu hình mặc định khi bạn kết nối một ví lần đầu trên TMX. Chế độ tuân thủ bật sẵn theo mặc định; phần định tuyến “quyền riêng tư đầy đủ” nằm sâu hơn một nấc, ẩn sau một menu Cài đặt mà đa số người dùng sẽ không mở ngay từ lần xem đầu tiên. $TMX, #TermMax , @termmax , nói về sự minh bạch và quyền riêng tư như thể chúng được cân trọng như nhau, nhưng trải nghiệm sản phẩm thực tế lại lặng lẽ chọn phe trước khi người dùng quyết định. Nhìn vào luồng tác vụ, có lẽ khoảng 80% diện tích giao diện được dành cho các bản xem trước giao dịch có thể đọc theo chuẩn tuân thủ, trong khi các tham số quyền riêng tư nâng cao lại nằm trong một accordion được thu gọn. Điều đó không hẳn là một lỗi; thậm chí có thể là lựa chọn onboarding hợp lý vì lý do tuân thủ quy định, nhưng nó cũng có nghĩa là “sự cùng tồn tại” trong phần giới thiệu thực chất là một quyết định về thứ tự: tuân thủ trước, quyền riêng tư dành cho ai chịu đi tìm. Tôi cứ tự hỏi liệu thứ tự này chỉ là giàn giáo tạm thời cho giai đoạn áp dụng sớm, hay đó thực sự là hình dạng vĩnh viễn của sản phẩm sau khi các ưu đãi đã ổn định. Dù thế nào đi nữa, mặc định đang làm rất nhiều công việc kể chuyện thầm lặng mà phần nội dung marketing không hề nhắc tới.
Điều đọng lại với tôi không phải là chính kiến trúc quyền riêng tư, mà là cấu hình mặc định khi bạn kết nối một ví lần đầu trên TMX. Chế độ tuân thủ bật sẵn theo mặc định; phần định tuyến “quyền riêng tư đầy đủ” nằm sâu hơn một nấc, ẩn sau một menu Cài đặt mà đa số người dùng sẽ không mở ngay từ lần xem đầu tiên. $TMX, #TermMax , @TermMax , nói về sự minh bạch và quyền riêng tư như thể chúng được cân trọng như nhau, nhưng trải nghiệm sản phẩm thực tế lại lặng lẽ chọn phe trước khi người dùng quyết định. Nhìn vào luồng tác vụ, có lẽ khoảng 80% diện tích giao diện được dành cho các bản xem trước giao dịch có thể đọc theo chuẩn tuân thủ, trong khi các tham số quyền riêng tư nâng cao lại nằm trong một accordion được thu gọn. Điều đó không hẳn là một lỗi; thậm chí có thể là lựa chọn onboarding hợp lý vì lý do tuân thủ quy định, nhưng nó cũng có nghĩa là “sự cùng tồn tại” trong phần giới thiệu thực chất là một quyết định về thứ tự: tuân thủ trước, quyền riêng tư dành cho ai chịu đi tìm. Tôi cứ tự hỏi liệu thứ tự này chỉ là giàn giáo tạm thời cho giai đoạn áp dụng sớm, hay đó thực sự là hình dạng vĩnh viễn của sản phẩm sau khi các ưu đãi đã ổn định. Dù thế nào đi nữa, mặc định đang làm rất nhiều công việc kể chuyện thầm lặng mà phần nội dung marketing không hề nhắc tới.
Đã xác minh
Điều gây ấn tượng không phải là phần pitch RWA, mà là một chi tiết “lặng” hơn về cách Dusk, $DUSK , #dusk , thực sự cấu trúc sự tuân thủ ở cấp độ giao thức, thay vì chỉ gắn nó lên trên. Hầu hết các câu chuyện về RWA đều mô tả việc phân quyền,@Dusk_Foundation như một tính năng được xếp lớp bên trên một chuỗi chung — các cổng KYC, danh sách cho phép, một lựa chọn dạng checkbox ở cấp ứng dụng. Thiết kế Zedger của Dusk và cơ chế thanh toán bảo mật đưa logic đó “đi xuống” trong mô hình giao dịch nền tảng, nên quyền riêng tư và việc công bố không phải là các tiện ích cạnh tranh mà đồng tồn tại ngay từ mặc định. Điều khiến tôi nhớ nhất là: nhà phát hành được quản lý được hưởng lợi ngay lập tức, bởi các nguyên tắc tuân thủ đã là hạ tầng chịu tải chính, trong khi một người nắm giữ hoặc nhà giao dịch thông thường gần như không có gì khác biệt theo ngày thường — không có dashboard, không có lợi thế nhìn thấy rõ, chỉ là một chuỗi âm thầm giả định các quy tắc theo chuẩn thể chế trước khi thể chế thực sự xuất hiện. Trình tự như vậy thật kỳ lạ. Thông thường hoạt động bán lẻ là lớp hiển thị, còn hạ tầng thể chế được hứa rằng “sẽ có sau”. Ở đây thì bị đảo ngược — hạ tầng được xây trước, và phần sử dụng sẽ chứng minh điều đó vẫn chưa thực sự đến. Điều này khiến tôi tự hỏi liệu đó là sự thận trọng mang tính kỷ luật hay một canh bạc dựa trên một thị trường vẫn đang cân nhắc xem mình có muốn đến mức cấu trúc như vậy hay không.
Điều gây ấn tượng không phải là phần pitch RWA, mà là một chi tiết “lặng” hơn về cách Dusk, $DUSK , #dusk , thực sự cấu trúc sự tuân thủ ở cấp độ giao thức, thay vì chỉ gắn nó lên trên. Hầu hết các câu chuyện về RWA đều mô tả việc phân quyền,@Dusk như một tính năng được xếp lớp bên trên một chuỗi chung — các cổng KYC, danh sách cho phép, một lựa chọn dạng checkbox ở cấp ứng dụng. Thiết kế Zedger của Dusk và cơ chế thanh toán bảo mật đưa logic đó “đi xuống” trong mô hình giao dịch nền tảng, nên quyền riêng tư và việc công bố không phải là các tiện ích cạnh tranh mà đồng tồn tại ngay từ mặc định. Điều khiến tôi nhớ nhất là: nhà phát hành được quản lý được hưởng lợi ngay lập tức, bởi các nguyên tắc tuân thủ đã là hạ tầng chịu tải chính, trong khi một người nắm giữ hoặc nhà giao dịch thông thường gần như không có gì khác biệt theo ngày thường — không có dashboard, không có lợi thế nhìn thấy rõ, chỉ là một chuỗi âm thầm giả định các quy tắc theo chuẩn thể chế trước khi thể chế thực sự xuất hiện. Trình tự như vậy thật kỳ lạ. Thông thường hoạt động bán lẻ là lớp hiển thị, còn hạ tầng thể chế được hứa rằng “sẽ có sau”. Ở đây thì bị đảo ngược — hạ tầng được xây trước, và phần sử dụng sẽ chứng minh điều đó vẫn chưa thực sự đến. Điều này khiến tôi tự hỏi liệu đó là sự thận trọng mang tính kỷ luật hay một canh bạc dựa trên một thị trường vẫn đang cân nhắc xem mình có muốn đến mức cấu trúc như vậy hay không.
Đã dành một giờ trong tài liệu Dusk, chờ đợi bức tường ngôn ngữ chuẩn mực “đạt chuẩn thể chế” như thường lệ, nhưng cuối cùng lại rơi vào thứ gì đó nhỏ hơn: bộ công cụ dành cho nhà phát triển trông như được xây dựng trước khi bản chào mời về tuân thủ được hoàn thiện, chứ không phải sau đó. Dusk ($DUSK , #dusk , @Dusk_Foundation ) tự quảng bá về tài chính được quản lý và thanh toán bí mật, nhưng phần thiết lập Rusk VM và các ví dụ hợp đồng thông minh Piecrust lại có cảm giác khá “lãnh đạm” với cách khung đó—chúng chỉ đang cố gắng làm cho việc thực thi zero-knowledge dễ hiểu khi chạy cục bộ. Một chi tiết đọng lại với tôi: phần hướng dẫn chạy node và faucet testnet lại được hoàn thiện hơn nhiều so với các trang quan hệ đối tác theo hướng thể chế, vốn vẫn chủ yếu là thông báo nhưng thiếu các chi tiết tích hợp cụ thể. Điều đó trái ngược với những gì thông điệp gợi ý. Nó khiến tôi tự hỏi liệu câu chuyện “thể chế” thực ra lại đi sau việc nhà phát triển đã bắt đầu dùng rộng rãi, thay vì ngược lại: ngân hàng và nhà quản lý tài sản sẽ không đụng tới thứ này cho đến khi các bên xây dựng độc lập đã đủ thời gian “stress-test” những nền tảng cốt lõi đó trong công khai. Không ai hứa hẹn điều gì cho nhà phát triển cả—họ chỉ lặng lẽ để lại những tài liệu tốt hơn. Và từ đó nảy sinh câu hỏi thực sự: Dusk đang được xây cho các tổ chức, hay đang chỉ được bán cho họ trong khi có thứ gì khác được xây dựng bên dưới?
Đã dành một giờ trong tài liệu Dusk, chờ đợi bức tường ngôn ngữ chuẩn mực “đạt chuẩn thể chế” như thường lệ, nhưng cuối cùng lại rơi vào thứ gì đó nhỏ hơn: bộ công cụ dành cho nhà phát triển trông như được xây dựng trước khi bản chào mời về tuân thủ được hoàn thiện, chứ không phải sau đó. Dusk ($DUSK , #dusk , @Dusk ) tự quảng bá về tài chính được quản lý và thanh toán bí mật, nhưng phần thiết lập Rusk VM và các ví dụ hợp đồng thông minh Piecrust lại có cảm giác khá “lãnh đạm” với cách khung đó—chúng chỉ đang cố gắng làm cho việc thực thi zero-knowledge dễ hiểu khi chạy cục bộ. Một chi tiết đọng lại với tôi: phần hướng dẫn chạy node và faucet testnet lại được hoàn thiện hơn nhiều so với các trang quan hệ đối tác theo hướng thể chế, vốn vẫn chủ yếu là thông báo nhưng thiếu các chi tiết tích hợp cụ thể. Điều đó trái ngược với những gì thông điệp gợi ý. Nó khiến tôi tự hỏi liệu câu chuyện “thể chế” thực ra lại đi sau việc nhà phát triển đã bắt đầu dùng rộng rãi, thay vì ngược lại: ngân hàng và nhà quản lý tài sản sẽ không đụng tới thứ này cho đến khi các bên xây dựng độc lập đã đủ thời gian “stress-test” những nền tảng cốt lõi đó trong công khai. Không ai hứa hẹn điều gì cho nhà phát triển cả—họ chỉ lặng lẽ để lại những tài liệu tốt hơn. Và từ đó nảy sinh câu hỏi thực sự: Dusk đang được xây cho các tổ chức, hay đang chỉ được bán cho họ trong khi có thứ gì khác được xây dựng bên dưới?
Điều cứ kéo tôi mãi trong lúc lục lọi lớp tuân thủ của $TMX là cách khung “permissionless” (phi cho phép) ngầm giả định một đường dẫn mặc định duy nhất, nhưng kiến trúc thực tế lại tách nhánh ngay từ sớm. #TermMax @termmax ,Kiến trúc tiếp thị bản thân như là tương thích tuân thủ cho thị trường mở, nhưng cấu hình mặc định lại định tuyến mọi giao dịch qua một điểm kiểm tra xác minh, trong khi chế độ permissionless lại nằm sâu hơn một lớp, bị chặn bởi các cài đặt nâng cao mà hầu hết người dùng sẽ không đụng tới. Tôi đã xem một giao dịch thử phải thực hiện thêm bốn bước chỉ để vượt qua hook tuân thủ tiêu chuẩn, và tài liệu mô tả điều này là “tính linh hoạt” thay vì sự vướng víu. Đây là một lựa chọn thiết kế nhỏ, nhưng nó cho thấy ngay từ đầu kiến trúc thật sự được xây cho ai: các trung gian được quản lý nhận được con đường “mượt”, còn trường hợp sử dụng permissionless mà mọi người hay bàn trong các bài viết thì về mặt kỹ thuật là có thể, nhưng trên thực tế lại là một tùy chọn tách rời. Tôi cứ kỳ vọng hai lộ trình sẽ gặp nhau ở đâu đó giữa chừng, và rốt cuộc chúng không bao giờ thực sự hội tụ. Có lẽ vậy là ổn; có lẽ “compliance-first” (ưu tiên tuân thủ) là cách thực tế duy nhất để gây dựng niềm tin ở đây, nhưng tôi không chắc “permissionless” có phải là từ đúng để nói về một chế độ mà bạn phải tự đào bới mới tìm thấy.
Điều cứ kéo tôi mãi trong lúc lục lọi lớp tuân thủ của $TMX là cách khung “permissionless” (phi cho phép) ngầm giả định một đường dẫn mặc định duy nhất, nhưng kiến trúc thực tế lại tách nhánh ngay từ sớm. #TermMax @TermMax ,Kiến trúc tiếp thị bản thân như là tương thích tuân thủ cho thị trường mở, nhưng cấu hình mặc định lại định tuyến mọi giao dịch qua một điểm kiểm tra xác minh, trong khi chế độ permissionless lại nằm sâu hơn một lớp, bị chặn bởi các cài đặt nâng cao mà hầu hết người dùng sẽ không đụng tới. Tôi đã xem một giao dịch thử phải thực hiện thêm bốn bước chỉ để vượt qua hook tuân thủ tiêu chuẩn, và tài liệu mô tả điều này là “tính linh hoạt” thay vì sự vướng víu. Đây là một lựa chọn thiết kế nhỏ, nhưng nó cho thấy ngay từ đầu kiến trúc thật sự được xây cho ai: các trung gian được quản lý nhận được con đường “mượt”, còn trường hợp sử dụng permissionless mà mọi người hay bàn trong các bài viết thì về mặt kỹ thuật là có thể, nhưng trên thực tế lại là một tùy chọn tách rời. Tôi cứ kỳ vọng hai lộ trình sẽ gặp nhau ở đâu đó giữa chừng, và rốt cuộc chúng không bao giờ thực sự hội tụ. Có lẽ vậy là ổn; có lẽ “compliance-first” (ưu tiên tuân thủ) là cách thực tế duy nhất để gây dựng niềm tin ở đây, nhưng tôi không chắc “permissionless” có phải là từ đúng để nói về một chế độ mà bạn phải tự đào bới mới tìm thấy.
Đúng một phần
Xem bản dịch
During the CreatorPad task, what stayed with me about Dusk was how its governance test for community-driven growth actually begins. $DUSK , #dusk , @Dusk_Foundation , frames OpenDusk as handing direction to the community via a treasury fed by the ~11.8M previously unminted block rewards (plus ~6.8M yearly) that had effectively acted as a continuous burn. Yet the mechanism that reaches the vote is a five-member committee that sources and refines every proposal before any stake-weighted decision occurs, and eligibility itself is narrowed to active provisioners who both secure the network and have performed a stake operation in the prior three months. The promised broader growth sits downstream of that filter. I keep wondering whether the first real beneficiaries of this shift are the same active stakers already securing the chain, or whether the structure can open further once the initial redirection is live.
During the CreatorPad task, what stayed with me about Dusk was how its governance test for community-driven growth actually begins. $DUSK , #dusk , @Dusk , frames OpenDusk as handing direction to the community via a treasury fed by the ~11.8M previously unminted block rewards (plus ~6.8M yearly) that had effectively acted as a continuous burn. Yet the mechanism that reaches the vote is a five-member committee that sources and refines every proposal before any stake-weighted decision occurs, and eligibility itself is narrowed to active provisioners who both secure the network and have performed a stake operation in the prior three months. The promised broader growth sits downstream of that filter. I keep wondering whether the first real beneficiaries of this shift are the same active stakers already securing the chain, or whether the structure can open further once the initial redirection is live.
Xem bản dịch
What stuck with me wasn't the yield number itself, it was where I noticed it. Exploring $TMX for a CreatorPad task on #TermMax ,the APY sits front and center on the entry screen, big font, green text, the kind of number your eye lands on before anything else loads. But the actual composition, base rate versus incentive emissions versus fee share, was two menus deep, behind a small "details" toggle most people would never tap. @termmax , docs are honest about the breakdown if you go looking, but the default view doesn't ask you to look. It just gives you a headline number and lets you decide whether that's enough. I caught myself about to screenshot the front number for notes before some habit made me check the source. Made me wonder how much of "yield" in these systems is actually a UX decision, not a financial one. The math is disclosed, sure, but disclosure and default aren't the same thing, and most positions probably get entered on the default.
What stuck with me wasn't the yield number itself, it was where I noticed it. Exploring $TMX for a CreatorPad task on #TermMax ,the APY sits front and center on the entry screen, big font, green text, the kind of number your eye lands on before anything else loads. But the actual composition, base rate versus incentive emissions versus fee share, was two menus deep, behind a small "details" toggle most people would never tap. @TermMax , docs are honest about the breakdown if you go looking, but the default view doesn't ask you to look. It just gives you a headline number and lets you decide whether that's enough. I caught myself about to screenshot the front number for notes before some habit made me check the source. Made me wonder how much of "yield" in these systems is actually a UX decision, not a financial one. The math is disclosed, sure, but disclosure and default aren't the same thing, and most positions probably get entered on the default.
Tôi đã dành cả một giờ lục lọi giao diện đường cong lãi suất $TMX trước khi nhận ra một điều: chế độ xem mặc định chỉ cho phép bạn vào vị thế khi lãi suất thay đổi ở kỳ hạn ngắn, trong khi tab “advanced” — bị ẩn dưới một nút bật cài đặt mà đa số người không tìm thấy — mới là nơi chứa các công cụ thực sự để khớp kỳ hạn và phòng hộ. #TermMax , @termmax ,l quảng bá rằng ai cũng có thể giao dịch rủi ro lãi suất theo cách mà các tổ chức làm, nhưng giao diện lại âm thầm khóa phần “chuẩn tổ chức” đó sau vài thao tác nhấp thêm. Có hai điểm nổi bật: thứ nhất, nhóm thanh khoản mặc định cho các vị thế kỳ hạn ngắn rõ ràng sâu hơn so với nhóm cho kỳ hạn dài, cho thấy mức độ sử dụng thực tế tập trung ở đâu so với nơi các slide marketing chỉ vào. Thứ hai, cấu trúc phí khuyến khích tái cân bằng thường xuyên cho các vị thế ngắn, nhưng lại gần như không tính đến chi phí trượt giá khi đóng sớm một công cụ phòng hộ kỳ hạn dài — một chi tiết chỉ có thể thấy khi bạn thử thoát một vị thế như vậy. Nó khiến tôi tự hỏi liệu sản phẩm này thực sự được xây dựng cho những người phòng hộ theo đường cong lợi suất mà nó quảng cáo, hay liệu đối tượng đó chỉ là một hạng mục trong lộ trình hơn là thực tại hiện hữu. Người dùng cá nhân chỉ nhận được “cược đơn giản”; còn công cụ tinh vi thì nằm đó, về mặt kỹ thuật có thể dùng, nhưng hầu như không ai đụng đến. Ngay bây giờ thì cái này thực sự dành cho ai?
Tôi đã dành cả một giờ lục lọi giao diện đường cong lãi suất $TMX trước khi nhận ra một điều: chế độ xem mặc định chỉ cho phép bạn vào vị thế khi lãi suất thay đổi ở kỳ hạn ngắn, trong khi tab “advanced” — bị ẩn dưới một nút bật cài đặt mà đa số người không tìm thấy — mới là nơi chứa các công cụ thực sự để khớp kỳ hạn và phòng hộ. #TermMax , @TermMax ,l quảng bá rằng ai cũng có thể giao dịch rủi ro lãi suất theo cách mà các tổ chức làm, nhưng giao diện lại âm thầm khóa phần “chuẩn tổ chức” đó sau vài thao tác nhấp thêm. Có hai điểm nổi bật: thứ nhất, nhóm thanh khoản mặc định cho các vị thế kỳ hạn ngắn rõ ràng sâu hơn so với nhóm cho kỳ hạn dài, cho thấy mức độ sử dụng thực tế tập trung ở đâu so với nơi các slide marketing chỉ vào. Thứ hai, cấu trúc phí khuyến khích tái cân bằng thường xuyên cho các vị thế ngắn, nhưng lại gần như không tính đến chi phí trượt giá khi đóng sớm một công cụ phòng hộ kỳ hạn dài — một chi tiết chỉ có thể thấy khi bạn thử thoát một vị thế như vậy. Nó khiến tôi tự hỏi liệu sản phẩm này thực sự được xây dựng cho những người phòng hộ theo đường cong lợi suất mà nó quảng cáo, hay liệu đối tượng đó chỉ là một hạng mục trong lộ trình hơn là thực tại hiện hữu. Người dùng cá nhân chỉ nhận được “cược đơn giản”; còn công cụ tinh vi thì nằm đó, về mặt kỹ thuật có thể dùng, nhưng hầu như không ai đụng đến. Ngay bây giờ thì cái này thực sự dành cho ai?
Đang xem qua cách chia phần thưởng của Dusk và bị mắc kẹt ở một dòng: máy phát khối nhận 70% cộng thêm tối đa 10%, nhưng phần cộng thêm đó phụ thuộc vào việc họ đưa bao nhiêu tín chỉ vào chứng nhận—và phần còn lại không được thu thì sẽ bị đốt. Không phân phối lại. Bị đốt. $DUSK , #dusk , @Dusk_Foundation — chi tiết đó đã làm rõ lại đoạn “tiện ích token kết nối người dùng với hoạt động của mạng” theo cách khiến tôi nghĩ khác. Tài liệu không nêu rõ chính xác điều gì quyết định số lượng tín chỉ, nhưng nó giống như phần thưởng cho mức độ chữ ký đồng thuận được gộp trọn vào chứng nhận đó, chứ không phải cho việc máy phát đã xử lý bao nhiêu lưu lượng người dùng. Nếu đúng vậy, một phần phần thưởng khối bị chặn bởi một thứ gần với sự phối hợp giữa các trình xác thực hơn là nhu cầu của người dùng. Điều thay đổi đối với tôi là việc giả định phí gas là “đòn bẩy” chính liên kết giá trị token với mức sử dụng. Có lẽ nó không phải là toàn bộ câu chuyện. Và cơ chế gas lại tạo thêm một điểm rắc rối: gas không được dùng thì không bị tính phí, nhưng một giao dịch bị hoàn tác do hết gas vẫn phải trả phần gas đã tiêu tốn. “Hoạt động” trên Dusk cũng không ánh xạ rõ ràng với nhu cầu, dù nhìn theo cách nào. Thứ tiếp theo tôi muốn kiểm tra: cơ chế chứng nhận–tín chỉ thực sự khen thưởng điều gì, và tỉ lệ đốt thực tế từ các tín chỉ không được phân bổ trong một chuỗi các khối.
Đang xem qua cách chia phần thưởng của Dusk và bị mắc kẹt ở một dòng: máy phát khối nhận 70% cộng thêm tối đa 10%, nhưng phần cộng thêm đó phụ thuộc vào việc họ đưa bao nhiêu tín chỉ vào chứng nhận—và phần còn lại không được thu thì sẽ bị đốt. Không phân phối lại. Bị đốt.
$DUSK , #dusk , @Dusk — chi tiết đó đã làm rõ lại đoạn “tiện ích token kết nối người dùng với hoạt động của mạng” theo cách khiến tôi nghĩ khác. Tài liệu không nêu rõ chính xác điều gì quyết định số lượng tín chỉ, nhưng nó giống như phần thưởng cho mức độ chữ ký đồng thuận được gộp trọn vào chứng nhận đó, chứ không phải cho việc máy phát đã xử lý bao nhiêu lưu lượng người dùng. Nếu đúng vậy, một phần phần thưởng khối bị chặn bởi một thứ gần với sự phối hợp giữa các trình xác thực hơn là nhu cầu của người dùng.
Điều thay đổi đối với tôi là việc giả định phí gas là “đòn bẩy” chính liên kết giá trị token với mức sử dụng. Có lẽ nó không phải là toàn bộ câu chuyện. Và cơ chế gas lại tạo thêm một điểm rắc rối: gas không được dùng thì không bị tính phí, nhưng một giao dịch bị hoàn tác do hết gas vẫn phải trả phần gas đã tiêu tốn. “Hoạt động” trên Dusk cũng không ánh xạ rõ ràng với nhu cầu, dù nhìn theo cách nào.
Thứ tiếp theo tôi muốn kiểm tra: cơ chế chứng nhận–tín chỉ thực sự khen thưởng điều gì, và tỉ lệ đốt thực tế từ các tín chỉ không được phân bổ trong một chuỗi các khối.
Đọc tài liệu về kiến trúc của Dusk, tôi kỳ vọng sẽ có một lớp quyền riêng tư. Thế nhưng lại có hai lớp, và chúng không dùng chung cùng một kiểu mật mã. Dusk ($DUSK ) #dusk @Dusk_Foundation đang hướng tới một thiết kế tách rời — DuskDS chạy Piecrust với các chứng minh không tri thức (zero-knowledge proofs), và một lớp DuskEVM riêng nhằm chạy Solidity tiêu chuẩn thông qua Hardhat và MetaMask. Tôi nghĩ điều đó biến DuskEVM thành phía “minh bạch”. Nhưng không phải — ít nhất là theo một bài đăng trong lộ trình của Dusk: DuskEVM được lên kế hoạch để có mã hóa đồng cấu (homomorphic encryption) cho các giao dịch bảo mật và sổ lệnh bị che giấu (obfuscated order books). Toán học khác nhau, không phải là không có quyền riêng tư. Vì vậy, đây không phải “một chuỗi riêng tư với lối vào công khai”. Mà là hai ngăn xếp quyền riêng tư tách biệt nhắm tới hai nhóm nhà phát triển — một lớp dùng ZK proofs, lớp còn lại dùng HE. Hai cách tiếp cận mật mã để duy trì và kiểm toán thay vì chỉ một, cho dù trong thực tế điều đó sẽ có ý nghĩa như thế nào. Vẫn là lộ trình, chưa được triển khai: tài liệu mô tả DuskVM là “hiện đang được nhúng trong DuskDS nhưng sẽ được tách ra” thành một lớp riêng. Đáng để kiểm tra tiếp theo: liệu việc tách đó đã thực sự diễn ra chưa, hay tính bảo mật của DuskEVM dựa trên HE có tồn tại ở bất kỳ đâu ngoài thông báo.
Đọc tài liệu về kiến trúc của Dusk, tôi kỳ vọng sẽ có một lớp quyền riêng tư. Thế nhưng lại có hai lớp, và chúng không dùng chung cùng một kiểu mật mã. Dusk ($DUSK ) #dusk @Dusk đang hướng tới một thiết kế tách rời — DuskDS chạy Piecrust với các chứng minh không tri thức (zero-knowledge proofs), và một lớp DuskEVM riêng nhằm chạy Solidity tiêu chuẩn thông qua Hardhat và MetaMask.
Tôi nghĩ điều đó biến DuskEVM thành phía “minh bạch”. Nhưng không phải — ít nhất là theo một bài đăng trong lộ trình của Dusk: DuskEVM được lên kế hoạch để có mã hóa đồng cấu (homomorphic encryption) cho các giao dịch bảo mật và sổ lệnh bị che giấu (obfuscated order books). Toán học khác nhau, không phải là không có quyền riêng tư.
Vì vậy, đây không phải “một chuỗi riêng tư với lối vào công khai”. Mà là hai ngăn xếp quyền riêng tư tách biệt nhắm tới hai nhóm nhà phát triển — một lớp dùng ZK proofs, lớp còn lại dùng HE. Hai cách tiếp cận mật mã để duy trì và kiểm toán thay vì chỉ một, cho dù trong thực tế điều đó sẽ có ý nghĩa như thế nào. Vẫn là lộ trình, chưa được triển khai: tài liệu mô tả DuskVM là “hiện đang được nhúng trong DuskDS nhưng sẽ được tách ra” thành một lớp riêng.
Đáng để kiểm tra tiếp theo: liệu việc tách đó đã thực sự diễn ra chưa, hay tính bảo mật của DuskEVM dựa trên HE có tồn tại ở bất kỳ đâu ngoài thông báo.
Đúng một phần
Mình đã staking quanh dòng mainnet của DUSK suốt cả buổi chiều cho nhiệm vụ CreatorPad và có một chi tiết cứ làm mình băn khoăn. Mình kiểm tra số liệu DUSK trong lúc làm — CoinMarketCap đang niêm yết ở khoảng $0.0656 với chừng $3.54M khối lượng giao dịch 24h, và riêng cặp DUSK/USDT trên Binance cũng đã hiển thị khoảng $117k trong con số đó. Với một dự án mà toàn bộ lời chào của nó là “cổng kết nối cho hàng nghìn tỷ RWA sắp tới lên on-chain”, @Dusk_Foundation , thì… căn phòng khá yên tĩnh. Chưa chết, chỉ là rất sớm-sớm.#dusk ,$DUSK Điều thực sự khiến mình ám ảnh không phải là khối lượng. Mà là cơ chế staking. Cứ thêm vào một stake đang hoạt động thì chỉ 90% số tiền mới được đưa vào ngay lập tức — 10% còn lại chỉ nằm đó, ở trạng thái không hoạt động, không tạo ra gì, cho đến khi bạn xử lý nó riêng biệt. Không ai quảng cáo phần đó. Tài liệu nhắc đến gần như thoáng qua. Bạn chỉ biết rõ khi tự làm. Nó gần như tóm gọn khoảng cách giữa câu chuyện headline kiểu NPEX/BlackRock và trải nghiệm của một staker bình thường hiện nay — các tổ chức có bản tường thuật settlement được đánh bóng, còn retail thì nhận dòng tiền vào ví với một “khoản thuế” nhỏ mà chẳng ai cảnh báo trước. Đã làm mình chững lại giữa lúc ăn snack, nói thật là vậy. Mình tự hỏi liệu “ma sát” 10% đó có phải là chủ ý (chống gaming?) hay chỉ là đường ống thừa sót từ một lần thiết kế trước. Có ai trong đội ngũ thực sự trả lời thẳng thắn về chuyện này không?
Mình đã staking quanh dòng mainnet của DUSK suốt cả buổi chiều cho nhiệm vụ CreatorPad và có một chi tiết cứ làm mình băn khoăn. Mình kiểm tra số liệu DUSK trong lúc làm — CoinMarketCap đang niêm yết ở khoảng $0.0656 với chừng $3.54M khối lượng giao dịch 24h, và riêng cặp DUSK/USDT trên Binance cũng đã hiển thị khoảng $117k trong con số đó. Với một dự án mà toàn bộ lời chào của nó là “cổng kết nối cho hàng nghìn tỷ RWA sắp tới lên on-chain”, @Dusk , thì… căn phòng khá yên tĩnh. Chưa chết, chỉ là rất sớm-sớm.#dusk ,$DUSK
Điều thực sự khiến mình ám ảnh không phải là khối lượng. Mà là cơ chế staking. Cứ thêm vào một stake đang hoạt động thì chỉ 90% số tiền mới được đưa vào ngay lập tức — 10% còn lại chỉ nằm đó, ở trạng thái không hoạt động, không tạo ra gì, cho đến khi bạn xử lý nó riêng biệt. Không ai quảng cáo phần đó. Tài liệu nhắc đến gần như thoáng qua. Bạn chỉ biết rõ khi tự làm.
Nó gần như tóm gọn khoảng cách giữa câu chuyện headline kiểu NPEX/BlackRock và trải nghiệm của một staker bình thường hiện nay — các tổ chức có bản tường thuật settlement được đánh bóng, còn retail thì nhận dòng tiền vào ví với một “khoản thuế” nhỏ mà chẳng ai cảnh báo trước.
Đã làm mình chững lại giữa lúc ăn snack, nói thật là vậy. Mình tự hỏi liệu “ma sát” 10% đó có phải là chủ ý (chống gaming?) hay chỉ là đường ống thừa sót từ một lần thiết kế trước. Có ai trong đội ngũ thực sự trả lời thẳng thắn về chuyện này không?
Đúng một phần
Đã dành đoạn cuối cùng của vòng CreatorPad này để đào sâu vào hành vi thực tế trên chuỗi của $DUSK thay vì bản pitch deck, và có một con số cứ ám ảnh tôi. Trong lúc làm, tôi mở CoinGecko lên — DUSK đang ở $0.0762, giảm 5% trong tuần, vốn hóa khoảng $45.1M, nhưng khối lượng 24h đang in ra $3.06M. Tính đi… gần 7% toàn bộ vốn hóa thị trường đang quay vòng trong một ngày. @Dusk_Foundation ,#dusk ,$DUSK , Tỷ lệ đó không giống hành vi của một "regulated settlement layer". Nó giống đầu cơ token gas hơn. Mọi thứ Dusk công bố — token hóa NPEX, tuân thủ ZK, Zedger, cả bài pitch quyền riêng tư gặp MiFID — đều nằm ở phía settlement. Nhưng khối lượng mà tôi đang thấy thực sự là giao dịch churn, không phải dòng chảy tài sản. Không ai đang di chuyển chứng khoán đã token hóa với nhịp đó cả. Có ai đó chỉ đang lật đi lật lại token. — mà nghe hơi khó chịu khi phải ngồi với phần tách đó. Câu chuyện về "economic layer" cần có khối lượng NPEX, settlement RWA thực sự, dòng tiền lưu ký (custody flows) để xuất hiện trong dữ liệu trước khi nó được gọi là một layer. Hiện tại thứ hoạt động một cách xác minh được lại là token gas đang làm đúng nhiệm vụ của token gas: tay nhanh, rút nhanh. Tôi pha một ly cà phê giữa lúc viết và suýt tự thuyết phục mình bỏ qua — có lẽ hạ tầng giai đoạn đầu lúc nào cũng trông như vậy trước khi các dòng chảy thật sự đến. Có thể. Vậy DUSK hiện tại đang định giá dựa trên cái gì — luận điểm settlement, hay chỉ là chính nó?
Đã dành đoạn cuối cùng của vòng CreatorPad này để đào sâu vào hành vi thực tế trên chuỗi của $DUSK thay vì bản pitch deck, và có một con số cứ ám ảnh tôi.
Trong lúc làm, tôi mở CoinGecko lên — DUSK đang ở $0.0762, giảm 5% trong tuần, vốn hóa khoảng $45.1M, nhưng khối lượng 24h đang in ra $3.06M. Tính đi… gần 7% toàn bộ vốn hóa thị trường đang quay vòng trong một ngày. @Dusk ,#dusk ,$DUSK ,
Tỷ lệ đó không giống hành vi của một "regulated settlement layer". Nó giống đầu cơ token gas hơn. Mọi thứ Dusk công bố — token hóa NPEX, tuân thủ ZK, Zedger, cả bài pitch quyền riêng tư gặp MiFID — đều nằm ở phía settlement. Nhưng khối lượng mà tôi đang thấy thực sự là giao dịch churn, không phải dòng chảy tài sản. Không ai đang di chuyển chứng khoán đã token hóa với nhịp đó cả. Có ai đó chỉ đang lật đi lật lại token.
— mà nghe hơi khó chịu khi phải ngồi với phần tách đó. Câu chuyện về "economic layer" cần có khối lượng NPEX, settlement RWA thực sự, dòng tiền lưu ký (custody flows) để xuất hiện trong dữ liệu trước khi nó được gọi là một layer. Hiện tại thứ hoạt động một cách xác minh được lại là token gas đang làm đúng nhiệm vụ của token gas: tay nhanh, rút nhanh.
Tôi pha một ly cà phê giữa lúc viết và suýt tự thuyết phục mình bỏ qua — có lẽ hạ tầng giai đoạn đầu lúc nào cũng trông như vậy trước khi các dòng chảy thật sự đến. Có thể.
Vậy DUSK hiện tại đang định giá dựa trên cái gì — luận điểm settlement, hay chỉ là chính nó?
Tôi đã cho rằng “thời gian unbonding ngắn hơn” nghĩa là chính khóa thời gian timelock của Bitcoin hai ngày đã được dời đi. Không phải vậy. Thứ được thông qua bởi quản trị (governance) là một điều chỉnh phí — giảm phí Giai đoạn 2 từ 100 xuống 30 /vbyte, tổng cộng 9600 sats, được xác nhận qua đề xuất trên diễn đàn và được phản ánh trên chuỗi. #baby ,$BABY , @babylonlabs_io Nó không phải là một tham số của Cosmos mà Babylon có thể bỏ phiếu phủ quyết — mà là thứ được kế thừa từ nhịp độ xác nhận vốn có của chính Bitcoin. Vì vậy “ngắn hơn” chỉ có nghĩa là rẻ hơn khi thoát, chứ không phải nhanh hơn. Hai lời hứa rất khác nhau, nhưng khoác lên cùng một tiêu đề. Trong khi đó giao dịch spot đang quanh $0.0105, giảm khoảng số ít (mid-single-digits) trong ngày, kèm một đợt mở khóa 136M token — khoảng 1,2% tổng cung — sẽ về trong năm ngày tới. Phí rẻ hơn, nguồn cung sắp vào nhiều hơn, nến đỏ. Cảm giác ít giống ngẫu nhiên và nhiều giống việc mọi người “đánh trước” một lối thoát mà thực ra không hề nhanh hơn so với thời điểm hồi tháng 4. Tôi đã để bài này yên một phút trước khi đăng vì “ngắn hơn” theo tôi phải ám chỉ thời gian chứ không phải chi phí — và ngôn ngữ marketing thường không tự chỉnh phân biệt đó cho bạn. Hiện giờ ai đang thực sự đọc các thay đổi về phí như thể là thay đổi về timelock, và khoảng cách đó sẽ được thu hẹp trước hay sau khi đợt mở khóa rơi xuống?
Tôi đã cho rằng “thời gian unbonding ngắn hơn” nghĩa là chính khóa thời gian timelock của Bitcoin hai ngày đã được dời đi. Không phải vậy. Thứ được thông qua bởi quản trị (governance) là một điều chỉnh phí — giảm phí Giai đoạn 2 từ 100 xuống 30 /vbyte, tổng cộng 9600 sats, được xác nhận qua đề xuất trên diễn đàn và được phản ánh trên chuỗi. #baby ,$BABY , @BabylonLabs_io
Nó không phải là một tham số của Cosmos mà Babylon có thể bỏ phiếu phủ quyết — mà là thứ được kế thừa từ nhịp độ xác nhận vốn có của chính Bitcoin. Vì vậy “ngắn hơn” chỉ có nghĩa là rẻ hơn khi thoát, chứ không phải nhanh hơn. Hai lời hứa rất khác nhau, nhưng khoác lên cùng một tiêu đề. Trong khi đó giao dịch spot đang quanh $0.0105, giảm khoảng số ít (mid-single-digits) trong ngày, kèm một đợt mở khóa 136M token — khoảng 1,2% tổng cung — sẽ về trong năm ngày tới. Phí rẻ hơn, nguồn cung sắp vào nhiều hơn, nến đỏ. Cảm giác ít giống ngẫu nhiên và nhiều giống việc mọi người “đánh trước” một lối thoát mà thực ra không hề nhanh hơn so với thời điểm hồi tháng 4.
Tôi đã để bài này yên một phút trước khi đăng vì “ngắn hơn” theo tôi phải ám chỉ thời gian chứ không phải chi phí — và ngôn ngữ marketing thường không tự chỉnh phân biệt đó cho bạn.
Hiện giờ ai đang thực sự đọc các thay đổi về phí như thể là thay đổi về timelock, và khoảng cách đó sẽ được thu hẹp trước hay sau khi đợt mở khóa rơi xuống?
@babylonlabs_io — vay mượn “live” được Bitcoin hậu thuẫn, native với Aave v4, được cung cấp bởi Trustless Bitcoin Vaults, không bọc, không bridging, giữ quyền giám sát đầy đủ. Nghe như đúng nguyên văn pitch, đúng không? #baby , $BABY , giải quyết đúng vấn đề mà ba giao thức khác đã tuyên bố là họ bẻ khóa. Nhưng — đó là Public Testnet. Không phải mainnet. Tôi đã phải đọc lại thông báo hai lần để chắc rằng mình không lướt qua mất chữ đó. Đây là điều thực sự đọng lại trong tôi. WBTC, BTC và một vài thị trường cho vay kiểu CDP đã cho phép mọi người vay dựa trên mức phơi nhiễm BTC ngay hôm nay, live, với vốn thực sự luân chuyển qua chúng. “Câu trả lời” của Babylon cho “làm sao dùng Bitcoin làm tài sản thế chấp mà không có rủi ro giám quản” là có thật và về mặt kỹ thuật thì gọn gàng hơn trên giấy — không có token tổng hợp, không có hợp đồng bridge để phải tin tưởng — nhưng vẫn đang trong giai đoạn demo trong khi các bên hiện hữu đang xử lý khối lượng giao dịch thực tế. Câu chuyện đọc như đã xong. Việc triển khai thì trông vẫn còn sớm. Tôi rót cà phê và cứ nghĩ về khoảng cách giữa “chúng tôi đã xây phiên bản không cần tin cậy” và “người ta có thể dùng nó ngay lúc này.” Hai tuyên bố đó không phải là một, dù chúng có thể bị gộp chung vào cùng một dòng tweet. Không chắc liệu khoảng cách này sẽ được lấp đầy trong vài tuần hay kéo dài sang một quý khác. Có ai theo dõi xem khi nào việc này chuyển từ testnet?
@BabylonLabs_io — vay mượn “live” được Bitcoin hậu thuẫn, native với Aave v4, được cung cấp bởi Trustless Bitcoin Vaults, không bọc, không bridging, giữ quyền giám sát đầy đủ. Nghe như đúng nguyên văn pitch, đúng không? #baby , $BABY , giải quyết đúng vấn đề mà ba giao thức khác đã tuyên bố là họ bẻ khóa.
Nhưng — đó là Public Testnet. Không phải mainnet. Tôi đã phải đọc lại thông báo hai lần để chắc rằng mình không lướt qua mất chữ đó.
Đây là điều thực sự đọng lại trong tôi. WBTC, BTC và một vài thị trường cho vay kiểu CDP đã cho phép mọi người vay dựa trên mức phơi nhiễm BTC ngay hôm nay, live, với vốn thực sự luân chuyển qua chúng. “Câu trả lời” của Babylon cho “làm sao dùng Bitcoin làm tài sản thế chấp mà không có rủi ro giám quản” là có thật và về mặt kỹ thuật thì gọn gàng hơn trên giấy — không có token tổng hợp, không có hợp đồng bridge để phải tin tưởng — nhưng vẫn đang trong giai đoạn demo trong khi các bên hiện hữu đang xử lý khối lượng giao dịch thực tế. Câu chuyện đọc như đã xong. Việc triển khai thì trông vẫn còn sớm.
Tôi rót cà phê và cứ nghĩ về khoảng cách giữa “chúng tôi đã xây phiên bản không cần tin cậy” và “người ta có thể dùng nó ngay lúc này.” Hai tuyên bố đó không phải là một, dù chúng có thể bị gộp chung vào cùng một dòng tweet.
Không chắc liệu khoảng cách này sẽ được lấp đầy trong vài tuần hay kéo dài sang một quý khác. Có ai theo dõi xem khi nào việc này chuyển từ testnet?
Ngồi với bài đăng diễn đàn mới từ sáng nay — bài đề xuất việc BABY hướng tới cơ chế giảm phát sau khi các BSN bắt đầu trả phí cho Genesis để sử dụng các dịch vụ của control plane. #baby ,$BABY @babylonlabs_io Đây là điều thực sự đã khiến tôi dừng lại: toàn bộ câu chuyện giảm phát lại nằm ở phía sau của BTC Multi-Staking, mà hiện chưa hoạt động. Vì vậy, ngay lúc này, không có dòng phí nào để đốt — đề xuất này là kiến trúc cho một trạng thái trong tương lai, chứ không phải là mô tả của tokenomics hiện tại. Thiết kế hợp lý, chắc chắn. Nhưng khi đọc nó cạnh việc đăng ký nhận airdrop sẽ đóng trong tuần này và chiến dịch giao dịch trên sàn đang diễn ra song song, thật khó không nhận ra sự trùng khớp — các nội dung nói về giảm phát xuất hiện đúng lúc lượng cung mới và sự chú ý mới đang bước vào hệ thống, chứ không phải khi bất cứ thứ gì thực sự đang thoát ra khỏi đó. Nó cũng khiến tôi phải dừng lại ở giả định của chính mình — tôi đã xem "cơ chế giảm phát sắp tới" như một thực tế ở hiện tại trong các bản nháp trước. Không phải vậy. Đó là một chuỗi phụ thuộc: Multi-Staking được triển khai → BSN trả phí → rồi ngay cả logic đốt cũng cần phải có thứ để tác động. Không phải giảm giá kỳ vọng (bearish), không phải lạc quan (bullish). Chỉ là… ai đang ở vị trí trước khi chuỗi phụ thuộc đó được hoàn tất, và ai đang đặt cược rằng trình tự sẽ hoàn thành đúng lịch?
Ngồi với bài đăng diễn đàn mới từ sáng nay — bài đề xuất việc BABY hướng tới cơ chế giảm phát sau khi các BSN bắt đầu trả phí cho Genesis để sử dụng các dịch vụ của control plane. #baby ,$BABY @BabylonLabs_io
Đây là điều thực sự đã khiến tôi dừng lại: toàn bộ câu chuyện giảm phát lại nằm ở phía sau của BTC Multi-Staking, mà hiện chưa hoạt động. Vì vậy, ngay lúc này, không có dòng phí nào để đốt — đề xuất này là kiến trúc cho một trạng thái trong tương lai, chứ không phải là mô tả của tokenomics hiện tại. Thiết kế hợp lý, chắc chắn. Nhưng khi đọc nó cạnh việc đăng ký nhận airdrop sẽ đóng trong tuần này và chiến dịch giao dịch trên sàn đang diễn ra song song, thật khó không nhận ra sự trùng khớp — các nội dung nói về giảm phát xuất hiện đúng lúc lượng cung mới và sự chú ý mới đang bước vào hệ thống, chứ không phải khi bất cứ thứ gì thực sự đang thoát ra khỏi đó.
Nó cũng khiến tôi phải dừng lại ở giả định của chính mình — tôi đã xem "cơ chế giảm phát sắp tới" như một thực tế ở hiện tại trong các bản nháp trước. Không phải vậy. Đó là một chuỗi phụ thuộc: Multi-Staking được triển khai → BSN trả phí → rồi ngay cả logic đốt cũng cần phải có thứ để tác động.
Không phải giảm giá kỳ vọng (bearish), không phải lạc quan (bullish). Chỉ là… ai đang ở vị trí trước khi chuỗi phụ thuộc đó được hoàn tất, và ai đang đặt cược rằng trình tự sẽ hoàn thành đúng lịch?
đã kiểm tra bảng điều khiển staking giữa nhiệm vụ và chỉ ngồi với nó một chút: hiện có 56,853 BTC đang bị khóa trong các Babylon vault, khoảng 5,6B USD được đảm bảo, và $BABY own market cap đang ở đâu đó quanh mức 80–100M USD. Khoảng chênh lệch đó chính là toàn bộ câu chuyện của ghi chú này. #baby ,@babylonlabs_io gọi nó là "giải quyết BTC nhàn rỗi", và được thôi—nó mang lại lợi suất cho những người nắm giữ BTC mà không cần cầu nối hay bọc (wrapping), không có gì để tranh luận. Nhưng điều nổi bật khi tôi đào sâu vào bản tóm tắt của CreatorPad là: BTC không còn ở trạng thái nhàn rỗi nữa. Còn token BABY thì kiểu… không. Nó vẫn chủ yếu là một token gas-và-quản trị vận hành theo lịch lạm phát 8%, được chia giữa BTC stakers và BABY stakers, chờ một cơ chế burn-auction (đốt thông qua đấu giá) vẫn chưa thực sự kích hoạt hoàn toàn. Thế nên bạn có một giao thức đang bảo đảm 5,6B USD tài sản của người khác, trong khi token gốc của chính nó lại được giao dịch ở mức chỉ là một phần nhỏ so với market cap đó. Không hẳn là bị định giá thấp—đúng hơn là chưa được kích hoạt.$BABY Tôi có một khoảnh khắc kiểu "khoan, rốt cuộc ai được lợi trước". Những người giữ BTC nhận vốn sinh lời ngay lập tức. Những người giữ BABY nhận một lời hứa rằng tiện ích sẽ theo kịp trong tương lai, khi các tỷ lệ co-staking và mô hình đấu giá-đốt trưởng thành. Có thể đó chỉ là tokenomics giai đoạn đầu đang làm đúng cái mà nó luôn làm. Hoặc có thể "idle BTC solved" chỉ lặng lẽ tạo ra sự nhàn rỗi $BABY ở chỗ khác—có ai khác đang theo dõi tỷ lệ đó và tự hỏi khi nào nó mới đóng lại không?
đã kiểm tra bảng điều khiển staking giữa nhiệm vụ và chỉ ngồi với nó một chút: hiện có 56,853 BTC đang bị khóa trong các Babylon vault, khoảng 5,6B USD được đảm bảo, và $BABY own market cap đang ở đâu đó quanh mức 80–100M USD. Khoảng chênh lệch đó chính là toàn bộ câu chuyện của ghi chú này. #baby ,@BabylonLabs_io gọi nó là "giải quyết BTC nhàn rỗi", và được thôi—nó mang lại lợi suất cho những người nắm giữ BTC mà không cần cầu nối hay bọc (wrapping), không có gì để tranh luận.
Nhưng điều nổi bật khi tôi đào sâu vào bản tóm tắt của CreatorPad là: BTC không còn ở trạng thái nhàn rỗi nữa. Còn token BABY thì kiểu… không. Nó vẫn chủ yếu là một token gas-và-quản trị vận hành theo lịch lạm phát 8%, được chia giữa BTC stakers và BABY stakers, chờ một cơ chế burn-auction (đốt thông qua đấu giá) vẫn chưa thực sự kích hoạt hoàn toàn. Thế nên bạn có một giao thức đang bảo đảm 5,6B USD tài sản của người khác, trong khi token gốc của chính nó lại được giao dịch ở mức chỉ là một phần nhỏ so với market cap đó. Không hẳn là bị định giá thấp—đúng hơn là chưa được kích hoạt.$BABY
Tôi có một khoảnh khắc kiểu "khoan, rốt cuộc ai được lợi trước". Những người giữ BTC nhận vốn sinh lời ngay lập tức. Những người giữ BABY nhận một lời hứa rằng tiện ích sẽ theo kịp trong tương lai, khi các tỷ lệ co-staking và mô hình đấu giá-đốt trưởng thành.
Có thể đó chỉ là tokenomics giai đoạn đầu đang làm đúng cái mà nó luôn làm. Hoặc có thể "idle BTC solved" chỉ lặng lẽ tạo ra sự nhàn rỗi $BABY ở chỗ khác—có ai khác đang theo dõi tỷ lệ đó và tự hỏi khi nào nó mới đóng lại không?
Sáu tháng đào bới trong $BABY chiến dịch và thứ thực sự khiến tôi lần này phải dừng lại không phải là bộ slide tokenomics — mà là đề xuất trên trình khám phá quản trị Genesis ,#baby ,$BABY @babylonlabs_io , đề xuất đã thông qua cơ chế đốt (burn) cho phiên đấu giá phần thưởng BSN. Được thông qua, có ghi nhận đầy đủ, đa số siêu vượt trội sạch sẽ. Ngon. Nhưng vướng mắc nằm ở đây. Đề xuất tồn tại trên chuỗi, đã được thực thi đầy đủ, nằm ngay đó trong module quản trị. Tuy nhiên khi tôi đi tìm khối lượng đốt thực tế gắn với nó — kiểu như, lượng BABY thật sự di chuyển qua các phiên đấu giá đó — thì hoạt động khá mỏng. Gần như im ắng. Cơ chế thì đã chạy, đường dẫn mã hoạt động, nhưng nó đang chờ sự tham gia của BSN mà vẫn chưa được mở rộng. Vậy là bạn có một “đòn bẩy” giảm phát đang ở trạng thái “bật” về mặt kỹ thuật nhưng thực tế lại đang rảnh. Điều này cũng phản chiếu thứ tôi nhận thấy khi mò thêm về phần gỡ khóa (unbonding) nữa: cửa sổ khoảng 300 khối BTC, ~1 giờ, nhưng thời điểm sẽ trôi một chút tùy theo độ hoàn tất của checkpoint. Một chi tiết nhỏ thôi, nhưng nó cho thấy cùng một mẫu: hạ tầng đã sẵn sàng trước khi lượng sử dụng kịp bắt nhịp. Khiến tôi tự hỏi “Năm một của Genesis” thực ra là nói nhiều về độ trễ khi được áp dụng (adoption lagging) hơn là thiết kế bị chậm theo sau việc áp dụng. Nút thắt thực sự ở đâu: thiết kế chậm bắt nhịp hay người dùng chưa kịp bắt nhịp với thiết kế?
Sáu tháng đào bới trong $BABY chiến dịch và thứ thực sự khiến tôi lần này phải dừng lại không phải là bộ slide tokenomics — mà là đề xuất trên trình khám phá quản trị Genesis ,#baby ,$BABY @BabylonLabs_io , đề xuất đã thông qua cơ chế đốt (burn) cho phiên đấu giá phần thưởng BSN. Được thông qua, có ghi nhận đầy đủ, đa số siêu vượt trội sạch sẽ. Ngon.
Nhưng vướng mắc nằm ở đây. Đề xuất tồn tại trên chuỗi, đã được thực thi đầy đủ, nằm ngay đó trong module quản trị. Tuy nhiên khi tôi đi tìm khối lượng đốt thực tế gắn với nó — kiểu như, lượng BABY thật sự di chuyển qua các phiên đấu giá đó — thì hoạt động khá mỏng. Gần như im ắng. Cơ chế thì đã chạy, đường dẫn mã hoạt động, nhưng nó đang chờ sự tham gia của BSN mà vẫn chưa được mở rộng. Vậy là bạn có một “đòn bẩy” giảm phát đang ở trạng thái “bật” về mặt kỹ thuật nhưng thực tế lại đang rảnh.
Điều này cũng phản chiếu thứ tôi nhận thấy khi mò thêm về phần gỡ khóa (unbonding) nữa: cửa sổ khoảng 300 khối BTC, ~1 giờ, nhưng thời điểm sẽ trôi một chút tùy theo độ hoàn tất của checkpoint. Một chi tiết nhỏ thôi, nhưng nó cho thấy cùng một mẫu: hạ tầng đã sẵn sàng trước khi lượng sử dụng kịp bắt nhịp.
Khiến tôi tự hỏi “Năm một của Genesis” thực ra là nói nhiều về độ trễ khi được áp dụng (adoption lagging) hơn là thiết kế bị chậm theo sau việc áp dụng. Nút thắt thực sự ở đâu: thiết kế chậm bắt nhịp hay người dùng chưa kịp bắt nhịp với thiết kế?
Đă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