อดีต ปัจจุบัน และอนาคตของการอัปเกรด Cancun

ชีวิตที่ผ่านมา

**เหตุใดจึงต้องอัปเกรดแคนคูน **

• วิสัยทัศน์ของ Ethereum คือการปรับขนาดได้และปลอดภัยยิ่งขึ้นภายใต้สมมติฐานของการกระจายอำนาจ การอัปเกรด Ethereum ในปัจจุบันยังมุ่งมั่นที่จะแก้ปัญหาไตรลักษณ์นี้ แต่ก็เผชิญกับความท้าทายที่ยิ่งใหญ่
• ปัญหาเกี่ยวกับ Ethereum:
• ในปัจจุบัน TPS และประสิทธิภาพต่ำ ค่าน้ำมันสูง และความแออัดก็ร้ายแรง ในขณะเดียวกัน พื้นที่ดิสก์ที่ต้องใช้ในการรันไคลเอนต์ Ethereum ก็เพิ่มขึ้นอย่างรวดเร็ว ที่ด้านล่าง งานเพื่อให้แน่ใจว่า ความปลอดภัยและการกระจายอำนาจของ Ethereum ผลกระทบของอัลกอริธึมฉันทามติด้านปริมาณต่อสภาพแวดล้อมทั้งหมดก็มีความสำคัญมากขึ้นเรื่อยๆ
• ดังนั้นภายใต้สมมติฐานของการกระจายอำนาจ วิธีส่งข้อมูลให้มากขึ้นและลดก๊าซเพื่อเพิ่มความสามารถในการปรับขนาด และวิธีเพิ่มประสิทธิภาพอัลกอริทึมที่สอดคล้องกันเพื่อให้แน่ใจว่าความปลอดภัยคือความพยายามทั้งหมดที่ Ethereum กำลังทำอยู่
• เพื่อแก้ปัญหาด้านความปลอดภัย การกระจายอำนาจ และการขยายขนาด Ethereum ได้ใช้กลไก PoW-to-PoS เพื่อลดโหนด threshold ลงอีก และยังวางแผนที่จะใช้ beacon chain เพื่อกำหนดตัวตรวจสอบแบบสุ่มเพื่อเพิ่มประสิทธิภาพการรักษาความปลอดภัย ในแง่นี้ ความสามารถในการปรับขนาด Ethereum พิจารณาใช้การแบ่งส่วนเพื่อลดภาระงานของโหนด ซึ่งทำให้ Ethereum สามารถสร้างบล็อกหลาย ๆ บล็อกในเวลาเดียวกันและเพิ่มความสามารถในการปรับขนาดได้
• พื้นที่ปัจจุบันของแต่ละบล็อกของ Ethereum อยู่ที่ประมาณ 200~300 KB, ขนาดขั้นต่ำของแต่ละธุรกรรมคือประมาณ 100 ไบต์, ประมาณ 2,000 ธุรกรรม, หารด้วยเวลาบล็อก 12 วินาที, ขีดจำกัดบนของ TPS ของ Ethereum ถูกจำกัดไว้ที่ประมาณ 100 เห็นได้ชัดว่าข้อมูลนี้ไม่สามารถตอบสนองความต้องการของ Ethereum ได้
• ดังนั้น Ethereum Layer 2 จึงมุ่งเน้นไปที่วิธีการใส่ข้อมูลจำนวนมากลงในบล็อก ในพื้นที่นี้ ความปลอดภัยรับประกันผ่านการพิสูจน์การฉ้อโกงและการพิสูจน์ความถูกต้อง ซึ่งเป็นสาเหตุที่ชั้น DA กำหนดขีดจำกัดสูงสุดของการรักษาความปลอดภัย ซึ่งเป็นเนื้อหาหลักของการอัปเกรด Cancun ด้วย
• เส้นทางวนซ้ำของระบบนิเวศ Ethereum ไม่สามารถสร้างประสิทธิภาพของเกณฑ์มาตรฐาน Solana (ในแง่ของความล่าช้าและปริมาณงาน) และประสิทธิภาพการกระจายตัวของ Near จะไม่เห็นในระยะสั้นหรือประสิทธิภาพการดำเนินการแบบขนานของ Sui และ Aptos ในระยะสั้น Ethereum สามารถสร้างโครงสร้างหลายชั้นโดยมี Rollup เป็นแกนหลัก ดังนั้น Cancun จึงอัปเกรดเพื่อแก้ปัญหา TPS, Gas ค่าธรรมเนียมและประสบการณ์ของนักพัฒนามีความสำคัญต่อแผนงาน Ethereum

**แผนงาน Ethereum มีการวางแผนอย่างไร? **

การอัปเกรดที่สำคัญสองสามรายการล่าสุดและเป้าหมาย

• 2020ปี12เดือน1* เปิดตัว Beacon chain อย่างเป็นทางการ ปูทางสู่ POS อัพเกรด*
• 2021**8เดือน5** การอัปเกรดในลอนดอน EIP1559 เปลี่ยนรูปแบบเศรษฐกิจของ Ethereum
• 2022ปี9เดือน15* ปารีสอัพเกรด (The ผสาน), เสร็จสิ้น POW การสลับ POS;*
• 2023ปี4เดือน12* อัพเกรดในเซี่ยงไฮ้ แก้ปัญหาถอนจำนำ*
• แบบจำลองเศรษฐกิจและการอัปเกรดที่เกี่ยวข้องกับ POS เสร็จสมบูรณ์แล้ว และการอัปเกรดอีกสองสามรายการถัดไปได้แก้ปัญหาประสิทธิภาพของ Ethereum, TPS และประสบการณ์ของนักพัฒนา
• ขั้นตอนต่อไปคือการมุ่งเน้นไปที่แผนงาน Ethereum * ไฟกระชาก* 。
• เป้า: บรรลุ 100,000+ TPS ใน Rollup
• มี 2 รูปแบบ on-chain และ off-chain:
• โซลูชันออฟไลน์: หมายถึง Layer2 รวมถึงการยกเลิก ฯลฯ
• On-chain scheme: หมายถึงการเปลี่ยนแปลงโดยตรงใน L1 ซึ่งเป็น Sharding Scheme ที่ได้รับความนิยม ความเข้าใจง่ายๆ ของ Sharding คือการแบ่งโหนดทั้งหมดออกเป็นพื้นที่ต่างๆ และทำงานให้เสร็จในแต่ละพื้นที่ ซึ่งจะช่วยเพิ่มความเร็วได้อย่างมีประสิทธิภาพ
• การวิเคราะห์รูปแบบการแบ่งกลุ่ม:
• ภาวะที่กลืนไม่เข้าคายไม่ออกของ Sharding Scheme: Sharding เคยรวม State Sharding, Transaction Sharding ฯลฯ แต่การซิงโครไนซ์ระหว่าง Shards ต่างๆ เป็นปัญหา ในปัจจุบัน การซิงโครไนซ์ข้อมูลโหนดเครือข่ายขนาดใหญ่ให้เสร็จสมบูรณ์นั้นทำได้ยาก ไม่เพียงเท่านั้น ไม่สามารถแก้ไขสถานการณ์ของ MEV ได้ แต่อาจต้องใช้แพตช์จำนวนมากเพื่อชดเชยปัญหาต่างๆ ที่อาจเกิดขึ้นซึ่งไม่สามารถทำได้ในระยะสั้น
• Danksharding คือการออกแบบ Sharding ใหม่ที่เสนอสำหรับ Ethereum แนวคิดหลักคือ การผลิตบล็อกแบบรวมศูนย์ + การตรวจสอบแบบกระจายอำนาจ + การต่อต้านการเซ็นเซอร์ ซึ่งเกี่ยวข้องกับความพร้อมใช้งานของข้อมูลที่กล่าวถึงด้านล่าง การสุ่มตัวอย่าง (DAS) การแยกกลุ่มผู้ผลิต-ผู้บรรจุหีบห่อ (PBS) และรายการต่อต้านการเซ็นเซอร์ (Crlist) ความสำคัญที่ยิ่งใหญ่ที่สุดของแนวคิดหลักของ Danksharding คือการเปลี่ยน Ethereum L1 ให้เป็นการตั้งถิ่นฐานแบบครบวงจร (การชำระบัญชี) และความพร้อมใช้งานของข้อมูล (ความพร้อมใช้งานของข้อมูล) ห้องว่าง）层。

*รูปแบบการแบ่งย่อยแบ่งออกเป็น 2 ขั้นตอน ปัจจุบันแบ่งเป็น ****Proto- **** การแบ่งกลุ่ม ****** และ **** การรวบรวมทั้งหมด ****** ***

• ดังนั้น- แดนส์ชาร์ดดิ้ง**：**
• แนะนำ: ช่วยลดค่าธรรมเนียม L2 และเพิ่มปริมาณงานโดยแนะนำ blobs ในขณะเดียวกันก็เป็นโซลูชันก่อนการแตกสะเก็ดเพื่อปูทางไปสู่การแตกยอดที่สมบูรณ์ คาดว่าหลังจากการโปรโต-แดนส์ชาร์ด การนำดันแชริ่งไปใช้งานจะใช้เวลา 2-5 ปี
• เนื้อหา: คุณสมบัติหลักของ proto-danksharding คือการแนะนำธุรกรรม blob ประเภทใหม่ Blob มีลักษณะความจุขนาดใหญ่และต้นทุนต่ำ การเพิ่มแพ็กเก็ตข้อมูลดังกล่าวใน Ethereum สามารถทำให้ข้อมูลสะสมทั้งหมดถูกจัดเก็บไว้ใน blob ซึ่งอย่างมาก แบ่งเบาภาระของห่วงโซ่หลัก นอกจากนี้ แรงดันในการจัดเก็บยังช่วยลดต้นทุนในการม้วนเก็บได้อีกด้วย
• ครบชุด
• บทนำ: ค่าสะสมได้รับการขยายอย่างเต็มที่ โดยมุ่งเน้นที่การใช้ประโยชน์จากความพร้อมใช้งานของข้อมูล
• เนื้อหา:
• การออกแบบ P2P ของ DAS: งานและการวิจัยบางส่วนที่เกี่ยวข้องกับปัญหาการเชื่อมต่อเครือข่ายการแบ่งส่วนข้อมูล
• ไคลเอ็นต์การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล: พัฒนาไคลเอ็นต์ที่มีน้ำหนักเบาซึ่งสามารถระบุได้อย่างรวดเร็วว่ามีข้อมูลหรือไม่โดยการสุ่มตัวอย่างสองสามกิโลไบต์
• การรักษาตัวเองของ DA ที่มีประสิทธิภาพ: สามารถสร้างข้อมูลทั้งหมดใหม่ได้อย่างมีประสิทธิภาพภายใต้สภาวะเครือข่ายที่เลวร้ายที่สุด (เช่น การโจมตีด้วยเครื่องมือตรวจสอบที่เป็นอันตราย หรือการหยุดทำงานระยะยาวของโหนดบล็อคขนาดใหญ่)

การประชุมนักพัฒนาหลักของ Ethereum

การอัปเกรด Ethereum ทุกครั้งขึ้นอยู่กับการประชุมนักพัฒนาหลัก ผ่านการอภิปรายร่วมกันของผู้สนับสนุนหลัก และตามชุดข้อเสนอจากนักพัฒนา ทิศทางการพัฒนาในอนาคตจะถูกกำหนด

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

• กระบวนการหลัก: กระบวนการอัปเกรดที่มีศูนย์กลางอยู่ที่ EIP เป็นดังนี้ ขั้นแรก EIP จะได้รับการยอมรับในเบื้องต้นในการประชุมนักพัฒนาหลัก (เรียกสั้นๆ ว่า ACD) จากนั้นทีมลูกค้าจะทดสอบโดยไม่คำนึงว่า EIP จะรวมอยู่ใน อัปเกรดหรือไม่ และหลังจากการทดสอบขั้นสุดท้าย ให้ทบทวนอีกครั้ง จากนั้นตัดสินใจว่าจะรวมไว้ในการอัปเกรดจริงตามการสนทนาหรือไม่
• การประชุมแบ่งออกเป็น 2 ประเภท ได้แก่ การประชุมระดับฉันทามติและการประชุมระดับผู้บริหาร ซึ่งจัดสลับกันทุกสัปดาห์:
• ** การประชุมชั้นฉันทามติ (**** ทั้งหมด ฉันทามติของนักพัฒนาหลัก - ACDC****) โดยเน้นที่เลเยอร์ฉันทามติของ Ethereum (การพิสูจน์การเดิมพัน ห่วงโซ่บีคอน ฯลฯ)**
• การประชุมระดับผู้บริหาร ( ทั้งหมด โซลูชัน Core Developers - ACDE**) ซึ่งมุ่งเน้นไปที่ชั้นการดำเนินการของ Ethereum (EVM, **Gas กำหนดการ ฯลฯ)
• มีผู้ดูแลหลักของ Ethereum อยู่ 3 ประเภท โดยส่วนใหญ่เป็นองค์กรทางการหรือฟอรัมอาสาสมัครที่หารือเกี่ยวกับข้อเสนอ:
• AllCoreDevs: ผู้ดูแลโค้ด รับผิดชอบไคลเอ็นต์เครือข่าย ETH1 อัปเกรด บำรุงรักษาโค้ด Ethereum และสถาปัตยกรรมหลัก
• ส่วน "การจัดการโครงการ": สนับสนุนนักพัฒนา Ethereum ประสานงานฮาร์ดฟอร์ก ตรวจสอบ EIP ฯลฯ และช่วยเหลือ AllCoreDevs โดยตรงในการสื่อสารและการดำเนินงาน
• อีเธอเรียม นักมายากล: "ฟอรัม" ที่ต้องการการอภิปรายเกี่ยวกับ EIP และหัวข้อทางเทคนิคอื่นๆ

เส้นเวลาของการประชุมที่เกี่ยวข้องกับการยกระดับ Cancun

*ตามเนื้อหาของการสนทนา การอัปเกรด Cancun นี้สามารถแบ่งออกเป็นขั้น 5 อย่างคร่าวๆ ***

เฟส 1 - แนะนำการอัพเกรดธีม

แนะนำงานใหม่proto-danksharding***,EOF และ "ทำลายตัวเอง" * Opcode การสนทนาผิวเผินของเนื้อหาการอัปเกรด Shanghai**

• หลังจากการควบรวมกิจการของ Ethereum เสร็จสิ้นในวันที่ 15 กันยายน 22 การประชุมนักพัฒนาซอฟต์แวร์ถูกระงับเป็นเวลา 4 สัปดาห์ ทำให้นักพัฒนาสามารถตรวจสอบ EIP ที่กล่าวถึงในการอัปเกรดครั้งต่อไปเป็นเวลาหนึ่งเดือน
• เมื่อวันที่ 28 ตุลาคม 22 การประชุมนักพัฒนาซอฟต์แวร์ครั้งแรกหลังจากการควบรวมกิจการได้เสนอการนำ proto-danksharding, EOF และ opcode "selfdestruct" มาใช้เป็นครั้งแรก ในขณะนี้ ขอบเขตเฉพาะของ proto-danksharding ยังไม่ได้กำหนด และนักพัฒนาบางส่วนในเบื้องต้น เชื่อกันว่าการอัปเกรดในเซี่ยงไฮ้สามารถแบ่งออกเป็นการอัปเกรดเล็กๆ หลายรายการ เช่น การเปิดใช้งานการถอน ETH ที่จำนำไว้ก่อน แล้วจึงอัปเกรด EIP 4844 แต่นักพัฒนาอีกกลุ่มหนึ่งคิดว่าเหมาะสมกว่าที่จะใช้การอัปเกรดที่ใหญ่ขึ้นในขั้นตอนเดียว

ขั้นตอนที่ 2 - กำหนดระยะเวลาและเตรียมการสำหรับพิธี KZG

ในตอนท้ายของ 2022** การประชุม Ethereum ส่วนใหญ่หมุนรอบ EOF และ EIP 4844 การสนทนาในขณะที่ยังคงส่งเสริม EIP 4844 พิธีการตั้งค่าล่วงหน้าที่จำเป็นสำหรับพิธี — KZG**** ผู้พัฒนาจะมีขึ้นใน *******23 **** ปี **** 1 **** เดือนได้รับการยืนยันอย่างเป็นทางการซึ่งการอัพเกรด **** 4844 **** จะปรากฏใน ***

• เมื่อวันที่ 22 พฤศจิกายน EOF หรือ proto-danksharding ได้รับการกล่าวถึงในการประชุมทางโทรศัพท์ #149 ของนักพัฒนาหลักทั้งหมดของ Ethereum ในขณะนี้ นักพัฒนายังคงพิจารณาที่จะวางมันในการอัปเกรดเซี่ยงไฮ้
• ในการประชุมเลเยอร์ฉันทามติเมื่อวันที่ 2, 22 ธันวาคม เทรนต์ หัวหน้าระบบนิเวศ Ethereum Van Epps อัปเดต EIP 4844 ความคืบหน้าในการดำเนินพิธีการตั้งค่าที่เชื่อถือได้เพื่อสร้าง รหัสความปลอดภัยที่ใช้ใน 4844 รถตู้ Epps หวังว่าพิธีจะเป็นหนึ่งในงานที่ใหญ่ที่สุดที่เคยมีมาในพื้นที่ crypto โดยรวบรวมผลงาน 8,000 ถึง 10,000 รายการ และระยะเวลาการบริจาคสาธารณะสำหรับพิธีจะใช้เวลาประมาณ 2 เดือนและเริ่มในเดือนธันวาคม
• ในการประชุมนักพัฒนาหลักในวันเดียวกัน มีการอภิปรายเกี่ยวกับ EOF และการปิดใช้งาน opcode ที่ทำลายตัวเอง นักพัฒนาของ Ethereum Foundation คัดค้านการเลื่อน EOF ไปที่ Cancun โดยให้เหตุผลว่าหากไม่มีการเปลี่ยนแปลงรหัสในเซี่ยงไฮ้ ความเป็นไปได้ในการเข้าสู่ Cancun นั้นน้อยมาก เกี่ยวกับรหัส selfdestruct มีนักพัฒนาที่สนับสนุนการพัฒนา EIP ในเวลานั้น 4758 แต่การปิดใช้งาน opcode นี้โดยตรงจะทำให้บางแอปพลิเคชันเสียหาย และผู้พัฒนาเชื่อว่าควรชั่งน้ำหนัก EIP นี้อีกครั้งสักระยะหนึ่งก่อนที่จะสร้าง edge case เพื่อป้องกันสัญญาประเภทนี้
• ในการประชุมนักพัฒนาหลักเมื่อวันที่ 9 ธันวาคม 22 มีการส่งเสริมการดำเนินการตามพิธี KZG เกี่ยวกับการอัปเกรด Cancun และ EIP ปัจจุบัน 4844 พิธีตั้งค่าที่เชื่อถือได้พร้อมแล้ว
• ในการประชุมชั้นฉันทามติเมื่อวันที่ 16 ธันวาคม 22 เกี่ยวกับ EIP 4844 นักพัฒนาได้กล่าวถึงการรวมคำขอดึงข้อมูล (PRs) ที่แตกต่างกันสองรายการเข้ากับข้อมูลจำเพาะสำหรับ Proto-danksharding โดยรายการหนึ่งเกี่ยวข้องกับวิธีที่โหนดจัดการกับความพร้อมใช้งานของข้อมูลที่เกินจุดหนึ่งหลังจากการตัดข้อมูล และอีกครั้งเมื่อบล็อกรหัสข้อผิดพลาดใหม่จะถูกนำมาใช้เพื่อแจ้งเตือน โหนดเมื่อไม่มีข้อมูลเกี่ยวกับ blobs
• ในระหว่างการประชุมนักพัฒนาหลักในวันที่ 01/05/23 ผู้พัฒนาได้บรรลุฉันทามติเพื่อลบการแก้ไขโค้ดที่เกี่ยวข้องกับการใช้งาน EOF จากการอัปเกรดที่เซี่ยงไฮ้ ในเวลานี้ Beiko แนะนำให้ตัดสินใจหลังจากสองสัปดาห์ว่าควรรวม EOF ไว้ใน Cancun หรือไม่ อัพเกรด;

