ผู้แต่ง: Vitalik Buterin

คอมไพล์: Odaily ดาราดวงดาว คุณสามารถ

ตั้งแต่ 14 ตุลาคม เวลา คุณ Vitalic Buterin ผู้ก่อตั้ง ETH ได้เริ่มเผยแพร่การอภิปรายเกี่ยวกับอนาคตที่เป็นไปได้ของ ETH ตั้งแต่ "The Merge" ไปจนถึง "The Surge" "The Scourge" และ "The Verge" และเมื่อเร็วๆ นี้ได้เผยแพร่ "The Purge" ซึ่งเป็นการแสดงถึงความฝันของ Vitalic เกี่ยวกับการพัฒนา Mainnet ของ ETH และวิธีการแก้ปัญหาที่พวกเขากำลังเผชิญอยู่ในปัจจุบัน

The Merge: สํารวจการเปลี่ยนแปลงของ Ethereum ไปยัง PoS เพื่อปรับปรุงการสิ้นสุดของสล็อตเดี่ยวและลดเกณฑ์การปักหลักเพื่อเพิ่มการมีส่วนร่วมและความเร็วในการยืนยันธุรกรรม

《The Surge》: สำรวจและพูดคุยเกี่ยวกับยุทธศาสตร์ต่าง ๆ ในการขยายของ Ether และโดยเฉพาะเส้นทางที่มุ่งเน้น Rollup รวมถึงความท้าทายและวิธีการแก้ไขในเรื่องของความสามารถในการขยายตัวการกระจายอำนาจและความปลอดภัย

《The Scourge》: สำรวจความเสียหาย: ในกระบวนการเปลี่ยนแปลงจาก PoW เป็น PoS ของ Ethereum และเสี่ยงต่อการกลายเป็นระบบที่มีอำนาจที่ไม่เชื่อถือได้และการสกัดมูลค่า ได้พัฒนารูปแบบหลายอย่างเพื่อเสริมความกระจายอำนาจและความเป็นธรรมศีลธรรม พร้อมทั้งดำเนินการปฏิรูปเศรษฐกิจ stake เพื่อให้ความคุ้มครองผลประโยชน์ของผู้ใช้

《The Verge》: อธิบายความท้าทายและวิธีการแก้ไขการตรวจสอบสถานะที่ไม่มีของ ETH บล็อกเชน โดยเน้นการแนะนำเทคโนโลยี Verkle Tree และ STARK ซึ่งเพิ่มประสิทธิภาพและการกระจายอำนาจของบล็อกเชน

ในวันที่ 26 ตุลาคม วิทาลิค บุตเตอรินเผยแพร่บทความเกี่ยวกับ "The Purge" โดยบทความนี้สนทนาถึงความท้าทายที่ Ethereum ต้องเผชิญหน้าในอนาคตเมื่อต้องเผชิญกับภาระของความซับซ้อนและความต้องการการเก็บรักษาข้อมูลในระยะยาว โดยเรียกเก็บว่าการปล่อยประวัติศาสตร์และการปล่อยสถานะ และผ่านการล้างคุณลักษณะเพื่อทำให้โปรโตคอลเป็นไปอย่างง่ายดาย นอกจากนี้ยังมีมาตรการอื่น ๆ เพื่อให้เครือข่ายสามารถยังคงต่อเนื่องและสามารถขยายได้ เช่นเดียวกับการลดภาระการเก็บข้อมูลของไคลเอนต์ โดยใช้การใช้งานประวัติศาสตร์และสถานะที่ผ่านมาในเวลาที่จำกัด 01928374656574839201

ด้านล่างเป็นเนื้อหาต้นฉบับที่แปลโดย Odaily Planet Daily.

ขอบคุณอย่างเป็นพิเศษ Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden และ Tomasz Stanczak สำหรับคำแนะนำและการตรวจสอบ

โดยทั่วไปแล้ว หนึ่งในความท้าทายของ Ethereum คือ บล็อกเชนโปรโตคอล ที่มีความขยายตัวและซับซ้อนเพิ่มขึ้นตามเวลาโดยค่าเริ่มต้น สิ่งนี้เกิดขึ้นที่สองที่

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

ฟังก์ชันโปรโตคอล: การเพิ่มฟังก์ชันใหม่ง่ายกว่าการลบฟังก์ชันเก่าทำให้ความซับซ้อนของรหัสเพิ่มขึ้นตามเวลา

เพื่อให้เอเทอร์เรียมสามารถอยู่ได้ยาวนาน เราต้องมีแรงกดดันที่แข็งแกร่งสำหรับทั้ง 2 แนวโน้มนี้ โดยเวลาผ่านไป ปล่อยความซับซ้อนและการขยายตัว แต่ในเวลาเดียวกัน เราต้องรักษาคุณสมบัติที่สำคัญหนึ่งในการทำให้บล็อกเชนยอดเยี่ยม : ความคงทน คุณสามารถวางโทเค็นที่ไม่สามารถแทนที่ได้ ส่งข้อความอารมณ์ในการทำธุรกรรม หรือสัญญาอัจฉริยะที่มีมูลค่า 1 ล้านดอลลาร์ลงในเครื่องทำธุรกรรม (on-chain) เข้าไปในหลุมถ้ำเป็นเวลา 10 ปี และพบว่ามันยังคงอยู่ที่นั่นรอคุณอ่านและโต้ตอบ ในการทำให้ DApp มั่นใจและลบกุญแจลับการอัปเกรดตัวเองออก พวกเขาต้องมั่นใจว่าลูกน้องของพวกเขาจะไม่ได้อัปเกรดในทางที่ทำให้พวกเขาเสียหายโดยเฉพาะอย่างยิ่ง L1 ตัวเอง

