แนะนำสกุลเงิน

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

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

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

หลังจากอ่านบทความนี้ ผู้อ่านจะได้รับข้อมูลเชิงลึกเกี่ยวกับ:

1. นามธรรมบัญชีแบบแยกส่วนคืออะไร
2. บัญชีโต้ตอบกับโมดูลอย่างไร
3. ลำดับการเรียกโมดูลคืออะไร
4. วิธีค้นหาและตรวจสอบโมดูลแบบเปิด

บทวิจารณ์โดยย่อของ AA

เอสซีเอ แลนด์สเคป

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

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

1. ชั้นโปรโตคอล: โปรโตคอลบางตัวเองก็ให้การสนับสนุนนามธรรมบัญชีดั้งเดิม ธุรกรรม ZKsync เป็นไปตามโฟลว์เดียวกันไม่ว่าจะมาจาก EOA หรือ SCA ซึ่งใช้ mempool และโฟลว์ธุรกรรมเดียวเพื่อรองรับ AA และ Starknet ได้ลบ EOA และบัญชีทั้งหมดเป็น SCA และพวกเขามี กระเป๋าเงินสัญญาอัจฉริยะดั้งเดิมเช่น Argent
2. ชั้นสัญญา: สำหรับ Ethereum และ L2 ที่เทียบเท่า ERC4337 แนะนำจุดเริ่มต้นแยกต่างหากสำหรับธุรกรรมเพื่อรองรับ AA โดยไม่ต้องเปลี่ยนชั้นฉันทามติ โปรเจ็กต์ต่างๆ เช่น Stackup, Alchemy, Etherspot, Biconomy, Candide และ Plimico กำลังสร้างโครงสร้างพื้นฐานแบบรวมกลุ่ม และอื่นๆ อีกมากมายเช่น Safe, Zerodev, Etherspot และ Biconomy กำลังสร้างสแต็กและ SDK

👉 หากคุณไม่คุ้นเคยกับ AA หรือ ERC4337 ตรวจสอบงานวิจัยก่อนหน้าของ SevenX ที่นี่

ภาวะที่กลืนไม่เข้าคายไม่ออกของการยอมรับ SCA

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

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

1. ผลกระทบของตลาดหมี:
   แม้ว่า AA จะแนะนำคุณประโยชน์ต่างๆ เช่น การเข้าสู่ระบบที่ราบรื่นและการใช้ Gas Abstraction แต่ตลาดขาลงส่วนใหญ่ประกอบด้วยผู้ใช้ EOA ที่มีการศึกษามากกว่าผู้ใช้ใหม่ ดังนั้นจึงไม่มีแรงจูงใจสำหรับ dApps และ Wallet แม้จะกล่าวอย่างนั้น แอปชั้นนำยังคงอยู่ระหว่างการนำ AA มาใช้ เหมือนกับที่ Cyberconnect ขับเคลื่อน UserOps ประมาณ 360,000 ราย (ธุรกรรมของ AA) ต่อเดือนเพียงเดือนเดียวด้วยการแนะนำระบบ AA และโซลูชันไร้ก๊าซ
2. อุปสรรคในการอพยพ:
   สำหรับกระเป๋าเงินและแอปพลิเคชันที่มีการสะสมผู้ใช้และทรัพย์สินที่จัดเก็บไว้ใน EOA การโยกย้ายสินทรัพย์อย่างปลอดภัยและสะดวกสบายยังคงเป็นเรื่องท้าทาย อย่างไรก็ตาม โครงการริเริ่มต่างๆ เช่น EIP-7377 ช่วยให้ EOA สามารถเริ่มต้นธุรกรรมการย้ายข้อมูลแบบครั้งเดียวได้