ขั้นตอนที่ 3 - การอภิปรายเบื้องต้นเกี่ยวกับขอบเขตของข้อเสนอ

ในตอนท้ายของ 231EOF ย้ายไป Cancun เพื่อเลื่อนตำแหน่ง หลังจากย้ายจากเซี่ยงไฮ้โปรโม ตั้งแต่นั้นมา 2 เดือนส่วนใหญ่หมุนรอบยกเว้น EOF** และ EIP มีการหารือข้อเสนออื่นๆ นอกเหนือจาก 4844 และในเวลาเดียวกัน ***EOF ถูกเสนอให้ย้ายออกจากแคนคูน ช่วงเวลานี้ส่วนใหญ่ใช้ไปกับการกำหนดขอบเขตของข้อเสนอสำหรับการยกระดับแคนคูน ***

• ในการประชุมนักพัฒนาหลักเมื่อวันที่ 20, 23 มกราคม EOF ถูกย้ายไปที่ Cancun เพื่ออัปเกรด
• ในการประชุมนักพัฒนาหลักเมื่อวันที่ 6 มีนาคม 23 ข้อเสนอเบื้องต้นสำหรับการอัปเกรด Cancun คือ: EIP 4788 (รูทสถานะของ beacon chain สาธารณะ), EIP 2537 (ดำเนินการอย่างมีประสิทธิภาพเช่นการตรวจสอบลายเซ็น BLS และการตรวจสอบ SNARK), EIP-5920 (เปิดตัว opcode PAY ใหม่) และ EIP การใช้งานร่วมกันของ 6189 (สำหรับการทำให้ SELFDESTRUCT เข้ากันได้กับต้นไม้ Verkle) และ EIP-6190 (การเปลี่ยนฟังก์ชัน SELFDESTRUCT เพื่อให้เกิดการเปลี่ยนแปลงสถานะในจำนวนจำกัดเท่านั้น)
• ในการประชุมนักพัฒนาหลักในวันที่ 16, 23 มีนาคม ยกเว้น EOF และ EIP 4844 ข้อเสนอต่อไปนี้ได้รับการพิจารณาเพื่อรวมไว้ใน Cancun: รูปแบบ SSZ, การลบ SELFDESTRUCT, EIP 2537、EVMMAX、EIP 1153 คำแนะนำ SWAP และ DUP แบบไม่จำกัด แนะนำรหัส PAY และรูทสถานะบีคอนใน EVM
• ในการประชุมนักพัฒนาหลักเมื่อวันที่ 30 มีนาคม 23 มีการนำเสนอข้อเสนอ EIP-6780 เกี่ยวกับการปิดใช้งาน SELFDESTRUCT เป็นครั้งแรก ซึ่งเป็นข้อเสนอสำหรับการปิดใช้งาน SELFDESTRUCT ที่ Cancun ตัดสินใจใช้ในที่สุด แต่เกี่ยวกับการดำเนินการของ EOF จาก Erigon (EL) นักพัฒนาในทีมลูกค้ากล่าวว่า EOF 'การเปลี่ยนแปลงมากเกินไป' เพื่อแข่งขันกับ EIP ข้อเสนอการปรับปรุง Ethereum ในการอัปเกรด Cancun ที่กำลังจะมีขึ้น 4844 มีข้อเสนอให้นำ EOF ไปใช้ในฮาร์ดฟอร์กหลังจากอัปเกรด Cancun ได้ไม่นาน

ขั้นตอนที่สี่ - กำหนดทิศทางที่ชัดเจนของการอัปเกรดข้อเสนอและลบข้อเสนอที่ไม่เกี่ยวข้อง

ใน 234 เดือน มีทิศทางที่ชัดเจนสำหรับข้อเสนอที่ควรครอบคลุมโดยการอัปเกรด Cancun และโหนดสำคัญอยู่ใน 4 ************************************************ ************************************************** *********** EIP และ ทิม ยังมีการอภิปรายเชิงลึกเพิ่มเติมเกี่ยวกับข้อเสนอทางเลือกใน 4 เดือน ในการประชุมวันที่ 27,*** EIP 6780******、**EIP 6475 และ *EIP 1153ถูกกำหนดให้รวมอยู่ใน Cancun และในเวลาเดียวกัน *EOF และ EVMMAX (ที่มี * ***EOF ***ส่วนย่อยที่เกี่ยวข้องกับการดำเนินการ EIP) ถูกลบออกจากการอัปเกรด Cancun EOF การอัปเกรดส่วนใหญ่ช่วยได้ EVM ดำเนินการควบคุมเวอร์ชัน และสามารถเรียกใช้กฎสัญญาหลายชุดพร้อมกัน ซึ่งจะช่วยการขยายตัวของ Ethereum ในภายหลัง แต่เมื่อพิจารณาถึงความเป็นไปได้ของการอัปเกรดทั้งหมดแล้ว ** * EOF การอัปเกรดอาจดำเนินการต่อด้วยการอัปเกรดรายวัน

• 23****4เดือน12**** การอัปเกรด Ethereum Shanghai เสร็จสมบูรณ์แล้ว
• ระหว่างการประชุมผู้พัฒนาหลักในวันที่ 13.04.23 ผู้พัฒนาได้หารือเกี่ยวกับ EIP 4844 (สำหรับการเปิดเผยข้อมูลเกี่ยวกับรากสถานะ CL ใน EL) มี EIP อย่างน้อยเก้ารายการที่กำลังพิจารณาสำหรับการอัปเกรด ได้แก่ EIP 4844**, ทำลายตัวเอง ลบ (EIP-6780, EIP 4758、EIP 6046、EIP 6190）、EIP 5920、EIP 1153、EIP 2537、สพป 4788、EVMMAX EIP（EIP 6601 และ EIP 6690), สส การเปลี่ยนแปลง（EIP 6475、EIP 6493、EIP 6465、EIP 6404 และ EIP 6466 ）、EIP 5656 และ **EIP 6193；
• ในการประชุมนักพัฒนาหลักในวันที่ 27, 23 เมษายน ความคืบหน้าและการแลกเปลี่ยนหลายรายการได้มุ่งเน้นไปที่ ประการแรก EIP4844 ยังคงได้รับการระบุเพื่อรวมในการอัปเกรด Cancun ด้วยการเพิ่ม EIP ต่อไปนี้: EIP 6780 (เปลี่ยนการทำงานของ SELFDESTRUCT opcode), EIP 6475 (ประเภท Simple Serialization (SSZ) ใหม่เพื่อแสดงค่าทางเลือก), EIP 1153 (เพิ่ม opcode ใหม่เพื่อดำเนินการสถานะ) ประการที่สอง EIP ที่กำลังพิจารณาแต่ไม่รวมอยู่ในการอัปเกรดอย่างเป็นทางการคือ EIP 6913 (แนะนำคำสั่ง SETCODE), EIP 6493 (กำหนดรูปแบบลายเซ็นสำหรับธุรกรรมที่เข้ารหัส SSZ), EIP 4788 (เปิดเผยรูทของบล็อกเชนบีคอนในส่วนหัวของบล็อก EL), EIP 2537 (เพิ่มเส้นโค้ง BLS12-381 เป็นพรีคอมไพล์) และ EIP 5656 (แนะนำคำสั่ง EVM ใหม่สำหรับการคัดลอกขอบเขตหน่วยความจำ) สุดท้าย EOF ** และ ** EVMMAX** (** EOF ** ขึ้นอยู่กับการใช้งาน ** * EIP** ชุดย่อย) ถูกลบออกจากการอัปเกรด Cancun **EOF การอัปเกรดถูกย้ายออกจากเซี่ยงไฮ้ในการประชุม Ethereum Developers Conference เมื่อต้นปี ****2023****1**** และต่อมาได้รับการอัปเกรดจาก * *** จากจุดสิ้นสุดของ 1 ถึงจุดเริ่มต้นของ 4 ใน 23**** จะปรากฏใน Cancun upgrade ตามค่าเริ่มต้น แต่ใน ** 23** **EOF **ถูกลบอีกครั้งในการประชุมนักพัฒนาเมื่อ 29, 4 **

ขั้นตอนที่ห้า - การกำหนดข้อเสนอขั้นสุดท้ายและการปรับปรุงรายละเอียด

235เดือน ปรับปรุงและปรับปรุงรายละเอียดของข้อเสนอขั้นสุดท้ายเป็นหลักSSZ-> การเปลี่ยนแปลง RLP** หมายความว่าไม่จำเป็นต้องใช้ SSZ ทั้งสองแห่งใน Cancun อีกต่อไป EIPs****** ดังนั้น EIPs 6475 และ 6493 จะถูกย้ายออกจาก Cancun เพื่อทำการอัพเกรด พร้อมกันนี้ในการประชุมแกนนำวันที่ 26ทิม Beiko* แนะนำว่าการสนทนาในอนาคตเกี่ยวกับการขยายการเข้าถึงของ Cancun จำกัดไว้ที่ห้ารายการต่อไปนี้EIP:**EIP-5920 * ,5656,7069,4788 และ ****2530 * ****. ขณะนี้ผู้พัฒนาได้กำหนดขอบเขตการอัปเกรด Cancun ทั้งหมดแล้ว ***

*การประชุม Ethereum Core Consensus เมื่อวันที่ 5/5/23 หารือเกี่ยวกับ EIP ที่กล่าวถึงล่าสุด 4788 ในขณะที่เพิ่ม EIP 6987 และ EIP การอภิปรายในปี 6475 ข้อเสนอทั้งสองนี้เกี่ยวกับผู้ตรวจสอบและธุรกรรม SSZ ตามลำดับ

• ในการประชุมระดับผู้บริหาร Ethereum ครั้งที่ 161 เมื่อวันที่ 11 พฤษภาคม 23 Tim Beiko กล่าวว่าขอบเขตของการอัปเกรด Cancun ยังสามารถแก้ไขได้ในอีกไม่กี่สัปดาห์ข้างหน้า แต่หากไม่มีคำแนะนำที่ชัดเจนจากนักพัฒนา ขอบเขตของการอัปเกรด Cancun จะยังคงอยู่ในสถานะ "เริ่มต้น" และการอภิปรายเกี่ยวกับ EIP-4844 แสดงให้เห็น ว่าการพัฒนา ผู้เขียนตกลงที่จะลบ SSZ ออกจากการใช้งาน EL ของ EIP-4844 **แต่ยังไม่ส่งผลกระทบต่อความคืบหน้าอย่างต่อเนื่องของ ** 6475 ** **นอกจากนี้ ผู้พัฒนายังได้หารือสั้น ๆ เกี่ยวกับ EIP สองรายการสำหรับการพิจารณาใน Cancun นั่นคือ EIP 6969（EIP

1559. และ EIP 5656 (คำแนะนำ EVM ที่มีประสิทธิภาพสำหรับการคัดลอกขอบเขตหน่วยความจำ);

• การพัฒนาในปี 4844 ได้มีการหารือสั้นๆ ในการประชุม Developer Consensus เมื่อวันที่ 18 พฤษภาคม 23 เช่น การอนุญาตให้แอปพลิเคชันสัญญาอัจฉริยะบน EL ตรวจสอบหลักฐานสถานะ CL;
• การปิดใช้งาน SELFDESTRUCT, การเปลี่ยนแปลงข้อมูลจำเพาะ EIP-4844, การจัดการ opcode และการเพิ่ม Cancun ขั้นสุดท้ายที่เป็นไปได้ ได้มีการหารือในการประชุม Ethereum Core ครั้งที่ 162 เมื่อวันที่ 25 พฤษภาคม 2023 ทิม Beiko แนะนำว่าการสนทนาในอนาคตเกี่ยวกับการขยายขอบเขตของ Cancun ให้จำกัดไว้ที่ EIP ห้ารายการต่อไปนี้: EIP-5920**, 5656, 7069,* ** 4788* ** และ ** 2530** ผู้พัฒนาจะยืนยันในอีกไม่กี่สัปดาห์ข้างหน้า ** Dencun** (****Deneb

• แคนคูนเต็มรูปแบบ****);**

• ในการประชุม Ethereum Consensus Layer ครั้งที่ 110 เมื่อวันที่ 1 มิถุนายน 2023 นักวิจัยจาก Ethereum Foundation ได้แนะนำผลการทดลองข้อมูลเกี่ยวกับความสามารถของ Ethereum mainnet nodes ในการเผยแพร่ข้อมูลจำนวนมาก จากผลนี้ นักวิจัยแนะนำว่า สพป ข้อมูลจำเพาะ 4844 เพิ่มจากสูงสุด 4 blobs เป็น 6 ต่อบล็อก ในขณะเดียวกัน ผู้พัฒนากำลังพิจารณา EIP 4788 รวมอยู่ในการอัปเกรด Cancun;
• ในการประชุมนักพัฒนาหลักในวันที่ 13 มิถุนายน 2023 นักพัฒนายืนยันอย่างเป็นทางการถึงขอบเขตการอัปเกรด ซึ่งรวมถึง EIP 4844、EIP 1153、EIP 5656、EIP 6780、EIP 4788；
• ในการประชุมฉันทามติเมื่อวันที่ 15 มิถุนายน 2023 มีการหารือกันว่า EIPs ที่เน้น CL ใดที่จะรวมไว้ใน Deneb โดยในจำนวนนี้ EIP-6988, EIP-7044, EIP-7045 ถูกเสนอให้เพิ่ม และทีมไคลเอนต์ CL ตกลง ต่อไปนี้ เครือข่ายทดสอบ EIP-4844 Devnet6 จะทดสอบจำนวน blobs ที่เพิ่มขึ้นและทำการตัดสินใจขั้นสุดท้ายเกี่ยวกับเรื่องนี้ภายในสองสัปดาห์ ในขณะที่ Michael นักวิจัยของ Ethereum Foundation Neuder เสนอให้ถอดขีดจำกัดการเดิมพัน 32 ETH เพื่อช่วยลดการเติบโตของชุดเครื่องมือตรวจสอบที่ใช้งานอยู่
• ในการประชุมเมื่อวันที่ 22 มิถุนายน 2566 ทิมเสนอให้ย้ายที่อยู่พรีคอมไพล์ของ 4844 ไปที่ 0xA บรรจุและย้าย BLS ไปยังแอดเดรสอื่น แม้ว่าคอมไพล์ล่วงหน้าผ่าน EIP 2537 แต่จะไม่ถูกพิจารณาในแคนคูน;
• ในการประชุมฉันทามติเมื่อวันที่ 29 มิถุนายน 2023 ผู้พัฒนายังคงหารือเกี่ยวกับจำนวนของ Blob โดยจำกัดเป้าหมายของ Blob เพิ่มขึ้นจาก 2 เป็น 3 เพิ่มขีดจำกัด blob สูงสุดจาก 4 เป็น 6 และ 4844 ทดสอบเครือข่าย Devnet #7 กำลังจะมา

ชีวิตนี้

• เนื้อหาหลักคือ EIP 4844，即Proto-Danksharding
• ช่วง EIP สุดท้ายสำหรับการอัปเกรด Cancun นี้คือ: EIP 4844**、EIP 1153、EIP 5656、EIP 6780、EIP 4788. ในขณะเดียวกัน ในการประชุม Ethereum ACDC ครั้งที่ 111 เมื่อวันที่ 19 มิถุนายน นักพัฒนายังคงหารือเกี่ยวกับ EIP 6988、** EIP 7044**、**EIP 7045 สำหรับการรวมใน Deneb นักพัฒนากล่าวว่าพวกเขาวางแผนที่จะรวม EIP ทั้งสามดังกล่าวเข้ากับข้อกำหนดของ Deneb ในอีกไม่กี่สัปดาห์ข้างหน้า

การวิเคราะห์คีย์EIP**

สพฐ 4844

