200 มิลลิวินาที! ออปติมิซึม(OP) เปลี่ยนซับบล็อกเสร็จ แต่ 4 ฟิลด์ข้อมูลกลายเป็นศูนย์

เมนเน็ตของออปติมิซึม(Optimism, OP) ลดรอบการสร้าง 'ซับบล็อก' (subblock) จาก 250 มิลลิวินาทีเหลือ 200 มิลลิวินาทีเรียบร้อยแล้ว ทำให้ผู้ใช้เห็นผลธุรกรรมได้เร็วขึ้น แต่ผู้เชี่ยวชาญด้านโครงสร้างพื้นฐานเตือนว่า ฟิลด์ข้อมูลดิบบางส่วนที่ส่งออกมาพร้อมกันกลับกลายเป็นค่า 'ศูนย์' (zero value) ทำให้แอปพลิเคชันและผู้ให้บริการ RPC ต้องเพิ่มขั้นตอนตรวจสอบข้อมูลมากขึ้น

เพจสถานะ (status page) ของออปติมิซึมระบุว่า การเปลี่ยนผ่านระบบ '200ms subblocks' บนเมนเน็ต OP เสร็จสมบูรณ์เมื่อวันที่ 1 กันยายน เวลา 03.16 น. ตามเวลาไทย โดยเป็นส่วนหนึ่งของการปรับโครงสร้างพื้นฐานฝั่งซีเควนเซอร์ (sequencer) จากเดิมที่ผลิต 'แฟลชบล็อก' (flashblock) ทุก 250 มิลลิวินาที มาเป็นการผลิตซับบล็อกทุก 200 มิลลิวินาที

ประเด็นสำคัญของการเปลี่ยนแปลงครั้งนี้ไม่ได้อยู่ที่ความเร็วเพียงอย่างเดียว แต่อยู่ที่การตีความข้อมูล QuickNode ผู้ให้บริการโครงสร้างพื้นฐานบล็อกเชน ออกประกาศสถานะระบุว่า ระหว่างการเปลี่ยนผ่านซับบล็อกบน OP Stack ฟิลด์ △'state_root' △'block_hash' △'withdrawals_root' △'withdrawals' จะถูกแทนที่ด้วยค่าศูนย์ ขณะที่ฟิลด์ 'receipts_root' และ 'logs_bloom' ยังคงเป็นค่าจริงตามปกติ

เนื่องจากรูปแบบของเพย์โหลด (payload) ยังคงเดิม ระบบจึงอาจไม่เกิดข้อผิดพลาดในการแยกวิเคราะห์ข้อมูล (parsing) ทันที แต่หากนักพัฒนานำค่าศูนย์เหล่านี้ไปใช้เสมือนเป็นค่าสถานะจริง ก็อาจเกิดปัญหาความเข้ากันได้แบบเงียบ ๆ ในการตรวจสอบยอดคงเหลือ การพิสูจน์สถานะ (state proof) และการประมวลผลที่เกี่ยวข้องกับการถอนเงิน

ทั้งนี้ ซับบล็อกไม่ใช่บล็อกที่ยืนยันขั้นสุดท้าย (final block) สเปกของ OP Stack ระบุค่าเริ่มต้นของแฟลชบล็อกไว้ที่ 200 มิลลิวินาที และอธิบายว่าในขั้นตอนพรีคอนเฟิร์ม (pre-confirmation) ค่าบางอย่าง เช่น 'blockHash' อาจเป็นเพียงตัวยึดตำแหน่ง (placeholder) ซึ่งช่วยให้ผู้ใช้เห็นผลธุรกรรมได้เร็วขึ้น แต่การตรวจสอบสถานะขั้นสุดท้ายยังต้องมีกระบวนการแยกต่างหาก

แฟลชบล็อกคือโครงสร้างที่ส่งข้อมูลบางส่วนของบล็อกออกมาเป็นช่วงสั้น ๆ ก่อนที่ธุรกรรมจะได้รับการยืนยันสมบูรณ์ เครือข่ายเลเยอร์ 2 โดยทั่วไปมักใช้สัญญาณพรีคอนเฟิร์มลักษณะนี้เพื่อลดความรู้สึกล่าช้าของผู้ใช้ แต่สัญญาณดังกล่าวยังไม่สามารถนำไปใช้ในระดับความน่าเชื่อถือเดียวกับข้อมูลบล็อกที่ยืนยันแล้ว

ช่องทางเข้าถึงสาธารณะก็มีข้อจำกัดเช่นกัน เอกสารทางการของออปติมิซึมเปิดเผยที่อยู่เว็บซ็อกเก็ต (WebSocket) สำหรับแฟลชบล็อกบนเมนเน็ต OP พร้อมระบุว่า URL สาธารณะนี้ถูกจำกัดอัตราการใช้งาน (rate limit) อย่างเข้มงวด และ RPC URL สาธารณะไม่รองรับการเชื่อมต่อผ่านเว็บซ็อกเก็ต หากต้องการใช้ฟังก์ชันนี้ ผู้ใช้ต้องรันโหนดของตนเองหรือใช้บริการผู้ให้บริการ RPC จากบุคคลที่สาม

