การอภิปรายเชิงลึกเกี่ยวกับการออกแบบบัญชีสัญญาอัจฉริยะแบบแยกส่วน: การแก้ปัญหาทางเทคนิคในการใช้งาน

ชื่อเดิม:Modular Smart Contract Account Architecture and Challenges

ผู้เขียนต้นฉบับ: Rui S, SevenX Ventures

การรวบรวมต้นฉบับ: Deep Chao TechFlow

แนะนำ

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

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

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

AA คำอธิบายโดยย่อ

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

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

• ชั้นโปรโตคอล: โปรโตคอลบางตัวเองก็ให้การสนับสนุนการลบบัญชีในเครื่อง ธุรกรรม ZKsync ไม่ว่าจะจาก EOA หรือ SCA เป็นไปตามกระบวนการเดียวกันโดยใช้พูลหน่วยความจำเดียวและกระบวนการธุรกรรมเพื่อรองรับ AA ในขณะที่ Starknet ได้ลบ EOA และบัญชีทั้งหมดออก นั่นคือ SCA และ พวกเขามีกระเป๋าเงินสัญญาอัจฉริยะเช่น Argent

• ชั้นสัญญา: สำหรับ Ethereum และ L2 ที่เทียบเท่า ERC 4337 แนะนำรายการธุรกรรมแยกต่างหากเพื่อรองรับ AA โดยไม่ต้องเปลี่ยนชั้นฉันทามติ โปรเจ็กต์ต่างๆ เช่น Stackup, Alchemy, Etherspot, Biconomy, Candide และ Plimico กำลังสร้างโครงสร้างพื้นฐานแบบรวมกลุ่ม ในขณะที่โปรเจ็กต์อย่าง Safe, Zerodev, Etherspot และ Biconomy กำลังสร้างสแต็กและ SDK

ประเด็นขัดแย้งในการรับ SCA

หัวข้อ Account Abstraction (AA) อยู่ระหว่างการสนทนาตั้งแต่ปี 2558 และได้รับความสนใจในปีนี้โดย ERC 4337 อย่างไรก็ตาม จำนวนบัญชีสัญญาอัจฉริยะที่ใช้งานยังน้อยกว่าจำนวน EOA มาก

มาเจาะลึกลงไปในภาวะที่กลืนไม่เข้าคายไม่ออกนี้:

• ผลกระทบของตลาดหมี:

แม้ว่า AA จะแนะนำคุณประโยชน์ต่างๆ เช่น การเข้าสู่ระบบที่ราบรื่นและ Gas abstraction แต่ผู้คนในปัจจุบันที่ประสบปัญหาตลาดหมีนั้นส่วนใหญ่ประกอบด้วยผู้ใช้ EOA ที่มีการศึกษามากกว่าผู้ใช้ใหม่ ดังนั้นจึงไม่มีแรงจูงใจสำหรับ dApps และ wallets ถึงกระนั้น แอปพลิเคชันชั้นนำบางแอปพลิเคชันก็ค่อยๆ นำ AA มาใช้ เช่น Cyberconnect ซึ่งกระตุ้น UserOps (ธุรกรรม AA) ประมาณ 360,000 รายการในเวลาเพียงเดือนเดียวด้วยการเปิดตัวระบบ AA และโซลูชันไร้ก๊าซ

• อุปสรรคต่อการย้ายถิ่น:

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

• ปัญหาลายเซ็น:

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

• ค่าใช้จ่ายก๊าซ:

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

• ปัญหาทางวิศวกรรม:

ทีม ERC-4337 ได้สร้างพื้นที่เก็บข้อมูล eth-infinitiism เพื่อให้นักพัฒนาใช้งานขั้นพื้นฐานได้ อย่างไรก็ตาม เมื่อเราแยกออกเป็นฟังก์ชันที่ละเอียดหรือเฉพาะเจาะจงมากขึ้นในกรณีการใช้งานที่แตกต่างกัน การบูรณาการและการถอดรหัสจะกลายเป็นเรื่องท้าทาย

ในบทความนี้ เราจะเจาะลึกประเด็นที่ห้า: ความท้าทายทางวิศวกรรม

บัญชีสัญญาอัจฉริยะแบบแยกส่วนเพื่อแก้ไขความท้าทายทางวิศวกรรม

คำอธิบายเพิ่มเติมเกี่ยวกับความท้าทายทางวิศวกรรมมีดังนี้:

• การกระจายตัว: ขณะนี้ฟีเจอร์ต่างๆ ได้รับการเปิดใช้งานในรูปแบบที่แตกต่างกัน ไม่ว่าจะผ่าน SCA ที่เฉพาะเจาะจงหรือระบบปลั๊กอินอิสระ แต่ละอันเป็นไปตามมาตรฐานของตัวเอง ทำให้นักพัฒนาต้องตัดสินใจว่าจะรองรับแพลตฟอร์มใด สิ่งนี้สามารถนำไปสู่การล็อคแพลตฟอร์มหรือความพยายามที่ซ้ำซ้อน

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

