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

อย่างไรก็ตาม EIP-4337 ยังคงมีจุดเจ็บเหล่านั้น เช่น การแยกบัญชีสมาร์ทและประสบการณ์ผู้ใช้ที่แยกออกอย่างสูงของการสร้างข้อบัญชีระหว่างโซนในโครงสร้าง EIP-4337 บทความนี้สำรวจวิธีการส่งเสริมการพัฒนาในสาขาการสร้างข้อบัญชีภายใต้กรอบ EIP-4337 โดยใช้โครงการเช่น Biconomy, Safe Core และ Particle Network เป็นตัวอย่าง

เข้าใจแนวคิดของการสรุปบัญชีจากมุมมองของการสรุปการไหลของธุรกรรม

เกี่ยวกับนามธรรมของบัญชี Vitalik ได้ชี้ให้เห็นหลายครั้งว่าเป็นเงื่อนไขที่จําเป็นในการลดเกณฑ์ของผู้ใช้ Ethereum และบรรลุการยอมรับจํานวนมาก วิสัยทัศน์หลักคือการอนุญาตให้ผู้ใช้ปรับแต่งวิธีการตรวจสอบลายเซ็นและเพลิดเพลินกับการชําระเงินด้วยก๊าซและสามารถเริ่มต้นการทําธุรกรรมแบบ on-chain โดยไม่ต้องใช้สินทรัพย์ใด ๆ (เรียกกันทั่วไปว่าธุรกรรมแบบไร้ก๊าซ) โดยการตระหนักถึงข้อกําหนดเบื้องต้นเหล่านี้เท่านั้นที่แอปพลิเคชัน Web3 สามารถปรับปรุงอัตราการแปลงของผู้ใช้ได้ แม้ว่าข้อเสนอนามธรรมที่ไม่ใช่บัญชีก่อนหน้านี้หรือกระเป๋าเงินสัญญาอัจฉริยะสามารถบรรลุประสบการณ์ที่คล้ายกัน แต่ก็ห่างไกลจากความยืดหยุ่นและมีประสิทธิภาพเพียงพอ ตัวอย่างเช่น Gnosis Safe ยังคงต้องการที่อยู่ EOA เพื่อกระตุ้นการทําธุรกรรมและค่าใช้จ่ายก๊าซที่เกี่ยวข้องนั้นสูงมาก สิ่งที่เป็นนามธรรมของบัญชีมีจุดมุ่งหมายเพื่อเพิ่มประสิทธิภาพโครงสร้างพื้นฐานของบัญชีสัญญาอัจฉริยะปูทางสําหรับระบบบัญชีอัจฉริยะรุ่นต่อไป แต่ถ้าเราดูข้อเสนอเชิงนามธรรมของบัญชีจริงเราจะพบว่าการมุ่งเน้นของพวกเขาไม่ได้อยู่ที่รูปแบบบัญชีเอง ตัวอย่างเช่นข้อเสนอที่เกี่ยวข้องกับนามธรรมของบัญชีเช่น EIP-86, EIP-4337 และ EIP-6900 มุ่งเน้นไปที่นามธรรม / โมดูลาร์ของกระบวนการประมวลผลทั้งหมดของธุรกรรมตั้งแต่เริ่มต้นจนถึงการรับโดยโหนดรวมถึงการตรวจสอบลายเซ็นการชําระเงินก๊าซ สิ่งที่เป็นนามธรรมของโครงสร้างบัญชี ดังนั้นจึงเหมาะสมกว่าที่จะเรียกข้อเสนอปัจจุบันต่างๆ ว่า "นามธรรมของกระแสธุรกรรม" หากเราเข้าใจข้อเสนอเชิงนามธรรมของบัญชีที่รู้จักกันดีจากมุมมองของนามธรรมของการไหลของธุรกรรมเราสามารถเข้าใจประเด็นหลักของพวกเขาได้ง่ายขึ้น: สิ่งที่เป็นนามธรรมของธุรกรรมประเภทนี้มีจุดมุ่งหมายเพื่อนําประสบการณ์ของผู้ใช้ในการเข้าสู่ระดับ Web2 และการใช้ผลิตภัณฑ์เข้าสู่ระบบ Ethereum สิ่งนี้อาจอยู่ในรูปของบัญชีดํา / บัญชีขาวการเริ่มต้นการซื้อขายโดยไม่มีการยืนยันตัวตนภายในระยะเวลาหนึ่งการทําธุรกรรมแบบไร้ก๊าซการชําระเงินสกุลเงินเฟียต

(Image source: Zengo)

อย่างไรก็ตาม บางคนอาจถาม: ไม่สามารถทำสิ่งเหล่านี้ได้ด้วยกระเป๋าเงินสมาร์ทคอนแทร็กที่มีอยู่ในอดีตหรือไม่? ค่ามูลค่าของการแยกแยะบัญชีเช่น EIP-4337 อยู่ที่ไหน?

สารวัตรของ EIP-4337: โซลูชันที่เหมาะสมในพื้นที่สำหรับการสร้างสรรค์บัญชีในระบบ Ethereum

