ชื่อเดิม: อนาคตที่เป็นไปได้ของโปรโตคอล Ethereum ตอนที่ 5: The Purge
ผู้เขียนต้นฉบับ: Vitalik Buterin
เรียบเรียงต้นฉบับ: สามีรายวันของ Odaily Planet เป็นยังไงบ้าง?
ตั้งแต่วันที่ 14 ตุลาคม Vitalik Buterin ผู้ก่อตั้ง Ethereum ได้เผยแพร่การอภิปรายเกี่ยวกับอนาคตที่เป็นไปได้ของ Ethereum อย่างต่อเนื่อง ตั้งแต่ The Merge , The Surge , The Scourge , The Verge ไปจนถึงการเปิดตัวล่าสุดของ The Purge วิสัยทัศน์ของ Vitalik สำหรับการพัฒนาเครือข่ายหลัก Ethereum ในอนาคต และวิธีแก้ปัญหาที่กำลังเผชิญอยู่ในปัจจุบัน
การผสาน: กล่าวถึงความจำเป็นของ Ethereum ในการปรับปรุงขั้นสุดท้ายของสล็อตเดี่ยว และลดเกณฑ์การเดิมพันหลังจากย้ายไปยัง PoS เพื่อเพิ่มความเร็วในการเข้าร่วมและการยืนยันธุรกรรม
The Surge: สำรวจกลยุทธ์ต่างๆ สำหรับการขยาย Ethereum โดยเฉพาะอย่างยิ่งแผนงานแบบ Rollup-centric และความท้าทายและโซลูชันในด้านความสามารถในการปรับขนาด การกระจายอำนาจ และความปลอดภัย
The Scourge: พูดคุยถึงความเสี่ยงของการรวมศูนย์และการดึงคุณค่าที่ Ethereum เผชิญในการเปลี่ยนแปลงเป็น PoS และพัฒนากลไกต่างๆ เพื่อเพิ่มการกระจายอำนาจและความเป็นธรรม ขณะเดียวกันก็ดำเนินการปฏิรูปเศรษฐกิจเชิงเดิมพันเพื่อปกป้องผลประโยชน์ของผู้ใช้
The Verge: พูดคุยถึงความท้าทายและแนวทางแก้ไขของการตรวจสอบไร้สถานะของ Ethereum โดยเน้นไปที่วิธีที่เทคโนโลยี เช่น Verkle tree และ STARK สามารถปรับปรุงการกระจายอำนาจและประสิทธิภาพของบล็อกเชนได้อย่างไร
เมื่อวันที่ 26 ตุลาคม Vitalik Buterin ตีพิมพ์บทความเรื่อง The Purge บทความนี้ได้กล่าวถึงความท้าทายที่ Ethereum เผชิญคือการลดความซับซ้อนและความต้องการในการจัดเก็บข้อมูลในระยะยาว ในขณะเดียวกันก็รักษาความทนทานและการกระจายอำนาจของห่วงโซ่มาตรการหลัก ได้แก่ การลดพื้นที่จัดเก็บข้อมูลของลูกค้า ภาระผ่าน การหมดอายุของประวัติ และ การหมดอายุสถานะ และลดความซับซ้อนของโปรโตคอลผ่าน การล้างคุณสมบัติ เพื่อให้มั่นใจถึงความยั่งยืนและความสามารถในการปรับขนาดของเครือข่าย
ต่อไปนี้เป็นเนื้อหาต้นฉบับ เรียบเรียงโดย Odaily Planet Daily
ขอขอบคุณเป็นพิเศษสำหรับ Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden และ Tomasz Stanczak สำหรับคำติชมและบทวิจารณ์
หนึ่งในความท้าทายที่ Ethereum เผชิญอยู่ก็คือ ตามค่าเริ่มต้น ความขยายตัวและความซับซ้อนของโปรโตคอลบล็อกเชนใดๆ จะเพิ่มขึ้นเมื่อเวลาผ่านไป สิ่งนี้เกิดขึ้นในสองแห่ง:
ข้อมูลในอดีต: ธุรกรรมใด ๆ ที่ทำขึ้นและบัญชีใด ๆ ที่สร้างขึ้น ณ จุดใด ๆ ในประวัติศาสตร์จะต้องได้รับการจัดเก็บอย่างถาวรโดยไคลเอนต์ทั้งหมดและดาวน์โหลดโดยไคลเอนต์ใหม่ ดังนั้นจะถูกซิงโครไนซ์กับเครือข่ายโดยสมบูรณ์ ซึ่งทำให้เวลาในการโหลดและการซิงโครไนซ์ของไคลเอ็นต์เพิ่มขึ้นเมื่อเวลาผ่านไป แม้ว่าความจุของเชนจะยังคงเท่าเดิมก็ตาม
คุณสมบัติโปรโตคอล: การเพิ่มคุณสมบัติใหม่ทำได้ง่ายกว่าการลบคุณสมบัติเก่าออก ส่งผลให้ความซับซ้อนของโค้ดเพิ่มขึ้นเมื่อเวลาผ่านไป
เพื่อให้ Ethereum สามารถคงอยู่ได้ในระยะยาว เราต้องการแรงกดดันที่แข็งแกร่งต่อทั้งสองแนวโน้ม ลดความซับซ้อนและการขยายตัวเมื่อเวลาผ่านไป แต่ในขณะเดียวกัน เราจำเป็นต้องรักษาคุณลักษณะสำคัญประการหนึ่งที่ทำให้บล็อกเชนมีความยอดเยี่ยม นั่นก็คือ ความพากเพียร คุณสามารถใส่ NFT, จดหมายรักในข้อมูลการทำธุรกรรม หรือสัญญาอัจฉริยะที่มีมูลค่า 1 ล้านดอลลาร์ในเครือข่าย เข้าไปในถ้ำเป็นเวลาสิบปี และพบว่ามันยังคงรอให้คุณอ่านและโต้ตอบกับมัน . เพื่อให้ DApps รู้สึกสบายใจที่ได้รับการกระจายอำนาจอย่างสมบูรณ์และลบคีย์การอัปเกรด พวกเขาต้องมั่นใจว่าการพึ่งพาของพวกเขาจะไม่อัปเกรดในลักษณะที่ทำลายพวกเขา - โดยเฉพาะ L1 เอง
หากเรามุ่งมั่นที่จะสร้างสมดุลระหว่างความต้องการทั้งสองนี้และรักษาความต่อเนื่องในขณะที่ลดหรือย้อนกลับการขยายตัว ความซับซ้อน และการลดลง ก็เป็นไปได้อย่างแน่นอน สิ่งมีชีวิตสามารถทำเช่นนี้ได้: แม้ว่าสิ่งมีชีวิตส่วนใหญ่จะมีอายุมากขึ้นเมื่อเวลาผ่านไป แต่ โชคดีเพียงไม่กี่ชนิดที่ไม่ทำ แม้แต่ระบบสังคมก็สามารถ มีชีวิตที่ยืนยาวได้ ในบางกรณี Ethereum ประสบความสำเร็จ: การพิสูจน์การทำงานหายไป opcode ของ SELFDESTRUCT ส่วนใหญ่หายไป และโหนดลูกโซ่บีคอนได้จัดเก็บข้อมูลเก่ามูลค่าสูงสุดหกเดือน การค้นหาเส้นทางนี้สำหรับ Ethereum ในลักษณะทั่วไปมากขึ้น และไปสู่ผลลัพธ์สุดท้ายของความเสถียรในระยะยาว ถือเป็นความท้าทายขั้นสูงสุดสำหรับความสามารถในการปรับขนาดในระยะยาว ความยั่งยืนทางเทคนิค และแม้กระทั่งความปลอดภัย
The Purge: เป้าหมายหลัก
ลดความต้องการพื้นที่จัดเก็บข้อมูลของไคลเอ็นต์ โดยการลดหรือขจัดความจำเป็นที่แต่ละโหนดจะต้องจัดเก็บประวัติทั้งหมดหรือสถานะสุดท้ายอย่างถาวร
ลดความซับซ้อนของโปรโตคอลโดยกำจัดการทำงานที่ไม่จำเป็น
ไดเรกทอรีบทความ:
ประวัติหมดอายุ
แก้ไขปัญหาอะไรได้บ้าง?
ในขณะที่เขียนบทความนี้ โหนด Ethereum ที่ซิงโครไนซ์อย่างสมบูรณ์ต้องการ พื้นที่ดิสก์ ประมาณ 1.1 TB สำหรับ ไคลเอ็นต์การดำเนินการ และพื้นที่ดิสก์เพิ่มเติมหลายร้อย GB สำหรับไคลเอ็นต์ที่สอดคล้องกัน ข้อมูลส่วนใหญ่เป็นข้อมูลในอดีต: ข้อมูลเกี่ยวกับบล็อกในอดีต ธุรกรรม และใบเสร็จรับเงิน ซึ่งส่วนใหญ่มีอายุหลายปี ซึ่งหมายความว่าขนาดของโหนดจะเพิ่มขึ้นอย่างต่อเนื่องหลายร้อย GB ทุกปี แม้ว่าขีดจำกัดของก๊าซจะไม่เพิ่มขึ้นเลยก็ตาม
มันคืออะไรและมันทำงานอย่างไร?
คุณลักษณะที่สำคัญที่ทำให้ปัญหาการจัดเก็บประวัติง่ายขึ้นคือ เนื่องจากแต่ละบล็อกชี้ไปยังบล็อกก่อนหน้าผ่านลิงก์แฮช (และ โครงสร้าง อื่นๆ ) ฉันทามติในปัจจุบันจึงเพียงพอที่จะบรรลุฉันทามติเกี่ยวกับประวัติ ตราบใดที่เครือข่ายได้รับความเห็นพ้องต้องกันเกี่ยวกับบล็อกล่าสุด ผู้เข้าร่วมรายเดียวสามารถจัดเตรียมบล็อกหรือธุรกรรมหรือสถานะใดๆ ในอดีตได้ (ยอดคงเหลือในบัญชี nonce รหัส พื้นที่เก็บข้อมูล) พร้อมหลักฐาน Merkle และหลักฐานดังกล่าวช่วยให้ใครก็ตามสามารถตรวจสอบได้ ความถูกต้อง. ฉันทามติคือโมเดลความน่าเชื่อถือ N/2-of-N ในขณะที่ประวัติคือ โมเดลความน่าเชื่อถือ N-of-N
สิ่งนี้ทำให้เรามีทางเลือกมากมายสำหรับวิธีการจัดเก็บประวัติ ทางเลือกที่เป็นธรรมชาติคือเครือข่ายที่แต่ละโหนดจัดเก็บข้อมูลเพียงส่วนเล็กๆ เท่านั้น นี่คือวิธีที่เครือข่ายทอร์เรนต์ทำงานมานานหลายทศวรรษ: แม้ว่าเครือข่ายจะจัดเก็บและแจกจ่ายไฟล์ทั้งหมดนับล้านไฟล์ แต่ผู้เข้าร่วมแต่ละคนจะจัดเก็บและแจกจ่ายไฟล์เพียงไม่กี่ไฟล์เท่านั้น บางทีอาจขัดกับสัญชาตญาณ วิธีการนี้ไม่ได้ทำให้ข้อมูลมีความแข็งแกร่งน้อยลงด้วยซ้ำ หากเราสามารถสร้างเครือข่าย 100,000 โหนดโดยการรันโหนดในเชิงประหยัดมากขึ้น โดยแต่ละโหนดจะจัดเก็บประวัติแบบสุ่ม 10% จากนั้นข้อมูลแต่ละชิ้นจะถูกจำลองแบบ 10,000 ครั้ง เทียบกับ 10,000 ปัจจัยการจำลองแบบของแต่ละโหนดนั้นตรงกันทุกประการ เหมือนกัน - เครือข่ายของโหนด แต่ละโหนดจะเก็บทุกอย่าง
ทุกวันนี้ Ethereum เริ่มที่จะย้ายออกจากโมเดลของโหนดทั้งหมดที่เก็บประวัติทั้งหมดอย่างถาวร บล็อกฉันทามติ (เช่น ส่วนที่เกี่ยวข้องกับฉันทามติ Proof of Stake) จะถูกเก็บไว้ประมาณ 6 เดือนเท่านั้น Blobs จะถูกเก็บไว้ประมาณ 18 วันเท่านั้น EIP-4444 มีเป้าหมายที่จะแนะนำระยะเวลาการจัดเก็บหนึ่งปีสำหรับบล็อกและใบเสร็จรับเงินในอดีต เป้าหมายระยะยาวคือการสร้างช่วงเวลาที่รวมเป็นหนึ่ง (อาจประมาณ 18 วัน) ในระหว่างที่แต่ละโหนดมีหน้าที่รับผิดชอบในการจัดเก็บทุกอย่าง จากนั้นจึงสร้างเครือข่ายแบบ peer-to-peer ของโหนด Ethereum เพื่อจัดเก็บข้อมูลเก่าในลักษณะเครือข่ายแบบกระจาย
รหัสการลบสามารถใช้เพื่อเพิ่มความคงทนในขณะที่ยังคงรักษาปัจจัยการจำลองแบบไว้เหมือนเดิม ในความเป็นจริง Blobs ได้รับการเข้ารหัสเพื่อสนับสนุนการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลแล้ว วิธีแก้ปัญหาที่ง่ายที่สุดน่าจะเป็นการนำรหัสการลบข้อมูลดังกล่าวกลับมาใช้ใหม่ และใส่ข้อมูลการดำเนินการและข้อมูลบล็อกที่เป็นเอกฉันท์ลงใน Blob เช่นกัน
อะไรคือความเชื่อมโยงกับการวิจัยที่มีอยู่?
EIP-4444 ;
จะต้องทำอะไรอีก จะต้องแลกอะไรอีก?
งานหลักที่เหลืออยู่ประกอบด้วยการสร้างและบูรณาการโซลูชันแบบกระจายที่เป็นรูปธรรมเข้ากับประวัติการจัดเก็บ - อย่างน้อยก็ประวัติการดำเนินการ แต่ในที่สุดก็มีฉันทามติและหยดเช่นกัน วิธีแก้ปัญหาที่ง่ายที่สุดคือ (i) เพียงนำไลบรารีทอร์เรนต์ที่มีอยู่เข้ามา และ (ii) โซลูชันแบบเนทิฟ Ethereum ที่เรียกว่า เครือข่ายพอร์ทัล เมื่อสิ่งเหล่านี้ถูกนำเสนอ เราก็จะสามารถเปิด EIP-4444 ได้ EIP-4444 นั้นไม่จำเป็นต้องใช้ฮาร์ดฟอร์ค แต่ต้องใช้โปรโตคอลเครือข่ายเวอร์ชันใหม่ ดังนั้นจึงมีประโยชน์ในการเปิดใช้งานสำหรับไคลเอนต์ทั้งหมดในเวลาเดียวกัน มิฉะนั้นอาจมีความเสี่ยงที่ไคลเอนต์จะล้มเหลวเนื่องจากการเชื่อมต่อกับโหนดอื่นที่คาดว่าจะดาวน์โหลดประวัติทั้งหมดแต่ไม่ได้รับจริง
ข้อเสียเปรียบหลักคือวิธีที่เรามุ่งมั่นที่จะให้ข้อมูลทางประวัติศาสตร์ โบราณ วิธีแก้ปัญหาที่ง่ายที่สุดคือการหยุดจัดเก็บประวัติศาสตร์โบราณในวันพรุ่งนี้ และใช้โหนดการเก็บถาวรที่มีอยู่และผู้ให้บริการส่วนกลางต่างๆ สำหรับการจำลองแบบ เป็นเรื่องง่าย แต่จะทำให้สถานะของ Ethereum อ่อนแอลงในฐานะสถานที่บันทึกถาวร เส้นทางที่ยากกว่าแต่ปลอดภัยกว่าคือการสร้างและรวมเครือข่ายทอร์เรนต์ก่อนเพื่อจัดเก็บประวัติในลักษณะกระจาย ในที่นี้ เราพยายามแค่ไหน มีสองมิติ:
เราจะพยายามแน่ใจได้อย่างไรว่าชุดโหนดที่ใหญ่ที่สุดจะจัดเก็บข้อมูลทั้งหมดไว้จริง
เราบูรณาการการจัดเก็บประวัติเข้ากับโปรโตคอลได้ลึกแค่ไหน?
แนวทางที่หวาดระแวงอย่างมากต่อ (1) จะเกี่ยวข้องกับ การพิสูจน์หลักฐานของเอสโครว์ : โดยกำหนดให้ผู้ตรวจสอบหลักฐานพิสูจน์การเดิมพันแต่ละคนเก็บประวัติเปอร์เซ็นต์ที่แน่นอนและตรวจสอบเป็นระยะ ๆ ด้วยการเข้ารหัสลับว่าพวกเขาทำเช่นนั้น แนวทางที่เรียบง่ายกว่าคือการกำหนดมาตรฐานโดยสมัครใจสำหรับเปอร์เซ็นต์ของประวัติที่ลูกค้าแต่ละรายจัดเก็บ
สำหรับ (2) การใช้งานขั้นพื้นฐานเกี่ยวข้องกับงานที่เสร็จสิ้นในวันนี้เท่านั้น: พอร์ทัลจัดเก็บไฟล์ ERA ที่มีประวัติทั้งหมดของ Ethereum ไว้แล้ว การใช้งานที่ละเอียดยิ่งขึ้นจะเกี่ยวข้องกับการเชื่อมต่อเข้ากับกระบวนการซิงค์ ดังนั้นหากมีคนต้องการซิงค์โหนดที่เก็บข้อมูลประวัติแบบเต็มหรือโหนดไฟล์เก็บถาวร พวกเขาสามารถทำได้โดยการซิงค์โดยตรงจากเครือข่ายพอร์ทัล แม้ว่าจะไม่มีโหนดไฟล์เก็บถาวรอื่นอยู่ก็ตาม ออนไลน์
มันโต้ตอบกับส่วนอื่น ๆ ของแผนการทำงานอย่างไร?
หากเราต้องการทำให้รันหรือเริ่มต้นโหนดได้ง่ายมาก การลดความต้องการพื้นที่จัดเก็บข้อมูลในอดีตนั้นมีความสำคัญมากกว่าการไร้สถานะ กล่าวคือ จากขนาด 1.1 TB ที่โหนดต้องการนั้น ~300 GB จะเป็นสถานะ และที่เหลือ ~800 GB เป็นประวัติ มีเพียงการนำการไร้สัญชาติมาใช้และ EIP-4444 เท่านั้นที่สามารถบรรลุวิสัยทัศน์ในการใช้งานโหนด Ethereum บนนาฬิกาอัจฉริยะ และใช้เวลาเพียงไม่กี่นาทีในการตั้งค่า
การจำกัดพื้นที่จัดเก็บประวัติยังทำให้มีความเป็นไปได้มากขึ้นสำหรับการใช้งานโหนด Ethereum รุ่นใหม่เพื่อรองรับเฉพาะโปรโตคอลเวอร์ชันล่าสุด ซึ่งทำให้ง่ายขึ้น ตัวอย่างเช่น ขณะนี้สามารถลบโค้ดหลายบรรทัดได้อย่างปลอดภัย เนื่องจากช่องเก็บข้อมูลว่างที่สร้างขึ้นระหว่างการโจมตี DoS ปี 2559 ได้ถูก ลบออก ทั้งหมดแล้ว ตอนนี้การย้ายไปยัง Proof-of-Stake กลายเป็นประวัติศาสตร์แล้ว ลูกค้าจึงสามารถลบโค้ดที่เกี่ยวข้องกับ Proof-of-Work ทั้งหมดได้อย่างปลอดภัย
รัฐหมดอายุ
แก้ไขปัญหาอะไรได้บ้าง?
แม้ว่าเราจะขจัดความต้องการให้ลูกค้าจัดเก็บประวัติแล้ว แต่ความต้องการพื้นที่จัดเก็บข้อมูลของลูกค้าจะยังคงเพิ่มขึ้นที่ประมาณ 50 GB ต่อปี เนื่องจากสถานะยังคงเติบโตอย่างต่อเนื่อง: ยอดคงเหลือในบัญชีและ nonces รหัสสัญญา และพื้นที่จัดเก็บสัญญา ผู้ใช้สามารถชำระค่าธรรมเนียมเพียงครั้งเดียว ซึ่งจะสร้างภาระให้กับลูกค้า Ethereum ทั้งในปัจจุบันและอนาคตตลอดไป
สถานะนั้น หมดอายุ ได้ยากกว่าประวัติศาสตร์ เนื่องจาก EVM ได้รับการออกแบบโดยพื้นฐานบนสมมติฐานที่ว่าเมื่อวัตถุสถานะถูกสร้างขึ้น จะมีอยู่เสมอและสามารถอ่านได้จากธุรกรรมใดๆ ก็ตามได้ตลอดเวลา บางคนแย้งว่าปัญหานี้อาจไม่เลวร้ายนักหากเราแนะนำการไร้สัญชาติ: เฉพาะคลาสตัวสร้างบล็อกเฉพาะเท่านั้นที่จำเป็นในการจัดเก็บสถานะจริง ในขณะที่โหนดอื่นๆ ทั้งหมด (แม้แต่การสร้างรายการ!) ก็สามารถรันแบบไร้สัญชาติได้ อย่างไรก็ตาม มีข้อโต้แย้งที่ต้องทำว่าเราไม่ต้องการพึ่งพาการไร้สัญชาติมากเกินไป และในที่สุด เราอาจต้องการยุติสถานะเพื่อให้ Ethereum มีการกระจายอำนาจต่อไป
มันคืออะไรและมันทำงานอย่างไร
วันนี้ เมื่อคุณสร้างออบเจ็กต์สถานะใหม่ (ซึ่งอาจเกิดขึ้นได้ด้วยวิธีใดวิธีหนึ่งจากสามวิธี: (i) ส่ง ETH ไปยังบัญชีใหม่ (ii) สร้างบัญชีใหม่โดยใช้รหัส (iii) ตั้งค่าช่องเก็บข้อมูลที่ไม่มีใครแตะต้องก่อนหน้านี้) วัตถุสถานะจะอยู่ในสถานะนี้เสมอ แต่สิ่งที่เราต้องการคือการให้ออบเจ็กต์หมดอายุเมื่อเวลาผ่านไปโดยอัตโนมัติ ความท้าทายที่สำคัญคือการทำเช่นนี้ในลักษณะที่บรรลุเป้าหมายสามประการ:
ประสิทธิภาพ: ไม่จำเป็นต้องมีการคำนวณเพิ่มเติมเพิ่มเติมเพื่อดำเนินกระบวนการหมดอายุ
เป็นมิตรกับผู้ใช้: หากมีใครเข้าไปในถ้ำเป็นเวลาห้าปีแล้วกลับมา พวกเขาไม่ควรสูญเสียการเข้าถึงตำแหน่ง ETH, ERC 20, NFT, CDP...
ความเป็นมิตรของนักพัฒนา: นักพัฒนาไม่จำเป็นต้องเปลี่ยนไปใช้โมเดลทางจิตที่ไม่คุ้นเคยเลย นอกจากนี้ แอปพลิเคชันที่ล้าสมัยและไม่ได้อัปเดตควรทำงานต่อไปได้ตามปกติ
การไม่บรรลุเป้าหมายเหล่านี้อาจทำให้เกิดปัญหาได้ง่าย ตัวอย่างเช่น คุณสามารถให้ออบเจ็กต์สถานะแต่ละรายการจัดเก็บตัวนับวันที่หมดอายุ (วันหมดอายุสามารถขยายได้โดยการเบิร์น ETH ซึ่งอาจเกิดขึ้นโดยอัตโนมัติทุกครั้งที่มีการอ่านหรือเขียน) และให้วนซ้ำเหนือสถานะเพื่อลบออก วัตถุสถานะกระบวนการวันหมดอายุ อย่างไรก็ตาม สิ่งนี้ทำให้เกิดการคำนวณเพิ่มเติม (และแม้แต่ข้อกำหนดในการจัดเก็บข้อมูล) และแน่นอนว่ามันไม่เป็นไปตามข้อกำหนดด้านความเป็นมิตรต่อผู้ใช้ นอกจากนี้ยังเป็นเรื่องยากสำหรับนักพัฒนาที่จะให้เหตุผลเกี่ยวกับกรณีขอบที่เกี่ยวข้องกับค่าที่เก็บไว้ซึ่งบางครั้งจะถูกรีเซ็ตเป็นศูนย์ หากคุณตั้งค่าตัวจับเวลาการหมดอายุภายในสัญญา ในทางเทคนิคแล้ว นักพัฒนาซอฟต์แวร์จะใช้ชีวิตได้ง่ายขึ้น แต่จะทำให้เศรษฐศาสตร์ยากขึ้น: นักพัฒนาซอฟต์แวร์ต้องคิดถึงวิธี ส่งต่อ ต้นทุนพื้นที่จัดเก็บข้อมูลที่กำลังดำเนินอยู่ให้กับผู้ใช้
สิ่งเหล่านี้เป็นปัญหาที่ชุมชนการพัฒนาหลักของ Ethereum ต่อสู้ดิ้นรนมานานหลายปี รวมถึงข้อเสนอเช่น การเช่าบล็อกเชน และ การสร้างใหม่ ท้ายที่สุด เราได้รวมส่วนที่ดีที่สุดของข้อเสนอเข้าด้วยกันและมุ่งเน้นไปที่ วิธีแก้ปัญหาที่แย่ที่สุดที่รู้จักน้อยที่สุด สองหมวดหมู่:
โซลูชันการหมดอายุของสถานะบางส่วน
ระบุคำแนะนำการหมดอายุตามระยะเวลาที่อยู่
การหมดอายุของสถานะบางส่วน สถานะบางส่วนหมดอายุ
ข้อเสนอการหมดอายุของสถานะบางส่วนทั้งหมดเป็นไปตามหลักการเดียวกัน เราแบ่งรัฐออกเป็นส่วนๆ ทุกคนจะจัดเก็บ แผนที่ระดับบนสุด ของบล็อกที่ว่างหรือไม่ว่างเปล่าอย่างถาวร ข้อมูลในแต่ละบล็อกจะถูกจัดเก็บเฉพาะเมื่อมีการเข้าถึงข้อมูลเมื่อเร็วๆ นี้ มีกลไก การฟื้นคืนชีพ หากไม่เก็บไว้อีกต่อไป
ข้อแตกต่างที่สำคัญระหว่างข้อเสนอเหล่านี้คือ: (i) เราจะให้คำจำกัดความของคำว่า ใกล้ที่สุด ได้อย่างไร และ (ii) เราจะนิยามคำว่า chunk ได้อย่างไร ข้อเสนอเฉพาะประการหนึ่งคือ EIP-7736 ซึ่งต่อยอดจากการออกแบบ stem-leaf ที่นำมาใช้กับต้นไม้ Verkle (แม้ว่าจะเข้ากันได้กับรัฐไร้สัญชาติทุกรูปแบบ เช่น ต้นไม้ไบนารี) ในการออกแบบนี้ ส่วนหัว รหัส และช่องที่อยู่ติดกันจะถูกจัดเก็บไว้ใน ลำตัว เดียวกัน จำนวนข้อมูลสูงสุดที่เก็บไว้ภายใต้ Stem สามารถเป็น 256 * 31 = 7,936 ไบต์ ในหลายกรณี ส่วนหัวและรหัสทั้งหมดของบัญชีจะถูกจัดเก็บไว้ใน Trunk เดียวกัน รวมถึงช่องจัดเก็บคีย์หลายช่อง หากไม่ได้อ่านหรือเขียนข้อมูลภายใต้ Trunk ที่กำหนดเป็นเวลา 6 เดือน ข้อมูลนั้นจะไม่ถูกจัดเก็บอีกต่อไป แต่จะจัดเก็บเฉพาะข้อผูกพันขนาด 32 ไบต์ (stub) ของข้อมูลนั้นเท่านั้น ธุรกรรมในอนาคตที่เข้าถึงข้อมูลนี้จะต้อง ฟื้นฟู ข้อมูลและแสดงหลักฐานการตรวจสอบกับต้นขั้ว
มีวิธีอื่นในการนำแนวคิดที่คล้ายกันไปใช้ ตัวอย่างเช่น หากรายละเอียดในระดับบัญชีไม่เพียงพอ เราสามารถพัฒนาโครงการที่แต่ละ 1/2 32 ส่วนของต้นไม้ถูกควบคุมโดยกลไกลำต้นและใบที่คล้ายกัน
สิ่งนี้จะยุ่งยากมากขึ้นเนื่องจากสิ่งจูงใจ ผู้โจมตีสามารถ อัปเดตแผนผัง โดยการใส่ข้อมูลจำนวนมากลงในแผนผังย่อยเดียวและส่งธุรกรรมเดียวทุกปี บังคับให้ลูกค้าจัดเก็บสถานะจำนวนมากอย่างถาวร หากคุณทำให้ต้นทุนการต่ออายุเป็นสัดส่วนกับขนาดแผนผัง (หรือแปรผกผันกับระยะเวลาการต่ออายุ) อาจมีบางคนทำร้ายผู้ใช้รายอื่นด้วยการใส่ข้อมูลจำนวนมากลงในแผนผังย่อยเดียวกันกับพวกเขา เราสามารถพยายามจำกัดปัญหาทั้งสองได้โดยทำให้รายละเอียดเป็นไดนามิกตามขนาดแผนผังย่อย ตัวอย่างเช่น แต่ละออบเจ็กต์สถานะ 2 16 = 65536 ที่ต่อเนื่องกันสามารถถือเป็น กลุ่ม ได้ อย่างไรก็ตาม แนวคิดเหล่านี้มีความซับซ้อนมากกว่า วิธีการแบบอิง Stem นั้นเรียบง่ายและสามารถปรับเปลี่ยนสิ่งจูงใจได้ เนื่องจากโดยทั่วไปแล้วข้อมูลทั้งหมดที่อยู่ภายใต้ Stem จะเกี่ยวข้องกับแอปพลิเคชันหรือผู้ใช้เดียวกัน
ระบุคำแนะนำการหมดอายุตามระยะเวลาที่อยู่
จะเป็นอย่างไรหากเราต้องการหลีกเลี่ยงการเติบโตแบบถาวรใดๆ แม้แต่สตับขนาด 32 ไบต์ล่ะ? เนื่องจาก ข้อขัดแย้งในการฟื้นคืนชีพ นี่เป็นคำถามที่ยาก: จะเกิดอะไรขึ้นหากวัตถุสถานะหนึ่งถูกลบและการดำเนินการ EVM ในภายหลังทำให้วัตถุสถานะอื่นอยู่ในตำแหน่งเดียวกัน แต่แล้วคนที่ใส่ใจเกี่ยวกับวัตถุสถานะดั้งเดิมกลับมาและพยายามกู้คืนมัน Stubbing ป้องกันไม่ให้ข้อมูลใหม่ถูกสร้างขึ้นเมื่อส่วนหนึ่งของสถานะหมดอายุ เนื่องจากสถานะหมดอายุอย่างสมบูรณ์แล้ว เราจึงไม่สามารถจัดเก็บต้นขั้วได้
การออกแบบตามวงจรที่อยู่เป็นแนวคิดที่รู้จักกันดีที่สุดในการแก้ปัญหานี้ แทนที่จะมีแผนผังสถานะเดียวเพื่อจัดเก็บทั้งรัฐ เรามีรายการแผนผังสถานะที่เพิ่มขึ้นเรื่อยๆ และสถานะใดๆ ที่อ่านหรือเขียนจะถูกบันทึกไว้ในแผนผังสถานะล่าสุด โครงสร้างสถานะว่างใหม่จะถูกเพิ่มทุกช่วงเวลา (เช่น 1 ปี) ต้นไม้เก่าแก่ถูกแช่แข็งจนหมด โหนดเต็มจะเก็บเฉพาะต้นไม้ที่ใกล้ที่สุดสองต้นเท่านั้น หากวัตถุสถานะไม่ได้รับการสัมผัสในสองรอบ ซึ่งตกอยู่ในแผนผังการหมดอายุ ก็ยังคงสามารถอ่านหรือเขียนได้ แต่ธุรกรรมจำเป็นต้องพิสูจน์หลักฐาน Merkle - เมื่อพิสูจน์แล้ว สำเนาจะถูกบันทึกอีกครั้งอย่างช้าที่สุดใน ต้นไม้.
แนวคิดสำคัญที่ทำให้ทั้งผู้ใช้และนักพัฒนาเป็นมิตรคือแนวคิดของวงจรที่อยู่ ระยะเวลาที่อยู่คือตัวเลขที่เป็นส่วนหนึ่งของที่อยู่ กฎสำคัญคือที่อยู่ที่มีจุดที่อยู่ N สามารถอ่านหรือเขียนได้ในระหว่างหรือหลังช่วง N เท่านั้น (เช่น เมื่อรายการแผนผังสถานะยาวถึง N) หากคุณต้องการบันทึกออบเจ็กต์สถานะใหม่ (เช่น สัญญาใหม่ หรือยอดคงเหลือ ERC 20 ใหม่) หากคุณแน่ใจว่าได้ใส่ออบเจ็กต์สถานะไว้ในสัญญาที่มีระยะเวลาที่อยู่ N หรือ N-1 คุณสามารถบันทึกได้ ทำทันทีโดยไม่ต้องแสดงหลักฐานว่าไม่เคยมีอะไรมาก่อน ในทางกลับกัน การเพิ่มเติมหรือการแก้ไขใดๆ ที่เกิดขึ้นระหว่างที่อยู่เดิมจะต้องมีการพิสูจน์
การออกแบบนี้ยังคงรักษาคุณสมบัติปัจจุบันของ Ethereum ส่วนใหญ่ไว้ และไม่จำเป็นต้องคำนวณเพิ่มเติม ทำให้สามารถเขียนแอปพลิเคชันได้เกือบเหมือนที่เป็นอยู่ในปัจจุบัน (ERC 20 จำเป็นต้องเขียนใหม่เพื่อให้แน่ใจว่ายอดคงเหลือของที่อยู่ในช่วงเวลาที่อยู่ N จะถูกจัดเก็บไว้ในผู้รับเหมาช่วง ในตัวมันเอง มีที่อยู่ ช่วง N) ซึ่งแก้ปัญหา ผู้ใช้อยู่ในถ้ำมาห้าปีแล้ว อย่างไรก็ตาม มีปัญหาใหญ่: ที่อยู่ต้องขยายเกิน 20 ไบต์เพื่อให้พอดีกับรอบที่อยู่
ส่วนขยายพื้นที่ที่อยู่ ส่วนขยายพื้นที่ที่อยู่
ข้อเสนอหนึ่งคือการแนะนำรูปแบบที่อยู่ 32 ไบต์ใหม่ซึ่งประกอบด้วยหมายเลขเวอร์ชัน หมายเลขช่วงที่อยู่ และแฮชแบบขยาย
0x 01 (สีแดง) 0000 (สีส้ม) 000001 (สีเขียว) 57 เออี 408398 ดีเอฟ 7 อี 5 ฉ 4552091 ก 69125 d5 เอฟซี 7 บี 8 ค 2659029395 bdF (สีน้ำเงิน)
สีแดงคือหมายเลขเวอร์ชัน ศูนย์สีส้มสี่ตัวที่นี่มีวัตถุประสงค์เพื่อเป็นช่องว่างที่สามารถรองรับหมายเลขชาร์ดได้ในอนาคต สีเขียวคือหมายเลขรอบที่อยู่ สีน้ำเงินคือค่าแฮชขนาด 26 ไบต์
ความท้าทายหลักที่นี่คือความเข้ากันได้แบบย้อนหลัง สัญญาที่มีอยู่ได้รับการออกแบบให้มีที่อยู่ขนาด 20 ไบต์ และมักใช้เทคนิคการบรรจุไบต์ที่เข้มงวด โดยมีสมมติฐานอย่างชัดเจนว่าที่อยู่นั้นมีความยาว 20 ไบต์พอดี แนวคิดหนึ่งในการแก้ปัญหานี้ เกี่ยวข้องกับการแมปการแปล โดยที่สัญญาแบบเก่าที่โต้ตอบกับที่อยู่รูปแบบใหม่จะเห็นแฮชขนาด 20 ไบต์ของที่อยู่รูปแบบใหม่ อย่างไรก็ตาม มีความซับซ้อนที่สำคัญในการรับรองความปลอดภัย
การหดตัวของพื้นที่ที่อยู่
อีกวิธีหนึ่งมีทิศทางตรงกันข้าม: เราจะแบนช่วงย่อยที่อยู่ขนาด 128 จำนวน 2 ช่วงทันที (เช่น ที่อยู่ทั้งหมดที่ขึ้นต้นด้วย 0x ffffffff) จากนั้นใช้ช่วงนั้นเพื่อแนะนำที่อยู่ที่มีวงจรที่อยู่และแฮชขนาด 14 ไบต์
0x ffffffff 000169125 d5 เอฟซี 7 บี 8 C2659029395bdF
การเสียสละหลักที่ทำโดยวิธีนี้คือ การแนะนำความเสี่ยงด้านความปลอดภัยของที่อยู่ที่เป็นเท็จ : ที่อยู่ที่เก็บทรัพย์สินหรือการอนุญาต แต่รหัสที่ยังไม่ได้เผยแพร่ไปยังห่วงโซ่ ความเสี่ยงนี้เกี่ยวข้องกับบางคนที่สร้างที่อยู่ที่อ้างว่าเป็นเจ้าของโค้ด (ที่ยังไม่ได้เผยแพร่) แต่ก็มีโค้ดที่ถูกต้องอีกชิ้นหนึ่งที่ถูกแฮชไปยังที่อยู่เดียวกัน การคำนวณการชนกันดังกล่าวในปัจจุบันจะต้องใช้แฮช 280 รายการ การย่อพื้นที่ที่อยู่จะลดจำนวนนี้ลงเหลือ 256 แฮชที่เข้าถึงได้ง่าย
พื้นที่เสี่ยงหลัก ที่อยู่ที่เป็นเท็จสำหรับกระเป๋าเงินที่ถือโดยเจ้าของมากกว่าหนึ่งรายนั้นค่อนข้างหายากในปัจจุบัน แต่มีแนวโน้มว่าจะกลายเป็นเรื่องธรรมดามากขึ้นเมื่อเราก้าวเข้าสู่โลกที่มีหลาย L2 ทางออกเดียวคือยอมรับความเสี่ยงนี้ แต่ระบุกรณีการใช้งานทั่วไปทั้งหมดที่อาจเกิดปัญหาและหาวิธีแก้ปัญหาที่มีประสิทธิภาพ
อะไรคือความเชื่อมโยงกับการวิจัยที่มีอยู่?
ข้อเสนอเบื้องต้น
ข้อเสนอสถานะบางส่วนหมดอายุแล้ว
EIP-7736 ;
เอกสารการขยายพื้นที่ที่อยู่
จะต้องทำอะไรอีก จะต้องแลกอะไรอีก?
ฉันคิดว่ามีสี่เส้นทางที่เป็นไปได้สำหรับอนาคต:
เราเป็นคนไร้สัญชาติและไม่เคยเสนอการหมดอายุของรัฐ รัฐกำลังเติบโต (แม้ว่าจะช้า: เราอาจไม่เห็นมันเกิน 8 TB มานานหลายทศวรรษ) แต่โดยผู้ใช้ระดับที่ค่อนข้างพิเศษเท่านั้น: แม้แต่เครื่องมือตรวจสอบ PoS ก็ไม่ต้องการ state
คุณลักษณะหนึ่งที่ต้องการการเข้าถึงสถานะบางส่วนคือการสร้างรายการรวม แต่เราสามารถทำได้ด้วยวิธีการกระจายอำนาจ: ผู้ใช้แต่ละรายมีหน้าที่รับผิดชอบในการรักษาส่วนของแผนผังสถานะที่มีบัญชีของตนเอง เมื่อพวกเขาออกอากาศธุรกรรม พวกเขาจะออกอากาศพร้อมกับหลักฐานว่าออบเจ็กต์สถานะถูกเข้าถึงในระหว่างขั้นตอนการตรวจสอบ (สิ่งนี้ใช้กับบัญชี EOA และ ERC-4337) เครื่องมือตรวจสอบแบบไร้สัญชาติสามารถรวมการพิสูจน์เหล่านี้เป็นการพิสูจน์ที่มีรายการทั้งหมดได้เราดำเนินการหมดอายุของสถานะบางส่วนและยอมรับอัตราการเติบโตของขนาดสถานะถาวรที่ต่ำกว่ามากแต่ยังคงไม่เป็นศูนย์ ผลลัพธ์นี้อาจคล้ายคลึงกับวิธีที่ข้อเสนอการหมดอายุประวัติที่เกี่ยวข้องกับเครือข่ายเพียร์ทูเพียร์ยอมรับอัตราการเติบโตของพื้นที่จัดเก็บข้อมูลประวัติถาวรที่ต่ำกว่ามากแต่ยังคงไม่เป็นศูนย์ โดยที่ไคลเอนต์แต่ละรายต้องจัดเก็บข้อมูลประวัติที่ต่ำกว่าแต่คงที่
เราทำสถานะการหมดอายุผ่านการขยายพื้นที่ที่อยู่ ซึ่งจะเกี่ยวข้องกับกระบวนการหลายปีเพื่อให้แน่ใจว่าวิธีการแปลงรูปแบบที่อยู่มีประสิทธิภาพและปลอดภัย รวมถึงสำหรับแอปพลิเคชันที่มีอยู่ด้วย
เราดำเนินการหมดอายุสถานะผ่านการย่อขนาดพื้นที่ที่อยู่ ซึ่งจะเกี่ยวข้องกับกระบวนการหลายปีเพื่อให้แน่ใจว่าความเสี่ยงด้านความปลอดภัยทั้งหมดที่เกี่ยวข้องกับความขัดแย้งที่อยู่ รวมถึงสถานการณ์ข้ามสายโซ่ได้รับการแก้ไข
จุดสำคัญก็คือไม่ว่าจะมีการนำแผนการหมดอายุของรัฐที่อาศัยการเปลี่ยนแปลงรูปแบบที่อยู่ไปใช้หรือไม่ก็ตาม ปัญหายากๆ ที่เกี่ยวข้องกับการขยายพื้นที่ที่อยู่และการหดตัวจะต้องได้รับการแก้ไขในที่สุด ปัจจุบัน การสร้างความขัดแย้งของที่อยู่ต้องใช้แฮชประมาณ 2,80 รายการ และภาระในการคำนวณนี้เป็นไปได้แล้วสำหรับนักแสดงที่มีทรัพยากรจำนวนมาก: GPU สามารถทำงานได้ประมาณ 2,27 แฮช ดังนั้นจึงใช้งานได้หนึ่งปีที่ 2,52 ดังนั้น ประมาณ 2,30 GPU ในทั้งหมด โลก สามารถคำนวณการชนกันได้ในเวลาประมาณ 1/4 ปี และ FPGA และ ASIC ก็สามารถเร่งกระบวนการนี้ต่อไปได้ ในอนาคตการโจมตีดังกล่าวจะเปิดกว้างต่อผู้คนมากขึ้นเรื่อยๆ ดังนั้นต้นทุนจริงในการดำเนินการหมดอายุแบบเต็มสถานะอาจไม่สูงเท่าที่ควร เนื่องจากเราจะต้องแก้ไขปัญหาที่อยู่ที่ท้าทายนี้ต่อไป
มันโต้ตอบกับส่วนอื่น ๆ ของแผนการทำงานอย่างไร?
การหมดอายุของสถานะอาจทำให้การแปลงจากรูปแบบแผนผังสถานะหนึ่งไปเป็นอีกรูปแบบหนึ่งได้ง่ายขึ้น เนื่องจากไม่จำเป็นต้องใช้กระบวนการแปลง คุณสามารถเริ่มสร้างแผนผังใหม่ในรูปแบบใหม่ จากนั้นทำการฮาร์ดฟอร์กเพื่อแปลงแผนผังเก่า แม้ว่าการหมดอายุของสถานะจะซับซ้อน แต่ก็มีประโยชน์ในการทำให้แผนงานด้านอื่นๆ ง่ายขึ้น
การล้างข้อมูลคุณลักษณะ
มันแก้ปัญหาอะไรได้บ้าง?
ข้อกำหนดเบื้องต้นที่สำคัญประการหนึ่งสำหรับ การรักษาความปลอดภัย การเข้าถึง และ ความเป็นกลางที่เชื่อถือได้ คือความเรียบง่าย หากโปรโตคอลสวยงามและเรียบง่าย โอกาสที่จะเกิดข้อผิดพลาดก็น้อยลง มันเพิ่มโอกาสที่นักพัฒนาใหม่จะสามารถมีส่วนร่วมในส่วนใดส่วนหนึ่งของมันได้ มีแนวโน้มที่จะยุติธรรมและต่อต้านผลประโยชน์พิเศษมากกว่า น่าเสียดายที่โปรโตคอล เช่นเดียวกับระบบโซเชียลใดๆ มีความซับซ้อนมากขึ้นเมื่อเวลาผ่านไปตามค่าเริ่มต้น หากเราไม่ต้องการให้ Ethereum ตกอยู่ในหลุมดำที่มีความซับซ้อนเพิ่มมากขึ้น เราจำเป็นต้องทำหนึ่งในสองสิ่งต่อไปนี้: (i) หยุดทำการเปลี่ยนแปลงและทำให้โปรโตคอลแข็งตัว (ii) สามารถลบคุณสมบัติต่างๆ ได้จริงและลดความซับซ้อน เส้นทางสายกลางก็เป็นไปได้เช่นกัน เส้นทางที่มีการเปลี่ยนแปลงโปรโตคอลน้อยลง และขจัดความซับซ้อนเล็กน้อยเมื่อเวลาผ่านไป ในส่วนนี้จะกล่าวถึงวิธีการลดหรือขจัดความซับซ้อน
มันคืออะไรและมันทำงานอย่างไร?
ไม่มีการแก้ไขที่สำคัญเพียงอย่างเดียวที่สามารถลดความซับซ้อนของโปรโตคอลได้ ลักษณะของปัญหาคือมีวิธีแก้ไขเล็กๆ น้อยๆ มากมาย
ตัวอย่างหนึ่งที่ส่วนใหญ่เสร็จสมบูรณ์แล้วคือ การลบ SELFDESTRUCT opcode ออก และสามารถใช้เป็นพิมพ์เขียวสำหรับวิธีเข้าถึงตัวอย่างอื่นๆ ได้ opcode SELFDESTRUCT เป็น opcode เดียวที่สามารถแก้ไขช่องจัดเก็บข้อมูลได้ไม่จำกัดจำนวนภายในบล็อกเดียว โดยกำหนดให้ไคลเอ็นต์ต้องใช้ความซับซ้อนที่สูงขึ้นอย่างมากเพื่อหลีกเลี่ยงการโจมตี DoS วัตถุประสงค์ดั้งเดิมของ opcode นี้คือเพื่อให้รัฐสามารถชำระบัญชีโดยสมัครใจได้ ซึ่งจะทำให้ขนาดของรัฐลดลงเมื่อเวลาผ่านไป ในความเป็นจริงมีเพียงไม่กี่คนที่ใช้มัน opcode ถูกทำให้อ่อนแอลง เพื่ออนุญาตเฉพาะบัญชีที่ทำลายตัวเองที่สร้างขึ้นในธุรกรรมเดียวกันกับ Dencun hard fork วิธีนี้ช่วยแก้ไขปัญหา DoS และลดความซับซ้อนของรหัสไคลเอนต์ได้อย่างมาก ในอนาคต มันอาจจะสมเหตุสมผลที่จะลบ opcodes ออกทั้งหมดในที่สุด
ตัวอย่างที่สำคัญบางส่วนของโอกาสในการลดความซับซ้อนของโปรโตคอลที่ระบุไว้จนถึงปัจจุบันมีดังต่อไปนี้ ประการแรก ตัวอย่างบางส่วนนอกเหนือจาก EVM สิ่งเหล่านี้ค่อนข้างไม่รุกราน ดังนั้นจึงง่ายต่อการเข้าถึงฉันทามติและนำไปปฏิบัติในเวลาที่น้อยลง
การแปลง RLP → SSZ: เริ่มแรก อ็อบเจ็กต์ Ethereum ถูกทำให้เป็นอนุกรมโดยใช้การเข้ารหัสที่เรียกว่า RLP RLP ไม่มีประเภทและซับซ้อนโดยไม่จำเป็น ในปัจจุบัน บีคอนเชนใช้ SSZ ซึ่งดีกว่าอย่างมากในหลาย ๆ ด้าน รวมถึงการรองรับไม่เพียงแต่การทำให้เป็นอนุกรมเท่านั้น แต่ยังรวมถึงการแฮชด้วย ในที่สุด เราหวังว่าจะกำจัด RLP ออกไปโดยสิ้นเชิง และย้ายประเภทข้อมูลทั้งหมดไปยังโครงสร้าง SSZ ซึ่งจะทำให้การอัพเกรดง่ายขึ้น EIP ปัจจุบัน ได้แก่ [1] [2] [3]
การลบประเภทธุรกรรมเก่า: มีประเภทธุรกรรมมากเกินไปในปัจจุบัน และหลายประเภทอาจถูกลบ ทางเลือกอื่นที่ง่ายกว่าในการลบออกอย่างสมบูรณ์คือฟีเจอร์ Account Abstraction โดยที่บัญชีอัจฉริยะสามารถรวมโค้ดเพื่อประมวลผลและตรวจสอบธุรกรรมเดิมได้หากพวกเขาเลือก
การปฏิรูป LOG: บันทึกจะสร้างตัวกรองบานและตรรกะอื่น ๆ ที่เพิ่มความซับซ้อนของโปรโตคอล แต่ไคลเอ็นต์ไม่ได้ใช้งานจริงเนื่องจากช้าเกินไป เราสามารถ ลบคุณลักษณะเหล่านี้ออก และดำเนินการกับทางเลือกอื่นแทนได้ เช่น เครื่องมืออ่านบันทึกแบบกระจายอำนาจนอกโปรโตคอลโดยใช้เทคโนโลยีสมัยใหม่ เช่น SNARK
ในที่สุดกลไกคณะกรรมการการซิงโครไนซ์บีคอนก็ถูกลบออก: กลไกคณะกรรมการการซิงโครไนซ์ ถูกนำมาใช้เพื่อเปิดใช้งานการตรวจสอบไคลเอนต์แบบเบาของ Ethereum อย่างไรก็ตาม มันเพิ่มความซับซ้อนของโปรโตคอลอย่างมาก ในที่สุด เราจะสามารถ ตรวจสอบเลเยอร์ฉันทามติของ Ethereum ได้โดยตรงโดยใช้ SNARK ซึ่งจะขจัดความจำเป็นในการใช้โปรโตคอลการตรวจสอบไคลเอ็นต์แบบ light โดยเฉพาะ อาจเป็นไปได้ว่าการเปลี่ยนแปลงฉันทามติอาจทำให้เราสามารถลบคณะกรรมการการซิงโครไนซ์ออกก่อนหน้านี้โดยการสร้างโปรโตคอลไคลเอ็นต์แบบเบา ดั้งเดิม ที่เกี่ยวข้องกับการตรวจสอบความถูกต้องของลายเซ็นจากชุดย่อยแบบสุ่มของเครื่องมือตรวจสอบฉันทามติของ Ethereum
รูปแบบข้อมูลที่เป็นหนึ่งเดียว: ในปัจจุบัน สถานะการดำเนินการจะถูกจัดเก็บไว้ในแผนผัง Merkle Patricia สถานะที่เป็นเอกฉันท์จะถูกจัดเก็บไว้ใน แผนผัง SSZ และ blobs ได้รับการคอมมิตผ่าน ข้อผูกพัน KZG ในอนาคต มันจะสมเหตุสมผลที่จะมีรูปแบบรวมเดียวสำหรับข้อมูลบล็อกและรูปแบบรวมเดียวสำหรับสถานะ รูปแบบเหล่านี้จะเป็นไปตามข้อกำหนดที่สำคัญทั้งหมด: (i) การพิสูจน์อย่างง่ายของไคลเอนต์ไร้สัญชาติ (ii) การทำให้เป็นอนุกรมและการลบการเข้ารหัสข้อมูล (iii) โครงสร้างข้อมูลที่เป็นมาตรฐาน
การถอดคณะกรรมการ Beacon Chain ออก: เดิมทีกลไกนี้ถูกนำมาใช้เพื่อรองรับ การแบ่งส่วนการดำเนินการเวอร์ชันเฉพาะ แต่เรากลับจบลงด้วยการแบ่งส่วน ผ่าน L2 และ blobs คณะกรรมการจึงไม่จำเป็นและ กำลังดำเนินการเพื่อกำจัดคณะ กรรมการดังกล่าว
ลบ endianness แบบผสม: EVM เป็น endian ขนาดใหญ่และเลเยอร์ฉันทามติคือ endian เล็กน้อย มันอาจสมเหตุสมผลที่จะประสานกันใหม่และทำให้ทุกอย่างไม่ทางใดก็ทางหนึ่ง (อาจเป็น endian ที่ยิ่งใหญ่เนื่องจาก EVM นั้นยากต่อการเปลี่ยนแปลง)
ตอนนี้ตัวอย่างบางส่วนใน EVM:
การทำให้กลไกของแก๊สง่ายขึ้น: กฎของแก๊สในปัจจุบันยังไม่ได้รับการปรับให้เหมาะสมอย่างเหมาะสม และไม่สามารถให้ข้อจำกัดที่ชัดเจนเกี่ยวกับจำนวนทรัพยากรที่จำเป็นในการตรวจสอบบล็อก ตัวอย่างที่สำคัญของสิ่งนี้ ได้แก่ (i) ค่าใช้จ่ายในการอ่าน/เขียนพื้นที่เก็บข้อมูล ซึ่งออกแบบมาเพื่อจำกัดจำนวนการอ่าน/เขียนในบล็อก แต่ในปัจจุบันค่อนข้างจะกำหนดขึ้นเอง และ (ii) กฎการเติมหน่วยความจำ ซึ่งปัจจุบันประเมินค่าสูงสุดได้ยาก การใช้หน่วยความจำของ EVM การแก้ไขที่เสนอประกอบด้วย การเปลี่ยนแปลงต้นทุนก๊าซไร้สถานะ ที่รวมต้นทุนที่เกี่ยวข้องกับพื้นที่จัดเก็บข้อมูลทั้งหมดไว้ในสูตรง่ายๆ และ ข้อเสนอราคาหน่วยความจำ
ลบการคอมไพล์ล่วงหน้า: การคอมไพล์ล่วงหน้าจำนวนมากที่ Ethereum มีในปัจจุบันมีความซับซ้อนโดยไม่จำเป็น ค่อนข้างไม่ได้ใช้ และถือเป็นส่วนใหญ่ของความล้มเหลวที่เป็นเอกฉันท์ในขณะที่แอปพลิเคชันใดๆ แทบไม่ได้ใช้งาน สองวิธีในการจัดการกับปัญหานี้คือ (i) เพียงลบการคอมไพล์ล่วงหน้า และ (ii) แทนที่ด้วยโค้ด EVM (มีราคาแพงกว่าอย่างหลีกเลี่ยงไม่ได้) ที่ใช้ตรรกะเดียวกัน ร่าง EIP แนะนำให้ ทำเช่นนี้สำหรับการคอมไพล์ข้อมูลประจำตัวล่วงหน้าเป็นขั้นตอนแรกในภายหลัง RIPEMD 160, MODEXP และ BLAKE อาจกลายเป็นตัวเลือกสำหรับการลบออก
ลบความสามารถในการสังเกตก๊าซ: ทำให้การดำเนินการ EVM ไม่สามารถดูปริมาณก๊าซที่เหลืออยู่ได้อีกต่อไป การดำเนินการนี้จะทำให้แอปพลิเคชันบางรายการเสียหาย (โดยเฉพาะอย่างยิ่งข้อตกลงการสนับสนุน) แต่จะทำให้อัปเกรดได้ง่ายขึ้นในอนาคต (เช่น สำหรับเวอร์ชันขั้นสูงของ ก๊าซระหว่างมิติ ) ข้อกำหนด EOF ทำให้ Gas ไม่สามารถสังเกตได้อยู่แล้ว แต่เพื่อให้โปรโตคอลง่ายขึ้น EOF จำเป็นต้องกลายเป็นข้อบังคับ
การปรับปรุงการวิเคราะห์แบบคงที่: รหัส EVM ในปัจจุบันเป็นเรื่องยากที่จะวิเคราะห์โดยเฉพาะอย่างยิ่งเนื่องจากการกระโดดอาจเป็นแบบไดนามิก นอกจากนี้ยังทำให้การปรับการใช้งาน EVM ให้เหมาะสม (การคอมไพล์โค้ด EVM ล่วงหน้าเป็นภาษาอื่น) ยากขึ้น เราสามารถแก้ไขปัญหานี้ได้โดย การลบการกระโดดแบบไดนามิก (หรือทำให้มีราคาแพงกว่า เช่น ค่าก๊าซเชิงเส้นสำหรับจำนวน JUMPDEST ทั้งหมดในสัญญา) EOF ทำเช่นนั้น แม้ว่าจำเป็นต้องบังคับใช้ EOF เพื่อเก็บเกี่ยวผลประโยชน์จากการลดความซับซ้อนของโปรโตคอลก็ตาม
อะไรคือความเชื่อมโยงกับการวิจัยที่มีอยู่?
วิธีการเรียกค้นบันทึกความปลอดภัยนอกเครือข่ายโดยใช้การคำนวณที่ตรวจสอบได้แบบเพิ่มหน่วย (อ่าน: STARK แบบเรียกซ้ำ)
จะต้องทำอะไรอีก จะต้องแลกอะไรอีก?
ข้อเสียเปรียบหลักในการทำให้ฟีเจอร์นี้ง่ายขึ้นคือ (i) ขอบเขตและความเร็วของการลดความซับซ้อนของเราเทียบกับ (ii) ความเข้ากันได้แบบย้อนหลัง คุณค่าของ Ethereum ในฐานะเครือข่ายมาจากข้อเท็จจริงที่ว่าเป็นแพลตฟอร์มที่คุณสามารถปรับใช้แอปพลิเคชันได้ และมั่นใจได้ว่าจะยังคงใช้งานได้ในอีกหลายปีต่อมา ในเวลาเดียวกัน อุดมคตินี้อาจไปไกลเกินไป และในคำพูดของ William Jennings Bryan ตอกย้ำ Ethereum ให้กลายเป็นกากบาทของความเข้ากันได้แบบย้อนหลัง หากมีเพียงสองแอปพลิเคชันใน Ethereum ทั้งหมดที่ใช้คุณสมบัติที่กำหนด และแอปพลิเคชั่นหนึ่งไม่มีผู้ใช้มานานหลายปี ในขณะที่อีกแอปพลิเคชั่นหนึ่งไม่ได้ใช้งานเกือบทั้งหมดและมีมูลค่ารวม $57 เราควรลบฟังก์ชันนั้นออก และ จ่ายเงินให้เหยื่อ $57 จากกระเป๋าหากจำเป็น
ปัญหาทางสังคมในวงกว้างคือการสร้างไปป์ไลน์ที่เป็นมาตรฐานสำหรับการเปลี่ยนแปลงความเข้ากันได้แบบย้อนหลังที่ไม่เร่งด่วน วิธีหนึ่งในการแก้ไขปัญหานี้คือการตรวจสอบและขยายแบบอย่างที่มีอยู่ เช่น กระบวนการทำลายตนเอง ไปป์ไลน์มีลักษณะดังนี้:
เริ่มพูดคุยเกี่ยวกับการลบคุณลักษณะ X;
ดำเนินการวิเคราะห์เพื่อกำหนดผลกระทบของการลบและดำเนินการต่อ
พัฒนา EIP อย่างเป็นทางการเพื่อเลิกใช้งาน X. ตรวจสอบให้แน่ใจว่าโครงสร้างพื้นฐานระดับสูงกว่ายอดนิยม (เช่น ภาษาการเขียนโปรแกรม กระเป๋าเงิน) เคารพสิ่งนี้และหยุดใช้คุณสมบัตินี้ -
สุดท้ายให้ลบ X;
ระหว่างขั้นตอนที่ 1 ถึง 4 ควรมีการดำเนินการหลายปี โดยมีคำแนะนำที่ชัดเจนว่าโครงการใดอยู่ในขั้นตอนใด ณ จุดนี้ มีการแลกกันระหว่างไดนามิกและความเร็วของกระบวนการลบฟีเจอร์ เทียบกับการระมัดระวังมากกว่าและการทุ่มเททรัพยากรมากขึ้นในด้านอื่น ๆ ของการพัฒนาโปรโตคอล แต่เรายังห่างไกลจากขอบเขต Pareto
อีโอเอฟ
ชุดการเปลี่ยนแปลงที่สำคัญชุดหนึ่งที่เสนอใน EVM คือ EVM Object Format (EOF) EOF นำเสนอการเปลี่ยนแปลงจำนวนมาก เช่น การปิดใช้งานความสามารถในการสังเกตก๊าซ ความสามารถในการสังเกตโค้ด (เช่น ไม่มี CODECOPY) และการอนุญาตเฉพาะการข้ามแบบคงที่เท่านั้น เป้าหมายคือการอนุญาตให้อัปเกรด EVM ได้มากขึ้นด้วยคุณสมบัติที่แข็งแกร่งยิ่งขึ้นในขณะที่ยังคงความเข้ากันได้แบบย้อนหลัง (เนื่องจาก EVM ก่อน EOF ยังคงมีอยู่)
ข้อดีของสิ่งนี้คือสร้างเส้นทางธรรมชาติสำหรับการเพิ่มฟังก์ชัน EVM ใหม่และสนับสนุนการโยกย้ายไปยัง EVM ที่เข้มงวดยิ่งขึ้นพร้อมการรับประกันที่แข็งแกร่งยิ่งขึ้น ข้อเสียคือจะเพิ่มความซับซ้อนของโปรโตคอลอย่างมาก เว้นแต่ว่าเราจะหาวิธีเลิกใช้และลบ EVM เก่าได้ในที่สุด คำถามสำคัญคือ EOF มีบทบาทอย่างไรในข้อเสนอการทำให้ EVM ง่ายขึ้น โดยเฉพาะอย่างยิ่งหากเป้าหมายคือการลดความซับซ้อน EVM โดยรวม
มันโต้ตอบกับส่วนอื่น ๆ ของแผนการทำงานอย่างไร?
คำแนะนำ การปรับปรุง หลายประการในแผนการทำงานที่เหลือยังเป็นโอกาสในการทำให้ฟีเจอร์เก่าๆ ง่ายขึ้นอีกด้วย ทำซ้ำตัวอย่างบางส่วนจากด้านบน:
การเปลี่ยนไปใช้ single-slot Finality ทำให้เรามีโอกาสกำจัดคณะกรรมการ ออกแบบเศรษฐศาสตร์ใหม่ และทำให้ง่ายขึ้นอื่นๆ ที่เกี่ยวข้องกับการพิสูจน์การเดิมพัน
การใช้นามธรรมบัญชีโดยสมบูรณ์ช่วยให้เราสามารถลบตรรกะการประมวลผลธุรกรรมที่มีอยู่จำนวนมาก และย้ายไปยัง รหัส EVM ของบัญชีเริ่มต้น ที่ EOA ทั้งหมดสามารถแทนที่ได้
สิ่งนี้สามารถกระทบยอดกับ SSZ เวอร์ชันใหม่ได้หากเราย้ายสถานะ Ethereum ไปที่แผนผังแฮชแบบไบนารี เพื่อให้สามารถแฮชโครงสร้างข้อมูล Ethereum ทั้งหมดได้ในลักษณะเดียวกัน
แนวทางที่รุนแรงยิ่งขึ้น: แปลงโปรโตคอลส่วนใหญ่ให้เป็นรหัสสัญญา
กลยุทธ์การลดความซับซ้อนของ Ethereum ที่ต่างไปจากเดิมอย่างสิ้นเชิงคือการรักษาโปรโตคอลให้เหมือนเดิม แต่ย้ายส่วนใหญ่จากฟังก์ชันการทำงานของโปรโตคอลไปเป็นรหัสสัญญา
เวอร์ชันที่รุนแรงที่สุดคือการทำให้ Ethereum L1 ในทางเทคนิค เป็นเพียงแค่บีคอนเชนและแนะนำเครื่องเสมือนขั้นต่ำ (เช่น RISC-V , ไคโร หรือแม้แต่ระบบพิสูจน์เฉพาะขั้นต่ำสุด) ที่จะอนุญาตให้ผู้อื่นสร้างโรลอัปของตนเอง จากนั้น EVM จะกลายเป็นชุดแรกในการยกเลิกเหล่านี้ น่าแปลกที่นี่คือผลลัพธ์เดียวกันกับ ข้อเสนอด้านสิ่งแวดล้อมสำหรับผู้บริหารปี 2019-20 แม้ว่า SNARK จะทำให้นำไปปฏิบัติจริงมีความเป็นไปได้มากขึ้นก็ตาม
แนวทางที่เรียบง่ายกว่าคือการรักษาความสัมพันธ์ระหว่างบีคอนเชนและสภาพแวดล้อมการดำเนินการ Ethereum ในปัจจุบันไม่เปลี่ยนแปลง แต่ทำการสลับ EVM แบบแทนที่ เราสามารถเลือก RISC-V, Cairo หรือ VM อื่นเป็น Ethereum VM อย่างเป็นทางการ ใหม่ จากนั้นบังคับให้สัญญา EVM ทั้งหมดเป็นโค้ด VM ใหม่ที่ตีความตรรกะของโค้ดต้นฉบับ (ไม่ว่าจะผ่านการคอมไพล์หรือการตีความ) ตามทฤษฎีแล้ว สิ่งนี้สามารถทำได้ผ่าน VM เป้าหมาย ซึ่งเป็นเวอร์ชันของ EOF
