Thông thường khi xem cầu liên chuỗi, mắt ta cứ luôn dõi vào xem tiền đã đến chưa. Nhưng thực ra trên một cây cầu, thứ “chạy” thực sự có hai loại: tiền và lời. Tiền có số dư, có xác nhận—thiếu một đồng cũng tra ra được. Còn “lời” được truyền qua liên chuỗi đó có được gửi tới chính xác hay không, liệu có bị ai đó chặn lại rồi phát lại (replay) một lần nữa không—những người quan tâm lại không nhiều.
Trong sơ đồ kiến trúc của @Dusk , điều đó được viết rất thẳng thắn: Bridge vừa chuyển hai thứ—DUSK và tin nhắn. Thứ nhất nằm trên chuỗi thì có gas, có số dư, có xác nhận—giống như một làn đường được dán giá rõ ràng. Còn thứ hai thì giống như một con đường nhỏ trên cây cầu, không ai tự thu phí riêng; hễ có trục trặc là chẳng biết phải tìm ai.
Vai trò của DUSK trong hệ thống này thì không cần nói nhiều: lớp thực thi thì “đốt” nó, còn giữa L1 và DuskEVM cũng phải dùng nó qua lại. Mỗi khi giao dịch, thanh toán, gọi hợp đồng… đều phải tốn $DUSK , nên giá trị của nó có thể quy đổi tương ứng sang thông lượng (throughput). Nhưng tin nhắn thì không phải token. Nó có thể là lệnh gọi liên chuỗi, ủy quyền (authorization), thay đổi trạng thái, hoặc một kiểu chỉ thị bắt buộc phải thực thi theo đúng thứ tự.
Tài liệu chỉ thừa nhận cách Dusk hợp đồng nhận diện người gọi khác với Ethereum, và việc “bắc cầu” cùng cách “thu nhặt giá trị” cần Dusk đặc thù. Nhưng gần như không khai triển các điểm đảm bảo việc gửi tin, chống phát lại, quy tắc sắp xếp, lối đi khi thất bại. Nghĩ thử xem: trong tài chính được quản lý, đây lại chính là “điểm mù” nguy hiểm nhất—chuyển nhầm một khoản tiền thì còn có thể hoàn lại; nhưng nếu một chỉ thị bị lặng lẽ thực thi hai lần, thì trách nhiệm không thể nào “quay lại” được.
Chẳng phải đây mới là phần đáng để soi kỹ hơn cả tài sản sao? Nói thẳng ra: DUSK trả phí cho làn đường “tiền”, nhưng lại không thể tự động bảo đảm cho làn đường “lời”. Người nắm giữ token mua “tính toán mạng” chứ không phải trách nhiệm thanh toán/giải quyết của tin nhắn bắc cầu. Nếu có trục trặc, thì lỗi của cây cầu có thể phải để ứng dụng, người dùng hoặc một ai đó xui xẻo đứng ra gánh. Gas của DUSK sẽ không tự biến thành cam kết bồi thường.#dusk
Nhìn tổng thể, “cú lôi” trong hệ thống liên chuỗi mà tôi thấy thường không nằm ở phần chân tài sản, mà nằm ở phần chân tin nhắn. Tài sản có giá; tin nhắn chỉ có thứ tự và quyền hạn. Cái trước ít nhiều còn có thể bị theo dõi; còn cái sau một khi bị đảo thứ tự, thì đó là một vụ vi phạm mà ngay cả bên đối tác cũng không tìm ra đường truy cứu được. DYOR—công việc học tập, tự làm đi, đừng chỉ nghe một câu của tôi.
Trong sơ đồ kiến trúc của @Dusk , điều đó được viết rất thẳng thắn: Bridge vừa chuyển hai thứ—DUSK và tin nhắn. Thứ nhất nằm trên chuỗi thì có gas, có số dư, có xác nhận—giống như một làn đường được dán giá rõ ràng. Còn thứ hai thì giống như một con đường nhỏ trên cây cầu, không ai tự thu phí riêng; hễ có trục trặc là chẳng biết phải tìm ai.
Vai trò của DUSK trong hệ thống này thì không cần nói nhiều: lớp thực thi thì “đốt” nó, còn giữa L1 và DuskEVM cũng phải dùng nó qua lại. Mỗi khi giao dịch, thanh toán, gọi hợp đồng… đều phải tốn $DUSK , nên giá trị của nó có thể quy đổi tương ứng sang thông lượng (throughput). Nhưng tin nhắn thì không phải token. Nó có thể là lệnh gọi liên chuỗi, ủy quyền (authorization), thay đổi trạng thái, hoặc một kiểu chỉ thị bắt buộc phải thực thi theo đúng thứ tự.
Tài liệu chỉ thừa nhận cách Dusk hợp đồng nhận diện người gọi khác với Ethereum, và việc “bắc cầu” cùng cách “thu nhặt giá trị” cần Dusk đặc thù. Nhưng gần như không khai triển các điểm đảm bảo việc gửi tin, chống phát lại, quy tắc sắp xếp, lối đi khi thất bại. Nghĩ thử xem: trong tài chính được quản lý, đây lại chính là “điểm mù” nguy hiểm nhất—chuyển nhầm một khoản tiền thì còn có thể hoàn lại; nhưng nếu một chỉ thị bị lặng lẽ thực thi hai lần, thì trách nhiệm không thể nào “quay lại” được.
Chẳng phải đây mới là phần đáng để soi kỹ hơn cả tài sản sao? Nói thẳng ra: DUSK trả phí cho làn đường “tiền”, nhưng lại không thể tự động bảo đảm cho làn đường “lời”. Người nắm giữ token mua “tính toán mạng” chứ không phải trách nhiệm thanh toán/giải quyết của tin nhắn bắc cầu. Nếu có trục trặc, thì lỗi của cây cầu có thể phải để ứng dụng, người dùng hoặc một ai đó xui xẻo đứng ra gánh. Gas của DUSK sẽ không tự biến thành cam kết bồi thường.#dusk
Nhìn tổng thể, “cú lôi” trong hệ thống liên chuỗi mà tôi thấy thường không nằm ở phần chân tài sản, mà nằm ở phần chân tin nhắn. Tài sản có giá; tin nhắn chỉ có thứ tự và quyền hạn. Cái trước ít nhiều còn có thể bị theo dõi; còn cái sau một khi bị đảo thứ tự, thì đó là một vụ vi phạm mà ngay cả bên đối tác cũng không tìm ra đường truy cứu được. DYOR—công việc học tập, tự làm đi, đừng chỉ nghe một câu của tôi.
