การวิเคราะห์โดยสังเขปของการซิงโครไนซ์ข้อมูลที่ใช้งานอยู่ใน Ethereum

I. บทนำ

ตรงประเด็น การซิงโครไนซ์ข้อมูล Ethereum ใช้โหนด (เพียร์) เป็นพาหะข้อมูลเพื่อจัดเก็บและส่งข้อมูลที่มีหัวข้อหลักประกอบด้วย Header, Body และ Reciept ธุรกรรมการซิงโครไนซ์ข้อมูลได้รับการจัดการผ่านโปรโตคอลการสื่อสาร Ethereum p2p และสุดท้ายก็ส่งต่อไปยัง ตัวดำเนินการ (การซิงโครไนซ์ที่ใช้งานอยู่จะมอบให้กับ Downloader การซิงโครไนซ์แบบพาสซีฟจะถูกส่งต่อไปยัง Fetcher) เพื่อดำเนินการดาวน์โหลดข้อมูลขั้นสุดท้าย

จากนั้นถามเจ้าของข้อมูลว่าข้อมูลใดที่เราต้องซิงโครไนซ์สำหรับการซิงโครไนซ์ จำเป็นต้องจัดประเภทและซิงโครไนซ์ข้อมูลที่แตกต่างกันหรือไม่?

โปรดทราบว่า Chuangyu Blockchain Security Lab ได้ทำการวิเคราะห์อย่างละเอียดและครอบคลุม

2. เรื่องข้อมูล:

ในการซิงโครไนซ์ข้อมูล ก่อนอื่นเราต้องชี้แจงว่าข้อมูลที่เราซิงโครไนซ์ประกอบด้วยอะไรบ้าง โดยทั่วไป มีอยู่ 2 ประเภท ประเภทหนึ่งไม่ต้องการโหนดในการส่งคำขอซิงโครไนซ์ที่ใช้งานอยู่ และโหนดจะเผยแพร่ไปยังเครือข่ายด้วยตัวเอง เมื่อข้อมูลถูก package ข้อมูลประเภทนี้มีอยู่ 3 ประเภท: Types - full block, block hash และ transaction Transaction วันนี้เรามุ่งเน้นไปที่หมวดหมู่ถัดไปของข้อมูล

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

⬆Header หมายถึงส่วนหัวของบล็อกซึ่งมีบทบาทสำคัญมากในบล็อก ParentHash จะบันทึกแฮชบล็อกของบล็อกก่อนหน้า uncleHash จะบันทึกแฮชของบล็อกลุง และ coinbase จะระบุที่อยู่ของผู้ขุด Root, Txhash และ ReceiptHash เป็นโหนดรูทของทรีคำนำหน้าสามต้นของ state trie, tx trie และ Receipt.trie ตามลำดับ แฮชรหัส RLP หนึ่งรหัสใช้เพื่ออธิบายสถานะของโลก และอีกอันใช้เพื่ออธิบายการรับธุรกรรม Bloom เป็นตัวกรอง Bloom ในส่วนหัวของบล็อกเพื่อระบุอย่างรวดเร็วว่าแฮชเป้าหมายอยู่ในชุดที่กำหนดหรือไม่ ข้อมูลข้างต้นในส่วนหัวถูกใช้โดยส่วนหัวของบล็อกเพื่อระบุบล็อกและโมดูลข้อมูลที่สำคัญในบล็อกโดยใช้แฮช ข้อมูลที่เหลือมีความต้องการของตนเอง จะเห็นได้ว่าส่วนหัวของบล็อกได้อธิบายกรอบของบล็อกโดยพื้นฐานแล้ว ซึ่งปูทางสำหรับกลยุทธ์การซิงโครไนซ์ข้อมูลที่กล่าวถึงในภายหลังด้วย

⬆เนื้อหาค่อนข้างกระชับ ซึ่งประกอบด้วยชุดของอ็อบเจกต์ธุรกรรมและอาร์เรย์ของส่วนหัวบล็อกของบล็อกลุง

