เรียนรู้เกี่ยวกับความคืบหน้าในการดำเนินการตามแผนงาน Ethereum ในบทความเดียว

DeFi之道

特邀专栏作者

2022-11-29 12:30

บทความนี้มีประมาณ 5885 คำ การอ่านทั้งหมดใช้เวลาประมาณ 9 นาที

ทำอะไรสำเร็จและก้าวต่อไปคืออะไร?

สรุปโดย AI

ขยาย

ทำอะไรสำเร็จและก้าวต่อไปคืออะไร?

รวบรวมข้อความต้นฉบับ: The Way of DeFi

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

เป็นเอกสารที่มีชีวิต โปรดอย่าลังเลที่จะติดต่อฉันหากข้อมูลใดๆ ที่ระบุในที่นี้ไม่ชัดเจน ไม่ถูกต้อง ล้าสมัย หรือขาดลิงก์ที่ดีกว่า

ตามที่ลูกศรระบุบนแผนงาน ระยะต่างๆ ที่ระบุไว้จะไม่เรียงตามลำดับ และความพยายามต่างๆ จะเกิดขึ้นควบคู่กันไป

1. การผสาน

เป้าหมาย: เพื่อให้ได้ฉันทามติ Proof of Stake (PoS) ในอุดมคติ เรียบง่าย แข็งแกร่ง และกระจายอำนาจ

สิ่งที่ได้ทำ

1. 1 ธันวาคม 2020 - เปิดตัว Beacon chain

ขอแนะนำเลเยอร์ฉันทามติของ Ethereum ที่ได้รับการรักษาความปลอดภัยโดย ETH ที่เดิมพันโดยผู้ตรวจสอบความถูกต้อง
เรียกว่าเฟส 0 ในข้อกำหนดฉันทามติ (เวอร์ชันที่มีคำอธิบายประกอบของ Vitalik และ Danny Ryan);

2. 27 ตุลาคม 2021 - Warm up fork (Altair) - การทดลองใช้ไคลเอ็นต์ที่เป็นเอกฉันท์ของนักพัฒนาเรียกใช้การอัปเกรดฮาร์ดฟอร์กที่ประสานงานกัน

Altair แนะนำคณะกรรมการการซิงค์เพื่อสนับสนุนลูกค้ารายเล็กและปรับบทลงโทษบางส่วน
ประกาศ Altair;
ข้อมูลจำเพาะของ Altair (เวอร์ชันที่มีคำอธิบายประกอบ);
บทความ "มีอะไรใหม่ใน ETH 2" เกี่ยวกับ Altair;

3. 15 กันยายน 2565 - รวม! ไม่มี PoW อีกต่อไป - ชั้น Consensus และชั้น Enforcement มีการผสานครั้งใหญ่ที่บล็อก 15,537,394

อะไรต่อไป

1. การถอน – ช่วยให้ผู้ตรวจสอบสามารถถอนเงินเดิมพัน ETH ทั้งหมดหรือบางส่วนได้

Capella forks ระบุการเปลี่ยนแปลงในเลเยอร์ฉันทามติ
EIP-4895 ระบุการเปลี่ยนแปลงในชั้นการดำเนินการ
คำถามที่พบบ่อยของ Tim Beiko เกี่ยวกับการถอนเงิน
ข้อกำหนดเมตาการถอนพร้อมข้อมูลเพิ่มเติม

2. ตัวตรวจสอบความถูกต้องแบบกระจาย - แนะนำหลายลายเซ็น โดยที่บุคคล n คนใช้ตัวตรวจสอบความถูกต้องเดียวกันร่วมกัน และ m-of-n ต้องตกลงว่าจะทำงานอย่างไร

ปรับปรุงการเดิมพันโดยป้องกันการฟันโดยไม่ได้ตั้งใจและทำให้สามารถเข้าถึงได้มากขึ้น (เช่น การแจกจ่าย 32 ETH ที่จำเป็นให้กับผู้เข้าร่วมหลายคนอย่างไม่ไว้วางใจ)
นี่ไม่ใช่สิ่งที่อยู่ในโปรโตคอล ทีมอย่าง SSV และ Obol กำลังดำเนินการอยู่

