Vitalik: การวิเคราะห์โครงร่างส่วนขยายของ Rollups - data sharding
แก้ไข: เซาท์วินด์
Vitalik Buterin ผู้ร่วมก่อตั้ง Ethereum
แก้ไข: เซาท์วินด์
สำหรับ Ethereum Rollups เป็นโซลูชันการปรับขยายที่ไม่น่าเชื่อถือเพียงอย่างเดียวในระยะสั้นถึงกลาง และอาจเป็นไปได้ในระยะยาว ค่าธรรมเนียมการทำธุรกรรมบน Ethereum L1 นั้นสูงมาหลายเดือนแล้ว และตอนนี้ยิ่งเร่งด่วนมากขึ้นที่จะต้องดำเนินการใดๆ ก็ตามที่จำเป็นเพื่อช่วยย้ายระบบนิเวศทั้งหมดไปที่ Rollups Rollups มีค่าธรรมเนียมที่ลดลงอย่างมากสำหรับผู้ใช้ Ethereum จำนวนมาก: เว็บไซต์ l2fees.info มักจะแสดงให้เห็นว่าเครือข่าย Optimism และ Arbitrum มีราคาถูกกว่าชั้นฐานของ Ethereum ประมาณ 3-8 เท่า ในขณะที่ zk-Rollups มีการบีบอัดข้อมูลที่ดีกว่า และสามารถหลีกเลี่ยงได้ รวมถึงลายเซ็น ดังนั้นค่าธรรมเนียมจึงต่ำกว่าชั้นฐานของ Ethereum ประมาณ 40-100 เท่า
อย่างไรก็ตาม แม้ว่าค่าธรรมเนียมเหล่านี้ (ใน Rollups) จะมีราคาแพงสำหรับผู้ใช้หลายคนก็ตาม เป็นเวลานานแล้วที่ data sharding (data sharding) ได้รับการพิจารณาว่าเป็นวิธีแก้ปัญหาข้อบกพร่องระยะยาวของ Rollups ในรูปแบบปัจจุบัน และ data sharding คาดว่าจะเพิ่มพื้นที่ข้อมูลเฉพาะประมาณ 1-2MB/s สำหรับ Rollups บน ห่วงโซ่ Ethereum บทความนี้จะอธิบายเส้นทางที่นำไปใช้ได้จริงในการปรับใช้โซลูชัน ปลดล็อกพื้นที่ข้อมูลสำหรับ Rollups โดยเร็วที่สุด และเพิ่มพื้นที่เพิ่มเติมและความปลอดภัยเมื่อเวลาผ่านไป
ขั้นตอนที่ 1: ขยายข้อมูลการโทรของธุรกรรมRollups ที่มีอยู่ในปัจจุบันใช้ calldata ของธุรกรรม ดังนั้น หากเราต้องการเพิ่มความจุของ Rollups และลดค่าใช้จ่ายในระยะสั้นโดยที่ทีม Rollups ต่างๆ ไม่ต้องทำงานเพิ่มเติม เราควรลดต้นทุนแก๊สของธุรกรรมการเรียกข้อมูล ขนาดบล็อกเฉลี่ยในปัจจุบันไม่ได้ใกล้เคียงกับขนาดที่คุกคามความเสถียรของเครือข่าย Ethereum ดังนั้นจึงอาจปลอดภัยที่จะทำเช่นนั้น แม้ว่าอาจต้องใช้ตรรกะเพิ่มเติมเพื่อป้องกันกรณีขอบที่ไม่ปลอดภัยดูEIP-4488 ข้อเสนอ
EIP-4488：
https://github.com/ethereum/EIPs/pull/4488
EIP-4490：
https://github.com/ethereum/EIPs/pull/4490
, หรืออย่างอื่น (ง่ายกว่าแต่อ่อนโยนกว่า)ข้อเสนอ EIP-4490EIP 4488 ควรจะทำได้1 MBแต่ละช่องพื้นที่ข้อมูลที่มีอยู่สำหรับ Rollups จะเพิ่มขึ้นสูงสุดตามทฤษฎีโดยประมาณต้นทุนต่ำกว่าประมาณ 5 เท่า
. ซึ่งสามารถทำได้เร็วกว่าขั้นตอนต่อมา
ชื่อระดับแรกขั้นตอนที่ 2: ชิ้นส่วนหลายชิ้นในระหว่างนี้ เราสามารถเริ่มทำงานบางอย่างเพื่อแผ่ส่วน "ที่เหมาะสม" ออกมา การนำชาร์ดดิ้งไปใช้ในรูปแบบที่สมบูรณ์ (ใช้งานได้) จะใช้เวลานาน แต่สิ่งที่เราทำได้คือนำไปใช้ทีละขั้นตอนและได้รับประโยชน์จากแต่ละขั้นตอน ประการแรก เป็นเรื่องปกติที่จะใช้ "ตรรกะทางธุรกิจ" ของข้อมูลจำเพาะการแบ่งส่วนข้อมูล แต่จำเป็นต้องทำให้จำนวนชาร์ดที่เริ่มใช้งานครั้งแรกต่ำมาก(เช่น 4 ชาร์ด) เพื่อหลีกเลี่ยงปัญหาส่วนใหญ่รอบ ๆ เครือข่ายชาร์ด แต่ละเศษจะอยู่ในตัวของมันเอง
เครือข่ายย่อย
ออกอากาศ. โดยค่าเริ่มต้น Validator จะเชื่อถือคณะกรรมการแต่สามารถเลือกที่จะอยู่ในแต่ละเครือข่ายย่อยได้หากต้องการแต่จะได้รับก็ต่อเมื่อได้เห็นข้อมูลทั้งหมดของ Shard Block ที่ได้รับการยืนยันโดย Beacon Block เท่านั้น
ข้อมูลจำเพาะของชิ้นส่วนนั้นไม่ได้ยากเป็นพิเศษ มีการเปลี่ยนแปลงรหัสสำเร็จรูปที่มีขนาดใกล้เคียงกับ Altair hard fork ที่เพิ่งเปิดตัว (ไฟล์ข้อมูลจำเพาะการเปลี่ยนแปลงสัญญาณของ altair คือ 728 บรรทัด ไฟล์ข้อมูลจำเพาะการเปลี่ยนแปลงสัญญาณของชิ้นส่วนของชิ้นส่วนคือ 888 บรรทัด) ดังนั้นจึงสมเหตุสมผลที่จะ คาดว่าจะสามารถทำได้ในกรอบเวลาที่ใกล้เคียงกับการปรับใช้และการปรับใช้ของ Altair
เพื่อให้ข้อมูลที่แยกออกมาใช้งานได้จริงโดย Rollups นั้น Rollups จะต้องได้รับการพิสูจน์ในข้อมูลที่แยกส่วน มีสองตัวเลือก:
เพิ่มการคอมไพล์ล่วงหน้าสำหรับการเข้าถึงสถานะและประวัติในอนาคต เพื่อให้ Rollups ไม่จำเป็นต้องเปลี่ยนรหัสเมื่อแผนสัญญาผูกมัดมีการเปลี่ยนแปลงในอนาคต
ซึ่งจะเพิ่มพื้นที่ข้อมูลค่าสะสมต่อสล็อตเป็นประมาณ 2 MB (250 kB ต่อชาร์ด * 4 ชาร์ด บวกกับข้อมูลการโทรที่ขยายในขั้นตอนที่ 1 ด้านบน)
ชื่อระดับแรก
เพิ่มจำนวนเศษที่ใช้งานอยู่จาก 4 เป็น 64 ณ จุดนี้ ข้อมูลที่แยกย่อยจะเข้าสู่เครือข่ายย่อย ดังนั้นเลเยอร์ P2P ณ จุดนั้นจึงต้องแข็งแกร่งพอที่จะทำให้แยกออกเป็นเครือข่ายย่อยจำนวนมากขึ้นได้ ความปลอดภัยของความพร้อมใช้งานของข้อมูลจะขึ้นอยู่กับสมมติฐานของคนส่วนใหญ่ (ผู้ตรวจสอบความถูกต้อง) โดยขึ้นอยู่กับความปลอดภัยของคณะกรรมการ
การดำเนินการนี้จะเพิ่มพื้นที่ข้อมูลค่าสะสมต่อช่องเป็นประมาณ 16 MB (250 kB ต่อชาร์ด * 64 ชาร์ด) เราคิดว่าค่าสะสมจะย้ายจากห่วงโซ่การดำเนินการ Ethereum ณ จุดนี้
ชื่อระดับแรก
มีการเพิ่มการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล (DAS) เพื่อให้แน่ใจว่ามีความปลอดภัยในระดับที่สูงขึ้น ช่วยให้ผู้ใช้ได้รับการปกป้องแม้ในกรณีของการโจมตีที่ไม่สุจริต (Validator) ส่วนใหญ่ การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลสามารถทำได้เป็นขั้นๆ ขั้นแรก ด้วยวิธีที่ไม่มีข้อผูกมัดเพื่อให้เครือข่ายทดสอบได้ จากนั้นตามข้อกำหนดในการรับบีคอนบล็อก เป็นไปได้แม้กระทั่งกับไคลเอนต์บางรายก่อน
เมื่อมีการแนะนำการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลอย่างสมบูรณ์ การกระจายชิ้นส่วนจะเสร็จสมบูรณ์
ชื่อระดับแรก
การเปิดเผยในแง่ดีตามแฟรกเมนต์และการยกเลิก ZK
หนึ่งในข้อแตกต่างที่สำคัญระหว่าง Ethereum ปัจจุบันและ Ethereum หลังจากการใช้งาน Sharding ก็คือในโลกของ Sharding นั้น เป็นไปไม่ได้ที่ข้อมูล Rollup จะเป็นส่วนหนึ่งของธุรกรรมที่ส่งบล็อก Rollup ไปยังสัญญาอัจฉริยะ การเผยแพร่ข้อมูลค่าสะสมและการส่งบล็อกค่าสะสมจะต้องแยกจากกัน ขั้นแรก การเผยแพร่ข้อมูลจะใส่ข้อมูลบนเชน (นั่นคือ ลงในเชนชาร์ด) จากนั้นการส่งบล็อกจะส่งส่วนหัวของบล็อกและ หลักฐานที่ชี้ไปยังข้อมูลพื้นฐานZK-SNARKOptimism และ Arbitrum ใช้การออกแบบแบบสองขั้นตอนสำหรับการคอมมิตแบบ Rollup block แล้ว ดังนั้นนี่จะเป็นการเปลี่ยนแปลงโค้ดเล็กน้อยสำหรับทั้งสองอย่าง
ด้วย ZK Rollups สิ่งต่าง ๆ จะยุ่งยากกว่าเล็กน้อย เนื่องจากการทำธุรกรรมจำเป็นต้องแสดงหลักฐานว่าการดำเนินการนั้นดำเนินการกับข้อมูลโดยตรง พวกเขาสามารถผ่านไปได้เพื่อพิสูจน์ว่าข้อมูลในชาร์ดตรงกับข้อผูกมัดบนบีคอนเชน แต่การดำเนินการนี้มีราคาแพงมาก โชคดีที่มีทางเลือกอื่นที่ถูกกว่าหาก ZK-SNARK เป็นแบบ BLS12-381
จากนั้นพวกเขาสามารถจัดแพ็คเกจข้อผูกมัดข้อมูลชิ้นส่วนได้โดยตรงเป็นอินพุต ข้อผูกมัดข้อมูลชิ้นส่วน BLS12-381 เป็นข้อผูกมัดของ KZG ซึ่งเป็นข้อผูกมัดประเภทเดียวกับใน PLONK ดังนั้นจึงสามารถส่งผ่านโดยตรงไปยังการพิสูจน์ในฐานะอินพุตสาธารณะ
หาก ZK-SNARK ใช้กลไกบางอย่างที่แตกต่างกัน (หรือแม้แต่ BLS12-381 PLONK แต่มีการตั้งค่าที่เชื่อถือได้มากกว่า) ก็สามารถรวมข้อผูกมัดข้อมูลของตัวเองและใช้การพิสูจน์ความเท่าเทียมกันเพื่อตรวจสอบว่าข้อผูกมัดในข้อพิสูจน์นั้นเป็นข้อผูกมัดเดียวกัน ข้อมูลเป็นข้อผูกมัดในห่วงโซ่สัญญาณ
ชื่อระดับแรกในโลกที่แตกสลาย ใครจะเป็นผู้จัดเก็บข้อมูลประวัติศาสตร์?เงื่อนไขที่จำเป็นสำหรับการเพิ่มพื้นที่ข้อมูลคือ
ลบคุณสมบัติที่โปรโตคอลหลักของ Ethereum รับผิดชอบในการรักษาข้อมูลทั้งหมดที่เข้าถึงฉันทามติอย่างถาวร
. เนื่องจากจำนวนข้อมูลเหล่านี้มีมากเกินไป ตัวอย่างเช่น:
ขนาดเชนสูงสุดตามทฤษฎีที่ EIP-4488 นำมาคือประมาณ 1,262,861 ไบต์ต่อสล็อต 12 วินาที ซึ่งเท่ากับ 3.0 TB ต่อปี แต่ในทางปฏิบัติมีแนวโน้มที่จะอยู่ที่ประมาณ 250-1,000 GB ต่อปี โดยเฉพาะในช่วงเริ่มต้น
4 ชาร์ด (1 MB ต่อสล็อต) จะเพิ่ม ~2.5 TB ต่อปี
64 ชาร์ด (16 MB ต่อสล็อต) จะทำให้มีพื้นที่เก็บข้อมูลทั้งหมดประมาณ 40 TB ต่อปีผู้ใช้ส่วนใหญ่มีฮาร์ดไดรฟ์ระหว่าง 256 GB และ 2 TB โดยที่ 1 TB ดูเหมือนจะเป็นค่ากลาง กราฟด้านล่างเป็นผลจากการสำรวจภายในที่ดำเนินการโดยกลุ่มนักวิจัยบล็อกเชนเกี่ยวกับพื้นที่ว่างในฮาร์ดไดรฟ์ของคอมพิวเตอร์:ซึ่งหมายความว่าผู้ใช้สามารถเรียกใช้โหนดได้ในขณะนี้ แต่หากมีการปรับใช้ส่วนใดส่วนหนึ่งของแผนงานนี้โดยไม่มีการแก้ไข ผู้ใช้จะไม่สามารถเรียกใช้โหนดได้ แน่นอนว่ามีไดรฟ์ขนาดใหญ่กว่า แต่ผู้ใช้จะต้องพยายามอย่างเต็มที่เพื่อซื้อไดรฟ์เหล่านี้ ซึ่งเพิ่มความซับซ้อนอย่างมากในการเรียกใช้โหนด โซลูชันหลักในปัจจุบันคือ EIP-4444
ข้อเสนอนี้ยกเลิกความรับผิดชอบของผู้ดำเนินการโหนดในการจัดเก็บบล็อกหรือใบเสร็จรับเงินที่เก่ากว่า 1 ปี. ในกรณีของการชาร์ดดิ้ง ระยะเวลา 1 ปีนี้จะสั้นลงอีก และโหนดจะต้องรับผิดชอบชาร์ดบนเครือข่ายย่อยที่เข้าร่วมเท่านั้น
สิ่งนี้ทำให้เกิดคำถาม:ถ้า Ethereum core protocol ไม่เก็บข้อมูลนี้ ใครจะเก็บ?
อันดับแรก สิ่งสำคัญคือต้องจำไว้ว่าแม้จะมีการแบ่งส่วนข้อมูล ปริมาณข้อมูลจะไม่มากขนาดนั้น ใช่ 40 TB ต่อปีนั้นเกินเอื้อมสำหรับฮาร์ดแวร์สำหรับผู้บริโภคที่ใช้งาน "ค่าเริ่มต้น" แต่ละตัว (อันที่จริง แม้แต่ 1 TB ต่อปีก็ยังเป็นเช่นนั้น) อย่างไรก็ตาม สำหรับคนที่ยอมลงทุนทรัพยากรบางส่วนและหาทางเก็บข้อมูลนี้ ถือว่าอยู่ในขอบเขตที่ยอมรับได้ ปัจจุบัน HDD ขนาด 48 TB (ฮาร์ดดิสก์ไดรฟ์) จำหน่ายในราคา 1,729 ดอลลาร์ และ 14 TB ราคาประมาณ 420 ดอลลาร์ คนที่ใช้สล็อตตัวตรวจสอบความถูกต้อง 32 ETH อาจยินดีจ่ายและจัดเก็บเชนทั้งหมดหลังจากใช้การแบ่งส่วนเพื่อรับรางวัล ดังนั้น ในทางปฏิบัติ "ไม่มีใครจะเก็บข้อมูลประวัติของเศษส่วนใดส่วนหนึ่งไว้เพื่อให้ข้อมูลสูญหายโดยสิ้นเชิง"
สถานการณ์นี้ดูเหมือนจะเป็นไปไม่ได้
แล้วใครจะเป็นผู้จัดเก็บข้อมูลนี้? ความคิดของฉันบางส่วน:
อาสาสมัครรายบุคคลและสถาบัน
Block explorer (etherchain.org, etherscan.io, amberdata.io ฯลฯ) จะจัดเก็บข้อมูลทั้งหมดอย่างแน่นอน เนื่องจากเป็นรูปแบบธุรกิจในการให้ข้อมูลแก่ผู้ใช้
Rollup DAO แต่งตั้งและจ่ายเงินให้ผู้เข้าร่วมเพื่อจัดเก็บและให้ข้อมูลประวัติที่เกี่ยวข้องกับ Rollups ของพวกเขา
สามารถอัปโหลดและแชร์ข้อมูลย้อนหลังผ่านทอร์เรนต์ได้
ลูกค้าสามารถเลือกสุ่มเก็บข้อมูลประวัติของบล็อกเชนได้ 0.05% (โดยใช้การลบรหัสเพื่อให้ข้อมูลส่วนเล็กๆ หายไปหากลูกค้าจำนวนมากออฟไลน์พร้อมกัน)
ลูกค้าในเครือข่ายพอร์ทัลสามารถสุ่มเก็บส่วนหนึ่งของข้อมูลประวัติของบล็อคเชน และพอร์ทัลเน็ตเวิร์กจะส่งคำขอข้อมูลไปยังโหนดที่เก็บข้อมูลนั้นโดยอัตโนมัติ
การจัดเก็บข้อมูลประวัติสามารถสร้างแรงจูงใจในโปรโตคอล
