เมื่อวันที่ 12 ตุลาคม นักพัฒนา Ethereum รวมตัวกันเพื่อประชุมทางโทรศัพท์ผ่าน Zoom การประชุมซึ่งจัดโดย Tim Beiko หัวหน้าฝ่ายสนับสนุนโปรโตคอลที่ Ethereum Foundation เป็นที่ที่นักพัฒนาพูดคุยและประสานงานการเปลี่ยนแปลงใน Ethereum Execution Layer (EL) การประชุมล่าสุดมุ่งเน้นไปที่การทดสอบ Dencun และการพัฒนารูปแบบออบเจ็กต์ EVM

เมื่อวันที่ 12 ตุลาคม นักพัฒนา Ethereum ได้รวมตัวกันบน Zoom เพื่อการประชุม All Core Developers Execution (ACDE) Call #172 ACDE Conference Call เป็นการประชุมทุกสองสัปดาห์ที่จัดโดย Tim Beiko หัวหน้าฝ่ายสนับสนุนโปรโตคอลที่ Ethereum Foundation ซึ่งนักพัฒนาจะหารือและประสานงานการเปลี่ยนแปลงใน Ethereum Execution Layer (EL) สัปดาห์นี้ นักพัฒนามุ่งเน้นไปที่ความคืบหน้าของหัวข้อต่อไปนี้:

การทดสอบแคนคูน/เดเนบ (เดนคุน)

การพัฒนารูปแบบอ็อบเจ็กต์ Ethereum Virtual Machine (EVM)

การทดสอบเดนคุน

Barnabas Busa วิศวกร DevOps ที่ Ethereum Foundation เพิ่งแชร์การอัปเดตบางอย่างเกี่ยวกับ Devnet #9 ซึ่งเผยแพร่เมื่อวันที่ 29 กันยายน

ขณะนี้ Devnet #9 มีอัตราการมีส่วนร่วม 93% ซึ่งหมายความว่า 93% ของผู้ตรวจสอบมีส่วนร่วมอย่างแข็งขันในฉันทามติของเครือข่าย

7% ของเครื่องมือตรวจสอบที่ไม่ทำงานประกอบด้วยโหนดเครื่องมือตรวจสอบ Geth (EL)/Teku (CL) เป็นหลัก

นอกจากนี้ยังมีปัญหากับชุดไคลเอนต์ Eragon (EL)/Prysm (CL) รวมถึงไคลเอนต์ EthereumJS (EL)

ทีม Flashbots กำลังทดสอบการถ่ายทอดและตัวสร้าง MEV-Boost บน Devnet #9 Busa สนับสนุนให้ผู้ดำเนินการรีเลย์และผู้สร้างรายอื่นติดต่อเขาเพื่อให้สามารถทดสอบโครงสร้างพื้นฐาน MEV ได้มากขึ้นบน Devnet #9

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

Busa และเพื่อนร่วมงานของ Ethereum Foundation Parithosh Jayanthi ได้แชร์การอัปเดตเกี่ยวกับ Devnet #10 ที่กำลังจะมาถึง:

Devnet #10 ยังไม่พร้อมในสัปดาห์นี้ แต่คาดว่าจะพร้อมในสัปดาห์หน้า

สำหรับ Devnet #10 นักพัฒนาวางแผนที่จะทดสอบไฟล์การตั้งค่าที่เชื่อถือได้ในพิธี EIP 4844 KZG

Devnet #10 จะมีฐานผู้ตรวจสอบจำนวนมาก รวมถึงผู้ตรวจสอบที่ใช้งานอยู่ 330,000 ราย เมื่อเครือข่ายการพัฒนาเพิ่งเปิดตัว จะมีการฝากและถอนเงินของ Validator จำนวนมาก คาดว่าขีดจำกัดการเข้าและออกของ Validator จะลดลงจาก 5 เป็น 4 ครั้งภายในหนึ่งหรือสองวันหลังจากเปิดตัวเครือข่าย แม้ว่าขีดจำกัดการปั่นเข้าสูงสุดตามจริงบน mainnet คือ 8 นักพัฒนาจะใช้ขีดจำกัดที่ 4 เพื่อทดสอบ EIP 7514 บน Devnet #10

