Vitalik: เส้นทางสู่บัญชีที่เป็นนามธรรมใน Ethereum

รวบรวมข้อความต้นฉบับ: The Way of DeFi

รวบรวมข้อความต้นฉบับ: The Way of DeFi

การสรุปบัญชีช่วยให้เราสามารถใช้ตรรกะของสัญญาอัจฉริยะเพื่อระบุผลกระทบของธุรกรรม เช่นเดียวกับการชำระค่าธรรมเนียมและตรรกะการตรวจสอบความถูกต้อง สิ่งนี้นำมาซึ่งประโยชน์ด้านความปลอดภัยที่สำคัญหลายประการ เช่น multi-signature และ smart recovery wallet ความสามารถในการเปลี่ยนคีย์โดยไม่ต้องเปลี่ยน wallet และการรักษาความปลอดภัยแบบควอนตัม

มีการเสนอแนวทางมากมายในการสรุปบัญชีและนำไปปฏิบัติในระดับที่แตกต่างกัน ดู: EIP-86, EIP-2938 และบทความนี้เมื่อสองปีที่แล้ว ปัจจุบัน การพัฒนา EIP เหล่านี้หยุดชะงักเนื่องจากนักพัฒนาต้องการมุ่งเน้นที่การรวมและแยกย่อย ในขณะที่ ERC-4337 ซึ่งเป็นทางเลือกที่ไม่ต้องการการเปลี่ยนแปลงที่เป็นเอกฉันท์ มีความก้าวหน้าอย่างมาก

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

ERC-4337 สามารถทำอะไรได้หลายอย่างโดยเป็น ERC ที่สมัครใจล้วนๆ อย่างไรก็ตาม มันอ่อนแอกว่าโซลูชันในโปรโตคอลจริงในประเด็นสำคัญบางประการ:

1. ผู้ใช้ปัจจุบันไม่สามารถอัปเกรดได้หากไม่ย้ายเนื้อหาและกิจกรรมทั้งหมดไปยังบัญชีใหม่

2. ค่าใช้จ่ายเพิ่มเติมของก๊าซ(การดำเนินการของผู้ใช้ UserOperation พื้นฐานประมาณ 42k ในขณะที่ธุรกรรมพื้นฐานประมาณ 21k)

3. ได้รับประโยชน์น้อยลงจากเทคนิคการต่อต้านการเซ็นเซอร์ในโปรโตคอล (เช่น crLists) ซึ่งกำหนดเป้าหมายธุรกรรมและพลาดการดำเนินการของผู้ใช้

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

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

แปลง EOA Wallet เป็น Smart Contract Wallet

ในการอัปเกรดกระเป๋าเงิน EOA ที่มีอยู่เป็นกระเป๋าเงิน ERC-4337 เราสามารถสร้าง EIP ที่อนุญาตให้ EOA ดำเนินการตามที่กำหนดรหัสสัญญาได้ เมื่อ EOA บรรลุเป้าหมายนี้แล้ว การเปลี่ยนแปลงจะย้อนกลับไม่ได้ ตั้งแต่นั้นมา บัญชีจะถูกใช้เป็นกระเป๋าเงินสัญญาอัจฉริยะเท่านั้น โชคดีที่เนื่องจากบัญชี ERC-4337 เป็นพร็อกซี DELEGATECALL กระเป๋าเงินจึงสามารถแปลงเป็นสัญญาอัจฉริยะอื่นๆ ที่เข้ากันได้กับ ERC ได้ในภายหลังหากต้องการ

มีข้อเสนอบางประการเกี่ยวกับวิธีการใช้กระบวนการอัปเกรดนี้:

1. ประเภทธุรกรรม "เปลี่ยนรหัส"

สิ่งนี้ยังไม่ได้รับการแนะนำเป็น EIP อย่างเป็นทางการ แต่วิธีการนั้นง่าย: เพิ่มประเภทธุรกรรม EIP-2718 ใหม่ เพียงแทนที่ account_code ด้วย calldata

2、AUTH_USURP (EIP-5003)

EIP-5003 เป็นข้อเสนอส่วนขยายของ EIP-3074 (AUTH และ AUTHCALL) ซึ่งแนะนำ opcode AUTHUSURP ใหม่ AUTHUSURP อนุญาตให้ B ตั้งรหัสของ A หากใช้กลไก EIP-3074 ที่อยู่ EOA A ได้อนุญาตให้ที่อยู่อื่น B ​​ดำเนินการแทน

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

การแปลงบังคับ