หากเราตั้งใจทำการสมดุลระหว่างความต้องการทั้งสองและลดหรือเปลี่ยนทางความอึดอัด ความซับซ้อนและความเสื่อมถอยลงให้มากที่สุดโดยยังคงความต่อเนื่องนั้นเป็นเรื่องที่เป็นไปได้อย่างแน่นอน สิ่งมีชีวิตสามารถทำได้: แม้ว่าส่วนมากของสิ่งมีชีวิตจะเสื่อมโทรมไปพร้อมกับเวลา แต่ก็มีสิ่งมีชีวิตบางส่วนที่ไม่ได้เป็นอย่างนั้น แม้ว่าระบบสังคมยังสามารถมีอายุยืนได้นานมาก ในบางกรณี ETH ได้ประสบความสำเร็จ: พยายามหางานหายไป และคำสั่ง SELFDESTRUCT หายไปเป็นส่วนใหญ่ Beacon Chain โหนดเก็บข้อมูลย้อนหลังได้ถึงหกเดือน ค้นหาวิธีที่สามารถทำให้ ETH ดำเนินไปในทางที่สามารถใช้กับ ETH ในลักษณะที่ทั่วไปและเป็นไปในทางที่มีความเสถียรในระยะยาว มันเป็นความท้าทายสุดท้ายที่ ETH ต้องเผชิญหน้าในด้านความยืดหยุ่นในระยะยาว ความยั่งยืนทางเทคโนโลยีและความปลอดภัย

The Purge: จุดหมายหลัก

โดยการลดหรือกำจัดความจำเป็นที่โหนดแต่ละโหนดจะต้องเก็บรักษาการบันทึกประวัติทั้งหมดหรือสถานะที่สุดท้าย

ลดความซับซ้อนของโปรโตคอลโดยการลบฟังก์ชันที่ไม่จำเป็น

สารบัญบทความ:

การหมดอายุของประวัติศาสตร์ (History expiry)

หมดอายุของรัฐ

การทำความสะอาดคุณลักษณะ

วันหมดอายุของประวัติศาสตร์

แก้ปัญหาอะไร

ณ เวลาที่เขียนบทความนี้, โหนด Ethereum ที่ซิงโครไนซ์อย่างสมบูรณ์ต้องใช้พื้นที่ดิสก์ประมาณ 1.1 TB เพื่อเรียกใช้ไคลเอนต์และรวมถึงพื้นที่ดิสก์อีกหลายร้อย GB เพื่อฉันทามติไคลเอนต์ ซึ่งเป็นข้อมูลประวัติศาสตร์ส่วนใหญ่: ข้อมูลเกี่ยวกับบล็อก, ธุรกรรม, และใบเสร็จที่มีอยู่มาหลายปี นี่หมายความว่าถึงแม้ว่าจะไม่มีการเพิ่มขีดจำกัดแก๊สโหนดก็จะเพิ่มขนาดขึ้นเป็นร้อย GB ทุกปี

01928374656574839201

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

นี้มีการเลือกมากมายในการเก็บบันทึกประวัติของเรา วิธีที่เป็นธรรมชาติคือทุกโหนดจะเก็บข้อมูลบางส่วนของเครือข่าย นี่คือวิธีการทำงานของเครือข่ายเมล็ดพันธุ์ในหลายสิบปี: แม้ว่าเครือข่ายจะเก็บและแจกจ่ายไฟล์ล้านรายการ แต่แต่ละผู้ร่วมเก็บและแจกจ่ายเพียงไฟล์เพียงไม่กี่รายการ บางทีว่าความคิดอาจกลับกับความรู้สึก วิธีนี้อาจไม่จำเป็นต้องปล่อยความคงทนของข้อมูล ถ้าเราสามารถสร้างเครือข่ายที่มีโหนด 100,000 โหนด โดยที่แต่ละโหนดเก็บบันทึกประวัติสุ่ม 10% ดังนั้นข้อมูลแต่ละรายการจะถูกคัดลอก 10,000 ครั้ง - ซึ่งเท่าเทียมกับตัวคูณการคัดลอกของ 10,000 โหนด - โครงข่ายโหนด โดยที่แต่ละโหนดเก็บทุกเนื้อหา

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

Erasure codes สามารถใช้เพื่อเพิ่มความทนทานและรักษาความสัมพันธ์ของตัวก๊อปปี้ไว้เท่าเดิม ในความเป็นจริงแล้ว Blob ได้ทำการแก้ไขรหัสเพื่อสนับสนุนการตัวอย่างข้อมูล วิธีง่ายที่สุดคือการนำ Erasure codes นี้มาใช้ใหม่และนำข้อมูลบล็อกการดำเนินการและการอิงมาใส่ใน blob ด้วย

มีความเกี่ยวข้องกับงานวิจัยเดิมอย่างไร

EIP-4444; EIP-4444

Torrents และ EIP-4444;

เครือข่ายพอร์ทัล;

