Lần này tôi đọc tài liệu phát triển của Dusk, thứ thực sự khiến tôi dừng lại không phải là ZK, cũng không phải quyền riêng tư.
Mà là một chi tiết nhỏ ở giao diện:
**Nút sẽ thông báo cho client phiên bản Rusk của chính nó, và client cũng có thể chủ động yêu cầu một khoảng phiên bản.**
Nếu không tương thích phiên bản, thì từ chối ngay.
Nhìn qua thì điều này chẳng liên quan gì đến câu chuyện lớn về blockchain.
Nhưng khi tôi đưa nó vào quy trình phát triển thực tế, tôi lại thấy khá thú vị.
Vì nỗi sợ lớn nhất của rất nhiều ứng dụng trên chuỗi không phải là API chậm hơn một chút.
Mà là:
Hôm nay vẫn dùng được, nhưng sau khi nâng cấp thì đột nhiên xuất hiện tình trạng “một số node nhận, một số node không nhận”.
Nếu nhà phát triển không biết mình đang kết nối đến node nào và node đó chạy phiên bản gì, thì rất khó để xác định vấn đề đến từ code, từ node, hay chính bản thân giao thức.
Hiện tại, Dusk đưa trực tiếp thông tin phiên bản vào phản hồi HTTP, đồng thời cho phép client thực hiện strict version check.
Trước đây tôi quen đánh giá một L1 hoạt động tốt hay không dựa vào TPS và tính cuối cùng.
Nhưng bây giờ tôi lại thấy rằng, những quy tắc nhỏ ở tầng giao diện này có thể cho thấy rõ hơn liệu một mạng lưới có thực sự cân nhắc các rắc rối mà nhà phát triển sẽ gặp hay không.
Vì cơ sở hạ tầng đáng sợ nhất không phải là sự phức tạp.
Mà là **tính không chắc chắn**.
Nếu một ứng dụng phụ thuộc vào một năng lực nào đó của node, và sau khi nâng cấp mà hành vi của node thay đổi, thì kẻ xui xẻo nhất thường không phải là đội ngũ giao thức, mà là những ứng dụng đã được triển khai.
Vì vậy, thứ trông có vẻ rất “kỹ sư” này—kiểm soát phiên bản—thực ra lại giải quyết một vấn đề rất thực tế:
Giúp nhà phát triển biết mình đang nói chuyện với đúng bộ quy tắc giao thức nào.
Đó cũng là điều khiến tôi hiện tại thấy Dusk đáng để nghiên cứu.
Một L1 thực sự trưởng thành không chỉ là chạy cho chuỗi hoạt động.
Mà còn phải giúp người khác khi kết nối vào biết ranh giới nằm ở đâu.
#dusk $DUSK @Dusk
Mà là một chi tiết nhỏ ở giao diện:
**Nút sẽ thông báo cho client phiên bản Rusk của chính nó, và client cũng có thể chủ động yêu cầu một khoảng phiên bản.**
Nếu không tương thích phiên bản, thì từ chối ngay.
Nhìn qua thì điều này chẳng liên quan gì đến câu chuyện lớn về blockchain.
Nhưng khi tôi đưa nó vào quy trình phát triển thực tế, tôi lại thấy khá thú vị.
Vì nỗi sợ lớn nhất của rất nhiều ứng dụng trên chuỗi không phải là API chậm hơn một chút.
Mà là:
Hôm nay vẫn dùng được, nhưng sau khi nâng cấp thì đột nhiên xuất hiện tình trạng “một số node nhận, một số node không nhận”.
Nếu nhà phát triển không biết mình đang kết nối đến node nào và node đó chạy phiên bản gì, thì rất khó để xác định vấn đề đến từ code, từ node, hay chính bản thân giao thức.
Hiện tại, Dusk đưa trực tiếp thông tin phiên bản vào phản hồi HTTP, đồng thời cho phép client thực hiện strict version check.
Trước đây tôi quen đánh giá một L1 hoạt động tốt hay không dựa vào TPS và tính cuối cùng.
Nhưng bây giờ tôi lại thấy rằng, những quy tắc nhỏ ở tầng giao diện này có thể cho thấy rõ hơn liệu một mạng lưới có thực sự cân nhắc các rắc rối mà nhà phát triển sẽ gặp hay không.
Vì cơ sở hạ tầng đáng sợ nhất không phải là sự phức tạp.
Mà là **tính không chắc chắn**.
Nếu một ứng dụng phụ thuộc vào một năng lực nào đó của node, và sau khi nâng cấp mà hành vi của node thay đổi, thì kẻ xui xẻo nhất thường không phải là đội ngũ giao thức, mà là những ứng dụng đã được triển khai.
Vì vậy, thứ trông có vẻ rất “kỹ sư” này—kiểm soát phiên bản—thực ra lại giải quyết một vấn đề rất thực tế:
Giúp nhà phát triển biết mình đang nói chuyện với đúng bộ quy tắc giao thức nào.
Đó cũng là điều khiến tôi hiện tại thấy Dusk đáng để nghiên cứu.
Một L1 thực sự trưởng thành không chỉ là chạy cho chuỗi hoạt động.
Mà còn phải giúp người khác khi kết nối vào biết ranh giới nằm ở đâu.
#dusk $DUSK @Dusk
