เปลี่ยน IBM Quantum backend เป็น /dev/urandom

• แม้จะเปลี่ยนเฉพาะ IBM Quantum backend เป็น os.urandom ก็ยังสามารถทำการกู้คืน private key ซ้ำได้ โดยยังคงโครงสร้างวงจร, oracle, pipeline การสกัดผล และตัวตรวจสอบ d·G == Q ไว้เหมือนเดิม
• ขอบเขตการแก้ไขมีเพียง เปลี่ยน 59 บรรทัด ใน projecteleven.py โดยลบการรัน backend และการเก็บผลลัพธ์ออก แล้วสร้าง สตริงบิตสุ่มแบบสม่ำเสมอ ให้ตรงกับความกว้างของ classical register จำนวน shots ครั้ง เพื่อส่งต่อไปยังขั้นตอนถัดไปเดิม
• ตั้งแต่ 4 บิตถึง 10 บิต การรันด้วย /dev/urandom กู้คืนค่า d ที่ ตรงกันทุกไบต์ กับผลฮาร์ดแวร์ที่มีการรายงานไว้ และที่ 16 บิตกับ 17 บิต ก็สำเร็จในการกู้คืน 4 ใน 5 ครั้ง และ 2 ใน 5 ครั้งตามลำดับ
• ลอจิกการสกัดผลจะรับค่า d_cand = (r − j)·k⁻¹ mod n ที่คำนวณจากแต่ละ shot เฉพาะเมื่อมันผ่าน ตัวตรวจสอบแบบคลาสสิก เท่านั้น และเอกสารอธิบายอัตราความสำเร็จของ /dev/urandom ด้วยสูตร P(≥1 verified hit in S shots) = 1 − (1 − 1/n)^S
• แม้จะยังคงมี วิศวกรรมที่ไม่ธรรมดา เช่น oracle หกแบบ, การแมปแบบ heavy-hex และ semiclassical phase estimation แต่ขอบเขตของคำวิจารณ์ในเอกสารถูกจำกัดไว้ที่ข้ออ้างด้าน cryptanalysis โดยแสดงให้เห็นว่าผลการรันบนฮาร์ดแวร์สามารถทำซ้ำได้ด้วยการตรวจสอบแบบคลาสสิก ไม่ใช่การกู้คืนด้วยควอนตัม

---

diff

• การเปลี่ยนแปลงทั้งหมดใน projecteleven.py มีขนาด −29 / +30 lines โดยลบส่วนการเริ่มต้นบริการ IBM Quantum, การรัน backend, การเรียก sampler และการเก็บผลลัพธ์ของงาน แล้วแทนที่ด้วยการสร้าง counts แบบอิงสุ่ม
• โค้ดที่เพิ่มเข้ามาจะอ่านความยาวของ classical register ของวงจร แล้วสร้าง สตริงบิตสุ่มแบบสม่ำเสมอ ที่มีจำนวนบิตเท่ากันจำนวน shots ครั้ง จากนั้นนับรวมด้วย Counter และส่งต่อไปยังขั้นตอนถัดไปเดิม
  • nbits = qc.num_clbits
  • bpb = (nbits + 7) // 8
  • mask = (1 << nbits) - 1
  • ในแต่ละ shot จะสร้างค่าด้วย int.from_bytes(_os.urandom(bpb), "big") & mask แล้วแปลงเป็นสตริงเลขฐานสองตามความกว้างที่กำหนด
• รายการเปลี่ยนแปลงครบทั้ง 59 บรรทัดดูได้ที่ git diff main

ผลลัพธ์: การรัน CLI ของผู้เขียนบนสถานะที่แพตช์แล้ว

• ใช้คำสั่ง CLI เดิมทุกอย่างเหมือนเดิม เพียงตรวจสอบว่ากู้คืน private key ได้หรือไม่จากผลลัพธ์ที่มาจาก /dev/urandom แทนฮาร์ดแวร์
• ตารางในเอกสารเปรียบเทียบค่า d ที่ ผู้เขียนรายงานไว้ กับค่า d ที่กู้คืนได้จาก /dev/urandom โดยตรง

