บทความใหม่ของ Vitalik: อนาคตที่เป็นไปได้ของ Ethereum (V) — The Purge
ชื่อเรื่องเดิม: อนาคตที่เป็นไปได้ของโปรโตคอล Ethereum ตอนที่ 5: การชำระล้าง
บทความต้นฉบับโดย Vitalik Buterin
คำแปลต้นฉบับ: Odaily Planet Daily Husband How
ตั้งแต่วันที่ 14 ตุลาคม Vitalik Buterin ผู้ก่อตั้ง Ethereum ได้เผยแพร่การอภิปรายเกี่ยวกับอนาคตที่เป็นไปได้ของ Ethereum อย่างต่อเนื่อง การผสาน , การกระชาก , ภัยพิบัติ , ขอบ สู่การเปิดตัวล่าสุด การชำระล้าง พวกเขาทั้งหมดเน้นย้ำถึงวิสัยทัศน์ของ Vitaliks สำหรับการพัฒนาในอนาคตของ Ethereum mainnet และวิธีแก้ไขปัญหาปัจจุบัน
การผสาน: หารือถึงความจำเป็นของ Ethereum ที่ต้องปรับปรุงความสมบูรณ์แบบของสล็อตเดียวและเกณฑ์การเดิมพันที่ต่ำลงหลังจากย้ายไปยัง PoS เพื่อเพิ่มการมีส่วนร่วมและเร่งความเร็วในการยืนยันธุรกรรม
The Surge: สำรวจกลยุทธ์ต่างๆ สำหรับการปรับขนาด Ethereum โดยเฉพาะแผนงานที่เน้นที่ Rollup รวมถึงความท้าทายและโซลูชันในแง่ของความสามารถในการปรับขนาด การกระจายอำนาจ และความปลอดภัย
The Scourge: สำรวจความเสี่ยงของการรวมศูนย์และการดึงมูลค่าที่ Ethereum เผชิญในการเปลี่ยนผ่านไปยัง PoS พัฒนากลไกต่างๆ มากมายเพื่อปรับปรุงการกระจายอำนาจและความยุติธรรม และปฏิรูปเศรษฐกิจสเตกกิ้งเพื่อปกป้องผลประโยชน์ของผู้ใช้
The Verge: สำรวจความท้าทายและโซลูชันของการตรวจสอบแบบไร้สถานะของ Ethereum โดยมุ่งเน้นไปที่วิธีที่เทคโนโลยีเช่น Verkle trees และ STARKs สามารถปรับปรุงการกระจายอำนาจและประสิทธิภาพของบล็อคเชนได้อย่างไร
เมื่อวันที่ 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 ประสบความสำเร็จในบางกรณี: หลักฐานการทำงานหายไป โอปโค้ด SELFDESTRUCT หายไปเกือบหมด และโหนดบีคอนเชนก็เก็บข้อมูลเก่าไว้มากถึงหกเดือน การหาเส้นทางนี้สำหรับ Ethereum ในลักษณะทั่วไปมากขึ้น และมุ่งสู่ผลลัพธ์สุดท้ายที่เสถียรในระยะยาว ถือเป็นความท้าทายสูงสุดสำหรับความสามารถในการปรับขนาดในระยะยาว ความยั่งยืนทางเทคนิค และแม้แต่ความปลอดภัยของ Ethereum
การชำระล้าง: เป้าหมายหลัก
-
ความต้องการพื้นที่เก็บข้อมูลของลูกค้าลดลง โดยลดหรือขจัดความจำเป็นที่แต่ละโหนดจะต้องจัดเก็บประวัติทั้งหมดอย่างถาวรหรือแม้แต่สถานะสุดท้าย
-
ลดความซับซ้อนของโปรโตคอลโดยการกำจัดฟังก์ชันที่ไม่จำเป็น
ไดเรกทอรีบทความ:
ประวัติการหมดอายุ
มันช่วยแก้ปัญหาอะไรได้บ้าง?
ณ ขณะที่เขียนนี้ โหนด Ethereum ที่ซิงโครไนซ์อย่างสมบูรณ์ต้องการ ประมาณ 1.1TB ของพื้นที่ดิสก์สำหรับ ไคลเอนต์การดำเนินการ และอีกหลายร้อย GB สำหรับไคลเอนต์ที่ใช้ฉันทามติ ข้อมูลส่วนใหญ่นี้เป็นข้อมูลในอดีต: ข้อมูลเกี่ยวกับบล็อก ธุรกรรม และใบเสร็จในอดีต ซึ่งส่วนใหญ่มีอายุหลายปี ซึ่งหมายความว่าแม้ว่าขีดจำกัดแก๊สจะไม่เพิ่มขึ้นเลย แต่ขนาดของโหนดจะยังคงเพิ่มขึ้นหลายร้อย GB ต่อปี
มันคืออะไรและทำงานอย่างไร?
คุณสมบัติที่สำคัญในการลดความซับซ้อนของปัญหาการจัดเก็บประวัติคือเนื่องจากแต่ละบล็อกจะชี้ไปยังบล็อกก่อนหน้าผ่านลิงก์แฮช (และ อื่น โครงสร้าง ) ฉันทามติในปัจจุบันก็เพียงพอที่จะบรรลุฉันทามติเกี่ยวกับประวัติ ตราบใดที่เครือข่ายตกลงกันในบล็อกล่าสุด บล็อกหรือธุรกรรมหรือสถานะทางประวัติศาสตร์ใดๆ (ยอดคงเหลือในบัญชี หมายเลขสุ่ม รหัส พื้นที่จัดเก็บ) สามารถจัดทำโดยผู้เข้าร่วมรายเดียวพร้อมกับหลักฐาน Merkle และหลักฐานนั้นช่วยให้ผู้อื่นสามารถยืนยันความถูกต้องได้ ฉันทามติเป็นแบบจำลองความไว้วางใจ N/2-of-N ในขณะที่ประวัติคือ แบบจำลองความไว้วางใจ N-of-N .
สิ่งนี้ทำให้เรามีตัวเลือกมากมายสำหรับวิธีจัดเก็บประวัติ ทางเลือกตามธรรมชาติอย่างหนึ่งคือเครือข่ายที่แต่ละโหนดจัดเก็บข้อมูลเพียงเศษเสี้ยวเล็กน้อยเท่านั้น นี่คือวิธีที่เครือข่าย Seed ทำงานมาหลายทศวรรษแล้ว ในขณะที่เครือข่ายจัดเก็บและแจกจ่ายไฟล์นับล้านไฟล์ แต่ผู้เข้าร่วมแต่ละรายจัดเก็บและแจกจ่ายเพียงไม่กี่ไฟล์เท่านั้น ซึ่งอาจขัดกับสัญชาตญาณ แนวทางนี้ไม่ได้ลดความทนทานของข้อมูลลงเลยด้วยซ้ำ หากเราสามารถสร้างเครือข่ายที่มีโหนด 100,000 โหนด โดยที่แต่ละโหนดจัดเก็บประวัติแบบสุ่ม 10% ข้อมูลแต่ละชิ้นจะถูกจำลอง 10,000 ครั้ง ซึ่งเท่ากับปัจจัยการจำลองแบบเดียวกันกับเครือข่าย 10,000 โหนด โดยที่แต่ละโหนดจัดเก็บทุกอย่าง
ปัจจุบัน Ethereum เริ่มเคลื่อนตัวออกจากรูปแบบที่โหนดทั้งหมดจัดเก็บประวัติทั้งหมดอย่างถาวร บล็อกคอนเซนซัส (กล่าวคือ ส่วนที่เกี่ยวข้องกับคอนเซนซัสแบบ Proof-of-Stake) จะถูกจัดเก็บเพียงประมาณ 6 เดือน ส่วนบล็อบจะถูกจัดเก็บเพียงประมาณ 18 วันเท่านั้น EIP-4444 มีเป้าหมายที่จะแนะนำระยะเวลาการจัดเก็บข้อมูลหนึ่งปีสำหรับบล็อกและใบเสร็จในประวัติศาสตร์ เป้าหมายระยะยาวคือการกำหนดระยะเวลาที่สม่ำเสมอ (อาจประมาณ 18 วัน) ซึ่งแต่ละโหนดจะรับผิดชอบในการจัดเก็บทุกอย่าง จากนั้นจึงสร้างเครือข่ายเพียร์ทูเพียร์ของโหนด Ethereum ที่จัดเก็บข้อมูลเก่าในลักษณะเครือข่ายแบบกระจาย
รหัสการลบข้อมูลสามารถใช้เพื่อปรับปรุงความทนทานในขณะที่ยังคงปัจจัยการจำลองข้อมูลไว้เท่าเดิม ในความเป็นจริง บล็อบมีรหัสการลบข้อมูลอยู่แล้วเพื่อรองรับการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล วิธีแก้ปัญหาที่ง่ายที่สุดคือการนำรหัสการลบข้อมูลดังกล่าวมาใช้ซ้ำและใส่ข้อมูลบล็อกการดำเนินการและการตกลงกันลงในบล็อบด้วยเช่นกัน
มีความเชื่อมโยงกับงานวิจัยที่มีอยู่อย่างไร?
-
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 ในปี 2016 ถูกลบออกหมดแล้ว ลบแล้ว เนื่องจากตอนนี้การเปลี่ยนไปใช้การพิสูจน์การถือครองถือเป็นอดีตไปแล้ว ไคลเอนต์จึงสามารถลบโค้ดที่เกี่ยวข้องกับการพิสูจน์การทำงานทั้งหมดได้อย่างปลอดภัย
วันหมดอายุของรัฐ
มันช่วยแก้ปัญหาอะไรได้บ้าง?
แม้ว่าเราจะไม่จำเป็นต้องให้ไคลเอนต์เก็บประวัติ แต่ความต้องการพื้นที่เก็บข้อมูลของไคลเอนต์ก็ยังคงเพิ่มขึ้นเรื่อยๆ ประมาณ 50 GB ต่อปี เนื่องจากสถานะยังคงเพิ่มขึ้นเรื่อยๆ เช่น ยอดเงินในบัญชีและรหัสสัญญา รหัสสัญญา และการจัดเก็บสัญญา ผู้ใช้สามารถชำระค่าธรรมเนียมครั้งเดียว ซึ่งจะทำให้ไคลเอนต์ Ethereum ทั้งในปัจจุบันและในอนาคตต้องแบกรับภาระตลอดไป
สถานะนั้นหมดอายุได้ยากกว่าประวัติศาสตร์ เนื่องจาก EVM ได้รับการออกแบบมาโดยยึดตามสมมติฐานที่ว่าเมื่อสร้างวัตถุสถานะแล้ว วัตถุนั้นก็จะคงอยู่ตลอดไปและสามารถอ่านได้โดยธุรกรรมใดๆ ตลอดเวลา หากเรานำระบบไร้สถานะมาใช้ บางคนอาจคิดว่าปัญหานี้อาจไม่เลวร้ายนัก: มีเพียงคลาสของตัวสร้างบล็อกเฉพาะเท่านั้นที่ต้องจัดเก็บสถานะจริง และโหนดอื่นๆ ทั้งหมด (แม้แต่การสร้างรายการ!) สามารถทำงานแบบไร้สถานะได้ อย่างไรก็ตาม มีข้อโต้แย้งว่าเราไม่ต้องการพึ่งพาระบบไร้สถานะมากเกินไป และในที่สุด เราอาจต้องการให้สถานะหมดอายุเพื่อให้ Ethereum กระจายอำนาจต่อไป
มันคืออะไรและมันทำงานอย่างไร
ปัจจุบัน เมื่อคุณสร้างวัตถุสถานะใหม่ (ซึ่งสามารถทำได้ 3 วิธีด้วยกัน: (i) ส่ง ETH ไปยังบัญชีใหม่ (ii) สร้างบัญชีใหม่โดยใช้โค้ด (iii) ตั้งค่าช่องเก็บข้อมูลที่ยังไม่ได้แตะต้องก่อนหน้านี้) วัตถุสถานะนั้นจะคงอยู่ในสถานะนั้นตลอดไป แต่สิ่งที่เราต้องการคือให้วัตถุหมดอายุโดยอัตโนมัติเมื่อเวลาผ่านไป ความท้าทายที่สำคัญคือต้องทำในลักษณะที่บรรลุเป้าหมาย 3 ประการ:
-
ประสิทธิภาพ: ไม่จำเป็นต้องมีการคำนวณเพิ่มเติมจำนวนมากในการรันกระบวนการหมดอายุ
-
ความเป็นมิตรต่อผู้ใช้: หากใครก็ตามเข้าไปในถ้ำเป็นเวลา 5 ปีแล้วกลับมา พวกเขาไม่ควรสูญเสียการเข้าถึงตำแหน่ง ETH, ERC 20, NFT, CDP ของพวกเขา…
-
ความเป็นมิตรต่อนักพัฒนา: นักพัฒนาไม่จำเป็นต้องเปลี่ยนไปใช้รูปแบบความคิดที่ไม่คุ้นเคยเลย นอกจากนี้ แอปพลิเคชันที่ล้าสมัยและไม่ได้รับการอัปเดตในปัจจุบันยังคงทำงานได้ดี
การแก้ไขปัญหาที่ไม่เป็นไปตามเป้าหมายเหล่านี้ทำได้ง่าย ตัวอย่างเช่น คุณสามารถให้แต่ละอ็อบเจกต์สถานะจัดเก็บตัวนับวันที่หมดอายุ (วันที่หมดอายุสามารถขยายได้โดยการเบิร์น ETH ซึ่งอาจเกิดขึ้นโดยอัตโนมัติทุกครั้งที่มีการอ่านหรือเขียน) และมีกระบวนการที่วนซ้ำผ่านสถานะเพื่อลบอ็อบเจกต์สถานะที่หมดอายุ อย่างไรก็ตาม การทำเช่นนี้จะเพิ่มการคำนวณ (และแม้แต่ข้อกำหนดด้านพื้นที่เก็บข้อมูล) และแน่นอนว่าไม่เป็นไปตามข้อกำหนดด้านความเป็นมิตรต่อผู้ใช้ นอกจากนี้ นักพัฒนายังพบว่ายากที่จะหาเหตุผลเกี่ยวกับกรณีขอบที่เกี่ยวข้องกับค่าที่เก็บไว้ซึ่งบางครั้งจะถูกรีเซ็ตเป็นศูนย์ หากคุณตั้งเวลาหมดอายุภายในขอบเขตของสัญญา การดำเนินการดังกล่าวจะทำให้ชีวิตของนักพัฒนาง่ายขึ้นในทางเทคนิค แต่จะทำให้เศรษฐศาสตร์ยากขึ้น นักพัฒนาต้องคิดว่าจะส่งต่อต้นทุนการจัดเก็บอย่างต่อเนื่องไปยังผู้ใช้ได้อย่างไร
สิ่งเหล่านี้เป็นปัญหาที่ชุมชนนักพัฒนา Ethereum core ได้ดำเนินการมาเป็นเวลาหลายปี ซึ่งรวมถึงข้อเสนอ เช่น “ การเช่าบล็อคเชน " และ " การสร้างขึ้นใหม่ ในที่สุด เราได้รวมส่วนที่ดีที่สุดของข้อเสนอและมุ่งเน้นไปที่สองประเภทของ "โซลูชันที่แย่ที่สุดเท่าที่ทราบ":
-
โซลูชันการหมดอายุสถานะบางส่วน
-
คำแนะนำการหมดอายุของรัฐตามรอบที่อยู่
การหมดอายุของสถานะบางส่วน
ข้อเสนอการหมดอายุของสถานะบางส่วนทั้งหมดปฏิบัติตามหลักการเดียวกัน เราแบ่งสถานะออกเป็นส่วนๆ แต่ละส่วนจะจัดเก็บแผนที่ระดับบนสุดอย่างถาวร โดยที่ส่วนนั้นจะว่างเปล่าหรือไม่ว่างเปล่า ข้อมูลในแต่ละส่วนจะถูกจัดเก็บเฉพาะในกรณีที่มีการเข้าถึงข้อมูลดังกล่าวเมื่อเร็วๆ นี้เท่านั้น มีกลไกการฟื้นคืนชีพที่จะฟื้นคืนส่วนหากไม่ได้จัดเก็บไว้แล้ว
ความแตกต่างหลักระหว่างข้อเสนอเหล่านี้คือ: (i) เราจะทำอย่างไร เด็ดขาดne “เมื่อไม่นานนี้” และ (ii) เราจะนิยามคำว่า “บล็อก” ได้อย่างไร? ข้อเสนอเฉพาะอย่างหนึ่งคือ อีไอพี-7736 ซึ่งสร้างขึ้นจากการออกแบบ “ลำต้นและใบ” แนะนำสำหรับต้น Verkle (แม้ว่าจะเข้ากันได้กับรูปแบบสถานะไร้สถานะใดๆ เช่น ต้นไม้ไบนารี) ในการออกแบบนี้ ส่วนหัว โค้ด และช่องเก็บข้อมูลที่อยู่ติดกันจะถูกจัดเก็บภายใต้ "ทรังค์" เดียวกัน ข้อมูลที่จัดเก็บภายใต้สเต็มสามารถมีขนาดได้ถึง 256 * 31 = 7,936 ไบต์ ในหลายกรณี ส่วนหัวและโค้ดทั้งหมดของบัญชี รวมถึงช่องเก็บข้อมูลคีย์จำนวนมากจะถูกจัดเก็บภายใต้ทรังค์เดียวกัน หากข้อมูลภายใต้ทรังค์ที่กำหนดไม่ได้รับการอ่านหรือเขียนเป็นเวลา 6 เดือน ข้อมูลนั้นจะไม่ถูกจัดเก็บอีกต่อไป และจะจัดเก็บเฉพาะการผูกมัด 32 ไบต์ ("สตับ") กับข้อมูลนั้นเท่านั้น ธุรกรรมในอนาคตที่เข้าถึงข้อมูลนั้นจะต้อง "ฟื้นคืนชีพ" ข้อมูลนั้นและแสดงหลักฐานว่าข้อมูลนั้นตรวจสอบกับสตับแล้ว
มีวิธีอื่นๆ ในการนำแนวคิดที่คล้ายกันไปใช้ ตัวอย่างเช่น หากความละเอียดในระดับบัญชีไม่เพียงพอ เราสามารถสร้างรูปแบบที่ส่วนต่างๆ ของต้นไม้ 1/2 32 ส่วนได้รับการควบคุมโดยกลไกลำต้นและใบที่คล้ายคลึงกัน
ปัญหานี้มีความซับซ้อนมากขึ้นเนื่องจากแรงจูงใจ: ผู้โจมตีสามารถบังคับให้ไคลเอ็นต์จัดเก็บสถานะจำนวนมากเป็นการถาวรได้โดยการใส่ข้อมูลจำนวนมากลงในซับทรีเดียวและส่งธุรกรรมเดียวทุกปีเพื่ออัปเดตทรี หากคุณทำให้ต้นทุนการต่ออายุเป็นสัดส่วนกับขนาดของทรี (หรือแปรผกผันกับระยะเวลาการต่ออายุ) บุคคลใดบุคคลหนึ่งอาจทำอันตรายต่อผู้ใช้รายอื่นได้โดยการใส่ข้อมูลจำนวนมากลงในซับทรีเดียวกันกับพวกเขา เราสามารถลองจำกัดปัญหาทั้งสองนี้โดยทำให้รายละเอียดเป็นแบบไดนามิกเมื่อเทียบกับขนาดของซับทรี เช่น ออบเจ็กต์สถานะ 216 = 65536 แต่ละรายการที่ต่อเนื่องกันอาจถือเป็นกลุ่มได้ อย่างไรก็ตาม แนวคิดเหล่านี้มีความซับซ้อนมากกว่า แนวทางที่อิงตามสเต็มนั้นเรียบง่าย และแรงจูงใจสามารถจัดตำแหน่งได้ เนื่องจากโดยทั่วไปแล้วข้อมูลทั้งหมดภายใต้สเต็มจะเกี่ยวข้องกับแอปพลิเคชันหรือผู้ใช้เดียวกัน
คำแนะนำการหมดอายุตามรอบที่อยู่
จะเกิดอะไรขึ้นหากเราต้องการหลีกเลี่ยงการเติบโตของสถานะถาวรใดๆ แม้แต่สตับขนาด 32 ไบต์ นี่เป็นปัญหาที่ยากเนื่องจาก ความขัดแย้งของการฟื้นคืนชีพ :จะเกิดอะไรขึ้นหากวัตถุสถานะถูกลบ และภายหลังการดำเนินการของ EVM วางวัตถุสถานะอื่นไว้ในตำแหน่งเดียวกัน แต่แล้วมีคนที่สนใจวัตถุสถานะเดิมกลับมาและพยายามกู้คืน เมื่อส่วนหนึ่งของสถานะหมดอายุ สตับจะป้องกันไม่ให้มีการสร้างข้อมูลใหม่ เมื่อสถานะหมดอายุโดยสมบูรณ์แล้ว เราไม่สามารถจัดเก็บสตับได้ด้วยซ้ำ
การออกแบบตามรอบที่อยู่เป็นแนวคิดที่รู้จักกันดีที่สุดในการแก้ปัญหานี้ แทนที่จะมีโครงสร้างสเตตทรีหนึ่งโครงสร้างที่จัดเก็บทั้งสเตต เรามีรายการสเตตทรีที่เพิ่มมากขึ้น และการอ่านหรือเขียนสเตตใดๆ ก็ตามจะถูกบันทึกไว้ในโครงสร้างสเตตทรีล่าสุด โครงสร้างสเตตทรีว่างเปล่าใหม่จะถูกเพิ่มหนึ่งครั้งในทุกยุค (เช่น 1 ปี) โครงสร้างเก่าจะถูกหยุดการทำงานอย่างถาวร โหนดเต็มจะจัดเก็บเฉพาะสองโครงสร้างล่าสุดเท่านั้น หากวัตถุสถานะไม่ได้รับการสัมผัสในสองยุคและตกอยู่ในโครงสร้างที่หมดอายุ ก็ยังสามารถอ่านหรือเขียนได้ แต่ธุรกรรมจะต้องพิสูจน์การพิสูจน์ Merkle เมื่อพิสูจน์แล้ว สำเนาจะถูกบันทึกอีกครั้งในโครงสร้างล่าสุด
แนวคิดหลักที่ทำให้ผู้ใช้และนักพัฒนาเป็นมิตรต่อผู้ใช้คือแนวคิดของช่วงที่อยู่ ช่วงที่อยู่คือตัวเลขที่เป็นส่วนหนึ่งของที่อยู่ กฎหลักคือที่อยู่ที่มีช่วงที่อยู่ N สามารถอ่านจากหรือเขียนได้เฉพาะในช่วง N หรือหลังจากช่วง N เท่านั้น (กล่าวคือ เมื่อรายการโครงสร้างสถานะถึงความยาว N) หากคุณกำลังบันทึกวัตถุสถานะใหม่ (เช่น สัญญาใหม่หรือยอดคงเหลือ ERC 20 ใหม่) หากคุณแน่ใจว่าได้ใส่วัตถุสถานะลงในสัญญาที่มีช่วงที่อยู่ N หรือ N-1 คุณสามารถบันทึกได้ทันทีโดยไม่ต้องแสดงหลักฐานว่าไม่มีอะไรอยู่ก่อนหน้านั้น ในทางกลับกัน การเพิ่มหรือแก้ไขใดๆ ที่ทำในช่วงที่อยู่เดิมจะต้องมีการพิสูจน์
การออกแบบนี้ยังคงคุณสมบัติของ Ethereum ส่วนใหญ่ในปัจจุบันไว้ ไม่ต้องใช้การคำนวณเพิ่มเติม ช่วยให้เขียนแอปพลิเคชันได้เกือบเหมือนที่เป็นอยู่ในปัจจุบัน (ERC 20 จำเป็นต้องเขียนใหม่เพื่อให้แน่ใจว่ายอดคงเหลือของที่อยู่พร้อมวงจรที่อยู่ N จะถูกเก็บไว้ในสัญญาช่วงซึ่งมีวงจรที่อยู่ N ในตัว) และช่วยแก้ปัญหาผู้ใช้ในถ้ำเป็นเวลา 5 ปี อย่างไรก็ตาม มีปัญหาใหญ่ประการหนึ่งคือ จำเป็นต้องขยายที่อยู่ให้มากกว่า 20 ไบต์เพื่อรองรับวงจรที่อยู่
การขยายพื้นที่ที่อยู่
ข้อเสนอประการหนึ่งคือการแนะนำรูปแบบที่อยู่ 32 ไบต์ใหม่ซึ่งประกอบด้วยหมายเลขเวอร์ชัน หมายเลขรอบที่อยู่ และแฮชขยาย
0x 01 (แดง) 0000 (ส้ม) 000001 (เขียว) 57 เออี 408398 ดีเอฟ 7 อี 5 ฉ 4552091 เอ 69125 d5 FWF ฟ ... 7 บี 8 ซี 2659029395 bdF (สีน้ำเงิน)
หมายเลขสีแดงคือหมายเลขเวอร์ชัน เลขศูนย์สีส้มสี่ตัวในที่นี้มีไว้สำหรับเป็นช่องว่างที่สามารถรองรับหมายเลขชาร์ดในอนาคต หมายเลขสีเขียวคือหมายเลขรอบที่อยู่ หมายเลขสีน้ำเงินคือค่าแฮช 26 ไบต์
ความท้าทายสำคัญที่นี่คือความเข้ากันได้แบบย้อนหลัง สัญญาที่มีอยู่ได้รับการออกแบบโดยใช้ที่อยู่ขนาด 20 ไบต์ และมักใช้เทคนิคการแพ็คไบต์ที่เข้มงวดซึ่งถือว่าที่อยู่มีความยาว 20 ไบต์พอดี ความคิดหนึ่งที่จะแก้ไขปัญหานี้ เกี่ยวข้องกับการแมปการแปลง โดยสัญญาเก่าที่โต้ตอบกับที่อยู่รูปแบบใหม่จะเห็นแฮช 20 ไบต์ของที่อยู่รูปแบบใหม่ อย่างไรก็ตาม มีความซับซ้อนอย่างมากในการรับรองความปลอดภัย
การหดตัวของพื้นที่ที่อยู่
แนวทางอีกประการหนึ่งเป็นไปในทิศทางตรงกันข้าม: เราห้ามช่วงย่อยบางช่วงที่มีขนาด 2 128 ทันที (ตัวอย่างเช่น ที่อยู่ทั้งหมดเริ่มต้นด้วย 0x ffffffff ) จากนั้นจึงใช้ช่วงดังกล่าวเพื่อแนะนำที่อยู่ที่มีรอบที่อยู่และค่าแฮช 14 ไบต์
0x ฟฟฟฟฟฟ 000169125 d5 FWF ฟ ... 7 บี 8 C2659029395bdF
การเสียสละหลักที่เกิดจากแนวทางนี้คือ ความเสี่ยงด้านความปลอดภัยจากการแนะนำที่อยู่ที่ไม่เป็นความจริง : ที่อยู่ที่ถือครองทรัพย์สินหรือสิทธิ์การใช้งานแต่โค้ดยังไม่ได้เผยแพร่ไปยังเครือข่าย ความเสี่ยงนี้เกี่ยวข้องกับใครบางคนสร้างที่อยู่ที่อ้างว่าเป็นเจ้าของโค้ดบางส่วน (ที่ยังไม่ได้เผยแพร่) แต่มีโค้ดที่ถูกต้องอีกส่วนหนึ่งที่แฮชไปยังที่อยู่เดียวกัน การคำนวณการชนกันดังกล่าวในปัจจุบันต้องใช้แฮช 2 80 แฮช การหดตัวของพื้นที่ที่อยู่จะลดจำนวนนี้ลงเหลือ 2 56 แฮชที่เข้าถึงได้ง่าย
พื้นที่เสี่ยงสำคัญซึ่งเป็นที่อยู่ที่ไม่เป็นจริงสำหรับกระเป๋าเงินที่ไม่ได้ถือครองโดยเจ้าของคนเดียวนั้นค่อนข้างหายากในปัจจุบัน แต่มีแนวโน้มว่าจะกลายเป็นเรื่องธรรมดามากขึ้นเมื่อเราเข้าสู่โลกที่มี L2 หลายระดับ วิธีแก้ปัญหาเพียงทางเดียวคือยอมรับความเสี่ยงนี้ แต่ระบุกรณีการใช้งานทั่วไปทั้งหมดที่อาจผิดพลาด และคิดหาแนวทางแก้ไขที่มีประสิทธิภาพ
มีความเชื่อมโยงกับงานวิจัยที่มีอยู่อย่างไร?
ข้อเสนอเบื้องต้น
ข้อเสนอการหมดอายุสถานะบางส่วน
เอกสารประกอบการขยายพื้นที่ที่อยู่
ต้องทำอะไรอีกและต้องแลกเปลี่ยนสิ่งใด?
ฉันเห็นเส้นทางที่เป็นไปได้สี่ทางไปข้างหน้า:
-
เราทำให้มันไร้สถานะและไม่เคยแนะนำให้มีการหมดอายุของสถานะ สถานะกำลังเติบโต (แม้ว่าจะช้า: เราคงจะไม่เห็นมันเกิน 8 TB เป็นเวลาหลายทศวรรษ) แต่โดยผู้ใช้กลุ่มพิเศษเท่านั้น: แม้แต่ผู้ตรวจสอบ PoS ก็ไม่ต้องการสถานะ
คุณลักษณะหนึ่งที่ต้องเข้าถึงส่วนหนึ่งของสถานะคือการสร้างรายการรวม แต่เราสามารถทำได้ในลักษณะกระจายอำนาจ: ผู้ใช้แต่ละคนต้องรับผิดชอบในการดูแลส่วนของสถานะที่ประกอบด้วยบัญชีของตนเอง เมื่อผู้ใช้ออกอากาศธุรกรรม พวกเขาจะออกอากาศธุรกรรมนั้นพร้อมกับหลักฐานของวัตถุสถานะที่เข้าถึงได้ระหว่างขั้นตอนการยืนยัน (วิธีนี้ใช้ได้กับทั้งบัญชี EOA และ ERC-4337) จากนั้นผู้ตรวจสอบที่ไม่มีสถานะสามารถรวมหลักฐานเหล่านี้เข้าด้วยกันเพื่อพิสูจน์รายการรวมทั้งหมด -
เราดำเนินการหมดอายุสถานะบางส่วนและยอมรับอัตราการเติบโตขนาดสถานะถาวรที่ต่ำกว่ามากแต่ยังไม่เป็นศูนย์ ผลลัพธ์นี้อาจคล้ายคลึงกับข้อเสนอการหมดอายุประวัติที่เกี่ยวข้องกับเครือข่ายเพียร์ทูเพียร์ที่ยอมรับอัตราการเติบโตการจัดเก็บประวัติถาวรที่ต่ำกว่ามากแต่ยังไม่เป็นศูนย์ โดยที่ไคลเอนต์แต่ละรายต้องจัดเก็บข้อมูลประวัติในเปอร์เซ็นต์ที่ต่ำกว่าแต่คงที่
-
เรากำลังดำเนินการหมดอายุสถานะผ่านส่วนขยายของพื้นที่ที่อยู่ ซึ่งจะต้องมีกระบวนการหลายปีเพื่อให้แน่ใจว่าวิธีการแปลงรูปแบบที่อยู่จะมีประสิทธิภาพและปลอดภัย รวมถึงสำหรับแอปพลิเคชันที่มีอยู่
-
เราดำเนินการทำให้สถานะหมดอายุโดยการลดขนาดพื้นที่ที่อยู่ ซึ่งจะต้องมีกระบวนการหลายปีเพื่อให้แน่ใจว่าความเสี่ยงด้านความปลอดภัยทั้งหมดที่เกี่ยวข้องกับความขัดแย้งของที่อยู่ (รวมถึงสถานการณ์ข้ามเครือข่าย) ได้รับการจัดการ
ประเด็นสำคัญคือไม่ว่าจะนำแผนการหมดอายุสถานะที่อาศัยการเปลี่ยนแปลงรูปแบบที่อยู่ไปใช้หรือไม่ก็ตาม ปัญหาที่ยากของการขยายและหดตัวของพื้นที่ที่อยู่จะต้องได้รับการแก้ไขในที่สุด ปัจจุบัน การสร้างการชนกันของที่อยู่ต้องใช้แฮชประมาณ 280 รายการ และภาระในการคำนวณนี้สามารถทำได้แล้วสำหรับผู้ดำเนินการที่มีทรัพยากรมาก: GPU สามารถดำเนินการแฮชได้ประมาณ 227 รายการ ดังนั้นจึงสามารถคำนวณได้ 252 รายการในหนึ่งปี ดังนั้นทั้งหมด ประมาณ 2 30 GPU ในโลก สามารถคำนวณการชนกันได้ในเวลาประมาณ 1/4 ปี และ FPGA และ ASIC สามารถเร่งกระบวนการนี้ให้เร็วขึ้นได้ ในอนาคต การโจมตีดังกล่าวจะเปิดรับผู้คนมากขึ้นเรื่อยๆ ดังนั้น ต้นทุนจริงในการดำเนินการหมดอายุสถานะเต็มรูปแบบอาจไม่สูงเท่าที่คิด เนื่องจากเราต้องแก้ปัญหาที่อยู่อันท้าทายนี้อยู่ดี
มันจะโต้ตอบกับแผนงานส่วนที่เหลืออย่างไร?
การทำการหมดอายุของสถานะอาจทำให้การเปลี่ยนจากรูปแบบ trie ของสถานะหนึ่งไปเป็นอีกรูปแบบหนึ่งง่ายขึ้น เนื่องจากไม่จำเป็นต้องมีกระบวนการแปลงใดๆ คุณเพียงแค่เริ่มสร้างแผนภูมิใหม่ด้วยรูปแบบใหม่ จากนั้นจึงทำการฮาร์ดฟอร์กเพื่อแปลงแผนภูมิเดิม ดังนั้น แม้ว่าการหมดอายุของสถานะจะมีความซับซ้อน แต่ก็มีข้อดีในการทำให้ส่วนอื่นๆ ของแผนงานง่ายขึ้น
การล้างคุณสมบัติ
มันช่วยแก้ปัญหาอะไรได้บ้าง?
ข้อกำหนดเบื้องต้นที่สำคัญประการหนึ่งสำหรับ ความปลอดภัย การเข้าถึง และ ความเป็นกลางที่เชื่อถือได้ คือความเรียบง่าย หากโปรโตคอลสวยงามและเรียบง่าย ก็มีโอกาสเกิดจุดบกพร่องน้อยลง เพิ่มโอกาสที่นักพัฒนาใหม่จะมีส่วนร่วมในส่วนใดส่วนหนึ่งของโปรโตคอลได้ โปรโตคอลจะยุติธรรมและป้องกันผลประโยชน์พิเศษได้ง่ายขึ้น น่าเสียดายที่โปรโตคอลก็เหมือนกับระบบโซเชียลอื่นๆ ที่จะซับซ้อนมากขึ้นตามกาลเวลา หากเราไม่ต้องการให้ Ethereum ตกลงไปในหลุมดำแห่งความซับซ้อนที่เพิ่มมากขึ้น เราต้องทำอย่างใดอย่างหนึ่งจากสองสิ่งนี้: (i) หยุดทำการเปลี่ยนแปลงและทำให้โปรโตคอลไม่เสถียร หรือ (ii) สามารถลบฟีเจอร์ต่างๆ และลดความซับซ้อนลงได้จริง นอกจากนี้ ยังมีแนวทางสายกลางอีกด้วย โดยทำการเปลี่ยนแปลงโปรโตคอลให้น้อยลงและลบความซับซ้อนออกไปอย่างน้อยสักเล็กน้อยเมื่อเวลาผ่านไป หัวข้อนี้จะอธิบายวิธีการลดหรือขจัดความซับซ้อน
มันคืออะไรและทำงานอย่างไร?
ไม่มีวิธีแก้ไขหลักๆ ที่จะช่วยลดความซับซ้อนของโปรโตคอลได้ ปัญหามีอยู่ที่วิธีแก้ไขเล็กๆ น้อยๆ มากมาย
ตัวอย่างหนึ่งที่เกือบจะเสร็จสมบูรณ์แล้ว และสามารถใช้เป็นต้นแบบสำหรับวิธีดำเนินการตัวอย่างอื่นๆ ได้คือ การลบ opcode SELFDESTRUCT โอปโค้ด SELFDESTRUCT เป็นโอปโค้ดเพียงตัวเดียวที่สามารถปรับเปลี่ยนช่องเก็บข้อมูลจำนวนไม่จำกัดภายในบล็อกเดียว ทำให้ไคลเอนต์ต้องใช้ความซับซ้อนมากขึ้นอย่างมากเพื่อหลีกเลี่ยงการโจมตีแบบ DoS จุดประสงค์เดิมของโอปโค้ดคือเพื่อให้สามารถทำการล้างสถานะโดยสมัครใจ ทำให้ขนาดสถานะลดลงเมื่อเวลาผ่านไป ในทางปฏิบัติ มีคนเพียงไม่กี่คนที่ใช้มัน โอปโค้ดถูกลดประสิทธิภาพลง อนุญาตให้สร้างบัญชีที่ทำลายตัวเองได้เฉพาะในธุรกรรมเดียวกันกับฮาร์ดฟอร์กของ Dencun เท่านั้น ซึ่งจะช่วยแก้ปัญหา DoS และทำให้โค้ดไคลเอนต์ง่ายขึ้นอย่างมาก ในอนาคต อาจมีเหตุผลที่จะลบโอปโค้ดทั้งหมดในที่สุด
ตัวอย่างสำคัญบางส่วนของโอกาสในการลดความซับซ้อนของโปรโตคอลที่ระบุจนถึงปัจจุบัน ได้แก่ ต่อไปนี้ ประการแรก ตัวอย่างบางส่วนที่อยู่นอก EVM ตัวอย่างเหล่านี้ค่อนข้างไม่รุกรานและจึงบรรลุฉันทามติได้ง่ายกว่าและนำไปใช้ได้ในเวลาอันสั้นกว่า
-
การแปลง RLP → SSZ: เดิมที วัตถุ Ethereum จะถูกแปลงเป็นอนุกรมโดยใช้การเข้ารหัสที่เรียกว่า อาร์แอลพี RLP ไม่มีการกำหนดประเภทและซับซ้อนโดยไม่จำเป็น ปัจจุบัน บีคอนเชนใช้ สซซ. ซึ่งดีขึ้นอย่างเห็นได้ชัดในหลายๆ ด้าน รวมถึงรองรับไม่เพียงแค่การทำซีเรียลไลเซชันเท่านั้น แต่ยังรวมถึงการแฮชด้วย ในที่สุด เราหวังว่าจะกำจัด RLP ออกไปได้หมดและย้ายประเภทข้อมูลทั้งหมดไปยังโครงสร้าง SSZ ซึ่งจะทำให้การอัปเกรดง่ายขึ้นมาก EIP ในปัจจุบันประกอบด้วย [1] [2] [3] .
-
การลบประเภทธุรกรรมเก่า: ปัจจุบันมีประเภทธุรกรรมมากเกินไป และหลายประเภทอาจถูกลบออกได้ ทางเลือกอื่นที่ง่ายกว่าในการลบออกทั้งหมดคือฟีเจอร์การแยกบัญชี โดยที่บัญชีอัจฉริยะสามารถมีโค้ดสำหรับจัดการและตรวจสอบธุรกรรมเก่าได้หากต้องการ
-
การปฏิรูป LOG: ฟิลเตอร์การสร้างบันทึกและตรรกะอื่นๆ เพิ่มความซับซ้อนให้กับโปรโตคอล แต่ไคลเอนต์ไม่ได้ใช้จริงเนื่องจากช้าเกินไป เราสามารถ ลบคุณสมบัติเหล่านี้ออกไป และทำงานกับทางเลือกอื่น เช่น เครื่องมืออ่านบันทึกแบบกระจายอำนาจนอกโปรโตคอลโดยใช้เทคโนโลยีสมัยใหม่ เช่น SNARKs
-
ท้ายที่สุดต้องลบกลไก Beacon Chain Sync Committee ออกไป: กลไกของคณะกรรมการการซิงค์ เดิมทีมีการแนะนำเพื่อเปิดใช้งานการตรวจสอบไคลเอนต์แบบเบาสำหรับ Ethereum อย่างไรก็ตาม มันเพิ่มความซับซ้อนของโปรโตคอลอย่างมาก ในที่สุดเราจะสามารถทำได้ ตรวจสอบเลเยอร์ฉันทามติ Ethereum โดยตรงโดยใช้ SNARKs ซึ่งจะช่วยลดความจำเป็นในการใช้โปรโตคอลการตรวจสอบไคลเอนต์แบบไลท์โดยเฉพาะ การเปลี่ยนแปลงตามฉันทามติอาจทำให้เราสามารถลบ Sync Committee ได้เร็วขึ้นโดยการสร้างโปรโตคอลไคลเอนต์แบบไลท์ดั้งเดิมมากขึ้นซึ่งเกี่ยวข้องกับการตรวจสอบลายเซ็นจากกลุ่มย่อยแบบสุ่มของผู้ตรวจสอบฉันทามติของ Ethereum
-
การรวมรูปแบบข้อมูล: ปัจจุบัน สถานะการดำเนินการจะถูกเก็บไว้ในต้นไม้ Merkle Patricia สถานะฉันทามติจะถูกเก็บไว้ใน ต้นไม้ SSZ และ blobs จะถูกคอมมิตผ่าน พันธสัญญาของ KZG ในอนาคต การมีรูปแบบรวมเดียวสำหรับข้อมูลแบบบล็อกและรูปแบบรวมเดียวสำหรับสถานะจะเป็นสิ่งที่สมเหตุสมผล รูปแบบเหล่านี้จะตอบสนองความต้องการที่สำคัญทั้งหมด: (i) การพิสูจน์แบบง่ายสำหรับไคลเอนต์ที่ไม่มีสถานะ (ii) การเข้ารหัสแบบอนุกรมและการลบข้อมูล และ (iii) โครงสร้างข้อมูลมาตรฐาน
-
การถอด Beacon Chain Committee: กลไกนี้ถูกนำมาใช้ครั้งแรกเพื่อสนับสนุน เวอร์ชันเฉพาะของการแบ่งส่วนการดำเนินการ . แทนที่เราจะลงเอยด้วยการแยกชิ้นส่วน ผ่าน L2 และ blobs . ดังนั้นคณะกรรมการจึงไม่จำเป็น กำลังมีการเคลื่อนไหวเพื่อขจัดมันออกไป .
-
กำจัดเอนเดียนแบบผสม: EVM คือบิ๊กเอนเดียน ส่วนเลเยอร์คอนเซนซัสคือลิตเทิลเอนเดียน อาจสมเหตุสมผลที่จะปรับทุกอย่างให้สอดคล้องกัน (อาจเป็นบิ๊กเอนเดียน เนื่องจาก EVM เปลี่ยนแปลงได้ยากกว่า)
ตัวอย่างบางส่วนใน EVM:
-
การลดความซับซ้อนของกลไกแก๊ส: กฎแก๊สปัจจุบันยังไม่ได้รับการปรับให้เหมาะสมเพื่อให้มีขีดจำกัดที่ชัดเจนเกี่ยวกับจำนวนทรัพยากรที่จำเป็นในการตรวจสอบบล็อก ตัวอย่างที่สำคัญ ได้แก่ (i) ต้นทุนการอ่าน/เขียนที่เก็บข้อมูล ซึ่งมีวัตถุประสงค์เพื่อจำกัดจำนวนการอ่าน/เขียนในบล็อก แต่ปัจจุบันค่อนข้างไม่แน่นอน และ (ii) กฎการแพดหน่วยความจำ ซึ่งปัจจุบันยากที่จะประมาณการใช้หน่วยความจำสูงสุดของ EVM การแก้ไขที่เสนอ ได้แก่ การเปลี่ยนแปลงต้นทุนก๊าซแบบไร้รัฐ (ซึ่งรวมต้นทุนที่เกี่ยวข้องกับการจัดเก็บทั้งหมดไว้ในสูตรที่เรียบง่าย) และ ข้อเสนอราคาหน่วยความจำ .
-
การลบการคอมไพล์ล่วงหน้า: การคอมไพล์ล่วงหน้าจำนวนมากที่ Ethereum มีอยู่ในปัจจุบันนั้นมีความซับซ้อนโดยไม่จำเป็นและไม่ค่อยได้ใช้งาน และเป็นสาเหตุหลักของความล้มเหลวในการบรรลุฉันทามติจำนวนมากเมื่อแทบไม่มีแอปพลิเคชันใด ๆ ใช้งานเลย มีสองวิธีในการจัดการกับปัญหานี้คือ (i) เพียงแค่ลบการคอมไพล์ล่วงหน้า และ (ii) แทนที่ด้วยโค้ด EVM (ซึ่งมีราคาแพงกว่าอย่างหลีกเลี่ยงไม่ได้) ที่ใช้ตรรกะเดียวกัน ร่าง EIP นี้เสนอ เพื่อดำเนินการนี้สำหรับการคอมไพล์ล่วงหน้าเพื่อระบุตัวตนเป็นขั้นตอนแรก ในภายหลัง RIPEMD 160, MODEXP และ BLAKE อาจกลายเป็นตัวเลือกสำหรับการลบออก
-
ลบการสังเกตก๊าซ: ทำให้การดำเนินการ EVM ไม่สามารถดูปริมาณก๊าซที่เหลืออยู่ได้อีกต่อไป ซึ่งจะทำให้แอปพลิเคชันบางส่วนเสียหาย (โดยเฉพาะอย่างยิ่งธุรกรรมที่ได้รับการสนับสนุน) แต่จะทำให้การอัปเกรดในอนาคตง่ายขึ้น (เช่น เป็นเวอร์ชันขั้นสูงที่มี ก๊าซหลายมิติ ). ข้อมูลจำเพาะ EOF ทำให้ก๊าซไม่สามารถสังเกตได้อยู่แล้ว แต่เพื่อลดความซับซ้อนของโปรโตคอล จำเป็นต้องบังคับใช้ EOF
-
การปรับปรุงการวิเคราะห์แบบคงที่: ในปัจจุบัน การวิเคราะห์แบบคงที่ของโค้ด EVM เป็นเรื่องยาก โดยเฉพาะอย่างยิ่งเนื่องจากการกระโดดอาจเป็นแบบไดนามิก นอกจากนี้ยังทำให้การปรับให้เหมาะสมในการใช้งาน EVM (การคอมไพล์โค้ด EVM ล่วงหน้าเป็นภาษาอื่น) ยากขึ้นอีกด้วย เราสามารถแก้ไขได้โดย การลบการกระโดดแบบไดนามิก (หรือทำให้มีราคาแพงขึ้น เช่น ต้นทุนก๊าซเชิงเส้นของจำนวน JUMPDEST ทั้งหมดในสัญญา) EOF ทำเช่นนั้น แม้ว่าการบังคับใช้ EOF จะเป็นสิ่งจำเป็นเพื่อให้ได้รับประโยชน์จากการลดความซับซ้อนของโปรโตคอลก็ตาม
มีความเชื่อมโยงกับงานวิจัยที่มีอยู่อย่างไร?
-
วิธีการสำหรับการดึงข้อมูลบันทึกที่ปลอดภัยนอกเครือข่ายโดยใช้การคำนวณที่ตรวจสอบได้แบบเพิ่มหน่วย (อ่าน: STARKs แบบเรียกซ้ำ)
ต้องทำอะไรอีกและต้องแลกเปลี่ยนสิ่งใด?
การแลกเปลี่ยนหลักในการทำการลดความซับซ้อนของฟีเจอร์ประเภทนี้คือ (i) เราลดความซับซ้อนได้มากเพียงใดและรวดเร็วเพียงใด เมื่อเทียบกับ (ii) ความเข้ากันได้แบบย้อนหลัง มูลค่าของ Ethereum ในฐานะเชนมาจากการเป็นแพลตฟอร์มที่คุณสามารถปรับใช้แอปพลิเคชันและมั่นใจได้ว่าจะยังทำงานได้หลายปีหลังจากนั้น ในขณะเดียวกัน อุดมคตินี้ก็อาจถูกนำไปใช้มากเกินไปได้เช่นกัน ตามคำพูดของวิลเลียม เจนนิงส์ ไบรอัน “ตรึง Ethereum ไว้กับมาตรฐานความเข้ากันได้แบบย้อนหลัง” หากมีเพียงสองแอปพลิเคชันใน Ethereum ทั้งหมดที่ใช้ฟีเจอร์ที่กำหนด และแอปพลิเคชันหนึ่งไม่มีผู้ใช้เลยเป็นเวลาหลายปี ในขณะที่แอปพลิเคชันอื่นแทบไม่ได้ใช้งานเลยและมีมูลค่าเพิ่มขึ้นทั้งหมด $57 ดังนั้นเราจึงควรลบฟีเจอร์นั้นและจ่ายเงิน $57 ให้กับเหยื่อจากกระเป๋าของตัวเองหากจำเป็น
ปัญหาสังคมโดยรวมคือการสร้างมาตรฐานสำหรับการเปลี่ยนแปลงที่ไม่เร่งด่วนและทำลายความเข้ากันได้แบบย้อนหลัง วิธีหนึ่งในการแก้ไขปัญหานี้คือการตรวจสอบและขยายขอบเขตของบรรทัดฐานที่มีอยู่ เช่น กระบวนการทำลายตัวเอง โดยขั้นตอนดังกล่าวจะมีลักษณะดังต่อไปนี้:
-
เริ่มพูดคุยเกี่ยวกับการลบคุณสมบัติ X;
-
ดำเนินการวิเคราะห์เพื่อพิจารณาผลกระทบของการลบ X ออกจากแอปพลิเคชัน และขึ้นอยู่กับผลลัพธ์: (i) ล้มเลิกแนวคิด (ii) ดำเนินการตามแผน หรือ (iii) กำหนดแนวทาง "ก่อกวนน้อยที่สุด" ที่แก้ไขใหม่ในการลบ X และดำเนินการต่อ
-
สร้าง EIP อย่างเป็นทางการเพื่อเลิกใช้ X ตรวจสอบให้แน่ใจว่าโครงสร้างพื้นฐานระดับสูงที่เป็นที่นิยม (เช่น ภาษาโปรแกรม กระเป๋าสตางค์) เคารพสิ่งนี้และหยุดใช้ฟีเจอร์นี้
-
สุดท้ายก็ลบ X จริงๆ
ควรมีขั้นตอนหลายปีระหว่างขั้นตอนที่ 1 และ 4 พร้อมการระบุอย่างชัดเจนว่าโครงการใดอยู่ในขั้นตอนใด ณ จุดนี้ มีการแลกเปลี่ยนระหว่างความเข้มแข็งและความรวดเร็วของกระบวนการลบฟีเจอร์กับความอนุรักษ์นิยมมากกว่าและลงทุนทรัพยากรมากขึ้นในด้านอื่นๆ ของการพัฒนาโปรโตคอล แต่เรายังห่างไกลจากแนวหน้าของ Pareto มาก
อีโอเอฟ
ชุดการเปลี่ยนแปลงหลักที่เสนอให้กับ EVM คือ รูปแบบวัตถุ EVM (EOF) EOF นำเสนอการเปลี่ยนแปลงมากมาย เช่น การปิดการสังเกตแก๊ส การสังเกตโค้ด (กล่าวคือ ไม่มี CODECOPY) และอนุญาตเฉพาะการกระโดดแบบคงที่เท่านั้น เป้าหมายคือเพื่อให้ EVM สามารถอัปเกรดได้มากขึ้นในลักษณะที่มีคุณสมบัติที่แข็งแกร่งขึ้นในขณะที่ยังคงความเข้ากันได้แบบย้อนหลัง (เนื่องจาก EVM ก่อน EOF ยังคงมีอยู่)
ข้อดีของวิธีนี้คือจะสร้างเส้นทางธรรมชาติสำหรับการเพิ่มฟีเจอร์ EVM ใหม่ๆ และสนับสนุนการโยกย้ายไปยัง EVM ที่เข้มงวดยิ่งขึ้นพร้อมการรับประกันที่เข้มงวดยิ่งขึ้น ข้อเสียคือจะเพิ่มความซับซ้อนของโปรโตคอลอย่างมาก เว้นแต่ว่าเราจะหาวิธีเลิกใช้และลบ EVM เก่าในที่สุด คำถามสำคัญคือ EOF มีบทบาทอย่างไรในข้อเสนอการลดความซับซ้อนของ EVM โดยเฉพาะอย่างยิ่งหากเป้าหมายคือการลดความซับซ้อนของ EVM ทั้งหมด
มันจะโต้ตอบกับแผนงานส่วนที่เหลืออย่างไร?
ข้อเสนอแนะในการปรับปรุงหลายๆ ข้อในแผนงานที่เหลือยังเป็นโอกาสในการลดความซับซ้อนของฟีเจอร์เก่าๆ อีกด้วย หากต้องการทำซ้ำตัวอย่างบางส่วนข้างต้น:
-
การเปลี่ยนไปใช้ระบบ single-slot finality ทำให้เราสามารถลบคณะกรรมการ ออกแบบเศรษฐศาสตร์ใหม่ และทำการลดความซับซ้อนอื่นๆ ที่เกี่ยวข้องกับการพิสูจน์การถือครอง
-
การนำการแยกบัญชีไปใช้อย่างเต็มรูปแบบจะทำให้เราสามารถลบตรรกะการประมวลผลธุรกรรมที่มีอยู่จำนวนมากออก และย้ายไปไว้ใน "โค้ด EVM บัญชีเริ่มต้น" ที่ EOA ทั้งหมดสามารถแทนที่ได้
-
หากเราย้ายสถานะของ Ethereum ไปที่ไบนารีแฮชทรี การเปลี่ยนแปลงนี้จะสอดคล้องกับ SSZ เวอร์ชันใหม่ เพื่อให้สามารถแฮชโครงสร้างข้อมูล Ethereum ทั้งหมดได้ในลักษณะเดียวกัน
แนวทางที่รุนแรงยิ่งขึ้น: การแปลงส่วนใหญ่ของโปรโตคอลเป็นโค้ดสัญญา
กลยุทธ์ที่รุนแรงกว่าในการทำให้ Ethereum เรียบง่ายลงคือการรักษาโปรโตคอลให้เหมือนเดิมแต่ย้ายโปรโตคอลส่วนใหญ่ออกจากฟังก์ชันการทำงานของโปรโตคอลและไปที่โค้ดสัญญา
เวอร์ชันที่รุนแรงที่สุดคือการมี Ethereum L1 "ทางเทคนิค" เป็นเพียงบีคอนเชน และแนะนำเครื่องเสมือนขั้นต่ำ (เช่น ริสค์-วี , ไคโร หรือบางอย่างที่น้อยที่สุดโดยเฉพาะสำหรับระบบพิสูจน์) ซึ่งช่วยให้ผู้อื่นสามารถสร้างการสรุปข้อมูลของตนเองได้ จากนั้น EVM จะกลายเป็นการสรุปข้อมูลชุดแรก ซึ่งถือเป็นผลลัพธ์เดียวกันกับ ข้อเสนอสภาพแวดล้อมการดำเนินการปี 2019-20 แม้ว่า SNARK จะทำให้การใช้งานจริงเป็นไปได้มากขึ้นก็ตาม
แนวทางที่สุภาพกว่าคือการรักษาความสัมพันธ์ระหว่างบีคอนเชนและสภาพแวดล้อมการดำเนินการ Ethereum ปัจจุบันไว้โดยไม่เปลี่ยนแปลง แต่สลับ EVM ในตำแหน่งเดิม เราสามารถเลือก RISC-V, Cairo หรือ VM อื่นเป็น VM Ethereum อย่างเป็นทางการใหม่ จากนั้นจึงบังคับให้สัญญา EVM ทั้งหมดถูกแปลงเป็นโค้ด VM ใหม่ที่ตีความตรรกะของโค้ดต้นฉบับ (ไม่ว่าจะโดยการคอมไพล์หรือการตีความ) ในทางทฤษฎี การทำเช่นนี้สามารถทำได้แม้กับเครื่องเสมือนเป้าหมายที่เป็นเวอร์ชันของ EOF
บทความนี้มีที่มาจากอินเทอร์เน็ต: บทความใหม่ของ Vitalik: อนาคตที่เป็นไปได้ของ Ethereum (V) — The Purge