Binance Square
Aeri 艾瑞
7.9k Bài đăng

Aeri 艾瑞

@Aeshiha
431 Đang theo dõi
13.0K+ Người theo dõi
10.4K+ Đã thích
Bài đăng
PINNED
·
--
Đã chốt giao dịch với mức ROI điên rồ tới tận 2012% 🚀🔥 Thật lòng mà nói, mình vẫn đang xử lý con số đó. Lấy lợi nhuận, khóa lại và bước đi trong nụ cười. 📈💰 Quả là một chuyến đi! Một lời nhắc nhỏ: đừng để lòng tham biến một giao dịch tốt thành sự hối tiếc. 📈 Hãy chốt lời, bảo vệ thành quả của bạn và nhớ rằng luôn có cơ hội khác. 🧠💰
Đã chốt giao dịch với mức ROI điên rồ tới tận 2012% 🚀🔥 Thật lòng mà nói, mình vẫn đang xử lý con số đó. Lấy lợi nhuận, khóa lại và bước đi trong nụ cười. 📈💰 Quả là một chuyến đi!

Một lời nhắc nhỏ: đừng để lòng tham biến một giao dịch tốt thành sự hối tiếc. 📈 Hãy chốt lời, bảo vệ thành quả của bạn và nhớ rằng luôn có cơ hội khác. 🧠💰
#dusk $DUSK @Dusk_Foundation tòa án không đối xử với có tội và không có tội theo cách giống nhau. Bạn cần gần như tất cả mọi người phải đồng ý để kết tội một ai đó. Chỉ cần một người phản đối là đủ để họ được trắng án. Tiêu chuẩn khác nhau cho những kết quả khác nhau, vì sai theo một hướng sẽ tốn kém hơn nhiều so với hướng còn lại. sự đồng thuận của Dusk cũng vận hành theo logic tương tự và tôi không ngờ điều đó lại đến từ một blockchain. khi tôi tìm hiểu cách một khối thực sự được xác nhận, tôi cũng thấy sự chia tách tương tự. Để xác nhận nó là hợp lệ, ủy ban cần có hai phần ba tán thành. Để bác bỏ, hoặc nói "chúng tôi không thể quyết định", chỉ cần nửa cộng một là đủ. Có là tốn kém. Không là rẻ. Chắc là cố tình như vậy. Một khối xấu lọt qua là một mớ rối khó gỡ. Một khối bị kẹt thì lần sau lại thử tiếp ở vòng kế tiếp. những lá phiếu đó không phải là đếm đầu người. Dusk chia mỗi ủy ban thành 64 tín dụng, và những bên đặt cược lớn sẽ nhận được nhiều hơn. Ba tín dụng từ một con cá voi vượt trội hơn ba người giữ nhỏ bỏ phiếu theo cùng hướng. Mốc yêu cầu trông có vẻ cố định là 2/3 và nửa cộng một, nhưng người mà tôi cần thuyết phục để đạt được nó sẽ phụ thuộc vào cách các tín dụng đó được phân bổ. đó là điều cứ ám ảnh tôi. Nếu tiền cược cứ dồn vào ít người hơn, phía rẻ hơn—phía "không"—sẽ càng dễ kích hoạt hơn. Không phải vì phép tính thay đổi, mà vì càng ít người nắm đủ Dusk để xoay chuyển tình thế, và tôi không thích điều đó.
#dusk $DUSK @Dusk

tòa án không đối xử với có tội và không có tội theo cách giống nhau. Bạn cần gần như tất cả mọi người phải đồng ý để kết tội một ai đó. Chỉ cần một người phản đối là đủ để họ được trắng án. Tiêu chuẩn khác nhau cho những kết quả khác nhau, vì sai theo một hướng sẽ tốn kém hơn nhiều so với hướng còn lại.

sự đồng thuận của Dusk cũng vận hành theo logic tương tự và tôi không ngờ điều đó lại đến từ một blockchain.

khi tôi tìm hiểu cách một khối thực sự được xác nhận, tôi cũng thấy sự chia tách tương tự. Để xác nhận nó là hợp lệ, ủy ban cần có hai phần ba tán thành. Để bác bỏ, hoặc nói "chúng tôi không thể quyết định", chỉ cần nửa cộng một là đủ. Có là tốn kém. Không là rẻ. Chắc là cố tình như vậy. Một khối xấu lọt qua là một mớ rối khó gỡ. Một khối bị kẹt thì lần sau lại thử tiếp ở vòng kế tiếp.

những lá phiếu đó không phải là đếm đầu người. Dusk chia mỗi ủy ban thành 64 tín dụng, và những bên đặt cược lớn sẽ nhận được nhiều hơn. Ba tín dụng từ một con cá voi vượt trội hơn ba người giữ nhỏ bỏ phiếu theo cùng hướng. Mốc yêu cầu trông có vẻ cố định là 2/3 và nửa cộng một, nhưng người mà tôi cần thuyết phục để đạt được nó sẽ phụ thuộc vào cách các tín dụng đó được phân bổ.

đó là điều cứ ám ảnh tôi. Nếu tiền cược cứ dồn vào ít người hơn, phía rẻ hơn—phía "không"—sẽ càng dễ kích hoạt hơn. Không phải vì phép tính thay đổi, mà vì càng ít người nắm đủ Dusk để xoay chuyển tình thế, và tôi không thích điều đó.
Đã xác minh
#dusk $DUSK @Dusk_Foundation dạo gần đây mình đào sâu hơn vào các mô hình song song của Dusk, và cách bố trí Moonlight so với Phoenix có cảm giác ít giống hai công cụ tách biệt mà hơn là năng lực “lật” tư thế quản lý/quy định của một tổ chức duy nhất mà vẫn không làm đứt chuỗi. moonlight là phía sổ cái công khai. Số dư hiển thị rõ ràng, mọi lần chuyển đều cho thấy ai gửi cho ai và gửi gì. Vì vậy, đây là con đường ít trở ngại nhất cho các sàn giao dịch, báo cáo, hoặc bất kỳ luồng nào mà kiểm toán viên hay đối tác cần được nhìn thấy đầy đủ. Phoenix thì ngược lại. Tiền được chuyển dưới dạng các ghi chú (note) được mã hóa. Mạng chỉ thấy rằng phép tính là đúng thông qua các bằng chứng không kiến thức (zero knowledge proofs). Số tiền và liên kết được giữ kín khỏi công chúng, nhưng người nhận vẫn biết người gửi, và các khóa xem (viewing keys) có thể mở “chiếc hộp” cho các bên được ủy quyền khi cần. điểm nổi bật là hai bên “khớp” với nhau gọn gàng đến mức nào trên cùng một lớp thanh toán (settlement). Một tổ chức có thể duy trì báo cáo kho quỹ hoặc tuân thủ hằng ngày trên Moonlight, rồi chuyển các vị thế nhạy cảm hoặc thanh toán cho khách hàng sang Phoenix khi các quy tắc công bố siết chặt hoặc khi vấn đề tác động thị trường trở thành mối quan tâm. Không có cầu nối, không có tài sản bọc (wrapped assets), chỉ là một lần chuyển đổi nguyên tử (atomic) thông qua hợp đồng Transfer. Điều này loại bỏ khoản “phí phân mảnh” thường thấy khi quyền riêng tư và sự minh bạch tồn tại trên các mạng khác nhau. nhưng giới hạn thì là có thật. Phần lớn khối lượng vẫn có vẻ thích đi theo hướng minh bạch, dù là do thói quen, cài đặt mặc định của ví, hay đơn giản là vì nhiều quy trình được quản lý vẫn yêu cầu các dấu vết công khai. Quyền riêng tư chỉ thực sự quan trọng nếu động lực và công cụ (tooling) có đủ để kéo người dùng sang phía được che chắn. tính linh hoạt của chế độ kép đó có thực sự làm giảm rào cản cho các tổ chức, hay chỉ tạo ra thêm một lớp phức tạp vận hành mà họ sẽ ngại phải quản lý?
#dusk $DUSK @Dusk

dạo gần đây mình đào sâu hơn vào các mô hình song song của Dusk, và cách bố trí Moonlight so với Phoenix có cảm giác ít giống hai công cụ tách biệt mà hơn là năng lực “lật” tư thế quản lý/quy định của một tổ chức duy nhất mà vẫn không làm đứt chuỗi.

moonlight là phía sổ cái công khai. Số dư hiển thị rõ ràng, mọi lần chuyển đều cho thấy ai gửi cho ai và gửi gì. Vì vậy, đây là con đường ít trở ngại nhất cho các sàn giao dịch, báo cáo, hoặc bất kỳ luồng nào mà kiểm toán viên hay đối tác cần được nhìn thấy đầy đủ. Phoenix thì ngược lại. Tiền được chuyển dưới dạng các ghi chú (note) được mã hóa. Mạng chỉ thấy rằng phép tính là đúng thông qua các bằng chứng không kiến thức (zero knowledge proofs). Số tiền và liên kết được giữ kín khỏi công chúng, nhưng người nhận vẫn biết người gửi, và các khóa xem (viewing keys) có thể mở “chiếc hộp” cho các bên được ủy quyền khi cần.

điểm nổi bật là hai bên “khớp” với nhau gọn gàng đến mức nào trên cùng một lớp thanh toán (settlement). Một tổ chức có thể duy trì báo cáo kho quỹ hoặc tuân thủ hằng ngày trên Moonlight, rồi chuyển các vị thế nhạy cảm hoặc thanh toán cho khách hàng sang Phoenix khi các quy tắc công bố siết chặt hoặc khi vấn đề tác động thị trường trở thành mối quan tâm. Không có cầu nối, không có tài sản bọc (wrapped assets), chỉ là một lần chuyển đổi nguyên tử (atomic) thông qua hợp đồng Transfer. Điều này loại bỏ khoản “phí phân mảnh” thường thấy khi quyền riêng tư và sự minh bạch tồn tại trên các mạng khác nhau.

