ชื่อเรื่องเดิม: การรักษาความปลอดภัยการอัปเกรด EIP-7702: รูปแบบพร็อกซีสำหรับการเปลี่ยนผ่านจาก EOA ไปเป็น Smart Wallet อย่างปลอดภัย

ผู้เขียนต้นฉบับ: Amie Corso
การแปลต้นฉบับ: Foresight News

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

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

เพื่อให้ EOA สามารถทำหน้าที่เป็นกระเป๋าเงินสัญญาอัจฉริยะ เราได้พัฒนา EIP7702Proxy ซึ่งเป็นสัญญาพร็อกซี ERC-1967 น้ำหนักเบาที่ออกแบบมาเพื่อใช้เป็นการมอบหมาย EIP-7702 สำหรับ EOA นอกเหนือจากการส่งต่อตรรกะพื้นฐานที่ดำเนินการโดยพร็อกซีแล้ว EIP7702Proxy ยังมีคุณสมบัติและตัวเลือกการออกแบบอื่นๆ ที่แก้ไขปัญหาเฉพาะบางอย่างของบัญชีที่ได้รับมอบหมาย EIP-7702 เป้าหมายประการหนึ่งของการออกแบบ EIP7702Proxy คือการรักษาสมดุลให้มากที่สุดระหว่าง Coinbase Smart Wallet "ที่ปรับใช้ตามมาตรฐาน" และ Coinbase Smart Wallet ที่มอบหมาย EIP-7702 ซึ่งหมายถึงการแยกความซับซ้อนเพิ่มเติมที่จำเป็นโดยกลไก EIP-7702 ลงในพร็อกซีเฉพาะและยังคงพึ่งพาการใช้งานดั้งเดิมของ CoinbaseSmartWallet โซลูชันสำหรับความท้าทายนี้สามารถนำไปใช้กับตรรกะการใช้งานใดๆ ได้อย่างมีประสิทธิภาพ ไม่ใช่แค่การใช้งาน CoinbaseSmartWallet เท่านั้น ในขณะที่ช่วยให้ EOA ปลอดภัยในสภาพแวดล้อมที่เปิดใช้งาน 7702 ได้ด้วย

ด้านล่างนี้ เราจะอธิบายถึงความท้าทายเฉพาะเจาะจงและแนวทางการออกแบบที่สอดคล้องกัน ซึ่งช่วยให้เราปรับใช้การใช้งานกระเป๋าเงินสัญญาอัจฉริยะที่มีอยู่ได้อย่างปลอดภัยเพื่อใช้กับการอัปเกรด EIP-7702

ความท้าทายที่ 1: การบังคับใช้การเริ่มต้นที่ปลอดภัย

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

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

วิธีแก้ปัญหา: ต้องใช้ลายเซ็น EOA เพื่อตั้งค่าการใช้งานและการเริ่มต้นโดยอัตโนมัติ

โปรดทราบว่า Coinbase Smart Wallet ที่มีอยู่ถูกปรับใช้ภายใต้พร็อกซี ERC-1967 พร้อมการใช้งาน UUPSUpgradeable (ตรรกะ CoinbaseSmartWallet จริง) โค้ดในที่อยู่บัญชีจริงคือพร็อกซีที่ใช้ตำแหน่งจัดเก็บปกติที่กำหนดโดย ERC-1967 เพื่อจัดเก็บตัวชี้ไปยังตรรกะการใช้งาน วิธีแก้ปัญหาช่องโหว่การเริ่มต้นระบบในบริบทของ 7702 ของเราเกี่ยวข้องกับการรับรู้ว่าตรรกะการใช้งานใดๆ ก็ตามจะเปิดใช้งานได้ (และจึงเป็นอันตราย) เมื่อพร็อกซีสร้างการเชื่อมต่อกับมันจริงๆ ดังนั้น หากเราไม่สามารถบังคับใช้การปรับใช้และการเริ่มต้นระบบแบบอะตอม เราสามารถบังคับใช้การตั้งค่าการใช้งานแบบอะตอมและการเริ่มต้นระบบได้

สถาปัตยกรรมสัญญา EIP-7702CoinbaseSmartWallet และกระบวนการมอบหมายตรรกะ

ในบริบทของ EIP-7702 EOA เองเป็นผู้มีอำนาจเริ่มต้นในการทำการเปลี่ยนแปลงใดๆ กับบัญชีของตน และต้องจัดเตรียมลายเซ็นเพื่ออนุญาตให้เจ้าของใดๆ เริ่มต้นและสร้างบัญชีอัจฉริยะใหม่ สัญญา EIP7702Proxy ของเราใช้ฟังก์ชัน setImplementation ที่ตั้งค่าการใช้งานเชิงตรรกะใหม่โดยอัตโนมัติและเริ่มต้นบัญชี ฟังก์ชัน setImplementation:

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

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