3. ปัญหาการลงนาม:
   สัญญาอัจฉริยะนั้นไม่สามารถลงนามในข้อความได้ตามธรรมชาติ เนื่องจากไม่มีคีย์ส่วนตัวเช่น EOA ความพยายามเช่น ERC1271 ทำให้เป็นไปได้ แต่การเซ็นข้อความจะไม่ทำงานจนกว่าจะมีการทำธุรกรรมครั้งแรก ซึ่งเสนอความท้าทายสำหรับกระเป๋าเงินที่ใช้การปรับใช้ที่ขัดแย้งกับข้อเท็จจริง และ ERC-6492 ที่เสนอโดย Ambire นั้นเป็นรุ่นต่อจาก ERC-1271 ที่เข้ากันได้แบบย้อนหลัง ซึ่งอาจแก้ไขปัญหาก่อนหน้านี้ได้
4. ค่าโสหุ้ยก๊าซ:
   การปรับใช้ การจำลอง และการดำเนินการ SCA มีต้นทุนที่สูงกว่าเมื่อเทียบกับ EOA มาตรฐาน สิ่งนี้กลายเป็นอุปสรรคต่อการรับเลี้ยงบุตรบุญธรรม อย่างไรก็ตาม มีการทดสอบหลายอย่าง เช่น การแยกการสร้างบัญชีออกจากการดำเนินงานของผู้ใช้ และการกำจัดเกลือของบัญชีและการตรวจสอบการมีอยู่ ที่กำลังได้รับการพิจารณาเพื่อลดต้นทุนเหล่านี้
5. ปัญหาทางวิศวกรรม:
   ทีม ERC-4337 ได้จัดตั้ง repo eth-infinitism เพื่อให้นักพัฒนามีการใช้งานขั้นพื้นฐาน อย่างไรก็ตาม เมื่อเราขยายขอบเขตไปยังฟังก์ชันที่เหมาะสมยิ่งขึ้นหรือเฉพาะเจาะจงมากขึ้นสำหรับกรณีการใช้งานที่แตกต่างกัน การบูรณาการและการถอดรหัสกลายเป็นเรื่องที่ท้าทาย

ในบทความนี้ เราจะเจาะลึกปัญหา #5: ปัญหาทางวิศวกรรม

🤔️

บัญชีสัญญาอัจฉริยะแบบโมดูลาร์เพื่อจัดการกับปัญหาทางวิศวกรรม

เพื่ออธิบายรายละเอียดเพิ่มเติมเกี่ยวกับปัญหาทางวิศวกรรม:

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

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

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

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

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

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

โมดูลการเรียกบัญชีจะรับรู้ถึงฟังก์ชันต่างๆ ได้อย่างไร

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

การโทรภายนอกและการโทรของผู้รับมอบสิทธิ์:

เกี่ยวกับ delegateCall

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

สัญญามอบฉันทะและ delegateCall

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

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

สถาปัตยกรรมที่ปลอดภัย

สถาปัตยกรรมที่ปลอดภัย

ปลอดภัยคืออะไร:

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

โครงสร้างของ What's Safe

1. สัญญาบัญชีที่ปลอดภัย: สัญญาพร็อกซีหลัก (Stateful)
   บัญชีที่ปลอดภัยเป็นสัญญาพร็อกซีเนื่องจากจะมอบหมายการเรียกสัญญาแบบซิงเกิลตัน บัญชีที่ปลอดภัยประกอบด้วยเจ้าของ เกณฑ์ และที่อยู่การใช้งานทั้งหมดถูกตั้งค่าเป็นตัวแปรของพร็อกซี ดังนั้นจึงกำหนดสถานะ
2. สัญญาซิงเกิลตัน: Integration Hub (ไร้สัญชาติ)
   Singleton ให้บริการบัญชี Safe และบูรณาการและกำหนดการบูรณาการต่างๆ รวมถึงปลั๊กอิน, Hook, ตัวจัดการฟังก์ชัน และเครื่องมือตรวจสอบลายเซ็น
