Ethereum มีบัญชี 2 ประเภท: Externally Owned Account (EOA) และ Contract Account (CA) EOA ถูกควบคุมโดย private key ในขณะที่ CA ถูกควบคุมโดยโค้ดสมาร์ทคอนแทนในตัวมัน EOA มีสิทธิพิเศษมากกว่า CA เสมอ เพราะเพียง EOA เท่านั้นที่สามารถเริ่มการดำเนินการธุรกรรมโดยการจ่าย gas Account Abstraction (AA) เป็นข้อเสนอที่อนุญาตให้สัญญาสามารถเป็นบัญชีระดับสูง เหมือน EOA ที่สามารถจ่ายค่าธรรมเนียมและเริ่มการดำเนินการธุรกรรม

แรงจูงใจของ AA คือการปรับปรุงประสบการณ์ของผู้ใช้ให้ดีขึ้นอย่างมีนัยสำคัญในเรื่องของวิธีการที่ผู้ใช้มีปฏิสัมพันธ์กับบล็อกเชน Ethereum ในปัจจุบันในสถานการณ์ต่างๆ เช่น กระเป๋าสตางค์ ผสมเสียง, ÐApps และ DeFi AA ให้ความสามารถในระบบชั้นฐานใน Ethereum เพื่อตัดสินใจเมื่อใดที่คนสามารถจ่ายค่าแก๊สซึ่งยังมีผลต่อใครจะจ่ายค่าแก๊สและวิธีที่พวกเขาจะจ่ายค่าแก๊ส

แอปพลิเคชัน Messenger ของ Status รวมกันด้วย Messenger ที่ใส่ใจความเป็นส่วนตัวพร้อมกับกระเป๋าเงิน Ethereum และ Web3 ÐApp browser กระเป๋าเงินของ Status ในขณะนี้เป็นกระเป๋าเงิน EOA ซึ่งจำกัดเราจากการนำเสนอ UX ที่ครบครันที่เฉพาะกระเป๋าเงินสมาร์ทคอนแทรคที่สามารถให้เช่นความปลอดภัยแบบลายมือลายเท้าตัวเป็นหลายส่วนการกู้คืนทางสังคมการจำกัดอัตราการอนุญาตและปฏิเสธรายการของที่อยู่และการทำธุรกรรมยามยกยอโดยไม่เสียค่าธรรมเนียม อย่างไรก็ตาม ปัญหา UX ของกระเป๋าเงินสมาร์ทคอนแทรคในปัจจุบันถูกความขัดข้องอย่างมากโดยราคาแก๊สที่เปลี่ยนแปลงอย่างไม่คงที่ซึ่งไม่ได้รับการแก้ไขอย่างมีประสิทธิภาพโดย relayers ฝ่ายที่สาม สมาคม AA มีเป้าหมายที่จะแก้ไขปัญหานี้

ในบทความนี้ เราจะให้กำลังใจในความจำเป็นของการใช้ Account Abstraction ในบริบทของตลาดสมาร์ทคอนแทรคท์ จากนั้นเราจะลงไปในด้านสำคัญของ AA โดยการอธิบายการเปลี่ยนแปลงของโปรโตคอลและผลกระทบต่อโหนด สุดท้าย เราจะพูดถึงส่วนขยายที่เสนอและสรุปโดยการสรรสร้างแผนโครงการที่แผนรับส่วนที่ต้องการติดต่อกับ Ethereum และอาจได้รับผลกระทบจาก AA

ประวัติศาสตร์และแรงจูงใจ

Account Abstraction ถูกเสนอครั้งแรกเป็นEIP-86ในปี 2017 เพื่อให้การทำงานของ "การทำให้ต้นทางและลายเซ็นของธุรกรรมเป็นนามธรรม" แต่แรงบันดาลของความคิดดังกล่าวกลับย้อนหลังไปอีกมากกว่านั้นต้นปี 2016, ที่ได้มีคำแนะนำว่า: “แทนที่จะมีกลไกในโปรโตคอลที่ ECDSA และ default nonce scheme ถูกยึดเป็นวิธีเดียวที่ “มาตรฐาน” ในการรักษาความปลอดภัยของบัญชี เราจะเริ่มต้นด้วยการสร้างโมเดลที่ในระยะยาวทุกบัญชีจะกลายเป็นสัญญา สัญญาสามารถจ่ายค่า gas และผู้ใช้สามารถกำหนดโมเดลความปลอดภัยของตัวเองได้เสรี”

