ข้ามไปยังเนื้อหา
Financial Context Wiki

ไคลเอนต์แบบเบา

คู่มือที่คำนึงถึง fork สำหรับการ bootstrap ไคลเอนต์ฉันทามติแบบเบา, sync committee, weak-subjectivity checkpoint, optimistic และ finalized header, proof ของ state ฝั่ง execution, ผู้ให้บริการ RPC, data availability และความเป็นส่วนตัว

อัปเดต

จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

คำตอบโดยตรง

ไคลเอนต์แบบเบาคือซอฟต์แวร์ตรวจสอบที่ติดตามบล็อกเชนโดยประมวลผลและเก็บ state กับข้อมูลย้อนหลังไว้ในเครื่องน้อยกว่าโหนดแบบเต็ม ส่วนโหนดแบบเบาคืออุปกรณ์หรือกระบวนการที่ใช้ซอฟต์แวร์ดังกล่าว สำหรับ Ethereum แบบ proof-of-stake ไคลเอนต์ฉันทามติแบบเบาจะ bootstrap จาก checkpoint ล่าสุดที่ finalized และเชื่อถือได้ จากนั้นตรวจสอบการอัปเดตของ sync committee โดยคำนึงถึง fork เพื่อดูแล optimistic header และ finalized header โดยไม่รันธุรกรรม EVM ทุกธุรกรรมซ้ำ

มุมมองฉันทามติที่ตรวจสอบแล้วเป็นเพียงหลักยึดความเชื่อถือชั้นแรก หากต้องการตรวจสอบค่าของบัญชีหรือ storage ของสัญญา ไคลเอนต์ต้องเชื่อม beacon header ที่ยืนยันแล้วกับ execution payload header เลือก stateRoot ของ payload นั้น และตรวจ proof ของบัญชีหรือ storage เทียบกับ root ดังกล่าว คำตอบ RPC ทั่วไปที่ไม่มี proof ตามที่ต้องการยังคงเป็นเพียงคำยืนยันจากผู้ให้บริการ ลายเซ็นฉันทามติไม่ได้พิสูจน์ประวัติธุรกรรม receipt, trace, data availability, พฤติกรรมของแอป หรือการเรียกค้นข้อมูลระยะยาวโดยอัตโนมัติ