3. สัญญาโมดูล: ตรรกะและคุณสมบัติที่กำหนดเอง:
   โมดูลมีประสิทธิภาพ ปลั๊กอินที่เป็นประเภทโมดูลาร์สามารถกำหนดคุณสมบัติต่างๆ ได้ เช่น การสตรีมการชำระเงิน กลไกการกู้คืน และคีย์เซสชัน และสามารถทำหน้าที่เป็นสะพานเชื่อมระหว่าง web2 และ web3 โดยการดึงข้อมูลนอกเครือข่าย โมดูลอื่นๆ เช่น Hook เป็นตัวรักษาความปลอดภัย และ Function Handler จะตอบสนองต่อคำสั่งใดๆ

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

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

ERC-2535 ผู้รับมอบฉันทะเพชร

ERC2535 สถาปัตยกรรมเพชร

เกี่ยวกับ ERC2535, Diamond Proxies:

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

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

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

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

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

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

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

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

1. ความยืดหยุ่น:
   ในบริบทของการเปิดใช้งานปลั๊กอินใหม่ Safe จำเป็นต้องปรับใช้สัญญา Singleton ใหม่เพื่อใช้การเปลี่ยนแปลงในพร็อกซี ในทางตรงกันข้าม Diamond บรรลุเป้าหมายนี้โดยตรงผ่านฟังก์ชัน diamondCut ใน Proxy ความแปรปรวนในแนวทางนี้แปลเป็น Safe โดยคงระดับการควบคุมที่สูงกว่า ในขณะที่ Diamond นำเสนอความยืดหยุ่นและโมดูลาร์ที่ได้รับการปรับปรุง
2. ความปลอดภัย:
   delegatecall ซึ่งใช้ในทั้งสองโครงสร้างในขณะนี้ สามารถอนุญาตให้โค้ดภายนอกจัดการการจัดเก็บสัญญาหลักได้ ในสถาปัตยกรรม Safe การเรียกผู้รับมอบสิทธิ์จะชี้ไปที่สัญญาตรรกะเดียว ในขณะที่ Diamond ใช้การเรียกผู้รับมอบสิทธิ์ในสัญญาปลั๊กอินหลายโมดูล ด้วยเหตุนี้ ปลั๊กอินที่เป็นอันตรายจึงมีโอกาสที่จะเขียนทับปลั๊กอินอื่นได้ ทำให้เกิดความเสี่ยงที่พื้นที่จัดเก็บจะขัดแย้งกันซึ่งอาจส่งผลต่อความสมบูรณ์ของพร็อกซี
3. ค่าใช้จ่าย:
   ความยืดหยุ่นที่มีอยู่ในแนวทาง Diamond มาพร้อมกับข้อกังวลด้านความปลอดภัยที่ขยายวงกว้างขึ้น สิ่งนี้จะเพิ่มปัจจัยด้านต้นทุน โดยจำเป็นต้องมีการตรวจสอบที่ครอบคลุมพร้อมกับการเพิ่มปลั๊กอินใหม่ทุกครั้ง กุญแจสำคัญคือการทำให้แน่ใจว่าปลั๊กอินเหล่านี้จะไม่รบกวนการทำงานของกันและกัน ซึ่งถือเป็นความท้าทาย โดยเฉพาะอย่างยิ่งสำหรับองค์กรขนาดเล็กหรือขนาดกลางที่มุ่งมั่นที่จะรักษามาตรฐานความปลอดภัยที่แข็งแกร่ง

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

ลำดับโมดูล: Validator, Executor และ Hook

ลำดับการเรียกโมดูลคืออะไร

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

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

ชื่อฟังก์ชันในรูปแบบต่างๆ

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

ERC6900

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

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

วิธีค้นหาและตรวจสอบโมดูลแบบเปิด

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

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

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

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