ข้อเสนอเบื้องต้นถูกพิจารณาว่ายากที่จะนำมาใช้เนื่องจากมีการเปลี่ยนแปลงโปรโตคอลมากมายที่จำเป็นและการรับรองความปลอดภัยที่จะต้องประทับใจ ในทวีปสุดท้าย Vitalik et al. ได้เสนอร่าง EIP-2938ซึ่งกล่าวถึงวิธีการปรับปรุงที่ง่ายมากโดยการเก็บรักษาการเปลี่ยนแปลงของโปรโตคอล/คอนเซนซัสให้น้อยที่สุดและบังคับการรักษาความปลอดภัยที่จำเป็นผ่านกฎของ mempool ของโหนด ของ Vitalikการนำเสนอกลุ่ม Ethereum Engineering Meetupและการนำเสนอ ETHOnline(พร้อมกับบทความที่ประกอบ@SamWilsn/ryhxoGp4D">1 & @SamWilsn/S1UQDOzBv">2) โดย Sam Wilson & Ansgar Dietrichs (ผู้เขียน EIP อีกสองคน) มีบทนำที่ยอดเยี่ยมเกี่ยวกับหัวข้อนี้ บทความนี้เน้นหลักการสำคัญจากแหล่งข้อมูลทั้งหมดเหล่านี้

แรงจูงใจ: เหตุผลจูงใจที่อยู่เบื้องหลัง AA นั้นง่ายมาก แต่เป็นพื้นฐาน: ธุรกรรม Ethereum ในปัจจุบันมีผลกระทบที่ตั้งโปรแกรมได้ (ทําได้ผ่านการโทรไปยังสัญญาอัจฉริยะ) แต่พวกเขามีความถูกต้องคงที่ในการทําธุรกรรมนั้นจะใช้ได้ก็ต่อเมื่อพวกเขามีลายเซ็น ECDSA ที่ถูกต้องพร้อม nonce ที่ถูกต้องและมียอดคงเหลือในบัญชีเพียงพอ AA อัพเกรดธุรกรรมจากความถูกต้องคงที่เป็นความถูกต้องที่ตั้งโปรแกรมได้โดยแนะนําประเภทธุรกรรม AA ใหม่ที่มาจากที่อยู่พิเศษเสมอซึ่งโปรโตคอลไม่จําเป็นต้องมีการตรวจสอบลายเซ็น nonce หรือยอดคงเหลือ ความถูกต้องของธุรกรรม AA ดังกล่าวจะถูกกําหนดโดยสัญญาอัจฉริยะเป้าหมายซึ่งสามารถบังคับใช้กฎความถูกต้องของตนเองหลังจากนั้นสามารถตัดสินใจชําระเงินสําหรับธุรกรรมดังกล่าวได้

ดังนั้น ทำไมมันถึงมีประโยชน์? ให้เรามาดูตัวอย่างของกระเป๋าเงิน Ethereum เพื่อเน้นความสำคัญของ AA กัน

พวกกระเป๋าสมาร์ทคอนแทร็ก: กระเป๋าเอทีเธอเรียมส่วนใหญ่ในปัจจุบันเป็นกระเป๋า EOA ซึ่งได้รับคุ้มครองด้วยคีย์ส่วนตัวที่สร้างจากวลีเมล็ดพันธุ์BIP-39วลัยหรือคำบรรยายเรียงลำดับเป็นรายการของคำ 12-24 คำที่ถูกเลือกแบบสุ่มจากรายการ 2048 คำ สร้างเอ็นโทรปีที่จำเป็นในการได้รับเมล็ดที่สร้างขึ้นโดยใช้ฟังก์ชัน PBKDF2 เมล็ดที่สร้างขึ้นจากนั้นถูกใช้ในการสร้างคู่สุ่มคีย์สำหรับ BIP-32(กระเป๋าเงิน) ผู้ใช้คาดหวังที่จะจดบันทึกวลีเมล็ดพันธุ์ไว้ในที่ปลอดภัยใด ๆ เพราะอาจจำเป็นต้องใช้ภายหลังสำหรับการกู้คืนคีย์บนกระเป๋าเงินอื่น ๆ กระเป๋าเงินเช่นนี้อย่างไรก็ตาม อาจเป็นอยู่ในอันตรายต่อการถูกขโมยคีย์ส่วนตัวหรือสูญหายของวลีเมล็ดพันธุ์ซึ่งจะทำให้เสียเงินของผู้ใช้

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

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

ตัวอย่างของกระเป๋าสมาร์ทคอนแทร็กArgent, Authereum, Dapper, Dharma, Gnosis Safe, โมนอลิธและMYKEYการนำร่างกายของกระเป๋าเงินเหล่านี้ดูเหมือนจะเพิ่มขึ้นตามที่แสดงไว้ด้านล่างกราฟ.