• การแนะนำ:
• ชื่อของข้อเสนอ EIP4844 คือ Proto-Danksharding ซึ่งเป็นโปรโตคอลก่อนหน้าของเวอร์ชันเต็มของ Danksharding ส่วนขยาย Sharding โครงร่าง Sharding ทั้งชุดอิงจาก Rollup สำหรับการขยายแบบ on-chain **จุดประสงค์ของโปรแกรมคือการขยาย ** 2 เลเยอร์ **การสั่งสม——****โดยการช่วย L2 ลดค่าธรรมเนียมและเพิ่มปริมาณงาน ในขณะที่ปูทางไปสู่การแบ่งส่วนย่อยทั้งหมด (การแบ่งส่วนย่อย) **
• ในการประชุมทางโทรศัพท์วันที่ 23 กุมภาพันธ์ นักพัฒนา Ethereum จะ EIP การอัปเกรด 4844 มีชื่อว่า Deneb ซึ่งเป็นชื่อของดาวฤกษ์ดวงแรกในกลุ่มดาว Cygnus ซึ่งเป็น EIP ในเวอร์ชัน GitHub ที่เกี่ยวข้องในอนาคต การตั้งชื่อ 4844 จะได้รับการอัปเดตเป็น Deneb ในการประชุมวันที่ 1, 23 มิถุนายน จะมีการเปลี่ยนแปลงบางอย่างในข้อกำหนดการอัปเกรดครั้งต่อไปของ Ethereum ซึ่งเรียกว่า Deneb ในฝั่ง CL และ Cancun ในฝั่ง EL
• ในการประชุมนักพัฒนาเมื่อวันที่ 23 มิถุนายน 23 นักพัฒนาได้เตรียมอัปเดต EIP ที่อยู่ที่คอมไพล์แล้วของ 4844 ปัจจุบัน ผู้พัฒนาหลักได้เพิ่มพรีคอมไพล์ 9 รายการใน EVM และจะเปิดใช้งาน EIP ภายใน 4844 และ 4788 สร้างพรีคอมไพล์สองตัวภายใต้แอดเดรส "0xA" และ "0xB" ตามลำดับ ในการประชุมฉันทามติในวันที่ 29 มิถุนายน EIP พร้อมที่จะเปิดตัวแล้ว Devnet เครือข่ายทดสอบระยะสั้นโดยเฉพาะของ 4844 #7。
• EIP-4844** แนะนำประเภทธุรกรรมใหม่ล่าสุด - Blob การแปลง.**
• โปรไฟล์หยด:
• Blob คล้ายกับแพ็กเก็ตข้อมูลปลั๊กอิน เพียง 128 ที่จุดเริ่มต้น พื้นที่เก็บข้อมูลของ KB ในตอนต้นของการอภิปรายข้อเสนอ เป้าหมายและขีดจำกัดของ Blob คือ 2/4 และปรับเป็น 3/6 ในการประชุมนักพัฒนาเมื่อวันที่ 9 มิถุนายน 23 นั่นคือ ปัจจุบันแต่ละธุรกรรมใน Ethereum สามารถทำธุรกรรม Blob ได้สูงสุด 3 รายการ นั่นคือ 384 รายการ KB เป้าหมายของแต่ละบล็อก ความจุหยดคือ 6 นั่นคือ 768 KB ซึ่งสามารถรองรับได้ถึง 16 blobs ซึ่งเป็น 2MB
• อาจมีผลกระทบบางอย่างต่อความเสถียรของเครือข่าย แต่ทีมพัฒนา Ethereum ยังคงตัดสินใจที่จะทดสอบก่อนเพื่อหลีกเลี่ยงความจำเป็นในการฮาร์ดฟอร์กในภายหลังเพื่อขยายบล็อกหยด
• หยด **ใน ** KZG commit Hash เป็น ** Hash ใช้สำหรับตรวจสอบข้อมูล ฟังก์ชันคล้ายกับ ** Merkle ;
• โหนดซิงโครไนซ์ Blob บนห่วงโซ่ หลังจากการทำธุรกรรม ส่วนของ Blob จะหมดอายุและถูกลบหลังจากช่วงระยะเวลาหนึ่ง และเวลาจัดเก็บคือสามสัปดาห์
• ฟังก์ชั่น Blob - ปรับปรุง TPS ของ Ethereum ในขณะที่ลดต้นทุน
• ในปัจจุบัน ปริมาณข้อมูลทั้งหมดของ Ethereum ทั้งหมดอยู่ที่ประมาณ 1TB เท่านั้น และ Blob สามารถนำปริมาณข้อมูลเพิ่มเติม 2.5-5TB มาสู่ Ethereum ทุกปี ซึ่งมากกว่าบัญชีแยกประเภทโดยตรงหลายเท่า
• สำหรับโหนด การดาวน์โหลดข้อมูล blob เพิ่มเติม 1MB ถึง 2MB ต่อบล็อกจะไม่ทำให้เกิดภาระแบนด์วิธ และพื้นที่จัดเก็บจะเพิ่มปริมาณข้อมูล blob คงที่ประมาณ 200~400GB ต่อเดือนเท่านั้น ซึ่งจะไม่ส่งผลกระทบต่อ การกระจายอำนาจของโหนด Ethereum ทั้งหมด แต่การขยายตัวรอบ ๆ Rollup ได้รับการปรับปรุงอย่างมาก
• อันที่จริง โหนดเองไม่จำเป็นต้องเก็บข้อมูล Blob ทั้งหมด เนื่องจากจริง ๆ แล้ว Blob เป็นแพ็คเกจข้อมูลชั่วคราว ดังนั้นในความเป็นจริงแล้ว โหนดจำเป็นต้องดาวน์โหลดข้อมูลในจำนวนคงที่เป็นเวลาสามสัปดาห์เท่านั้น
• บทบาทของ EIP-4844** - เพื่อเปิดบทแรกของการเล่าเรื่อง **** Danksharding******
• **การขยายความจุสูง: **ในปัจจุบัน EIP-4844 สามารถขยายความจุ L2 ได้ในตอนแรก Danksharding เวอร์ชันเต็มสามารถขยายปริมาณข้อมูล Blob ใน EIP-4844 จาก 1MB เป็น 2MB เป็น 16MB เป็น 32MB ทำให้มั่นใจได้ถึงการกระจายอำนาจและความปลอดภัยในขณะที่ บรรลุการขยายตัวที่สูงขึ้น
• **ค่าธรรมเนียมต่ำ: **นักวิเคราะห์ของ Bernstein แสดงให้เห็นว่า Proto-dank-sharding สามารถลดค่าธรรมเนียมของเครือข่ายเลเยอร์ 2 ได้ถึง 10-100 เท่าของระดับปัจจุบัน
• ข้อมูลจริง:
• เครือข่ายการทดสอบตรงข้ามได้ปรับใช้ 4844 ซึ่งสามารถลดค่าใช้จ่ายในการยกเลิกได้ 50% ตามข้อสังเกตในปัจจุบัน
• โซลูชันทางเทคนิค DA ของ EigenLayer ไม่เปิดเผยมากเกินไปในการประเมินข้อมูล
• พูดอย่างเคร่งครัด Celestia มีส่วนเกี่ยวข้องกับ Ethereum เพียงเล็กน้อย และไม่สามารถประเมินค่าใช้จ่าย DA ได้ในขณะนี้ ขึ้นอยู่กับโซลูชันทางเทคนิคเฉพาะ
• วิธีแก้ปัญหาของ Ethstorage คือการอัปโหลดใบรับรองพื้นที่เก็บข้อมูล Layer2 และค่าใช้จ่าย DA อาจลดลงเหลือ 5% ของต้นฉบับ
• Topia คาดว่าจะลดค่าใช้จ่ายได้ 100~1,000 เท่า เนื่องจาก Danksharding เครือข่ายหลักยังต้องคำนึงถึงความปลอดภัยและความเข้ากันได้กับการแพร่ภาพเครือข่าย P2P เลเยอร์ 1
• **DA****โซลูชัน: Danksharding (โซลูชันการแบ่งส่วนสำหรับการขยายตัวของ Ethereum) ในปัจจุบัน หากการขยายตัวดำเนินต่อไป ภาระของโหนดอาจใหญ่เกินไป (****16mb **** ด้านบน) และความพร้อมใช้งานของข้อมูลไม่เพียงพอ (30 วันที่ถูกต้อง) สารละลาย: **
• การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูล (Data การสุ่มตัวอย่างความพร้อมใช้งาน) - ลดภาระของโหนด
• ตัดข้อมูลใน Blob ออกเป็น data fragments และให้โหนดเปลี่ยนจากการดาวน์โหลดข้อมูล Blob เป็นการสุ่มตรวจชิ้นส่วนข้อมูล Blob เพื่อให้ชิ้นส่วนข้อมูล Blob กระจายอยู่ในแต่ละโหนดของ Ethereum แต่ข้อมูล Blob ที่สมบูรณ์นั้น เก็บไว้ในบัญชีแยกประเภททั้งหมดของ Ethereum ข้อสันนิษฐานคือโหนดต้องเพียงพอและกระจายอำนาจ
• DAS ใช้เทคโนโลยีสองอย่าง: ลบรหัส (Erasure การเข้ารหัส) และ KZG Polynomial Commitment (KZG ความมุ่งมั่น);
• Proposer-Packager Separation (PBS)——แก้ไขปัญหาการแบ่งงานของโหนด ให้โหนดที่มีการกำหนดค่าประสิทธิภาพสูงรับผิดชอบในการดาวน์โหลดข้อมูลทั้งหมดสำหรับการกระจายการเข้ารหัส และให้โหนดที่มีการกำหนดค่าประสิทธิภาพต่ำรับผิดชอบ ตรวจสอบการตรวจสอบจุด
• โหนดที่มีการกำหนดค่าประสิทธิภาพสูงสามารถเป็น builder ได้ builder ต้องการเพียงดาวน์โหลดข้อมูล blob เพื่อเข้ารหัสและสร้างบล็อก (Block) จากนั้นเผยแพร่ไปยังโหนดอื่นเพื่อตรวจสอบจุด สำหรับ builders เนื่องจากปริมาณข้อมูลการซิงโครไนซ์ และความต้องการแบนด์วิธสูง ดังนั้นมันจึงค่อนข้างรวมศูนย์
• โหนดที่มีการกำหนดค่าประสิทธิภาพต่ำสามารถกลายเป็นผู้เสนอ (Proposer) ได้ และผู้เสนอจะต้องตรวจสอบความถูกต้องของข้อมูลและสร้างและออกอากาศส่วนหัวของบล็อกเท่านั้น (Block ส่วนหัว) แต่สำหรับผู้เสนอ (Proposer) ปริมาณข้อมูลการซิงโครไนซ์และความต้องการแบนด์วิธต่ำ ดังนั้นจะมีการกระจายอำนาจ
• รายการต่อต้านการเซ็นเซอร์ (crList) - แก้ปัญหาที่ผู้จัดทำแพคเกจสามารถเพิกเฉยต่อธุรกรรมบางรายการโดยจงใจ และสุ่มเรียงลำดับและแทรกธุรกรรมที่พวกเขาต้องการได้รับ MEV เนื่องจากอำนาจการตรวจสอบที่มากเกินไป
• ก่อนที่ผู้สร้าง (Builder) จะบล็อกธุรกรรม ผู้เสนอ (Proposer) จะเผยแพร่รายการที่ต่อต้านการทบทวน (crList) ก่อน ซึ่งมีธุรกรรมทั้งหมดใน mempool
• ผู้สร้าง (Builder) สามารถเลือกที่จะจัดแพ็คเกจและจัดเรียงธุรกรรมใน crList เท่านั้น ซึ่งหมายความว่าผู้สร้างไม่สามารถแทรกธุรกรรมส่วนตัวของเขาเองเพื่อรับ MEV และเขาไม่สามารถปฏิเสธธุรกรรมโดยเจตนาได้ (เว้นแต่ Gas วงเงินเต็ม);
• หลังจากบรรจุแล้ว Builder จะออกอากาศเวอร์ชันสุดท้ายของรายการธุรกรรมแฮชไปยังผู้เสนอ และผู้เสนอเลือกหนึ่งในรายการธุรกรรมเพื่อสร้างส่วนหัวของบล็อก (บล็อก ส่วนหัว) และออกอากาศ;
• เมื่อโหนดซิงโครไนซ์ข้อมูล โหนดจะได้รับส่วนหัวของบล็อกจากผู้เสนอ (Proposer) จากนั้นจึงขอรับเนื้อหาของบล็อกจากผู้ทำแพ็กเกจ (Builder) เพื่อให้แน่ใจว่าเนื้อหาของบล็อกเป็นเวอร์ชันสุดท้ายที่เลือก
• Dual-slot PBS - แก้ปัญหาที่ผู้ทำแพคเกจแบบรวมศูนย์เริ่มรวมศูนย์มากขึ้นเรื่อย ๆ โดยการซื้อ MEV
• ใช้โหมดการเสนอราคาเพื่อกำหนดบล็อก:
• ตัวสร้าง (ตัวสร้าง) สร้างส่วนหัวของบล็อกของรายการธุรกรรมหลังจากได้รับ crList และราคาเสนอ
• ผู้เสนอ (ผู้เสนอ) เลือกส่วนหัวของบล็อกและตัวสร้าง (ตัวสร้าง) ที่เสนอราคาสำเร็จในที่สุด และผู้เสนอจะได้รับค่าธรรมเนียมการประมูลแบบไม่มีเงื่อนไข (โดยไม่คำนึงว่าบล็อกที่ถูกต้องจะถูกสร้างขึ้นหรือไม่)
• คณะกรรมการตรวจสอบ (คณะกรรมการ) ยืนยันส่วนหัวของบล็อกที่ชนะ
• ผู้สร้างเปิดเผยเนื้อหาของบล็อกที่ชนะ
• คณะกรรมการตรวจสอบ (คณะกรรมการ) ยืนยันเนื้อหาของบล็อกที่ชนะและดำเนินการลงคะแนนเสียงยืนยัน (หากบล็อกผ่าน บล็อกจะถูกผลิตขึ้น หากผู้บรรจุหีบห่อจงใจไม่ให้บล็อกตัว ก็จะถือว่าบล็อกนั้น ไม่ได้อยู่).
• ความหมาย:
• ประการแรก ตัวสร้าง (ตัวสร้าง) มีอำนาจมากกว่าในการจัดทำแพ็คเกจธุรกรรม แต่ข้อแรก crList ที่กล่าวถึงข้างต้นจะจำกัดความเป็นไปได้ในการแทรกธุรกรรมชั่วคราว และประการที่สอง หากตัวสร้าง (ตัวสร้าง) ต้องการทำกำไรโดยการเปลี่ยนลำดับของการทำธุรกรรม จากนั้นจำเป็นต้องจ่ายค่าใช้จ่ายในการประมูลจำนวนมากในตอนเริ่มต้นเพื่อให้แน่ใจว่าสามารถได้รับคุณสมบัติของหัวบล็อก จากนั้นกำไร MEV ที่ได้รับจะลดลงอีก และโดยรวมแล้วจะมีผลกระทบต่อค่าเฉลี่ยและมูลค่าที่แท้จริง ของการได้รับ MEV;
• อย่างไรก็ตาม ในระยะแรก คนจำนวนน้อยเท่านั้นที่อาจกลายเป็นผู้แบ่งบรรจุ (เมื่อพิจารณาถึงปัญหาประสิทธิภาพของโหนด) ในขณะที่คนส่วนใหญ่กลายเป็นผู้เสนอเท่านั้น ซึ่งอาจนำไปสู่การรวมศูนย์ต่อไปได้ ในขณะเดียวกัน จำนวนผู้แบ่งบรรจุก็น้อยมาก ในกรณีของ นักขุดที่มีประสบการณ์บางรายที่มีความสามารถด้าน MEV จะมีแนวโน้มที่จะประมูลได้สำเร็จ ซึ่งจะส่งผลต่อผลกระทบของโซลูชัน MEV จริงมากกว่า
• มีผลกระทบกับโซลูชัน MEV บางอย่างที่ใช้การประมูล MEV
• ความหมาย:
• สพป 4844 อันที่จริงแล้วเป็นเวอร์ชันที่เรียบง่ายสุด Danksharding**: **มีอินเทอร์เฟซแอปพลิเคชันเดียวกันกับ Danksharding รวมถึง opcode ใหม่ที่เรียกว่า Data แฮช และวัตถุข้อมูลใหม่ที่เรียกว่าไบนารี วัตถุขนาดใหญ่ นั่นคือ Blob;
• proto-danksharding ** ใช้เพื่อดำเนินการให้เสร็จสมบูรณ์ ** Danksharding ** ข้อมูลจำเพาะ "วงเล็บ"** (** เป็นรูปแบบธุรกรรมและกฎการตรวจสอบ****) * * ข้อเสนอ: อย่างไรก็ตาม ยังไม่มีการนำการแบ่งส่วนย่อยมาใช้ และผู้ตรวจสอบและผู้ใช้ทั้งหมดยังคงต้องตรวจสอบความพร้อมใช้งานของข้อมูลที่สมบูรณ์โดยตรง
• เหตุใดจึงเลือกมุมมองระยะยาว proto-danksharding ไม่ใช่ EIP 4488 ** ช่วยลดค่าธรรมเนียมของ ** layer2 ** โดยตรง เนื่องจากจำเป็นต้องมีการปรับแต่งเพียงเล็กน้อยเมื่ออัปเกรดเป็นชิ้นส่วนทั้งหมดในอนาคต**:
• สพป ข้อแตกต่างหลักในทางปฏิบัติระหว่าง 4488 และ proto-danksharding คือ EIP-4488 พยายามลดการเปลี่ยนแปลงที่ Ethereum ต้องทำในวันนี้ให้น้อยที่สุด ในขณะที่ proto-danksharding ทำการเปลี่ยนแปลง Ethereum มากขึ้นในวันนี้เพื่อที่จะอัปเกรดเป็น Ethereum ในอนาคต การเปลี่ยนแปลงที่น้อยที่สุดคือ จำเป็นสำหรับการชาร์ดเวอร์ชันเต็ม
• แม้ว่ามันจะเป็นงานที่ซับซ้อนมากในการทำให้การแบ่งส่วนข้อมูลเสร็จสมบูรณ์ (ด้วยการสุ่มตัวอย่างความพร้อมของข้อมูล ฯลฯ) และยังมีงานอีกมากที่ต้องทำหลังจากนำการแบ่งโปรโตแดนส์มาใช้ ความซับซ้อนเหล่านี้จะถูกควบคุมในชั้นฉันทามติ เมื่อใช้งาน proto-danksharding แล้ว ทีมไคลเอนต์เลเยอร์การดำเนินการ ผู้พัฒนาชุดรวม และผู้ใช้ไม่จำเป็นต้องทำงานเพิ่มเติมใดๆ เพื่อเปลี่ยนไปใช้การแบ่งส่วนทั้งหมด
• เพื่อให้ได้การแบ่งกลุ่มที่สมบูรณ์ จำเป็นต้องดำเนินการจริงของ ** PBS, การพิสูจน์การมอบหมายสิทธิ์และการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลให้เสร็จสมบูรณ์ แต่การแก้ไขดังกล่าวจะเข้มข้นใน ** CL * * เลเยอร์ นักพัฒนาไม่จำเป็นต้องปรับใหม่ **: 4844 กำลังใช้ประเภทธุรกรรมใหม่ ซึ่งเหมือนกันทุกประการกับรูปแบบธุรกรรม ตรรกะการตรวจสอบความถูกต้องข้ามฉันทามติ และตรรกะเลเยอร์การดำเนินการที่จำเป็นในชาร์ดทั้งหมด และยัง ได้รับมาสำหรับ blobs การปรับราคาก๊าซอิสระด้วยตนเอง เพื่อให้บรรลุการแบ่งส่วนที่สมบูรณ์ในอนาคต จำเป็นต้องดำเนินการใช้งานจริงของ PBS การพิสูจน์การมอบหมาย และการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลให้เสร็จสมบูรณ์ แต่การปรับเปลี่ยนเหล่านี้อยู่ที่ชั้น CL เท่านั้น และ ไม่ต้องการ EL Layer หรือ Rollup Developer ในการแก้ไข ซึ่งสะดวกต่อการพัฒนา By.

