Khi tôi đọc tài liệu vòng đời giao dịch của Dusk @Dusk Dusk, tôi mới chỉ ra một chẩn đoán sai: phản hồi của API là 202 Accepted, chỉ cho thấy node đã nhận yêu cầu. Sau khi gửi chữ ký Dusk L1, node trước tiên làm admission; nếu qua thì mới vào real mempool và phát broadcast tới peers, còn trình tạo khối sẽ thực thi theo thứ tự gasPrice.
Tôi xem chuỗi sự kiện này như một dây chuyền thanh toán. 202 là bưu kiện ở quầy tiếp nhận phía trước, included là vào khu chờ, executed còn phải kiểm tra err có phải null hay không. Dù khối đã được accepted, vẫn có thể bị reverted, cho đến khi blocks/statechange báo finalized thì sổ cái mới được đóng băng. Moonlight dựa vào xung đột theo tài khoản và nonce, Phoenix dựa vào nullifier; giao dịch thay thế cần tăng gasPrice.
Chuỗi sự kiện này chỉ áp dụng cho Dusk L1, còn DuskEVM có model sequencer và finality riêng. Tôi viết một listener sẽ lưu tx hash và tọa độ khối, rồi dùng onlyFinalized:true để kiểm chứng. Chỉ theo dõi included thì khi gặp node thay thế, hết hạn hoặc bị loại do quá tải, rất dễ nhầm trạng thái cục bộ là đã có tiền về. Biên nhận chỉ là bản ghi nhận ở quầy, còn xác nhận tiền cần chờ trạng thái cuối cùng.
#dusk $DUSK
Tôi xem chuỗi sự kiện này như một dây chuyền thanh toán. 202 là bưu kiện ở quầy tiếp nhận phía trước, included là vào khu chờ, executed còn phải kiểm tra err có phải null hay không. Dù khối đã được accepted, vẫn có thể bị reverted, cho đến khi blocks/statechange báo finalized thì sổ cái mới được đóng băng. Moonlight dựa vào xung đột theo tài khoản và nonce, Phoenix dựa vào nullifier; giao dịch thay thế cần tăng gasPrice.
Chuỗi sự kiện này chỉ áp dụng cho Dusk L1, còn DuskEVM có model sequencer và finality riêng. Tôi viết một listener sẽ lưu tx hash và tọa độ khối, rồi dùng onlyFinalized:true để kiểm chứng. Chỉ theo dõi included thì khi gặp node thay thế, hết hạn hoặc bị loại do quá tải, rất dễ nhầm trạng thái cục bộ là đã có tiền về. Biên nhận chỉ là bản ghi nhận ở quầy, còn xác nhận tiền cần chờ trạng thái cuối cùng.
#dusk $DUSK