Không ngừng nỗ lực và giờ từ hạng 750 lên top 100 không phải là một việc dễ dàng. Đó là sự cam kết và tính nhất quán hướng tới nội dung chất lượng. Khi tôi ở hạng 750 lúc đó, tâm trí tôi bị mắc kẹt và tôi đã đưa ra một vài lựa chọn sai trong $BANK & $SKYAI nhưng sau đó tâm trí tôi hoàn toàn chuyển hướng sang @BabylonLabs_io .
Hôm nay tôi đang đọc về backend staking của Babylon và gặp phải một điều mà tôi thực sự không hề dự đoán trước.
Có bao nhiêu thứ trông như là trạng thái on-chain thực sự đi qua hạ tầng off-chain trước, trước khi bạn từng thấy nó.
Trình lập chỉ mục staking (staking indexer), một dịch vụ cụ thể trong bộ backend của Babylon, đồng bộ các sự kiện ủy quyền (delegation events), trạng thái của nhà cung cấp cuối cùng (finality provider status) và các tham số staking toàn cầu từ cả Bitcoin và Babylon Genesis vào cơ sở dữ liệu riêng của nó. Cả giao diện frontend lẫn dịch vụ API staking đều đọc từ trình lập chỉ mục đó, chứ không đọc trực tiếp từ bất kỳ chuỗi nào, và tôi thú nhận rằng mình chưa hình dung ra điều này cho tới khi thấy nó được trình bày rõ ràng.
Lần đọc đầu tiên của tôi là, à, vậy thì đây chỉ là một lớp đệm (caching) để tăng tốc. Tiện thì có tiện, nhưng không phải thứ quyết định.
Không hẳn. Nếu trình lập chỉ mục bị tụt hậu trong việc đồng bộ, thì những gì người dùng thấy về phần stake của chính họ sẽ bắt đầu lệch khỏi điều thực sự đúng trên on-chain, dù không có gì trên bất kỳ chuỗi nào thay đổi.
Vẫn hơi khiến tôi băn khoăn: chuyện này dễ bị bỏ sót đến vậy sao.
Các chuỗi vẫn chính xác trong suốt thời gian đó. Chính lớp trung gian dịch (translation layer), nằm ở giữa, mới có thể âm thầm trôi lệch.
Tôi không biết hiện tại có bao nhiêu instance của indexer chạy song song, hoặc thành phần này thực sự có tập trung đến mức nào ngày nay. Đây không phải thứ mà các tài liệu kiến trúc tổng quát đi sâu phân tích, và tôi sẽ không giả vờ rằng mình có một con số khi không có.
Lần đầu tiên một người staking thấy trạng thái sai vì indexer bị trễ, không phải vì stake của họ thực sự thay đổi—liệu điều đó có làm thay đổi cách mọi người nghĩ về ý nghĩa của “on-chain” theo từng ngày không?
Bạn nên tin dữ liệu nhiều hơn ở đâu?
@BabylonLabs_io &#baby $BABY
Hôm nay tôi đang đọc về backend staking của Babylon và gặp phải một điều mà tôi thực sự không hề dự đoán trước.
Có bao nhiêu thứ trông như là trạng thái on-chain thực sự đi qua hạ tầng off-chain trước, trước khi bạn từng thấy nó.
Trình lập chỉ mục staking (staking indexer), một dịch vụ cụ thể trong bộ backend của Babylon, đồng bộ các sự kiện ủy quyền (delegation events), trạng thái của nhà cung cấp cuối cùng (finality provider status) và các tham số staking toàn cầu từ cả Bitcoin và Babylon Genesis vào cơ sở dữ liệu riêng của nó. Cả giao diện frontend lẫn dịch vụ API staking đều đọc từ trình lập chỉ mục đó, chứ không đọc trực tiếp từ bất kỳ chuỗi nào, và tôi thú nhận rằng mình chưa hình dung ra điều này cho tới khi thấy nó được trình bày rõ ràng.
Lần đọc đầu tiên của tôi là, à, vậy thì đây chỉ là một lớp đệm (caching) để tăng tốc. Tiện thì có tiện, nhưng không phải thứ quyết định.
Không hẳn. Nếu trình lập chỉ mục bị tụt hậu trong việc đồng bộ, thì những gì người dùng thấy về phần stake của chính họ sẽ bắt đầu lệch khỏi điều thực sự đúng trên on-chain, dù không có gì trên bất kỳ chuỗi nào thay đổi.
Vẫn hơi khiến tôi băn khoăn: chuyện này dễ bị bỏ sót đến vậy sao.
Các chuỗi vẫn chính xác trong suốt thời gian đó. Chính lớp trung gian dịch (translation layer), nằm ở giữa, mới có thể âm thầm trôi lệch.
Tôi không biết hiện tại có bao nhiêu instance của indexer chạy song song, hoặc thành phần này thực sự có tập trung đến mức nào ngày nay. Đây không phải thứ mà các tài liệu kiến trúc tổng quát đi sâu phân tích, và tôi sẽ không giả vờ rằng mình có một con số khi không có.
Lần đầu tiên một người staking thấy trạng thái sai vì indexer bị trễ, không phải vì stake của họ thực sự thay đổi—liệu điều đó có làm thay đổi cách mọi người nghĩ về ý nghĩa của “on-chain” theo từng ngày không?
Bạn nên tin dữ liệu nhiều hơn ở đâu?
@BabylonLabs_io &#baby $BABY
Direct chain query
50%
Indexer/dashboard
25%
Both, equally
25%
Depends on timing
0%
4 phiếu bầu • Cuộc bỏ phiếu đã kết thúc