ผลกระทบของ EIP-3074 ต่อกระเป๋าเงินและ DApps

กลาง6/11/2024, 7:40:39 AM
บทความนี้แนะนําผลกระทบที่เป็นนวัตกรรมของ EIP-3074 ต่อ EOA ด้วยการอนุญาตให้ EOA ถ่ายโอนการควบคุมไปยังสัญญา Invoker ทําให้ได้รับความสามารถในการทํางานอเนกประสงค์เช่นเดียวกับสัญญา สิ่งนี้ไม่เพียง แต่ปรับปรุงประสบการณ์ของผู้ใช้อย่างมีนัยสําคัญ แต่ยังปรับเปลี่ยนวิธีการอนุญาตที่มีอยู่เพื่อให้ปลอดภัยยิ่งขึ้นโดยไม่ต้องเปลี่ยนประสบการณ์ของผู้ใช้

EIP-3074

ประสบการณ์การใช้งานที่ดีขึ้นและปลอดภัยยิ่งขึ้น

EIP-3074 ช่วยให้ EOA (บัญชีที่เป็นเจ้าของภายนอก) สามารถถ่ายโอนการควบคุมไปยังสัญญาที่ระบุจึงได้รับความสามารถในการดําเนินการที่หลากหลายเช่นเดียวกับสัญญา ก่อน EIP-3074 EOA สามารถดําเนินการได้เพียงหนึ่งครั้งต่อธุรกรรม เช่น การอนุมัติ ERC20 หรือการแลกเปลี่ยนบน Uniswap หลังจาก EIP-3074 EOA สามารถดําเนินการหลายอย่างพร้อมกันหรือแม้แต่ทํางานที่เป็นไปไม่ได้ก่อนหน้านี้ พูดง่ายๆก็คือ EIP-3074 ช่วยเพิ่มประสบการณ์ของผู้ใช้ได้อย่างมากและวิธีการอนุมัติโทเค็นที่คุ้นเคยจะถูกปรับเปลี่ยนใหม่เพิ่มความปลอดภัยโดยไม่ต้องเปลี่ยนประสบการณ์ของผู้ใช้

ยิ่งไปกว่านั้นผ่าน EIP-3074 EOA ไม่จําเป็นต้องส่งธุรกรรมไปยังห่วงโซ่ด้วยตัวเองอีกต่อไปขจัดปัญหาที่ต้องเพิ่ม ETH เพื่อชําระค่าธรรมเนียมการทําธุรกรรม

Invoker Contract

สัญญาที่สามารถควบคุม EOA ได้เรียกว่าสัญญา Invoker แน่นอนว่าไม่ใช่แค่สัญญาใด ๆ เท่านั้นที่สามารถควบคุม EOA ได้: EOA จะต้องลงนามด้วยคีย์ส่วนตัวและเนื้อหาของลายเซ็นจะระบุอย่างชัดเจนว่าเป็นสัญญา Invoker ใดและ Invoker ได้รับอนุญาตให้ดําเนินการใด

เนื้อหาลายเซ็นของ EOA จะระบุอย่างชัดเจนว่าสัญญา Invoker ใด (ที่อยู่ผู้เรียกใช้) และอนุญาตให้ดําเนินการตามสัญญา Invoker นั้น (ผูกมัด)

กระบวนการดําเนินการจริงอาจมีลักษณะดังนี้:

  1. อลิซลงนามด้วยคีย์ส่วนตัว EOA ของเธอจากนั้นให้เนื้อหาลายเซ็นและลายเซ็นแก่ Relayer
  2. Relayer นําห่วงโซ่ไปสู่การดําเนินการตามสัญญา Invoker
  3. Invoker ตรวจสอบลายเซ็น หลังจากผ่านการตรวจสอบแล้วจะสามารถดําเนินการเป็น EOA เช่นการอนุมัติ USDC จากนั้นไปที่ Uniswap เพื่อแลกเปลี่ยนและในที่สุดก็โอน USDC บางส่วนไปยัง Relayer เป็นค่าธรรมเนียมการจัดการ

หมายเหตุ 1: ไม่จําเป็นต้องใช้ Relayer อลิซยังสามารถนําเนื้อหาลายเซ็นของเธอเองและประทับตราไปยังห่วงโซ่

หลังจาก Invoker ตรวจสอบลายเซ็นและเริ่มดําเนินการแล้วมันจะถูกดําเนินการเป็น Alice EOA ซึ่งเหมือนกับการได้รับการควบคุม (จํากัด ) ของ EOA

อย่างไรก็ตามควรสังเกตว่าค่า nonce ของ EOA จะไม่เพิ่มขึ้นหลังจากการดําเนินการดังนั้นลายเซ็นเดียวกันอาจถูกนํากลับมาใช้ใหม่ (ตราบใดที่ EOA nonce ยังคงไม่เปลี่ยนแปลง) ดังนั้น Invoker จึงจําเป็นต้องใช้กลไก nonce ของตัวเองเพื่อหลีกเลี่ยงการเล่นซ้ํา

หากสัญญา Invoker ไม่สามารถเล่นซ้ําได้การอนุญาตเดียวกันสามารถดําเนินการได้ตลอดเวลา

สําหรับการแนะนํากลไกการทํางานจริงของ EIP-3074 โปรดดูที่: ความรู้เบื้องต้นเกี่ยวกับ EIP3074

Application

Batchcall

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

หมายเหตุ: สิ่งนี้จะต้องใช้ dApp เพื่อรองรับฟังก์ชัน Batchcall เช่น EIP-5792 ซึ่งกําลังถูกผลักดันโดยชุมชน มิฉะนั้น dApp จะแจ้งให้ผู้ใช้ลงนามเพียงครั้งเดียวสําหรับแต่ละการดําเนินการหากถือว่าผู้ใช้เป็น EOA ปกติ

Session Key

