Fireblocks vừa tung ra tính năng mới mang tên “Wallet Pools”, cho phép gộp nhiều tài khoản két (vault) lại thành một nguồn giao dịch duy nhất để né tránh tình trạng giao dịch bị treo. Khi một két gặp sự cố, hệ thống sẽ tự động chuyển giao dịch mới sang két khác đang hoạt động bình thường.
Theo Crypto Briefing đưa tin ngày 5, Fireblocks đã gom nhiều két thành một pool chung và áp dụng thuật toán “round-robin theo trạng thái” để đi vòng qua các điểm nghẽn. Tính năng này nhắm đến các chuỗi dùng mô hình tài khoản như Ethereum (ETH), nơi một giao dịch bị kẹt có thể khiến toàn bộ giao dịch phía sau phải xếp hàng chờ vì thứ tự nonce.
Nonce là con số xác định thứ tự giao dịch trên các blockchain theo mô hình tài khoản. Nếu giao dịch gửi trước đó bị kẹt lại trong mempool do phí thấp hoặc phí mạng tăng đột biến, các giao dịch gửi sau từ cùng một tài khoản cũng buộc phải chờ đến lượt xử lý.
Hiện tượng nghẽn dây chuyền như vậy có thể gây áp lực lên khâu chăm sóc khách hàng và vận hành nội bộ của các sàn giao dịch, công ty thanh toán và doanh nghiệp fintech vốn thường xuyên xử lý rút tiền và thanh toán bù trừ. Giao dịch càng dồn về một tài khoản két, nguy cơ nghẽn do vấn đề nonce hoặc phí giao dịch càng lớn.
Tài liệu dành cho nhà phát triển của Fireblocks giải thích rằng phí thấp hoặc phí mạng tăng đột ngột có thể khiến giao dịch bị giữ lại trong mempool. Ở một số mạng, điều này kéo theo cả các giao dịch tiếp theo của cùng một tài khoản két bị chậm trễ.
Cách xử lý trước đây chủ yếu là điều chỉnh phí của chính giao dịch bị kẹt để tăng khả năng được xử lý. Trên các mạng tương thích EVM, giải pháp thường dùng là RBF (Replace By Fee), còn với Bitcoin (BTC) là CPFP (Child Pays For Parent).
Wallet Pools chọn hướng đi khác: thay vì tăng phí cho giao dịch đang bị trễ, tính năng này phân tán nguồn giao dịch ra nhiều két khác nhau. Nhờ vậy, khi một két gặp nghẽn, giao dịch mới vẫn có thể đi theo một đường khác đang thông suốt.
Ghi chú phát hành của bộ SDK Python từ Fireblocks cho thấy loại giá trị “WALLET_POOL” đã được bổ sung vào danh mục nguồn giao dịch kể từ phiên bản v21.0.0, phát hành ngày 11 tháng 6. Thay đổi này giúp khách hàng sử dụng Wallet Pools làm nguồn giao dịch và lọc các giao dịch liên quan.
Ngày 27 tháng 7, Fireblocks cũng công bố một bản cập nhật sản phẩm khác, hỗ trợ hoạt động lưu ký trực tiếp với tần suất cao. Bản cập nhật này bao gồm △phê duyệt theo lô (batch approval) △giao dịch đa đích trên Solana (SOL) △UTXO Manager △các trạng thái phụ khi phát sóng giao dịch (Broadcasting sub-statuses) △Account Traffic Control.
Account Traffic Control là tính năng phát hiện giao dịch bị treo trong mempool và hỗ trợ xử lý sự cố theo thời gian thực. Theo tài liệu dành cho nhà phát triển, webhook bản beta có tên “transaction.alert.stuck_confirming” sẽ được kích hoạt khi một giao dịch trên blockchain EVM bị kẹt ở trạng thái “CONFIRMING” và có nguy cơ chặn các giao dịch tiếp theo.
Ví dụ về webhook này bao gồm các trường thông tin như phát hiện giao dịch phí thấp, số lượng giao dịch bị kẹt, nonce hoàn tất gần nhất và thời gian bị đình trệ. Nếu Wallet Pools đóng vai trò phân tán đường đi cho giao dịch mới, thì Account Traffic Control thiên về phát hiện và xử lý những độ trễ đã xảy ra.
Fireblocks cho biết khách hàng của công ty xử lý thanh toán trên hàng chục blockchain và phát hành ví nhúng (embedded wallet) cho hàng triệu người dùng cuối. Theo phần giới thiệu công ty, hàng nghìn tổ chức đang sử dụng Fireblocks, trong đó có Worldpay, BNY Mellon, Galaxy và Revolut.
Đợt ra mắt lần này liên quan đến mức độ ổn định vận hành của hạ tầng lưu ký và thanh toán, chứ không phải giá hay cung cầu của token nào. Fireblocks chưa công bố cụ thể tính năng Wallet Pools được áp dụng trên những chuỗi nào, điều kiện kích hoạt cho từng khách hàng, tỷ lệ giảm sự cố hay mức cải thiện thông lượng xử lý.
Bình luận 0