ความท้าทายที่ 2: พื้นที่จัดเก็บที่ใช้ร่วมกันระหว่างผู้แทน EIP-7702

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

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

ตัวอย่างของสถานะที่ไม่ถูกต้องสำหรับผู้แทน A ที่เกิดจากรูปแบบการมอบหมาย A → B → A

วิธีแก้ไข: การนำค่าที่เก็บไว้ซึ่งมีความสำคัญต่อความปลอดภัยภายนอก

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

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

การป้องกันทั่วไปต่อการเล่นซ้ำลายเซ็นคือการใช้ nonce ในข้อความการลงนามและทำเครื่องหมายว่าใช้หลังจากตรวจสอบแล้ว ความเสี่ยงต่อบัญชี 7702: การมอบหมายอื่นอาจทำให้ที่เก็บข้อมูลการติดตาม nonce นี้เสียหายได้ หากลบการใช้ nonce ในการติดตามที่เก็บข้อมูล ลายเซ็น setImplementation ของ EOA (ซึ่งเปิดเผยต่อสาธารณะใน mempool) อาจนำมาใช้ใหม่เมื่อมอบหมายกลับไปยัง EIP7702Proxy

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

ความท้าทายที่ 3: ความเสี่ยงที่เพิ่มขึ้นของการแบ่งปันตำแหน่งจัดเก็บแบบดั้งเดิม

ช่องเก็บข้อมูลมาตรฐาน เช่น ช่องที่กำหนดโดย ERC-1967 นั้นมีความเสี่ยงต่อข้อขัดแย้งในการจัดเก็บเป็นพิเศษ เนื่องจากเป็นตำแหน่งทั่วไปที่การใช้งานตัวแทนหลายรายการอาจใช้ ช่องเก็บข้อมูลมาตรฐาน ERC-1967 เป็นตำแหน่งเก็บข้อมูลมาตรฐานเพียงตำแหน่งเดียวที่ใช้ใน EIP7702Proxy และจะจัดเก็บที่อยู่ของการใช้งานลอจิกที่พร็อกซีชี้ไป การออกแบบของเรารับประกันว่าไม่ว่าค่าของตำแหน่งเก็บข้อมูลนี้จะมีค่าเท่าใด (ซึ่งกำหนดลอจิกส่วนใหญ่ที่มีในบัญชี) EIP7702Proxy จะสามารถตั้งค่าลอจิกการใช้งานให้ตรงกับสัญญาที่ EOA คาดหวังไว้ได้สำเร็จเสมอ

เพื่อให้ชัดเจนขึ้นว่ากำลังแก้ปัญหาอะไรอยู่ โปรดทราบว่าเมื่อบัญชีเปลี่ยนผ่านระหว่างตัวแทนที่แตกต่างกัน (A→B→A) โดยที่ตัวแทนทั้งสองใช้งานรูปแบบพร็อกซี ERC-1967 ตัวแทน B จะใช้ช่องเก็บข้อมูลเดียวกันกับที่ตัวแทน A ใช้เพื่อจัดเก็บที่อยู่การใช้งานโดยธรรมชาติ ในระหว่างระยะเวลา ผู้แทน B อาจแก้ไขหรือเขียนทับสล็อตนี้โดยตั้งใจหรือเป็นส่วนปกติของพร็อกซีของตัวเอง ในรูปแบบพร็อกซี UUPSUpgradeable ตรรกะสำหรับการอัปเกรดการใช้งานจะถูกกำหนดไว้ในสัญญาการใช้งานนั้นเอง หากการใช้งานที่ผู้แทน B วางไว้ในตำแหน่งจุดนี้ไม่มีอินเทอร์เฟซ upgradeToAndCall ที่คาดไว้ในการใช้งาน เมื่อส่งกลับไปยังผู้แทน A กลไกในการเปลี่ยนแปลงการใช้งานอาจไม่มีอยู่ในตรรกะที่มีอยู่ในปัจจุบัน

ตัวอย่างของผู้แทนใหม่เขียนทับตำแหน่งจัดเก็บข้อมูลแบบเดิมที่ใช้ร่วมกัน

วิธีแก้ไข: กลไกการอัปเกรดที่มีใน EIP7702Proxy

EIP7702Proxy ของเราแก้ปัญหานี้ผ่านฟังก์ชัน setImplementation ซึ่งจัดเตรียมกลไกการอัปเกรดที่ไม่ขึ้นกับการใช้งานโดยตรงบนพร็อกซีเอง สิ่งนี้จะช่วยให้แน่ใจว่าแม้ว่าผู้มอบหมายระดับกลางได้ชี้การใช้งาน ERC-1967 ไปยังการใช้งานที่ไม่ถูกต้อง (หรือลบออกไปทั้งหมด) หลังจากมอบหมายกลับไปยัง EIP7702Proxy แล้ว EOA เดิมจะยังรักษาความสามารถในการกำหนดค่าตัวชี้ ERC-1967 ของพร็อกซีใหม่เพื่อชี้ไปยังการใช้งานเชิงตรรกะที่พวกเขาเลือก

