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

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

เพื่อให้ Ethereum รักษาตัวเองในระยะยาวเราต้องการแรงกดดันที่แข็งแกร่งต่อแนวโน้มทั้งสองนี้ลดความซับซ้อนและขยายตัวเมื่อเวลาผ่านไป แต่ในขณะเดียวกันเราจําเป็นต้องรักษาหนึ่งในคุณสมบัติหลักที่ทําให้บล็อกเชนยอดเยี่ยม: ความคงทนของพวกเขา คุณสามารถใส่ NFT, บันทึกความรักในการทําธุรกรรม calldata หรือสัญญาอัจฉริยะที่มีเงินล้าน onchain เข้าไปในถ้ําเป็นเวลาสิบปีออกมาและพบว่ามันยังคงรอคุณอ่านและโต้ตอบด้วย เพื่อให้ dapps รู้สึกสบายใจที่จะกระจายอํานาจอย่างเต็มที่และลบคีย์อัปเกรดพวกเขาต้องมั่นใจว่าการพึ่งพาของพวกเขาจะไม่อัปเกรดในลักษณะที่ทําลายพวกเขาโดยเฉพาะ L1 เอง

Luh Purge, 2023 roadmap.

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

Luh Purge: วัตถุประสงค์หลัก

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

ในบทนี้

• ประวัติศาสตร์การหมดอายุ
• วันหมดอายุสถานะ
• การทำความสะอาดคุณสมบัติ

ประวัติศาสตร์ที่หมดอายุ

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

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

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

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

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

วันนี้ Ethereum ได้เริ่มย้ายออกจากแบบจําลองของโหนดทั้งหมดที่จัดเก็บประวัติศาสตร์ทั้งหมดตลอดไป บล็อกฉันทามติ (เช่นส่วนที่เกี่ยวข้องกับการพิสูจน์ฉันทามติการถือหุ้น) จะถูกเก็บไว้เป็นเวลา ~ 6 เดือนเท่านั้น Blobs จะถูกเก็บไว้เป็นเวลา ~ 18 วันเท่านั้น EIP-4444มีเป้าหมายที่จะนำเสนอระยะเวลาการเก็บรักษาของบล็อกและใบเสร็จที่ย้อนหลังนาน 1 ปี ซึ่งเป็นเป้าหมายระยะยาวที่จะมีระยะเวลาที่เป็นไปตามกฏหมาย (ซึ่งอาจเป็น ~18 วัน) ในช่วงที่แต่ละโหนดรับผิดชอบในการเก็บรักษาทุกอย่างแล้วมีเครือข่ายแบบ peer-to-peer ที่ประกอบด้วยโหนด Ethereum ที่เก็บข้อมูลเก่าๆ ในรูปแบบการกระจายข้อมูล

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

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

• EIP-4444: https://eips.ethereum.org/EIPS/eip-4444
• Torrents และ EIP-4444: https://ethresear.ch/t/torrents-and-eip-4444/19788
• เครือข่ายพอร์ทัล: https://ethereum.org/en/developers/docs/networking-layer/portal-network/
• เครือข่ายประตูและ EIP-4444: https://github.com/ethereum/portal-network-specs/issues/308
• การจัดเก็บและเรียกคืนข้อมูลแบบกระจายของวัตถุ SSZ ในพอร์ทัล: https://ethresear.ch/t/distributed-storage-and-cryptographically-secured-retrieval-of-ssz-objects-for-portal-network/19575
• วิธีเพิ่มขีดจำกัดการใช้ก๊าซ (Paradigm):https://www.paradigm.xyz/2024/05/วิธีเพิ่มขีด จำกัด ก๊าซ-2

เหลืออะไรที่ต้องทำและต้องเสียสิทธิ์อะไรบ้าง?