เครือข่ายพอร์ทัลและ EIP-4444；

การจัดเก็บและการค้นหาแบบกระจายของวัตถุ SSZ ในพอร์ทัล;

วิธีเพิ่มขีด จํากัด ก๊าซ (กระบวนทัศน์)

ยังต้องทำอะไร ต้องชั่งชีวิตอะไรอีก？

งานหลักที่เหลืออยู่รวมถึงการสร้างและรวมเข้ากันของ Solition กระจายที่แน่นอนเพื่อเก็บบันทึกของประวัติศาสตร์ - อย่างน้อยก็ประวัติการดำเนินการ แต่สุดท้ายก็รวมถึง ฉันทามติ และ blob ข้อแนะนำที่ง่ายที่สุดคือ (i) การนำเข้าโบราณคดีที่มีอยู่แล้ว และ (ii) การแก้ปัญหาแบบ Portal Network ซึ่งเป็น Solition ธรรมชาติของ ETH หนึ่งครั้งที่เราได้นำเสนอสิ่งใดสิ่งหนึ่งเราก็สามารถเปิด EIP-4444 ได้ เอกสาร EIP-4444 เองไม่จำเป็นต้อง Hard Fork แต่จริงๆแล้วมันต้องการรุ่นโปรโตคอลใหม่ด้วย ดังนั้นการเปิดใช้งานสำหรับลูกค้าทุกคนพร้อมกันนั้นมีค่าอย่างมาก มิฉะนั้นจะมีความเสี่ยงที่ลูกค้าจะล้มเหลวเนื่องจากติดต่อกับโหนดอื่นๆที่คาดหวังการดาวน์โหลดประวัติศาสตร์เต็มรูปแบบแต่จริงๆไม่ได้รับการรับรู้

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

วิธีการทำให้แน่ใจว่าชุดโหนดขนาดใหญ่สุดจริงๆเก็บข้อมูลทั้งหมด?

เรารวมการจัดเก็บทางประวัติศาสตร์เข้ากับโปรโตคอลลึกแค่ไหน?

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

สำหรับ (2) การปฏิบัติงานพื้นฐานเพียงแค่เกี่ยวข้องกับงานที่เสร็จสิ้นในวันนี้: Portal ได้เก็บข้อมูล ERA ที่ประกอบด้วยประวัติศาสตร์ Ethereum ทั้งหมด การปฏิบัติงานที่เป็นระเบียบเรียบร้อยจะเกี่ยวข้องกับการเชื่อมต่อจริงไปยังกระบวนการซิงโครไนซ์ ซึ่งจะทำให้ผู้ที่ต้องการซิงโครไนซ์โหนดเก็บข้อมูลทั้งหมดหรือโหนดเก็บข้อมูลเต็มรูปแบบ แม้ว่าไม่มีโหนดเก็บข้อมูลสำรองอื่นออนไลน์แล้วเขาก็สามารถทำได้ผ่านกระบวนการซิงโครไนซ์โดยตรงจากเครือข่ายพอร์ทัล

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

หากเราต้องการให้การเริ่มต้นหรือการเริ่มต้นโหนดเป็นเรื่องที่ง่ายมาก การลดความต้องการในการเก็บรักษาประวัติที่มีอยู่อาจสำคัญกว่าการไม่มีสถานะ: โดยที่โหนดต้องใช้ 1.1 TB ประมาณ 300 GB เป็นสถานะและส่วนที่เหลือประมาณ 800 GB เป็นประวัติ เพียงแค่ทำให้ไม่มีสถานะและ EIP-4444 สามารถทำให้เป็นจริงได้ ซึ่งจะทำให้เป็นไปได้ที่จะเปิดโหนด ETH บนนาฬิกาอัจฉริยะและสามารถตั้งค่าได้ในไม่กี่นาที

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

วันหมดอายุ

แก้ปัญหาอะไร

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

สถานะที่ยากกว่าประวัติศาสตร์ที่จะ 'หมดอายุ' เพราะ EVM ถูกออกแบบขึ้นมาในพื้นฐานที่ว่า: เมื่อสร้างวัตถุสถานะแล้วจะอยู่ตลอดเวลาและสามารถอ่านโดยธุรกรรมใด ๆ ได้เมื่อใดก็ได้ ถ้าเรานำเข้าความไม่มีสถานะ บางคนอาจคิดว่าปัญหานี้ไม่ได้แย่มาก: เฉพาะคลาสบล็อกสร้างเท่านั้นที่ต้องจัดเก็บสถานะจริง ๆ และโหนดอื่น ๆ (รวมถึงการสร้างรายการ!) สามารถเป็นได้โดยไม่มีสถานะ อย่างไรก็ตาม มีความเห็นว่าเราไม่ต้องการพึ่งพาความไม่มีสถานะมากเกินไป ในที่สุดเราอาจต้องการให้สถานะหมดอายุเพื่อรักษาการกระจายอำนาจของเอเทอร์

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

