#dusk $DUSK @Dusk Tôi trước đây khi làm thanh toán trên chuỗi thường có thói quen nhét mã đơn hàng vào memo cho tiện, nhưng sau khi đọc tài liệu Transaction Lifecycle của @Dusk thì tôi mới phát hiện rằng thói quen này không thể bê nguyên sang được. Vì dữ liệu giao dịch của Dusk có quan hệ chọn một trong các mục: memo, lời gọi hợp đồng, triển khai hợp đồng và blob—memo không thể mặc định đi kèm cùng các payload khác. Sự khác biệt này sẽ trực tiếp làm thay đổi cách đấu nối hệ thống thanh toán. Nếu một thương gia vừa cần nhận tiền vừa cần gọi hợp đồng để hoàn tất tác vụ, thì không thể cứ cho rằng có thể tiếp tục nhét mã đơn hàng vào memo của cùng một giao dịch như trước. Ứng dụng khách cần quyết định trước nhiệm vụ chính của giao dịch đó, rồi thiết kế một bản ghi đáng tin cậy khác để liên kết đơn hàng. Tình huống chịu tải thực ra rất cụ thể: khi người dùng gửi một khoản thanh toán kèm hành động hợp đồng, giao diện phía trước hiển thị “đã gửi”, nhưng phía backend lại đối chiếu đơn hàng theo memo. Kết quả là số tiền đã vào, nhưng mã đơn hàng không xuất hiện như mong đợi, vì vậy bộ phận chăm sóc khách hàng chỉ có thể tra cứu thủ công giao dịch. Điều này không nhất thiết là Dusk bị mất dữ liệu; nhiều khả năng bên tích hợp đã áp đặt thói quen giao dịch của một chain khác vào. Vì vậy, khi tôi xem phần tích hợp thanh toán của DUSK, tôi sẽ không chỉ hỏi chuyển khoản có thành công hay không, mà sẽ xác nhận giao dịch rốt cuộc đang được “chở” bằng memo hay bằng lời gọi hợp đồng, rồi kiểm tra xem việc liên kết đơn hàng có thể được đối chiếu độc lập hay không. @Dusk đã vạch rõ ranh giới payload, nhưng liệu các ví dụ có giúp nhà phát triển tránh sớm kiểu dùng sai này hay không mới là điều đáng được xác thực hơn khi Dusk đi vào bối cảnh thanh toán thực tế.