Giá tăng khoảng 28,9%, và biểu đồ cho thấy xu hướng tăng ngắn hạn rõ ràng.
Điều nổi bật với tôi là động lượng — đỉnh sau cao hơn, lực mua mạnh, và giá đang giữ trên đường Supertrend trên khung 5 phút.
Các con số cũng rất đáng chú ý: • Vốn hóa: ~126,6M$ • Khối lượng 24h: ~1,78M$ • Thanh khoản: ~10,8M$ • Số lượng nắm giữ: ~460K
Động lượng ngắn hạn trông có vẻ mạnh, nhưng sau một đợt tăng như thế này, tôi sẽ theo dõi xem FLOKI có thể giữ vững các mức cao hơn này hay không, thay vì đuổi theo cây nến.
$BTCDOM Bố cục Btc nhìn có vẻ thú vị ở đây. 📊 Giá hiện quanh $78,5K, với vùng kháng cự lớn ở khoảng $80K–$88K và hỗ trợ được xếp chồng quanh $70K–$72K. Nếu phá vỡ sạch sẽ lên trên $80K, có thể mở ra cánh cửa hướng tới $88K–$92K. Nếu mất hỗ trợ phía dưới, thì $60K–$65K lại trở nên đáng chú ý. Theo dõi các mốc, đừng đuổi theo nến. 👀 #bitcoin #BTC #crypto #trading $ETH $BNB
Tôi đã xem xét kỹ hơn Dusk, và có một điểm nổi bật là quyền riêng tư đang được xem như một phần của hệ thống thay vì chỉ là một tính năng khác.
Phoenix là một ví dụ tốt. Hệ thống nullifier cho phép mạng biết rằng một ghi chú đã được chi tiêu mà không tiết lộ chính xác ghi chú đó là ghi chú nào.
Sự tách bạch này có vẻ quan trọng đối với Dusk. Mạng vẫn nhận được tín hiệu cần thiết để ngăn chi tiêu hai lần, trong khi các chi tiết giao dịch ở lớp bên dưới có thể được che giấu.
Điều khiến tôi quan tâm là đây không thực sự nhằm mục đích che giấu mọi thứ. Đó là việc quyết định mạng thực sự cần biết gì.
Tôi vẫn cho rằng câu hỏi lớn hơn là liệu sự cân bằng giữa quyền riêng tư, xác minh và tuân thủ có thể hoạt động ở quy mô thể chế thực tế hay không.
Nếu Dusk có thể biến sự cân bằng đó trở nên khả thi, thì lớp quyền riêng tư sẽ không còn chỉ là một tính năng nữa. $COLLECT $BTC
Hầu hết mọi người nhìn vào @Dusk và thấy một sợi xích về quyền riêng tư. Tôi nghĩ bức tranh lớn hơn mới thú vị.
DuskDS cung cấp cho mạng lưới hai cách khác nhau để chuyển giá trị: Moonlight cho các luồng minh bạch và Phoenix cho các chuyển khoản được che chắn. Mấu chốt không phải là giấu hết mọi thứ, mà là kiểm soát những gì thực sự cần phải được nhìn thấy.
Chính ở đây cơ chế npk của Phoenix trở nên quan trọng.
Mỗi ghi chú nhận một khóa dùng một lần mới, vì vậy các khoản thanh toán lặp lại cho cùng một người dùng sẽ không tự động trở thành một dấu vết công khai. Đồng thời, một khóa xem có thể nhận diện các ghi chú đến mà không cấp quyền chi tiêu.
Với các tài sản được quản lý, sự khác biệt đó là rất lớn.
Dusk không cố gắng biến tài chính hoàn toàn riêng tư. Nó đang cố gắng để quyền riêng tư, công bố thông tin và thanh toán bù trừ hoạt động cùng nhau.
Mình đã đào sâu vào cách thiết lập Moonlight vs Phoenix của Dusk, và thật lòng thì chính cách tiếp cận hai mô hình là thứ khiến mình chú ý.
Moonlight là kiểu minh bạch và dựa trên tài khoản, khá giống Ethereum.
Phoenix đi theo hướng ngược lại — ghi chú, cây Merkle và các bằng chứng ZK giúp giữ chi tiết giao dịch ở chế độ riêng tư trong khi các bộ vô hiệu (nullifiers) ngăn chặn chi tiêu hai lần.
Điều mình thấy thú vị là Dusk không ép người dùng chỉ chọn một mô hình.
Minh bạch khi cần tuân thủ, riêng tư khi không cần.
Chắc chắn sẽ có thêm độ phức tạp ở đây, nhưng với tài chính được quản lý, sự đánh đổi này có thể lại là hợp lý.
Vẫn đang tìm hiểu điều này trở nên hữu ích như thế nào trong thực tế.
Tôi đang tìm hiểu cách @Dusk chọn các trình tạo block và ủy ban bỏ phiếu, và phần DS/DE đã thu hút sự chú ý của tôi. DS đảm nhiệm việc lựa chọn, trong khi DE sử dụng trọng số stake và một điểm số dựa trên SHA3 để quyết định ai được chọn. Điểm tôi thích là các node không cần phải giao tiếp chỉ để thực hiện việc lựa chọn. Chúng có thể dùng cùng các đầu vào và cho ra cùng một kết quả. Ngoài ra còn có một quy tắc đơn giản mà tôi thấy thú vị: sau khi một provisioner nhận được tín dụng, 1 DUSK sẽ bị loại khỏi trọng số của họ. Vì vậy, những người stake lớn hơn vẫn có cơ hội cao hơn, nhưng cùng những người đó không chỉ tiếp tục được chọn mãi. Cơ chế nhỏ, nhưng nó làm cho toàn bộ quá trình chọn lựa trở nên cân bằng hơn rất nhiều.
Tôi đang xem cơ chế Fallback của Dusk và có một điểm nổi bật với tôi: số lần lặp (iteration number) thực sự rất quan trọng khi xảy ra một nhánh (fork).
Vì sự đồng thuận của Dusk là bất đồng bộ, các tin nhắn có thể đến trễ hoặc bị mất trong thời gian tắc nghẽn. Do đó, các phần khác nhau của mạng có thể thấy các khối (block) khác nhau, và đôi khi hơn một ứng viên có thể đạt được ngưỡng (quorum) trong cùng một vòng.
Quy tắc cơ bản là lần lặp thấp hơn sẽ được ưu tiên. Nếu một khối ở iteration 1 được chấp nhận nhưng sau đó một khối ở iteration 0 lại đạt quorum, thì khối ở lần lặp thấp hơn có thể thay thế. Nút sẽ quay về trạng thái trước khối cũ và tổ chức lại (reorganize) chuỗi.
Điều đó khiến iteration 0 trở nên thú vị. Iteration 0 là lần thử đầu tiên, sau đó đến iteration 1, 2, và cứ thế tiếp. Vì không có iteration -1, nên một khối ở iteration 0 không thể được thay thế trực tiếp thông qua Fallback bởi một lần lặp thấp hơn.
Nhưng tôi sẽ không gọi đó là tính hoàn tất cuối cùng (complete finality). Khối ở iteration 0 vẫn có thể bị ảnh hưởng nếu một tổ tiên (ancestor) bị hoàn nguyên. Tính cuối cùng thực sự đến từ Rolling Finality.
Vì vậy, theo cách tôi nhìn nhận, Fallback không chỉ là dọn dẹp fork. Số lần lặp mang lại cho mạng một cách xác định (deterministic) để chọn giữa các khối cạnh tranh, với iteration 0 nằm ở đáy của thứ tự ưu tiên đó.
Trước đây, tôi từng nghĩ Chế độ Khẩn cấp của Dusk chỉ đơn giản là một phương án dự phòng khi mạng không thể tạo ra một khối.
Nhưng sau khi đi sâu hơn, tôi cho rằng ở đây có một ý tưởng thú vị hơn: làm thế nào để giữ cho một blockchain vận hành khi cơ chế đồng thuận thông thường bắt đầu thất bại?
Dusk thường hoạt động theo các vòng lặp lặp lại: đề xuất khối, xác thực và phê chuẩn. Nhưng nếu quá nhiều người cung cấp (provisioners) ngoại tuyến, thì có thể xảy ra nhiều vòng lặp thất bại liên tiếp.
Sau 16 vòng lặp thất bại liên tiếp, Dusk có thể chuyển sang Chế độ Khẩn cấp.
Điểm thay đổi ở đây khá đáng chú ý. Các cơ chế timeout ở bước thông thường không còn là ràng buộc chính, và nhiều vòng lặp mở có thể tiếp tục thử cho đến khi một vòng đạt được đủ số lượng (quorum).
Tất nhiên, điều đó lại tạo ra một vấn đề khác. Việc có nhiều ứng viên cũng đồng nghĩa với nguy cơ xuất hiện các khối cạnh tranh cao hơn.
Dusk xử lý vấn đề này bằng cách chấp nhận khối thành công từ vòng lặp có số thứ tự thấp nhất và đóng các vòng lặp mở còn lại.
Nhưng nếu ngay cả vòng lặp cuối cùng cũng không thể đạt được quorum thì sao?
Đó là lúc các Yêu cầu Khối Khẩn cấp (Emergency Block Requests) xuất hiện.
Nếu đa số có trọng số theo lượng stake của các provisioners yêu cầu một yêu cầu như vậy, thì Dusk có thể tạo một khối rỗng đặc biệt, được chính Dusk ký, qua đó cho phép chuỗi tiếp tục tiến lên thay vì bị kẹt mãi mãi.
Phần mà tôi thấy thú vị nhất chính là sự đánh đổi (trade-off).
Dusk đang bổ sung một cơ chế dự phòng tập trung có kiểm soát để bảo vệ khả năng duy trì hoạt động của mạng (network liveness) trong một tình huống thất bại cực đoan.
Vậy có lẽ câu hỏi thực sự không phải là Chế độ Khẩn cấp có phi tập trung đủ hay không.
Mà là liệu việc giữ cho mạng sống trong tình huống tệ nhất có đáng để chấp nhận sự thỏa hiệp nhỏ đó hay không.
Sự cân bằng giữa phi tập trung và khả năng duy trì hoạt động chính là điều khiến thiết kế đồng thuận của Dusk trở nên hấp dẫn đối với tôi.
#dusk $DUSK Tôi đã đọc lại các tài liệu @Dusk và cuối cùng lại nhìn kỹ hơn vào Rolling Finality.
Ý tưởng cơ bản khá dễ hiểu. Một khối bắt đầu ở trạng thái Accepted, sau đó trở thành Attested khi nhận đủ số phiếu bầu. Từ đó, nó có thể chuyển sang Confirmed và cuối cùng là Final.
Nhưng phần tôi thấy thú vị lại là n=0 so với n>0.
Lần lặp đầu tiên sẽ đi theo đường nhanh (fast path). Nếu khối n=0 đạt đến Attested, thì nó đã có thể được coi là không thể đảo ngược. Tuy nhiên, các lần lặp sau thì khác. Dù đã ở trạng thái Attested, chúng vẫn cần thêm các lần xác nhận.
Tôi đoán lý do khá rõ ràng: nếu lần thử đầu tiên thất bại, mạng không muốn một bộ tạo (generator) ở sau lại đạt được cùng mức độ hoàn tất cuối cùng tức thời.
Vẫn đang tự hỏi các quy tắc này hoạt động thế nào trong bản triển khai hiện tại và liệu các yêu cầu xác nhận có thể thay đổi theo thời gian không.
#dusk $DUSK Tôi cứ thấy Dusk được mô tả như một blockchain được xây dựng đặc biệt cho các thị trường tài chính được quản lý, nên tôi đã lặn vào một “mê cung” nhỏ để hiểu điều gì khiến nó thực sự khác biệt.
So sánh hiển nhiên là khá thú vị. Các public chain như Bitcoin và Ethereum mang lại sự minh bạch, nhưng mức độ hiển thị đó không phải lúc nào cũng lý tưởng cho hoạt động tài chính được quản lý. Các mạng tập trung vào quyền riêng tư giải quyết được một phần vấn đề này, nhưng rồi việc tuân thủ và khả năng kiểm toán lại trở nên khó hơn.
Dusk dường như đang cố gắng đứng đúng ở giữa: có quyền riêng tư khi dữ liệu tài chính cần được bảo vệ, nhưng vẫn đủ cấu trúc để các thị trường được quản lý có thể vận hành trong các yêu cầu tuân thủ.
Sau đó, tôi bắt đầu tìm hiểu kiến trúc đứng sau ý tưởng đó.
Succinct Attestation được thiết kế để cung cấp khả năng hoàn tất nhanh. Kadcast đảm nhiệm lớp peer-to-peer. Moonlight và Phoenix áp dụng những cách tiếp cận khác nhau cho giao dịch. Và Zedger là nơi mọi thứ trở nên đặc biệt thú vị — một khung smart contract bí mật được xây dựng xoay quanh chứng khoán và các sản phẩm tài chính.
Điều đọng lại với tôi là Dusk không đơn giản chỉ cố tạo ra một blockchain đa dụng khác. Kiến trúc có vẻ được xây dựng xoay quanh một câu hỏi hẹp hơn nhiều:
Liệu hạ tầng blockchain có thể mang lại quyền riêng tư cho các thị trường tài chính được quản lý mà không đánh đổi việc tuân thủ không?
Đây là một bài toán khó hơn nhiều so với việc chỉ làm giao dịch nhanh hơn hoặc rẻ hơn.
Và giờ tôi tự hỏi — nếu các tài sản được quản lý thực sự được chuyển lên chuỗi ở quy mô lớn, thì liệu cách tiếp cận “quyền riêng tư + tuân thủ” của Dusk có trở thành tính năng quan trọng nhất?