3. ดูการผสาน - ปรับกฎการเลือกส้อม (วิธีที่ผู้ตรวจสอบความถูกต้องลงคะแนน) เพื่อลดระดับของการโจมตี

โดยพื้นฐานแล้วการเปิดใช้งานผู้ตรวจสอบที่ซื่อสัตย์สามารถ "กำหนด" ความคิดเห็นของพวกเขาต่อหัวหน้าห่วงโซ่ที่ถูกต้องเพื่อลดโอกาสที่ผู้ตรวจสอบความถูกต้องที่เป็นอันตรายจะแยกคะแนนเสียงและจัดระเบียบบล็อกใหม่ในภายหลังตามต้องการ
โพสต์ ethresear.ch ที่มีพื้นฐานการวิจัย (ทางเทคนิคมาก) มากมาย

4. การรวมที่ปรับปรุงใหม่ - Ethereum มุ่งมั่นที่จะสนับสนุนตัวตรวจสอบความถูกต้องให้ได้มากที่สุดเท่าที่จะเป็นไปได้ แต่การที่ตัวตรวจสอบความถูกต้องแต่ละรายการลงคะแนนในแต่ละบล็อก สิ่งที่ดีที่สุดรองลงมาคือลายเซ็นรวม แต่ก็มีข้อจำกัดและสามารถทำได้ดีกว่านี้

โพสต์เกี่ยวกับวิทยาศาสตร์ยอดนิยมเกี่ยวกับประโยชน์ของการรวม BLS
ผู้ที่มีศักยภาพ: ฮอร์น;

5. Single slot finality (SSF) - ห่วงโซ่ถูกกำหนดโดยแต่ละช่อง (12 วินาที) แทนที่จะเป็นยุค (12.8 นาที)

เส้นทางสู่ SSF;
นอกจากการรวมลายเซ็นที่ปรับปรุงแล้ว เราจำเป็นต้องจัดการอีกสองสิ่ง:

(1) อัลกอริทึมที่สอดคล้องกันของ SSF - อัลกอริทึมที่เข้ากันได้กับ SSF ที่มีอยู่นั้นไม่เพียงพอ เราต้องการอัลกอริทึมที่สามารถทำให้ห่วงโซ่ใช้งานได้แม้ว่าตัวตรวจสอบความถูกต้องมากกว่า 1/3 จะออฟไลน์อยู่

(2) SSF Validator Economics - หากเราต้องจำกัดจำนวน Validator เราจะจำกัดการมีส่วนร่วมอย่างไร และเราเสียสละอะไรบ้าง?

6. การเลือกตั้งผู้นำลับ (SLE)

วันนี้ ผู้ตรวจสอบความถูกต้อง (ผู้นำช่อง) ที่เลือกเพื่อเสนอบล็อกเป็นที่รู้จักล่วงหน้า ทำให้การโจมตี DoS ที่อาจเกิดขึ้นสามารถกำหนดเป้าหมายผู้นำของบล็อกที่กำลังจะมาถึงได้อย่างเฉพาะเจาะจง
โพสต์ของ ethresear.ch บนโปรโตคอล SLE เดียวที่มีการสุ่มสับ: ไม่มีใครรู้ว่าใครจะเป็นผู้นำของสล็อตยกเว้นผู้นำเองจนกว่าพวกเขาจะเปิดเผยบล็อกและหลักฐานการเป็นผู้นำ
การเลือกผู้นำแบบลับๆ ที่ไม่ใช่คนเดียวก็อาจเป็นทางเลือกได้เช่นกัน

7. การสนับสนุนผู้ตรวจสอบความถูกต้องมากขึ้น - ความพยายามระยะยาวอย่างต่อเนื่อง: การสนับสนุนผู้ตรวจสอบความถูกต้องอย่างปลอดภัยเป็นสิ่งที่พึงปรารถนาเสมอ

8. ลายเซ็นที่เป็นมิตรกับควอนตัมปลอดภัย - ทำให้ Ethereum ปลอดภัยจากการโจมตีคอมพิวเตอร์ควอนตัม

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

9. ใช้ EIP-4844 - ใช้ EIP-4844 กับ Ethereum mainnet

จำเป็นต้องมี "พิธีการ" เพื่อสร้างการตั้งค่าที่น่าเชื่อถือ: คำอธิบาย ลำดับเวลาโดยประมาณ ข้อมูลจำเพาะ;
ภาพรวมเส้นเวลาการใช้งาน EIP-4844;

10. การขยายค่าสะสมพื้นฐาน - ขึ้นอยู่กับสิ่งต่อไปนี้:

EIP-4844 - การปรับขนาดยังถือว่าเป็นพื้นฐาน/จำกัด เนื่องจากลักษณะ "ทุกโหนดดาวน์โหลดข้อมูลทั้งหมด" ที่จำกัดความจุที่ใช้งานได้ของ blobspaces
วงล้อการฝึกที่จำกัดแบบโรลอัพ (ดูเหตุการณ์สำคัญที่เสนอ);

11. ขยายค่าสะสมให้เสร็จสมบูรณ์ - ขึ้นอยู่กับสิ่งต่อไปนี้:

การออกแบบ P2P สำหรับการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล: ความพยายามและการวิจัยทั้งหมดที่เกี่ยวข้องกับเครือข่ายที่จำเป็นสำหรับการแบ่งส่วนข้อมูล
ไคลเอนต์การสุ่มตัวอย่าง DA: พัฒนาไคลเอ็นต์ที่มีน้ำหนักเบาซึ่งสามารถระบุได้อย่างรวดเร็วว่าข้อมูลพร้อมใช้งานผ่านการสุ่มตัวอย่างหลายกิโลไบต์หรือไม่
การรักษาตัวเองของ DA ที่มีประสิทธิภาพ: สามารถสร้างข้อมูลทั้งหมดใหม่ได้อย่างมีประสิทธิภาพภายใต้สภาวะเครือข่ายที่เลวร้ายที่สุด (เช่น การโจมตีด้วยตัวตรวจสอบที่เป็นอันตราย หรือการหยุดทำงานเป็นเวลานานของโหนดจำนวนมาก)
Rollups ที่ไม่มีวงล้อฝึก: Sequencers ที่กระจายอำนาจอย่างเต็มที่ ผู้พิสูจน์การฉ้อโกงที่ไว้ใจไม่ได้ สัญญาที่ไม่เปลี่ยนรูป ฯลฯ

12. ความปลอดภัยควอนตัมและสัญญาของการตั้งค่าที่ไม่น่าเชื่อถือ - ทำให้ Ethereum มีภูมิคุ้มกันต่อคอมพิวเตอร์ควอนตัม

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

2. หายนะ

ลิงก์ที่เกี่ยวข้อง:

ชี้นำโดยความเป็นกลางที่เชื่อถือได้
ทวีตต่างๆ เกี่ยวกับ MEV;
บทความเกี่ยวกับ MEV และ PBS;
รายการลิงค์บน PBS;

สิ่งที่ได้ทำ

1. ตลาด MEV นอกโปรโตคอล - มิดเดิลแวร์ MEV-Boost ช่วยให้ผู้ตรวจสอบทั่วไปสามารถทำกำไรจาก MEV โดยไม่ต้องเรียกใช้กลยุทธ์ MEV ที่ซับซ้อนด้วยตนเอง

วิธีแก้ปัญหายังไม่สมบูรณ์เนื่องจากมีปัญหาเรื่องการเซ็นเซอร์
ดู Resilience Costs และ SUAVE สำหรับแนวคิดและแผนการทำให้ตลาดที่อยู่นอกข้อตกลงเหล่านี้มีความยืดหยุ่นมากขึ้น

อะไรต่อไป

1. รายการรวมหรือทางเลือกอื่น - ให้ผู้เสนอบล็อกกำหนดข้อจำกัดกับผู้สร้างบล็อก เช่น บังคับให้รวมการทำธุรกรรม

(1) มีคำอธิบายประกอบรายการ;

(2) การวิจัยเกี่ยวกับการสร้างบล็อกที่มีข้อจำกัดโดยไม่สร้างภาระให้กับผู้เสนอบล็อก

2. PBS ในโปรโตคอล – รวมตลาดสำหรับผู้สร้างบล็อกเข้ากับโปรโตคอลโดยตรง

3. MEV เผาไหม้ - ให้ blockchain จับมูลค่าที่สกัดจากเศรษฐกิจแบบ on-chain