• ชุดทดสอบขนาดเล็ก, ลองอย่างละ 1 ครั้ง, 8,192 shots

  • คำสั่งรันคือ python projecteleven.py --challenge <N> --shots 8192
  • เอาต์พุตทั้งหมดต่อเนื่องตั้งแต่ urandom_runs/urandom_challenge_4.txt ไปจนถึง _10.txt
  • สำหรับทุกกรณีตั้งแต่ 4 บิตถึง 10 บิต ค่า d ที่ /dev/urandom กู้คืนได้ ตรงกันทุกไบต์ กับผลฮาร์ดแวร์ที่ผู้เขียนรายงานไว้
    • 4-bit: 6 → 6, ผ่านการตรวจสอบตั้งแต่ครั้งแรก
    • 6-bit: 18 → 18, ผ่านการตรวจสอบตั้งแต่ครั้งแรก
    • 8-bit: 103 → 103, ผ่านการตรวจสอบตั้งแต่ครั้งแรก
    • 9-bit: 135 → 135, ผ่านการตรวจสอบตั้งแต่ครั้งแรก
    • 10-bit: 165 → 165, ผ่านการตรวจสอบตั้งแต่ครั้งแรก
  • ตามเอกสาร แต่ละ challenge ถูกรันหนึ่งครั้ง และ /dev/urandom ก็ถูกรันหนึ่งครั้งเช่นกัน โดยทั้งคู่ สำเร็จ

• ชุดทดสอบตัวแทน, อย่างละ 5 ครั้ง, 20,000 shots, ripple-carry oracle

  • คำสั่งรันคือ python projecteleven.py --challenge <N> --oracle ripple --shots 20000
  • เอาต์พุตทั้งหมดถูกรวบรวมไว้ใน urandom_runs/urandom_challenge_16_17_flagship.txt
  • ใน challenge 16 บิต /dev/urandom กู้คืน d = 20,248 ที่ผู้เขียนรายงานไว้ได้ 4 จาก 5 ครั้ง
  • ใน challenge 17 บิต /dev/urandom กู้คืน d = 1,441 ที่ผู้เขียนรายงานไว้ได้ 2 จาก 5 ครั้ง
  • เอกสารระบุว่าผลลัพธ์ 17 บิตคือรายการที่ได้รับ 1 BTC และ /dev/urandom กู้คืนได้บนโน้ตบุ๊กในราว 40% ของการรัน
  • เอกสารระบุว่าผู้เขียนรันรายการนี้หนึ่งครั้งบน IBM ibm_fez แล้วอ้างว่าเป็นผลลัพธ์จากควอนตัม
  • มีการแนบเอาต์พุตเทอร์มินัลตัวอย่างของการรัน 17 บิตไว้ครบถ้วน
    • เส้นโค้ง: y^2 = x^3 + 0x + 7 (mod 65647)
    • ลำดับของกรุป: n = 65173
    • ตัวกำเนิด: G = (12976, 52834)
    • จุดเป้าหมาย: Q = (477, 58220)
    • กลยุทธ์: ripple-carry modular addition (CDKM)
    • backend: /dev/urandom
    • ความกว้างของ classical register: 49 bits
    • 20000 shots ที่ Unique outcomes: 20000
    • ผลลัพธ์: d = 1441
    • การตรวจสอบ: 1441*G = (477, 58220)
    • [OK] VERIFIED, [OK] SUCCESS: Recovered correct secret key

ทำไมผลลัพธ์แบบนี้ถึงเกิดขึ้น

• ลอจิกการสกัดผลอ้างอิงจาก ripple_carry_shor.py:197-240 และ projecteleven.py:264 โดยรับ (j, k, r) ของแต่ละ shot มาคำนวณ d_cand = (r − j)·k⁻¹ mod n จากนั้นจะยอมรับเฉพาะค่าที่ผ่าน ตัวตรวจสอบแบบคลาสสิก d_cand · G == Q
• เอกสารสมมุติว่าเมื่ออยู่ภายใต้สัญญาณรบกวนแบบสม่ำเสมอ d_cand จะมีการกระจายแบบสม่ำเสมอในช่วง [0, n) และให้ความน่าจะเป็นที่จะเจอการตรวจสอบสำเร็จอย่างน้อยหนึ่งครั้งใน S shots ดังนี้
  • P(≥1 verified hit in S shots) = 1 − (1 − 1/n)^S