ตามด้วยSELFDESTRUCT เอาออก***,EIP-6780 ในที่สุดก็ได้รับการพิจารณาว่าเป็นทางออกที่เหมาะสมที่สุด แต่ผู้พัฒนาใน 26** ใน ประชุม tim** เสนอให้เพิ่ม opcode อื่นในข้อเสนอนี้SETCODE เพื่อให้บัญชีแบบเป็นโปรแกรมยังคงได้รับการอัปเดต***

** การทำลายตนเอง การกำจัด** EIP-6780**：**X

• พื้นหลัง:
• เมื่อวันที่ 21 มีนาคม Vitalik เสนอว่า SELFDESTRUCT ทำอันตรายมากกว่าดีต่อระบบนิเวศของ Ethereum เหตุผลหลักคือเป็นสิ่งเดียวที่สามารถเปลี่ยนอ็อบเจกต์สถานะจำนวนไม่สิ้นสุดในบล็อกเดียวซึ่งส่งผลให้รหัสสัญญาเปลี่ยนไป และสามารถใช้ได้โดยไม่ต้องได้รับความยินยอมจากบัญชีสามารถแก้ไขรหัสการดำเนินการของยอดเงินในบัญชีซึ่งมีอันตรายแอบแฝงอย่างมากในความปลอดภัยของ Ethereum**
• วิธีเดียวที่จะลบสัญญาออนไลน์คือ SELFDESTRUCT หากคุณเรียกใช้ฟังก์ชันทำลายตัวเองในสัญญา คุณสามารถทำลายสัญญาได้เอง Ethereum ที่เก็บไว้ในสัญญาจะถูกส่งไปยังที่อยู่ที่กำหนดไว้ รหัสที่เหลือและตัวแปรหน่วยเก็บข้อมูลจะถูกลบออกในเครื่องสถานะ ในความเป็นจริง การทำลายสัญญาฟังดูดีในทางทฤษฎี แต่จริงๆ แล้วเป็นอันตรายมาก แม้ว่าฟังก์ชัน selfdestruct** สามารถช่วยนักพัฒนาในการลบสัญญาอัจฉริยะและโอนยอดคงเหลือในสัญญาไปยังที่อยู่ที่ระบุในกรณีฉุกเฉิน แต่อาชญากรยังใช้คุณลักษณะนี้ ทำให้เป็นวิธีการโจมตี **
• ในการประชุมนักพัฒนาหลักเมื่อวันที่ 13, 23 เมษายน ข้อเสนอสี่ข้อเกี่ยวกับ SELFDESTRUCT ได้รับการแนะนำให้เข้าร่วมในการอภิปราย ได้แก่ 6780, 4758, 6046 และ 6190 และ EIP ที่ตามมา 6780 ถูกตั้งค่าเป็นข้อเสนอสุดท้าย
• บทนำ: selfdestruct เป็นปุ่มฉุกเฉินของสัญญาอัจฉริยะ ซึ่งจะทำลายสัญญาและโอน ETH ที่เหลือไปยังบัญชีที่กำหนด
• สพป 6780: ปิดใช้งาน SELFDESTRUCT เว้นแต่ว่าพวกเขาจะอยู่ในธุรกรรมเดียวกันในสัญญา
• อัปเดต: เมื่อวันที่ 26 พฤษภาคม ทิมเสนอว่านอกเหนือจากการลบ SELFDESTRUCT แล้ว ให้เพิ่ม opcode อื่น - SETCODE เพื่อให้บัญชีแบบเป็นโปรแกรมยังคงได้รับการอัปเดต (นั่นคือมีการเพิ่มฟังก์ชันการอัพเดท และคุณสมบัติในสัญญาอัจฉริยะได้รับการอัพเดทโดยวิธีการอัพเดท/อัพเกรด) นี่คือการดูดซับของ EIP ข้อดีของ 4758 ซึ่งสามารถให้ห้อง dapp ในการอัพเกรด

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

สามข้อเสนอด้านล่างนี้เป็นข้อเสนอเกี่ยวกับ SELFDESTRUCT ที่ถูกลบในภายหลังในปี 23********4 *** 6780 ได้รับเลือกอย่างเป็นทางการในการประชุมนักพัฒนาหลักเมื่อวันที่ **28 และอีกสามข้อเสนอถูกละทิ้ง เหตุผล คือในที่สุดทีมพัฒนา Ethereum ก็ต้องการที่จะลบ opcode SELFDESTRUCT ออกทั้งหมด และข้อเสนอสามข้อต่อไปนี้ส่วนใหญ่จะได้รับการแก้ไขโดยการแทนที่ ***

• EIP-4758 (เลิกใช้แล้ว): ปิดใช้งาน SELFDESTRUCT โดยเปลี่ยน SELFDESTRUCT เป็น SENDALL ซึ่งจะคืนทุนทั้งหมดให้กับผู้โทร (ส่ง ether ทั้งหมดในบัญชีไปยังผู้โทร) แต่จะไม่ลบรหัสหรือที่เก็บข้อมูลใดๆ
• เหตุผล: เช่นเดียวกับข้างต้น การจัดการรหัส SELFDESTRUCT ก่อนหน้านี้จำเป็นต้องเปลี่ยนแปลงสถานะบัญชีอย่างครอบคลุม เช่น การลบรหัสและพื้นที่เก็บข้อมูลทั้งหมด สิ่งนี้ทำให้เกิดความยุ่งยากในการใช้ Verkle tree ในอนาคต: แต่ละบัญชีจะถูกจัดเก็บไว้ในรหัสบัญชีที่แตกต่างกันจำนวนมากซึ่งจะไม่เชื่อมโยงกับบัญชีรูทอย่างชัดเจน
• เปลี่ยน:
• Opcode SELFDESTRUCT เปลี่ยนชื่อเป็น SENDALL ตอนนี้ย้ายเฉพาะ ETH ทั้งหมดในบัญชีไปยังผู้โทร แผนนี้จะไม่ทำลายโค้ดและที่เก็บข้อมูลอีกต่อไป หรือเปลี่ยนตัวเลขสุ่ม
• การคืนเงินทั้งหมดที่เกี่ยวข้องกับ SELFDESTRUCT ถูกลบแล้ว
• ความหมาย:
• รักษาฟังก์ชันดั้งเดิมไว้เมื่อเทียบกับ EIP-6780 เนื่องจากบางแอปพลิเคชันยังคง/จำเป็นต้องใช้รหัส SELFDESTRUCT
• EIP-6046 (เลิกใช้แล้ว): แทนที่ SELFDESTRUCT ด้วย DEACTIVATE เปลี่ยน SELFDESTRUCT เพื่อไม่ลบคีย์การจัดเก็บและใช้ค่าพิเศษในบัญชี nonce เพื่อระบุการปิดใช้งาน
• เหตุผล: เช่นเดียวกับข้างต้น เมื่อใช้แผนผัง Verkle บัญชีจะถูกจัดระเบียบแตกต่างกัน: คุณสมบัติของบัญชี (รวมถึงพื้นที่เก็บข้อมูล) จะมีคีย์แยกต่างหาก แต่จะไม่สามารถสำรวจและค้นหาคีย์ที่ใช้ทั้งหมดได้ การจัดการรหัส SELFDESTRUCT ก่อนหน้านี้จำเป็นต้องมีการเปลี่ยนแปลงอย่างมากในสถานะบัญชี ทำให้ยากต่อการใช้ SELFDESTRUCT ใน Verkle tree ต่อไป
• เปลี่ยน:
• เปลี่ยนกฎที่แนะนำโดย EIP-2681 เพื่อให้ nonce ที่เพิ่มขึ้นปกติมีขอบเขตเป็น 2^64-2 แทน 2^64-1;
• SELFDESTRUCT เปลี่ยนเป็น:
• อย่าลบคีย์การจัดเก็บใด ๆ และปล่อยให้บัญชีอยู่กับที่
• โอนยอดเงินในบัญชีไปยังเป้าหมาย **, **ตั้งค่ายอดเงินในบัญชีเป็น 0
• ตั้งค่าบัญชี nonce เป็น 2^64-1
• ไม่มีการคืนเงินตั้งแต่ EIP-3529;
• กฎที่เกี่ยวข้อง SELFDESTRUCT ของ EIP-2929 ยังคงไม่เปลี่ยนแปลง
• ความหมาย:
• ข้อเสนอนี้มีความยืดหยุ่นมากกว่าการลบ SELFDESTRUCT โดยตรงอื่นๆ
• EIP-6190 (เลิกใช้แล้ว): เปลี่ยน SELFDESTRUCT เข้ากันได้กับ Verkle เพื่อให้มีการเปลี่ยนแปลงสถานะในจำนวนจำกัดเท่านั้น
• เหตุผล: เช่นเดียวกับข้างต้น เมื่อใช้แผนผัง Verkle บัญชีจะถูกจัดระเบียบแตกต่างกัน: คุณสมบัติของบัญชี (รวมถึงพื้นที่เก็บข้อมูล) จะมีคีย์แยกต่างหาก แต่จะไม่สามารถสำรวจและค้นหาคีย์ที่ใช้ทั้งหมดได้ การจัดการรหัส SELFDESTRUCT ก่อนหน้านี้จำเป็นต้องมีการเปลี่ยนแปลงอย่างมากในสถานะบัญชี ทำให้ยากต่อการใช้ SELFDESTRUCT ใน Verkle tree ต่อไป
• เปลี่ยน: แทนที่จะทำลายสัญญาเมื่อสิ้นสุดธุรกรรม สิ่งต่อไปนี้จะเกิดขึ้นเมื่อสิ้นสุดธุรกรรมที่เรียกว่า:
• รหัสสัญญาถูกกำหนดเป็น 0x1 และตัวเลขสุ่มถูกกำหนดเป็น 2^64-1
• ช่องเก็บข้อมูลช่องที่ 0 ของสัญญาถูกตั้งค่าเป็นสัญญาโดยใช้ CREATE opcode ( keccak256(contractAddress, nonce)) จะออกเมื่อที่อยู่. ตัวเลขสุ่มคือ 2^64-1 เสมอ
• หากสัญญาทำลายตัวเองหลังจากโอนสายโดยสัญญานามแฝงตั้งแต่หนึ่งสัญญาขึ้นไป ให้ตั้งค่าช่องเก็บข้อมูลที่ 0 ของสัญญานามแฝงไปยังที่อยู่ที่คำนวณในขั้นตอนที่ 2
• ยอดคงเหลือของสัญญาจะถูกโอนไปยังที่อยู่ด้านบนสุดของสแตกทั้งหมด
• ด้านบนของสแต็คถูกโผล่ออกมา
• ความหมาย:
• ออกแบบมาเพื่อให้ SELFDESTRUCT สร้างต้นไม้ Verkle ในภายหลังโดยมีการเปลี่ยนแปลงเพียงเล็กน้อย
• ค่าแก๊สเพิ่มขึ้นเมื่อใช้ EIP-2929

ตามมาด้วยEIP 1153*** ในขณะที่ประหยัดก๊าซ ปูทางสำหรับการออกแบบพื้นที่จัดเก็บในอนาคต***

สพฐ 1153X

• บทสรุป: opcodes ร้านค้าชั่วคราว เพิ่ม opcodes สำหรับจัดการสถานะที่ทำงานเหมือนกับร้านค้า แต่ละทิ้งหลังจากการทำธุรกรรมแต่ละครั้ง
• เหตุผล:
• การดำเนินธุรกรรมใน Ethereum สามารถสร้างเฟรมการดำเนินการที่ซ้อนกันหลายเฟรม แต่ละเฟรมสร้างโดยคำสั่ง CALL (หรือที่คล้ายกัน) สามารถป้อนสัญญาอีกครั้งในธุรกรรมเดียวกัน ซึ่งในกรณีนี้มีมากกว่าหนึ่งเฟรมที่อยู่ในสัญญาเดียว
• ปัจจุบัน เฟรมเหล่านี้สามารถสื่อสารได้สองวิธี: อินพุต/เอาต์พุตผ่านคำสั่ง CALL และผ่านการอัปเดตร้านค้า การสื่อสารผ่าน I/O จะไม่ปลอดภัยหากมีเฟรมเวิร์กขั้นกลางที่เป็นของสัญญาอื่นที่ไม่น่าเชื่อถือ
• ด้วยการกลับเข้าใหม่ ล็อคเป็นตัวอย่าง ไม่สามารถพึ่งพาเฟรมระดับกลางในการสื่อสารสถานะของการล็อค: การสื่อสาร SSTORE SLOAD ผ่านพื้นที่จัดเก็บมีราคาแพง และพื้นที่จัดเก็บชั่วคราวเป็นโซลูชันเฉพาะและประหยัดน้ำมันสำหรับปัญหาการสื่อสารระหว่างเฟรม
• เปลี่ยน: เพิ่ม opcodes ใหม่สองตัว TLOAD ( 0xb3 ) และ TSTORE ( 0xb4 ) ใน EVM
• ที่เก็บข้อมูลชั่วคราวเป็นแบบส่วนตัวสำหรับสัญญาที่เป็นเจ้าของ เช่นเดียวกับที่เก็บข้อมูลถาวร เฉพาะเฟรมเวิร์กของสัญญาที่เป็นเจ้าของเท่านั้นที่สามารถเข้าถึงที่เก็บข้อมูลชั่วคราวได้ เมื่อเข้าถึงที่เก็บข้อมูล เฟรมทั้งหมดจะเข้าถึงที่เก็บข้อมูลชั่วคราวเดียวกันในลักษณะเดียวกับที่เก็บข้อมูลถาวร แต่แตกต่างจากหน่วยความจำ
• กรณีการใช้งานที่เป็นไปได้:
• การกลับเข้ามาใหม่ ล็อค;
• ที่อยู่ CREATE2 บนเครือข่ายที่คำนวณได้: พารามิเตอร์ตัวสร้างถูกอ่านจากสัญญาโรงงาน แทนที่จะส่งผ่านเป็นส่วนหนึ่งของแฮชรหัสเริ่มต้น
• การอนุมัติ EIP-20 ธุรกรรมเดียว เช่น #temporaryApprove(address อะไรต่อมิอะไรจำนวน uint256);
• สัญญาค่าธรรมเนียมการโอน: จ่ายค่าธรรมเนียมให้กับสัญญาโทเค็นเพื่อปลดล็อกการโอนระหว่างการทำธุรกรรม
• โหมด "จนถึง": อนุญาตให้ผู้ใช้ดำเนินการทั้งหมดโดยเป็นส่วนหนึ่งของการเรียกกลับ และตรวจสอบว่า "จนถึง" มีความสมดุลในตอนท้ายหรือไม่
• ข้อมูลเมตาของการโทรพร็อกซี: ส่งผ่านข้อมูลเมตาเพิ่มเติมเพื่อดำเนินการตามสัญญาโดยไม่ต้องใช้ข้อมูลการโทร เช่น ค่าของพารามิเตอร์ตัวสร้างพร็อกซีที่ไม่เปลี่ยนรูป
• ความหมาย:
• ประหยัด แก๊ส** ด้วยความเรียบง่าย** แก๊ส กฎการเรียกเก็บเงิน
• ** แก้ปัญหาการสื่อสารระหว่างเฟรม **
• ** อย่าเปลี่ยนความหมายของการดำเนินการที่มีอยู่ **
• ไม่ต้องล้างถังเก็บหลังใช้งาน
• ** การออกแบบพื้นที่จัดเก็บในอนาคต (เช่น ต้นไม้ ** Verkle **) ไม่จำเป็นต้องพิจารณาขอคืนเงินสำหรับพื้นที่จัดเก็บทันที **

ตามด้วย 4788 สามารถลดสมมติฐานความน่าเชื่อถือในกลุ่มจำนำ**

สพฐ 4788**：***X

• บทนำ: Beacon block root ใน EVM *อัปเดต: ในการประชุมนักพัฒนาเมื่อวันที่ 15, 23 มิถุนายน นักพัฒนาเสนอให้ทำการเปลี่ยนแปลงโค้ดเพื่อปรับปรุงประสบการณ์ staker EIP นี้จะเปิดเผยรากของ beacon chain block ซึ่งมีข้อมูลสถานะห่วงโซ่ภายใน EVM สำหรับการพัฒนา DApp ผู้เขียนไว้วางใจ ลดการเข้าถึง
• เปลี่ยน: คอมมิตรูทแฮชของบล็อกเชนบีคอนแต่ละอันในส่วนหัวเพย์โหลดการดำเนินการที่เกี่ยวข้อง เก็บรูทเหล่านั้นในสัญญาในสถานะการดำเนินการ และเพิ่ม opcode ใหม่เพื่ออ่านสัญญานั้น
• นัยสำคัญ: นี่คือข้อเสนอการแก้ไขโค้ดที่เสนอให้ปรับเปลี่ยน Ethereum Virtual Machine (EVM) เพื่อให้สามารถเปิดเผยสถานะชั้นสัญญา (CL) รูทข้อมูลที่ชั้นการดำเนินการ (EL) สามารถทำให้การสื่อสารระหว่างโปรโตคอลและแอปพลิเคชันต่างๆ ในเครือข่าย Ethereum มีประสิทธิภาพและปลอดภัยมากขึ้น** **อนุญาตให้มีการออกแบบที่ไม่น่าเชื่อถือมากขึ้นสำหรับโปรโตคอล Stake Pool, Bridging และ Restake

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

สพฐ 5656X

• บทนำ: อสม

• คำสั่งคัดลอกหน่วยความจำ

• อัปเดต: 09.06.23 ทีมพัฒนาระบุว่าพวกเขาถูกแบ่งใน MCOPY ในตอนแรกเนื่องจากในขณะที่แก้ปัญหาด้านความปลอดภัย พวกเขายังคงกังวลเกี่ยวกับการเพิ่มแบนด์วิธในการใช้งาน + การทดสอบที่จำเป็นสำหรับการอัปเกรด แต่ในที่สุดก็ตกลงที่จะรวม EIP แต่จะถูกพิจารณาให้ลบหากผู้พัฒนาพบปัญหาด้านความจุในการทดสอบหรือในฝั่งไคลเอ็นต์ ดังนั้น MCOPY** จึงอยู่ในสถานะรวมชั่วคราวในการอัปเกรด Cancun **
• เปลี่ยนแปลง: จัดเตรียมคำสั่ง EVM ที่มีประสิทธิภาพเพื่อคัดลอกขอบเขตหน่วยความจำ
• ความสำคัญ: การคัดลอกหน่วยความจำเป็นการดำเนินการพื้นฐาน แต่มีค่าใช้จ่ายสำหรับการติดตั้งบน EVM
• ด้วยความพร้อมใช้งานของคำสั่ง MCOPY ทำให้สามารถคัดลอกคำและประโยครหัสได้แม่นยำยิ่งขึ้น ซึ่งจะเพิ่มประสิทธิภาพการคัดลอกหน่วยความจำประมาณ 10.5% ซึ่งมีประโยชน์มากสำหรับการดำเนินการที่ต้องใช้การคำนวณจำนวนมาก
• นอกจากนี้ยังเป็นประโยชน์สำหรับคอมไพเลอร์ในการสร้างไบต์โค้ดที่มีประสิทธิภาพมากขึ้นและมีขนาดเล็กลง
• มันสามารถประหยัดค่าก๊าซที่คอมไพล์ข้อมูลประจำตัวได้จำนวนหนึ่ง แต่ไม่สามารถส่งเสริมการใช้งานส่วนนี้ได้อย่างแท้จริง

