ERC 4337: การถอนบัญชีโดยไม่ต้องเปลี่ยนโปรโตคอล Ethereum

DAOrayaki

特邀专栏作者

2021-12-23 12:42

บทความนี้มีประมาณ 3840 คำ การอ่านทั้งหมดใช้เวลาประมาณ 6 นาที

การทำบัญชีเป็นความฝันของชุมชนนักพัฒนา Ethereum มานานแล้ว

สรุปโดย AI

ขยาย

การทำบัญชีเป็นความฝันของชุมชนนักพัฒนา Ethereum มานานแล้ว

กลุ่มโบนัสการวิจัย DAOrayaki DAO:

ความคืบหน้าการลงคะแนน คณะกรรมการ อพท. 3/7 ผ่านไป

ที่อยู่ของทุน: DAOrayaki.eth

ความคืบหน้าการลงคะแนน คณะกรรมการ อพท. 3/7 ผ่านไป

ค่าหัวทั้งหมด: 80USDC

ประเภทของการวิจัย: DAO, ERC4337, นามธรรมของบัญชี, กระเป๋าเงินอัจฉริยะ

ผู้เขียนต้นฉบับ: Vitalik Buterin

ผู้ร่วมให้ข้อมูล: Dewei, DAOCtor @DAOrayaki

ข้อความต้นฉบับ: ERC 4337: การแยกบัญชีโดยไม่มีการเปลี่ยนแปลงโปรโตคอล Ethereum

การทำบัญชีเป็นความฝันของชุมชนนักพัฒนา Ethereum มานานแล้ว โค้ด EVM ไม่ได้ใช้เพียงเพื่อปรับใช้ตรรกะของแอปพลิเคชันเท่านั้น แต่ยังใช้การตรวจสอบเชิงตรรกะของกระเป๋าเงินของผู้ใช้แต่ละรายด้วย (nonces, ลายเซ็น...) สิ่งนี้จะให้แนวคิดมากมายสำหรับนวัตกรรมการออกแบบกระเป๋าเงิน และกระเป๋าเงินสามารถให้ฟังก์ชันที่สำคัญบางอย่าง เช่น:

1. Multisig และการกู้คืนทางสังคม

2. อัลกอริทึมลายเซ็นที่มีประสิทธิภาพและง่ายกว่า (เช่น Schnorr, BLS)

3. อัลกอริธึมลายเซ็นที่ปลอดภัยหลังควอนตัม (เช่น Lamport, Winternitz)

ทุกวันนี้ สิ่งเหล่านี้สามารถทำได้ด้วยกระเป๋าเงินสัญญาอัจฉริยะ แต่โปรโตคอล Ethereum นั้นต้องการให้ทุกอย่างรวมอยู่ในธุรกรรมที่มาจากบัญชีภายนอกที่ปลอดภัยของ ECDSA (EOA) ซึ่งเป็นเรื่องยากสำหรับกระเป๋าเงินสัญญาอัจฉริยะที่จะบรรลุ การดำเนินการของผู้ใช้ทุกคนจำเป็นต้องปิดล้อมด้วยธุรกรรมจาก EOA โดยเพิ่มค่าใช้จ่าย 21,000 แก๊ส ผู้ใช้จำเป็นต้องเป็นเจ้าของ ETH ใน EOA แยกต่างหากเพื่อชำระค่าน้ำมันและจัดการยอดคงเหลือในทั้งสองบัญชี หรือพึ่งพาระบบรีเลย์ซึ่งมักจะรวมศูนย์

EIP 2938 เป็นวิธีการแก้ปัญหานี้โดยการเปลี่ยนโปรโตคอล Ethereum บางส่วนเพื่อให้การทำธุรกรรม Ethereum ระดับบนสุดเริ่มต้นด้วยสัญญาแทน EOA ตัวสัญญาจะมีตรรกะในการยืนยันและการชำระค่าธรรมเนียม ซึ่งนักขุดจะตรวจสอบ อย่างไรก็ตาม เมื่อผู้พัฒนาโปรโตคอลให้ความสำคัญกับการผสานรวมและความสามารถในการปรับขนาด พวกเขาจำเป็นต้องทำการเปลี่ยนแปลงที่สำคัญกับโปรโตคอล ในข้อเสนอใหม่ของเรา (ERC 4337) เรามีวิธีที่จะบรรลุผลประโยชน์เดียวกันโดยไม่ต้องเปลี่ยนโปรโตคอลชั้นฉันทามติ

ชื่อเรื่องรอง

คำแนะนำนี้ทำงานอย่างไร

สิ่งที่เราแก้ไขไม่ใช่ตรรกะของเลเยอร์ฉันทามติ แต่เป็นฟังก์ชันของการจำลอง mempool ของธุรกรรมในระบบระดับที่สูงกว่า ผู้ใช้ส่งวัตถุ UserOperation บรรจุความตั้งใจของผู้ใช้ด้วยลายเซ็นและข้อมูลอื่น ๆ เพื่อการตรวจสอบ ทั้งนักขุดและบันเดิลที่ใช้บริการต่างๆ เช่น Flashbots สามารถรวมชุดของออบเจกต์ UserOperation ไว้ใน "ธุรกรรมรวม" ซึ่งจะรวมอยู่ในบล็อก Ethereum

Bundlers จะได้รับการชำระเงินสำหรับการทำธุรกรรมแบบรวมเป็น ETH และได้รับการชดเชยผ่านค่าธรรมเนียมที่จ่ายซึ่งเป็นส่วนหนึ่งของการดำเนินการของผู้ใช้แต่ละคนที่ดำเนินการ Bundlers จะเลือกออบเจกต์ UserOperation ที่จะรวมตามตรรกะการจัดลำดับความสำคัญของค่าธรรมเนียม คล้ายกับวิธีการทำงานของ miners ใน mempool ธุรกรรมที่มีอยู่ UserOperation ดูเหมือนธุรกรรม เป็นโครงสร้างที่เข้ารหัส ABI ซึ่งมีฟิลด์ต่อไปนี้:

1. ผู้ส่ง: กระเป๋าเงินสำหรับการดำเนินการ

2. nonce และลายเซ็น: พารามิเตอร์ที่ส่งผ่านไปยังฟังก์ชันการตรวจสอบกระเป๋าเงินเพื่อให้กระเป๋าเงินสามารถตรวจสอบการดำเนินการได้

4. callData: ข้อมูลที่ใช้ในการเรียกกระเป๋าเงินในขั้นตอนการดำเนินการจริง

ฟิลด์ที่เหลือเกี่ยวข้องกับการจัดการก๊าซและค่าธรรมเนียม รายการฟิลด์ทั้งหมดสามารถพบได้ในข้อมูลจำเพาะ ERC 4337

ชื่อเรื่องรอง

กระเป๋าเงินเป็นสัญญาอัจฉริยะที่ต้องมีสองหน้าที่:

2. op เรียกใช้ฟังก์ชันและตีความ calldata เป็นคำสั่งให้ wallet ดำเนินการ วิธีที่ฟังก์ชันนี้ตีความ calldata และผลลัพธ์ของมันเปิดอย่างสมบูรณ์ แต่เราคาดว่าลักษณะการทำงานที่พบบ่อยที่สุดคือการแยกวิเคราะห์ calldata เป็นคำแนะนำสำหรับกระเป๋าเงินเพื่อทำการโทรอย่างน้อยหนึ่งสาย

เพื่อลดความซับซ้อนของตรรกะของกระเป๋าเงิน เทคนิคสัญญาอัจฉริยะที่ซับซ้อนส่วนใหญ่ที่จำเป็นเพื่อให้แน่ใจว่าการรักษาความปลอดภัยไม่ได้ทำในกระเป๋าเงินเอง แต่อยู่ในสัญญาส่วนกลางที่เรียกว่าจุดเข้าใช้งาน ฟังก์ชัน validateUserOp และการดำเนินการนั้นคาดว่าจะมี gated ด้วย required(msg.sender == ENTRY_POINT) ดังนั้นเฉพาะจุดเข้าใช้งานที่เชื่อถือได้เท่านั้นที่สามารถทำให้กระเป๋าเงินดำเนินการใดๆ หรือจ่ายค่าธรรมเนียมได้ จุดเริ่มต้นทำการเรียกโดยพลการไปยังกระเป๋าเงินหลังจากตรวจสอบ UserOp แล้ว และ UserOperation ที่ส่งข้อมูลของการโทรนั้นสำเร็จ ดังนั้นนี่จึงเพียงพอที่จะปกป้องกระเป๋าเงินจากการถูกโจมตี จุดเริ่มต้นยังรับผิดชอบในการสร้างกระเป๋าเงินโดยใช้ initCode ที่ให้มา หากไม่มีกระเป๋าเงินอยู่