ความท้าทายที่ 4: ความเข้ากันได้แบบย้อนหลังกับการทำงานของ EOA มาตรฐาน

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

การตรวจสอบลายเซ็น

มาตรฐานการตรวจสอบลายเซ็นสำหรับสัญญาอัจฉริยะนั้นแตกต่างจาก EOA มาตรฐาน สัญญาอัจฉริยะใช้อินเทอร์เฟซ isValidSignature ที่กำหนดโดย ERC-1271 และสามารถกำหนดตรรกะตามอำเภอใจได้อย่างอิสระเพื่อพิจารณาว่าสัญญาถือว่าลายเซ็นนั้นถูกต้องหรือไม่ สำหรับ EOA มาตรฐาน ลายเซ็นจะได้รับการตรวจสอบผ่านการตรวจสอบ ecrecover มาตรฐาน ซึ่งรับประกันว่าผู้ลงนามจะกลับไปยังที่อยู่ EOA ที่คาดไว้

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

การรับโทเค็น

มาตรฐานโทเค็นบางมาตรฐาน (โดยเฉพาะ ERC-1155 และ ERC-721) พยายามป้องกันไม่ให้โทเค็นติดอยู่ในสัญญาอัจฉริยะที่อาจไม่สามารถจัดการได้ โทเค็นเหล่านี้ต้องการให้สัญญาอัจฉริยะใดๆ ก็ตามที่จะรับโทเค็นดังกล่าวโฆษณาความสามารถนี้โดยนำอินเทอร์เฟซตัวรับโทเค็นมาตรฐานมาใช้ ซึ่งสัญญาโทเค็นจะเรียกใช้ระหว่างการโอนโทเค็น นอกจากนี้ ยังมีความสำคัญที่ตรรกะบน EOA ที่อัปเกรดแล้วจะต้องมีฟังก์ชันการรับมาตรฐานหรือฟังก์ชันสำรองที่ต้องชำระเพื่อให้สามารถรับโทเค็นดั้งเดิมได้ บัญชีไม่ควรถูกปล่อยให้อยู่ในสถานะที่ไม่สามารถรับ ETH หรือโทเค็นอื่นๆ ได้ แม้ว่าจะเป็นระยะเวลาสั้นๆ ก็ตาม

เนื่องจากพร็อกซีของเราไม่มีการใช้งานเริ่มต้น เราจึงรวมการใช้งาน DefaultReceiver ที่ไม่เปลี่ยนแปลงเป็นตรรกะเริ่มต้นสำหรับ EIP7702Proxy ในกรณีที่ไม่มีตัวบ่งชี้ ERC-1967 ตัวรับนี้จะนำฟังก์ชันการรับและการเชื่อมต่อตัวรับมาตรฐานไปใช้กับโทเค็นทั่วไปเหล่านี้ เพื่อให้แน่ใจว่าบัญชีต่างๆ สามารถยอมรับการโอนโทเค็นได้ก่อนที่จะตั้งค่าการใช้งานใหม่โดยชัดเจน

บทสรุป

การออกแบบ EIP7702Proxy ช่วยให้เราสามารถรักษาความสอดคล้องอย่างใกล้ชิดกับ CoinbaseSmartWallets ที่ใช้งานมาตรฐาน และยังคงใช้การใช้งาน CoinbaseSmartWallet ที่มีอยู่ได้ในขณะที่จัดการกับความท้าทายด้านความปลอดภัยเฉพาะตัวที่เกิดขึ้นในบริบทของ EIP-7702 ด้วยการพิจารณาความปลอดภัยในการเริ่มต้น ผลกระทบของระยะเวลาในการจัดเก็บและการรบกวน ความจำเป็นในการจัดการโทเค็นอย่างไม่หยุดชะงัก และความเข้ากันได้ย้อนหลังกับการตรวจสอบลายเซ็น EOA มาตรฐาน เราได้สร้างพร็อกซีสำหรับการมอบหมายและจัดการกระเป๋าสตางค์สัญญาอัจฉริยะ EIP-7702 อย่างปลอดภัย แม้ว่า EIP7702Proxy จะได้รับการออกแบบโดยคำนึงถึงการใช้งาน CoinbaseSmartWallet V1 แต่พร็อกซีนี้จะไม่ขึ้นอยู่กับการใช้งานจริง เราขอแนะนำให้ผู้พัฒนาประเมินโซลูชันนี้เพื่อป้องกันการใช้งานกระเป๋าสตางค์สัญญาอัจฉริยะอื่นๆ ด้วย 7702

ลิงก์ต้นฉบับ

ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App

บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia