ขอบคุณพิเด, แดโน เฟอริน, จัสติน ดราก, ลาดิสลาส, และทิม เบย์โก สำหรับคำติชมและการทบทวนของพวกเขา

เป้าหมายของ Ethereum คือการเป็นสมุดบัญชีระดับโลก - แพลตฟอร์มที่บรรลุทรัพย์ของมนุษย์และบันทึกข้อมูล และเป็นชั้นฐานสำหรับแอปพลิเคชันเช่นการเงิน การปกครอง และการยืนยันข้อมูลมูลค่าสูง เพื่อที่จะบรรลุเป้าหมายนี้ มันต้องมีการขยายขอบเขตและความทนทาน Fusaka แผนการ hard fork จะเพิ่มพื้นที่ให้บริการข้อมูล L2 ได้ 10 เท่า ในขณะที่โครงการแผนเส้นทางปี 2026 ที่เสนอรวมถึงมาตราส่วนที่เหมือนกันของการขยายข้อมูล L1 เช่นกัน ในระหว่างนี้ 'การผสาน' ได้ทำการอัปเกรด Ethereum เป็นกลไกความเห็นร่วมแบบพิส (PoS)ความหลากหลายของลูกค้าเพิ่มขึ้นอย่างรวดเร็ว, ZK (Zero-Knowledge Proof) และความสามารถในการตรวจสอบและความต้านทานต่อการโจมตีด้านควอนตัมก็ก้าวหน้าอย่างต่อเนื่อง และระบบนิเวศแอปพลิเคชั่นก็เพิ่มขึ้นสมบูรณ์และแข็งแรง.

วัตถุประสงค์ของบทความนี้คือการเน้นความสำคัญอย่างเท่าเทียม แต่มักถูกประเมินค่าน้อยความยืดหยุ่น (และในที่สุดยืดหยุ่น)Elements:
ความง่ายของโปรโตคอล

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

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

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

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

In the past, Ethereum has not performed well in this regard (sometimes even because of my personal decisions), which has led to our excessive development expenses,@vbuterin/selfdestruct”>Various security risks and the closed nature of R&D culture, and these efforts often only bring illusory returns.
บทความนี้จะอธิบายว่า Ethereum สามารถบรรลุระดับความง่ายเท่ากับ Bitcoin ในอีกห้าปี

เลเยอร์ความเห็นที่เรียบง่าย

3-slot finality（3槽终结性）模拟图 — 3sf-mini

การออกแบบชั้นความเห็นใหม่ (ที่เคยเรียกว่า ‘beam chain’) มีเป้าหมายที่จะผสานประสบการณ์ที่เราได้รวบรวมไว้ในทฤษฎีความเห็น ZK-SNARK การพัฒนา staking economics และพื้นที่อื่นๆ ในช่วงสิบปีที่ผ่านมาเพื่อสร้างชั้นความเห็น Ethereum ที่แม่นยำในระยะยาว ชั้นความเห็นใหม่นี้เปรียบเทียบกับ Beacon Chain ที่มีอยู่ คาดว่าจะบรรลุความง่ายดายสูงขึ้น สิ่งนี้เป็นเฉพาะอย่างยิ่งใน:

• 3-slot finality restructure
  การออกแบบนี้กำจัดความแตกต่างระหว่าง 'ช่อง' และ 'ยุค' การสลับคณะ และรายละเอียดของโปรโตคอลที่เกี่ยวข้องกับกลไกเหล่านี้ (เช่น คณะที่เป็นเข้ม) เวอร์ชันพื้นฐานของการเสร็จสิ้นในช่อง 3ต้องใช้โค้ดประมาณ 200 บรรทัดเท่านั้นสามารถทำได้ เมื่อเปรียบเทียบกับโปรโตคอล Gasper ปัจจุบัน การชนะ 3 สล็อตยังมีความปลอดภัยใกล้เคียงกับระดับสูงสุด
• จำนวนผู้ตรวจสอบที่ใช้งานอยู่ลดลง
  ทำให้การนำมาใช้กฎการเลือก Fork ที่ง่ายขึ้นและเป็นไปได้มากขึ้น