1. บัญชี: ในโปรโตคอล Safe{Core} แนวคิดของบัญชีมีความยืดหยุ่นและไม่ผูกมัดกับการใช้งานเฉพาะ สิ่งนี้ทำให้ผู้ให้บริการบัญชีที่หลากหลายสามารถเข้าร่วมได้
2. ผู้จัดการ: ผู้จัดการทำหน้าที่เป็นผู้ประสานงานระหว่างบัญชี การลงทะเบียน และโมดูลต่างๆ นอกจากนี้ยังรับผิดชอบด้านความปลอดภัยในฐานะเลเยอร์การอนุญาต
3. การลงทะเบียน: การลงทะเบียนจะกำหนดคุณลักษณะด้านความปลอดภัยและบังคับใช้มาตรฐานเช่น ERC6900 สำหรับโมดูล โดยมีเป้าหมายเพื่อสร้างสภาพแวดล้อม "app store" แบบเปิดสำหรับทั้งการค้นพบและความปลอดภัย
4. โมดูล: โมดูลจัดการฟังก์ชันการทำงานและมีหลายประเภทเริ่มต้น รวมถึงปลั๊กอิน Hooks เครื่องมือตรวจสอบลายเซ็น และตัวจัดการฟังก์ชัน สิ่งเหล่านี้เปิดให้นักพัฒนาสามารถมีส่วนร่วมได้หากเป็นไปตามมาตรฐานที่กำหนด

การออกแบบพลอยเทียม

การออกแบบพลอยเทียม

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

1. การสร้างคำจำกัดความของสคีมา: สคีมาทำหน้าที่เป็นโครงสร้างข้อมูลที่กำหนดไว้ล่วงหน้าซึ่งจำเป็นสำหรับการรับรอง ธุรกิจต่างๆ สามารถปรับแต่งให้สอดคล้องกับกรณีการใช้งานเฉพาะของตนได้
2. การสร้างโมดูลตามสคีมา: สัญญาอัจฉริยะได้รับการลงทะเบียนเป็นโมดูล รับรหัสไบต์ และเลือกรหัสสคีมา ข้อมูลนี้จะถูกเก็บไว้ในรีจิสทรีแล้ว
3. การบรรลุการรับรองสำหรับโมดูล: ผู้รับรอง/ผู้ตรวจสอบสามารถจัดให้มีการรับรองสำหรับโมดูลต่างๆ ตามแบบแผน การรับรองเหล่านี้อาจรวมถึงตัวระบุเฉพาะ (UID) และการอ้างอิงถึงการรับรองอื่น ๆ สำหรับการผูกมัด พวกเขาสามารถเผยแพร่ข้ามเครือข่ายและตรวจสอบว่าตรงตามเกณฑ์เฉพาะในเครือข่ายปลายทางหรือไม่
4. การใช้ตรรกะที่ซับซ้อนกับตัวแก้ไข: ตัวแก้ไขซึ่งเป็นทางเลือกที่ตั้งค่าไว้ในสคีมาเข้ามามีบทบาท สามารถเรียกใช้ได้ในระหว่างการสร้างโมดูล การสร้างการรับรอง และการเพิกถอน ตัวแก้ไขเหล่านี้ช่วยให้นักพัฒนาสามารถรวมตรรกะที่ซับซ้อนและหลากหลายในขณะที่ยังคงรักษาโครงสร้างการรับรองไว้ได้
5. การเข้าถึงแบบสอบถามที่ใช้งานง่าย: แบบสอบถามเสนอวิธีการสำหรับผู้ใช้ในการเข้าถึงข้อมูลความปลอดภัยจากส่วนหน้า ค้นหา EIP นี้ได้ที่นี่

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

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

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

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

ปิดความคิด

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

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

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

ชิ้นสำคัญ

1. เอกสารไวท์เปเปอร์ที่ปลอดภัย: https://github.com/safe-global/safe-core-protocol-specs/blob/main/whitepaper.pdf
2. เอกสาร Rhinestone: https://docs.rhinestone.wtf/
3. เอกสาร Biconomy: https://www.biconomy.io/post/making-biconomy-smart-accounts-modular

ข้อสงวนสิทธิ์：

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