(1) การทำลายข้อเสนอ MEV โดยตรงผ่านการประมูลของผู้เสนอ

(2) การปรับให้เรียบ MEV ที่ขับเคลื่อนโดยคณะกรรมการจะช่วยให้โปรโตคอลสามารถรับรู้ MEV ได้

(3) การจำกัดตัวตรวจสอบที่กำหนดโดยสิ่งจูงใจทางเศรษฐกิจจะทำให้ MEV เสียหายทางอ้อมผ่านการออกเชิงลบ

4. Application Layer MEV Minimization - ไม่เกี่ยวข้องโดยตรงกับ L1 โครงการนี้เกี่ยวข้องกับนักพัฒนาที่คำนึงถึง MEV เมื่อออกแบบ dapps ต่อไปนี้คือตัวอย่างบางส่วนของ Dapp ที่ใช้กลยุทธ์การลดขนาด MEV

แทร็กตัวสร้างแบบกระจาย

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

การสร้าง Blob - การค้นหาวิธีที่จะลดแบนด์วิธสูงและความต้องการในการประมวลผลของ data sharding ในหลาย ๆ โหนดที่ฮาร์ดแวร์สำหรับผู้บริโภคทั่วไปสามารถทำงานได้
บริการยืนยันล่วงหน้า - ให้การรับประกันที่หนักแน่นแก่ผู้ใช้ว่าการทำธุรกรรมของพวกเขาจะรวมอยู่ในบล็อกถัดไป
การป้องกันสารตะกั่ว - ลด MEV ที่เป็นพิษให้เหลือน้อยที่สุด เช่น การทำธุรกรรมแบบแซนด์วิช เพื่อให้การสร้างแบบกระจายเป็นกลางอย่างน่าเชื่อถือ

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

นี่คือลิงค์ที่เกี่ยวข้องบางส่วน:

พูดคุยเกี่ยวกับการสร้างบล็อกแบบผสานซึ่งกล่าวถึงการสร้างบล็อกแบบกระจายอำนาจ: https://www.youtube.com/watch?v=KP 5 ppCRH 0 iM
พูดคุยกับผู้สร้างบล็อกแบบกระจายศูนย์: https://www.youtube.com/watch?v=fAgrIdyWIqc
ความคิดบางประการเกี่ยวกับการสร้างบล็อกแบบกระจาย: https://github.com/flashbots/mev-boost/issues/139

3. เดอะเวอร์จ

เป้าหมาย: การยืนยันบล็อกควรเป็นเรื่องง่ายมาก - ดาวน์โหลดข้อมูล N ไบต์ ทำการคำนวณพื้นฐาน ยืนยัน SNARK เท่านี้ก็เสร็จเรียบร้อย

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

ทุกอย่างอาศัยเทคนิคที่ไม่มีความรู้ เช่น SNARK และ STARK ซึ่งอาศัยแผนการผูกมัดพหุนาม นี่คือลิงค์ที่เกี่ยวข้องบางส่วน:

แนะนำวิธีการนำ zk-SNARKs ไปใช้โดยสังเขป
บทวิเคราะห์ของ STARK;
หากคุณรู้คณิตศาสตร์และการเขียนโปรแกรมมาบ้าง บทความนี้จะช่วยให้คุณเข้าใจว่า zk-SNARK คืออะไร;
เกี่ยวกับบทบาทของ Polynomial Commitment Scheme ในการปรับขนาด Ethereum

สิ่งที่ได้ทำ

1. แก้ไขปัญหา EVM DoS ที่ร้ายแรงที่สุด - ส่วนใหญ่เป็นปัญหาราคาก๊าซ ซึ่งได้รับการแก้ไขแล้วในการอัปเกรดเบอร์ลิน

2. การสนับสนุนไคลเอ็นต์แบบไลท์พื้นฐาน (คณะกรรมการการซิงโครไนซ์) - ด้วยคณะกรรมการการซิงโครไนซ์ ทำให้ง่ายต่อการสร้างไคลเอ็นต์แบบไลท์ที่เป็นไปตามชั้นฉันทามติ

ตรวจสอบวิธีที่ลูกค้า Helios ใช้คณะกรรมการแบบซิงโครนัส (และบทความที่ดีเกี่ยวกับวิธีการทำงานของคณะกรรมการเหล่านี้)