⬆Receipt เป็นอาร์เรย์ที่สร้างขึ้นโดยอ็อบเจกต์ธุรกรรมทั้งหมดในบล็อกหลังจากการดำเนินการเสร็จสิ้น และใช้เพื่อบันทึกข้อมูลการประมวลผลธุรกรรม หลังจากสร้างแล้ว พวกมันจะถูกแทรกลงใน Receipt trie ทีละรายการ และ ReceiptHash ในส่วนหัวของบล็อกก็จะถูกสร้างขึ้นด้วย ใบเสร็จธุรกรรมจะบันทึกข้อมูลสามส่วนสำหรับการจัดการธุรกรรมและการระบุตัวตน ส่วนแรกคือ ส่วนที่เป็นเอกฉันท์, PostState, สถานะ, CumulativeGasUsed, Bloom และ Logs เฉพาะข้อมูลทั้งห้านี้เท่านั้นที่จะถูกเข้ารหัสใน ReceiptRLP เพื่อสร้างแฮชใบเสร็จ จากนั้น แฮชใบเสร็จจะเข้าร่วมในฉันทามติ ส่วนที่สองของข้อมูลคือส่วนธุรกรรม TxHash หมายถึงแฮชธุรกรรมที่สอดคล้องกับใบเสร็จธุรกรรม ที่อยู่สัญญาคือที่อยู่ของสัญญาใหม่เมื่อธุรกรรมถูกปรับใช้ และ GasUsed บ่งชี้ก๊าซ ของธุรกรรมการใช้งาน ส่วนที่สามคือส่วนบล็อก ซึ่งบันทึกแฮชบล็อก BlockHash, BlockNumber หมายเลขบล็อกปัจจุบัน และ TransactionIndex หมายเลขซีเรียลของธุรกรรมในบล็อก Receipt มีความแตกต่างโดยสัญชาตญาณในกลยุทธ์การซิงโครไนซ์ข้อมูล ข้อแตกต่างที่ใช้งานง่ายที่สุดระหว่าง fullSync และ fastSync ที่กล่าวถึงด้านล่างคือการซิงโครไนซ์การรับของเพียร์หรือสร้างใบเสร็จในเครื่อง

3. ผู้ให้บริการข้อมูล

ผู้ให้บริการรับส่งข้อมูลคือโหนดเพียร์ เพียร์ผู้ให้บริการข้อมูลนี้ หากคุณค้นหาอย่างระมัดระวังในซอร์สโค้ด คุณจะพบ peer.go ในบางมุม อันดับแรก ฉันจะแสดงรายการโครงสร้างเพียร์ที่ฉันพบเกี่ยวกับโมดูลการซิงโครไนซ์ข้อมูล . มี p2p/peer.go, eth/peer.go, les/peer.go, eth/downloader/peer.go เครือข่ายของ Ethereum ยังมีเลเยอร์การขนส่ง เลเยอร์เซสชัน เลเยอร์การนำเสนอ และเลเยอร์โปรโตคอล

เพียร์ในแพ็คเกจ p2p ทำหน้าที่เป็นโมเดลโหนดพื้นฐาน เลเยอร์การขนส่งจะค้นหาเพียร์ที่อยู่ติดกันตามโปรโตคอล UDP และรักษาการเชื่อมต่อเพียร์ และยังสร้างช่องทางการแลกเปลี่ยนข้อมูลระหว่างเพียร์ตามโปรโตคอล TCP การจัดการเพียร์ที่เลเยอร์เซสชันส่วนใหญ่จะจัดการการโต้ตอบระหว่างโหนดและโปรโตคอลย่อยชั้นบน ในขณะที่การจัดการ NodeTable ส่วนใหญ่จะจัดการตารางการเชื่อมต่อโหนดพื้นฐานที่สร้างขึ้นตามโปรโตคอล UDP ดังนั้น เพียร์โหนดที่เลเยอร์ p2p จะต้องสามารถรับและเปิดโปรโตคอลย่อยได้ และต้องสามารถ ping โหนดอื่นได้ และแน่นอนว่าต้องรับข้อความจากโหนดอื่นด้วย สิ่งนี้สะท้อนให้เห็นในโมดูลการทำงานที่สำคัญสามโมดูลใน p2p/peer.go, pingLoop, readLoop และ startProtocol ซึ่งเป็นสามฟังก์ชันในเมธอด peer.run()

จะเห็นได้ว่าด้านบนคือโครงสร้างเพียร์พื้นฐานและภาพด้านล่างคือโครงสร้างเพียร์ของชั้นโปรโตคอลย่อย เลเยอร์ย่อยของโปรโตคอลที่แตกต่างกันจะมีโครงสร้างเพียร์ที่แตกต่างกัน ซึ่งเป็นเหตุผลว่าทำไมจึงมี eth/peer.go และ les/peer.go หลังจากทั้งหมด โปรโตคอลย่อยที่แตกต่างกันใช้กับสถานการณ์ข้อมูลที่แตกต่างกัน

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

4. กระบวนการซิงโครไนซ์ข้อมูล

ดังนั้นจะเริ่ม protocolManager ได้อย่างไร? เราแนะนำโครงสร้างเพียร์ข้างต้นซึ่งส่วนใหญ่เป็นตัวแทนของโหนดระยะไกลอื่น ๆ ใน Ethereum มีโหนดโครงสร้างอีกประเภทหนึ่งที่เป็นตัวแทนของโหนด โดยหลัก ๆ แล้วเป็นตัวแทนของโหนดภายในซึ่งแตกต่างกันเล็กน้อยและโหนดต้องการเริ่ม p2p เครือข่าย ต้องอาศัยโมดูลโหนดในเครื่องซึ่งใช้ฟังก์ชัน Node.Start() เพื่อเริ่มงานสองงาน หนึ่งคือ เริ่มบริการ Ethereum และ Ethereum.start เริ่มทำงาน protocolmanager อีกงานคือเริ่ม p2p เซิร์ฟเวอร์ สร้างและรีเฟรช K bucket เปิดใช้งานการตรวจสอบพอร์ต UDP และการตรวจสอบพอร์ต TCP พร้อมกัน และประมวลผลข้อความที่ส่งจากโหนดระยะไกล

