ชื่อต้นฉบับ: "Ethereum All Core Developers Execution Call #189 Writeup" ผู้เขียนต้นฉบับ: Christine Kim การรวบรวมต้นฉบับ: Luccy, BlockBeats หมายเหตุบรรณาธิการ: Ethereum All Core Developers Execution Call (ACDE) จัดขึ้นทุกสองสัปดาห์ ส่วนใหญ่จะใช้สำหรับการอภิปรายและการประสานงาน การเปลี่ยนแปลงใน Ethereum Execution Layer (EL) นี่คือการประชุมทางโทรศัพท์ครั้งที่ 189 ของ ACDE ในการประชุมครั้งนี้ นักพัฒนาได้หารือเกี่ยวกับประเด็นสำคัญบางประการในการอัปเกรด Pectra รวมถึงการเปลี่ยนแปลง รวมถึง EOF และ EIP 7702 การปรับปรุงขอบเขต Pectra และการเตรียมการสำหรับการเปลี่ยนแปลง Verkle การประชุมยังได้หารือถึงวิธีการบรรจุ EOF และ Pectra EIP อื่นๆ และวิธีการทดสอบการเปลี่ยนแปลงโค้ดเหล่านี้ นอกจากนี้ ยังมีการนำเสนอข้อเสนอบางส่วนเพื่อปรับปรุงกระบวนการอัปเกรดเครือข่าย Ethereum รวมถึงการปรับความถี่ของการอภิปรายหัวข้อการประชุมทางโทรศัพท์ของ ACD และข้อเสนอป้ายกำกับ EIP ใหม่ ความคืบหน้าในการบูรณาการของ EIP 4444 และ Portal Network ก็ถูกกล่าวถึงเช่นกัน Christine Kim รองประธานฝ่ายวิจัยของ Galaxy Digital ได้บันทึกประเด็นสำคัญของการประชุมครั้งนี้โดยละเอียด BlockBeasts ได้รวบรวมข้อความต้นฉบับไว้ดังนี้:

เมื่อวันที่ 6 มิถุนายน 2024 นักพัฒนา Ethereum ได้รวมตัวกันบน Zoom เพื่อเข้าร่วมในการประชุม All Core Developers Execution (ACDE) ครั้งที่ #189 ACDE Conference Call เป็นการประชุมทุกสองสัปดาห์ที่จัดโดย Tim Beiko หัวหน้าฝ่ายสนับสนุนโปรโตคอลที่ Ethereum Foundation ซึ่งนักพัฒนาจะหารือและประสานงานการเปลี่ยนแปลงใน Ethereum Execution Layer (EL) สัปดาห์นี้ นักพัฒนาตกลงที่จะรวม EOF และ EIP 7702 ไว้ในการอัพเกรด Pectra เพื่อหลีกเลี่ยงความล่าช้าในการอัปเกรดการทดสอบหลายไคลเอ็นต์เนื่องจากการเปลี่ยนแปลงโค้ดเหล่านี้ นักพัฒนาตกลงที่จะเปิดใช้งาน EOF บนเครือข่ายหลังการพัฒนา ซึ่งอาจอยู่ในรอบการเปิดใช้งานที่แตกต่างจาก EIP อื่นๆ เช่นเดียวกับที่นักพัฒนาวางแผนที่จะทดสอบ PeerDAS พวกเขายังได้หารือถึงวิธีการเลิกใช้งาน EIP 158 ในการอัพเกรดที่ Osaka เพื่อเตรียมพร้อมสำหรับ Verkle และขั้นตอนถัดไปสำหรับการนำ EIP 4444 ไปใช้ผ่านการบูรณาการกับ Portal Network ในที่สุด Beiko และทีม EF Developer Operations (DevOps) ได้แชร์การอัปเดตล่าสุดเกี่ยวกับกระบวนการกำกับดูแลและช่องทางการสื่อสารสำหรับการวางแผนการอัพเกรด Ethereum

ขอบเขตของเพคตรา