จากคําถามข้างต้นชี้ให้เห็นว่าในขณะที่กระเป๋าเงินอัจฉริยะก่อนหน้านี้สามารถบรรลุฟังก์ชันที่กล่าวถึงได้อย่างแท้จริงวิธีการใช้งานโดยทั่วไปเป็นพื้นฐานและมักจะพึ่งพาโครงสร้างพื้นฐานของบุคคลที่สามที่รวมศูนย์สูง ตัวอย่างเช่นในอดีตโซลูชันรีเลย์แก๊สจําเป็นต้องมีการแนะนําโหนดเลเยอร์ของบุคคลที่สาม (EIP-2771) นอกจากนี้ยังมีการขาดมาตรฐานที่เป็นหนึ่งเดียวระหว่างกระเป๋าเงินอัจฉริยะที่แตกต่างกันซึ่งเป็นอุปสรรคต่อการพัฒนาและการปรับใช้ส่วนประกอบเสริม ความต้องการหลักของ EIPs ที่เกี่ยวข้องกับนามธรรมของบัญชีต่างๆ คือการแก้ไขข้อบกพร่องเหล่านี้ที่มีอยู่ในโครงการกระเป๋าเงินต่างๆ โดยการแนะนํากรอบมาตรฐานที่ออกแบบมาโดยเฉพาะสําหรับกระเป๋าเงินสัญญาอัจฉริยะ ความก้าวหน้านี้มีจุดมุ่งหมายเพื่อเปลี่ยนโครงสร้างบัญชีภายในระบบนิเวศของ Ethereum จากโครงสร้างการทํางานพื้นฐานเป็นโครงสร้างอัจฉริยะที่ซับซ้อนยิ่งขึ้นพร้อมความสามารถที่สูงขึ้น

(Image source: Springer Link)

นี่คือคล้ายกับสถานการณ์ก่อน ERC-20 หรือ ERC-721 ที่ทำให้วิธีการนำมาใช้ ความสามารถ และฟังก์ชัน/อินเทอร์เฟซที่ให้บริการของโทเคนหลายรายไม่สอดคล้องกัน ความไม่สอดคล้องเหล่านี้กีดขวางการพัฒนาโครงสร้างพื้นฐานของบุคคลที่สามและการตรวจสอบโค้ด (มันยากที่จะนึกภาพได้ว่าแอปพลิเคชัน DeFi จะเติบโตไปสู่ระดับปัจจุบันได้โดยไม่มีโปรโตคอล ERC-20)

มาตรฐานการใช้งานสําหรับโปรโตคอล / คุณสมบัติที่เป็นมาตรฐานเป็นข้อกําหนดเบื้องต้นสําหรับการออกแบบโมดูลาร์และการพัฒนาแบบแยกส่วนเกือบจะเป็นข้อกําหนดเบื้องต้นสําหรับสาขาใด ๆ ที่มุ่งสู่การเติบโตที่สดใส (การแบ่งงานเป็นหลักการแรกในการปรับปรุงประสิทธิภาพ)

ในที่สุด EIP-4337 ยืนออกมา

EIP-4337 เป็น solusion จำเป็นบางอย่าง แต่มีมุมมองหลายประการที่ต้องได้รับการปรับปรุงภายในกรอบของมัน

EIP-4337 กําหนดชุดมาตรฐานอินเทอร์เฟซที่สมบูรณ์โดยชี้แจงโมดูลที่คาดหวังในกระเป๋าเงินอัจฉริยะที่เป็นไปตามโปรโตคอล 4337 และฟังก์ชัน / อินเทอร์เฟซที่แต่ละโมดูลควรนําไปใช้ ตัวอย่างเช่นฟังก์ชันที่เรียกได้ควรประกอบด้วยส่วนประกอบเช่น bundler, entrypoints และ paymaster เสนอภายนอก ด้วยแนวทางเหล่านี้ปฏิสัมพันธ์ระหว่างส่วนประกอบต่างๆจะชัดเจนขึ้นอํานวยความสะดวกในการรวมแนวคิดการออกแบบแบบแยกส่วนเข้ากับการออกแบบนามธรรมของบัญชีและกระเป๋าเงินอัจฉริยะ นักพัฒนาที่ทํางานเกี่ยวกับโมดูลกระเป๋าเงินก็ได้รับประโยชน์อย่างมากเช่นกัน อย่างไรก็ตามเมื่อมองจากมุมมองของผู้ใช้อย่างหมดจดมูลค่าที่เกิดจากกระบวนทัศน์การพัฒนากระเป๋าเงินอัจฉริยะแบบแยกส่วนอาจไม่ชัดเจนในทันทีเนื่องจากการเปลี่ยนแปลงในกระเป๋าเงินที่เป็นนามธรรมของบัญชีเองอาจไม่ชัดเจนในระยะสั้น อย่างไรก็ตามเมื่อพิจารณาถึงระยะกลางถึงระยะยาวค่าของโปรโตคอลเช่น EIP-4337 คล้ายกับ ERC-20 และ ERC-721 มันวางรากฐานสําหรับการพัฒนาระยะยาวของกระเป๋าเงินนามธรรมบัญชีนับเป็นเหตุการณ์สําคัญ อย่างไรก็ตาม EIP-4337 ยังคงมีปัญหาที่ยังไม่ได้รับการแก้ไขมากมายเช่น:

1. การนำเข้าบัญชีไม่ง่ายมากพอที่จะสามารถผสานเข้าไปได้ ทำให้นักพัฒนาต่างกันต้องสร้างใหม่อย่างไม่ได้ตั้งใจ

2. ความเขัดข้องในความสอดคล้องของโมดูลบัญชีทำให้ระบบนิเวศเป็นส่วนส่วน

3. ความแตกต่างสูงของระบบนิเวศการสร้างบัญชีในระบบโซ่ต่าง ๆ ซึ่งทำให้ยากต่อการให้ประสบการณ์ที่สมบูรณ์และมีคุณภาพสูงสุดสำหรับผู้ใช้สุดท้ายและนักพัฒนา

ด้านล่างเราจะสำรวจวิธีการแก้ปัญหาเหล่านี้

โซลูชั่นการปรับปรุง 1: ปลั๊กอินการหน้าที่บัญชีจะกลายเป็นการกำหนดค่าพื้นฐาน

หนึ่งในจุดศูนย์กลางสำคัญในการอภิปรายปัจจุบันเกี่ยวกับการหนึ่งของบัญชีคือการเสริมความโมดูลาร์สำหรับกระเป๋าเงินที่เหนี่ยวนำและปรับปรุงความละเอียดของแต่ละโมดูลได้อีกด้วย ตัวอย่างเช่น Biconomy โดยใช้ EIP-4337 (EIP-6900 ที่ละเอียดมากขึ้นจะถูกนำเสนอในอนาคต) โดยมีข้อเสนอเรื่องการหนึ่งของบัญชีแบบเสียบและเล่นเพื่อเคลื่อนย้ายการพัฒนาแบบโมดูลาร์ของระบบนิเวศหนึ่งของบัญชีอีกต่อไป

(Image source: Biconomy)

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

Biconomy’s v2, ซึ่งก่อตั้งบน EIP-4337 เป็นกรอบโปรโตคอลที่ออกแบบมาเพื่อมีมาตรฐานที่ละเอียดมากขึ้นและนำเสนอชุดของอินเทอร์เฟซที่ไม่ได้กล่าวถึงใน EIP-4337 ในขณะที่ประกาศฟังก์ชันที่สามารถครอบครองได้ว่า bundlers, smart contract wallets, paymaster และโมดูลอื่น ๆ ควรมี Biconomy อนุญาตให้นักพัฒนาบุคคลที่สามสามารถดำเนินการโมดูลด้วยคุณสมบัติเดียวกันแต่มีรายละเอียดโค้ดที่แตกต่างกัน หากพวกเขาปฏิบัติตามแนวทางโปรโตคอลที่ถูกกำหนดโดย Biconomy (ที่เข้ากันได้กับ EIP-4337)

(มาตรฐานอินเทอร์เฟซที่เสนอโดย Biconomy ระบุว่านักพัฒนาโมดูลบุคคลที่สามควรใช้ฟังก์ชันใดภายในโมดูลสําหรับการโทรภายนอก) นอกจากนี้ Biconomy ยังแนะนําสโลแกนของ "Module Store" อย่างแข็งขันเพื่อส่งเสริมการเปิดตัว SDK โมดูลนามธรรมบัญชีในขณะที่สนับสนุนให้นักพัฒนาส่งโมดูลนามธรรมบัญชีที่ออกแบบเอง ความคิดริเริ่มนี้มีจุดมุ่งหมายเพื่อส่งเสริม "โมดูลเป็นบริการ" ทําให้โครงการกระเป๋าเงินทั้งหมดที่ปฏิบัติตามโปรโตคอล EIP-4337 สามารถนําโมดูลนามธรรมบัญชีที่พัฒนาภายนอกเหล่านี้มาใช้โดยตรง ขณะนี้ผู้ใช้มีตัวเลือกที่หลากหลายมากขึ้นเกี่ยวกับโมดูลที่จะใช้เมื่อสร้างบัญชีอัจฉริยะผ่านส่วนหน้า

โมดูลาร์ไม่เพียง แต่อํานวยความสะดวกในการแบ่งงาน แต่ยังอํานวยความสะดวกให้ผู้ใช้เปลี่ยนหรือเพิ่ม / ลบฟังก์ชั่นบางอย่างในกระเป๋าเงินอัจฉริยะได้อย่างรวดเร็ว พูดอย่างตรงไปตรงมาจะช่วยให้สามารถปรับแต่งความละเอียดของส่วนประกอบได้ Biconomy ชี้ให้เห็นว่ายิ่งระดับโมดูลาร์ในกระเป๋าเงินสัญญาอัจฉริยะสูงขึ้นเท่าใดการเปลี่ยนแปลงก็จะน้อยลงเมื่ออัปเดตหรืออัปเกรด ไม่จําเป็นต้องอัปเดตสัญญา Smart Contract Wallet ที่มีอยู่ของผู้ใช้หรือใช้ DelegateCall มีเพียงโมดูลภายนอกบางโมดูลเท่านั้นที่ต้องได้รับการอัปเดตทําให้ผู้ใช้หรือนักพัฒนารายอื่นสามารถแทนที่ส่วนประกอบบางอย่างได้สะดวก