• ความสามารถในการอัปเกรด: เมื่อฟังก์ชันการทำงานพัฒนาขึ้น สิ่งสำคัญคือต้องรักษาความสามารถในการเพิ่ม แทนที่ หรือลบฟังก์ชันการทำงาน การปรับใช้ฟังก์ชันการทำงานที่มีอยู่ใหม่ทุกครั้งที่มีการอัปเดตทำให้เกิดความซับซ้อน

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

คำเหล่านี้มาบรรจบกันบนแนวคิดทั่วไป: การสร้างสถาปัตยกรรมนามธรรมบัญชีแบบแยกส่วน (Modular AA)

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

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

โครงสร้างโมดูลาร์: บัญชีหลักและโมดูล

มอบหมายการโทรและสัญญาพร็อกซี

การโทรภายนอกและการโทรแบบมอบหมาย:

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

ในการใช้โครงสร้างที่ประกอบได้และอัปเกรดได้ จำเป็นต้องมีความรู้พื้นฐานที่เรียกว่า สัญญาตัวแทน

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

• กรณีการใช้งาน: แม้ว่าสัญญาพร็อกซีจะยังคงเหมือนเดิม คุณสามารถปรับใช้การใช้งานใหม่หลังพร็อกซีได้ สัญญาพร็อกซีใช้สำหรับการอัพเกรดและมีราคาถูกกว่าในการปรับใช้และบำรุงรักษาบนบล็อกเชนสาธารณะ

สถาปัตยกรรมความปลอดภัย

Safe เป็นโครงสร้างพื้นฐานบัญชีอัจฉริยะแบบโมดูลาร์ชั้นนำที่ออกแบบมาเพื่อมอบความปลอดภัยและความยืดหยุ่นที่ได้รับการพิสูจน์แล้ว ช่วยให้นักพัฒนาสามารถสร้างแอปพลิเคชันและกระเป๋าเงินที่หลากหลาย เป็นที่น่าสังเกตว่าหลายทีมกำลังสร้างทีมเพิ่มเติมจากหรือได้รับแรงบันดาลใจจาก Safe Biconomy เปิดตัวบัญชีโดยขยาย 4337 แบบเนทีฟและ 1/1 หลายลายเซ็นบน Safe ด้วยสัญญาใช้งานมากกว่า 164,000 สัญญาและการล็อคมูลค่ามากกว่า 30.7 พันล้านดอลลาร์ Safe จึงเป็นตัวเลือกอันดับต้นๆ ในด้านนี้อย่างไม่ต้องสงสัย

โครงสร้างที่ปลอดภัย

• สัญญาบัญชีปลอดภัย: สัญญาตัวแทนหลัก (เก็บสถานะ)

บัญชี Safe เป็นสัญญาพร็อกซีเนื่องจากจะมอบหมายให้เรียกสัญญาแบบซิงเกิลตัน บัญชี Safe ประกอบด้วยเจ้าของ เกณฑ์ และที่อยู่การใช้งาน ซึ่งถูกกำหนดเป็นตัวแปรสำหรับตัวแทน ซึ่งเป็นการกำหนดสถานะ

• สัญญาซิงเกิลตัน: ศูนย์บูรณาการ (ไร้สัญชาติ)

singleton ทำหน้าที่บัญชี Safe และผสานรวมและกำหนดการบูรณาการต่างๆ รวมถึงปลั๊กอิน hooks ตัวจัดการฟังก์ชัน และผู้ตรวจสอบลายเซ็น

• สัญญาโมดูล: ตรรกะและฟังก์ชันที่กำหนดเอง

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

จะเกิดอะไรขึ้นเมื่อเรานำ Safe มาใช้

• สัญญาที่อัปเกรดได้:

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

• โมดูลที่ประกอบและนำกลับมาใช้ใหม่ได้:

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

ERC-2535 ตัวแทนเพชร

เกี่ยวกับ ERC 2535 และ Diamond Agent

ERC 2535 สร้างมาตรฐานให้กับ Diamond Agent ซึ่งเป็นระบบสัญญาอัจฉริยะแบบแยกส่วนที่สามารถอัปเกรด/ขยายได้หลังการใช้งาน และแทบไม่มีข้อจำกัดด้านขนาด จนถึงตอนนี้ หลายทีมได้รับแรงบันดาลใจจากสิ่งนี้ เช่น การทดลองของ Kernel และ Soul Wallet ของ Zerodev

โครงสร้างของเพชรคืออะไร?

• สัญญาเพชร: สัญญาพร็อกซีหลัก (สถานะ) ไดมอนด์เป็นสัญญาพร็อกซีที่เรียกใช้ฟังก์ชันจากการนำไปใช้งานผ่านการโทรแบบมอบหมาย

• โมดูล/ปลั๊กอิน/สัญญาเหลี่ยมเพชรพลอย: ตรรกะที่กำหนดเองและฟังก์ชันการทำงาน (ไร้สถานะ) โมดูลหรือสิ่งที่เรียกว่า facet คือสัญญาไร้สถานะที่สามารถปรับใช้ฟังก์ชันการทำงานกับเพชรหนึ่งเม็ดขึ้นไป เป็นสัญญาอิสระที่สามารถแชร์ฟังก์ชันภายใน ไลบรารี และตัวแปรสถานะได้

จะเกิดอะไรขึ้นเมื่อเราใช้ไดมอนด์

• สัญญาที่อัปเกรดได้: Diamond มอบวิธีการที่เป็นระบบในการแยกปลั๊กอินต่างๆ และเชื่อมต่อเข้าด้วยกัน และเพิ่ม/แทนที่/ลบปลั๊กอินใดๆ โดยตรงผ่านฟังก์ชัน diamondCut ไม่มีการจำกัดจำนวนปลั๊กอินที่สามารถเพิ่มลงใน Diamond เมื่อเวลาผ่านไป

• ปลั๊กอินแบบโมดูลาร์และแบบใช้ซ้ำได้: Diamonds จำนวนเท่าใดก็ได้สามารถใช้ปลั๊กอินที่ปรับใช้ได้ ซึ่งจะช่วยลดต้นทุนการใช้งานได้อย่างมาก

ความแตกต่างระหว่างบัญชี Safe Smart และวิธี Diamond

มีความคล้ายคลึงกันหลายประการระหว่างสถาปัตยกรรม Safe และ Diamond โดยทั้งคู่อาศัยสัญญาพร็อกซีเป็นแกนหลักและอ้างอิงสัญญาลอจิกสำหรับการอัปเกรดและความเป็นโมดูล

อย่างไรก็ตาม ข้อแตกต่างหลักอยู่ที่การจัดการสัญญาเชิงตรรกะ คำแนะนำโดยละเอียดเพิ่มเติมมีดังนี้:

• ความยืดหยุ่น: เมื่อเปิดใช้งานปลั๊กอินใหม่ Safe จำเป็นต้องปรับใช้สัญญาแบบซิงเกิลตันใหม่เพื่อใช้การเปลี่ยนแปลงในตัวแทน ในทางตรงกันข้าม Diamond ทำสิ่งนี้โดยตรงผ่านฟังก์ชัน diamondCut ในผู้รับมอบสิทธิ์ วิธีการที่แตกต่างกันนี้หมายความว่า Safe ยังคงรักษาระดับการควบคุมที่สูงกว่า ในขณะที่ Diamond นำเสนอความยืดหยุ่นและความเป็นโมดูลที่มากขึ้น

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

• ต้นทุน: ความยืดหยุ่นที่มีอยู่ในแนวทาง Diamond มาพร้อมกับข้อกังวลด้านความปลอดภัยที่เพิ่มขึ้น สิ่งนี้จะเพิ่มปัจจัยด้านต้นทุนและต้องมีการตรวจสอบเต็มรูปแบบทุกครั้งที่มีการเพิ่มปลั๊กอินใหม่ สิ่งสำคัญคือต้องแน่ใจว่าปลั๊กอินเหล่านี้จะไม่รบกวนการทำงานของกันและกัน ซึ่งอาจเป็นเรื่องท้าทายสำหรับธุรกิจขนาดเล็กและขนาดกลางที่พยายามรักษามาตรฐานความปลอดภัยที่แข็งแกร่ง

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

ลำดับโมดูล: เครื่องมือตรวจสอบ ผู้ดำเนินการ และ hooks

ให้เราขยายการสนทนาของเราโดยแนะนำมาตรฐานที่เสนอโดยทีม Alchemy ERC 6900 ซึ่งได้รับการแรงบันดาลใจจาก Diamond และดัดแปลงเป็นพิเศษสำหรับ ERC-4337 ช่วยแก้ปัญหาความท้าทายด้านโมดูลาร์ในบัญชีอัจฉริยะโดยจัดให้มีอินเทอร์เฟซทั่วไปและประสานงานการทำงานระหว่างนักพัฒนาปลั๊กอินและกระเป๋าสตางค์

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

• การยืนยัน: ตรวจสอบความถูกต้องและอำนาจของบัญชีของผู้โทร

• การดำเนินการ: ดำเนินการตรรกะที่กำหนดเองใด ๆ ที่อนุญาตโดยบัญชี

• Hook: เป็นโมดูลที่ทำงานก่อนหรือหลังฟังก์ชันอื่น สามารถแก้ไขสถานะหรือทำให้การโทรทั้งหมดถูกยกเลิก

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