ก่อนการประชุม ACD ในสัปดาห์นี้ ทีมลูกค้า EL และทีม EF DevOps ต่างๆ ได้แบ่งปันความคิดเกี่ยวกับขอบเขตของ Pectra

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

นักพัฒนาชื่อ "Kamil Sliwak" กล่าวว่า EOF จะเป็น "การปรับปรุงครั้งใหญ่" จากมุมมองของผู้ใช้ที่มีปฏิสัมพันธ์กับคอมไพเลอร์ของภาษาโปรแกรมสัญญาอัจฉริยะ Ethereum Solidity Dragan Rakita ผู้พัฒนา Reth กล่าวเสริมว่า การคิดว่า EOF จะทำให้การเปลี่ยนแปลงของ Verkle ล่าช้าไปอย่างมาก “เรากำลังพูดถึงการขยายเวลาการเปลี่ยนแปลง 10% ถึง 20% EOF จะไม่เพิ่มสถานะ และการเพิ่มเติมอีกสามเดือนเพื่อปล่อยส้อมเพิ่มเติมบางส่วนจะไม่ทำให้ Verkle ล่าช้าอย่างมีนัยสำคัญ” Rakita กล่าว หากต้องการข้อมูลเพิ่มเติมว่า EOF คืออะไรและจะปรับปรุง Ethereum Virtual Machine (EVM ได้อย่างไร) โปรดฟังพอดแคสต์ Infinite Jungle ตอนนี้

Beiko ถามนักพัฒนาว่าพวกเขาต้องการรวม EOF เข้ากับ EIP ของ Pectra อื่นๆ หรือแยก EIP ของ Pectra ออกเป็นสองฮาร์ดฟอร์ก Andrew Ashikhmin ผู้พัฒนา Erigon กล่าวว่าเขาเชื่อว่านักพัฒนาควรพยายามเผยแพร่ EIP ของ Pectra ทั้งหมดพร้อมกัน หรือเลื่อน EOF ออกไปจนกว่าจะถึงการเปลี่ยนแปลงของ Verkle “สิ่งสุดท้ายที่ฉันต้องการคือการแยกระหว่าง Pectra และ Verkle เพื่อปล่อย EOF เนื่องจากฉันเห็นด้วยกับ Guillaume ว่ารัฐกำลังเติบโต ฉันคิดว่า Verkle มีความสำคัญมากกว่า EOF ดังนั้นในความคิดของฉัน นี่คือผลลัพธ์ที่เลวร้ายที่สุดที่เป็นไปได้ " อาชิคมินกล่าว Beiko แนะนำให้เผยแพร่ EIP ทั้งหมดของ Pectra รวมถึง EOF ในไคลเอนต์เดียว อย่างไรก็ตาม เพื่อวัตถุประสงค์ในการทดสอบ เขากล่าวว่านักพัฒนาควรพิจารณาใช้เครือข่ายการพัฒนาเพื่อดำเนินการเปลี่ยนแปลงโค้ดเหล่านี้เป็นระยะๆ “การใช้เครือข่ายการพัฒนาเป็นช่องทางให้เราจัดลำดับความสำคัญในแง่ของการทดสอบหลายไคลเอนต์ และถ้าเราเห็นว่า EOF ทำให้สิ่งต่าง ๆ ล่าช้าเป็นเวลานาน เราก็สามารถตัดสินใจแยกมันออกได้” Beiko กล่าว

