Airbender Prime và phép thử khối chậm nhất

Phân tích | Ngày 17/10/2026

Đánh giá ngày 13/10 của ZKsync báo cáo một GPU chứng minh 7.200 khối, tất cả dưới 12 giây mỗi khối.

Câu hỏi kỹ thuật hữu ích là dùng phần thời gian dư từ bộ chứng minh nhanh hơn như thế nào. Open Market Notes xem xét ba lựa chọn: giảm chờ, hấp thụ đợt công việc dồn đến hoặc yêu cầu thêm các triển khai đồng thuận. Các phép tính dưới đây là ví dụ giả định nguyên bản, không phải số đo của Airbender Prime hay bản tái lập độc lập của thử nghiệm đã công bố.

Xác định khi nào đồng hồ dừng

Lộ trình Ethereum mô tả nhịp tạo khối 12 giây và phân biệt việc tạo bằng chứng với xác minh.

Trong phép thử dịch vụ chúng tôi đề xuất, bắt đầu tính giờ khi một công việc hoàn chỉnh sẵn sàng và dừng khi kết quả bắt buộc đã được chấp nhận. Ghi riêng thời gian xếp hàng, chứng minh, truyền và xác minh. Giai đoạn chứng minh ngắn hơn tạo chỗ cho các khâu khác, nhưng không xác định chúng thực sự mất bao lâu. Chỉ riêng khoảng cách giữa các khối cũng không quy định hạn chấp nhận của dịch vụ; điều đó phải được nêu rõ.

Một công việc chậm có thể làm chậm việc kế tiếp

Xét năm công việc độc lập đến ở giây 0, 12, 24, 36 và 48. Một bộ xử lý làm lần lượt theo thứ tự đến, không ngắt công việc đang chạy. Thời gian xử lý tương ứng là 8, 8, 20, 8 và 8 giây. Hạn của mỗi việc là 12 giây sau khi đến. Bỏ qua truyền dữ liệu, xác minh, khởi động và mọi chi phí thời gian khác; hoàn thành đúng thời điểm hạn vẫn được tính là đúng hạn.

Các thời điểm hoàn thành là giây 8, 20, 44, 52 và 60, so với các hạn 12, 24, 36, 48 và 60. Việc thứ ba và thứ tư trễ, dù thời gian xử lý trung bình chỉ là 10,4 giây. Việc thứ tư chỉ cần tám giây xử lý nhưng phải chịu thời gian chờ do việc thứ ba để lại. Việc thứ năm vừa kịp hạn, không còn dư cho bất kỳ chi phí thời gian nào đã bỏ qua.

Ví dụ này không ước tính tỷ lệ trễ của một hệ thống thực. Nó chỉ tách thời gian thực hiện công việc khỏi thời gian đã trôi qua kể từ lúc công việc đến. Đổi thứ tự, cho phép ngắt để xử lý việc khác hoặc thêm bộ xử lý sẽ tạo ra một thí nghiệm khác. Các lựa chọn đó cần được công khai thay vì nằm khuất trong số trung bình.

Công suất dự phòng khác với đồng thuận bắt buộc

Nghiên cứu của Ethereum Foundation đề xuất đa dạng hóa cả zkVM lẫn các triển khai chuyển đổi trạng thái mà chúng thực thi.

Bây giờ xét hai quy tắc chấp nhận hoàn toàn giả định. Quy tắc thứ nhất nhận kết quả hợp lệ đầu tiên từ hai bộ xử lý. Quy tắc thứ hai yêu cầu cả hai triển khai độc lập được chỉ định đều đưa ra kết quả hợp lệ và thống nhất. Giả sử cùng một khối ứng viên, kết quả có ở giây thứ tám và thứ mười ba, không có chi phí thời gian khác. Quy tắc thứ nhất chấp nhận ở giây thứ tám; quy tắc thứ hai không thể chấp nhận trước giây thứ mười ba. Đây là chính sách dịch vụ minh họa, không mô tả cơ chế đồng thuận Ethereum hiện tại.

Bộ xử lý bổ sung vì thế có vai trò khác nhau trong hai thiết kế. Ở một thiết kế, nó có thể bù cho kết quả đến chậm; ở thiết kế kia, kết quả của nó là một điều kiện bắt buộc. Nhiều máy hơn chưa cho biết những kết quả nào phải thống nhất. Mọi so sánh tốc độ cần nêu rõ quy tắc chấp nhận, kể cả việc thiếu kết quả bắt buộc có khiến công việc vẫn chưa hoàn tất hay không.

Thử đợt dồn việc và công bố cả phần chưa xong

Chúng tôi đề xuất phát lại một chuỗi khối cố định theo lịch đến được xác định rõ, bao gồm cả các đợt dồn việc. Giữ lịch sử hàng đợi thay vì đặt lại bộ xử lý trước mỗi khối. Nêu phần cứng sẵn có, quy tắc lập lịch, hạn và điều kiện chấp nhận. Chạy cùng chuỗi đó khi đã bật yêu cầu dự phòng hoặc đa dạng triển khai dự kiến.

Báo cáo riêng kết quả được chấp nhận đúng hạn, kết quả trễ và công việc chưa hoàn thành. Cho biết hàng đợi mất bao lâu để phục hồi sau một đợt dồn việc. Đừng loại việc chưa xong chỉ vì nó không có thời điểm hoàn thành: bỏ chúng đi có thể khiến dịch vụ đang quá tải trông nhanh hơn. Tách kết quả vận hành này khỏi đánh giá an toàn.

Lựa chọn thiết kế nằm ở cách dùng thời gian tiết kiệm được. Giảm chờ, dự trữ cho một chuỗi khó xử lý và yêu cầu thêm một kết quả là những cách khác nhau để dùng cùng phần thời gian dư. Một trình diễn hữu ích tiếp theo cần nêu rõ sự phân bổ đó và cho thấy liệu hạn đã chọn có chịu được hàng đợi do thiết kế tạo ra hay không.