เริ่มต้นที่ Ethereum มีกลยุทธ์การขยายมากถึงสองวิธีในโครงการของมัน หนึ่ง (เช่น ดู กระดาษเช้านี้ จากปี 2015) คือ "การแบ่งส่วน": แทนที่จะตรวจสอบและจัดเก็บธุรกรรมทั้งหมดในห่วงโซ่แต่ละโหนดจะต้องตรวจสอบและจัดเก็บธุรกรรมเพียงเล็กน้อยเท่านั้น นี่คือวิธีที่เครือข่ายเพียร์ทูเพียร์อื่น ๆ (เช่น. BitTorrent) ก็ใช้งานได้เช่นกัน ดังนั้นแน่นอนว่าเราสามารถทําให้บล็อกเชนทํางานในลักษณะเดียวกันได้ อีกอย่างคือโปรโตคอลเลเยอร์ 2: เครือข่ายที่จะอยู่ด้านบนของ Ethereum ในลักษณะที่ช่วยให้พวกเขาได้รับประโยชน์อย่างเต็มที่จากความปลอดภัยในขณะที่เก็บข้อมูลและการคํานวณส่วนใหญ่ออกจากห่วงโซ่หลัก "โปรโตคอลเลเยอร์ 2" หมายถึง ช่องสถานะในปี 2015,พลาสม่าในปี 2017 แล้ว แล้วค่าสะสมในปี 2019 โรลอัพมีประสิทธิภาพมากกว่าช่องสถานะหรือ Plasma แต่ต้องใช้แบนด์วิดท์ข้อมูล on-chain จำนวนมาก โชคดีที่ในปี 2019 การวิจัยเชิงชิ้นส่วนได้แก้ปัญหาปัญหาของการตรวจสอบ "ความพร้อมใช้งานของข้อมูล" ในวงกว้างด้วยผลลัพธ์ ทางสองทางรวมตัวกันและเราได้แผนการดำเนินงานที่ใช้ Rollup เป็นศูนย์กลางซึ่งยังคงเป็นกลยุทธ์ในการขยายของ Ethereum ในปัจจุบัน

The Surge, 2023 ฉบับตารางเส้นทาง

แผนเส้นทางที่ให้ความสำคัญกับ rollup предлагает การแบ่งงานอย่างง่าย: Ethereum L1 เน้นไปที่เป็นฐานรากที่แข็งแรงและมีการกระจายอย่างมีประสิทธิภาพในขณะที่ L2s รับหน้าที่ในการช่วยให้ระบบนิเวศขยายตัว นี่คือรูปแบบที่เกิดซ้ำๆทุกที่ในสังคม: ระบบศาล (L1) ไม่ได้จะเร็วและมีประสิทธิภาพสูงมาก มันมีไว้เพื่อป้องกันสัญญาและสิทธิ์ทรัพย์ และมันอยู่ในความรับผิดชอบของผู้ประกอบการ (L2) ที่จะสร้างขึ้นบนบนนั้นแข็งแรงฐานเลเยอร์ และพามนุษย์สู่บรรดาดา (ที่เป็นเรื่องแม่นยำและประสบการณ์) มาร์ส

ปีนี้ แผนภูมิที่เน้น Rollup ได้รับความสำเร็จสำคัญ: แบนด์วิดธ์ข้อมูล Ethereum L1 เพิ่มขึ้นมากEIP-4844 blobs, และมีหลาย EVM rollups ตอนนี้ระหว่างขั้นตอนที่ 1. A very การนำมาใช้โดยหลากหลายและหลากหลายของการแบ่งพิเศษโดยที่แต่ละ L2 ทำหน้าที่เสมือน "shard" ด้วยกฎและตรรกะภายในของตนเอง ตอนนี้กลายเป็นความเป็นจริง แต่เมื่อเราเห็น เราพบว่าการเดินทางนี้มีความท้าทายที่เฉพาะเจาะจงของตัวเอง ดังนั้น ที่เราต้องทำตอนนี้คือ นำโครงการ rollup-centric roadmap สู่ความสมบูรณ์ และแก้ปัญหาเหล่านี้ พร้อมทั้งรักษาความแข็งแรงและการกระจายอำนาจที่ทำให้ Ethereum L1 เป็นพิเศษ

The Surge: จุดประสงค์หลัก

• 100,000+ TPS บน L1+L2
• รักษาความกระจายและความแข็งแกร่งของ L1
• อย่างน้อย L2 บางส่วนสืบทอดคุณสมบัติหลักของ Ethereum อย่างเต็มรูปแบบ (ไว้วางใจได้ โอเพน ต้านการเซ็นเซอร์ชัน)
• ความสามารถในการทำงานร่วมกันสูงสุดระหว่าง L2s Ethereum ควรรู้สึกเหมือนเป็นระบบนึง ไม่ใช่ 34 บล็อกเชนที่แตกต่างกัน

ในบทนี้

• ข้างบน: ปริภูมิของปัญหาที่ยากลำบากในการขยายขอบเขต
• ความคืบหน้าเพิ่มเติมในการสำรวจความพร้อมในการใช้ข้อมูล
• การบีบอัดข้อมูล
• โพลาสมาที่ถูกพัฒนาให้มีความทั่วถึง
• ระบบพิสูจน์ L2 กำลังเจริญ
• ความสามารถในการทำงานร่วมกันระหว่าง L2 และการปรับปรุงประสิทธิภาพ UX
• การขยายการดำเนินการบน L1

ข้อคิด: ประเด็นสามเส้นทางของความยืดหยุ่น

ปัญหาความยืดหยุ่นของตรีเลมมาเปิดตัวในปี 2017, ซึ่งอ้างว่ามีความตึงเครียดระหว่างสามคุณสมบัติของบล็อกเชน: การกระจาย (ที่เฉพาะเจาะจงมาก: ต้นทุนต่ำในการเรียกใช้โหนด), ประสิทธิภาพในการขยาย (ที่เฉพาะเจาะจงมาก: จำนวนการทำธุรกรรมที่มีการประมวลผลสูง), และความปลอดภัย (ที่เฉพาะเจาะจงมาก: ผู้โจมตีจำเป็นต้องทำให้โหนดส่วนใหญ่ในเครือข่ายทั้งหมดเสียหายเพื่อทำให้ธุรกรรมเดียวล้มเหลว)

โดยเฉพาะอย่างยิ่ง trilemma ไม่ใช่ทฤษฎีบทและโพสต์แนะนํา trilemma ไม่ได้มาพร้อมกับหลักฐานทางคณิตศาสตร์ มันให้อาร์กิวเมนต์ทางคณิตศาสตร์แบบฮิวริสติก: หากโหนดที่เป็นมิตรกับการกระจายอํานาจ (เช่นแล็ปท็อปของผู้บริโภค) สามารถตรวจสอบธุรกรรม N ต่อวินาทีและคุณมีห่วงโซ่ที่ประมวลผลธุรกรรม k * N ต่อวินาทีจากนั้น (i) แต่ละธุรกรรมจะเห็นได้เพียง 1 / k ของโหนดซึ่งหมายความว่าผู้โจมตีจะต้องทําให้โหนดเสียหายเพียงไม่กี่โหนดเพื่อผลักดันธุรกรรมที่ไม่ดีผ่าน หรือ (ii) โหนดของคุณจะอ้วนและห่วงโซ่ของคุณไม่กระจายอํานาจ จุดประสงค์ของโพสต์ไม่เคยแสดงให้เห็นว่าการทําลายไตรภูมิเป็นไปไม่ได้ แต่เป็นการแสดงให้เห็นว่าการทําลาย trilemma นั้นยาก - มันต้องคิดนอกกรอบที่อาร์กิวเมนต์หมายถึง

เป็นปกติมากมายในหลายปีที่ผ่านมาที่บางโซ่ที่มีประสิทธิภาพสูงกล่าวอ้างว่าพวกเขาแก้ปัญหาสามแกนโดยที่ไม่ต้องทำอะไรเฉลี่ยที่ระดับสถาปัตยกรรมพื้นฐาน โดยทั่วไปโดยใช้เคล็ดลับในการเขียนซอฟต์แวร์เพื่อปรับปรุงโหนด สิ่งนี้เป็นการคดเคี้ยวเสมอ และการเรียกใช้โหนดในโซ่ที่แบบนี้มักจะทำให้ยากมากกว่าใน Ethereumโพสต์นี้เข้าถึงบางสิ่งที่ซับที่ซับของเหตุผลที่เกิดขึ้น (และด้วยเหตุนั้น ทำไมซอฟต์แวร์เคลียนต์ L1 เองไม่สามารถขยาย Ethereum เองได้)