nhưng giới hạn thì là có thật. Phần lớn khối lượng vẫn có vẻ thích đi theo hướng minh bạch, dù là do thói quen, cài đặt mặc định của ví, hay đơn giản là vì nhiều quy trình được quản lý vẫn yêu cầu các dấu vết công khai. Quyền riêng tư chỉ thực sự quan trọng nếu động lực và công cụ (tooling) có đủ để kéo người dùng sang phía được che chắn.

tính linh hoạt của chế độ kép đó có thực sự làm giảm rào cản cho các tổ chức, hay chỉ tạo ra thêm một lớp phức tạp vận hành mà họ sẽ ngại phải quản lý?
🎙️ DUSK Live: Khám phá tầm nhìn tài chính của Dusk
cover
Kết thúc
04 giờ 14 phút 20 giây
498
2
0
Đúng một phần
#dusk $DUSK @Dusk_Foundation tôi nghĩ rằng “mức cam kết càng cao” chỉ có nghĩa là “quyền bỏ phiếu càng lớn”, đơn giản vậy thôi. Cứ DUSK được đặt nhiều gấp đôi thì xác suất được chọn cũng gấp đôi. Nhưng thuật toán sắp xếp chọn lọc (sortition) của Dusk nói rằng đó chưa phải toàn bộ bức tranh—và tôi chỉ nhận ra điều này khi đọc kỹ phần sau bản tóm tắt. khi Dusk xây dựng một ủy ban bỏ phiếu, nó không chỉ xem cam kết của bạn một lần rồi cấp tín dụng dựa trên đúng con số duy nhất đó. Nó cấp tín dụng từng cái một, theo một vòng lặp. Và mỗi khi một người cung ứng (provisioner) nhận được một tín dụng, thuật toán sẽ trừ trọng số của tín dụng đó khỏi phần cam kết của họ trước cả khi kiểm tra xem ai đủ điều kiện cho tín dụng tiếp theo trong hàng. vì vậy, phần cam kết của bạn không phải là một con số cố định, “đông cứng” trong suốt toàn bộ quá trình trích xuất. Nó thay đổi, tín dụng này qua tín dụng khác, khi vòng lặp chạy qua ủy ban. Điều này có nghĩa là hai người cung ứng với cùng “cam kết thô” (ví dụ đều đặt DUSK như nhau), vẫn có thể nhận được xác suất thực tế hơi khác nhau chỉ vì vị trí của họ trong thứ tự mà các tín dụng được gán. Không phải một cú lật quá lớn khiến kết quả đổi hẳn. Nhưng cũng không phải đường thẳng “sạch sẽ tuyệt đối” mà đa số người ta tưởng tượng khi ai đó nói “càng cam kết, càng có quyền lực”. tôi suýt bỏ qua điểm này hoàn toàn, nói thật là vậy. Lời giải thích phổ biến về sortition của Dusk thường dừng ngay ở “cam kết càng lớn, xác suất càng tốt” và dừng ở đó—không sai, chỉ là thiếu. Bước trừ đó nằm sâu hơn một lớp nữa: trong chính vòng lặp trích xuất xác định (deterministic) chứ không nằm ở phiên bản tiêu đề mà ai cũng nhắc lại. vậy nên đây là quan điểm thẳng thắn. Điều này không phải là một “lỗi ẩn” hay một cú lừa kiểu bắt bẻ. Nó chỉ “có nhiều lớp chi tiết” hơn lời chào mời. Dusk xây dựng một hệ thống trong đó cam kết thực sự rất quan trọng, nhưng không theo đúng kiểu tuyến tính hoàn hảo như bạn nghĩ—ít nhất là khi bạn thật sự xem vòng lặp chạy tín dụng từng cái một.
#dusk $DUSK @Dusk

tôi nghĩ rằng “mức cam kết càng cao” chỉ có nghĩa là “quyền bỏ phiếu càng lớn”, đơn giản vậy thôi. Cứ DUSK được đặt nhiều gấp đôi thì xác suất được chọn cũng gấp đôi. Nhưng thuật toán sắp xếp chọn lọc (sortition) của Dusk nói rằng đó chưa phải toàn bộ bức tranh—và tôi chỉ nhận ra điều này khi đọc kỹ phần sau bản tóm tắt.

khi Dusk xây dựng một ủy ban bỏ phiếu, nó không chỉ xem cam kết của bạn một lần rồi cấp tín dụng dựa trên đúng con số duy nhất đó. Nó cấp tín dụng từng cái một, theo một vòng lặp. Và mỗi khi một người cung ứng (provisioner) nhận được một tín dụng, thuật toán sẽ trừ trọng số của tín dụng đó khỏi phần cam kết của họ trước cả khi kiểm tra xem ai đủ điều kiện cho tín dụng tiếp theo trong hàng.

vì vậy, phần cam kết của bạn không phải là một con số cố định, “đông cứng” trong suốt toàn bộ quá trình trích xuất. Nó thay đổi, tín dụng này qua tín dụng khác, khi vòng lặp chạy qua ủy ban. Điều này có nghĩa là hai người cung ứng với cùng “cam kết thô” (ví dụ đều đặt DUSK như nhau), vẫn có thể nhận được xác suất thực tế hơi khác nhau chỉ vì vị trí của họ trong thứ tự mà các tín dụng được gán. Không phải một cú lật quá lớn khiến kết quả đổi hẳn. Nhưng cũng không phải đường thẳng “sạch sẽ tuyệt đối” mà đa số người ta tưởng tượng khi ai đó nói “càng cam kết, càng có quyền lực”.

tôi suýt bỏ qua điểm này hoàn toàn, nói thật là vậy. Lời giải thích phổ biến về sortition của Dusk thường dừng ngay ở “cam kết càng lớn, xác suất càng tốt” và dừng ở đó—không sai, chỉ là thiếu. Bước trừ đó nằm sâu hơn một lớp nữa: trong chính vòng lặp trích xuất xác định (deterministic) chứ không nằm ở phiên bản tiêu đề mà ai cũng nhắc lại.

vậy nên đây là quan điểm thẳng thắn. Điều này không phải là một “lỗi ẩn” hay một cú lừa kiểu bắt bẻ. Nó chỉ “có nhiều lớp chi tiết” hơn lời chào mời. Dusk xây dựng một hệ thống trong đó cam kết thực sự rất quan trọng, nhưng không theo đúng kiểu tuyến tính hoàn hảo như bạn nghĩ—ít nhất là khi bạn thật sự xem vòng lặp chạy tín dụng từng cái một.
Đã xác minh
#dusk $DUSK @Dusk_Foundation Tôi đã nghĩ chỉ cần một hệ thống chứng minh cần thiết lập tin cậy, còn hệ thống kia chỉ việc bỏ qua. Nhưng không phải vậy—thiết lập riêng của Dusk đã làm rõ điều đó với tôi. Sự thật là: cả PlonK và Groth16 đều cần một thiết lập tin cậy. Dusk hỗ trợ cả hai, tích hợp sẵn ngay trong engine Piecrust dưới dạng các hàm native. Điểm khác biệt thực sự không phải là bạn có cần một hay không. Mà là tần suất. Groth16 cần thiết lập mới cho *mỗi* mạch (circuit) một lần. Mỗi lần có logic hợp đồng (contract logic) mới thì lại phải thiết lập mới. Việc tổ chức điều này tốn kém, nhưng bù lại hiệu quả. Bằng chứng (proof) rất nhỏ và việc xác minh diễn ra nhanh. PlonK làm theo cách khác. Một thiết lập, thực hiện một lần, sau đó tái sử dụng cho bất kỳ mạch nào bạn xây dựng về sau. Linh hoạt hơn rất nhiều. Nhưng các bằng chứng sẽ lớn hơn và việc kiểm tra chúng tốn kém hơn. Vì vậy Dusk không chọn một “kẻ thắng” ở đây. Nó cung cấp cho nhà phát triển cả hai công cụ và để bạn tự quyết tradeoff (đánh đổi). Muốn tốc độ và không ngại phải tổ chức lại phần thiết lập theo từng mạch? Groth16. Muốn linh hoạt và có thể “chịu” bằng chứng lớn hơn? PlonK. Trước đây tôi nghĩ thiết lập tin cậy chỉ là câu hỏi có hay không. Tài liệu của Dusk cho tôi thấy đó thực sự là câu hỏi bạn sẵn sàng phải làm lại bao nhiêu công việc thiết lập và bạn sẵn sàng mang theo một bằng chứng lớn cỡ nào.
#dusk $DUSK @Dusk

Tôi đã nghĩ chỉ cần một hệ thống chứng minh cần thiết lập tin cậy, còn hệ thống kia chỉ việc bỏ qua. Nhưng không phải vậy—thiết lập riêng của Dusk đã làm rõ điều đó với tôi.

Sự thật là: cả PlonK và Groth16 đều cần một thiết lập tin cậy. Dusk hỗ trợ cả hai, tích hợp sẵn ngay trong engine Piecrust dưới dạng các hàm native. Điểm khác biệt thực sự không phải là bạn có cần một hay không. Mà là tần suất.

Groth16 cần thiết lập mới cho *mỗi* mạch (circuit) một lần. Mỗi lần có logic hợp đồng (contract logic) mới thì lại phải thiết lập mới. Việc tổ chức điều này tốn kém, nhưng bù lại hiệu quả. Bằng chứng (proof) rất nhỏ và việc xác minh diễn ra nhanh.

PlonK làm theo cách khác. Một thiết lập, thực hiện một lần, sau đó tái sử dụng cho bất kỳ mạch nào bạn xây dựng về sau. Linh hoạt hơn rất nhiều. Nhưng các bằng chứng sẽ lớn hơn và việc kiểm tra chúng tốn kém hơn.

