TL;DR

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

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

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

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

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

แนวคิดการสรุปบัญชีมีจุดมุ่งหมายที่จะปรับปรุงจากโครงสร้างพื้นฐานของบัญชีสมาร์ทคอนแทรค เป็นการเตรียมทางสำหรับระบบบัญชีอัจฉริยะรุ่นต่อไป

อย่างไรก็ตาม หากเรามองไปที่ข้อเสนอเชิงนามธรรมบัญชีจริง ๆ เราจะพบว่าจุดมุ่งหมายของพวกเขาไม่ได้อยู่ที่โมเดลบัญชีเอง ตัวอย่างเช่น ข้อเสนอที่เกี่ยวข้องกับการสรุปบัญชี เช่น EIP-86, EIP-4337, และ EIP-6900 มุ่งที่การสรุป/ทำเป็นโมดูลกระบวนการทั้งหมดของธุรกรรมตั้งแต่ขั้นตอนเริ่มต้นจนถึงการได้รับโดยโหนด การตรวจสอบลายเซ็น, การชำระค่าGas เป็นต้น, แทนที่จะมุ่งในการสรุปโครงสร้างบัญชีอย่างแท้จริง ดังนั้น ดูเหมือนจะเหมาะสมกว่าที่จะอ้างถึงข้อเสนอเหล่านี้ว่า “การสรุปธุรกรรม”

หากเราเข้าใจข้อเสนอที่เป็นที่รู้จักเกี่ยวกับแนวคิดการสรุปบัญชีจากมุมมองของ "การสรุปกระบวนการประมวลผลธุรกรรม" เราสามารถเข้าใจจุดสำคัญของพวกเขาได้ง่ายขึ้น: การสรุปธุรกรรมประเภทนี้จริง ๆ มีจุดประสงค์เพื่อนำประสบการณ์ของผู้ใช้ระดับ Web2 เข้าสู่ระบบ Ethereum และการใช้ผลิตภัณฑ์ได้ง่ายขึ้น เช่น บัญชีดำ / บัญชีขาว ธุรกรรมที่เริ่มต้นภายในระยะเวลาโดยไม่ต้องการการตรวจสอบตัวตน ธุรกรรมฟรีจากค่าแก๊ส การชำระค่าธรรมเนียมด้วยสกุลเงินเงินบาท ฯลฯ

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

ความเป็นธรรมของ EIP-4337: แนวคิดการสรุปบัญชีเป็นสิ่งที่เหมาะสมในระบบ Ethereum

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

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

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

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

ในที่สุด EIP-4337 ปรากฏออกมา

EIP-4337 เป็น solusi optimal lokal, แต่มีมุมมองหลายองค์ในโครงสร้างที่ต้องการการปรับปรุงด่วน

EIP-4337 กำหนดชุดมาตรฐานอินเตอร์เฟซที่สมบูรณ์ โดยแจ้งชัดเจนว่าโมดูลใดที่กระเป๋าเงินสมาร์ทที่ปฏิบัติตามโปรโตคอล 4337 ควรมี และฟังก์ชัน/อินเตอร์เฟซแต่ละโมดูลควรดำเนินการ เช่น ผู้รวบรวม, ทางเข้า, และผู้จ่ายเงิน และฟังก์ชันที่เรียกใช้จากส่วนประกอบเหล่านี้ควรให้บริการ

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

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

อย่างไรก็ตาม EIP-4337 ยังมีปัญหาอีกมากมายที่ยังไม่ได้แก้ไข เช่น

1. ความสามารถของแนวคิดการสรุปบัญชีไม่เพียงพอที่จะเป็น plug-and-play อย่างเพียงพอทำให้ง่ายต่อนักพัฒนาที่แตกต่างกันที่จะสร้างสรรค์ใหม่

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

3. ระบบ account abstraction ที่แยกส่วนกันอย่างมากระหว่างเครือข่ายที่แตกต่างกัน ทำให้ยากต่อการให้ประสบการณ์ที่สมบูรณ์แบบและมีคุณภาพสูงให้กับผู้ใช้สุดท้ายและนักพัฒนา เพื่อให้ได้ประสบการณ์ UX ที่ดีขึ้น