ในโครงการสรุปบัญชีที่อัปเดตของ Biconomy ที่กำลังจะมา พวกเขายังจะพิจารณา EIP-6900 ซึ่งเหมาะสมกับการทำให้เป็นโมดูลมากกว่า EIP-4337

โซลูชันการปรับปรุง 2: การแบ่งส่วนโมดูลอย่างละเอียดมากขึ้นเพื่อแก้ไขปัญหาการแยกบัญชี

เกี่ยวกับ EIP-6900 Safe (ก่อนหน้านี้เคยเรียกว่า Gnosis Safe) ได้เผยแพร่เอกสารขาว Safe Core Protocol ในเดือนสิงหาคมปีนี้ ซึ่งถูกสร้างขึ้นจาก EIP-6900 อย่างมาก

(แผนผัง EIP-6900) EIP-6900 เน้นปัญหาที่แพร่หลายในนามธรรมบัญชีโมดูลาร์ปัจจุบันนั่นคือ "การกระจายตัว" ของบัญชีหรือปัญหาเกาะ ตัวอย่างเช่นในขณะที่ผู้ให้บริการโมดูลนามธรรมบัญชีที่แตกต่างกันหรือ DApps ต่างๆอาจเข้ากันได้กับ EIP-4337 แต่ระดับของนามธรรมในโมดูลต่างๆนั้นไม่เพียงพอโดยมีความละเอียดค่อนข้างต่ํา สถานการณ์นี้ช่วยให้นักพัฒนาโมดูลบัญชีอัจฉริยะมีอิสระ "มากเกินไป" (บัญชีอัจฉริยะเป็นองค์ประกอบหลักที่จัดเก็บข้อมูลผู้ใช้บันทึกการตรวจสอบธุรกรรมที่กําหนดเองและจัดการตรรกะการชําระเงินด้วยก๊าซ) เพื่อสร้างโมดูลที่มีคุณลักษณะเฉพาะ ด้วยเหตุนี้เมื่อเวลาผ่านไปโครงการกระเป๋าเงินที่แตกต่างกันมักจะออกแบบโมดูลบัญชีอัจฉริยะที่มีคุณสมบัติแตกต่างกัน แนวโน้มนี้บังคับให้ผู้ให้บริการโมดูลนามธรรมบัญชีอื่น ๆ จัดลําดับความสําคัญของความเข้ากันได้กับผู้ให้บริการโมดูลบัญชีอัจฉริยะที่เฉพาะเจาะจงโดยค่อยๆสร้างห่วงโซ่อุปทานต้นน้ํา - ปลายน้ําคงที่ สิ่งนี้นําไปสู่การกระจายตัวและการแยกระบบนิเวศโมดูลนามธรรมของบัญชีอย่างหลีกเลี่ยงไม่ได้ (คล้ายกับยุคแรก ๆ ในอุตสาหกรรมคอมพิวเตอร์ซึ่งนักพัฒนาระบบปฏิบัติการต้องพิจารณาความเข้ากันได้กับฮาร์ดแวร์จากผู้ผลิตหลายราย) เพื่อแก้ไขปัญหาการกระจายตัวของระบบนิเวศและเพิ่มความเข้ากันได้ระหว่างโมดูลนามธรรมบัญชีที่พัฒนาโดยผู้ให้บริการหลายรายแนวทางที่ดีที่สุดคือการเพิ่มเติมบัญชีกระเป๋าเงินสัญญาอัจฉริยะที่เป็นนามธรรมและปรับแต่งความละเอียดของการแบ่งส่วนโมดูล ตามหลักการที่ระบุไว้ใน EIP-6900 เอกสารรายงาน Safe Core Protocol ได้ทําการเพิ่มประสิทธิภาพโดยละเอียดสําหรับบัญชีอัจฉริยะ (บัญชีกระเป๋าเงินอัจฉริยะของผู้ใช้) Safe Core Protocol แบ่งโมดูลที่เรียกได้ภายในบัญชีกระเป๋าเงินอัจฉริยะแต่ละบัญชีออกเป็นหมวดหมู่ต่างๆเช่นปลั๊กอินตะขอตัวตรวจสอบลายเซ็นโปรเซสเซอร์ฟังก์ชันและอื่น ๆ โมดูลบัญชีอัจฉริยะมีจุดมุ่งหมายเพื่อให้มีน้ําหนักเบาที่สุดเท่าที่จะเป็นไปได้โดยจัดเก็บข้อมูลและฟังก์ชันที่จําเป็นเท่านั้นในขณะที่มอบหมายฟังก์ชันที่เคลื่อนย้ายได้ให้กับ "โปรเซสเซอร์ฟังก์ชัน" หรือโมดูลที่แบ่งส่วนที่คล้ายกัน วิธีการนี้สอดคล้องกับหลักการของมีดโกนของ Occam - "เอนทิตีไม่ควรคูณโดยไม่จําเป็น" หากบัญชีอัจฉริยะมีน้ําหนักเบาเพียงพอและไม่เกี่ยวข้องกับรายละเอียดที่ซับซ้อนเกินไปบัญชีอัจฉริยะที่พัฒนาโดยผู้ให้บริการที่แตกต่างกันจะแสดงโครงสร้างภายในที่ใกล้ชิดยิ่งขึ้นและความเข้ากันได้ที่สูงขึ้น