อะไรต่อไป

1. SNARK / STARK ASIC - ฮาร์ดแวร์ที่สร้างขึ้นโดยเฉพาะสำหรับการสร้างหลักฐาน

2. ต้นไม้ Verkle - แทนที่โครงสร้างข้อมูลที่ใช้สำหรับสถานะส่วนกลางด้วยโครงสร้างข้อมูลที่มีประสิทธิภาพมากขึ้น:

(1) รายชื่อต้นไม้ Verkle ที่เชื่อมโยง;

(2) ประโยชน์หลักคือการมีหลักฐานสั้นๆ ที่ไคลเอ็นต์ light สามารถตรวจสอบยืนยันสิ่งต่างๆ ได้อย่างง่ายดาย เช่น ยอดคงเหลือในบัญชีโดยใช้เฉพาะส่วนหัวของบล็อก - พวกเขาสามารถใช้ประโยชน์จากคณะกรรมการการซิงค์เพื่อยืนยันว่าบล็อกที่กำหนด ส่วนหัวของบล็อกนั้นเป็นส่วนหนึ่งของหลัก โซ่;

(3) พึ่งพาการค้นหาข้อมูลจำเพาะที่ถูกต้อง วิธีการเปลี่ยนอย่างปลอดภัย และจะส่งผลต่อต้นทุนแก๊ส EVM ของสถานะการอัปเดต/แก้ไขอย่างไร (ขึ้นอยู่กับการไม่อนุญาต SELF-DESTRUCT ใน The Purge)

3. ไคลเอนต์แสงที่ใช้ SNARK – SNARKify การเปลี่ยนคณะกรรมการการซิงโครไนซ์เพื่อพิสูจน์อย่างรวดเร็วว่าผู้ตรวจสอบความถูกต้องของคณะกรรมการการซิงโครไนซ์ปัจจุบันประกอบด้วยใคร

4. SNARKed Ethereum อย่างสมบูรณ์ - 3 รายการต่อไปนี้รวมกันถือเป็นหลักชัยสำคัญสำหรับ Ethereum ในการยืนยันการบล็อกที่มีประสิทธิภาพอย่างยิ่งและไร้ความน่าเชื่อถือ:

(1) SNARK สำหรับการพิสูจน์ Verkle - ด้วยการรวมการพิสูจน์ Verkle เข้ากับ SNARK บล็อกจะมีหลักฐานสั้นๆ อิสระของสถานะบางส่วนที่แก้ไข ดังนั้นจึงไม่จำเป็นต้องตรวจสอบสถานะทั้งหมดของบล็อก N-1 เพื่อยืนยันว่าบล็อกนั้นหรือไม่ N แก้ไขอย่างถูกต้อง

(2) SNARK สำหรับการเปลี่ยนสถานะฉันทามติ — ย้ายจากคณะกรรมการการซิงค์ที่ลดความไว้วางใจให้เหลือน้อยที่สุด ไปสู่การตรวจสอบที่ไม่ไว้วางใจอย่างเต็มที่ของทุกสิ่งที่เกิดขึ้นในชั้นฉันทามติ

(3) SNARKs สำหรับ L1 EVM - ใช้ประโยชน์จากความพยายามของทีมโรลอัพใน zk-EVM โดยการรวม zk-EVM เข้ากับ L1 โดยตรง (ดูโพสต์เกี่ยวกับโรลอัปเสริม)

5. เพิ่มขีดจำกัดก๊าซ L1 - ด้วยการขจัดภาระในปัจจุบันของ "ทุกโหนดต้องจัดเก็บทุกอย่าง" เพื่อตรวจสอบบล็อกด้วยวิธีที่ไม่ไว้วางใจ การมีบล็อกขนาดใหญ่จะทำให้ง่ายต่อการขยายขนาด L1 มากขึ้น (สิ่งนี้จะรวมส่วนขยาย L2 ทั้งหมดโดยอัตโนมัติ)

6. หันมาใช้ SNARK ที่ปลอดภัยด้วยควอนตัม (เช่น STARK) - เพื่อทำให้ Ethereum มีภูมิต้านทานต่อการโจมตีคอมพิวเตอร์ควอนตัม (ประสิทธิภาพของ SNARK อาศัยการเข้ารหัสที่ทราบกันว่าถอดรหัสโดยคอมพิวเตอร์ควอนตัม ในขณะที่ STARK ไม่ทำเช่นนั้น)