รายการสั้น****EIP

ในวันที่ 236 เดือน15** การประชุมฉันทามติของนักพัฒนาได้กล่าวถึงใน *** ซึ่ง EIP** โดยมีศูนย์กลางอยู่ที่ CL รวมอยู่ใน Deneb โดยที่ **** ** สพป 6988******、EIP 7044、******EIP 7045 *** *** ขอเสนอเข้าร่วม ***

สพฐ 6988**：***X

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

สพฐ 7044**：***X

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

สพฐ 7045**：***X

• บทนำ: พินัยกรรมรับรอง ช่วงการรวมสล็อตขยายจากหน้าต่างเลื่อนของหนึ่งยุคเป็นสองยุค
• ความสำคัญ: เพิ่มความปลอดภัยเครือข่าย

ลบการวิเคราะห์ของ EIP

ใน* วันที่ 29******************************* *********************************************** ใน ** 160********** ACDE****** การประชุมของ Ethereum, EVMMAX และ **** EOF **** ได้รับการยืนยันว่าถูกลบออกจากการอัปเกรดนี้ การเปลี่ยนแปลงที่เกี่ยวข้องกับ EOF* อาจถูกนำมาใช้ในการอัปเกรดรายวันถัดไป***

**อีวีเอ็มแม็กซ์ EIP ***：

• บทสรุป: EVMMAX ตั้งเป้าที่จะมอบความยืดหยุ่นที่มากขึ้นให้กับการดำเนินการทางคณิตศาสตร์และรูปแบบลายเซ็นบน Ethereum ปัจจุบัน มีข้อเสนอ EVMMAX สองรายการ ข้อเสนอหนึ่งมี EOF และอีกข้อเสนอหนึ่งไม่มี EOF
• สพป 6601: ส่วนขยายทางคณิตศาสตร์แบบแยกส่วน EVM (EVMMAX)
• เปลี่ยน: เป็น EIP 5843 ซ้ำกับ EIP ความแตกต่างของ 5843 คือ:
• 6601 แนะนำประเภทส่วน EOF ใหม่ที่จัดเก็บโมดูลัส, พารามิเตอร์ Montgomery ที่คำนวณไว้ล่วงหน้า, จำนวนของค่าที่จะใช้ (ยังคงรองรับโมดูลัสที่กำหนดค่ารันไทม์ได้);
• 6601 ใช้พื้นที่หน่วยความจำแยกต่างหากสำหรับค่า EVMMAX โดยมีรหัสโหลด/จัดเก็บใหม่เพื่อย้ายค่าระหว่างหน่วยความจำ EVM<->EVMMAX
• 6601 รองรับการทำงานบนโมดูลิสูงสุด 4096 บิต (ขีดจำกัดเบื้องต้นที่กล่าวถึงใน EIP)
• ความสำคัญ: EIP-5843 แนะนำการบวก การลบ และการคูณแบบโมดูลาร์ที่มีประสิทธิภาพสำหรับ Ethereum Virtual Machine EIP-6601 การอัปเกรดเพิ่มเติมบนพื้นฐานนี้ โดยการแนะนำส่วนการตั้งค่า พื้นที่หน่วยความจำแยกต่างหาก และรหัส opcodes ใหม่ สำหรับการดำเนินการทางคณิตศาสตร์แบบโมดูลาร์ช่วยให้องค์กรดีขึ้น และความยืดหยุ่นในขณะที่รองรับโมดูลัสที่ใหญ่ขึ้นและปรับปรุงประสิทธิภาพ EVM
• ในฐานะสัญญา EVM เปิดใช้งานการคำนวณเลขคณิตเส้นโค้งวงรีบนเส้นโค้งต่างๆ (รวมถึง BLS12-381)
• MULMOD ช่วยลดต้นทุนการดำเนินการสำหรับค่าสูงถึง 256 บิตโดย 90-95% เมื่อเทียบกับ opcodes ADDMOD ที่มีอยู่
• อนุญาตให้ใช้การคอมไพล์ล่วงหน้าของ modexp เป็นสัญญา EVM
• ลดค่าใช้จ่ายในการตรวจสอบ ZKP ลงอย่างมากในฟังก์ชันแฮชเชิงพีชคณิต (เช่น MiMC/Poseidon) และ EVM
• สพป 6690：
• การเปลี่ยนแปลง: EIP-6990 เป็นข้อเสนอที่ดัดแปลงมาจาก EIP-6601 เพื่อแนะนำการดำเนินการทางคณิตศาสตร์แบบโมดูลาร์ที่เหมาะสมที่สุดให้กับ EVM โดยไม่ต้องอาศัย EOF ในขณะที่ EIP-6601 ต้องการ EIP-4750 และ EIP-3670 เป็นการอ้างอิง แต่ EIP-6990 ให้โซลูชันที่เป็นอิสระมากกว่า ให้แนวทางที่ง่ายขึ้นโดยการเอาการพึ่งพา EOF ออก
• นัยสำคัญ: ยังคงไว้ซึ่งฟังก์ชันหลักของ EIP-6601 ซึ่งสามารถดำเนินการทางคณิตศาสตร์แบบโมดูลาร์ที่ปรับให้เหมาะสมบนโมดูลัสคี่ได้ถึง 4096 บิต การลดความซับซ้อนนี้ช่วยให้สามารถใช้งานและปรับใช้ได้อย่างมีประสิทธิภาพมากขึ้น ในขณะที่ยังคงให้ประโยชน์ที่เกี่ยวข้องกับผลประโยชน์ของ EIP-6601

สอศ การเปลี่ยนแปลง**：**

• บทนำ: EOF เป็นการอัปเกรดเป็น EVM ซึ่งแนะนำมาตรฐานสัญญาใหม่และ opcodes ใหม่บางส่วน รหัสไบต์ EVM แบบดั้งเดิม (bytecode) เป็นลำดับคำสั่งที่ไม่มีโครงสร้าง ลำดับคำสั่ง) bytecode EOF แนะนำแนวคิดของคอนเทนเนอร์ ซึ่งนำ bytecode ที่มีโครงสร้างไปใช้ คอนเทนเนอร์ประกอบด้วยส่วนหัวและหลายส่วนสำหรับจัดโครงสร้างรหัสไบต์ หลังจากการอัปเกรด EVM จะสามารถดำเนินการควบคุมเวอร์ชันและเรียกใช้กฎของสัญญาหลายชุดได้ในเวลาเดียวกัน
• สพป 663：
• บทสรุป: คำแนะนำ SWAP และ DUP ไม่จำกัด
• ความสำคัญ: ด้วยการแนะนำสองคำสั่งใหม่: SWAPN และ DUPN ซึ่งแตกต่างจาก SWAP และ DUP โดยเพิ่มความลึกของสแต็กจาก 16 องค์ประกอบเป็น 256 องค์ประกอบ
• สพป 3540：
• การแนะนำ:
• ในอดีต โค้ดไบต์ EVM ที่ปรับใช้บนเชนไม่มีโครงสร้างที่กำหนดไว้ล่วงหน้า และโค้ดจะได้รับการยืนยันก่อนที่จะรันในไคลเอนต์เท่านั้น นี่ไม่ใช่แค่ต้นทุนทางอ้อม แต่ยังขัดขวางนักพัฒนาจากการแนะนำสิ่งใหม่ๆ คุณสมบัติหรือคุณสมบัติเก่าที่เลิกใช้แล้ว
• EIP นี้แนะนำคอนเทนเนอร์ที่สามารถขยายได้และควบคุมเวอร์ชันสำหรับ EVM และประกาศรูปแบบของสัญญา EOF ตามนี้ รหัสสามารถตรวจสอบได้เมื่อปรับใช้สัญญา EOF นั่นคือการสร้าง การตรวจสอบเวลา ซึ่งหมายความว่าสัญญาที่ไม่เป็นไปตามรูปแบบ EOF สามารถป้องกันไม่ให้ปรับใช้ได้ การเปลี่ยนแปลงนี้ใช้การควบคุมเวอร์ชัน EOF ซึ่งจะช่วยปิดใช้งานคำสั่ง EVM ที่มีอยู่หรือแนะนำฟังก์ชันขนาดใหญ่ (เช่น นามธรรมของบัญชี) ใน อนาคต.
• ความหมาย:
• การควบคุมเวอร์ชันเอื้อต่อการแนะนำหรือการเลิกใช้ฟังก์ชันใหม่ในอนาคต (เช่น การแนะนำนามธรรมของบัญชี)
• การแยกรหัสสัญญาและข้อมูลเป็นประโยชน์ต่อการตรวจสอบ L2 (op) ซึ่งช่วยลดต้นทุนของเครื่องมือตรวจสอบ L2 ในขณะเดียวกันการแยกรหัสสัญญาและข้อมูลยังสะดวกกว่าสำหรับการวิเคราะห์ข้อมูลแบบ on-chain เครื่องมือ
• สพป 3670：
• บทนำ: ตาม EIP-3540 จุดประสงค์คือเพื่อให้แน่ใจว่ารหัสของสัญญา EOF เป็นไปตามรูปแบบและถูกต้อง และการปรับใช้สัญญาที่ไม่เป็นไปตามรูปแบบจะถูกป้องกันโดยไม่ส่งผลกระทบต่อมรดก รหัสไบต์。
• ความสำคัญ: ตามคอนเทนเนอร์ที่เปิดตัวในปี 3540 EIP-3670 ช่วยให้มั่นใจได้ว่าโค้ดในสัญญา EOF นั้นถูกต้อง หรือป้องกันไม่ให้ใช้งาน ซึ่งหมายความว่าไม่สามารถปรับใช้ opcodes ที่ไม่ได้กำหนดในสัญญา EOF ซึ่งมีประโยชน์เพิ่มเติมจากการลดจำนวนเวอร์ชัน EOF ที่ต้องเพิ่ม
• สพป 4200：
• การแนะนำ:
• แนะนำ opcodes เฉพาะ EOF ตัวแรก: RJUMP, RJUMPI และ RJUMPV ซึ่งเข้ารหัส ปลายทางเป็นค่าทันทีที่มีการลงนาม คอมไพเลอร์สามารถใช้ JUMP opcodes ใหม่เหล่านี้เพื่อเพิ่มประสิทธิภาพต้นทุนก๊าซเมื่อปรับใช้และดำเนินการ JUMP เนื่องจากไม่จำเป็นต้องใช้ OPcode JUMP และ JUMPI ที่มีอยู่เพื่อทำ Jumpdest เวลาที่ใช้ในการวิเคราะห์ EIP นี้มีไว้สำหรับไดนามิก นอกเหนือจากการกระโดด
• เมื่อเปรียบเทียบกับการดำเนินการ JUMP แบบดั้งเดิม ข้อแตกต่างคือการดำเนินการเช่น RJUMP ไม่ได้ระบุตำแหน่งออฟเซ็ตเฉพาะ แต่ระบุตำแหน่งออฟเซ็ตสัมพัทธ์ (จากไดนามิก กระโดด -> กระโดดคงที่) เพราะหลายครั้งคงที่ การกระโดดก็เพียงพอแล้ว
• ความสำคัญ: เพิ่มประสิทธิภาพเครือข่ายและลดต้นทุน
• สพป 4750：
• ใช้ฟังก์ชันของ 4200 ไปอีกขั้น: โดยการแนะนำ CALLF opcode ใหม่สองตัวของและ RETF ใช้โซลูชันทางเลือกสำหรับสถานการณ์ที่ไม่สามารถแทนที่ด้วย RJUMP, RJUMPI และ RJUMPV เพื่อให้ JUMPDEST ไม่จำเป็นอีกต่อไปในสัญญา EOF ดังนั้นจึงห้ามใช้ไดนามิก กระโดด.
• ความสำคัญ: ปรับรหัสให้เหมาะสมโดยแบ่งรหัสออกเป็นหลายส่วน
• สพป 5450：
• ความเป็นมา: เบื้องหลังยังคงเป็นสัญญา Ethereum ที่ไม่ถูกตรวจสอบเมื่อมันถูกปรับใช้ และจะทำการตรวจสอบเพียงชุดเดียวเมื่อมันทำงาน ไม่ว่าจะเป็นสแต็กโอเวอร์โฟลว์ (ขีดจำกัดสูงสุดคือ 1024) ก๊าซเพียงพอหรือไม่ และอื่น ๆ
• เนื้อหา: เพิ่มการตรวจสอบความถูกต้องอีกครั้งสำหรับสัญญา EOF คราวนี้เป็นรอบกอง EIP นี้ป้องกันสถานการณ์ที่การปรับใช้สัญญา EOF อาจทำให้เกิดสแต็คอันเดอร์โฟลว์หรือโอเวอร์โฟลว์ (สแต็ก อันเดอร์โฟลว์/โอเวอร์โฟลว์) ด้วยวิธีนี้ ลูกค้าสามารถลดจำนวนการตรวจสอบความถูกต้องที่ทำระหว่างการดำเนินการตามสัญญา EOF
• ความสำคัญ: การปรับปรุงครั้งใหญ่คือการทำให้การตรวจสอบเหล่านี้เกิดขึ้นระหว่างการดำเนินการให้น้อยที่สุดเท่าที่จะเป็นไปได้ และการตรวจสอบเพิ่มเติมจะเกิดขึ้นเมื่อมีการปรับใช้สัญญา

5*** เดือน26************************** ************************************************** ************************************** 4844ประเภทการทำธุรกรรมที่เกี่ยวข้องเปลี่ยนจากSSZเป็นRLPหมายความว่า Cancun's two a สสส EIPs****** ดังนั้น EIPs 6475 และ 6493** ถูกย้ายออกจาก Cancun เพื่ออัพเกรด***

สพฐ 6475X

• บทนำ: EIP ข้อเสนอร่วมกับ 4844 Proto-danksharding แนะนำประเภทธุรกรรมใหม่ที่ใช้การเข้ารหัส SSZ แทนการเข้ารหัส RLP ที่ใช้โดยประเภทธุรกรรมอื่นๆ
• UPDATE: ในระหว่างการประชุม Ethereum Executive Layer Core Developers ครั้งที่ 161 มีการอภิปรายเกี่ยวกับ EIP การอภิปรายเกี่ยวกับรูปแบบการทำให้เป็นอนุกรม SSZ สำหรับ 4844 แสดงให้เห็นว่า ในตอนแรกผู้พัฒนาสนับสนุนการแนะนำรูปแบบ SSZ ซ้ำก่อนเป็น EL ผ่านธุรกรรมแบบหยด และในที่สุด นักพัฒนาวางแผนที่จะอัปเกรดประเภทธุรกรรมทั้งหมดจาก RLP เป็น SSZ แต่ด้วยเส้นทางที่ไม่ชัดเจนและแน่นอน ไม่ได้ดำเนินการในการอัปเกรด Cancun นักพัฒนาได้ทำการชั่งน้ำหนักการถอด SSZ ออกจาก EIP-4844 หลังจากการถกเถียงกันอย่างมาก ผู้พัฒนาตกลงที่จะลบ SSZ ออกจากการใช้งาน EL ของ EIP-4844** แต่จะไม่มีการลบ EIP6475**** **SSZ-> การเปลี่ยนแปลง RLP หมายความว่า SSZ ทั้งสองรายการใน Cancun ไม่จำเป็นอีกต่อไป EIP: ** ดังนั้น EIP 6475 และ 6493 จะถูกย้ายออกจาก Cancun เพื่อทำการอัพเกรด **

สพฐ 6493X

• บทนำ: รูปแบบลายเซ็นธุรกรรม SSZ EIP นี้กำหนดโครงร่างลายเซ็นสำหรับธุรกรรมที่เข้ารหัส Simple Serialization (SSZ) และจะกล่าวถึงวิธีที่โหนดควรจัดการประเภทธุรกรรม blob ที่จัดรูปแบบในรูปแบบ SSZ บน CL แต่เข้ารหัสต่างกันบน EL EIP นี้เป็นส่วนหนึ่งของการอัปเดตรูปแบบการทำให้เป็นอนุกรมของ Ethereum เพื่อความสอดคล้องข้ามเลเยอร์
• ความเป็นมา: SSZ การเปลี่ยนแปลง
• บทนำ: ง่าย SerialiZe เป็นวิธีการทำให้เป็นอนุกรมที่ใช้กับบีคอนเชน
• เอสเอส การเปลี่ยนแปลงยังรวมถึงข้อเสนอสนับสนุนอีกสามรายการ ครั้งนี้มีเพียง 6465 เท่านั้นที่ได้รับการแนะนำ
• สพป 6465: รูทการถอน SSZ กำหนด Merkle-Patricia ที่มีอยู่ การย้ายข้อผูกพันของ Trie (MPT) ไปสู่การถอนออก Simple Serialization (SSZ);
• สพป 6404 / สพป 6466：
• ทั้งคู่กำหนด Merkle-Patricia ที่มีอยู่ สัญญา Trie (MPT) กำลังอยู่ในกระบวนการย้ายไปยัง Simple Serialization (SSZ)
• EIP-6404 — รากธุรกรรม SSZ
• EIP-6466 — เกณฑ์การรับ SSZ

ทิม Beiko* แนะนำการพัฒนาในอนาคตเกี่ยวกับการขยาย Cancun ในการประชุมนักพัฒนาหลักใน 5 เดือน26*** การสนทนาคือ จำกัดเพียงห้ารายการต่อไปนี้EIP:EIP 5920,5656,7069,4788 และ 2537 ข้อเสนอติดตามผลจะถูกสร้างขึ้นภายในขอบเขตนี้ การติดตามผล EIP 5656 และ EIP 4788 ได้รับการยืนยันว่าเป็นข้อเสนอการอัพเกรดอย่างเป็นทางการ,5920,7069 และ2537 ลบออกโดยที่EIP 5920** เกิดจากความกังวลของผู้พัฒนาเกี่ยวกับผลข้างเคียงที่อาจเกิดขึ้นจากวิธีการโอน ETH** เช่นเดียวกับการให้เหตุผล การทดสอบ และการรักษาความปลอดภัยที่ยังไม่เสร็จ ดังนั้นจากการอัปเกรด ลบ. ***