Busa เน้นย้ำว่านักพัฒนายังคงแก้ไขปัญหาสำคัญบางประการในระหว่างกระบวนการทดสอบของ Dencun ทีมพัฒนาจะไม่เปิดตัว Devnet #10 จนกว่าปัญหาเหล่านี้จะได้รับการแก้ไขอย่างเหมาะสม ซึ่งน่าจะเป็น Devnet สุดท้ายของ Dencun ก่อนที่จะเปิดใช้งานการอัปเกรดบนเครือข่ายทดสอบ Ethereum สาธารณะ เช่น Goerli ในการแชทผ่าน Zoom Jayanthi ได้สรุปประเด็นสำคัญที่นักพัฒนาจำเป็นต้องแก้ไขก่อนเปิดตัว Devnet #10:

อัปเดตไฟล์การตั้งค่าที่เชื่อถือได้สำหรับพิธี EIP 4844 KZG

การแสดงภาพธุรกรรม Blob ที่ดีขึ้น

การปรับปรุงท่อส่ง MEV

การปรับปรุงความเสถียรของเครือข่าย

อัปเดตไฟล์การตั้งค่าที่เชื่อถือได้สำหรับพิธี EIP 4844 KZG

การแสดงภาพธุรกรรม Blob ที่ดีขึ้น

การปรับปรุงท่อส่ง MEV

การปรับปรุงความเสถียรของเครือข่าย

ในระหว่างการโทร Jayanthi สนับสนุนให้ทีมลูกค้าเพิ่มการรองรับ Beacon API เพื่อเพิ่มการมองเห็นธุรกรรม Blob Beiko ถามว่านักพัฒนาเต็มใจที่จะอัปเกรดเครือข่ายทดสอบ Goerli หลังจากเปิดตัว Devnet #10 หรือไม่ Busa แนะนำให้สังเกตประสิทธิภาพของ Devnet #10 ก่อนที่จะตัดสินใจขั้นตอนการทดสอบการอัพเกรดในภายหลัง

นอกจากนี้ Jayanthi ยังยืนยันว่าในช่วงเวลาหนึ่งหลังจากการเปิดตัว Devnet #10 นักพัฒนาอาจดำเนินการ shadow fork ของ Ethereum mainnet ในเวลาเดียวกันกับที่การทดสอบเครือข่ายทดสอบสาธารณะทำงานเพื่อทดสอบการอัพเกรด Dencun เพิ่มเติม อย่างไรก็ตาม Jayanthi ตั้งข้อสังเกตว่าประโยชน์ของ Shadow Fork อาจมีจำกัด เนื่องจากข้อบกพร่องส่วนใหญ่ที่พบในระหว่างการทดสอบ Dencun อยู่ที่ระดับเครือข่ายแบบ peer-to-peer

Marius van der Wijden ผู้พัฒนา Geth (EL) กล่าวว่า Péter Szilágyi เพื่อนร่วมงานของเขาประสบความสำเร็จในการรันโหนดของตัวเองบน Devnet #9 และค้นพบปัญหาร้ายแรงที่เกี่ยวข้องกับสแปมแบบหยด

มีรายงานว่าเพื่อป้องกันการล่มของโหนด Szilágyi ได้ใช้ตัวจัดการธุรกรรมเพื่อจำกัดจำนวน Blob ที่เขาเห็นในเครือข่ายการพัฒนา Van der Wijden แนะนำให้ทีม CL กลับมาดูเป้าหมาย/ขีดจำกัด Blob สูงสุด 3/6 ใน EIP 4844 และให้ทีม EL พิจารณาในเชิงลึกเกี่ยวกับข้อกำหนดแบนด์วิดท์ของโหนดและวิธีการจัดการกับสแปม Blob