วันนี้เมื่อคุณสร้างออบเจกต์สถานะใหม่ (สามารถเกิดขึ้นได้ทางหนึ่งจาก (i) การส่ง ETH ไปยังบัญชีใหม่, (ii) การสร้างบัญชีใหม่โดยใช้โค้ด, (iii) การตั้งค่าช่องจัดเก็บที่ไม่เคยถูกสัมผัสมาก่อน) อ็อบเจกต์สถานะนั้นจะอยู่ในสถานะนั้นตลอดไป ตรงกันข้ามกับที่เราต้องการซึ่งคือ อ็อบเจกต์จะหมดอายุโดยอัตโนมัติตามเวลา ความท้าทายสำคัญคือการทำให้สามารถทำให้สิ่งที่เราต้องการได้โดยที่สถานะนั้นมีอยู่ 3 วิธี

ประสิทธิภาพ: ไม่จำเป็นต้องคำนวณเพิ่มเติมเพื่อดำเนินการกระบวนการหมดอายุ

ความเป็นมิตรของผู้ใช้: หากใครบางคนเข้าถ้ำเป็นเวลาห้าปีและกลับมา พวกเขาไม่ควรที่จะสูญเสียสิทธิในการเข้าถึง ETH、ERC20、โทเค็นที่ไม่สามารถทดแทนได้、CDP 头寸...

ความเป็นมิตรของนักพัฒนา: นักพัฒนาไม่จำเป็นต้องสลับไปยังโมเดลความคิดที่ไม่คุ้นเคยทั้งหมด นอกจากนี้ แอปพลิเคชันที่ตายและไม่ได้อัพเดทต่อไปน่าจะยังสามารถทำงานได้ตามปกติ

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

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

• บางส่วนของสถานะหมดอาย
• สถานะที่ขึ้นอยู่กับวันหมดอายุของที่อยู่แนะนำ

ส่วนหนึ่งของการหมดอายุของสถานะ

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

ความแตกต่างหลักระหว่างข้อเสนอเหล่านี้คือ: (i) วิธีการนิยาม "เร็วกว่า" และ (ii) วิธีการนิยาม "บล็อก"? หนึ่งในข้อเสนอที่เป็นทางเลือกคือ EIP-7736 ซึ่งได้รับการพัฒนาจากการออกแบบ "สายใบ" ที่ถูกนำเข้าสำหรับต้นไม้ Verkle (แม้ว่าจะเข้ากันได้กับสถานะที่ไม่มีสถานะใด ๆ อย่างไรก็ตาม เช่น ต้นไม้ทวิภาค) ในการออกแบบนี้ ส่วนหัว รหัส และช่องเก็บข้อมูลที่อยู่ติดกันจะถูกเก็บไว้ใน "สายกลาง" เดียวกัน ข้อมูลที่เก็บในสายกลางหนึ่ง สามารถเป็นได้สูงสุด 256 * 31 = 7,936 ไบต์ ในกรณีส่วนมาก ส่วนหัวของบัญชี รหัส และช่องเก็บข้อมูลหลายๆ คีย์จะถูกเก็บไว้ในสายกลางเดียวกัน หากข้อมูลในสายกลางที่กำหนดไว้ไม่ได้ถูกอ่านหรือเขียนภายในระยะเวลา 6 เดือน ข้อมูลดังกล่าวจะไม่ถูกเก็บไว้แล้ว แต่เพียงแค่เก็บคำสัญญา 32 ไบต์ของข้อมูลเท่านั้น ("ราก") ธุรกรรมที่เข้าถึงข้อมูลดังกล่าวในอนาคตจะต้องมีการ "ฟื้นคืน" ข้อมูลและให้พิสูจน์การตรวจสอบตามรากที่ให้มา

ยังมีวิธีอื่นๆ ที่สามารถทำให้เกิดความคิดที่คล้ายกันได้ เช่น หากระดับของบัญชีไม่เพียงพอ เราสามารถกำหนดแผนการที่แต่ละส่วนของต้นไม้ขนาด 1/232 จะถูกควบคุมด้วยกลไกใบไม้ที่คล้ายกัน

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

ข้อเสนอเมื่อสถานะของที่อยู่หมดอายุ

จะเกิดอะไรขึ้นถ้าเราต้องการหลีกเลี่ยงสถานะถาวรใด ๆ อย่างสมบูรณ์แม้แต่ต้นขั้ว 32 ไบต์? นี่เป็นปริศนาเนื่องจากความขัดแย้งในการฟื้นคืนชีพ: จะเกิดอะไรขึ้นถ้าวัตถุสถานะหนึ่งถูกลบและต่อมาการดําเนินการ EVM ทําให้วัตถุสถานะอื่นอยู่ในตําแหน่งเดียวกันแน่นอน แต่แล้วคนที่ห่วงใยวัตถุสถานะเดิมจะกลับมาและพยายามกู้คืน? เมื่อสถานะบางส่วนหมดอายุ "ต้นขั้ว" จะป้องกันการสร้างข้อมูลใหม่ เมื่อรัฐหมดอายุเต็มเราไม่สามารถเก็บต้นขั้วได้

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