Vì vậy Dusk không chọn một “kẻ thắng” ở đây. Nó cung cấp cho nhà phát triển cả hai công cụ và để bạn tự quyết tradeoff (đánh đổi). Muốn tốc độ và không ngại phải tổ chức lại phần thiết lập theo từng mạch? Groth16. Muốn linh hoạt và có thể “chịu” bằng chứng lớn hơn? PlonK.

Trước đây tôi nghĩ thiết lập tin cậy chỉ là câu hỏi có hay không. Tài liệu của Dusk cho tôi thấy đó thực sự là câu hỏi bạn sẵn sàng phải làm lại bao nhiêu công việc thiết lập và bạn sẵn sàng mang theo một bằng chứng lớn cỡ nào.
#termmax @termmax Trước đây tôi từng nghĩ timelock chỉ là một khoảng trễ được thêm vào smart contract. Sau khi xem các tài liệu bảo mật của TermMax, tôi nghĩ rằng cách hiểu đó chưa nắm đúng lý do thực sự. Điểm khiến tôi chú ý là các thao tác nhạy cảm không diễn ra ngay lập tức. Các thay đổi tham số quan trọng phải chờ trước khi được triển khai. Điều đó cho mọi người có thời gian xem xét thay đổi và, nếu thấy có điều gì đó có hại, có thể hủy bỏ trước khi nó trở nên hiệu lực. Dưới đây là một ví dụ đơn giản. Nếu một tham số nhạy cảm của Vault bị thay đổi, hệ thống sẽ không coi thay đổi đã được phê duyệt là thứ bắt buộc phải thực hiện ngay lập tức. Có một khoảng thời gian giữa quyết định và triển khai thực tế. Khoảng thời gian này quan trọng vì sai sót hoặc các thay đổi gây hại sẽ dễ xử lý hơn rất nhiều trước khi chúng có hiệu lực. Đánh đổi ở đây là tốc độ. TermMax từ bỏ việc thay đổi tức thời để đổi lấy cơ hội phát hiện vấn đề trước. Và tôi nghĩ đây là phần thú vị hơn trong thiết kế. Bảo mật không phải lúc nào cũng chỉ là thêm nhiều lớp kiểm soát hơn. Đôi khi đó là chủ động làm chậm quá trình kiểm soát. TermMax còn khiến tôi suy nghĩ thêm về một điều khác. Nếu thay đổi tham số là khẩn cấp, thì độ trễ bao nhiêu là chấp nhận được trước khi chính cơ chế bảo vệ bắt đầu trở thành vấn đề? Sự cân bằng đó khiến thiết kế TMX timelock đáng để chú ý.
#termmax @TermMax

Trước đây tôi từng nghĩ timelock chỉ là một khoảng trễ được thêm vào smart contract. Sau khi xem các tài liệu bảo mật của TermMax, tôi nghĩ rằng cách hiểu đó chưa nắm đúng lý do thực sự.

Điểm khiến tôi chú ý là các thao tác nhạy cảm không diễn ra ngay lập tức. Các thay đổi tham số quan trọng phải chờ trước khi được triển khai. Điều đó cho mọi người có thời gian xem xét thay đổi và, nếu thấy có điều gì đó có hại, có thể hủy bỏ trước khi nó trở nên hiệu lực.

Dưới đây là một ví dụ đơn giản. Nếu một tham số nhạy cảm của Vault bị thay đổi, hệ thống sẽ không coi thay đổi đã được phê duyệt là thứ bắt buộc phải thực hiện ngay lập tức. Có một khoảng thời gian giữa quyết định và triển khai thực tế. Khoảng thời gian này quan trọng vì sai sót hoặc các thay đổi gây hại sẽ dễ xử lý hơn rất nhiều trước khi chúng có hiệu lực.

Đánh đổi ở đây là tốc độ. TermMax từ bỏ việc thay đổi tức thời để đổi lấy cơ hội phát hiện vấn đề trước. Và tôi nghĩ đây là phần thú vị hơn trong thiết kế. Bảo mật không phải lúc nào cũng chỉ là thêm nhiều lớp kiểm soát hơn. Đôi khi đó là chủ động làm chậm quá trình kiểm soát.

TermMax còn khiến tôi suy nghĩ thêm về một điều khác. Nếu thay đổi tham số là khẩn cấp, thì độ trễ bao nhiêu là chấp nhận được trước khi chính cơ chế bảo vệ bắt đầu trở thành vấn đề?

Sự cân bằng đó khiến thiết kế TMX timelock đáng để chú ý.
·
--
Giảm giá
#dusk $DUSK @Dusk_Foundation Tôi cam kết, và tôi muốn phiếu bầu của mình được tính ngay lập tức. Thế nên khi tôi biết Dusk bắt bạn phải chờ, tôi đã khó chịu. Rồi sau đó tôi thực sự đọc lý do. Đây là thiết lập: Dusk chạy theo các epoch, tức là các đợt gồm 2.160 khối mỗi đợt. Khi bạn stake, bạn không đủ điều kiện bỏ phiếu ngay giây phút DUSK của bạn chạm mạng. Có một công thức quyết định khi nào phần stake của bạn thực sự “trưởng thành”: M bằng hai lần epoch, trừ đi phần dư của chiều cao chia cho epoch. Nghe như bài toán lớp học. Thực ra chỉ là một bộ đếm chờ. Ban đầu tôi nghĩ đó chỉ là thủ tục rườm rà. Rồi tôi nghĩ đến chuyện gì sẽ xảy ra nếu không có nó. Nếu stake mới có thể bỏ phiếu ngay lập tức, ai đó có thể theo dõi trước ủy ban sắp tới, nhanh chóng stake ngay trước một cuộc bỏ phiếu mà họ muốn tác động, bỏ phiếu xong rồi rút ra. Vào rồi ra, không có “da thịt” thật sự trong cuộc chơi. Dusk đóng cánh cửa đó lại. Bạn phải chờ qua một phần của epoch thì stake của bạn mới có ý nghĩa. Sự đánh đổi cũng là có thật. Người stake trung thực phải chờ lâu hơn mức họ muốn, và không có cách nào tránh được chi phí đó. Nhưng tôi thà chờ một chút hơn là stake trên một chuỗi nơi bất kỳ ai cũng có thể thuê ảnh hưởng chỉ cho một lần bỏ phiếu. Dusk chọn sự kiên nhẫn thay vì tốc độ ở chỗ này, và sau khi đào sâu tìm hiểu, tôi hiểu vì sao.
#dusk $DUSK @Dusk

Tôi cam kết, và tôi muốn phiếu bầu của mình được tính ngay lập tức. Thế nên khi tôi biết Dusk bắt bạn phải chờ, tôi đã khó chịu. Rồi sau đó tôi thực sự đọc lý do. Đây là thiết lập: Dusk chạy theo các epoch, tức là các đợt gồm 2.160 khối mỗi đợt. Khi bạn stake, bạn không đủ điều kiện bỏ phiếu ngay giây phút DUSK của bạn chạm mạng. Có một công thức quyết định khi nào phần stake của bạn thực sự “trưởng thành”: M bằng hai lần epoch, trừ đi phần dư của chiều cao chia cho epoch. Nghe như bài toán lớp học. Thực ra chỉ là một bộ đếm chờ.

Ban đầu tôi nghĩ đó chỉ là thủ tục rườm rà. Rồi tôi nghĩ đến chuyện gì sẽ xảy ra nếu không có nó. Nếu stake mới có thể bỏ phiếu ngay lập tức, ai đó có thể theo dõi trước ủy ban sắp tới, nhanh chóng stake ngay trước một cuộc bỏ phiếu mà họ muốn tác động, bỏ phiếu xong rồi rút ra. Vào rồi ra, không có “da thịt” thật sự trong cuộc chơi. Dusk đóng cánh cửa đó lại. Bạn phải chờ qua một phần của epoch thì stake của bạn mới có ý nghĩa.

Sự đánh đổi cũng là có thật. Người stake trung thực phải chờ lâu hơn mức họ muốn, và không có cách nào tránh được chi phí đó. Nhưng tôi thà chờ một chút hơn là stake trên một chuỗi nơi bất kỳ ai cũng có thể thuê ảnh hưởng chỉ cho một lần bỏ phiếu. Dusk chọn sự kiên nhẫn thay vì tốc độ ở chỗ này, và sau khi đào sâu tìm hiểu, tôi hiểu vì sao.
Thị trường đã đóng. Vậy tại sao sàn TradFi vĩnh viễn (perpetual) vẫn có thể giao dịch? 👀 Đây là một trong những điều thú vị hơn ở các sản phẩm TradFi của Binance Futures. Các thị trường chứng khoán truyền thống không hoạt động 24/7. Thế nhưng Binance lại cung cấp các hợp đồng perpetual TradFi có thể giao dịch suốt ngày đêm. Vậy bạn đang giao dịch chính xác là gì? Không phải là cổ phiếu thực sự. Bạn đang giao dịch một hợp đồng tương lai vĩnh viễn (perpetual futures) bám theo giá của tài sản cơ sở. Sự khác biệt này rất quan trọng. Hãy tưởng tượng bạn đang theo dõi một cổ phiếu mà sàn giao dịch truyền thống của nó đã đóng cửa trong ngày. Tin tức bùng nổ qua đêm. Sàn cơ sở không còn giao dịch tích cực, nhưng hợp đồng perpetual vẫn có thể có hoạt động thị trường riêng. Điều đó đặt ra một câu hỏi quan trọng: Hợp đồng được giữ gắn kết với giá của tài sản cơ sở bằng cách nào? Các hợp đồng perpetual sử dụng các cơ chế như hệ thống chỉ số/giá mark (index/mark-price) và tỷ lệ funding để giúp hợp đồng bám sát thị trường cơ sở. Và vì vậy, việc hiểu cấu trúc sản phẩm quan trọng hơn nhiều so với chỉ nhìn ra mã (ticker). Bạn có thể thấy: TSLAUSDT và nghĩ: “Đang mua Tesla.” Nhưng điều đó không giống như việc sở hữu cổ phiếu Tesla. Bạn đang giao dịch một sản phẩm phái sinh mà giá trị của nó bám theo tài sản cơ sở. 📌 Bài học: Một mã ticker quen thuộc không nhất thiết đồng nghĩa với một sản phẩm quen thuộc. Trước khi giao dịch bất kỳ perpetual TradFi nào, hãy hiểu: → Hợp đồng đó đại diện cho điều gì → Giá của nó được xác định như thế nào → Khi nào thị trường cơ sở giao dịch → Funding hoạt động ra sao → Bạn đang dùng đòn bẩy bao nhiêu Cùng một tài sản cơ sở ≠ cùng một công cụ tài chính. Đó là chi tiết mà tôi muốn hiểu trước khi đặt lệnh. #Binance #TradFi #futures #cryptoeducation
Thị trường đã đóng. Vậy tại sao sàn TradFi vĩnh viễn (perpetual) vẫn có thể giao dịch? 👀

