เรียนรู้เกี่ยวกับการอัปเดตที่เป็นไปได้ของการอัปเกรด Ethereum Shanghai ในบทความเดียว
ชื่อเรื่องเดิม: "Ethereum All Core Developers Call #149 Writeup》
ผู้เขียน: คริสติน คิม
เรียบเรียงข้อความต้นฉบับ: ข้าวต้มข้ามคืน
ชื่อเรื่องเดิม: "
ผู้เขียน: คริสติน คิม
ในวันที่ 10 พฤศจิกายน 2022 นักพัฒนา Ethereum รวมตัวกันเพื่อเข้าร่วมการประชุมทางโทรศัพท์ All Core Developers (ACD) ครั้งที่ 149 การประชุมทางโทรศัพท์ ACD นี้ดำเนินการโดย Tim Beiko จาก Ethereum Foundation รูปแบบวัตถุ (EOF) และการเปลี่ยนแปลงโค้ดที่เกี่ยวข้องกับโปรโตแด็งก์ฮาร์ดกำลังดำเนินการเพื่อเปิดใช้งาน การอัปเกรดครั้งใหญ่ครั้งแรกของเครือข่าย Ethereum ที่ควบรวมกัน (เรียกว่า Shanghai) ในระหว่างการโทรนี้ นักพัฒนายังได้หารือเกี่ยวกับ EIP อีกสี่รายการที่อาจรวมอยู่ในการอัปเกรด Shanghai แม้ว่าข้อเสนอแต่ละข้อจะนำข้อดีและประโยชน์ที่ไม่เหมือนใครมาสู่ Ethereum แต่ก็ยังมีการถกเถียงกันอย่างมากในหมู่นักพัฒนาเกี่ยวกับ EIP ใดที่ควรจัดลำดับความสำคัญสำหรับการรวม นอกเหนือจากการอภิปรายเกี่ยวกับการอัปเกรด Shanghai แล้ว นักพัฒนายังได้กล่าวถึงหัวข้อของการต่อต้านการเซ็นเซอร์และการแลกเปลี่ยนที่อาจเกิดขึ้นของคุณสมบัติการต่อต้านการเซ็นเซอร์ของ ethereum เพื่อความสามารถในการปรับขนาดเครือข่ายที่นี่แผนการอัพเกรดเซี่ยงไฮ้
ในการเรียก ACD ก่อนหน้านี้ นักพัฒนา ethereum ตกลงที่จะรวมรายการหลักของ EIP ในการอัปเกรด Shanghai บันทึกการโทรฉบับเต็มจาก ACD Call #148 อยู่ที่
ที่นี่
. เป็นที่น่าสังเกตว่าจากรายการ EIP หลักนี้ ผู้พัฒนาตกลงที่จะรวมข้อเสนอการถอน ETH ที่จำนำไว้ในการอัปเกรด Shanghai แต่ไม่ได้ตกลงที่จะรวม EOF หรือ proto-danksharding ในการอัปเกรดเดียวกันจนกว่าจะมีข้อเสนอสองข้อหลัง ถูกเพิ่มเติมเนื้อออก โดยเฉพาะอย่างยิ่งในหัวข้อ EOF นักพัฒนาลังเลว่าจะใช้ EOF ผ่านส่วนเล็กๆ ของส่วน EIP ของการอัปเกรด Shanghai หรือพยายามรวมวิสัยทัศน์ทั้งหมดของ EOF เข้ากับการอัปเกรด Ethereum หลังจากเซี่ยงไฮ้
Proto-danksharding
การใช้งาน EOFEIP 4844Danno Ferrin หัวหน้าวิศวกรซอฟต์แวร์ของ Hedera ให้ข้อมูลอัปเดตในการประชุมทางโทรศัพท์ของสัปดาห์นี้เกี่ยวกับความคืบหน้าของการนำ EOF ไปใช้งานในเซี่ยงไฮ้ เขาอธิบายว่านักพัฒนามักจะรวม EIPs ส่วนใหญ่ที่เกี่ยวข้องกับการใช้งาน EOF เข้าไว้ด้วยกันในการอัปเกรดขนาดใหญ่ครั้งเดียวโดยเร็วที่สุด EIPs ที่เกี่ยวข้องกับการใช้งาน EOF ที่นักพัฒนาซอฟต์แวร์พิจารณาในการอัปเกรด Shanghai ได้แก่ EIP 3540, EIP 3670, EIP 4200 และ EIP 4750 ยังคงมีความขัดแย้งในหมู่นักพัฒนาว่าควรรวม EIP 5450 ไว้ในรายการการเปลี่ยนแปลงรหัสที่เกี่ยวข้องกับ EOF หรือไม่GithubAndrew Ashikhmin จากทีมไคลเอนต์ Erigon Execution Layer (EL) ยังแสดงความกังวลว่าทีมภาษาสัญญาอัจฉริยะของ Solidity จะสามารถรองรับและใช้งาน EIP ทั้งสี่ (หรืออาจห้า) ได้อย่างเต็มที่หรือไม่ Ashikhmin เน้นย้ำว่าก่อนที่จะทำการอัปเกรดและเปิดใช้งาน EIP เหล่านี้ในเซี่ยงไฮ้ จำเป็นต้องยืนยันก่อนว่าทีมงาน Solidity พร้อมสำหรับ EIP เหล่านี้ที่จะนำไปใช้ Ashikhmin กล่าวในสายว่านี่คือ "การตรวจสุขภาพที่จำเป็น" ซึ่งสะท้อนโดย Marius van der Wijden จากทีมลูกค้าของ Geth EL
จากนั้นนักพัฒนาได้หารือเกี่ยวกับการพัฒนาล่าสุดใน proto-danksharding ไม่เหมือนกับการนำ EOF ไปใช้ EIP เดียวเท่านั้นที่เกี่ยวข้องกับการเปลี่ยนแปลงรหัส proto-danksharding กล่าวคือ
. Diederik Loerakker (มักเรียกกันว่า "Protolambda") นักวิจัยจาก OP Labs กล่าวว่ายังมีบางประเด็นที่อยู่ภายใต้การอภิปรายที่เกี่ยวข้องกับ EIP 4844 Ansgar Dietrichs จากมูลนิธิ Ethereum กล่าวเพิ่มเติมว่า บางเรื่องเกี่ยวข้องกับการกำหนดราคาขั้นต่ำสำหรับธุรกรรม blob และลดปริมาณธุรกรรม blob สำหรับการอัปเกรด Shanghai สิ่งที่ต้องทำเหล่านี้อยู่ใน
1、EIP 4758มีบทสรุป.
2、EIP 1153ปิดใช้งาน opcode ที่ทำลายตัวเองและ EIP อื่น ๆ ที่เป็นไปได้
3、EIP 2537ในขณะที่นักพัฒนากำลังเตรียมงาน EOF และ proto-danksharding สำหรับการอัปเกรด Shanghai นักพัฒนาได้ตกลงอย่างไม่แน่นอนที่จะดำเนินการกับ EIP อีกสี่รายการต่อไปเพื่อรวมไว้ในการอัปเกรด Ethereum ครั้งต่อไป
4、EIP 2294การปิดใช้งาน opcode "selfdestruct" บน Ethereum: นักพัฒนากลับมาทบทวนการสนทนาจากการโทร ACD ครั้งล่าสุดเกี่ยวกับการปิดใช้งาน opcode ที่นักพัฒนาพิจารณาอย่างกว้างขวางว่ามีประโยชน์ในสัญญาอัจฉริยะและแอปพลิเคชันที่กระจายอำนาจ (dapps) แนวปฏิบัติที่ไม่ดีที่ใช้ใน . opcode นี้เป็นหนึ่งใน opcode ดั้งเดิมไม่กี่ตัวที่มีต้นทุนคงที่ในการปรับใช้ แต่อาจมีค่าใช้จ่ายในการจัดเก็บที่ไม่จำกัดสำหรับเครือข่าย Micah Zoltu นักพัฒนาอิสระย้ำว่าสัญญาอัจฉริยะที่ใช้งานอยู่บน ethereum บางส่วนยังคงใช้ opcode แบบทำลายตัวเอง และการปิดใช้งานจะทำให้ฟังก์ชันการทำงานเสียหาย สำหรับกรณีขอบพิเศษเหล่านี้ อาจมีวิธีแก้ปัญหาบางอย่างและการเข้าถึงชุมชนเพิ่มเติมโดยมูลนิธิ Ethereum” Tim Beiko กล่าว
, การเพิ่ม Opcode ของพื้นที่เก็บข้อมูลชั่วคราว: ตัวแทนของทีม Uniswap และ Optimism ได้สร้างกรณีที่น่าสนใจเพื่อแนะนำ opcode ของพื้นที่เก็บข้อมูลชั่วคราวซึ่งทำงานเหมือนกับ opcodes ของพื้นที่เก็บข้อมูลปกติบน Ethereum ยกเว้น opcode ใหม่ทั้งสองนี้ ค่าของ TLOAD และ TSTORE จะ จะถูกยกเลิกหลังจากการทำธุรกรรมแต่ละครั้ง มีแรงจูงใจมากมายสำหรับการจัดเก็บชั่วคราว ซึ่งหนึ่งในนั้นตามที่ Mark Tyneway จาก Optimism อธิบายไว้ คือการประหยัดค่าน้ำมัน บน Uniswap เพียงอย่างเดียว EIP นี้มีศักยภาพในการประหยัดค่าน้ำมันต่อปีแก่ผู้ใช้ได้ถึง 3 ล้านดอลลาร์ นอกจากนี้ การใช้พื้นที่เก็บข้อมูลชั่วคราวแทนพื้นที่เก็บข้อมูลปกติจะช่วยลดหนี้ทางเทคนิคของ Ethereum ทีมงาน Uniswap และ Optimism ได้ทำงานมากมายเพื่อช่วยสร้างการใช้งานการเปลี่ยนแปลงโค้ดนี้ในไคลเอนต์ซอฟต์แวร์ Ethereum ต่างๆ และสร้างชุดทดสอบที่ครอบคลุมสำหรับ EIP Daniel Lehrner จากทีมลูกค้า Besu (EL) ขอบคุณนักพัฒนาจากภายนอกสำหรับการโทรเพื่อเตรียมความพร้อมสำหรับการใช้งาน EIP 1153 ถึงกระนั้นก็ดี ไม่ใช่ว่านักพัฒนาทุกคนจะพบภาระการทดสอบเพิ่มเติมของการรวม EIP 1153 ที่คุ้มค่า Marius van der Wijden ผู้พัฒนา Geth เตือนว่า EIP 1153 อาจรบกวนการเตรียมการอย่างต่อเนื่องสำหรับ EIP ที่เกี่ยวข้องกับ EOF และก่อให้เกิดความยุ่งยาก ถึงกระนั้น Van der Wijden กล่าวว่าเขายังคง "รอดู" เกี่ยวกับการเพิ่มความพยายามในการทดสอบการเปลี่ยนแปลงโค้ด นักพัฒนาตกลงที่จะทดสอบ EIP 1153 ต่อไปด้วยความช่วยเหลือจากนักพัฒนาภายนอกจากทีม Uniswap และทีม Optimism เพื่อรวมไว้ในการอัปเกรด Shanghai
การเพิ่ม BLS Precompilation: Alex Stokes จาก Ethereum Foundation อธิบายถึงข้อดีของการเพิ่ม BLS precompilation ให้กับ Ethereum มีเหตุผลหลายประการสำหรับเรื่องนี้ Stokes อธิบาย รวมถึงความสามารถในการสร้างหลักฐานการเข้ารหัสที่ปลอดภัยยิ่งขึ้น การทำงานร่วมกันที่ดีขึ้นกับห่วงโซ่บีคอนของ ethereum และฟังก์ชันเพิ่มเติมของพูลเดิมพันแบบกระจายอำนาจ Van der Wijden ตกลงว่าการเพิ่มการคอมไพล์ล่วงหน้าของ BLS เป็นการเปลี่ยนแปลงโค้ดที่สำคัญซึ่งอาจมีความสำคัญเหนือการนำ EOF และ EIP 1153 ไปใช้ อย่างไรก็ตาม เนื่องจากต้องมีการทดสอบอย่างครอบคลุมเพื่อใช้ EIP 2537 Van der Wijden แสดงความกังวลว่าการเพิ่มการเปลี่ยนแปลงรหัสนี้จะทำให้การอัพเกรดของ Shanghai ล่าช้า Jared Wasinger จาก Ethereum Foundation กล่าวว่าเขากำลังทำงานบน EIP แบบคู่ขนานที่สามารถให้เส้นทางการใช้งานที่ง่ายกว่า EIP 2537 นักพัฒนาตกลงที่จะทำงานกับ EIP 2537 และเริ่มลดจำนวนพรีคอมไพล์ BLS ต่างๆ เพื่อรวมการอัปเกรด Shanghai
: ในที่สุด Zainan Victor Zhou วิศวกรซอฟต์แวร์ของ Google ได้เปิดตัว EIP 2294 ซึ่งการเปลี่ยนโค้ดนั้นค่อนข้างง่าย แต่จำกัดขนาดไบต์ของฟิลด์ ID เชนของ Ethereum ซึ่งโดยปกติจะใช้เพื่อช่วยในการค้นหาโหนดหลังจากการฮาร์ดฟอร์ก Victor Zhou กล่าวในการประชุมทางโทรศัพท์ว่าเนื่องจากความเป็นไปได้ของ Sharding และ Multi-chain ใน Ethereum ในอนาคต กรณีการใช้งานของ Chain ID จะมีขนาดใหญ่ขึ้นและมีความสำคัญมากขึ้น เพื่อป้องกันไม่ให้ผู้คนพยายามใช้ประโยชน์จากฟิลด์ ID ของเชนโดยเก็บข้อมูลประเภทอื่นไว้ในนั้น Victor Zhou เรียกร้องให้มีการผูกมัดที่ชัดเจนกับขนาด ID ของเชน นักพัฒนาทุกคนยอมรับว่าการเปลี่ยนแปลงนี้มีความสำคัญและง่ายต่อการดำเนินการ Micah Zoltu เน้นย้ำว่าการเปลี่ยนแปลงโค้ดดังกล่าวต้องใช้ soft fork เท่านั้น ซึ่งหมายความว่าทีมไคลเอนต์ ethereum สามารถดำเนินการเปลี่ยนแปลงตามไทม์ไลน์ของตนเองโดยไม่ต้องประสานความสูงของบล็อกเฉพาะสำหรับการเปลี่ยนแปลง นอกจากนี้ยังมีการพูดคุยในหมู่นักพัฒนาว่าจะจำกัดขนาด chain ID เป็น 64 บิตหรือ 256 บิตเมื่อสิ้นสุดการโทร Tim Beiko สนับสนุนให้นักพัฒนาพูดคุยแบบออฟไลน์และหาตัวเลขแบบอะซิงโครนัสในการแชท Discord
ตามรายการ EIP ที่เพิ่มขึ้นเรื่อย ๆ ที่วางแผนจะรวมอยู่ในการอัปเกรด Shanghai นักพัฒนาจะแบ่งออกว่า EIP ใดควรจัดลำดับความสำคัญสำหรับการรวมไว้นอกรายการหลัก นักพัฒนา Ethereum Foundation ภายใต้นามแฝง "lightclient" เสนอให้คงการถอนแบบเปิดและจัดลำดับความสำคัญเฉพาะ EIP ที่สำคัญอื่นๆ ไม่ว่าจะเป็น proto-danksharding, การใช้งาน EOF หรือหนึ่งในสี่ข้อเสนอในการเรียก Tim Beiko คิดว่าไม่สมจริงที่จะพยายามรวมกลุ่มการใช้งาน EOF, proto-danksharding, BLS precompilation และเพิ่ม opcodes พื้นที่เก็บข้อมูลชั่วคราวในการอัปเกรดครั้งต่อไป เนื่องจากไม่มีเวลาประชุม Beiko จึงนำการอภิปรายเกี่ยวกับแผนการอัปเกรด Shanghai และสนับสนุนให้นักพัฒนาเตรียมการเพื่อหารือเกี่ยวกับลำดับความสำคัญสูงสุดของการอัปเกรด Shanghai นอกเหนือจากการให้คำมั่นว่าจะถอน ETH ในระหว่างการประชุมทางโทรศัพท์ ACD ครั้งต่อไป
จะลดต้นทุนการดำเนินงานของโหนด Ethereum ได้อย่างไร (เพิ่มความต้านทานการเซ็นเซอร์)
ในการพูดคุยเกี่ยวกับการอัปเกรดในเซี่ยงไฮ้ นักพัฒนา Ethereum อิสระ Micah Zoltu ได้นำเสนอหัวข้อสนทนาที่สำคัญเกี่ยวกับการต่อต้านการเซ็นเซอร์ของ Ethereum ผู้ใช้ ethereum เพียงไม่กี่รายเรียกใช้โหนดของตนเองเพื่อดำเนินการธุรกรรม Zoltu อธิบาย และผู้คนพึ่งพาบริการแบบรวมศูนย์เช่น Infura หรือ Alchemy ที่เซ็นเซอร์ผู้ใช้จากบางประเทศและเซ็นเซอร์การกระจายอำนาจบน ethereum แอปพลิเคชัน (dapps) เช่น Tornado Cash ในขณะที่นักพัฒนากำลังทำงานเพื่อปรับปรุงความสามารถในการปรับขนาดของ ethereum ผ่าน EIP 4844 ก็ยังขาดความพยายามในการลดต้นทุนในการรันโหนด ethereum และกระตุ้นให้เกิดความมั่นใจมากขึ้นในการต่อต้านการเซ็นเซอร์ของ ethereum Mikhail Kalinin นักพัฒนาในทีมไคลเอนต์ Ethereum Teku (CL) เสนอให้มุ่งเน้นที่การลดต้นทุนในการรันโหนด Ethereum หลังจากใช้งาน EIP 4844 Andrew Ashikhmin จาก Erigon เชื่อว่านักพัฒนา Ethereum สามารถมุ่งเน้นไปที่ทั้งสองอย่างในเวลาเดียวกัน และ Ansgar Dietrichs กล่าวว่าด้วยเหตุผลเชิงปฏิบัติ นักพัฒนา ethereum ควรเสียสละการต่อต้านการเซ็นเซอร์เพื่อความสามารถในการปรับขนาดในระยะสั้น และมุ่งเน้นไปที่การต่อต้านการเซ็นเซอร์ในระยะยาว
มุมมองของ Dankrad Feist นักวิจัยจาก Ethereum Foundation คือ EIP 4844 มีค่าใช้จ่ายเพิ่มขึ้นเล็กน้อยในการดำเนินงานของผู้ให้บริการโหนดและจะไม่สร้างความเสียหายอย่างมากต่อลักษณะการต่อต้านการเซ็นเซอร์ของ Ethereum Feist ยังเสริมว่าผู้ใช้ ethereum ส่วนใหญ่ไม่ได้รันโหนดของตนเอง ไม่ใช่เพราะค่าใช้จ่าย แต่เป็นเพราะประสบการณ์การใช้งานที่ไม่ดี Diederik Loerakker กล่าวว่าเพื่อสร้างระดับการกระจายอำนาจที่สูงขึ้น การปรับขนาดควรมีความสำคัญสำหรับนักพัฒนา Ethereum เนื่องจากการเปลี่ยนแปลงรหัสเช่น EIP 4844 จะทำให้ Ethereum มีราคาถูกลงในการใช้งานและเข้าถึงได้มากขึ้นสำหรับผู้คนทั่วโลก ผู้คนลดอุปสรรคในการ รายการ.
นอกเหนือจากข้างต้น ยังมีบางสิ่งที่นักพัฒนา Ethereum ยังไม่ได้กล่าวถึงในการโทรครั้งนี้ ได้แก่:ข้อเสนอการปรับปรุงข้อกำหนด API ของเครื่องยนต์
: ผู้พัฒนา Teku Mikhail Kalinin ได้สร้างข้อเสนอสำหรับการปรับปรุงข้อกำหนด Engine API ของ Ethereum ในเบื้องหลัง Engine API เป็นซอฟต์แวร์ที่ช่วยให้การสื่อสารระหว่างไคลเอนต์ EL และ CL ของโหนด Ethereum ทำได้ง่าย การเปลี่ยนแปลงที่เสนอไปยัง Engine API นั้นมีแนวโน้มที่จะมีการหารือในการประชุม Ethereum CL ในวันพฤหัสบดีหน้าShanghai "Core" กับ Prototype Developer Testnet