ในส่วนถัดไป เราจะพูดถึงวิธีการแก้ปัญหาเหล่านี้

ทิศทางการปรับปรุงหนึ่ง: ความสามารถในการติดตั้งและใช้งานโมดูลของแนวคิดการสรุปบัญชีจะกลายเป็นการกำหนดค่าพื้นฐาน

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

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

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

เวอร์ชัน V2 ของ Biconomy โดยใช้ EIP-4337 เป็นกรอบโปรโตคอลได้กำหนดมาตรฐานที่ละเอียดมากขึ้นและเพิ่มอินเทอร์เฟซเป็นชุดที่ไม่ได้กล่าวถึงใน 4337 อย่างชัดเจน โดยระบุความสามารถที่ Bundler, Smart Contract Wallet, Paymaster, และโมดูลอื่น ๆ ควรมี Biconomy อนุญาตให้นักพัฒนาบุคคลที่สามสามารถที่จะปฏิบัติตามกฎกำหนดล่วงหน้าโดย Biconomy (เข้ากันได้กับ EIP-4337) โดยมีรายละเอียดของโค้ดที่แตกต่างกัน แต่มีคุณสมบัติที่คล้ายกันและเวอร์ชันที่แตกต่างกัน

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

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

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

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

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

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

EIP-6900 ระบุว่าปัญหาปัจจุบันของการสรุปบัญชีแบบโมดูลได้แก้ปัญหา “การแตกแยก” หรือ “ปัญหาเกาะ” ของบัญชี เช่น ในขณะที่ผู้ให้บริการโมดูลการสรุปบัญชีหรือแอปพลิเคชัน DApp ที่แตกต่างกันอาจเข้ากันได้กับ EIP-4337 ระดับการสรุปของ EIP-4337 สำหรับโมดูลที่แตกต่างกันไม่มีความสูงพอ และละเอียดไม่เพียงพอ นี่ทำให้เหลือ “เสรี” แก่นักพัฒนาโมดูลบัญชีอัจฉริยะ (บัญชีอัจฉริยะเก็บข้อมูลผู้ใช้และบันทึกส่วนสำคัญของการตรวจสอบธุรกรรมและตรวจสอบตราบันทึกแก๊ส)

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

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

หลังจากนำแนวคิดจาก EIP-6900 มาใช้ whitepaper ของ Safe Core Protocol ได้ทำการปรับปรุงเพิ่มเติมในส่วนของ Smart Account (บัญชีกระเป๋าสมาร์ทคอนแทรคของผู้ใช้) อย่างละเอียดมากขึ้น Safe Core Protocol แบ่งแต่ละโมดูลที่เรียกใช้ของบัญชีกระเป๋าสมาร์ทคอนแทรคเป็นหมวดหมู่ต่าง ๆ เช่น ปลั๊กอิน, ฮุค, ตัวตรวจสอบลายเซ็น, และตัวประมวลผลฟังก์ชัน

โมดูลบัญชีสมาร์ทถูกสร้างให้มีน้ำหนักเบาที่สุดเท่าที่จะทำได้ โดยที่สัญญาบัญชีเก็บข้อมูลและฟังก์ชันพื้นฐานเท่านั้น ในขณะที่ฟังก์ชันที่สามารถเคลื่อนย้ายไปด้านนอกถูกนำมาปฏิบัติโดยโมดูลที่เชี่ยวชาญเช่น “ตัวประมวลผลฟังก์ชัน” หรือ “ปลั๊กอิน” นี้เข้ากับหลักการของ Occam’s Razor: “Entities should not be multiplied unnecessarily.”

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

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

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

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

เส้นทางการปรับปรุงที่สาม: การสรุปบัญชีรวมกันในเครือข่ายต่าง ๆ เพื่อให้บัญชีเหมือนกันบนเครือข่ายต่าง ๆ

อย่างไรก็ตาม แม้จะมีการแก้ไขดังกล่าว ยังคงมีปัญหาที่ยังไม่ได้แก้: โซลูชั่นต่าง ๆ ยังคงก้าวหน้าด้วยวิธีการสรุปบัญชีที่แตกต่างกันในโซลูชั่นชั้นที่ 2 หลายแบบที่ขัดแย้งกัน โดยมีหลายตัวอย่างที่ขัดแย้งกับ EIP-4337 เช่น zkSync Era, Starknet, Flow, เป็นต้น ความแตกแยกนี้ใน UX ของกระเป๋าเงิน เช่น ทำให้เป็นไปไม่ได้ที่จะรวมที่อยู่กระเป๋าเงินอัจฉริยะของผู้ใช้บน Starknet กับอย่างที่อยู่บน Arbitrum

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