• โปรโตคอลการรวมรวมที่ขึ้นอยู่กับ STARK
  หมายถึงว่าใครก็สามารถกลายเป็นผู้รวบรวมโดยไม่ต้องกังวลเรื่องความน่าเชื่อถือของผู้รวบรวม ค่าธรรมเนียมที่มากเกินไปสำหรับช่องความสามารถที่ซ้ำซ้อน เป็นต้น แม้ว่าการเข้ารหัสการรวบรวมเองมีความซับซ้อนบางประการ นี้ความซับซ้อนที่ถูกห่อหุ้มอย่างสูงความเสี่ยงระบบโดยรวมของโปรโตคอลมีระดับต่ำมาก
• จุดสองข้างต้นนั้นยังเป็นไปได้ที่จะสนับสนุนโครงสร้างพีอีร์ทูพีร์ (p2p) ที่เรียบง่ายและทนทานมากขึ้น
• เรามีโอกาสที่จะทบทวนกลไกการเข้าร่วมของผู้ตรวจสอบ การออก การถอนเงิน การสลับคีย์ การลงโทษความเฉื่อย ฯลฯ และทำให้ง่ายขึ้น ไม่ใช่เพียงลดจำนวนบรรทัดของโค้ด (LoC) เท่านั้น แต่ยังให้ความมั่นใจในกลไกที่ชัดเจนมากขึ้น เช่น เส้นหลัก 'weak subjectivity' ที่ชัดเจนมากยิ่งขึ้น

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

Simplify Execution Layer

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

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

ดังนั้น ในฐานะทางเลือก ของฉันเสนอแนะไอเดียที่เปลี่ยนแปลงมากขึ้น: แทนที่จะทำการเปลี่ยนแปลงเชิงขั้นต่ำ (แต่ยังทำให้เกิดความเสียหาย) เพื่อการปรับปรุงที่เพิ่มขึ้น 1.5 เท่า มันดีกว่าที่จะย้ายไปสู่เครื่องจำลองเสมือนใหม่ที่ดีมากและง่ายขึ้น โดยมีเป้าหมายที่จะได้รับผลตอบแทน 100 เท่า อย่างที่ ‘การผสาน’ ที่เราลดจำนวนการเปลี่ยนแปลง แต่ละอย่างมีความสำคัญ โดยเฉพาะอย่างยิ่ง ฉันขอเสนอแนะที่จะแทนที่ EVM ที่มีอยู่ด้วย RISC-V (หรือเครื่องจำลองเสมือนอื่นที่จะถูกใช้โดย ZK prover ของ Ethereum) แนวทางนี้ เราจะบรรลุเป้าหมายดังนี้:

• ปรับปรุงความสามารถในการดำเนินงานอย่างมีประสิทธิภาพ: เนื่องจากสมาร์ทคอนแทร็คสามารถทำงานโดยตรงในตัวพิสูจน์ได้โดยไม่มีภาระของตัวแปลคำสั่ง ข้อมูลที่กระชับแสดงให้เห็นว่าประสิทธิภาพสามารถปรับปรุงได้มากกว่า 100 เท่าในสถานการณ์มากมาย
• ความง่ายสุด ๆ: เมื่อเปรียบเทียบกับ EVM มาตรฐาน RISC-Vง่ายมาก. วิธีการทางเลือกอื่น ๆ (เช่น ไคโร) เป็นอย่างสมบูรณ์เท่าเท่ากัน
• สืบทอดคุณสมบัติที่คาดหวังของ EOF: เช่น การแบ่งโค้ด การวิเคราะห์สถิติที่เป็นมิตรมากขึ้น ขีดจำกัดความจุโค้ดที่ใหญ่ขึ้น เป็นต้น
• นักพัฒนามีตัวเลือกมากขึ้น: Solidity และ Vyper สามารถคอมไพล์เป็น backend เครื่องจำลองใหม่ หากเลือกใช้ RISC-V นักพัฒนาภาษาสากลยักษ์ยากสามารถย้ายโค้ดของพวกเขาได้อย่างง่ายดายเช่นกัน
• ลดความต้องการในการคอมไพล์ล่วงหน้าอย่างมีนัยสำคัญ: อาจจะยังคงเก็บไว้เพียงไม่กี่ดำเนินการวงรีลิปส์ที่ถูกปรับแต่งอย่างสูง (อย่างไรก็ตามจะไม่มีอีกต่อไปเมื่อคอมพิวเตอร์โควนตัมกลายเป็นที่นิยม)