Đây là một trong những điều thú vị hơn ở các sản phẩm TradFi của Binance Futures.

Các thị trường chứng khoán truyền thống không hoạt động 24/7.

Thế nhưng Binance lại cung cấp các hợp đồng perpetual TradFi có thể giao dịch suốt ngày đêm.

Vậy bạn đang giao dịch chính xác là gì?

Không phải là cổ phiếu thực sự.

Bạn đang giao dịch một hợp đồng tương lai vĩnh viễn (perpetual futures) bám theo giá của tài sản cơ sở.

Sự khác biệt này rất quan trọng.

Hãy tưởng tượng bạn đang theo dõi một cổ phiếu mà sàn giao dịch truyền thống của nó đã đóng cửa trong ngày.

Tin tức bùng nổ qua đêm.

Sàn cơ sở không còn giao dịch tích cực, nhưng hợp đồng perpetual vẫn có thể có hoạt động thị trường riêng.

Điều đó đặt ra một câu hỏi quan trọng:

Hợp đồng được giữ gắn kết với giá của tài sản cơ sở bằng cách nào?

Các hợp đồng perpetual sử dụng các cơ chế như hệ thống chỉ số/giá mark (index/mark-price) và tỷ lệ funding để giúp hợp đồng bám sát thị trường cơ sở.

Và vì vậy, việc hiểu cấu trúc sản phẩm quan trọng hơn nhiều so với chỉ nhìn ra mã (ticker).

Bạn có thể thấy:

TSLAUSDT

và nghĩ:

“Đang mua Tesla.”

Nhưng điều đó không giống như việc sở hữu cổ phiếu Tesla.

Bạn đang giao dịch một sản phẩm phái sinh mà giá trị của nó bám theo tài sản cơ sở.

📌 Bài học:

Một mã ticker quen thuộc không nhất thiết đồng nghĩa với một sản phẩm quen thuộc.

Trước khi giao dịch bất kỳ perpetual TradFi nào, hãy hiểu:

→ Hợp đồng đó đại diện cho điều gì

→ Giá của nó được xác định như thế nào

→ Khi nào thị trường cơ sở giao dịch

→ Funding hoạt động ra sao

→ Bạn đang dùng đòn bẩy bao nhiêu

Cùng một tài sản cơ sở ≠ cùng một công cụ tài chính.

Đó là chi tiết mà tôi muốn hiểu trước khi đặt lệnh.

#Binance #TradFi #futures #cryptoeducation
·
--
Tăng giá
Đã xác minh
#dusk $DUSK {future}(DUSKUSDT) @Dusk_Foundation Hiện nay dự án crypto nào cũng dán một huy hiệu “đã được kiểm toán” lên trang chủ. Đến mức lúc này nó gần như chỉ là hình nền. Chẳng ai đọc xem đằng sau đó là gì. Tôi đã đọc một lần, và cụ thể là của @Dusk_Foundation _Foundation, và nó đã thay đổi cách tôi nghĩ về toàn bộ chuyện kiểm toán này. Dusk xây dựng công nghệ quyền riêng tư cho tài chính được quản lý—tài sản được mã hoá, giao dịch tuân thủ, và phần “đường ống” không mấy hào nhoáng mà các ngân hàng thực sự có thể dùng. Không phô trương. Nhưng đó lại là điểm mấu chốt. Hạ tầng tiền tệ vốn dĩ phải… nhàm chán. Đó là lịch sử kiểm toán của Dusk được công khai trên GitHub. Mười cuộc kiểm toán riêng lẻ, tổng cộng hơn 200 trang, do các công ty độc lập thực hiện như Zellic và Oak Security—không có lý do gì để họ làm nhẹ tay. Và nó không phải kiểu “quét sạch”. Một lần rà soát động cơ smart contract của họ phát hiện hai lỗi nghiêm trọng—những lỗi có thể làm hệ thống sập hoặc khiến các con số vận hành theo cách không nên. Vấn đề thật. Nhóm đã sửa chúng và vẫn đăng kết quả, bao gồm cả các sai sót. Chi tiết quan trọng chính là ở đây. Một báo cáo không có phát hiện gì mọi lần—không phải điều khiến người ta yên tâm. Nó còn đáng ngờ. Việc lỗi được phát hiện và đóng lại mới là thứ một quy trình thực sự trông như thế nào, và không cần đến huy hiệu. Hãy đọc báo cáo thực tế. Xem những gì bị gắn cờ và liệu nhóm có tự chịu trách nhiệm với những vấn đề đó hay không. Điều đó cho bạn biết nhiều hơn bất kỳ logo nào.
#dusk $DUSK
@Dusk

Hiện nay dự án crypto nào cũng dán một huy hiệu “đã được kiểm toán” lên trang chủ. Đến mức lúc này nó gần như chỉ là hình nền. Chẳng ai đọc xem đằng sau đó là gì. Tôi đã đọc một lần, và cụ thể là của @Dusk _Foundation, và nó đã thay đổi cách tôi nghĩ về toàn bộ chuyện kiểm toán này.

Dusk xây dựng công nghệ quyền riêng tư cho tài chính được quản lý—tài sản được mã hoá, giao dịch tuân thủ, và phần “đường ống” không mấy hào nhoáng mà các ngân hàng thực sự có thể dùng. Không phô trương. Nhưng đó lại là điểm mấu chốt. Hạ tầng tiền tệ vốn dĩ phải… nhàm chán.

Đó là lịch sử kiểm toán của Dusk được công khai trên GitHub. Mười cuộc kiểm toán riêng lẻ, tổng cộng hơn 200 trang, do các công ty độc lập thực hiện như Zellic và Oak Security—không có lý do gì để họ làm nhẹ tay.

Và nó không phải kiểu “quét sạch”. Một lần rà soát động cơ smart contract của họ phát hiện hai lỗi nghiêm trọng—những lỗi có thể làm hệ thống sập hoặc khiến các con số vận hành theo cách không nên. Vấn đề thật. Nhóm đã sửa chúng và vẫn đăng kết quả, bao gồm cả các sai sót.

Chi tiết quan trọng chính là ở đây. Một báo cáo không có phát hiện gì mọi lần—không phải điều khiến người ta yên tâm. Nó còn đáng ngờ. Việc lỗi được phát hiện và đóng lại mới là thứ một quy trình thực sự trông như thế nào, và không cần đến huy hiệu. Hãy đọc báo cáo thực tế. Xem những gì bị gắn cờ và liệu nhóm có tự chịu trách nhiệm với những vấn đề đó hay không. Điều đó cho bạn biết nhiều hơn bất kỳ logo nào.
#termmax @termmax Trước đây tôi từng nghĩ thanh lý chủ yếu là bán tài sản thế chấp, chịu lỗ và cố gắng thu hồi những gì còn nợ. Sau khi đọc FAQ của TermMax, tôi nhận ra quy trình có thể trông khác đi khá nhiều. Điều khiến tôi chú ý là chuyện gì có thể xảy ra trong một đợt thanh lý một phần. Thay vì chỉ xem tài sản thế chấp như một thứ để bán nhằm thu hồi nợ, người nắm giữ FT (FT holders) có thể nhận được một phần tương ứng của tài sản thế chấp. Điều đó thay đổi cách tôi nhìn về cơ chế này. Hãy tưởng tượng một vị thế bị thiếu tài sản đảm bảo (undercollateralized) và chỉ cần thanh lý một phần. Với TermMax, các FT holders bị ảnh hưởng có thể nhận phần tài sản thế chấp tương ứng ngay chính bản thân tài sản đó. Vì vậy, kết quả gắn chặt hơn với tài sản cơ sở thay vì bị giảm xuống thành một khoản thanh toán thu hồi đơn giản. Nhưng vẫn có sự đánh đổi. Giao nhận vật chất không loại bỏ rủi ro thanh lý. Giá trị của tài sản thế chấp vẫn có thể biến động, và việc nhận tài sản trực tiếp đồng nghĩa với việc người nắm giữ có thể giờ đây chịu rủi ro theo biến động giá thị trường của chính tài sản đó. Đó là điều tôi thấy thú vị về TermMax. Thanh lý không chỉ là một cơ chế bán tháo khẩn cấp. Nó cũng có thể thay đổi xem ai là người cuối cùng nắm giữ tài sản thế chấp sau khi vị thế được giảm bớt. TMX khiến tôi tự hỏi liệu giao nhận vật chất có tạo ra một quy trình thanh lý công bằng hơn hay chỉ đơn giản là chuyển một phần rủi ro từ giao thức (protocol) trở lại cho người nắm giữ FT. Giao nhận vật chất thay đổi điều gì?
#termmax @TermMax

Trước đây tôi từng nghĩ thanh lý chủ yếu là bán tài sản thế chấp, chịu lỗ và cố gắng thu hồi những gì còn nợ. Sau khi đọc FAQ của TermMax, tôi nhận ra quy trình có thể trông khác đi khá nhiều.