โปรโตคอล Safe Core ยังนำเสนอทะเบียน (คล้ายกับ iPhone App Store) ซึ่งประกอบด้วยโมดูลทั้งหมดที่ได้รับการอนุมัติและที่มีอยู่ ผู้ใช้สามารถเลือกโมดูลที่ต้องการเปิดใช้งาน และทุกครั้งที่มีการเปิดใช้งานโมดูลใหม่ จะต้องผ่านการประมวลผลผ่าน Manger

โดยทั่วไป UserOperation จะเรียกใช้ปลั๊กอินก่อน และจากนั้น Manager จะตรวจสอบว่าสถานะของปลั๊กอินอยู่ในสถานะปกติหรือไม่ (ที่จดทะเบียนไว้) หากอยู่ในสถานะปกติ คำขอของปลั๊กอินจะได้รับอนุญาต หากจำเป็น ปลั๊กอินจะเรียกใช้ฟังก์ชันบางฟังก์ชันที่ Hook หรือเลือกไม่เรียกใช้ ภายหลัง สถานะของบัญชีสมาร์ทที่เกี่ยวข้องกับ UserOperation จะถูกเปลี่ยนแปลง

ผ่านวิธีการแบ่งส่วนโมดูลอย่างละเอียดและกระบวนการตารางเวลาที่กล่าวถึงข้างต้น Safe Core Protocol พยายามที่จะดำเนินการเซ็ตของโปรโตคอลสื่อสารระหว่างโมดูลสร้างโฉมบัญชีโอเพนซอร์ส ไอเดียหลักคือการทำให้บัญชีสมาร์ทเป็นเบาและง่ายเหมือนบัญชี EOA เพื่อเสริมความเข้ากันได้ระหว่างโมดูลบัญชีสมาร์ทจากผู้ให้บริการต่างๆ

โซลูชันการปรับปรุง 3: บัญชี Omnichain Abstraction สำหรับบัญชีเข้าร่วมทั่วโลกที่แตกต่างกันในเครือข่าย

อย่างไรก็ตามแม้จะมีวิธีแก้ปัญหาดังกล่าวข้างต้น แต่ก็ยังมีปัญหาสําคัญที่ยังไม่ได้รับการแก้ไข: โซ่ที่แตกต่างกันและโซลูชันเลเยอร์ 2 ต่างๆกําลังพัฒนารายละเอียดการใช้งานที่เป็นนามธรรมของบัญชีที่แตกต่างกันซึ่งส่วนใหญ่ขัดแย้งกับ EIP-4337 เช่น zkSync Era, Starknet, Flow เป็นต้น ส่วนนี้ชิ้นส่วนกระเป๋าเงิน UX สําหรับผู้ใช้ ตัวอย่างเช่น ที่อยู่กระเป๋าเงินอัจฉริยะบน Starknet ไม่สามารถรวมเป็นหนึ่งเดียวกับที่อยู่บน Arbitrum ได้ นอกจากนี้ในสภาพแวดล้อมแบบหลายสายผู้ใช้ได้ปรับใช้บัญชีอัจฉริยะอย่างอิสระในห่วงโซ่ที่แตกต่างกันและข้อมูลผู้ใช้ที่เกี่ยวข้องมักจะกระจัดกระจายไปทั่วสัญญาเหล่านี้ หากจําเป็นต้องอัปเดตข้อมูลผู้ใช้เช่นคีย์ธุรกรรมจะต้องเริ่มต้นซ้ํา ๆ ในหลายเชนทําให้ยากต่อการรับรองความสอดคล้องของบัญชีอัจฉริยะ ก่อนหน้านี้ Vitalik ได้เสนอโซลูชันบัญชีอัจฉริยะที่รวมเป็นหนึ่งเดียวทั่วทั้งห่วงโซ่และจัดการได้ง่าย โซลูชันนี้ใช้ Ethereum หรือ ZK-Rollup ที่มีความปลอดภัยสูงเป็นห่วงโซ่ต้นทางและปรับใช้สัญญา Keystore เพื่อจัดเก็บคีย์ส่วนกลางของผู้ใช้ จากนั้นบัญชีสัญญาอัจฉริยะทั้งหมดในเลเยอร์ 2 จะแชร์คีย์ส่วนกลางที่เก็บไว้ในสัญญา Keystore