ในระยะยาว เราอาจต้องการแปลงภาคบังคับเพื่อลดความซับซ้อนของโปรโตคอลและทำสัญญาเป็นบัญชีประเภทเดียว โดยลบ ECDSA ออกจากโปรโตคอลแนวทางหนึ่งที่เป็นไปได้คือการเพิ่มกฎการแทนที่โดยเริ่มจากบล็อกหนึ่งๆ บัญชีที่ไม่มีรหัสจะถือว่าเป็นบัญชีที่มีรหัส "กระเป๋าเงิน ERC-4337 EOA" ที่เป็นมาตรฐานเฉพาะ

คำถาม

คำถาม

1. การตรวจสอบ ECRECOVER ในสัญญา:สัญญาอัจฉริยะบางรายการใช้ข้อสันนิษฐานว่าหากคุณให้ลายเซ็นของ ECRECOVER กับบัญชีใดบัญชีหนึ่ง แสดงว่าคุณเป็นเจ้าของบัญชีนั้น หาก EOA ถูกแปลงเป็นสัญญา แล้วคีย์การยืนยันถูกเปลี่ยน รหัสเดิมจะยังคงสามารถ "เป็นตัวแทน" บัญชีในบริบทเฉพาะเหล่านี้ได้ ซึ่งสามารถทำได้โดยเริ่มสนับสนุนให้โครงการดังกล่าวทั้งหมดเปลี่ยนไปใช้การตรวจสอบ EIP-1271 แทน ECRECOVER หากบัญชีมีรหัส

2. ยังไม่ตรวจพบบัญชี:ความท้าทายอย่างหนึ่งของการบังคับแปลงคือบัญชีที่เป็นเจ้าของสินทรัพย์ (เช่น ERC20s, ERC721s แต่ไม่ใช่ ETH) แต่ยังไม่ได้ส่งหรือรับธุรกรรมใดๆ ดังนั้นโปรโตคอลจึงไม่สามารถตรวจจับบัญชีเหล่านี้ได้อย่างน่าเชื่อถือ โปรโตคอลจะต้องรักษาความสามารถในการแปลงบัญชีดังกล่าวเป็นกระเป๋าเงินเริ่มต้นอย่างถาวร หรือต้องมีกำหนดเวลา (เช่น 4 ปีหลังจากการปรับใช้) หลังจากนั้นบัญชีที่ยังไม่ได้แปลงจะถูกเผา

3. EOA ตรวจสอบเฉพาะการไม่สามารถถ่ายโอนได้:ชื่อเรื่องรอง

ลดค่าแก๊ส

กระเป๋าเงิน ERC-4337 ต้องเผชิญกับต้นทุนก๊าซที่สูงขึ้น (ประมาณ 42,000 ก๊าซสำหรับการดำเนินการพื้นฐานของ ERC-4337 เทียบกับ 21,000 ก๊าซสำหรับการทำธุรกรรมปกติขั้นพื้นฐาน) ด้วยเหตุผลดังต่อไปนี้:

1. คุณต้องจ่ายค่าใช้จ่ายในการอ่าน/เขียนพื้นที่เก็บข้อมูลจำนวนมาก ในกรณีของ EOA ค่าใช้จ่ายเหล่านี้จะรวมอยู่ในการจ่ายก๊าซ 21,000 เพียงครั้งเดียว:

(1) แก้ไขช่องเก็บข้อมูลที่มี pubkey+nonce (~5000);

(2) ต้นทุนข้อมูลการโทรของการดำเนินการของผู้ใช้ (ประมาณ 4,500 ซึ่งสามารถลดเหลือประมาณ 2,500 ผ่านการบีบอัด)

（3）ECRECOVER (~3000)；

(4) การเข้าถึงกระเป๋าเงินครั้งแรก (~2600)

(5) การเข้าถึงบัญชีผู้รับเงินเป็นครั้งแรก (~2600)

(6) โอน ETH ไปยังบัญชีผู้รับผลประโยชน์ (~9000)

(7) แก้ไขพื้นที่จัดเก็บเพื่อชำระค่าธรรมเนียม (~5,000)

(8) เข้าถึงช่องเก็บข้อมูลที่มีเอเจนต์ (~2100) จากนั้นเข้าถึงเอเจนต์เอง (~2600)

2. นอกเหนือจากค่าใช้จ่ายในการอ่าน/เขียนพื้นที่เก็บข้อมูลข้างต้นแล้ว สัญญายังต้องดำเนินการ "ตรรกะทางธุรกิจ" (แกะ UserOperation, แฮชมัน, ตัวแปรสุ่ม ฯลฯ)