หนึ่งในความคิดสำคัญที่ทำให้เป็นเพื่อนกันของผู้ใช้และนักพัฒนาคือแนวความคิดของรอบชิ้นส่วนของที่อยู่ รอบชิ้นส่วนของที่อยู่เป็นตัวเลขที่เป็นส่วนหนึ่งของที่อยู่ กฎหลักที่สำคัญคือที่อยู่ที่มีรอบชิ้นส่วน N สามารถอ่านหรือเขียนได้เมื่อถึงรอบชิ้นส่วน N หรือหลังจากนั้น (เช่นเมื่อรายการต้นไม้สถานะมีความยาว N) หากคุณต้องการบันทึกวัตถุสถานะใหม่ (เช่นสัญญาใหม่หรือยอดคงเหลือ ERC20 ใหม่) หากคุณยืนยันว่าวัตถุสถานะได้รับการนำเข้าสู่สัญญาที่มีรอบชิ้นส่วนเป็น N หรือ N-1 คุณสามารถบันทึกได้ทันทีโดยไม่ต้องให้หลักฐานใด ๆ ก่อนหน้านี้ อย่างไรก็ตามการเพิ่มหรือแก้ไขในช่วงที่อยู่เก่าต้องมีหลักฐาน

การออกแบบนี้เก็บไว้บางส่วนของคุณสมบัติปัจจุบันของอีเธอร์เรียมที่ไม่ต้องการการคำนวณเพิ่มเติม อนุญาตให้เขียนแอปพลิเคชันเกือบเหมือนเดิม (ต้องเขียนใหม่สำหรับ ERC20 เพื่อให้แน่ใจว่ายอดคงเหลือของที่อยู่ขนาด N จะถูกเก็บไว้ในสัญญาย่อยและมีที่อยู่ขนาด N อย่างต่อเนื่อง) และแก้ไขปัญหา 'ผู้ใช้เข้าเขตป่าเป็นเวลา 5 ปี' อย่างไรก็ตาม มันก็มีปัญหาใหญ่ ที่อยู่จำเป็นต้องขยายเพื่อให้มีขนาดมากกว่า 20 บิตในรอบการทำงาน

ที่อยู่ที่ต่อยอดพื้นที่

หนึ่งคำแนะนำคือการนำเข้ารูปแบบที่อยู่ 32 ไบต์ใหม่ที่รวมถึงหมายเลขรุ่น รหัสรอบที่อยู่และการแยกขยาย

0x01 (สีแดง) 0000 (สีส้ม) 000001 (สีเขียว) 57aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF (สีน้ำเงิน)。

สีแดงคือหมายเลขเวอร์ชัน สี่เลขศูนย์สีส้มที่นี่มีไว้เป็นพื้นที่ว่าง สำหรับหมายเลขการแบ่งส่วนในอนาคต สีเขียวคือหมายเลขรอบการทำงาน สีฟ้าคือค่าแฮชขนาด 26 ไบต์

ความท้าทายสำคัญที่นี่คือความเข้ากันได้ย้อนหลัง สัญญาที่มีอยู่ออกแบบเพื่อที่อยู่ 20 ไบต์ และมักใช้เทคโนโลยีการบีบอัดไบต์อย่างเข้มงวด โดยที่ทำให้ ที่อยู่ มีความยาว 20 ไบต์อย่างแน่นอน หนึ่งไอเดียในการแก้ปัญหานี้เกี่ยวข้องกับการแปลงการแมพ ทำให้สัญญาเก่าที่โต้ตอบกับ ที่อยู่ แบบใหม่จะเห็นค่าแฮชของ ที่อยู่ แบบใหม่ 20 ไบต์ อย่างไรก็ตาม การรักษาความปลอดภัยของมันเป็นเรื่องที่ซับซ้อนอย่างมาก

ที่อยู่ 01928374656574839201 การหดตัวของพื้นที่

วิธีอื่น ๆ คือการเลือกทิศทางที่ต่างกัน: เราจะห้ามบางช่วงที่อยู่ขนาด 2128 ทันที (เช่นที่อยู่ทั้งหมดที่เริ่มต้นด้วย 0xffffffff) แล้วใช้ช่วงนั้นเป็นที่อยู่สำหรับการแนะนำที่อยู่ที่มีระยะเวลาที่อยู่และค่าแฮช 14 ไบต์

0xffffffff000169125d5dFcb7B8C2659029395bdF

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

ในพื้นที่ความเสี่ยงสำคัญ กล่าวคือ สิ่งที่ไม่เป็นความจริงที่กระเป๋าที่เป็นเจ้าของเดียวกันไม่ได้อยู่ในสภาพที่แตกต่างกัน อย่างไรก็ดี เมื่อเราเข้าสู่โลก L2 หลายๆ อย่าง สิ่งนี้อาจกลายเป็นสิ่งที่พบบ่อยขึ้น มีแนวทางการแก้ไขเดียวคือรับความเสี่ยงนี้อย่างง่ายดาย แต่จำเป็นต้องระบุ Use case ที่เป็นที่พบบ่อยที่อาจเกิดปัญหาและนำเสนอวิธีการแก้ไขที่มีประสิทธิภาพ

มีความเกี่ยวข้องกับงานวิจัยเดิมอย่างไร

เสนอเรื่องในช่วงเริ่มต้น

• บล็อก chain cleaning;
• การทำใหม่;
• ทฤษฎีการจัดการขนาดสถานะของ Ethereum;
• บางเส้นทางที่เป็นไปได้ของสถานะไม่มีสถานะและหมดอายุของสถานะ；

ข้อเสนอเพื่อให้สถานะบางส่วนหมดอายุ

• EIP-7736;

ที่อยู่พื้นที่ขยายเอกสาร

• ข้อเสนอเดิม;
• ความคิดเห็นของ Ipsilon;
• ความคิดเห็นบทความบล็อก;
• หากเราสูญเสียความต้านทานการชนของเรา จะทำลายอะไร