4. การชำระล้าง

เป้าหมาย: ลดความซับซ้อนของโปรโตคอล กำจัดหนี้ทางเทคนิค และจำกัดค่าใช้จ่ายในการเข้าร่วมในเครือข่ายโดยล้างข้อมูลประวัติเก่า

สิ่งที่ได้ทำ

1. กำจัดการขอคืนน้ำมันส่วนใหญ่ - การปรับราคาน้ำมันทั้งหมดเสร็จสิ้นในการอัปเกรดที่เบอร์ลิน

2. การซิงโครไนซ์ Beacon chain อย่างรวดเร็ว - งานพัฒนาทั้งหมดจะถูกซิงโครไนซ์จากยุคที่เสร็จสมบูรณ์ล่าสุด ไม่ใช่จากจุดเริ่มต้น (เรียกว่า "การซิงโครไนซ์ด่าน" ในไคลเอนต์ส่วนใหญ่ที่เป็นเอกฉันท์)

3. ข้อกำหนด EIP-4444—ดูข้อกำหนด EIP

อะไรต่อไป

1. การหมดอายุของประวัติ - ลดข้อกำหนดในการจัดเก็บ เวลาในการซิงโครไนซ์ และความซับซ้อนของรหัสโดยการทำให้ประวัติเก่าหมดอายุ

(1) ดูโพสต์ Twitter นี้;

(2) ขึ้นอยู่กับการใช้งาน EIP-4444 ซึ่งขึ้นอยู่กับการเข้าถึงประวัติทางเลือกด้วยวิธีอื่น (เช่น Portal Network)

(3) AMA ของ Vitalik เมื่อหมดอายุตามประวัติ;

2. การหมดอายุของสถานะ - แก้ปัญหา "จ่ายครั้งเดียว เก็บข้อมูลตลอดไป" ทั้งหมดเกี่ยวกับสถานะ

(1) แนวคิดคือการทำให้ส่วนที่ไม่ได้ใช้ของสถานะหมดอายุโดยอัตโนมัติ และเก็บเฉพาะรากต้นไม้ verkle ที่ผู้ใช้สามารถใช้เพื่อกู้คืนสถานะที่หมดอายุเมื่อจำเป็น

(2) AMA ของ Vitalik เกี่ยวกับการหมดอายุของสถานะ;

(3) พึ่งพา: Base State Expiration Specification - วิธีที่เราทำจริง ดูแผนงานที่เป็นไปได้ (และตัวเลือกอื่น ๆ )

การขยายพื้นที่ที่อยู่ - เพิ่มขนาดที่อยู่จาก 20 ไบต์เป็น 32 ไบต์เพื่อป้องกันการชนกันและเพิ่มข้อมูลเกี่ยวกับวัฏจักรสถานะ
การวิเคราะห์แอปพลิเคชัน - ค้นหาว่าอาจทำให้แอปพลิเคชัน/สัญญาปัจจุบันเสียหายได้อย่างไร และเหมาะสมอย่างไร

3. การปฏิรูปบันทึก - ลดความซับซ้อนของวิธีการทำงานของบันทึกเหตุการณ์เพื่อค้นหาเหตุการณ์ทางประวัติศาสตร์ได้อย่างมีประสิทธิภาพมากขึ้น

4. การประสานงานการทำให้เป็นอนุกรม - เลเยอร์การดำเนินการใช้ RLP สำหรับการทำให้เป็นอนุกรมข้อมูล ในขณะที่เลเยอร์ฉันทามติใช้ SSZ ซึ่งจะกำจัด RLP และใช้ SSZ ทุกที่

5. ลบประเภทธุรกรรมเก่า - หยุดสนับสนุนประเภทธุรกรรมเก่า (ดู EIP-2718) เพื่อลบความซับซ้อนของรหัสออกจากไคลเอนต์

6. แทร็กแบบง่าย EVM

(1) ปิดการใช้งาน SELFDESTRUCT - opcode นี้เป็นที่มาของปัญหามากมาย (EIP ที่เกี่ยวข้อง: EIP-4758 และ EIP-4760 และการสนทนา)