งานที่เหลือหลักๆ เป็นการสร้างและผสานโซลูชันกระจ敏จระจักในการเก็บประวัติแบบแจจอแจการเจดแจการ-อย่างน้อยแล้วประวัติการดำเนินงาน แต่ในที่สุดยังรวมถึงข้อตกลงและ blog วิธีที่ง่ายที่สุดสำหรับนี้คือ (i) การเพียงแค่นำเข้าห้องสมุดทอร์เรนต์ที่มีอยู่แล้ว และ (ii) หรือโซลูชันของ Ethereum-native ที่เรียกว่าเครือข่าย Portal. เมื่อเปิดตัวอย่างใดอย่างหนึ่งแล้วเราสามารถเปิด EIP-4444 ได้ EIP-4444 นั้นไม่ต้องใช้ hard fork แม้ว่าจะต้องใช้โปรโตคอลเครือข่ายเวอร์ชันใหม่ ด้วยเหตุนี้จึงมีค่าในการเปิดใช้งานสําหรับลูกค้าทั้งหมดในเวลาเดียวกันเพราะมิฉะนั้นมีความเสี่ยงที่ลูกค้าจะทํางานผิดปกติจากการเชื่อมต่อกับโหนดอื่น ๆ ที่คาดว่าจะดาวน์โหลดประวัติทั้งหมด แต่ไม่ได้รับจริง

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

1. เราพยายามอย่างไรเพื่อให้แน่ใจว่าเซตของโหนดที่ใหญ่ที่สุดจริงๆเก็บข้อมูลทั้งหมด
2. เรารวมการจัดเก็บข้อมูลในอดีตเข้ากับโปรโตคอลอย่างลึกซึ้งเพียงใด

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

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

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

การลดข้อกําหนดในการจัดเก็บประวัติมีความสําคัญมากกว่าการไร้สัญชาติหากเราต้องการทําให้การเรียกใช้หรือหมุนโหนดเป็นเรื่องง่ายมาก: จาก 1.1 TB ที่โหนดจําเป็นต้องมี ~ 300 GB เป็นสถานะและส่วนที่เหลือ ~ 800 GB คือประวัติ วิสัยทัศน์ของโหนด Ethereum ที่ทํางานบนนาฬิกาอัจฉริยะและใช้เวลาเพียงไม่กี่นาทีในการตั้งค่าจะสามารถทําได้ก็ต่อเมื่อมีการใช้ทั้งการไร้สัญชาติและ EIP-4444

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

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

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

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

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

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

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

1. ประสิทธิภาพ: ไม่ต้องใช้การคำนวณเพิ่มเติมจำนวนมากเพื่อดำเนินการหมดอายุ
2. ความเข้าใจของผู้ใช้: หากมีคนเข้าไปในถ้ำเป็นเวลาห้าปีและกลับมา พวกเขาไม่ควรที่จะสูญเสียการเข้าถึง ETH, ERC20, NFT, ตำแหน่ง CDP ...
3. ความเป็นมิตรกับนักพัฒนา: นักพัฒนาไม่ควรต้องสลับไปใช้แนวคิดที่ไม่คุ้นเคยอย่างสมบูรณ์แบบ นอกจากนี้ แอปพลิเคชันที่เป็นซากโครงของวันนี้และไม่ได้อัพเดทควรทำงานได้อย่างมีเหตุผล

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

เป็นปัญหาที่ชุมชนการพัฒนา Ethereum คอร์สตรัคเกอร์ต่อสู้กับมาหลายปี รวมถึงข้อเสนอเช่นบล็อกเชนเช่า“ และ “regenesisในที่สุด เรารวมส่วนที่ดีที่สุดจากข้อเสนอและรวมกันเข้าไปที่สองหมวดหมู่ของ "known least bad solutions":

• Partial state-expiry solutions
• Address-period-based state expiry proposals.

การหมดอายุส่วนบาง

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

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

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

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

การ提议ให้สถานะของช่วงเวลาหมดอาย

หากเราต้องการหลีกเลี่ยงการเติบโตของสถานะถาวรทั้งหมด แม้แต่กระเป๋าสั้น 32 ไบต์ จะเป็นปัญหาที่ยาก เนื่องจาก@vbuterin/state_size_management#Resurrection-conflicts">resurrection conflicts: จะเกิดอะไรขึ้นถ้าวัตถุของรัฐถูกลบออกการดําเนินการ EVM ในภายหลังทําให้วัตถุของรัฐอื่นอยู่ในตําแหน่งเดียวกัน แต่หลังจากนั้นคนที่ใส่ใจเกี่ยวกับวัตถุสถานะเดิมจะกลับมาและพยายามกู้คืน? เมื่อสถานะบางส่วนหมดอายุ "ต้นขั้ว" จะป้องกันไม่ให้มีการสร้างข้อมูลใหม่ เมื่อหมดอายุเต็มสถานะเราไม่สามารถจัดเก็บแม้แต่ต้นขั้วได้

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

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

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

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

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