เพื่อหารือเกี่ยวกับปัญหาเหล่านี้เพิ่มเติม Beiko สนับสนุนให้นักพัฒนาเข้าร่วมการประชุมทดสอบความสามารถในการทำงานร่วมกันของ Dencun ในวันที่ 16 ตุลาคม

การพัฒนารูปแบบวัตถุ EVM

จากนั้นนักพัฒนาจึงหารือเกี่ยวกับการพัฒนาล่าสุดในรูปแบบ EVM Object Format (EOF) EOF คือชุดของ EIP ที่มุ่งเน้นไปที่การเปลี่ยนแปลงใน EVM ซึ่งเป็นเครื่องเสมือนที่ใช้ Ethereum ซึ่งใช้ในการรันโค้ดสัญญาอัจฉริยะ Danno Ferrin หนึ่งในผู้สนับสนุน EOF ได้สรุปและสรุปงานของ EOF ในช่วงไม่กี่เดือนที่ผ่านมา

ในช่วงเริ่มต้นของการนำเสนอ Ferrin เน้นย้ำว่าเขาคาดหวังว่า EOF จะเป็นการเปลี่ยนแปลงรหัสที่สำคัญในการอัพเกรดหลังจาก Cancun/Deneb (เรียกว่า Prague/Electra) Ferrin กล่าวว่าขณะนี้มีทีมหลักสี่ทีมที่ทำงานเกี่ยวกับ EOF:

Team Ipsilon: ทีมพัฒนาที่ได้รับทุนจาก Ethereum Foundation โดยมุ่งเน้นที่การปรับปรุง EVM

ทีมลูกค้า EL: เช่น Geth, Besu และ Nethermind

ทีมคอมไพเลอร์ภาษาระดับสูง: เช่น Solidity และ Vyper

นักพัฒนาสัญญาอัจฉริยะ: ตัวอย่างเช่น ผู้สนับสนุน opcode SSTORE2

โดยทั่วไปแล้ว ทีมงานต่างๆ มีส่วนร่วมในการพัฒนา EOF และร่วมกันส่งเสริมความก้าวหน้าทางเทคโนโลยีของเครือข่าย Ethereum

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

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

EIP ที่เกี่ยวข้องกับ EOF ที่เฟอร์รินกล่าวถึงในสุนทรพจน์ของเขา ได้แก่:

EIP 3540: รูปแบบคอนเทนเนอร์ใหม่สำหรับโค้ด EVM

EIP 4200: คำแนะนำการกระโดด EVM ใหม่สามคำสั่งที่แนะนำการกระโดดแบบคงที่

EIP 4750: opcode ใหม่สองตัวจะขจัดความจำเป็นในการกระโดดแบบไดนามิกและปิดการใช้งาน

EIP 3540: รูปแบบคอนเทนเนอร์ใหม่สำหรับโค้ด EVM

EIP 4200: คำแนะนำการกระโดด EVM ใหม่สามคำสั่งที่แนะนำการกระโดดแบบคงที่

EIP 4750: opcode ใหม่สองตัวจะขจัดความจำเป็นในการกระโดดแบบไดนามิกและปิดการใช้งาน

EIP 663: สองคำสั่งใหม่อนุญาตให้เข้าถึงความลึกของสแต็กที่ 256 (แทนที่จะเป็น 16)

EIP 7480: สี่คำสั่งใหม่เพื่อเปิดใช้งานการอ่านส่วนข้อมูลของคอนเทนเนอร์ EOF

EIP 7069: คำแนะนำการโทรใหม่สามประการเพื่อลดความซับซ้อนของการใช้ก๊าซและความหมายที่เกี่ยวข้องกับต้นทุน

EIP 5450: ขอแนะนำการตรวจสอบสัญญาอัจฉริยะในรูปแบบ EOF ในระหว่างการดำเนินการตามสัญญา

EIP 3670: แนะนำการตรวจสอบสัญญาอัจฉริยะในรูปแบบ EOF ณ เวลาที่สร้างสัญญา