Users ยังสามารถอนุญาตให้บุคคลที่สามดําเนินการในนามของพวกเขาภายใต้เงื่อนไขบางประการ คีย์ผู้รับมอบสิทธิ์ในแผนภาพด้านล่างเป็นบุคคลที่สามที่ได้รับอนุญาต นโยบายการเข้าถึงคือข้อ จํากัด ในการดําเนินการเช่นการ จํากัด ให้ใช้งาน Uniswap เท่านั้นโอนสูงสุด 1 ETH ต่อวันระยะเวลาการอนุญาตเป็นต้น เงื่อนไขเหล่านี้ได้รับการออกแบบและตรวจสอบภายในสัญญา Invoker ตราบใดที่การตรวจสอบผ่านไปบุคคลที่สามสามารถดําเนินการในฐานะ EOA ของผู้ใช้ได้


Telegram Bot สามารถให้สิทธิ์เฉพาะในการดําเนินการในนามของ EOA ของผู้ใช้

Native ETH Permit

ตราบใดที่ตรงตามเงื่อนไข (นั่นคือลายเซ็นใบอนุญาตถูกกฎหมาย) การถ่ายโอน ETH สามารถดําเนินการในฐานะผู้อนุญาต EOA ซึ่งบรรลุผลของใบอนุญาต ETH ดั้งเดิม

Limit Order

ผู้ใช้กรอกเงื่อนไขคําสั่งจํากัดและเมื่อตรงตามเงื่อนไขก็สามารถดําเนินการในฐานะผู้ใช้ EOA รวมถึงการอนุมัติโทเค็นให้กับ DEX ไปที่ DEX เพื่อไถ่ถอน เมื่อเทียบกับ Limit Order ที่ DEX จัดหาให้ผู้ใช้ไม่จําเป็นต้องส่งธุรกรรมไปยัง DEX เพื่อขออนุมัติล่วงหน้า

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

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

ตราบใดที่ตรงตามเงื่อนไขเจตนาทุกคนสามารถเริ่มการดําเนินการในชื่อของ EOA ของผู้ใช้

การกู้คืนทางสังคม

เมื่อผู้ใช้สูญเสียคีย์ส่วนตัว EOA เธอ (อลิซ) สามารถใช้การอนุญาต EIP-3074 ที่เธอลงนามพร้อมกับลายเซ็นของผู้มีอํานาจของเธอ (สามีและตัวแทนทรัสต์) เพื่อโอนทรัพย์สินทั้งหมดของ EOA ในความเป็นจริงสิ่งที่กู้คืนคือสินทรัพย์ (โอนได้) ไม่ใช่การควบคุมบัญชี หลังจากคีย์ส่วนตัว EOA สูญหาย EOA จะไม่สามารถใช้งานได้อีกต่อไป

เมื่อผู้ใช้สูญเสียคีย์ส่วนตัว EOA ผู้มีอํานาจอื่น ๆ สามารถลงนามและอนุมัติการโอนสินทรัพย์ EOA ได้

ผลกระทบของ EIP-3074

การปรับปรุงวิธีการอนุญาตโทเค็น และอาจแทนที่การอนุมัติ/ใบอนุญาต?

ปัจจุบัน dApps ได้รับการออกแบบภายใต้สมมติฐานที่ว่าผู้ใช้เป็น EOA: ผู้ใช้ต้อง "อนุมัติล่วงหน้า" และ "อนุมัติเงินจํานวนเพียงพอ" สําหรับสัญญา dApp ซึ่งหมายความว่าผู้ใช้ไม่จําเป็นต้องออนไลน์ตลอดเวลารอให้ dApp ดําเนินการหรืออนุมัติใหม่อย่างต่อเนื่องปรับปรุงประสบการณ์ของผู้ใช้อย่างมาก สําหรับแอปพลิเคชันที่เรียกใช้ตามเงื่อนไขเช่นคําสั่ง จํากัด หรือ DCA ผู้ใช้อาจไม่ออนไลน์เมื่อตรงตามเงื่อนไขดังนั้นพวกเขาจึงต้องอนุมัติเงินจํานวนมากเพียงพอสําหรับสัญญา dApp ที่จะดําเนินการและอาจเป็นกระบวนการซ้ํา

ผู้ใช้ต้องอนุมัติจํานวนเงินมากพอสําหรับ dApp ล่วงหน้าเพื่อให้ dApp สามารถทํางานได้ด้วยเงิน

แต่ยังจําเป็นต้องเชื่อถือ dApp หรือหลีกเลี่ยงการอนุมัติ dApp ปลอมและสามารถลบการอนุมัติได้ทันที

โหมดใบอนุญาตที่ปรากฏในภายหลังเช่น EIP-2612 แบบโทเค็นดั้งเดิมหรือใบอนุญาตที่ไม่ใช่เจ้าของภาษา 2 ทั้งหมดเพื่อปรับปรุงประสบการณ์การใช้งานและความปลอดภัยของโหมดอนุมัติ: ผู้ใช้ไม่จําเป็นต้องอนุมัติเงินจํานวนมากให้กับสัญญา dApp แต่ละสัญญาอีกต่อไป (และแต่ละโทเค็นจะต้องได้รับการอนุมัติครั้งเดียว) ผู้ใช้จะต้อง "เซ็นชื่อ" เพื่ออนุญาตสัญญา dApp เพื่อ "ถอนจํานวนเงินที่ระบุ" ภายใน "เวลาที่กําหนด" สิ่งนี้ไม่เพียง แต่ช่วยลดพื้นผิวการโจมตีได้อย่างมาก แต่ยังช่วยเพิ่มประสบการณ์ของผู้ใช้อีกด้วย

ผู้ใช้จะต้องลงชื่อเข้าใช้นอกเครือข่ายเท่านั้นและสามารถระบุจํานวนเงินและระยะเวลาที่ถูกต้องซึ่งมอบประสบการณ์และความปลอดภัยแก่ผู้ใช้ที่ดีกว่าการอนุมัติ

