ต้นฉบับ:What comes after Ethereums Cancun hard fork?》
ผู้เขียน : จอร์จิโอส คอนสตันโตปูลอส
เรียบเรียงโดย: โอเดลี่ โมนิ
1. ภาพรวมเนื้อหา
บทความนี้จะวิเคราะห์ความเข้าใจของทีม Paradigm Reth เกี่ยวกับ EIP ที่สำคัญ (Ethereum Network Improvement Protocol) ที่รวมอยู่ในฮาร์ดฟอร์คของปราก (ปราก) (ฮาร์ดฟอร์กของเลเยอร์การประมวลผลถัดไปหลังจากการอัพเกรด Cancun) และความเข้าใจในปี 2024 “EL Core Dev “มุมมองของแผน
การฮาร์ดฟอร์คของปรากอาจเกิดขึ้นบน Ethereum testnet ในไตรมาสที่สามของปี 2024 และจะดำเนินการบน mainnet ก่อนสิ้นปีนี้เนื้อหาการอัพเกรดประกอบด้วย：
1. ขอแนะนำให้รวม EIP ที่เกี่ยวข้องกับการเดิมพัน เช่น EIP-7002 เพื่อเปิดใช้งานการเดิมพันใหม่และกลุ่มการเดิมพันที่ไม่ต้องการความไว้วางใจจากภายนอก
2. การเปลี่ยนแปลง EVM อิสระ
นอกจากนี้ Paradigm ยังยินดีที่จะทำงานร่วมกับทีมใดๆ ก็ตามที่ต้องการตรวจสอบปัญหาที่ยากลำบากเพิ่มเติมในฮาร์ดฟอร์กของ EL เช่น ปราก และยินดีที่จะให้คำแนะนำรวมถึงการแก้ไขฐานโค้ด Reth
ทิศทางที่กระบวนทัศน์ยอมรับ:
1. กระบวนทัศน์เชื่อว่าควรให้ความสำคัญกับ EIP ต่อไปนี้: 7002, 6110, 2537
2. Paradigm รองรับ Ethereum Object Format (EOF) ที่อธิบายไว้ในข้อกำหนด แต่หวังว่าจะกำหนดขอบเขตโดยเร็วที่สุด และสร้าง meta-EIP สำหรับขอบเขตนี้โดยเฉพาะ
3. Paradigm ยินดีที่จะเพิ่ม Max Blob Gas EIP-4844 จะไม่แสดงความคิดเห็นมากเกินไปเกี่ยวกับจำนวนที่ถูกต้อง แต่จะเชิญนักวิทยาศาสตร์ข้อมูลให้ความร่วมมือในการตรวจสอบ EIP
4. Paradigm เปิดให้เผยแพร่เวอร์ชัน EIP-7547: Inclusion Lists ซึ่งสามารถช่วยต่อต้านการเซ็นเซอร์เลเยอร์ฐานได้
แนวทางที่กระบวนทัศน์ไม่เห็นด้วยกับ:
1. Paradigm ไม่สนับสนุนโครงสร้างข้อมูล Verkle Tries ที่ใช้ในฮาร์ดฟอร์คของปราก แต่สนับสนุนทีมลูกค้าเพื่อเริ่มทำงานในส่วนนี้ในไตรมาสที่สองของปี 2024 และสัญญาว่าจะอัปเกรดและเผยแพร่ในโอซาก้าในช่วงกลาง/ปลายปี 2025
2. Paradigm เชื่อว่าไม่ควรเพิ่มขีดจำกัดการดำเนินการ L1 หรือขนาดสัญญา แต่จะเชิญชวนบุคลากรด้านข้อมูลให้ความร่วมมือในการตรวจสอบผลกระทบของแนวทางนี้ในเครือข่าย Ethereum ในขณะเดียวกัน Paradigm ก็เต็มใจที่จะปรับมุมมองของตน เนื่องจากการทดสอบที่ผ่านมาแสดงให้เห็นว่าโหนด Reth สามารถรองรับโหลดที่เพิ่มขึ้นได้โดยไม่มีปัญหา
3. Paradigm เชื่อว่า EIP ของกระเป๋าเงิน/บัญชีจะต้องได้รับการทดสอบเปรียบเทียบกันเพื่อให้เข้าใจถึงการแลกเปลี่ยนในโลกไซเบอร์ได้ดีขึ้น หากการลบกระเป๋าสตางค์/บัญชีไม่ได้แยกจากกัน ก็มีความยินดีที่จะปรับใช้ EIP หลายรายการที่เกี่ยวข้องกับการลบบัญชีในอนาคต
4. หากชุมชนเห็นด้วยกับประตูหลังของ NSA ที่มีข่าวลือ Paradigm เชื่อว่าสามารถข้ามเส้น EIP-7212 (secp 256 r 1) ได้
5. หัวข้อแผนงานอื่นๆ: Paradigm ไม่มีความเข้าใจอย่างแท้จริงเกี่ยวกับ consensus layer EIP หรือ CL/EL (consensus layer/execution layer) fork Coupling แต่ข้อเสนอทั้งสอง EIP 7549 และ EIP 7251 ดูเหมือนจะมีแนวโน้มดี Paradigm ยังต้องการสนับสนุนความพยายาม PeerDAS ให้มากที่สุดเท่าที่จะเป็นไปได้จากฝั่ง EL และในปัจจุบันต้องการหลีกเลี่ยงการใช้ราก SSZ (EIP 6404, 6465, 6466) สุดท้าย Paradigm เชื่อว่าควรมีโซลูชันการเก็บข้อมูลในระยะยาวสำหรับ blobs ประวัติ และสถานะที่หมดอายุ เนื่องจากทั้ง EIP-4844 และ EIP-4444 ไม่ได้ระบุไว้ในเรื่องนี้ แต่ Ethereum ยินดีที่จะมอบโซลูชันดังกล่าวหรือไม่นั้นยังคงต้องได้รับการพิจารณา .
นี่คือรายละเอียด:
ทิศทางกระบวนทัศน์ในการระบุตัวตน
หากพูดโดยสรุปแล้ว Paradigm จะสนับสนุนสองประเด็นต่อไปนี้เป็นหลัก:
1) ลดช่องว่างระหว่างชั้นฉันทามติและชั้นการดำเนินการให้แคบลง
2) การปรับเปลี่ยน EVM สามารถทำได้แบบคนเดียวและทดสอบอย่างอิสระหรือแบบคู่ขนานก็ได้
EIP-7002
EIP นี้ปลดล็อกกลุ่มการวางเดิมพันใหม่และการวางเดิมพันที่ไม่น่าเชื่อถือโดยการเปิดใช้งานสัญญาอัจฉริยะบนฝั่งเลเยอร์การดำเนินการเพื่อควบคุมเครื่องมือตรวจสอบความถูกต้องเดี่ยวหรือหลายตัวบนฝั่งเลเยอร์ฉันทามติ จากมุมมองของ Paradigm EIP นี้สมเหตุสมผล และอย่างน้อยก็จะทำให้ Stake Pool ที่มีอยู่สามารถลบเลเยอร์ของการรวมศูนย์ออกจากสัญญาอัจฉริยะที่เปิดใช้งานการถอนเงินได้
นอกจากนี้ การแนะนำการคอมไพล์ล่วงหน้าแบบมีสถานะใน EVM ยังเป็นคุณลักษณะที่ Paradigm เห็นด้วยว่าจำเป็นต้องปฏิบัติตามในการใช้งาน EVM แต่นอกเหนือจากนั้น Paradigm เชื่อว่านี่คือ EIP ที่สามารถนำไปใช้ได้โดยตรง
EIP-6110
EIP นี้แนะนำฟังก์ชันการฝากเงินในสถานะเลเยอร์การดำเนินการ ซึ่งทำให้การจัดการสถานะที่ต้องดำเนินการในเลเยอร์ที่สอดคล้องกันง่ายขึ้น ในแง่ของการนำไปปฏิบัติ สิ่งนี้คล้ายกับการติดตามการถอนเลเยอร์ฉันทามติ ดังนั้น Paradigm โดยรวมจึงรู้สึกว่านี่เป็นเรื่องง่ายที่จะนำไปใช้และ EIP ที่เป็นอิสระ
EIP-2537
ปัจจุบัน BLS 12-381 มีการใช้งานหลายอย่างและเป็นเส้นโค้งที่ใช้กันทั่วไปใน SNARK, อัลกอริธึมลายเซ็น BLS และ EIP-4844 จำนวนมาก กระบวนทัศน์เชื่อว่าความซับซ้อนในการใช้งาน BLS 12-381 ต่ำ เนื่องจากเปิดเผยเฉพาะอัลกอริธึมการตรวจสอบของเส้นโค้งผ่านอินเทอร์เฟซที่คอมไพล์แล้ว ดังนั้นอาจจำเป็นต้องมีแฮชที่คอมไพล์แล้วของเส้นโค้ง BLS 12-381 ด้วย
รูปแบบวัตถุ Ethereum (EOF)
พูดง่ายๆ ก็คือ EOF จะรองรับทั้ง Solidity และ Vyper ด้วยการเปิดตัวที่หลากหลายมากขึ้น การจัดรูปแบบโค้ด และการปรับแต่งการตรวจสอบเพื่อให้การวิเคราะห์ง่ายขึ้นก็เป็นสิ่งที่สมเหตุสมผลเช่นกัน Paradigm แนะนำให้พิจารณาสิ่งใด ๆ นอกเหนือจากนี้อย่างรอบคอบและแนะนำด้านล่าง EIP บางตัวก็ยินดีเช่นกัน ทำการปรับเปลี่ยนเพิ่มเติม
ด้านดี:
● การเปลี่ยนแปลงเฉพาะ EVM เท่านั้นที่สามารถทดสอบได้โดยใช้ Ethereum/testnet และนำไปใช้โดยบุคคลเดียว
● การเปลี่ยนแปลง EVM ที่ต้องการโดย Vyper และ Solidity
● ช่วยปรับปรุงประสิทธิภาพและเพิ่มขีดจำกัดขนาดสัญญา
● ขจัดความจำเป็นที่ EVM จะทำการวิเคราะห์ไบต์โค้ด ณ รันไทม์ ซึ่งอาจใช้เวลานานถึง 50% โดยไม่ต้องแคช และจะเพิ่มขึ้นเมื่อขนาดสัญญาเพิ่มขึ้น
● เปิดใช้งานการโหลดโค้ดบางส่วน เจ้อเจียงช่วยดำเนินการสัญญาอัจฉริยะขนาดใหญ่
● Devex: จะช่วยแก้ไขปัญหา สแต็กลึกเกินไป ด้วย dupN/swapN และการปรับปรุงเครื่องมืออื่นๆ
● คุณลักษณะที่ใช้งานได้ในอนาคต: สามารถนำเสนอคุณลักษณะ cross-L2 ที่ปลอดภัยใหม่ได้ และเครื่องมือจะทราบว่าคุณลักษณะใดที่เข้ากันได้
ด้านที่ไม่ดี:
● ระยะและเป้าหมายที่กำลังเคลื่อนที่
● ไม่มีการสนับสนุนที่สำคัญในการรวมไว้
● รหัสเดิมยังต้องการการสนับสนุน
● ก่อนที่จะนำมาใช้ มีความแตกต่างชั่วคราวระหว่าง Ethereum mainnet และเครือข่าย EVM อื่นๆ
กระบวนทัศน์เชื่อว่าความสามารถ EOF ต่อไปนี้ควรได้รับการปรับใช้ภายในปี 2567 และแนะนำให้กำหนดขอบเขตและมุ่งมั่นที่จะนำไปใช้โดยเร็วที่สุด ควรพิจารณาประเด็นเพิ่มเติมสำหรับการปรับใช้ในภายหลัง ดังนั้น Paradigm จึงแนะนำให้:
● EIP-3540 (EOF - รูปแบบออบเจ็กต์ EVM v1): แนะนำโค้ดและคอนเทนเนอร์ข้อมูล รวมถึงการเพิ่มโครงสร้างและการกำหนดเวอร์ชันให้กับ Ethereum bytecode
● EIP-3670 (EOF - การตรวจสอบรหัส): ปฏิเสธสัญญาใดๆ ที่ไม่เป็นไปตามรูปแบบ EOF เมื่อใช้งาน สามารถดำเนินการได้เฉพาะโค้ดที่มีโครงสร้างเพิ่มเติมเท่านั้น และคำสั่งที่ไม่ถูกต้องและไม่ได้กำหนดจะถูกปิดใช้งาน
● EIP-663 (คำสั่ง SWAP และ DUP ไม่จำกัด): EIP นี้แก้ปัญหา สแต็กลึกเกินไป ใน Solidity โดยการใช้การวิเคราะห์ JUMPDEST เป็นค่าปัจจุบันอาจมีผลข้างเคียง แต่เป็นคุณลักษณะที่ต้องการอย่างมากของ EVM ที่จะกลายเป็นภาษา
● EIP-4200 (EOF - การกระโดดแบบสัมพันธ์แบบคงที่): การวิเคราะห์แบบคงที่ดีขึ้น ไม่มีการกระโดดโดยไม่ได้กำหนด การคอมไพล์ aot ที่ดีกว่าและการข้ามแบบสัมพัทธ์นั้นเอื้อต่อการนำโค้ดกลับมาใช้ใหม่ได้มากกว่า
● EIP-4750 (EOF – ฟังก์ชัน): จำเป็นต้องแก้ปัญหารูทีนย่อยที่สามารถใช้การกระโดดแบบไดนามิกแต่ไม่สามารถใช้การกระโดดแบบคงที่ได้ และยังอนุญาตให้มีการโหลดโค้ดบางส่วน ซึ่งสามารถทำงานได้ดีกับโครงสร้างข้อมูล Verkle และเพิ่มขีดจำกัดขนาดสัญญา
● EIP-5450 (EOF - การตรวจสอบสแต็ก): ตรวจสอบข้อกำหนดของโค้ดและสแต็ก ลบการตรวจสอบรันไทม์สแต็กอันเดอร์โฟลว์และโอเวอร์โฟลว์สำหรับคำแนะนำทั้งหมด ยกเว้น CALLF (EIP-4750)
● EIP-7480 (EOF - คำแนะนำในการเข้าถึงข้อมูลบางส่วน): อนุญาตให้เข้าถึงส่วนข้อมูลของรหัสไบต์
● EIP-7069 (ปรับปรุงคำสั่ง CALL)ความสามารถในการลบความสามารถในการสังเกตก๊าซออกจาก CALL จะทำให้การปรับราคาก๊าซในอนาคตง่ายขึ้น แม้ว่า EIP นี้ไม่ขึ้นอยู่กับ EOF แต่ Paradigm เชื่อว่า Hard Fork นี้เป็นโอกาสที่ดีที่จะแนะนำ EIP นี้
กระบวนทัศน์ที่ถูกต้องEIP-6206 (EOF-JUMPF และฟังก์ชันไม่ส่งคืน)ไม่แน่ใจ แม้ว่า EIP นี้จะอนุญาตให้เพิ่มประสิทธิภาพการเรียกส่วนท้ายในฟังก์ชัน EOF ได้ แต่ Paradigm ยังคงต้องการดูการวิเคราะห์ภาษาเพื่อประโยชน์ของมัน ถ้าไม่เช่นนั้น Paradigm จะเห็นว่าเหมาะสมที่จะลบออกจากขอบเขตและรวมไว้ในการอัปเดต EOF ครั้งต่อไป
กระบวนทัศน์ประมาณการปริมาณงานข้างต้นจะอยู่ที่ประมาณ 1-2 คนต่อเดือนโดยทำงานเต็มเวลา และยินดีที่จะจำกัดช่วงข้างต้นให้แคบลงอีกหากปริมาณงานที่ประเมินมีขนาดใหญ่กว่า
หมายเหตุเกี่ยวกับรหัสไบต์เดิม:
● แม้ว่าจะสามารถระงับรหัสไบต์เดิม/ไม่ใช่ EOF ใหม่ได้ แต่รหัสไบต์เดิมที่มีอยู่ไม่สามารถเลิกใช้ได้ เนื่องจากจะทำหน้าที่เป็น EOF v 0 ได้อย่างมีประสิทธิภาพ ไบต์โค้ดแบบเดิมยังคงต้องมีการวิเคราะห์หลัง EOF JUMPDEST และยังคงต้องมีการจัดการโค้ดแบบพิเศษเพื่อแบ่งส่วนออกเป็นชิ้นๆ ใน Verkle Tries
● ตามความรู้ที่ดีที่สุดของ Paradigm เป็นไปไม่ได้ที่จะตรวจสอบการแปลงจากรหัสไบต์ที่ไม่ใช่ EOF เป็น EOF โดยไม่ต้องเข้าถึงซอร์สโค้ด แต่ Paradigm ยินดีที่จะตรวจสอบกลไกเพื่ออำนวยความสะดวกในการแปลงนี้
● อีกทางหนึ่ง Paradigm ยินดีที่จะสำรวจวิธีการหมดอายุที่บังคับให้ย้ายสถานะไปยัง EOF
เพิ่มจำนวนหยด EIP-4844
กระบวนทัศน์เปิดรับการเปลี่ยนแปลงนี้ และจะเพิ่ม MAX_BLOB_GAS_PER_BLOCK และ TARGET_BLOB_GAS_PER_BLOCK ตามลำดับ
เลือกค่าสำหรับ TARGET_BLOB_GAS_PER_BLOCK และ MAX_BLOB_GAS_PER_BLOCK เพื่อให้สอดคล้องกับเป้าหมาย 3 blobs (0.375 MB) ต่อบล็อก (สูงสุด 6 blobs ประมาณ 0.75 MB) ขีดจำกัดเริ่มต้นเหล่านี้มีขนาดไม่ใหญ่นัก แต่จะช่วยลดความเครียดที่ EIP นี้สร้างไว้บนเครือข่ายให้เหลือน้อยที่สุด และสามารถเพิ่มขึ้นได้ในการอัปเกรดครั้งต่อๆ ไป เนื่องจากเครือข่ายแสดงให้เห็นถึงความน่าเชื่อถือด้วยบล็อกที่ใหญ่กว่า
ในทางปฏิบัติ การเปลี่ยนแปลงโค้ดที่เกี่ยวข้องจะไม่ใหญ่เกินไป แต่ Paradigm จำเป็นต้องตรวจสอบผลกระทบที่แท้จริงของสิ่งเหล่านี้ใน txpool ที่สูงกว่า ดังนั้นโครงสร้างพื้นฐานการทดสอบความเครียด EIP-4844 จึงสามารถนำมาใช้ซ้ำได้ ชั้นฉันทามติอาจมีปัญหาในการเผยแพร่ Blob มากขึ้น ดังนั้น Paradigm จึงเคารพความคิดเห็นของทีมชั้นฉันทามติด้วย
กระบวนทัศน์ไม่สอดคล้องกับทิศทาง
Verkle Tries
พูดง่ายๆ ก็คือ การปรับใช้งาน Verkle ให้เสร็จสิ้นภายในสิ้นปี 2567/ต้นปี 2568 ดูเหมือนจะไม่น่าเป็นไปได้ โดย Paradigm แนะนำให้ทีมจัดสรรทรัพยากรสำหรับสิ่งนี้ในไตรมาสที่ 2 ปี 2567 และมุ่งมั่นที่จะทำฮาร์ดฟอร์คของ Osaka ในไตรมาสที่ 2-ไตรมาสที่ 3 ปี 2568
ด้านดี:
● ไคลเอนท์แบบเบาราคาประหยัดด้วยพื้นที่จัดเก็บที่มีขนาดเล็กลง
● การดำเนินการแบบไร้สถานะโดยรวมการอ่านสถานะล่วงหน้าไว้ในส่วนหัวของบล็อก ซึ่งอาจนำไปสู่การปรับปรุงประสิทธิภาพเนื่องจากการเข้าถึงสถานะคงที่
● เพิ่มขีดจำกัดขนาดสัญญาด้วยการแบ่งไบต์โค้ดและเปิดใช้งานการโหลดโค้ดบางส่วน
● การหมดอายุของสถานะจะยอมรับได้มากขึ้นเนื่องจากมีต้นทุนที่ต่ำกว่าในการ กู้คืน สถานะ
ด้านที่ไม่ดี:
● ผลกระทบของการเปลี่ยนแปลงและความพยายามในการบูรณาการที่นำไปใช้และทดสอบ
● การเปลี่ยนแปลงการบัญชีก๊าซ: Verkle Tries แนะนำการกำหนดขนาดพยานในฟังก์ชันการบัญชีก๊าซ และ Paradigm กังวลว่าการเปลี่ยนแปลงราคาพื้นที่จัดเก็บยังไม่ได้รับการสำรวจ (เช่น ราคาผู้บริโภคก๊าซหลักหลังจาก Verkle มีราคาเท่าใด)
● การรวมแอปพลิเคชัน: แอปพลิเคชันที่มีเครื่องมือตรวจสอบความถูกต้องของ Merkle Patricia Trie ควรทำอย่างไรเมื่อดำเนินการการแปลงแบบซ้อนทับ eth_getProof ควรทำงานอย่างไร
แม้ว่า Verkle Tries จะมีข้อได้เปรียบบางประการ Paradigm เชื่อว่าจำเป็นต้องพิจารณาเพิ่มเติมเกี่ยวกับวิธีการปรับตัวของเครื่องมือ/สัญญาของบุคคลที่สาม และสิ่งที่ส่งผลกระทบต่อการเปลี่ยนแปลงจะมีต่อโซลูชันระดับที่สองและอื่นๆ ที่คล้ายคลึงกัน กระบวนทัศน์เริ่มแรกถือเป็นการโกงนโยบายการย้ายข้อมูล เนื่องจากมีการกำหนดว่า Verkle Tries ควรได้รับการอัปเดตเมื่อมีการอ่านสถานะจาก MPT ที่มีอยู่แล้ว แต่ดูเหมือนว่าจะไม่เป็นเช่นนั้นอีกต่อไป ดังนั้น Paradigm จึงสนับสนุนวิธีการซ้อนทับเป็นเส้นทางการย้ายข้อมูลที่ทำงานได้
เอกสารเกี่ยวกับกลยุทธ์การย้าย Verkle มักจะล้าสมัย เนื่องจากแหล่งข้อมูลส่วนใหญ่ยังคงระบุว่าควรอัปเดต Verkle trie เมื่ออ่านสถานะจาก MPT แม้ว่าจะไม่เป็นเช่นนั้นก็ตาม Paradigm ต้องการดูเอกสารการเปลี่ยนแปลงที่สำคัญที่อัปเดตด้วยวิธีล่าสุด โปรดดูที่เอกสารนี้. กระบวนทัศน์ยังต้องการเห็นร่างแผนการลงทุนเชิงนิเวศเกี่ยวกับกลยุทธ์การเปลี่ยนแปลง
ดังนั้น Paradigm ยังคงสนับสนุนการเปิดตัวในปี 2568 และไม่ได้ปรับใช้ในฮาร์ดฟอร์คนี้
ขีดจำกัดก๊าซ L1
Paradigm เชื่อว่าอาจมี ความเข้าใจผิด ในด้านอุปสงค์ และในความเป็นจริง การเพิ่มขีดจำกัด L1 Gas จะไม่ส่งผลกระทบมากนักในทางปฏิบัติ Paradigm ยังเชื่ออีกว่าไคลเอ็นต์ส่วนใหญ่สามารถรองรับการเพิ่มขึ้นของภาระโดยเฉลี่ยได้ แต่ Paradigm ต้องการระวังสถานการณ์ที่เลวร้ายที่สุด ดังนั้นจึงไม่แนะนำให้เพิ่มขีดจำกัด L1 Gas ในปัจจุบัน กระบวนทัศน์เชื่อว่าการเพิ่มขีดจำกัดก๊าซหยดเป็นวิธีแก้ปัญหาที่มีความหวังมากกว่าในระยะสั้น
Paradigm ต้องการเชิญชวนชุมชนให้ทำงานร่วมกันในการวิจัยในทิศทางที่เกี่ยวข้อง ซึ่งมักจะเกี่ยวกับการทำลายการวัดทรัพยากรใน EVM โพสต์โดย Broken Meterกระดาษน่าจะเป็นจุดเริ่มต้นที่ดีสำหรับการวิจัยสาขานี้
นามธรรมบัญชี
Paradigm ยินดีที่จะรวม EIP 1 รายการขึ้นไป (หรือรวม ERC) ไว้ในฮาร์ดฟอร์ค แต่ตามหลักการแล้วต้องการเห็นประสบการณ์ผู้ใช้และการเปรียบเทียบประสบการณ์ของนักพัฒนาเพิ่มเติมระหว่างแต่ละข้อเสนอ ซึ่งจะดีกว่า เข้าใจพื้นที่การแลกเปลี่ยนและความพยายามของเครื่องมือ บูรณาการ Paradigm มุ่งเน้นไปที่ EIP/ERC ต่อไปนี้ และชุมชนสามารถให้คำแนะนำเกี่ยวกับ Paradigm ได้ตลอดเวลา:
● EIP-3074: รหัส AUTH และ AUTHCALL
● ERC-4337: การแยกบัญชีโดยใช้ Alt Mempool
● EIP-5806: ธุรกรรมที่ได้รับมอบหมาย
● RIP-7560: Native Account Abstraction - Core EIP - Fellowship of Ethereum Magicians
การแจ้งเตือนครั้งสุดท้ายคือ การลบบัญชี ใช้กับ EIP-4337 และ EIP-7560 ที่กล่าวถึงข้างต้นเท่านั้น ในขณะที่ข้อเสนออื่นๆ ส่วนใหญ่จะครอบคลุมสองด้าน: การสนับสนุนก๊าซและการดำเนินงานแบบแบตช์ (นามธรรมบัญชี ก็เหมือนกับการทำให้ฟังก์ชันการตรวจสอบเป็นนามธรรม เป้าหมายหลักคือการเปิดใช้งานการหมุนเวียนคีย์ ทำให้ลายเซ็นหลายลายเซ็นเป็นองค์ประกอบสำคัญ และมอบเส้นทางอัตโนมัติไปสู่การต่อต้านควอนตัม)