ยังต้องทำอะไร ต้องชั่งชีวิตอะไรอีก？

ฉันคิดว่าอนาคตมีทางเลือกที่สามารถเลือกได้ 4 ชนิด:

• เราทำให้เป็นไปได้ที่ไม่มีสถานะ และไม่มีการนำเข้าสถานะที่หมดอายุ สถานะกำลังพุ่งขึ้นอย่างต่อเนื่อง (ถึงแม้จะช้า แต่เราอาจจะไม่เห็นมันมากกว่า 8 TB ในหลายปี) แต่มันเพียงจำเป็นเพียงสำหรับผู้ใช้ประเภทที่เฉพาะเจาะจง: แม้แต่ผู้ตรวจสอบ PoS ก็ไม่จำเป็นต้องมีสถานะ หนึ่งฟังก์ชันที่ต้องการเข้าถึงสถานะบางส่วนคือการสร้างรายการ แต่เราสามารถทำการดำเนินการนี้ได้โดยการกระจาย: แต่ละผู้ใช้มีหน้าที่ดูแลส่วนของต้นไม้สถานะที่มีบัญชีของตนเอง ขณะที่พวกเขากระจายธุรกรรม พวกเขาจะกระจายธุรกรรมพร้อมกับการพิสูจน์ว่าพวกเขาเข้าถึงวัตถุสถานะขณะที่ตรวจสอบ (สำหรับบัญชี EOA และ ERC-4337) จากนั้น ผู้ตรวจสอบที่ไม่มีสถานะสามารถรวมพวกพิสูจน์เหล่านี้เข้าด้วยกันเป็นพิสูจน์ทั้งหมดของรายการ
• เรากำลังจะตั้งค่าสถานะบางส่วนให้หมดอายุและยอมรับอัตราการเติบโตของขนาดสถานะถาวรที่ต่ำมาก แต่ไม่เท่ากับศูนย์ ผลลัพธ์นี้สามารถบอกได้ว่าคล้ายกับการยอมรับการเสนอที่หมดอายุของเครือข่ายพีอีระหว่างว่าทุก ๆ ลูกค้าจำเป็นต้องเก็บข้อมูลประวัติที่ต่ำกว่าแต่มีอัตราเปอร์เซ็นต์ที่คงที่ของข้อมูลประวัติที่ต่ำมาก แต่ไม่เท่ากับศูนย์
• เราจะขยายพื้นที่ของที่อยู่เพื่อให้สถานะเก่าล่วงเวลา นี่จะเป็นกระบวนการที่ใช้เวลาหลายปีเพื่อให้การแปลงรูปแบบของที่อยู่เป็นเรื่องที่มีประสิทธิภาพและปลอดภัย รวมถึงการใช้ในแอปพลิเคชันที่มีอยู่
• เราจะใช้การหดลดของที่อยู่เพื่อทำให้สถานะหมดอาย นี่จะเป็นกระบวนการที่ระยะยาวเพื่อให้มั่นใจว่ามีการจัดการความเสี่ยงที่เกี่ยวข้องกับที่อยู่ทั้งหมด (รวมถึงกรณีปฏิสัมพันธ์ข้ามเชน)

สิ่งสำคัญคือไม่ว่าจะมีแผนการใช้งานใดที่เกี่ยวข้องกับการเปลี่ยนแปลงรูปแบบที่อยู่หรือไม่ ในที่สุดจะต้องแก้ไขปัญหาเกี่ยวกับการขยายและหดของพื้นที่ที่อยู่ ในปัจจุบันการสร้างคอลลิชันที่อยู่ที่ขัดแย้งกันคือประมาณ 280 ค่าแฮชสำหรับผู้เข้าร่วมทรัพยากรที่มีมากมายการคำนวณเหล่านี้เป็นไปได้: GPU สามารถทำการคำนวณแฮชได้ประมาณ 227 ค่า ดังนั้นการเรียกใช้งานหนึ่งปีสามารถคำนวณได้ประมาณ 252 ค่า ดังนั้น GPU ทั้งหมดทั่วโลกประมาณ 230 ตัวสามารถคำนวณการชนทีละครั้งในเวลาประมาณ 1/4 ปี ส่วน FPGA และ ASIC สามารถเร่งกระบวนการนี้ได้อีก ในอนาคตการโจมตีประเภทนี้จะเปิดให้มีผู้เข้าถึงมากขึ้น ดังนั้นต้นทุนในการใช้งานสถานะสมบูรณ์เมื่อสิ้นสุดอายุอาจไม่สูงเท่าที่คิดเพราะไม่ว่าเราจะทำอย่างไรเราต้องแก้ไขปัญหาที่อยู่ที่ยากลำบากนี้

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

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

ทำความสะอาดคุณสมบัติ

มันแก้ปัญหาอะไร?

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

01928374656574839201

ไม่มีการแก้ไขเดียวที่สำคัญที่สามารถปล่อยโปรโตคอลที่ซับซ้อนได้； ปัญหานี้มีลักษณะที่มีหลายทางเลือกในการแก้ไข

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

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