แต่ในความเป็นจริงไม่เพียง แต่อนุมัติโหมดใบอนุญาตถูกใช้เป็นวิธีการโจมตีหลอกลวงบ่อยครั้ง (1,2,3): เหยื่อเซ็นชื่อในสิ่งที่พวกเขาคิดว่าเป็นใบอนุญาตสําหรับ dApp แต่ถูกมอบให้กับผู้โจมตีจริงๆ

เมื่อผู้ใช้ลงนามในใบอนุญาตพวกเขาจะสามารถดูได้ว่าใครจะอนุญาต แต่พวกเขาไม่รู้ว่าการดําเนินการใดจะถูกจับคู่กับการดําเนินการเพื่อดําเนินการ

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

อย่างไรก็ตาม EIP-3074 นํามาซึ่งโอกาสในการเปลี่ยนแปลง: เมื่อนักพัฒนา dApp รู้ว่า EOA สามารถดําเนินการที่ซับซ้อนต่างๆผ่าน Invoker การออกแบบการโต้ตอบ dApp ไม่จําเป็นต้องเสียสละความปลอดภัยอีกต่อไปเพื่อปรับปรุงประสบการณ์ของผู้ใช้เช่น "ผู้ใช้อนุมัติเงินจํานวนมากล่วงหน้า" และ "ผู้ใช้ลงนามในข้อความใบอนุญาตเพื่ออนุมัติการถอนเงิน" ผู้ใช้ผูกการดําเนินการ dApp เพื่ออนุมัติและดําเนินการอะตอมผ่าน Invoker: การดําเนินการอนุมัติและ dApp จะดําเนินการร่วมกันสําเร็จหรือล้มเหลวด้วยกัน ไม่มีความเป็นไปได้ที่จะประสบความสําเร็จในการอนุมัติเพียงอย่างเดียวดังนั้นผู้ใช้จึงมั่นใจได้ว่าการอนุมัตินี้มีไว้สําหรับการดําเนินการนี้ และผู้ใช้กําลังใช้การอนุญาตลายเซ็นนอกห่วงโซ่ดังนั้นประสบการณ์ของผู้ใช้จึงเหมือนกับใบอนุญาต! ซึ่งหมายความว่า dApp จะไม่ต้องการโหมดใบอนุญาตอีกต่อไป! ในอนาคตกระเป๋าเงินสามารถแบนหรือดําเนินการตรวจสอบคําขอลายเซ็นใบอนุญาตที่เข้มงวดขึ้นได้โดยตรงโดยไม่ต้องกังวลว่าจะทําให้ผู้ใช้ไม่ใช้ dApps บางอย่างหรือไม่ (แต่จะใช้สําหรับการหลอกลวง)

ผู้ใช้ไม่ได้อนุญาตที่อยู่ที่แน่นอนอีกต่อไป แต่อนุญาตที่อยู่ที่แน่นอนและสิ่งที่ต้องทําและแม้แต่ดูผลการดําเนินการจําลอง

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

วิธีที่ Wallet จัดการกับ EOA nonces

การออกแบบ EIP-3074 ปัจจุบันจะรวมค่า NONCE ของ EOA ไว้ในเนื้อหาลายเซ็น ตราบใดที่ EOA ส่งธุรกรรมไปยังห่วงโซ่เพื่อดําเนินการและเปลี่ยนแปลงค่า nonce การอนุญาต EIP-3074 ดั้งเดิมทั้งหมดจะถูกยกเลิก

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

หากผู้ใช้ได้รับอนุญาตให้ดําเนินการด้วยตัวเองไม่จําเป็นต้องป้องกันไม่ให้มีการเปลี่ยนแปลง EOA nonce โดยเฉพาะเนื่องจากลายเซ็น EIP-3074 ยังคงคาดว่าจะดําเนินการก่อนกําหนดเส้นตายที่แน่นอนเช่นการทําธุรกรรม มันเป็นเพียงว่ากระเป๋าเงินจําเป็นต้องจัดการธุรกรรม EIP-3074 เพิ่มเติมของ EOA: หากมีลายเซ็น EIP-3074 ที่รอการอัปโหลดไปยังห่วงโซ่ธุรกรรมของ EOA เองจะต้องรอ

หมายเหตุ: สัญญา Invoker จะ (และควร) รักษาชุดของกลไก nonce ดังนั้นหลังจากใช้ลายเซ็นแล้วยังคงต้องลงนามอีกครั้งโดยไม่คํานึงว่า EOA nonce จะเปลี่ยนแปลงหรือไม่

คีย์เซสชันและการกู้คืนทางสังคมมักจะต้องรอจนกว่า EIP-3074 จะเปลี่ยนกฎเพื่อลบ EOA nonce ออกจากเนื้อหาลายเซ็นก่อนที่จะนําไปใช้ในวงกว้าง ดังนั้นกระเป๋าเงินจะต้องมุ่งเน้นไปที่กรณีการใช้งานของ "การดําเนินการที่ได้รับอนุญาตจากผู้ใช้" และถือว่าลายเซ็น EIP-3074 เป็นธุรกรรม ไม่จําเป็นต้องกังวลเกี่ยวกับการหลีกเลี่ยงการส่งธุรกรรม EOA หรือเปลี่ยน EOA nonce

อย่างไรก็ตามควรสังเกตว่าหากผู้ใช้ต้องการนําเนื้อหาลายเซ็น EIP-3074 ของตัวเองไปยังห่วงโซ่จะมีข้อเสียสองประการ:

  1. ผู้ใช้ต้องลงนามสองครั้ง: หนึ่งครั้งสําหรับลายเซ็น EIP-3074 และหนึ่งครั้งสําหรับลายเซ็นธุรกรรมแบบ on-chain
  2. เนื่องจากธุรกรรมแบบ on-chain จะเพิ่ม 1 ลงใน EOA nonce ก่อนที่ธุรกรรมจะเริ่มดําเนินการ EOA nonce ในลายเซ็น EIP-3074 ของผู้ใช้จะต้องถูกเพิ่มไว้ล่วงหน้า 1 เพื่อให้ตรงกับ EOA nonce +1 ที่เกิดจากห่วงโซ่เอง

