Tôi hiện có nghi vấn lớn nhất về @Dusk , không phải là liệu có làm được bằng mặt kỹ thuật hay không, mà là người dùng phổ thông có dám dùng hay không.
Gần đây tôi đã rà lại quy trình thao tác thực tế của nó một lần nữa. Bên kỹ thuật cập nhật đúng là khá thường xuyên, nhưng khi đến tay người dùng thì các hành động nền tảng nhất như di chuyển, chuyển chuỗi (cross-chain), và staking/phần thưởng, tỷ lệ dung sai (tỷ lệ xử lý lỗi) vẫn còn hơi thấp.
Ví dụ, việc chuyển ERC20/BEP20 DUSK sang mainnet không phải chỉ cần bấm một cái là xong: trước hết phải Approve, rồi Execute; thiếu một bước thì sẽ không được xem là đã hoàn tất chuyển. Thời gian chờ điển hình mà tài liệu chính thức đưa ra vẫn khoảng 1 giờ, đồng thời còn cần chuẩn bị ETH/BNB trước để trả gas.
Điều khiến tôi quan tâm hơn nữa là việc chuyển từ mainnet sang BSC. Địa chỉ nhận cần chỉ định qua memo; tài liệu chính thức còn nhắc thẳng rằng nếu memo bị thiếu hoặc không hợp lệ, giao dịch có thể không được xử lý tự động, thậm chí tồn tại rủi ro là tài sản không thể khôi phục.
Với các game thủ kỳ cựu thì có thể sẽ nghĩ “thấy rõ không thì đâu có gì”, nhưng nếu sản phẩm hướng đến tệp người dùng lớn hơn thì không thể mãi đẩy toàn bộ trách nhiệm chống nhầm thao tác sang người dùng.
Staking cũng tương tự. Staking trực tiếp tối thiểu 1000 DUSK, nhưng bạn còn phải tự chạy provisioner, node cần duy trì trực tuyến, đồng bộ và đúng phiên bản; kích hoạt bình thường còn cần khoảng 6—12 giờ. Về mặt kỹ thuật thì không có gì đáng chê, nhưng từ góc nhìn của một người nắm giữ token bình thường thì rõ ràng đây vẫn chưa phải một thao tác “nhẹ nhàng”.
Hơn nữa, hồi tháng 1 năm nay dịch vụ bridge cũng từng xảy ra việc ví ký bị xâm nhập. Mặc dù phía chính thức sau đó có khẳng định là không phải lỗ hổng ở lớp đồng thuận của Dusk, nhưng người dùng phổ thông thực tế sẽ không giúp dự án phân biệt “an toàn giao thức” và “an toàn ở lớp dịch vụ”; họ chỉ quan tâm một điều: tiền của tôi thao tác nhầm hoặc hệ thống có vấn đề thì cuối cùng có rút lại/khôi phục được không?
Vì vậy hiện tại tôi ngược lại cảm thấy giai đoạn tiếp theo của Dusk không chỉ nên bổ sung hiệu năng nền tảng.
Mà là biến trải nghiệm mặc định của sản phẩm thành thứ “không điền nhầm”, “xem được trạng thái”, và “khi xảy ra lỗi thì có đường cứu”.
Kỹ thuật có thể phức tạp, nhưng trải nghiệm người dùng không thể phức tạp.
#dusk $DUSK @Dusk
Gần đây tôi đã rà lại quy trình thao tác thực tế của nó một lần nữa. Bên kỹ thuật cập nhật đúng là khá thường xuyên, nhưng khi đến tay người dùng thì các hành động nền tảng nhất như di chuyển, chuyển chuỗi (cross-chain), và staking/phần thưởng, tỷ lệ dung sai (tỷ lệ xử lý lỗi) vẫn còn hơi thấp.
Ví dụ, việc chuyển ERC20/BEP20 DUSK sang mainnet không phải chỉ cần bấm một cái là xong: trước hết phải Approve, rồi Execute; thiếu một bước thì sẽ không được xem là đã hoàn tất chuyển. Thời gian chờ điển hình mà tài liệu chính thức đưa ra vẫn khoảng 1 giờ, đồng thời còn cần chuẩn bị ETH/BNB trước để trả gas.
Điều khiến tôi quan tâm hơn nữa là việc chuyển từ mainnet sang BSC. Địa chỉ nhận cần chỉ định qua memo; tài liệu chính thức còn nhắc thẳng rằng nếu memo bị thiếu hoặc không hợp lệ, giao dịch có thể không được xử lý tự động, thậm chí tồn tại rủi ro là tài sản không thể khôi phục.
Với các game thủ kỳ cựu thì có thể sẽ nghĩ “thấy rõ không thì đâu có gì”, nhưng nếu sản phẩm hướng đến tệp người dùng lớn hơn thì không thể mãi đẩy toàn bộ trách nhiệm chống nhầm thao tác sang người dùng.
Staking cũng tương tự. Staking trực tiếp tối thiểu 1000 DUSK, nhưng bạn còn phải tự chạy provisioner, node cần duy trì trực tuyến, đồng bộ và đúng phiên bản; kích hoạt bình thường còn cần khoảng 6—12 giờ. Về mặt kỹ thuật thì không có gì đáng chê, nhưng từ góc nhìn của một người nắm giữ token bình thường thì rõ ràng đây vẫn chưa phải một thao tác “nhẹ nhàng”.
Hơn nữa, hồi tháng 1 năm nay dịch vụ bridge cũng từng xảy ra việc ví ký bị xâm nhập. Mặc dù phía chính thức sau đó có khẳng định là không phải lỗ hổng ở lớp đồng thuận của Dusk, nhưng người dùng phổ thông thực tế sẽ không giúp dự án phân biệt “an toàn giao thức” và “an toàn ở lớp dịch vụ”; họ chỉ quan tâm một điều: tiền của tôi thao tác nhầm hoặc hệ thống có vấn đề thì cuối cùng có rút lại/khôi phục được không?
Vì vậy hiện tại tôi ngược lại cảm thấy giai đoạn tiếp theo của Dusk không chỉ nên bổ sung hiệu năng nền tảng.
Mà là biến trải nghiệm mặc định của sản phẩm thành thứ “không điền nhầm”, “xem được trạng thái”, và “khi xảy ra lỗi thì có đường cứu”.
Kỹ thuật có thể phức tạp, nhưng trải nghiệm người dùng không thể phức tạp.
#dusk $DUSK @Dusk