ชื่อเรื่องรอง

โฟลว์การควบคุมจุดเข้าใช้งานรันไทม์

ถ้าการตรวจสอบความถูกต้องของ UserOperation ถูกจำลองสำเร็จ UserOperation จะรับประกันได้จนกว่าจะมีการเปลี่ยนแปลงสถานะภายในอื่นๆ ในบัญชีผู้ส่ง (อาจเป็นเพราะ UserOperation อื่นมีผู้ส่งคนเดียวกันหรือสัญญาอื่นที่เรียกใช้ผู้ส่ง ในกรณีใดกรณีหนึ่ง การเรียกใช้เงื่อนไขนี้สำหรับบัญชีต้องใช้ 7500 + น้ำมันในห่วงโซ่)

นอกจากนี้ การกระทำของผู้ใช้ยังระบุขีดจำกัดแก๊สสำหรับขั้นตอนตรวจสอบผู้ใช้ โหนด mempool และบันเดิลเลอร์จะปฏิเสธ เว้นแต่ขีดจำกัดแก๊สนี้จะน้อยมาก (เช่น ต่ำกว่า 200000) ข้อจำกัดเหล่านี้ทำซ้ำคุณสมบัติหลักของธุรกรรม Ethereum ที่มีอยู่ ทำให้ mempool มีภูมิคุ้มกันต่อการโจมตี DoS Bundler และโหนด mempool สามารถใช้ตรรกะคล้ายกับธุรกรรม Ethereum ในปัจจุบันเพื่อกำหนดว่าจะรวมหรือส่งต่อ UserOperation

ชื่อเรื่องรอง

คุณสมบัติใดที่การออกแบบนี้เพิ่ม รักษา และเสียสละเมื่อเทียบกับ mempool ธุรกรรม Ethereum ปกติ

รักษาคุณสมบัติ:

1. ไม่มีผู้เข้าร่วมจากส่วนกลาง ทุกอย่างทำผ่าน mempool แบบเพียร์ทูเพียร์

2. DoS ปลอดภัย (การกระทำของผู้ใช้ที่ผ่านการตรวจสอบการแอบอ้างเป็นการรับประกันว่าจะมีอยู่จนกว่าผู้ส่งจะมีการเปลี่ยนแปลงสถานะอื่น ซึ่งจะทำให้ผู้โจมตีต้องจ่าย 7500+ ก๊าซต่อผู้ส่ง)

3. ไม่มีความซับซ้อนในการตั้งค่ากระเป๋าเงินฝั่งไคลเอ็นต์: ผู้ใช้ไม่จำเป็นต้องสนใจว่าสัญญากระเป๋าเงินของพวกเขาได้รับการ "เผยแพร่" หรือไม่ กระเป๋าเงินมีอยู่ที่ที่อยู่ CREATE2 ที่กำหนด และถ้ากระเป๋าเงินยังไม่มีอยู่ UserOperation แรกจะ สร้างโดยอัตโนมัติ

4. รองรับ EIP 1559 เต็มรูปแบบ รวมถึงการตั้งค่าค่าธรรมเนียม (ผู้ใช้สามารถตั้งค่าพรีเมียมค่าธรรมเนียมคงที่และค่าธรรมเนียมรวมสูงสุด และคาดว่าจะมีการรวมที่รวดเร็วและค่าธรรมเนียมที่ยุติธรรม)

5. ความสามารถในการส่งการกระทำของผู้ใช้ใหม่ในราคาพรีเมี่ยมที่สูงกว่าการกระทำเก่าเพื่อแทนที่การกระทำหรือรวมการกระทำเหล่านั้นเร็วขึ้นด้วยการแทนที่แบบชำระเงิน

สิทธิประโยชน์ใหม่:

1. ความยืดหยุ่นของลอจิกการตรวจสอบความถูกต้อง: ฟังก์ชัน validateUserOp สามารถเพิ่มตรรกะการตรวจสอบลายเซ็นและแบบไม่มีตัวตนได้ตามอำเภอใจ (รูปแบบลายเซ็นใหม่, หลายลายเซ็น...)

3. ความสามารถในการอัปเกรด Wallet: ตรรกะการยืนยัน Wallet สามารถเก็บสถานะได้ ดังนั้น Wallet จึงสามารถเปลี่ยนรหัสสาธารณะหรือ (หากออกโดยใช้ DELEGATECALL) ให้อัปเกรดรหัสอย่างสมบูรณ์

