200 mili giây: Optimism(OP) hoàn tất chuyển đổi sub-block

Chu kỳ tạo sub-block trên mạng chính Optimism(OP) đã giảm từ 250 mili giây xuống còn 200 mili giây, giúp rút ngắn thời gian phản hồi giao dịch. Tuy nhiên một số trường dữ liệu thô lại trả về giá trị 0, khiến gánh nặng xác minh của các ứng dụng và nhà cung cấp RPC tăng lên.

Trang trạng thái của Optimism cho biết quá trình chuyển đổi "200ms subblocks" trên OP Mainnet đã hoàn tất lúc 5h16 sáng ngày 1 (giờ Hàn Quốc). Đây là một phần trong quá trình chuyển đổi hạ tầng sequencer, từ sản xuất flashblock 250 mili giây sang sản xuất sub-block 200 mili giây.

Điểm mấu chốt của thay đổi lần này không nằm ở tốc độ mà ở cách diễn giải dữ liệu. Thông báo trạng thái của QuickNode cho biết trong quá trình chuyển đổi sub-block trên OP Stack, bốn trường state_root, block_hash, withdrawals_root và withdrawals chuyển thành giá trị 0 (zero value), trong khi receipts_root và logs_bloom vẫn giữ giá trị thực.

Do định dạng payload không đổi, lỗi phân tích cú pháp có thể không xuất hiện ngay. Nhưng nếu nhà phát triển hiểu nhầm các trường giá trị 0 là trạng thái thực, việc kiểm tra số dư, chứng minh trạng thái (state proof) và xử lý rút tiền có thể gặp lỗi tương thích một cách âm thầm.

Sub-block không phải là block đã được xác nhận cuối cùng. Theo đặc tả OP Stack, thời gian mặc định của flashblock là 200 mili giây, và ở giai đoạn xác nhận sơ bộ (pre-confirmation), các giá trị như blockHash có thể chỉ là placeholder. Đây là cơ chế giúp người dùng nắm kết quả giao dịch nhanh hơn, nhưng việc xác minh trạng thái cuối cùng vẫn cần xử lý riêng.

Flashblock là cấu trúc truyền một phần thông tin block theo chu kỳ ngắn, trước khi giao dịch được xác nhận hoàn toàn. Các mạng layer 2 thường cung cấp tín hiệu xác nhận sơ bộ để giảm độ trễ cảm nhận của người dùng, nhưng tín hiệu này khó được xử lý với mức độ tin cậy tương đương dữ liệu block cuối cùng.

Kênh truy cập công khai cũng có giới hạn riêng. Tài liệu chính thức của Optimism công bố địa chỉ websocket flashblock của OP Mainnet, đồng thời lưu ý URL công khai này bị giới hạn tốc độ truy cập khá chặt. URL RPC công khai không hỗ trợ kết nối websocket; nếu cần dùng tính năng websocket, nhà phát triển được khuyến nghị tự vận hành node riêng hoặc sử dụng nhà cung cấp RPC bên thứ ba.

Tài liệu của các đơn vị hạ tầng bên ngoài cũng đưa ra hướng dẫn tương tự. Alchemy mô tả flashblock trên OP Mainnet là tính năng cập nhật một phần block mỗi 200 mili giây. QuickNode cho biết có thể tra cứu trạng thái flashblock mới nhất qua tag pending, và nhận dữ liệu flashblock theo thời gian thực qua websocket.

Trên thực tế vận hành, endpoint công khai và khả năng tương thích của client đã bộc lộ là biến số. Trên kênh thảo luận GitHub dành cho nhà phát triển Optimism, có câu hỏi về địa chỉ websocket flashblock cùng phản ánh về giới hạn truy cập WSS công khai. Một số câu trả lời khuyên nên dùng nhà cung cấp RPC bên ngoài thay vì endpoint công khai.

Ở một issue GitHub khác, có báo cáo cho biết docker image op-reth gặp lỗi "TLS support not compiled in" khi kết nối tới WSS của flashblock. Điều này cho thấy dù tốc độ được cải thiện rõ rệt, bản phân phối client, khả năng hỗ trợ TLS và cách kết nối websocket vẫn có thể là điểm nghẽn khi triển khai dịch vụ thực tế.

Về bản chất, đợt chuyển đổi lần này thiên về vấn đề chất lượng dữ liệu và ranh giới truyền tải hơn là sự cố mạng lưới. Trang trạng thái Optimism hiển thị OP Mainnet ở trạng thái vận hành bình thường sau khi chuyển đổi. Các tài liệu liên quan cũng mô tả thay đổi này là cải thiện hiệu năng và điều chỉnh khả năng tương thích.

Xét về cấu trúc thị trường, thay đổi kiểu này ảnh hưởng trước tiên tới các nhà cung cấp RPC, ví, trình khám phá block (block explorer) và dịch vụ dữ liệu on-chain. Những dịch vụ trực tiếp tiêu thụ luồng sub-block hoặc chuyển tiếp payload thô cho khách hàng sẽ nhạy cảm hơn so với dịch vụ người dùng phổ thông chỉ đọc block cuối cùng.

Người dùng trong nước cũng có điểm liên quan. Nếu sàn giao dịch hoặc ví trong nước phụ thuộc vào nhà cung cấp RPC bên ngoài để hiển thị nạp/rút, số dư và trạng thái gọi hợp đồng trên OP Mainnet, đơn vị vận hành cần phân biệt rõ ranh giới giữa dữ liệu xác nhận sơ bộ và dữ liệu cuối cùng. Tuy nhiên, tài liệu tham khảo hiện chưa ghi nhận trường hợp sự cố hay gián đoạn nạp/rút nào từ các đơn vị trong nước.

Optimism gần đây cũng liên tục có các vấn đề về quản trị và tái cấu trúc hệ sinh thái. Trước đó, TokenPost từng đưa tin về việc đề xuất tái phân bổ 546,9 triệu OP airdrop còn lại của người dùng sang quỹ hệ sinh thái chiến lược đã được thông qua. Đợt chuyển đổi sub-block lần này là vấn đề điều chỉnh hạ tầng vận hành của OP Mainnet, tách biệt với vấn đề phân bổ token.

Đơn vị vận hành dịch vụ cần xử lý để giá trị 0 của bốn trường dữ liệu nói trên không bị đưa vào dữ liệu trạng thái, số dư hay đầu vào chứng minh. Đặc biệt, nếu hệ thống đang hiển thị hoặc lưu trữ trạng thái pending và dữ liệu block cuối cùng theo cùng một tiêu chuẩn, cần rà soát đồng thời đường nhận flashblock, cách kết nối websocket và định dạng phản hồi theo từng nhà cung cấp RPC.