ท่ามกลางการอภิปรายเกี่ยวกับวิธีการรวม EOF เข้ากับ Pectra นักพัฒนา Geth ยังคงแสดงความสงสัยในการแชทของ Zoom และตลอดการประชุมว่าควรรวม EOF ไว้ในการอัปเกรดหรือไม่ เพื่อตอบสนองต่อการอภิปรายอย่างต่อเนื่องของทีม Geth เกี่ยวกับ EOF George Konstantinopoulos ผู้พัฒนา Reth กล่าวว่า: "มาทำกันเถอะ มันค่อนข้างจะสับสนเล็กน้อยว่าการสนทนาจะดำเนินไปในทิศทางใด เราไม่รังเกียจที่จะขยายการเปลี่ยนแปลง Verkle ไปอีกสองสามวัน ข้อมูลแสดงให้เห็นว่า ว่าสถานะกำลังลดลง นี่จึงเป็นข้อโต้แย้งที่น่าสับสน และคุณมีแอปมากมายที่บอกคุณว่ามันเป็นฟีเจอร์ที่ดี แล้วทำไมเราถึงไม่ควรพิจารณาที่จะไม่ทำมันในเมื่อคนส่วนใหญ่สนับสนุนมัน”

Beiko เห็นด้วยและย้ำว่าควรรวม EOF ไว้ใน Pectra แต่ได้รับการทดสอบในขั้นตอนบนเครือข่ายการพัฒนา ซึ่งหมายความว่าทีมลูกค้าควรทดสอบ EIP ของ Devnet 1 ที่ใช้งานแล้วบน Devnet 0 จากนั้นในเครือข่ายการพัฒนาในอนาคต ให้เพิ่ม EOF สำหรับการทดสอบ กลยุทธ์นี้จะช่วยให้มั่นใจได้ว่าทีมลูกค้ามุ่งเน้นไปที่การเผยแพร่ EIP ส่วนหนึ่งของ Pectra บนไทม์ไลน์เดียวกัน และสามารถดำเนินการต่อไปบนเครือข่ายการพัฒนาลูกค้าหลายรายได้ Mario Vega วิศวกร DevOps ที่ Ethereum Foundation (EF) กล่าวว่าเขาคาดว่าจะมีการทดสอบข้อกำหนด Execution Layer (EL) ของ EOF ให้พร้อมภายในสองเดือน Parithosh Jayanthi วิศวกรของ EF DevOps กล่าวว่า EOF สามารถทดสอบแยกจาก EIP ของ Execution Layer (EL) อื่นๆ ใน Pectra ได้ อย่างไรก็ตาม เขามีความกังวลเกี่ยวกับการพึ่งพาอาศัยกันระหว่าง Consensus Layer (CL) EIP ใน Pectra และความซับซ้อนในการทดสอบการเปลี่ยนแปลงโค้ดเหล่านี้

Charles Cooper ผู้พัฒนาคอมไพเลอร์ Vyper กล่าวว่าในมุมมองของเขา EOF นั้นไม่ได้เร่งด่วนเท่ากับการเปลี่ยนแปลงโค้ดที่เขาเสนอเพื่อให้การป้องกันการโจมตีซ้ำมีราคาถูกและเป็นเรื่องธรรมดา Beiko เตือน Cooper ว่าแม้ว่าความเห็นพ้องต้องกันในวงกว้างเกี่ยวกับ EOF นั้นชัดเจน แต่ก็ไม่ชัดเจนว่าทีมลูกค้ามีพลังเพียงพอที่จะเพิ่มการเปลี่ยนแปลงโค้ดเพิ่มเติมหรือไม่ เช่น ที่เกี่ยวข้องกับการโจมตีซ้ำ “ฉันคิดว่าชัดเจนว่าหากเราผลักดัน EOF ไปข้างหน้า จะเหลือพลังงานเพียงเล็กน้อยในการทำสิ่งอื่น นี่จะเป็นทางแยกที่ใหญ่ที่สุดในปัจจุบัน” Beiko กล่าว