การค้นพบโมดูลและความปลอดภัย

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

ปลอดภัย {Core} โปรโตคอล

Safe{Core} Protocol เป็นโปรโตคอลบัญชีสัญญาอัจฉริยะแบบโอเพ่นซอร์สที่ทำงานร่วมกันได้ ซึ่งออกแบบมาเพื่อเพิ่มการเข้าถึงสำหรับผู้ขายและนักพัฒนาที่หลากหลายผ่านมาตรฐานและกฎเกณฑ์ที่กำหนดไว้อย่างชัดเจน ขณะเดียวกันก็รักษาความปลอดภัยที่แข็งแกร่ง

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

• ผู้จัดการ: ผู้จัดการทำหน้าที่เป็นผู้ประสานงานระหว่างบัญชี รีจิสทรี และโมดูล นอกจากนี้ยังรับผิดชอบด้านความปลอดภัยโดยทำหน้าที่เป็นชั้นสิทธิ์

• รีจิสทรี: รีจิสทรีกำหนดคุณลักษณะด้านความปลอดภัยและบังคับใช้มาตรฐานโมดูล เช่น ERC 6900 โดยมีเป้าหมายเพื่อสร้างสภาพแวดล้อม app store แบบเปิดสำหรับการค้นพบและความปลอดภัย

• โมดูล: โมดูลจัดการฟังก์ชันการทำงานและมีให้ในประเภทเริ่มต้นที่หลากหลาย รวมถึงปลั๊กอิน Hooks เครื่องมือตรวจสอบลายเซ็น และตัวจัดการฟังก์ชัน นักพัฒนาซอฟต์แวร์สามารถมีส่วนร่วมได้ตราบใดที่มีคุณสมบัติตรงตามมาตรฐานที่กำหนด

Rhinestone Design

กระบวนการเกิดขึ้นดังนี้:

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

• สร้างโมดูลตามรูปแบบ: สัญญาอัจฉริยะได้รับการลงทะเบียนเป็นโมดูล รับรหัสไบต์ และเลือกรหัสรูปแบบ ข้อมูลนี้จะถูกเก็บไว้ในรีจิสทรีแล้ว

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

• ใช้ตัวแยกวิเคราะห์เพื่อใช้ตรรกะที่ซับซ้อน: ตัวแยกวิเคราะห์จะถูกตั้งค่าหรือไม่ก็ได้ในสคีมา สามารถเรียกได้ในระหว่างการสร้างโมดูล การสร้างหลักฐาน และการรื้อถอน ตัวแยกวิเคราะห์เหล่านี้ช่วยให้นักพัฒนาสามารถรวมตรรกะที่ซับซ้อนและหลากหลายในขณะที่ยังคงรักษาโครงสร้างของการพิสูจน์ไว้

• การเข้าถึงแบบสอบถามที่เป็นมิตรต่อผู้ใช้: แบบสอบถามให้วิธีสำหรับผู้ใช้ในการเข้าถึงข้อมูลที่ปลอดภัยจากส่วนหน้า EIP สามารถพบได้ที่นี่

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

• ผู้รับรอง: หน่วยงานที่เชื่อถือได้ เช่น Safe สามารถทำงานร่วมกับ Rhinestone ในฐานะผู้รับรองสำหรับโมดูลภายในได้ ในขณะเดียวกัน นักพิสูจน์อิสระก็สามารถเข้าร่วมได้เช่นกัน

• นักพัฒนาโมดูล: ด้วยตลาดที่เปิดกว้าง นักพัฒนาโมดูลจึงสามารถนำงานของตนไปขายในเชิงพาณิชย์ผ่านทางทะเบียนได้

• ผู้ใช้: ผ่านอินเทอร์เฟซที่เป็นมิตรต่อผู้ใช้ เช่น กระเป๋าเงินหรือ dApps ผู้ใช้สามารถดูข้อมูลโมดูลและมอบความไว้วางใจให้กับผู้พิสูจน์ต่างๆ

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

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

สรุป

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

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

เรามองเห็นอนาคตด้วยการมีส่วนร่วมในวงกว้าง ซึ่งทำให้เกิดคำถามที่น่าสนใจ: เมื่อกระบวนการสั่งซื้อ SCA มีผลกำไรเพียงพอ กลไก Miner Extractable Value (MEV) แบบดั้งเดิมจะเข้าสู่พื้นที่ สร้าง Bundlers และจับมูลค่าได้อย่างไร เมื่อโครงสร้างพื้นฐานครบกำหนด Account Abstraction (AA) จะกลายเป็นฐานสำหรับธุรกรรม ตามเจตนา ได้อย่างไร โปรดติดตามเนื่องจากพื้นที่นี้มีการพัฒนาอย่างต่อเนื่อง