Điều khiến tôi chú ý là chuyện gì có thể xảy ra trong một đợt thanh lý một phần. Thay vì chỉ xem tài sản thế chấp như một thứ để bán nhằm thu hồi nợ, người nắm giữ FT (FT holders) có thể nhận được một phần tương ứng của tài sản thế chấp.

Điều đó thay đổi cách tôi nhìn về cơ chế này. Hãy tưởng tượng một vị thế bị thiếu tài sản đảm bảo (undercollateralized) và chỉ cần thanh lý một phần. Với TermMax, các FT holders bị ảnh hưởng có thể nhận phần tài sản thế chấp tương ứng ngay chính bản thân tài sản đó. Vì vậy, kết quả gắn chặt hơn với tài sản cơ sở thay vì bị giảm xuống thành một khoản thanh toán thu hồi đơn giản.

Nhưng vẫn có sự đánh đổi. Giao nhận vật chất không loại bỏ rủi ro thanh lý. Giá trị của tài sản thế chấp vẫn có thể biến động, và việc nhận tài sản trực tiếp đồng nghĩa với việc người nắm giữ có thể giờ đây chịu rủi ro theo biến động giá thị trường của chính tài sản đó.

Đó là điều tôi thấy thú vị về TermMax. Thanh lý không chỉ là một cơ chế bán tháo khẩn cấp. Nó cũng có thể thay đổi xem ai là người cuối cùng nắm giữ tài sản thế chấp sau khi vị thế được giảm bớt.

TMX khiến tôi tự hỏi liệu giao nhận vật chất có tạo ra một quy trình thanh lý công bằng hơn hay chỉ đơn giản là chuyển một phần rủi ro từ giao thức (protocol) trở lại cho người nắm giữ FT.

Giao nhận vật chất thay đổi điều gì?
Shifts risk to holders
67%
Makes liquidation riskier
0%
Fairer for FT holders
33%
Reduces liquidation losses
0%
3 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
·
--
Tăng giá
#termmax @termmax Trước đây tôi nghĩ rằng việc chia thanh khoản qua nhiều lệnh thì thực tế vốn cũng phải được chia ra theo tương ứng. Sau khi đọc thiết kế Atomic Orders, tôi nhận ra điều đó không nhất thiết đúng. Phần thú vị nằm ở việc sử dụng thanh khoản ảo. Vốn có thể được phân bổ trên nhiều lệnh trước khi bất kỳ ai thực sự vay từ nó mà không cần phải di chuyển vật lý cùng một khoản tiền vào từng lệnh. Nhờ đó, một “pool” vốn có thể hỗ trợ hiệu quả nhiều vị thế thị trường cùng lúc. Hãy tưởng tượng tôi có 100 đơn vị vốn và muốn tiếp xúc với nhiều khoảng lãi suất khác nhau. Thay vì đưa các phần vốn riêng vào từng lệnh, hệ thống có thể biểu diễn thanh khoản trên các lệnh đó trước, trong khi các quỹ cơ bản vẫn được giữ chung cho đến khi thực sự cần đến. Đó là điểm tôi thấy thú vị về TMX. Nó chuyển bài toán từ “Làm thế nào để tôi chia vốn của mình?” sang “Làm sao để cùng một khoản vốn có thể sẵn sàng cho nhiều lệnh khác nhau mà không tạo ra sự phân mảnh không cần thiết?” TMX cũng khiến tôi nghĩ về sự đánh đổi. Định vị ảo có thể làm vốn linh hoạt hơn, nhưng hệ thống vẫn phải quyết định cách các vị thế ảo đó được thanh toán/đối soát khi xảy ra việc vay thực sự. Chính tại đây, thiết kế trở nên quan trọng hơn nhiều so với tính năng được quảng cáo nổi bật. Câu hỏi của tôi là liệu cách tiếp cận của TMX có thể làm cho thanh khoản hiệu quả hơn mà không chỉ đơn giản chuyển độ phức tạp từ khâu phân bổ vốn sang khâu thực thi.
#termmax @TermMax

Trước đây tôi nghĩ rằng việc chia thanh khoản qua nhiều lệnh thì thực tế vốn cũng phải được chia ra theo tương ứng. Sau khi đọc thiết kế Atomic Orders, tôi nhận ra điều đó không nhất thiết đúng. Phần thú vị nằm ở việc sử dụng thanh khoản ảo. Vốn có thể được phân bổ trên nhiều lệnh trước khi bất kỳ ai thực sự vay từ nó mà không cần phải di chuyển vật lý cùng một khoản tiền vào từng lệnh. Nhờ đó, một “pool” vốn có thể hỗ trợ hiệu quả nhiều vị thế thị trường cùng lúc.

Hãy tưởng tượng tôi có 100 đơn vị vốn và muốn tiếp xúc với nhiều khoảng lãi suất khác nhau. Thay vì đưa các phần vốn riêng vào từng lệnh, hệ thống có thể biểu diễn thanh khoản trên các lệnh đó trước, trong khi các quỹ cơ bản vẫn được giữ chung cho đến khi thực sự cần đến. Đó là điểm tôi thấy thú vị về TMX. Nó chuyển bài toán từ “Làm thế nào để tôi chia vốn của mình?” sang “Làm sao để cùng một khoản vốn có thể sẵn sàng cho nhiều lệnh khác nhau mà không tạo ra sự phân mảnh không cần thiết?”

TMX cũng khiến tôi nghĩ về sự đánh đổi. Định vị ảo có thể làm vốn linh hoạt hơn, nhưng hệ thống vẫn phải quyết định cách các vị thế ảo đó được thanh toán/đối soát khi xảy ra việc vay thực sự. Chính tại đây, thiết kế trở nên quan trọng hơn nhiều so với tính năng được quảng cáo nổi bật.

Câu hỏi của tôi là liệu cách tiếp cận của TMX có thể làm cho thanh khoản hiệu quả hơn mà không chỉ đơn giản chuyển độ phức tạp từ khâu phân bổ vốn sang khâu thực thi.
·
--
Tăng giá
#dusk $DUSK {future}(DUSKUSDT) @Dusk_Foundation Vì vậy mình đã nghiên cứu thông qua các quy tắc đồng thuận của Dusk và phát hiện ra một điều thoạt nhìn có vẻ ngẫu nhiên, nhưng thật ra lại rất hợp lý nếu nghĩ kỹ. Bối cảnh ở Dusk là: mỗi lần lặp lại sẽ có một bộ tạo khối riêng. Người đề xuất khối và ủy ban bỏ phiếu riêng của họ sẽ kiểm tra xem khối đó có tốt hay không. Mình nghĩ ai đủ điều kiện cũng có thể bỏ phiếu ở bất kỳ lần lặp nào. Nhưng Dusk lại chặn một nhóm cụ thể không cho bỏ phiếu—đó là nhóm được chỉ định làm người tạo khối ở lần lặp tiếp theo. Ban đầu mình tự hỏi: sao lại chặn họ? Họ vẫn là một “provisioner” bình thường. Nhưng rồi mình hiểu ra. Nếu người tạo khối trong tương lai có thể bỏ phiếu ngay lúc này, họ sẽ có lý do để bỏ phiếu chống lại khối hiện tại. Bởi vì nếu khối này thất bại, công việc và phần thưởng sẽ được chuyển sang cho họ ở lượt tiếp theo. Đó là xung đột lợi ích quá rõ ràng. Bỏ phiếu không thì nhận tiền sau. Vì vậy Dusk chỉ đơn giản là loại bỏ cám dỗ này. Không bỏ phiếu thì không có lý do để phá hoại. Đây chỉ là một quy tắc nhỏ, nhưng nó đang làm việc thực sự. Nó giúp những người tạo khối tập trung vào lượt của chính họ, thay vì “làm trò” để nhắm vào lượt của người khác. Và thật lòng mà nói, đó là kiểu chi tiết cho thấy liệu một mạng lưới có thực sự cân nhắc đến động cơ khuyến khích hay chỉ sao chép một mẫu. Dusk không phô trương mấy chuyện kiểu này. Nhưng những quy tắc nhỏ như thế mới là lý do mình vẫn tiếp tục đọc tài liệu của Dusk thay vì chỉ xem phần marketing của họ.
#dusk $DUSK
@Dusk

Vì vậy mình đã nghiên cứu thông qua các quy tắc đồng thuận của Dusk và phát hiện ra một điều thoạt nhìn có vẻ ngẫu nhiên, nhưng thật ra lại rất hợp lý nếu nghĩ kỹ. Bối cảnh ở Dusk là: mỗi lần lặp lại sẽ có một bộ tạo khối riêng. Người đề xuất khối và ủy ban bỏ phiếu riêng của họ sẽ kiểm tra xem khối đó có tốt hay không. Mình nghĩ ai đủ điều kiện cũng có thể bỏ phiếu ở bất kỳ lần lặp nào. Nhưng Dusk lại chặn một nhóm cụ thể không cho bỏ phiếu—đó là nhóm được chỉ định làm người tạo khối ở lần lặp tiếp theo.

Ban đầu mình tự hỏi: sao lại chặn họ? Họ vẫn là một “provisioner” bình thường. Nhưng rồi mình hiểu ra. Nếu người tạo khối trong tương lai có thể bỏ phiếu ngay lúc này, họ sẽ có lý do để bỏ phiếu chống lại khối hiện tại. Bởi vì nếu khối này thất bại, công việc và phần thưởng sẽ được chuyển sang cho họ ở lượt tiếp theo. Đó là xung đột lợi ích quá rõ ràng.

