ประวัติโดยย่อของ Ethereum Fragmentation Design: จาก "Block" ถึง "Blob"
แหล่งที่มาดั้งเดิม:ทวีตโดย @protolambda
จาก "บล็อก" เป็น "หยด" ความหมายลึกซึ้ง
จาก "บล็อก" เป็น "หยด" ความหมายลึกซึ้ง
"shard chains" ที่เรียกใช้งานได้พร้อม "crosslinks" ออกแล้ว: การใช้งาน EVM ใน beacon chain; โร้ดแมป Ethereum ที่เน้นการรวมศูนย์โดยใช้ "การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล" การปรับขนาดชั้นฐาน Ethereum โดยไม่เพิ่มความซับซ้อนของสภาพแวดล้อมแอปพลิเคชัน แต่คุณจะเรียกเนื้อหาเศษโดยไม่บล็อกข้อมูลเมตาได้อย่างไร
นี่คือสิ่งที่ "blobs" มีประโยชน์ "Blobspace" เป็นชื่อที่ดี!
ให้ฉันแบ่งปันประวัติของการออกแบบ Ethereum sharding:
Sharding (หรือ "เฟส 1") ควรจะเปิดตัวใน "เฟส 2" (สภาพแวดล้อม Beacon Chain Execution) ตามที่วางแผนไว้ก่อนหน้านี้ แต่ก่อน "เฟส 0" (การเปิดตัวบีคอนเชน) จะเห็นได้ชัดว่า mainnet EVM มีลำดับความสำคัญก่อน ในขณะที่การเปิดตัวเลเยอร์การดำเนินการ "เฟส 2" (ewasm?) ยังไม่ปรากฏให้เห็น
ข้อกำหนด "ระยะที่ 1" ถูกเขียนใหม่หลายครั้งก่อน Beacon Chain:
เศษน้อยลง (1024 -> 64)
ไร้กังวลด้วยการสื่อสารแบบข้ามชาร์ด (ครอสลิงค์)
การออกแบบการป้องกัน escrow ใหม่ (ลบส่วน escrow ออกเพื่อให้หลักฐานการสูญหายโดยเจตนาหายาก)
ไม่ต้องพูดถึงงานวิจัยการชาร์ดดิ้งก่อนหน้านี้ พูดตามตรง งานวิจัยเหล่านั้นมีความเป็นนามธรรมและทะเยอทะยานมาก: การส่งข้อความข้ามโดเมน สภาพแวดล้อมการดำเนินการที่มีความละเมียดละไม การเข้าถึงไดนามิกไร้สัญชาติ คณะกรรมการการแบ่งกลุ่ม ฯลฯ L1 มีความซับซ้อนมากขึ้น และ L1 เริ่มแข็งตัวแล้ว
อย่างไรก็ตาม หาก L1 มุ่งเน้นไปที่การแก้ปัญหาข้อมูลเท่านั้น ปัญหาส่วนใหญ่ที่กล่าวถึงข้างต้นจะแปลเป็นปัญหาการพัฒนา L2 และการสุ่มตัวอย่าง (การสุ่มตัวอย่าง) เพียงแค่แก้ปัญหาข้อมูล L1 จะเกิดอะไรขึ้นถ้าเราสามารถรองรับการทำงานเพิ่มเติมที่เลเยอร์เครือข่ายได้...
ดังนั้นในวันที่ 14 ตุลาคม 2020 นักพัฒนาจึงมีการประชุมทางโทรศัพท์เกี่ยวกับ "ปัญหาการเชื่อมต่อเครือข่ายระยะที่ 1 (เครือข่าย)" หลังจากการอภิปรายสรุปได้ว่า: ซุบซิบซับร้อนแรงมาก + DHT ดูเหมือนจะช้า แต่ในเวลานั้น ยังเป็นวันแรก นักพัฒนาเว็บทุกคนยังคงยุ่งอยู่กับการเตรียมการเปิดตัว beacon chain (วันที่ 1 ธันวาคม!) และเนื่องจากการพัฒนาล่าสุดในขณะนั้นทำให้เกิดช่องว่างที่เห็นได้ชัดในเลเยอร์เครือข่าย ลำเอียง
อคติในขณะนั้น:
Gossipsub = hot, mainnet ready (ไม่มีปัญหาอะไรมาก ยกเว้นปัญหา DoS บางอย่าง และปัญหาเหล่านี้ก็ถูกค้นพบ/เปิดเผยก่อนที่จะเปิดตัว mainnet)
Discv5 = ไม่สมบูรณ์ ต้องการการโยกย้ายเครือข่ายสดจาก 5.0 -> 5.1 ก่อนเปิดตัว mainnet
(https://github.com/protolambda/discv5-catdog)
แต่ทิศทางดูเหมือนชัดเจน: ลดความซับซ้อนของ L1 โซ่บีคอนนั้นซับซ้อนเพียงพอแล้ว ปรับปรุงความสามารถในการปรับขนาดผ่านข้อมูลเท่านั้น ใช้แบบแผน "การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล" ในระยะยาว และปรับใช้โซลูชันการขยาย L2 ดังนั้น Vitalik จึงอธิบายว่าเป็น "Ethereum Roadmap Centered on Rollup" (ฉบับภาษาจีน)
อย่างไรก็ตาม ในขณะที่ผู้ปฏิบัติงานยุ่งอยู่กับการเปิดตัวบีคอนเชน นักวิจัยก็ยุ่งอยู่กับงานหลังการเปิดตัว: Vitalik/Dankrad กำลังทำงานกับร่างการออกแบบความพร้อมใช้งานของข้อมูลในช่วงแรก โดยพยายามทำให้หลักการง่ายขึ้นสำหรับผู้ปฏิบัติให้เข้าใจ
ในเวลาเดียวกัน เราได้เปิดตัวเครือข่ายทดสอบ Zinken, Toledo และ Pyrmont + ตรวจสอบรายการเปิดตัวเพิ่มเติม (ตรวจหาจุดบกพร่อง ฯลฯ) และเราพยายามที่จะติดตามการวิจัยและเริ่มเพิ่มเอกสารการออกแบบสำหรับสิ่งต่าง ๆ ในเลเยอร์เครือข่าย ในขณะนั้น ยังเร็วเกินไปที่จะให้ความสำคัญกับประเด็นเหล่านี้ แต่ DAS (Data Availability Sampling) นั้นดีเกินกว่าจะเพิกเฉย
จากข้อมูลบางอย่างจาก gossipsub ฉันได้เขียนแนวคิดบางอย่างเพื่อใช้กับ DAS เมื่อมองย้อนกลับไป ตอนนี้ฉันคิดว่า DHT เหมาะกับ DAS มากกว่า Gossipsub ยกเว้นบางทีสำหรับการเผยแพร่ครั้งแรก
ในขณะนั้น ฉันคาดว่าข้อกำหนด DAS บางอย่างจะถูกนำไปใช้และจำลอง ฉันคิดว่านี่เป็นครั้งแรกที่กล่าวถึง "blob"? เราใช้คำนี้ในบริบทเช่น "sharded data blobs" และคำนั้นไม่ปรากฏในข้อมูลจำเพาะสำหรับการแบ่งส่วนข้อมูลในตอนนั้น
หลังจากปล่อยบีคอนเชน ฉันมีเวลามากขึ้น จากนั้นฉันก็เขียนแบบร่างที่เพิ่มการพิมพ์และเนื้อหาเลเยอร์เครือข่ายเพิ่มเติมให้กับร่างข้อกำหนดการสุ่มตัวอย่างที่เขียนโดย Vitalik และ Dankrad นำการตั้งชื่อหยดเข้าสู่ข้อมูลจำเพาะของเศษ :)
บางสิ่งเปลี่ยนไปในปี 2021: โครงสร้าง p2p ในอุดมคติที่ออกแบบมาสำหรับมันนั้นซับซ้อนเกินไป ดังนั้นฉันจึงลองใช้เครื่องมือที่สนับสนุน (go-kzg) และเข้าร่วมในการผสานรวมในช่วงต้น (rayonism) จากนั้นลองอีกครั้งในฤดูร้อนเพื่อเข้าร่วมงานวิจัยเกี่ยวกับการแยกชิ้นส่วน แทนที่จะทำงานในการพัฒนาการอัปเกรด Altair/London
Blobs กลับมาอีกครั้ง คราวนี้มีโครงสร้างคล้าย PBS มากขึ้น ซึ่งรวมลายเซ็น BLS ของผู้สร้าง blob และผู้เสนอ blob ยังคงซับซ้อนเกินไป: ดังนั้น การออกแบบการแบ่งส่วนข้อมูลจึงพัฒนามาเป็น "ผู้เสนอบีคอนเป็นศูนย์กลาง" โดยหลักแล้วจะเป็น "เฉพาะ" ปัญหาเลเยอร์เครือข่ายเท่านั้น
นี่เป็นเหมือนการออกแบบที่ห้าสำหรับการแยกย่อยในทางใดทางหนึ่ง? ความมินิมอลเป็นสิ่งที่ต้องมอบให้มากมาย แต่ผลลัพธ์ที่ได้นั้นสวยงามและทรงพลัง: การออกแบบโมดูลาร์ที่มากขึ้น บรรจุภัณฑ์ และความซับซ้อนที่เลือกได้ Rollup ดึงดูดความสนใจของฉันโดยเฉพาะการมองโลกในแง่ดี
สิ้นปี 2022 EIP 4488 (อย่าสับสน ไม่ใช่ 4844!) และ 4490: ผู้คนเริ่มหมดความอดทน และค่าใช้จ่ายของ calldata จะต้องลดลงอย่างรวดเร็วเพื่อให้สามารถแข่งขันได้! การสนทนาในหัวข้อเหล่านี้ยังมีชีวิตชีวาที่ All Core devs หลังจากการอัปเกรดในลอนดอน แต่สิ่งนี้ไม่ยั่งยืนในความคิดของฉันเพราะ calldata มาพร้อมกับโอเวอร์เฮดดั้งเดิมที่ L2 ไม่ต้องการ
ในขณะเดียวกัน Vitalik และ Dankrad ยังคงทำงานเกี่ยวกับการออกแบบ Sharding ใหม่บางอย่าง: ศูนย์กลางของบีคอนที่มากขึ้น, การปรับขนาดผ่านข้อมูลเท่านั้น และมุ่งเน้นไปที่แผนการสุ่มตัวอย่าง ฉันคิดว่า "danksharding" ออกมาจริง ๆ ในช่วงปลาย 21/22 ต้น? ไม่แน่ใจว่าเวอร์ชันแรกคืออะไร Dankrad กำลังทำงานเกี่ยวกับการแยกส่วน
ในตอนต้นของวันที่ 22 Vitalik ได้เสนอสองวิธีที่เราสามารถพัฒนาไปสู่ Darksharding เต็มรูปแบบโดยไม่ต้องใช้การสุ่มตัวอย่าง: เวอร์ชันที่เรียบง่ายและเวอร์ชันที่ซับซ้อน แม้ว่าในความคิดของฉัน นี่เป็นข้อแตกต่างระหว่าง "EL หนัก (ชั้นการดำเนินการ)" และ "การแยก EL และ CL เพื่อความเข้ากันได้ที่ง่ายขึ้นในอนาคต"
ฉันชอบตัวเลือกที่สอง จากนั้นในช่วง EthDenver 2022 เราได้ติดตั้ง EIP-4844: ฉันและ @lightclients ทำงานใน Geth, @asn_d6 ช่วยเหลือ KZG, @adietrichs ที่ทำงานในตลาดค่าธรรมเนียม และทั้งสองอย่างกับ Vitalik/Dankrad Draft EIP ทีม Prysm สร้างต้นแบบ CL ตัวแรก
4844 ได้รับการตั้งชื่อแล้ว"proto-danksharding": ข้อกำหนดเบื้องต้นเพื่อให้ได้การแบ่งส่วนที่สมบูรณ์ แต่ "blobspace" เป็นมีมที่แท้จริง: หลังจากออกแบบ Sharding ซ้ำหลายครั้ง นี่เป็นเวอร์ชันที่ใกล้เคียงกับวิสัยทัศน์ของ Ethereum มากกว่าการออกแบบ Sharding อื่นๆ
สำหรับฉัน Serenity ขั้นนี้เกี่ยวกับ PoS และการออกแบบชิ้นส่วนและการอัปเดตซ้ำๆ เรามีความคืบหน้าในห่วงโซ่บีคอนและการพัฒนาต่างๆ เช่น PBS นอกโปรโตคอล ทำให้เราสามารถเริ่มต้น PoS ได้ดี ฉันคิดว่ามันถึงเวลาแล้วสำหรับการอัพเกรดชิ้นส่วนแรก: 4844!
นอกจากนี้ยังมีฮอตสปอตสำหรับ Darksharding ในอนาคต:
ผลกระทบของเวลาแฝงการรวมข้อมูล L1 ต่อ L2 นั้นประเมินไว้สูงเกินไป
การแลกเปลี่ยนพื้นที่การออกแบบนั้นคุ้มค่าสำหรับแบนด์วิธที่มากขึ้นสำหรับความพร้อมใช้งานของข้อมูล
การนินทาและ TCP DHT นั้นไม่ดี การครอบคลุมคลาส UDP DHT นั้นดี: ทั้งหมดเกี่ยวกับการนับโหนดแสง (เมื่อใดที่ discv5 จะสเกลออก)
ฮอตสปอตเพิ่มเติมของ Danksharding:
การสุ่มตัวอย่างต้องพึ่งพาเพื่อนที่ดีเป็นอย่างมาก ต้องการเห็นการออกแบบที่คำนึงถึงคะแนนเป็นหลักแต่มีประสิทธิภาพมากขึ้น
ชอบการสื่อสารที่ไม่ซับซ้อนและซีบิลมากกว่าการขาดความเป็นส่วนตัวของผู้ตรวจสอบมากกว่า p2p
ZK อาจกลายเป็นเทคโนโลยีต่อต้านแม่มด p2p ในอนาคต แต่ดูเหมือนว่าจะยังห่างไกล