Argent ใช้การกู้คืนด้วยตนเองโดยไม่ต้องมีการใช้ Seed ด้วยแนวคิดของ Guardians ซึ่งเป็นคนหรืออุปกรณ์ที่ผู้ใช้ว่าเชื่อถือได้ที่สามารถช่วยกู้คืนกระเป๋าเงินของผู้ใช้ได้ด้วย Argent เป้าหมายของ Argent ยังคงเป็นการเป็นธนาคารโดยใช้ความปลอดภัยแบบธนาคาร (ผ่านคุณสมบัติเช่น วงเงินการทำธุรกรรมรายวัน การล็อคบัญชีและติดต่อที่เชื่อถือได้) ร่วมกับความสามารถในการใช้งานแบบ Venmo (ผ่านการใช้ชื่อ ENS แทนที่จะใช้ที่อยู่และรองรับ meta-transactions)

Gnosis Safe เป็นกระเป๋าสตางค์สมาร์ทคอนแทร็กหลายลายซึ่งเน้นการจัดการทีมของเงินทุนที่ต้องการจำนวนขั้นต่ำ (m-of-n) ของสมาชิกทีมให้อนุมัติธุรกรรมก่อนที่จะเกิดขึ้น นอกจากนี้ยังสามารถเปิดใช้งานลายเซ็นต์โดยไม่ต้องใช้แก๊สผ่านการทำธุรกรรมแมต้า

ความสามารถของกระเป๋าเงินขั้นสูงเช่นนี้ ต้องการการใช้งานของสัญญาอัจฉริยะที่ซับซ้อน ผู้ใช้กระเป๋าเงินจะต้องมี EOA พร้อมกับแก๊สเพื่อที่จะสื่อสารกับพวกเขา หรือจะขึ้นอยู่กับผู้ให้บริการกระเป๋าเงินที่จะสนับสนุนการทำธุรกรรมย่อยผ่านทาง relayers ของผู้ให้บริการ หรือเครือข่าย relayer จากบุคคลที่สามเครือข่ายปั้มน้ำมัน. ในขณะที่ข้อแรกเชื่อมั่นใน ETH ที่ซื้อโดยทั่วไปบนบริษัทแลกเปลี่ยนกลางหลังจาก KYC ข้อหลังมีเป้าหมายที่จะลดความเสียหายใน UX การเข้าสู่ระบบนี้โดยการโอนภาระของผู้ใช้ไปยังผู้ส่งเสริมด้วยค่าใช้จ่ายที่ได้รับการชดเชยโดยผู้ให้บริการกระเป๋าเงิน on-/off-chain และ/หรือโดยผู้ใช้ off-chain

อย่างไรก็ตาม โครงสร้างที่ใช้ relayer มีจุดอ่อนสามจุดหลัก: (1) อาจถูกพิจารณาว่าเป็นตัวกลางที่มีลักษณะส่วนกลางที่สามารถเซ็นเซอร์ธุรกรรม (2) พวกเขาไม่มีประสิทธิภาพทางเทคนิค/เศรษฐศาสตร์เนื่องจากมีค่าธรรมเนียมเบสพิเศษ 21000 หน่วยที่จำเป็นสำหรับธุรกรรมของ relayer และความต้องการทางธุรกิจของพวกเขาที่ต้องการทำกำไรเพิ่มเติมเหนือค่าธรรมเนียม (3) การใช้โปรโตคอลที่เฉพาะเจาตัวของ relayer ทำให้แอปพลิเคชันต้องพึ่งพาที่พื้นฐาน Ethereum ที่มีพื้นฐานผู้ใช้เล็กกว่าและไม่มั่นใจในการรับประกันความพร้อมใช้งาน

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

Tornado Cash: แอพพลิเคชันที่เกี่ยวข้องที่มีความกระตุ้นคือการผสมเช่นเดียวกับ tornado.cashที่@tornadoTornado ปรับปรุงความเป็นส่วนตัวของธุรกรรมโดยการแตกต่างจากการเชื่อมโยง on-chain ระหว่างที่อยู่โดยใช้สัญญาอัจฉริยะที่ยอมรับการฝากเงิน ETH ซึ่งสามารถถอนได้ภายหลังโดยที่อยู่แตกต่างกัน ผู้ใช้คาดหวังว่าจะให้แฮชของความลับในระหว่างการฝากและภายหลังให้พิสูจน์ zkSnark ในการถอนเพื่อแสดงความรู้เกี่ยวกับความลับโดยไม่เปิดเผยความลับหรือการฝากเงินเริ่มแรก สิ่งนี้ทำให้การถอนไม่ได้เชื่อมโยงกับการฝาก

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

การแยกบัญชีจะแก้ปัญหานี้โดยอนุญาตให้สัญญา Tornado ยอมรับธุรกรรมการถอน AA จากผู้ใช้ ตรวจสอบ zkSnark หักค่าธรรมเนียมในการเปิดบัญชีบางส่วน (จากจำนวนเงินฝากเงินก่อนหน้า) แล้วโอนจำนวนเงินฝากเงินที่เหลือไปยังที่อยู่การถอน