หากต้องการดูรายการการเปลี่ยนแปลงทั้งหมดของ opcode EOF โปรดดูแผนภูมิต่อไปนี้จากการนำเสนอของ Ferrin

สรุปการเปลี่ยนแปลง opcode ของ EOF ที่มา: ดันโน เฟห์ลิง

เกี่ยวกับความคืบหน้าของการทดสอบ EOF นั้น Ferrin อธิบายว่าเนื่องจากข้อกำหนด EOF ยังไม่ได้รับการสรุป นี่คือเหตุผลว่าทำไมจึงยังไม่มีลูกค้าใดที่ดำเนินการอัปเกรด อย่างไรก็ตาม เขาคาดว่าการทดสอบ EOF จะเป็น "แบบสแตนด์อโลน" และค่อนข้างง่าย เนื่องจาก EOF มุ่งเน้นไปที่การเปลี่ยนแปลงที่ทำกับ EVM เพียงอย่างเดียว “เราไม่จำเป็นต้องกังวลเกี่ยวกับการโต้ตอบของเครือข่ายหรือการจับคู่กับชุดค่าผสม CL/EL ที่แตกต่างกัน” เขากล่าว “ฉันไม่คิดว่าเราจะต้องมีเครือข่ายการพัฒนาและเครือข่ายทดสอบในระดับเดียวกันเพราะเราจะสามารถทดสอบได้ ” Ferrin กล่าวเสริม: "เราจะเขียนการทดสอบอ้างอิงที่ชัดเจน... นอกจากนี้ ข้อดีหลักประการหนึ่งที่เรามีคือการทดสอบ EVM แบบดิฟเฟอเรนเชียลที่เราทำอยู่"

ในตอนท้ายของการพูดคุย Ferrin ย้ำความปรารถนาของเขาที่จะเห็น EOF เป็นการเปลี่ยนแปลงรหัสครั้งใหญ่ในการอัพเกรด Prague/Electra นอกจากนี้เขายังกล่าวอีกว่ามีความเป็นไปได้ที่จะทดสอบและดำเนินการเปลี่ยนแปลงโค้ดชุดหนึ่งสำหรับ EOF บน mainnet ภายในสามถึงหกเดือนหลังจากการอัปเกรด Dencun เสร็จสิ้น สามารถดูข้อมูลจำเพาะล่าสุดของ EOF ได้ที่นี่ คำถามปลายเปิดเกี่ยวกับข้อมูลจำเพาะเหล่านี้ได้รวบรวมไว้ ที่นี่ โดยทีมงาน Ipsilon ข้อกำหนด EOF บางส่วนยังจำเป็นต้องได้รับการปรับปรุง นักพัฒนาที่เข้าร่วมการโทรได้รับการสนับสนุนให้แบ่งปันความคิดเกี่ยวกับการพัฒนาและข้อกำหนดล่าสุดสำหรับ EOF ในช่อง "#EVM" บน Ethereum Research and Development Discord

การอภิปรายรูปแบบวัตถุ EVM

การนำเสนอของ Ferrin จุดประกายการอภิปรายอย่างกว้างขวางในหมู่นักพัฒนา ในระหว่างการประชุมทางโทรศัพท์ ข้อกังวลหลักของนักพัฒนาเกี่ยวกับ EOF มีดังต่อไปนี้:

ไทม์ไลน์: นักพัฒนาหลายคน รวมถึง Tim Beiko ลังเลกับไทม์ไลน์สามถึงหกเดือนสำหรับการนำ EOF ไปใช้หลังจากการอัปเกรด Dencun

