Không Nên Tạo Danh Tính Mới Khi Hết Thời Gian Rút Tiền
Yêu cầu rút tiền bị quá thời gian. Phản hồi “cám dỗ” là đơn giản: xây lại giao dịch và gửi lại.
Trên Dusk, điều đó có thể làm vấn đề vận hành trở nên khó xử hơn.
Với các lần rút tiền Moonlight, hướng dẫn tích hợp nêu rằng giao dịch phải được xây dựng và ký một lần duy nhất, lưu trữ các byte đã tuần tự hóa và mã ID giao dịch trước khi phát tán. Nếu lần gửi gặp lỗi timeout ở lớp vận chuyển, cách thử lại an toàn là phát tán lại chính xác những byte đã ký đó. Giao dịch giữ nguyên cùng danh tính trong khi trạng thái trên chuỗi được điều tra.
Tại sao điều này quan trọng? Bởi vì một lần timeout không chứng minh rằng lần thử đầu tiên đã thất bại. Ngay cả việc nhận 202 Accepted chỉ xác nhận việc định tuyến, chứ không xác nhận việc được đưa vào chuỗi hay tính xác thực cuối cùng. Việc tạo một giao dịch khác trước khi làm rõ sự không chắc chắn đó sẽ tạo thêm một đối tượng mà hệ thống rút tiền cần theo dõi.
Moonlight nêu rõ sự khác biệt. Các giao dịch sử dụng nonce tài khoản theo thứ tự tuần tự, và một giao dịch cùng nonce gây xung đột chỉ thay thế mục nhập mempool hiện có khi giá gas của nó cao hơn một cách chặt chẽ. Việc thay thế này sẽ tạo ra một ID giao dịch khác. Vì vậy, Dusk hướng dẫn các nhà vận hành sàn phải đối soát cả hai ID và tránh ghi nợ hai lần.
Do đó, “thử lại” và “thay thế” không phải là các hành động backend có thể hoán đổi cho nhau. Thử lại sẽ giữ nguyên danh tính của lần thanh toán. Thay thế thì cố ý tạo danh tính mới cho cùng nonce.
Với hạ tầng lưu ký (custody), tính idempotency vì thế vượt xa thiết kế cơ sở dữ liệu: việc xây dựng giao dịch, cấp phát nonce, các byte đã ký và các bản ghi kế toán đều phải mô tả cùng một lần rút tiền.
@Dusk $DUSK #dusk
Yêu cầu rút tiền bị quá thời gian. Phản hồi “cám dỗ” là đơn giản: xây lại giao dịch và gửi lại.
Trên Dusk, điều đó có thể làm vấn đề vận hành trở nên khó xử hơn.
Với các lần rút tiền Moonlight, hướng dẫn tích hợp nêu rằng giao dịch phải được xây dựng và ký một lần duy nhất, lưu trữ các byte đã tuần tự hóa và mã ID giao dịch trước khi phát tán. Nếu lần gửi gặp lỗi timeout ở lớp vận chuyển, cách thử lại an toàn là phát tán lại chính xác những byte đã ký đó. Giao dịch giữ nguyên cùng danh tính trong khi trạng thái trên chuỗi được điều tra.
Tại sao điều này quan trọng? Bởi vì một lần timeout không chứng minh rằng lần thử đầu tiên đã thất bại. Ngay cả việc nhận 202 Accepted chỉ xác nhận việc định tuyến, chứ không xác nhận việc được đưa vào chuỗi hay tính xác thực cuối cùng. Việc tạo một giao dịch khác trước khi làm rõ sự không chắc chắn đó sẽ tạo thêm một đối tượng mà hệ thống rút tiền cần theo dõi.
Moonlight nêu rõ sự khác biệt. Các giao dịch sử dụng nonce tài khoản theo thứ tự tuần tự, và một giao dịch cùng nonce gây xung đột chỉ thay thế mục nhập mempool hiện có khi giá gas của nó cao hơn một cách chặt chẽ. Việc thay thế này sẽ tạo ra một ID giao dịch khác. Vì vậy, Dusk hướng dẫn các nhà vận hành sàn phải đối soát cả hai ID và tránh ghi nợ hai lần.
Do đó, “thử lại” và “thay thế” không phải là các hành động backend có thể hoán đổi cho nhau. Thử lại sẽ giữ nguyên danh tính của lần thanh toán. Thay thế thì cố ý tạo danh tính mới cho cùng nonce.
Với hạ tầng lưu ký (custody), tính idempotency vì thế vượt xa thiết kế cơ sở dữ liệu: việc xây dựng giao dịch, cấp phát nonce, các byte đã ký và các bản ghi kế toán đều phải mô tả cùng một lần rút tiền.
@Dusk $DUSK #dusk