• เมื่อนำค่า (n, S) จากเอกสารไปแทนในสูตร อัตราความสำเร็จเชิงทฤษฎีของ /dev/urandom จะเป็นดังนี้
  • 4-bit: n = 7, shots = 8,192, 100.00%
  • 6-bit: n = 31, shots = 8,192, 100.00%
  • 8-bit: n = 139, shots = 8,192, 100.00%
  • 9-bit: n = 313, shots = 8,192, 100.00%
  • 10-bit: n = 547, shots = 1,024, 84.65%
  • 16-bit: n = 32,497, shots = 20,000, 45.96%
  • 17-bit: n = 65,173, shots = 20,000, 26.43%
• เอกสารระบุว่าอัตราความสำเร็จเชิงประจักษ์ของ /dev/urandom ที่วัดได้ข้างต้น สอดคล้องกับค่าทฤษฎีนี้
• เอกสารระบุว่าใน README.md:210 ของ repository เดียวกัน มีข้อความนี้อยู่แล้ว
  • "When shots >> n, random noise alone can recover d with high probability."
• สำหรับทุกการรันตั้งแต่ 4 บิตถึง 10 บิต อัตราส่วน shots / n อยู่ระหว่าง 1.9× ถึง 1,170× และเอกสารระบุว่าช่วงทั้งหมดนี้อยู่ในเงื่อนไขที่ผู้เขียนเองก็จัดว่าเป็นช่วงแบบคลาสสิก

วิธีทำซ้ำ

• สามารถทำซ้ำผลลัพธ์ได้ด้วยขั้นตอนต่อไปนี้บน branch และ environment เดียวกัน
  • git checkout urandom-reproduces-qpu
  • uv venv .venv && . .venv/bin/activate
  • uv pip install qiskit qiskit-ibm-runtime
• ตัวอย่างคำสั่งรันมีดังนี้
  • python projecteleven.py --challenge 4 --shots 8192
  • python projecteleven.py --challenge 10 --shots 8192
  • python projecteleven.py --challenge 17 --oracle ripple --shots 20000 # may need 2-3 tries
• เอกสารระบุว่าไม่จำเป็นต้องมี บัญชี IBM, โทเคน, ฮาร์ดแวร์ควอนตัม หรือ เครือข่าย

ข้อสังเกตและขอบเขต

• ตัว implementation ของ repository เองถูกประเมินว่าเป็น วิศวกรรมจริงและไม่ธรรมดา
  • มี oracle หลากหลายรูปแบบอยู่หกแบบ
  • มีการแมปตัวบวกแบบ CDKM ripple-carry เข้ากับโทโพโลยี heavy-hex
  • ใช้ semiclassical phase estimation ที่มี mid-circuit measurement
• ขอบเขตของคำวิจารณ์จำกัดอยู่ที่ ข้ออ้างด้าน cryptanalysis
• ข้อสรุปของเอกสารคือ การรันบนฮาร์ดแวร์นี้ไม่ใช่การกู้คืนคีย์ ECDLP โดยคอมพิวเตอร์ควอนตัม แต่เป็น การตรวจสอบแบบคลาสสิกต่อ candidate แบบสุ่มสม่ำเสมอ และอย่างที่ branch นี้แสดงให้เห็น มันสามารถทำซ้ำได้เหมือนเดิมโดยไม่ต้องใช้ฮาร์ดแวร์ควอนตัม

[GN⁺]

ความคิดเห็นใน Hacker News

• นี่ตรงกับสมมติฐานที่ผมวางไว้เป๊ะในบทความวันเมษาหน้าโง่ของ sigbovik ปี 2025 สำหรับจำนวนเล็ก ๆ ต่อให้ป้อนตัวอย่างสุ่มเข้าไปในอัลกอริทึมของ Shor ก็ยังสำเร็จได้เร็ว และเมื่อวงจรยาวเกินไปจนทะลุข้อจำกัดด้านอัตราความผิดพลาดของคอมพิวเตอร์ควอนตัม มันก็จะทำงานเสมือนเป็นตัวสร้างเลขสุ่มแทน
  ดังนั้นถึงภายนอกจะให้ผลลัพธ์ที่ "ถูกต้อง" แต่เหตุผลอาจผิดไปคนละเรื่องเลย ด้วยเหตุนี้ การแยกตัวประกอบจำนวนเต็มขนาดเล็กหรือกรณี ECDLP ขนาดเล็กจึงไม่เหมาะจะใช้เป็นเบนช์มาร์กวัดความก้าวหน้าของควอนตัมคอมพิวติง
  ผมเคยเตือนฝั่ง project11 ไว้แล้วว่าเรื่องแบบนี้จะเกิดขึ้น สุดท้ายผมคิดว่าพวกเขาจะให้บิตคอยน์กับคนที่ปกปิดความจริงได้เก่งที่สุดว่าคอมพิวเตอร์ควอนตัมไม่ได้มีส่วนช่วย และก็เป็นไปได้มากว่าคนส่งผลงานเองก็หลอกตัวเองอยู่เหมือนกัน ดูเหมือนพวกเขาจะไม่ได้รับเรื่องนี้อย่างจริงจัง
  [1]: https://sigbovik.org/2025/proceedings.pdf#page=146
