การเปลี่ยนผ่านสู่ระบบเข้ารหัสต้านควอนตัม (Post-Quantum Cryptography) กำลังกลายเป็นโจทย์ความปลอดภัยระยะยาวของบิตคอยน์(BTC) และอีเธอเรียม(ETH) แม้ในตอนนี้คอมพิวเตอร์ควอนตัมยังไม่สามารถเจาะระบบเข้ารหัสที่ใช้อยู่ในปัจจุบันได้ แต่ประเด็นสำคัญอยู่ที่ต้นทุนของการเปลี่ยนระบบกุญแจสาธารณะและลายเซ็นดิจิทัล ซึ่งอาจส่งผลต่อค่าธรรมเนียมและภาระด้านพื้นที่จัดเก็บข้อมูลของเครือข่าย
สถาบันมาตรฐานและเทคโนโลยีแห่งชาติสหรัฐฯ (NIST) ประกาศรับรองมาตรฐานการเข้ารหัสต้านควอนตัม 3 ฉบับอย่างเป็นทางการเมื่อวันที่ 13 สิงหาคม 2024 ได้แก่ ML-KEM สำหรับการแลกเปลี่ยนกุญแจ, ML-DSA ลายเซ็นดิจิทัลแบบแลตทิซ (lattice-based) และ SLH-DSA ลายเซ็นดิจิทัลที่อิงฟังก์ชันแฮช
ระบบเข้ารหัสต้านควอนตัม หมายถึงเทคโนโลยีการเข้ารหัสที่ออกแบบมาให้ทนทานต่อการโจมตีจากคอมพิวเตอร์ควอนตัม แม้การประกาศมาตรฐานของ NIST จะวางเกณฑ์การเปลี่ยนผ่านสำหรับวงการไอทีทั่วไปไว้แล้ว แต่ในกรณีของบล็อกเชน ต้นทุนการเปลี่ยนผ่านจะปรากฏชัดเจนกว่า เพราะทุกธุรกรรมต้องแนบข้อมูลลายเซ็นไปด้วย
เว็บไซต์ Crypto Briefing อ้างอิงคำอธิบายของชาร์ลส์ กีเยเมต์(Charles Guillemet) ประธานเจ้าหน้าที่ฝ่ายเทคโนโลยีของเลดเจอร์(Ledger) ที่มองว่าบิตคอยน์และอีเธอเรียมอาจพิจารณาใช้ SLH-DSA มากกว่า ML-DSA เนื่องจากลายเซ็นแบบอิงฟังก์ชันแฮชพึ่งพาความปลอดภัยของฟังก์ชันแฮชมากกว่าสมมติฐานทางคณิตศาสตร์ใหม่ ทำให้อธิบายต่อผู้ดูแลเครือข่ายบล็อกเชนที่เน้นความระมัดระวังได้ง่ายกว่า
อย่างไรก็ตาม มุมมองนี้เป็นการตีความของฝั่งเลดเจอร์เท่านั้น เอกสารทางการของอีเธอเรียมและวงสนทนาในชุมชนยังพูดถึงทั้งแนวทางอิงฟังก์ชันแฮชและแนวทางแลตทิซควบคู่กัน จึงยังไม่ใช่ข้อสรุปที่วงการยอมรับร่วมกัน
เลดเจอร์เปิดเผยในเอกสารเผยแพร่เมื่อเดือนกรกฎาคม 2026 ว่าได้เพิ่ม API ของ ML-KEM และ ML-DSA เข้าไปใน SDK ของตน โดยเอกสารฉบับเดียวกันระบุว่า ML-DSA เป็นลายเซ็นที่อาจใช้แทน ECDSA แบบเดิมได้ แต่กุญแจและลายเซ็นแบบใหม่อาจมีขนาดใหญ่กว่าเดิมถึง 30-50 เท่า
ความแตกต่างของขนาดนี้ไม่ใช่แค่รายละเอียดทางเทคนิคสำหรับบล็อกเชน เพราะทุกธุรกรรมต้องแนบลายเซ็นไปด้วย เมื่อขนาดลายเซ็นใหญ่ขึ้น ค่าแก๊ส ค่าธรรมเนียม พื้นที่จัดเก็บของโหนด และต้นทุนการกระจายข้อมูลในเครือข่ายก็อาจเพิ่มขึ้นตามไปด้วย
เอกสารทางการของอีเธอเรียมระบุว่า บัญชีมาตรฐานในปัจจุบันเซ็นธุรกรรมด้วย ECDSA บนเส้นโค้ง secp256k1 ส่วนการเปลี่ยนผ่านสู่ระบบต้านควอนตัมถูกวางไว้เป็นแผนงานระยะยาวราวปี 2029
เส้นทางการเปลี่ยนผ่านของอีเธอเรียมไม่ได้เปลี่ยนไปใช้มาตรฐานเดียวในคราวเดียว ที่ชั้นฉันทามติ (consensus layer) มีการหารือเรื่อง leanXMSS ซึ่งอิงฟังก์ชันแฮช ส่วนชั้นการประมวลผล (execution layer) พูดถึงความยืดหยุ่นของลายเซ็นผ่านการรวมบัญชี (account abstraction) ขณะที่ด้านความพร้อมใช้งานของข้อมูลและการพิสูจน์แบบไม่เปิดเผยข้อมูล (zero-knowledge proof) ก็พิจารณาทั้งแนวทางอิงแฮชและแลตทิซควบคู่กัน
วงสนทนาในชุมชนก็ยังแบ่งเป็นหลายฝ่าย เว็บบอร์ด Ethereum Magicians มีข้อเสนอ อาทิ PQTS, ERC-8231 และธุรกรรมแบบเฟรม (frame transactions) ขณะที่บางฝ่ายมองว่าลายเซ็นแบบแลตทิซตระกูล Falcon และ Dilithium ก็เป็นทางเลือกที่ใช้งานได้จริงเช่นกัน
ประเด็นนี้เชื่อมโยงกับการหารือเรื่องปรับโครงสร้างการออกแบบฟังก์ชันแฮชของอีเธอเรียมที่ TokenPost เคยรายงานไปก่อนหน้านี้ ใจความสำคัญไม่ได้อยู่ที่การเลือกใช้เทคโนโลยีใดทันที แต่อยู่ที่กระบวนการจัดลำดับความสำคัญของการออกแบบระบบเข้ารหัสใหม่ ให้สอดคล้องกับการเปลี่ยนผ่านสู่ยุคต้านควอนตัม
ฝั่งบิตคอยน์เคลื่อนไหวอย่างระมัดระวังกว่า เอกสารสำหรับนักพัฒนาบิตคอยน์ระบุว่ากุญแจสาธารณะใช้ ECDSA บนเส้นโค้ง secp256k1 ส่วนข้อเสนอ BIP-361 ฉบับร่างเสนอแนวทางยุติการใช้ ECDSA และลายเซ็นแบบชนอร์ (Schnorr) แบบเป็นขั้นตอน ก่อนย้ายไปใช้ที่อยู่ที่ปลอดภัยต่อควอนตัม
แต่สถานะของ BIP-361 ยังเป็นเพียง 'ฉบับร่าง' (Draft) เท่านั้น ส่วนประเด็นวิจัยเรื่องกระเป๋าเงินต้านควอนตัมของ Bitcoin Core ก็ถูกปิดไปแล้วในสถานะ 'ไม่มีแผนดำเนินการ' (not planned)
ความแตกต่างนี้เกิดจากเรื่องการกำกับดูแล (governance) มากกว่าเรื่องเทคโนโลยี อีเธอเรียมจัดการทางเลือกต่าง ๆ แบบคู่ขนานผ่านแผนงาน ทีมวิจัย และการหารือเรื่องการรวมบัญชี ขณะที่บิตคอยน์ต้องอาศัยฉันทามติร่วมกันระหว่างผู้ให้บริการกระเป๋าเงิน ตลาดแลกเปลี่ยน นักขุด และผู้ดูแลโหนดก่อนเป็นลำดับแรก
สำหรับนักลงทุนในไทย ประเด็นนี้ถือเป็นตัวแปรระยะกลางถึงยาวด้านโครงสร้างพื้นฐานการเก็บรักษาสินทรัพย์และความปลอดภัยของเครือข่าย มากกว่าปัจจัยที่จะส่งผลต่อราคาในระยะสั้น สิ่งที่ยืนยันได้ในตอนนี้คือ มาตรฐานของ NIST ได้ถูกกำหนดขึ้นแล้ว เลดเจอร์เริ่มดำเนินการในระดับ SDK ส่วนบิตคอยน์และอีเธอเรียมต่างก็เดินหน้าหารือเรื่องการเปลี่ยนผ่านด้วยความเร็วที่แตกต่างกัน
ความคิดเห็น 0