Ở trên chuỗi đủ lâu, tôi nhận ra một chi tiết rất dễ đánh lừa người khác: thời gian xác nhận giao dịch càng nhanh, người ta càng dễ coi “đã được đưa vào block” là “tiền đã thực sự nhận được”. Tôi gọi hiện tượng này là “nghịch lý cuối cùng”.
Quy trình giao dịch của DuskEVM giải thích khá rõ điều đó: giao dịch trước tiên được gửi cho sequencer, sau đó được đưa vào block ở L2; tiếp theo, batcher công bố dữ liệu lên DuskDS, và nhờ cơ chế cam kết trạng thái cùng các fault proofs mà kết quả được neo lại trở về lớp thanh toán (settlement layer). Nói cách khác, việc xuất hiện trong block chỉ mới là bước đầu; thứ thực sự khiến mạng chịu trách nhiệm cho kết quả của giao dịch là vài bước phía sau đó. Trình tự @Dusk này giống như dịch vụ chuyển phát: tạo mã vận đơn không đồng nghĩa với việc đã ký nhận, hàng được đưa vào kho cũng không đồng nghĩa với việc bạn đã mở kiện kiểm tra. Tài liệu thậm chí còn nhắc thẳng rằng đừng dùng “đã trôi qua bao lâu” để suy ra tính cuối cùng, nhất là khi bạn chuyển giá trị giữa DuskEVM và L1.
$DUSK ở đây đồng thời đóng hai vai trò: vừa là “nhiên liệu” để lớp thực thi trả gas, vừa là chính “giá trị” được đem đi rồi lại được mang về. Người dùng nhìn thấy số dư DUSK trên chuỗi thay đổi có thể chỉ là lớp thực thi đã ghi tạm một bút toán trước; việc chuyển cầu (bridging) và thanh toán thực sự vẫn chưa hoàn tất. Vì vậy, với người thực hiện giao dịch hoặc gom/thu tiền, thứ cần xem là trạng thái theo giao thức hoặc trạng thái trong ví, chứ không phải chăm chăm nhìn đồng hồ bấm giờ.
Tôi nghĩ đây mới là phần khó thật sự của hạ tầng riêng tư và tuân thủ loại này: #dusk không thể chỉ mang lại “nhanh”, mà còn phải giúp người dùng phân biệt được “đang xảy ra” và “đã được xác định”. Nếu lớp sản phẩm cũng làm mờ ranh giới đó, người dùng sẽ phải gánh rủi ro ở cấp độ phút ngay trong giao diện ở cấp độ mili giây. Bài học phải tự làm, đừng chỉ nghe tôi nói một câu.
Quy trình giao dịch của DuskEVM giải thích khá rõ điều đó: giao dịch trước tiên được gửi cho sequencer, sau đó được đưa vào block ở L2; tiếp theo, batcher công bố dữ liệu lên DuskDS, và nhờ cơ chế cam kết trạng thái cùng các fault proofs mà kết quả được neo lại trở về lớp thanh toán (settlement layer). Nói cách khác, việc xuất hiện trong block chỉ mới là bước đầu; thứ thực sự khiến mạng chịu trách nhiệm cho kết quả của giao dịch là vài bước phía sau đó. Trình tự @Dusk này giống như dịch vụ chuyển phát: tạo mã vận đơn không đồng nghĩa với việc đã ký nhận, hàng được đưa vào kho cũng không đồng nghĩa với việc bạn đã mở kiện kiểm tra. Tài liệu thậm chí còn nhắc thẳng rằng đừng dùng “đã trôi qua bao lâu” để suy ra tính cuối cùng, nhất là khi bạn chuyển giá trị giữa DuskEVM và L1.
$DUSK ở đây đồng thời đóng hai vai trò: vừa là “nhiên liệu” để lớp thực thi trả gas, vừa là chính “giá trị” được đem đi rồi lại được mang về. Người dùng nhìn thấy số dư DUSK trên chuỗi thay đổi có thể chỉ là lớp thực thi đã ghi tạm một bút toán trước; việc chuyển cầu (bridging) và thanh toán thực sự vẫn chưa hoàn tất. Vì vậy, với người thực hiện giao dịch hoặc gom/thu tiền, thứ cần xem là trạng thái theo giao thức hoặc trạng thái trong ví, chứ không phải chăm chăm nhìn đồng hồ bấm giờ.
Tôi nghĩ đây mới là phần khó thật sự của hạ tầng riêng tư và tuân thủ loại này: #dusk không thể chỉ mang lại “nhanh”, mà còn phải giúp người dùng phân biệt được “đang xảy ra” và “đã được xác định”. Nếu lớp sản phẩm cũng làm mờ ranh giới đó, người dùng sẽ phải gánh rủi ro ở cấp độ phút ngay trong giao diện ở cấp độ mili giây. Bài học phải tự làm, đừng chỉ nghe tôi nói một câu.
