Toàn bộ @Dusk ngăn xếp thực ra có hai sổ sách liên quan nhưng khác nhau: một sổ là sổ thực thi của DuskEVM, đối ngoại kể bằng Ethereum JSON-RPC; sổ còn lại là sổ quyết toán của Dusk L1, đối ngoại kể bằng GraphQL / RUES. DUSK phải được đọc thành cùng một con số trong cả hai sổ, nhưng đồng hồ, đơn vị và số chữ số thập phân của chúng lại không giống nhau.
DuskEVM là lớp thực thi EVM theo phong cách OP Stack, trả về các khối, log và biên lai ở hình dạng chuẩn EVM; sau đó phần quyết toán cuối cùng và khả năng sẵn có dữ liệu được đưa qua batcher, cam kết trạng thái và neo qua liên kết tới DuskDS. Nói cách khác, đây không phải là một bộ “dịch GraphQL thời gian thực sang JSON-RPC”, mà là hai lớp duy trì tính nhất quán cuối cùng nhờ cầu nối và cam kết trạng thái. Điều thật sự cần chú ý là các tình huống xuyên lớp: inclusion trên DuskEVM diễn ra nhanh, nhưng quyết toán đầy đủ và xác nhận cầu nối còn phải đi thêm vài bước; trong khoảng thời gian đó, trạng thái mà hai bên nhìn thấy có thể tạm thời khác nhau.
Vai trò của $DUSK khiến rủi ro này trở nên cụ thể hơn. Phía L1 gốc dùng LUX để biểu diễn, 1 DUSK bằng 10 mũ 9 LUX; còn DuskEVM để tương thích với chuỗi công cụ Ethereum, lại bộc lộ DUSK theo dạng thập phân 18 chữ số. Khi cầu nối thực hiện quy đổi hoặc xử lý độ chính xác không đúng, cùng một giá trị có thể tạm thời không khớp giữa hai sổ sách trong thời gian ngắn. Với chuyển khoản thông thường có thể chỉ là sai số hiển thị, nhưng với quyết toán có điều tiết, có thể là “cửa sổ thao tác sai” kiểu một bên hiển thị đã nhận tiền, trong khi phía bên kia vẫn chưa được xác nhận cuối cùng.
Đánh giá sau khi tôi xem xong là: đánh giá #dusk , không thể chỉ nhìn vào việc “tương thích EVM”; còn phải xem cơ chế đảm bảo tính nhất quán giữa sổ quyết toán L1 và sổ thực thi EVM. Tài liệu hiện chưa giải thích đầy đủ thứ tự ưu tiên của nguồn dữ liệu mang tính thẩm quyền, cơ chế phát hiện xung đột và khắc phục, và DUSK chính là con số không được đọc nhầm nhất trong hai sổ này. DYOR.
DuskEVM là lớp thực thi EVM theo phong cách OP Stack, trả về các khối, log và biên lai ở hình dạng chuẩn EVM; sau đó phần quyết toán cuối cùng và khả năng sẵn có dữ liệu được đưa qua batcher, cam kết trạng thái và neo qua liên kết tới DuskDS. Nói cách khác, đây không phải là một bộ “dịch GraphQL thời gian thực sang JSON-RPC”, mà là hai lớp duy trì tính nhất quán cuối cùng nhờ cầu nối và cam kết trạng thái. Điều thật sự cần chú ý là các tình huống xuyên lớp: inclusion trên DuskEVM diễn ra nhanh, nhưng quyết toán đầy đủ và xác nhận cầu nối còn phải đi thêm vài bước; trong khoảng thời gian đó, trạng thái mà hai bên nhìn thấy có thể tạm thời khác nhau.
Vai trò của $DUSK khiến rủi ro này trở nên cụ thể hơn. Phía L1 gốc dùng LUX để biểu diễn, 1 DUSK bằng 10 mũ 9 LUX; còn DuskEVM để tương thích với chuỗi công cụ Ethereum, lại bộc lộ DUSK theo dạng thập phân 18 chữ số. Khi cầu nối thực hiện quy đổi hoặc xử lý độ chính xác không đúng, cùng một giá trị có thể tạm thời không khớp giữa hai sổ sách trong thời gian ngắn. Với chuyển khoản thông thường có thể chỉ là sai số hiển thị, nhưng với quyết toán có điều tiết, có thể là “cửa sổ thao tác sai” kiểu một bên hiển thị đã nhận tiền, trong khi phía bên kia vẫn chưa được xác nhận cuối cùng.
Đánh giá sau khi tôi xem xong là: đánh giá #dusk , không thể chỉ nhìn vào việc “tương thích EVM”; còn phải xem cơ chế đảm bảo tính nhất quán giữa sổ quyết toán L1 và sổ thực thi EVM. Tài liệu hiện chưa giải thích đầy đủ thứ tự ưu tiên của nguồn dữ liệu mang tính thẩm quyền, cơ chế phát hiện xung đột và khắc phục, và DUSK chính là con số không được đọc nhầm nhất trong hai sổ này. DYOR.
