EIP-7906 kiểm tra kết quả giao dịch Ethereum, tiêu chí lỏng có thể bỏ lọt rủi ro

Một đề xuất mới của Ethereum (ETH) sẽ kiểm tra kết quả giao dịch sau khi thực thi. Tuy nhiên, nếu tiêu chí kiểm tra quá lỏng, giao dịch vẫn có thể cho ra kết quả không mong muốn mà không bị phát hiện. Để EIP-7906 trở thành biện pháp bảo vệ thực chất, ví và giao thức cần thực thi các tiêu chí, đồng thời ngăn bên tạo giao dịch hạ thấp chúng.

Ngày 5 tháng 10, Ethereum Foundation công bố nghiên cứu về “khẳng định giao dịch” (transaction assertion), một cơ chế kiểm tra thay đổi số dư, dữ liệu lưu trữ và sự kiện sau khi giao dịch được thực thi. Bản triển khai đề xuất EIP-7906 đưa ra khung POST_TX chỉ đọc, hoạt động sau giao dịch. Đề xuất hiện vẫn là bản nháp và chưa có quyết định về việc đưa vào bản nâng cấp Hegotá.

Chữ ký giao dịch ghi nhận yêu cầu mà người dùng đã chấp thuận, nhưng không cố định kết quả thực thi. Nếu mã nguồn hoặc trạng thái blockchain thay đổi trước khi giao dịch chạy, kết quả thực tế có thể khác dự kiến. Ethereum Foundation nêu cuộc tấn công sandwich, trong đó giá hoán đổi biến động theo thứ tự giao dịch, làm ví dụ về sự chênh lệch kết quả.

EIP-7906 được thiết kế để dùng TXTRACE liệt kê các thay đổi ròng và sự kiện của giao dịch, còn TXDIFF kiểm tra giá trị ban đầu và cuối cùng tại các địa chỉ cùng vùng lưu trữ cụ thể. Dữ liệu sự kiện được đọc bằng EVENTDATACOPY. Ngay cả khi vùng lưu trữ thay đổi nhiều lần, cơ chế chỉ giữ lại giá trị đầu tiên và cuối cùng, chứ không ghi nhận toàn bộ các thay đổi trung gian.

Có chức năng kiểm tra không đồng nghĩa mọi giao dịch đều tự động được bảo vệ. Đề xuất không bắt buộc phải thêm khẳng định vào từng giao dịch; ví cần đưa các bước kiểm tra cần thiết vào giao dịch. Để bảo vệ ở cấp giao thức, cần yêu cầu kiểm tra POST_TX đã định sẵn đối với tính năng cần bảo vệ, đồng thời từ chối giao dịch nếu thiếu bước kiểm tra hoặc sử dụng một bước kiểm tra khác.

Ethereum Foundation cho biết trong phần giải thích nghiên cứu rằng giao diện tạo giao dịch bị xâm nhập có thể đưa vào các quy tắc đủ lỏng để cho phép tấn công. Thiết lập mức nhận tối thiểu trong các giao dịch hoán đổi hiện nay cũng cho thấy hạn chế tương tự. Tài liệu dành cho nhà phát triển của Uniswap cảnh báo ví dụ đặt mức nhận tối thiểu bằng 0 sẽ gây rủi ro khi dùng trên dịch vụ thực tế. Tài liệu cũng cho biết có thể dùng nguồn dữ liệu riêng như SDK hoặc oracle giá để xác định mức an toàn hơn. Dù có điều kiện bảo vệ, kết quả chỉ cần vừa đủ vượt qua một ngưỡng quá thấp vẫn có thể được chấp nhận.

Nếu kiểm tra thất bại, phí giao dịch đã sử dụng không được hoàn lại. Theo bản nháp EIP-7906, khi kiểm tra POST_TX thất bại, phần thực thi bị hoàn tác nhưng giao dịch vẫn được ghi vào khối với trạng thái thất bại và người dùng vẫn phải trả phí gas đã tiêu thụ. Những thay đổi đã được xác nhận ở bước xác thực cũng được giữ nguyên.

Ethereum Foundation giải thích rằng các thao tác cần được bảo vệ nên nằm trong phần thực thi có thể hoàn tác, còn bước xác thực không nên chứa hoạt động thực thi không đáng tin cậy. Nếu không đủ gas để chạy kiểm tra, khẳng định cũng bị xử lý là thất bại. Vì vậy, muốn bảo vệ kết quả giao dịch cần xem xét cả logic kiểm tra lẫn phạm vi thao tác có thể hoàn tác khi xảy ra lỗi.

Trạng thái của oracle giá hoặc registry mà bước kiểm tra tham chiếu cũng có thể thay đổi trong lúc giao dịch được thực thi. Tài liệu đề xuất các phương án như cố định giá trị tại thời điểm ký hoặc tham chiếu trạng thái lúc giao dịch bắt đầu. Tuy nhiên, rủi ro giá biến động trong cùng một khối trước khi giao dịch bắt đầu vẫn còn.

EIP-7906 dựa trên EIP-8141, đề xuất định nghĩa giao dịch dạng khung. Theo trạng thái được Ethereum Foundation công bố, EIP-8141 được xếp vào nhóm dự kiến đưa vào Hegotá, trong khi EIP-7906 vẫn đang được xem xét. Phạm vi áp dụng thực tế ở ví và giao thức cũng chưa được xác định.

Trước đó, Ethereum Foundation đã khảo sát phương án kiểm tra thay đổi trạng thái sau khi giao dịch được thực thi. Các chi tiết trong bản nháp lần này cho thấy chức năng xác nhận kết quả giao dịch chưa đủ để hoàn thiện cơ chế bảo vệ. Vấn đề then chốt là ai đặt ra tiêu chí mà người dùng chấp thuận và làm thế nào để bên tạo giao dịch không thể làm suy yếu tiêu chí đó.