ข้อเสียหลักของวิธีการนี้คือ ไม่เหมือนกับ EOF (ที่สามารถนำไปใช้ได้ทันที) เครื่องจำลองเสมือนใหม่จะใช้เวลานานกว่าเพื่อประโยชน์แก่นักพัฒนา โดยการลดผลกระทบนี้ เราสามารถนำเสนอการปรับปรุง EVM ขนาดเล็กแต่มีค่ามากในช่วงระยะเวลาสั้นเพิ่มขีดจำกัดขนาดโค้ดสัญญาเพิ่มคำสั่ง DUP/SWAP17-32 ฯลฯ

ในที่สุดนี่จะให้เรามีเครื่องจำลองเสมือนที่เรียบง่ายมาก แต่คำถามที่สำคัญที่สิ่งที่เกี่ยวกับ EVM ที่มีอยู่เดิม?

กลยุทธ์ความเข้ากันได้ย้อนหลังของ VM

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

ก่อนอื่น ต้องชัดเจนว่าไม่มีวิธีเดียวที่จะกำหนดขอบเขตของ "รหัส Ethereum" (แม้แต่ในไคลเอ็นต์เดียวกัน)

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

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

หมวดหมู่ใหม่คือพื้นที่สีเหลือง: ประเภทของโค้ดนี้สำคัญมากสำหรับการเข้าใจและแยกวิเคราะห์สถานะของโซ่ปัจจุบัน และสำหรับการสร้างบล็อกที่ดีที่สุด แต่มันไม่ใช่ส่วนหนึ่งของความเห็นร่วม. ตัวอย่างเช่น Etherscan(และบางสิ่งBlock Builder) การสนับสนุนการดำเนินการของผู้ใช้ ERC-4337 หากเราใช้การดำเนินการบนเชน RISC-V เพื่อแทนที่ฟังก์ชันที่ใหญ่บางส่วนของ Ethereum (เช่น บัญชี EOA และการสนับสนุนของพวกเขาสำหรับประเภทธุรกรรมที่เก่า) แม้ว่าจะมีการลดความซับซ้อนของรหัสตรวจสอบอย่างมีนัยสำคัญ บางโหนดที่เป็นมืออาชีพอาจยังคงใช้รหัสต้นฉบับในการวิเคราะห์ฟังก์ชันเหล่านี้

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

โอนโค้ดจากพื้นที่สีเขียวไปยังพื้นที่สีเหลือง วิธีการนี้คล้ายกับ Apple Inc.แปลผ่านชั้นการแปล Rosettaเพื่อให้มั่นใจว่าจะเข้ากันได้ในระยะยาว

ฉันเสนอ (ยืมมาจาก@ipsilon/eof-ethereums-gateway-to-risc-v”> มุมมองล่าสุดของทีม Ipsilon) ขั้นตอนการย้ายเครื่องเสมือน (โดยใช้การย้าย EVM ไปยัง RISC-V เป็นตัวอย่าง แต่ยังสามารถใช้กับการย้าย EVM ไปยัง Cairo และอาจจะย้ายไปยัง VM ที่ดียิ่งกว่าในอนาคต):

