การแยกบัญชี (Account Abstraction: AA) เป็นแนวทางสำคัญสำหรับการสำรวจระบบนิเวศ Ethereum ในระยะยาว โดยมุ่งหวัง ที่จะทำลายขอบเขตระหว่างบัญชีภายนอก (External Account: EOA) และบัญชีสัญญา ทำให้กระเป๋าเงินสามารถเขียนโปรแกรมได้ ปลอดภัย และอัปเกรดได้มากขึ้น เนื่องจาก EIP-4337 เป็นโซลูชันการนำ AA ไปใช้อย่างแพร่หลาย จึงถูกใช้กันอย่างแพร่หลายในกระเป๋าเงินสัญญาอัจฉริยะจำนวนมากที่ใช้ EntryPoint (เช่น Safe, Stacks, Argent) อย่างไรก็ตาม EIP-4337 ยังคงมีข้อจำกัดบางประการในแง่ของความเป็นเนทีฟบนเชน ความซับซ้อนในการดำเนินการ และความเข้ากันได้ทางระบบนิเวศ เนื่องจาก EIP-4337 แนะนำกลุ่มธุรกรรมอิสระและกลไกสัญญาการเข้า
เพื่อลดเกณฑ์สำหรับการใช้การแยกบัญชีและปรับปรุงการรองรับดั้งเดิม Vitalik จึงเสนอ EIP-7702 ในปี 2024 และรวมข้อเสนอนี้ไว้ในการอัปเกรด Pectra แนวคิดหลักของ EIP-7702 คือการอนุญาตให้ EOA ดั้งเดิมดำเนินการรหัสสัญญา (contract_code) ของที่อยู่ที่ระบุเมื่อเริ่มต้นธุรกรรม และใช้รหัสนี้เพื่อกำหนดตรรกะการดำเนินการของธุรกรรม
EIP-7702 แนะนำกลไกใหม่ของ การใส่รหัสในระดับธุรกรรม ซึ่งช่วยให้ บัญชีผู้ใช้สามารถระบุตรรกะการดำเนินการในแต่ละธุรกรรมได้อย่างไดนามิกแทนที่จะต้องพึ่งพารหัสสัญญาที่ปรับใช้ไว้ล่วงหน้า วิธีนี้ทำลายรูปแบบการอนุญาตแบบเดิมที่อิงตามรหัสคงที่ เพิ่มความยืดหยุ่นมากขึ้น และยัง นำไปสู่ความท้าทายด้านความปลอดภัยใหม่ๆ อีกด้วย สัญญาที่เดิมพึ่งพาตรรกะการตัดสิน เช่น isContract และ extcodehash อาจกลายเป็นโมฆะ และระบบบางระบบที่ถือว่าผู้เรียกเป็น EOA ล้วนๆ ก็อาจถูกข้ามได้เช่นกัน สำหรับผู้ตรวจสอบ จำเป็นต้องไม่เพียงแต่ ตรวจสอบความปลอดภัยของรหัสที่ใส่เข้าไปเท่านั้น แต่ยัง ต้องประเมินผลกระทบที่อาจเกิดขึ้นกับระบบสัญญาอื่นๆ ในบริบทไดนามิกด้วย
ในบทความนี้ ทีมงานด้านความปลอดภัยของ Beosin จะ มุ่งเน้นไปที่หลักการออกแบบและคุณลักษณะสำคัญของ EIP-7702 คัดแยกความเสี่ยงด้านความปลอดภัยที่กระเป๋าสตางค์ AA ที่สร้างขึ้นโดยใช้ EIP-7702 อาจเผชิญในระหว่างการตรวจสอบอย่างเป็นระบบ และ เสนอกระบวนการตรวจสอบและข้อเสนอแนะ จากมุมมองเชิงปฏิบัติเพื่อช่วยให้นักวิจัยด้านความปลอดภัยรับมือกับความท้าทายทางเทคนิคภายใต้กรอบแนวคิดใหม่นี้ได้ดีขึ้น
1. บทนำสู่ EIP-7702
1. ภาพรวมทางเทคนิคของ EIP-7702
EIP-7702 แนะนำประเภทธุรกรรมใหม่ 0x 04 (SetCode) ซึ่งช่วยให้ EOA สามารถอนุญาตให้ดำเนินการรหัสสัญญาผ่านธุรกรรมนี้ได้ โครงสร้างธุรกรรมมีดังนี้:
rlp([chain_id, nonce, ค่าธรรมเนียมลำดับความสำคัญสูงสุดต่อก๊าซ, ค่าธรรมเนียมสูงสุดต่อก๊าซ, ขีดจำกัดก๊าซ,
จุดหมายปลายทาง, ค่า, ข้อมูล, รายการการเข้าถึง, รายการการอนุญาต, ลายเซ็น_y_parity, ลายเซ็น_r, ลายเซ็น_s])
authorization_list ประกอบด้วยรายการการอนุญาตหลายรายการ และยังสามารถประกอบด้วยพฤติกรรมการอนุญาตของผู้ริเริ่มที่ไม่ใช่ธุรกรรม โครงสร้างภายในมีดังนี้:
authorization_list = [[chain_id, address, nonce, y_parity, r, s]]
ในจำนวนนี้ chain_id ระบุถึงเชนที่การอนุญาตของผู้ใช้มีผล และค่าของ chain_id จะต้องเท่ากับรหัสเชนของเชนการดำเนินการหรือ 0 เมื่อ chain_id เป็น 0 แสดงว่าการอนุญาตมีผลกับเชน EVM ทั้งหมดที่รองรับ EIP-7702 แต่ต้องมีการตั้งสมมติฐานว่าพารามิเตอร์อื่นๆ (เช่น nonce) จะต้องตรงกัน Address ระบุที่อยู่ของสัญญาเป้าหมายที่ได้รับอนุญาตจากผู้ใช้
เมื่อการอนุญาตเสร็จสิ้นแล้ว ระบบจะแก้ไขฟิลด์รหัสผู้ใช้ที่ได้รับอนุญาตเป็น 0x ef 0100 || address โดยที่ address คือที่อยู่สัญญาที่ได้รับอนุญาต หากคุณต้องการยกเลิกการอนุญาต เพียงเริ่มธุรกรรม SetCode เพื่อตั้งค่าที่อยู่เป็น 0 address
2. ข้อดีของ EIP 7702
(1) ความยืดหยุ่นและการปรับแต่ง
บัญชีนามธรรมสามารถปรับแต่งฟังก์ชันต่างๆ ตามความต้องการได้อย่างยืดหยุ่นโดยเขียนลอจิกของบัญชีลงในสัญญาอัจฉริยะ ตัวอย่างเช่น ผู้ใช้สามารถกำหนดค่าลายเซ็นหลายรายการ การกู้คืนโซเชียล การควบคุมขีดจำกัด ฯลฯ เพื่อตอบสนองความต้องการในสถานการณ์ต่างๆ สำหรับบุคคลหรือองค์กร การออกแบบนี้ช่วยปรับปรุงความสามารถในการปรับขนาดฟังก์ชันการทำงานของบัญชีได้อย่างมาก และ ทำลายข้อจำกัดของบัญชีภายนอกแบบเดิม (EOA)
(2) เพิ่มความปลอดภัย
บัญชีนามธรรมมี กลไกการรักษาความปลอดภัยหลายชั้น รวมถึงการตรวจสอบสิทธิ์หลายปัจจัย การจำกัดธุรกรรม และการกู้คืนโซเชียล แม้ว่าผู้ใช้จะสูญเสียคีย์ส่วนตัวไป ก็สามารถกู้คืนบัญชีของตนได้ผ่านผู้ติดต่อที่เชื่อถือได้หรือการตรวจสอบสิทธิ์หลายปัจจัย จึงหลีกเลี่ยงการสูญเสียทรัพย์สินถาวรที่เกิดจากการสูญเสียคีย์ส่วนตัวในบัญชีแบบเดิมได้ ในเวลาเดียวกัน ฟังก์ชันต่างๆ เช่น การควบคุมขีดจำกัดยังสามารถป้องกันไม่ให้เงินจำนวนมากถูกขโมยไปโดยเจตนาได้อีกด้วย
(3) การเพิ่มประสิทธิภาพก๊าซ
บัญชีแบบ Abstract รองรับกลไกการแยก Gas ที่มีความยืดหยุ่น ช่วยให้ผู้ใช้ชำระค่า Gas ผ่านบุคคลที่สาม หรือแม้แต่ใช้โทเค็นอื่นโดยตรงเพื่อชำระค่าธรรมเนียมธุรกรรม กลไกนี้ไม่เพียงแต่ช่วยลดต้นทุนการดำเนินงานของผู้ใช้เท่านั้น แต่ยังทำให้กระบวนการใช้งานบล็อคเชนง่ายขึ้นอีกด้วย โดยเฉพาะอย่างยิ่งสำหรับผู้ใช้มือใหม่หรือสถานการณ์ธุรกรรมหลายขั้นตอนที่ซับซ้อน
(4) ส่งเสริมการเผยแพร่ Web3
การปรับปรุงประสบการณ์และความปลอดภัยทำให้บัญชีนามธรรมซ่อนความซับซ้อนของบล็อคเชนจากผู้ใช้ ทำให้การทำงานสะดวกใกล้เคียงกับ Web2 การออกแบบนี้ช่วยลดต้นทุนการเรียนรู้สำหรับผู้ใช้ทั่วไป ทำให้ผู้คนจำนวนมากขึ้นสามารถเข้าร่วมในแอปพลิเคชัน Web3 โดยไม่มีอุปสรรค และส่งเสริมการเผยแพร่เทคโนโลยีแบบกระจายอำนาจ
2. การวิเคราะห์ความเสี่ยงด้านความปลอดภัยในการปฏิบัติ EIP-7702
แม้ว่า EIP-7702 จะสร้างแรงผลักดันใหม่ให้กับระบบนิเวศ Ethereum และขยายสถานการณ์การใช้งานของมัน แต่ก็ยัง ทำให้เกิดความเสี่ยงด้านความปลอดภัยใหม่ๆ ตามมาอย่างหลีกเลี่ยงไม่ได้:
1. การโจมตีด้วยการอนุญาตเล่นซ้ำ
ภายใต้โมเดล EIP-7702 หากผู้ใช้ตั้งค่าฟิลด์ chain_id ในการอนุญาตเป็น 0 แสดง ว่าการอนุญาตนั้นถูกต้องบนเชนหลายเชน แม้ว่าการออกแบบ การอนุญาตสากลแบบข้ามเชน นี้จะช่วยปรับปรุงความยืดหยุ่นในบางสถานการณ์ แต่ก็ยังก่อให้เกิดความเสี่ยงด้านความปลอดภัยที่ชัดเจนอีกด้วย
สิ่งสำคัญที่ต้องทราบคือ แม้ว่า ID บัญชีของที่อยู่เดียวกันบนเชนที่แตกต่างกันจะเหมือนกัน แต่การใช้งานสัญญาพื้นฐานอาจแตกต่างกันอย่างสิ้นเชิง ซึ่งหมายความว่า ผู้โจมตีอาจใช้สัญญาเวอร์ชันที่เป็นอันตรายบนเชนอื่นและใช้พฤติกรรมการอนุญาตของที่อยู่เดียวกันบนเชนเพื่อดำเนินการที่ไม่คาดคิด จึงก่อให้เกิดความเสี่ยงต่อทรัพย์สินของผู้ใช้
ดังนั้น สำหรับผู้ให้บริการกระเป๋าสตางค์หรือแพลตฟอร์มอินเทอร์แอคทีฟแบบฟรอนท์เอนด์ เมื่อผู้ใช้ดำเนินการอนุญาตดังกล่าว พวกเขาควรตรวจสอบอย่างชัดเจนว่า chainId ที่ประกาศไว้ในการอนุญาตผู้ใช้สอดคล้องกับเครือข่ายที่เชื่อมต่ออยู่ในปัจจุบัน หรือไม่ หากตรวจพบว่าผู้ใช้ตั้งค่า chainId ไว้ที่ 0 ควรมีการแจ้งเตือนความเสี่ยงที่ชัดเจนเพื่อ เตือนผู้ใช้ว่าการอนุญาตจะมีผลกับเชนที่เข้ากันได้กับ EVM ทั้งหมด และอาจถูกละเมิดโดยสัญญาที่เป็นอันตรายได้
นอกจากนี้ ผู้ให้บริการควร ประเมินด้วยว่าควรจำกัดหรือห้ามการอนุญาตโดยใช้ chainId 0 ตามค่าเริ่มต้นที่เลเยอร์ UI เพื่อลดความเสี่ยงจากการทำงานผิดพลาดหรือการโจมตีแบบฟิชชิ่ง
2. ปัญหาความเข้ากันได้ของสัญญา
(1) ความเข้ากันได้ของการโทรกลับสัญญา
เมื่อโอนเงินไปยังที่อยู่สัญญา ERC-721, ERC-777, ERC 1155 และสัญญาโทเค็นอื่นๆ ที่มีอยู่จะเรียกใช้อินเทอร์เฟซคอลแบ็กมาตรฐาน (เช่น onERC 721 Received, tokensReceived) เพื่อดำเนินการโอนให้เสร็จสมบูรณ์ หากที่อยู่ผู้รับไม่นำอินเทอร์เฟซที่เกี่ยวข้องไปใช้ การโอนจะล้มเหลวหรืออาจส่งผลให้สินทรัพย์ถูกล็อก
ใน EIP-7702 สามารถกำหนดรหัสสัญญาให้กับที่อยู่ของผู้ใช้สามารถดำเนินการ set_code ได้ จึงทำให้กลายเป็นบัญชีสัญญา ในขณะนี้:
ที่อยู่ของผู้ใช้ถือเป็นสัญญา
หากสัญญาไม่ดำเนินการตามอินเทอร์เฟซการโทรกลับที่จำเป็น การโอนโทเค็นจะล้มเหลว
ผู้ใช้บางรายอาจไม่สามารถรับโทเค็นกระแสหลักได้หากไม่ทราบ
ดังนั้น นักพัฒนาควรตรวจสอบให้แน่ใจว่าสัญญาเป้าหมายที่มอบหมายโดยผู้ใช้ได้ใช้งานอินเทอร์เฟซการโทรกลับที่เกี่ยวข้องเพื่อให้แน่ใจถึงความเข้ากันได้กับโทเค็นหลัก
(2) ความล้มเหลวในการตรวจสอบ tx.origin
ในสัญญาแบบเดิม มักใช้ tx.origin เพื่อพิจารณาว่าผู้ใช้เป็นผู้เริ่มธุรกรรมโดยตรงหรือไม่ และใช้เพื่อป้องกันการควบคุมความปลอดภัย เช่น การเรียกสัญญา
แต่ในสถานการณ์ EIP-7702:
ผู้ใช้ลงนามในธุรกรรมการอนุญาตซึ่งจะถูกออกอากาศโดยผู้ถ่ายทอดหรือผู้รวมข้อมูล เมื่อดำเนินการธุรกรรม tx.origin จะเป็นที่อยู่ของผู้ถ่ายทอดข้อมูล ไม่ใช่ที่อยู่ของผู้ใช้
“msg.sender” คือสัญญากระเป๋าสตางค์ที่แสดงถึงข้อมูลประจำตัวผู้ใช้
ดังนั้น การตรวจสอบสิทธิ์โดยอิงตาม tx.origin == msg.sender จะส่งผลให้การดำเนินการของผู้ใช้โดยชอบธรรมถูกปฏิเสธ และสูญเสียความน่าเชื่อถือ ในทำนองเดียวกัน ข้อจำกัดในการเรียกใช้สัญญา เช่น tx.origin == user ก็จะล้มเหลวเช่นกัน ขอแนะนำให้ละทิ้ง tx.origin เป็นพื้นฐานในการตัดสินด้านความปลอดภัย และใช้กลไกการตรวจสอบลายเซ็นหรือการอนุญาตแทน
(3) การตัดสินผิดเกี่ยวกับ สัญญา
สัญญาจำนวนมากใช้ isContract(address) (การตรวจสอบความยาวรหัสที่อยู่) เพื่อป้องกันไม่ให้บัญชีสัญญามีส่วนร่วมในการดำเนินการบางอย่าง เช่น การแอร์ดรอป การสแนปอัป ฯลฯ:
require(!isContract(msg.sender), สัญญาไม่ได้รับอนุญาต)
ภายใต้กลไก EIP-7702 ที่อยู่ของผู้ใช้สามารถเปลี่ยนเป็นบัญชีสัญญาได้ผ่านธุรกรรม set_code และ isContract คืนค่าเป็นจริง สัญญาจะระบุผู้ใช้ที่ถูกต้องตามกฎหมายเป็นบัญชีสัญญาโดยผิดพลาดและปฏิเสธไม่ให้ผู้ใช้เข้าร่วมในการดำเนินการ ส่งผลให้ผู้ใช้ไม่สามารถใช้บริการบางอย่างได้และ ประสบการณ์ที่ได้รับจะได้รับผลกระทบ
เนื่องจากกระเป๋าสตางค์แบบมีสัญญาได้รับความนิยมมากขึ้น การออกแบบที่ต้องอาศัย isContract เพื่อระบุว่าเป็นผู้ใช้จริงหรือไม่จึงไม่ปลอดภัยอีกต่อไป ขอแนะนำให้ใช้วิธีการระบุตัวตนของผู้ใช้ที่แม่นยำยิ่งขึ้น เช่น การตรวจสอบลายเซ็น
3. การโจมตีแบบฟิชชิ่ง
หลังจากนำ กลไกการมอบอำนาจ EIP-7702 มา ใช้ สินทรัพย์ในบัญชีผู้ใช้จะถูกควบคุมโดยสัญญาอัจฉริยะที่มอบอำนาจอย่างสมบูรณ์ เมื่อผู้ใช้ให้สิทธิ์สัญญาที่เป็นอันตราย ผู้โจมตีอาจใช้สัญญาดังกล่าวเพื่อควบคุมสินทรัพย์ในบัญชีทั้งหมด ส่งผลให้เงินถูกโอนหรือขโมยอย่างรวดเร็ว ซึ่งถือเป็นความเสี่ยงด้านความปลอดภัยที่สูงมาก
ดังนั้น จึงมีความจำเป็นอย่างยิ่งที่ผู้ให้บริการกระเป๋าสตางค์ จะต้องสนับสนุนการแยกวิเคราะห์ธุรกรรมประเภท EIP-7702 และกลไกการระบุความเสี่ยงโดยเร็วที่สุด เมื่อผู้ใช้ลงนามในธุรกรรมที่มอบหมาย ฟรอนต์เอนด์ควรแสดงที่อยู่ของสัญญาเป้าหมายอย่างชัดเจนและเด่นชัด และรวมข้อมูลเสริม เช่น แหล่งที่มาของสัญญาและข้อมูลการใช้งาน เพื่อช่วยให้ผู้ใช้ระบุการฟิชชิ่งหรือพฤติกรรมฉ้อโกงที่อาจเกิดขึ้นได้ ซึ่งจะช่วยลดความเสี่ยงในการลงนามผิด นอกจากนี้ บริการกระเป๋าสตางค์ควรผสานรวมความสามารถในการวิเคราะห์ความปลอดภัยอัตโนมัติสำหรับสัญญาเป้าหมาย เช่น การตรวจสอบสถานะโอเพนซอร์สของรหัสสัญญา การวิเคราะห์แบบจำลองการอนุญาต และการระบุการดำเนินการที่อาจเป็นอันตราย เพื่อช่วยให้ผู้ใช้ตัดสินใจได้อย่างปลอดภัยยิ่งขึ้นก่อนการอนุมัติ
สิ่งสำคัญโดยเฉพาะอย่างยิ่งที่ควรทราบคือ รูปแบบลายเซ็นที่มอบหมายซึ่งนำมาใช้โดย EIP-7702 นั้นไม่เข้ากันได้กับมาตรฐานลายเซ็น EIP-191 และ EIP-712 ที่มีอยู่ ลายเซ็นของรูปแบบนี้สามารถข้ามคำเตือนลายเซ็นเดิมและข้อความโต้ตอบของกระเป๋าสตางค์ได้อย่างง่ายดาย ซึ่ง ทำให้มีความเสี่ยงที่ผู้ใช้จะถูกหลอกให้ลงนามในการดำเนินการที่เป็นอันตรายเพิ่มมากขึ้น ดังนั้น การนำกลไกการจดจำและการประมวลผลของโครงสร้างลายเซ็นนี้มาใช้ในกระเป๋าสตางค์จึงถือเป็นจุดเชื่อมโยงสำคัญในการรับรองความปลอดภัยของผู้ใช้
4. ความเสี่ยงของสัญญากระเป๋าสตางค์
(1) การจัดการอนุญาตสัญญากระเป๋าสตางค์
สัญญากระเป๋าสตางค์ EIP-7702 จำนวนมากใช้สถาปัตยกรรมพร็อกซี (หรือสิทธิ์การจัดการในตัว) เพื่อรองรับการอัปเกรดตรรกะ อย่างไรก็ตาม การทำเช่นนี้ยังทำให้เกิด ความเสี่ยงในการจัดการสิทธิ์ ที่สูงกว่าด้วย หากสิทธิ์การอัปเกรดไม่ได้ถูกจำกัดอย่างเคร่งครัด ผู้โจมตีอาจแทนที่สัญญาการใช้งานและแทรกโค้ดที่เป็นอันตราย ส่งผลให้บัญชีผู้ใช้ถูกแทรกแซงหรือเงินถูกขโมย
เคล็ดลับความปลอดภัย:
ใช้การพิสูจน์ตัวตนด้วยลายเซ็นหลายลายเซ็น การตรวจสอบปัจจัยหลายแบบ หรือกลไกการล็อคเวลาเพื่อควบคุมสิทธิ์การอัปเกรด
การเปลี่ยนแปลงรหัสและการอนุญาตจะต้องผ่านการตรวจสอบและการยืนยันความปลอดภัยที่เข้มงวด
กระบวนการอัปเกรดเป็นแบบเปิดและโปร่งใสเพื่อให้แน่ใจว่าผู้ใช้มีสิทธิ์ที่จะทราบและมีส่วนร่วม
(2) ความเสี่ยงจากการขัดแย้งในการจัดเก็บข้อมูลและการแยกข้อมูล
สัญญากระเป๋าสตางค์รุ่นต่างๆ หรือผู้ให้บริการกระเป๋าสตางค์ที่แตกต่างกันอาจใช้ช่องเก็บข้อมูลเดียวกันซ้ำ หากผู้ใช้เปลี่ยนผู้ให้บริการกระเป๋าสตางค์หรืออัปเกรดตรรกะของกระเป๋า สตางค์ การใช้ช่องเก็บข้อมูลซ้ำจะนำไปสู่ความขัดแย้งของตัวแปรสถานะ การเขียนทับข้อมูล การอ่านผิดปกติ และปัญหาอื่นๆ ซึ่งอาจไม่เพียงทำลายการทำงานปกติของกระเป๋าสตางค์เท่านั้น แต่ยังทำให้สูญเสียเงินหรือสิทธิ์ใช้งานผิดปกติอีกด้วย
เคล็ดลับความปลอดภัย:
ใช้โซลูชันการแยกหน่วยเก็บข้อมูลเฉพาะ (เช่น มาตรฐาน EIP-1967) หรือใช้เนมสเปซที่ไม่ซ้ำกันเพื่อจัดการช่องเก็บข้อมูล
เมื่ออัปเกรดสัญญา โปรดตรวจสอบให้แน่ใจว่าเค้าโครงการจัดเก็บข้อมูลมีความเข้ากันได้เพื่อหลีกเลี่ยงการทับซ้อนของตัวแปร
ทดสอบความสมเหตุสมผลของสถานะการจัดเก็บข้อมูลอย่างเคร่งครัดในระหว่างกระบวนการอัปเกรด
(3) การจัดการ Nonce ภายในกระเป๋าสตางค์
สัญญาของกระเป๋าสตางค์มักจะตั้งค่า nonce ไว้ภายในและจัดการด้วยตัวเองเพื่อให้แน่ใจว่าลำดับการดำเนินการของผู้ใช้เป็นไปตามปกติและป้องกันการโจมตีแบบรีเพลย์ หากใช้ nonce อย่างไม่ถูกต้อง การดำเนินการของผู้ใช้จะไม่ถูกดำเนินการตามปกติ
เคล็ดลับความปลอดภัย:
Nonce จะต้องได้รับการตรวจสอบอย่างเคร่งครัดเพื่อความเท่าเทียม (หรือการเพิ่มขึ้น) และไม่สามารถข้ามได้
ห้ามไม่ให้ฟังก์ชันแก้ไข nonce โดยตรง Nonce จะได้รับการอัพเดตแบบซิงโครนัสเมื่อดำเนินการกับผู้ใช้เท่านั้น
ออกแบบการทนทานต่อข้อผิดพลาดและกลไกการกู้คืนสำหรับความผิดปกติของ nonce เพื่อหลีกเลี่ยงการหยุดชะงักของ nonce
(4) การตรวจสอบสิทธิ์การเรียกใช้ฟังก์ชัน
เพื่อให้มั่นใจถึงความปลอดภัย สัญญาของกระเป๋าเงินจะต้องให้แน่ใจว่าผู้เรียกใช้ฟังก์ชันสำคัญคือบัญชีเจ้าของกระเป๋าเงิน วิธีการทั่วไปสองวิธี ได้แก่:
การอนุญาตลายเซ็นนอกเครือข่าย
ผู้ใช้ลงนามในชุดการดำเนินการด้วยคีย์ส่วนตัว และสัญญาของกระเป๋าเงินจะตรวจสอบบนเชนว่าลายเซ็นถูกต้องตามกฎหมาย หมดอายุ และเป็นไปตาม nonce ที่สอดคล้องกันหรือไม่ วิธีนี้เหมาะสำหรับโหมดธุรกรรมรีเลย์ที่แนะนำโดย EIP-7702 (ลายเซ็นออฟไลน์ของผู้ใช้ + ธุรกรรมตัวแทนรีเลย์)
ข้อจำกัดการโทร (msg.sender == address(this))
ฟังก์ชันการทำงานของผู้ใช้จะได้รับอนุญาตให้เรียกใช้ได้จากสัญญาเท่านั้น ซึ่งโดยพื้นฐานแล้วเป็นกลไกควบคุมเส้นทางการโทรเพื่อให้แน่ใจว่าผู้ริเริ่มภายนอกจะต้องเป็นบัญชีนั้นเอง ซึ่งในความเป็นจริงแล้วเทียบเท่ากับการกำหนดให้ผู้โทรเป็น EOA ดั้งเดิม เนื่องจากที่อยู่สัญญาในขณะนี้คือที่อยู่ EOA
3. แนวโน้ม: EIP-7702 และมาตรฐานกระเป๋าสตางค์ AA ในอนาคต
การเปิดตัว EIP-7702 ไม่เพียงแต่เป็นนวัตกรรมใหม่ของโมเดลบัญชีแบบดั้งเดิมเท่านั้น แต่ยังเป็นการส่งเสริมระบบนิเวศ Account Abstraction ที่สำคัญอีกด้วย ความสามารถของผู้ใช้ในการโหลดโค้ดสัญญาที่เปิดตัวมานี้ทำให้มีพื้นที่กว้างขวางสำหรับการสำรวจการออกแบบกระเป๋าเงินและระบบสัญญาในอนาคต และยังเสนอข้อกำหนดใหม่สำหรับมาตรฐานการตรวจสอบความปลอดภัยอีกด้วย
1. วิวัฒนาการร่วมกับ EIP-4337: สู่ความเข้ากันได้ของโหมดคู่
แม้ว่า EIP-7702 และ EIP-4337 จะมีเป้าหมายการออกแบบที่แตกต่างกัน แต่ EIP-7702 จะสร้างกลไกการโหลดรหัสบัญชีขึ้นใหม่ ในขณะที่ EIP-4337 จะสร้างระบบนิเวศการป้อนรายการธุรกรรมและการจัดแพคเกจที่สมบูรณ์ อย่างไรก็ตาม ทั้งสองไม่มีความขัดแย้งกัน แต่มีความเสริมซึ่งกันและกันอย่างมาก:
● EIP-4337 จัดทำ “ช่องทางธุรกรรมสากล” และ “อินเทอร์เฟซการดำเนินการบัญชีนามธรรม”
● EIP-7702 ช่วยให้บัญชีผู้ใช้สามารถให้ความสามารถด้านลอจิกของสัญญาแบบไดนามิกโดยไม่ต้องเปลี่ยนแปลงที่อยู่
ดังนั้น ในอนาคต กระเป๋าสตางค์อาจนำเอา สถาปัตยกรรมรองรับโหมดคู่ มาใช้ โดยใช้ EIP-7702 เป็นทางเลือกน้ำหนักเบาบนเชนที่ไม่รองรับ EIP-4337 และยังคงใช้สแต็กโปรโตคอลแบบสมบูรณ์ของ EIP-4337 ในสถานการณ์ที่ต้องการการจัดแพ็คเกจนอกเชนและการรวมผู้ใช้หลายราย
กลไกแบบโหมดคู่นี้จะช่วยให้กระเป๋าสตางค์สามารถรองรับรูปแบบการอนุญาตบัญชีที่ยืดหยุ่นมากขึ้น ลดระดับกลไก และโซลูชันการย้อนกลับในเลเยอร์เคอร์เนล
2. การสนับสนุนและแรงบันดาลใจสำหรับลอจิกกระเป๋าสตางค์ใหม่เช่น MPC และ ZK
กลไกสัญญาบัญชีที่สนับสนุนโดย EIP-7702 มีศักยภาพในการบูรณาการอย่างเป็นธรรมชาติกับสถาปัตยกรรมใหม่ยอดนิยมในปัจจุบัน เช่น กระเป๋าเงิน MPC กระเป๋าเงิน ZK และกระเป๋าเงินแบบโมดูลาร์:
● ในโหมด MPC พฤติกรรมการลงนามไม่จำเป็นต้องพึ่งคีย์ส่วนตัวเพียงตัวเดียวอีกต่อไป แต่จะต้องอาศัยการตัดสินใจร่วมกันของหลายฝ่าย แทน ลายเซ็นที่สร้างขึ้นจากการรวม EIP-7702 และ MPC สามารถควบคุมตรรกะของสัญญาที่โหลดแบบไดนามิกได้ จึงทำให้มีกลยุทธ์การดำเนินการที่ยืดหยุ่นยิ่งขึ้น
● กระเป๋าสตางค์ ZK ยืนยันตัวตนหรือการรับรองความถูกต้องของผู้ใช้ผ่านการพิสูจน์แบบไม่ต้องเปิดเผยข้อมูลโดยไม่เปิดเผยข้อมูลคีย์ ส่วนตัว เมื่อใช้ร่วมกับ EIP-7702 กระเป๋าสตางค์ ZK จะสามารถใส่สัญญาตรรกะเฉพาะชั่วคราวหลังจากการตรวจสอบเสร็จสิ้น ซึ่งจะทำให้สามารถปรับใช้พฤติกรรมส่วนบุคคลได้หลังจากการคำนวณความเป็นส่วนตัว เช่น การดำเนินการตรรกะบางอย่างโดยอัตโนมัติหลังจากตรงตามเงื่อนไขความเป็นส่วนตัวบางประการเท่านั้น
● กระเป๋าสตางค์แบบโมดูลาร์ สามารถใช้ EIP-7702 เพื่อแบ่งตรรกะของบัญชีออกเป็นหลายโมดูลและโหลดแบบไดนามิกเมื่อจำเป็น
ดังนั้น EIP-7702 จึงจัดเตรียม คอนเทนเนอร์การดำเนินการ ดั้งเดิมสำหรับกระเป๋าเงินขั้นสูงที่กล่าวข้างต้น: สามารถแทรกลอจิกของสัญญาที่แตกต่างกันได้ในขณะที่ยังคงที่อยู่ของผู้ใช้ไว้ตามเดิม หลีกเลี่ยงปัญหาการพึ่งพาที่อยู่ในกระบวนการปรับใช้สัญญาแบบดั้งเดิม และขจัดความจำเป็นในการปรับใช้ล่วงหน้า ช่วยปรับปรุงความยืดหยุ่นและความสามารถในการผสมผสานของพฤติกรรมบัญชีได้อย่างมาก
3. ผลกระทบต่อผู้พัฒนาสัญญาและผู้ตรวจสอบบัญชี
EIP-7702 จะส่งเสริมการเปลี่ยนแปลงครั้งใหญ่ในกระบวนทัศน์การพัฒนา ผู้พัฒนาสัญญาไม่มองผู้โทรเป็นเพียง EOA แบบดั้งเดิมหรือบัญชีสัญญาคงที่อีกต่อไป แต่ต้องปรับตัวให้เข้ากับกลไกใหม่: ตัวตนของผู้โทรสามารถสลับไปมาระหว่าง EOA และสถานะสัญญาได้อย่างไดนามิกในระหว่างขั้นตอนการทำธุรกรรม และตรรกะพฤติกรรมของบัญชีจะไม่คงที่อีกต่อไป แต่สามารถเปลี่ยนแปลงได้อย่างยืดหยุ่นตามความต้องการ ซึ่งสิ่งนี้ต้องการให้ผู้พัฒนาและผู้ตรวจสอบมี:
แนะนำการยืนยันผู้โทรและการตัดสินอนุญาตที่เข้มงวดยิ่งขึ้น
ตรวจสอบว่าเส้นทางการโทรได้รับผลกระทบจากลอจิกของสัญญาแบบไดนามิกหรือไม่
ระบุช่องโหว่ที่อาจเกิดขึ้นซึ่งอาศัยพฤติกรรม เช่น msg.sender.code.length == 0, isContract() เป็นต้น
ชี้แจง ความสัมพันธ์ของบริบท ของลอจิกของสัญญา เช่น การควบคุมขอบเขตของการเรียกแบบคงที่และการมอบหมายการเรียก
รองรับการจำลองและการวิเคราะห์การคืนค่าของสถานการณ์ setCode ในระดับเครื่องมือ
กล่าวอีกนัยหนึ่ง ความปลอดภัยของโค้ดไม่ใช่แค่ “ปัญหาในช่วงก่อนการปรับใช้” อีกต่อไป แต่ได้กลายมาเป็น “กระบวนการไดนามิกที่ต้องได้รับการตรวจยืนยันในระหว่างการโทรและธุรกรรม”
IV. บทสรุป
EIP-7702 แนะนำการใช้งานที่เบากว่า ดั้งเดิม และยืดหยุ่นกว่าสำหรับการแยกย่อยบัญชี (AA) ซึ่งช่วยให้ EOA ทั่วไปสามารถดำเนินการและดำเนินการตามตรรกะของสัญญาได้ในธุรกรรมเดียว กลไกนี้ทำลายสมมติฐานแบบคงที่แบบเดิมเกี่ยวกับพฤติกรรมของบัญชี นักพัฒนาไม่สามารถพึ่งพาสถานะโค้ดของที่อยู่บัญชีเพื่อกำหนดรูปแบบพฤติกรรมของบัญชีได้อีกต่อไป แต่ต้องสร้างความเข้าใจเกี่ยวกับตัวตนของผู้โทรและขอบเขตการอนุญาตขึ้นมาใหม่
สิ่งที่ตามมาคือการเปลี่ยนแปลงกระบวนทัศน์ในการวิเคราะห์ด้านความปลอดภัย จุดเน้นของการตรวจสอบไม่ได้จำกัดอยู่แค่ว่า ที่อยู่บางแห่งมีสิทธิ์อนุญาตหรือไม่ อีกต่อไป แต่จะเปลี่ยนไปที่ ตรรกะของสัญญาที่มีอยู่ในธุรกรรมสามารถทำอะไรได้บ้างในบริบทปัจจุบัน ธุรกรรมแต่ละรายการอาจมีคำจำกัดความพฤติกรรมที่เป็นอิสระ ซึ่งจะทำให้บัญชีมีฟังก์ชันที่แข็งแกร่งขึ้น และยังกำหนดข้อกำหนดที่เข้มงวดยิ่งขึ้นสำหรับการตรวจสอบด้านความปลอดภัยอีกด้วย
