Tôi đã đi lại quy trình đồng thế chấp của Babylon một lần nữa. Điều khó chịu nhất là: nhiều điều kiện quan trọng, chỉ khi người dùng chưa nhận được phần thưởng thì họ mới phát hiện ra.
Bên phía chính thức tóm tắt quy trình thành hai bước: BTC được ủy thác cho Finality Provider, sau đó BABY lại ủy thác cho trình xác thực (validator). Nhưng khi thực hiện thực tế, BTC phải đi từ trạng thái PENDING qua VERIFIED, cuối cùng mới vào ACTIVE; chỉ khi ở trạng thái ACTIVE thì mới được tính phần thưởng. Ngoài ra, BTC và BABY còn phải dùng cùng một địa chỉ BABY. Nếu địa chỉ không khớp, phần thưởng đồng thế chấp sẽ bị về 0 ngay lập tức. Muốn ăn trọn hiệu suất nhận phần thưởng, còn phải nhớ rằng khoảng 1 BTC tương ứng với 20,000 BABY.
Vấn đề là người dùng phổ thông nhìn thấy “đã gửi” hoặc “đã xác minh” thì rất dễ cho rằng mọi việc đã xong. Còn việc bị kẹt ở bước nào, vì sao không có phần thưởng, Finality Provider được chọn có còn đang hoạt động hay không, hai địa chỉ rốt cuộc có khớp nhau hay không—đáng lẽ trang nên nói rõ ngay. Không nên để người dùng tự lật tài liệu và đoán mò.
Hiện tại bảng điều khiển của Babylon hiển thị khoảng 51,342 BTC đã được thế chấp, trong 132 Finality Provider thì chỉ có 36 cái ở trạng thái hoạt động. Biên độ lợi suất năm của BTC nằm trong khoảng 0.04% đến 0.70%. Quy mô đã được xây dựng rồi, nhưng phía người dùng vẫn phải tự dò lỗi.
Khâu rút ra cũng không hề dễ dàng như bề ngoài. Tài liệu chính thức về rút (unstake) BTC ghi rõ thời gian chờ tối thiểu là 301 khối Bitcoin; việc khắc phục sự cố CLI có thể còn liên quan đến tham số gas, cấu hình RPC, GRPC; nếu không giải quyết được thì đi lên Discord để nhờ hỗ trợ.
Tôi đặt câu hỏi về @BabylonLabs_io rất thẳng thắn: có thể hiểu rằng giao thức phức tạp, nhưng sản phẩm không thể bê nguyên độ phức tạp đó giao cho người dùng.
Thứ thực sự cần bổ sung là giải thích trạng thái, định vị lỗi và đường xử lý rõ ràng. Nếu không, cái gọi là “tự quản lý tài sản” rất dễ biến thành—mọi vấn đề mà người dùng không hiểu được thì người dùng sẽ phải tự chịu trách nhiệm.
#baby $BABY @BabylonLabs_io
Bên phía chính thức tóm tắt quy trình thành hai bước: BTC được ủy thác cho Finality Provider, sau đó BABY lại ủy thác cho trình xác thực (validator). Nhưng khi thực hiện thực tế, BTC phải đi từ trạng thái PENDING qua VERIFIED, cuối cùng mới vào ACTIVE; chỉ khi ở trạng thái ACTIVE thì mới được tính phần thưởng. Ngoài ra, BTC và BABY còn phải dùng cùng một địa chỉ BABY. Nếu địa chỉ không khớp, phần thưởng đồng thế chấp sẽ bị về 0 ngay lập tức. Muốn ăn trọn hiệu suất nhận phần thưởng, còn phải nhớ rằng khoảng 1 BTC tương ứng với 20,000 BABY.
Vấn đề là người dùng phổ thông nhìn thấy “đã gửi” hoặc “đã xác minh” thì rất dễ cho rằng mọi việc đã xong. Còn việc bị kẹt ở bước nào, vì sao không có phần thưởng, Finality Provider được chọn có còn đang hoạt động hay không, hai địa chỉ rốt cuộc có khớp nhau hay không—đáng lẽ trang nên nói rõ ngay. Không nên để người dùng tự lật tài liệu và đoán mò.
Hiện tại bảng điều khiển của Babylon hiển thị khoảng 51,342 BTC đã được thế chấp, trong 132 Finality Provider thì chỉ có 36 cái ở trạng thái hoạt động. Biên độ lợi suất năm của BTC nằm trong khoảng 0.04% đến 0.70%. Quy mô đã được xây dựng rồi, nhưng phía người dùng vẫn phải tự dò lỗi.
Khâu rút ra cũng không hề dễ dàng như bề ngoài. Tài liệu chính thức về rút (unstake) BTC ghi rõ thời gian chờ tối thiểu là 301 khối Bitcoin; việc khắc phục sự cố CLI có thể còn liên quan đến tham số gas, cấu hình RPC, GRPC; nếu không giải quyết được thì đi lên Discord để nhờ hỗ trợ.
Tôi đặt câu hỏi về @BabylonLabs_io rất thẳng thắn: có thể hiểu rằng giao thức phức tạp, nhưng sản phẩm không thể bê nguyên độ phức tạp đó giao cho người dùng.
Thứ thực sự cần bổ sung là giải thích trạng thái, định vị lỗi và đường xử lý rõ ràng. Nếu không, cái gọi là “tự quản lý tài sản” rất dễ biến thành—mọi vấn đề mà người dùng không hiểu được thì người dùng sẽ phải tự chịu trách nhiệm.
#baby $BABY @BabylonLabs_io