1. ทุก precompiles ใหม่จะต้องเขียนในการปฏิบัติ RISC-V มาตรฐาน on-chain เพื่อให้นิเวศทำความรู้จักและใช้ RISC-V เป็นเครื่องจำลองได้เริ่มต้น
2. การเสนอ RISC-V เป็นตัวเลือกสำหรับการพัฒนาสัญญาข้อกันพร้อมกับ EVM สำหรับนักพัฒนา โปรโตคอลรองรับทั้ง RISC-V และ EVM อย่างเป็นธรรมชาติ ทำให้สัญญาที่เขียนด้วยทั้งสองภาษาสามารถทำงานร่วมกันได้อย่างอิสระ
3. Replace all precompiles (except elliptic curve operations and KECCAK) with RISC-V implementation. We remove these precompiles through a hard fork and at the same time change the code at the corresponding address (DAO fork-style) to be a RISC-V implementation. Because the RISC-V VM is extremely concise, even just doing this simplifies the overall structure.
4. นำ EVM interpreter ที่เขียนด้วย RISC-V มาปรับใช้เป็นสมาร์ทคอนแทรคบนเชน หลังจากปล่อยตลาดมาบางปีแล้ว สัญญา EVM ที่มีอยู่จะถูกประมวลผ่านตัวแปลนี้

หลังจากทำขั้นตอนที่ 4 เสร็จแล้ว จะยังคงมี 'การประมวลผล EVM' อย่างต่อเนื่องที่ใช้ในการปรับปรุงการสร้างบล็อก เครื่องมือการพัฒนา และการวิเคราะห์บนเชน แต่พวกเขาจะไม่ได้เป็นส่วนหนึ่งของข้อกำหนดข้อตกลงหลัก ณ เวลานั้น การตกลงของ Ethereum จะ 'เข้าใจ' เฉพาะ RISC-V เท่านั้น

Simplify by sharing protocol components

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

รหัสการลบที่สมบูรณ์

เราต้องแก้รหัสการลบในสามสถานการณ์:

• การสุ่มตรวจสอบความพร้อมใช้ข้อมูล - ลูกค้าตรวจสอบว่าบล็อกได้รับการเผยแพร่หรือยัง
• การกระจาย P2P อย่างเร็ว - โหนดสามารถยอมรับบล็อกหลังจากได้รับ n/2 จาก n บล็อก ซึ่งจะสร้างสมดุลในการลดความล่าช้าและความเหลือเชื่อ
• การเก็บรักษาประวัติที่กระจาย - ทุกชิ้นของประวัติของ Ethereum ถูกเก็บไว้ในบล็อกหลายๆ อัน เพื่อ (i) บล็อกเหล่านี้สามารถที่จะตรวจสอบได้อย่างอิสระ และ (ii) ครึ่งของบล็อกในแต่ละกลุ่มสามารถกู้คืนครึ่งที่เหลือลงไป ลดความเสี่ยงในการสูญหายของบล็อกเดียว

หากเราใช้รหัสการลบเดียวกัน (ไม่ว่าจะเป็น Reed-Solomon, รหัสเชิงเส้นแบบสุ่ม หรืออื่น ๆ) ในสามกรณีการใช้งาน เราจะได้รับประโยชน์บางประการที่สำคัญ

1. ลดจำนวนรวมของรหัส
2. เพิ่มประสิทธิภาพเพราะหากแต่ละโหนดต้องดาวน์โหลดส่วนต่าง ๆ ของบล็อกสำหรับกรณีการใช้งานหนึ่ง (แทนที่ทั้งบล็อก) ข้อมูลสามารถใช้ในกรณีการใช้งานอื่น
3. Ensure Verifiability: ทุกบล็อกสามตัวในบริบทสามารถทำการตรวจสอบได้โดยใช้ราก

หากจะต้องการรหัสการแก้ไขข้อผิดพลาดที่แตกต่างกันจริง ๆ 'ความเข้ากันได้' ควรถูกต้องอย่างน้อย: ตัวอย่างเช่น ในสถานการณ์ DAS การใช้ Reed-Solomon ในแนวนอนและการใช้โค้ดเชิงเส้นสุ่มในแนวตั้ง แต่ทั้งสองระบบมีพื้นที่คณิตศาสตร์เดียวกัน

รูปแบบการซีเรียลที่มีการรวมกัน

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

• บัญชีสมบูรณ์การรวม(อีอีพี-7701): เครื่องจำลองจะสามารถเห็นเนื้อหาของธุรกรรมทั้งหมด
• เพิ่มขีดจำกัดแก๊ส: การดำเนินการข้อมูลบล็อกต้องถูกห่อเป็น blob