ความเร่งด่วน: นักพัฒนากำลังพิจารณาที่จะรวม Verkle เข้ากับ Bragg/Electra ในการเปลี่ยนแปลงโค้ดที่สำคัญอื่น ในช่วงต้นเดือนสิงหาคม Guillaume Ballet ผู้พัฒนา Ethereum Foundation ได้แบ่งปันความคืบหน้าล่าสุดของ Verkle ในระหว่างการประชุมทางโทรศัพท์ในสัปดาห์นี้ Ballet เน้นย้ำว่า Verkle เป็นการอัปเกรด Ethereum ที่เร่งด่วนมากกว่า EOF ดังนั้นจึงควรได้รับการจัดลำดับความสำคัญ Ballet ยังกล่าวอีกว่าเขาจะสนับสนุนการอัพเกรดหากความซับซ้อนของ EOF สามารถลดลงได้ และจำนวนการเปลี่ยนแปลงโค้ดลดลง เพื่อที่การใช้งานจะไม่ส่งผลกระทบต่อกำหนดการของ Verkle

ประโยชน์ที่ได้รับ: Lukasz Rozmej ผู้พัฒนา Van der Wijden และ Nethermind (EL) ตั้งคำถามถึงข้อดีข้อเสียระหว่างผลประโยชน์ที่ได้รับทันทีของ EOF และความซับซ้อนในการอัพเกรด เกี่ยวกับความกังวลเกี่ยวกับการขาดความต้องการที่แข็งแกร่งสำหรับการเปลี่ยนแปลงครั้งใหญ่ใน EVM นั้น Ferrin กล่าวว่า EVM ถูกเขียนขึ้น "ในช่วงสุดสัปดาห์" โดยทีมพัฒนาดั้งเดิมของ Ethereum และสามารถทำการปรับปรุงได้มากมายเพื่อให้แน่ใจว่า EVM ยังคงอยู่ แข่งขันกับคู่แข่งได้ เช่น การทดแทน Layer-1 blockchain Sui ใหม่ “นี่ไม่ใช่ความเสี่ยงด้านความปลอดภัย” เฟอร์รินกล่าว "มันเป็นธุรกรรมที่มีอยู่มากกว่า"

ความซับซ้อนและความเสี่ยงที่เพิ่มขึ้น: Van der Wijden เน้นย้ำถึงวิธีการที่ EOF สามารถเพิ่มความซับซ้อนและความเสี่ยงของโปรโตคอล ทีมลูกค้าจะมีภาระเพิ่มขึ้นในการบำรุงรักษา EVM ทั้งสองเวอร์ชัน และรับประกันว่าการพึ่งพาซึ่งกันและกันจะได้รับการพิจารณาในระหว่างการฮาร์ดฟอร์คในอนาคต Wijden เชื่อว่าทีม Layer-2 ไม่ควรพยายาม "ผลักดัน" งานบำรุงรักษา EVM และ EOF ให้กับทีมลูกค้าแบบคู่ขนาน แต่ควรมุ่งเน้นไปที่การดำเนินการปรับปรุง EVM บนโปรโตคอลของตนเอง

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

การกำกับดูแล EVM: ทริชส์ยังแสดงความกังวลเกี่ยวกับผลกระทบของ EOF ต่อการกำกับดูแล EVM Ethereum มีการพัฒนาอย่างต่อเนื่องเพื่อรองรับการดำเนินการสัญญาอัจฉริยะบนเครือข่ายทางเลือกที่เรียกว่า Layer-2 สมมติว่าในอนาคตกิจกรรมผู้ใช้ส่วนใหญ่และการดำเนินการสัญญาอัจฉริยะเกิดขึ้นนอกเครือข่าย และ Ethereum ถูกใช้เป็นเลเยอร์ความพร้อมใช้งานของข้อมูลเป็นหลัก การเปลี่ยนแปลง EVM ควรมีความสำคัญมากที่สุดสำหรับโปรโตคอลเลเยอร์ 2 มากกว่า Ethereum mainnet Dietrichs แนะนำให้นักพัฒนาพิจารณาอย่างรอบคอบและหารือเกี่ยวกับวิธีที่พวกเขาตัดสินใจเปลี่ยนแปลง EVM ในระบบนิเวศของเลเยอร์ 2 ที่กำลังขยายตัว