การนำบัญชีมากใน

Account Abstraction, ตามที่เสนอใน EIP-2938, ช่วยให้สัญญาณเป็นบัญชีระดับบนที่จ่ายค่าธรรมเนียมและเริ่มการดำเนินการธุรกรรม นี้ถูกบรรลุด้วยการนำเสนอการเปลี่ยนแปลงโปรโตคอลด้วยชนิดธุรกรรม AA ใหม่ที่ต้องการสองชนิดของ opcode ใหม่: NONCE และ PAYGAS, การเปลี่ยนแปลงกฎ mempool และส่วนขยายเพื่อรองรับการใช้งานที่ขั้นสูง ชนิดของบัญชียังคงเป็นสอง (EOA และ สัญญาณสัญญา) และการเปลี่ยนแปลงทั้งหมดที่เสนอนี้เป็นสอดคล้องกับธุรกรรมปัจจุบัน สัญญาอัจฉริยะ และโปรโตคอล

การใช้งานของ AA ถูกพิจารณาในสองหมวด: 1) แอปพลิเคชันเซิงเกิ้ลเทแนนท์ เช่น กระเป๋าตัวสมาร์ทคอนแทร็กที่สร้างสัญญาใหม่สำหรับแต่ละผู้ใช้ 2) แอปพลิเคชันหลายเทแนนท์ เช่น tornado.cash หรือ Uniswap ที่ผู้ใช้หลายคนมีปฏิสัมพันธ์กับเซ็ตสัญญาอัจฉริยะเดียวกัน

การสนับสนุน AA สำหรับแอปพลิเคชันหลายผู้เช่าต้องการการวิจัยเพิ่มเติมและถูกเสนอเป็นงานที่จะมาในอนาคต ดังนั้นเราจะมุ่งเน้นการสนับสนุน AA สำหรับผู้เช่าเดี่ยวในบทความนี้

การเปลี่ยนแปลงโปรโตคอล

มีประเภทธุรกรรมใหม่ที่นำเสนอพร้อมกับคำสั่ง NONCE และ PAYGAS 2 คำสั่งที่ให้การสนับสนุน นี้เป็นการเปลี่ยนแปลงโปรโตคอลเท่าที่เท่านั้น

ธุรกรรม AA: มีการนำเสนอประเภทใหม่ของธุรกรรม AA แบบ AA_TX_TYPE ซึ่งข้อความของมันถูกตีความว่า RLP([nonce, target, data]) แทนที่ประเภทธุรกรรมที่มีอยู่ก่อนหน้าซึ่งข้อความของมันถูกตีความว่า RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s])

ราคาก๊าซและขีดจำกัดก๊าซที่ถูกข้ามในธุรกรรม AA ถูกระบุโดยสัญญา AA เป้าหมายระหว่างการดำเนินการ ลายเซ็น ECDSA v, r, s ที่ถูกข้ามในธุรกรรม AA ถูกแทนที่ด้วยการตรวจสอบเฉพาะสัญญาบนข้อมูล ที่อยู่เป้าหมายถูกแทนที่ด้วยที่อยู่สัญญาเป้าหมาย มูลค่าถูกข้ามเนื่องจากที่อยู่ต้นทางสำหรับธุรกรรม AA ทั้งหมดเป็นที่อยู่ที่เข้าถึงพิเศษ (0xFFFF…FFFF) และไม่ใช่ EOA ซึ่งมีค่าที่เกี่ยวข้อง

โนนซ์ถูกประมวลผลอย่างอนาล็อกได้เหมือนกับการทำธุรกรรมที่มีอยู่โดยการตรวจสอบว่า tx.nonce == tx.target.nonce หากการตรวจสอบนี้ล้มเหลว ธุรกรรมจึงถือว่าไม่ถูกต้อง แต่ในทางกลับกัน tx.target.nonce จะถูกเพิ่มขึ้นและธุรกรรมจะดำเนินไป

ค่าใช้จ่ายในการทำธุรกรรม AA ฐานเสียงถูกเสนอให้เป็น 15000 แทนที่ 21000 ปัจจุบัน (เพื่อแสดงความประหยัดของค่าใช้จ่ายจากข้อบกพร่องของลายเซ็นเจอร์ ECDSA) นอกจากนี้ ธุรกรรม AA ไม่มีขีดจำกัดในการใช้เสียง ขณะเริ่มการดำเนินการ ขีดจำกัดใช้เสียงจะถูกตั้งเพียงแค่เท่ากับเสียงที่เหลือในบล็อก

โอปโค้ด NONCE: โอปโค้ด NONCE (0x48) ผลักภาระของ callee หรือ AA target contract ลงบน EVM stack Nonces ถูกเปิดเผยให้กับ EVM เพื่ออนุญาตให้การตรวจสอบลายเซ็นเจเนอเรทชั่นถูกดำเนินการผ่านฟิลด์ทรานแซคชันทั้งหมด (รวมถึง nonce) เป็นส่วนหนึ่งของการตรวจสอบในสัญญา AA

โค้ดค่าเชื้อเพลิง PAYGAS: โค้ดค่าเชื้อเพลิง PAYGAS (0x49) เอาอาร์กิวเมนต์สองตัวจากสแต็ก: (ด้านบน) เวอร์ชัน_นัมเบอร์, (อันดับสองจากด้านบน) เริ่มต้นหน่วยความจำ_เมมโมรี่ เวอร์ชัน_นัมเบอร์ อนุญาตให้การปรับเปลี่ยนความหมายของโค้ดค่าเชื้อเพลิงสำหรับการนำมาใช้ในอนาคต ในปัจจุบัน โค้ดค่าเชื้อเพลิงมีความหมายดังต่อไปนี้:

1. ตรวจสอบ version_number == 0 (ถ้าไม่ใช่ ให้โยน exception)
2. อ่าน gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
3. อ่าน gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])
4. ตรวจสอบ contract.balance >= gas_price * gas_limit (else โยน exception)
5. ตรวจสอบ globals.transaction_fee_paid == False (มิฉะนั้นโยนคำพูดสร้างความสับสน)
6. ตรวจสอบเฟรมการดำเนินการ AA == เฟรมระดับบน นั่นคือ หากการดำเนินการ EVM ปัจจุบันออกหรือย้อนกลับ การดำเนินการ EVM ของธุรกรรมทั้งหมดจะถูกสิ้นสุด (มิฉะนั้นโยนข้อยกเว้น)
7. ตั้ง contract.balance -= gas_price * gas_limit
8. ตั้ง globals.transaction_fee_paid = จริง
9. ตั้ง globals.gas_price = gas_price และ globals.gas_limit = gas_limit
10. ตั้งสถานการณ์การดำเนินการปัจจุบัน ทำให้ remaining_gas = gas_limit - gas ที่ถูกใช้ไปแล้ว

เมื่อสิ้นสุดการดำเนินการของธุรกรรม AA (globals.gas_limit - remaining_gas) globals.gas_price ถูกโอนไปยังผู้ทำเหมืองและสัญญา AA ถูกคืน remaining_gasglobals.gas_price.

PAYGAS ทำหน้าที่เป็นจุดตรวจสอบการดำเนินการ EVM ใด ๆ หลังจากจุดนี้จะถอนการทำรายการเฉพาะจนถึงจุดนี้แล้วทำให้สัญญาไม่ได้รับเงินคืนและ globals.gas_limit * globals.gas_price ถูกโอนไปยังนักขุด

ประเภทธุรกรรมใหม่และรหัสโอปคอดใหม่สองตัว เป็นการเปลี่ยนแปลงระดับโปรโตคอล/คอนเซนซัส และความหมายทางวิธีการของมันเป็นเรื่องที่ง่ายต่อการเห็นเหตุผล

กฎของ Mempool

“The mempoolอ้างถึงชุดของโครงสร้างข้อมูลในหน่วย Ethereum ภายในที่เก็บรายการธุรกรรมตัวเลือกก่อนที่จะถูกขุด Geth เรียกว่า “สระธุรกรรม”; Parity เรียกว่า “คิวธุรกรรม” ไม่ว่าจะเรียกชื่อว่าอย่างไรก็ตาม มันคือสระของธุรกรรมที่นั่งอยู่ในหน่วยความจำรอการรวมเข้าในบล็อก คิดเหมือน “พื้นที่รอ” สำหรับธุรกรรมที่จะได้รับการยอมรับเข้าไปในบล็อก

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

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

นักขุดแร่และโหนดจึงต้องการกลไกที่สามารถทำนายได้เพื่อหลีกเลี่ยงการขึ้นอยู่กับความถูกต้องของธุรกรรม AA ที่รอดำเนินการจากธุรกรรมที่รออยู่ใน mempool หากไม่เช่นนั้น การดำเนินการของธุรกรรมหนึ่งอาจจะทำให้ธุรกรรม AA หลายรายการหรือทั้งหมดใน mempool กลายเป็นโมฆะซึ่งอาจนำไปสู่การโจมตีแบบ DoS โดยเพื่อหลีกเลี่ยงสถานการณ์นี้มีกฎที่เสนออยู่สองข้อที่จะถูกบังคับ (โดยนักขุดแร่และโหนดแต่ไม่ได้เอาระบบโปรโตคอลเอง) ในธุรกรรม AA ใน mempools:

ข้อจำกัดของโอปโค้ด

เพื่อป้องกันความถูกต้องของธุรกรรม AA จากการขึ้นอยู่กับสถานะภายนอกที่ปรากฏบนสัญญา AA ตัวเอง โค้ดคำสั่งต่อไปนี้ถือว่าไม่ถูกต้องในขั้นตอนการตรวจสอบ (เช่น ก่อน PAYGAS): โค้ดคำสั่งสภาพแวดล้อม (BLOCKHASH, COINBASE, TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT) , BALANCE (ของบัญชีใดๆ รวมถึงเป้าหมายตัวเอง), การเรียกใช้ภายนอก/สร้างวัตถุใดๆ นอกเหนือจากเป้าหมายหรือ precompile (CALL, CALLCODE, STATICCALL, CREATE, CREATE2) และการเข้าถึงสถานะภายนอกที่อ่านโค้ด (EXTCODESIZE, EXTCODEHASH, EXTCODECOPY, DELEGATECALL) นอกจากที่อยู่เป้าหมาย

โหนดคาดว่าจะลดการทำธุรกรรม AA ในเมมพูลที่เป้าหมายที่ AA สัญญาที่เจาะข้อจำกัดนี้ ซึ่งทำให้มั่นใจว่าการทำธุรกรรม AA ที่ถูกต้องในเมมพูลจะยังคงถูกต้องตลอดจนสถานะสัญญา AA ไม่เปลี่ยนเปลี่ยน

ข้อจำกัดรหัสบน

หากธุรกรรม non-AA สามารถส่งผลต่อสถานะของสัญญา AA การดำเนินการนี้จะส่งผลต่อความถูกต้องของธุรกรรม AA ใน mempool เพื่อป้องกันปัญหานี้ ควรอนุญาตให้มีธุรกรรม AA เป้าหมายต่อสัญญาที่มี AA_PREFIX ที่ขึ้นต้นของ bytecode ของตน โดยที่ AA_PREFIX นำมาตรการตรวจสอบว่า msg.sender เป็นที่อยู่พิเศษ ENTRY_POINT ของธุรกรรม AA นี้ นี้จะป้องกันธุรกรรม non-AA ไม่สามารถมีปฏิสัมพันธ์กับสัญญา AA

โหนดคาดว่าจะทิ้งการทำธุรกรรม AA ไปยังสัญญา AA ที่ไม่มี AA_PREFIX ที่จุดเข้าโค้ดบายต์ของพวกเขา

ข้อจำกัดสองข้อนี้ที่บังคับใช้กับสัญญา AA ร่วมกัน ทำให้แน่ใจว่า: (1) สถานะที่สามารถเข้าถึงได้โดยตรงโดยตรงถูกตรวจสอบสถานะ AA และ (2) สถานะนี้สามารถถูกปรับเปลี่ยนได้เฉพาะโดยบัญชีธุรกรรม AA อื่น ๆ ที่เน้นถึงสัญญา AA นี้โดยเฉพาะ

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

ส่วนขยาย

การเปลี่ยนแปลงโปรโตคอลด้านบนและกฎของ mempool ช่วยให้สัญญา AA พื้นฐานสามารถนำมาใช้ในการประยุกต์ใช้แอปพลิเคชันแบบเช่าเรียกเท่านั้นอย่างเพียงพอและปลอดภัย เช่นกระเป๋าสมาร์ทคอนแทรค การใช้งานขั้นสูงอื่น ๆ ที่ต้องการความผ่อนคลายจากกฎด้านบนหรือต้องการนำมาใช้ในการประยุกต์ใช้แอปพลิเคชันแบบหลายผู้เช่าต้องการการสนับสนุนเพิ่มเติมจาก AA ในรูปแบบของส่วนขยาย เช่น:

1. โอปโคด SET_INDESTRUCTIBLE ซึ่งปิดการใช้งาน SELFDESTRUCT และอนุญาตให้สัญญา AA เรียกใช้ไลบรารีด้วย DELEGATECALL อย่างปลอดภัยในเฟสการตรวจสอบ
2. โอปโค้ด IS_STATIC ซึ่งคืนค่า true ถ้าบริบทปัจจุบันเป็นสถิตและอนุญาตให้ผู้เรียกธุรกรรมที่ไม่ใช่ AA ที่จะ Override ข้อจำกัดของไบต์โค้ดก่อนหน้าและอ่านค่าจากสัญญา AA ได้อย่างปลอดภัย
3. คำสั่ง RESERVE_GAS ซึ่งกำหนดขีดจำกัดล่างในการใช้แก๊สโดยสัญญา AA เมื่อเรียกใช้จากธุรกรรมที่ไม่ใช่ AA ที่พยายามเขียนสถานะสัญญา ซึ่งรับบริการในการบังคับผู้โจมตีไม่ให้ใช้แก๊สขั้นต่ำเพื่อไม่ให้มีความพยายามในการยกเลิกธุรกรรม AA ใด ๆ ใน mempool