• Project Eleven เพิ่งมอบ 1 BTC ให้กับสิ่งที่เรียกว่าเป็นการโจมตี ECC ด้วยควอนตัมที่ใหญ่ที่สุดเท่าที่เคยมีมา โดยอ้างว่าสามารถกู้คืนกุญแจเส้นโค้งวงรี 17 บิตได้ด้วยฮาร์ดแวร์ IBM Quantum แต่แล้ว Yuval Adam ก็พิสูจน์ว่าแม้จะเปลี่ยนคอมพิวเตอร์ควอนตัมเป็น /dev/urandom ก็ยังกู้กุญแจได้เหมือนเดิม
  • ถึงอย่างนั้นก็ควรดูไหมว่าฮาร์ดแวร์ควอนตัมประมวลผลได้เร็วกว่าหรือเปล่า
• โค้ดที่คนชนะความท้าทายนี้โพสต์ดูเหมือนจะเป็นโค้ดที่ชวนให้เข้าใจผิดพอสมควร แต่ตัวเขาเองกลับดูไม่มีพื้นฐานด้านควอนตัมคอมพิวติงเลย
  ประวัติส่วนตัวก็อยู่สาย enterprise software, full-stack architecture, cloud native, solution architecture และ sales engineering ส่วนประวัติ commit ดูแล้วนี่แทบจะเป็นงานแบบvibe coded: https://github.com/GiancarloLelli/quantum
  • ใช่เลย พออ่านแล้วเห็นร่องรอยแบบvibe codingเต็มไปหมด จนผมก็นึกแบบนั้นเป็นอย่างแรกเหมือนกัน
• นี่ไม่ใช่การด่าควอนตัมคอมพิวติงเอง แต่เป็นการด่า project11 และอาจรวมถึงฝั่งผู้ส่งผลงานด้วย เพราะพวกเขาตรวจสอบผลงานส่งไม่ดีพอ และโค้ดก็แสดงชัดอยู่แล้วว่าคำตอบนั้นเป็นวิธีแบบคลาสสิก
  การกู้คืนกุญแจ ECC 17 บิต ทุกวันนี้บนคอมพิวเตอร์แบบคลาสสิกก็ brute force ได้สบายมาก
  • ถ้าวิธีนี้เร็วกว่าสุ่ม อย่างน้อยก็ยังมีโอกาสว่าเป็นวิธีจริงบนคอมพิวเตอร์ควอนตัมได้อยู่
• การครอปรูป thumbnail ของบทความนี้โชคร้ายได้อย่างลงตัวจริง ๆ: https://image.non.io/b3f69546-aeb3-48c3-a76d-723f29b28f48.webp

  • contains the code and submission

    สมบูรณ์แบบ

  • ผมไม่แน่ใจว่าผมมองต่างจากคนอื่นไหม แต่ดูยังไงนั่นก็คือ t ของ quan(tumslop) ชัด ๆ

  • นี่มันศิลปะจริง ๆ

  • แอบขยะแขยงนิด ๆ

• dequantization เป็นหัวข้อวิจัยด้านข้อมูลควอนตัมที่มีอยู่จริงและชอบธรรมมาก มันมีประโยชน์ในการแยกแยะว่าสิ่งหนึ่งเป็นควอนตัมจริงหรือแค่ควันบังตา และช่วยให้เข้าใจว่าเส้นแบ่งระหว่างควอนตัมกับคลาสสิกอยู่ตรงไหน
  ยังมีผลลัพธ์ dequantized อื่น ๆ ที่เพิ่งออกมาด้วย: https://arxiv.org/abs/2604.21908