(ภาพที่มา: https://vitalik.ca/general/2023/06/20/deeperdive.html)

อย่างไรก็ตามโซลูชันนี้มีค่าใช้จ่ายจํานวนมาก เมื่อใดก็ตามที่คีย์ส่วนกลางที่บันทึกไว้ในสัญญา Keystore ในการเปลี่ยนแปลงห่วงโซ่ต้นทางแต่ละบัญชีใน L2 / ห่วงโซ่เป้าหมายจําเป็นต้องซิงโครไนซ์คีย์ใหม่ผ่านการโต้ตอบข้ามสายโซ่ ค่าโสหุ้ยของการโต้ตอบข้ามสายโซ่ระหว่าง Ethereum และ Layer 2 นั้นสูงเกินไปสําหรับผู้ใช้ที่จะแบกรับ นอกจากนี้ สิ่งสําคัญคือต้องทราบว่าบัญชีสัญญาอัจฉริยะแตกต่างจาก EOAs หลังเนื่องจากแนวทางการสร้างที่อยู่ที่เป็นเอกลักษณ์ของพวกเขาจึงรวมเป็นหนึ่งเดียวในเครือข่าย EVM หลายแห่ง แต่บัญชีสัญญาอัจฉริยะนั้นแตกต่างกันอย่างสิ้นเชิงทําให้ผู้ใช้ได้รับบัญชีสัญญาอัจฉริยะที่มีที่อยู่เดียวกันในห่วงโซ่ที่แตกต่างกัน ในการตอบสนอง Particle Network ได้เสนอวิธีการของตัวเอง ในขณะที่แนวคิดทั่วไปเกี่ยวกับวิธีการของพวกเขาสอดคล้องกับแนวคิดของ Vitalik โดยมุ่งเน้นไปที่การแยกที่เก็บข้อมูลและรหัสของบัญชีอัจฉริยะ Particle Network ตั้งใจที่จะใช้ห่วงโซ่อิสระ - Particle Network Chain - เป็นฐานข้อมูล Storage ที่สมบูรณ์สําหรับบัญชีอัจฉริยะ พวกเขาวางแผนที่จะซิงโครไนซ์การเปลี่ยนแปลงไปยังที่เก็บข้อมูลของบัญชีไปยังที่เก็บข้อมูลในเครื่องของบัญชีบนเชนอื่นๆ ผ่านโซลูชันการส่งข้อความข้ามสายโซ่ของบุคคลที่สาม (เช่น LayerZero, CCIP, Axelar, Connext เป็นต้น)

(โครงสร้างการชดเชยบัญชีหลายโซนของเครือข่ายพาร์ติเคิล)

โดยเฉพาะอย่างยิ่ง ระบบบัญชี Omnichain ของ Particle Network ช่วยให้ผู้ใช้สามารถมีที่อยู่บัญชีสมาร์ทคอนแทรกตัวเดียวกันบนเครือข่าย EVM ต่าง ๆ นี้ต้องการการนำเสนอชุดของสัญญาตัวรับผิดชอบบนเครือข่ายที่แตกต่างกัน ผู้ใช้ต้องกระตุ้นการสร้างบัญชีใหม่บน Chain ของ Particle Network และจากนั้น Particle Chain จะกระตุ้นสัญญาตัวรับผิดชอบบนทุกเครือข่ายเพื่อให้ที่อยู่บัญชีสมาร์ทคอนแทรกที่สร้างขึ้นสำหรับผู้ใช้บนเครือข่ายที่แตกต่างกันเป็นไปได้ หรือในกรณีอื่น ๆ ผู้ใช้สามารถมีปฏิสัมพันธ์กับหลายเครือข่ายผ่านสัญญาบน Particle chain โดยไม่ต้องรู้จักเครือข่ายอื่น ๆ และสามารถใช้ Unified Gas Token เป็นวิธีการชำระเงินสำหรับค่าธรรมเนียมการทำธุรกรรมได้

Omnichain Account Abstraction ยังช่วยให้การทำงานของผู้ใช้ระหว่างเชนต่างๆ ได้โดยเริ่มต้นธุรกรรมบนเชนเป้าหมายผ่านการดำเนินการของผู้ใช้และชำระ Gas ที่เกี่ยวข้องบนเชนต้นทาง ตัวอย่างเช่น สิ่งนี้ช่วยให้ผู้ใช้สามารถซื้อ NFTs บน Base โดยใช้ $USDC ของ Polygon

อย่างไรก็ตามโซลูชันของ Particle Network ต้องการการทํางานร่วมกันในระดับสูงระหว่าง Deployer Contract และส่วนประกอบการส่งข้อความข้ามสายโซ่เพื่อให้เกิดการซิงโครไนซ์บัญชีหลายสายโซ่และที่เก็บข้อมูลโซ่ต้นทาง สิ่งนี้ทําให้เกิดความต้องการที่สูงขึ้นในบริดจ์ข้อความ oracle หรือ cross-chain ที่ใช้ (ซึ่งดูเหมือนจะเป็นปัญหาทั่วไปในโซลูชันทั้งหมดที่เกี่ยวข้องกับการทํางานร่วมกันของ omnichain) อย่างไรก็ตามการซิงโครไนซ์บัญชีข้ามสายโซ่ของผู้ใช้สามารถกําหนดค่าการรวมกันของบริดจ์ข้อความที่แตกต่างกันได้อย่างยืดหยุ่นแทนที่จะพึ่งพาบริดจ์เดียว ตัวอย่างเช่นสามารถกําหนดค่าเป็นกลยุทธ์ 2/3 โดยอาศัยการยืนยันของ LayerZero, Axelar และ Connext สองตัวเพื่อยืนยันการเปลี่ยนแปลงพื้นที่เก็บข้อมูลในห่วงโซ่เป้าหมาย นี่อาจเป็นวิธีแก้ปัญหาที่เป็นไปได้สําหรับปัญหาการพึ่งพาจุดเดียว

การโต้ตอบแบบอมนิเชนไร้รอยต่อระหว่าง EVM และ non-EVM เป็นขั้นตอนถัดไปสู่การนำเสนอบัญชีแบบอมนิเชนในระบบนิเวศ Ethereum

แม้จะมีการจัดการคีย์และบัญชีแบบรวมในเครือข่าย EVM แต่ก็ยังมีพื้นที่สําหรับการเพิ่มประสิทธิภาพภายในนามธรรมบัญชี omnichain เชนที่เข้ากันไม่ได้กับ EVM เช่น Aptos, Solana, Sui ฯลฯ ไม่สามารถรับประกันได้ว่าที่อยู่บัญชีสัญญาอัจฉริยะจะสอดคล้องกับที่อยู่บนเชน EVM ยิ่งไปกว่านั้นเครือข่ายที่ไม่ใช่ EVM จะพบว่าเป็นการยากที่จะนําแนวคิดของนามธรรมบัญชีข้ามสายโซ่ที่เสนอในการอภิปรายครั้งก่อนหากพวกเขาไม่ได้ใช้โปรโตคอล ERC-4337 ด้วยโซลูชันที่เทียบเท่า นอกจากนี้ยังมีพื้นที่สําหรับการปรับปรุงภายในโครงการกระเป๋าเงินที่เข้ากันได้กับ EIP-4337 โหนด Bundler ที่ใช้โดยกระเป๋าเงินอัจฉริยะส่วนใหญ่ทํางานอย่างอิสระอย่างเป็นทางการบางครั้งแม้จะแยกออกจากกันทําให้เกิดความเสี่ยงต่าง ๆ (เช่นความเสี่ยงที่เกี่ยวข้องกับความต้านทานการเซ็นเซอร์และความพร้อมใช้งาน) การสร้างอินเทอร์เฟซส่วนหน้าแบบรวมศูนย์ที่ครอบคลุมทั่วทั้งเครือข่ายส่วนใหญ่พิสูจน์ให้เห็นว่าเป็นเรื่องที่ท้าทายอย่างมาก ทางออกหนึ่งที่เป็นไปได้คือการแนะนําการออกแบบที่เน้นความตั้งใจโดยเพิ่มเลเยอร์เพิ่มเติมนอกเหนือจากนามธรรมของบัญชี omnichain เลเยอร์นี้รวมระบบนิเวศ EIP-4337 ของ Ethereum หรือสิ่งอํานวยความสะดวกที่เป็นนามธรรมของบัญชีเนทีฟของเชนอื่น ๆ (เช่น zkSync) เป็นอินสแตนซ์เฉพาะภายใต้ประเภท Solver/Reactor โดยมีหน้าที่เลือก Solver ที่เหมาะสมเป็นความรับผิดชอบระดับบน ยกตัวอย่าง Particle Network เสนอการใช้งานที่เน้นเจตนาที่กระชับและเป็นนามธรรม โครงการนามธรรมบัญชีที่แตกต่างกันเป็นเพียงอินสแตนซ์ที่รวมอยู่ในหมวดหมู่ Solver ภายในรูปแบบความตั้งใจ ประการแรกส่วนหน้าของผู้ใช้จะเปลี่ยนคําขอภาษาธรรมชาติหรือการโต้ตอบของผู้ใช้ใด ๆ เป็นคําอธิบายทางโปรแกรมเฉพาะที่ครอบคลุมข้อ จํากัด อินพุตและเอาต์พุต (กล่าวอีกนัยหนึ่งคือเงื่อนไขที่อนุญาตให้มีอินพุตที่ตอบสนองความต้องการของผู้ใช้และผลลัพธ์เอาต์พุตที่อยู่ในช่วงเฉพาะ) ต่อจากนั้นภายในเครือข่าย Solver ธุรกรรมส่งต่อ Solver เฉพาะที่มีข้อ จํากัด อินพุตและเอาต์พุตที่แม่นยําสําหรับสัญญา Solver ที่ปรับใช้บนห่วงโซ่ (Solvers ไม่เพียง แต่ครอบคลุมโครงสร้างพื้นฐานของโหนดเท่านั้น แต่ยังรวมถึงส่วนประกอบสัญญาแบบ on-chain ด้วย) สัญญา Solver ส่งคําสั่ง Intent ไปยังสัญญา Reactor (จัดการบัญชีผู้ใช้แบบ on-chain) โดยมอบหมายให้โมดูลหลังเรียกโมดูลอื่น ๆ เพื่อตอบสนองการโต้ตอบขั้นสุดท้าย เฟรมเวิร์กนี้ช่วยให้คําขอของผู้ใช้ได้รับการประมวลผลในขั้นต้นโดยเครือข่าย Solver ซึ่งช่วยลดความจําเป็นสําหรับผู้ใช้ในการทําความเข้าใจห่วงโซ่พื้นฐานหรือรูปแบบนามธรรมของบัญชีที่แตกต่างกันซึ่งเป็นงานที่มอบหมายให้ Solver สําหรับการสร้างโซลูชันเฉพาะ อย่างไรก็ตามแนวคิดเหล่านี้ยังคงเป็นกรอบทฤษฎีโดยมีรายละเอียดการใช้งานที่รอการอธิบายเพิ่มเติมโดย Particle Network เห็นได้ชัดว่าตลาด Solver ที่มีการแข่งขันสูงจะเกิดขึ้นในอนาคตทําให้ผู้ใช้สามารถเริ่มต้นการเสนอราคาโดยที่ Solvers หลายคนเสนอโซลูชันที่แตกต่างกัน ผ่านการทําธุรกรรมจําลองในท้องถิ่นสามารถเลือกโซลูชันที่ดีที่สุดและสามารถมอบสิ่งจูงใจที่สอดคล้องกันให้กับ Solver ของพวกเขา โครงสร้างแรงจูงใจจะถูกกําหนดโดยผู้ออกแบบโปรโตคอลของเครือข่าย Solver (Particle Network มีจุดมุ่งหมายเพื่อใช้โทเค็น PNT เป็นโทเค็นจูงใจสําหรับตลาดการประมูล Solver) ในปัจจุบันสาระสําคัญของเจตนาป้องกันรายละเอียดที่ซับซ้อนของชั้นล่างและนามธรรมชั้นที่สูงขึ้น การออกแบบเลเยอร์นี้ซึ่งคล้ายกับโปรโตคอล TCP/IP เป็นสิ่งจําเป็นสําหรับการปรับปรุงทั้งประสบการณ์ผู้ใช้และประสบการณ์ของนักพัฒนาในการทํางานร่วมกันอย่างราบรื่นข้ามห่วงโซ่

ยอมรับการนำเสนอของการใช้บัญชีหลบหลี

หลังจากปรับปรุงเฟรมเวิร์ก EIP-4337 ในระบบ Ethereum จากมุมมองต่าง ๆ และเร่งการทำงานร่วมกันได้อย่างไม่มีข้อกำหนดระหว่างระบบ Ethereum และระบบ non-Ethereum เราเชื่อว่า เพื่อสนับสนุนการใช้งานทั่วไปของการดึงดูดบัญชี เรายังต้องการผลิตภัณฑ์ที่ครอบคลุมด้านการจัดหาและความต้องการ ผลิตภัณฑ์นี้ควรลดความซับซ้อนสำหรับผู้ใช้สุดท้ายที่ใช้บริการผลิตภัณฑ์ Web3 ต่าง ๆ ในขณะที่เน้นลดขีดขันการเข้าร่วมของนักพัฒนา หนึ่งในผลิตภัณฑ์ที่เหมาะสมที่สุดในการปฏิบัติหน้าที่นี้คือ Particle Network’s Modular Smart Wallet-as-a-Service Stack:

(โครงสร้างบริการตัวกระเป๋าสมาร์ทของเครือข่ายพาร์ติเคิล)

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

นอกจากคุณลักษณะที่เป็นมิตรกับนักพัฒนาที่กล่าวถึงข้างต้น จุดสำคัญที่สุดของ Modular Smart Wallet-as-a-Service stack ของ Particle Network คือ การสร้างระบบนิเวศที่เปิดสำหรับโดเมน account abstraction โดยขึ้นอยู่กับ signature computation และเน้นไปที่นักพัฒนาโดยเฉพาะ พร้อมกับโมดูลสินค้า account abstraction ภายในบริษัทของพวกเขา Particle Network รวมถึงการผนวกผสมระหว่างชนิดต่าง ๆ ของสินค้าและบริการ account abstraction นี้ช่วยเร่งการนำผลิตภัณฑ์และบริการไปใช้งานในโดเมน account abstraction ทั้งหมดสำหรับนักพัฒนา

(การออกแบบโมดูลาร์ของ Smart Wallet-as-a-Service ของ Particle Network) ให้เทคโนโลยีบริการตอบโจทย์ผู้ใช้ หลังจากแก้ไขข้อจำกัดของกรอบงาน ERC-4337 การปรับปรุงประสบการณ์ของนักพัฒนาจะทำให้ผลิตภัณฑ์เพิ่มขึ้นที่มีประสบการณ์ของผู้ใช้ยอดเยี่ยมมากขึ้น ส่งผลให้การเปลี่ยนแปลงของ Web3 จากอุตสาหกรรมการเงินที่เหมาะสำหรับคริปโพงส์ไปสู่อุตสาหกรรมที่เหมาะสำหรับผู้บริโภคมวลชนที่เร่งขึ้น

ข้อความปฏิเสธความรับผิดชอบ：

1. บทความนี้ถูกนำมาจาก [ เว็บ 3 ของนักแนว]. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [Peter Pan, ผู้ร่วมก่อตั้งและผู้อำนวยการเทคโนโลยีของเครือข่าย Particle & Faust，Geek Web3]. หากมีข้อบกพร่องต่อการพิมพ์ฉบับนี้ โปรดติดต่อGate เรียนทีม และพวกเขาจะดำเนินการโดยเร็ว
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เกิดเป็นคำแนะนำในการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่นๆ ทำโดยทีม Gate Learn ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่ถูกแปล นอกจากที่ได้ระบุไว้