0x01000000000157aE408398dF7E5f4552091A69125d5dFcb7B8C2659029395bdF

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

ความท้าทายสำคัญที่นี่คือความเข้ากันได้ย้อนหลัง สัญญาที่มีอยู่ออกแบบโดยใช้ที่อยู่ 20 ไบต์และบ่อยครั้งใช้เทคนิค byte-packing ที่สุดแน่นอนซึ่งเหลือเฉพาะที่อยู่ขนาด 20 ไบต์เท่านั้น@ipsilon/address-space-extension-exploration">หนึ่งไอเดียในการแก้ปัญหานี้เกี่ยวข้องกับแผนที่การแปลภาษาซึ่งสัญญาแบบเก่าที่ปฏิสัมพันธ์กับที่อยู่แบบใหม่จะเห็นแฮช 20 ไบต์ของที่อยู่แบบใหม่ อย่างไรก็ตามการทำให้มันปลอดภัยนี้มีความซับซ้อนที่สำคัญ

การหดพื้นที่ที่อยู่

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

0xfffffff000169125d5dFcb7B8C2659029395bdF

ความเสียสละที่วิธีการนี้ทำได้คือเพิ่มความเสี่ยงด้านความปลอดภัยสําหรับที่อยู่ที่ขัดแย้งกัน: ที่อยู่ที่ถือสินทรัพย์หรือสิทธิ แต่โค้ดของมันยังไม่ได้เผยแพร่ไปยังเครือข่าย ความเสี่ยงเกี่ยวกับการมีคนสร้างที่อยู่ซึ่งอ้างว่ามีโค้ดชิ้นหนึ่ง (ที่ยังไม่ได้เผยแพร่) แต่ยังมีโค้ดอีกชิ้นที่ถูกต้องซึ่งมีการแฮชไปยังที่อยู่เดียวกัน การคำนวณให้เกิดการชนกันแบบนั้นต้องใช้ 2⁸⁰ hashes วันนี้; การกระทำพื้นที่ที่อยู่จะลดจำนวนนี้ลงเหลือเพียง 2 ที่สามารถเข้าถึงได้ง่ายมาก⁵⁶ hashes.

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

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

• ข้อเสนอแรกเริ่ม
  • ค่าเช่า Blockchain: https://github.com/ethereum/EIPs/issues/35
  • Regenesis: https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of-large-blockchain-and-state/7582
• ทฤษฎีการบริหารจัดการขนาดสถานะของ Ethereum: @vbuterin/state_size_management"">https://hackmd.io/@vbuterin/state_size_management
• เส้นทางบางเส้นทางที่เป็นไปได้สู่สถานะที่ไม่มีสถานะและการหมดอายุของสถานะ: @vbuterin/state_expiry_paths"">https://hackmd.io/@vbuterin/state_expiry_paths
• ข้อเสนอให้สภาวะบางส่วนหมดอาย
  • EIP-7736: https://eips.ethereum.org/EIPS/eip-7736
• เอกสารส่วนขยายพื้นที่ที่อยู่
  • Original proposal: https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485
  • รีวิว Ipsilon: @ipsilon/address-space-extension-exploration"">https://notes.ethereum.org/@ipsilon/address-space-extension-exploration
  • บทวิจารณ์บล็อกโพสต์:@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6"">https://medium.com/@chaisomsri96/statelessness-series-part2-ase-address-space-extension-60626544b8e6
• ถ้าเราสูญเสียความทนทานต่อการชนกัน สิ่งที่จะเสียหายคืออะไรhttps://ethresear.ch/t/what-would-break-if-we-lose-address-collision-resistance/11356

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

ฉันเห็นทางเลือกสี่ทางที่เป็นไปได้สำหรับอนาคต:

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

หนึ่งจุดสำคัญคือปัญหาที่ยากลำบากเกี่ยวกับการขยายพื้นที่ที่อยู่และการหดของพื้นที่ที่อยู่จะต้องได้รับการพิจารณาในที่สุดไม่ว่าจะมีการใช้แผนการหมดอายุของสถานะที่ขึ้นอยู่กับการเปลี่ยนแปลงรูปแบบของที่อยู่หรือไม่ ในปัจจุบันใช้เวลาประมาณ 2⁸⁰การแปลงค่าแฮชเพื่อสร้างการชนที่อยู่ ซึ่งเป็นภาระการคำนวณที่เป็นไปได้อยู่แล้วสำหรับผู้กระทำทรัพยากรที่ดีมาก: GPU สามารถทำได้ประมาณ 2²⁷ hashes, so running for a year it can compute 2⁵², ดังนั้นทั้งหมด~2^30 GPUs ในโลก สามารถคํานวณการชนกันใน ~ 1/4 ของปีและ FPGA และ ASIC สามารถเร่งสิ่งนี้ต่อไปได้ ในอนาคตการโจมตีดังกล่าวจะเปิดกว้างสําหรับผู้คนมากขึ้นเรื่อย ๆ ดังนั้นค่าใช้จ่ายที่แท้จริงในการดําเนินการหมดอายุของรัฐเต็มรูปแบบอาจไม่สูงอย่างที่คิดเนื่องจากเราต้องแก้ปัญหาที่อยู่ที่ท้าทายมากนี้โดยไม่คํานึงถึง

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

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

การล้างข้อมูลคุณสมบัติ

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

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

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

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

ตัวอย่างหนึ่งที่เสร็จสมบูรณ์แล้วและสามารถใช้เป็นแบบแผนการดำเนินงานสำหรับวิธีการจัดการกับอื่น ๆ ได้แก่@vbuterin/selfdestruct">removal ของ SELFDESTRUCT opcode SELFDESTRUCT opcode เป็น opcode เดียวที่สามารถปรับเปลี่ยนช่องเก็บข้อมูลได้ไม่ จํากัด จํานวนภายในบล็อกเดียวทําให้ไคลเอนต์ต้องใช้ความซับซ้อนมากขึ้นอย่างมากเพื่อหลีกเลี่ยงการโจมตี DoS จุดประสงค์เดิมของ opcode คือเพื่อให้สามารถล้างสถานะโดยสมัครใจทําให้ขนาดของรัฐลดลงเมื่อเวลาผ่านไป ในทางปฏิบัติมีน้อยมากที่ลงเอยด้วยการใช้มัน การ opcode ถูกปรับลด เพื่ออนุญาตเฉพาะบัญชีที่ทําลายตัวเองที่สร้างขึ้นในธุรกรรมเดียวกันใน Dencun hardfork วิธีนี้ช่วยแก้ปัญหา DoS และช่วยให้โค้ดไคลเอ็นต์ง่ายขึ้นอย่างมาก ในอนาคตมันน่าจะสมเหตุสมผลที่จะลบ opcode อย่างสมบูรณ์ในที่สุด

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

