Đăng
--
Eman098
·
--
#dusk $DUSK @Dusk
Điều thu hút tôi khi xem qua tài liệu của Dusk: chỉ có hai hợp đồng tồn tại ngay từ genesis. Đó là hợp đồng stake và hợp đồng transfer. Mọi thứ khác, bao gồm DuskVM và DuskEVM, đều nằm “trên” hai hợp đồng này.
Đó là một mức độ tập trung kỳ lạ đối với một chuỗi được xây dựng để giải quyết các tài sản được quản lý. Vì vậy, tôi muốn kiểm tra hai hợp đồng này thực sự làm gì và liệu chúng có thể bị thay đổi về sau không.
Hợp đồng stake theo dõi các provisioner (bên cung cấp dịch vụ) đang được stake bao nhiêu, thời điểm phần thưởng chín muồi khi nào, và khi slashing áp dụng thì xử lý ra sao. Hợp đồng transfer xử lý cả số dư công khai (Moonlight) và số dư được che giấu (Phoenix), và đây là nơi duy nhất mà việc chuyển tiền từ hợp đồng đến hợp đồng thực sự diễn ra. Mọi môi trường thực thi đều định tuyến thông qua nó để phục vụ cho mục đích thanh toán và tính sẵn có dữ liệu theo các tài liệu hiện tại.
Tại sao điều này quan trọng: nếu bạn đang xây dựng trên DuskEVM hoặc phát hành tài sản thông qua Dusk Trade, bạn không chỉ tin vào logic hợp đồng của chính bạn. Bạn còn phải tin rằng hai hợp đồng genesis này vận hành đúng đắn một cách lâu dài, vì chúng là lớp nền thanh toán (settlement substrate) nằm bên dưới mọi thứ khác.
Đây là phần tôi không thể xác định rõ. Tài liệu mô tả các hợp đồng này được tái cấu trúc theo thời gian: hợp đồng staking đã được xây dựng lại để khắc phục vấn đề về lưu trữ (storage), và về sau các cập nhật kỹ thuật đã thay đổi cấu trúc Event của nó. Như vậy rõ ràng chúng không “bất biến” theo nghĩa là được khóa cố định ngay từ genesis.
Điều chưa rõ với tôi là lộ trình nâng cấp thực tế: việc nâng cấp có mang tính tùy ý (nhóm phát triển/protocol triển khai bản nâng cấp mạng) hay có một bước quản trị chính thức trên chuỗi (on-chain governance) mà các provisioner bỏ phiếu trước khi logic của hợp đồng genesis thay đổi? Các tài liệu tôi tìm thấy mô tả các hợp đồng làm gì, chứ không nói rõ việc các thay đổi đối với chúng được ủy quyền như thế nào.
Với một chuỗi định vị để giải quyết theo hướng tổ chức (institutional settlement), sự khác biệt “nâng cấp được nhóm của tổ chức dự án ủy quyền” vs. “nâng cấp được các provisioner phê chuẩn” sẽ lẽ ra phải được ghi rõ ràng ở đâu đó.
Có ai đã thấy nơi nào nêu rõ <@Dusk > chỉ định quy trình ủy quyền (Authorization) thực tế cho các thay đổi đối với hợp đồng genesis chưa?
$DUSK #dusk
Điều thu hút tôi khi xem qua tài liệu của Dusk: chỉ có hai hợp đồng tồn tại ngay từ genesis. Đó là hợp đồng stake và hợp đồng transfer. Mọi thứ khác, bao gồm DuskVM và DuskEVM, đều nằm “trên” hai hợp đồng này.
Đó là một mức độ tập trung kỳ lạ đối với một chuỗi được xây dựng để giải quyết các tài sản được quản lý. Vì vậy, tôi muốn kiểm tra hai hợp đồng này thực sự làm gì và liệu chúng có thể bị thay đổi về sau không.
Hợp đồng stake theo dõi các provisioner (bên cung cấp dịch vụ) đang được stake bao nhiêu, thời điểm phần thưởng chín muồi khi nào, và khi slashing áp dụng thì xử lý ra sao. Hợp đồng transfer xử lý cả số dư công khai (Moonlight) và số dư được che giấu (Phoenix), và đây là nơi duy nhất mà việc chuyển tiền từ hợp đồng đến hợp đồng thực sự diễn ra. Mọi môi trường thực thi đều định tuyến thông qua nó để phục vụ cho mục đích thanh toán và tính sẵn có dữ liệu theo các tài liệu hiện tại.
Tại sao điều này quan trọng: nếu bạn đang xây dựng trên DuskEVM hoặc phát hành tài sản thông qua Dusk Trade, bạn không chỉ tin vào logic hợp đồng của chính bạn. Bạn còn phải tin rằng hai hợp đồng genesis này vận hành đúng đắn một cách lâu dài, vì chúng là lớp nền thanh toán (settlement substrate) nằm bên dưới mọi thứ khác.
Đây là phần tôi không thể xác định rõ. Tài liệu mô tả các hợp đồng này được tái cấu trúc theo thời gian: hợp đồng staking đã được xây dựng lại để khắc phục vấn đề về lưu trữ (storage), và về sau các cập nhật kỹ thuật đã thay đổi cấu trúc Event của nó. Như vậy rõ ràng chúng không “bất biến” theo nghĩa là được khóa cố định ngay từ genesis.
Điều chưa rõ với tôi là lộ trình nâng cấp thực tế: việc nâng cấp có mang tính tùy ý (nhóm phát triển/protocol triển khai bản nâng cấp mạng) hay có một bước quản trị chính thức trên chuỗi (on-chain governance) mà các provisioner bỏ phiếu trước khi logic của hợp đồng genesis thay đổi? Các tài liệu tôi tìm thấy mô tả các hợp đồng làm gì, chứ không nói rõ việc các thay đổi đối với chúng được ủy quyền như thế nào.
Với một chuỗi định vị để giải quyết theo hướng tổ chức (institutional settlement), sự khác biệt “nâng cấp được nhóm của tổ chức dự án ủy quyền” vs. “nâng cấp được các provisioner phê chuẩn” sẽ lẽ ra phải được ghi rõ ràng ở đâu đó.
Có ai đã thấy nơi nào nêu rõ <@Dusk > chỉ định quy trình ủy quyền (Authorization) thực tế cho các thay đổi đối với hợp đồng genesis chưa?
$DUSK #dusk
Tuyên bố miễn trừ trách nhiệm: Nội dung bao gồm cả quan điểm của bên thứ ba, không phải lời khuyên. Có thể sử dụng nội dung do Binance Ai đưa ra nhưng không được đảm bảo. Xem Điều khoản & Điều kiện.