Bỏ phiếu không thì nhận tiền sau. Vì vậy Dusk chỉ đơn giản là loại bỏ cám dỗ này. Không bỏ phiếu thì không có lý do để phá hoại. Đây chỉ là một quy tắc nhỏ, nhưng nó đang làm việc thực sự. Nó giúp những người tạo khối tập trung vào lượt của chính họ, thay vì “làm trò” để nhắm vào lượt của người khác. Và thật lòng mà nói, đó là kiểu chi tiết cho thấy liệu một mạng lưới có thực sự cân nhắc đến động cơ khuyến khích hay chỉ sao chép một mẫu. Dusk không phô trương mấy chuyện kiểu này. Nhưng những quy tắc nhỏ như thế mới là lý do mình vẫn tiếp tục đọc tài liệu của Dusk thay vì chỉ xem phần marketing của họ.
Chợ truyền thống trên Binance? Phần I mà tôi nên hiểu trước không phải là tài sản. Mà là rủi ro. Binance Futures hiện cho phép nhà giao dịch tiếp cận một số tài sản TradFi được chọn, điều này có thể giúp việc tiếp xúc với thị trường truyền thống trở nên khả thi song song với các thị trường crypto. Thoạt nhìn, điều đó nghe có vẻ đơn giản. Nhưng có một điểm khác biệt quan trọng: Tiếp cận một tài sản không có nghĩa là rủi ro trở nên đơn giản. Trước khi giao dịch một sản phẩm futures TradFi, tôi muốn hiểu: 🔹 Đòn bẩy — Chỉ cần thị trường biến động nhỏ cũng có thể tạo tác động lớn hơn nhiều lên vị thế của bạn khi có sử dụng đòn bẩy. 🔹 Thanh lý — Nếu thị trường đi xa đủ theo hướng bất lợi đối với vị thế dùng đòn bẩy, vị thế có thể được đóng tự động. 🔹 Biến động — Tài sản truyền thống cũng có thể biến động mạnh. “TradFi” không có nghĩa là “rủi ro thấp”. 🔹 Điều kiện giao dịch — Các thị trường khác nhau có thể có giờ giao dịch, thanh khoản và cách biến động giá khác nhau. 🔹 Quy mô vị thế — Số tiền bạn đặt vào rủi ro quan trọng không kém gì hướng mà bạn đang dự đoán. Vì vậy, tôi nghĩ người mới bắt đầu nên đổi câu hỏi từ: ❌ “Tôi có thể kiếm được bao nhiêu?” thành: ✅ “Nếu tôi sai thì tôi có thể mất bao nhiêu?” Chỉ một câu hỏi đó thôi có thể thay đổi hoàn toàn cách bạn tiếp cận giao dịch dùng đòn bẩy. Futures có thể là công cụ hữu ích cho nhà giao dịch có kinh nghiệm, nhưng chúng không phù hợp với tất cả mọi người. Hiểu sản phẩm. Hiểu đòn bẩy. Hiểu thanh lý. Sau đó hãy quyết định liệu mức rủi ro đó có phù hợp với bạn hay không. Không phải lời khuyên tài chính. Luôn tự nghiên cứu và không bao giờ giao dịch bằng số tiền bạn không thể chịu mất. #Binance #TradFi #CryptoTrading #RiskManagement #future
Chợ truyền thống trên Binance? Phần I mà tôi nên hiểu trước không phải là tài sản. Mà là rủi ro.

Binance Futures hiện cho phép nhà giao dịch tiếp cận một số tài sản TradFi được chọn, điều này có thể giúp việc tiếp xúc với thị trường truyền thống trở nên khả thi song song với các thị trường crypto.

Thoạt nhìn, điều đó nghe có vẻ đơn giản.

Nhưng có một điểm khác biệt quan trọng:

Tiếp cận một tài sản không có nghĩa là rủi ro trở nên đơn giản.

Trước khi giao dịch một sản phẩm futures TradFi, tôi muốn hiểu:

🔹 Đòn bẩy — Chỉ cần thị trường biến động nhỏ cũng có thể tạo tác động lớn hơn nhiều lên vị thế của bạn khi có sử dụng đòn bẩy.

🔹 Thanh lý — Nếu thị trường đi xa đủ theo hướng bất lợi đối với vị thế dùng đòn bẩy, vị thế có thể được đóng tự động.

🔹 Biến động — Tài sản truyền thống cũng có thể biến động mạnh. “TradFi” không có nghĩa là “rủi ro thấp”.

🔹 Điều kiện giao dịch — Các thị trường khác nhau có thể có giờ giao dịch, thanh khoản và cách biến động giá khác nhau.

🔹 Quy mô vị thế — Số tiền bạn đặt vào rủi ro quan trọng không kém gì hướng mà bạn đang dự đoán.

Vì vậy, tôi nghĩ người mới bắt đầu nên đổi câu hỏi từ:

❌ “Tôi có thể kiếm được bao nhiêu?”
thành:

✅ “Nếu tôi sai thì tôi có thể mất bao nhiêu?”
Chỉ một câu hỏi đó thôi có thể thay đổi hoàn toàn cách bạn tiếp cận giao dịch dùng đòn bẩy.

Futures có thể là công cụ hữu ích cho nhà giao dịch có kinh nghiệm, nhưng chúng không phù hợp với tất cả mọi người.

Hiểu sản phẩm. Hiểu đòn bẩy. Hiểu thanh lý. Sau đó hãy quyết định liệu mức rủi ro đó có phù hợp với bạn hay không.

Không phải lời khuyên tài chính. Luôn tự nghiên cứu và không bao giờ giao dịch bằng số tiền bạn không thể chịu mất.

#Binance #TradFi #CryptoTrading #RiskManagement #future
#dusk $DUSK @Dusk_Foundation Tôi đã đọc qua các tài liệu đồng thuận của Dusk và bị kẹt ở một chi tiết nhỏ—nhưng hóa ra nó quan trọng hơn tôi tưởng. Nào, bối cảnh là thế này. Khi một ủy ban bỏ phiếu cho một khối (block), bạn chỉ cần một số lượng phiếu nhất định để đạt ngưỡng (quorum). Nhưng không có gì ngăn việc nhiều phiếu hơn tiếp tục được gửi đến sau thời điểm đó. Vì vậy, về mặt kỹ thuật, bạn có thể kết thúc với hai bằng chứng (proof) hợp lệ khác nhau rằng ngưỡng đã được đạt cho cùng một khối—chỉ là với hai tập hợp cử tri (voters) khác nhau được đưa vào. Nghe thì giống như một ghi chú kỹ thuật nhỏ. Nhưng thực ra đó là một vấn đề. Nếu không chọn ra một bằng chứng cụ thể, bạn sẽ không thể xác định rõ ai được thưởng và ai bị phạt. Hai tập phiếu khác nhau sẽ dẫn đến hai cách tính phần thưởng khác nhau. Dusk giải quyết điều này theo một cách khá đơn giản. Mỗi khối mới phải bao gồm một bản xác thực (attestation) về khối trước đó. Bản xác thực này được gọi là “block certificate” (chứng chỉ khối). Và nhiệm vụ của nó là khóa lại đúng một tập hợp cử tri duy nhất cho khối đó. Không phải một tập hợp hợp lệ. Mà là tập hợp. Vì vậy, chứng chỉ không thật sự dùng để chứng minh khối đã xảy ra. Cơ chế đồng thuận (consensus) đã làm điều đó. Nó nhằm đảm bảo rằng Dusk có đúng một câu trả lời cho câu hỏi: “Ai đã bỏ phiếu, và họ được trả bao nhiêu cho phần đó.” Một cơ chế nhỏ, nhưng nó bít một khoảng trống có thể khiến hệ thống phần thưởng của Dusk bị mơ hồ. Khi nào chứng chỉ (certificate) của một khối được tạo và được đưa vào Mạng Dusk?
#dusk $DUSK @Dusk

Tôi đã đọc qua các tài liệu đồng thuận của Dusk và bị kẹt ở một chi tiết nhỏ—nhưng hóa ra nó quan trọng hơn tôi tưởng.
Nào, bối cảnh là thế này. Khi một ủy ban bỏ phiếu cho một khối (block), bạn chỉ cần một số lượng phiếu nhất định để đạt ngưỡng (quorum). Nhưng không có gì ngăn việc nhiều phiếu hơn tiếp tục được gửi đến sau thời điểm đó. Vì vậy, về mặt kỹ thuật, bạn có thể kết thúc với hai bằng chứng (proof) hợp lệ khác nhau rằng ngưỡng đã được đạt cho cùng một khối—chỉ là với hai tập hợp cử tri (voters) khác nhau được đưa vào.
Nghe thì giống như một ghi chú kỹ thuật nhỏ. Nhưng thực ra đó là một vấn đề. Nếu không chọn ra một bằng chứng cụ thể, bạn sẽ không thể xác định rõ ai được thưởng và ai bị phạt.

Hai tập phiếu khác nhau sẽ dẫn đến hai cách tính phần thưởng khác nhau.
Dusk giải quyết điều này theo một cách khá đơn giản. Mỗi khối mới phải bao gồm một bản xác thực (attestation) về khối trước đó. Bản xác thực này được gọi là “block certificate” (chứng chỉ khối). Và nhiệm vụ của nó là khóa lại đúng một tập hợp cử tri duy nhất cho khối đó. Không phải một tập hợp hợp lệ. Mà là tập hợp.

Vì vậy, chứng chỉ không thật sự dùng để chứng minh khối đã xảy ra. Cơ chế đồng thuận (consensus) đã làm điều đó. Nó nhằm đảm bảo rằng Dusk có đúng một câu trả lời cho câu hỏi: “Ai đã bỏ phiếu, và họ được trả bao nhiêu cho phần đó.” Một cơ chế nhỏ, nhưng nó bít một khoảng trống có thể khiến hệ thống phần thưởng của Dusk bị mơ hồ.