• การเปลี่ยนจาก RLP เป็น SSZ: ต้นฉบับ Ethereum ถูกซีเรียไลซ์โดยใช้การเข้ารหัสที่เรียกว่าRLP. RLP เป็นประเภทที่ไม่มีประเภท และซับซ้อนอย่างไม่จำเป็น ในปัจจุบัน beacon chain ใช้SSZ, ซึ่งดีขึ้นอย่างมีนัยสำคัญในหลายด้าน รวมถึงการสนับสนุนไม่เพียงแค่การอัตราการเซียรีลิเซชัน แต่ยังรวมถึงการแฮชชิ่งด้วย ในที่สุดเราต้องการจะกำจัด RLP โดยสิ้นเชิง และย้ายประเภทข้อมูลทั้งหมดเข้าไปเป็น SSZ structs ซึ่งในเวลาเดียวกันจะทำให้การอัพเกรดง่ายขึ้นมากขึ้น EIPs ปัจจุบันสำหรับสิ่งนี้รวมถึง [1] [2][3].
• การลบประเภทธุรกรรมเก่า: วันนี้มีประเภทธุรกรรมมากมายมากเกินไป บางส่วนอาจถูกนำออกได้ ทางเลือกที่เป็นมิตรกว่าที่สุดสำหรับการนำออกโดยสมบูรณ์คือคุณลักษณะการนำบัญชีที่อาจจะรวมรหัสเพื่อประมวลผลและยืนยันธุรกรรมรูปแบบเก่าหากพวกเขาต้องการ
• การปฏิรูป LOG: บันทึกสร้างตัวกรองบานและตรรกะอื่น ๆ ที่เพิ่มความซับซ้อนให้กับโปรโตคอล แต่ลูกค้าไม่ได้ใช้จริงเพราะมันช้าเกินไป เราทําได้ ลบคุณลักษณะเหล่านี้และใช้ความพยายามแทนทางเลือกอื่น เช่น เครื่องมืออ่านบันทึกแบบกระจายอํานาจนอกโปรโตคอลที่ใช้เทคโนโลยีสมัยใหม่ เช่น SNARKs
• การลบกลไกคณะกรรมการซิงค์ชุดไบอีมที่ไม่ถูกกำหนดให้เกิดขึ้นในอนาคต: กลไกคณะกรรมการซิงค์ถูกแนะนำเพื่อเป็นการยืนยันตัวระบบไลท์ของ Ethereum อย่างไรก็ตาม มันเพิ่มความซับซ้อนให้กับโปรโตคอล ในที่สุดเราจะสามารถตรวจสอบชั้นความเห็นของ Ethereum โดยตรงโดยใช้ SNARKs, ซึ่งจะลดความจำเป็นในการมีโปรโตคอลการยืนยันไคลเอนต์แสงที่มีการเปลี่ยนแปลงที่อาจทำให้เราสามารถลบคณะกรรมการซิงค์ได้แม้แรกยิ่งโดยการสร้างโปรโตคอลไคลเอนต์แสงที่“เกิดธรรมชาติ”มากขึ้นซึ่งเกี่ยวข้องกับการยืนยันลายเซ็นจากชุดย่อยสุ่มของผู้ตรวจสอบความเห็นของ Ethereum
• การปรับให้รูปแบบข้อมูลสอดคล้อง: ในปัจจุบันการดำเนินการถูกเก็บไว้ในต้นไม้ Merkle Patricia สถานะการตกลงถูกเก็บไว้ใน ต้นไม้ SSZ, และ blobs ถูกส่งมอบไปพร้อมกับ @vbuterin/proto_danksharding_faq#ข้อมูลแบบ blob มีรูปแบบอย่างไร และมันถูกยอมรับไว้อย่างไร">KZG commitments ในอนาคต มันมีความหมายที่จะทำให้มีรูปแบบเดียวสำหรับข้อมูลบล็อกและรูปแบบเดียวสำหรับสถานะ รูปแบบเหล่านี้จะครอบคลุมความต้องการที่สำคัญทั้งหมด: (i) พิสูจน์ง่ายสำหรับลูกค้าที่ไม่มีสถานะ, (ii) การอัตราการเกิดซีเรียลและการเข้ารหัสข้อมูล, (iii) โครงสร้างข้อมูลมาตรฐาน
• การลบคณะกรรมการ beacon chain: กลไกนี้เดิมที่ถูกนำเสนอขึ้นเพื่อสนับสนุน เวอร์ชันที่เฉพาะเจาะจงของการประมวลผลแต่เราจบการทำงานโดยการทำ Sharding แทนผ่าน L2s และ blobs. ดังนั้น คณะกรรมาธิการไม่จำเป็น และดังนั้นจึงมี การเคลื่อนไหวที่กำลังดำเนินไปสู่การเอาออก.
• การลบ endianness ที่ผสมผสานกัน: EVM มี big-endian และเลเยอร์ความเห็นมี little-endian การทำให้ทุกอย่างเป็นหนึ่งหรืออีกอย่างหนึ่ง (น่าจะเป็น big-endian เพราะ EVM ยากต่อการเปลี่ยนแปลง) อาจจะเป็นไปได้

ตอนนี้มีตัวอย่างบางอย่างที่อยู่ภายใน EVM:

• การบูรณาการกลไกแก๊ส: กฎระเบียบแก๊สปัจจุบันยังไม่ได้ถูกปรับเพื่อให้เห็นชัดเจนว่าจำนวนทรัพยากรที่ต้องใช้ในการตรวจสอบบล็อกมีจำกัดเท่าไหร่ ตัวอย่างสำคัญรวมถึง (i) ค่าใช้จ่ายในการอ่าน/เขียนข้อมูลเชิงพื้นที่ที่จะถูกจำกัดในการอ่าน/เขียนในบล็อก แต่ก็ยังไม่เป็นระเบียบกฏเสียค่อนข้างมาก และ (ii) กฏการเติมความจำที่ยังเป็นการประเมินค่าความจำสูงสุดของ EVM อยู่ในระยะที่ยากจะประเมินได้ในปัจจุบัน วิธีการแก้ไขที่เสนออยู่ได้แก่ การเปลี่ยนแปลงค่าแก๊สของการไม่มีสถานะ, ซึ่งทำให้ค่าใช้จ่ายที่เกี่ยวข้องกับการเก็บรักษาทั้งหมดเข้าไปอยู่ในสูตรที่เรียบง่าย และ ข้อเสนอนี้สำหรับการกำหนดราคาหน่วยความจำ.
• การกําจัด precompiles: precompiles จํานวนมากที่ Ethereum มีในปัจจุบันมีทั้งความซับซ้อนที่ไม่จําเป็นและค่อนข้างไม่ได้ใช้และประกอบขึ้นเป็นเปอร์เซ็นต์ขนาดใหญ่ของความล้มเหลวฉันทามติที่ใกล้จะพลาดในขณะที่ไม่ได้ใช้งานจริงโดยแอปพลิเคชันใด ๆ สองวิธีในการจัดการกับสิ่งนี้คือ (i) เพียงแค่ลบ precompile และ (ii) แทนที่ด้วยรหัส EVM (แพงกว่าอย่างหลีกเลี่ยงไม่ได้) ที่ใช้ตรรกะเดียวกัน แบบร่างนี้เสนอ EIPทำเช่นนี้สำหรับ identity precompile เป็นขั้นตอนแรก ภายหลัง RIPEMD160, MODEXP และ BLAKE อาจเป็นตัวเลือกสำหรับการลบออก
• การลบการตรวจสอบแก๊ส: ทำให้การดำเนินการ EVM ไม่สามารถเห็นได้ว่ามีแก๊สเหลืออยู่เท่าไรอีกต่อไป นี่จะทำให้แอปพลิเคชันบางตัวเสียหาย (โดยเฉพาะสำหรับการทำธุรกรรมที่ได้รับสนับสนุน) แต่จะทำให้การอัปเกรดในอนาคตง่ายมากขึ้น (เช่นสำหรับเวอร์ชันที่สูงกว่า)แก๊สมิติมิชัน). การ สเปคของ EOFการทำให้แก๊สไม่สามารถสังเกตเห็นได้แล้ว แม้ว่าจะเป็นไปได้ที่จะมีประโยชน์สำหรับการทำให้โปรโตคอลง่ายลด
• การปรับปรุงการวิเคราะห์แบบสถิต: วันนี้รหัส EVM ยากต่อการวิเคราะห์แบบสถิตโดยเฉพาะอย่างยิ่งเนื่องจากการกระโดดอาจมีความเปลี่ยนแปลงได้ สิ่งนี้ยังทำให้มันยากขึ้นในการทำให้การปรับปรุง EVM ที่ตั้งไว้ล่วงหน้าเป็นไปได้โดยการแปลงรหัส EVM เป็นภาษาอื่น ๆ พวกเราสามารถแก้ไขสิ่งนี้ได้โดยเฉพาะการลบการกระโดดแบบไดนามิก (หรือทำให้มันแพงขึ้นมากขึ้น เช่น ค่าก๊าสเป็นเส้นตรงในจำนวน JUMPDEST ทั้งหมดในสัญญา) ไฟล์สิ้นสุดโปรโตคอลนี้ แม้ว่าการทำให้โปรโตคอลง่ายลงจะต้องการให้ไฟล์สิ้นสุดโปรโตคอลเป็นบังคับ

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

• ขั้นตอนถัดไปในการปฏิบัติการล้างhttps://notes.ethereum.org/I_AIhySJTTCYau_adoy2TA
• SELFDESTRUCT: @vbuterin/selfdestruct"">https://hackmd.io/@vbuterin/selfdestruct
• SSZ-ification EIPS: [1] [2] [3]
• การเปลี่ยนแปลงค่าใช้จ่ายในการใช้ก๊าซที่ไม่มีสถานะ: https://eips.ethereum.org/EIPS/eip-4762
• การกำหนดราคาหน่วยความจำเชิงเส้น: https://notes.ethereum.org/ljPtSqBgR2KNssu0YuRwXw
• การลบพรีคอมไพล์: https://notes.ethereum.org/IWtX22YMQde1K_fZ9psxIg
• การลบกรองบลูม: https://eips.ethereum.org/EIPS/eip-7668
• วิธีการดึงข้อมูลบันทึกที่ปลอดภัยนอกโซนโดยใช้การคำนวณที่สามารถยืนยันได้เพิ่มขึ้น (อ่าน: recursive STARKs):https://notes.ethereum.org/XZuqy8ZnT3KeG1PkZpeFXw