การแปล RLP → SSZ: ตั้งแต่ต้นฉบับ วัตถุอาศัยการเข้ารหัสชื่อ RLP เพื่อการทำให้เป็นอนุกรม Ethereum ระบบนี้ไม่มีประเภทและซับซ้อนไร้จำเป็น SSZ ที่ใช้ใน Beacon Chain มีประสิทธิภาพมากขึ้นในหลายด้าน รวมถึงการรองรับการทำให้เป็นอนุกรมและการรองรับแฮช ในที่สุดเราหวังว่าจะก้าวออกจาก RLP และย้ายประเภทข้อมูลทั้งหมดไปยังโครงสร้าง SSZ ซึ่งจะทำให้การอัพเกรดง่ายขึ้น EIP ปัจจุบันรวมถึง[1][2]。

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

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

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

การทำให้เป็นอนุกรม

การลบคณะกรรมการ Beacon Chain: กลไกนี้เริ่มแรกถูกนำเข้ามาเพื่อรองรับการแบ่งส่วนของเวอร์ชันที่ระบุไว้ อย่างไรก็ตาม เราสุดท้ายใช้ L2 และ blob ในการแบ่งส่วน ดังนั้น คณะกรรมการเป็นไม่จำเป็นและกำลังดำเนินการลบคณะกรรมการ

ลบลำดับบิตเรียงผสม: EVM เป็นลำดับบิตเรียงขนาดใหญ่ และชั้นเสียงร่วมกันเป็นลำดับบิตเรียงขนาดเล็ก การปรับปรุงใหม่และการทำให้เป็นทั้งสองอย่างเป็นไปได้น่าสนใจ (อาจเป็นลำดับบิตเรียงขนาดใหญ่เนื่องจาก EVM เปลี่ยนแปลงได้ยากกว่า)

ตอนนี้ตัวอย่างบางอย่างใน EVM:

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

ลบการเตรียมความพร้อมก่อน: มีการเตรียมความพร้อมหลายรายการใน ETH ที่ซับซ้อนเกินไปและไม่จำเป็น มันไม่ได้ถูกใช้งานบ่อยและเป็นส่วนใหญ่ของฉันทามติที่เกิดขึ้นโดยไม่จำเป็น วิธีการแก้ไขปัญหานี้คือ (i) ลบการเตรียมความพร้อมเท่านั้น และ (ii) แทนที่ด้วยรหัส EVM ชุดหนึ่งที่มีต้นฉบับเดียวกัน (ที่แพงกว่า) ชั้นนำของ EIP นี้แนะนำให้ดำเนินการลบการเตรียมความพร้อมเอกสารที่เกี่ยวกับตัวตนก่อน ซึ่งในอนาคตของ RIPEMD160 MODEXP และ BLAKE อาจเป็นผู้สมัครที่ถูกลบออก

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

การปรับปรุงการวิเคราะห์แบบคงที่: ขณะนี้โค้ด EVM มีการวิเคราะห์แบบคงที่ที่ยากมาก โดยเฉพาะอย่างยิ่งเนื่องจากการกระโดดอาจเป็นไดนามิก สิ่งนี้ยังทำให้การปรับปรุง EVM implementation (การคอมไพล์โค้ด EVM เป็นภาษาอื่น) ยากขึ้น เราสามารถแก้ปัญหานี้ได้โดยการลบการกระโดดไดนามิกออก (หรือทำให้มันแพงขึ้น เช่น ต้นทุนแก๊สของ JUMPDEST ในสัญญาเป็นเส้นตรง) EOF ทำเช่นนี้ แม้จะต้องทำให้ EOF เป็นบังคับเพื่อให้ได้รับประโยชน์จากการลดโปรโตคอล

มีความเกี่ยวข้องกับงานวิจัยเดิมอย่างไร

• ขั้นตอนถัดไปของการล้างล้าง;
• ทำลายตัวเอง
• EIPS ที่ใช้ SSZ:[1][2]；
• ไม่มีการเปลี่ยนแปลงต้นทุนของแก๊ส;
• การกำหนดราคาเมมโมรี่เชิงเส้น;
• การลบที่ถูกคอมไพล์ล่วงหน้า;
• ตัวกรองของบลูมถูกลบออก;
• วิธีการเรียกบันทึกความปลอดภัยนอกเครือข่ายโดยใช้การคํานวณที่ตรวจสอบได้เพิ่มขึ้น (อ่าน: STARK ซ้ํา);

ยังต้องทำอะไร ต้องชั่งชีวิตอะไรอีก？

ประเด็นสำคัญในการหาความสมดุลของการกระทำที่สะดวกสบายนี้คือ (i) ระดับและความเร็วของการกระทำที่เราทำให้ง่ายขึ้นและ (ii) ความเข้ากันได้ย้อนหลัง ETH คือความคุ้มค่าของเครือข่ายในการเป็นแพลตฟอร์มที่คุณสามารถใช้ในการติดตั้งแอปพลิเคชันและมั่นใจได้ว่ามันยังสามารถทำงานได้หลังจากหลายปี ในเวลาเดียวกัน ความคาดหวังนี้อาจจะเป็นเรื่องที่ไกลเกินไปในคำพูดของ William Jennings Bryan ว่า 'ETH คือการติดครอสแบบย้อนหลัง' ถ้ามีแค่สองแอปพลิเคชันใน ETH ที่ใช้ฟังก์ชันที่กำหนดและมีแอปพลิเคชันหนึ่งที่ไม่มีผู้ใช้เลยในหลายปีและแอปพลิเคชันอีกอันหนึ่งที่ไม่เคยถูกใช้เกือบจะเลยไปโดยรวม 57 ดอลลาร์ จะต้องลบฟังก์ชันนั้นออกและจะต้องชดใช้เงิน 57 ดอลลาร์ให้กับผู้เสียหายถ้าจำเป็น

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