สพฐ 5920**：***X

• บทนำ: opcode การชำระเงิน แนะนำ opcode PAY ใหม่สำหรับการถ่ายโอน Ethereum ซึ่งส่ง Ether ไปยังที่อยู่โดยไม่ต้องเรียกใช้ฟังก์ชันใดๆ
• เหตุผล: ในปัจจุบัน การส่งอีเธอร์ไปยังแอดเดรสจำเป็นต้องให้ผู้ใช้เรียกฟังก์ชันจากแอดเดรสนั้น ซึ่งมีปัญหาหลายประการ:
• ประการแรก จะเปิดเวกเตอร์สำหรับการโจมตีการกลับเข้ามาใหม่ เนื่องจากผู้รับสามารถโทรกลับไปยังผู้ส่งได้
• ประการที่สอง เปิดเวกเตอร์ DoS ดังนั้นฟังก์ชันพาเรนต์ต้องระวังว่าเครื่องรับอาจหมดแก๊สหรือโทรกลับ
• ประการสุดท้าย CALL opcode มีราคาแพงโดยไม่จำเป็นสำหรับการถ่ายโอนอีเธอร์แบบธรรมดา เนื่องจากต้องมีการขยายหน่วยความจำและสแต็ก การโหลดข้อมูลทั้งหมดของผู้รับ รวมถึงรหัสและหน่วยความจำ และสุดท้ายจำเป็นต้องทำการเรียก ซึ่งอาจทำสิ่งอื่นโดยไม่ได้ตั้งใจ
• เปลี่ยน:
• มีการแนะนำ opcode ใหม่: ( PAY) PAY_OPCODE โดยที่:
• ป๊อปสองค่าจากสแต็ก: addrthen val
• โอน wei จากที่อยู่การดำเนินการ val ไปยังที่อยู่ addr ถ้า addr เป็นที่อยู่ศูนย์ valwei จะถูกตั้งโปรแกรมจากที่อยู่ดำเนินการ
• ข้อผิดพลาดที่อาจเกิดขึ้น: สัญญาที่มีอยู่จะถูกใช้โดยไม่ขึ้นกับยอดคงเหลือจริงของกระเป๋า เนื่องจากเป็นไปได้ที่จะส่ง ether ไปยังที่อยู่โดยไม่ต้องเรียกใช้
• ความหมาย: save gas** **
• อัปเดต: 09.06.23 PAY ถูกลบออกจากการอัปเกรดเนื่องจากความกังวลเกี่ยวกับผลข้างเคียงที่อาจเกิดขึ้นจากวิธีการโอน ETH และการให้เหตุผล การทดสอบ และงานรักษาความปลอดภัยที่จำเป็นในการผ่านข้อเสนอ

สพฐ 7069X

• บทนำ: แก้ไขคำสั่ง CALL
• เปลี่ยนแปลง: แนะนำคำสั่งการโทรใหม่สามคำสั่ง ได้แก่ CALL2, DELEGATECALL2 และ STATICCALL2 ซึ่งมีผลในการทำให้ความหมายง่ายขึ้น มีจุดมุ่งหมายเพื่อขจัดความสามารถในการสังเกตก๊าซออกจากคำสั่งใหม่และเปิดประตูสู่สัญญาประเภทใหม่ที่ไม่ได้รับผลกระทบจากการปรับราคาใหม่
• พื้นหลัง:
• กฎข้อที่ 63/64: จำกัดความลึกของการโทรและตรวจสอบให้แน่ใจว่าผู้โทรมีน้ำมันเหลืออยู่เพื่อทำการเปลี่ยนสถานะหลังจากที่ผู้รับสายกลับมา
• ก่อนนำกฎ 63/64 มาใช้ จำเป็นต้องมีการคำนวณก๊าซที่มีอยู่ของผู้โทรที่แม่นยำขึ้นเล็กน้อย Solidity มีกฎที่ซับซ้อนที่พยายามประมาณการค่าใช้จ่ายในด้านผู้โทรในการดำเนินการเรียกเองเพื่อตั้งค่าก๊าซที่สมเหตุสมผล
• **กำลังแนะนำ **63/64 กติกา:
• ลบการตรวจสอบความลึกของการโทร;
• ตรวจสอบให้แน่ใจว่าได้สำรองก๊าซไว้อย่างน้อย 5,000 ก่อนที่จะดำเนินการพฤติกรรมที่เรียกว่า
• ตรวจสอบให้แน่ใจว่ามีก๊าซอย่างน้อย 2300 สำหรับพฤติกรรมที่เรียกว่า
• กฎการอุดหนุน: เช่นเงินอุดหนุน 2300 ที่รู้จักกันดีเมื่อสัญญาเรียกอีกสัญญาหนึ่งสัญญาที่เรียกจะได้รับ 2300 ก๊าซถูกใช้เพื่อดำเนินการอย่างจำกัดมาก (เพียงพอสำหรับการคำนวณเล็กน้อยและสร้างบันทึก แต่ไม่เพียงพอสำหรับเติมช่องจัดเก็บ) และเนื่องจากมันกำหนดปริมาณก๊าซที่แน่นอน จึงไม่มีทางที่ผู้คนจะระบุได้ว่าสิ่งเหล่านี้เป็น ตราบเท่าที่ราคาก๊าซยังสามารถปรับขึ้นได้ การคำนวณแบบใดที่รองรับก๊าซ?
• ความสำคัญ: ** ปูทางสำหรับการเปิดตัว ** EOF ** ในอนาคต และสะดวกกว่าสำหรับการดำเนินการตามสัญญาขนาดใหญ่ **
• ลบตัวเลือกแก๊ส: คำสั่งใหม่ไม่อนุญาตให้ระบุแก๊ส จำกัด แต่ใช้ "กฎ 63/64" (ส่วนใหญ่หมายถึงการกำหนดราคาก๊าซใหม่สำหรับการดำเนินการ IO จำนวนมากใน EIP-150 ซึ่งเพิ่มการใช้ก๊าซของการดำเนินงานเฉพาะ) เพื่อจำกัดก๊าซ การปรับปรุงที่สำคัญนี้ช่วยลดความยุ่งยาก กระบวนการรอบกฎ " ค่าเผื่อ" ไม่ว่าจะส่งค่าหรือไม่ก็ตาม ผู้โทรไม่จำเป็นต้องทำการคำนวณที่เกี่ยวข้องกับก๊าซ
• หลังจากแนะนำข้อเสนอใหม่ ผู้ใช้สามารถเอาชนะ Out ได้เสมอโดยส่งแก๊สมากขึ้นในการทำธุรกรรม (แน่นอนว่าขึ้นอยู่กับขีดจำกัดของบล็อกแก๊ส) ข้อผิดพลาดของแก๊ส
• ก่อนหน้านี้เมื่อมีการเพิ่มต้นทุนการจัดเก็บ (เช่น EIP-1884 เพิ่มก๊าซสำหรับ opcodes บางตัว) สัญญาบางสัญญาที่ส่งก๊าซไปยังการโทรในปริมาณที่จำกัดเท่านั้นถูกทำลายโดยกลไกการคิดต้นทุนใหม่ ก่อนหน้านี้สัญญาบางฉบับมีขีดจำกัดปริมาณก๊าซที่จำกัดอย่างถาวร แม้ว่าจะส่งก๊าซดังกล่าวไปยังการโทรย่อยก็ตาม มันก็จะไม่ได้ผล ไม่ว่าพวกเขาจะส่งก๊าซพิเศษมากเพียงใด เพราะการโทรจะจำกัด จำนวนเงินที่ส่ง
• ปูทางสู่การเปิดตัว EOF: เมื่อเปิดตัว EVM Object Format (EOF) แล้ว คำสั่งการโทรแบบเก่าสามารถถูกปฏิเสธในสัญญา EOF เพื่อให้มั่นใจว่าคำสั่งเหล่านั้นจะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงราคาก๊าซ เนื่องจากการดำเนินการเหล่านี้มีความจำเป็นในการลบความสามารถในการสังเกตก๊าซ EOF จะกำหนดให้ใช้แทนคำสั่งที่มีอยู่
• รหัสส่งคืนสถานะที่สะดวกยิ่งขึ้น: มีการแนะนำฟังก์ชันอำนวยความสะดวกที่ส่งคืนรหัสสถานะโดยละเอียดมากขึ้น: สำเร็จ (0) กู้คืน (1) ล้มเหลว (2) และสามารถขยายได้ในอนาคต

สพฐ 2537**：***X

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

ประชาสัมพันธ์ 3175 *** กล่าวถึง แต่ไม่ได้อยู่ในรายชื่อ ไม่มีการสนทนาเพิ่มเติม ***

ประชาสัมพันธ์ 3175**：***X

• บทสรุป: ข้อเสนอนี้จะป้องกันไม่ให้ผู้ตรวจสอบที่ถูกลงโทษเสนอบล็อกเมื่อถูกระงับ หากผู้ตรวจสอบความถูกต้องมากกว่า 50% ถูกลงโทษเนื่องจากพฤติกรรมที่เป็นอันตราย ผู้ตรวจสอบความถูกต้องเหล่านั้นจะยังสามารถเสนอการบล็อกได้ในขณะที่ถูกบังคับให้ลบออกจากเครือข่าย การเปลี่ยนแปลงตรรกะนี้เป็นการเปลี่ยนแปลงเลเยอร์ CL ที่ค่อนข้างน้อยซึ่งให้การป้องกัน "โหมดความล้มเหลวสูง" นักพัฒนากล่าว
• จากการประชุมฉันทามติ Ethereum Core Developers ครั้งที่ 108 เมื่อวันที่ 4 พฤษภาคม PR 3175 กำลังอยู่ในระหว่างการฟอร์แมตเป็น EIP และจะเปลี่ยนเป็น EIP-6987 ซึ่งเป็นเหตุผลด้านความปลอดภัยเพื่อป้องกันไม่ให้ Slashed Validator ถูกเลือกให้เป็นผู้เสนอบล็อก

อนาคต

จากข้อมูลข้างต้น เราได้ข้อสรุปดังต่อไปนี้:

**1.**เป้าหมายหลักของการอัปเกรด Cancun คือ การขยายความจุ ความปลอดภัย การประหยัด ก๊าซ และการทำงานร่วมกัน:

• ไม่ต้องสงสัยเลยว่าการขยายตัวเป็นสิ่งสำคัญอันดับแรก (4844);
• ความปลอดภัยและการประหยัดน้ำมันมีความสำคัญเป็นอันดับสอง (6780, 1153, 5656 และ 7045) ในขณะที่คำนึงถึงประสบการณ์ของนักพัฒนาซอฟต์แวร์
• ประการที่สามคือความสามารถในการทำงานร่วมกัน เช่น การเพิ่มประสิทธิภาพการเชื่อมต่อ การสื่อสาร และการทำงานร่วมกันระหว่าง dapps (4788, 7044 และ 6988)
• ข้อมูลที่คาดหวัง: testnet 4844 สามารถลดค่าตรงข้ามได้ 50% ของค่าใช้จ่ายในการยกเลิก; โซลูชันทางเทคนิคของ EigenLayer และ Celestia ยังไม่ได้เปิดเผยมากเกินไป และข้อมูลของพวกเขาไม่สามารถประเมินได้ Ethstorage ประมาณการว่าต้นทุนของ DA จะลดลงเหลือ 5% ของต้นฉบับ Topia คาดว่าจะลดต้นทุน โดย 100 ~ 1,000 ครั้ง

2.** แคนคูนอัพเกรด ในอนาคต 2~5 ปี Danksharding** จะเป็นช่วงทองของการพัฒนาโครงการชั้น DA***

• ชั้น ขีดจำกัดสูงสุดด้านความปลอดภัยที่ 2 ขึ้นอยู่กับเลเยอร์ DA ที่นำมาใช้ Proto-Danksharding จะได้รับประโยชน์จากโปรโตคอลการจัดเก็บข้อมูล โปรโตคอลแบบแยกส่วน
• **ประการแรก **Danksharding กลับสู่แก่นแท้ของเครื่องสถานะ Ethereum V God กล่าวว่าจุดประสงค์ของโปรโตคอลฉันทามติของ Ethereum ไม่ใช่การรับประกันการจัดเก็บข้อมูลประวัติทั้งหมดอย่างถาวร ความตั้งใจคือการจัดหากระดานข่าวตามเวลาจริงที่มีความปลอดภัยสูง และปล่อยให้มีที่ว่างสำหรับโปรโตคอลแบบกระจายอำนาจอื่นๆ สำหรับการจัดเก็บระยะยาว （เดอะ วัตถุประสงค์ของโปรโตคอลฉันทามติของ Ethereum ไม่ได้รับประกัน จัดเก็บข้อมูลย้อนหลังทั้งหมดตลอดไป ค่อนข้างมีจุดประสงค์เพื่อ จัดเตรียมกระดานข่าวตามเวลาจริงที่มีความปลอดภัยสูง และปล่อยให้มีที่ว่างสำหรับ โปรโตคอลการกระจายอำนาจอื่น ๆ เพื่อทำการจัดเก็บข้อมูลระยะยาว ）；
• **ประการที่สอง **Danksharding **ลดค่าใช้จ่ายของ **DA ** แต่ปัญหาเวลาลงจอดจริงและความพร้อมใช้งานของข้อมูลจำเป็นต้องได้รับการแก้ไขด้วย **
• DA** การลดต้นทุน: **ก่อนการอัปเดตนี้ จำเป็นต้องเรียก calldata เพื่อเผยแพร่ข้อมูลจากการรวบรวมไปยัง Ethereum main chain และค่าธรรมเนียมแก๊สสำหรับการเรียกรหัสนี้มีราคาแพงมาก ซึ่งเป็นเลเยอร์ การจ่ายเงินที่ใหญ่ที่สุดของ 2, EIP 4844 แนะนำ data blob เป็นพื้นที่ข้อมูลเพิ่มเติมเฉพาะสำหรับการยกเลิก ซึ่งจะช่วยลดต้นทุนพื้นที่จัดเก็บได้อย่างมาก จึงลดค่าใช้จ่าย DA
• เวลาลงจอดจริงนั้นนาน และการปรับปรุง ** TPS ** และลด ** ก๊าซ ** ยังมีจำกัด ดังนั้นจึงดีสำหรับ ** DA * * โครงการเลเยอร์ในการพัฒนาต่อเนื่องในภายหลัง:
• มีปัญหาเกี่ยวกับ danksharding ใน polynya ในบทความการแบ่งส่วนข้อมูลความปลอดภัยระบุว่าจะใช้เวลา 2-5 ปีในการดำเนินการ
• ** แม้ว่ามันจะตกลงสู่พื้น แต่ก็สามารถเพิ่ม ** TPS ** และลด ** ก๊าซ ** ขนาดยังคงจำกัด:**
• สพป ปัจจุบัน 4844 รองรับ 6 blobs และปัญหาการขยายตัวในอนาคตสามารถแก้ไขได้โดย Danksharding เท่านั้น
• พื้นที่บล็อก Ethereum ปัจจุบันอยู่ที่ประมาณ 200 กิโลไบต์ หลังจาก Danksharding ขนาดที่วางแผนไว้ในข้อมูลจำเพาะคือ 32 เมกะไบต์ ซึ่งเพิ่มขึ้นประมาณ 100 เท่า ปัจจุบัน TPS ของ Ethereum อยู่ที่ประมาณ 15 ในสถานะอุดมคติ มันจะอยู่ที่ประมาณ 1,500 หลังจากเพิ่มขึ้น 100 เท่า ซึ่งไม่ใช่การปรับปรุงขนาดใหญ่
• ดังนั้น ใช้เวลานานในการลงจอด ++ การเปลี่ยนแปลงที่เกิดขึ้นจริงในวงจำกัดจะได้รับประโยชน์ DA โครงการเลเยอร์ เช่น Celestia, ** Eigenda ** ** DA ** โครงการยังสามารถผ่านต้นทุนที่ถูกกว่าและเร็วกว่า ** TPS ** เพื่อแข่งขันกับ ** Danksharding ** ในอนาคต , การจัดเก็บ ETH Topia* และโครงการ DA ใหม่อื่นๆ ยังสามารถเติมเต็มช่องว่างทางการตลาดก่อนที่จะลงจอด **
• ปัญหาทางเทคนิค เช่น ปัญหาการจัดเก็บข้อมูลและความพร้อมใช้งานของข้อมูลจำเป็นต้องได้รับการแก้ไขด้วย:
• มีค่าใช้จ่ายหลักสองประการของ DA หนึ่งคือต้นทุนของแบนด์วิดท์เครือข่าย อีกอย่างคือต้นทุนของพื้นที่จัดเก็บ และ 4844 เองก็ไม่สามารถแก้ปัญหาพื้นที่เก็บข้อมูลและปัญหาแบนด์วิดท์ของบล็อกเชนได้
• Blob จะถูกจัดเก็บไว้ในเลเยอร์ฉันทามติของ Ethereum ประมาณ 3 สัปดาห์แล้วลบออก หากคุณต้องการจัดเก็บบันทึกประวัติทั้งหมดและทำให้ข้อมูลทั้งหมดพร้อมใช้งาน โซลูชันปัจจุบัน ได้แก่: dapp เก็บข้อมูลที่เกี่ยวข้องกับตัวเอง เครือข่ายพอร์ทัล Ethereum (กำลังอยู่ในระหว่างการพัฒนา) หรือโปรโตคอลของบุคคลที่สาม เช่น ตัวสำรวจบล็อก ข้อมูลประวัติใน BitTorrent หรือที่เก็บข้อมูลที่เกิดขึ้นเองโดยผู้ใช้แต่ละราย
• ดังนั้น Proto-Danksharding จะเป็นประโยชน์ต่อโปรโตคอลการจัดเก็บข้อมูล โปรโตคอลโมดูลาร์ และเครือข่ายการขยายการจัดเก็บข้อมูล L1:
• ความต้องการในการเรียกข้อมูลประวัติจะนำไปสู่ช่องทางการพัฒนาใหม่สำหรับโปรโตคอลการจัดเก็บข้อมูลแบบกระจายอำนาจหรือโปรโตคอลดัชนีของบุคคลที่สาม
• ข้อตกลงโมดูลาร์ที่ตามมาสามารถดำเนินการธุรกรรมผ่าน Rollup ความเร็วสูง ชั้นการชำระเงินที่ปลอดภัยจะรับผิดชอบในการชำระบัญชี และชั้นความพร้อมใช้งานข้อมูลที่มีต้นทุนต่ำและความจุสูงจะรับผิดชอบการรับประกัน
• เครือข่ายการขยายหน่วยเก็บข้อมูล L1 ที่ดี เช่น Eth สตอเรจซึ่งสามารถมอบโซลูชันชั้นสองสำหรับสตอเรจแบบตั้งโปรแกรมได้โดยมีต้นทุนสตอเรจที่ต่ำกว่า