Khi nào chứng chỉ (certificate) của một khối được tạo và được đưa vào Mạng Dusk?
In the same block it attest to
60%
At the end of every epoch
30%
Only during emergency mode
0%
Next block attests prior
10%
10 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
Đã xác minh
#termmax @termmax Tôi từng nghĩ một người quản lý (curator) trong DeFi chủ yếu ở đó để quyết định tiền sẽ đi đến đâu. Sau khi đọc kỹ hơn các tài liệu @termmax , tôi nghĩ điều đó đã bỏ lỡ vai trò lớn hơn. Một curator cũng đang đưa ra các quyết định về rủi ro. Trong TermMax, các curator có thể thiết lập các đường cong định giá và các tham số rủi ro cho thị trường. Vì vậy họ không chỉ đơn giản là chuyển vốn qua lại. Họ đang giúp quyết định các điều kiện vay và cho vay nên có dạng như thế nào. Đây là phần khiến tôi thấy thú vị. Giả sử một thị trường có tài sản thế chấp biến động. Một curator có thể cần đặt các giới hạn rủi ro chặt chẽ hơn và một đường cong định giá khác so với trường hợp một tài sản ổn định hơn. Những lựa chọn đó có thể ảnh hưởng đến việc bao nhiêu vốn được sử dụng và mức lãi suất mà người dùng thấy. Vì vậy, câu hỏi thực sự không chỉ đơn giản là liệu curator có thể quản lý thanh khoản hay không. Mà là nên trao bao nhiêu mức độ phán đoán cho chính người quản lý đó ngay từ đầu. Trao nhiều quyền ra quyết định hơn cho một chuyên gia có thể giúp hệ thống phản ứng nhanh hơn trước những thay đổi của điều kiện thị trường. Nhưng đồng thời nó cũng tạo ra một điểm khác mà người dùng phải tin tưởng. Nếu các tham số được chọn kém, vấn đề không chỉ là vốn kém hiệu quả. Nó có thể trở thành một vấn đề rủi ro. Sự giằng co đó là điều nổi bật với tôi ở TermMax. Các quy tắc của giao thức thì có thể dự đoán được, nhưng chúng có thể phản ứng chậm. Các curator có thể phản ứng nhanh hơn, nhưng các quyết định của họ cần các cơ chế kiểm soát chặt chẽ hơn. Và điều đó để lại cho tôi một câu hỏi: TermMax nên trao cho các curator bao nhiêu mức phán đoán thị trường, và bao nhiêu nên được giữ nằm trong các quy tắc cố định của giao thức? Các curator của TermMax giúp thiết lập gì?
#termmax @TermMax

Tôi từng nghĩ một người quản lý (curator) trong DeFi chủ yếu ở đó để quyết định tiền sẽ đi đến đâu. Sau khi đọc kỹ hơn các tài liệu @TermMax , tôi nghĩ điều đó đã bỏ lỡ vai trò lớn hơn.

Một curator cũng đang đưa ra các quyết định về rủi ro.

Trong TermMax, các curator có thể thiết lập các đường cong định giá và các tham số rủi ro cho thị trường. Vì vậy họ không chỉ đơn giản là chuyển vốn qua lại. Họ đang giúp quyết định các điều kiện vay và cho vay nên có dạng như thế nào.

Đây là phần khiến tôi thấy thú vị.

Giả sử một thị trường có tài sản thế chấp biến động. Một curator có thể cần đặt các giới hạn rủi ro chặt chẽ hơn và một đường cong định giá khác so với trường hợp một tài sản ổn định hơn. Những lựa chọn đó có thể ảnh hưởng đến việc bao nhiêu vốn được sử dụng và mức lãi suất mà người dùng thấy.

Vì vậy, câu hỏi thực sự không chỉ đơn giản là liệu curator có thể quản lý thanh khoản hay không.

Mà là nên trao bao nhiêu mức độ phán đoán cho chính người quản lý đó ngay từ đầu.

Trao nhiều quyền ra quyết định hơn cho một chuyên gia có thể giúp hệ thống phản ứng nhanh hơn trước những thay đổi của điều kiện thị trường. Nhưng đồng thời nó cũng tạo ra một điểm khác mà người dùng phải tin tưởng. Nếu các tham số được chọn kém, vấn đề không chỉ là vốn kém hiệu quả. Nó có thể trở thành một vấn đề rủi ro.

Sự giằng co đó là điều nổi bật với tôi ở TermMax.

Các quy tắc của giao thức thì có thể dự đoán được, nhưng chúng có thể phản ứng chậm. Các curator có thể phản ứng nhanh hơn, nhưng các quyết định của họ cần các cơ chế kiểm soát chặt chẽ hơn.

Và điều đó để lại cho tôi một câu hỏi: TermMax nên trao cho các curator bao nhiêu mức phán đoán thị trường, và bao nhiêu nên được giữ nằm trong các quy tắc cố định của giao thức?

Các curator của TermMax giúp thiết lập gì?
Pricing and risk parameters
43%
Blockchain consensus rules
29%
Token supply schedule
28%
Wallet recovery phrases
0%
7 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
·
--
Tăng giá
MrRUHUL
·
--
Là một người sáng tạo trên Binance Square, chúng tôi muốn điều gì... và những kỳ vọng của chúng tôi từ Binance
Các bạn ơi, hôm nay tôi sắp nói điều gì đó quan trọng với đội ngũ Binance sau khi nghe rất nhiều ý kiến từ cộng đồng người sáng tạo... Nên
Thưa Binance, với tư cách là một người sáng tạo kiên định, chúng tôi bỏ công sức và dành thời gian 24/7 cho Binance, ngày này qua ngày khác, tháng này qua tháng khác, năm này qua năm khác, với kỳ vọng rằng với tư cách là người sáng tạo, chúng tôi có thể kiếm được rất nhiều tiền. Từ góc nhìn của một người sáng tạo, chúng tôi kỳ vọng Binance sẽ mang đến cho chúng tôi một giải pháp kiếm tiền vĩnh viễn. Nhưng hy vọng và kỳ vọng của chúng tôi đang hoàn toàn bị phá vỡ.

Chúng tôi biết rằng có một nền tảng cho người sáng tạo, có mục alpha để viết kiếm tiền, nhưng những thứ đó không phải là giải pháp lâu dài. Chúng tôi cũng biết chuyện gì đang diễn ra phía sau mục creator paid hoặc alpha và viết để kiếm tiền, v.v.
Chứng khoán được mã hóa nghe như chứng khoán. Nhưng có một khác biệt quan trọng. 📈 Bạn có thể đã thấy bStocks của Binance và tự hỏi: “Vậy tôi có thực sự đang mua cổ phiếu của công ty không?” Đây chính là lúc người mới bắt đầu nên chậm lại và hiểu rõ cấu trúc. bStocks được thiết kế để mang lại cho người dùng khả năng tiếp cận với các cổ phiếu truyền thống thông qua các phiên bản được mã hóa, đưa mức độ tiếp xúc của thị trường truyền thống vào môi trường dựa trên blockchain. Nhưng việc “tiếp xúc” dưới dạng mã hóa không tự động đồng nghĩa với việc bạn đang nắm giữ một cổ phiếu thông thường thông qua công ty môi giới truyền thống. Trước khi sử dụng một sản phẩm như thế này, hãy hiểu: 🔹 Token thực sự đại diện cho cái gì? 🔹 Những quyền gì đi kèm với sản phẩm? 🔹 Tài sản cơ sở được biểu diễn và được bảo đảm như thế nào? 🔹 Thời gian giao dịch và điều kiện thanh khoản ra sao? 🔹 Những khoản phí và rủi ro nào áp dụng? Vì thế, tôi nghĩ câu hỏi quan trọng nhất không phải là: “Liệu tôi có thể giao dịch cổ phiếu on-chain không?” Mà là: “Mình có hiểu mình đang thực sự mua cái gì không?” Sự khác biệt này rất quan trọng. Mã hóa có thể giúp các tài sản truyền thống trở nên dễ tiếp cận hơn trong hệ sinh thái tài sản kỹ thuật số, nhưng khả năng tiếp cận không làm mất đi rủi ro đầu tư. 📌 Quy tắc của tôi: Hiểu tài sản → hiểu cấu trúc → hiểu rủi ro → rồi mới quyết định. Đừng mua thứ gì chỉ vì tên của nó trông quen thuộc. #Binance #BStocks #Tokenization #Investing #cryptoeducation
Chứng khoán được mã hóa nghe như chứng khoán. Nhưng có một khác biệt quan trọng. 📈

Bạn có thể đã thấy bStocks của Binance và tự hỏi:

“Vậy tôi có thực sự đang mua cổ phiếu của công ty không?”

Đây chính là lúc người mới bắt đầu nên chậm lại và hiểu rõ cấu trúc.

bStocks được thiết kế để mang lại cho người dùng khả năng tiếp cận với các cổ phiếu truyền thống thông qua các phiên bản được mã hóa, đưa mức độ tiếp xúc của thị trường truyền thống vào môi trường dựa trên blockchain.

Nhưng việc “tiếp xúc” dưới dạng mã hóa không tự động đồng nghĩa với việc bạn đang nắm giữ một cổ phiếu thông thường thông qua công ty môi giới truyền thống.

Trước khi sử dụng một sản phẩm như thế này, hãy hiểu:

🔹 Token thực sự đại diện cho cái gì?

🔹 Những quyền gì đi kèm với sản phẩm?

🔹 Tài sản cơ sở được biểu diễn và được bảo đảm như thế nào?

🔹 Thời gian giao dịch và điều kiện thanh khoản ra sao?

🔹 Những khoản phí và rủi ro nào áp dụng?

Vì thế, tôi nghĩ câu hỏi quan trọng nhất không phải là:

“Liệu tôi có thể giao dịch cổ phiếu on-chain không?”

Mà là:

“Mình có hiểu mình đang thực sự mua cái gì không?”

Sự khác biệt này rất quan trọng.

Mã hóa có thể giúp các tài sản truyền thống trở nên dễ tiếp cận hơn trong hệ sinh thái tài sản kỹ thuật số, nhưng khả năng tiếp cận không làm mất đi rủi ro đầu tư.

