บทความใหม่ของ Vitalik: อนาคตที่เป็นไปได้ของ Ethereum, The Surge
ผู้เขียนต้นฉบับ: Vitalik Buterin
การรวบรวมต้นฉบับ: Karen, Foresight News
ขอขอบคุณเป็นพิเศษสำหรับ Justin Drake, Francesco, Hsiao-wei Wang, @antonttc และ Georgios Konstantopoulos
ในตอนแรก มีกลยุทธ์การปรับขนาดอยู่สองกลยุทธ์ในแผนงานของ Ethereum หนึ่ง (ดูรายงานก่อนหน้าของปี 2558) คือ "การแบ่งส่วน": แต่ละโหนดจำเป็นต้องตรวจสอบและจัดเก็บธุรกรรมเพียงเล็กน้อยเท่านั้น แทนที่จะตรวจสอบและจัดเก็บธุรกรรมทั้งหมดในห่วงโซ่ เครือข่ายเพียร์ทูเพียร์อื่นๆ (เช่น BitTorrent) ก็ทำงานในลักษณะนี้เช่นกัน ดังนั้นแน่นอนว่าเราสามารถทำให้บล็อกเชนทำงานในลักษณะเดียวกันได้ อีกประการหนึ่งคือโปรโตคอลเลเยอร์ 2: เครือข่ายเหล่านี้จะอยู่บนสุดของ Ethereum ช่วยให้พวกเขาได้รับประโยชน์อย่างเต็มที่จากการรักษาความปลอดภัย ในขณะเดียวกันก็เก็บข้อมูลและการคำนวณส่วนใหญ่ไว้นอกสายโซ่หลัก โปรโตคอลเลเยอร์ 2 อ้างถึงช่องสถานะในปี 2558 พลาสมาในปี 2560 และภาพรวมในปี 2562 Rollups มีประสิทธิภาพมากกว่าช่องสถานะหรือพลาสมา แต่ต้องใช้แบนด์วิดท์ข้อมูลออนไลน์จำนวนมาก โชคดีที่ภายในปี 2019 การวิจัยการแบ่งส่วนข้อมูลได้แก้ไขปัญหาในการตรวจสอบ "ความพร้อมใช้งานของข้อมูล" ในวงกว้างได้ เป็นผลให้ทั้งสองเส้นทางมาบรรจบกันและเราได้รับแผนงานแบบ Rollup-centric ซึ่งยังคงเป็นกลยุทธ์การขยายขนาดของ Ethereum ในปัจจุบัน
The Surge ฉบับโรดแมปปี 2023
แผนงานแบบ Rollup-centric เสนอการแบ่งงานที่เรียบง่าย: Ethereum L1 มุ่งเน้นไปที่การเป็นเลเยอร์ฐานที่ทรงพลังและกระจายอำนาจ ในขณะที่ L2 ได้รับมอบหมายให้ช่วยเหลือในขนาดของระบบนิเวศ โมเดลนี้แพร่หลายในสังคม: ระบบศาล (L1) ไม่ได้มีไว้เพื่อแสวงหาความรวดเร็วและประสิทธิภาพขั้นสูงสุด แต่เพื่อปกป้องสัญญาและสิทธิในทรัพย์สิน และผู้ประกอบการ (L2) สร้างขึ้นบนชั้นรากฐานอันแข็งแกร่งนี้ เพื่อสร้างและนำมนุษยชาติไปสู่ (ตามตัวอักษรและ เปรียบเปรย) ดาวอังคาร
ในปีนี้ แผนงานแบบเน้นการโรลอัพได้รับผลลัพธ์ที่สำคัญ: ด้วยการเปิดตัว EIP-4844 blobs แบนด์วิดท์ข้อมูลของ Ethereum L1 ได้เพิ่มขึ้นอย่างมาก และการโรลอัพ Ethereum Virtual Machine (EVM) หลายรายการได้เข้าสู่ระยะแรกแล้ว L2 แต่ละตัวมีอยู่เป็น "ส่วนย่อย" โดยมีกฎและตรรกะภายในของตัวเอง ความหลากหลายและความหลากหลายของวิธีการนำส่วนย่อยไปใช้ได้กลายเป็นความจริงแล้ว แต่อย่างที่เราได้เห็นมาแล้ว การไปตามเส้นทางนี้ยังมาพร้อมกับความท้าทายที่ไม่เหมือนใครอีกด้วย ดังนั้น งานของเราในตอนนี้คือการทำตามแผนงานแบบ Rollup-centric ให้เสร็จสิ้น และแก้ไขปัญหาเหล่านี้ ในขณะเดียวกันก็รักษาความแข็งแกร่งและการกระจายอำนาจที่เป็นลักษณะเฉพาะของ Ethereum L1
The Surge: วัตถุประสงค์หลัก
1. ในอนาคต Ethereum สามารถเข้าถึงมากกว่า 100,000 TPS ผ่าน L2
2. รักษาการกระจายอำนาจและความแข็งแกร่งของ L1
3. อย่างน้อย L2 บางตัวจะสืบทอดคุณสมบัติหลักของ Ethereum อย่างสมบูรณ์ (ไม่น่าเชื่อถือ เปิดกว้าง ต้านทานการเซ็นเซอร์)
4. Ethereum ควรรู้สึกเหมือนเป็นระบบนิเวศที่เป็นหนึ่งเดียวมากกว่า 34 บล็อกเชนที่แตกต่างกัน
เนื้อหาของบทนี้
สามเหลี่ยมความสามารถในการปรับขนาด
ความคืบหน้าเพิ่มเติมในการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล
การบีบอัดข้อมูล
พลาสมาทั่วไป
ระบบป้องกัน L2 สำหรับผู้ใหญ่
การปรับปรุงการทำงานร่วมกันระหว่าง Cross-L2
ขยายการดำเนินการบน L1
สามเหลี่ยมความสามารถในการปรับขนาด
Scalability Triangle เป็นแนวคิดที่เสนอในปี 2560 ซึ่งเชื่อว่ามีความขัดแย้งระหว่างคุณสมบัติสามประการของบล็อกเชน: การกระจายอำนาจ (โดยเฉพาะอย่างยิ่ง: ต้นทุนการรันโหนดที่ต่ำ) ความสามารถในการขยายขนาด (การประมวลผลธุรกรรมจำนวนมาก) และความปลอดภัย (ผู้โจมตีจะต้อง ประนีประนอมโหนดส่วนใหญ่ในเครือข่ายเพื่อทำให้ธุรกรรมเดียวล้มเหลว)
เป็นที่น่าสังเกตว่า Triangle Paradox ไม่ใช่ทฤษฎีบท และโพสต์ที่แนะนำ Triangle Paradox ไม่ได้มาพร้อมกับการพิสูจน์ทางคณิตศาสตร์ มันให้ข้อโต้แย้งทางคณิตศาสตร์แบบศึกษาสำนึก: หากโหนดที่เป็นมิตรต่อการกระจายอำนาจ (เช่น แล็ปท็อปสำหรับผู้บริโภค) สามารถตรวจสอบธุรกรรม N รายการต่อวินาที และคุณมีห่วงโซ่ที่ประมวลผลธุรกรรม k*N ต่อวินาที ดังนั้น (i) แต่ละธุรกรรมสามารถทำได้เท่านั้น เห็นได้จากโหนด 1/k ซึ่งหมายความว่าผู้โจมตีจำเป็นต้องประนีประนอมเพียงไม่กี่โหนดเพื่อส่งธุรกรรมที่เป็นอันตราย หรือ (ii) โหนดของคุณจะมีประสิทธิภาพ และคุณ ห่วงโซ่จะไม่ได้รับการกระจายอำนาจ จุดประสงค์ของบทความนี้ไม่เคยเพื่อพิสูจน์ว่าการทำลาย Triangle Paradox นั้นเป็นไปไม่ได้ แต่มีวัตถุประสงค์เพื่อแสดงให้เห็นว่าการทำลาย Trilemma นั้นเป็นเรื่องยาก และต้องใช้การคิดนอกกรอบของการโต้แย้งในระดับหนึ่ง
ในช่วงหลายปีที่ผ่านมา เครือข่ายประสิทธิภาพสูงบางแห่งมักอ้างว่าได้แก้ไขไตรเล็มมาโดยไม่ต้องเปลี่ยนสถาปัตยกรรมโดยพื้นฐาน โดยมักจะใช้เทคนิคทางวิศวกรรมซอฟต์แวร์เพื่อเพิ่มประสิทธิภาพโหนด สิ่งนี้ทำให้เข้าใจผิดอยู่เสมอ การรันโหนดบนเชนเหล่านี้ยากกว่าการรันโหนดบน Ethereum มาก บทความนี้จะสำรวจว่าเหตุใดจึงเป็นเช่นนี้ และเหตุใดวิศวกรรมซอฟต์แวร์ไคลเอ็นต์ L1 เพียงอย่างเดียวจึงไม่สามารถปรับขนาด Ethereum ได้
อย่างไรก็ตาม การรวมกันของการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลและ SNARK จะช่วยแก้ปัญหาความขัดแย้งของสามเหลี่ยมได้ โดยช่วยให้ลูกค้าสามารถตรวจสอบได้ว่ามีข้อมูลจำนวนหนึ่งพร้อมใช้งานและมีขั้นตอนการคำนวณจำนวนหนึ่งที่พร้อมใช้งาน ในขณะที่ดาวน์โหลดข้อมูลจำนวนเล็กน้อยและดำเนินการเท่านั้น การคำนวณจำนวนเล็กน้อยดำเนินการอย่างถูกต้อง SNARK นั้นไม่น่าเชื่อถือ การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลมีโมเดลความน่าเชื่อถือเพียงไม่กี่แบบของ N แต่ยังคงรักษาคุณสมบัติพื้นฐานของเชนที่ไม่สามารถปรับขนาดได้ กล่าวคือ แม้แต่การโจมตี 51% ก็ไม่สามารถบังคับให้เครือข่ายยอมรับบล็อกที่ไม่ดีได้
วิธีแก้ปัญหาไตรเล็มม่าอีกประการหนึ่งคือสถาปัตยกรรมพลาสมา ซึ่งใช้เทคนิคอันชาญฉลาดเพื่อผลักดันความรับผิดชอบในการตรวจสอบความพร้อมใช้งานของข้อมูลให้กับผู้ใช้ในลักษณะที่เข้ากันได้กับสิ่งจูงใจ ในช่วงต้นปี 2017-2019 เมื่อเรามีเพียงหลักฐานการฉ้อโกงเป็นวิธีการในการขยายพลังการประมวลผล Plasma ก็มีข้อจำกัดอย่างมากในแง่ของการดำเนินการด้านความปลอดภัย แต่ด้วยความนิยมของ SNARK (ข้อโต้แย้งที่ไม่โต้ตอบโดยสรุปแบบไม่มีความรู้) ทำให้ Plasma สถาปัตยกรรมมีมากขึ้น กรณีการใช้งานที่กว้างขึ้นมีความเป็นไปได้มากขึ้น
ความคืบหน้าเพิ่มเติมในการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล
เรากำลังแก้ไขปัญหาอะไรอยู่?
เมื่อวันที่ 13 มีนาคม 2024 เมื่อการอัปเกรด Dencun ดำเนินการทางออนไลน์ Ethereum blockchain มีสามหยดประมาณ 125 kB ต่อสล็อต 12 วินาที หรือประมาณ 375 kB ของแบนด์วิธข้อมูลที่มีอยู่ต่อช่อง สมมติว่าข้อมูลธุรกรรมได้รับการเผยแพร่โดยตรงบนลูกโซ่ การถ่ายโอน ERC 20 จะอยู่ที่ประมาณ 180 ไบต์ ดังนั้น TPS สูงสุดของ Rollup บน Ethereum คือ: 375000 / 12 / 180 = 173.6 TPS
หากเราเพิ่ม calldata ของ Ethereum (สูงสุดตามทฤษฎี: 30 ล้าน Gas ต่อสล็อต / 16 gas ต่อไบต์ = 1,875,000 ไบต์ต่อสล็อต) มันจะกลายเป็น 607 TPS ด้วย PeerDAS จำนวน blobs อาจเพิ่มขึ้นเป็น 8-16 ซึ่งจะให้ 463-926 TPS สำหรับข้อมูลการโทร
นี่เป็นการปรับปรุงที่สำคัญเหนือ Ethereum L1 แต่ยังไม่เพียงพอ เราต้องการความสามารถในการขยายขนาดที่มากขึ้น เป้าหมายระยะกลางของเราคือ 16 MB ต่อช่อง ซึ่งเมื่อรวมกับการปรับปรุงการบีบอัดข้อมูล Rollup จะส่งผลให้ได้ ~58,000 TPS
มันคืออะไร? มันทำงานอย่างไร?
PeerDAS เป็นการใช้งาน "การสุ่มตัวอย่าง 1D" ที่ค่อนข้างง่าย ใน Ethereum แต่ละหยดเป็นพหุนามระดับ 4096 บนไพรม์ฟิลด์ 253 บิต เราออกอากาศการแบ่งปันพหุนาม โดยแต่ละการแบ่งปันประกอบด้วย 16 การประเมินที่ 16 พิกัดที่อยู่ติดกัน จากทั้งหมด 8,192 พิกัด จากการประเมิน 8,192 ครั้ง มี 4,096 รายการ (ตามพารามิเตอร์ที่เสนอในปัจจุบัน: ตัวอย่างที่เป็นไปได้ 64 รายการจาก 128 ตัวอย่าง) สามารถกู้คืนหยดได้
PeerDAS ทำงานโดยให้ไคลเอนต์แต่ละรายฟังซับเน็ตจำนวนเล็กน้อย โดยที่ซับเน็ต i-th ออกอากาศตัวอย่าง i-th ของ blob ใดๆ และโดยการขอให้เพียร์ในเครือข่าย p2p ทั่วโลกที่จะฟังบนซับเน็ตที่แตกต่างกัน) เพื่อขอ blobs บน ซับเน็ตอื่นๆ ที่ต้องการ SubnetDAS เวอร์ชันอนุรักษ์นิยมใช้เฉพาะกลไกซับเน็ตโดยไม่มีการซักถามเลเยอร์เพียร์เพิ่มเติม ข้อเสนอปัจจุบันคือให้โหนดที่เข้าร่วมใน Proof of Stake ใช้ SubnetDAS ในขณะที่โหนดอื่นๆ (เช่น ไคลเอนต์) ใช้ PeerDAS
ตามทฤษฎี เราสามารถปรับขนาด "การสุ่มตัวอย่าง 1D" ได้เล็กน้อย: ถ้าเราเพิ่มจำนวนสูงสุดของ Blob เป็น 256 (กำหนดเป้าหมาย 128) เราก็จะสามารถบรรลุเป้าหมาย 16 MB โดยไม่ต้องสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล 16 ตัวอย่างต่อโหนด * 128 blobs * 512 ไบต์ต่อตัวอย่างต่อหยด = แบนด์วิดท์ข้อมูล 1 MB ต่อสล็อต ซึ่งถือว่าอยู่ในช่วงพิกัดความเผื่อของเราเพียงเล็กน้อยเท่านั้น ทำได้ แต่หมายความว่าไคลเอ็นต์ที่มีแบนด์วิธจำกัดจะไม่สามารถสุ่มตัวอย่างได้ เราสามารถเพิ่มประสิทธิภาพสิ่งนี้ได้บ้างโดยการลดจำนวนหยดและเพิ่มขนาดหยด แต่จะทำให้การสร้างใหม่มีราคาแพงขึ้น
ในที่สุดเราก็ต้องการก้าวไปอีกขั้นและทำการสุ่มตัวอย่างแบบ 2 มิติ ซึ่งจะสุ่มตัวอย่างไม่ใช่แค่ภายใน Blob เท่านั้น แต่ยังรวมถึงระหว่าง Blob ด้วย การใช้คุณสมบัติเชิงเส้นตรงของข้อผูกพัน KZG ชุดของ blobs ในบล็อกจะถูกขยายโดยชุด blobs เสมือนชุดใหม่ที่เข้ารหัสข้อมูลเดียวกันซ้ำซ้อน
ดังนั้นท้ายที่สุดแล้ว เราต้องการที่จะก้าวไปอีกขั้นหนึ่งและทำการสุ่มตัวอย่างแบบ 2 มิติ ซึ่งเป็นการสุ่มตัวอย่างไม่ใช่แค่ภายใน Blob เท่านั้น แต่ยังรวมถึงระหว่าง Blob ด้วย คุณสมบัติเชิงเส้นของข้อผูกพัน KZG ใช้เพื่อขยายชุดของ blobs ในบล็อกที่มีรายการ blobs เสมือนใหม่ที่เข้ารหัสข้อมูลเดียวกันซ้ำซ้อน
การสุ่มตัวอย่าง 2 มิติ ที่มา: a16z crypto
สิ่งสำคัญที่สุดคือ การคำนวณการขยายขนาดของข้อผูกพันไม่จำเป็นต้องใช้ Blob ดังนั้นโซลูชันนี้จึงเป็นมิตรต่อการสร้างบล็อกแบบกระจายโดยพื้นฐาน โหนดที่สร้างบล็อกจริงๆ จะต้องมีข้อผูกพัน Blob KZG เท่านั้น และสามารถพึ่งพา Data Availability Sampling (DAS) เพื่อตรวจสอบความพร้อมใช้งานของบล็อกข้อมูล การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลแบบมิติเดียว (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
EIP-7594: https://eips.ethereum.org/EIPS/eip-7594
SubnetDAS บน ethresear.ch: https://ethresear.ch/t/subnetdas-an-intermediate-das-approach/17169
ความแตกต่างของการกู้คืนข้อมูลในการสุ่มตัวอย่าง 2D: https://ethresear.ch/t/nuances-of-data-recoverability-in-data-availability-sampling/16256
จะต้องทำอะไรอีก? การแลกเปลี่ยนมีอะไรบ้าง?
ขั้นตอนต่อไปคือการปรับใช้และการเปิดตัว PeerDAS ให้เสร็จสิ้น หลังจากนั้น เป็นกระบวนการที่ค่อยเป็นค่อยไปในการเพิ่มจำนวน blobs บน PeerDAS ในขณะที่สังเกตเครือข่ายอย่างระมัดระวังและปรับปรุงซอฟต์แวร์เพื่อให้มั่นใจในความปลอดภัย ในระหว่างนี้ เราหวังว่าจะเห็นงานทางวิชาการที่สร้างมาตรฐานให้กับ PeerDAS และ DAS เวอร์ชันอื่นๆ มากขึ้น และการโต้ตอบกับประเด็นต่างๆ เช่น ความปลอดภัยของกฎ fork-choice
ในระยะต่อไปในอนาคต เราจำเป็นต้องทำงานมากขึ้นเพื่อระบุเวอร์ชันที่เหมาะสมที่สุดของ 2D DAS และพิสูจน์คุณสมบัติด้านความปลอดภัย นอกจากนี้ เรายังหวังที่จะย้ายออกจาก KZG ไปเป็นทางเลือกที่ปลอดภัยและไม่ต้องการการตั้งค่าที่เชื่อถือได้ในที่สุด ขณะนี้เราไม่ทราบว่าผู้สมัครรายใดที่เป็นมิตรต่อการสร้างบล็อกแบบกระจาย แม้แต่การใช้เทคนิค "กำลังดุร้าย" ที่มีราคาแพง แม้แต่การใช้ STARK แบบเรียกซ้ำเพื่อสร้างการพิสูจน์ความถูกต้องสำหรับการสร้างแถวและคอลัมน์ใหม่ ยังไม่เพียงพอ เพราะแม้ว่าในทางเทคนิคแล้ว STARK จะเป็นค่าแฮช O(log(n ) * log(log(n)) (โดยใช้ STIR) แต่ในความเป็นจริงแล้ว STARK เกือบจะใหญ่เท่ากับหยดทั้งหมด
เส้นทางความเป็นจริงระยะยาวของฉันคือ:
ใช้ 2D DAS ในอุดมคติ
เลือกใช้ 1D DAS โดยเสียสละประสิทธิภาพแบนด์วิธในการสุ่มตัวอย่าง และยอมรับขีดจำกัดข้อมูลที่ต่ำกว่าเพื่อความเรียบง่ายและทนทาน
(Hard pivot) เลิกใช้ DA และยอมรับ Plasma อย่างเต็มที่เป็นสถาปัตยกรรมเลเยอร์ 2 หลักที่เรามุ่งเน้น
โปรดทราบว่าตัวเลือกนี้มีอยู่แม้ว่าเราจะตัดสินใจปรับขนาดการดำเนินการโดยตรงที่เลเยอร์ L1 ก็ตาม เนื่องจากหากเลเยอร์ L1 ต้องจัดการ TPS จำนวนมาก บล็อก L1 จะมีขนาดใหญ่มากและไคลเอนต์จะต้องการวิธีที่มีประสิทธิภาพในการตรวจสอบความถูกต้อง ดังนั้นเราจะต้องใช้ Rollup (เช่น ZK) ที่ L1 layer -EVM และ DAS) เทคโนโลยีเดียวกัน
ฉันจะโต้ตอบกับส่วนอื่นๆ ของแผนงานได้อย่างไร
หากใช้การบีบอัดข้อมูล ความต้องการ 2D DAS จะลดลงหรืออย่างน้อยก็ล่าช้าออกไป และหากพลาสมาถูกนำมาใช้กันอย่างแพร่หลาย ความต้องการก็จะลดลงอีก นอกจากนี้ DAS ยังก่อให้เกิดความท้าทายต่อโปรโตคอลและกลไกการก่อสร้างบล็อกแบบกระจาย: แม้ว่าในทางทฤษฎี DAS จะเป็นมิตรกับการสร้างใหม่แบบกระจาย แต่ในทางปฏิบัติ จำเป็นต้องรวมกับข้อเสนอรายการรวมและกลไกการเลือกทางแยกที่อยู่รอบๆ
การบีบอัดข้อมูล
เรากำลังแก้ไขปัญหาอะไรอยู่?
ธุรกรรมแต่ละรายการใน Rollup ใช้พื้นที่ข้อมูลออนไลน์จำนวนมาก: การถ่ายโอน ERC 20 ต้องใช้พื้นที่ประมาณ 180 ไบต์ แม้จะมีการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลในอุดมคติ สิ่งนี้จะจำกัดความสามารถในการปรับขนาดของโปรโตคอลเลเยอร์ ด้วยขนาด 16 MB ต่อช่อง เราได้รับ:
16000000 / 12 / 180 = 7407 ทีพีเอส
จะเป็นอย่างไรถ้าเราไม่เพียงแต่สามารถแก้ปัญหาตัวเศษเท่านั้น แต่ยังแก้ปัญหาตัวส่วนด้วย เพื่อให้แต่ละธุรกรรมในการรวบรวมใช้ไบต์น้อยลงในสายโซ่
มันคืออะไรและมันทำงานอย่างไร?
ในความคิดของฉัน คำอธิบายที่ดีที่สุดคือภาพนี้เมื่อสองปีที่แล้ว:
ในการบีบอัดแบบศูนย์ไบต์ แต่ละลำดับแบบยาวของไบต์ศูนย์จะถูกแทนที่ด้วยสองไบต์ เพื่อระบุจำนวนไบต์ที่เป็นศูนย์ ก้าวไปอีกขั้นหนึ่ง เราใช้ประโยชน์จากคุณสมบัติเฉพาะของธุรกรรม:
การรวมลายเซ็น: เราเปลี่ยนจากลายเซ็น ECDSA เป็นลายเซ็น BLS ลักษณะของลายเซ็น BLS คือสามารถรวมลายเซ็นหลายลายเซ็นเป็นลายเซ็นเดียวที่สามารถพิสูจน์ความถูกต้องของลายเซ็นต้นฉบับทั้งหมดได้ ในเลเยอร์ L1 ลายเซ็น BLS จะไม่ถูกพิจารณา เนื่องจากมีค่าใช้จ่ายในการคำนวณสูงในการตรวจสอบแม้ว่าจะมีการรวมกลุ่มก็ตาม แต่ในสภาพแวดล้อมที่มีข้อมูลไม่เพียงพอ เช่น L2 การใช้ลายเซ็น BLS ก็สมเหตุสมผล ลักษณะการรวมกลุ่มของ ERC-4337 ช่วยให้บรรลุฟังก์ชันการทำงานนี้
การแทนที่ที่อยู่ด้วยตัวชี้: หากเคยใช้ที่อยู่มาก่อน เราสามารถแทนที่ที่อยู่ 20 ไบต์ด้วยตัวชี้ 4 ไบต์ที่ชี้ไปยังตำแหน่งในประวัติ
การกำหนดลำดับมูลค่าธุรกรรมแบบกำหนดเอง - มูลค่าธุรกรรมส่วนใหญ่มีตัวเลขน้อยมาก เช่น 0.25 ETH จะแสดงเป็น 250, 000, 000, 000, 000, 000 wei ค่าธรรมเนียมการจัดการพื้นฐานสูงสุดและค่าธรรมเนียมการจัดการตามลำดับความสำคัญก็ใกล้เคียงกันเช่นกัน ดังนั้นเราจึงสามารถใช้รูปแบบทศนิยมทศนิยมที่กำหนดเองเพื่อแสดงมูลค่าทางการเงินส่วนใหญ่ได้
ลิงค์ไปยังงานวิจัยที่มีอยู่คืออะไร?
สำรวจ sequence.xyz: https://sequence.xyz/blog/compressing-calldata
สัญญาการเพิ่มประสิทธิภาพ L2 Calldata: https://github.com/ScopeLift/l2-optimizooooors
Rollups ที่อิงการพิสูจน์ความถูกต้อง (หรือที่รู้จักในชื่อ Rollups ZK) เผยแพร่ความแตกต่างของสถานะแทนธุรกรรม: https://ethresear.ch/t/rollup-diff-compression-application-level-compression-strategies-to-reduce-the-l2 -data-footprint-on-l1/9975
BLS Wallet - การรวม BLS ผ่าน ERC-4337: https://github.com/getwax/bls-wallet
จะต้องทำอะไรอีกและมีข้อเสียอะไรบ้าง?
สิ่งสำคัญที่ต้องทำต่อไปคือนำโซลูชันข้างต้นไปใช้จริง ข้อเสียเปรียบหลัก ได้แก่ :
1. การเปลี่ยนไปใช้ลายเซ็น BLS ต้องใช้ความพยายามอย่างมาก และลดความเข้ากันได้กับชิปฮาร์ดแวร์ที่เชื่อถือได้ซึ่งสามารถปรับปรุงความปลอดภัยได้ สามารถใช้ wrappers ZK-SNARK ของรูปแบบลายเซ็นอื่นๆ แทนได้
2. การบีบอัดข้อมูลแบบไดนามิก (เช่น การแทนที่ที่อยู่ด้วยพอยน์เตอร์) จะทำให้โค้ดไคลเอ็นต์ซับซ้อนขึ้น
3. การเผยแพร่ความแตกต่างของสถานะไปยังห่วงโซ่แทนการทำธุรกรรมจะลดการตรวจสอบ และทำให้ซอฟต์แวร์จำนวนมาก (เช่น Block Explorer) ไม่สามารถทำงานได้
ฉันจะโต้ตอบกับส่วนอื่นๆ ของแผนงานได้อย่างไร
การใช้ ERC-4337 และการรวมส่วนต่างๆ เข้ากับ L2 EVM ในท้ายที่สุดสามารถเร่งการปรับใช้เทคโนโลยีแบบหลอมรวมได้อย่างมาก การวางชิ้นส่วนของ ERC-4337 บน L1 สามารถเร่งการปรับใช้บน L2 ได้
พลาสมาทั่วไป
เรากำลังแก้ไขปัญหาอะไรอยู่?
แม้ว่าจะมี blobs และการบีบอัดข้อมูลขนาด 16 MB แต่ 58,000 TPS อาจไม่เพียงพอที่จะตอบสนองความต้องการการชำระเงินของผู้บริโภค การกระจายอำนาจทางสังคม หรือพื้นที่แบนด์วิธสูงอื่นๆ ได้อย่างเต็มที่ โดยเฉพาะอย่างยิ่งเมื่อเราเริ่มพิจารณาข้อควรพิจารณาด้านความเป็นส่วนตัว ซึ่งอาจทำให้ความสามารถในการปรับขนาดลดลง 3-8 เท่า สำหรับสถานการณ์แอปพลิเคชันที่มีปริมาณธุรกรรมสูงและมีมูลค่าต่ำ ทางเลือกหนึ่งในปัจจุบันคือการใช้ Validium ซึ่งจะทำให้ข้อมูลอยู่นอกเครือข่ายและใช้รูปแบบการรักษาความปลอดภัยที่น่าสนใจ: ผู้ดำเนินการไม่สามารถขโมยเงินของผู้ใช้ได้ แต่อาจระงับเงินทุนของผู้ใช้ทั้งหมดชั่วคราวหรือถาวร แต่เราสามารถทำได้ดีกว่า
มันคืออะไรและมันทำงานอย่างไร?
Plasma เป็นโซลูชันการปรับขนาดที่เกี่ยวข้องกับตัวดำเนินการเผยแพร่บล็อกแบบ off-chain และวาง Merkle root ของบล็อกเหล่านั้นแบบ on-chain (ไม่เหมือนกับ Rollup ซึ่งจะทำให้บล็อกเสร็จสมบูรณ์แบบ on-chain ) สำหรับแต่ละบล็อก ผู้ดำเนินการจะส่งสาขา Merkle ไปยังผู้ใช้แต่ละรายเพื่อพิสูจน์ว่าทรัพย์สินของผู้ใช้มีการเปลี่ยนแปลงหรือไม่มีอะไรเปลี่ยนแปลง ผู้ใช้สามารถถอนทรัพย์สินของตนได้โดยจัดเตรียม Merkle fork ที่สำคัญสาขานี้ไม่จำเป็นต้องรูทที่สถานะล่าสุด ดังนั้นแม้ว่าจะมีปัญหาเกี่ยวกับความพร้อมใช้งานของข้อมูล ผู้ใช้ยังคงสามารถกู้คืนสินทรัพย์ของตนได้โดยการดึงสถานะล่าสุดที่มีอยู่ หากผู้ใช้กระทำสาขาที่ไม่ถูกต้อง (เช่น การถอนสินทรัพย์ที่พวกเขาได้ส่งไปให้บุคคลอื่นแล้ว หรือผู้ดำเนินการเองสร้างสินทรัพย์ขึ้นมาจากอากาศ) ความเป็นเจ้าของทางกฎหมายของสินทรัพย์สามารถกำหนดได้ผ่านการท้าทายแบบออนไลน์ กลไก.
แผนภาพลูกโซ่เงินสดพลาสม่า ธุรกรรมที่เสียเหรียญ i จะถูกวางไว้ที่ตำแหน่งที่ i ในแผนผัง ในตัวอย่างนี้ สมมติว่าแผนผังก่อนหน้านี้ทั้งหมดถูกต้อง เรารู้ว่าปัจจุบัน Eve เป็นเจ้าของโทเค็น 1 David เป็นเจ้าของโทเค็น 4 และ George เป็นเจ้าของโทเค็น 6
พลาสมาเวอร์ชันก่อนๆ สามารถจัดการได้เฉพาะกรณีการใช้งานการชำระเงินเท่านั้น และไม่สามารถส่งเสริมเพิ่มเติมได้อย่างมีประสิทธิภาพ อย่างไรก็ตาม พลาสมาจะมีประสิทธิภาพมากขึ้นหากเราต้องการให้แต่ละรูทได้รับการตรวจสอบด้วย SNARK เกมท้าทายแต่ละเกมสามารถทำให้ง่ายขึ้นอย่างมาก เนื่องจากเรากำจัดเส้นทางที่เป็นไปได้ส่วนใหญ่ที่ผู้ปฏิบัติงานจะโกงได้ ในขณะเดียวกัน ก็ยังเปิดเส้นทางใหม่เพื่อให้เทคโนโลยีพลาสมาสามารถขยายไปสู่ประเภทสินทรัพย์ที่หลากหลายยิ่งขึ้น สุดท้ายนี้ หากผู้ดำเนินการไม่โกง ผู้ใช้สามารถถอนเงินได้ทันทีโดยไม่ต้องรอเป็นระยะเวลาหนึ่งสัปดาห์
วิธีหนึ่ง (ไม่ใช่วิธีเดียว) ในการสร้าง EVM Plasma chain: ใช้ ZK-SNARK เพื่อสร้างแผนผัง UTXO แบบขนานที่สะท้อนถึงการเปลี่ยนแปลงสมดุลที่ทำโดย EVM และกำหนด "โทเค็นเดียวกัน" ที่จุดต่างๆ ในประวัติศาสตร์ "การแมปเดียวเท่านั้น . โครงสร้างพลาสมาสามารถสร้างขึ้นทับได้
ข้อมูลเชิงลึกที่สำคัญคือระบบพลาสมาไม่จำเป็นต้องสมบูรณ์แบบ แม้ว่าคุณจะสามารถปกป้องเนื้อหาบางส่วนได้ (เช่น โทเค็นที่ไม่ได้ย้ายในสัปดาห์ที่ผ่านมา) คุณได้ปรับปรุงสถานะปัจจุบันของ EVM แบบไฮเปอร์สเกลได้อย่างมาก (เช่น Validium)
โครงสร้างอีกประเภทหนึ่งคือ Hybrid Plasma/Rollup เช่น Intmax โครงสร้างเหล่านี้ใส่ข้อมูลจำนวนน้อยมากต่อผู้ใช้ออนไลน์ (เช่น 5 ไบต์) และในการทำเช่นนั้นให้บรรลุคุณสมบัติบางอย่างระหว่าง Plasma และ Rollup: ในกรณีของ 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
กระแสเงินสดพลาสม่า: https://hackmd.io/DgzmJIRjSzCYvl4lUjZXNQ?view#🚪-ออก
Intmax (2023): https://eprint.iacr.org/2023/1082
จะต้องทำอะไรอีก? การแลกเปลี่ยนมีอะไรบ้าง?
ภารกิจหลักที่เหลืออยู่คือการนำระบบพลาสมาไปใช้งานจริง ดังที่ได้กล่าวไว้ข้างต้น Plasma vs. Validium ไม่ใช่ตัวเลือกอย่างใดอย่างหนึ่ง: Validium ใดๆ สามารถปรับปรุงคุณสมบัติด้านความปลอดภัยได้อย่างน้อยในระดับหนึ่งโดยการรวมคุณสมบัติ Plasma เข้ากับกลไกทางออก จุดมุ่งหมายของการวิจัยคือการได้รับสิ่งที่ดีที่สุดสำหรับคุณสมบัติ EVM (พิจารณาในแง่ของข้อกำหนดด้านความน่าเชื่อถือ ต้นทุน L1 Gas ที่เลวร้ายที่สุด และความสามารถในการทนต่อการโจมตี DoS) รวมถึงโครงสร้างเฉพาะแอปพลิเคชันทางเลือก นอกจากนี้ Plasma ยังมีแนวคิดที่ซับซ้อนมากกว่า Rollup ซึ่งต้องการการจัดการโดยตรง การวิจัยและสร้างกรอบการทำงานทั่วไปที่ดีขึ้น
ข้อด้อยหลักๆ ในการใช้การออกแบบพลาสมาก็คือ พวกมันขึ้นอยู่กับผู้ปฏิบัติงานมากกว่าและยากต่อการวางฐาน แม้ว่าการออกแบบพลาสมา/โรลอัพแบบไฮบริดมักจะหลีกเลี่ยงจุดอ่อนนี้
ฉันจะโต้ตอบกับส่วนอื่นๆ ของแผนงานได้อย่างไร
ยิ่งโซลูชันพลาสมามีประสิทธิภาพมากขึ้นเท่าใด L1 ก็จะยิ่งกดดันน้อยลงในการมีขีดความสามารถด้านความพร้อมใช้งานของข้อมูลประสิทธิภาพสูงเท่านั้น การย้ายกิจกรรมไปที่ L2 ยังช่วยลดแรงกดดัน MEV บน L1 อีกด้วย
ระบบป้องกัน L2 สำหรับผู้ใหญ่
เรากำลังแก้ไขปัญหาอะไรอยู่?
ในปัจจุบัน Rollups ส่วนใหญ่ไม่น่าเชื่อถือจริงๆ มีคณะกรรมการด้านความปลอดภัยที่มีความสามารถในการแทนที่ (ในแง่ดีหรือการตรวจสอบ) พฤติกรรมของระบบ ในบางกรณี ระบบการรับรองไม่ทำงานเลยด้วยซ้ำ หรือหากทำงาน ระบบจะมีเพียงฟังก์ชัน "ที่ปรึกษา" เท่านั้น การยกเลิกที่ล้ำสมัยประกอบด้วย: (i) การยกเลิกเฉพาะแอปพลิเคชันที่ไม่น่าเชื่อถือ เช่น Fuel; (ii) ในขณะที่เขียนบทความนี้ การมองในแง่ดีและการอนุญาโตตุลาการเป็นสองประการที่ประสบความสำเร็จในเหตุการณ์สำคัญที่ไม่น่าเชื่อถือบางส่วนที่เรียกว่า "ระยะที่ 1" การยกเลิก EVM แบบเต็ม เหตุผลที่ Rollup ไม่สามารถดำเนินการต่อไปได้เนื่องมาจากความกังวลเกี่ยวกับจุดบกพร่องในโค้ด เราต้องการ Rollup ที่ไม่น่าเชื่อถือ ดังนั้นเราจึงต้องเผชิญกับปัญหานี้โดยตรงและแก้ไขมัน
มันคืออะไรและมันทำงานอย่างไร?
ก่อนอื่น เรามาทบทวนระบบ "ระยะ" ที่เดิมนำมาใช้ในบทความนี้กันก่อน
เฟส 0: ผู้ใช้จะต้องสามารถรันโหนดและซิงค์เชนได้ หากการตรวจสอบได้รับความไว้วางใจ/รวมศูนย์โดยสมบูรณ์ ก็ไม่เป็นไร
ระยะที่ 1: ต้องมีระบบพิสูจน์ (ไม่ไว้วางใจ) เพื่อให้แน่ใจว่าธุรกรรมที่ถูกต้องเท่านั้นที่จะได้รับการยอมรับ อนุญาตให้คณะกรรมการความปลอดภัยสามารถแทนที่ระบบการรับรองได้ แต่จะต้องมีคะแนนเสียงตามเกณฑ์ 75% นอกจากนี้ ส่วนที่ปิดกั้นองค์ประชุมของคณะกรรมการ (เช่น 26%+) จะต้องอยู่นอกบริษัทหลักที่สร้างชุดรวมอัปเดต อนุญาตให้ใช้กลไกการอัปเกรดที่อ่อนแอกว่า (เช่น DAO) แต่ต้องมีความล่าช้านานพอที่จะอนุมัติการอัปเกรดที่เป็นอันตราย ผู้ใช้สามารถถอนเงินก่อนที่เงินทุนจะออนไลน์
ระยะที่ 2: ต้องมีระบบพิสูจน์ (ไร้ความน่าเชื่อถือ) เพื่อให้แน่ใจว่าจะยอมรับเฉพาะธุรกรรมที่ถูกต้องเท่านั้น คณะกรรมการด้านความปลอดภัยจะได้รับอนุญาตให้เข้าไปแทรกแซงได้ก็ต่อเมื่อมีข้อผิดพลาดที่พิสูจน์ได้ในโค้ดเท่านั้น หากระบบพิสูจน์ซ้ำซ้อนสองระบบไม่สอดคล้องกัน หรือหากระบบพิสูจน์ระบบหนึ่งยอมรับรากสถานะหลังสถานะที่แตกต่างกันสองระบบสำหรับบล็อกเดียวกัน (หรือไม่ยอมรับสิ่งใดเลยเป็นระยะเวลานานเพียงพอ เช่น หนึ่งสัปดาห์) อนุญาตให้ใช้กลไกการอัพเกรดได้ แต่ต้องมีความล่าช้ายาวนาน
เป้าหมายของเราคือการไปถึงระยะที่ 2 ความท้าทายหลักในการไปถึงขั้นที่ 2 คือการได้รับความมั่นใจเพียงพอที่จะพิสูจน์ว่าระบบมีความน่าเชื่อถือเพียงพอจริงๆ มีสองวิธีหลักในการทำเช่นนี้:
การตรวจสอบอย่างเป็นทางการ: เราสามารถใช้คณิตศาสตร์และเทคนิคคอมพิวเตอร์สมัยใหม่เพื่อพิสูจน์ (ในแง่ดีและถูกต้อง) ว่าระบบยอมรับเฉพาะบล็อกที่ผ่านข้อกำหนด EVM เท่านั้น เทคโนโลยีเหล่านี้มีมานานหลายทศวรรษแล้ว แต่ความก้าวหน้าล่าสุด (เช่น Lean 4) ทำให้ใช้งานได้จริงมากขึ้น และความก้าวหน้าในการพิสูจน์ที่ได้รับความช่วยเหลือจาก AI อาจเร่งแนวโน้มนี้ต่อไป
ผู้พิสูจน์หลายราย: สร้างระบบพิสูจน์หลายระบบและลงทุนเงินในระบบพิสูจน์เหล่านี้กับคณะกรรมการรักษาความปลอดภัย (หรืออุปกรณ์อื่น ๆ ที่สันนิษฐานว่าน่าเชื่อถือ เช่น TEE) หากระบบพิสูจน์เห็นด้วย คณะกรรมการความปลอดภัยจะไม่มีอำนาจ หากไม่เป็นเช่นนั้น คณะกรรมการความปลอดภัยจะสามารถเลือกได้ระหว่างข้อใดข้อหนึ่งเท่านั้น และไม่สามารถกำหนดคำตอบของตนเองเพียงฝ่ายเดียวได้
กราฟมีสไตล์แบบหลายผู้พิสูจน์ซึ่งรวมเอาระบบการพิสูจน์ในแง่ดี ระบบการพิสูจน์ความถูกต้อง และคณะกรรมการความปลอดภัย
ลิงค์ไปยังงานวิจัยที่มีอยู่คืออะไร?
EVM K Semantics (งานตรวจสอบอย่างเป็นทางการตั้งแต่ปี 2560): https://github.com/runtimeverification/evm-semantics
บรรยายแนวคิดการพิสูจน์หลายข้อ (2022): https://www.youtube.com/watch?v=6hfVzCWT6YI
Taiko วางแผนที่จะใช้การพิสูจน์หลายรายการ: https://docs.taiko.xyz/core-concepts/multi-proofs/
จะต้องทำอะไรอีก? การแลกเปลี่ยนมีอะไรบ้าง?
สำหรับการตรวจสอบอย่างเป็นทางการ ภาระงานมีมาก เราจำเป็นต้องสร้างเวอร์ชันที่ได้รับการตรวจสอบอย่างเป็นทางการของพิสูจน์ SNARK ทั้งหมดของ EVM นี่เป็นโครงการที่ซับซ้อนมาก แม้ว่าเราจะได้เริ่มทำงานแล้วก็ตาม มีเคล็ดลับที่ทำให้งานนี้ง่ายขึ้นอย่างมาก: เราสามารถสร้างเครื่องพิสูจน์ SNARK ที่ได้รับการยืนยันอย่างเป็นทางการสำหรับเครื่องเสมือนขั้นต่ำ (เช่น RISC-V หรือ Cairo) จากนั้นจึงนำ EVM ไปใช้งานในเครื่องเสมือนขั้นต่ำนี้ (และการพิสูจน์อย่างเป็นทางการของความเท่าเทียมกัน ไปยังข้อกำหนดเฉพาะอื่นๆ ของ Ethereum Virtual Machine)
การพิสูจน์หลายส่วนมีสองส่วนหลักที่ยังดำเนินการไม่เสร็จสิ้น อันดับแรก เราจำเป็นต้องมีความมั่นใจเพียงพอในระบบการพิสูจน์ที่แตกต่างกันอย่างน้อยสองระบบ ทั้งสองระบบเพื่อให้แน่ใจว่าแต่ละระบบมีความปลอดภัยพอสมควร และเพื่อให้แน่ใจว่าหากมีปัญหา ปัญหาควรจะแตกต่างกันและไม่เกี่ยวข้องกัน (เพื่อไม่ให้เกิดขึ้นพร้อมกัน A ปัญหาเกิดขึ้น) ประการที่สอง เราจำเป็นต้องมีความไว้วางใจในระดับที่สูงมากในตรรกะพื้นฐานของระบบป้องกันการรวม โค้ดส่วนนี้น้อยกว่ามาก มีวิธีทำให้มีขนาดเล็กมาก โดยเพียงแค่จัดเก็บเงินทุนไว้ในสัญญา Safe multisig โดยมีสัญญาที่เป็นตัวแทนของระบบพิสูจน์แต่ละระบบในฐานะผู้ลงนาม แต่การทำเช่นนี้จะเพิ่มต้นทุนก๊าซในห่วงโซ่ เราจำเป็นต้องค้นหาสมดุลระหว่างประสิทธิภาพและความปลอดภัย
ฉันจะโต้ตอบกับส่วนอื่นๆ ของแผนงานได้อย่างไร
การย้ายกิจกรรมไปที่ L2 จะช่วยลดแรงกดดัน MEV บน L1
การปรับปรุงการทำงานร่วมกันระหว่าง Cross-L2
เรากำลังแก้ไขปัญหาอะไรอยู่?
ความท้าทายสำคัญที่ระบบนิเวศ L2 เผชิญอยู่ทุกวันนี้ก็คือ เป็นเรื่องยากสำหรับผู้ใช้ในการนำทางภายในระบบนิเวศ L2 นอกจากนี้ วิธีที่ง่ายที่สุดมักจะรื้อฟื้นสมมติฐานด้านความน่าเชื่อถือ เช่น เครือข่ายแบบรวมศูนย์ ไคลเอนต์ RPC เป็นต้น เราจำเป็นต้องทำให้การใช้ระบบนิเวศ L2 รู้สึกเหมือนใช้ระบบนิเวศ Ethereum ที่เป็นหนึ่งเดียว
มันคืออะไร?
การปรับปรุงการทำงานร่วมกันข้าม L2 มีหลายประเภท ตามทฤษฎีแล้ว Ethereum ที่เน้นการสะสมรวมเป็นสิ่งเดียวกับการดำเนินการชาร์ด L1 ระบบนิเวศ Ethereum L2 ในปัจจุบันยังคงมีข้อบกพร่องเหล่านี้จากสถานะในอุดมคติในทางปฏิบัติ:
1. ที่อยู่ของห่วงโซ่เฉพาะ: ที่อยู่ควรมีข้อมูลห่วงโซ่ (L1, Optimism, Arbitrum...) เมื่อบรรลุผลดังกล่าวแล้ว กระบวนการส่งแบบ cross-L2 ก็สามารถนำไปใช้ได้โดยเพียงแค่ใส่ที่อยู่ลงในช่อง "ส่ง" ซึ่ง ณ จุดนี้กระเป๋าเงินจะสามารถจัดการวิธีการส่งได้ด้วยตัวเองในเบื้องหลัง (รวมถึงการใช้โปรโตคอลแบบ cross-chain) .
2. คำขอชำระเงินเฉพาะเครือ: ควรเป็นเรื่องง่ายและเป็นมาตรฐานในการสร้างข้อความในรูปแบบ "ส่งโทเค็น X ประเภท Y บนเชน Z" สิ่งนี้มีสองสถานการณ์หลักในการสมัคร: (i) ไม่ว่าจะเป็นการชำระเงินระหว่างผู้คนหรือการชำระเงินระหว่างผู้คนกับบริการของผู้ค้า (ii) DApp ที่ร้องขอเงินทุน
3. การแลกเปลี่ยนข้ามเชนและการจ่ายแก๊ส: ควรมีโปรโตคอลเปิดที่เป็นมาตรฐานเพื่อแสดงการดำเนินการข้ามเชน เช่น "ฉันจะส่ง 1 Ethereum ไปยังบุคคลที่ส่ง 0.9999 Ethereum ให้ฉันบน Arbitrum (ในการมองโลกในแง่ดี)" และ " ฉันจะส่ง 0.0001 Ether (ในการมองโลกในแง่ดี) ให้กับบุคคลที่รวมธุรกรรมนี้ไว้ใน Arbitrum" ERC-7683 เป็นความพยายามในครั้งแรก และ RIP-7755 เป็นความพยายามในครั้งหลัง แม้ว่าทั้งสองจะมีการใช้งานที่กว้างกว่ากรณีการใช้งานเฉพาะเหล่านี้
4. ไคลเอ็นต์แบบ Light: ผู้ใช้ควรสามารถตรวจสอบห่วงโซ่ที่ตนโต้ตอบด้วยได้จริง แทนที่จะเชื่อถือผู้ให้บริการ RPC เท่านั้น Helios ของ a16z crypto สามารถทำได้ (สำหรับ Ethereum เอง) แต่เราจำเป็นต้องขยายความไม่ไว้วางใจนี้ไปยัง L2 ERC-3668 (อ่าน CCIP) เป็นกลยุทธ์หนึ่งในการบรรลุเป้าหมายนี้
วิธีที่ไคลเอ็นต์แบบเบาอัปเดตมุมมองของห่วงโซ่ส่วนหัวของ Ethereum เมื่อคุณมีห่วงโซ่ส่วนหัวแล้ว คุณสามารถใช้การพิสูจน์ Merkle เพื่อตรวจสอบวัตถุสถานะใดๆ ได้ เมื่อคุณมีออบเจ็กต์สถานะ L1 ที่ถูกต้องแล้ว คุณสามารถใช้การพิสูจน์ Merkle (และลายเซ็นหากคุณต้องการตรวจสอบการยืนยันล่วงหน้า) เพื่อตรวจสอบออบเจ็กต์สถานะใด ๆ บน L2 Helios ได้ทำอดีตแล้ว การปรับขนาดไปสู่อย่างหลังถือเป็นความท้าทายในการสร้างมาตรฐาน
1. Keystore wallet: วันนี้ หากคุณต้องการอัปเดตคีย์ที่ควบคุมกระเป๋าเงินสัญญาอัจฉริยะของคุณ คุณต้องอัปเดตบนเครือข่าย N ทั้งหมดที่มีกระเป๋าเงินอยู่ Keystore wallets เป็นเทคโนโลยีที่ช่วยให้กุญแจอยู่ในที่เดียวเท่านั้น (ไม่ว่าจะบน L1 หรืออาจเป็นหลังจากนั้นบน L2) จากนั้น L2 ใด ๆ ที่มีสำเนาของกระเป๋าเงินจะสามารถอ่านกุญแจได้ ซึ่งหมายความว่าต้องทำการอัปเดตเพียงครั้งเดียวเท่านั้น เพื่อปรับปรุงประสิทธิภาพ Keystore Wallet กำหนดให้ L2 มีวิธีการอ่านข้อมูลบน L1 ที่เป็นมาตรฐานโดยไม่มีค่าใช้จ่าย มีข้อเสนอสองข้อสำหรับเรื่องนี้ ได้แก่ L1S LOAD และ REMOTESTATICCALL
กระเป๋าเงิน Keystore ทำงานอย่างไร
2. แนวคิด "สะพานโทเค็นที่ใช้ร่วมกัน" ที่ต่างไปจากเดิมอย่างสิ้นเชิง: ลองจินตนาการถึงโลกที่ L2 ทั้งหมดเป็น Rollup ที่พิสูจน์ความถูกต้อง และทุกช่องจะถูกส่งไปยัง Ethereum แม้แต่ในโลกเช่นนี้ การโอนสินทรัพย์จาก L2 หนึ่งไปยังอีก L2 ในรัฐดั้งเดิมยังคงต้องมีการถอนและฝากเงิน ซึ่งจำเป็นต้องจ่ายค่าธรรมเนียมก๊าซ L1 จำนวนมาก วิธีหนึ่งในการแก้ปัญหานี้คือการสร้างการสรุปแบบเรียบง่ายที่ใช้ร่วมกันซึ่งมีฟังก์ชันเดียวคือการรักษาว่า L2 ใดเป็นเจ้าของโทเค็นแต่ละประเภทและยอดคงเหลือที่แต่ละประเภทมีเท่าใด และอนุญาตให้ยอดคงเหลือเหล่านี้ผ่านชุดของธุรกรรมที่เริ่มต้นโดยการดำเนินการส่ง L2 ใด ๆ ใน L2 สำหรับการอัพเดตแบบแบตช์ ซึ่งจะช่วยให้สามารถโอนข้าม L2 ได้โดยไม่ต้องจ่ายค่าธรรมเนียมก๊าซ L1 สำหรับการโอนแต่ละครั้ง และไม่ต้องใช้เทคโนโลยีที่อิงผู้ให้บริการสภาพคล่อง เช่น ERC-7683
3. การจัดองค์ประกอบแบบซิงโครนัส: อนุญาตให้มีการเรียกแบบซิงโครนัสระหว่าง 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
การออกแบบกระเป๋าสตางค์ของร้านขายกุญแจแบบเลื่อน: https://hackmd.io/@haichen/keystore
เฮลิออส: https://github.com/a16z/helios
ERC-3668 (บางครั้งเรียกว่า CCIP อ่าน): https://eips.ethereum.org/EIPS/eip-3668
ข้อเสนอ "การยืนยันล่วงหน้าตาม (ที่ใช้ร่วมกัน)" เสนอโดย Justin Drake: https://ethresear.ch/t/based-preconfirmations/17353
โหลด L1S (RIP-7728): https://ethereum-magicians.org/t/rip-7728-l1s load-precompile/20388
REMOTESTATICCALL ในการมองในแง่ดี: https://github.com/ethereum-optimism/ecosystem-contributions/issues/76
AggLayer ซึ่งรวมถึงแนวคิดเกี่ยวกับโทเค็นบริดจ์ที่ใช้ร่วมกัน: https://github.com/AggLayer
จะต้องทำอะไรอีก? การแลกเปลี่ยนมีอะไรบ้าง?
ตัวอย่างหลายรายการข้างต้นเผชิญกับภาวะที่กลืนไม่เข้าคายไม่ออกของมาตรฐานว่าเมื่อใดที่จะต้องสร้างมาตรฐานและเลเยอร์ใดที่จะทำให้เป็นมาตรฐาน หากคุณสร้างมาตรฐานเร็วเกินไป คุณเสี่ยงที่จะยึดแนวทางการแก้ปัญหาที่ไม่ดี หากคุณสร้างมาตรฐานช้าเกินไป คุณอาจสร้างการกระจายตัวที่ไม่จำเป็น ในบางกรณี มีวิธีแก้ปัญหาระยะสั้นที่มีคุณสมบัติอ่อนกว่าแต่นำไปใช้ได้ง่ายกว่า และวิธีแก้ปัญหาระยะยาวที่ "ถูกต้องในที่สุด" แต่ต้องใช้เวลาหลายปีในการดำเนินการ
งานเหล่านี้ไม่ใช่แค่ปัญหาทางเทคนิคเท่านั้น แต่ยังเป็นปัญหาสังคม (บางทีอาจเป็นหลักด้วยซ้ำ) ที่ต้องอาศัยความร่วมมือระหว่าง L2 และกระเป๋าเงินเช่นเดียวกับ L1
ฉันจะโต้ตอบกับส่วนอื่นๆ ของแผนงานได้อย่างไร
ข้อเสนอเหล่านี้ส่วนใหญ่เป็นโครงสร้าง "ระดับที่สูงกว่า" ดังนั้นจึงมีผลกระทบเพียงเล็กน้อยต่อการพิจารณาระดับ L1 ข้อยกเว้นประการหนึ่งคือการเรียงลำดับร่วมกัน ซึ่งมีผลกระทบอย่างมีนัยสำคัญต่อมูลค่าการแยกสูงสุด (MEV)
ขยายการดำเนินการบน L1
เรากำลังแก้ไขปัญหาอะไรอยู่?
หาก L2 สามารถปรับขนาดได้และประสบความสำเร็จอย่างมาก แต่ L1 ยังคงสามารถรองรับปริมาณธุรกรรมที่น้อยมากเท่านั้น ความเสี่ยงหลายประการอาจเกิดขึ้นสำหรับ Ethereum:
1. สถานะทางเศรษฐกิจของสินทรัพย์ ETH จะไม่เสถียรมากขึ้น ซึ่งจะส่งผลต่อความปลอดภัยของเครือข่ายในระยะยาว
2. L2 จำนวนมากได้รับประโยชน์จากความสัมพันธ์ใกล้ชิดกับระบบนิเวศทางการเงินที่มีการพัฒนาอย่างมากบน L1 หากระบบนิเวศนี้อ่อนแอลงอย่างมาก แรงจูงใจในการเป็น L2 (แทนที่จะกลายเป็น L1 ที่เป็นอิสระ) ก็จะลดลง
3. L2 จะใช้เวลานานในการบรรลุการรับประกันความปลอดภัยเช่นเดียวกับ L1
4. หาก L2 ล้มเหลว (เช่น เนื่องจากพฤติกรรมที่เป็นอันตรายของผู้ปฏิบัติงานหรือการหายตัวไป) ผู้ใช้ยังคงต้องกู้คืนทรัพย์สินของตนผ่าน L1 ดังนั้น L1 จึงต้องมีพลังมากพอที่จะจัดการกับงานตกแต่งที่ซับซ้อนสูงและยุ่งเหยิงของ L2 เป็นครั้งคราว
ด้วยเหตุผลเหล่านี้ จึงมีประโยชน์อย่างยิ่งที่จะขยาย L1 ต่อไป และรับประกันว่าจะสามารถรองรับกรณีการใช้งานได้มากขึ้นเรื่อยๆ
มันคืออะไร? มันทำงานอย่างไร?
วิธีที่ง่ายที่สุดในการขยายขนาดคือการเพิ่มขีดจำกัดของแก๊สโดยตรง อย่างไรก็ตาม สิ่งนี้สามารถรวมศูนย์ L1 ได้ ซึ่งจะบ่อนทำลายคุณสมบัติที่สำคัญอีกอย่างหนึ่งที่ทำให้ Ethereum L1 ทรงพลังมาก นั่นคือความน่าเชื่อถือในฐานะเลเยอร์ฐานที่แข็งแกร่ง ยังคงมีการถกเถียงกันอยู่ว่าการเพิ่มขีดจำกัดของก๊าซนั้นยั่งยืนเพียงใด และจะขึ้นอยู่กับเทคนิคอื่นๆ ที่ใช้เพื่อทำให้การตรวจสอบบล็อกขนาดใหญ่ง่ายขึ้น (เช่น การหมดอายุของประวัติ ไร้สถานะ หลักฐานความถูกต้องของ L1 EVM) สิ่งสำคัญอีกประการหนึ่งที่ต้องปรับปรุงอย่างต่อเนื่องคือประสิทธิภาพของซอฟต์แวร์ไคลเอนต์ Ethereum ซึ่งมีประสิทธิภาพมากขึ้นในปัจจุบันมากกว่าเมื่อห้าปีที่แล้ว กลยุทธ์การกำหนดปริมาณก๊าซ L1 ที่มีประสิทธิผลจะเกี่ยวข้องกับการเร่งการพัฒนาเทคโนโลยีการตรวจสอบเหล่านี้
EOF: รูปแบบไบต์โค้ด EVM ใหม่ที่เป็นมิตรต่อการวิเคราะห์แบบคงที่มากขึ้นและช่วยให้สามารถนำไปใช้งานได้เร็วขึ้น เมื่อคำนึงถึงการปรับปรุงประสิทธิภาพเหล่านี้ EOF bytecode สามารถลดต้นทุนการใช้ก๊าซได้
ราคาก๊าซหลายมิติ: การตั้งค่าค่าธรรมเนียมพื้นฐานและขีดจำกัดที่แตกต่างกันสำหรับการประมวลผล ข้อมูล และพื้นที่เก็บข้อมูลสามารถเพิ่มความจุโดยเฉลี่ยของ Ethereum L1 ได้โดยไม่ต้องเพิ่มความจุสูงสุด (ซึ่งจะช่วยหลีกเลี่ยงการสร้างความเสี่ยงด้านความปลอดภัยใหม่ ๆ )
การลดต้นทุนการใช้น้ำมันสำหรับ opcodes และการคอมไพล์ล่วงหน้าเฉพาะ - ในอดีต เราได้เพิ่มต้นทุนการใช้น้ำมันซ้ำแล้วซ้ำเล่าสำหรับการดำเนินการที่มีราคาต่ำเกินไปบางอย่างเพื่อหลีกเลี่ยงการโจมตีแบบปฏิเสธการให้บริการ สิ่งหนึ่งที่สามารถทำได้มากกว่านี้คือการลดต้นทุนการใช้ opcode ที่เกินราคา ตัวอย่างเช่น การบวกมีราคาถูกกว่าการคูณมาก แต่ปัจจุบันรหัส ADD และ MUL มีราคาเท่าเดิม เราสามารถทำให้ ADD ถูกลงและ opcodes ที่ง่ายกว่าอย่าง PUSH ถูกลงได้ EOF ได้รับการปรับให้เหมาะสมโดยรวมมากขึ้นในเรื่องนี้
EVM-MAX และ SIMD: EVM-MAX เป็นข้อเสนอเพื่อให้คณิตศาสตร์แอนะล็อกจำนวนมากที่มีประสิทธิภาพมากขึ้นเป็นโมดูลแยกต่างหากของ EVM เว้นแต่จะมีการส่งออกโดยเจตนา ค่าที่คำนวณโดยการคำนวณ EVM-MAX จะสามารถเข้าถึงได้โดย opcode EVM-MAX อื่นๆ เท่านั้น ซึ่งช่วยให้มีพื้นที่มากขึ้นในการจัดเก็บค่าเหล่านี้ในรูปแบบที่ปรับให้เหมาะสม SIMD (คำสั่งเดียวหลายข้อมูล) เป็นข้อเสนอที่ช่วยให้การดำเนินการคำสั่งเดียวกันบนอาร์เรย์ของค่ามีประสิทธิภาพ ทั้งสองร่วมกันสร้างโปรเซสเซอร์ร่วมที่ทรงพลังควบคู่ไปกับ EVM ที่สามารถใช้เพื่อดำเนินการเข้ารหัสได้อย่างมีประสิทธิภาพมากขึ้น สิ่งนี้มีประโยชน์อย่างยิ่งสำหรับโปรโตคอลความเป็นส่วนตัวและระบบป้องกัน L2 ดังนั้นจึงช่วยในการปรับขนาด L1 และ L2
การปรับปรุงเหล่านี้จะกล่าวถึงรายละเอียดเพิ่มเติมในบทความ Splurge ในอนาคต
สุดท้าย กลยุทธ์ที่สามคือการโรลอัปแบบเนทิฟ (หรือโรลอัปที่ประดิษฐาน): โดยพื้นฐานแล้วเป็นการสร้างสำเนาของ EVM จำนวนมากที่ทำงานแบบขนาน ส่งผลให้ได้โมเดลที่เทียบเท่ากับที่ Rollup สามารถให้ได้ แต่จะผสานรวมเข้ากับโปรโตคอลโดยกำเนิดมากกว่า
ลิงค์ไปยังงานวิจัยที่มีอยู่คืออะไร?
โรดแมปการขยาย Ethereum L1 ของ Polynya: 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
บทสัมภาษณ์ Max Resnick เกี่ยวกับมูลค่าของการปรับขนาด L1: https://x.com/BanklessHQ/status/1831319419739361321
Justin Drake พูดถึงการปรับขนาดด้วย SNARK และ Rollups ดั้งเดิม: https://www.reddit.com/r/ethereum/comments/1f81ntr/comment/llmfi28/
จะต้องทำอะไรอีกและมีข้อเสียอะไรบ้าง?
มีสามกลยุทธ์สำหรับการขยาย L1 ซึ่งสามารถทำได้ทีละรายการหรือแบบคู่ขนาน:
ปรับปรุงเทคโนโลยี (เช่น รหัสไคลเอนต์ ไคลเอนต์ไร้สัญชาติ การหมดอายุของประวัติ) เพื่อให้ L1 ตรวจสอบได้ง่ายขึ้น จากนั้นจึงเพิ่มขีดจำกัดของก๊าซ
ลดต้นทุนสำหรับการดำเนินงานเฉพาะและเพิ่มกำลังการผลิตโดยเฉลี่ยโดยไม่เพิ่มความเสี่ยงกรณีที่เลวร้ายที่สุด
Native Rollups (นั่นคือการสร้างสำเนา EVM แบบขนาน N ชุด)
เมื่อทำความเข้าใจกับเทคโนโลยีที่แตกต่างกันเหล่านี้ เราจะพบว่ามีข้อแลกเปลี่ยนที่แตกต่างกัน ตัวอย่างเช่น Rollups แบบเนทีฟประสบกับจุดอ่อนหลายประการในความสามารถในการเขียนแบบเดียวกับ Rollups ธรรมดา: คุณไม่สามารถส่งธุรกรรมเดียวเพื่อดำเนินการพร้อมกันในหลาย Rollups ได้ เหมือนกับที่คุณสามารถทำได้ภายในสัญญาบน L1 (หรือ L2) เดียวกันนั้น ทาง. การเพิ่มขีดจำกัดจะลดประโยชน์อื่นๆ ที่สามารถทำได้โดยทำให้การตรวจสอบ L1 ง่ายขึ้น เช่น การเพิ่มสัดส่วนของผู้ใช้ที่ใช้งานโหนดตรวจสอบความถูกต้อง และการเพิ่มจำนวนผู้เดิมพันเดี่ยว ขึ้นอยู่กับการใช้งาน การทำให้การดำเนินการเฉพาะใน EVM (Ethereum Virtual Machine) ถูกลงอาจเพิ่มความซับซ้อนโดยรวมของ EVM
คำถามสำคัญที่แผนงานการปรับขนาด L1 จำเป็นต้องตอบคือ อะไรคือวิสัยทัศน์ขั้นสูงสุดสำหรับ L1 และ L2 แน่นอนว่าการวางทุกอย่างไว้บน L1 นั้นไร้สาระ กรณีการใช้งานที่เป็นไปได้อาจเกี่ยวข้องกับธุรกรรมนับแสนรายการต่อวินาที ซึ่งจะทำให้ L1 ไม่สามารถตรวจสอบได้อย่างสมบูรณ์ (เว้นแต่เราจะใช้แนวทาง Rollup ดั้งเดิม) แต่เราต้องการแนวทางบางอย่างเพื่อให้แน่ใจว่าเราจะไม่ตกอยู่ในสถานการณ์ที่ขีดจำกัดก๊าซเพิ่มขึ้น 10 เท่า และส่งผลเสียร้ายแรงต่อการกระจายอำนาจของ Ethereum L1
มุมมองการแบ่งงานระหว่าง L1 และ L2
ฉันจะโต้ตอบกับส่วนอื่นๆ ของแผนงานได้อย่างไร
การนำผู้ใช้เข้าสู่ L1 มากขึ้น ไม่เพียงแต่หมายถึงการปรับปรุงการปรับขนาดเท่านั้น แต่ยังปรับปรุงด้านอื่นๆ ของ L1 ด้วย ซึ่งหมายความว่า MEV จะยังคงอยู่ที่ L1 มากขึ้น (แทนที่จะเป็นเพียงปัญหา L2) ดังนั้นความจำเป็นในการจัดการ MEV อย่างชัดเจนจึงกลายเป็นเรื่องเร่งด่วนมากขึ้น สิ่งนี้จะเพิ่มมูลค่าของเวลาสล็อตที่รวดเร็วใน L1 อย่างมาก ในขณะเดียวกัน การดำเนินการนี้ยังต้องอาศัยความคืบหน้าอย่างราบรื่นของการตรวจสอบ L1 (the Verge) อีกด้วย
IOS
Android