เหลืออะไรที่ต้องทำ และความละเอียดของการเทรดคืออะไร

ข้อเสียเปรียบหลักในการทําการลดความซับซ้อนของคุณลักษณะนี้คือ (i) เราลดความซับซ้อนลงมากแค่ไหนและความเข้ากันได้ย้อนหลังได้เร็วแค่ไหนเมื่อเทียบกับ (ii) คุณค่าของ Ethereum ในฐานะห่วงโซ่มาจากการเป็นแพลตฟอร์มที่คุณสามารถปรับใช้แอปพลิเคชันและมั่นใจได้ว่าจะยังคงใช้งานได้หลายปีนับจากนี้ ในขณะเดียวกันก็เป็นไปได้ที่จะนําอุดมคตินั้นไปไกลเกินไปและ เพื่อจะพูดให้เข้าใจง่ายขึ้น วิลเลียม เจนนิงส์ ไบรอัน“ล้มล้าง Ethereum บนครูซิฟายเออร์เรียบร้อย” หากมีแอปพลิเคชันเพียงสองตัวใน Ethereum ที่ใช้คุณสมบัติที่กำหนด โดยที่หนึ่งไม่มีผู้ใช้เลยมาหลายปีและอีกตัวก็ใช้งานน้อยมากและรักษามูลค่ารวม $57 เท่านั้น แล้วเราควรเพียงนำคุณสมบัติออก เมื่อมีความจำเป็น จะจ่ายค่าเสียหายให้เหยื่อ $57 จากกระเป๋าเราเอง

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

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

ควรมีท่อระบายนานหลายปีระหว่างขั้นตอนที่ 1 และขั้นตอนที่ 4 พร้อมข้อมูลชัดเจนเกี่ยวกับสิ่งที่อยู่ที่ขั้นไหน ณ จุดนั้น จะมีการแลกเปลี่ยนระหว่างความกระตือรือร้นและเร็วกับท่อระบายคุณลักษณะ โดยการมีการระบายท่อการเอาคุณลักษณะออก มีข้อจำกัด มากกว่าการระวังและใช้ทรัพยากรมากขึ้นในด้านอื่นของการพัฒนาโปรโตคอล แต่เรายังคงอยู่ห่างไกลจาก Pareto frontier

EOF

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

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

มันมีปฏิสัมพันธ์กับส่วนอื่น ๆ ของแผนการดำเนินงานอย่างไร?

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

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

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

วิธีการบูรณาการ Ethereum ที่เป็นรูปแบบที่เข้มงวดกว่าคือการเก็บโปรโตคอลเดิมไว้อยู่แต่ย้ายส่วนใหญ่ของมันจากฟีเจอร์โปรโตคอลเป็นรหัสสัญญากลับ

รุ่นที่สุด โดยการทำให้ Ethereum L1 “เทคนิค” เป็นแค่ beacon chain และนำเข้า VM ที่เรียบง่ายที่สุด (เช่นRISC-V, ไคโร, หรือบางสิ่งที่เฉพาะเจาะจงมากกว่าอีกสำหรับการพิสูจน์ระบบ) ซึ่งอนุญาตให้ผู้ใดก็สามารถสร้าง rollup ของตนเองได้ จากนั้น EVM ก็จะกลายเป็น rollup แรกของสิ่งเหล่านี้ นี่ก็คือผลลัพธ์ที่เป็นเรื่องตลกที่เหมือนกันกับสิ่งที่ข้อเสนอสภาพแวดล้อมการดำเนินการ ตั้งแต่ปี 2019-20แม้ว่า SNARKs จะทำให้เป็นไปได้มากขึ้นในการดำเนินการจริงๆ

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

Disclaimer：

1. บทความนี้ถูกพิมพ์ซ้ำจาก [ วิตาลิค บุเทริน] ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [Vitalik Buterin]. หากมีข้อความใดๆ ที่ไม่เหมาะสมกับการพิมพ์ฉีดหมด โปรดติดต่อเกตเรียนทีม และพวกเขาจะจัดการกับมันโดยรวดเร็ว
2. คำประกาศเกี่ยวกับความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้นและไม่เป็นที่ปรึกษาการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่น ๆ นำมาทำโดยทีม Sanv Nurlae หากไม่ได้กล่าวถึง การคัดลอก การแจกจ่าย หรือการลอกเลียนบทความที่ถูกแปล ถือเป็นการละเมิด