บทความนี้เขียนโดยทีมวิจัยของ SevenX และมีวัตถุประสงค์เพื่อการสื่อสารและการเรียนรู้เท่านั้น และไม่ถือเป็นการอ้างอิงการลงทุนใดๆ หากต้องการอ้างอิงกรุณาระบุแหล่งที่มา
รายงานต้นฉบับภาษาอังกฤษเผยแพร่บนแพลตฟอร์ม Mirror ของ SevenX ในเดือนกันยายน 2023สำหรับเนื้อหาการวิจัยการลงทุนของจีนเพิ่มเติม โปรดติดตามบัญชีสาธารณะ [SevenXVentures]
ขอขอบคุณ Lukas ผู้ร่วมก่อตั้ง Safe, Noam หัวหน้าฝ่ายวิศวกรรมที่ Alchemy, Kurt และ Konrad ผู้ร่วมก่อตั้ง Rhinestone และนักลงทุน Arnav จาก HashKey Capital
หมายเหตุบรรณาธิการ: Smart Contract Accounts (SCA) กำลังพัฒนาอย่างแข็งแกร่งและได้รับการสนับสนุนจากผู้ประกอบการหลักหลายราย รวมถึง Vitalik อย่างไรก็ตาม การนำ SCA มาใช้ยังคงเผชิญกับความท้าทายมากมาย Account Abstraction (AA) มีข้อได้เปรียบในการปรับแต่งฟังก์ชันการทำงานโดยใช้โค้ด แต่ความสามารถในการทำงานร่วมกันไม่ได้ทำให้เกิดปัญหาในการผสานรวมและการล็อคอินของผู้ขาย นามธรรมบัญชีแบบแยกส่วนมีจุดมุ่งหมายเพื่อสร้างโครงสร้างแบบแยกส่วนสำหรับการพัฒนากระเป๋าเงินที่มีฟังก์ชันการทำงานที่หลากหลาย ความปลอดภัย และการบูรณาการที่ราบรื่น
Rui นักลงทุนของ SevenX Ventures ชี้ให้เห็นถึงความท้าทายหลัก 5 ประการที่ต้องเผชิญกับการนำ SCA มาใช้ ได้แก่ ผลกระทบต่อตลาด ความยากในการอพยพ ปัญหาลายเซ็นต์ ต้นทุนก๊าซที่สูง และปัญหาทางวิศวกรรม และได้หารือเพิ่มเติมเกี่ยวกับปัญหาทางวิศวกรรม นอกจากนี้ การวิเคราะห์สถาปัตยกรรมของบัญชีสัญญาอัจฉริยะแบบแยกส่วน ชี้ให้เห็นว่า SCA แบบแยกส่วนเป็นเพียงส่วนเล็ก ๆ ของปริศนาในการนำไปใช้
เพื่อให้ตระหนักถึงศักยภาพของ SCA อย่างเต็มที่ โซลูชันเลเยอร์ 2 จำเป็นต้องให้การสนับสนุนเลเยอร์โปรโตคอลเพิ่มเติม โครงสร้างพื้นฐาน Bundler ที่มีประสิทธิภาพและพูลหน่วยความจำแบบ peer-to-peer กลไกลายเซ็น SCA ที่คุ้มค่าและเป็นไปได้มากขึ้น การซิงโครไนซ์ SCA แบบข้ามสายโซ่ และ กลไกการจัดการและการพัฒนา User-Friendly Interface และอื่นๆ
ในอนาคต เมื่อความท้าทายในปัจจุบันค่อยๆ คลี่คลาย และผู้คนหันมาใช้ SCA มากขึ้น จะเกิดอะไรขึ้นต่อไป รุยยังตั้งคำถามที่น่าสนใจเกี่ยวกับเรื่องนี้ด้วย BlockBeats รวบรวมข้อความต้นฉบับดังนี้:
การเปลี่ยนจากบัญชีภายนอก (EOA) ไปเป็นบัญชีสัญญาอัจฉริยะ (SCA) กำลังได้รับแรงผลักดันและได้รับการสนับสนุนจากผู้ประกอบการหลักหลายราย รวมถึง Vitalik อย่างไรก็ตาม การนำ SCA มาใช้ยังไม่แพร่หลายเท่า EOA ปัญหาหลัก ได้แก่ ผลกระทบของตลาดหมี ความยากในการย้ายจาก eoa สู่ sca ปัญหาลายเซ็นต์ ต้นทุนก๊าซที่สูง และปัญหาการพัฒนาที่สำคัญที่สุด
ข้อได้เปรียบที่สำคัญที่สุดของ Account Abstraction (AA) คือความสามารถในการปรับแต่งฟังก์ชันการทำงานโดยใช้โค้ด อย่างไรก็ตาม การไม่สามารถทำงานร่วมกันได้ของฟังก์ชัน AA ทำให้เกิดความท้าทายที่สำคัญ การกระจายตัวนี้อาจขัดขวางการรวม AA และเสริมการล็อคอินของผู้ขาย นอกจากนี้ การรับรองความปลอดภัยในขณะที่อัปเกรดและจัดองค์ประกอบได้ก็ถือเป็นความท้าทายที่สำคัญเช่นกัน
พื้นที่เฉพาะด้านหนึ่งในแนวโน้มการพัฒนา AA คือการเกิดขึ้นของนามธรรมบัญชีแบบโมดูลาร์ ซึ่งเป็นแนวทางใหม่ที่แยกบัญชีอัจฉริยะออกจากฟังก์ชันการทำงานที่กำหนดเอง เป้าหมายคือการสร้างโครงสร้างโมดูลาร์เพื่อพัฒนากระเป๋าเงินที่มีฟังก์ชันการทำงานที่หลากหลาย ความปลอดภัย และการบูรณาการที่ราบรื่น ในอนาคต นามธรรมบัญชีแบบโมดูลาร์สามารถใช้บัญชีสัญญาอัจฉริยะฟรี app store ซึ่งช่วยให้ wallets และ dApps มุ่งเน้นไปที่การปรับปรุงประสบการณ์ผู้ใช้โดยไม่ต้องใช้พลังงานมากเกินไปในการสร้างฟังก์ชันต่างๆ
ข้อมูลเบื้องต้นเกี่ยวกับ Account Abstraction (AA)
ในกระบวนการที่ผู้คนเข้ามาติดต่อกับบล็อกเชน EOA แบบดั้งเดิมได้นำมาซึ่งความท้าทายมากมาย เช่น คำช่วยในการจำ ค่าธรรมเนียมก๊าซ การดำเนินการข้ามเครือข่าย และธุรกรรมหลายรายการ
นามธรรมบัญชีใช้ประโยชน์จากบัญชีสัญญาอัจฉริยะ ช่วยให้สามารถตรวจสอบและดำเนินการโปรแกรมได้ ซึ่งหมายความว่าผู้ใช้สามารถอนุมัติธุรกรรมหลายรายการพร้อมกัน แทนที่จะต้องลงนามและออกอากาศแต่ละรายการ การลบบัญชียังสามารถบรรลุฟังก์ชันต่างๆ ได้มากขึ้น เช่น การปรับปรุงประสบการณ์ผู้ใช้ (เช่น การลบแก๊สและคีย์เซสชัน) การลดต้นทุน (เช่น ธุรกรรมแบบแบตช์) และปรับปรุงความปลอดภัย (เช่น การกู้คืนทางสังคม ลายเซ็นหลายลายเซ็น) ปัจจุบัน มีสองวิธีในการใช้นามธรรมบัญชี:
ชั้นโปรโตคอล: โปรโตคอลบางตัวเองก็ให้การสนับสนุนการลบบัญชีแบบเนทีฟ ธุรกรรม ZKSync ใช้พูลหน่วยความจำเดียวและกระบวนการธุรกรรมเพื่อรองรับ AA ไม่ว่าจะมาจาก EOA หรือ SCA พวกเขาก็ทำตามกระบวนการเดียวกัน และ Starknet ได้ลบ EOA และบัญชีทั้งหมดเป็น SCA และพวกเขามีกระเป๋าเงินสัญญาอัจฉริยะอย่างเช่น Argent
ชั้นสัญญา: สำหรับ Ethereum และ L2 ที่คล้ายกัน ERC 4337 แนะนำ mempool แยกต่างหากเพื่อรองรับ AA โดยไม่ต้องเปลี่ยนชั้นฉันทามติ บริษัทต่างๆ เช่น Stackup, Alchemy, Etherspot, Biconomy, Candide และ Plimico กำลังสร้างโครงสร้างพื้นฐานแบบรวมกลุ่ม ในขณะที่บริษัทอย่าง Safe, Zerodev, Etherspot และ Biconomy กำลังสร้างชุดรวมและ SDK
ประเด็นขัดแย้งเมื่อนำ SCA มาใช้
หัวข้อ Account Abstraction (AA) ได้รับการพูดคุยกันตั้งแต่ปี 2558 และได้รับความสนใจเพิ่มเติมในปีนี้โดย ERC 4337 อย่างไรก็ตาม จำนวนบัญชีสัญญาอัจฉริยะที่ใช้งานยังน้อยกว่าจำนวน EOA มาก
มาเจาะลึกลงไปในภาวะที่กลืนไม่เข้าคายไม่ออกนี้:
1. ผลกระทบของตลาดหมี
แม้ว่า AA จะมีข้อได้เปรียบ เช่น การเข้าสู่ระบบที่ราบรื่นและ Gas abstraction ในตลาดหมีในปัจจุบัน ผู้ใช้ทั้งหมดได้รับการศึกษาเป็นผู้ใช้ EOA และมีผู้ใช้ใหม่ไม่มากนัก ดังนั้น dApps และ Wallets จึงไม่จูงใจให้ใช้ SCA ถึงกระนั้นก็ตาม dApps ชั้นนำบางแห่งก็ค่อยๆ นำ AA มาใช้ เช่น Cyberconnect ซึ่งขับเคลื่อน UserOps (ธุรกรรม AA) ประมาณ 360,000 รายในเวลาเพียงเดือนเดียวโดยการแนะนำระบบ AA และโซลูชันไร้ก๊าซ
2. อุปสรรคต่อการย้ายถิ่น
สำหรับกระเป๋าสตางค์และแอปพลิเคชันที่มีผู้ใช้และทรัพย์สินสะสม การโยกย้ายสินทรัพย์อย่างปลอดภัยและสะดวกสบายยังคงเป็นเรื่องท้าทาย อย่างไรก็ตาม รูปแบบเช่น EIP-7377 ช่วยให้ EOA สามารถเริ่มต้นธุรกรรมการย้ายข้อมูลแบบครั้งเดียวได้
3. ปัญหาลายเซ็น
สัญญาอัจฉริยะไม่สามารถเซ็นข้อความได้เนื่องจากไม่มีคีย์ส่วนตัวเช่น EOA ความพยายามเช่น ERC 1271 ทำให้สิ่งนี้เป็นไปได้ แต่ลายเซ็นข้อความจะไม่ทำงานก่อนการทำธุรกรรมครั้งแรก ซึ่งก่อให้เกิดความท้าทายอีกครั้งสำหรับกระเป๋าเงินที่ใช้การปรับใช้ที่ขัดแย้งกับข้อเท็จจริง ERC-6492 ซึ่งเสนอโดย Ambire เป็นผู้สืบทอดที่เข้ากันได้แบบย้อนหลังกับ ERC-1271 และอาจสามารถแก้ไขปัญหาก่อนหน้านี้ได้
4. ค่าน้ำมัน
อุปสรรคประการหนึ่งในการนำไปใช้คือค่าใช้จ่ายในการปรับใช้ จำลอง และดำเนินการ SCA ที่สูงกว่าเมื่อเปรียบเทียบกับ EOA มาตรฐาน อย่างไรก็ตาม มีการทดสอบบางอย่างเกิดขึ้น เช่น แยกการสร้างบัญชีออกจากการกระทำของผู้ใช้ และกำจัด"salt"รอ.
5. ปัญหาทางวิศวกรรม
ทีม ERC-4337 ได้สร้าง repo eth-infinitism เพื่อให้การใช้งานขั้นพื้นฐานสำหรับนักพัฒนา อย่างไรก็ตาม การบูรณาการและการถอดรหัสจะเผชิญกับความท้าทายมากขึ้น เนื่องจากนักพัฒนาขยายไปสู่ฟังก์ชันการทำงานเฉพาะเจาะจงและเหมาะสมมากขึ้นสำหรับกรณีการใช้งานที่แตกต่างกัน ในบทความนี้ เราจะมาดูความท้าทายทางวิศวกรรมอย่างละเอียดยิ่งขึ้น
แก้ปัญหาความท้าทายด้านวิศวกรรมด้วยบัญชีสัญญาอัจฉริยะแบบโมดูลาร์
ความท้าทายด้านวิศวกรรมสามารถอธิบายเพิ่มเติมได้เป็น 3 ด้าน ได้แก่ การกระจายตัว ความปลอดภัย และความสามารถในการขยายขนาด
การกระจายตัว
ขณะนี้คุณลักษณะต่างๆ สามารถเปิดใช้งานได้หลายวิธี ไม่ว่าจะผ่าน SCA เฉพาะหรือผ่านระบบปลั๊กอินแบบสแตนด์อโลน แพลตฟอร์มและผู้ให้บริการแต่ละรายปฏิบัติตามมาตรฐานของตนเอง ทำให้นักพัฒนาต้องตัดสินใจว่าจะสนับสนุนแพลตฟอร์มและผู้ให้บริการรายใด สิ่งนี้สามารถนำไปสู่การล็อคอินแพลตฟอร์ม (ผู้ขาย) ที่อาจเกิดขึ้นหรือการทำงานซ้ำซ้อน
ความปลอดภัย
แม้ว่าการแยกบัญชีและฟังก์ชันต่างๆ จะทำให้เกิดข้อได้เปรียบด้านความยืดหยุ่น แต่ก็อาจทำให้ปัญหาด้านความปลอดภัยแย่ลงได้เช่นกัน เนื่องจากฟีเจอร์ทั้งหมดอาจได้รับการตรวจสอบร่วมกัน การขาดการประเมินโดยอิสระอาจเพิ่มความเสี่ยงต่อช่องโหว่ของบัญชี
ความสามารถในการอัพเกรด
เมื่อบัญชีเติบโตขึ้น สิ่งสำคัญคือต้องรักษาความสามารถในการเพิ่ม แทนที่ หรือลบฟังก์ชันการทำงาน และการอัปเดตแต่ละครั้งที่ปรับใช้ฟังก์ชันที่มีอยู่ใหม่จะทำให้เกิดความซับซ้อน
เพื่อจัดการกับปัญหาเหล่านี้ เราจำเป็นต้องมีสัญญาที่อัปเกรดได้เพื่อให้แน่ใจว่าการอัปเกรดที่ปลอดภัยและมีประสิทธิภาพ แกนนำที่นำมาใช้ซ้ำได้เพื่อปรับปรุงประสิทธิภาพการพัฒนาโดยรวม และอินเทอร์เฟซที่ได้มาตรฐานเพื่อให้แน่ใจว่าบัญชีสัญญาสามารถเปลี่ยนแปลงได้อย่างราบรื่นระหว่างส่วนหน้าที่แตกต่างกัน
คำเหล่านี้มาบรรจบกันบนแนวคิดทั่วไป: การสร้างสถาปัตยกรรมนามธรรมบัญชีแบบแยกส่วน (แบบแยกส่วน AA)
Modular account abstraction เป็นแผนกย่อยภายในการพัฒนา AA แบบกว้างๆ ที่มองเห็นการทำให้บัญชีอัจฉริยะเป็นแบบโมดูลาร์ เพื่อปรับแต่งบริการให้กับผู้ใช้ และทำให้นักพัฒนาปรับปรุงฟังก์ชันการทำงานได้อย่างราบรื่นโดยมีข้อจำกัดน้อยที่สุด
อย่างไรก็ตาม การสร้างและส่งเสริมมาตรฐานใหม่ในอุตสาหกรรมใดก็ตามถือเป็นความท้าทายอย่างมาก วิธีแก้ปัญหาต่างๆ มากมายมีแนวโน้มที่จะเกิดขึ้นในระยะเริ่มแรกจนกว่าทุกคนจะยอมรับมาตรฐานเดียวกัน เป็นเรื่องน่ายินดีที่ได้เห็นผู้ที่ทำงานเพื่อปรับปรุงและส่งเสริมการสร้างบัญชีที่เป็นนามธรรม ไม่ว่าจะเป็น 4337 SDK, กระเป๋าเงิน, ทีมโครงสร้างพื้นฐาน หรือผู้ออกแบบเลเยอร์โปรโตคอล ทำงานร่วมกันเพื่อเร่งกระบวนการนี้ให้เร็วขึ้น
โครงสร้างโมดูลาร์: บัญชีหลักและโมดูล
วิธีที่บัญชีเรียกใช้โมดูลเพื่อใช้งานฟังก์ชันต่างๆ
มอบหมายสัญญาการโทรและพร็อกซี
การโทรภายนอกและการโทรแบบมอบหมาย:
เกี่ยวกับการโทรของผู้รับมอบสิทธิ์
แม้ว่า การเรียกการมอบหมาย จะคล้ายกับ การร้องขอ แต่ก็ไม่ได้ดำเนินการในบริบทของสัญญาเป้าหมาย แต่ในบริบทของสถานะปัจจุบันของสัญญาการเรียก ซึ่งหมายความว่าการเปลี่ยนแปลงสถานะใดๆ ที่ทำโดยสัญญาเป้าหมายจะเปลี่ยนพื้นที่เก็บข้อมูลของสัญญาการโทร
สัญญาพร็อกซีและการโทรของผู้รับมอบสิทธิ์
เพื่อให้บรรลุถึงโครงสร้างที่ประกอบและอัปเกรดได้ จำเป็นต้องมีการแนะนำแนวคิดพื้นฐาน สัญญาตัวแทน
สัญญาตัวแทน: สัญญาทั่วไปจะจัดเก็บตรรกะและสถานะ และไม่สามารถอัปเดตได้หลังจากการปรับใช้ สัญญาพร็อกซีใช้การเรียกของผู้รับมอบสิทธิ์เพื่อปรับใช้กับสัญญาอื่น ใช้ฟังก์ชันโดยการอ้างอิง โดยดำเนินการในสถานะปัจจุบันของสัญญาตัวแทน
กรณีการใช้งาน: แม้ว่าสัญญาพร็อกซีจะยังคงเหมือนเดิม คุณสามารถปรับใช้การใช้งานใหม่หลังพร็อกซีได้ สัญญาพร็อกซีช่วยให้สามารถอัปเกรดได้และมีราคาถูกกว่าในการปรับใช้และบำรุงรักษาบนบล็อกเชนสาธารณะ
สถาปัตยกรรมที่ปลอดภัย
สถาปัตยกรรมที่ปลอดภัย
ปลอดภัยคืออะไร:
Safe เป็นโครงสร้างพื้นฐานบัญชีอัจฉริยะแบบแยกส่วนชั้นนำที่ออกแบบมาเพื่อมอบความปลอดภัยและความยืดหยุ่นที่ผ่านการทดสอบการต่อสู้ ช่วยให้นักพัฒนาสามารถสร้างแอปพลิเคชันและกระเป๋าเงินที่หลากหลาย หลายทีมกำลังสร้างแอปพลิเคชันตาม (หรือได้รับแรงบันดาลใจจาก) Safe ตัวอย่างเช่น เมื่อ Biconomy เปิดตัวบัญชีสัญญาอัจฉริยะ ก็ใช้ลายเซ็นหลายลายเซ็น 4337 และ 1/1 เพื่อขยาย Safe ด้วยสัญญาที่ใช้งานมากกว่า 164,000 สัญญาและการล็อคมูลค่ามากกว่า 30.7 พันล้านดอลลาร์ Safe จึงเป็นผู้นำในสาขานี้อย่างไม่ต้องสงสัย
โครงสร้างของ Safe ประกอบด้วยสัญญาบัญชีความปลอดภัย สัญญาซิงเกิลตัน และสัญญาโมดูล
สัญญาบัญชีหลักทรัพย์ (สัญญามอบฉันทะ): สัญญาตัวแทนหลัก (Stateful)
บัญชีความปลอดภัยเป็นสัญญาพร็อกซีเนื่องจากการเรียกของผู้รับมอบสิทธิ์เป็นสัญญาแบบซิงเกิลตัน บัญชีความปลอดภัยประกอบด้วยตัวแปรสำหรับเจ้าของ เกณฑ์ และที่อยู่การใช้งานที่ตั้งค่าให้กับตัวแทนทั้งหมด และสถานะของตัวแปรจะถูกกำหนดตามสิ่งเหล่านี้
สัญญาซิงเกิลตัน: Integration Hub (ไร้สัญชาติ)
สัญญาซิงเกิลตันให้บริการบัญชี Safe และกำหนดการบูรณาการสัญญาโมดูลต่างๆ รวมถึงปลั๊กอิน, Hook, ตัวจัดการฟังก์ชัน และเครื่องมือตรวจสอบลายเซ็น
สัญญาโมดูล (โมดูล): ตรรกะและฟังก์ชันที่กำหนดเอง
สัญญาโมดูลมีประสิทธิภาพ ปลั๊กอินเป็นประเภทโมดูลาร์ สามารถกำหนดฟังก์ชันต่างๆ ได้ เช่น ขั้นตอนการชำระเงิน กลไกการกู้คืน และคีย์เซสชัน และสามารถทำหน้าที่เป็นสะพานเชื่อมระหว่าง Web2 และ Web3 โดยการรับข้อมูลนอกเครือข่าย โมดูลอื่นๆ เช่น Hook และ Function Handler ที่เป็นเจ้าหน้าที่รักษาความปลอดภัยสามารถตอบสนองทุกคำสั่งได้
การเปลี่ยนแปลงที่เกิดจากการใช้ Safe:
สัญญาที่อัปเกรดได้: จำเป็นต้องปรับใช้ซิงเกิลตันใหม่ทุกครั้งที่มีการแนะนำปลั๊กอินใหม่ ผู้ใช้ยังคงมีอิสระในการอัพเกรด Safe เป็นเวอร์ชันซิงเกิลตันที่ต้องการ
โมดูลที่ประกอบและนำกลับมาใช้ใหม่ได้: ลักษณะโมดูลาร์ของปลั๊กอินช่วยให้นักพัฒนาสามารถพัฒนาฟังก์ชันการทำงานได้อย่างอิสระ พวกเขามีอิสระในการเลือกและรวมปลั๊กอินเหล่านี้ตามกรณีการใช้งาน ส่งผลให้เกิดแนวทางที่ปรับแต่งได้สูง
ERC-2535 ตัวแทนเพชร
เกี่ยวกับ ERC 2535 ตัวแทนเพชร:
โมเดล Diamond ที่ได้มาตรฐาน ERC 2535 ซึ่งเป็นระบบสัญญาอัจฉริยะแบบโมดูลาร์ที่สามารถอัปเกรด/ขยายได้หลังจากการปรับใช้โดยแทบไม่มีการจำกัดขนาด ในปัจจุบัน การทดลองของหลายๆ ทีม เช่น Kernel และ Soul Wallet ของ Zerodev ได้รับแรงบันดาลใจจากโครงสร้าง Diamond
โครงสร้างเพชรคืออะไร:
สัญญาเพชร: สัญญาพร็อกซีหลัก (สถานะ) ไดมอนด์เป็นสัญญาพร็อกซีที่ใช้วิธีการเรียกผู้รับมอบสิทธิ์เพื่อเรียกใช้ฟังก์ชันจากการใช้งาน
โมดูล/ปลั๊กอิน/สัญญา Facet: ตรรกะที่กำหนดเองและฟังก์ชันการทำงาน (ไร้สถานะ) โมดูลหรือที่เรียกว่า Facet คือสัญญาไร้สัญชาติที่สามารถปรับใช้งานฟังก์ชันกับเพชรหนึ่งเม็ดขึ้นไป เป็นสัญญาอิสระที่แยกจากกันซึ่งสามารถแชร์ฟังก์ชันภายใน ไลบรารี และตัวแปรสถานะได้
การเปลี่ยนแปลงที่เกิดจากการใช้ Diamond:
สัญญาที่อัปเกรดได้: Diamond มอบวิธีการที่เป็นระบบในการแยกปลั๊กอินต่างๆ และเชื่อมต่อเข้าด้วยกัน แบ่งปันข้อมูลระหว่างปลั๊กอินเหล่านั้น และยังเพิ่ม/แทนที่/ลบปลั๊กอินใดๆ โดยตรงโดยใช้ฟังก์ชัน diamondCut เมื่อเวลาผ่านไป จะไม่มีการจำกัดจำนวนปลั๊กอินที่สามารถเพิ่มลงใน Diamond
ปลั๊กอินแบบโมดูลาร์และแบบใช้ซ้ำได้: Diamonds จำนวนเท่าใดก็ได้สามารถใช้ปลั๊กอินที่ปรับใช้ได้ ซึ่งจะช่วยลดต้นทุนการใช้งานได้อย่างมาก
ความแตกต่างระหว่างบัญชี Safe smart และวิธี Diamond:
มีความคล้ายคลึงกันหลายประการระหว่างสถาปัตยกรรม Safe และ Diamond โดยทั้งคู่อาศัยสัญญาพร็อกซีที่แกนหลักและอ้างอิงสัญญาเชิงตรรกะสำหรับการอัปเกรดและความเป็นโมดูล
ความแตกต่างที่สำคัญระหว่างทั้งสองคือการจัดการสัญญาเชิงตรรกะ โดยเฉพาะ:
ความยืดหยุ่น: เมื่อเปิดใช้งานปลั๊กอินใหม่ Safe จำเป็นต้องปรับใช้สัญญาซิงเกิลตันใหม่เพื่อใช้การเปลี่ยนแปลงในพร็อกซี ในทางตรงกันข้าม Diamond ดำเนินการนี้โดยตรงผ่านฟังก์ชัน diamondCut ในสัญญาพร็อกซี วิธีการที่แตกต่างกันนี้หมายความว่า Safe ยังคงรักษาระดับการควบคุมที่สูงกว่า ในขณะที่ Diamond นำเสนอความยืดหยุ่นและการแยกส่วนที่ได้รับการปรับปรุง
ความปลอดภัย: ปัจจุบันใช้ในสองโครงสร้างที่อนุญาตให้โค้ดภายนอกจัดการการจัดเก็บสัญญาหลัก ในสถาปัตยกรรม Safe การโทรของผู้รับมอบสิทธิ์จะชี้ไปที่สัญญาเชิงตรรกะเดียว ในขณะที่ Diamond ใช้การโทรของผู้รับมอบสิทธิ์ในปลั๊กอินสัญญาโมดูลหลายรายการ ดังนั้นจึงเป็นไปได้ที่ปลั๊กอินที่เป็นอันตรายจะเขียนทับปลั๊กอินอื่น ซึ่งทำให้เกิดความเสี่ยงที่ข้อขัดแย้งในการจัดเก็บข้อมูลและทำให้ความสมบูรณ์ของเอเจนต์ลดลง
ค่าใช้จ่าย: ด้วยแนวทาง Diamond ความยืดหยุ่นมาพร้อมกับข้อกังวลด้านความปลอดภัย การดำเนินการนี้จะเพิ่มค่าใช้จ่ายและต้องมีการตรวจสอบฉบับสมบูรณ์ทุกครั้งที่มีการเพิ่มปลั๊กอินใหม่ สิ่งสำคัญคือต้องแน่ใจว่าปลั๊กอินเหล่านี้จะไม่รบกวนการทำงานของกันและกัน ซึ่งเป็นงานที่อาจท้าทาย โดยเฉพาะอย่างยิ่งสำหรับธุรกิจขนาดเล็กและขนาดกลางที่พยายามรักษามาตรฐานความปลอดภัยระดับสูง
วิธีบัญชีอัจฉริยะที่ปลอดภัย และ วิธีเพชร เป็นตัวอย่างของโครงสร้างที่แตกต่างกันที่เกี่ยวข้องกับตัวแทนและโมดูล วิธีสร้างสมดุลระหว่างความยืดหยุ่นและความปลอดภัยถือเป็นสิ่งสำคัญ และแนวทางทั้งสองนี้จะยังคงพัฒนาและส่งเสริมซึ่งกันและกันในอนาคต
ลำดับโมดูล: Validator, Executor และ Hook
เราจะมาพูดคุยกันเพิ่มเติมด้วยการแนะนำ ERC-6900 ซึ่งเป็นมาตรฐานที่เสนอโดยทีมงาน Alchemy ซึ่งได้รับแรงบันดาลใจจาก Diamond และปรับแต่งมาสำหรับ ERC-4337 โดยเฉพาะ ช่วยแก้ปัญหาความท้าทายของการทำให้บัญชีอัจฉริยะเป็นแบบโมดูลาร์โดยจัดให้มีอินเทอร์เฟซทั่วไปและประสานงานการทำงานระหว่างนักพัฒนาปลั๊กอินและกระเป๋าเงิน
เมื่อพูดถึงกระบวนการทำธุรกรรมของ AA มีกระบวนการหลักสามกระบวนการ: การตรวจสอบ การดำเนินการ และการเชื่อมต่อ ดังที่เราได้กล่าวไว้ก่อนหน้านี้ ขั้นตอนเหล่านี้ทั้งหมดสามารถจัดการได้โดยการเรียกโมดูลโดยใช้บัญชีพร็อกซี แม้ว่าโครงการต่างๆ อาจใช้ชื่อที่แตกต่างกัน แต่สิ่งสำคัญคือต้องเข้าใจตรรกะพื้นฐานที่คล้ายกัน
ชื่อฟังก์ชันในรูปแบบต่างๆ
เครื่องมือตรวจสอบความถูกต้อง: ตรวจสอบความถูกต้องและอำนาจของผู้เรียกบัญชี
ผู้ดำเนินการ: ดำเนินการตรรกะที่กำหนดเองใด ๆ ที่อนุญาตโดยบัญชี
Hook: ทำหน้าที่เป็นโมดูลที่ทำงานก่อนหรือหลังฟังก์ชันอื่น สามารถแก้ไขสถานะหรือยกเลิกการโทรทั้งหมดได้
ERC 6900
จำเป็นอย่างยิ่งที่จะต้องแยกโมดูลตามตรรกะที่แตกต่างกัน แนวทางที่เป็นมาตรฐานควรกำหนดวิธีการเขียนฟังก์ชันการตรวจสอบ การดำเนินการ และการเชื่อมต่อสำหรับบัญชีสัญญาอัจฉริยะ ไม่ว่าจะเป็น Safe หรือ ERC-6900 การกำหนดมาตรฐานจะช่วยลดความจำเป็นในการพัฒนาเฉพาะสำหรับการใช้งานหรือระบบนิเวศบางอย่าง และป้องกันการผูกมัดของผู้ขาย
การค้นพบโมดูลและความปลอดภัย
วิธีค้นหาและตรวจสอบโมดูลด้วยวิธีเปิด: โซลูชันหนึ่งที่กำลังก้าวหน้าเกี่ยวข้องกับการสร้างพื้นที่ที่อนุญาตให้ผู้ใช้ค้นพบโมดูลที่ตรวจสอบได้ เรียกว่า รีจิสทรี รีจิสทรีทำหน้าที่เหมือน app store และได้รับการออกแบบมาเพื่อส่งเสริมตลาดโมดูลาร์ที่เรียบง่ายแต่เจริญรุ่งเรือง
โปรโตคอลที่ปลอดภัย {Core}
Safe{Core} Protocol เป็นโปรโตคอลแบบโอเพ่นซอร์สที่ทำงานร่วมกันได้สำหรับบัญชีสัญญาอัจฉริยะ ซึ่งได้รับการออกแบบมาเพื่อปรับปรุงการเข้าถึงสำหรับผู้ขายและนักพัฒนาที่หลากหลาย ขณะเดียวกันก็รักษาความปลอดภัยที่แข็งแกร่งผ่านมาตรฐานและกฎเกณฑ์ที่กำหนดไว้อย่างชัดเจน
บัญชี: ในโปรโตคอล Safe{Core} แนวคิดของบัญชีมีความยืดหยุ่นและไม่เชื่อมโยงกับการใช้งานเฉพาะ ซึ่งจะทำให้ผู้ให้บริการบัญชีต่างๆ สามารถเข้าร่วมได้
ผู้จัดการ: ผู้จัดการทำหน้าที่เป็นผู้ประสานงานระหว่างบัญชี รีจิสทรี และโมดูล นอกจากนี้ยังทำหน้าที่เป็นชั้นการอนุญาตที่รับผิดชอบด้านความปลอดภัย
ศูนย์การลงทะเบียน: ศูนย์การลงทะเบียนจะกำหนดคุณลักษณะด้านความปลอดภัยและใช้มาตรฐานโมดูล เช่น ERC 6900 โดยมีเป้าหมายเพื่อสร้างสภาพแวดล้อม ร้านค้าแอปพลิเคชัน แบบเปิดเพื่อให้ค้นพบได้และรักษาความปลอดภัย
โมดูล: โมดูลจัดการฟังก์ชันการทำงานและมีประเภทเริ่มต้นที่หลากหลาย รวมถึงปลั๊กอิน hooks เครื่องมือตรวจสอบลายเซ็น และตัวจัดการฟังก์ชัน นักพัฒนาสามารถเข้าร่วมได้ตราบใดที่มีคุณสมบัติตรงตามมาตรฐานที่กำหนด
การออกแบบพลอยเทียม
กระบวนการเกิดขึ้นดังนี้:
สร้างข้อกำหนดสคีมา (สคีมา): สคีมาจัดเตรียมโครงสร้างข้อมูลที่กำหนดไว้ล่วงหน้า ผู้คนสามารถปรับแต่งให้เหมาะกับกรณีการใช้งานเฉพาะของตนได้
สร้างโมดูลตามสถาปัตยกรรม: สัญญาอัจฉริยะที่ลงทะเบียนเป็นโมดูลจะได้รับรหัสไบต์และเลือกรหัสสถาปัตยกรรม และข้อมูลจะถูกจัดเก็บไว้ในรีจิสทรี
รับการรับรองโมดูล: ผู้รับรอง/ผู้ตรวจสอบสามารถจัดเตรียมการรับรองสำหรับโมดูลต่างๆ ตามสถาปัตยกรรม ใบรับรองเหล่านี้อาจมีตัวระบุเฉพาะ (UID) และการอ้างอิงถึงใบรับรองอื่นๆ ที่ใช้สำหรับการเชื่อมโยง พวกเขาสามารถเผยแพร่ข้ามเครือข่ายและตรวจสอบว่าห่วงโซ่เป้าหมายตรงตามเกณฑ์ที่กำหนด
ใช้ตรรกะที่ซับซ้อนโดยใช้รีโซลเวอร์: รีโซลเวอร์ (การตั้งค่าเสริม) เข้ามามีบทบาท สามารถเรียกได้ในระหว่างการสร้างโมดูล การสร้างหลักฐาน และการรื้อถอน ตัวแยกวิเคราะห์เหล่านี้ช่วยให้นักพัฒนาสามารถรวมตรรกะที่ซับซ้อนและหลากหลายในขณะที่ยังคงรักษาโครงสร้างการพิสูจน์ได้
การเข้าถึงแบบสอบถามที่เป็นมิตรต่อผู้ใช้ (แบบสอบถาม): แบบสอบถามช่วยให้ผู้ใช้สามารถเข้าถึงข้อมูลที่ปลอดภัยจากส่วนหน้าได้
แม้ว่าโมเดลนี้ยังอยู่ในช่วงเริ่มต้น แต่ก็มีศักยภาพในการสร้างมาตรฐานในลักษณะการกระจายอำนาจและการทำงานร่วมกัน รายการทะเบียนช่วยให้นักพัฒนาสามารถลงทะเบียนโมดูลของตน ผู้ตรวจสอบเพื่อตรวจสอบความปลอดภัย กระเป๋าเงินที่จะบูรณาการ และผู้ใช้สามารถค้นหาโมดูลและตรวจสอบข้อมูลการรับรองได้อย่างง่ายดาย การใช้งานในอนาคตหลายประการอาจเป็น:
ผู้รับรอง: หน่วยงานที่เชื่อถือได้เช่น Safe สามารถทำงานร่วมกับ Rhinestone เพื่อทำหน้าที่เป็นผู้รับรองสำหรับโมดูลภายในได้ ในขณะเดียวกัน ผู้รับรองอิสระก็สามารถเข้าร่วมได้เช่นกัน
นักพัฒนาโมดูล: ด้วยการก่อตัวของตลาดเปิด เป็นไปได้ที่นักพัฒนาโมดูลจะสร้างรายได้จากงานของตนผ่านการลงทะเบียน
ผู้ใช้: เข้าร่วมผ่านอินเทอร์เฟซที่เป็นมิตรต่อผู้ใช้ เช่น กระเป๋าเงินหรือ dApp ซึ่งผู้ใช้สามารถตรวจสอบข้อมูลโมดูลและมอบความไว้วางใจให้กับผู้พิสูจน์ต่างๆ
แนวคิดของ การลงทะเบียนโมดูล จะเปิดช่องทางการทำกำไรสำหรับนักพัฒนาปลั๊กอินและโมดูล มันสามารถปูทางไปสู่ ตลาดโมดูล ต่อไปได้ บางแง่มุมอาจได้รับการดูแลโดยทีมงาน Safe ในขณะที่บางแง่มุมอาจปรากฏเป็นตลาดที่มีการกระจายอำนาจ โดยเชิญชวนให้ทุกคนมีส่วนร่วมและให้แนวทางการตรวจสอบที่โปร่งใส การผสานรวมสิ่งนี้จะช่วยหลีกเลี่ยงการผูกมัดผู้ขายและสนับสนุนการขยายตัวของ EVM โดยการเพิ่มประสบการณ์ผู้ใช้ที่ได้รับการปรับปรุงซึ่งดึงดูดผู้ชมในวงกว้าง
แม้ว่าวิธีการเหล่านี้จะรักษาความปลอดภัยให้กับแต่ละโมดูล แต่บัญชีสัญญาอัจฉริยะก็ไม่สามารถป้องกันความผิดพลาดได้เมื่อพูดถึงเรื่องความปลอดภัยที่กว้างขึ้น การบูรณาการกับโมดูลการปฏิบัติตามกฎระเบียบและการพิสูจน์ว่าไม่มีข้อขัดแย้งในการจัดเก็บข้อมูลอาจเป็นเรื่องท้าทาย ซึ่งเน้นย้ำถึงความสำคัญของกระเป๋าสตางค์หรือโครงสร้างพื้นฐาน AA ในการแก้ปัญหาดังกล่าว
สรุป
ด้วยการใช้ประโยชน์จากสแต็กบัญชีสัญญาอัจฉริยะแบบโมดูลาร์ ผู้ให้บริการกระเป๋าเงินและ dApps จะสามารถหลุดพ้นจากความซับซ้อนของการบำรุงรักษาทางเทคนิคได้ ในเวลาเดียวกัน นักพัฒนาโมดูลภายนอกมีโอกาสที่จะให้บริการระดับมืออาชีพส่วนบุคคล อย่างไรก็ตาม ความท้าทายที่ต้องแก้ไข ได้แก่ การสร้างสมดุลระหว่างความยืดหยุ่นและความปลอดภัย การขับเคลื่อนมาตรฐานแบบโมดูลาร์ และการใช้อินเทอร์เฟซมาตรฐานที่ช่วยให้ผู้ใช้สามารถอัปเกรดและแก้ไขบัญชีอัจฉริยะได้อย่างง่ายดาย
นอกจากนี้ บัญชีสัญญาอัจฉริยะแบบโมดูลาร์ (SCA) เป็นเพียงส่วนเล็กๆ ของปริศนาในการนำไปใช้ เพื่อให้ตระหนักถึงศักยภาพของ SCA อย่างเต็มที่ โซลูชันเลเยอร์ 2 จำเป็นต้องให้การสนับสนุนเลเยอร์โปรโตคอลเพิ่มเติม เช่น โครงสร้างพื้นฐาน Bundler ที่แข็งแกร่งและพูลหน่วยความจำแบบ peer-to-peer กลไกลายเซ็น SCA ที่คุ้มค่าและเป็นไปได้มากขึ้น SCA แบบข้ามสายโซ่ กลไกการซิงโครไนซ์และการจัดการ และพัฒนาส่วนต่อประสานที่ใช้งานง่าย
ในอนาคต จะมีการนำ SCA มาใช้มากขึ้น แต่ก็ทำให้เกิดคำถามที่น่าสนใจเช่นกัน: เมื่อลำดับคำสั่งของ SCA มีผลกำไรเพียงพอ กลไก Miner Extractable Value (MEV) แบบดั้งเดิมจะเข้าสู่พื้นที่เพื่อสร้าง Bundlers และรับมูลค่าได้อย่างไร เมื่อโครงสร้างพื้นฐานครบกำหนด Account Abstraction (AA) จะทำหน้าที่เป็นชั้นฐานสำหรับธุรกรรม ตามเจตนา ได้อย่างไร ให้เรารอดูกัน
