“Từ ‘Removed’ đặt trong hệ thống giám sát giao dịch rất dễ bị đọc thành ‘thất bại’, nhưng khi tôi xem sự kiện RUES của @Dusk thì tôi sẽ tạm dừng lại, vì việc một giao dịch rời khỏi mempool cục bộ không đồng nghĩa với việc nó bị chuỗi (blockchain) từ chối. Đây không phải trò chơi chữ. Theo phần mô tả chính thức của Dusk, transactions/removed chỉ cho biết giao dịch rời khỏi mempool cục bộ của một nút nào đó; nguyên nhân có thể là được đưa vào khối, bị thay thế bởi một giao dịch xung đột có gasPrice cao hơn, hết hạn, bị loại do dung lượng, hoặc đơn giản là giao dịch xung đột rời khỏi đó—chỉ dựa vào sự kiện đơn lẻ này thì hệ thống chưa hề nói cho bạn biết kết quả cuối cùng.

Điều này khiến tôi nhìn lại trải nghiệm của nhà phát triển với $DUSK . Khi bộ giám sát ánh xạ ‘removed’ thành thất bại, hệ thống sẽ nhắc người dùng quá sớm ở hậu trường; còn nếu coi nó là thành công thì lại có thể bỏ sót những giao dịch thực sự đã bị loại. Một trường trạng thái thực chất tách “điều gì đang xảy ra trước mắt tại nút” và “điều gì cuối cùng được sổ cái ghi nhớ” thành hai lớp khác nhau. Tình huống áp lực thực ra rất phổ biến: người dùng chuyển tiền xong, ví nhận được removed và hiển thị “Vui lòng thử lại”. Người dùng gửi thêm một giao dịch nữa rồi mới phát hiện giao dịch đầu tiên đã được đưa vào khối; kết quả là phải trả thêm một khoản gas, và bộ phận chăm sóc khách hàng còn phải giải thích giao dịch nào mới có hiệu lực. Nếu thông báo lỗi không dựa vào sổ cái mà chỉ dựa vào sự kiện, thì quan điểm cục bộ sẽ bị phóng đại thành sự thật.

Vì vậy, tôi sẽ không xem removed của RUES như một tín hiệu thất bại. Tài liệu của @Dusk đưa ra hướng đi vững vàng hơn: kiểm tra lại giao dịch và trạng thái của khối rồi mới quyết định có nên thử lại hay không. Tiếp theo, tôi sẽ xem liệu ví có hiển thị rõ ràng cho người dùng việc “đã rời khỏi cục bộ” và “kết quả cuối cùng” một cách tách bạch hay không—đó mới là chi tiết Dusk giúp người dùng tránh bẫy. #dusk