นอกเหนือจากการรวม EOF แล้ว นักพัฒนายังตกลงที่จะให้ EIP 7702 มาแทนที่ EIP 3074 อีกด้วย นักพัฒนายังคงหารือเกี่ยวกับข้อกำหนด EIP 7702 ใน การประชุมกลุ่มแยกต่างหาก Beiko แนะนำแนวทางที่คล้ายกันกับ EOF สำหรับ EIP 7702 "ฉันจะรวมมันไว้ในทางแยก แต่ถ้าเราไม่พอใจกับสเป็ค อย่าทำให้มันเป็นส่วนหนึ่งของ Devnet 1 หรือ 2 แล้วใช้เวลาในเดือนหน้าเพื่อแยกแยะสเป็คจริงๆ เพื่อที่เราจะได้มีการเพิกถอนที่ดีขึ้น กลไกมากกว่าที่เสนอในขณะนี้ EIP ที่ไม่ใหญ่เกินไปจะถูกเพิ่มในภายหลังในกระบวนการ” Beiko กล่าว นักพัฒนา Geth "Lightclient" กล่าวว่าหากทีมลูกค้าพร้อม พวกเขาควรใช้ EIP 7702 โดยเร็วที่สุด ไม่มีการคัดค้านการรวม EIP 7702 ไว้ในเครือข่ายการพัฒนา Pectra ฉุกเฉินถัดไป Devnet 1

ข้อมูลจำเพาะเพคตรา

ต่อมา Mikhail Kalinin ผู้พัฒนา Teku ได้แชร์การอัปเดตบางอย่างกับข้อกำหนด Pectra EIP ที่มีอยู่ ประการแรกคือข้อเสนอในการจัดการคำขอเลเยอร์ฉันทามติ (CL) ที่ ทริกเกอร์ ผ่านกลไกช่วยเหลือแทนโดยตรงในบล็อกเลเยอร์การดำเนินการ (EL) นักพัฒนา Prysm "Potuz" ชี้ให้เห็นว่ากลยุทธ์นี้จะทำลายตรรกะที่จำเป็นสำหรับการเปลี่ยนแปลงโค้ดในอนาคต กล่าวคือ การแยกผู้เสนอและผู้สร้างที่ชัดเจน (ePBS) "บล็อกบีคอนไม่ควรพึ่งพาเพย์โหลดที่มีอยู่แล้ว ดังนั้น ไม่ว่าจะเป็นการถอนหรือการฝากเงิน คุณไม่ต้องการให้บีคอนบล็อกพึ่งพาสิ่งที่อยู่ในเพย์โหลด เพราะนั่นจะทำให้การไหลของ ePBS หยุดชะงัก" Potuz พูดว่า. เนื่องจากปัญหานี้ Kalinin จึงตกลงที่จะถอนข้อเสนอของเขาและปิดคำขอดึงบน GitHub

Kalinin แบ่งปัน การเปลี่ยนแปลงอื่นๆ หลายประการกับข้อกำหนด EL และ API ของเครื่องยนต์ของ Pectra ซึ่งหนึ่งในนั้นคือการเปิดใช้งาน EL ที่ทริกเกอร์การรวมภายใต้ EIP 7251 ซึ่งเพิ่ม MAX_EFFECTIVE_Balance Beiko แนะนำให้นักพัฒนาตรวจสอบการเปลี่ยนแปลงเหล่านี้ก่อนการเรียก ACD ครั้งถัดไป เพื่อให้สามารถสรุปผลและพร้อมสำหรับการทดสอบใน Devnet 1

การเตรียมแวร์เคิล

จากงานของเขาเกี่ยวกับการเปลี่ยนแปลงของ Verkle นั้น Ballet กล่าวว่า EIP 158 จะสร้างปัญหาที่คล้ายกันกับ opcode SELFDESTRUCT ที่เลิกใช้แล้ว เพื่อหลีกเลี่ยงปัญหายุ่งยากบนเครือข่ายหลังการเปลี่ยนแปลง Ballet แนะนำให้ปิดการใช้งาน EIP 158 ในการอัพเกรด Pectra อย่างไรก็ตาม เขาตั้งข้อสังเกตว่าหากการใช้งาน EIP 7702 ได้รับการปรับแต่งอย่างละเอียดใน Pectra การเลิกใช้งาน EIP 158 อาจมีความล่าช้าและเกิดขึ้นพร้อมกับการเปลี่ยนแปลงของ Verkle Beiko แนะนำให้ Guillaume เริ่มร่างข้อเสนอของเขาเพื่อปิดการใช้งาน EIP 158