3. ต้องใช้น้ำมันเพื่อชำระค่าธรรมเนียมบันทึก (EOA ไม่เผยแพร่บันทึก);

4. ต้นทุนการสร้างสัญญาแบบครั้งเดียว (ประมาณ 32,000 แก๊ส บวก 200 แก๊สสำหรับแต่ละรหัสไบต์ในพร็อกซี บวก 20,000 แก๊สสำหรับการตั้งค่าที่อยู่พร็อกซี)

ปัญหาเหล่านี้จำนวนมากจะได้รับการแก้ไขโดยอัตโนมัติใน EIP ของ Verkle tree เป็นพยานต้นทุนก๊าซ และเขียน EIP ปฏิรูปต้นทุนก๊าซ แทนที่ต้นทุนการจัดเก็บขนาดใหญ่ด้วยระบบที่บางลง ตัวอย่างเช่น สามารถจัดเก็บคีย์ Pubkey และ Nonces ในช่อง 0…63 ซึ่งช่วยลดต้นทุนในการเข้าถึงให้ต่ำกว่า 1,000 ผู้ใช้จะจ่ายน้อยลงเมื่อโอน ETH และชำระค่าธรรมเนียม เนื่องจากต้องเข้าถึงบัญชีเป้าหมายและบัญชีรับเพียงครั้งเดียวในครั้งแรก

มี EIP มากมายที่ช่วยให้เราง่ายขึ้น ตัวอย่างเช่น:

1. การปิดใช้งานลอจิกสัญญาอัจฉริยะจากการใช้ ERC โดยสมัครใจของช่อง 0 จะทำให้สามารถใช้เป็นพร็อกซีพื้นที่เก็บข้อมูลได้ ทำให้ได้รับประโยชน์จากต้นทุนก๊าซที่ถูกกว่า

2. ช่อง "ที่อยู่รหัส" สามารถทำให้การใช้พร็อกซีง่ายขึ้นและกินน้ำมันน้อยลง

3. การคอมไพล์ล่วงหน้า "การบีบอัดอย่างรวดเร็ว" ช่วยให้ใช้ออบเจกต์ ABI ได้ง่ายขึ้นโดยไม่ต้องจ่ายค่าก๊าซ calldata สำหรับศูนย์ไบต์ทั้งหมด

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

crLists

นี่เป็นปัญหาระยะยาว เนื่องจาก crLists จะใช้งานได้จริงๆ ต่อเมื่อเปิดใช้แผนการแยกผู้เสนอ/ผู้สร้างโปรโตคอลแบบเต็ม ความท้าทายคือเราต้องการให้ผู้เสนอสามารถระบุการกระทำของผู้ใช้ที่ "คู่ควร" ในการรวม (เช่น พวกเขาจ่ายค่าธรรมเนียมเพียงพอ) เพื่อให้โปรโตคอลสามารถบังคับให้รวมอยู่ในบล็อกถัดไปที่มีที่ว่าง

สิ่งนี้ต้องการให้แนวคิดของ "การตรวจสอบความถูกต้อง" และ "การดำเนินการ" ชัดเจนในโปรโตคอล สำหรับการดำเนินการของผู้ใช้ ต้องมีวิธีที่กำหนดไว้ในการตรวจสอบความถูกต้องของการดำเนินการ และวิธีการที่กำหนดไว้ในการดำเนินการ เช่น หากการดำเนินการได้รับการตรวจสอบแล้ว ความพยายามในการดำเนินการจะได้รับการรับประกันว่าจะต้องจ่าย เว้นแต่สถานะการอ่านจะถูกแก้ไขระหว่างการตรวจสอบความถูกต้อง . การดำเนินการเหล่านี้สามารถนำไปใช้ได้โดยการฝังวิธี ABI หรือโดยการเพิ่มส่วน EOF เฉพาะหากมีการใช้ EOF EIP

โชคดีที่สิ่งนี้ไม่ต้องการให้เราถือว่า ERC-4337 เป็นมาตรฐานขั้นสุดท้าย แต่แทนที่จะรวมเอาแนวคิดที่อ่อนแอกว่าซึ่งรองรับโดย ERC-4337 ซึ่งรองรับได้อย่างง่ายดายโดย ERC อื่นๆ ที่แตกต่างกันอย่างมาก