มีสิ่งอื่น ๆ เช่น ธุรกรรมที่รอดำเนินการหลายรายการ การเก็บผลลัพธ์ของการตรวจสอบ ขีดจำกัดแก๊สเพื่อการตรวจสอบและธุรกรรมที่ได้รับการสนับสนุนที่จำเป็นสำหรับการสนับสนุนแอปพลิเคชันหลายผู้เช่าและพิสูจน์ zk ตัวอย่างเช่น Tornado Cash การอภิปรายเกี่ยวกับพวกเขาอยู่นอกขอบเขตของบทความนี้

ขั้นตอนต่อไป

บัญชี Abstraction EIP-2938 กําลังอยู่ในโหมดร่างและกําลังถูกกล่าวถึงในฟอรัมการวิจัยของ Ethereum ขั้นตอนต่อไปสําหรับ EIP คือการพิจารณาเพื่อรวมไว้ในหนึ่งใน hard forks ที่จะเกิดขึ้น ผู้เขียน EIP เห็นได้ชัดว่ามีเป้าหมายสําหรับ hard fork หลังจากเบอร์ลิน (เบอร์ลินมีกําหนดอย่างไม่แน่นอนในบางครั้งใน ต้นปี 2021) ซึ่งกำหนดเวลาไม่ชัดเจนในขณะนี้ ดังนั้นยังเร็วไปสำหรับกระบวนการ EIP-2938 อยู่

นอกจากนี้ยังไม่ชัดเจนว่าจะจำเป็นต้องรวม EIP-2938 ที่ Ethereum base Layer 1 (L1) โดยสิ้นเชิง โดยคำนึงถึงความยืดหยุ่นที่สูงของ Layer 2 (L2) solutions (ตามที่ได้ระบุไว้ในบทความก่อนหน้าของเรา บทความ) Account Abstraction อาจถูกนำมาใช้บน L2 ที่เฉพาะเจาะจงโดยไม่ต้องอัปเกรด L1 ทั้งหมด อย่างไรก็ตาม ยังมีประโยชน์จากการสนับสนุน AA แบบเดียวกันบน L1 แม้ว่าบาง L2 จะนำ AA เวอร์ชันของตนมาใช้เอง ดังนั้น ยังคงมีการดูว่า AA จะถูกนำมาใช้ที่ไหนและอย่างไร

"ความสำคัญของการดึงบัญชีมีความสำคัญน้อยลงเล็กน้อยเพราะสามารถนำมาใช้บน L2 ได้โดยไม่ว่า L1 จะรองรับหรือไม่" — Vitalik เกี่ยวกับสิ่งที่ยังคงสำคัญที่เลเยอร์พื้นฐาน (ในส่วนของเขาโพสต์ในแผนที่เน้น rollup บน Ethereum)

สถานะ: กระเป๋าเงินสถานะในปัจจุบันเป็นกระเป๋า EOA ซึ่งแตกต่างด้วยการรวมตัวของ Messenger ที่ใส่ใจความเป็นส่วนตัวและการเปิดใช้งานการผสานรวม เช่น การชำระเงินในแชทหรือความปลอดภัยที่เพิ่มเติมด้วยบัตรกุญแจคุณลักษณะของกระเป๋าเงินสมาร์ทคอนแทรคตั้นท์ เช่น การสนับสนุน Multisig และ social recovery กำลังถูกพิจารณาในส่วนที่ EIP-2938 จะช่วยโดยการลดความขึ้นอยู่กับโครงสร้างที่ใช้ relayer ที่มีการกระทำที่ไม่เป็นไปตามหลักการและไม่มีประสิทธิภาพที่เป็นศูนย์กลาง ตามที่ได้ระบุไว้ก่อนหน้า

