Hồi cuối tuần trước, tôi đã dành nhiều thời gian hơn dự kiến để đọc sâu về luồng thực thi (execution flow) của Newton. Tôi tưởng mình đang cố gắng hiểu việc lọc giao dịch. Ai đó trong quá trình ủy quyền (authorization path) đã khiến tôi nhận ra rằng mình đã bắt đầu đặt một câu hỏi khác.
Ban đầu, mọi thứ có vẻ đơn giản. Một ứng dụng kiểm tra vài điều kiện trước khi gửi một giao dịch lên chuỗi. Tôi cho rằng đó là nơi mà lớp bảo vệ tồn tại.
Càng đi sâu theo luồng thực thi, tôi càng ít bị thuyết phục. Điều quan trọng không phải là giao diện, mà là thời điểm một giao dịch ngừng chỉ là ý định và trở thành thứ mà mạng có thể chấp nhận.
Rồi mọi thứ bỗng thấy ngược lại.
Tôi nhận ra mình đã gán trách nhiệm cho lớp không đúng.
Một frontend có thể cảnh báo người dùng, kiểm tra tính hợp lệ của dữ liệu đầu vào, hoặc chặn các hành động, nhưng các cơ chế đó chỉ thuộc về một giao diện duy nhất. Giao dịch tồn tại độc lập với đường dẫn đó.
Đến lúc đó, <t-2/>@NewtonProtocol bắt đầu trông khác với tôi. Thứ tôi nghĩ là bảo vệ ở lớp giao diện hóa ra lại là ủy quyền được gắn trực tiếp vào chính giao dịch.
Những ví khác nhau, tác nhân (agents), script, API, hay cả các ứng dụng trong tương lai đều có thể tạo ra cùng một calldata. Việc bảo vệ một điểm vào (entry point) không nhất thiết bảo vệ được chính giao dịch đó.
Thay vào đó, bước ủy quyền diễn ra trước thời điểm quyết toán (settlement), nơi giao dịch được đánh giá dựa trên chính sách đang hoạt động, thay vì chỉ dựa vào các kiểm tra ở cấp giao diện.
Càng nghĩ về điều này, tôi càng thấy nó không giống một tính năng bảo mật khác.
Có lẽ đó chính là phần mà tôi đã hiểu sai ngay từ đầu.
Giao diện bắt đầu một giao dịch.
Kiến trúc quyết định liệu giao dịch đó có được ủy quyền trước khi thực thi hay không.
#Newt $NEWT $LAB $BEAT
Ban đầu, mọi thứ có vẻ đơn giản. Một ứng dụng kiểm tra vài điều kiện trước khi gửi một giao dịch lên chuỗi. Tôi cho rằng đó là nơi mà lớp bảo vệ tồn tại.
Càng đi sâu theo luồng thực thi, tôi càng ít bị thuyết phục. Điều quan trọng không phải là giao diện, mà là thời điểm một giao dịch ngừng chỉ là ý định và trở thành thứ mà mạng có thể chấp nhận.
Rồi mọi thứ bỗng thấy ngược lại.
Tôi nhận ra mình đã gán trách nhiệm cho lớp không đúng.
Một frontend có thể cảnh báo người dùng, kiểm tra tính hợp lệ của dữ liệu đầu vào, hoặc chặn các hành động, nhưng các cơ chế đó chỉ thuộc về một giao diện duy nhất. Giao dịch tồn tại độc lập với đường dẫn đó.
Đến lúc đó, <t-2/>@NewtonProtocol bắt đầu trông khác với tôi. Thứ tôi nghĩ là bảo vệ ở lớp giao diện hóa ra lại là ủy quyền được gắn trực tiếp vào chính giao dịch.
Những ví khác nhau, tác nhân (agents), script, API, hay cả các ứng dụng trong tương lai đều có thể tạo ra cùng một calldata. Việc bảo vệ một điểm vào (entry point) không nhất thiết bảo vệ được chính giao dịch đó.
Thay vào đó, bước ủy quyền diễn ra trước thời điểm quyết toán (settlement), nơi giao dịch được đánh giá dựa trên chính sách đang hoạt động, thay vì chỉ dựa vào các kiểm tra ở cấp giao diện.
Càng nghĩ về điều này, tôi càng thấy nó không giống một tính năng bảo mật khác.
Có lẽ đó chính là phần mà tôi đã hiểu sai ngay từ đầu.
Giao diện bắt đầu một giao dịch.
Kiến trúc quyết định liệu giao dịch đó có được ủy quyền trước khi thực thi hay không.
#Newt $NEWT $LAB $BEAT