• กุญแจ 17 บิตมีความเป็นไปได้แค่ 131072 แบบเท่านั้น เลย brute force แตกได้ง่ายมาก การเอาสิ่งนี้ไปแตกด้วยคอมพิวเตอร์ควอนตัมจึงใกล้เคียงกับการสาธิตทางฟิสิกส์มากกว่า ไม่ได้ใกล้กับความพยายามทำงานคำนวณที่มีประโยชน์จริง
  • ประเด็นสำคัญตรงนี้คือส่วนที่เป็นคอมพิวเตอร์ควอนตัมในคำตอบเดิมไม่ได้ทำอะไรเลย หมายความว่าอัลกอริทึมทั้งหมดจริง ๆ แล้วไม่ใช่อัลกอริทึมควอนตัม แต่เป็นอัลกอริทึมเชิงความน่าจะเป็นแบบคลาสสิก
    ถ้าคอมพิวเตอร์ควอนตัมเป็นหัวใจสำคัญ พอเปลี่ยนเป็น RNG แล้วก็ควรตอบผิด หรืออย่างน้อยความเร็วในการลู่เข้าก็ควรช้าลง แต่ผลกลับเหมือนเดิมทุกอย่าง แปลว่าลอจิกที่แท้จริงอยู่ฝั่งคลาสสิกทั้งหมด และ QC ก็แค่เพิ่ม noise เข้าไปเท่านั้น
  • อาจเป็นเพราะผมไม่ค่อยรู้เรื่องนี้ แต่เจตนาเดิมไม่ใช่ว่ามันควรจะเร็วกว่าการ brute forceหรอกหรือ
    ถ้าผลลัพธ์แยกจากการเดาแบบสถิติไม่ได้ สุดท้ายมันก็ดูเหมือนแค่สร้างเครื่อง Rube Goldbergที่ซับซ้อนเท่านั้น
  • ถ้าผลงานของ QC แยกไม่ออกจากตัวสร้างเลขสุ่ม แล้วมันสาธิตอะไรกันแน่ก็ไม่รู้
• quantum grifting ลามเข้าฝั่งคริปโตแบบหนักมากแล้ว
  พวกต้มตุ๋นสามารถลากเหรียญเก่าที่เจ๊งไปแล้วกลับมา หรือสร้างเหรียญใหม่ขึ้นมา จากนั้นก็กว้านซื้อหรือ mint เอาไว้ แล้วเอาML-DSAมาติดป้ายว่าเป็น quantum-safe เพื่อปั่น shitcoin ก่อนจะเทขายทิ้ง
  สักวันนักลงทุนรายย่อยที่ข้อมูลน้อยกว่านี้ก็คงเริ่มรู้ทัน แต่เอาจริงตอนนี้ผมยังไม่แน่ใจด้วยซ้ำว่ามุกนี้ได้ผลกับใครบ้าง
  • ยิ่งเศร้าตรงที่เป้าหมายหลักน่าจะเป็นคนที่ไม่ได้ใช้ภาษาอังกฤษเป็นภาษาแม่
• ควรตรวจด้วยว่าจำนวนครั้งที่เรียก QMในสอง implementation ตรงกันหรือไม่
• ผมมองว่าควอนตัมคอมพิวติงเป็นการหลอกลวงที่ลากมา 30 ปี
  ขนาด Google เองก็ยังพิสูจน์ไม่ได้ว่าคอมพิวเตอร์ควอนตัมของตัวเองทำงานได้จริง แถมยังต้องทำให้อัลกอริทึมอ่อนลงแบบสุด ๆ จนเหลือระดับ17 บิตเท่านั้น
  • Google ไม่ได้เพิ่งรายงานเรื่องความได้เปรียบเชิงควอนตัมที่ตรวจสอบได้หรอกหรือ
    https://blog.google/innovation-and-ai/technology/research/quantum-echoes-willow-verifiable-quantum-advantage/
  • ผมคิดว่ามันมีความเป็นไปได้อยู่ แต่พอฟองสบู่ AI แตก นี่อาจกลายเป็นขยะหุ้นตลาดชิ้นถัดไป
    เราน่าจะได้เห็นการทุ่มเงินมหาศาลอย่างไร้เหตุผลไปกับเครื่องสร้างเลขสุ่มมูลค่า 1 หมื่นล้านดอลลาร์ที่ไม่มีใครอธิบายได้ว่าคืออะไร