#dusk $DUSK @Dusk
Tôi đã xem lại tài liệu DuskEVM của Dusk sau khi thấy kết quả load-test mới nhất, và tôi nhận ra mình đã đưa ra một giả định đơn giản: một khối EVM nhanh có nghĩa là DuskDS hẳn phải thực thi lại cùng các giao dịch đó.
Luồng tài liệu lại khác. Một giao dịch được gửi đến sequencer của DuskEVM, đi vào một khối L2, và batcher xuất bản dữ liệu của nó lên DuskDS. Sau đó, các cam kết trạng thái và các bằng chứng lỗi liên kết trạng thái kết quả với việc quyết toán trên DuskDS. Trong bài test được báo cáo, khoảng 10.000 giao dịch trong một khối DuskEVM kéo dài hai giây tạo ra tám blob, được chia trên hai giao dịch DuskDS, trong khi DuskDS vẫn tiếp tục xử lý đúng khối lượng công việc bản địa của nó.
Điều đó khiến tôi nhìn nhận vấn đề theo cách khác.
Diễn giải của tôi: kết quả quan trọng không chỉ nằm ở số lượng giao dịch. Mấu chốt là việc thực thi EVM và quyết toán trên DuskDS đã xử lý các công việc trộn lẫn thông qua các mô hình trạng thái tách biệt, mà không có ví dụ nào cho thấy một loại tải công việc chặn loại còn lại.
Điểm không chắc của tôi là điều gì xảy ra ngoài trường hợp “sạch”. Trong điều kiện nhu cầu hỗn hợp được duy trì, giới hạn cận xấu nhất giữa việc đưa vào (EVM inclusion), xuất bản dữ liệu và quyết toán trên DuskDS là gì? Nếu sequencer hoặc batcher bị tắc, ai là người có thể khởi tạo khôi phục, và điều gì ngăn chặn thẩm quyền đó sắp xếp lại hoặc trì hoãn các giao dịch tài chính đang chờ?
Tôi muốn theo dõi điều này trong thực tế.
Tôi đã xem lại tài liệu DuskEVM của Dusk sau khi thấy kết quả load-test mới nhất, và tôi nhận ra mình đã đưa ra một giả định đơn giản: một khối EVM nhanh có nghĩa là DuskDS hẳn phải thực thi lại cùng các giao dịch đó.
Luồng tài liệu lại khác. Một giao dịch được gửi đến sequencer của DuskEVM, đi vào một khối L2, và batcher xuất bản dữ liệu của nó lên DuskDS. Sau đó, các cam kết trạng thái và các bằng chứng lỗi liên kết trạng thái kết quả với việc quyết toán trên DuskDS. Trong bài test được báo cáo, khoảng 10.000 giao dịch trong một khối DuskEVM kéo dài hai giây tạo ra tám blob, được chia trên hai giao dịch DuskDS, trong khi DuskDS vẫn tiếp tục xử lý đúng khối lượng công việc bản địa của nó.
Điều đó khiến tôi nhìn nhận vấn đề theo cách khác.
Diễn giải của tôi: kết quả quan trọng không chỉ nằm ở số lượng giao dịch. Mấu chốt là việc thực thi EVM và quyết toán trên DuskDS đã xử lý các công việc trộn lẫn thông qua các mô hình trạng thái tách biệt, mà không có ví dụ nào cho thấy một loại tải công việc chặn loại còn lại.
Điểm không chắc của tôi là điều gì xảy ra ngoài trường hợp “sạch”. Trong điều kiện nhu cầu hỗn hợp được duy trì, giới hạn cận xấu nhất giữa việc đưa vào (EVM inclusion), xuất bản dữ liệu và quyết toán trên DuskDS là gì? Nếu sequencer hoặc batcher bị tắc, ai là người có thể khởi tạo khôi phục, và điều gì ngăn chặn thẩm quyền đó sắp xếp lại hoặc trì hoãn các giao dịch tài chính đang chờ?
Tôi muốn theo dõi điều này trong thực tế.