ประวัติหมดอายุ

นอกจาก Pectra และ Verkle แล้ว นักพัฒนาโปรโตคอล Ethereum ยังทำงานกับ EIP 4444 ซึ่งเป็นวันหมดอายุในอดีตอีกด้วย ตามที่ระบุไว้ใน แผน EIP 4444 และเอกสารสรุป เหตุผลในการเปลี่ยนแปลงโค้ดนี้คือ "ประวัติบล็อกใช้พื้นที่บนโหนดเป็นจำนวนมาก และเมื่อบล็อกเสร็จสมบูรณ์แล้ว จำเป็นเฉพาะในกรณีที่ไม่มีมติแบบจำกัดเท่านั้น กรณีการใช้งานที่สำคัญ" เอกสาร กล่าว ต่อว่า "ประวัติการบล็อกจะไม่ถูกจัดเก็บอย่างถาวรโดยโหนดเต็มรูปแบบอีกต่อไป หลังจากผ่านไประยะหนึ่ง ประวัติศาสตร์จะถูกลบออกจากโหนด และเอนทิตีที่ต้องการมันจะต้องสืบค้นจากโหนดนั้น ที่อื่น" Portal Network เป็นเครือข่ายทางเลือกที่มีการกระจายอำนาจ ซึ่งใช้โดยโหนดเพื่อสืบค้นข้อมูลประวัติ Ethereum

Merriam ย้ำถึงความตั้งใจของทีมที่จะให้การสนับสนุนการบูรณาการกับ Portal Network ให้กับทีมบัญชี EL เขากล่าวว่าหากไม่มีการสนับสนุนใดๆ การบูรณาการจะใช้เวลาประมาณหกเดือนในการพัฒนา อย่างไรก็ตาม ด้วยคำแนะนำและความร่วมมืออย่างใกล้ชิด เขามองในแง่ดีว่า EIP 4444 สามารถบรรลุความก้าวหน้าที่สำคัญได้ภายในสองเดือนข้างหน้า Jayanthi ถามว่ามีการตรวจสอบความปลอดภัยของข้อกำหนดเฉพาะของ Portal Network หรือไม่ เมอร์เรียมบอกว่าไม่ Ansgar Dietrichs นักวิจัยของ Ethereum Foundation ถามว่าทีมลูกค้าสามารถตัดสินใจได้ด้วยตัวเองว่าจะเชื่อมต่อกับเครือข่ายอย่างไร รวมถึงการรวมกลุ่มกับลูกค้าที่มีอยู่ การสร้างลูกค้าใหม่ หรือไม่ทำการบูรณาการใดๆ เลย Merriam ยืนยันว่าการตัดสินใจครั้งนี้ขึ้นอยู่กับดุลยพินิจของทีมลูกค้า

Merriam ถามทีมบัญชี EL ในสายเกี่ยวกับความคืบหน้าและความตั้งใจของพวกเขาใน EIP 4444 ผู้พัฒนา Nethermind Łukasz Rozmej กล่าวว่า “โดยรวมแล้ว มันเป็นเรื่องสำคัญ เมื่อวานนี้เรายังมีการประชุมกับทีม Portal อีกด้วย ปัญหาคือมีลำดับความสำคัญมากเกินไป บางครั้งมันก็ยากที่จะรักษาสมดุลของทุกอย่างให้ถูกต้อง ดังนั้นจึงมีลำดับความสำคัญที่เร่งด่วนน้อยกว่า เช่น Hard Fork แต่ Nethermind จะพยายามแก้ไขมัน และเราจะจัดลำดับความสำคัญให้กับมัน" Matt Nelson ผู้พัฒนา Besu กล่าวว่าเขารู้สึกแบบเดียวกัน Guillaume Ballet ผู้พัฒนา Geth กล่าวว่าทีมงานของเขาไม่ได้หารือเกี่ยวกับการรวมเครือข่ายพอร์ทัล

