ผู้เขียนต้นฉบับ | Taiko Labs
เรียบเรียงโดย | Odaily Planet Daily ( @OdailyChina )
นักแปล | Dingdang ( @XiaMiPP )
หมายเหตุจากบรรณาธิการ: คุณยังจำความตื่นเต้นเกี่ยวกับการแบ่งส่วนได้หรือไม่? ในเวลานั้น ถือเป็น รหัสผ่านสำหรับการเข้าชม ในอุตสาหกรรมบล็อคเชน ด้วยเหตุนี้ Ethereum จึงพิจารณาเรื่องนี้อย่างใจเย็นและเลิกสนใจเรื่องนี้ วันนี้ Rollup ในพื้นที่ได้กลับมาเป็นที่นิยมอีกครั้ง โดยการดำเนินการตามสัญญาที่คอมไพล์ไว้ล่วงหน้า (EXECUTE Precompile) และการปรับโครงสร้างการประมวลผลบล็อก Ethereum ให้เหมาะสมนั้นไม่เพียงแต่ทำให้ Rollup ปลอดภัยและยืดหยุ่นมากขึ้นเท่านั้น แต่ยังทำให้ Ethereum L1 มีการขยายในแนวนอนมากขึ้นอีกด้วย ซึ่งจะปูทางไปสู่การพิสูจน์แบบเรียลไทม์ในอนาคต
ต่อไปนี้เป็นเนื้อหาต้นฉบับที่เผยแพร่โดย Taiko Lab และแปลโดย Odaily Planet Daily เนื่องจากบทความนี้มีเนื้อหาทางเทคนิคสูง เพื่อให้แน่ใจว่าบทความสามารถอ่านได้ Odaily จึงได้ทำการลบออกอย่างเหมาะสมและนำเสนอให้ชัดเจนและง่ายที่สุด
การแนะนำ
การแบ่งส่วนเป็นหัวข้อร้อนแรงระหว่างปี 2017 ถึง 2020 ในเวลานั้น ทีมงานต่างๆ เช่น Harmony, Zilliqa และ Elrond ได้นำเทคโนโลยีการแบ่งส่วนมาใช้กับบล็อคเชนของพวกเขา เทคโนโลยีนี้จะแบ่งเครือข่ายออกเป็นเครือข่ายย่อยๆ หลายเครือข่ายที่ทำงานขนานกัน (เรียกว่า ชาร์ด) ซึ่งสามารถประมวลผลธุรกรรมพร้อมกันได้ โดยเป็นวิธีที่ตรงไปตรงมาในการปรับขนาดระบบแบบกระจาย
Sharding เป็นอีกหัวข้อหนึ่งที่ได้รับการพูดคุยอย่างจริงจังโดยชุมชนในยุค Ethereum 2.0 อย่างไรก็ตาม ในที่สุด Ethereum ก็ตัดสินใจไม่ใช้โซลูชัน sharding โดยพิจารณาจากความท้าทายสี่ประการดังต่อไปนี้:
1. ความแตกต่างของวิธีคิด
ในโมเดลการแบ่งส่วนนี้ โปรโตคอลจะบังคับใช้จำนวนชิ้นส่วนที่แน่นอนตั้งแต่บนลงล่าง ชาร์ดเหล่านี้เป็นโซ่เดี่ยวๆ ที่ทำงานตามเทมเพลตที่กำหนดไว้ล่วงหน้า ขาดการเขียนโปรแกรม และโดยพื้นฐานแล้วก็เป็นเพียงสำเนาที่เหมือนกันหลายชุดของ L1 (บล็อคเชนเลเยอร์ 1) เท่านั้น
2. ความปลอดภัยที่มองโลกในแง่ดี
ในเวลานั้น การจะแน่ใจถึงความซื่อสัตย์ของชิ้นส่วน จำเป็นต้องมีหลักฐานเชิงบวก แต่เทคโนโลยีความรู้เป็นศูนย์ (ZK) ยังไม่สมบูรณ์ ซึ่งหมายความว่าตรรกะป้องกันการฉ้อโกงจะต้องได้รับการจัดการอย่างเป็นระบบบนเครือข่าย
3. ความซับซ้อน
การนำการแบ่งส่วนข้อมูลไปใช้ในเลเยอร์ L1 จะเพิ่มความซับซ้อนของโปรโตคอลอย่างมาก โดยเฉพาะอย่างยิ่งในการจัดการระบบการยืนยันล่วงหน้าที่รวดเร็วและระบบการยืนยันขั้นสุดท้ายที่ช้า รวมถึงการประสานการแบ่งส่วนข้อมูลที่มีระดับความปลอดภัยที่แตกต่างกัน
4. ความเห็นพ้องเกี่ยวกับการโอเวอร์โหลด
การแสวงหาความสามารถในการปรับขนาดที่สูงขึ้นในเลเยอร์ L1 อาจเพิ่มความเสี่ยงในการรวมศูนย์ หากมีการนำการแบ่งส่วนไปใช้ในเลเยอร์ฐาน ความเสี่ยงนี้จะส่งผลกระทบต่อโปรโตคอลทั้งหมด แทนที่จะจำกัดอยู่แค่ L2 (โซลูชันการปรับขนาดเลเยอร์ที่สอง) เพียงตัวเดียวเหมือนในปัจจุบัน
Native Rollups นั้นสามารถมองได้ว่าเป็นการกลับไปสู่การแบ่งส่วน แต่ครั้งนี้มันจะแตกต่างออกไป เราได้เรียนรู้บทเรียนแล้วและมีความพร้อมด้านเทคโนโลยีและประสบการณ์มากขึ้น
Local Rollup คืออะไร?
โปรดจำไว้ว่า Rollup ประกอบด้วยโมดูลข้อมูล การเรียงลำดับ และการดำเนินการ Local Rollup จะใช้สภาพแวดล้อมการดำเนินการของ Ethereum (Execution Environment) เป็นโมดูลการดำเนินการโดยตรง เราเรียกมันว่า ชิ้นส่วนการดำเนินการที่ตั้งโปรแกรมได้ L1
การทำความเข้าใจวิธีใช้สภาพแวดล้อมการดำเนินการ L1 เป็น Rollup อาจค่อนข้างซับซ้อน เพื่อที่จะใช้สภาพแวดล้อมการดำเนินการ L1 ใน Rollup เราจะต้องสามารถดำเนินการ EVM อื่นภายใน EVM ได้ (EVM ภายใน EVM) ดังนั้น L1 จึงต้องสามารถรับรู้การเปลี่ยนแปลงสถานะของ Rollup ในพื้นที่ในแต่ละบล็อกได้ เพื่อให้บรรลุเป้าหมายนี้ เราต้องมี <สัญญาพรีคอมไพล์> เพื่อให้การสนับสนุน
ดำเนินการตามสัญญาที่รวบรวมไว้ล่วงหน้า
สัญญาที่คอมไพล์ไว้ล่วงหน้า ของ EXECUTE จะให้กลไกที่ทำให้บริบท EVM หนึ่งสามารถตรวจสอบผลลัพธ์การดำเนินการของบริบท EVM อื่นได้ ในขณะที่ยังคงรักษากฎการดำเนินการและตรรกะการเปลี่ยนสถานะไว้เหมือนเดิม
สัญญาที่คอมไพล์ล่วงหน้ายอมรับพารามิเตอร์อินพุตสามรายการ:
pre_state: รูทสถานะ 32 ไบต์ก่อนดำเนินการ
post_state: รูทสถานะ 32 ไบต์หลังจากการดำเนินการ
witness_trace: การติดตามการดำเนินการ รวมถึงธุรกรรมและหลักฐานการเข้าถึงสถานะ
หัวใจหลักของสัญญาที่คอมไพล์ไว้ล่วงหน้าคือ การยืนยัน : การดำเนินการติดตามจาก pre_state จะสามารถรับ post_state ได้หรือไม่ หากฟังก์ชั่นการเปลี่ยนสถานะถูกต้อง สัญญาที่คอมไพล์ไว้ล่วงหน้าจะส่งคืนค่าเป็นจริง
ร่องรอยการดำเนินการต้องพร้อมให้ผู้ตรวจสอบความถูกต้องทั้งหมดใช้ได้ (ในรูปแบบของบล็อบหรือข้อมูลการเรียก) เพื่อให้ผู้ตรวจสอบความถูกต้องสามารถดำเนินการคำนวณซ้ำอีกครั้ง และตรวจยืนยันความถูกต้องของการเปลี่ยนแปลงสถานะได้ ที่น่าสังเกตคือสัญญาที่รวบรวมไว้ล่วงหน้านี้ ไม่ รับการพิสูจน์เป็นอินพุต ซึ่งหมายความว่าโปรโตคอลนั้นไม่ได้บังคับใช้ระบบพิสูจน์เฉพาะใดๆ แต่จะเผยแพร่การพิสูจน์ประเภทต่างๆ ผ่านช่องทาง Gossip ของเครือข่าย p2p แทน
แบบจำลองการเรียกเก็บเงินค่าก๊าซ
Ethereum มีทรัพยากรการประมวลผลที่จำกัด ดังนั้นจึงใช้กลไก Gas ในการจัดการทรัพยากรเหล่านี้ สัญญาที่คอมไพล์ไว้ล่วงหน้า EXECUTE จะนำแบบจำลองการเรียกเก็บเงินค่าก๊าซมาใช้เพื่อจัดการทรัพยากรคอมพิวเตอร์:
ต้นทุนพื้นฐาน : สัญญาที่รวบรวมไว้ล่วงหน้าจะเรียกเก็บค่าธรรมเนียมแก๊สคง ที่ EXECUTE_GAS_COST บวกกับแก๊สที่ใช้ในเส้นทางการดำเนินการคูณด้วยราคาแก๊สปัจจุบัน
ขีดจำกัดแก๊ส สะสม : คล้ายกับกลไก EIP-1559 โดยจะจัดการและกำหนดราคาการใช้แก๊สทั้งหมดของการเรียก EXECUTE ทั้งหมดในบล็อก L1:
EXECUTE_CUMULATIVE_GAS_LIMIT: ขีดจำกัดแก๊สสูงสุดสำหรับการเรียก EXECUTE ทั้งหมดในบล็อก
EXECUTE_CUMULATIVE_GAS_TARGET: เป้าหมายการใช้ก๊าซเพื่อกำหนดราคาที่มีประสิทธิภาพ
โมเดลนี้จะคล้ายคลึงกับกลไกการกำหนดราคาความพร้อมใช้งานของข้อมูล (DA) ในรูปแบบบล็อบ
สิ่งสำคัญคือต้องจำไว้ว่าแนวคิดของ Rollup ในพื้นที่และ SNARKifying L1 มักสับสนกัน L1 แบบ SNARK เป็นวิธีการปรับขนาด ตามแนวตั้ง ซึ่งปรับปรุงประสิทธิภาพของ L1 ด้วยการกำจัดข้อจำกัดของแก๊สผ่านการดำเนินการแบบ SNARK (เช่น zkEVM) และฉันทามติ (เช่น Beam) Rollup ในพื้นที่เป็นการ ปรับขนาดแนวนอน L1 ซึ่งสามารถสร้างสำเนา EVM ได้หลายชุดในลักษณะที่ตั้งโปรแกรมได้เพื่อให้มีความสามารถในการปรับขนาดที่สูงขึ้น
เหตุใด Rollup ในพื้นที่จึงมีข้อได้เปรียบมากกว่า?
1. ความปลอดภัย
การออกแบบ Rollup ในปัจจุบันต้องการให้สภาความปลอดภัยอัปเดตโซ่เพื่อแก้ไขช่องโหว่ที่อาจเกิดขึ้น Rollup ในพื้นที่นั้นอาศัย <Social Consensus> ของ Ethereum เพื่อการกำกับดูแล ผู้ปฏิบัติการไม่จำเป็นต้องกังวลเกี่ยวกับช่องโหว่เนื่องจากชุมชน Ethereum จะเป็นผู้รับผิดชอบในการบำรุงรักษาและการแก้ไข
2. ลดความซับซ้อนของการประกอบแบบซิงโครนัส L1
Rollup ที่ใช้ L1 ใกล้จะบรรลุความสามารถในการจัดวางแบบซิงโครนัสแล้ว แต่ต้องสร้างบล็อค L1 และ L2 พร้อมกันโดยโปรแกรมสร้างเดียวกัน Rollup ในพื้นที่สามารถตรวจสอบสถานะของ Rollup ในพื้นที่อื่นได้โดยตรงผ่านสัญญาที่คอมไพล์ไว้ล่วงหน้าด้วย EXECUTE โดยไม่ต้องมีสมมติฐานความน่าเชื่อถือเพิ่มเติม
3. ความเข้ากันได้ไปข้างหน้า
ในขณะที่ L1 EVM มีการพัฒนา Rollup ในพื้นที่จะสืบทอดการปรับปรุงทั้งหมดโดยอัตโนมัติโดยไม่จำเป็นต้องปรับเปลี่ยนแยกต่างหาก ซึ่งจะทำให้เข้ากันได้ในระยะยาวกับเส้นทางการพัฒนาของ Ethereum
การดำเนินการเบื้องต้น: การดำเนินการซ้ำ
ในบริบทของการรวบรวมในพื้นที่ การดำเนินการซ้ำอีกครั้ง จะถือเป็นการดำเนินการเริ่มต้น การดำเนินการซ้ำหมายถึง การที่ตัวตรวจสอบดำเนินการติดตามธุรกรรมโดยตรง เพื่อตรวจยืนยันว่าการเปลี่ยนแปลงสถานะของ Rollup ในเครื่องนั้นถูกต้องหรือไม่ แทนที่จะต้องพึ่งพาการพิสูจน์ SNARK หาก EXECUTE_CUMULATIVE_GAS_LIMIT ยังคงมีขนาดเล็ก การดำเนินการซ้ำนี้จะยังคงจัดการได้โดยตัวตรวจสอบ
การเพิ่มประสิทธิภาพการดำเนินการ: การพิสูจน์แบบเรียลไทม์
ในโหมดการดำเนินการซ้ำ ผู้ตรวจสอบจะต้องประมวลผลธุรกรรมทั้งหมดด้วยตัวเอง โดยมีปริมาณงานที่รับส่งข้อมูลจำกัดด้วยพารามิเตอร์ EXECUTE_CUMULATIVE_GAS_LIMIT การพิสูจน์แบบเรียลไทม์สามารถปรับปรุงข้อจำกัดนี้ได้อย่างมาก เนื่องจากผู้ตรวจสอบจะต้องยืนยันการพิสูจน์เท่านั้นโดยไม่ต้องดำเนินการธุรกรรมทั้งหมดซ้ำ
เนื่องจากอุตสาหกรรมกำลังมุ่งหน้าสู่การรับรองแบบเรียลไทม์อย่างรวดเร็ว เราจึงต้องดำเนินขั้นตอน เพื่อขยายหน้าต่างการรับรองสำหรับ Rollups ในพื้นที่ เพื่อให้ได้เวลาในการพิสูจน์นานขึ้น จำเป็นต้องปรับโครงสร้างการประมวลผลบล็อก Ethereum ในปัจจุบัน
จะขยายระยะเวลาการรับรองได้อย่างไร?
กระแสการประมวลผลบล็อก Ethereum ในปัจจุบัน
ภายใต้โครงสร้างปัจจุบัน ขั้นตอนทั้งหมดต่อไปนี้จะต้องเสร็จสิ้นภายใน 12 วินาที (หนึ่งขั้นตอนทุกๆ 4 วินาที) ก่อนที่จะเข้าสู่บล็อกถัดไป:
บล็อค N เสนอธุรกรรม
ก่อนที่จะสามารถตรวจสอบ/ยืนยันบล็อกได้ จะต้องดำเนินการดังต่อไปนี้ให้เสร็จสมบูรณ์:
ดำเนินการทุกการค้า
การเปลี่ยนแปลงสถานะการคำนวณ
คำนวณรากสถานะ (stateRoot)
คำนวณการรับและบันทึกรายการธุรกรรม
หลังจากดำเนินการตามขั้นตอนข้างต้นทั้งหมดเสร็จสิ้นแล้ว จึงจะสามารถตรวจยืนยันการบล็อคได้
ภายใต้กระบวนการปัจจุบัน การพิสูจน์จะต้องเสร็จสิ้นภายใน 4 วินาที หากต้องการให้สามารถจัดทำองค์ประกอบแบบซิงโครนัสกับ L1 ได้ อย่างไรก็ตาม เทคโนโลยี ZK ยังไม่สมบูรณ์และไม่สามารถสร้างหลักฐานของบล็อค Ethereum ได้ภายใน 4 วินาที ดังนั้นเราจึงจำเป็นต้องเพิ่มความยืดหยุ่นในกระบวนการพิสูจน์
เพื่อให้ Rollup ในพื้นที่มีเวลาในการพิสูจน์มากขึ้น เราจำเป็นต้องปรับโครงสร้างการประมวลผลบล็อกปัจจุบันของ Ethereum ตัวอย่างเช่น:
การล่าช้าในการคำนวณ state_root: ลบการคำนวณ state_root ออกจากเส้นทางวิกฤต และให้ทำการคำนวณในระหว่างช่วงเวลาที่ไม่ได้ใช้งานตัวตรวจสอบ
การดำเนินการที่ล่าช้า: แยกการตรวจสอบแบบบล็อกจากการดำเนินการธุรกรรม ช่วยเพิ่มประสิทธิภาพของการบรรลุฉันทามติในขณะที่มีเวลาเพิ่มมากขึ้นสำหรับการสร้างหลักฐาน
คำถามที่พบบ่อย
ไทโกะจะใช้หลักฐานแบบไหน?
จะไม่ใช้หลักฐานประเภทเดียว เราต้องการความหลากหลายทั้งในหมู่ผู้พิสูจน์และลูกค้า ผู้ตรวจสอบสามารถตัดสินใจได้ตามความชอบว่าจะใช้วิธีการพิสูจน์ใดตามทางเลือกของตนเอง
ดู EthProofs เพื่อดูประเภทการพิสูจน์ที่หลากหลาย
ใครเป็นคนสร้างหลักฐาน?
ใครก็สามารถสร้างหลักฐานได้ แม้ว่าจะมีผู้รับรองเพียงคนเดียว แต่ห่วงโซ่ยังสามารถทำงานได้ตามปกติ ยังคงมีคำถามที่ยังไม่มีคำตอบ: จะสร้างแรงจูงใจให้กับผู้พิสูจน์ในระดับโปรโตคอลได้อย่างไร
จะมีการลงความเห็นตรงกันในข้อพิสูจน์ต่างๆ หรือไม่?
จะไม่. หลักฐานไม่ได้ตกลงกันว่าจะเป็นแบบบนเครือข่าย แต่เป็นแบบแพร่กระจายไปนอกเครือข่ายแทน สิ่งที่จำเป็นในเครือข่ายคือความเห็นพ้องกันว่ามีหลักฐานที่ถูกต้องอยู่ที่ไหนสักแห่ง