วิทาลิคเองเสนอแนวคิดการสรุปบัญชีอัจฉริยะที่สามารถจัดการได้อย่างเรียบง่ายทั่วทุกซี้ยบบายส์มีวิธีการใช้ Ethereum หรือ ZKRollup ที่ปลอดภัยมากเป็นซอร์สเชนการใช้งาน Keystore contract เพื่อเก็บกุญแจโกลบอลของผู้ใช้และจากนั้นบัญชีสมาร์ทคอนแทรคต่าง ๆ บนเลเยอร์ 2 จะแชร์กุญแจโกลบอลที่เก็บไว้ในสัญญา Keystore

อย่างไรก็ตามโซลูชันนี้มาพร้อมกับค่าใช้จ่ายที่สูงมาก เมื่อใดก็ตามที่มีการเปลี่ยนแปลงคีย์ส่วนกลางที่บันทึกโดยสัญญา Keystore บนห่วงโซ่ต้นทางแต่ละบัญชีในห่วงโซ่ L2 / เป้าหมายจําเป็นต้องซิงโครไนซ์คีย์ใหม่ผ่านการโต้ตอบข้ามสาย อย่างไรก็ตามค่าใช้จ่ายในการโต้ตอบข้ามสายโซ่ระหว่าง Ethereum และ L2 นั้นสูงเกินไปสําหรับผู้ใช้ที่จะจ่ายได้ นอกจากนี้ สิ่งสําคัญคือต้องทราบว่าบัญชีสัญญาอัจฉริยะแตกต่างจากบัญชี EOA ในขณะที่วิธีหลังเนื่องจากวิธีการสร้างที่อยู่ที่ไม่ซ้ํากันนั้นรวมเป็นหนึ่งเดียวในหลายเชน (ภายในระบบนิเวศ EVM) บัญชีสัญญาอัจฉริยะนั้นแตกต่างกันอย่างสิ้นเชิงทําให้ผู้ใช้ได้รับบัญชีสัญญาอัจฉริยะที่มีที่อยู่เดียวกันในห่วงโซ่ที่แตกต่างกันได้ยาก

เพื่อตอบสนองต่อสิ่งนี้ ระบบเครือข่าย Particle มีแนวการทำงานของตัวเอง แม้ว่าแนวคิดทั่วๆ ไปจะสอดคล้องกับแนวคิดของ Vitalik ในการแยกการเก็บรักษาและรหัสของบัญชีอัจฉริยะ ระบบเครือข่าย Particle วางแผนที่จะใช้โซ่แยกออกเป็นโซ่เต็ม Particle Network Chain เป็นฐานข้อมูลการเก็บรักษาเต็มรูปแบบสำหรับบัญชีอัจฉริยะ ผ่านการใช้โซลูชันการส่งข้อความระหว่างโซ่ข้ามโซ่ของบุคคลที่สาม (เช่น LayerZero, CCIP, Axelar, Connext เป็นต้น) ระบบเครือข่าย Particle ตั้งใจที่จะซิงโครไนซ์การเปลี่ยนแปลงของการเก็บรักษาของบัญชีไปยังบัญชีท้องถิ่นของโซ่อื่นๆ

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

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

การสรุปบัญชีเชื่อมโยงทั้งหมดยังทำให้ Cross-Chain User Operations เป็นไปได้ ทำให้ผู้ใช้สามารถเรียกใช้การทำธุรกรรมบนโซนเป้าหมายผ่าน User Operations และชำระ gas ที่เกี่ยวข้องบนโซนต้นทาง ตัวอย่างเช่น มันช่วยให้ซื้อ NFTs บน Base โดยใช้ USDC ของ Polygon ได้

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

