บั๊ก KAWPOW ของ Ravencoin: ส่วนหัวบล็อกที่เลือกการตรวจ proof of work ของตัวเอง
ในสัปดาห์ที่สองของเดือนสิงหาคม Ravencoin ต้องย้อนเชนของตัวเองกลับไปราว 3 วัน สาเหตุไม่ใช่กลุ่มนักขุดที่รวมหัวกัน ไม่ใช่ช่องโหว่ของกระเป๋าเงิน และไม่ใช่ฟังก์ชัน hash ที่พัง แต่เป็นฟิลด์เดียวในส่วนหัวบล็อกที่โหนดเชื่อให้บอกว่าจะรันการตรวจ proof of work แบบไหนจากสองแบบ โค้ดทุกชิ้นที่ยกมาด้านล่างอ่านจากซอร์สฉันทามติของ Ravencoin เอง ไม่ใช่จากประกาศ และตรงไหนที่ประกาศพูดถึงสิ่งที่ซอร์สไม่ได้แสดง บทความนี้จะบอกตรงๆ แทนที่จะเดา
ส่วนหัว KAWPOW เก็บอะไรไว้บ้าง
KAWPOW คือ proof of work ของ Ravencoin เป็น ProgPoW รูปแบบหนึ่งที่เชนเปลี่ยนมาใช้ในเดือนพฤษภาคม 2020 เพื่อให้เหรียญยังขุดได้ด้วย GPU ทั่วไป การเปลี่ยนนี้ทำให้ส่วนหัวบล็อกเปลี่ยนไป ก่อนเวลาเปิดใช้งาน ส่วนหัวจะจบด้วย nonce ขนาด 32 บิตแบบธรรมดาที่ทุกเชนซึ่งแยกมาจาก Bitcoin ใช้ หลังจากนั้น ตัว serializer จะเขียนสามฟิลด์ลงในช่องนั้นแทน ตามลำดับนี้: nHeight, nNonce64 และ mix_hash
สองฟิลด์ในนั้นไม่มีอะไรน่าสนใจ nNonce64 เป็นแค่ nonce ที่กว้างขึ้น ส่วน mix_hash คือผลลัพธ์กลางทางของส่วนที่ใช้หน่วยความจำหนัก (memory hard) ของอัลกอริทึม ซึ่งเก็บไว้ในส่วนหัวเพื่อให้ผู้ตรวจสอบมีค่าไว้เทียบ แทนที่จะต้องคำนวณใหม่ตั้งแต่ต้น ฟิลด์ที่สามคือฟิลด์ที่น่าสนใจ nHeight คือการที่บล็อกบอกไว้ในส่วนหัวของตัวเองว่ามันเชื่อว่าตัวเองอยู่ที่ความสูงเท่าไร
ตำแหน่งจริงของบล็อกในเชนไม่ใช่เรื่องความเห็น มันถูกกำหนดโดย hashPrevBlock: คุณต่อบล็อกบนบล็อกไหน ก็จะอยู่ตรงนั้น และคุณโกหกเรื่องนี้ไม่ได้ถ้ายังอยากต่อเข้ากับปลายเชน nHeight เป็นสำเนาที่สองของข้อเท็จจริงเดียวกันซึ่งเขียนแก้ได้ และสำเนาของข้อเท็จจริงจะมีค่าเท่ากับการตรวจที่เอามันไปเทียบกับต้นฉบับเท่านั้น
ฟังก์ชัน hash สองตัว ซึ่งตัวหนึ่งไม่ได้ตรวจอะไรเลย
ไฟล์ hash.cpp ของ Ravencoin กำหนดจุดเข้า KAWPOW ไว้สองจุด และ signature ของทั้งสองก็เล่าเรื่องส่วนใหญ่ได้แล้วก่อนคุณจะอ่านเนื้อฟังก์ชันสักบรรทัด ตัวแรกคือ uint256 KAWPOWHash(const CBlockHeader& blockHeader, uint256& mix_hash) ตัวที่สองคือ uint256 KAWPOWHash_OnlyMix(const CBlockHeader& blockHeader)
ตัวแรกรับ mix_hash เป็นพารามิเตอร์ขาออก เพราะมันสร้างค่านี้ขึ้นมา มันเลือกชุดข้อมูลด้วย ethash::get_epoch_number(blockHeader.nHeight) สร้าง epoch context นั้นถ้ายังไม่มี แล้วจึงรัน progpow::hash บนชุดข้อมูลนั้น ค่า mix ที่มันคืนมาเป็นผลพลอยได้จากการทำงานจริง นี่คือเส้นทางที่ใช้หน่วยความจำหนัก และความหนักของหน่วยความจำนี้คือเหตุผลทั้งหมดที่ KAWPOW มีอยู่ แทนที่จะเป็น hash ธรรมดา
ตัวที่สองไม่มีพารามิเตอร์แบบนั้น เพราะมันไม่ได้สร้างอะไรเลย มันใช้ค่า mix ที่อยู่ในส่วนหัวอยู่แล้ว ผ่าน progpow::hash_no_verify(blockHeader.nHeight, header_hash, to_hash256(blockHeader.mix_hash.GetHex()), blockHeader.nNonce64) ไลบรารีต้นทางตั้งชื่อฟังก์ชันนั้นว่า hash_no_verify และชื่อนั้นตรงทุกตัวอักษร มันทำขั้นตอนผสมสุดท้ายบนค่าที่ได้รับมาแล้วคืนคำตอบ มันไม่เคยสร้างชุดข้อมูล จึงไม่เคยยืนยันว่าค่าที่ได้รับมานั้นจะมาได้จากการทำงานจริงเท่านั้น
ทั้งสองฟังก์ชันไม่ใช่ความผิดพลาด ตัวที่ราคาถูกมีเหตุผลที่ดี: โหนดที่ซิงก์บล็อกเก่านับล้านบล็อกซึ่ง checkpoint ที่ฝังในโค้ดยืนยันไว้แล้ว ไม่ควรต้องสร้างชุดข้อมูลขนาดหลายกิกะไบต์ใหม่ทุก epoch เพื่อยืนยันประวัติที่ไม่มีใครโต้แย้ง คำถามเดียวที่ดีไซน์แบบนี้ต้องตอบคือ บล็อกไหนบ้างที่ได้รับอนุญาตให้ใช้ทางนี้
ประตู และสิ่งที่มันเชื่อ
คำถามนั้นถูกตอบโดย CheckBlockHeader ใน validation.cpp และคอมเมนต์ที่อยู่เหนือคำตอบก็บอกเจตนาไว้ชัด: "If we are checking a KAWPOW block below a know checkpoint height. We can validate the proof of work using the mix_hash" เจตนานั้นถูกต้อง แต่โค้ดใช้เงื่อนไข block.nHeight <= (uint32_t)pcheckpoint->nHeight และ block.nHeight คือตัวเลขที่บล็อกเขียนเกี่ยวกับตัวเอง
บรรทัดถัดลงมาเรียก CheckProofOfWork(uint256 hash, unsigned int nBits, const Consensus::Params&) แบบทั่วไป ลองดูสิ่งที่ signature นี้ไม่มี: ไม่มี mix ไม่มี nonce และไม่มีส่วนหัว มันรับ hash ที่เสร็จแล้วกับเป้าหมาย แล้วเทียบสองค่านั้น และไม่มีทางรู้ได้เลยว่าตัวเลขที่ได้รับมาผลิตจากฟังก์ชันไหน สำหรับบล็อก KAWPOW นั้น CBlockHeader::GetHash() คืนค่า KAWPOWHash_OnlyMix(*this) ตัวเลขที่มันได้รับจึงมาจากตัวที่ราคาถูก
เมื่อต่อทุกอย่างเข้าด้วยกัน บล็อกที่ประกาศ nHeight ต่ำพอจะถูกตรวจสอบโดยถามแค่ว่าค่าที่ได้จาก mix hash ของมันเองต่ำกว่าเป้าหมายหรือไม่ ไม่มีจุดไหนบนเส้นทางนั้นที่ถามว่า mix มาจากไหน และไม่มีจุดไหนที่เอาความสูงที่ประกาศไปเทียบกับตำแหน่งที่บล็อกอยู่จริง
ต่ำแค่ไหนจึงจะพอ กลายเป็นว่าไม่ใช่เรื่องละเอียดอ่อนเลย checkpoint สูงสุดในพารามิเตอร์เชน mainnet ที่ปล่อยออกมาคือ 2,383,550 บล็อกปลอมบล็อกแรกอยู่ที่ 4,487,776 ส่วนหัวของมันต้องอ้างตำแหน่งที่ย้อนหลังไปราว 2.1 ล้านบล็อกจากตำแหน่งจริง และเส้นทางที่มันเลือกด้วยวิธีนั้นก็ไม่เคยดูส่วนต่างนี้เลย
ทางลัดนี้ให้อะไร และไม่ได้ให้อะไร
ตรงนี้ควรพูดให้แม่นยำ เพราะข่าวส่วนใหญ่พูดเรื่องนี้อย่างหลวมๆ และเวอร์ชันที่หลวมทำให้บั๊กนี้ฟังดูทั้งง่ายกว่าและแปลกกว่าความจริง
ทางลัดนี้ไม่ได้ลดความยาก nBits ถูกตรวจเทียบกับสิ่งที่บล็อกก่อนหน้าตัวจริงกำหนด และบล็อกก่อนหน้าตัวจริงถูกเลือกด้วย hashPrevBlock ซึ่งผู้โจมตีปลอมไม่ได้ถ้ายังอยากต่อเข้ากับปลายเชน บล็อกปลอมต้องผ่านเป้าหมายเดียวกันทุกประการกับบล็อกที่ขุดอย่างสุจริตในนาทีเดียวกัน
สิ่งที่เปลี่ยนคือราคาของการเดาหนึ่งครั้ง นักขุดที่สุจริตจ่ายทุกครั้งที่ลองด้วยการอ่านชุดข้อมูลขนาดหลายกิกะไบต์จนครบหนึ่งรอบ ซึ่งคือหัวใจของอัลกอริทึมที่ใช้หน่วยความจำหนัก และเป็นเหตุผลที่ KAWPOW กัน ASIC ออกจาก Ravencoin ได้มา 6 ปี ทางลัดนี้มีต้นทุนแค่การ hash ส่วนหัวหนึ่งครั้ง บวกขั้นตอนผสมสุดท้ายอีกหนึ่งขั้นบนค่าที่ผู้โจมตีเลือกเองได้ตามใจ ลอตเตอรีเดิม โอกาสต่อใบเท่าเดิม แต่ตั๋วถูกลงหลายอันดับขนาด 2Miners เรียกผลที่ได้ว่าบล็อกที่แทบไม่ต้องทำงาน และเมื่อเทียบกับต้นทุนที่ KAWPOW ควรจะเป็น นั่นก็เป็นคำอธิบายที่ยุติธรรม
เกิดอะไรขึ้นบนเครือข่าย
บล็อกที่ไม่ถูกต้องบล็อกแรกที่รู้จักคือความสูง 4,487,776 เวลาประทับ 2026-08-07 15:44:01 UTC การโจมตีดำเนินต่อไปจนถึงรุ่นฉุกเฉินที่ปล่อยออกมาวันที่ 10 สิงหาคม ในช่วงหนึ่งที่ตรวจดูซึ่งยาว 2,089 บล็อก 2Miners นับบล็อกที่ได้รับผลกระทบได้ 96 บล็อก บล็อกปลอมจึงกระจายอยู่ทั่วสาขานั้น ไม่ได้อยู่ติดกันเป็นช่วงเดียว นี่คือเหตุผลที่ทางแก้ต้องเป็นการจัดเรียงเชนใหม่ (reorg) ไม่ใช่การตัดออกเฉพาะจุด
สำหรับผู้ดูแลโหนด อาการที่เห็นได้แย่กว่าการที่บล็อกไม่ถูกต้องถูกยอมรับไปเงียบๆ โหนดแครชเมื่อเจอบล็อกเหล่านี้ และหลังรีสตาร์ทก็หยุดซิงก์ Tron Black อธิบายกลไกนี้ไว้ภายหลัง และมันเป็นความเสียหายข้างเคียงที่ลงตัวพอดี ดัชนีบล็อกเก็บความสูงที่บล็อกอยู่จริง ไม่ใช่ความสูงที่ส่วนหัวประกาศ เมื่อรีสตาร์ท โหนดจะสร้างส่วนหัวแต่ละอันขึ้นใหม่จากดัชนีแล้วคำนวณ hash ใหม่ สำหรับบล็อกปลอม มันจึง hash ความสูงจริงในตำแหน่งที่ส่วนหัวเคยมีค่าปลอม hash ไม่ตรงกันอีกต่อไป การตรวจ proof of work ล้มเหลว และ LoadBlockIndexGuts ก็หยุดทำงาน บล็อกถูกยอมรับไปครั้งหนึ่งแล้วกลายเป็นโหลดไม่ได้ นี่คือเหตุผลที่อาการที่สองอยู่นานกว่าอาการแรก
กระดานเทรดหลายแห่งระงับการฝากและถอน RVN ระหว่างที่สาขานั้นยังไม่ได้ข้อยุติ นั่นคือการตอบสนองปกติและถูกต้องต่อเชนที่ประวัติล่าสุดกำลังจะถูกเขียนใหม่ และควรคาดไว้ล่วงหน้า แทนที่จะอ่านว่าเป็นคำตัดสินต่อตัวเหรียญ
แพตช์ และที่มาของมัน
การแก้ไขครั้งแรกออกมาวันที่ 10 สิงหาคม เป็นเวอร์ชัน 4.6.1.1-hf1 และมาจาก 2Miners ซึ่งเป็นพูลขุด ไม่ใช่จากโปรเจกต์ Ravencoin มันหยุดความเสียหายได้สำหรับทุกคนที่ติดตั้ง และถูกแทนที่ในวันถัดมา
เวอร์ชัน 4.8.0 ซึ่งเผยแพร่วันที่ 11 สิงหาคมผ่าน repository ของ Ravencoin คือรุ่นที่ควรรัน อย่าใช้รุ่นที่เก่ากว่านี้ รุ่นนี้ปฏิเสธบล็อกที่ความสูงที่ประกาศในส่วนหัวไม่ตรงกับตำแหน่งจริงตั้งแต่ 4,487,776 เป็นต้นไป ตั้ง checkpoint ที่ 4,487,775 เป็นบล็อกสุดท้ายที่สะอาด สร้างสถานะเชนที่เสียหายขึ้นใหม่โดยอัตโนมัติแทนที่จะหยุดทำงาน และรวมการแก้ overflow ในการโอนสินทรัพย์ (asset) ที่ hotfix ฉุกเฉินไม่มี พร้อมงานอื่นจากต้นทาง
มีแค่ข้อแรกเท่านั้นที่เป็นการซ่อม ปฏิเสธบล็อกที่ความสูงที่ประกาศไม่ตรงกับตำแหน่งที่มันอยู่จริง แล้วประตูก็จะปิด checkpoint และการสร้างใหม่อัตโนมัติคือการกู้คืน และ checkpoint โดยเฉพาะเป็นเครื่องมือที่หยาบ: มันคือการยืนยันที่ฝังไว้ในโค้ดว่าบล็อกหนึ่งบล็อกคือบล็อกที่ถูกต้อง ซึ่งเป็นสิ่งที่เชนอยากมีให้น้อยที่สุดเท่าที่จะทำได้ มันอยู่ตรงนี้เพราะต้องทำให้สาขาที่สุจริตติดแน่นเร็วกว่าที่แฮชเรทอย่างเดียวจะทำได้
จุดกู้คืนเองก็เป็นการตัดสินใจ ไม่ใช่สิ่งที่ชัดเจนในตัว Tron Black เขียนไว้ว่าเขาขอให้พูลต่างๆ พิจารณาจุดตัดที่ใหม่กว่า เพื่อให้การ reorg ตื้นขึ้น แล้วจัดการบล็อกปลอมเป็นกรณีพิเศษแทน แต่พูลปฏิเสธและเลือกเส้นที่สะอาดที่สุดเท่าที่ทำได้ ในระบบ proof of work ข้อถกเถียงแบบนี้ยุติได้ด้วยตัวเอง: เมื่อแฮชเรทที่สุจริตส่วนใหญ่ปฏิเสธประวัติชุดหนึ่ง ประวัตินั้นก็แพ้ และพูลที่ใหญ่ที่สุดสองแห่งรวมกันก็มีเสียงส่วนใหญ่
reorg 3 วันหมายความว่าอะไรจริงๆ
เพราะโหนดที่มีช่องโหว่ยอมรับบล็อกปลอม สาขาที่มีบล็อกเหล่านั้นจึงสะสมเชนจริงต่อขึ้นไปด้านบน การทิ้งสาขานี้จึงหมายถึงการ reorg และด้วยเป้าหมายเวลาบล็อก 1 นาทีของ Ravencoin ช่วงตั้งแต่ 4,487,776 ถึงแพตช์ก็เท่ากับบล็อกราว 3 วัน
ถ้าคุณถือ RVN ความหมายในทางปฏิบัติคือธุรกรรมที่ได้รับการยืนยันบนสาขาที่ถูกทิ้งจะไม่ได้รับการยืนยันอีกต่อไป ส่วนใหญ่จะกลับไปที่ mempool และถูกขุดใหม่บนเชนที่เหลืออยู่ แต่ไม่มีอะไรรับประกัน และมีธุรกรรมประเภทหนึ่งที่กลับมาไม่ได้เลย ธุรกรรมที่ใช้ coinbase ของบล็อกที่ถูกทิ้ง คือการใช้เหรียญที่ไม่มีอยู่แล้วบนเชนที่เหลืออยู่ และทุกอย่างที่ต่อยอดจากธุรกรรมนั้นก็เช่นกัน ธุรกรรมเหล่านี้ไม่ถูกต้องไปเลย ไม่ใช่รอดำเนินการ นี่คือเหตุผลที่การระงับของกระดานเทรดเป็นการตัดสินใจที่ถูก ไม่ใช่การตอบสนองเกินเหตุ และเหตุผลที่กิจกรรมหลัง 4,487,775 ควรระวังจนกว่าจะได้ปลายเชนเดียวที่ชัดเจน
มีรายละเอียดหนึ่งที่ควรรู้ถ้าคุณเห็นโหนดไม่ยอมขยับในสัปดาห์นั้น โหนด Ravencoin มีกฎห้าม reorg ยาว ซึ่งมีไว้หยุดการโจมตีแบบเสียงข้างมากที่ไม่คาดคิดไม่ให้เขียนประวัติลึกๆ ใหม่ โหนดเก่าส่วนใหญ่ที่รันต่อเนื่องในที่สุดก็มีจำนวน peer ลดลงต่ำกว่าที่กฎนั้นต้องใช้ แล้วจึงยอมรับเชนที่ยาวกว่าตามที่ออกแบบไว้ บางโหนดไม่เป็นเช่นนั้น เพราะไม่เคยเสีย peer มากพอ และเพราะตามกฎที่เขียนไว้ ไม่มีอะไรถูกละเมิด นี่คือการป้องกันที่ทำงานตรงตามสเปกทุกอย่าง กับปัญหาที่มันไม่เคยถูกออกแบบมารับมือ การแยกเชนครั้งนี้มาจากข้อบกพร่องในการตรวจสอบ ไม่ใช่จากการโจมตีเสียงข้างมาก และกฎนี้แยกสองอย่างนี้ออกจากกันไม่ได้
ถ้าคุณขุด RVN ควรทำอะไร
ถ้าคุณรันโหนด Ravencoin ของตัวเอง ให้รัน 4.8.0 และต้องไม่ใช่รุ่นก่อนหน้าที่แก้ปัญหานี้ได้แค่บางส่วน หยุดโหนด เปลี่ยนไบนารี แล้วเริ่มใหม่ ไม่ต้อง reindex และไม่มีขั้นตอนที่ต้องทำเอง: ซอฟต์แวร์จะสร้างสิ่งที่ต้องใช้ขึ้นใหม่เอง โหนดที่มาจาก hotfix ฉุกเฉินจะรีสตาร์ทได้เร็ว โหนดที่มาจากซอฟต์แวร์ที่ยังไม่ได้แพตช์ต้องเล่นซ้ำและสร้างใหม่ ซึ่งใช้เวลาหลายชั่วโมงบนฮาร์ดแวร์ทั่วไป และข้อผิดพลาด bad-blk-height ตลอดช่วงนั้นคือแพตช์กำลังทำงาน ไม่ใช่ความผิดพลาดของมัน
ถ้าคุณขุดผ่านพูล ฝั่งคุณไม่ต้องเปลี่ยนอะไร ไม่มีที่อยู่ใหม่ ไม่มีพอร์ตใหม่ และไม่ต้องอัปเดตซอฟต์แวร์ขุด ตัว KAWPOW เองไม่เคยเป็นปัญหาในเรื่องนี้: อัลกอริทึมทำงานตรงตามที่ออกแบบไว้ทุกอย่าง และข้อบกพร่องอยู่ในโค้ดที่ตัดสินว่าจะรันมันเมื่อไร แฮชเรทที่คุณชี้ไปที่สาขาเก่าเป็นงานจริง มันแค่ไปลงบนบล็อกที่ถูกทิ้งไปพร้อมกับบล็อกปลอมที่กระจายอยู่ในนั้น
มีวิธีบรรทัดเดียวที่ยืนยันได้ว่าคุณอยู่บนเชนที่ถูก และควรทำจริงแทนที่จะคิดเอาเอง ตรวจ hash ของบล็อก 4,494,143 บนเชนหลัก (canonical) hash จะลงท้ายด้วย 4c67d6a4 และ explorer ของ Ravencoin ที่เป็นอิสระทุกตัวแสดงเชนเดียวกันนี้ตอนที่โปรเจกต์ประกาศว่าเครือข่ายกู้คืนแล้ว
รูปร่างของบั๊ก
ตัดรายละเอียดเฉพาะออกไป สิ่งที่เหลือคือรูปแบบที่เกิดซ้ำอยู่เสมอ ทั้งในเชนและนอกเชนอีกมาก ค่าที่มาจากภายนอกถูกใช้ตัดสินว่าค่านั้นเองจะถูกตรวจละเอียดแค่ไหน ส่วนหัวบอกความสูงของตัวเอง และโหนดใช้คำบอกนั้นเลือกว่าส่วนหัวจะต้องผ่านการตรวจ proof of work แบบไหน
เวอร์ชันที่ถูกต้องไม่ซับซ้อน และแพตช์ก็คือหนึ่งบรรทัดของมันโดยพื้นฐาน: เทียบความสูงที่ประกาศกับตำแหน่งที่บล็อกอยู่จริงก่อน แล้วจึงปล่อยให้มันตัดสินอะไรก็ตาม ส่วนที่น่าสนใจกว่าคือทำไมมันถึงหายไป ทางลัดนี้เขียนขึ้นสำหรับบล็อกที่เชื่อถือได้อยู่แล้ว และภายใต้สมมติฐานนั้น ประตูนี้อ่านเหมือนการบอกข้อเท็จจริง ไม่ใช่คำถามที่ใครอาจตอบอย่างไม่สุจริต มันเลิกอ่านแบบนั้นทันทีที่บล็อกที่เชื่อถือไม่ได้ได้รับอนุญาตให้กรอกฟิลด์นั้น และไม่มีอะไรในโค้ดที่ทำเครื่องหมายไว้ว่าสิ่งนี้เปลี่ยนไปเมื่อไร
มีสองเรื่องเกี่ยวกับการค้นพบที่ควรบันทึกไว้ โค้ดของ Ravencoin เคยผ่านการตรวจสอบความปลอดภัยจากมืออาชีพ และการตรวจนั้นไม่พบทั้งปัญหานี้และ overflow ของสินทรัพย์ที่ถูกแก้ไปพร้อมกัน Tron Black เขียนว่าเขาสงสัยอย่างยิ่งว่าทั้งสองถูกพบด้วยการตรวจความปลอดภัยโดย AI ระดับ frontier model ไม่ว่าจะใช้เครื่องมืออะไร มันก็เข้ากับรูปแบบนี้: ข้อบกพร่องมองไม่เห็นตราบที่คุณอ่านทางลัดตามตรรกะของมันเอง และจะปรากฏเมื่อคุณถามว่าใครเป็นคนกรอกฟิลด์ที่ทางลัดเชื่อ
สิ่งสุดท้ายที่ควรสังเกตคือใครขยับ และขยับตามลำดับไหนพูลขุดแห่งหนึ่งอ่านเส้นทางการตรวจสอบ เข้าใจมัน และปล่อยไบนารีฉุกเฉินภายใน 3 วัน จากนั้น พูลที่ใหญ่ที่สุดสองแห่งตกลงขุดเชนที่ทิ้งช่วงการโจมตีทั้งหมด แทนที่จะเลือกจุดตัดที่สะดวก และเมื่อถูกขอให้เลือกจุดที่ตื้นกว่าก็ปฏิเสธ โปรเจกต์ตามมาในวันถัดไปด้วยรุ่นที่แทนที่ hotfix และแก้ได้มากกว่า ใครมาก่อนสำคัญน้อยกว่าการที่ทั้งสองอย่างเกิดขึ้น และสิ่งที่ยุติเรื่องนี้จริงๆ ไม่ใช่ประกาศของใคร แต่เป็นน้ำหนักสะสมของงานจริงฝั่งหนึ่งของการแยกเชน นี่คือหน้าตาของการกระจายศูนย์ในวันที่มันต้องรับน้ำหนักจริง ไม่ใช่แค่อยู่ใน whitepaper
ตัวเลขเหล่านี้มาจากไหน
เพื่อให้ทุกคนตรวจสอบได้เอง แทนที่จะเชื่อคำพูดของเรา โครงสร้างส่วนหัว ฟังก์ชัน hash ทั้งสองกับ signature การเลือก epoch และสาขาการตรวจสอบพร้อมคอมเมนต์ อ่านจากซอร์สของ Ravencoin เอง ใน src/primitives/block.h, src/primitives/block.cpp, src/hash.cpp, src/hash.h, src/pow.h และ src/validation.cpp รายการ checkpoint รวมถึง 2,383,550 ซึ่งสูงสุดบน mainnet อ่านจาก src/chainparams.cpp ความสูงแรกที่ไม่ถูกต้องและเวลาประทับมาจากประกาศเครือข่ายของโปรเจกต์ Ravencoin เอง เส้นทางการแครชของดัชนีบล็อก ธุรกรรมที่พึ่ง coinbase ซึ่งกลับมาไม่ได้ พฤติกรรมห้าม reorg ยาว จุดกู้คืนที่ตื้นกว่าที่ถูกปฏิเสธ ความเห็นเรื่องการตรวจสอบและการตรวจโดย AI สิ่งที่อยู่ใน 4.8.0 และการตรวจบล็อก 4,494,143 มาจากคำบอกเล่าของ Tron Black ในนามโปรเจกต์ Ravencoin เวอร์ชัน hotfix ฉุกเฉินและจำนวน 96 บล็อกที่ได้รับผลกระทบใน 2,089 บล็อก มาจากรุ่นที่ 2Miners ปล่อยและข่าวที่เกี่ยวข้อง สิ่งใดที่แหล่งข้อมูลไม่ได้ระบุ ถูกตัดออกจากบทความนี้ ไม่ได้เติมเอง