📌 Quy tắc của tôi:
Hiểu tài sản → hiểu cấu trúc → hiểu rủi ro → rồi mới quyết định.

Đừng mua thứ gì chỉ vì tên của nó trông quen thuộc.

#Binance #BStocks #Tokenization #Investing #cryptoeducation
Đã xác minh
#termmax @termmax Trước đây, tôi nghĩ rằng lãi suất vay cố định đơn giản chỉ có nghĩa là TermMax loại bỏ sự biến động của lãi suất khỏi phương trình. Sau khi xem lại cơ chế, tôi nghĩ mô tả đó bỏ lỡ phần thú vị hơn. @termmax không chỉ “ghi” một lãi suất cố định vào một khoản vay. Nó chuyển nghĩa vụ trả nợ trong tương lai thành các Token Lãi Suất Cố Định (Fixed Rate Tokens - FTs). Bên vay phát hành các FTs đại diện cho những gì sẽ phải trả khi đáo hạn, sau đó tách phần gốc và phần lãi để tiếp cận tài sản đã vay. Điều đó tạo ra một chuỗi hữu ích: nghĩa vụ trong tương lai → quyền yêu cầu được token hóa → thanh khoản tức thời. Nhưng vẫn có một sự đánh đổi. Bên vay có được sự chắc chắn về nghĩa vụ khi đáo hạn, nhưng sự chắc chắn đó lại gắn với một thị trường nơi các FTs tương ứng có thể được giao dịch ở các mức giá khác nhau trước ngày đáo hạn. Vì vậy, lãi suất cố định loại bỏ một loại không chắc chắn trong khi đồng thời đưa vào một chiều kích giá thị trường xung quanh tài sản dùng để thanh toán. Sự khác biệt đó đã thay đổi cách tôi nghĩ về TermMax. Câu hỏi thú vị không phải là việc lãi suất có cố định hay không. Mà là liệu việc token hóa nghĩa vụ có tạo ra một cách quản lý tốt hơn cho phần không chắc chắn vẫn còn tồn tại xung quanh nó hay không. Phần gì được cố định trong TermMax?
#termmax @TermMax

Trước đây, tôi nghĩ rằng lãi suất vay cố định đơn giản chỉ có nghĩa là TermMax loại bỏ sự biến động của lãi suất khỏi phương trình.

Sau khi xem lại cơ chế, tôi nghĩ mô tả đó bỏ lỡ phần thú vị hơn.

@TermMax không chỉ “ghi” một lãi suất cố định vào một khoản vay. Nó chuyển nghĩa vụ trả nợ trong tương lai thành các Token Lãi Suất Cố Định (Fixed Rate Tokens - FTs). Bên vay phát hành các FTs đại diện cho những gì sẽ phải trả khi đáo hạn, sau đó tách phần gốc và phần lãi để tiếp cận tài sản đã vay.

Điều đó tạo ra một chuỗi hữu ích: nghĩa vụ trong tương lai → quyền yêu cầu được token hóa → thanh khoản tức thời.

Nhưng vẫn có một sự đánh đổi.

Bên vay có được sự chắc chắn về nghĩa vụ khi đáo hạn, nhưng sự chắc chắn đó lại gắn với một thị trường nơi các FTs tương ứng có thể được giao dịch ở các mức giá khác nhau trước ngày đáo hạn. Vì vậy, lãi suất cố định loại bỏ một loại không chắc chắn trong khi đồng thời đưa vào một chiều kích giá thị trường xung quanh tài sản dùng để thanh toán.

Sự khác biệt đó đã thay đổi cách tôi nghĩ về TermMax.

Câu hỏi thú vị không phải là việc lãi suất có cố định hay không.

Mà là liệu việc token hóa nghĩa vụ có tạo ra một cách quản lý tốt hơn cho phần không chắc chắn vẫn còn tồn tại xung quanh nó hay không.

Phần gì được cố định trong TermMax?
Gas
53%
Rate
47%
Slippage
0%
Fees
0%
15 phiếu bầu • Cuộc bỏ phiếu đã kết thúc
Đã xác minh
#dusk $DUSK @Dusk_Foundation Nhìn thì có vẻ đơn giản cho đến khi tôi thực sự lần theo cách Mạng Dusk xác minh một phiếu bầu của ủy ban. Giả định ban đầu của tôi là việc tổng hợp chữ ký chủ yếu là tối ưu băng thông—một cách nén nhiều chữ ký thành một để các khối giữ được kích thước nhỏ. Tôi nghĩ rằng việc xác minh phiếu bầu của một ủy ban nghĩa là kiểm tra chữ ký của từng nhà cung cấp (provisioner) riêng lẻ rồi gói kết quả lại chỉ ở giai đoạn lưu trữ. Sáu mươi bốn khoản tín dụng tương ứng với sáu mươi bốn lần kiểm tra riêng lẻ rồi được nén lại sau đó. Tôi đã sai. tài liệu cho thấy việc tổng hợp diễn ra ở mức mật mã, không chỉ ở mức lưu trữ. Chữ ký BLS có một tính chất: về cơ bản là ECDSA không—các chữ ký cá nhân trên cùng một thông điệp có thể kết hợp thành một chữ ký duy nhất thông qua phép cộng điểm trên đường cong elliptic. Chữ ký đã kết hợp đó sau đó được đối chiếu với một khóa công khai đã tổng hợp bằng đúng một phép ghép (pairing) duy nhất—một lần kiểm tra thay vì một lần cho mỗi cử tri. Cơ chế này chỉ hoạt động gọn gàng vì mỗi provisioner trong một ủy ban đều ký chính xác cùng một thông điệp: kết quả của một bước thẩm định (validation) hoặc phê chuẩn (ratification) cụ thể. Cùng một thông điệp, nhiều người ký khác nhau—một bằng chứng tổng hợp duy nhất. Một bitset sau đó ghi lại những thành viên nào của ủy ban được đưa vào trong phép tổng hợp đó, vì bản thân chữ ký không tiết lộ trực tiếp ai thực sự đã bỏ phiếu. việc đánh đổi ở đây là: tổng hợp nén chi phí xác minh, chứ không nén trách nhiệm giải trình. Bạn có được một lần kiểm tra nhanh duy nhất để xác thực tính hợp lệ của đủ điều kiện (quorum), nhưng việc tái dựng xem ai đã bỏ phiếu theo hướng nào và tính toán sức mạnh có trọng số tín dụng vẫn đòi hỏi lớp bitset riêng biệt đó nằm song song với chữ ký. Vì vậy tôi cứ tự hỏi liệu sự tách bạch giữa “bằng chứng được nén” và “trách nhiệm được mở rộng” này có trở thành nút thắt cổ chai khi kích thước ủy ban của Network @Dusk_Foundation thay đổi hoặc mô hình tham gia dịch chuyển hay không. Việc tổng hợp có tiếp tục rẻ khi $DUSK staking tăng lên không, hay lớp bitset mới chính là ràng buộc thực sự?
#dusk $DUSK @Dusk

Nhìn thì có vẻ đơn giản cho đến khi tôi thực sự lần theo cách Mạng Dusk xác minh một phiếu bầu của ủy ban. Giả định ban đầu của tôi là việc tổng hợp chữ ký chủ yếu là tối ưu băng thông—một cách nén nhiều chữ ký thành một để các khối giữ được kích thước nhỏ. Tôi nghĩ rằng việc xác minh phiếu bầu của một ủy ban nghĩa là kiểm tra chữ ký của từng nhà cung cấp (provisioner) riêng lẻ rồi gói kết quả lại chỉ ở giai đoạn lưu trữ. Sáu mươi bốn khoản tín dụng tương ứng với sáu mươi bốn lần kiểm tra riêng lẻ rồi được nén lại sau đó.

Tôi đã sai.

tài liệu cho thấy việc tổng hợp diễn ra ở mức mật mã, không chỉ ở mức lưu trữ. Chữ ký BLS có một tính chất: về cơ bản là ECDSA không—các chữ ký cá nhân trên cùng một thông điệp có thể kết hợp thành một chữ ký duy nhất thông qua phép cộng điểm trên đường cong elliptic. Chữ ký đã kết hợp đó sau đó được đối chiếu với một khóa công khai đã tổng hợp bằng đúng một phép ghép (pairing) duy nhất—một lần kiểm tra thay vì một lần cho mỗi cử tri.
Cơ chế này chỉ hoạt động gọn gàng vì mỗi provisioner trong một ủy ban đều ký chính xác cùng một thông điệp: kết quả của một bước thẩm định (validation) hoặc phê chuẩn (ratification) cụ thể. Cùng một thông điệp, nhiều người ký khác nhau—một bằng chứng tổng hợp duy nhất. Một bitset sau đó ghi lại những thành viên nào của ủy ban được đưa vào trong phép tổng hợp đó, vì bản thân chữ ký không tiết lộ trực tiếp ai thực sự đã bỏ phiếu.

việc đánh đổi ở đây là: tổng hợp nén chi phí xác minh, chứ không nén trách nhiệm giải trình. Bạn có được một lần kiểm tra nhanh duy nhất để xác thực tính hợp lệ của đủ điều kiện (quorum), nhưng việc tái dựng xem ai đã bỏ phiếu theo hướng nào và tính toán sức mạnh có trọng số tín dụng vẫn đòi hỏi lớp bitset riêng biệt đó nằm song song với chữ ký. Vì vậy tôi cứ tự hỏi liệu sự tách bạch giữa “bằng chứng được nén” và “trách nhiệm được mở rộng” này có trở thành nút thắt cổ chai khi kích thước ủy ban của Network @Dusk thay đổi hoặc mô hình tham gia dịch chuyển hay không. Việc tổng hợp có tiếp tục rẻ khi $DUSK staking tăng lên không, hay lớp bitset mới chính là ràng buộc thực sự?
Đă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