อย่างไรก็ตาม การซิงโครไนซ์บัญชีระหว่างโซนสามารถกำหนดค่าได้อย่างยืดหยุ่นด้วยส่วนประกอบของทางส่งข้อความที่แตกต่างกัน แทนที่จะพึ่งพาบนส่วนประกอบเดียว ตัวอย่างเช่น สามารถกำหนดค่าด้วยนโยบาย 2/3 ที่การเปลี่ยนแปลงไปยังการเก็บรักษาบนโซนเป้าหมายจะได้รับการยืนยันเท่านั้นหลังจากที่ LayerZero, Axelar, หรือ Connext ยืนยันการเปลี่ยนแปลง ซึ่งสามารถลดปัญหาของการพึ่งพาจุดเดียว

ความสามารถในการทำงานร่วมกันได้อย่างไม่มีขั้นตอนทั้งในเครือข่าย EVM และ non-EVM แทนที่เป็นก้าวสำคัญในแนวคิดการสรุปบัญชีรายละเอียดภายในนิวเทรียม. แม้ว่ามีความคืบหน้าในการจัดการกับกุญแจสำคัญและบัญชียูไนเฟิดในเครือข่าย EVM อย่างไรก็ตามยังมีที่ว่างสำหรับการปรับปรุงในแนวคิดการสรุปบัญชีรายละเอียดภายในทั้งหมด. โซ่ที่ไม่รองรับ EVM เช่น Aptos, Solana และ Sui, ไม่สามารถรับประกันความสอดคล้องของที่อยู่บัญชีสัญญาฉลาดที่สร้างขึ้นโดยผู้ใช้กับบนโซ่ EVM. อย่างนั้นโซ่ non-EVM อาจต้องพยายามนำแนวคิดการสรุปบัญชีรายละเอียดภายในทั้งหมดที่ได้รับการเสนอโดย Vitalik และ Particle Network โดยที่ไม่ต้องนำเสนอโซลูชันเทียบเท่ากับโปรโตคอล EIP-4337.

นอกจากนี้ยังมีที่ว่างสําหรับการปรับปรุงโครงการกระเป๋าเงินที่เข้ากันได้กับ EIP-4337 กระเป๋าเงินอัจฉริยะส่วนใหญ่ใช้โหนด Bundler ที่ดําเนินการอย่างอิสระโดยแพลตฟอร์มที่เกี่ยวข้องซึ่งมักจะไม่เชื่อมต่อกัน การแยกตัวนี้ก่อให้เกิดความเสี่ยงเช่นการต่อต้านการเซ็นเซอร์และความพร้อมใช้งาน การสร้างอินเทอร์เฟซส่วนหน้าแบบรวมในเครือข่ายส่วนใหญ่จะเป็นเรื่องที่ท้าทายอย่างยิ่ง แนวทางหนึ่งในการแก้ไขปัญหานี้คือการแนะนําการออกแบบที่เน้นความตั้งใจโดยเพิ่มเลเยอร์ด้านบนของนามธรรมบัญชีแบบเต็มห่วงโซ่การรักษาระบบนิเวศ EIP-4337 ของ Ethereum หรือสิ่งอํานวยความสะดวกที่เป็นนามธรรมของบัญชีดั้งเดิมของเชนอื่น ๆ (เช่น zkSync) เป็นอินสแตนซ์เฉพาะภายใต้หมวดหมู่ Solver / Reactor โดยการเลือก Solvers ที่เหมาะสมเป็นงานระดับสูง

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

ขั้นแรกอินเทอร์เฟซผู้ใช้มีหน้าที่แปลคําขอภาษาธรรมชาติหรือการโต้ตอบของผู้ใช้ใด ๆ เป็นคําอธิบายทางโปรแกรมเฉพาะซึ่งรวมถึงข้อ จํากัด อินพุตและข้อ จํากัด เอาต์พุต (กล่าวอีกนัยหนึ่งคือเงื่อนไขสําหรับอินพุตและช่วงที่ยอมรับได้สําหรับผลลัพธ์เอาต์พุตที่ยอมรับได้) ต่อจากนั้น Solvers อย่างน้อยหนึ่งรายการในเครือข่าย Solver จะส่งต่อธุรกรรมที่มีข้อ จํากัด อินพุต - เอาต์พุตเฉพาะไปยังสัญญา Solver ที่ปรับใช้บนห่วงโซ่ (Solver ไม่เพียง แต่ครอบคลุมสิ่งอํานวยความสะดวกโหนดเท่านั้น แต่ยังรวมถึงส่วนประกอบสัญญาแบบ on-chain ด้วย) สัญญา Solver จะส่งคําแนะนําเจตนาไปยังสัญญาเครื่องปฏิกรณ์ (ซึ่งจัดการบัญชีแบบ on-chain ของผู้ใช้) โดยมอบหมายการดําเนินการเพื่อให้การโต้ตอบขั้นสุดท้ายเสร็จสมบูรณ์

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

