บทนำ: การผสานของ EVM bytecode
หมายเหตุบรรณาธิการ: บทความนี้มาจากUnitimes（ID：Uni-times）หมายเหตุบรรณาธิการ: บทความนี้มาจาก
บทคัดย่อ: ลูกค้าไร้สัญชาติต้องส่งรหัสสัญญาอัจฉริยะที่เรียกในบล็อกซึ่งเป็นส่วนหนึ่งของพยานบล็อก รหัสสัญญาเป็นผู้สนับสนุนรายใหญ่อันดับสองสำหรับโอเวอร์เฮดแบนด์วิธบล็อกไร้สัญชาติ เชื่อว่าการ Merkleization รหัสจะช่วยลดค่าใช้จ่ายนี้ บทความนี้จะอธิบายรายละเอียดวิธีที่เราแยกรหัสสัญญาออกเป็นบล็อก Merkleize บล็อกเหล่านี้ (หมายเหตุผู้เขียน: หมายถึงการทำให้บล็อกเหล่านี้กลายเป็น Merkle tree) และส่งเฉพาะบล็อกที่จำเป็นสำหรับการดำเนินธุรกรรม จากการทดลองที่ทำกับ mainnet block ล่าสุด เราจะเห็นว่าวิธีการนี้ช่วยประหยัดการถ่ายโอนรหัสโดยรวม 40-60%
ชื่อเรื่องรอง
บล็อกไร้สัญชาติมีขนาดใหญ่
ภายใต้โมเดลไร้สัญชาติ โหนด (อย่างน้อยบางส่วน) ไม่จำเป็นต้องจัดเก็บสถานะ และพึ่งพาโหนดอื่นๆ (เช่น นักขุด) เพื่อบรรจุในบล็อกสถานะที่จำเป็นทั้งหมด (รวมถึงรหัสสัญญา) และหลักฐานของ Merkle ที่พิสูจน์ความถูกต้องของสถานะเหล่านี้ ซึ่งหมายถึงแบนด์วิธของเครือข่ายที่มากขึ้นกว่าเดิม Alexey Akhunov และทีม turbo-geth[5] ได้ทำการทดลองเพื่อวัดขนาดพยานบล็อกของบล็อก mainnet ในอดีต ด้านล่างนี้คือการวัดสำหรับ 50,000 บล็อกล่าสุด เส้นสีแดงติดตามจำนวนรหัสสัญญาที่ต้องส่งในบล็อกไร้สัญชาติ ซึ่งเป็นแหล่งขนาดใหญ่อันดับสองของขนาดพยานบล็อก หาก Ethereum ย้ายจาก hex trie ปัจจุบันไปเป็น binary trie ส่วนแฮชของพยานเหล่านี้จะลดลงประมาณ 3 เท่า ทำให้รหัสสัญญาเป็นแหล่งที่มาของขนาดพยานหลัก
ข้อมูลจาก GitHub[6] กราฟแสดงองค์ประกอบพยานบล็อกไร้สัญชาติสำหรับบล็อก mainnet ล่าสุด 50,000 รายการ ค่าเหล่านี้เป็นค่าเฉลี่ยเคลื่อนที่ในหน้าต่าง 128 ช่วงตึก
ชื่อเรื่องรอง
ไม่ต้องส่งรหัสเต็ม
เพื่อดูว่ามันทำงานอย่างไร ลองจินตนาการว่ามีการปรับใช้สัญญาใหม่ เราสแกนรหัสสัญญาและระบุบล็อกพื้นฐาน [7] (ดูอัลกอริทึม [8]) (หมายเหตุผู้เขียน บล็อกพื้นฐานสามารถเข้าใจได้ว่าเป็นชิ้นส่วนของรหัสที่ดำเนินการตามลำดับ) โปรดทราบว่าไคลเอ็นต์ต้องสแกนโค้ดเพียงครั้งเดียวสำหรับการวิเคราะห์ JUMPDEST ดังนั้นจึงไม่มีการใช้โอเวอร์เฮดสูง บล็อกพื้นฐานเหล่านี้มีสองลักษณะ:
คำอธิบายภาพ
บล็อกพื้นฐานของรหัสไบต์จินตภาพ
แต่ละบล็อกพื้นฐานเริ่มต้นที่ดัชนี 0 หรือที่ JUMPDEST นี่คือการอนุญาตให้ลูกค้าไร้สัญชาติดำเนินการวิเคราะห์ JUMPDEST ได้อย่างปลอดภัย (เพิ่มเติมในภายหลัง)
แต่ละบล็อกพื้นฐานจะไม่เปลี่ยนโฟลว์การควบคุม (เช่น ไม่มี JUMP) ดังนั้นเราจึงมั่นใจได้ว่าเมื่อเราเริ่มดำเนินการบล็อกพื้นฐาน ไม่ว่าบล็อกนั้นจะดำเนินไปจนสุดหรือจะหมดพลังงานก็ตาม เราคิดว่าโซลูชันนี้จะมีประสิทธิภาพมากกว่า แต่ยังไม่ได้ทดสอบทางเลือกอื่นๆ เพื่อเปรียบเทียบ
เพื่อประสิทธิภาพ บล็อกพื้นฐานที่อยู่ติดกันจะถูกรวมเข้าด้วยกันจนกว่าแต่ละบล็อกพื้นฐานจะมีความยาวขั้นต่ำ 128 ไบต์ (นี่คือพารามิเตอร์ที่กำหนดค่าได้) จากนั้นจึงแทรกลงใน trie โดยใช้ดัชนีของไบต์แรกเป็นคีย์ ในที่สุดลูกค้าจะเก็บรูทของการทดลองนี้ไว้ในบัญชีที่สร้างขึ้นใหม่ที่บันทึกสัญญา ดังที่แสดงด้านล่าง โค้ด trie กลายเป็นทรีย่อยของ state trie (คล้ายกับ storage trie)
ลองทดสอบสิ่งนี้โดยส่งธุรกรรมที่เรียกสัญญา นักขุดทำธุรกรรมและทำเครื่องหมายบล็อกที่สัมผัสระหว่างการดำเนินการ (บล็อก 1 และ 3 ในกรณีนี้) เมื่อเผยแพร่บล็อก นักขุดจะรวมหลักฐานสถานะของบัญชีสัญญาและหลักฐานเทอร์โบในการแตะบล็อกรหัส [9]
คำอธิบายภาพ
หลังจากได้รับการบล็อกแล้ว ไคลเอนต์ไร้สัญชาติสามารถตรวจสอบได้ว่าสัญญาเป็นส่วนหนึ่งของสถานะและมีคุณสมบัติที่ถูกต้อง: สมดุล ค่าไม่มีสถานะ รูทสถานะ และรูทโค้ด จากนั้นจะสามารถตรวจสอบโค้ดบล็อกและคีย์กับโค้ดรูทได้ ข้อมูลข้างต้นเพียงพอสำหรับไคลเอนต์ในการสร้างส่วนของรหัสไบต์ใหม่จากบล็อกเหล่านี้ และปล่อยให้บล็อกอื่นๆ ว่างเปล่า เป็นที่น่าสังเกตว่าตามอัลกอริธึมการแบ่งบล็อกที่เราใช้ ลูกค้ารู้ว่าทุกบล็อก (ยกเว้นบล็อกแรก) เริ่มต้นด้วย JUMPDEST ดังนั้นจึงสามารถกระโดดได้อย่างปลอดภัย
ชื่อเรื่องรอง
การทดลอง
การทดลอง
ชื่อเรื่องรอง
ว่าจะไปที่ไหน
ว่าจะไปที่ไหน
ตามที่คุณจำได้ ความยาวขั้นต่ำของแต่ละบล็อกคือพารามิเตอร์ที่กำหนดค่าได้ (ตั้งค่าเป็น 128 ไบต์ด้านบน) การแก้ไขพารามิเตอร์นี้มีผลกระทบสองประการต่อขนาดของบล็อกพยาน ตัวอย่างเช่น การลดขนาดลงเหลือ 32 ไบต์ทำให้ความละเอียดของบล็อกละเอียดขึ้น จึงช่วยลดจำนวนรหัสทั้งหมดที่ต้องส่ง แต่ในขณะเดียวกัน ความลึกของทรีทรีก็เพิ่มขึ้นด้วย ซึ่งท้ายที่สุดจะนำไปสู่การเพิ่มจำนวนแฮชที่จำเป็นสำหรับการพิสูจน์ ขั้นตอนต่อไปคือการวิเคราะห์อย่างละเอียดมากขึ้นเกี่ยวกับการตั้งค่าขนาดบล็อกขั้นต่ำเพื่อดูว่ามีค่าพื้นที่ที่มีประสิทธิภาพมากที่สุดหรือไม่ โดยไม่คำนึงถึงค่าของขนาดบล็อกขั้นต่ำ การเปลี่ยนจาก Trie เลขฐานสิบหกเป็น Trie ไบนารีจะลดแฮชที่จำเป็นสำหรับการพิสูจน์ลง 1/4 (ดูที่นี่ [11]) และยังลดขนาดของ Block Aspect อีกด้วย ขนาด
สำหรับต้นแบบนี้ เราเลือกที่จะแบ่งโค้ดออกเป็นบล็อกพื้นฐาน แต่มีอัลกอริทึมการแยกแบบอื่นๆ อยู่ บางส่วนก็ง่ายกว่าและบางส่วนก็ซับซ้อนกว่า วิธีที่ง่ายที่สุดคือการแบ่งโค้ดออกเป็นบล็อกขนาดคงที่ (เช่น ทุก ๆ 32 ไบต์สำหรับหนึ่งบล็อก) ปัจจุบัน ปัญหาเดียวของโซลูชันนี้เกี่ยวข้องกับข้อมูล PUSH และการวิเคราะห์ JUMPDEST
การขยายตัวบนพื้นฐานนี้: หากเราแบ่ง bytecode ตามขอบเขตที่กำหนด ตัวถูกดำเนินการของ PUSH opcode และ multibyte opcodes อื่นๆ ที่จะนำมาใช้ในอนาคตอาจถูกเข้าใจผิดว่าเป็น JUMPDEST (0x5b) โดยไคลเอนต์ที่ได้รับการบล็อก ดังที่แสดงด้านล่าง ไคลเอนต์ที่มีรหัสที่สมบูรณ์สามารถเรียนรู้ว่า JUMP ไม่ถูกต้อง (เนื่องจาก 0x5b เป็นตัวดำเนินการของ PUSH1) และหยุดการดำเนินการ อย่างไรก็ตาม ลูกค้าที่ได้รับบล็อก 6 และ 8 แต่ไม่ได้รับบล็อก 7 จะข้ามไปที่ตำแหน่ง 41 ซึ่งแยกวิเคราะห์สัญญาแตกต่างกัน เราจะกล่าวถึงแผนการสั้น ๆ ที่หลีกเลี่ยงปัญหานี้และสนับสนุนขอบเขตตามอำเภอใจในภายหลัง
เพื่อแก้ปัญหานี้ Martin Holst Swende เสนอให้เพิ่มข้อมูลเมตาลงในแต่ละบล็อก โดยระบุจำนวนไบต์ของส่วนหัวที่เป็นตัวดำเนินการของ PUSH จากนั้นตัวตรวจสอบสามารถข้ามไบต์เหล่านี้ระหว่างการวิเคราะห์ JUMPDEST ช่องทางอื่นที่ Alexey กำลังสำรวจคือการปิดใช้งานการกระโดดแบบไดนามิกใน EVM (อย่างน้อยสำหรับสัญญาที่ต้องการรวมโค้ดของพวกเขา) ทำให้เราสามารถวิเคราะห์การกระโดดแบบคงที่ในครั้งเดียวในเวลาปรับใช้แทนที่จะเป็นแต่ละครั้งในระหว่างการเรียกใช้โค้ด Alex Beregszaszi เสนอว่าการใช้กราฟโฟลว์การควบคุมสัญญาสามารถแนะนำ Merkelization ได้ดีขึ้น ในขณะเดียวกัน Christian Reitweissner ได้เสนอแผนการพิสูจน์การดำเนินการซึ่ง Merkleized DAG ถูกสร้างขึ้นจากกราฟโฟลว์ควบคุมของสัญญา ฉันไม่สามารถประเมินความคิดของเขาในบทความนี้ได้อย่างเป็นกลาง และหวังว่าเขาจะสามารถอธิบายเพิ่มเติมได้ในอนาคต
ผลลัพธ์อาจแสดงเพียงประสิทธิภาพที่เพิ่มขึ้นเล็กน้อยสำหรับอัลกอริทึมการแบ่งส่วนที่แตกต่างกัน ในกรณีนี้ อัลกอริทึมที่ง่ายที่สุดจะเป็นทางเลือกที่ฉลาดที่สุด ข่าวดีก็คือเรามีอย่างน้อยหนึ่งอัลกอริธึมที่ดูเหมือนว่าจะลดจำนวนของโค้ดที่ถ่ายโอนในบล็อกไร้สัญชาติจากข้อมูลก่อนหน้าได้อย่างมาก
ลิงค์ต้นฉบับ:
ลิงค์ต้นฉบับ:
ลิงค์อ้างอิง:
