a16z丨กับการแข่งกับคอมพิวเตอร์ควอนตัม: คู่มือการเปลี่ยนผ่านอย่างระมัดระวังของอัลกอริทึมเข้ารหัสหลังควอนตัมในบล็อกเชน

เขียนโดย: Justin Thaler หุ้นส่วนวิจัยคริปโต a16z และรองศาสตราจารย์ด้านวิทยาการคอมพิวเตอร์ มหาวิทยาลัยจอร์จทาวน์ \nแปลโดย: Yangz Techub News\n\n\nการทำนายเวลาที่จะมีคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัสลับมักถูกเกินความเป็นจริง ทำให้มีการเรียกร้องให้เปลี่ยนไปใช้หลังควอนตัมเข้ารหัสอย่างเร่งด่วนและครอบคลุม การเรียกร้องเหล่านี้มักมองข้ามต้นทุนและความเสี่ยงของการเปลี่ยนแปลงก่อนเวลา และละเลยลักษณะความเสี่ยงที่แตกต่างกันของบรรพบุรุษเข้ารหัสต่างๆ:\n\n\nแม้การเข้ารหัสหลังควอนตัมจะมีต้นทุนสูง แต่ก็จำเป็นต้องใช้งานทันที: การโจมตี “เก็บข้อมูลก่อนถอดรหัส” (HNDL) ได้เริ่มขึ้น ข้อมูลที่เข้ารหัสในปัจจุบันยังคงมีคุณค่าเมื่อคอมพิวเตอร์ควอนตัมมาถึงจริง (แม้จะต้องใช้เวลาหลายสิบปี) นอกจากนี้ ผลกระทบด้านประสิทธิภาพและความเสี่ยงในการดำเนินการของการเข้ารหัสหลังควอนตัมก็มีอยู่ แต่สำหรับข้อมูลที่ต้องเก็บเป็นความลับในระยะยาว การโจมตี HNDL ทำให้เราไม่มีทางเลือกอื่น\n\nการลงนามหลังควอนตัมก็มีข้อพิจารณาที่แตกต่างกัน มันไม่ง่ายต่อการถูกโจมตีด้วย HNDL และต้นทุนและความเสี่ยง (ขนาดที่ใหญ่ขึ้น, ผลกระทบด้านประสิทธิภาพ, ความไม่สมบูรณ์ของการดำเนินการและช่องโหว่ที่อาจเกิดขึ้น) ทำให้เราต้องระมัดระวัง ไม่ใช่เปลี่ยนทันที\n\n\nความแตกต่างเหล่านี้สำคัญมาก ความเข้าใจผิดจะบิดเบือนการวิเคราะห์ต้นทุน-ผลประโยชน์ ทำให้ทีมมองข้ามความเสี่ยงด้านความปลอดภัยที่สำคัญกว่า เช่น ช่องโหว่ของระบบ\n\nความท้าทายที่แท้จริงในการเปลี่ยนไปใช้หลังควอนตัมคือ การทำให้ความเร่งด่วนสอดคล้องกับภัยคุกคามที่แท้จริง ด้านล่างนี้ ผมจะชี้แจงความเข้าใจผิดทั่วไปเกี่ยวกับภัยคุกคามจากคอมพิวเตอร์ควอนตัมต่อวิทยาการเข้ารหัส รวมถึงการเข้ารหัสลับ การลงนาม และการพิสูจน์ความรู้ศูนย์ และเน้นผลกระทบต่อบล็อกเชนเป็นพิเศษ\n\nเราอยู่ในช่วงไหน?\n\nแม้จะมีการโฆษณามากมาย ความเป็นไปได้ที่จะมีคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัสในศตวรรษนี้ในปี 20 นั้นต่ำมาก\n\nสิ่งที่ผมเรียกว่า “คอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัส” คือ คอมพิวเตอร์ควอนตัมที่สามารถทำงานแบบทนทานและแก้ไขข้อผิดพลาดได้ ซึ่งสามารถรันอัลกอริทึม Shor ในขนาดที่เพียงพอ เพื่อโจมตีเข้ารหัสวงกลมหรือ RSA ได้ในเวลาที่สมเหตุสมผล (เช่น ใช้เวลารวมไม่เกินหนึ่งเดือนในการถอดรหัส secp256k1 หรือ RSA-2048) จากการประมาณการตามเป้าหมายและทรัพยากรที่เปิดเผย เรายังห่างไกลจากการสร้างคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัสอย่างแท้จริง บางบริษัทอ้างว่า CRQC อาจปรากฏก่อนปี 2030 หรือก่อนปี 2035 แต่ความก้าวหน้าที่เปิดเผยแล้วไม่ได้สนับสนุนคำกล่าวเหล่านั้น\n\n\nในภาพรวมของสถาปัตยกรรมปัจจุบัน รวมถึง ion traps, superconductor qubits และระบบอะตอมเป็นกลาง ไม่มีแพลตฟอร์มควอนตัมใดที่ใกล้จะรันอัลกอริทึม Shor เพื่อถอดรหัส RSA-2048 หรือ secp256k1 ด้วยจำนวนควอนตัมบิตที่เป็นฟิสิกส์หลักหมื่นถึงหลักล้าน (ขึ้นอยู่กับอัตราความผิดพลาดและแผนการแก้ไขข้อผิดพลาด) ปัจจัยจำกัดไม่ใช่แค่จำนวนควอนตัมบิต แต่รวมถึงความแม่นยำของเกต การเชื่อมต่อของควอนตัมบิต และความลึกของวงจรแก้ไขข้อผิดพลาดที่จำเป็นในการรันอัลกอริทึมที่ซับซ้อน แม้บางระบบจะมีควอนตัมบิตฟิสิกส์เกิน 1,000 ตัว แต่การมีจำนวนควอนตัมบิตจำนวนมากเพียงอย่างเดียวอาจทำให้เข้าใจผิดได้ ระบบเหล่านี้ขาดความสามารถในการเชื่อมต่อของควอนตัมบิตและความแม่นยำของเกตที่จำเป็นสำหรับการคำนวณที่เกี่ยวข้องกับเข้ารหัส ล่าสุด ระบบกำลังเข้าใกล้จุดที่ความผิดพลาดทางฟิสิกส์เริ่มมีผลกระทบต่อการแก้ไขข้อผิดพลาด แต่ยังไม่มีใครแสดงให้เห็นว่ามีควอนตัมบิตเชิงตรรกะที่มีความลึกของวงจรแก้ไขข้อผิดพลาดต่อเนื่องหลายตัว ซึ่งจำเป็นสำหรับรันอัลกอริทึม Shor จริง ๆ\n\nจากการพิสูจน์ทางทฤษฎีว่าการแก้ไขข้อผิดพลาดควอนตัมเป็นไปได้ จนถึงการบรรลุขนาดที่จำเป็นสำหรับการวิเคราะห์เข้ารหัส ยังมีช่องว่างขนาดใหญ่อยู่ กล่าวโดยสรุป จนกว่าควอนตัมบิตและความแม่นยำจะเพิ่มขึ้นหลายระดับ การสร้างคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัสยังเป็นความฝัน ในข้อมูลที่เปิดเผยแล้ว ไม่สนับสนุนความคาดหวังว่าจะมีคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัสที่สามารถถอด RSA-2048 หรือ secp256k1 ได้ภายใน 5 ปีนี้ สำหรับคำถามที่ว่ารัฐบาลสหรัฐฯ ตั้งเป้าหมายให้ระบบของรัฐบาลทั้งหมดเปลี่ยนเป็นหลังควอนตัมในปี 2035 เป็นเส้นเวลาที่สมเหตุสมผลสำหรับการเปลี่ยนแปลงขนาดใหญ่นี้ แต่ก็ไม่ได้หมายความว่าจะมีคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัสในเวลานั้น\n\nHNDL โจมตีใช้ในสถานการณ์ใด?\n\n"เก็บข้อมูลก่อนถอดรหัส" (HNDL) คือ การโจมตีที่ผู้โจมตีเก็บข้อมูลการรับส่งข้อมูลที่เข้ารหัสไว้ในปัจจุบัน เพื่อรอให้คอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัสปรากฏขึ้น แล้วจึงทำการถอดรหัส ผู้โจมตีระดับชาติแน่ใจว่าได้เก็บข้อมูลการสื่อสารเข้ารหัสจำนวนมากของรัฐบาลสหรัฐฯ เพื่อใช้ในอนาคตเมื่อ CRQC มีอยู่จริง นี่คือเหตุผลที่เทคโนโลยีเข้ารหัสต้องเปลี่ยนไปทันที — อย่างน้อยสำหรับผู้ที่ต้องการความลับนานกว่า 10-50 ปี\n\nแต่ลายเซ็นดิจิทัล (ซึ่งเป็นเทคโนโลยีที่ใช้ในบล็อกเชนทั้งหมด) แตกต่างจากการเข้ารหัส หากคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัสปรากฏขึ้น การปลอมแปลงลายเซ็นก็เป็นไปได้ตั้งแต่จุดนั้น แต่ลายเซ็นในอดีตไม่ได้ “ซ่อน” ความลับเหมือนข้อความเข้ารหัส เพียงแค่คุณรู้ว่าลายเซ็นนั้นสร้างขึ้นก่อน CRQC มันจึงไม่สามารถปลอมแปลงได้ การเปลี่ยนไปใช้ลายเซ็นหลังควอนตัมจึงไม่เร่งด่วนเท่ากับการเปลี่ยนไปใช้การเข้ารหัสหลังควอนตัม\n\nปัจจุบัน แพลตฟอร์มหลักกำลังดำเนินการตามแนวทางนี้: Chrome และ Cloudflare เปิดตัวโซลูชันผสม X25519+ML-KEM สำหรับความปลอดภัยของการส่งข้อมูลบนเครือข่าย; Apple ใช้โปรโตคอล PQ3 ใน iMessage เพื่อใช้งานการเข้ารหัสหลังควอนตัมแบบผสมกัน; Signal ก็ทำเช่นเดียวกันผ่านโปรโตคอล PQXDH และ SPQR\n\nในทางตรงกันข้าม การนำลายเซ็นหลังควอนตัมไปใช้ในโครงสร้างพื้นฐานเครือข่ายสำคัญถูกเลื่อนออกไปจนกว่าคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัสจะใกล้จะปรากฏ เนื่องจากโซลูชันลายเซ็นหลังควอนตัมในปัจจุบันจะทำให้ประสิทธิภาพลดลง (รายละเอียดในภายหลัง)\n\nzkSNARKs (ซึ่งสำคัญต่อความสามารถในการขยายตัวและความเป็นส่วนตัวในระยะยาวของบล็อกเชน) อยู่ในสถานการณ์คล้ายกับลายเซ็น เนื่องจากแม้ zkSNARKs ที่ไม่ปลอดภัยต่อหลังควอนตัม (ใช้เข้ารหัสวงกลม เช่นเดียวกับเทคโนโลยีเข้ารหัสและลายเซ็นในปัจจุบัน) ก็ยังคงมีคุณสมบัติ zero-knowledge ที่ปลอดภัยต่อหลังควอนตัม ความสามารถนี้รับประกันว่าในการพิสูจน์จะไม่มีการเปิดเผยข้อมูลเกี่ยวกับพยานลับ — แม้แต่กับผู้โจมตีควอนตัม — ดังนั้นจึงไม่มีข้อมูลลับที่ “เก็บไว้ก่อน” เพื่อใช้ในอนาคต\n\nดังนั้น zkSNARKs จึงไม่ง่ายต่อการถูกโจมตีด้วย HNDL เช่นเดียวกับลายเซ็นที่สร้างขึ้นในปัจจุบันที่ปลอดภัยจากหลังควอนตัม การพิสูจน์ zkSNARK ที่สร้างขึ้นก่อนการปรากฏของคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัสก็เชื่อถือได้ (คือ ยืนยันว่าข้อความที่พิสูจน์เป็นจริง) แม้จะใช้เข้ารหัสวงกลมก็ตาม เท่านั้นที่เมื่อคอมพิวเตอร์ควอนตัมปรากฏขึ้น ผู้โจมตีจะสามารถหาข้อพิสูจน์ปลอมที่น่าเชื่อถือได้\n\nสิ่งที่บ่งชี้ต่อบล็อกเชนคืออะไร?\n\nบล็อกเชนส่วนใหญ่ไม่เสี่ยงต่อ HNDL: บล็อกเชนที่ไม่เน้นความเป็นส่วนตัว (เช่น บิตคอยน์และอีเธอร์เรียมในปัจจุบัน) ใช้การอนุญาตธุรกรรมด้วยเทคโนโลยีเข้ารหัสลับแบบไม่ปลอดภัยต่อหลังควอนตัม กล่าวคือ ใช้ลายเซ็นดิจิทัล แทนการเข้ารหัส ขอย้ำอีกครั้ง ลายเซ็นเหล่านี้ไม่เสี่ยงต่อ HNDL: HNDL เหมาะกับข้อมูลที่เข้ารหัส เช่น บล็อกเชนของบิตคอยน์เป็นสาธารณะ ภัยคุกคามจากควอนตัมอยู่ที่การปลอมแปลงลายเซ็น (การคำนวณหากุญแจส่วนตัวเพื่อขโมยเงิน) ไม่ใช่การถอดรหัสข้อมูลธุรกรรมที่เปิดเผยแล้ว ซึ่งลดความเร่งด่วนของความกดดันด้านเทคโนโลยีเข้ารหัส\n\nน่าเสียดาย แม้แต่การวิเคราะห์จากแหล่งเชื่อถือ เช่น ธนาคารกลางสหรัฐฯ ก็อ้างผิดว่าบิตคอยน์เสี่ยงต่อ HNDL ซึ่งเป็นการเกินความเป็นจริงของความเร่งด่วนในการเปลี่ยนไปใช้หลังควอนตัม แน่นอนว่าความเร่งด่วนลดลง แต่บิตคอยน์ก็ยังต้องเผชิญกับแรงกดดันจากการเปลี่ยนแปลงโปรโตคอลที่ต้องการความร่วมมือทางสังคมอย่างมาก (รายละเอียดความท้าทายเฉพาะของบิตคอยน์อยู่ด้านล่าง)\n\nข้อยกเว้นในปัจจุบันคือบล็อกความเป็นส่วนตัว ซึ่งหลายสายพันธุ์จะเข้ารหัสหรือซ่อนผู้รับและจำนวนเงินไว้ การรักษาความลับนี้สามารถถูกเก็บรวบรวมได้ในปัจจุบัน เมื่อคอมพิวเตอร์ควอนตัมสามารถถอดรหัสเข้ารหัสวงกลม ก็สามารถย้อนรอยเพื่อทำการลบการไม่ระบุตัวตนได้\n\nสำหรับบล็อกความเป็นส่วนตัว การโจมตีมีความรุนแรงแตกต่างกันไปตามการออกแบบของบล็อกเชน เช่น สำหรับ Monero ที่ใช้ ring signatures และ key images (ซึ่งใช้เพื่อป้องกัน double-spending) เพียงแค่ดูบันทึกสาธารณะก็สามารถย้อนรอยสร้างแผนผังการใช้จ่ายได้ แต่ในบล็อกอื่น ความเสียหายอาจจำกัดมากกว่า — ดูรายละเอียดจาก Sean Bowe นักวิจัยด้านเข้ารหัสของ Zcash\n\nหากผู้ใช้คิดว่าสำคัญที่ธุรกรรมของตนจะไม่ถูกเปิดเผยต่อคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัส ควรเปลี่ยนไปใช้หลังควอนตัมเร็วที่สุด (หรือใช้แบบผสม) หรือออกแบบโครงสร้างที่หลีกเลี่ยงการเก็บข้อมูลลับที่สามารถถอดรหัสได้บนบล็อก\n\nปัญหาเฉพาะของบิตคอยน์: การบริหารและเหรียญที่ถูกทิ้ง\n\nสำหรับบิตคอยน์ สองสถานการณ์ที่ผลักดันให้เริ่มเปลี่ยนไปใช้ลายเซ็นหลังควอนตัมอย่างเร่งด่วนคือ สองสิ่งนี้ไม่ได้เกี่ยวข้องกับเทคโนโลยีควอนตัมโดยตรง:\n\nอันดับแรกคือ ความช้าในการบริหาร: บิตคอยน์เปลี่ยนแปลงช้า หากชุมชนไม่สามารถตกลงกันได้ในแนวทางแก้ไขที่เหมาะสม ปัญหาที่มีความขัดแย้งอาจนำไปสู่การ fork ที่เป็นอันตราย\n\nประการที่สอง การเปลี่ยนไปใช้ลายเซ็นหลังควอนตัมของบิตคอยน์ต้องเป็นการเปลี่ยนแปลงโดยสมัครใจ: เจ้าของต้องย้ายเหรียญของตนเอง ซึ่งหมายความว่าเหรียญที่ถูกทิ้งและเสี่ยงต่อการโจมตีด้วยควอนตัมจะไม่ได้รับการปกป้อง คาดว่ามีจำนวนเหรียญที่เสี่ยงต่อการถูกโจมตีด้วยควอนตัมและอาจถูกทิ้งจำนวนหลายล้านเหรียญ\n\nแต่ภัยคุกคามจากควอนตัมต่อบิตคอยน์จะไม่เป็นการโจมตีฉับพลันหรือจบสิ้นในคืนเดียว แต่เป็นกระบวนการที่ค่อยเป็นค่อยไปและเลือกเป้าหมาย: คอมพิวเตอร์ควอนตัมจะไม่สามารถถอดรหัสทุกการเข้ารหัสพร้อมกันได้ อัลกอริทึม Shor ต้องโจมตีทีละกุญแจสาธารณะ การโจมตีในระยะเริ่มต้นจะมีค่าใช้จ่ายสูงและช้า ดังนั้น เมื่อคอมพิวเตอร์ควอนตัมสามารถถอดรหัสกุญแจลายเซ็นของบิตคอยน์ได้ในที่สุด ผู้โจมตีจะเลือกโจมตีเฉพาะเหรียญที่มีมูลค่าสูง\n\nนอกจากนี้ ผู้ใช้ที่หลีกเลี่ยงการใช้ address ซ้ำและไม่ใช้ Taproot address (ซึ่งเปิดเผยกุญแจสาธารณะบนบล็อกโดยตรง) ก็จะได้รับการป้องกันในระดับหนึ่งโดยไม่ต้องเปลี่ยนโปรโตคอล: กุญแจสาธารณะของพวกเขาจะซ่อนอยู่หลัง hash จนกว่าจะใช้จ่าย เมื่อพวกเขาส่งธุรกรรมออกไป กุญแจสาธารณะจะปรากฏขึ้นในเวลาสั้น ๆ ซึ่งจะเป็นการแข่งขันแบบเรียลไทม์: ฝ่ายที่ซื่อสัตย์ต้องการให้ธุรกรรมได้รับการยืนยัน ในขณะที่ผู้โจมตีที่มีอุปกรณ์ควอนตัมหวังจะหา private key ก่อนการยืนยันของเจ้าของจริง เพื่อใช้จ่ายเหรียญ เหรียญที่เสี่ยงต่อการโจมตีคือเหรียญที่กุญแจสาธารณะเปิดเผยแล้ว เช่น UTXO แบบ P2PK, address ที่ซ้ำกัน และเหรียญใน Taproot\n\nสำหรับเหรียญที่ถูกทิ้งและเสี่ยงต่อการโจมตี ไม่มีวิธีแก้ไขง่ายๆ ตัวเลือกบางอย่างคือ:\n\n- ชุมชนบิตคอยน์กำหนด “วันสุดท้าย” หลังจากนั้นเหรียญที่ไม่ได้เปลี่ยนจะถูกประกาศว่าสูญหาย\n- ให้เหรียญที่เสี่ยงต่อการโจมตีด้วยควอนตัมถูกแย่งชิงโดยผู้ที่มีคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัส\n\nตัวเลือกที่สองจะก่อให้เกิดปัญหาทางกฎหมายและความปลอดภัยอย่างรุนแรง การใช้คอมพิวเตอร์ควอนตัมเพื่อยึดครองเหรียญโดยไม่มี private key แม้จะอ้างว่ามีสิทธิ์ถูกต้องตามกฎหมายหรือมีเจตนาดี ก็อาจถูกดำเนินคดีในหลายเขตอำนาจศาลในฐานะการโจรกรรมและการฉ้อโกงคอมพิวเตอร์\n\nนอกจากนี้ “การทิ้ง” ยังเป็นการสมมุติฐานจากการไม่เคลื่อนไหว แต่ไม่มีใครรู้แน่ชัดว่าเหรียญเหล่านั้นไม่มีเจ้าของที่ยังมีชีวิตอยู่ การพิสูจน์ว่าคุณเคยเป็นเจ้าของเหรียญเหล่านั้นอาจไม่เพียงพอที่จะให้สิทธิ์ทางกฎหมายในการปลดล็อกเข้ารหัสและกู้คืนเหรียญ ความไม่ชัดเจนทางกฎหมายนี้เพิ่มความเสี่ยงที่เหรียญที่ถูกทิ้งอาจตกอยู่ในมือของผู้ไม่หวังดีที่ไม่สนใจกฎหมาย\n\nปัญหาเฉพาะของบิตคอยน์อีกประการคือ ความสามารถในการทำธุรกรรมต่ำ แม้แผนการเปลี่ยนผ่านจะเสร็จสมบูรณ์ การย้ายเงินจำนวนหลายพันล้านเหรียญไปยังที่อยู่ที่ปลอดภัยต่อควอนตัมในปัจจุบันอาจใช้เวลาหลายเดือน\n\nความท้าทายเหล่านี้ทำให้การวางแผนเปลี่ยนผ่านหลังควอนตัมของบิตคอยน์ตั้งแต่ตอนนี้เป็นสิ่งสำคัญ — ไม่ใช่เพราะคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัสอาจปรากฏก่อนปี 2030 แต่เพราะการเปลี่ยนย้ายเหรียญมูลค่าหลายพันล้านดอลลาร์ต้องใช้เวลาในการบริหาร จัดการ และเทคนิคอีกหลายปี\n\nภัยคุกคามจากควอนตัมต่อบิตคอยน์เป็นความจริง แต่เป็นเรื่องของเวลาที่เกิดจากข้อจำกัดของบิตคอยน์เอง ไม่ใช่จากคอมพิวเตอร์ควอนตัมที่กำลังจะมา แพลตฟอร์มบล็อกเชนอื่นก็เผชิญความท้าทายเช่นกัน แต่ความเสี่ยงของบิตคอยน์โดดเด่นมากขึ้น: การทำธุรกรรมในช่วงแรกจะเปิดเผยกุญแจสาธารณะโดยตรง ทำให้เหรียญจำนวนมากเสี่ยงต่อการโจมตีด้วยคอมพิวเตอร์ควอนตัม ความแตกต่างทางเทคนิคนี้ รวมกับประวัติศาสตร์อายุยาวของบิตคอยน์ การกระจุกตัวของมูลค่า ความสามารถในการทำธุรกรรมต่ำ และการบริหารจัดการที่แข็งทื่อ ทำให้ปัญหานี้รุนแรงเป็นพิเศษ\n\nโปรดทราบว่า คำอธิบายช่องโหว่ข้างต้นเป็นการวิเคราะห์ด้านความปลอดภัยของลายเซ็นดิจิทัลในบิตคอยน์ ไม่ใช่ความปลอดภัยทางเศรษฐกิจของบล็อกเชน ความปลอดภัยทางเศรษฐกิจนี้มาจากกลไกฉันทามติ Proof of Work ซึ่งมีข้อดีสามประการที่ทำให้ไม่ง่ายต่อการโจมตีด้วยคอมพิวเตอร์ควอนตัม:\n\n- PoW พึ่งพาการคำนวณแฮช จึงได้รับผลกระทบจากการเร่งความเร็วด้วยอัลกอริทึม Grover เป็นกำลังสองเท่านั้น ไม่ใช่การเร่งความเร็วเชิงเลขยกกำลังของ Shor\n- ค่าใช้จ่ายในการดำเนินการค้นหา Grover ทำให้เป็นไปไม่ได้ที่คอมพิวเตอร์ควอนตัมจะเร่งความเร็วในกลไก Proof of Work ของบิตคอยน์อย่างมีนัยสำคัญในโลกจริง\n- แม้จะมีการเร่งความเร็วอย่างมาก การเร่งนี้ก็จะทำให้เหมืองขนาดใหญ่ได้เปรียบเมื่อเทียบกับเหมืองขนาดเล็กเท่านั้น และไม่ทำลายความปลอดภัยทางเศรษฐกิจโดยรากฐาน\n\nหลังควอนตัมลายเซ็น: ต้นทุนและความเสี่ยง\n\nเพื่อให้เข้าใจว่าทำไมบล็อกเชนไม่ควรเร่งด่วนในการใช้งานลายเซ็นหลังควอนตัม เราต้องเข้าใจต้นทุนด้านประสิทธิภาพและความเชื่อมั่นในความปลอดภัยที่ยังอยู่ในระหว่างการพัฒนา\n\nลายเซ็นหลังควอนตัมส่วนใหญ่อิงบนห้าหลักการ: hash, coding, lattice, MQ, และ homomorphic วิธีการเข้ารหัสใดๆ ที่ปลอดภัยต่อหลังควอนตัมจะอิงบนสมมุติฐานว่า คอมพิวเตอร์ควอนตัมไม่สามารถแก้โจทย์ทางคณิตศาสตร์เฉพาะทางได้อย่างมีประสิทธิภาพ ยิ่งโครงสร้างของปัญหามีความซับซ้อนมากเท่าไร ก็สามารถสร้างโปรโตคอลเข้ารหัสที่มีประสิทธิภาพสูงขึ้นเท่านั้น แต่ก็มีข้อเสีย: โครงสร้างที่มากขึ้นก็เปิดช่องโหว่ให้กับการโจมตีมากขึ้นเช่นกัน ความสมดุลนี้เป็นความขัดแย้งพื้นฐาน — สมมุติฐานที่แข็งแกร่งขึ้นให้ประสิทธิภาพดีขึ้น แต่ก็เสี่ยงต่อความปลอดภัยมากขึ้น\n\nโดยทั่วไป วิธีการอิง hash มีความปลอดภัยที่สุดในแง่ความเชื่อมั่น เพราะเรามั่นใจว่าคอมพิวเตอร์ควอนตัมจะไม่สามารถโจมตีได้อย่างมีประสิทธิภาพ แต่ประสิทธิภาพก็แย่ที่สุด เช่น ลายเซ็นที่เป็นมาตรฐานของ NIST ที่ใช้ hash ขนาดต่ำสุดก็ยังมีขนาด 7-8 กิโลไบต์ ในขณะที่ลายเซ็นวงกลมแบบ elliptic curve ในปัจจุบันมีเพียง 64 ไบต์ ซึ่งต่างกันประมาณ 100 เท่า\n\nกลุ่ม lattice เป็นเป้าหมายหลักของการพัฒนามาตรฐานในปัจจุบัน NIST ได้เลือกแผนมาตรฐานเดียวและสองในสามของอัลกอริทึมลายเซ็นที่เป็นมาตรฐานเป็นแบบ lattice หนึ่งในนั้นคือ ML-DSA (เดิมชื่อ Dilithium) ซึ่งสร้างลายเซ็นขนาดตั้งแต่ 2.4 KB (ระดับความปลอดภัย 128 บิต) ถึง 4.6 KB (ระดับความปลอดภัย 256 บิต) ซึ่งใหญ่กว่าลายเซ็นแบบ elliptic curve ประมาณ 40-70 เท อีกแบบคือ Falcon ซึ่งมีขนาดลายเซ็นเล็กกว่า (Falcon-512 666 ไบต์, Falcon-1024 1.3 KB) แต่มีความซับซ้อนด้านคณิตศาสตร์และการคำนวณฟลอตต์ ซึ่ง NIST จัดเป็นความท้าทายด้านการนำไปใช้งาน หนึ่งในผู้สร้าง Falcon คือ Thomas Pornin เรียกมันว่า “อัลกอริทึมเข้ารหัสที่ซับซที่สุดที่ผมเคยสร้าง” \n\nเมื่อเทียบกับลายเซ็นแบบ elliptic curve แบบเดิม กลุ่ม lattice ก็มีความท้าทายด้านความปลอดภัยเช่นกัน เช่น ML-DSA มีค่าที่อ่อนไหวต่อความผิดพลาดและมีตรรกะการปฏิเสธที่ซับซ้อน ต้องการการป้องกันด้านช่องโหว่และความผิดพลาด Falcon ก็เพิ่มความกังวลด้านการคำนวณแบบคงที่เวลา ซึ่งมีการโจมตีด้วยช่องโหว่ด้านความปลอดภัยแล้วหลายครั้ง\n\nปัญหาเหล่านี้เป็นความเสี่ยงโดยตรง แตกต่างจากภัยคุกคามจากคอมพิวเตอร์ควอนตัมที่อยู่ไกลออกไป\n\nในขณะที่การนำเทคนิคเข้ารหัสหลังควอนตัมที่มีประสิทธิภาพสูงมาใช้ ควรระมัดระวังอย่างมาก ในประวัติศาสตร์ โซลูชันชั้นนำเช่น Rainbow (ลายเซ็น MQ) และ SIKE/SIDH (เข้ารหัสแบบ homomorphic) ถูกแฮกโดยคอมพิวเตอร์คลาสสิกแล้ว — ไม่ใช่โดยคอมพิวเตอร์ควอนตัม การแฮกเหล่านี้เกิดขึ้นในช่วงที่กระบวนการมาตรฐานของ NIST อยู่ในขั้นตอนลึก นี่เป็นการแสดงให้เห็นว่าการมาตรฐานและการใช้งานล่วงหน้าอาจเป็นอันตราย\n\nอย่างที่กล่าวไว้ โครงสร้างพื้นฐานอินเทอร์เน็ตกำลังดำเนินการเปลี่ยนแปลงอย่างระมัดระวังในการเปลี่ยนแปลงลายเซ็น เมื่อพิจารณาว่า การเปลี่ยนแปลงในโครงสร้างพื้นฐานของอินเทอร์เน็ตใช้เวลานานเท่าไร ตั้งแต่การเปลี่ยนจาก MD5 และ SHA-1 ซึ่งถูกเลิกใช้ในเชิงเทคนิคหลายปีก่อนแล้ว แต่ก็ยังใช้ในโครงสร้างพื้นฐานบางแห่งอยู่ การเปลี่ยนแปลงเหล่านี้ใช้เวลานานกว่าหลายปี แม้จะถูกแฮกแล้วก็ตาม\n\nความท้าทายเฉพาะของบล็อกเชนเมื่อเทียบกับโครงสร้างพื้นฐานของอินเทอร์เน็ต\n\nโชคดีที่บล็อกเชนโอเพนซอร์ส เช่น Ethereum หรือ Solana ซึ่งได้รับการบำรุงรักษาโดยชุมชน สามารถอัปเกรดได้เร็วกว่าโครงสร้างพื้นฐานแบบดั้งเดิม ในทางตรงกันข้าม โครงสร้างพื้นฐานแบบดั้งเดิมได้ประโยชน์จากการเปลี่ยนกุญแจบ่อย ซึ่งทำให้พื้นที่โจมตีเคลื่อนที่เร็วกว่าเทคโนโลยีควอนตัมในระยะเริ่มต้น ซึ่งเป็นข้อได้เปรียบของบล็อกเชน เพราะเหรียญและกุญแจที่เกี่ยวข้องอาจเปิดเผยได้ไม่มีกำหนด\n\nแต่โดยรวมแล้ว บล็อกเชนควรปฏิบัติตามแนวทางระมัดระวังของเครือข่ายในการเปลี่ยนแปลงลายเซ็น ทั้งสองไม่เสี่ยงต่อ HNDL และไม่ว่าจะกุญแจจะคงอยู่กี่นาน การเปลี่ยนไปใช้เทคโนโลยีหลังควอนตัมที่ยังไม่สมบูรณ์ก็มีต้นทุนและความเสี่ยงสูง\n\nความท้าทายเฉพาะของบล็อกเชนยังทำให้การเปลี่ยนแปลงล่วงหน้าเป็นอันตรายและซับซ้อน เช่น ความสามารถในการรวมลายเซ็นหลายอันอย่างรวดเร็ว ซึ่งเป็นเหตุผลที่ใช้ BLS ในปัจจุบันเพราะสามารถรวมกันได้อย่างรวดเร็ว แต่ไม่ปลอดภัยต่อหลังควอนตัม นักวิจัยกำลังสำรวจการรวมลายเซ็นแบบ SNARK ซึ่งมีแนวโน้มดี แต่ยังอยู่ในระยะเริ่มต้น\n\nสำหรับ SNARKs ชุมชนปัจจุบันเลือกใช้โครงสร้างแบบ hash เป็นทางเลือกหลักสำหรับหลังควอนตัม แต่ในอีกไม่กี่เดือนหรือหลายปีข้างหน้า คาดว่ากลุ่มแบบ lattice จะกลายเป็นทางเลือกที่น่าสนใจ เนื่องจากประสิทธิภาพดีกว่า เช่น ขนาดของการพิสูจน์จะสั้นลงมาก — คล้ายกับลายเซ็นแบบ lattice ที่สั้นกว่าลายเซ็นแบบ hash มาก\n\nปัญหาใหญ่ในปัจจุบัน: ความปลอดภัยในการดำเนินงาน\n\nในอีกไม่กี่ปีข้างหน้า ความเสี่ยงด้านช่องโหว่ในการดำเนินงานจะมีมากกว่าความเสี่ยงจากคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัส สำหรับ SNARKs ความกังวลหลักคือช่องโหว่\n\nช่องโหว่เป็นความท้าทายที่เกิดขึ้นในลายเซ็นและการเข้ารหัสแบบดั้งเดิม และ SNARKs ก็ซับซ้อนขึ้นอีกระดับ หนึ่งในความเสี่ยงคือ การโจมตีด้านช่องโหว่ เช่น side-channel และ fault injection ซึ่งสามารถดึงกุญแจออกจากระบบที่ใช้งานอยู่ได้ ซึ่งเป็นภัยคุกคามที่มีความเร่งด่วนมากกว่าความเสี่ยงจากคอมพิวเตอร์ควอนตัมในอนาคต\n\nชุมชนจะใช้เวลาหลายปีในการระบุและซ่อมแซมช่องโหว่ใน SNARKs และเสริมความแข็งแกร่งให้กับการดำเนินงานของลายเซ็นหลังควอนตัม เพื่อป้องกันการโจมตีด้านช่องโหว่และ fault injection เนื่องจากยังไม่มีการตัดสินใจสุดท้ายเกี่ยวกับ SNARKs และการรวมลายเซ็น การเปลี่ยนแปลงล่วงหน้าของบล็อกเชนอาจทำให้ติดอยู่ในทางเลือกรอง ซึ่งอาจต้องเปลี่ยนอีกครั้งเมื่อมีทางเลือกที่ดีกว่าหรือพบช่องโหว่\n\nเราควรทำอย่างไร? คำแนะนำ 7 ข้อ\n\nจากสถานการณ์ที่อธิบายข้างต้น ผมจะสรุปคำแนะนำสำหรับผู้มีส่วนได้ส่วนเสียต่างๆ หลักการสำคัญคือ: ให้ความสำคัญกับภัยคุกคามจากควอนตัมอย่างจริงจัง แต่ไม่ควรดำเนินการโดยอิงกับสมมุติฐานว่าคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัสจะปรากฏก่อนปี 2030 การพัฒนาปัจจุบันยังไม่สนับสนุนสมมุติฐานนี้ แต่เรายังมีสิ่งที่ทำได้และควรทำ:\n\n- ควรดำเนินการใช้งานการเข้ารหัสแบบผสมทันที หรืออย่างน้อยในพื้นที่ที่ความลับระยะยาวมีความสำคัญและต้นทุนยอมรับได้ หลายเบราว์เซอร์ CDN และแอปส่งข้อความ (เช่น iMessage และ Signal) ได้ใช้งานวิธีผสมแล้ว วิธีผสม (หลังควอนตัม + คลาสสิก) ช่วยป้องกัน HNDL และลดจุดอ่อนในโซลูชันหลังควอนตัม\n\n- ในกรณีที่ยอมรับได้ ควรใช้ลายเซ็นแบบ hash ทันที การอัปเดตซอฟต์แวร์/เฟิร์มแวร์ และสถานการณ์ที่ไม่บ่อยและไม่ขึ้นกับขนาดในตอนนี้ ควรใช้ลายเซ็นแบบ hash แบบผสม (เพื่อป้องกันช่องโหว่ในการนำไปใช้ในโซลูชันใหม่ ไม่ใช่เพราะสงสัยในความปลอดภัยของ hash) วิธีนี้เป็นแนวทางอนุรักษ์นิยม และให้ “เรือประตูฉุกเฉิน” สำหรับสังคม หากเกิดคอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับเข้ารหัสอย่างรวดเร็วและไม่คาดคิด หากไม่มีการอัปเดตซอฟต์แวร์ลายเซ็นหลังควอนตัมที่พร้อมใช้งาน เราจะไม่สามารถแจกจ่ายการแก้ไขด้านความปลอดภัยที่ต้านทานได้อย่างปลอดภัย\n\n- บล็อกเชนไม่จำเป็นต้องรีบใช้งานลายเซ็นหลังควอนตัม แต่ควรเริ่มวางแผนตอนนี้ ชุมชนพัฒนาบล็อกเชนควรปฏิบัติตามแนวทางของชุมชน PKI ของเครือข่ายอย่างระมัดระวัง เพื่อให้ลายเซ็นหลังควอนตัมมีความสมบูรณ์ด้านประสิทธิภาพและความเข้าใจด้านความปลอดภัยที่พัฒนาขึ้นอย่างต่อเนื่อง วิธีนี้ยังเปิดโอกาสให้พัฒนาระบบใหม่เพื่อรองรับลายเซ็นที่มีขนาดใหญ่ขึ้น และเทคนิคการรวมลายเซ็นที่ดีขึ้น\n\n- สำหรับ Bitcoin และ Layer 1 อื่นๆ: ชุมชนต้องวางแผนเส้นทางและนโยบายสำหรับเหรียญที่ถูกทิ้งและเสี่ยงต่อการโจมตีด้วยควอนตัม การเปลี่ยนแปลงโดยไม่วางแผนเป็นไปไม่ได้ ดังนั้น การวางแผนจึงสำคัญมาก และเนื่องจากความท้าทายหลักของ Bitcoin คือปัญหาทางการเมือง เช่น การบริหารที่ช้า และจำนวนเหรียญที่มีมูลค่าสูงและอาจถูกทิ้ง การเริ่มวางแผนตอนนี้จึงเป็นเรื่องสำคัญ\n\n- ในขณะเดียวกัน ควรสนับสนุนการวิจัยด้าน SNARKs และลายเซ็นแบบรวมกันให้เติบโต (อาจใช้เวลาหลายปี) การเปลี่ยนแปลงล่วงหน้าอาจทำให้ติดอยู่ในทางเลือกรอง หรือพบช่องโหว่ในการดำเนินงานเมื่อมีทางเลือกที่ดีกว่า\n\n- สำหรับโมเดลบัญชีของ Ethereum: Ethereum รองรับสองประเภทบัญชี (บัญชีเจ้าของภายนอก EOA ซึ่งควบคุมโดย secp256k1 private key และกระเป๋าเงินสมาร์ทคอนแทรกต์ที่มีตรรกะการอนุญาตแบบโปรแกรมได้) ซึ่งมีผลต่อการเปลี่ยนผ่านหลังควอนตัม ในกรณีฉุกเฉิน หาก Ethereum เพิ่มการสนับสนุนลายเซ็นหลังควอนตัม กระเป๋าเงินสมาร์ทคอนแทรกต์ที่สามารถอัปเกรดได้สามารถเปลี่ยนเป็นการตรวจสอบหลังควอนตัมผ่านการอัปเกรดสัญญา ในขณะที่ EOA อาจต้องย้ายเหรียญไปยังที่อยู่ปลอดภัยต่อควอนตัมใหม่ (แม้ Ethereum อาจมีกลไกการเปลี่ยนผ่านเฉพาะสำหรับ EOA) ในกรณีฉุกเฉิน นักวิจัย Ethereum เสนอแผน fork เพื่อหยุดบัญชีที่เสี่ยงต่อการโจมตี และให้ผู้ใช้พิสูจน์ว่ารู้ mnemonic ด้วย SNARKs หลังควอนตัม ซึ่งจะใช้ได้กับทั้ง EOA และกระเป๋าเงินสมาร์ทคอนแทรกต์ที่ยังไม่ได้อัปเกรด\n\n- ผลกระทบต่อผู้ใช้: กระเป๋าเงินสมาร์ทคอนแทรกต์ที่ได้รับการตรวจสอบและสามารถอัปเกรดได้อาจให้เส้นทางเปลี่ยนผ่านที่ราบรื่นขึ้น แต่ก็ยังมีข้อควรระวังในเรื่องความเชื่อมั่นใน