**3.**สิทธิประโยชน์ในการอัปเกรด Cancun L2ความหลากหลาย, L3, RAAS และ ความพร้อมใช้งานของข้อมูลและแทร็กอื่นๆ

• การวิเคราะห์แทร็ก L2:
• Head Layer2 เช่น Arbitrum วงโคจร、OP Stack、Polygon2.0、Fractal 5 โครงการรวมถึง Scaling (ภายใต้ StarkWare) และ HyperChain (ภายใต้ zkSync) จะได้รับประโยชน์ การลดค่าธรรมเนียมการจัดเก็บโดย blob จะทำให้เลเยอร์ที่ถูกจำกัดชุดก่อนหน้า 2 ปัญหาด้านต้นทุนของการพัฒนาและการขยายขนาดได้รับการปรับปรุงอย่างมาก และปริมาณงานข้อมูลได้รับการปรับปรุงอย่างมาก หลังจากแก้ปัญหาต้นทุนแล้ว เลเยอร์หลัก 2 จะมีโอกาสที่จะปรับใช้ระบบนิเวศ L3 พร้อมกันแบบหลายสายโซ่ที่ปรับแต่งได้สูงสำหรับการทำงานเฉพาะ
• ช่องว่างของค่าใช้จ่ายในการดำเนินงานระหว่าง Layer2 ระดับที่สองและ Layer2 หลักจะลดลง ทำให้โครงการขนาดเล็กบางโครงการมีโอกาสในการพัฒนามากขึ้น เช่น Aztec, Metis, Boba, ZKspace, layer2.finance เป็นต้น
• แม้ว่าความต้องการที่แท้จริงของโครงการโมดูลาร์บล็อกเชนยังคงต้องได้รับการตรวจสอบ แต่ภาษาโปรแกรมที่หลากหลายยังคงเป็นไปได้ เช่น ภาษาซีรีส์ Cario ของ Starkware, ภาษาซีรีส์ Move, ภาษาซีรีส์ C, c++, C# และ Go ที่ Wasm รองรับ แนะนำนักพัฒนา web2 เพิ่มเติม
• การวิเคราะห์แทร็ก Raas:
• ข้อได้เปรียบของ Raas นั้นอยู่ที่การปรับแต่งระดับสูง ความต้องการที่กำหนดเอง > ต้นทุนและประสิทธิภาพที่แท้จริง ดังนั้นการลดต้นทุนจึงเป็นข้อได้เปรียบอย่างมากของชุดรวมที่ปรับแต่งเอง
• แต่ปัญหาของแทร็ก RAAS คือมันอาจจะเป็น OverHype และมีข้อสงสัยเกี่ยวกับแทร็ก RAAS เอง ** เผชิญกับการแข่งขันของ ** 5 ** หัว ** layer2 ** การเกิดขึ้นใหม่ต่างๆ ** DA ** โครงการใหม่สามารถประกอบเป็นเราต้องใส่ เครื่องหมายคำถามบนแทร็ก **
• ขั้นแรก เลเยอร์ส่วนหัว 2 ข้อได้เปรียบของการปรับใช้แอพพลิเคชั่นเชนนั้นอยู่ที่ความสมบูรณ์ของกรอบเครือข่ายและความปลอดภัยของระบบนิเวศน์ระหว่างเชน และข้อดีของ RAAS อยู่ที่การปรับแต่งและอิสระ
• อย่างไรก็ตาม อุปสรรคทางเทคนิค RAAS ของซีรี่ส์ OP และ ZK ยังไม่แข็งแกร่งในปัจจุบัน และยังคงอยู่ในขั้นเครือข่ายทดสอบในระยะสั้น และไม่มีการโต้ตอบกับผลิตภัณฑ์จริง เมื่อพิจารณาถึงความคืบหน้าที่แท้จริงของ RAAS แบบฟอร์มทางเทคนิค และ ข้อได้เปรียบทางนิเวศวิทยาของเลเยอร์ 3 ในอนาคต ความต้องการที่แท้จริงของ RAAS เป็นที่น่าสงสัย
• แผนก OP: แม้ว่า OP การอัพเกรดชั้นหินของสแต็ค + การเปิดตัว 4844 ทำให้ต้นทุนและประสิทธิภาพเพิ่มขึ้นเล็กน้อย แต่การเพิ่มขึ้นนี้ไม่น่าสนใจมากนัก
• ซีรีส์ ZK: ในปัจจุบัน โครงการชั้นนำหลายแห่งดำเนินตามเส้นทาง ZKEVM และให้ความสำคัญกับความเข้ากันได้กับ Ethereum ดังนั้นการออกแบบวงจรจึงยอมลดประสิทธิภาพบางอย่างลง และไม่ได้มีเป้าหมายเท่ากับซีรีส์ OP แต่ปัจจุบัน ZK อยู่ในตลาด RAAS ส่วนใหญ่ยังคงใช้โครงการชั้นนำ (เช่น ZkSync) เพื่อแยกห่วงโซ่ และอุปสรรคก็ยังไม่แข็งแรง
• SO, ระยะสั้น OP RAAS** **ยังมีช่องว่างสำหรับการพัฒนาก่อนที่ ** layer3 ** จะลงดิน ในระยะยาว ** ZK RAAS ** และ ** layer3 ** อาจเป็นแนวโน้มในอนาคต **
• ZK RAAS มีข้อเสียด้านต้นทุนมากกว่าหลังจาก 4844 และใช้พลังงานการประมวลผลมากกว่า OP มาก แม้ว่าค่าใช้จ่ายในการอัปโหลดไปยัง L1 จะน้อยกว่าของ OP แต่นี่เป็นเพียงส่วนน้อยเมื่อเทียบกับต้นทุนของกระบวนการพิสูจน์ ในขณะที่ OP ข้อดีคือสามารถสร้างระบบนิเวศน์ได้อย่างรวดเร็วในช่วงเวลาสั้น ๆ และยังมีช่องว่างสำหรับการพัฒนาก่อนที่เลเยอร์ 3 จะลงจอด
• สำหรับแอปพลิเคชัน defi ทั่วไปและตลาด NFT การเปลี่ยนแปลงของการยกเลิกไม่ใช่ข้อกำหนดที่เข้มงวด เฉพาะแอปพลิเคชันการชำระเงินหรือเกมที่ต้องการประสิทธิภาพสูงเท่านั้นที่มีความต้องการการยกเลิกที่สูงกว่า ในอนาคต โครงการ defi อาจอยู่บน l2 โครงการโซเชียลอาจอยู่บน l3 หรือออฟไลน์ และสุดท้าย ข้อมูลหลักและความสัมพันธ์จะอยู่บน l2 โครงการเกมจำเป็นต้องไปที่ l3 หรือยกเลิก แต่เมื่อพิจารณาว่าปัจจุบันส่วนใหญ่ เกมลูกโซ่โดยพื้นฐานแล้วเป็นกองทุน และการที่โทเค็นไม่สามารถหมุนเวียนภายนอกได้ทำให้เกิดปัญหาคอขวดในการพัฒนา ควบคู่ไปกับการเกิดขึ้นของเกมในห่วงโซ่ทั้งหมด การดึงดูดทางนิเวศวิทยาของ l3 นั้นยิ่งใหญ่กว่าการเลิกเล่น

**4.**การอัปเกรด Cancun ช่วยปรับปรุงประสบการณ์ของนักพัฒนาและผู้ใช้

• Cancun อัพเกรด SELFDESTRUCT ข้อเสนอสำคัญที่สอง การลบออกจะช่วยปรับปรุงความปลอดภัยของ Ethereum ให้ดียิ่งขึ้น พร้อมกันนี้ สำหรับปัญหาการอัปเดตบัญชีแบบเป็นโปรแกรมที่เป็นไปได้หลังการลบ SETCODE รหัสการทำงานใหม่ก็เตรียมพร้อมเพื่อปรับปรุงสถานการณ์นี้
• EIP ข้อเสนอที่สามสำหรับการอัปเกรด Cancun 1153 เพิ่มรหัสการดำเนินการจัดเก็บชั่วคราว ซึ่งประการแรกสามารถประหยัดน้ำมันได้ ประการที่สองแก้ปัญหาการสื่อสารระหว่างเฟรม และสุดท้ายเป็นการปูทางสำหรับการออกแบบที่เก็บข้อมูลในอนาคต เช่น Verkle tree ซึ่งจะไม่ต้องพิจารณาปัญหาการคืนเงินของ การจัดเก็บชั่วคราว
• ข้อเสนอที่สี่ EIP สำหรับการอัปเกรด Cancun 5656 แนะนำคำสั่งคัดลอกหน่วยความจำ MCOPY ซึ่งสามารถคัดลอกรหัสคำและประโยคได้แม่นยำยิ่งขึ้น ซึ่งจะปรับปรุงประสิทธิภาพการคัดลอกหน่วยความจำประมาณ 10%;
• ข้อเสนอที่ห้าสำหรับการอัปเกรด Cancun คือ EIP 4788 สามารถทำให้การสื่อสารระหว่างโปรโตคอลและแอปพลิเคชันต่างๆ ในเครือข่าย Ethereum มีประสิทธิภาพและปลอดภัยมากขึ้น และยังช่วยให้การออกแบบที่ไม่น่าเชื่อถือมากขึ้นสำหรับกลุ่มการจำนำ การบริดจ์ และการคืนค่าโปรโตคอล
• Cancun อัพเกรดล่าสุด (15, 23 มิถุนายน) ที่เสนอการอัพเกรด EIP ที่เน้น CL-centric: EIP 6988、EIP 7044、EIP 7045 ซึ่งปรับปรุงความปลอดภัยและความสามารถในการใช้งานของ Ethereum ในรายละเอียด เช่น การปรับปรุงประสบการณ์ของผู้จำนำและการปรับปรุงความปลอดภัยของเครือข่าย
• ในข้อเสนอที่ถูกลบ SSZ-> การเปลี่ยนแปลงของ RLP ทำให้ SSZ ทั้งสอง อีไอพี（EIP 6475 และ EIP

6493. ถูกลบออกจากการอัปเกรด Cancun ข้อเสนอที่เกี่ยวข้องกับ EOF ถูกลบออกจากการอัปเกรด Cancun หลังจากถูกลบออกจากการอัปเกรด Shanghai และขณะนี้มีการพิจารณาว่าอาจนำไปใช้โดยตรงในการอัปเกรดรายวันในภายหลัง EVMMAX เกิดจาก EIP บางส่วน ที่เกี่ยวข้องกับการนำ EOF ไปใช้ Subset ดังนั้นจึงถูกย้ายออกจาก Cancun เพื่ออัพเกรดร่วมกับ EOF โดยพิจารณาถึงผลข้างเคียงที่อาจเกิดขึ้นในการถ่ายโอน ETH เช่นเดียวกับการให้เหตุผล การทดสอบ และงานด้านความปลอดภัยที่จำเป็นเพื่อให้ผ่านข้อเสนอ ,สพป 5920 ถูกลบออกจากการอัพเกรด

**5. **ความสัมพันธ์กับ zkml และนามธรรมของบัญชี

ผลกระทบเพียงเล็กน้อยต่อ zkml

• ZKML เป็นหลักฐานที่ไม่มีความรู้ (Zero Knowledge)และแมชชีนเลิร์นนิง(Machine การเรียนรู้) การรวมกันของ **blockchain และ ML โมเดลช่วยแก้ปัญหาการปกป้องความเป็นส่วนตัวและการตรวจสอบความถูกต้องของแมชชีนเลิร์นนิง:
• การคุ้มครองความเป็นส่วนตัว: การรักษาความลับของข้อมูลอินพุต เช่น การใช้ข้อมูลส่วนบุคคลจำนวนมากเป็นข้อมูลเพื่อป้อนให้กับเครื่องจักรสำหรับการฝึกอบรม การรักษาความลับของข้อมูลส่วนบุคคลเป็นข้อกำหนดหลัก หรือพารามิเตอร์แบบจำลองคือความสามารถในการแข่งขันหลักของโครงการ และ จำเป็นต้องมีการเข้ารหัสเพื่อรักษาอุปสรรคการแข่งขัน เมื่อปัญหาความน่าเชื่อถือเช่นนี้เกิดขึ้น แบบจำลอง ML จะถูกขัดขวางไม่ให้ได้รับข้อมูลและแอปพลิเคชันขนาดใหญ่
• การตรวจสอบได้: เทคโนโลยีการพิสูจน์ด้วยความรู้เป็นศูนย์มีแอปพลิเคชันที่หลากหลาย และ ZKP ช่วยให้ผู้ใช้ทราบความถูกต้องของข้อมูลโดยไม่ต้องมีการตรวจสอบ และเนื่องจากโมเดลแมชชีนเลิร์นนิงต้องการการคำนวณจำนวนมาก โมเดล ML จึงสามารถสร้างการพิสูจน์ผ่าน ZK-SNARK ซึ่งลดขนาดการพิสูจน์และลดความต้องการพลังงานในการคำนวณของ ML
• ข้อกำหนดด้านพื้นที่เก็บข้อมูลของ ZKML ** เกี่ยวข้องเพียงเล็กน้อยกับ ** DA **: **ต้องการบางอย่างเช่น Space เทคโนโลยีหลักของโครงสร้างการจัดเก็บข้อมูลที่แยกจากกันนี้คือโปรโตคอลความปลอดภัยใหม่ "พิสูจน์ SQL" กล่าวง่ายๆ คือคลังข้อมูลที่อยู่ถัดจากบล็อกเชนทำให้นักพัฒนาสามารถเชื่อมต่อออนเชนและออฟเชนในรูปแบบ SQL อย่างง่าย ข้อมูลและ โหลดผลลัพธ์ลงในสัญญาอัจฉริยะโดยตรง
• ZK-SNARKs **เป็นรูปแบบหลักของ ** ZK ** ใน ** ZKML ** และสามารถปรับให้เข้ากับการคำนวณออนไลน์ของ ** **ML ** ** ด้วยการพัฒนาการเข้ารหัส โดยเฉพาะ recursive **SNARK proof จะเป็นประโยชน์ ZKML Landing on the chain:
• ZK-SNARK มีลักษณะที่มีความกะทัดรัดสูง การใช้ ZK-SNARK ช่วยให้ผู้พิสูจน์สามารถสร้างการพิสูจน์แบบสั้นได้และผู้ตรวจสอบไม่จำเป็นต้องโต้ตอบและต้องการเพียงทำการคำนวณเพียงเล็กน้อยเพื่อตรวจสอบความถูกต้องของการพิสูจน์ประเภทนี้ ต้องการเพียงครั้งเดียว ธรรมชาติของการโต้ตอบระหว่างตัวตรวจสอบและตัวตรวจสอบทำให้ ZK-SNARK มีประสิทธิภาพและใช้งานได้จริงในการใช้งานจริง และเหมาะสมกว่าสำหรับข้อกำหนดด้านกำลังการประมวลผลของ ML บนสายโซ่
• ขณะนี้ไม่สามารถฝึกบนเชนได้ และเฉพาะผลลัพธ์ของการคำนวณนอกเชนเท่านั้นที่สามารถจัดเก็บบนเชน:
• ปัญหา ML ในปัจจุบันมีมากขึ้นเนื่องจากข้อกำหนดด้านพลังงานการประมวลผลที่ไม่น่าพอใจและประสิทธิภาพต่ำที่เกิดจากข้อจำกัดของอัลกอริทึม (ไม่สามารถคำนวณแบบขนานได้) การพิสูจน์ ZK โมเดลขนาดใหญ่ต้องการพลังการประมวลผลที่สูงกว่าซึ่งไม่สามารถรองรับบนเครือข่ายที่เป็นที่นิยมในปัจจุบัน ZK-SNARK รองรับเฉพาะการพิสูจน์ ML zero-knowledge ด้วยสเกลขนาดเล็กและการคำนวณจำนวนน้อย กล่าวคือ ข้อจำกัดของพลังการประมวลผลเป็นปัจจัยสำคัญที่ส่งผลต่อการพัฒนาแอปพลิเคชัน ZKML blockchain และ chain สามารถเก็บเฉพาะผลลัพธ์ของ off- การคำนวณห่วงโซ่

** สรุปบัญชีที่ดี **