เหตุผลคือความซับซ้อนของ ERC-4337 และ EIP-2938 ส่วนใหญ่เกี่ยวข้องกับการแก้ปัญหาการต่อต้าน DoS ที่แข็งแกร่งกว่า: เป็นไปไม่ได้ที่จะทำให้การดำเนินการหนึ่งรายการยกเลิกการดำเนินการอื่น ๆ อีกหลายร้อยรายการ เนื่องจากจะทำให้ขยะราคาถูกของ mempool ทำธุรกรรมได้ จู่โจม. ซึ่งจำเป็นต้องมีข้อจำกัดในการยืนยันบัญชีที่สามารถเข้าถึงได้ ที่นี่ เราสามารถทำอะไรที่ง่ายกว่านั้น: เพียงบันทึกว่าวัตถุสถานะใดถูกแตะระหว่างการตรวจสอบ และไม่จำเป็นต้องรวมไว้หากมีการแก้ไขวัตถุสถานะใด

ซึ่งช่วยให้แต่ละบัญชีสามารถเลือกการแลกเปลี่ยนระหว่างการต่อต้านการเซ็นเซอร์และความยืดหยุ่นได้เอง ในกรณีที่รุนแรง บัญชีสามารถจ่ายค่าธรรมเนียมระหว่างการตรวจสอบผ่าน Uniswap ได้หากต้องการ แต่เนื่องจากใครก็ตามสามารถส่งธุรกรรมที่ส่งผลกระทบต่อสถานะของ Uniswap บัญชีดังกล่าวจึงไม่รับประกันการต่อต้านการเซ็นเซอร์อย่างมีประสิทธิภาพ

โครงร่างทั่วไปของการออกแบบ crList มีดังนี้:

1. ข้อเสนอสามารถมี crList ที่ระบุรายการการดำเนินการที่จะรวม และรายการของคู่สถานะ (คีย์ ค่า) ที่แต่ละการดำเนินการอ่าน ผู้สร้าง (หรือใครก็ตาม) ที่ยอมรับ crList จะต้องตรวจสอบว่าการดำเนินการทั้งหมดผ่านการตรวจสอบความถูกต้อง

2. บล็อกจำเป็นต้องดำเนินการทุกการดำเนินการใน crList เว้นแต่บล็อกนั้นไม่มีก๊าซเหลือเพียงพอ หรือสถานะปัจจุบัน ณ เวลาที่ดำเนินการได้แก้ไขหนึ่งในวัตถุสถานะที่อ่านโดยการดำเนินการ

ความซับซ้อนที่เหลืออยู่ของ ERC-4337 จะใช้สำหรับการรักษาความปลอดภัย mempool เท่านั้น โดยหลักการแล้ว อาจมี ERC ที่แข่งขันกันหลายรายการที่บรรลุเป้าหมายนี้ด้วยวิธีที่แตกต่างกัน ตราบใดที่พวกเขาปฏิบัติตามมาตรฐานการตรวจสอบและการบังคับใช้เดียวกัน

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

แผนงานที่เป็นไปได้

ช่วงเวลาสั้น ๆ

1. ใส่ ERC-4337 ในการผลิตเต็มรูปแบบ เป็นการดีที่สามารถขยายได้ด้วยฟังก์ชันการรวมลายเซ็นเพื่อความเป็นมิตรในการยกเลิก

2. ควรมีกระเป๋าเงินเบราว์เซอร์ที่ใช้งานง่ายซึ่งเชื่อมต่อกับ ERC-4337

3. พิจารณาใช้การรวมลายเซ็นและการบีบอัดเพื่อทำให้ ERC-4337 เป็นมิตรกับ L2 มากขึ้น

4. แนะนำระบบนิเวศ ERC-4337 ในโปรโตคอล L2 ซึ่งปัญหาต้นทุนก๊าซจะน้อยลง

กลางภาค

1. ใช้ Verkle tree เพิ่ม EIP เพื่อลดต้นทุนก๊าซ

2. เพิ่มตัวเลือกการแปลง EOA-to-ERC-4337

3. เพิ่มตรรกะ crList พร้อมกันหรือหลังจากเปิดตัว PBS ไม่นาน

ยาว

1. ชื่อเรื่องรอง

ทางเลือกที่เป็นไปได้

1. พิจารณาการเขียน EIP ที่มีบัญชีและธุรกรรมที่เทียบเท่า ERC-4337 ที่เลเยอร์โปรโตคอล และผลักดันการยอมรับใน L2

2. ขจัดความจำเป็นในการดำเนินการของผู้ใช้เพื่อให้สามารถอ่านโปรโตคอล Ethereum ได้โดยใช้โซลูชันที่ป้องกันการเซ็นเซอร์ซึ่งทำงานผ่านบล็อคเสริม