เมื่อเริ่ม protocolManager มันจำเป็นต้องเชื่อมต่อเพียร์ชั้นลอจิกพื้นฐาน (p2p) และเพียร์เลเยอร์โปรโตคอลชั้นบนสุด (eth):

เมื่อ protocolManager เริ่มทำงาน โหนดจะเริ่มต้นและเรียก NewProtocolManager ก่อน ในระหว่างกระบวนการเตรียมใช้งาน ฟังก์ชัน SubProtocol จะถูกเรียกเพื่อรับช่องทางการอ่านและเขียนข้อความจากดันเจี้ยน p2p.peer จากนั้นสร้างตัวประมวลผลข้อความ Handle, Handle ซึ่งไม่เพียงยอมรับข้อความร้องขอการซิงโครไนซ์เท่านั้นยังยอมรับข้อความการตอบสนองของโหนดอีกด้วย ในเมธอด start ของ protocolManger มันจะเริ่มซิงโครไนซ์ coroutine syncer ปกติ ซึ่งจะเรียก fecher หรือ downloader executor เพื่อทำการซิงโครไนซ์ข้อมูลตามข้อความ การแจ้งเตือน

• โหมดการซิงโครไนซ์ข้อมูล

• การซิงโครไนซ์ข้อมูลที่แอ็คทีฟหมายความว่าโหนดในเครื่องร้องขอข้อมูลบล็อกจากโหนดที่อยู่ติดกันโดยธรรมชาติ และการป้อนข้อมูลอยู่ใน eth/downloader/downloader และ eth/handler

• การซิงโครไนซ์ข้อมูลแบบพาสซีฟหมายความว่าโลคัลโหนดได้รับข้อความการซิงโครไนซ์ข้อมูล (ข้อความ) จากโหนดอื่น จากนั้นร้องขอข้อมูลบล็อก การป้อนข้อมูลอยู่ที่ eth/fetcher/fetcher.go

• กระบวนการซิงโครไนซ์แบบแอ็คทีฟ ยกตัวอย่างการซิงโครไนซ์แบบแอ็คทีฟ เมื่อเรียกตัวเรียกใช้โปรแกรมดาวน์โหลด ก่อนอื่นจะเรียก findAncestor เพื่อค้นหาบรรพบุรุษร่วมของ local chain และรีโมตเชน และเริ่มการซิงโครไนซ์จากบรรพบุรุษร่วม โดยจะกำหนดค่า fetchers 4 ตัว คือ fetcherHeader และ fetcherBodies , fetcherReceipts, ProcessHeaders เรียก processFullSyncContent และ processFastSyncContent ตามโหมดการซิงโครไนซ์ และสุดท้ายเรียก spawnSync เพื่อดำเนินการซิงโครไนซ์

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

5. กลยุทธ์การซิงโครไนซ์ข้อมูล

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

• lightSync: การซิงโครไนซ์โหนดแสง เมื่อกรอกข้อมูล จะเติมเฉพาะข้อมูลส่วนหัวของบล็อกเท่านั้น ไม่จำเป็นต้องประกอบข้อมูล เรียก insertHeaderchain เพื่อแทรกส่วนหัวของบล็อกโดยตรง

• fullSync: การซิงโครไนซ์แบบเต็มโหนด เมื่อกรอกข้อมูลคุณต้องกรอกส่วนหัวของบล็อกและเนื้อหาของบล็อก แต่อย่ากรอกใบเสร็จธุรกรรม รวบรวมข้อมูลในชุดผลลัพธ์ผลลัพธ์แล้วเรียก importBlockResults เพื่อแทรกข้อมูลใน ผลลัพธ์ที่กำหนดไว้ในห่วงโซ่หลัก และความแตกต่างของ lightSync คือไม่มีตัวบล็อกสำหรับการซิงโครไนซ์ด้วยแสง ดังนั้นมันจะไม่ดำเนินการและตรวจสอบธุรกรรม ในขณะที่การซิงโครไนซ์โหนดแบบเต็มของ fullSync จะดำเนินการและตรวจสอบธุรกรรมในขณะที่แทรกข้อมูล ซึ่งเป็นเหตุผลว่าทำไม ความเร็วในการซิงโครไนซ์ช้า จากนั้นจะสร้างใบเสร็จธุรกรรมด้วยตัวเอง ใบเสร็จรับเงิน ดังนั้นเขาจึงไม่ต้องการใบเสร็จรับเงินเพื่อเข้าร่วมในการกรอกและประกอบ

• 6. บทสรุป

6. บทสรุป

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