(2) ลดความซับซ้อนของกลไกแก๊ส - เกี่ยวข้องกับการลบคุณสมบัติ EVM ที่เกี่ยวข้องกับแก๊สจำนวนมากที่กล่าวถึงที่นี่

(3) การคอมไพล์ล่วงหน้า --> การใช้งาน EVM -- กำจัดสัญญาที่คอมไพล์แล้วและสนับสนุนการใช้งาน EVM โดยตรง (นั่นคือ การทำงานแบบโมดูลาร์ขนาดใหญ่ ดูที่ The Splurge)

5. การสาดโคลน

เป้าหมาย: แก้ไขทุกอย่างอื่น

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

สิ่งที่ได้ทำ

1. EIP-1559 - EIP อันโด่งดังนี้มีประโยชน์มากมายนอกเหนือจากการเบิร์น ETH

2. ข้อกำหนด ERC-4337 - ERC นี้มีวัตถุประสงค์เพื่อแนะนำการสรุปบัญชีโดยไม่ต้องแก้ไขโปรโตคอลหลัก (บทความคำอธิบายเบื้องต้นของ ERC-4337)

อะไรต่อไป

1. EIP-1559 ในขั้นตอนสุดท้าย – EIP-1559 ได้รับการปรับปรุงผ่านหลายมิติ

2. แทร็กการปรับปรุง EVM และแทร็กที่เรียบง่ายจาก The Purge ไปจนถึงขั้นตอนสุดท้ายของ EVM

(1) EVM Object Format (EOF) — ชุดของ EIP ที่อนุญาตให้มีการตรวจสอบและกำหนดเวอร์ชันของ EVM bytecode เมื่อปรับใช้ ดูบทความอธิบายนี้และกระทู้ Twitter;

(2) การดำเนินการแบบโมดูลาร์ขนาดใหญ่ - การเข้ารหัสส่วนใหญ่ในแผนงานต้องอาศัยการดำเนินการแบบโมดูลาร์จำนวนมาก ซึ่งสามารถทำได้อย่างมีประสิทธิภาพมากขึ้นโดยตรงใน EVM

(3) การปรับปรุง EVM เพิ่มเติม - สิ่งอื่นใดที่ควรค่าแก่การเพิ่มเพื่อปรับปรุง EVM - หรือสิ่งใดก็ตามที่ลบออกเพื่อขจัดความซับซ้อน

3. แทร็กนามธรรมของบัญชีที่นำไปสู่การสรุปบัญชีขั้นสุดท้าย สำหรับข้อมูลเพิ่มเติม โปรดดูคำอธิบายของ Vitalik เกี่ยวกับรายการต่อไปนี้:

(1) ERC-4337 - พัฒนากระเป๋าเงินอัจฉริยะที่ใช้งานร่วมกันได้เพื่อการใช้งานจริง

(2) การแปลง EOA โดยสมัครใจ - ผ่าน EIP บัญชีธรรมดาสามารถเพิ่มรหัสกลับไม่ได้เพื่อแปลงเป็นบัญชีสัญญา นั่นคือ กระเป๋าเงินอัจฉริยะที่ตรงตามมาตรฐาน 4337

(3) การแปลงภายในข้อตกลง - ทำให้การแปลงข้างต้นเป็นข้อบังคับสำหรับบัญชีที่มีอยู่ทั้งหมด

4. Verifiable Delay Function (VDF) - โดยพื้นฐานแล้ว "การพิสูจน์การทำงานที่ไม่สามารถเทียบเคียงได้" ซึ่งจะช่วยเพิ่มการสุ่มใน PoS เหนือสิ่งอื่นใด (ดูโพสต์ ethresear.ch บน VDF และการใช้งานที่เป็นไปได้)

5. สำรวจวิธีแก้ปัญหาสำหรับบัญชีฝุ่น - ประหยัด "กองทุนฝุ่น" ที่เสียค่าใช้จ่ายในการย้ายมากกว่าที่คุ้มค่า มีความคิดมากมายที่นี่: https://ethereum-magicians.org/t/some-medium-term-dust-cleanup-ideas/6287

ETH

ยินดีต้อนรับเข้าร่วมชุมชนทางการของ Odaily