Status กำลังประเมิน L2 ทั้งสำหรับการสนับสนุนโซลูชันหลายๆ โซร์ชั่นในวอลเล็ตและสำหรับการให้สเกลที่จำเป็นสำหรับกรณีการใช้งานต่างๆ ตามที่ได้ระบุไว้ในการแจ้งข่าวก่อนหน้าบทความ. ตัวอย่างเช่น Keycard กำลังสำรวจเครือข่ายการชำระเงินซึ่งข้อกำหนดในการออกแบบระดับความสามารถในการขยายตัวเทียบเท่ากับบัตรเครดิตและความสมบูรณ์ใกล้เคียงที่ไม่ได้รับการบรรลุผลโดยเครือข่าย Ethereum ในปัจจุบัน นอกจากนี้ยังมีมีมากมายด้านการดำเนินการอื่น ๆ เช่น โปรแกรมอ้างอิง, SNT ปฏิกิริยา, Tribute-to-Talkและชื่อ ENS, ซึ่งทั้งหมดนั้นจะได้รับประโยชน์จาก L2 scalability สำหรับการใช้งานที่เป็นไปได้และประสบการณ์ผู้ใช้ที่เหมาะสม หากมีการใช้งานที่ L2 ที่เป็นไปได้แล้วใช้ AA แล้วโครงการที่กำลังสร้างบน L2 นั้นจะสามารถใช้ประโยชน์จาก AA โดยไม่จำเป็นต้องพึ่งพา L1

สรุป

แง่ธรรมพื้นฐานของโปรโตคอล Ethereum คือว่าเฉพาะบัญชีที่เป็นเจ้าของภายนอก (EOAs) เท่านั้นที่สามารถชำระค่าธรรมเนียมการใช้แก๊สและเริ่มดำเนินการธุรกรรม บัญชีสัญญา (CAs) ไม่สามารถทำเช่นนั้นได้ แนวทางของ Account Abstraction (AA) เป็นข้อเสนอที่มุ่งหวังที่จะเปลี่ยนแปลงความแตกต่างนี้และอนุญาตให้บัญชีสัญญาที่สร้างขึ้นอย่างเฉพาะเพื่อตรวจสอบความถูกต้องของประเภทใหม่ของธุรกรรม AA ตัดสินใจที่จะชำระค่าธรรมเนียมการใช้แก๊สในนามของพวกเขาและดำเนินการเริ่มต้นโดยไม่จำเป็นต้องมี EOA

AA มีผลต่อการปรับปรุงประสบการณ์การใช้งานของผู้ใช้ในสถานการณ์ต่างๆ เช่น กระเป๋าเงิน ผสมผสาน ÐApps และ DeFi โดยไม่ต้องพึ่งพากับโครงสร้างที่ใช้รีเลย์เลอร์ที่มีประสิทธิภาพต่ำและที่มีจุดอ่อนในการทำงาน สถานการณ์ที่มีผู้เช่าเพียงคนเดียว เช่น กระเป๋าเงินสมาร์ทคอนแทรค สามารถรองรับได้อย่างปลอดภัยด้วย AA ด้วยการนำเสนอชนิดของธุรกรรมใหม่ สองคำสั่งโอปโค้ดใหม่และสองกฎเก็บข้อมูลชั่วคราวใหม่ การใช้งานหลายผู้เช่าระดับขั้นสูง เช่น Tornado Cash ต้องการการขยายตัวของการเปลี่ยนแปลงโปรโตคอลเหล่านี้และกฎของโหนด

ในบทความนี้ เราโต้ตอบถึงความจำเป็นของ AA ในบริบทของกระเป๋าสมาร์ทคอนแทร็ค โดยเราได้เน้นที่ด้านสำคัญของ AA โดยการอธิบายการเปลี่ยนแปลงของโปรโตคอลและผลกระทบต่อโหนด เราได้สัมผัสถึงบางส่วนของการขยายของการใช้งานขั้นสูงที่เสนอและสรุปลงในท้ายที่สุดโดยการตั้งตำแหน่ง AA ในบริบทของแผนงานปัจจุบันของ Ethereum และลำดับความสำคัญที่ Status

การลดการเสียเวลาและปรับปรุงประสบการณ์ของผู้ใช้ใน Web3 เป็นความสำคัญอันดับต้นในโครงการทั้งหมดในระบบนี้ การเลียนแบบบัญชีในรูปแบบใดก็ตามอาจจะเป็นสิ่งสำคัญในความพยายามนี้ในอนาคต

ข้อความประกันประทับใจ：

1. บทความนี้ถูกพิมพ์ซ้ำจาก [ สถานะ], Forward the Original Title'Account Abstraction (EIP-2938): Why & What', ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [ราจีฟ โกปาลาคริชนาหากมีข้อขัดแย้งใดๆเกี่ยวกับการพิมพ์ฉบับนี้ กรุณาติดต่อเกต เรียนทีม และพวกเขาจะดำเนินการโดยเร็ว

2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่ได้รับการแสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ได้เป็นที่ปรึกษาการลงทุนใดๆ

3. การแปลบทความเป็นภาษาอื่นๆ ดำเนินการโดยทีม Gate Learn หากไม่ได้กล่าวถึง การคัดลอก การกระจาย หรือการลอกเลียนแบบบทความที่ถูกแปลนั้นถือเป็นการละเมิดลิขสิทธิ์