Ferrin และคณะ เริ่มทำงานวิจัย EOF ตั้งแต่ปี 2021 เมื่อต้นปีที่ผ่านมา EOF ถูกปฏิเสธโดย Shanghai hard fork เนื่องจากแผนงานแบบหลายเฟส ผู้เสนอ EOF แก้ไขปัญหานี้ด้วยการสร้างการออกแบบที่อัปเดตสำหรับการอัพเกรดที่จะแนะนำการเปลี่ยนแปลงที่เกี่ยวข้องกับ EOF ทั้งหมดในการอัปเกรดครั้งใหญ่ครั้งเดียว อย่างไรก็ตาม ความซับซ้อนของการอัปเกรดนี้เป็นหนึ่งในข้อกังวลหลักเกี่ยวกับ EOF ที่เกิดขึ้นระหว่างการประชุมทางโทรศัพท์ในสัปดาห์นี้ Van der Wijden เน้นย้ำว่าในครั้งนี้นักพัฒนาควรพิจารณาอย่างรอบคอบว่า EOF ควรนำไปใช้กับ Ethereum หรือไม่ แทนที่จะชะลอการตัดสินใจเกี่ยวกับ EOF ต่อไป

"ฉันรู้ว่าทีม Ipsilon และ Danno ใช้เวลาส่วนใหญ่ในการแก้ปัญหานี้ และมันค่อนข้างจะรุนแรงที่จะบอกว่าเราอาจจะไม่ส่งมอบมันให้สำเร็จหลังจากผ่านไปนานแล้ว แต่ฉันคิดว่ามันคงจะแย่กว่าถ้าพูดว่า 'มาดูกัน' ' แล้วเราก็ล่าช้าไปสองปีแล้วเราก็พูดว่า 'โอ้ เราจะไม่จัดส่งมันเลย' ดังนั้นฉันคิดว่าเราควรตัดสินใจเกี่ยวกับ Devconnect” van der Wijden กล่าวเสริม “ ถ้านั่นคือสิ่งที่เราต้องการทำสิ่งต่างๆ เราก็จะทำมัน เว้นแต่ว่าจะมีความท้าทายทางเทคนิคที่คล้ายกัน ถ้าเราบอกว่านี่คือสิ่งที่เราจะไม่ทำ เราก็จะทำมัน ฉันไม่คิดว่ามันจะเกิดขึ้น สำหรับการทำงานหนักทั้งหมดที่ทำไป มันยุติธรรมสำหรับทีมเท่านั้นที่ทุกคนตัดสินใจอย่างชัดเจน”

Rozmej กล่าวเพิ่มเติมว่า นอกเหนือจาก EOF และ Verkle แล้ว นักพัฒนาควรพิจารณาการเปลี่ยนแปลงโค้ด เช่น EIP 4444 อีกครั้ง เพื่อแก้ไขปัญหาการเติบโตของข้อมูลลูกโซ่ในอดีตที่เพิ่มขึ้น จากข้อมูลของ Rozmej อัตราการเติบโตของข้อมูลลูกโซ่ในอดีตคือ 20GB ต่อเดือน Beiko ตกลงว่านักพัฒนาควรหารือเกี่ยวกับ EOF, Verkle และ Prague/Electra เกี่ยวกับ Devconnect ต่อไป Beiko ยังเน้นย้ำอีกว่าวันพุธที่ 18 ตุลาคม จะทุ่มเทให้กับการประชุมโปรโตคอลเลเยอร์ 2 ที่มีลักษณะคล้าย EVM เพื่อส่งเสริมการทำงานร่วมกันระหว่างกลุ่มเหล่านี้ นอกจากนี้ จะมีการประชุมทางโทรศัพท์สำหรับผู้ดำเนินการ EOF ในวันเดียวกัน สุดท้าย Beiko กล่าวถึงงาน Layer2 Day โดยเฉพาะซึ่งจัดโดย L2Beat ที่ Devconnect