• ประการแรก การอัพเกรด Cancun สามารถลดได้ในระดับหนึ่ง ZK การรวบรวม หลักฐานค่าธรรมเนียม:
• ค่าธรรมเนียมการทำธุรกรรม zkSync ปัจจุบันขึ้นอยู่กับ 3 ด้าน:
• ค่าใช้จ่ายของทรัพยากรคงที่ที่ใช้โดยผู้ตรวจสอบเพื่อสร้างการพิสูจน์ SNARK และยืนยันค่อนข้างสูง
• ค่าธรรมเนียมก๊าซเมื่อผู้ตรวจสอบส่งหลักฐาน SNARK ไปยัง Ethereum mainnet ค่าธรรมเนียมส่วนนี้จะเพิ่มขึ้นตามความแออัดของเครือข่ายหลัก
• ค่าบริการที่ผู้ใช้จ่ายให้กับผู้ตรวจสอบ รวมถึงการยืนยันธุรกรรม การส่งข้อความ ฯลฯ
• ดังนั้นหากมีการแนะนำ 4844 ปัญหาของค่าธรรมเนียมก๊าซที่เพิ่มขึ้นซึ่งเกิดจากความแออัดของเครือข่ายหลักจะลดลงและค่าใช้จ่ายในการพิสูจน์ ZKP สามารถลดลงได้ในระดับหนึ่ง แม้ว่าจะไม่มากเมื่อเทียบกับต้นทุนในการสร้างการพิสูจน์ แต่เมื่อพิจารณา ZK ยังอยู่ในช่วงเริ่มต้น แนวโน้มการพัฒนาในอนาคตของซีรีส์ ZK ไม่ควรมองข้าม
• อย่างที่สอง การลบบัญชีจะแปลงธุรกรรมแบบดั้งเดิม ** tx ** เป็น ** useroperation จากนั้น ** useroperations use ECDSA * * บรรจุเป็นบล็อก พื้นที่จัดเก็บบนห่วงโซ่ใช้พื้นที่มากกว่าเดิม ดังนั้นความต้องการในการจัดเก็บจึงสูงขึ้น
• **ถัดไป การสรุปบัญชี และ ** ZK การยกเลิก เสริมซึ่งกันและกันได้:
• ปัญหาปัจจุบันของการตัดบัญชีคือแก๊ส ค่าธรรมเนียมมีราคาแพง เนื่องจากมีขั้นตอนมากเกินไปและมีสัญญาอัจฉริยะเข้ามาเกี่ยวข้อง ดังนั้นจึงมีข้อมูลจำนวนมากซึ่งนำไปสู่การใช้แก๊ส ค่าธรรมเนียมมีราคาแพงและ ZK ข้อดีของ Rollup คือสามารถลดข้อมูล
• การแยกบัญชีทำให้การรับประกันความปลอดภัยทำได้ยาก: เนื่องจาก AA เกี่ยวข้องกับสัญญาหลายฉบับ การรักษาความปลอดภัยจึงเป็นปัญหา แต่หลังจากการก่อตัวของ L2 อย่างค่อยเป็นค่อยไปในอนาคต ชั้นฉันทามติจะไม่เปลี่ยนแปลง สัญญาอัจฉริยะจะมีการใช้งานมากขึ้น และการรักษาความปลอดภัย นอกจากนี้ยังสามารถรับประกันการถอนบัญชีได้ด้วยความช่วยเหลือจาก ZK การตรวจสอบการยกเลิกที่เชื่อถือได้จะช่วยปรับปรุงความปลอดภัยให้ดียิ่งขึ้น
• สุดท้าย เมื่อพิจารณาถึงการเพิ่มขึ้นของ ** AI ** เทคโนโลยีนี้สามารถช่วยปรับปรุงความปลอดภัยของสัญญาบนเครือข่ายและเพิ่มประสิทธิภาพการทำธุรกรรมบนเครือข่ายหรือขั้นตอนกิจกรรม:
• AI และความปลอดภัย: เทคโนโลยี AI สามารถใช้เพื่อเพิ่มความปลอดภัยและการปกป้องความเป็นส่วนตัวของการทำธุรกรรมบนเครือข่าย ตัวอย่างเช่น SeQure แพลตฟอร์มการรักษาความปลอดภัย Web3 ใช้ AI เพื่อตรวจจับและป้องกันการโจมตีที่เป็นอันตราย การฉ้อโกง และการรั่วไหลของข้อมูล และให้กลไกการตรวจสอบและแจ้งเตือนตามเวลาจริงเพื่อให้มั่นใจถึงความปลอดภัยและความเสถียรของการทำธุรกรรมบนห่วงโซ่
• AI และการเพิ่มประสิทธิภาพของกิจกรรมบนห่วงโซ่: กิจกรรมบนบล็อกเชนรวมถึงธุรกรรม การดำเนินการตามสัญญา และการจัดเก็บข้อมูล ด้วยความสามารถในการวิเคราะห์และการทำนายที่ชาญฉลาดของ AI กิจกรรมบนเครือข่ายสามารถเพิ่มประสิทธิภาพได้ดีขึ้นและปรับปรุงประสิทธิภาพและประสิทธิภาพโดยรวม AI สามารถช่วยระบุรูปแบบการทำธุรกรรม ตรวจจับกิจกรรมที่ผิดปกติ และให้คำแนะนำแบบเรียลไทม์เพื่อเพิ่มประสิทธิภาพการจัดสรรทรัพยากรสำหรับเครือข่ายบล็อกเชนผ่านการวิเคราะห์ข้อมูลและการฝึกอบรมแบบจำลอง
• **ดังนั้น การอัปเกรด Cancun จะมาจากการขยายพื้นที่จัดเก็บ ไปจนถึงการผสานรวมกับ ** ZK ความสมบูรณ์แบบของการยกเลิก ** และการใช้ร่วมกับ ** AI ** เทคโนโลยีจะค่อยๆ เป็นประโยชน์ต่อการพัฒนานามธรรมของบัญชีในอนาคต **

**6.**มองย้อนกลับไปที่แผนงาน Ethereum อะไรต่อไป

• **ปัจจุบัน **Layer2 ** ไม่มีประสิทธิภาพ (ในแง่ของเวลาแฝงและปริมาณงาน) คล้ายกับ ** Solana ** และไม่เหมือนกับ ** ใกล้เคียง ** ดังกล่าว ประสิทธิภาพการแบ่งกลุ่มและไม่มีการดำเนินการแบบขนานเช่น ** Sui ** และ ** Aptos ** การอัปเกรด Cancun ได้ปรับปรุงตำแหน่งผู้นำของ Ethereum ในฐานะผู้นำ **
• หลังจากการอัปเกรด Cancun เวลาในการพัฒนาที่สำคัญหลาย ๆ ครั้งจะถูกประเมิน Danksharding อย่างเต็มที่** (2~5 ปี), *MEV * และ ** PBS ลงจอด (1~3 ปี), นามธรรมบัญชี (1~2 ปี), ***ZK ** *ทุกอย่าง (3~6 ปี), EOF และประสบการณ์ของนักพัฒนา (คุณเห็นส่วนขยายกี่ครั้งแล้ว) **

เดอะ หายนะ

• เป้าหมาย: มุ่งเน้นไปที่การแก้ปัญหา MEV
• วิธีแก้ไข: ลดขนาด MEV ที่เลเยอร์แอปพลิเคชันผ่าน "Proposer-Builder Separation (PBS)" ในขณะนี้ blobs อาจได้รับการปรับให้เหมาะสมและอาจแนะนำบริการยืนยันล่วงหน้าหรือการป้องกันล่วงหน้า
• PBS คือการแยกตัวผลิตบล็อกและตัวคัดแยก ตัวเรียงลำดับมีหน้าที่รับผิดชอบในการจัดเรียงเท่านั้น โดยไม่คำนึงถึงเชน และผู้สร้างบล็อกไม่สนใจเกี่ยวกับการทำธุรกรรม และเลือกแพ็คเกจที่สร้างโดยตัวเรียงลำดับโดยตรงและวางไว้บนเชน กระบวนการนี้จะทำให้กระบวนการทั้งหมดยุติธรรมมากขึ้นและบรรเทาปัญหาของ MEV ซึ่งเป็นแนวคิดของ MEV externalization
• ระดับความสำเร็จของ PBS ยังต่ำมาก และยิ่งมีความเป็นผู้ใหญ่มากขึ้น การทำงานร่วมกันกับโซลูชัน MEV ภายนอก - mevboost โดย flashbots
• รุ่นขั้นสูงของ "ประดิษฐาน Proposer-Builder Separation (ePBS)" มีระดับความสำเร็จที่ต่ำกว่าและวงจรที่ยาวกว่า และคาดว่าจะไม่ถูกนำมาใช้ในระยะสั้น นอกจากนี้ ยังมี PEPC เวอร์ชันก้าวหน้าและเวอร์ชันที่มองโลกในแง่ดี การถ่ายทอดซึ่งช่วยเพิ่มความยืดหยุ่นและความสามารถในการปรับตัวของกรอบ PBS

เดอะ หมิ่น

• เป้าหมาย: ใช้ Verkel tree เพื่อแทนที่ Merkle, แนะนำโซลูชันลดความน่าเชื่อถือ, เปิดใช้งาน light nodes เพื่อรับความปลอดภัยเช่นเดียวกับโหนดแบบเต็ม, และทำให้การยืนยันการบล็อกเป็นเรื่องง่ายและเบาที่สุดเท่าที่จะเป็นไปได้
• ในเวลาเดียวกัน ZKization ของ L1 ถูกเพิ่มอย่างชัดเจนในแผนงานของ Verge ZK จะเป็นแนวโน้มทั่วไปของการขยายตัวและความเร็วในอนาคต
• วิธีแก้ไข: แนะนำ zk-SNARK เพื่อแทนที่ระบบพิสูจน์แบบเก่า รวมถึงไคลเอนต์แสงที่ใช้ SNARK; SNARK สำหรับการเปลี่ยนแปลงสถานะที่เป็นเอกฉันท์; Enshrined โรลอัพ。
• ต้นไม้ Verkle เป็นทางเลือกที่มีประสิทธิภาพมากกว่าสำหรับต้นไม้ Merkle เฉพาะรัฐที่ไม่จำเป็นต้องระบุเส้นทางจากโหนดน้องสาวแต่ละโหนด (โหนดที่ใช้พาเรนต์เดียวกัน) ไปยังโหนดที่เลือก แต่เพียงเส้นทางของตัวเองเป็นหลักฐาน ส่วนหนึ่งของ Verkle การพิสูจน์มีประสิทธิภาพมากกว่าการพิสูจน์ของ Merkle ถึง 3 เท่า
• ประดิษฐาน Rollup หมายถึง Rollup ที่มีการรวมฉันทามติบางประเภทบน L1 ข้อได้เปรียบคือมันสืบทอดฉันทามติของ L1 และไม่จำเป็นต้องมีโทเค็นการกำกับดูแลเพื่อดำเนินการอัปเกรดการยกเลิก ในขณะเดียวกันโดยการคำนวณนอกห่วงโซ่และเผยแพร่เท่านั้น ผลลัพธ์ของ blockchain นั้นสามารถเพิ่มจำนวนธุรกรรมได้ แต่ความยากทางเทคนิคของการใช้งานนั้นค่อนข้างใหญ่ การรวมกันของการยกเลิกเหล่านี้ในอนาคตจะสามารถตอบสนองความต้องการส่วนใหญ่ของระบบนิเวศบล็อกเชนในอีกไม่กี่ทศวรรษข้างหน้า

เดอะ ล้าง

• เดอะ การล้างหมายถึงเป้าหมายในการลดความซับซ้อนของโปรโตคอลโดยการลดข้อกำหนดในการจัดเก็บข้อมูลเพื่อเข้าร่วมในการตรวจสอบความถูกต้องของเครือข่าย สิ่งนี้ทำได้โดยหลักจากการจำศีลและการจัดการประวัติศาสตร์และสถานะ การพักข้อมูลในอดีต (EIP-4444) ช่วยให้ลูกค้าสามารถตัดข้อมูลประวัติที่เก่ากว่าหนึ่งปีและหยุดให้บริการที่ระดับ P2P
• รัฐอยู่เฉยๆ. เมื่อพูดถึงการจัดการกับการเติบโตของรัฐ มีเป้าหมายหลักสองประการ ได้แก่ การไร้สัญชาติอย่างอ่อนแอ ซึ่งหมายถึงเป้าหมายเพียงใช้รัฐสร้างบล็อกแต่ไม่ได้ตรวจสอบ รัฐถูกเข้าถึง การไฮเบอร์เนตสถานะควรลดสถานะที่โหนดต้องจัดเก็บโดยรวม 20-50 กิกะไบต์。
• ในการชำระล้างขั้นที่ห้า EIP 4444 ถูกเขียนไว้ใน Roadmap อย่างชัดเจน EIP-4444 กำหนดให้ไคลเอ็นต์ต้องล้างข้อมูลที่เก่ากว่าหนึ่งปี และในขั้นตอนนี้ยังมีงานเพิ่มประสิทธิภาพ EVM บางอย่าง เช่น การลดความซับซ้อนของกลไกการคอมไพล์ล่วงหน้าของ GAS และ EVM เป็นต้น

เดอะ สาด

• ใน Splurge ด่านที่หกสุดท้าย EIP มีการกล่าวถึง 4337 ด้วย ในฐานะที่เป็นข้อเสนอเค้าโครงระยะยาวสำหรับระบบนิเวศน์ของ wallet การแยกบัญชีจะช่วยปรับปรุงความสะดวกในการใช้งาน wallet ในอนาคต รวมถึงการใช้ stablecoins เพื่อชำระค่าน้ำมัน, วอลเล็ตเพื่อการกู้คืนทางสังคม ฯลฯ

เอกสารอ้างอิง:

• อัปเดตการประชุม Ethereum core dev:
• อีเธอเรียม นักพัฒนาหลักทั้งหมดโทร #148 เขียน
• อีเธอเรียม นักพัฒนาหลักทั้งหมดโทร #149 เขียน
• อีเธอเรียม ชั้นฉันทามติ โทร #99 เขียน
• อีเธอเรียม นักพัฒนาหลักทั้งหมดโทร #150 เขียน
• อีเธอเรียม นักพัฒนาหลักทั้งหมดโทร #151 เขียน
• อีเธอเรียม ชั้นฉันทามติโทร #100 เขียน
• อีเธอเรียม นักพัฒนาหลักทั้งหมดโทร #152 เขียน
• อีเธอเรียม นักพัฒนาหลักทั้งหมดโทร #153 เขียน
• อีเธอเรียม การสนทนาในฟอรัมนักมายากลดั้งเดิม:
• อีเธอเรียม นักพัฒนาหลักทั้งหมดโทร #156 เขียน
• อีเธอเรียม นักพัฒนาหลักทั้งหมดโทร #157 เขียน
• อีเธอเรียม นักพัฒนาหลักทั้งหมดโทร #158 เขียน
• อีเธอเรียม นักพัฒนาหลักทั้งหมดโทร #159 เขียน
• อีเธอเรียม นักพัฒนาหลักทั้งหมดโทร #160 เขียน
• อีเธอเรียม ฉันทามติของนักพัฒนาหลักทั้งหมด โทร #108 เขียน
• อีเธอเรียม นักพัฒนาหลักทั้งหมดโทร #161 เขียน
• อีเธอเรียม ฉันทามติของนักพัฒนาหลักทั้งหมด โทร #109 เขียน
• อีเธอเรียม นักพัฒนาหลักทั้งหมดโทร #162 เขียน
• อีเธอเรียม ฉันทามติของนักพัฒนาหลักทั้งหมด โทร #110 เขียน *Tim ทวีตเกี่ยวกับการอัปเกรด Ethereum Cancun ล่าสุด (09.06.23):
• ฉันทามติ Ethereum นักพัฒนาหลักทั้งหมดโทร #111 เขียน
• อีเธอเรียม ฉันทามติของนักพัฒนาหลักทั้งหมด โทร #112 เขียน
• เนื้อหาที่เกี่ยวข้องกับการอัปเกรด Ethereum:
• ข้อมูลเบื้องต้นเกี่ยวกับรหัสทำลายตัวเอง:
• สำรวจข้อเสนอ EVMMAX และ BLS12-381
• นอกจาก EIP-4844 แล้ว การอัปเกรด Cancun ยังมีอะไรอีกบ้าง ดูการเรียกร้องฉันทามติล่าสุดของ Ethereum
• มีการเพิ่มเนื้อหาใหม่อะไรบ้างในการอัปเกรด Ethereum Shanghai
• ทวีต:
• ตกลง Ventures: หลังจากอัปเกรด Ethereum Shanghai แล้ว Cancun ก็อัปเกรดโอกาสการลงทุนที่มีศักยภาพ - ข่าวการมองการณ์ไกล
• นอกจาก EIP-4844 ที่มีชื่อเสียงแล้ว การอัปเกรด Cancun จะรวมข้อเสนออะไรบ้าง?
• V God: ฟังก์ชัน EVM ที่ควรพิจารณาสำหรับการลบ
• Proto-Danksharding คำถามที่พบบ่อย
• แนะนำโดย V God丨 เข้าใจเชิงลึกเกี่ยวกับโรดแมปของ Ethereum อ่านรายงานนี้ก็เพียงพอแล้ว
• บทความเพื่อทำความเข้าใจ Danksharding แผนการอัปเกรดใหม่ของ Ethereum
• ถอดรหัสข้อเท็จจริงที่น่าสนใจและความลับที่ซ่อนอยู่ในแผนงานล่าสุดของ Ethereum
• Vitalik: เหตุใด SELFDESTRUCT จึงส่งผลเสียต่อระบบนิเวศของ Ethereum มากกว่าผลดี
• วิสัยทัศน์ Ethereum:
• งานบล็อก นักวิจัย Brrr: Proto-Danksharding ช่วยเร่ง L1 ของ Ethereum ได้อย่างไร ความสามารถในการปรับขนาดแบบโรลอัพ
• การประชุม Ethereum ACDC ครั้งที่ 111: หารือเกี่ยวกับขอบเขตขั้นสุดท้ายของการอัปเกรด Deneb และข้อเสนอสามข้อรวมถึง EIP-7044
• KOL Stacy Muur มองดูวิวัฒนาการของโซลูชันการปรับขนาด Ethereum: OP สแต็ค、 ตามอำเภอใจ วงโคจร、รูปหลายเหลี่ยม 2.0
• การเปรียบเทียบแนวนอนของ Rollups สามประเภท: Rollups แบบคลาสสิก (Optimistic/ZK Rollups）、ประดิษฐาน Rollups、อธิปไตย โรลอัพ
• [AMA] พวกเราคือ EF Research (Pt. 8: 07 กรกฎาคม 2022)：
• 3 เพลงฮิตที่ควรคิดใหม่ในปี 2023
• มอนเตเนโกร EDCON ความคิดเกี่ยวกับสิ้นปี 2566: ดูแนวโน้มโครงสร้างพื้นฐานและแอปพลิเคชัน
• จินตนาการที่ไม่มีที่สิ้นสุดของความเป็นไปได้ในการรวม AI และ Web3
• AI+Web3: สำรวจการรวมปัญญาประดิษฐ์และบล็อกเชน
• เปรียบเทียบ zk-rollup และ op-rollup: วิเคราะห์ว่าทำไม zkSync ปัจจุบันจากวิธีการตรวจสอบ ค่าน้ำมันแพง
• "การเพิ่มวอลุ่มไปยังวอลุ่ม": โซลูชันการแยกบัญชีในยุคโรลอัพ
• การตีความ ZKML เชิงลึก: หลักการทางเทคนิค สถานการณ์การใช้งาน ข้อดี และความท้าทาย
• ZKML: เทคโนโลยีการปรับใช้โมเดลที่ผสานรวม AI และบล็อกเชนเพื่อให้ได้รับการปกป้องความเป็นส่วนตัว
• เป็นไปได้ ข้อมูลความปลอดภัย การแบ่งส่วน
• บทสนทนากับ Qi ผู้ก่อตั้ง EthStorage Zhou | ความพร้อมใช้งานของข้อมูลและการจัดเก็บแบบกระจายอำนาจ
• อ่านแผนงานการพัฒนา Ethereum เวอร์ชันล่าสุดในบทความเดียว
• เกี่ยวกับอวกาศ และ บทนำสั้น ๆ เกี่ยวกับเวลา
• ข้อเสนอเดิม:
• สพป 4844：
• สพป 6780：
• สพป 1153：
• สพป 5920：
• สพป 5656：
• สพป 7069：
• สพป 4788：
• สพป 2537：
• EVMMAX EIPs：
• สพป 6601：
• สพป 6990：
• อฟ การเปลี่ยนแปลง：
• สพป 663：
• สพป 3540：
• สพป 3670：
• สพป 4200：
• สพป 4750：
• สพป 5450：
• สพป 6475：
• สพป 6493：
• ประชาสัมพันธ์ 3175：