อย่างไรก็ตาม การผสมการสุ่มความพร้อมใช้ข้อมูลและ SNARKs สามารถแก้ปัญหาทริเลมมาได้: มันช่วยให้ลูกค้าสามารถยืนยันได้ว่ามีปริมาณข้อมูลบางอย่างที่มีอยู่ และมีจำนวนขั้นตอนของการคำนวณที่ถูกต้อง ในขณะที่การดาวน์โหลดเพียงบางส่วนเล็ก ๆ ของข้อมูลนั้น โดยการดำเนินการคำนวณจำนวนมากที่เล็กน้อยมาก ๆ SNARKs เป็นที่น่าเชื่อถือ การสุ่มความพร้อมใช้ข้อมูลมีลักษณะที่ซับซ้อนโมเดลน้อยจาก N โมเดลการเชื่อมั่น, แต่มันยังคงรักษาคุณสมบัติพื้นฐานที่บล็อกที่ไม่สามารถขยายขนาดมี คือ แม้ว่าการโจมตี 51% ก็ไม่สามารถทำให้บล็อกที่ไม่ดีได้รับการยอมรับจากเครือข่าย

วิธีอื่น ๆ ในการแก้ปัญหา trilemma คือ โครงสร้าง Plasma ซึ่งใช้เทคนิคที่ฉลาดเพื่อเน้นความรับผิดชอบในการดูสถานะของข้อมูลไปยังผู้ใช้อย่างเหมาะสมทางสรรพสิ่ง ย้อนกลับไปในปี 2017-2019 เมื่อทุกอย่างที่เรามีสำหรับการขยายมากคำนวณคือการพิสูจน์การโกง Plasma มีข้อจำกัดมากในสิ่งที่มันสามารถทำอย่างปลอดภัย แต่การทำให้ SNARKs เป็นที่นิยมทำให้โครงสร้าง Plasma มีความเป็นไปได้มากขึ้นสำหรับกรณีการใช้งานที่หลากหลายกว่าเดิม

ความคืบหน้าเพิ่มเติมในการสุ่มข้อมูลที่มีให้ใช้

เรากำลังแก้ปัญหาอะไร?

ตั้งแต่ 13 มีนาคม 2024 เมื่อวันที่ อัพเกรด Dencun เริ่มใช้งานจริง Ethereum blockchain มี "blobs" ~ 125 kB สามตัวต่อสล็อต 12 วินาทีหรือ ~ 375 kB ต่อช่องแบนด์วิดท์ความพร้อมใช้งานของข้อมูล สมมติว่ามีการเผยแพร่ข้อมูลธุรกรรมบน onchain โดยตรงการถ่ายโอน ERC20 คือ ~ 180 ไบต์ดังนั้น TPS สูงสุดของ rollups บน Ethereum คือ:

375000 / 12 / 180 = 173.6 TPS

หากเราเพิ่มข้อมูลการโทรของ Ethereum (สูงสุดตามทฤษฎี: 30 ล้านก๊าซต่อสล็อต / 16 ก๊าซต่อไบต์ = 1,875,000 ไบต์ต่อสล็อต) จะกลายเป็น 607 TPS ด้วย PeerDAS แผนคือการเพิ่มเป้าหมายการนับ blob เป็น 8-16 ซึ่งจะทําให้เรา 463-926 TPS ใน calldata

นี่เป็นการเพิ่มขึ้นอย่างมากเหนือ Ethereum L1 แต่ไม่เพียงพอ เราต้องการความสามารถในการปรับขนาดมากขึ้น เป้าหมายระยะกลางของเราคือ 16 MB ต่อสล็อตซึ่งหากรวมกับการปรับปรุงการบีบอัดข้อมูลสะสมจะทําให้เรา ~ 58,000 TPS

มันคืออะไร และมันทำงานอย่างไร?

PeerDAS เป็นการใช้งานที่ค่อนข้างง่ายของ "การสุ่มตัวอย่าง 1D" แต่ละ blob ใน Ethereum เป็นพหุนามองศา -4096 เหนือสนามไพรม์ 253 บิต เราออกอากาศ "หุ้น" ของพหุนามซึ่งแต่ละส่วนแบ่งประกอบด้วยการประเมิน 16 ที่ 16 พิกัดที่อยู่ติดกันซึ่งนํามาจากชุดพิกัดทั้งหมด 8192 การประเมิน 4096 จาก 8192 ใด ๆ (พร้อมพารามิเตอร์ที่เสนอในปัจจุบัน: 64 จาก 128 ตัวอย่างที่เป็นไปได้) สามารถกู้คืน blob ได้

PeerDAS ทำงานโดยการทำให้แต่ละไคลเอ็นต์ฟังบนจำนวนย่อยของเน็ตเวิร์ก ที่ i’th ย่อยกระจาย i’th ตัวอย่างของข้อมูลใดๆ และยังขอข้อมูลบนเน็ตเวิร์กอื่นที่ต้องการโดยการถามเพื่อนร่วมเครือข่าย p2p ทั่วโลก (ผู้ฟังบนเน็ตเวิร์กที่แตกต่างกัน) เวอร์ชันที่ระมัดระวังมากกว่า SubnetDAS, ใช้เฉพาะกลไกเครือข่ายย่อยโดยไม่มีชั้นเสริมในการถามเพื่อนร่วมงาน ข้อเสนอปัจจุบันคือให้โหนดที่มีส่วนร่วมในการพิสูจน์เป็นเจ้าของใช้ SubnetDAS และโหนดอื่น (เช่น ลูกค้า) ใช้ PeerDAS

โดยทฤษฎีแล้ว เราสามารถปรับขนาดการสุ่ม 1 มิติได้ไกลมาก: หากเราเพิ่มจำนวนบล็อบสูงสุดเป็น 256 (ดังนั้น เป้าหมายคือ 128) แล้วเราจะได้เป้าหมายขนาด 16 MB ของเราในขณะที่การสุ่มความพร้อมข้อมูลจะทำให้แต่ละโหนดเสียค่าเพียง 16 ตัวอย่าง 128 blobs 512 ไบต์ต่อตัวอย่างต่อบล็อบ = 1 MB ของแบนด์วิดธ์ต่อช่อง นี่เพียงแค่อยู่ในขอบเขตของความอดทนของเรา: มันเป็นไปได้ แต่มันจะหมายความว่าลูกค้าที่ถูกจำกัดทางแบนด์วิดธ์จะไม่สามารถทดลอง. เราสามารถปรับปรุงสิ่งนี้ให้ดีขึ้นนิดหน่อยโดยลดจำนวนของบล็อบและเพิ่มขนาดของบล็อบ แต่นี่จะทำให้การสร้างภาพสะอาดมีค่าใช้จ่ายมากขึ้น

และดังนั้นเราต้องการไปไกลกว่า และทำการสุ่ม 2 มิติ, ซึ่งทำงานโดยการสุ่มตัวอย่างไม่เพียงแค่ภายในบล็อก แต่ยังระหว่างบล็อกด้วย คุณสมบัติเชิงเส้นของการสมัครสมาชิก KZG ถูกใช้เพื่อ “ขยาย” ชุดของ blobs ในบล็อกด้วยรายการของ “blobs เสมือน” ใหม่ที่เข้ารหัสข้อมูลเดียวกันอย่างซ้ำซ้อน

การสุ่ม 2 มิติ แหล่งที่มา: a16z สกุลเงินดิจิตอล

อย่างสำคัญคือการคำนวณส่วนขยายของการสังฝั่งไม่จำเป็นต้องมี blobs ดังนั้นระบบจึงเป็นมิตรต่อการสร้างบล็อกแบบกระจาย โหนดที่กำลังสร้างบล็อกจะต้องมีการสังฝั่ง KZG commitments เท่านั้นและสามารถพึ่งพา DAS เพื่อตรวจสอบความพร้อมใช้งานของ blobs ได้เอง 1D DAS ยังเป็นมิตรต่อการสร้างบล็อกแบบกระจายโดยอย่างลำเพา

มีลิงก์ไหนบ้างที่เชื่อมโยงไปยังงานวิจัยที่มีอยู่แล้วบ้างคะ?

• โพสต์เริ่มต้นที่นำเสนอความพร้อมใช้งานข้อมูล (2018):https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
• บทความต่อไป: https://arxiv.org/abs/1809.09044
• โพสต์อธิบายเกี่ยวกับ DAS, พาราไดม์https://www.paradigm.xyz/2022/08/das
• การมี 2D พร้อมกับการสร้างข้อผูกพันของ KZG: https://ethresear.ch/t/2d-data-availability-with-kate-commitments/8081
• PeerDAS บน ethresear.ch: https://ethresear.ch/t/peerdas-a-simpler-das-approach-using-battle-tested-p2p-components/16541 และกระดาษ:https://eprint.iacr.org/2024/1362
• การนำเสนอเกี่ยวกับ PeerDAS โดยฟรานเชสโกhttps://www.youtube.com/watch?v=WOdpO1tH_Us
• EIP-7594: https://eips.ethereum.org/EIPS/eip-7594
• SubnetDAS บน ethresear.ch: https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169
• ความละเอียดของการกู้คืนในการสุ่ม 2 มิติ: https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256

มีสิ่งที่เหลืออยู่ที่จะทำ และสิ่งที่ต้องทำสลับกันเป็นอย่างไร