• เริ่มพูดเรื่องการลบฟีเจอร์ X;
• ทําการวิเคราะห์เพื่อกําหนดผลกระทบของการลบ X ในแอปพลิเคชันขึ้นอยู่กับผลลัพธ์: (i) ละทิ้งความคิด (ii) ดําเนินการต่อตามแผนที่วางไว้หรือ (iii) กําหนดวิธีการ "ก่อกวนน้อยที่สุด" ที่แก้ไขเพื่อลบ X และดําเนินการต่อ
• กำหนด EIP ที่เป็นทางการในการยกเลิก X ให้ระบบพื้นฐานระดับสูงที่ได้รับความนิยม (เช่นภาษาโปรแกรม กระเป๋า) เคารพสิ่งนี้และหยุดใช้ฟีเจอร์ดังกล่าว
• ในที่สุด X ถูกลบออกจริง ๆ ;
• ขั้นตอนที่ 1 และขั้นตอนที่ 4 ควรมีท่อที่ยาวนานหลายปีและระบุโครงการได้ชัดเจนว่าโครงการไหนอยู่ในขั้นตอนไหน ณ จุดนี้จำเป็นต้องพิจารณาความสมดุลระหว่างความกระตือรือร้นและความเร็วในกระบวนการลบคุณสมบัติกับการลงทุนที่สูงขึ้นและการลงทุนที่มีทรัพยากรมากกว่าในการพัฒนาโปรโตคอลอื่น ๆ แต่เรายังอยู่ห่างไกลจากขอบเขตของปาเรตโต้

EOF

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

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

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

คําแนะนํา "การปรับปรุง" จํานวนมากในแผนงานที่เหลือยังเป็นโอกาสในการลดความซับซ้อนของคุณลักษณะดั้งเดิม ทําซ้ําตัวอย่างข้างต้น:

• เมื่อเปลี่ยนไปใช้ความสมบูรณ์ของช่องเดียวเราจะมีโอกาสยกเลิกคณะกรรมการ ออกแบบใหม่เศรษฐศาสตร์และดำเนินการอื่น ๆ ที่เกี่ยวข้องกับการรับรอง
• การทำให้แนวคิดการสรุปบัญชีเป็นจริงอย่างสมบูรณ์สามารถช่วยให้เราลบตรรกะการดำเนินการการซื้อขายที่มีอยู่อย่างมาก และย้ายไปยัง "รหัส EVM บัญชีเริ่มต้น" ซึ่งสามารถแทนที่ได้ทุก EOA
• หากเราย้ายสถานะของอีเธอร์เรียมายังต้นไม้แบบไบนารีแฮช นี้สามารถจัดเรียงให้เข้ากันได้กับ SSZ เวอร์ชันใหม่ เพื่อให้สามารถประมวลผลแฮชโดยใช้วิธีเดียวกันกับโครงสร้างข้อมูลอีเธอร์เรียมทั้งหมดได้

วิธีที่หนึ่งที่เข้มข้นกว่า: แปลงเนื้อหาของโปรโตคอลเป็นรหัสสัญญา

ยังคงเป็นรูปแบบโปรโตคอล การย้ายฟังก์ชันใหญ่ๆ ของโปรโตคอลไปยังโค้ดสัญญา

เวอร์ชันสุดขั้วที่สุดคือการทำให้ ETH บล็อคเชน L1 เป็นเพียง Beacon Chain เท่านั้นและนำเข้าเครื่องจำลองขนาดเล็กที่สุด (เช่น RISC-V, Cairo หรือเครื่องจำลองที่เล็กที่สุดสำหรับระบบพิสูจน์) เพื่อให้ผู้อื่นสามารถสร้างสรรค์สร้างสรรค์ของตัวเองได้ จากนั้น EVM จะกลายเป็นครั้งแรกในสรุปของพวกเขา สิ่งที่น่าเสียดายก็คือ นั่นเป็นผลลัพธ์เดียวกันกับข้อเสนอแวดล้อมในปี 2019-20 ถึงแม้ว่า SNARK จะทำให้การนำไปใช้งานในความเป็นจริงง่ายขึ้น

แนวทางที่อ่อนโยนกว่าคือการรักษาความสัมพันธ์ระหว่าง Beacon Chain และสภาพแวดล้อมการดําเนินการ ETH Workshop ในปัจจุบันให้เหมือนเดิม, แต่สลับ EVM เข้าที่. เราสามารถเลือก RISC-V, Cairo หรือ VM อื่น ๆ เป็น "ETH Square VM อย่างเป็นทางการ" ใหม่จากนั้นบังคับให้สัญญา EVM ทั้งหมดเป็นรหัส VM ใหม่ที่ตีความตรรกะรหัสเดิม (ไม่ว่าจะโดยการรวบรวมหรือการตีความ) ในทางทฤษฎีสิ่งนี้สามารถทําได้ด้วย "Target เครื่องจําลอง" เป็นเวอร์ชันของ EOF