ในขณะนั้น พวกเรามีโอกาสในการรวมโซลูชันการซีเรียลไลเซชันที่ต้องการสำหรับสามด้านปัจจุบัน: 1) ชั้นการดำเนินการ; 2) ชั้นความเห็น; 3) ABI การเรียกใช้สมาร์ทคอนแทรค

ฉันขอแนะนำให้นำSSZ(Simple Serialize), เนื่องจาก SSZ มีข้อดีต่อไปนี้:

• ง่ายต่อการถอดรหัส: รวมถึงภายในสมาร์ทคอนแทร็ค (โดยขึ้นอยู่กับการออกแบบ 4 ไบต์ กรณีขอบเขตไม่มากมาย)
• ใช้กันอย่างแพร่หลายในการเชื่อมั่น
• คล้ายกับ ABI ที่มีอยู่: ต้นทุนการย้ายเครื่องมือต่ำ

ปัจจุบันมีองค์ประกอบเพิ่มเติมการย้ายTo SSZงานเมื่อวานที่วางแผนสำหรับการอัปเกรดในอนาคต เราควรพิจารณาอย่างเต็มที่และใช้ประโยชน์จากพัฒนาการเหล่านี้

โครงสร้างต้นไม้ที่สมบูรณ์

เมื่อเราย้ายจาก EVM ไปสู่ RISC-V (หรือ VM ตัวย่ออื่น) ต้นไม้ Merkle Patricia ทศนิยมจะกลายเป็นข้อจำกัดที่สำคัญที่สุดสำหรับการพิสูจน์การดำเนินการบล็อก แม้แต่ในสถานการณ์ที่เฉลี่ย การย้ายไปใช้ฟังก์ชันแฮชต้นไม้ทวิภาค, จะเพิ่มประสิทธิภาพของตัวตรวจสอบอย่างมาก และลดค่าข้อมูลของโหนดแสงและสถานการณ์อื่น ๆ ได้

เมื่อทำการย้ายโครงสร้างต้นไม้เสร็จสิ้น เรายังควรให้แน่ใจว่าชั้น consensus ใช้โครงสร้างต้นไม้เดียวกันเพื่อให้มั่นใจได้ว่า Ethereum ทั้งหมด - ทั้งชั้น consensus และชั้น execution - สามารถเข้าถึงและแยกวิเคราะห์โดยใช้ชุดโค้ดเดียวกัน

จากตอนนี้ไปสู่อนาคต

การทําให้เข้าใจง่ายและการกระจายอํานาจมีความคล้ายคลึงกันมาก ทั้งสองเป็นข้อกําหนดต้นน้ําที่จําเป็นเพื่อให้บรรลุเป้าหมายที่สูงขึ้นของความยืดหยุ่นของระบบ การเน้นการทําให้เข้าใจง่ายอย่างชัดเจนจําเป็นต้องมีการเปลี่ยนแปลงทางวัฒนธรรม ประโยชน์ของการทําให้เข้าใจง่ายมักจะมองเห็นได้ยากในระยะแรก แต่ค่าเสียโอกาสและภาระงานเพิ่มเติมของการปฏิเสธ "คุณสมบัติใหม่ที่แวววาว" เหล่านั้นจะเห็นได้ชัดทันที อย่างไรก็ตามเมื่อเวลาผ่านไปมูลค่าระยะยาวของการทําให้เข้าใจง่ายจะชัดเจนมากขึ้น - Bitcoin เองเป็นตัวอย่างที่ยอดเยี่ยม

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

คำปฏิเสธ:

1. บทความนี้พิมพ์ซ้ําจาก [vitalik] ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [vitalikAll. If you have any objections to this reprint, please contactGate Learnทีมจะดำเนินการในเวลาที่เหมาะสม
2. คำชี้แจง: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นที่แสดงของคำแนะนำในการลงทุนใด ๆ
3. ทีม Gate Learn แปลบทความเป็นภาษาอื่น ๆ การคัดลอก การแจกจ่าย หรือการลอกเลียนบทความที่ถูกแปลนั้น ถูกห้าม นอกจากจะระบุไว้เป็นอื่น ๆ