สิ่งที่ Ethlabs ให้ความสำคัญสำหรับ Hegotá และเหตุผล
ทิศทางของ Ethereum มีความสำคัญต่อทุกคนที่สร้างบนมัน ใช้งานมัน ถือ ETH หรือเพียงแค่เชื่อในสิ่งที่มันสามารถเป็นได้ ในขณะที่อนาคตนั้นจะถูกกำหนดโดยผู้คน แอปพลิเคชัน และชุมชนที่สร้างบน Ethereum ทุกวัน การอัปเกรดเครือข่ายเป็นหนึ่งในวิธีหลักที่โปรโตคอลจะพัฒนาเพื่อตอบสนองความต้องการของพวกเขา Hegotá คือการอัปเกรดเครือข่าย Ethereum ครั้งถัดไปหลังจาก Glamsterdam และเอกสารนี้แบ่งปันมุมมองของ Ethlabs ต่อสิ่งที่เราเชื่อว่า Ethereum ควรให้ความสำคัญสำหรับมัน และเหตุผล
Ethlabs คือ ห้องปฏิบัติการ R&D ที่ไม่แสวงหากำไรสำหรับ Ethereum และ ETH ซึ่งมีอายุ 8 สัปดาห์ และภารกิจของเราคือการทำให้ Ethereum เป็นเลเยอร์การชำระเงินของเศรษฐกิจโลก เราอยู่ระหว่างการใช้งาน Ethereum ในโลกจริงและการพัฒนาโปรโตคอล และเราใช้เวลา รับฟัง ผู้ใช้ กระเป๋าเงิน แอปพลิเคชัน rollups สถาบัน ผู้ถือ ETH นักวิจัย และทีมไคลเอนต์ บางครั้งเรา สร้างบนเชน เพราะคุณไม่สามารถสร้างสนามกีฬาได้โดยไม่ได้เข้าร่วม! เราเชื่อว่าวิศวกรรมโปรโตคอลที่ยอดเยี่ยมควรทำให้ผลิตภัณฑ์ที่ยอดเยี่ยมเป็นไปได้ และผลิตภัณฑ์ที่ยอดเยี่ยมควรช่วยแจ้งว่าโปรโตคอลจะไปทางไหนต่อไป
ขอบเขตของ Hegotá กำลังอยู่ในช่วงเริ่มต้นของการถูกกำหนดผ่านกระบวนการทางเทคนิคแบบเปิดของ Ethereum และข้อเสนอด้านล่างนี้สะท้อนถึงงานจากบุคคลจำนวนมากและทีมวิจัยและไคลเอนต์ เอกสารนี้เป็นบันทึกที่โปร่งใสเกี่ยวกับสิ่งที่เราแนะนำให้ให้ความสำคัญ และจุดที่มุมมองของเรายังคงก่อตัวขึ้น สิ่งเหล่านี้คือจุดยืนที่เราอยากให้ผู้อื่นประเมิน ท้าทาย และช่วยปรับปรุง และเราจะปรับเปลี่ยนตามที่เราหารือและเรียนรู้เพิ่มเติมในอีกไม่กี่วันและสัปดาห์ข้างหน้า
สำหรับการอัปเกรด Hegotá เมื่อพิจารณาจาก EIP ทั้งหมดที่ถูกเสนอ นี่คือพื้นที่ที่เรามองว่ามีความสำคัญสูงสุดสำหรับ Ethereum:
- การต่อต้านการเซ็นเซอร์ที่แข็งแกร่งขึ้น: ทุกคนควรสามารถทำธุรกรรมให้ถูกรวมได้ ไม่ว่าพวกเขาจะเป็นใครหรือใช้ Ethereum เพื่ออะไร
- Ethereum ที่เร็วขึ้น: บล็อกที่เร็วขึ้นหมายถึงการยืนยันที่เร็วขึ้น ราคาบนเชนที่สดใหม่ขึ้น และการสิ้นสุดที่เร็วขึ้น
- นามธรรมของบัญชีแบบเนทีฟ: บัญชีควรรองรับ passkeys ธุรกรรมที่ได้รับการสนับสนุน การจ่ายแก๊สด้วยโทเค็น การทำเป็นชุด และความเป็นส่วนตัวที่แข็งแกร่งขึ้น โดยมีเส้นทางไปสู่คีย์หลังควอนตัม
- การปรับขนาด L1 อย่างต่อเนื่อง: แอปพลิเคชันต้องการความจุที่ยังคงมีราคาไม่แพงและคาดการณ์ได้ แม้ในเวลาที่มีความต้องการพุ่งสูง
การทำงานอย่างเปิดเผยเป็นเป้าหมายหลักของ Ethlabs ซึ่งเป็นเหตุผลที่ เราเขียนอัปเดตรายสัปดาห์ และในโอกาสเช่นนี้ โพสต์ชิ้นงานทางเทคนิคที่ยาวมากเพื่อแบ่งปันความคิดของเรา 😅 เราจะเผยแพร่เนื้อหาที่สั้นลงในช่วงไม่กี่สัปดาห์ข้างหน้าสำหรับผู้ที่ต้องการเพียงไฮไลท์ ส่วนถัดไปนี้จะยาวและเป็นเทคนิค สำหรับพวกคุณที่อ่านทั้งหมด ขอให้โชคดี!
สิ่งแรกก่อน: กระบวนการ EIP ทำงานอย่างไร?
ก่อนที่จะลงลึกในข้อเสนอต่างๆ จุดสำคัญประการหนึ่ง: ขั้นตอนที่สองของกระบวนการกำหนดขอบเขตของ Hegotá เพิ่งเริ่มต้นขึ้น ขั้นตอนแรกเลือก FOCIL เป็นหัวเรือของ Hegotá เมื่อวันที่ 6 ส.ค. มีกำหนดเส้นตายในการเสนอ EIP ที่ไม่ใช่หัวเรือ และตอนนี้กระบวนการ ACD จะดำเนินการเพื่อประเมินการอัปเกรด Hegotá โดยรวม
EIP ทั้งหมดด้านล่างนี้อยู่ในขั้นตอน PFI (Proposed for Inclusion) ในปัจจุบัน ยกเว้น EIP ที่ผ่าน กระบวนการหัวเรือ การเสนอ EIP เพื่อรวมนั้นทำได้โดยไม่ต้องขออนุญาต และส่วนใหญ่ไม่เคยถูกบรรจุในการอัปเกรดครั้งสุดท้าย
โดยเฉพาะอย่างยิ่ง เมื่องานพัฒนาเริ่มคืบหน้า ข้อเสนอจะเคลื่อนผ่านขั้นตอนการตรวจสอบและความมั่นใจที่เข้มข้นขึ้นเรื่อยๆ เกี่ยวกับการจัดส่งในที่สุด:
- PFI (Proposed for Inclusion): แนวคิดถูกเสนอสำหรับการอัปเกรด ขั้นตอนนี้ไม่ต้องขออนุญาต และ ไม่ได้ หมายถึงการสนับสนุนจากไคลเอนต์หรือการรวมในที่สุด
- CFI (Considered for Inclusion): ทีมไคลเอนต์ได้ตรวจสอบข้อเสนอแล้วและตั้งใจจะสร้างต้นแบบและทดสอบ
- SFI (Scheduled for Inclusion): มีความตั้งใจอย่างกว้างขวางที่จะรวม โดยสมมติว่าการพัฒนาและการทดสอบยังคงดำเนินไปด้วยดี
หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับวิธีการทำงานของกระบวนการนี้ เราขอแนะนำให้ดูคำอธิบายสั้นๆ ของ Tim Beiko ที่นี่
การจัดการ: วิธีนำทางบทความนี้
เราปฏิบัติตาม การจัดลำดับชั้นของ Forkcast เพื่อแสดงมุมมองของเราเกี่ยวกับการจัดลำดับความสำคัญของ EIP สำหรับ Hegotá เพื่อลดการตัดสินใจ เราจึงแมป EIP ที่ตรวจสอบทั้งหมดออกเป็นสี่ระดับโดยมีความหมายดังนี้:
- [ระดับ S] แนะนำอย่างยิ่งให้รวม
- [ระดับ A] แนะนำให้รวมหากอุปสรรคที่เหลือ เช่น ความซับซ้อนในการพัฒนา การวิเคราะห์ผลกระทบ หรือการนำไปใช้ ได้รับการแก้ไข
- [ระดับ B] มีคุณค่า แต่เป็นการยืดเยื้อสำหรับการอัปเกรดนี้
- [ระดับ D] ไม่แนะนำให้รวมใน Hegotá ในรูปแบบปัจจุบัน
- [กำลังสร้างความคิดเห็น] เรายังคงสร้างความคิดเห็นของเราเกี่ยวกับ EIP นี้
โปรดทราบว่าสิ่งเหล่านี้คือ \คำแนะนำ\ ของ Ethlabs เราประเมินข้อเสนอแต่ละข้อโดยพิจารณาจากวัตถุประสงค์ ข้อมูลจำเพาะ และความเข้าใจของเราเกี่ยวกับความซับซ้อนในการพัฒนาที่เป็นไปได้เป็นหลัก ยกเว้นในกรณีที่เรามีความแน่นอนหรือมีส่วนร่วมโดยตรงมากกว่า (เช่น Frames และ Quick Slots) และจะอัปเดตมุมมองของเราตามการประเมินจาก ethPandaOps ทีมทดสอบ และไคลเอนต์เมื่อเราดำเนินไปตามกระบวนการ
[CL] หมายถึง EIP ที่ส่งผลกระทบต่อไคลเอนต์เลเยอร์ฉันทามติ และ [EL] หมายถึง EIP ที่ส่งผลกระทบต่อไคลเอนต์เลเยอร์การดำเนินการ
โปรดทราบว่าเราเป็นผู้ร่วมเขียนและมีส่วนร่วมใน EIP หลายฉบับ (รวมถึง FOCIL, Frame Transactions และ Quick Slots) ในขณะที่เราพยายามประเมิน EIP ทั้งหมดอย่างเป็นอิสระจากการมีส่วนร่วมหรือไม่ก็ตาม โปรดพิจารณาสิ่งนี้เมื่อประเมินจุดยืนของเรา
สรุปโดยย่อ
การจัดอันดับ CL
คุณสามารถปรับเปลี่ยนการจัดอันดับ [CL] นี้บน Forkcaster ได้ที่นี่
การจัดอันดับ EL
คุณสามารถปรับเปลี่ยนการจัดอันดับ [EL] นี้บน Forkcaster ได้ที่นี่
ตอนนี้ โดยไม่ต้องกังวลใจอีกต่อไป นี่คือมุมมองของเราเกี่ยวกับการอัปเกรด Hegota ในวันนี้ โดยรวม:
ธีมสำหรับ Hegotá
0. FOCIL: เสริมสร้างการต่อต้านการเซ็นเซอร์
EIP-7805: FOCIL ได้รับสถานะ SFI และได้รับการยืนยันให้เป็นหัวเรือของ Hegotá แล้ว สมาชิกสามคนของทีม Ethlabs (Francesco, Barnabé และ Julian) เป็นหนึ่งในผู้ร่วมเขียน และเราสนับสนุนการรวมนี้อย่างยิ่ง เนื่องจากการตัดสินใจได้ถูกกำหนดไว้แล้ว เราจะพูดสั้นๆ เฉพาะเชนที่เป็นกลางต่อทุกคนเท่านั้นจึงจะสามารถเป็นรากฐานของความไว้วางใจสำหรับทุกคนได้ นี่คือสิ่งที่ทำให้ Ethereum สามารถขยายขนาดเพื่อเป็นเลเยอร์การชำระเงินที่แท้จริงสำหรับเศรษฐกิจโลก และสำหรับทุกคนในนั้น
1. Quick Slots: Ethereum ที่เร็วขึ้น
สล็อต 12 วินาทีของ Ethereum คือต้นทุนแฝงที่ลดคุณค่าของผู้ใช้ ดังนั้นเราจึงขอแนะนำอย่างยิ่งให้รวม [CL] EIP-8198: Quick Slots [ระดับ S] ใน Hegotá ด้วยเหตุผลสี่ประการ:
- UX ที่ดีขึ้นบน L1 ด้วยการยืนยันธุรกรรมที่เร็วขึ้น
- ตลาดบนเชนบน L1 ทำงานด้วยราคาที่สดใหม่ขึ้น ปรับปรุงสเปรดและเศรษฐศาสตร์ของ LP
- การสิ้นสุดและกฎการยืนยันที่รวดเร็วสืบทอดเวลาสล็อต ดังนั้นทั้งคู่จึงเร็วขึ้นด้วยบล็อกที่เร็วขึ้น ปรับปรุงการทำงานร่วมกันกับ Ethereum
- ผู้เสนอブロックต่อวินาทีมากขึ้นหมายถึงการต่อต้านการเซ็นเซอร์ที่เพิ่มขึ้น รวมถึงการต่อต้านการเซ็นเซอร์ทางเศรษฐกิจ: จำนวนเงินที่คุณต้องจ่ายเพื่อให้บล็อกว่างเปล่าในช่วงเวลาหนึ่ง
การทำให้เร็วขึ้นในขณะที่รักษาการกระจายศูนย์ที่เป็นเอกลักษณ์ของ Ethereum ทำให้พื้นที่บล็อกของ Ethereum มีค่ามากขึ้น และมูลค่านั้นจะตกเป็นของเครือข่ายและ ETH ทุกการลดลงคือมูลค่าที่ส่งมอบให้กับผู้ใช้ของเราในทันที ท้ายที่สุด บล็อกที่เร็วขึ้นถือเป็นหนึ่งในการเปลี่ยนแปลงที่นักพัฒนาแอปพลิเคชันร้องขอมากที่สุด
เหตุผลในการเริ่มตอนนี้คือการลดเวลาสล็อตจะไม่ใช่การเปลี่ยนแปลงที่ทำครั้งเดียวจบ เช่นเดียวกับการปรับขนาด การลดลงที่ส่งมอบให้ความแน่นอนแก่แอปพลิเคชันมากกว่าคำมั่นสัญญาในโรดแมป เส้นทางสู่สล็อตที่ต่ำกว่า 6 วินาทีเริ่มต้นด้วยการทำให้เวลาเปลี่ยนได้ จากนั้นจึงเปลี่ยนซ้ำๆ EIP-8198 แบ่งงานออกเป็นสองส่วน:
- การปรับโครงสร้างครั้งเดียวที่ทำให้เวลาสล็อตอัปเดตได้ง่ายขึ้นในข้อกำหนดและโค้ดไคลเอนต์
- การลดลงครั้งแรกใน Hegotá ตามด้วยการลดลงเพิ่มเติมในฟอร์กถัดไป เมื่อโรดแมปดำเนินไปและได้รับหลักฐานเชิงประจักษ์ด้านความปลอดภัย
Hegotá คือฟอร์กที่เหมาะสมในการจ่ายต้นทุนครั้งเดียว ePBS ใน Glamsterdam ได้ปรับโครงสร้างสล็อตใหม่แล้ว Hegotá จึงเป็นฟอร์กที่ค่อนข้างเบาสำหรับเลเยอร์ฉันทามติ ซึ่งเป็นหน้าต่างที่ปิดลงด้วย ฉันทามติที่แยกออกจากกัน ใน I* ดังนั้นแบนด์วิดท์ CL สำหรับการปรับโครงสร้างครั้งเดียวจึงพร้อมใช้งานในขณะนี้ ในแบบที่จะไม่พร้อมอีกเป็นเวลาหลายฟอร์ก
ความหมาย: เรามุ่งมั่นที่จะอยู่ที่ 12 วินาทีเป็นเวลาอย่างน้อยสองปีข้างหน้า หรือลงจอดที่ 10 วินาทีในอีกประมาณหนึ่งปีใน Hegotá และอาจน้อยกว่า 10 วินาทีในปีถัดไป การลดลงทั้งสองนี้ไม่ใช่การปรับปรุงทางทฤษฎี พวกเขาได้รับมูลค่าผู้ใช้ที่เพิ่มขึ้นและเศรษฐศาสตร์เครือข่ายที่ดีขึ้นโดยตรง เราคิดว่าถึงเวลาเริ่มต้นแล้ว
ข้อโต้แย้งที่พบบ่อยที่สุด
เราหารือเกี่ยวกับประเด็นสำคัญ 4 ประการที่ถูกหยิบยกขึ้นมาระหว่างการหารือเบื้องต้นกับนักพัฒนาไคลเอนต์และ EF Protocol:
1. ความซับซ้อนในการพัฒนา: การกำหนดเวลาสล็อตที่แม่นยำระดับมิลลิวินาทีได้ถูกรวมเข้ากับข้อกำหนดฉันทามติแล้วผ่านงาน ePBS และมีร่างข้อกำหนด CL และ EL สำหรับ EIP-8198 โดยมีค่าธรรมเนียมพื้นฐาน ขีดจำกัดแก๊ส และตาราง blob ที่ปรับขนาดใหม่เพื่อรักษาพฤติกรรมต่อวินาที ต้นทุนที่เหลือคือส่วนท้ายของกรณีขอบในไคลเอนต์และเครื่องมือที่สมมติเวลาสล็อตคงที่ บวกกับการทดสอบ การปรับโครงสร้างครั้งเดียวจะโหลดงานนี้ไว้ล่วงหน้า หลังจากนั้นการลดลงแต่ละครั้งคือการเปลี่ยนแปลงพารามิเตอร์
2. การพิสูจน์ zkEVM: ปัญหาหลักสองประการคือเวลาในการพิสูจน์สัมพัทธ์และค่าใช้จ่ายในการพิสูจน์คงที่
2.1 เวลาในการพิสูจน์สัมพัทธ์วัดส่วนแบ่งของเวลาสล็อตที่อุทิศให้กับการพิสูจน์ และส่วนแบ่งนี้เปลี่ยนแปลงอย่างไรเมื่อเวลาสล็อตเปลี่ยนไป นี่คือคำอธิบายสั้นๆ เกี่ยวกับช่วงเวลาที่เกี่ยวข้องในสล็อต ผู้สร้างปัจจุบันสังเกตการเผยแพร่ payload ก่อนหน้า และสามารถเริ่มสร้างได้ทันที จากนั้นบล็อก beacon ปัจจุบันจะยืนยัน payload ของสล็อตปัจจุบัน payload นี้ต้องได้รับการพิสูจน์ก่อนการเผยแพร่บล็อกของผู้เสนอ beacon ถัดไป
สำหรับการพิสูจน์ เวลาสัมพัทธ์ขั้นต่ำคือหนึ่งสล็อตเต็ม ลบด้วยเวลาแฝงของการเผยแพร่บล็อก beacon เวลาแฝงของการเผยแพร่บล็อก beacon นั้นไม่สามารถบีบอัดได้ แต่โดยโครงสร้างแล้วสั้น ดังนั้นจึงไม่ได้จำกัดเราโดยพื้นฐานในขั้นตอนนี้ นอกจากนี้ยังมีความเป็นไปได้ที่ผู้สร้างที่ปรับให้เหมาะสมจะพิสูจน์ payload ร่วมกันในขณะที่กำลังสร้าง ทำให้พวกเขาสามารถเริ่มพิสูจน์ก่อนที่ payload ที่ชนะจะถูกยืนยันโดยผู้เสนอブロック beacon
2.2 การพิสูจน์ zkEVM ส่วนใหญ่จะปรับขนาดเป็นเส้นตรงตามขนาดบล็อก ยกเว้นค่าใช้จ่ายคงที่บางส่วน สล็อตที่เร็วขึ้นหมายความว่ามีการจ่ายค่าใช้จ่ายคงที่บ่อยขึ้น ซึ่งเพิ่มเวลาแฝงสำหรับปริมาณงานที่เท่ากัน เมื่อกำหนดงบประมาณเวลาแฝงคงที่แล้ว เราต้องแน่ใจว่ายังคงได้ปริมาณงานที่ดี ที่นี่เราเห็นโอกาสสองประการ: ประการแรก ความก้าวหน้าทางวิศวกรรมจะยังคงลดเวลาแฝงของการดำเนินการคงที่เหล่านี้ลง ประการที่สอง การเลื่อนการคำนวณ state root ออกไป ตามที่อธิบายไว้ใน EIP-7862 จะย้ายการพิสูจน์ส่วนใหญ่ออกจากเส้นทางวิกฤต หมายความว่าเราสามารถเพิ่มงบประมาณเวลาแฝงสำหรับการดำเนินการที่ไม่สามารถบีบอัดได้ การบรรจบกันของโอกาสทั้งสองนี้บอกเราว่าสล็อตที่เร็วขึ้นจะไม่ขัดขวางการเพิ่มปริมาณงานที่เพียงพอในอนาคต
3. การเปลี่ยนผ่านหลังควอนตัม: แนวทางฉันทามติที่แยกออกจากกันได้รับการสนับสนุนเพียงพอที่จะถือว่ามีเสถียรภาพในส่วนที่เกี่ยวกับสถาปัตยกรรมฉันทามติในอนาคต การแยกออกจากกันหมายถึงการย้ายการลงคะแนนสิ้นสุดออกจากเส้นทางวิกฤตของการผลิตบล็อก โดยเฉพาะอย่างยิ่ง การรวมลายเซ็น PQ ขนาดใหญ่ และกลไก STARK แบบเรียกซ้ำที่เกี่ยวข้องทั้งหมด จะอยู่นอกเส้นทางวิกฤต สิ่งที่เหลืออยู่สำหรับการผลิตบล็อก และการได้รับกฎการเลือกฟอร์กเพื่อติดตามหัวของเชนผลลัพธ์ คือคณะอนุกรรมการซึ่งปัจจุบันคาดว่าจะประกอบด้วยผู้ตรวจสอบ 512 ราย และอาจเป็น 256 ราย ขนาดลายเซ็นหลังควอนตัมมีขนาดใหญ่กว่า แต่ก็สะดวกสบายในการเผยแพร่ภายในเวลาสล็อตที่เสนอคือ 10 วินาทีและอาจน้อยกว่านั้นในอนาคต
4. สัญญาอัจฉริยะและโครงสร้างพื้นฐาน: การพึ่งพาเวลาสล็อตในสัญญาอัจฉริยะและโครงสร้างพื้นฐานกำลังถูกสำรวจอยู่ในขณะนี้ สำหรับสัญญาอัจฉริยะ เราได้ ร่วมมือกับ Sourcify เพื่อดำเนินการวิเคราะห์สัญญาที่ได้รับการยืนยันทั้งหมด เรากำลังศึกษาผลกระทบของการอัปเดตเวลาสล็อตต่อรากบล็อก beacon ในอดีต ตามที่จัดเก็บตาม EIP-4788: Beacon block root in the EVM ในส่วนของโครงสร้างพื้นฐาน ตามข้อมูลเชิงประจักษ์ Etherscan กล่าวว่าการเปลี่ยนแปลงเวลาสล็อตมีแนวโน้มที่จะนำไปสู่โหลดที่มากขึ้น แต่โครงสร้างพื้นฐานถูกสร้างขึ้นในช่วงเวลาสล็อตที่แปรผันใน Proof-of-Work ดังนั้นจึงไม่จำเป็นต้องเปลี่ยนแปลงมากนัก
2. นามธรรมของบัญชี: ปรับปรุง UX ความปลอดภัย และความเป็นส่วนตัว
Ethereum และระบบนิเวศที่กว้างขึ้นนั้นถึงกำหนดเวลาสำหรับ AA แบบเนทีฟ ซึ่งจะนำมาซึ่งประโยชน์ด้าน UX เช่น กระเป๋าเงิน passkey ธุรกรรมที่ได้รับการสนับสนุน การชำระแก๊สด้วย ERC20 การทำธุรกรรมเป็นชุด และอื่นๆ
อย่างไรก็ตาม เส้นทางสู่ AA แบบเนทีฟนั้นขรุขระเป็นพิเศษเพราะ AA สัมผัสทุกส่วนของสแต็ก Ethereum รวมถึงไคลเอนต์ L2 กระเป๋าเงิน RPC เครื่องมือสำหรับนักพัฒนา ฯลฯ ดังนั้นจึงต้องได้รับการยอมรับจากผู้มีส่วนได้ส่วนเสียที่หลากหลายมหาศาล สิ่งนี้ทำให้ EIP AA ใดๆ ก็ตามยากที่จะผลักดันผ่านกระบวนการพัฒนาที่ขับเคลื่อนด้วยฉันทามติของ Ethereum แต่ยังยากที่จะบรรลุการนำไปใช้ในทางปฏิบัติหลังจากที่ EIP ถูกจัดส่ง
ดังนั้นเราจึงวางข้อเสนอ AA แบบเนทีฟของ Hegotá ซึ่งก็คือ Frame Transactions ไว้ในระดับ A ไม่ใช่เพราะมันไม่ดีพอสำหรับ S ในทางเทคนิค แต่เป็นเพราะเราต้องการคำนึงถึงความเสี่ยงในการนำไปใช้ในทางปฏิบัติซึ่งจะต้องใช้ความพยายามในการประสานงานอย่างมหาศาลเพื่อแก้ไข ด้วยพื้นฐานของทีมเราใน AA Ethlabs ตั้งใจที่จะมีบทบาทสำคัญในการนำ Frame Transactions สู่ตลาด โดยทำงานร่วมกับผู้มีส่วนได้ส่วนเสีย เช่น L2 และกระเป๋าเงิน เพื่อให้การเปิดตัว AA แบบเนทีฟประสบความสำเร็จ
ตอนนี้มาถึงข้อเสนอ AA เฉพาะสำหรับ Hegotá
[EL] EIP-8141: Frame Transactions [ระดับ A]
เราเชื่อว่า EIP-8141: Frame Transactions เป็นตัวเลือกที่ดีที่สุดสำหรับระบบ AA แบบเนทีฟของ Ethereum เมื่อเปรียบเทียบกับข้อเสนอ AA แบบเนทีฟอื่นๆ Frames มีคุณสมบัติที่พึงประสงค์หลายประการที่ทำให้สอดคล้องกับอาณัติ CROPS ของ Ethereum โดยเฉพาะ:
- นวัตกรรมบัญชีที่ไม่ต้องขออนุญาต: ตรรกะการตรวจสอบความถูกต้องถูกจัดการโดยโค้ด EVM ดังนั้นนักพัฒนาจึงมีอิสระในการพัฒนาตรรกะการตรวจสอบใดๆ ก็ได้ ตรงกันข้ามกับแนวทาง AA อื่นๆ ที่กำหนดให้มีบัญชีขาวของตรรกะการตรวจสอบ
- การสนับสนุนชั้นหนึ่งสำหรับโปรโตคอลความเป็นส่วนตัว: เป็นผลสืบเนื่องมาจากข้อแรก โปรโตคอลความเป็นส่วนตัว เช่น Railgun สามารถจัดการตรรกะการตรวจสอบความถูกต้องของ frame transactions ทำให้ผู้ใช้สามารถส่งธุรกรรมส่วนตัวได้โดยไม่ต้องพึ่งพา relayers แบบรวมศูนย์เหมือนในปัจจุบัน สิ่งนี้ทำให้โปรโตคอลความเป็นส่วนตัวมีความเป็นส่วนตัวและไม่สามารถถูกเซ็นเซอร์ได้มากขึ้นอย่างมีนัยสำคัญ
- ความปลอดภัยหลังควอนตัม: frame transactions ได้รับการพัฒนาโดยคำนึงถึงโรดแมป PQ ที่กว้างขึ้นของ Ethereum ตัวอย่างเช่น frame transactions ได้รับการออกแบบอย่างชัดเจนเพื่อให้สามารถรวมลายเซ็นได้ ทำให้ Ethereum สามารถเรียกเก็บแก๊สต่ำสำหรับลายเซ็น PQ ในที่สุด แม้ว่าแต่ละลายเซ็นจะมีราคาแพงมากในการตรวจสอบก็ตาม
จุดอ่อนหลักของ Frame Transactions ก็มาจากจุดแข็งที่ยิ่งใหญ่ที่สุดเช่นกัน: เนื่องจากการตรวจสอบความถูกต้องถูกจัดการโดยโค้ด EVM การตรวจสอบความถูกต้องจึงทำให้เกิดต้นทุนแบบไดนามิกแทนที่จะเป็นต้นทุนคงที่ ซึ่งอาจก่อให้เกิดความท้าทายสำหรับเชนที่มี TPS สูง เช่น L2 เรามองในแง่ดีว่าปัญหานี้สามารถแก้ไขได้ผ่าน EIP หรือ ERC เพิ่มเติมบนพื้นฐานของ frame transactions เช่น EIP-7819 ซึ่งธุรกรรมสามารถระบุตรรกะการตรวจสอบของตนแบบคงที่ เพื่อให้ sequencers สามารถ "ลัด" การตรวจสอบด้วยโค้ดเนทีฟได้หากจำเป็น นอกจากนี้เรายังตั้งใจที่จะทำงานร่วมกับ L2 และ EF เพื่อดำเนินการวัดประสิทธิภาพของ frame transactions เพื่อให้เราสามารถระบุและจัดการกับคอขวดด้านประสิทธิภาพใดๆ
[CL][EL] ส่วนเสริม Frame Transactions
มี EIP จำนวนหนึ่งที่สามารถมองว่าเป็นส่วนขยายของ Frame txs ซึ่งสร้างขึ้นจากความสามารถของมัน
[EL] [EIP-8250: Keyed Nonces for Frame Transactions](https://forkcast.org/eips/8250/) [ระดับ A]
- เราคิดว่า EIP นี้เป็นส่วนหนึ่งของ EIP-8141: Frame Transactions ในเชิงแนวคิด และเชื่อว่าควรจัดส่งไปพร้อมกับมัน
- EIP นี้แนะนำ nonces แบบ 2 มิติสำหรับ Frame transactions nonces แบบ 2 มิติช่วยให้บัญชีสามารถส่งธุรกรรมแบบขนานไปยัง mempool รวมถึงอนุญาตให้โปรโตคอลความเป็นส่วนตัวจัดเก็บ nullifiers เป็น nonces แบบ 2 มิติ สิ่งนี้สำคัญเนื่องจาก nonces แบบ 2 มิติเป็นพื้นที่จัดเก็บพิเศษที่มีราคาถูกมากในการอ่านและจัดเก็บ ดังนั้นธุรกรรมส่วนตัวจึงประหยัดแก๊สได้อย่างมากเมื่อเทียบกับการจัดเก็บ nullifiers ในพื้นที่จัดเก็บแบบไดนามิกปกติเช่นในปัจจุบัน สิ่งนี้สำคัญอย่างยิ่งในบริบทของการกำหนดราคาพื้นที่จัดเก็บใหม่ของ Glamsterdam (EIP-8037: State Creation Gas Cost Increase
[EL] [EIP-8272: Recent Roots for Frame Transactions](https://forkcast.org/eips/8272/) [ระดับ B]
- นี่คือ EIP อีกฉบับที่ช่วยยกระดับประสบการณ์การใช้โปรโตคอลความเป็นส่วนตัวกับ Frame transactions โปรโตคอลความเป็นส่วนตัวจำเป็นต้องเข้าถึง commitment roots ล่าสุดระหว่างการตรวจสอบความถูกต้อง ซึ่งหากจัดเก็บในพื้นที่จัดเก็บปกติ อาจไม่เพียงแต่มีราคาแพง แต่ยังขัดแย้งกับกฎ mempool สาธารณะของ Frames อีกด้วย EIP-8272 แก้ไขปัญหาเหล่านี้โดยการเปิดเผยสัญญาของระบบสำหรับจัดเก็บ root เหล่านี้ใน ring buffer ที่ลบ root เก่าโดยอัตโนมัติ
- เราจัดให้อยู่ในระดับ B เนื่องจาก EIP นี้เพิ่มความซับซ้อนอย่างมากให้กับ frames สำหรับกรณีการใช้งานเฉพาะ และเราไม่แน่ใจว่าอาจมีวิธีทั่วไป/หรูหรากว่านี้ในการบรรลุเป้าหมายเดียวกันหรือไม่
[CL] [EIP-8369: VOPS Profiles for FOCIL Eligibility](https://forkcast.org/eips/8369/) [ระดับ B]
- EIP นี้จัดการกับปฏิสัมพันธ์ระหว่าง Frames และ VOPS (validity-only partial statelessness) ซึ่งเป็นข้อเสนอสำหรับให้โหนด mempool จัดเก็บสถานะเพียงพอที่จะตรวจสอบธุรกรรม เพื่อที่แม้ในโลกของ statelessness (เนื่องจาก zkEVM) mempool ก็ยังคงสามารถต้านทานการเซ็นเซอร์ได้
- เราจัดให้อยู่ในระดับ B เนื่องจาก EIP นี้เชื่อมโยงอย่างแน่นแฟ้นกับวิสัยทัศน์เฉพาะของ statelessness ซึ่งชุมชนยังไม่ได้ตกลงร่วมกันอย่างเต็มที่
[EL] [EIP-7906: Transaction Assertions via State Diff Opcode](https://forkcast.org/eips/7906/) [ระดับ B]
- EIP นี้ปรับปรุงความสามารถในการตรวจสอบผลลัพธ์ของธุรกรรมแบบคงที่ ผู้ใช้สามารถยืนยันสิ่งที่ควรเกิดขึ้นได้อยู่แล้ว แต่ไม่สามารถยืนยันว่าไม่มีสิ่งอื่นเกิดขึ้น การพิสูจน์ว่าไม่มีการเปลี่ยนแปลงสถานะต้องใช้ opcode ใหม่ การรวมการยืนยันเชิงบวก (เช่น ยอดคงเหลือ WETH เพิ่มขึ้นอย่างน้อย 1.5) เข้ากับการยืนยันเชิงลบ (ไม่มีสถานะอื่นเปลี่ยนแปลง) ช่วยให้ผู้ใช้สามารถจำกัดผลกระทบทั้งหมดของธุรกรรมโดยโครงสร้าง โดยไม่ต้องจำลอง โดยกระเป๋าเงินฮาร์ดแวร์เป็นผู้ได้รับประโยชน์ที่ชัดเจนรายหนึ่ง
- เนื่องจากความซับซ้อน การรวมไว้ใน hard fork จะเป็นทางเลือกที่มุ่งมั่นมาก เราแนะนำให้ทำเช่นนี้ก็ต่อเมื่อ (a) ทีมไคลเอนต์เข้าใจความแตกต่างและผลกระทบของ EIP เฉพาะนี้อย่างแท้จริง และ (b) พื้นผิวการทดสอบและความซับซ้อนเป็นที่เข้าใจกันดี
[EL] การย้าย EOA [ระดับ B]
[EL] EIP-7851: Code-Controlled EOA Delegation [ระดับ B] และ [EL] EIP-8151: Account Code Restricted ecRecover [ระดับ B] ควรมองว่าเป็นมาตรฐานคู่กันที่นำเสนอเรื่องราวว่า EOA สามารถเปลี่ยนผ่านไปยังสมาร์ทแอคเคาท์ได้อย่างไร ในเรื่องราวนี้ EOA จะมอบหมายให้สมาร์ทแอคเคาท์ก่อนผ่าน EIP-7702 จากนั้น opcode ที่ EIP-7851 แนะนำจะทำให้การมอบหมาย 7702 เป็นแบบถาวร โดยปิดการใช้งานคีย์ ECDSA หลัก ในทางกลับกัน EIP-8151 จะทำให้ ecrecover รับรู้ถึงการปิดใช้งาน ดังนั้นคีย์เก่าจึงไม่สามารถระบายเงินผ่านโฟลว์แบบ Permit ได้
เราจัดอันดับคู่นี้ในระดับ B เนื่องจากเป็นเพียงหนึ่งในหลายแนวทางในการย้าย EOA ไปยังสมาร์ทแอคเคาท์ และแนวทางเฉพาะนี้ยังไม่ได้รับการตรวจสอบหรือการยอมรับอย่างกว้างขวาง โดยเฉพาะอย่างยิ่ง เรากังวลว่าแนวทางนี้ไม่ได้ตอบคำถามเรื่องหลายเชน: EOA เดียวกันจะย้ายบน L2 ได้อย่างไร? ผู้ใช้จะต้องดำเนินการเดียวกันบนเชนทั้งหมด รวมถึงเชนที่ยังไม่มีอยู่ ซึ่งจะทำให้ UX แย่ เราสงสัยว่าอาจมีแนวทางที่ดีกว่าที่ L2 สามารถใช้ L1 เป็น "รากฐานของความไว้วางใจ" สำหรับการย้าย EOA ดังนั้นเราจึงสงวนระดับ A/S สำหรับแนวทางที่จะช่วยให้ผู้ใช้สามารถย้ายครั้งเดียวสำหรับเชน EVM ทั้งหมด
[EL] รูปแบบลายเซ็น PQ [ระดับ A]
Hegotá ควรสร้างเส้นทางที่น่าเชื่อถือไปสู่ลายเซ็นหลังควอนตัม แต่เราควรยืนยันกลไกที่ถูกต้องก่อนที่จะมุ่งมั่น
- EIP-8355: Add ML-DSA verification precompiles ทำให้ความปลอดภัยของบัญชีหลังควอนตัมเป็นรูปธรรมควบคู่ไปกับ Frame Transactions
- ทางเลือก: ลงทะเบียนล่วงหน้าสนับสนุน PQ โดยไม่ต้องเปิดใช้งาน หรือกำหนดรูปแบบการรับที่สามารถรองรับคีย์ PQ ได้ในภายหลัง
[EL] EIP-7819: คำสั่ง SETDELEGATE [ระดับ A]
- ด้วย AA แบบเนทีฟที่มีแนวโน้มจะลงจอดใน Hegota สิ่งสำคัญคือต้นทุนในการปรับใช้สมาร์ทแอคเคาท์ใหม่ต้องต่ำ แต่การปรับใช้บัญชีจะแพงขึ้นจริงใน Glamsterdam เนื่องจาก EIP-8037 ด้วย EIP-7819 บัญชีใหม่จะใช้ตัวชี้ delegate แบบง่ายแทนสัญญา proxy ซึ่งช่วยลดปริมาณสถานะใหม่ที่ต้องสร้างขึ้นอย่างมาก จึงช่วยลดต้นทุนการปรับใช้
- เราจัด EIP นี้ในระดับ A เนื่องจากเราเชื่อว่าต้นทุนการปรับใช้บัญชีที่ต่ำลงจะช่วยลดแรงเสียดทานในการนำ AA มาใช้ได้อย่างมาก
3. วิศวกรรมประสิทธิภาพ: การปรับขนาด L1 อย่างต่อเนื่อง
Glamsterdam ได้ทำเครื่องหมายการเปลี่ยนแปลงในวิธีที่ Ethereum เข้าใกล้ R&D โดยประสิทธิภาพได้รับการปฏิบัติเป็นข้อจำกัด R&D ระดับแรก ทั้งในการออกแบบโปรโตคอลและในการทำงานของไคลเอนต์ การดำเนินการที่ล่าช้า การกำหนดราคาทรัพยากรใหม่ และงานเพิ่มประสิทธิภาพไคลเอนต์จำนวนมากช่วยให้สามารถปรับขนาดจาก 30M เป็น (อย่างน้อย) 200M ในช่วงสองปีที่ผ่านมา โดยทั่วไป งานด้านประสิทธิภาพทำให้เรามีทางเลือก: ส่วนหัวที่เราได้รับสามารถใช้สำหรับการปรับขนาด เพื่อทำให้สล็อตสั้นลง เพื่อลดข้อกำหนดของโหนด หรือทั้งหมดที่กล่าวมา
วันนี้ เรายังคงมองว่าการปรับขนาดอย่างต่อเนื่องเป็นสิ่งจำเป็น แอปพลิเคชันตัดสินใจว่าจะสร้างที่ไหนโดยพิจารณาจากไม่เพียงแต่ราคาปัจจุบัน แต่ยังรวมถึงว่า Ethereum สามารถขยายอุปทานพื้นที่บล็อกได้อย่างคาดการณ์ได้เมื่อเวลาผ่านไปหรือไม่ การส่งมอบการเพิ่มขึ้นอย่างสม่ำเสมอให้ความแน่นอนมากกว่าคำมั่นสัญญาในโรดแมปเพียงอย่างเดียว ความจุของเมนเน็ตยังคงห่างไกลจากการจัดการกับความต้องการที่พุ่งสูง: ในวันเกิดปีที่สิบเอ็ดของ Ethereum ค่าธรรมเนียมพื้นฐานเฉลี่ยรายวันอยู่ที่ประมาณ 0.1 gwei เท่านั้น แต่การ mint NFT ผลักดันให้สูงกว่า 10 gwei ในบางครั้ง โดยต้นทุนธุรกรรมเฉลี่ยสูงถึงประมาณ $1 และเปอร์เซ็นไทล์ที่ 90 มากกว่า $5 ดังนั้นการผลักดันการปรับขนาดของ Glamsterdam ควรดำเนินต่อไปใน Hegotá
เมื่อรวมกันแล้ว EIP ต่อไปนี้จะสานต่อโมเมนตัมการปรับขนาดของ Glamsterdam ในขณะเดียวกันก็เสริมหลักการที่กว้างขึ้นเบื้องหลัง: ประสิทธิภาพควรยังคงเป็นข้อกังวลระดับแรกทั้งในงานไคลเอนต์และการออกแบบโปรโตคอล
[EL] EIP-8131 และ EIP-8279 [ระดับ S]: ชุดการกำหนดราคาข้อมูลใหม่
หลังจาก Glamsterdam ข้อจำกัดด้านการผูกมัดถัดไปคือการแพร่กระจายของ payload ซึ่งส่วนหนึ่งเป็นเพราะแหล่งที่มาของ payload bytes ที่แตกต่างกันนั้นถูกสะท้อนอย่างไม่สอดคล้องกัน หรือไม่ถูกสะท้อนเลย ในการคิดค่า gas EIP-8131: Unified Transaction Content Floor ขยายขอบเขตของ transaction floor ที่มีอยู่ให้ครอบคลุมเนื้อหาที่ทราบก่อนการดำเนินการ ในขณะที่ EIP-8279: Block Access List Byte Floor ครอบคลุม BAL bytes ที่ถูกสร้างขึ้นแบบไดนามิกระหว่างการดำเนินการ
การวัดแบบไดนามิกนี้ทำให้ EIP-8279 มีความซับซ้อนมากกว่าอย่างชัดเจนในสองข้อนี้ อย่างไรก็ตาม เราขอแนะนำให้มองว่ามันเป็นชุดเดียวกัน เมื่อรวมกันแล้ว พวกมันจะสร้างการคิดค่าใช้จ่ายที่สอดคล้องกันสำหรับ bytes ที่เกี่ยวข้องกับธุรกรรม โดยจำกัด payload ในกรณีที่เลวร้ายที่สุด ในขณะที่ปล่อยให้ธุรกรรมทั่วไปที่ไม่เน้นข้อมูลส่วนใหญ่ไม่ได้รับผลกระทบ สิ่งนี้จะแก้ไขช่องว่างในการคิดค่าใช้จ่ายทรัพยากรพื้นฐาน และปูทางไปสู่การเพิ่มขีดจำกัด gas ต่อไป
[CL][EL] EIP-8146: Block Access List Sidecars [ระดับ A]
EIP-8146 เสริมการปรับราคาใหม่โดยการปรับปรุงเส้นทางวิกฤตด้วยตัวมันเอง โดยการแพร่กระจาย BALs แยกจาก payload ซึ่งช่วยปรับปรุงการแพร่กระจาย และทำให้ execution clients มีการเริ่มต้นที่ดีในการ prefetching สถานะและการคำนวณ post-state-root เราเห็นว่านี่เป็นประเภทของการเพิ่มประสิทธิภาพแบบ low-hanging fruit ที่เราไม่ควรปล่อยทิ้งไว้ งานนำไปปฏิบัติส่วนใหญ่เป็นกลไก gossip ของ CL ที่คุ้นเคย ทำให้ EIP นี้เป็น EIP ที่ใช้ความพยายามน้อยแต่ให้คุณค่าสูง โดยเฉพาะอย่างยิ่งใน fork ที่กำลังจะมีลักษณะเป็น EL-heavy
EIPs ที่เกี่ยวข้องอื่นๆ
[EL] การปรับเทียบ CPSB ใหม่ [ระดับ A]
- การเปลี่ยนแปลงที่เรียบง่ายมาก เราขอแนะนำให้เก็บไว้ใน pipeline และรวมหนึ่งในสองข้อหากเห็นว่าจำเป็นตามการเพิ่มขีดจำกัด gas ที่วางแผนไว้และการใช้งาน state และ execution gas ที่สังเกตได้
- EIP-8368: การปรับเทียบ CPSB ใหม่สำหรับขีดจำกัด Gas ใหม่: การติดตามผลที่วางแผนไว้ล่วงหน้าของ EIP-8037 เพื่อชดเชยความจริงที่ว่าต้นทุนต่อ state byte (CSPB) ถูกทำให้เป็นแบบคงที่แทนที่จะเป็นฟังก์ชันของขีดจำกัด gas ซึ่งเป็นเพียงการทำให้การนำไปใช้และการทดสอบง่ายขึ้น แนวคิดคือการแทนที่การปรับแบบ block-by-block ด้วยการปรับครั้งเดียวที่ forks ตามความจำเป็นเพื่อให้การเติบโตของ state เป็นไปตามเป้าหมายเมื่อขีดจำกัด gas เพิ่มขึ้น เนื่องจาก CPSB ปัจจุบันถูกปรับเทียบด้วยขีดจำกัด gas 150M จึงมีแนวโน้มว่าการปรับใน Hegotá จะเป็นสิ่งที่สมเหตุสมผล
- EIP-8372: ขีดจำกัด gas สถานะปกติ: ยังคงเป็นชุด superset ที่ค่อนข้างน้อยของ EIP-8368 ซึ่งอนุญาตให้มีการปรับที่ละเอียดกว่าแค่ CPSB เพื่อชดเชยเป้าหมายการเติบโตของ state หรือเป้าหมาย gas ปกติที่ต่ำกว่าเป้าหมายเนื่องจากการกำหนดราคาสัมพัทธ์ที่ไม่ถูกต้อง
[EL] EIP-7862: การหน่วงเวลา State Root [ระดับ B]
- ง่ายต่อการกำหนด spec แต่ความซับซ้อนของการนำไปใช้ของ client ยังไม่เป็นที่เข้าใจดีเท่าที่เราทราบ state root นั้นแพร่หลายใน codebases
- แม้ว่าจะมีประโยชน์บางประการในการลดอุปสรรคในการเข้าถึงการสร้างที่แข่งขันได้ (การคำนวณ state root ที่รวดเร็ว) แต่ข้อได้เปรียบที่สำคัญที่สุดของ EIP นี้ในความคิดของเราอยู่ในอนาคต (มีเวลามากขึ้นในการพิสูจน์การคำนวณ state root)
- EL เป็นด้านที่หนักอยู่แล้วของ Hegotá
[CL] EIP-8341: ภาระผูกพัน Payload การดำเนินการบางส่วน [ระดับ D]
- เราขอแนะนำให้ปฏิเสธ: ประโยชน์เล็กน้อย (ชะลอการคำนวณ state root เล็กน้อย) ไม่เร่งด่วน และถูกแทนที่โดย EIP-7862: การหน่วงเวลา State Root (ซึ่งให้เวลามากกว่ามากสำหรับมัน)
EIPs อื่นๆ
ตอนนี้เราจะครอบคลุม EIPs ที่เหลือ โดยจัดกลุ่มตามหัวข้ออย่างหลวมๆ สำหรับ EIPs บางส่วน เรายังคงกำลังสร้างความคิดเห็นของเรา เราจะอัปเดตเอกสารนี้เมื่อเราเรียนรู้เพิ่มเติมจากทีม client และผู้เขียน EIP ในอีกไม่กี่วันและสัปดาห์ข้างหน้า
เนื่องจาก Hegotá ดูเหมือนจะเป็น hard fork ที่เน้น EL เราขอแนะนำให้มีวินัยและรักษามาตรฐานที่สูงสำหรับ EIP ฝั่ง EL ใดๆ ที่จะผ่าน เราเชื่อว่าการทำให้ Hegotá ค่อนข้าง CL-light นอกเหนือจาก FOCIL และ Quick Slots เป็นสิ่งที่พึงปรารถนา: ขอบเขตที่แคบลงจะรักษา bandwidth เพื่อให้ทีม client มีพื้นที่ในการเตรียมตัวสำหรับการเปลี่ยนแปลงทางสถาปัตยกรรมที่ใหญ่ขึ้น
[CL] การออก
เราจงใจไม่กำหนดระดับให้ EIP-8363: การเผาการออกแบบลดหลั่น เราเชื่อว่าการออกไม่ใช่การตัดสินใจที่ core devs ควรทำเพียงลำพัง และรายการระดับเป็นการแนะนำอย่างชัดเจนถึง core devs สำหรับ EIPs ส่วนใหญ่ กระบวนการ ACD ทำงานได้ดีเนื่องจากการตัดสินใจเป็นเรื่องทางเทคนิคเป็นหลัก และชุมชนได้มอบหมายให้ core devs อย่างมีประสิทธิภาพ การออกนั้นแตกต่างกันตรงที่เป็นคำถามเกี่ยวกับนโยบายการเงินที่ชุมชนเองต้องบรรลุฉันทามติโดยคร่าว ความคิดเห็นของ core devs มีความสำคัญ แต่เป็นข้อมูลนำเข้าสำหรับการอภิปรายสาธารณะนั้น การจัดอันดับ EIP-8363 ควบคู่ไปกับ EIPs อื่นๆ จะถือว่ามันเป็นการตัดสินใจ ACD ปกติ ซึ่งเราเชื่อว่าไม่ควรเป็นเช่นนั้น
ในทางเทคนิค เราเห็นคุณค่าในการเปลี่ยนแปลงการออกให้สอดคล้องกับ EIP-8363 ปัญหาที่มันแก้ไขนั้นมีอยู่จริง: ความน่าเชื่อถือของการ slash ลดลงเมื่อมีการ stake ETH มากขึ้น อัตราส่วนการ stake ที่สูงหมายถึงรางวัลส่วนใหญ่ชดเชยการเจือจาง และการประหยัดต่อขนาดยังคงทำให้ช่องว่างระหว่างผู้ดำเนินการรายใหญ่และผู้ stake เดี่ยวกว้างขึ้น การเปลี่ยนแปลงก็มีความเสี่ยงเช่นกัน ตั้งแต่ความไม่แน่นอนของผลกระทบต่อการกระจายการ stake ไปจนถึงการรีเซ็ตนาฬิกาการแข็งตัวของนโยบายการเงิน เธรดของ Ansgar วางทั้งสองด้านและสะท้อนตำแหน่งของเรา พวกเราบางคนเคยโต้แย้งเพื่อการเปลี่ยนแปลงการออกในอดีตและยังคงมีความเชื่อมั่นในเส้นทางนั้น
เราขอแนะนำให้ทำการตัดสินใจเรื่องการออกหลังจากขั้นตอนการกำหนดขอบเขต Hegotá อื่นๆ ทั้งหมด สิ่งนี้จะทำให้การอภิปรายของชุมชนมีเวลาที่ต้องการและหลีกเลี่ยงการเบี่ยงเบนความสนใจจากกระบวนการกำหนดขอบเขตเอง
[CL] คุณสมบัติการ Stake
การปรับปรุงการ Stake อาจมีคุณค่า แต่ผลประโยชน์ที่ผู้ใช้เห็นควรมีความสำคัญสูงกว่าการเปลี่ยนแปลงเฉพาะโครงสร้างพื้นฐาน เว้นแต่จำเป็นอย่างยิ่ง
[CL] EIP-8015: การลบฟิลด์ deposit และ eth1data [ระดับ A]
- การทำความสะอาดหนี้ทางเทคนิคที่เรียบง่ายมาก ขอบคุณ EIP-7688: โครงสร้างข้อมูลฉันทามติที่เข้ากันได้กับอนาคต การพิสูจน์ Merkle ของฟิลด์ที่ไม่เกี่ยวข้องจะไม่ได้รับผลกระทบ ดังนั้นจึงไม่มีผลกระทบต่อผู้บริโภค chain
[EL][CL] EIP-8237: การซิงค์ CL/EL อิสระ [ระดับ B]
- สร้างขึ้นจากการแยก beacon block และ payload ที่นำเสนอโดย ePBS เพื่อให้ EL และ CL ซิงค์กันอย่างอิสระ เราเชื่อว่าสิ่งนี้มีศักยภาพในการทำให้ส่วนที่ซับซ้อนของ Ethereum clients ง่ายขึ้น
[CL] EIP-8205: การลงทะเบียนล่วงหน้าของ withdrawal credentials [ระดับ D]
- เราขอแนะนำให้ปฏิเสธ แม้ว่า EIP จะให้โซลูชันภายในโปรโตคอลสำหรับปัญหาจริงในการ stake แบบมอบหมาย แต่เราเชื่อว่าโซลูชันก่อนการฝากที่มีอยู่นั้นเพียงพอแล้ว และความซับซ้อนของกลไกที่เพิ่มเข้ามายังไม่สมเหตุสมผลในปัจจุบัน
[CL] EIP-8148: เกณฑ์การ sweep ที่กำหนดเองสำหรับผู้ตรวจสอบ [ระดับ D]
- เราขอแนะนำให้ปฏิเสธ เราเชื่อว่า EIP นั้นซับซ้อนเกินไป (สัญญาระบบใหม่, คำขอการดำเนินการใหม่, กลไก CL) สำหรับผลประโยชน์ของมัน ซึ่งเราเห็นว่าเป็นการส่งเสริมการรวมบัญชีเพิ่มเติมเล็กน้อยจากกลุ่มผู้ดำเนินการในบ้านเป็นหลัก เราไม่คิดว่าสิ่งนี้จะมีผลมากนักต่อการรวมบัญชีผู้ตรวจสอบโดยรวมเมื่อพิจารณาจากวิธีการกระจาย stake
[CL] EIP-8375: การเผารางวัลการดำเนินการบังคับของ ePBS [ระดับ D]
- เราขอแนะนำให้ปฏิเสธ เราเชื่อว่าสิ่งนี้มีแนวโน้มที่จะนำไปสู่ side-channeling มากขึ้นเท่านั้น ยิ่งไปกว่านั้น การอภิปรายหลายปีเกี่ยวกับกลยุทธ์การเผา MEV ไม่ได้นำไปสู่ข้อเสนอใดๆ ที่บรรลุฉันทามติการวิจัยในวงกว้าง
[CL] EIP-7716: บทลงโทษการรับรองที่ต่อต้านสหสัมพันธ์ [ระดับ D]
- เราขอแนะนำให้ปฏิเสธ เราไม่คิดว่ามีหลักฐานที่ชัดเจนเพียงพอว่าการเปลี่ยนแปลงครั้งใหญ่ในแรงจูงใจในการ stake นั้นสมเหตุสมผล ยิ่งไปกว่านั้น แรงจูงใจในการ stake มีแนวโน้มที่จะถูกปรับปรุงใหม่โดยเป็นส่วนหนึ่งของฉันทามติที่แยกออกจากกัน
[CL] EIP-8333: จัดแนว Checkpoint กับ Epoch Boundary Block [ระดับ D]
- เราขอแนะนำให้ปฏิเสธ แม้ว่าจะเป็นการทำความสะอาดที่ดี แต่เราเชื่อว่าควรเลื่อนออกไปเป็นการเปลี่ยนผ่านฉันทามติที่แยกออกจากกันครั้งใหญ่ที่กำลังจะมาถึง
[CL] EIP-8359: ฟิลด์รายงาน Beacon Block [กำลังสร้างความคิดเห็น]
[CL] การเตรียม PQ เพิ่มเติม
ข้อเสนอเหล่านี้ลดการพึ่งพา BLS ที่เหลืออยู่ก่อนการเปลี่ยนผ่านหลังควอนตัมในอนาคต
[CL] EIP-8365: การเลิกใช้ withdrawal credential ของ BLS [ระดับ A]
- เลิกใช้ withdrawal credential แบบเก่า เพื่อเตรียมพร้อมสำหรับการทำให้โปรโตคอลง่ายขึ้นและทำให้การเปลี่ยนผ่าน PQ ในอนาคตง่ายขึ้น
- เนื่องจากมันง่ายมาก เราเชื่อว่าควรใส่ไว้ตอนนี้
[CL] EIP-8367: การยุติยอดคงเหลือสำหรับผู้ตรวจสอบ BLS ที่เลิกใช้ [ระดับ D]
- เราขอแนะนำให้ปฏิเสธ เราเชื่อว่าผู้ตรวจสอบ 0x0 ส่วนใหญ่มีแนวโน้มที่จะทำการเปลี่ยนแปลง credential (BLSToExecutionChange) ก่อนหรือหลัง EIP-8365: การเลิกใช้ withdrawal credential ของ BLS ถูกเปิดใช้งาน ไม่ว่าจะเพื่อถอนเงินทุนหรือเพื่อให้สามารถ stake ต่อไปได้ เราไม่คิดว่ามีความเร่งด่วนมากนักในการแนะนำกลไกสำหรับจัดการกับ stake 0x0 ที่เหลืออยู่ เราขอแนะนำให้รวมแค่ EIP-8365 และดูผลลัพธ์ของมันก่อนตัดสินใจขั้นตอนต่อไป
[CL] EIP-8321: Hash-Chain RANDAO [ระดับ D]
- เราขอแนะนำให้ปฏิเสธ การทำให้ RANDAO ปลอดภัยต่อควอนตัมหลังเพียงอย่างเดียวให้ความปลอดภัยระดับโปรโตคอลเพียงเล็กน้อยในขณะที่คีย์ BLS ของผู้ตรวจสอบยังคงเสี่ยง แต่เพิ่มประมาณ 32 bytes ต่อผู้ตรวจสอบ กลไกการจัดการความลับใหม่ และกลไกที่มีวัตถุประสงค์เดียวเป็นส่วนใหญ่ การออกแบบฉันทามติ PQ ในวงกว้างยังคงไม่แน่นอน เราสนับสนุนการเปลี่ยนผ่านแบบวนซ้ำ แต่ขั้นตอนแรกควรเป็นไปตามแผนงานที่ตกลงกันไว้ แทนที่จะเสี่ยงที่จะถูกแทนที่โดยการออกแบบในที่สุด
[EL][CL] การเตรียม zkEVM
การเตรียม zkEVM ส่วนใหญ่ให้ประโยชน์ระยะสั้นที่จำกัดนอกเหนือจากการทำให้การทำงานของ full node ง่ายขึ้นสำหรับผู้ใช้กลุ่มแคบๆ ในขณะที่ใช้ bandwidth ในการนำไปใช้และอาจทำให้ EVM มีราคาแพงขึ้น เราควรรวมเฉพาะการเปลี่ยนแปลงที่มูลค่าระยะยาวชัดเจนว่าสมเหตุสมผลกับต้นทุนทันทีเหล่านั้น
[CL] EIP-8025: หลักฐานการดำเนินการทางเลือก [ระดับ D]
- EIP ไม่จำเป็นต้องมี hard fork ข้อเสนอที่จะรวมมันกับ Hegota เป็นเพียงการแสดงออกถึงการจัดลำดับความสำคัญ และเราไม่เห็นด้วยกับตัวเลือกนั้น เราเชื่อว่างานควรดำเนินต่อไป แต่ Hegotá ไม่ควรถูกปิดกั้นด้วยมัน
- ก่อนที่จะส่งมอบหลักฐานทางเลือก เราควรทำงานเพื่อกำหนดสถานะสุดท้ายก่อน จากนั้นจึงเร่งไปสู่สิ่งนั้น แทนที่จะส่งมอบหลักฐานทางเลือกก่อนที่จะมีมุมมองที่ชัดเจนเกี่ยวกับโมเดลผู้ตรวจสอบ/สถานะระยะยาว
- คำถามเปิดหลักคือบทบาทที่ผู้ตรวจสอบควรมีเกี่ยวกับสถานะ: ไม่ว่าพวกเขาควรให้บริการหรือถือครองบางส่วนต่อไป แทนที่จะกลายเป็นไร้สถานะอย่างสมบูรณ์ เนื่องจากผู้ตรวจสอบเป็นกลุ่ม node หลักที่มีมูลค่าเครือข่ายและฮาร์ดแวร์จริง การเปลี่ยนแปลงที่ทำให้บทบาทนั้นอ่อนแอลงควรผ่านเกณฑ์ที่สูงกว่า
[EL] EIP-7666: การทำให้ precompile ระบุตัวตนเป็น EVM [ระดับ A]
- การเปลี่ยนแปลงที่มีประโยชน์และเล็กน้อย
[EL] EIP-8200: การทำให้เป็น EVM [ระดับ B]
- EIP-8200 แทนที่ precompile ดั้งเดิมสามตัวด้วย EVM bytecode ที่เทียบเท่า สองตัวมีการใช้งานน้อยและดูเหมือนจะย้ายได้ตรงไปตรงมา ตัวที่สามถูกใช้อย่างแพร่หลายในการตรวจสอบ SNARK ดังนั้นเราจึงต้องการการประเมินผลกระทบก่อนที่จะสนับสนุนการลบออก
- หากการวิเคราะห์ผลกระทบพบว่าต้นทุนการย้ายต่ำสำหรับผู้ใช้ที่ได้รับผลกระทบ หรือหาก precompile ตัวที่สามถูกลบออกจากขอบเขต เราจะย้าย EIP-8200 ไปที่ [ระดับ A]
[EL] EIP-7709: อ่าน BLOCKHASH จาก Storage และอัปเดตต้นทุน [ระดับ D]
- ค่อนข้างก่อกวนเนื่องจากการเพิ่มขึ้นของต้นทุน gas ที่มาก ไม่เร่งด่วน
- การลดความเสี่ยงอาจรวมถึงการวิเคราะห์ผลกระทบ หรือทำในภายหลังด้วยการ warming ระดับ block บางรูปแบบ (หรือการ warming แบบเฉพาะกิจของค่าเหล่านี้) เพื่อลดผลกระทบ
[EL] EIP-8268: Storage Roots ใน Block Access Lists [ระดับ B]
- อาจต้องมีการวิเคราะห์ผลกระทบที่เป็นรูปธรรมต่อขนาด BAL และผลกระทบที่เกี่ยวข้องต่อต้นทุน tx (EIP-8279 เสนอให้คิดค่าใช้จ่ายสำหรับ BAL bytes) เนื่องจากรายการ BAL สำหรับแต่ละบัญชีที่ถูกแตะต้องจะได้รับ storage trie root เพิ่มเติม
[EL] คุณสมบัติ EVM
Hegotá จะยังคงต้องการการตัดสินใจ EVM แบบเฉพาะกิจบางอย่าง เราเชื่อว่าหลังจาก Hegotá แล้ว Ethereum ควรมุ่งสู่แผนงาน EVM ระยะยาวที่ถูกกำหนดโดยระบบนิเวศ EVM ที่กว้างขึ้น Ethlabs จะมีส่วนร่วมในสิ่งนั้น
[EL] EIP-5920: PAY opcode [ระดับ A]
- ง่ายมาก และเราเชื่อว่ามันเป็น primitive ที่ดีสำหรับ EVM ที่จะมี
- การทำความเข้าใจกรณีการใช้งานที่เป็นรูปธรรมให้ดีขึ้นจะเป็นสิ่งสำคัญ
[EL] EIP-8163: สำรอง opcode EXTENSION (0xae) [ระดับ A]
- มีประโยชน์มากสำหรับ L2s ไม่มีต้นทุนจริงสำหรับ L1 (เป็นข้อมูลเท่านั้น)
[EL] การใช้ซ้ำ / การขจัดข้อมูลซ้ำซ้อนของโค้ด [ระดับ B]
- EIP-8058: ส่วนลดการขจัดข้อมูลซ้ำซ้อนของ Contract Bytecode และ EIP-8298: คำสั่งการใช้โค้ดซ้ำ SETCODEFROM ทั้งคู่พยายามใช้ประโยชน์จากความจริงที่ว่าโค้ดคอนแทรกต์ถูกจัดเก็บแยกจากบัญชีที่เกี่ยวข้องใน clients โดยมี code hash เป็นตัวชี้ระหว่างกัน ดังนั้นโค้ดที่ใช้ร่วมกันเหมือนกันสามารถจัดเก็บแบบไม่ซ้ำซ้อนได้ EIPs ทั้งสองอนุญาตให้มีวิธีในการตั้งค่า account codehash เป็น hash ของโค้ดที่มีอยู่ที่อื่นได้ในราคาถูก
- เราถือว่านี่เป็นแนวคิดทั่วไปที่น่าสนใจ แต่การทำความเข้าใจผลกระทบและความเข้ากันได้ในอนาคตกับ binary trees จะเป็นสิ่งสำคัญ ไม่มีความชอบในตอนนี้ระหว่างสองข้อนี้
[EL] การปฏิรูปการกำหนดราคาหน่วยความจำ [ระดับ B]
- เราจำเป็นต้องตัดสินใจว่าเราต้องการทำการปฏิรูปหน่วยความจำใน Hegota หรือไม่ ยังไม่ชัดเจนสำหรับเราว่าปัจจุบันเรามีความเข้าใจเพียงพอเกี่ยวกับพื้นที่การออกแบบเพื่อทำการประเมินนี้หรือไม่
EIP-7686: ขีดจำกัดหน่วยความจำ EVM เชิงเส้น
- การเปลี่ยนแปลงที่เล็กกว่า แค่กำจัดต้นทุนการขยายหน่วยความจำแบบควอดราติก
EIP-7923: การคิดต้นทุนหน่วยความจำเชิงเส้นแบบอิงหน้า
- การปรับปรุงใหม่ที่ลึกซึ้งและมีหลักการมากกว่า แต่ซับซ้อนกว่า
[EL] EIP-8219: Opcodes เลขคณิตที่ตรวจสอบแล้ว [ระดับ B]
- โดยรวมแล้ว การเพิ่ม safe math ให้กับ EVM ดูเหมือนจะมีประโยชน์
- การกำหนดราคาจะต้องได้รับการยืนยันด้วย benchmarks มันซับซ้อนแค่ไหน?
- ด้วย benchmarks และการวิเคราะห์ผลกระทบ (มีกี่ tx ที่จะได้รับประโยชน์ เท่าไหร่ คอมไพเลอร์ใดบ้างที่จะเพิ่มการสนับสนุน?) มันอาจเป็นระดับ A
[EL] EIP-8360: TCREATE Opcode [ระดับ B]
- EIP แนะนำความสามารถในการสร้างคอนแทรกต์ชั่วคราวภายในขอบเขตธุรกรรม นี่เป็น primitive ที่ดีที่จะมีโดยทั่วไป
- EIP เพิ่มความซับซ้อนอย่างมาก ด้วยการประเมินความซับซ้อนในการนำไปใช้และทดสอบที่ละเอียดยิ่งขึ้น มันอาจเป็นระดับ A
[EL] EIP-7645: ใช้นามแฝง ORIGIN เป็น SENDER [ระดับ D]
- เราขอแนะนำให้ปฏิเสธ: การเปลี่ยนแปลงที่ทำลายล้าง การใช้ ORIGIN ที่ไม่เหมาะสม
[EL] EIP-8182: การโอน ETH และ ERC-20 ส่วนตัว [ระดับ D]
- เราขอแนะนำให้ปฏิเสธ: การเปลี่ยนแปลงครั้งใหญ่ เพิ่มการพึ่งพา zk หากเคยถูกนำมาใช้ เราเชื่อว่าควรเป็นหัวข้อหลัก
[EL] EIP-2488: เลิกใช้ CALLCODE opcode [กำลังสร้างความคิดเห็น]
[EL] EIP-4758: ปิดการใช้งาน SELFDESTRUCT [กำลังสร้างความคิดเห็น]
[EL] EIP-7979: Opcodes การเรียกและการส่งคืนสำหรับ EVM [กำลังสร้างความคิดเห็น]
[EL] EIP-8173: พื้นฐานของการควบคุมการไหลของ EVM [กำลังสร้างความคิดเห็น]
[EL] EIP-8253: เพิ่ม nonce ของบัญชี storage ที่มี nonce เป็นศูนย์ [กำลังสร้างความคิดเห็น]
[EL] EIP-8030: การสนับสนุนอัลกอริทึม P256 [กำลังสร้างความคิดเห็น]
[EL] การกำหนดราคา EVM
Glamsterdam เพิ่มราคาสำหรับการดำเนินการที่ตั้งราคาต่ำเกินไปซึ่งจำกัดปริมาณงานโดยรวม ข้อเสนอการกำหนดราคา EVM ของ Hegotá ส่วนใหญ่กล่าวถึงอีกด้านหนึ่ง: การลดราคาสำหรับการดำเนินการแต่ละรายการซึ่งต้นทุนปัจจุบันจำกัดการใช้งาน แต่ไม่ใช่ความสามารถในการปรับขนาดเครือข่าย ดังนั้นสิ่งเหล่านี้จึงเป็นสิ่งที่ดีที่มี แต่มีผลกระทบต่อ EIP แต่ละรายการน้อยกว่า เราเปิดรับการปรับราคาแบบกำหนดเป้าหมาย แต่ข้อเสนอที่แนะนำกลไกการวัดใหม่ควรถูกรวมไว้ก็ต่อเมื่อการออกแบบของมันถูกต้องและลดความเสี่ยงอย่างเพียงพอโดยแชมเปี้ยนที่ทุ่มเท
[EL] EIP-8358: การวัดค่า Gas สุทธิสำหรับการเปลี่ยนแปลงบัญชี [ระดับ B]
- ไม่มั่นใจในผลกระทบ ใน 900 ตัวอย่าง mainnet blocks, ~400k txs: 2.07% ของธุรกรรมทั้งหมดจะประหยัด gas และ 1.14% ของ block gas จะถูกประหยัด
[EL] EIP-7973: การวัดค่าการเขียนบัญชีแบบ Warm [กำลังสร้างความคิดเห็น]
[EL] EIP-7609: ลดต้นทุนพื้นฐานของ TLOAD/TSTORE [กำลังสร้างความคิดเห็น]
[EL] EIP-7971: ขีดจำกัดแบบตายตัวสำหรับ Storage ชั่วคราว [กำลังสร้างความคิดเห็น]
[EL] EIP-3298: การลบการคืนเงิน [กำลังสร้างความคิดเห็น]
[EL] EIP-8374: คงชุดการเข้าถึงแบบ Warm ไว้เมื่อมีการย้อนกลับ [กำลังสร้างความคิดเห็น]
[EL] EIP-8115: ค่าธรรมเนียมลำดับความสำคัญแบบ Batch เมื่อสิ้นสุด Block [กำลังสร้างความคิดเห็น]
[EL] EIP-8188: Block ที่เขียนล่าสุดสำหรับบัญชีและ Slots [กำลังสร้างความคิดเห็น]
[EL][CL] ข้อมูลการดำเนินการและการจัดทำดัชนี
[EL][CL] EIP-7668: ลบ bloom filters [กำลังสร้างความคิดเห็น]
[EL][CL] EIP-7807: SSZ execution blocks [กำลังสร้างความคิดเห็น]
[EL] EIP-8116: แทนที่ฟิลด์ใบเสร็จสะสม [กำลังสร้างความคิดเห็น]
[EL] EIP-8304: ดัชนีธุรกรรมและบันทึกที่เชื่อถือได้ [กำลังสร้างความคิดเห็น]
[EL][CL] เครือข่าย
เลเยอร์ P2P ของ Ethereum มีพื้นที่สำหรับการปรับปรุงแบบกำหนดเป้าหมาย โดยเฉพาะอย่างยิ่งในวิธีการกระจายธุรกรรม blobs และการรับรองทั่วเครือข่าย
[CL] EIP-8371: RowDAS - การสร้าง Blob ใหม่แบบกระจาย [ระดับ A]
- โดยทั่วไปจะป้องกันไม่ให้การสร้างใหม่แบบเต็มรูปแบบและประสิทธิภาพของ full custody node เป็นคอขวดต่อการปรับขนาดจำนวน blob
- มีคุณค่า ในที่สุดการสร้างใหม่แบบกระจายบางรูปแบบควรจะเข้ามาอยู่ในโปรโตคอลอย่างแน่นอน สิ่งนี้อาจทำให้เราสามารถลบ validator custody ได้
- จำเป็นต้องเข้าใจความซับซ้อนให้ดีขึ้น
[CL] EIP-8142: Block-in-Blobs (BiB) [ระดับ D]
- ยังเร็วเกินไป ไม่มีความเร่งด่วนมากนัก ค่อนข้างจะนาทีสุดท้าย มีคำถามมากมายที่ยังคงอยู่ (KZG หรือไม่? หัวข้อ gossip ใหม่หรือไม่?)
- ไม่ต้องการนำ KZG เข้าสู่เส้นทางวิกฤตของการผลิต block ทางเลือกอื่นไม่ชัดเจนและจะเพิ่มความซับซ้อนอีก
[CL] EIP-8243: การรวมการรับรองเป็นชุดที่ต้นทาง [ระดับ D]
- ไม่ชัดเจนว่าเราสามารถพึ่งพาสิ่งนี้เพื่อลดเวลาในการสรุปผลได้หรือไม่ ไม่ได้กำหนดขอบเขตที่ชัดเจนเกี่ยวกับโหลด
- การต้านทาน DoS ของกลไกยังไม่ชัดเจนทั้งหมด
[EL] EIP-8077: eth/XX - ประกาศธุรกรรมด้วย nonce [กำลังสร้างความคิดเห็น]
[EL] EIP-8094: eth/vhash - Mempool ที่รับรู้ Blob [กำลังสร้างความคิดเห็น]
[CL] EIP-8334: การกระจายการรับรองแบบรวมกลุ่ม [กำลังสร้างความคิดเห็น]
หากคุณยังคงอยู่กับเราด้วยวิธีใดก็ตาม ขอบคุณที่อ่านจนจบ รู้สึกอิสระที่จะตอบกลับด้วยคำถามใดๆ และเราจะพยายามอย่างดีที่สุดเพื่อตอบกลับคุณ! หากคุณข้ามและเพียงเลื่อนลงมาที่นี่เพราะการอ่านข้อความยาวเหยียดไม่ใช่สิ่งที่คุณตัดสินใจใช้เวลาวันอาทิตย์ของคุณ คุณจะพบกับความสุขที่รู้ว่าส่วนถัดไปนี้สั้น
คำพูด (เพิ่มเติม) สองสามคำ...
การอัปเกรด Ethereum นั้นซับซ้อนเพราะเดิมพันสูง โหนดหลายพันแห่งทั่วโลกเปลี่ยนไปใช้กฎใหม่ใน slot เดียวกัน และเครือข่ายไม่หยุดแม้แต่วินาทีเดียวในขณะที่พวกเขาทำเช่นนั้น ความเข้มงวดนั้นได้นำพาการอัปเกรดทุกครั้งที่ Ethereum ส่งมอบ ส่งผลให้เกิดเครือข่ายแบบกระจายอำนาจที่เฉลิมฉลอง 11 ปี ของการทำงาน 100%
จุดยืนของเราเกี่ยวกับ Hegotá เป็นการประเมินที่ดีที่สุดของเรา ณ วันนี้ แต่เราจะอัปเดตความคิดของเราเมื่อใดก็ตามที่หลักฐานใหม่จากการอภิปรายหรืองานนำไปใช้เปลี่ยนมุมมองของเรา
EIPs เหล่านี้บางส่วนถูกเขียนหรือพัฒนาโดยสมาชิกของ Ethlabs ส่วนอื่นๆ มาจากนักวิจัย นักพัฒนา client และผู้มีส่วนร่วมรายบุคคลที่มีความสามารถและตั้งใจดีอย่างเหลือเชื่อทั่วทั้ง Ethereum อย่างไรก็ตาม ทั้งหมด จะต้องอาศัยความร่วมมือระหว่างทีม client, กระเป๋าเงิน, แอปพลิเคชัน, L2s, ผู้ให้บริการโครงสร้างพื้นฐาน, สถาบัน, ผู้ดำเนินการ node และท้ายที่สุดคือผู้ใช้จึงจะประสบความสำเร็จ Ethereum คือโครงการร่วมกันของโลก และความก้าวหน้าทางเครือข่ายที่มีความหมายไม่เคยเป็นผลงานขององค์กรเดียว
เรารู้สึกขอบคุณที่ได้เป็นส่วนเล็กๆ ของระบบนิเวศนี้ และเราหวังว่าจะได้ช่วยให้ Ethereum ตระหนักถึงศักยภาพของมัน
– Ethlabs