วิธีการทำงาน

  1. กำหนดเครือข่ายและ trust root ให้แน่นอน ได้แก่ chain identity, genesis validators root และเวลา genesis, ตาราง fork และ preset, เวลาปัจจุบัน, เวอร์ชันไคลเอนต์ และ weak-subjectivity checkpoint ล่าสุดที่เชื่อถือได้และ finalized ตรวจทาน checkpoint กับแหล่งที่มาอิสระซึ่งยืนยันตัวตนแล้ว เพราะการที่ peer เห็นตรงกันไม่อาจแก้ root เริ่มต้นที่เป็นอันตรายได้
  2. รับ LightClientBootstrap สำหรับ trusted block root ตรวจ bootstrap header, sync committee ปัจจุบัน และ Merkle branch ของ committee แล้วเริ่มต้น LightClientStore ปฏิเสธ chain, fork digest, generalized index หรือ serialization schema ที่ไม่ตรงกับ fork ที่กำหนด
  3. ประมวลผลออบเจ็กต์ LightClientUpdate แยกตามช่วงของ sync committee ก่อนหมุนเปลี่ยน committee ให้ตรวจ slot, participation bit, ลายเซ็น BLS แบบรวมและ domain, branch ของ committee ปัจจุบันและชุดถัดไป, finality branch และการเพิ่มขึ้นตามลำดับ การอัปเกรด fork อาจเปลี่ยน field และ generalized index ได้ ค่าคงที่ของ Altair จึงไม่ใช่ค่าถาวรสำหรับทุก fork
  4. ใช้นโยบายแยกกันสำหรับ optimistic_header และ finalized_header การอัปเดตแบบ optimistic อาจใหม่กว่าแต่เสี่ยงต่อ reorganization หรือการกักข้อมูลมากกว่า ส่วนการอัปเดตที่ finalized มีสถานะฉันทามติแข็งแรงกว่าแต่อาจล่าช้า แอปต้องเลือก header ที่เหมาะสมอย่างชัดเจน ไม่ใช่เรียกคำตอบล่าสุดว่า finalized
  5. ผูกข้อมูล execution เข้ากับหลักยึด ตรวจ execution payload header และ branch ที่อยู่ใน light-client header ซึ่งยืนยันแล้ว จากนั้นผูกคำถามเกี่ยวกับบัญชีหรือ storage ทุกครั้งกับ execution stateRoot, block hash และสถานะ finality ที่ตรงกัน สำหรับ Ethereum นั้น eth_getProof สามารถคืน proof ของบัญชีและ storage ที่ร้องขอได้ จึงต้องตรวจ node, path, ค่า และการไม่มีอยู่จริงในเครื่อง
  6. ทำบัญชีพื้นผิวที่ยังไม่ได้ตรวจสอบทั้งหมด Proof ของยอดคงเหลือไม่ได้ยืนยัน transaction receipt, การค้น log, trace, call simulation, mempool, ป้ายชื่อ token, oracle, blob, ช่วงข้อมูลย้อนหลัง หรือคำอ้างของผู้ให้บริการว่าไม่ได้ละผลลัพธ์ สำหรับออบเจ็กต์แต่ละชนิดให้กำหนด proof, การสร้างซ้ำอย่างอิสระ, ทางสำรองด้วยโหนดแบบเต็ม หรือข้อสมมติเรื่องความเชื่อถืออย่างชัดเจน
  7. ดำเนินงานแบบ fail-closed บันทึก checkpoint, fork, optimistic และ finalized root, execution block และ state root, proof node, ผู้ให้บริการ และ timestamp กำหนดอายุข้อมูลสูงสุด กระจายผู้ให้บริการและเส้นทางเครือข่าย ปกป้องความเป็นส่วนตัวของคำค้น ทดสอบการกู้คืนจาก eclipse และ outage และใช้โหนดแบบเต็มหรือระบบตรวจสอบอื่นเมื่อขอบเขต proof ของไคลเอนต์แบบเบาไม่เพียงพอ

ตัวอย่างคำนวณ

  • ขอบเขตจำนวนเต็มของ sync committee สำหรับ committee ขนาด 512 คน การทดสอบ supermajority ตามข้อกำหนดคือ participants * 3 >= 512 * 2 เมื่อมีผู้เข้าร่วม 341 คน จะได้ 341 / 512 = 66.6015625% และ 1,023 < 1,024 จึงไม่ผ่าน เมื่อมี 342 คน จะได้ 342 / 512 = 66.796875% และ 1,026 >= 1,024 จึงผ่าน ผลนี้ตรวจเฉพาะกฎของการอัปเดตที่กำหนด ไม่ได้พิสูจน์ว่าสมาชิกหรือ implementation ทุกชุดซื่อสัตย์
  • เวลาของ header สมมติ checkpoint อยู่ที่ slot 10,000, attested header อยู่ที่ 10,064 และ finalized header ของมันอยู่ที่ 10,032 เมื่อใช้ 12 seconds/slot attested header จะตาม checkpoint อยู่ 64 * 12 = 768 seconds = 12 minutes 48 seconds ส่วน finality ตามหลัง attested header อยู่ 32 * 12 = 384 seconds = 6 minutes 24 seconds ระยะเวลาของ slot ไม่รับประกันการส่งผ่านเครือข่ายหรือ finality ภายใน SLA ตามเวลาจริงที่ตายตัว
  • Branch เล็กแต่ขอบเขตคำยืนยันแคบ ใน tree สมดุลเชิงอุดมคติที่มี leaf 2^20 รายการ branch ของ leaf เดียวมี sibling hash 20 ค่า เมื่อใช้ 32 bytes/hash จะมีขนาด 640 bytes เทียบกับออบเจ็กต์ 8 MiB = 8,388,608 bytes แล้ว branch มีขนาด 0.00762939453125% หรือเล็กลง 99.99237060546875% Branch พิสูจน์เพียงความสัมพันธ์จาก leaf ถึง root ไม่ได้พิสูจน์ว่า byte ที่เหลือพร้อมใช้งาน
  • Proof เทียบกับ RPC ที่ไม่มี proof ณ execution stateRoot ที่ finalized แล้ว proof ของบัญชีซึ่งตรวจสอบได้ให้ค่า 3.25 ETH ขณะที่คำตอบ RPC ที่ไม่มี proof ระบุ 3.30 ETH ส่วนต่างคือ 0.05 ETH และคำตอบที่ไม่มี proof สูงกว่า 0.05 / 3.30 = 1.5151515152% ให้ยอมรับค่าที่พิสูจน์ภายใต้ root ที่เลือก แต่อย่าสรุปยอดในเวลาถัดมา receipt, ผลย้อนหลัง หรืออัตลักษณ์ของ token จาก proof นั้น

ความเสี่ยง

  • กำหนด chain, genesis validators root, genesis time หรือ preset ผิด
  • Bootstrap จาก checkpoint ที่เป็นอันตราย เก่าเกินไป หรือยังไม่ finalized
  • ใช้ checkpoint จากแหล่งเดียวที่ไม่ยืนยันตัวตน หรือยอมรับ long-range fork
  • นาฬิกาในเครื่องคลาดเคลื่อนจนตัดสิน slot, period, domain หรือความเก่าของข้อมูลผิด
  • ใช้ตาราง fork, object schema หรือ generalized index ที่ล้าสมัย
  • ไม่ตรวจ participation ของ sync committee, ลายเซ็น BLS หรือ domain
  • พลาดการหมุน committee หรือยอมรับ committee ปัจจุบันหรือชุดถัดไปที่ไม่ถูกต้อง
  • ถือว่า optimistic header เป็น finalized header
  • เชื่อม beacon header, execution payload หรือ execution block hash ผิดรายการ
  • ตรวจ proof ของบัญชีหรือ storage เทียบกับ stateRoot ผิดค่า
  • ยอมรับ trie node, path, encoding หรือ nonexistence proof ที่ผิดรูป
  • ถือว่าวิธี RPC ที่ไม่รองรับหรือไม่มี proof เป็นข้อมูลที่ตรวจสอบแล้ว
  • ได้คำตอบจากผู้ให้บริการที่เก่า ถูกปิดกั้น ไม่ครบ หรือสร้างขึ้น
  • ถูก eclipse, Sybil หรือความล้มเหลวจากการควบคุมร่วมของผู้ให้บริการที่ดูเหมือนต่างกัน
  • สูญเสีย liveness เมื่อโหนดแบบเต็มที่ให้ proof ทำ pruning หรือหยุดให้ข้อมูล
  • สับสนระหว่างความถูกต้องของฉันทามติกับการรัน execution ซ้ำหรือความถูกต้องของแอป
  • สับสนระหว่าง proof ที่ถูกต้องกับ data availability หรือการเรียกค้นได้ถาวร
  • ไม่มี receipt, log, trace, body หรือข้อมูลย้อนหลังที่แอปต้องใช้
  • การทำงานผิดพลาดของ implementation, dependency, binary หรือการอัปเกรด fork
  • ข้อมูลคำค้น IP บัญชี และธุรกรรมรั่วไหลไปยังผู้ให้บริการหรือ peer

ความเข้าใจผิดที่พบบ่อย

  • ไคลเอนต์แบบเบาเป็นเพียงโหนดแบบเต็มที่เล็กลง หรือเป็นชื่อใหม่ของ RPC ระยะไกล
  • Sync-committee header ที่ตรวจสอบแล้วทำให้คำตอบ RPC ทุกคำตอบเชื่อถือได้
  • Optimistic header ล่าสุดเทียบเท่ากับ finalized header
  • Merkle proof หรือลายเซ็นฉันทามติพิสูจน์ data availability และความครบถ้วนของประวัติ
  • การใช้ไคลเอนต์แบบเบาให้ความเป็นส่วนตัว liveness และการต้าน censorship เท่าโหนดแบบเต็มโดยอัตโนมัติ

หัวข้อที่เกี่ยวข้อง

แหล่งที่มา

การนำทาง

ค้นหาในวิกิ...