เนื่องจากห่วงโซ่จะเพิ่ม 1 ใน EOA nonce ก่อนการตรวจสอบลายเซ็น EIP-3074 จะล้มเหลวเนื่องจาก EOA nonce ไม่ตรงกัน

หากผู้ใช้เพิ่ม 1 ลงใน EOA nonce ในลายเซ็น EIP-3074 ก่อนที่จะนําเข้าสู่ห่วงโซ่เองการตรวจสอบสามารถดําเนินการได้อย่างราบรื่น

สรุปและไฮไลท์

  • EIP-3074 ช่วยให้ EOA ได้รับความสามารถในการดําเนินการที่หลากหลายเช่นเดียวกับสัญญาซึ่งเปิดสถานการณ์การใช้งานใหม่ ๆ มากมาย
  • สิ่งนี้จะไม่เพียง แต่ปรับปรุงประสบการณ์ของผู้ใช้อย่างมาก แต่ยังจะเปลี่ยนวิธีการอนุญาตโทเค็นปัจจุบันทําให้ปลอดภัยยิ่งขึ้นในขณะที่ยังคงรักษาประสบการณ์ผู้ใช้เดิม
  • ยิ่งไปกว่านั้น EIP-3074 เป็นลายเซ็นที่เรียบง่ายและผู้ใช้ไม่จําเป็นต้องนําลายเซ็นเข้าสู่ห่วงโซ่เพื่อดําเนินการดังนั้นจึงไม่จําเป็นต้องกังวลเกี่ยวกับการรวบรวม ETH เพื่อชําระค่าธรรมเนียมการทําธุรกรรม
  • การใช้ EIP-3074 ได้แก่ Batch Call, Session Key, Native ETH Permit, Limit Order และ Social Recovery สิ่งเหล่านี้หลายอย่างก่อนหน้านี้เป็นไปไม่ได้ที่ EOAs จะบรรลุและบางส่วนเช่น Limit Order ต้องใช้วิธีการอนุมัติล่วงหน้าที่ไม่ปลอดภัย
  • EIP-3074 จะเปลี่ยนวิธีการอนุญาตโทเค็นปัจจุบันด้วย วิธีการอนุมัติอนุญาตให้ที่อยู่เฉพาะมีอํานาจในการถอนโทเค็นอย่างไม่มีกําหนดและต้องใช้ EOA ของผู้ใช้ในการส่งธุรกรรมเพื่อดําเนินการอนุมัติดังนั้นประสบการณ์ของผู้ใช้และความปลอดภัยจึงไม่ดี วิธีการอนุญาตกําหนดให้ผู้ใช้ต้องลงนามเท่านั้นและลายเซ็นแต่ละลายเซ็นจะระบุจํานวนเงินและระยะเวลาที่ถูกต้องซึ่งช่วยปรับปรุงประสบการณ์และความปลอดภัยของผู้ใช้อย่างมากเมื่อเทียบกับการอนุมัติ
  • อย่างไรก็ตามใบอนุญาตยังคงใช้บ่อยในการหลอกลวง เมื่อลงนามผู้ใช้สามารถทราบได้เฉพาะผู้ที่จะอนุญาตจํานวนเท่าใดและระยะเวลาที่ถูกต้อง แต่พวกเขาไม่ทราบว่าการอนุญาตนี้มีไว้เพื่ออะไร "มีไว้เพื่ออะไร" จะเป็นลายเซ็นอื่น (หรือธุรกรรม) dApps ปกติจะอนุญาตให้ผู้ใช้ลงนามในใบอนุญาตและ "มีไว้เพื่ออะไร" แต่จะยังคงเป็นลายเซ็นสองแบบที่แตกต่างกันดังนั้นเมื่อได้รับการร้องขอให้ลงนามในใบอนุญาตทั้งผู้ใช้และกระเป๋าเงินไม่สามารถทราบได้ว่าใบอนุญาตนี้จะใช้เพื่ออะไร
  • ด้วย EIP-3074 ผู้ใช้ (1) ไม่จําเป็นต้องอนุมัติเงินจํานวนมากให้กับ dApp ล่วงหน้า แต่ต้องอนุมัติเมื่อมีการดําเนินการซึ่งมีผลเช่นเดียวกับใบอนุญาต (2) เป็นเพียงลายเซ็นง่ายๆและไม่จําเป็นต้องกังวลเกี่ยวกับการรวบรวม ETH เพื่อชําระค่าธรรมเนียมการทําธุรกรรมซึ่งเหมือนกับใบอนุญาต (3) การอนุมัติแต่ละครั้งเชื่อมโยงกับการดําเนินการเฉพาะและลงนามร่วมกันเพื่อให้ผู้ใช้สามารถทราบได้อย่างชัดเจนว่าการอนุมัตินี้มีไว้เพื่ออะไรซึ่งจะปลอดภัยกว่าใบอนุญาต!
  • หวังว่า EIP-3074 จะสามารถแทนที่โหมดการอนุมัติและใบอนุญาตปัจจุบันได้สําเร็จและให้วิธีการอนุญาตที่ปลอดภัยยิ่งขึ้นแก่ผู้ใช้

ข้อจํากัดความรับผิดชอบ:

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

ผลกระทบของ EIP-3074 ต่อกระเป๋าเงินและ DApps

กลาง6/11/2024, 7:40:39 AM
บทความนี้แนะนําผลกระทบที่เป็นนวัตกรรมของ EIP-3074 ต่อ EOA ด้วยการอนุญาตให้ EOA ถ่ายโอนการควบคุมไปยังสัญญา Invoker ทําให้ได้รับความสามารถในการทํางานอเนกประสงค์เช่นเดียวกับสัญญา สิ่งนี้ไม่เพียง แต่ปรับปรุงประสบการณ์ของผู้ใช้อย่างมีนัยสําคัญ แต่ยังปรับเปลี่ยนวิธีการอนุญาตที่มีอยู่เพื่อให้ปลอดภัยยิ่งขึ้นโดยไม่ต้องเปลี่ยนประสบการณ์ของผู้ใช้

EIP-3074

ประสบการณ์การใช้งานที่ดีขึ้นและปลอดภัยยิ่งขึ้น

EIP-3074 ช่วยให้ EOA (บัญชีที่เป็นเจ้าของภายนอก) สามารถถ่ายโอนการควบคุมไปยังสัญญาที่ระบุจึงได้รับความสามารถในการดําเนินการที่หลากหลายเช่นเดียวกับสัญญา ก่อน EIP-3074 EOA สามารถดําเนินการได้เพียงหนึ่งครั้งต่อธุรกรรม เช่น การอนุมัติ ERC20 หรือการแลกเปลี่ยนบน Uniswap หลังจาก EIP-3074 EOA สามารถดําเนินการหลายอย่างพร้อมกันหรือแม้แต่ทํางานที่เป็นไปไม่ได้ก่อนหน้านี้ พูดง่ายๆก็คือ EIP-3074 ช่วยเพิ่มประสบการณ์ของผู้ใช้ได้อย่างมากและวิธีการอนุมัติโทเค็นที่คุ้นเคยจะถูกปรับเปลี่ยนใหม่เพิ่มความปลอดภัยโดยไม่ต้องเปลี่ยนประสบการณ์ของผู้ใช้

ยิ่งไปกว่านั้นผ่าน EIP-3074 EOA ไม่จําเป็นต้องส่งธุรกรรมไปยังห่วงโซ่ด้วยตัวเองอีกต่อไปขจัดปัญหาที่ต้องเพิ่ม ETH เพื่อชําระค่าธรรมเนียมการทําธุรกรรม

Invoker Contract

สัญญาที่สามารถควบคุม EOA ได้เรียกว่าสัญญา Invoker แน่นอนว่าไม่ใช่แค่สัญญาใด ๆ เท่านั้นที่สามารถควบคุม EOA ได้: EOA จะต้องลงนามด้วยคีย์ส่วนตัวและเนื้อหาของลายเซ็นจะระบุอย่างชัดเจนว่าเป็นสัญญา Invoker ใดและ Invoker ได้รับอนุญาตให้ดําเนินการใด

เนื้อหาลายเซ็นของ EOA จะระบุอย่างชัดเจนว่าสัญญา Invoker ใด (ที่อยู่ผู้เรียกใช้) และอนุญาตให้ดําเนินการตามสัญญา Invoker นั้น (ผูกมัด)

กระบวนการดําเนินการจริงอาจมีลักษณะดังนี้:

  1. อลิซลงนามด้วยคีย์ส่วนตัว EOA ของเธอจากนั้นให้เนื้อหาลายเซ็นและลายเซ็นแก่ Relayer
  2. Relayer นําห่วงโซ่ไปสู่การดําเนินการตามสัญญา Invoker
  3. Invoker ตรวจสอบลายเซ็น หลังจากผ่านการตรวจสอบแล้วจะสามารถดําเนินการเป็น EOA เช่นการอนุมัติ USDC จากนั้นไปที่ Uniswap เพื่อแลกเปลี่ยนและในที่สุดก็โอน USDC บางส่วนไปยัง Relayer เป็นค่าธรรมเนียมการจัดการ

หมายเหตุ 1: ไม่จําเป็นต้องใช้ Relayer อลิซยังสามารถนําเนื้อหาลายเซ็นของเธอเองและประทับตราไปยังห่วงโซ่

หลังจาก Invoker ตรวจสอบลายเซ็นและเริ่มดําเนินการแล้วมันจะถูกดําเนินการเป็น Alice EOA ซึ่งเหมือนกับการได้รับการควบคุม (จํากัด ) ของ EOA

อย่างไรก็ตามควรสังเกตว่าค่า nonce ของ EOA จะไม่เพิ่มขึ้นหลังจากการดําเนินการดังนั้นลายเซ็นเดียวกันอาจถูกนํากลับมาใช้ใหม่ (ตราบใดที่ EOA nonce ยังคงไม่เปลี่ยนแปลง) ดังนั้น Invoker จึงจําเป็นต้องใช้กลไก nonce ของตัวเองเพื่อหลีกเลี่ยงการเล่นซ้ํา

หากสัญญา Invoker ไม่สามารถเล่นซ้ําได้การอนุญาตเดียวกันสามารถดําเนินการได้ตลอดเวลา

สําหรับการแนะนํากลไกการทํางานจริงของ EIP-3074 โปรดดูที่: ความรู้เบื้องต้นเกี่ยวกับ EIP3074

Application

Batchcall

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

หมายเหตุ: สิ่งนี้จะต้องใช้ dApp เพื่อรองรับฟังก์ชัน Batchcall เช่น EIP-5792 ซึ่งกําลังถูกผลักดันโดยชุมชน มิฉะนั้น dApp จะแจ้งให้ผู้ใช้ลงนามเพียงครั้งเดียวสําหรับแต่ละการดําเนินการหากถือว่าผู้ใช้เป็น EOA ปกติ

Session Key

Users ยังสามารถอนุญาตให้บุคคลที่สามดําเนินการในนามของพวกเขาภายใต้เงื่อนไขบางประการ คีย์ผู้รับมอบสิทธิ์ในแผนภาพด้านล่างเป็นบุคคลที่สามที่ได้รับอนุญาต นโยบายการเข้าถึงคือข้อ จํากัด ในการดําเนินการเช่นการ จํากัด ให้ใช้งาน Uniswap เท่านั้นโอนสูงสุด 1 ETH ต่อวันระยะเวลาการอนุญาตเป็นต้น เงื่อนไขเหล่านี้ได้รับการออกแบบและตรวจสอบภายในสัญญา Invoker ตราบใดที่การตรวจสอบผ่านไปบุคคลที่สามสามารถดําเนินการในฐานะ EOA ของผู้ใช้ได้


Telegram Bot สามารถให้สิทธิ์เฉพาะในการดําเนินการในนามของ EOA ของผู้ใช้

Native ETH Permit

ตราบใดที่ตรงตามเงื่อนไข (นั่นคือลายเซ็นใบอนุญาตถูกกฎหมาย) การถ่ายโอน ETH สามารถดําเนินการในฐานะผู้อนุญาต EOA ซึ่งบรรลุผลของใบอนุญาต ETH ดั้งเดิม

Limit Order

ผู้ใช้กรอกเงื่อนไขคําสั่งจํากัดและเมื่อตรงตามเงื่อนไขก็สามารถดําเนินการในฐานะผู้ใช้ EOA รวมถึงการอนุมัติโทเค็นให้กับ DEX ไปที่ DEX เพื่อไถ่ถอน เมื่อเทียบกับ Limit Order ที่ DEX จัดหาให้ผู้ใช้ไม่จําเป็นต้องส่งธุรกรรมไปยัง DEX เพื่อขออนุมัติล่วงหน้า

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

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

ตราบใดที่ตรงตามเงื่อนไขเจตนาทุกคนสามารถเริ่มการดําเนินการในชื่อของ EOA ของผู้ใช้

การกู้คืนทางสังคม

เมื่อผู้ใช้สูญเสียคีย์ส่วนตัว EOA เธอ (อลิซ) สามารถใช้การอนุญาต EIP-3074 ที่เธอลงนามพร้อมกับลายเซ็นของผู้มีอํานาจของเธอ (สามีและตัวแทนทรัสต์) เพื่อโอนทรัพย์สินทั้งหมดของ EOA ในความเป็นจริงสิ่งที่กู้คืนคือสินทรัพย์ (โอนได้) ไม่ใช่การควบคุมบัญชี หลังจากคีย์ส่วนตัว EOA สูญหาย EOA จะไม่สามารถใช้งานได้อีกต่อไป

เมื่อผู้ใช้สูญเสียคีย์ส่วนตัว EOA ผู้มีอํานาจอื่น ๆ สามารถลงนามและอนุมัติการโอนสินทรัพย์ EOA ได้

ผลกระทบของ EIP-3074

การปรับปรุงวิธีการอนุญาตโทเค็น และอาจแทนที่การอนุมัติ/ใบอนุญาต?

ปัจจุบัน dApps ได้รับการออกแบบภายใต้สมมติฐานที่ว่าผู้ใช้เป็น EOA: ผู้ใช้ต้อง "อนุมัติล่วงหน้า" และ "อนุมัติเงินจํานวนเพียงพอ" สําหรับสัญญา dApp ซึ่งหมายความว่าผู้ใช้ไม่จําเป็นต้องออนไลน์ตลอดเวลารอให้ dApp ดําเนินการหรืออนุมัติใหม่อย่างต่อเนื่องปรับปรุงประสบการณ์ของผู้ใช้อย่างมาก สําหรับแอปพลิเคชันที่เรียกใช้ตามเงื่อนไขเช่นคําสั่ง จํากัด หรือ DCA ผู้ใช้อาจไม่ออนไลน์เมื่อตรงตามเงื่อนไขดังนั้นพวกเขาจึงต้องอนุมัติเงินจํานวนมากเพียงพอสําหรับสัญญา dApp ที่จะดําเนินการและอาจเป็นกระบวนการซ้ํา

ผู้ใช้ต้องอนุมัติจํานวนเงินมากพอสําหรับ dApp ล่วงหน้าเพื่อให้ dApp สามารถทํางานได้ด้วยเงิน

แต่ยังจําเป็นต้องเชื่อถือ dApp หรือหลีกเลี่ยงการอนุมัติ dApp ปลอมและสามารถลบการอนุมัติได้ทันที

โหมดใบอนุญาตที่ปรากฏในภายหลังเช่น EIP-2612 แบบโทเค็นดั้งเดิมหรือใบอนุญาตที่ไม่ใช่เจ้าของภาษา 2 ทั้งหมดเพื่อปรับปรุงประสบการณ์การใช้งานและความปลอดภัยของโหมดอนุมัติ: ผู้ใช้ไม่จําเป็นต้องอนุมัติเงินจํานวนมากให้กับสัญญา dApp แต่ละสัญญาอีกต่อไป (และแต่ละโทเค็นจะต้องได้รับการอนุมัติครั้งเดียว) ผู้ใช้จะต้อง "เซ็นชื่อ" เพื่ออนุญาตสัญญา dApp เพื่อ "ถอนจํานวนเงินที่ระบุ" ภายใน "เวลาที่กําหนด" สิ่งนี้ไม่เพียง แต่ช่วยลดพื้นผิวการโจมตีได้อย่างมาก แต่ยังช่วยเพิ่มประสบการณ์ของผู้ใช้อีกด้วย

ผู้ใช้จะต้องลงชื่อเข้าใช้นอกเครือข่ายเท่านั้นและสามารถระบุจํานวนเงินและระยะเวลาที่ถูกต้องซึ่งมอบประสบการณ์และความปลอดภัยแก่ผู้ใช้ที่ดีกว่าการอนุมัติ

แต่ในความเป็นจริงไม่เพียง แต่อนุมัติโหมดใบอนุญาตถูกใช้เป็นวิธีการโจมตีหลอกลวงบ่อยครั้ง (1,2,3): เหยื่อเซ็นชื่อในสิ่งที่พวกเขาคิดว่าเป็นใบอนุญาตสําหรับ dApp แต่ถูกมอบให้กับผู้โจมตีจริงๆ

เมื่อผู้ใช้ลงนามในใบอนุญาตพวกเขาจะสามารถดูได้ว่าใครจะอนุญาต แต่พวกเขาไม่รู้ว่าการดําเนินการใดจะถูกจับคู่กับการดําเนินการเพื่อดําเนินการ

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

อย่างไรก็ตาม EIP-3074 นํามาซึ่งโอกาสในการเปลี่ยนแปลง: เมื่อนักพัฒนา dApp รู้ว่า EOA สามารถดําเนินการที่ซับซ้อนต่างๆผ่าน Invoker การออกแบบการโต้ตอบ dApp ไม่จําเป็นต้องเสียสละความปลอดภัยอีกต่อไปเพื่อปรับปรุงประสบการณ์ของผู้ใช้เช่น "ผู้ใช้อนุมัติเงินจํานวนมากล่วงหน้า" และ "ผู้ใช้ลงนามในข้อความใบอนุญาตเพื่ออนุมัติการถอนเงิน" ผู้ใช้ผูกการดําเนินการ dApp เพื่ออนุมัติและดําเนินการอะตอมผ่าน Invoker: การดําเนินการอนุมัติและ dApp จะดําเนินการร่วมกันสําเร็จหรือล้มเหลวด้วยกัน ไม่มีความเป็นไปได้ที่จะประสบความสําเร็จในการอนุมัติเพียงอย่างเดียวดังนั้นผู้ใช้จึงมั่นใจได้ว่าการอนุมัตินี้มีไว้สําหรับการดําเนินการนี้ และผู้ใช้กําลังใช้การอนุญาตลายเซ็นนอกห่วงโซ่ดังนั้นประสบการณ์ของผู้ใช้จึงเหมือนกับใบอนุญาต! ซึ่งหมายความว่า dApp จะไม่ต้องการโหมดใบอนุญาตอีกต่อไป! ในอนาคตกระเป๋าเงินสามารถแบนหรือดําเนินการตรวจสอบคําขอลายเซ็นใบอนุญาตที่เข้มงวดขึ้นได้โดยตรงโดยไม่ต้องกังวลว่าจะทําให้ผู้ใช้ไม่ใช้ dApps บางอย่างหรือไม่ (แต่จะใช้สําหรับการหลอกลวง)

ผู้ใช้ไม่ได้อนุญาตที่อยู่ที่แน่นอนอีกต่อไป แต่อนุญาตที่อยู่ที่แน่นอนและสิ่งที่ต้องทําและแม้แต่ดูผลการดําเนินการจําลอง

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

วิธีที่ Wallet จัดการกับ EOA nonces

การออกแบบ EIP-3074 ปัจจุบันจะรวมค่า NONCE ของ EOA ไว้ในเนื้อหาลายเซ็น ตราบใดที่ EOA ส่งธุรกรรมไปยังห่วงโซ่เพื่อดําเนินการและเปลี่ยนแปลงค่า nonce การอนุญาต EIP-3074 ดั้งเดิมทั้งหมดจะถูกยกเลิก

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

หากผู้ใช้ได้รับอนุญาตให้ดําเนินการด้วยตัวเองไม่จําเป็นต้องป้องกันไม่ให้มีการเปลี่ยนแปลง EOA nonce โดยเฉพาะเนื่องจากลายเซ็น EIP-3074 ยังคงคาดว่าจะดําเนินการก่อนกําหนดเส้นตายที่แน่นอนเช่นการทําธุรกรรม มันเป็นเพียงว่ากระเป๋าเงินจําเป็นต้องจัดการธุรกรรม EIP-3074 เพิ่มเติมของ EOA: หากมีลายเซ็น EIP-3074 ที่รอการอัปโหลดไปยังห่วงโซ่ธุรกรรมของ EOA เองจะต้องรอ

หมายเหตุ: สัญญา Invoker จะ (และควร) รักษาชุดของกลไก nonce ดังนั้นหลังจากใช้ลายเซ็นแล้วยังคงต้องลงนามอีกครั้งโดยไม่คํานึงว่า EOA nonce จะเปลี่ยนแปลงหรือไม่

คีย์เซสชันและการกู้คืนทางสังคมมักจะต้องรอจนกว่า EIP-3074 จะเปลี่ยนกฎเพื่อลบ EOA nonce ออกจากเนื้อหาลายเซ็นก่อนที่จะนําไปใช้ในวงกว้าง ดังนั้นกระเป๋าเงินจะต้องมุ่งเน้นไปที่กรณีการใช้งานของ "การดําเนินการที่ได้รับอนุญาตจากผู้ใช้" และถือว่าลายเซ็น EIP-3074 เป็นธุรกรรม ไม่จําเป็นต้องกังวลเกี่ยวกับการหลีกเลี่ยงการส่งธุรกรรม EOA หรือเปลี่ยน EOA nonce

อย่างไรก็ตามควรสังเกตว่าหากผู้ใช้ต้องการนําเนื้อหาลายเซ็น EIP-3074 ของตัวเองไปยังห่วงโซ่จะมีข้อเสียสองประการ:

  1. ผู้ใช้ต้องลงนามสองครั้ง: หนึ่งครั้งสําหรับลายเซ็น EIP-3074 และหนึ่งครั้งสําหรับลายเซ็นธุรกรรมแบบ on-chain
  2. เนื่องจากธุรกรรมแบบ on-chain จะเพิ่ม 1 ลงใน EOA nonce ก่อนที่ธุรกรรมจะเริ่มดําเนินการ EOA nonce ในลายเซ็น EIP-3074 ของผู้ใช้จะต้องถูกเพิ่มไว้ล่วงหน้า 1 เพื่อให้ตรงกับ EOA nonce +1 ที่เกิดจากห่วงโซ่เอง

เนื่องจากห่วงโซ่จะเพิ่ม 1 ใน EOA nonce ก่อนการตรวจสอบลายเซ็น EIP-3074 จะล้มเหลวเนื่องจาก EOA nonce ไม่ตรงกัน

หากผู้ใช้เพิ่ม 1 ลงใน EOA nonce ในลายเซ็น EIP-3074 ก่อนที่จะนําเข้าสู่ห่วงโซ่เองการตรวจสอบสามารถดําเนินการได้อย่างราบรื่น

สรุปและไฮไลท์

  • EIP-3074 ช่วยให้ EOA ได้รับความสามารถในการดําเนินการที่หลากหลายเช่นเดียวกับสัญญาซึ่งเปิดสถานการณ์การใช้งานใหม่ ๆ มากมาย
  • สิ่งนี้จะไม่เพียง แต่ปรับปรุงประสบการณ์ของผู้ใช้อย่างมาก แต่ยังจะเปลี่ยนวิธีการอนุญาตโทเค็นปัจจุบันทําให้ปลอดภัยยิ่งขึ้นในขณะที่ยังคงรักษาประสบการณ์ผู้ใช้เดิม
  • ยิ่งไปกว่านั้น EIP-3074 เป็นลายเซ็นที่เรียบง่ายและผู้ใช้ไม่จําเป็นต้องนําลายเซ็นเข้าสู่ห่วงโซ่เพื่อดําเนินการดังนั้นจึงไม่จําเป็นต้องกังวลเกี่ยวกับการรวบรวม ETH เพื่อชําระค่าธรรมเนียมการทําธุรกรรม
  • การใช้ EIP-3074 ได้แก่ Batch Call, Session Key, Native ETH Permit, Limit Order และ Social Recovery สิ่งเหล่านี้หลายอย่างก่อนหน้านี้เป็นไปไม่ได้ที่ EOAs จะบรรลุและบางส่วนเช่น Limit Order ต้องใช้วิธีการอนุมัติล่วงหน้าที่ไม่ปลอดภัย
  • EIP-3074 จะเปลี่ยนวิธีการอนุญาตโทเค็นปัจจุบันด้วย วิธีการอนุมัติอนุญาตให้ที่อยู่เฉพาะมีอํานาจในการถอนโทเค็นอย่างไม่มีกําหนดและต้องใช้ EOA ของผู้ใช้ในการส่งธุรกรรมเพื่อดําเนินการอนุมัติดังนั้นประสบการณ์ของผู้ใช้และความปลอดภัยจึงไม่ดี วิธีการอนุญาตกําหนดให้ผู้ใช้ต้องลงนามเท่านั้นและลายเซ็นแต่ละลายเซ็นจะระบุจํานวนเงินและระยะเวลาที่ถูกต้องซึ่งช่วยปรับปรุงประสบการณ์และความปลอดภัยของผู้ใช้อย่างมากเมื่อเทียบกับการอนุมัติ
  • อย่างไรก็ตามใบอนุญาตยังคงใช้บ่อยในการหลอกลวง เมื่อลงนามผู้ใช้สามารถทราบได้เฉพาะผู้ที่จะอนุญาตจํานวนเท่าใดและระยะเวลาที่ถูกต้อง แต่พวกเขาไม่ทราบว่าการอนุญาตนี้มีไว้เพื่ออะไร "มีไว้เพื่ออะไร" จะเป็นลายเซ็นอื่น (หรือธุรกรรม) dApps ปกติจะอนุญาตให้ผู้ใช้ลงนามในใบอนุญาตและ "มีไว้เพื่ออะไร" แต่จะยังคงเป็นลายเซ็นสองแบบที่แตกต่างกันดังนั้นเมื่อได้รับการร้องขอให้ลงนามในใบอนุญาตทั้งผู้ใช้และกระเป๋าเงินไม่สามารถทราบได้ว่าใบอนุญาตนี้จะใช้เพื่ออะไร
  • ด้วย EIP-3074 ผู้ใช้ (1) ไม่จําเป็นต้องอนุมัติเงินจํานวนมากให้กับ dApp ล่วงหน้า แต่ต้องอนุมัติเมื่อมีการดําเนินการซึ่งมีผลเช่นเดียวกับใบอนุญาต (2) เป็นเพียงลายเซ็นง่ายๆและไม่จําเป็นต้องกังวลเกี่ยวกับการรวบรวม ETH เพื่อชําระค่าธรรมเนียมการทําธุรกรรมซึ่งเหมือนกับใบอนุญาต (3) การอนุมัติแต่ละครั้งเชื่อมโยงกับการดําเนินการเฉพาะและลงนามร่วมกันเพื่อให้ผู้ใช้สามารถทราบได้อย่างชัดเจนว่าการอนุมัตินี้มีไว้เพื่ออะไรซึ่งจะปลอดภัยกว่าใบอนุญาต!
  • หวังว่า EIP-3074 จะสามารถแทนที่โหมดการอนุมัติและใบอนุญาตปัจจุบันได้สําเร็จและให้วิธีการอนุญาตที่ปลอดภัยยิ่งขึ้นแก่ผู้ใช้

ข้อจํากัดความรับผิดชอบ:

  1. บทความนี้พิมพ์ซ้ําจาก [imToken Labs] ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [ไม่มีอะไร] หากมีการคัดค้านการพิมพ์ซ้ํานี้ โปรดติดต่อทีม Gate Learn และพวกเขาจะจัดการทันที
  2. ข้อจํากัดความรับผิดชอบความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนและไม่ถือเป็นคําแนะนําการลงทุนใด ๆ
  3. การแปลบทความเป็นภาษาอื่นทําโดยทีม Gate Learn ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปล
แล้ว เว้นแต่จะกล่าวถึง
Comece agora
Inscreva-se e ganhe um cupom de
$100
!