ขั้นตอนถัดไปคือการดำเนินการและการใช้งาน PeerDAS ให้เสร็จสมบูรณ์ จากนั้น จะต้องเริ่มการเพิ่มจำนวน blob บน PeerDAS อย่างเป็นขั้นต่อไปอย่างรวดเร็วโดยต้องระมัดระวังดูแลเครือข่ายและปรับปรุงซอฟต์แวร์เพื่อให้มั่นใจในเรื่องความปลอดภัย ในเวลาเดียวกัน เราต้องการงานทางวิชาการเพิ่มเติมในการทำให้ PeerDAS เป็นรูปแบบที่เป็นทางการและรุ่นอื่น ๆ ของ DAS และปฏิสัมพันธ์ของมันกับปัญหาต่าง ๆ เช่น ความปลอดภัยของกฎการเลือก fork

เข้าสู่อนาคตมากขึ้นเราต้องทำงานมากขึ้นในการหาเวอร์ชันที่เหมาะสมของ 2D DAS และพิสูจน์คุณสมบัติความปลอดภัยของมัน เรายังต้องการที่จะย้ายออกจาก KZG ไปสู่ทางเลือกที่ป้องกันการคาดการณ์ทางได้จากควอนตัมที่ไม่ต้องการการตั้งค่าที่น่าเชื่อถือ ณ ปัจจุบันเราไม่ทราบเกี่ยวกับผู้สมัครที่เป็นมิตรกับการสร้างบล็อกแบบกระจาย แม้ว่าเทคนิคที่แพงอย่าง “การบังคับ” โดยการใช้ STARKs แบบ recursive ในการสร้างการพิสูจน์ความถูกต้องสำหรับการสร้างแถวและคอลัมน์ไม่เพียงพอ เพราะในขณะที่ทางเทคนิค STARK เทคนิคหนึ่งมีขนาด O(log(n) * log(log(n)) ในการแฮช (พร้อมSTIR) ในทางปฏิบัติ STARK เกือบเท่ากับ blob ทั้งหมด

เส้นทางที่เป็นไปได้ตามความเป็นจริงที่ฉันเห็นสำหรับระยะยาวคือ:

• นำไอเดีย 2D DAS มาปฏิบัติ
• ยึดถือกับ 1D DAS ที่เสียเสียแบนด์วิดท์ในการสุ่มและยอมรับปริมาณข้อมูลที่น้อยลงเพื่อความง่ายและความคงทน
• (Hard pivot) ละทิ้ง DA และยอมรับ Plasma อย่างสมบูรณ์เป็นโครงสร้างชั้นที่ 2 หลักที่เรากำลังให้ความสำคัญ

เราสามารถดูเหล่านี้ตามสเปกตรัมการค้าได้

โปรดทราบว่าตัวเลือกนี้ยังมีอยู่ แม้ว่าเราจะตัดสินใจที่จะขยายการดำเนินการบน L1 โดยตรง นี้เป็นเพราะหาก L1 ต้องประมวลผล TPS มากมาย L1 blocks จะกลายเป็นขนาดใหญ่มาก และลูกค้าต้องการวิธีการที่มีประสิทธิภาพในการตรวจสอบว่าถูกต้อง ดังนั้นเราต้องใช้เทคโนโลยีเดียวกันที่ขับเคลื่อน rollups (ZK-EVM และ DAS) ที่ L1

มันจะทำงานร่วมกับส่วนอื่น ๆ ของแผนการดำเนินงานได้อย่างไร?

ความต้องการใน 2D DAS ลดลงเล็กน้อย หรืออย่างน้อยก็เลื่อนหรือล่าช้าลง หากใช้การบีบอัดข้อมูล (ดูด้านล่าง) และลดลงมากขึ้นหาก Plasma ใช้งานอย่างกว้างขวาง DAS ยังเป็นอุปสรรคต่อโปรโตคอลและกลไกการสร้างบล็อกแบบกระจาย: ในขณะที่ DAS เป็นเพื่อนกับการสร้างเบล็อกแบบกระจายตามทฤษฎี สิ่งนี้ต้องร่วมกับการใช้งานในปฏิบัติด้วยรายชื่อที่รวมข้อเสนอและกลไกการเลือก fork ที่รอบ ๆ ของพวกเขา

การบีบอัดข้อมูล

เรากำลังแก้ปัญหาอะไร

ทุกธุรกรรมใน rollup ใช้พื้นที่ข้อมูลใน onchain จำนวนมาก: การโอน ERC20 ใช้ประมาณ 180 ไบต์ แม้ว่าจะมีการสำรวจความพร้อมใช้ข้อมูลในระดับที่สมบูรณ์ นี้ก็จำกัดความสามารถในการขยายของโปรโตคอลชั้น 2 ด้วยการมี 16 MB ต่อสล็อต เราจะได้:

16000000 / 12 / 180 = 7407 TPS

ถ้านอกจากการแก้ไขตัวเศษ ท่านยังสามารถแก้ไขตัวส่วนได้ด้วย และทำให้ธุรกรรมแต่ละรายการใน rollup ใช้อักขระน้อยลงบนเชน

มันคืออะไร และทำงานอย่างไร

คำอธิบายที่ดีที่สุดในความคิดของฉันคือแผนภาพนี้ เมื่อสองปีก่อน

กำไรที่ง่ายที่สุดคือการบีบอัดบิตศูนย์: การแทนที่ลำดับยาวๆ ของบิตศูนย์ด้วยสองบิตที่แทนจำนวนบิตศูนย์ที่มี หากต้องการไปไกลกว่านี้ เราจะใช้ประโยชน์จากคุณสมบัติเฉพาะของธุรกรรม:

• การรวมลายเซ็นเข้าด้วยกัน - เราสลับจากลายเซ็น ECDSA เป็นลายเซ็น BLS ซึ่งมีคุณสมบัติที่สามารถรวมลายเซ็นหลาย ๆ อันเข้าด้วยกันเป็นลายเซ็นเดียวที่ยืนยันความถูกต้องของลายเซ็นต้นฉบับทั้งหมด นี่ไม่ได้ถูกพิจารณาสำหรับ L1 เพราะค่าใช้จ่ายในการตรวจสอบแม้ว่าจะมีการรวมกัน ก็ยังสูงกว่า แต่ในสภาพแวดล้อมที่ขาดแคลนข้อมูลเช่น L2s นั้น พวกเขาน่าจะมีความหมาย คุณลักษณะการรวมกันERC-4337นำเสนอหนึ่งทางสำหรับการนำมาใช้
• การแทนที่ที่อยู่ด้วยตัวชี้ - หากเคยใช้ที่อยู่มาก่อนเราสามารถแทนที่ที่อยู่ 20 ไบต์ด้วยตัวชี้ 4 ไบต์ไปยังตําแหน่งในประวัติศาสตร์ สิ่งนี้จําเป็นเพื่อให้บรรลุผลกําไรสูงสุดแม้ว่าจะต้องใช้ความพยายามในการดําเนินการเพราะต้องใช้ประวัติของบล็อกเชน (อย่างน้อยส่วนหนึ่ง) จึงจะเป็นส่วนหนึ่งของรัฐได้อย่างมีประสิทธิภาพ
• การซีเรียลไร้สายสำหรับค่าธุรกรรม - ค่าธุรกรรมส่วนใหญ่มีหลายหลัก, เช่น 0.25 ETH จะถูกแทนด้วย 250,000,000,000,000,000 วาย Gas max-basefees และค่าธุรกรรมลำดับความสำคัญทำงานในทางเดียวกัน ดังนั้นเราสามารถแทนค่าสกุลเงินส่วนใหญ่อย่างอย่างกระชับด้วยรูปแบบจุดทศนิยมพิเศษหรือแม้กระทั่งพจนานุกรมของค่าที่พบบ่อย

มีลิงก์ไหนบ้างที่เกี่ยวข้องกับงานวิจัยที่มีอยู่แล้ว?

• การสำรวจจาก sequence.xyz: https://sequence.xyz/blog/compressing-calldata
• สัญญาที่ปรับปรุงข้อมูลการเรียกใช้สำหรับ L2s จาก ScopeLift: https://github.com/ScopeLift/l2-optimizoooors
• กลยุทธ์ทางเลือก - การจัดอันดับที่ขึ้นอยู่กับการพิสูจน์ความถูกต้อง (เรียกว่า ZK rollups) โพสต์การแตกต่างของสถานะแทนการทำธุรกรรม: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2-data-footprint-on-l1/9975
• กระเป๋า BLS - การประมวลผลการรวมกลุ่ม BLS ผ่าน ERC-4337: https://github.com/getwax/bls-wallet

เหลืออะไรที่ต้องทำ และต้องทำต่อไปอย่างไร?

สิ่งสำคัญที่เหลืออยู่คือการนำแผนด้านบนไปปฏิบัติจริง ความแตกต่างหลัก ๆ คือ:

• การเปลี่ยนเป็นลายเซ็น BLS ต้องใช้ความพยายามอย่างมาก และลดความเข้ากันได้กับชิปฮาร์ดแวร์ที่เชื่อถือได้ซึ่งสามารถเพิ่มความปลอดภัย การใช้ ZK-SNARK มัดรอบลายเซ็นรูปแบบอื่น ๆ สามารถนำมาใช้แทนได้
• การบีบอัดแบบไดนามิก (เช่น การแทนที่ที่อยู่ด้วยตัวชี้) ทำให้โค้ดของไคลเอ็นต์ซับซ้อนขึ้น
• การโพสต์สถานะต่างๆ ไปยังเชนแทนการทำธุรกรรมจะลดความสามารถในการตรวจสอบ และทำให้ซอฟต์แวร์หลายราย (เช่น ตัวสำรวจบล็อก) ไม่สามารถใช้งานได้

มันทำงานร่วมกับส่วนอื่น ๆ ของแผนงานอย่างไร

การนำ ERC-4337 มาใช้ และในที่สุดจะเอาส่วนหนึ่งของมันมาติดตั้งใน L2 EVMs สามารถเร่งการใช้เทคนิคการรวมข้อมูลได้อย่างมาก เอาส่วนหนึ่งของ ERC-4337 มาติดตั้งบน L1 สามารถเร่งการใช้งานของมันบน L2s ได้อย่างรวดเร็ว

Generalized Plasma

เรากำลังแก้ปัญหาอะไร?

แม้จะมี blobs 16 MB และการบีบอัดข้อมูล 58,000 TPS ไม่จําเป็นต้องเพียงพอที่จะเข้าควบคุมการชําระเงินของผู้บริโภคภาคโซเชียลแบบกระจายอํานาจหรือภาคแบนด์วิดท์สูงอื่น ๆ และสิ่งนี้จะเป็นจริงโดยเฉพาะอย่างยิ่งหากเราเริ่มคํานึงถึงความเป็นส่วนตัวซึ่งอาจลดความสามารถในการปรับขนาดลง 3-8 เท่า สําหรับแอปพลิเคชันที่มีปริมาณมากและมีมูลค่าต่ําตัวเลือกหนึ่งในปัจจุบันคือ validium, ซึ่งเก็บข้อมูลออกจากเชื่อมโยงและมีระบบรักษาความปลอดภัยที่น่าสนใจโดยผู้ดำเนินการไม่สามารถขโมยเงินของผู้ใช้ได้ แต่พวกเขาสามารถหายไปและแช่แข็งเงินของผู้ใช้ทั้งหมดชั่วคราวหรือถาวรได้ แต่เราสามารถปรับปรุงได้ดีกว่านี้

มันคืออะไร และทำงานอย่างไร?

พลาสม่าเป็นโซลูชันการปรับขนาดที่เกี่ยวข้องกับตัวดําเนินการเผยแพร่บล็อก offchain และวางราก Merkle ของบล็อกเหล่านั้น onchain (ตรงข้ามกับ rollups ที่วางบล็อกเต็ม) สําหรับแต่ละบล็อกโอเปอเรเตอร์จะส่งสาขา Merkle ไปยังผู้ใช้แต่ละรายเพื่อพิสูจน์สิ่งที่เกิดขึ้นหรือไม่เกิดขึ้นกับสินทรัพย์ของผู้ใช้รายนั้น ผู้ใช้สามารถถอนสินทรัพย์ได้โดยจัดหาสาขาของ Merkle ที่สําคัญสาขานี้ไม่จําเป็นต้องหยั่งรากในสถานะล่าสุด - ด้วยเหตุนี้แม้ว่าความพร้อมใช้งานของข้อมูลจะล้มเหลวผู้ใช้ยังสามารถกู้คืนสินทรัพย์ของพวกเขาได้โดยการถอนสถานะล่าสุดที่พวกเขามีอยู่ หากผู้ใช้ส่งสาขาที่ไม่ถูกต้อง (เช่น ออกจากสินทรัพย์ที่พวกเขาส่งให้คนอื่นแล้ว หรือผู้ให้บริการเองสร้างสินทรัพย์จากอากาศบาง ๆ ) กลไกการท้าทาย onchain สามารถตัดสินได้ว่าสินทรัพย์นั้นเป็นของใครโดยชอบธรรม

แผนภาพของโซ่ Plasma Cash ธุรกรรมที่ใช้เหรียญ i ถูกใส่ลงในตำแหน่งที่ i ในต้นไม้ ในตัวอย่างนี้ ในกรณีที่ถือว่าต้นไม้ก่อนหน้าทั้งหมดถูกต้อง เราทราบว่าอีฟเป็นเจ้าของเหรียญ 1 ดาวิดเป็นเจ้าของเหรียญ 4 และจอร์จเป็นเจ้าของเหรียญ 6

พลาสม่ารุ่นแรก ๆ สามารถจัดการกรณีการใช้งานการชําระเงินเท่านั้นและไม่สามารถสรุปได้อย่างมีประสิทธิภาพต่อไป หากเราต้องการให้แต่ละรูทได้รับการตรวจสอบด้วย SNARK อย่างไรก็ตาม Plasma จะมีประสิทธิภาพมากขึ้น เกมท้าทายแต่ละเกมสามารถลดความซับซ้อนได้อย่างมากเพราะเราใช้เส้นทางที่เป็นไปได้มากที่สุดสําหรับผู้ให้บริการในการโกง เส้นทางใหม่ยังเปิดขึ้นเพื่อให้เทคนิคพลาสมาสามารถขยายไปยังสินทรัพย์ประเภททั่วไปได้มากขึ้น ในที่สุดในกรณีที่ผู้ให้บริการไม่โกงผู้ใช้สามารถถอนเงินได้ทันทีโดยไม่จําเป็นต้องรอระยะเวลาท้าทายหนึ่งสัปดาห์

วิธีหนึ่ง (ไม่ใช่วิธีเดียว) ในการสร้างห่วงโซ่พลาสม่า EVM: ใช้ ZK-SNARK เพื่อสร้างต้นไม้ UTXO แบบขนานที่สะท้อนถึงการเปลี่ยนแปลงความสมดุลที่ทําโดย EVM และกําหนดแผนที่เฉพาะของสิ่งที่เป็น "เหรียญเดียวกัน" ที่จุดต่างๆ ในประวัติศาสตร์ การก่อสร้างพลาสม่าสามารถสร้างขึ้นได้นอกเหนือจากนั้น

ข้อมูลเชิงลึกที่สําคัญอย่างหนึ่งคือระบบพลาสม่าไม่จําเป็นต้องสมบูรณ์แบบ แม้ว่าคุณจะสามารถปกป้องสินทรัพย์บางส่วนได้เท่านั้น (เช่นแม้แต่เหรียญที่ไม่ได้เคลื่อนไหวในสัปดาห์ที่ผ่านมา) คุณก็ได้ปรับปรุงสถานะที่เป็นอยู่ของ EVM ที่ปรับขนาดได้เป็นพิเศษซึ่งเป็น validium

Another class of constructions is hybrid plasma/rollups, such as Intmax. การก่อสร้างเหล่านี้ใส่ข้อมูลจำนวนเล็กมากต่อผู้ใช้บนเชน (เช่น 5 ไบต์) และด้วยการทำเช่นนั้น ได้คุณสมบัติที่อยู่ระหว่าง plasma และ rollups: ในกรณี Intmax คุณจะได้รับระดับความยืดหยุ่นและความเป็นส่วนตัวระดับสูงมาก แม้กระนั้นในโลกขนาด 16 MB ความจุถูกจำกัดทฤษฎีไปเป็นราว 16,000,000 / 12 / 5 = 266,667 TPS

อะไรคือสิ่งที่เชื่อมโยงไปยังการวิจัยที่มีอยู่?

• เอกสารพลาสม่าเดิม: https://plasma.io/plasma-deprecated.pdf
• พลาสมาแคช: https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298
• Plasma Cashflow: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#🚪-ทางออก
• Intmax (2023): https://eprint.iacr.org/2023/1082

เหลืออะไรให้ทําและการแลกเปลี่ยนคืออะไร?

งานหลักที่เหลืออยู่คือการนําระบบพลาสมาไปสู่การผลิต ดังที่ได้กล่าวมาแล้ว "พลาสมา vs validium" ไม่ใช่ไบนารี: validium ใด ๆ สามารถปรับปรุงคุณสมบัติด้านความปลอดภัยได้อย่างน้อยเล็กน้อยโดยการเพิ่มคุณสมบัติพลาสมาลงในกลไกทางออก ส่วนการวิจัยคือการได้รับคุณสมบัติที่ดีที่สุด (ในแง่ของข้อกําหนดด้านความไว้วางใจและต้นทุนก๊าซ L1 ในกรณีที่เลวร้ายที่สุดและช่องโหว่ต่อ DoS) สําหรับ EVM รวมถึงโครงสร้างเฉพาะการใช้งานทางเลือก นอกจากนี้ความซับซ้อนทางแนวคิดที่มากขึ้นของ Plasma ที่สัมพันธ์กับ rollups จําเป็นต้องได้รับการแก้ไขโดยตรงทั้งผ่านการวิจัยและผ่านการสร้างกรอบการทํางานทั่วไปที่ดีขึ้น

การแลกเปลี่ยนหลักในการใช้การออกแบบพลาสมาคือการที่พวกเขาขึ้นอยู่กับผู้ประกอบการมากกว่า และยากที่จะทำ"ตาม"แม้ว่าการออกแบบพลาสมา/โรลอัพแบบไฮบริดมักจะสามารถหลีกเลี่ยงจุดอ่อนนี้ได้

มันจะทำงานร่วมกับส่วนอื่น ๆ ของแผนโอกาสอย่างไร

ยิ่งโซลูชันพลาสม่ามีประสิทธิภาพมากเท่าไหร่ L1 ก็ยิ่งมีแรงดันน้อยลงเท่านั้นที่จะมีฟังก์ชันความพร้อมใช้งานของข้อมูลที่มีประสิทธิภาพสูง การย้ายกิจกรรมไปยัง L2 ยังช่วยลดแรงดัน MEV บน L1 อีกด้วย

ระบบพิสูจน์ L2 กำลังเจริญ

เรากําลังแก้ปัญหาอะไรอยู่?

วันนี้การโรลอัพส่วนใหญ่ยังไม่น่าเชื่อถือจริง ๆ มีคณะมนตรีความมั่นคงที่มีความสามารถในการลบล้างพฤติกรรมของ (มองโลกในแง่ดีหรือความถูกต้อง) ระบบพิสูจน์ในบางกรณีระบบพิสูจน์ไม่ได้ทำงานอย่างสมบูรณ์เลย หรือถ้ามันทำงานก็มีเพียงฟังก์ชัน “ที่ปรึกษา” เท่านั้น ที่ได้ไปไกลที่สุดคือ (i) บางชุดของ rollups ที่เฉพาะในแอปพลิเคชัน เช่น Fuel ซึ่งเป็นที่เชื่อถือได้ และ (ii) ณ เวลานี้ Optimism และ Arbitrum ทั้งสองเป็น full-EVM rollups ที่ได้รับการยืนยันความเชื่อบางส่วนที่เรียกว่า “stage 1” เหตุผลที่ rollups ไม่ได้ไปไกลกว่านั้นคือความกังวลเกี่ยวกับข้อบกพร่องในโค้ด เราต้องการ rollups ที่เชื่อถือได้ ดังนั้นเราต้องจัดการกับปัญหานี้โดยตรง

มันคืออะไรและทำงานอย่างไร

ก่อนอื่นเรามาทบทวนระบบ "stage" ซึ่งถูกนำเสนอครั้งแรกในโพสต์นี้. มีข้อกำหนดที่ละเอียดมากขึ้น แต่สรุปได้ว่า:

• ขั้นตอนที่ 0: ผู้ใช้ต้องสามารถเรียกใช้โหนดและซิงค์เชนได้ ไม่เป็นไรหากการตรวจสอบถูกเชื่อถือ/ทำซ้ำทั้งหมด
• ขั้นตอนที่ 1: ต้องมีระบบพิสูจน์ (ไม่น่าเชื่อถือ) เพื่อให้แน่ใจว่าเฉพาะธุรกรรมที่ถูกต้องเท่านั้นที่ได้รับการยอมรับ อนุญาตให้มีคณะมนตรีความมั่นคงที่สามารถแทนที่ระบบการพิสูจน์ได้ แต่มีเพียงคะแนนเสียงเกณฑ์ 75% เท่านั้น นอกจากนี้ส่วนที่ปิดกั้นองค์ประชุมของสภา (ดังนั้น 26%+) จะต้องอยู่นอก บริษัท หลักที่สร้างม้วน อนุญาตให้ใช้กลไกการอัปเกรดที่มีคุณสมบัติที่อ่อนแอกว่า (เช่น DAO) แต่ต้องมีความล่าช้านานพอที่หากอนุมัติการอัปเกรดที่เป็นอันตรายผู้ใช้สามารถออกจากเงินทุนก่อนที่จะออนไลน์ได้
• ขั้นที่ 2: จะต้องมีระบบพิสูจน์ (ไร้ความเชื่อถือ) ที่ให้ความมั่นใจว่ามีเพียงธุรกรรมที่ถูกต้องเท่านั้นที่ได้รับการยอมรับ เทศมนตรีความปลอดภัยสามารถที่จะแทรกแซงได้เฉพาะในกรณีของข้อบกพร่องที่สามารถพิสูจน์ได้ในรหัส เช่น หากมีระบบพิสูจน์ที่ไม่จำเป็นต่างกันหรือหากมีระบบพิสูจน์ที่ยอมรับรากซับสถานะสองรากที่แตกต่างกันสำหรับบล็อกเดียวกัน (หรือยอมรับว่าไม่มีอะไรเลยเป็นระยะเวลานานพอ ๆ กับอาทิตย์หนึ่ง) กลไกการอัพเกรดได้รับอนุญาต แต่จะต้องมีความล่าช้ามาก

เป้าหมายคือการเดินทางสู่ ระดับ 2. ความท้าทายหลักในการเดินทางสู่ระดับ 2 คือการมั่นใจเพียงพอว่าระบบพิสูจน์จริงๆ นั้นถูกต้องอย่างเพียงพอ. มีวิธีหลัก 2 ในการทำเช่นนี้:

• การยืนยันอย่างเป็นทางการ: เราสามารถใช้เทคนิคทางคณิตศาสตร์และคอมพิวเตอร์ที่ทันสมัยเพื่อพิสูจน์ว่าระบบพิสูจน์ (เชิงโต้งหรือถูกต้อง) จะยอมรับบล็อกเฉพาะที่ผ่านเข้าสู่สเปก EVM เท่านั้น เทคนิคเหล่านี้มีอยู่มาเป็นเวลาหลายทศวรรย์แล้ว แต่ความก้าวหน้าล่าสุด เช่น ยัน 4ทำให้พวกเขามีประโยชน์มากขึ้น และความก้าวหน้าในการพิสูจน์ด้วยปัญญาประดิษฐ์อาจสามารถเร่งความแน่ใจนี้ไปอีกได้
• Multi-provers: สร้างระบบพิสูจน์หลายระบบและวางเงินใน multisig 2-of-3 (หรือมากกว่า) ระหว่างระบบพิสูจน์เหล่านั้นและคณะกรรมาธิการความปลอดภัย (และ/หรือเครื่องมืออื่น ๆ ที่มีการสมมติเชื่อ เช่น TEEs) หากระบบพิสูจน์ตกลง คณะกรรมาธิการไม่มีอำนาจ หากพวกเขาไม่ตกลง คณะกรรมาธิการสามารถเลือกระหว่างหนึ่งในนั้นเท่านั้น มันไม่สามารถบังคับด้วยความเห็นของตนเอง

แผนภาพเก๋ไก๋ของเครื่องพิสูจน์หลายตัวรวมระบบพิสูจน์ในแง่ดีหนึ่งระบบระบบพิสูจน์ความถูกต้องหนึ่งระบบและสภาความมั่นคง

อะไรคือสิ่งที่เชื่อมโยงไปยังการวิจัยที่มีอยู่?

• EVM K Semantics (formal verification work from 2017): https://github.com/runtimeverification/evm-semantics
• การนำเสนอเกี่ยวกับหลักการของผู้พิสูจน์หลายคน (2022): https://www.youtube.com/watch?v=6hfVzCWT6YI
• Taiko วางแผนที่จะใช้ multi-proofs: https://docs.taiko.xyz/core-concepts/multi-proofs/

เหลืออะไรที่ต้องทำ และต้องเสียสิ่งหนึ่ง

สําหรับการตรวจสอบอย่างเป็นทางการจํานวนมาก เราจําเป็นต้องสร้างเวอร์ชันที่ได้รับการยืนยันอย่างเป็นทางการของ SNARK prover ทั้งหมดของ EVM นี่เป็นโครงการที่ซับซ้อนอย่างไม่น่าเชื่อแม้ว่าจะเป็นโครงการที่ เราได้เริ่มแล้ว. มีเคล็ดลับหนึ่งที่ทําให้งานง่ายขึ้นอย่างมาก: เราสามารถสร้าง SNARK prover ที่ได้รับการยืนยันอย่างเป็นทางการของ VM ขั้นต่ําเช่น RISC-V หรือ ไคโร, แล้วเขียนการปฏิบัติของ EVM ใน VM ที่เรียบง่ายนั้น (และพิสูจน์อย่างเป็นทางการถึงความเท่าเทียมของมันกับข้อมูลอื่น ๆ ของ EVM)

สําหรับ multi-provers มีสองชิ้นหลักที่เหลืออยู่ ประการแรกเราต้องมีความมั่นใจเพียงพอในระบบการพิสูจน์ที่แตกต่างกันอย่างน้อยสองระบบทั้งที่พวกเขาปลอดภัยพอสมควรเป็นรายบุคคลและหากพวกเขาทําลายพวกเขาจะทําลายด้วยเหตุผลที่แตกต่างกันและไม่เกี่ยวข้อง (และดังนั้นพวกเขาจะไม่ทําลายในเวลาเดียวกัน) ประการที่สองเราจําเป็นต้องได้รับความมั่นใจในระดับที่สูงมากในตรรกะพื้นฐานที่รวมระบบพิสูจน์ นี่เป็นโค้ดที่เล็กกว่ามาก มีวิธีที่จะทําให้มันเล็กมาก - เพียงแค่เก็บเงินไว้ใน สัญญา Safe multisigซึ่งผู้ลงนามคือสัญญาที่แทนระบบพิสูจน์แต่ละระบบ - แต่สิ่งนี้มีความแตกต่างของค่าใช้จ่ายแก๊ส onchain สูง จะต้องหาสมดุลระหว่างประสิทธิภาพและความปลอดภัย

มันจะทำงานร่วมกับส่วนอื่น ๆ ของแผนการด้วยวิธีไหน

การย้ายกิจกรรมไปยัง L2 จะลดความดัน MEV บน L1

การปรับปรุงความสามารถในการทำงานร่วมกันระหว่าง L2 ที่เชื่อมโยงกัน

เรากําลังแก้ปัญหาอะไรอยู่?

ความท้าทายหนึ่งในระบบ L2 ในปัจจุบันคือมันยากสำหรับผู้ใช้ในการนำทาง นอกจากนี้วิธีที่ง่ายที่สุดในการทำเช่นนี้ มักจะนำความสมัครใจกลับมา: สะพานที่ทำศูนย์, ลูกค้า RPC, และอื่น ๆ หากเราจริงจังกับความคิดที่ L2 เป็นส่วนหนึ่งของ Ethereum เราต้องทำให้การใช้ระบบ L2 รู้สึกเหมือนกับการใช้ระบบ Ethereum ที่เป็นเอกลักษณ์

ตัวอย่างของ UX ระหว่าง L2 ที่แย่มาก (และอันตราย: ฉันสูญเสีย $100 จากข้อผิดพลาดในการเลือกเชนที่นี่) - แม้ว่านี่จะไม่ใช่ความผิดของ Polymarket การร่วมทำงานระหว่าง L2 ควรเป็นความรับผิดชอบของวอลเล็ตและชุมชนมาตรฐาน Ethereum (ERC) ในระบบนิพจน์ Ethereum ที่ทำงานอย่างดี การส่งเหรียญจาก L1 ไปยัง L2 หรือจาก L2 หนึ่งไปยังอีกตัวควรรู้สึกเหมือนกับการส่งเหรียญภายใน L1 เดียวกัน

มันคืออะไร และมันทำงานอย่างไร?

มีหลายหมวดหมู่ของการปรับปรุงความสามารถในการทำงานร่วมกันระหว่าง L2 โดยทั่วไป วิธีในการคิดถึงเรื่องนี้คือการสังเกตว่าตามทฤษฎีEthereum ที่เน้นการสะสมเป็นสิ่งเดียวกับการแบ่งส่วนการดําเนินการ L1, แล้วถามว่าโลก Ethereum L2 ปัจจุบันมีข้อบกพร่องในทางปฏิบัติอย่างไร นี่คือบางข้อ:

• ที่อยู่เฉพาะโซ่: ห่วงโซ่ (L1, Optimism, Arbitrum ... ) ควรเป็นส่วนหนึ่งของที่อยู่ เมื่อดําเนินการแล้วโฟลว์การส่งข้าม L2 สามารถใช้งานได้โดยเพียงแค่ใส่ที่อยู่ลงในฟิลด์ "ส่ง" ณ จุดนั้นกระเป๋าเงินสามารถหาวิธีส่ง (รวมถึงการใช้โปรโตคอลการเชื่อมโยง) ในพื้นหลัง
• คำขอการชำระเงินที่เฉพาะเคาะ: ควรทำให้ง่ายและมาตรฐานที่จะสร้างข้อความในรูปแบบ "ส่ง X โทเคนประเภท Y ในเชน Z ให้ฉัน" มีกรณีใช้หลักสองกรณี: (i) การชำระเงิน ไม่ว่าจะเป็นบุคคลต่อบุคคลหรือบุคคลต่อบริการร้านค้าและ (ii) dapps ขอเงิน เช่น ตัวอย่าง Polymarket ด้านบน
• การแลกเปลี่ยนข้ามสายโซ่และการชําระเงินด้วยก๊าซ: ควรมีโปรโตคอลแบบเปิดที่เป็นมาตรฐานสําหรับการแสดงการดําเนินการข้ามสายโซ่เช่น "ฉันกําลังส่ง 1 ETH เกี่ยวกับการมองโลกในแง่ดีให้กับใครก็ตามที่ส่ง ETH 0.9999 ให้ฉันบน Arbitrum" และ "ฉันกําลังส่ง 0.0001 ETH เกี่ยวกับการมองโลกในแง่ดีให้กับใครก็ตามที่รวมธุรกรรมนี้ใน Arbitrum" ERC-7683เป็นหนึ่งในพยานเดียวกันที่และRIP-7755เป็นการพยายามที่หนึ่งที่เกี่ยวข้องกับประการหนึ่ง แม้ว่าทั้งสองนั้นยังมีลักษณะทั่วไปมากกว่าเพียงกรณีการใช้เฉพาะเหล่านี้
• Light clients: ผู้ใช้ควรสามารถตรวจสอบเชื่อมโยงที่พวกเขากำลังทำงานกับจริง ๆ และไม่ใช่เพียงแค่ไว้วางใจผู้ให้บริการ RPC เท่านั้น A16z crypto’sHelios ทําสิ่งนี้เพื่อ Ethereum เอง แต่เราจําเป็นต้องขยายความไว้เนื้อเชื่อใจนี้ไปยัง L2s ERC-3668 (CCIP-read)เป็นหนึ่งในกลยุทธ์ที่ใช้เพื่อทำเช่นนี้

ว่า light client สามารถอัพเดทมุมมองของตัวเองเกี่ยวกับ Ethereum header chain ได้อย่างไร หลังจากที่คุณได้รับ header chain แล้ว คุณสามารถใช้ Merkle proofs เพื่อตรวจสอบ state object ใดๆ และหลังจากที่คุณได้ state objects ที่ถูกต้องบน L1 คุณสามารถใช้ Merkle proofs (และบางที signatures ถ้าคุณต้องการตรวจสอบ preconfirmations) เพื่อตรวจสอบ state object ใดๆ บน L2 Helios ทำสิ่งแรกนี้ไปแล้ว การขยายไปสู่สิ่งหลังนั้นเป็นความท้าทายในเรื่องของมาตรฐาน

• กระเป๋าเงิน Keystore: วันนี้หากคุณต้องการอัปเดตกุญแจที่ควบคุมกระเป๋าเงินสัญญาอัจฉริยะของคุณคุณต้องทํากับโซ่ N ทั้งหมดที่มีกระเป๋าเงินนั้นอยู่ กระเป๋าเงิน Keystore เป็นเทคนิคที่ช่วยให้กุญแจมีอยู่ในที่เดียว (ไม่ว่าจะใน L1 หรือใหม่กว่าบน L2) จากนั้นอ่านจาก L2 ใด ๆ ที่มีสําเนาของกระเป๋าเงิน ซึ่งหมายความว่าการอัปเดตจะต้องเกิดขึ้นเพียงครั้งเดียว เพื่อให้มีประสิทธิภาพกระเป๋าเงินคีย์สโตร์ต้องการให้ L2s มีวิธีมาตรฐานในการอ่าน L1 โดยไม่เสียค่าใช้จ่าย สองข้อเสนอสําหรับเรื่องนี้คือ L1SLOADและการเรียกค้างสถานการณ์ที่ไกล.

แผนภาพเก๋ไก๋ของวิธีการทํางานของกระเป๋าเงิน keystore

• แนวคิด "สะพานโทเค็นที่ใช้ร่วมกัน" ที่รุนแรงยิ่งขึ้น: ลองนึกภาพโลกที่ L2 ทั้งหมดเป็นการรวบรวมหลักฐานความถูกต้องซึ่งมุ่งมั่นกับ Ethereum ทุกช่อง แม้แต่ในโลกนี้การย้ายสินทรัพย์จาก L2 หนึ่งไปยังอีก L2 "โดยกําเนิด" จะต้องถอนและฝากซึ่งต้องจ่ายก๊าซ L1 จํานวนมาก วิธีหนึ่งในการแก้ปัญหานี้คือการสร้าง rollup ขั้นต่ําที่ใช้ร่วมกันซึ่งมีหน้าที่เพียงอย่างเดียวคือการรักษายอดคงเหลือของจํานวนโทเค็นที่เป็นเจ้าของโดย L2 และอนุญาตให้ยอดคงเหลือเหล่านั้นได้รับการอัปเดตเป็นจํานวนมากโดยชุดของการดําเนินการส่งข้าม L2 ที่เริ่มต้นโดย L2 ใด ๆ สิ่งนี้จะช่วยให้การถ่ายโอนข้าม L2 เกิดขึ้นได้โดยไม่จําเป็นต้องจ่ายก๊าซ L1 ต่อการโอนหนึ่งครั้งและไม่ต้องใช้เทคนิคที่ใช้ผู้ให้บริการสภาพคล่องเช่น ERC-7683
• การสามารถใช้งานร่วมกันแบบเพียงพอ: อนุญาตให้การเรียกใช้งานเป็นพร้อมกันเกิดขึ้นระหว่าง L2 ที่เฉพาะเจาะจงและ L1 หรือระหว่าง L2 หลายรายการ สิ่งนี้อาจจะเป็นประโยชน์ในการปรับปรุงประสิทธิภาพทางการเงินของโปรโตคอล defi ส่วนแรกสามารถทำได้โดยไม่ต้องมีการประสานงานระหว่าง L2 ส่วนล่างต้องการการเรียงลำดับที่แบ่งปัน.รวมการทำงานฐานเป็นมิตรอัตโนมัติต่อทุกเทคนิคเหล่านี้

มีลิงก์ไหนบ้างที่เชื่อมโยงไปยังงานวิจัยที่มีอยู่แล้ว?

• ที่อยู่เฉพาะกลุ่ม: ERC-3770: https://eips.ethereum.org/EIPS/eip-3770
• ERC-7683: https://eips.ethereum.org/EIPS/eip-7683
• RIP-7755: https://github.com/wilsoncusack/RIPs/blob/cross-l2-call-standard/RIPS/rip-7755.md
• การออกแบบกระเป๋าสตางค์เก็บ Scroll: @haichen/keystore"">https://hackmd.io/@haichen/keystore
• Helios: https://github.com/a16z/helios
• ERC-3668 (ชื่อที่เรียกบางครั้งว่า CCIP-read): https://eips.ethereum.org/EIPS/eip-3668
• ข้อเสนอสำหรับ "การยืนยันก่อน (ที่ถูกแบ่งปัน) โดย Justin Drake:https://ethresear.ch/t/based-preconfirmations/17353
• L1SLOAD (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1sload-precompile/20388
• การเรียกค่าระยะไกลที่ไร้การเชื่อมต่อใน Optimism: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76
• AggLayer, ซึ่งรวมไอเดียสะพานโทเคนร่วม: https://github.com/AggLayer

เหลืออะไรที่ต้องทำ และมีการต่อสู้แบบไหนบ้าง

หลายตัวอย่างด้านบนเผชิญกับความลังเลมาตรฐานเมื่อควรมาตรฐานและเลเยอะไปที่จะมาตรฐานถ้าคุณมาตรฐานเร็วเกินไป คุณอาจเสี่ยงตัวเข้าสู่ผลการทางที่น้อยกว่า หากคุณมาตรฐานช้าเกินไป คุณอาจเสี่ยงทำให้เกิดการแตกแยกที่ไม่จำเป็น ในบางกรณี มีทั้งทางที่เป็นทางส่วนใหญ่ที่มีคุณสมบัติที่อ่อนแอกว่าแต่ง่ายกว่าที่จะปรับใช้ และมีทางที่เป็นทางระยะยาวที่เป็น "ที่ถูกต้องในที่สุด" แต่จะใช้เวลาหลายปีในการเดินทางไปถึงจุดนั้น

วิธีหนึ่งที่ส่วนนี้ไม่เหมือนใครคืองานเหล่านี้ไม่ได้เป็นเพียงปัญหาทางเทคนิค: พวกเขายังเป็นปัญหาสังคม (อาจเป็นหลัก!) พวกเขาต้องการ L2s และกระเป๋าเงินและ L1 เพื่อร่วมมือกัน ความสามารถของเราในการจัดการปัญหานี้ให้ประสบความสําเร็จคือการทดสอบความสามารถของเราในการรวมตัวกันเป็นชุมชน

มันจะทำงานร่วมกับส่วนอื่น ๆ ของโครงการได้อย่างไร?

โครงการส่วนใหญ่เหล่านี้เป็น "โครงสร้างชั้นสูง" และดังนั้นไม่มีผลมากต่อความพิจารณาของ L1 ข้อยกเว้นหนึ่งคือการเรียงลำดับที่ใช้ร่วมกัน ซึ่งมีผลกระทบมากต่อ MEV

การขยายการดำเนินการบน L1

ปัญหาที่เรากำลังแก้ไขคืออะไร?

หาก L2s กลายเป็น scalable และประสบความสำเร็จมาก แต่ L1 ยังคงสามารถประมวลผลเพียงปริมาณเล็กมากของธุรกรรม เกิดความเสี่ยงต่าง ๆ ต่อ Ethereum ที่อาจเกิดขึ้น

1. สถานการณ์ทางเศรษฐกิจของ ETH สินทรัพย์มีความเสี่ยงมากขึ้นซึ่งจะส่งผลต่อความปลอดภัยในระยะยาวของเครือข่าย
2. หลาย L2 ได้รับประโยชน์จากการเชื่อมโยงอย่างใกล้ชิดกับระบบนิเวศการเงินที่พัฒนาอย่างมีระดับสูงบน L1 และหากระบบนิเวศนี้อ่อนแอมาก แรงจูงใจที่จะกลายเป็น L2 (แทนที่จะเป็น L1 อิสระ) ก็อ่อนแอลง
3. จะใช้เวลานานก่อนที่ L2s จะมีความมั่นคงปลอดภัยเหมือนกับ L1 ที่แน่นอน
4. หาก L2 ล้มเหลว (เช่น เนื่องจากผู้ดำเนินการที่มีชั่วร้ายหรือหายไป) ผู้ใช้ยังจำเป็นต้องผ่าน L1 เพื่อกู้คืนสินทรัพย์ของพวกเขา ดังนั้น L1 จำเป็นต้องมีพลังงานเพียงพอที่จะสามารถจัดการกับการลดความซับซ้อนและโลกโซ่ที่รกเร่อของ L2 อย่างน้อยบ้าง

เพื่อเหตุผลเหล่านี้ มันมีคุณค่าที่จะดำเนินการขยายขอบเขต L1 เอง และให้แน่ใจว่ามันสามารถรองรับจำนวนการใช้งานที่เติบโตขึ้นได้ต่อไป

มันคืออะไรและทำงานอย่างไร

วิธีที่ง่ายที่สุดในการปรับขนาดคือการเพิ่มขีด จํากัด ก๊าซ อย่างไรก็ตามสิ่งนี้มีความเสี่ยงที่จะรวมศูนย์ L1 และทําให้คุณสมบัติที่สําคัญอื่น ๆ ที่ทําให้ Ethereum L1 มีประสิทธิภาพมาก: ความน่าเชื่อถือในฐานะชั้นฐานที่แข็งแกร่ง มีการถกเถียงกันอย่างต่อเนื่องเกี่ยวกับระดับของการเพิ่มขีด จํากัด ก๊าซอย่างง่ายที่ยั่งยืนและสิ่งนี้ยังเปลี่ยนแปลงตามเทคโนโลยีอื่น ๆ ที่ถูกนํามาใช้เพื่อให้บล็อกขนาดใหญ่ง่ายต่อการตรวจสอบ (เช่นการหมดอายุของประวัติการไร้สัญชาติการพิสูจน์ความถูกต้องของ L1 EVM) สิ่งสําคัญอีกประการหนึ่งในการปรับปรุงต่อไปคือประสิทธิภาพของซอฟต์แวร์ไคลเอนต์ Ethereum ซึ่งได้รับการปรับให้เหมาะสมกว่าเมื่อห้าปีก่อน กลยุทธ์การเพิ่มขีด จํากัด ก๊าซ L1 ที่มีประสิทธิภาพจะเกี่ยวข้องกับการเร่งเทคโนโลยีการตรวจสอบเหล่านี้

ยกตัวอย่างเช่นยุคที่ผ่านมาการปรับปรุงและการพัฒนาเทคโนโลยีเกี่ยวกับการชำระเงินและการโอนเงินเป็นสิ่งสำคัญที่เป็นที่นิยมในขณะนี้

• EOFรูปแบบ bytecode EVM ใหม่ที่เป็นมิตรกับการวิเคราะห์แบบคงที่มากขึ้น ทำให้การประมวลผลเร็วขึ้น bytecode EOF อาจได้รับค่า gas ต่ำกว่าเพื่อพิจารณาประสิทธิภาพเหล่านี้
• การกำหนดราคาแก๊สหลากมิติการกำหนดค่าฐานแยกต่างหากและขีดจำกัดสำหรับการคำนวณ ข้อมูล และการเก็บข้อมูล สามารถเพิ่มความสามารถเฉลี่ยของ Ethereum L1 โดยไม่เพิ่มความสามารถสูงสุด (และดังนั้นสร้างความเสี่ยงทางความปลอดภัยใหม่)
• ลดค่าแก๊สของโอปโค้ดและการเตรียมการที่เฉพาะเจาะจง - ในประวัติศาสตร์เรามีหลาย รอบของการเพิ่มเติม gas ค่าใช้จ่ายสำหรับการดำเนินการบางรายการที่ถูกตั้งราคาต่ำเพื่อหลีกเลี่ยงการโจมตีปฏิเสธบริการ สิ่งที่เรามีน้อยลง และสามารถทำได้มากขึ้น คือ การลดค่า gas สำหรับการดำเนินการที่ตั้งราคาสูงเกินไป ตัวอย่างเช่น การบวก จะถูกกว่าการคูณ แต่ต้นทุนของ opcodes สำหรับ ADD และ MUL ในปัจจุบันเท่ากัน เราสามารถทำให้ ADD ถูกลง และ opcodes ที่ง่ายยิ่งขึ้น เช่น PUSH ก็จะถูกลง
• EVM-MAXและSIMD: EVM-MAX ("modular arithmetic extensions") เป็นข้อเสนอที่อนุญาตให้การคำนวณโมดูลาร์เลขที่ใหญ่มากขึ้นเป็นอย่างมีประสิทธิภาพมากขึ้นเป็นโมดูลแยกต่างหากของ EVM ค่าที่คำนวณด้วยการคำนวณ EVM-MAX จะสามารถเข้าถึงได้เฉพาะโดยตัวดำเนินการ EVM-MAX อื่น ๆ นอกจากกรณีที่ส่งออกอย่างตั้งใจ ซึ่งนี้จะช่วยเพิ่มพื้นที่ในการเก็บค่าเหล่านี้เข้าไปใน รูปแบบที่ปรับแต่ง. SIMD (“single instruction multiple data”) เป็นข้อเสนอให้ทำให้สามารถปฏิบัติดำเนินการเดียวกันบนอาร์เรย์ของค่าได้อย่างมีประสิทธิภาพ สองอย่างร่วมกันสามารถสร้างอำนาจcoprocessor ควบคู่ไปกับ EVM ที่สามารถใช้เพื่อดําเนินการเข้ารหัสได้อย่างมีประสิทธิภาพมากขึ้น สิ่งนี้จะเป็นประโยชน์อย่างยิ่งสําหรับโปรโตคอลความเป็นส่วนตัวและสําหรับระบบพิสูจน์ L2 ดังนั้นจึงช่วยปรับขนาดทั้ง L1 และ L2

การปรับปรุงเหล่านี้จะถูกพูดถึงอย่างละเอียดมากขึ้นในโพสต์ในอนาคตเกี่ยวกับ Splurge

ในที่สุดกลยุทธ์ที่สามคือการใช้ native rollups (หรือ "enshrined rollups") ซึ่งหมายถึงการสร้างสำเนาของ EVM จำนวนมากที่ทำงานแบบขนานกัน ซึ่งเป็นโมเดลที่เทียบเท่ากับสิ่งที่ rollups สามารถให้ได้ แต่มีการผสมผสานเข้ากับโปรโตคอลอย่างมีความเชื่อถือ

มีลิงก์ไหนบางอย่างที่เป็นการวิจัยที่มีอยู่บ้างหรือ

• โครงการขยายมิติของ Polynya สำหรับ Ethereum L1: https://polynya.mirror.xyz/epju72rsymfB-JK52_uYI7HuhJ-W_zM735NdP7alkAQ
• การกำหนดราคาแก๊สแบบหลายมิติ: https://vitalik.eth.limo/general/2024/05/09/multidim.html
• EIP-7706: https://eips.ethereum.org/EIPS/eip-7706
• EOF: https://evmobjectformat.org/
• EVM-MAX: https://ethereum-magicians.org/t/eip-6601-evm-modular-arithmetic-extensions-evmmax/13168
• SIMD: https://eips.ethereum.org/EIPS/eip-616
• รอลอัพฐานภาษาhttps://mirror.xyz/ohotties.eth/P1qSCcwj2FZ9cqo3_6kYI4S2chW5K5tmEgogk6io1GE
• สัมภาษณ์กับแม็กซ์เรสนิกเกี่ยวกับค่าของการขยาย L1: https://x.com/BanklessHQ/status/1831319419739361321
• Justin Drake เกี่ยวกับการใช้ SNARKs และ native rollups สำหรับการขยายขนาด:https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/

สิ่งที่เหลืออยู่ที่ต้องทำ และการตัดสินใจอย่างไร?

มีกลยุทธ์สามประการสำหรับการขยายของ L1 ซึ่งสามารถดำเนินการได้โดยตัวเองหรือพร้อมกัน

• ปรับปรุงเทคโนโลยี (เช่น รหัสไคลเอนต์, ไคลเอนต์ที่ไม่มีสถานะ, การหมดอายุของประวัติ) เพื่อทำให้ L1 ง่ายต่อการตรวจสอบ และเพิ่มขีดจำกัดแก๊ส
• ทำให้การดำเนินการที่เฉพาะเจาะจงถูกลดราคา โดยเพิ่มความสามารถเฉลี่ยโดยไม่เพิ่มความเสี่ยงในกรณีสุดยอด
• โรลอัพเครื่องกล (เช่น "สร้างสำเนาขนาดขนาดของ EVM" อย่างไรก็ตาม มีโอกาสที่จะให้นักพัฒนาได้รับความยืดหยุ่นมากมายในพารามิเตอร์ของสำเนาที่พวกเขานำไปใช้งาน)

คุ้มค่าที่จะเข้าใจว่าเทคนิคเหล่านี้มีข้อดีข้อเสียที่แตกต่างกัน ตัวอย่างเช่น การทำ rollups แบบ native มีข้ออ่อนเหมือนกับ rollups ธรรมดาในเรื่องของความสามารถในการรวมอยู่ด้วยกัน คุณไม่สามารถส่งธุรกรรมเดียวที่ดำเนินการในขณะเดียวกันได้ทั้งหมดเหมือนกับสัญญาบน L1 (หรือ L2) การเพิ่มขีดจำกัดแก๊สจะลดลงจากประโยชน์อื่น ๆ ที่สามารถบรรลุได้โดยการทำให้ L1 ง่ายต่อการตรวจสอบ เช่น เพิ่มส่วนที่รับผิดชอบของผู้ใช้ที่เป็นโหนดในการตรวจสอบ และเพิ่มผู้ stake เดี่ยว การทำให้การดำเนินการที่เฉพาะเจาะจงใน EVM ถูกลดลง ขึ้นอยู่กับว่ามันทำอย่างไร สามารถเพิ่มความซับซ้อนของ EVM ทั้งหมด

คําถามใหญ่ที่แผนงานการปรับขนาด L1 ต้องตอบคือ: วิสัยทัศน์ที่ดีที่สุดสําหรับสิ่งที่เป็นของ L1 คืออะไรและอะไรเป็นของ L2? เห็นได้ชัดว่ามันไร้สาระสําหรับทุกอย่างที่จะไปใน L1: กรณีการใช้งานที่เป็นไปได้เข้าสู่ธุรกรรมหลายแสนรายการต่อวินาทีและนั่นจะทําให้ L1 ไม่น่าเชื่อถืออย่างสมบูรณ์ในการตรวจสอบ (เว้นแต่เราจะไปเส้นทางสะสมดั้งเดิม) แต่เราต้องการหลักการชี้นําบางอย่างเพื่อให้เราสามารถมั่นใจได้ว่าเราไม่ได้สร้างสถานการณ์ที่เราเพิ่มขีด จํากัด ก๊าซ 10 เท่าสร้างความเสียหายอย่างมากต่อการกระจายอํานาจของ Ethereum L1 และพบว่าเราเพิ่งเข้าสู่โลกที่แทนที่จะเป็น 99% ของกิจกรรมที่อยู่ใน L2 90% ของกิจกรรมอยู่ใน L2 ดังนั้นผลลัพธ์จึงดูเกือบจะเหมือนกันยกเว้นการสูญเสียสิ่งที่ทําให้ Ethereum L1 พิเศษกลับไม่ได้

มุมมองหนึ่งที่เสนอเกี่ยวกับ "การแบ่งงาน" ระหว่าง L1 และ L2s แหล่ง.

มันจะทำงานร่วมกับส่วนอื่น ๆ ของแผนที่ได้อย่างไร?

การนําผู้ใช้เข้าสู่ L1 มากขึ้นหมายถึงการปรับปรุงไม่เพียง แต่ขนาด แต่ยังรวมถึงด้านอื่น ๆ ของ L1 ด้วย หมายความว่า MEV มากขึ้นจะยังคงอยู่ใน L1 (ตรงข้ามกับการกลายเป็นปัญหาสําหรับ L2s เท่านั้น) และจะเป็นความต้องการเร่งด่วนในการจัดการอย่างชัดเจน มันเพิ่มมูลค่าของการมีเวลาสล็อตที่รวดเร็วใน L1 อย่างมาก และยังขึ้นอยู่กับการตรวจสอบ L1 ("the Verge") เป็นไปด้วยดี

ข้อความปฏิเสธความรับผิดชอบ：

1. บทความนี้ถูกพิมพ์ออกมาจาก [ วิตาลิก บูเตริน] ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [วิทัลิค บุเทริน]. If there are objections to this reprint, please contact the เกต เรียนทีม และพวกเขาจะจัดการกับมันโดยเร็ว
2. คำโต้แย้งความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำในการลงทุนใด ๆ ทั้งสิ้น
3. การแปลบทความเป็นภาษาอื่น ๆ ทำโดยทีม Gate Learn หากไม่ได้กล่าวถึง การคัดลอก การกระจาย หรือการลอกเลียนบทความที่ถูกแปลนั้นถือเป็นการละเมิดกฎหมาย