การปรับปรุงกระบวนการ ACD

การปรับปรุงกระบวนการ ACD ต่อไป Beiko ได้แบ่งปันข้อเสนอแนะหลายประการเพื่อปรับปรุงกระบวนการอัปเกรดเครือข่าย Ethereum อันดับแรกเขาแนะนำให้ลดความถี่ของการสนทนาเกี่ยวกับการโทรของ ACD ในหัวข้อที่ทีมบัญชียังไม่ได้ตรวจสอบโดยละเอียด Beiko แนะนำให้ทำเครื่องหมายหัวข้อเหล่านี้เพื่อตรวจสอบการเรียก ACD ก่อนที่จะอนุญาตให้นักพัฒนาเข้าร่วมการสนทนาอย่างมืออาชีพ จากนั้นจึงหารือในรายละเอียดเพิ่มเติมเกี่ยวกับการเรียก ACD ครั้งต่อไปตามความจำเป็น

ข้อเสนอแนะที่สองที่ Beiko ทำนั้นเกี่ยวข้องกับสถานะ “การพิจารณาเพื่อรวม” (CFI) ซึ่งโดยทั่วไปจะแนบไปกับข้อเสนอการปรับปรุง Ethereum (EIP) ที่กำลังพิจารณาเพื่อรวมไว้ในฮาร์ดฟอร์ค ในอดีตสถานะนี้ไม่ใช่ตัวบ่งชี้ที่เป็นประโยชน์ว่า EIP ใดมีแนวโน้มที่จะรวมอยู่ในฮาร์ดฟอร์ค Beiko แนะนำให้สร้างป้ายกำกับอื่น "Pending for Inclusion" (PFI) เพื่อให้นักพัฒนาสามารถแยกแยะได้ดีขึ้นว่า EIP ใดมีแนวโน้มที่จะรวมอยู่ในฮาร์ดฟอร์กมากกว่าและใดบ้างที่ไม่รวมอยู่ใน

Ansgar Dietrichs นักวิจัยของ Ethereum Foundation เขียนไว้ในแชท Zoom ว่าการสร้างป้ายกำกับใหม่สำหรับ EIP นั้นเป็น "ทิศทางที่ผิด" และมีแต่จะทำให้ป้ายกำกับ CFI กลายเป็น "ไร้ประโยชน์โดยสิ้นเชิง" Beiko กล่าวว่านักพัฒนาสามารถหารือเกี่ยวกับการปรับปรุงกระบวนการอัปเกรดเครือข่ายบน GitHub และ EthMagicians ต่อไปได้

นอกจากนี้ Mario Vega วิศวกร DevOps ของ Ethereum Foundation กล่าวว่าเขาหวังที่จะสร้างช่องทางย่อย Discord ใหม่สำหรับการทดสอบการอัปเดตที่เกี่ยวข้อง Vega กล่าวว่าขณะนี้ข้อมูลการทดสอบเผยแพร่อยู่ใน Ethereum R&D Discord กระจายอยู่ในหลายช่องทาง อย่างไรก็ตาม เขาหวังว่าฟอรัมใหม่นี้จะกลายเป็นข้อมูลอ้างอิงแบบ "ครบวงจร" สำหรับทีมลูกค้าเพื่อรับการอัปเดตการทดสอบจากทีม DevOps ของ Ethereum Foundation เขาขอให้ทีมบัญชีให้ข้อเสนอแนะเกี่ยวกับเรื่องนี้

ในที่สุด Beiko เตือนนักพัฒนาว่าการประชุมกลุ่มสองครั้งจะมีขึ้นในอีกไม่กี่วันข้างหน้า การประชุมครั้งแรกบน ePBS ซึ่งจะจัดขึ้นในวันที่ 7 มิถุนายน และอีกครั้งบน PeerDAS ซึ่งจะจัดขึ้นในวันที่ 11 มิถุนายน