แน่นอนว่าแนวคิดเหล่านี้เป็นเพียงกรอบทฤษฎีและรายละเอียดการใช้งานยังอยู่ระหว่างการปรับใช้อย่างเป็นทางการโดย Particle Network สิ่งที่ชัดเจนคือจะมีตลาด Solver ที่มีการแข่งขันสูงในอนาคตอย่างหลีกเลี่ยงไม่ได้ซึ่งผู้ใช้สามารถเริ่มการประมูลสําหรับ Solvers หลายตัวเพื่อเสนอโซลูชันที่แตกต่างกัน ผ่านธุรกรรมจําลองในท้องถิ่นสามารถเลือกโซลูชันที่ดีที่สุดและ Solver ที่เกี่ยวข้องสามารถได้รับรางวัลได้ สําหรับรูปแบบของสิ่งจูงใจนั้นขึ้นอยู่กับการพิจารณาของผู้ออกแบบโปรโตคอลของเครือข่าย Solver (Particle Network ตั้งใจที่จะใช้โทเค็น PNT เป็นสิ่งจูงใจสําหรับตลาดการประมูล Solver)

ความตั้งใจปัจจุบันในทางประการที่ดีมีหน้าที่ปกป้องรายละเอียดที่ซับซ้อนด้านล่างและทำให้มีการสรุปในชั้นที่สูงขึ้น การออกแบบชั้นลอยนั้นเหมือนกับโปรโตคอล TCP/IP ที่จำเป็นสำหรับทั้งประสบการณ์ของผู้ใช้และนักพัฒนาในการให้การทำงานร่วมกันได้โดยไม่มีข้อบกพร่อง

ยอมรับการใช้แนวคิดการสรุปบัญชีอย่างแพร่หลาย

เมื่อเราทำให้โครงสร้าง 4337 ภายในระบบนิเวศ Ethereum มีประสิทธิภาพจากมุมมองต่าง ๆ พร้อมกัน และส่งเสริมความสามารถในการทำงานร่วมกันอย่างไม่มีข้อกังวลระหว่างระบบ Ethereum และระบบ non-Ethereum เพื่อสนับสนุนการใช้แนวคิดการสรุปบัญชีอย่างแพร่หลาย เราเชื่อว่ายังมีความจำเป็นที่จะต้องมีผลิตภัณฑ์ที่ครอบคลุมทั้งด้านการจัดหาและด้านการต้องการ มันไม่เพียงแค่ลดข barrier สำหรับผู้ใช้ท้ายระบบในการใช้บริการผลิตภัณฑ์ Web3 ต่าง ๆ แต่ยังเน้นในการลดความยากลำบากสำหรับนักพัฒนาบริการ

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

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

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

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

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

1. บทความนี้ถูกพิมพ์ซ้ำจาก[เว็บไซต์ Tencent], All copyrights belong to the original author [Peter Pan, ผู้ก่อตั้งและหัวหน้าฝ่ายเทคโนโลยีของ Particle Network & Faust, นักพัฒนาเว็บ3ที่มีความคิดเชิงเทคโนโลยี]. หากมีข้อแก้เลี่ยงต่อการพิมพ์ซ้ำนี้ กรุณาติดต่อเกต เรียนทีมของเรา และพวกเขาจะดำเนินการต่อไปอย่างรวดเร็ว
2. คำปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่มีเจตนาที่จะให้คำแนะนำทางด้านการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นๆ นำมาทำโดยทีม Gate Learn หากไม่ได้กล่าวถึง การคัดลอก การกระจาย หรือการลอกเลียนแบบบทความที่ถูกแปลนั้นถือเป็นการละเมิด