เอกสารของผู้ให้บริการโครงสร้างพื้นฐานรายอื่นก็ระบุไปในทิศทางเดียวกัน Alchemy อธิบายฟีเจอร์แฟลชบล็อกบนเมนเน็ต OP ว่าเป็นการอัปเดตบล็อกบางส่วนทุก 200 มิลลิวินาที ส่วน QuickNode ระบุว่าสามารถเรียกดูสถานะแฟลชบล็อกล่าสุดผ่านแท็ก 'pending' และรับข้อมูลแฟลชบล็อกแบบเรียลไทม์ผ่านเว็บซ็อกเก็ตได้

ในทางปฏิบัติ ความเข้ากันได้ของเอนด์พอยต์สาธารณะกับไคลเอนต์ต่าง ๆ กลายเป็นตัวแปรสำคัญ กระทู้สนทนาบน GitHub ของนักพัฒนาออปติมิซึมมีทั้งคำถามเกี่ยวกับที่อยู่เว็บซ็อกเก็ตของแฟลชบล็อก และความเห็นที่ชี้ว่าการเชื่อมต่อ WSS สาธารณะถูกจำกัดมาก โดยมีคำตอบแนะนำให้ใช้ผู้ให้บริการ RPC ภายนอกแทนเอนด์พอยต์สาธารณะ

อีกทั้งยังมีรายงานใน GitHub Issue แยกต่างหากระบุว่า อิมเมจ Docker ของ 'op-reth' เกิดข้อผิดพลาด 'TLS support not compiled in' เมื่อพยายามเชื่อมต่อกับ WSS ของแฟลชบล็อก สะท้อนว่าแม้ความเร็วจะดีขึ้นจริง แต่รูปแบบการติดตั้งไคลเอนต์ การรองรับ TLS และวิธีเชื่อมต่อเว็บซ็อกเก็ต ยังอาจเป็นคอขวดของการนำไปใช้งานจริง

อย่างไรก็ตาม การเปลี่ยนแปลงครั้งนี้ไม่ใช่เหตุขัดข้องของเครือข่าย แต่เป็นประเด็นเรื่องคุณภาพข้อมูลและขอบเขตการส่งข้อมูลมากกว่า เพจสถานะของออปติมิซึมยังคงแสดงสถานะเมนเน็ต OP เป็นปกติหลังการเปลี่ยนผ่าน และเอกสารต่าง ๆ ก็อธิบายว่านี่คือการปรับปรุงประสิทธิภาพควบคู่กับการปรับความเข้ากันได้ของระบบ

ในเชิงโครงสร้างตลาด การเปลี่ยนแปลงลักษณะนี้ส่งผลกระทบต่อผู้ให้บริการ RPC กระเป๋าเงินดิจิทัล บล็อกเอ็กซ์พลอเรอร์ และบริการข้อมูลบนเชนก่อนกลุ่มอื่น โดยเฉพาะบริการที่ดึงข้อมูลสตรีมซับบล็อกโดยตรงหรือส่งต่อเพย์โหลดดิบให้ลูกค้า จะได้รับผลกระทบมากกว่าบริการทั่วไปที่อ่านเฉพาะบล็อกสุดท้าย

สำหรับผู้ใช้งานในไทยก็มีจุดเชื่อมโยงเช่นกัน หากเว็บเทรดหรือกระเป๋าเงินดิจิทัลที่ให้บริการฝาก-ถอนบนเมนเน็ต OP การแสดงยอดคงเหลือ หรือสถานะการเรียกใช้สัญญาอัจฉริยะ พึ่งพาผู้ให้บริการ RPC ภายนอก ก็จำเป็นต้องแยกขอบเขตระหว่างข้อมูลพรีคอนเฟิร์มกับข้อมูลขั้นสุดท้ายให้ชัดเจน ทั้งนี้ จากข้อมูลที่มีอยู่ ยังไม่พบรายงานเหตุขัดข้องหรือการระงับฝาก-ถอนจากผู้ให้บริการรายใดในไทย

ก่อนหน้านี้ ออปติมิซึมมีความเคลื่อนไหวด้านธรรมาภิบาลและการปรับโครงสร้างระบบนิเวศต่อเนื่อง โดยทีมข่าวเคยรายงานมติที่อนุมัติให้จัดสรรโทเคน OP ส่วนที่เหลือจากแอร์ดรอปผู้ใช้จำนวน 546.9 ล้าน OP ไปยังกองทุนระบบนิเวศเชิงกลยุทธ์แทน ซึ่งเป็นคนละประเด็นกับการปรับโครงสร้างพื้นฐานการรันระบบของเมนเน็ต OP ในครั้งนี้

ผู้ดูแลระบบบริการต่าง ๆ จำเป็นต้องป้องกันไม่ให้ค่าศูนย์ของทั้ง 4 ฟิลด์ไหลเข้าไปเป็นข้อมูลนำเข้าสำหรับการตรวจสอบสถานะ ยอดคงเหลือ หรือการพิสูจน์ (proof) โดยเฉพาะระบบที่แสดงผลหรือจัดเก็บข้อมูลสถานะ 'pending' กับบล็อกขั้นสุดท้ายด้วยมาตรฐานเดียวกัน ควรตรวจสอบช่องทางรับข้อมูลแฟลชบล็อก วิธีเชื่อมต่อเว็บซ็อกเก็ต และรูปแบบการตอบกลับของผู้ให้บริการ RPC แต่ละรายไปพร้อมกัน