ข้อบกพร่อง

4. ความยืดหยุ่นของตรรกะการดำเนินการ: กระเป๋าสตางค์สามารถเพิ่มตรรกะที่กำหนดเองสำหรับขั้นตอนการดำเนินการ เช่น ทำ Atomic Multi-ops (เป้าหมายหลักของ EIP 3074)

ข้อบกพร่อง

1. แม้จะมีความพยายามอย่างดีที่สุดของโปรโตคอล แต่ก็ยังมีช่องโหว่ DoS เพิ่มขึ้นเล็กน้อยเพียงเพราะตรรกะการตรวจสอบที่อนุญาตนั้นซับซ้อนกว่าสถานะเดิมด้วยการตรวจสอบ ECDSA เพียงครั้งเดียว

2. ค่าใช้จ่ายก๊าซ: ค่าใช้จ่ายก๊าซมากกว่าการทำธุรกรรมปกติเล็กน้อย (แม้ว่าในบางกรณีการใช้งานนี้จะถูกหักล้างด้วยการสนับสนุนการทำงานหลายอย่าง)

3. ธุรกรรมครั้งละหนึ่งรายการ: บัญชีไม่สามารถจัดคิวและส่งธุรกรรมหลายรายการไปยัง mempool อย่างไรก็ตาม ความสามารถในการดำเนินการหลายอย่างในระดับปรมาณูทำให้การทำงานนี้มีความจำเป็นน้อยลงมาก

ผู้สนับสนุนกับผู้ชำระเงิน:

มีหลายกรณีการใช้งานที่สำคัญสำหรับการทำธุรกรรมของผู้สนับสนุน กรณีการใช้งานที่ต้องการอ้างถึงบ่อยที่สุดคือ:

2. อนุญาตให้ผู้ใช้ชำระค่าธรรมเนียมด้วยโทเค็น ERC20 และสัญญาทำหน้าที่เป็นตัวกลางในการเรียกเก็บเงิน ERC20 และชำระด้วย ETH

ข้อเสนอสามารถสนับสนุนการทำงานนี้ผ่านกลไกผู้ดูแลระบบการชำระเงินในตัว UserOperation สามารถตั้งค่าที่อยู่อื่นเป็นผู้ชำระเงิน หากมีการตั้งค่าผู้ดูแลระบบการชำระเงิน (เช่น ไม่เป็นศูนย์) ในระหว่างขั้นตอนการยืนยัน จุดเข้าใช้งานยังเรียกผู้ดูแลระบบการชำระเงินเพื่อตรวจสอบว่าผู้ดูแลระบบการชำระเงินยินดีชำระเงินสำหรับ UserOperation หากเป็นเช่นนั้น ค่าธรรมเนียมจะถูกหักออกจาก ETH ของผู้อำนวยการฝ่ายการชำระเงินที่เดิมพันภายในจุดเริ่มต้น (การถอนเงินล่าช้าเพื่อความปลอดภัย) แทนที่จะเป็นกระเป๋าเงิน ในขั้นตอนการดำเนินการ กระเป๋าเงินจะเรียกตามปกติด้วย calldata ใน UserOperation แต่จากนั้นจะเรียก paymaster ด้วย postOp

ชื่อเรื่องรอง

เวิร์กโฟลว์ตัวอย่างสำหรับกรณีการใช้งานสองกรณีข้างต้นคือ:

2. ผู้ดูแลระบบการชำระเงินตรวจสอบว่ากระเป๋าเงินของผู้ส่งมียอดคงเหลือ ERC20 เพียงพอที่จะชำระ UserOperation หรือไม่ ถ้าเป็นเช่นนั้น paymaster ยอมรับและชำระค่าธรรมเนียม ETH จากนั้นเรียกร้องโทเค็น ERC20 ใน postOp เป็นการชดเชย (หาก postOp ล้มเหลวเนื่องจาก UserOperation ระบายยอดคงเหลือ ERC20 การดำเนินการจะกลับมาทำงานต่อและ postOp จะถูกเรียกอีกครั้ง ดังนั้น paymaster ได้รับเงินเสมอ) โปรดทราบว่าในปัจจุบัน สามารถทำได้ก็ต่อเมื่อ ERC20 เป็นโทเค็นแบบรวมที่จัดการโดยผู้ดูแลระบบการชำระเงินเอง