ประสบการณ์การใช้งานที่ดีขึ้นและปลอดภัยยิ่งขึ้น
EIP-3074 ช่วยให้ EOA (บัญชีที่เป็นเจ้าของภายนอก) สามารถถ่ายโอนการควบคุมไปยังสัญญาที่ระบุจึงได้รับความสามารถในการดําเนินการที่หลากหลายเช่นเดียวกับสัญญา ก่อน EIP-3074 EOA สามารถดําเนินการได้เพียงหนึ่งครั้งต่อธุรกรรม เช่น การอนุมัติ ERC20 หรือการแลกเปลี่ยนบน Uniswap หลังจาก EIP-3074 EOA สามารถดําเนินการหลายอย่างพร้อมกันหรือแม้แต่ทํางานที่เป็นไปไม่ได้ก่อนหน้านี้ พูดง่ายๆก็คือ EIP-3074 ช่วยเพิ่มประสบการณ์ของผู้ใช้ได้อย่างมากและวิธีการอนุมัติโทเค็นที่คุ้นเคยจะถูกปรับเปลี่ยนใหม่เพิ่มความปลอดภัยโดยไม่ต้องเปลี่ยนประสบการณ์ของผู้ใช้
ยิ่งไปกว่านั้นผ่าน EIP-3074 EOA ไม่จําเป็นต้องส่งธุรกรรมไปยังห่วงโซ่ด้วยตัวเองอีกต่อไปขจัดปัญหาที่ต้องเพิ่ม ETH เพื่อชําระค่าธรรมเนียมการทําธุรกรรม
สัญญาที่สามารถควบคุม EOA ได้เรียกว่าสัญญา Invoker แน่นอนว่าไม่ใช่แค่สัญญาใด ๆ เท่านั้นที่สามารถควบคุม EOA ได้: EOA จะต้องลงนามด้วยคีย์ส่วนตัวและเนื้อหาของลายเซ็นจะระบุอย่างชัดเจนว่าเป็นสัญญา Invoker ใดและ Invoker ได้รับอนุญาตให้ดําเนินการใด
เนื้อหาลายเซ็นของ EOA จะระบุอย่างชัดเจนว่าสัญญา Invoker ใด (ที่อยู่ผู้เรียกใช้) และอนุญาตให้ดําเนินการตามสัญญา Invoker นั้น (ผูกมัด)
กระบวนการดําเนินการจริงอาจมีลักษณะดังนี้:
หมายเหตุ 1: ไม่จําเป็นต้องใช้ Relayer อลิซยังสามารถนําเนื้อหาลายเซ็นของเธอเองและประทับตราไปยังห่วงโซ่
หลังจาก Invoker ตรวจสอบลายเซ็นและเริ่มดําเนินการแล้วมันจะถูกดําเนินการเป็น Alice EOA ซึ่งเหมือนกับการได้รับการควบคุม (จํากัด ) ของ EOA
อย่างไรก็ตามควรสังเกตว่าค่า nonce ของ EOA จะไม่เพิ่มขึ้นหลังจากการดําเนินการดังนั้นลายเซ็นเดียวกันอาจถูกนํากลับมาใช้ใหม่ (ตราบใดที่ EOA nonce ยังคงไม่เปลี่ยนแปลง) ดังนั้น Invoker จึงจําเป็นต้องใช้กลไก nonce ของตัวเองเพื่อหลีกเลี่ยงการเล่นซ้ํา
หากสัญญา Invoker ไม่สามารถเล่นซ้ําได้การอนุญาตเดียวกันสามารถดําเนินการได้ตลอดเวลา
สําหรับการแนะนํากลไกการทํางานจริงของ EIP-3074 โปรดดูที่: ความรู้เบื้องต้นเกี่ยวกับ EIP3074
อนุญาตให้ผู้ใช้รวมการดําเนินการหลายธุรกรรมเป็นหนึ่งเดียวช่วยประหยัดกระบวนการของลายเซ็นที่ได้รับอนุญาตหลายรายการและค่าใช้จ่ายก๊าซบางส่วน
หมายเหตุ: สิ่งนี้จะต้องใช้ dApp เพื่อรองรับฟังก์ชัน Batchcall เช่น EIP-5792 ซึ่งกําลังถูกผลักดันโดยชุมชน มิฉะนั้น dApp จะแจ้งให้ผู้ใช้ลงนามเพียงครั้งเดียวสําหรับแต่ละการดําเนินการหากถือว่าผู้ใช้เป็น EOA ปกติ
Users ยังสามารถอนุญาตให้บุคคลที่สามดําเนินการในนามของพวกเขาภายใต้เงื่อนไขบางประการ คีย์ผู้รับมอบสิทธิ์ในแผนภาพด้านล่างเป็นบุคคลที่สามที่ได้รับอนุญาต นโยบายการเข้าถึงคือข้อ จํากัด ในการดําเนินการเช่นการ จํากัด ให้ใช้งาน Uniswap เท่านั้นโอนสูงสุด 1 ETH ต่อวันระยะเวลาการอนุญาตเป็นต้น เงื่อนไขเหล่านี้ได้รับการออกแบบและตรวจสอบภายในสัญญา Invoker ตราบใดที่การตรวจสอบผ่านไปบุคคลที่สามสามารถดําเนินการในฐานะ EOA ของผู้ใช้ได้
Telegram Bot สามารถให้สิทธิ์เฉพาะในการดําเนินการในนามของ EOA ของผู้ใช้
ตราบใดที่ตรงตามเงื่อนไข (นั่นคือลายเซ็นใบอนุญาตถูกกฎหมาย) การถ่ายโอน ETH สามารถดําเนินการในฐานะผู้อนุญาต EOA ซึ่งบรรลุผลของใบอนุญาต ETH ดั้งเดิม
ผู้ใช้กรอกเงื่อนไขคําสั่งจํากัดและเมื่อตรงตามเงื่อนไขก็สามารถดําเนินการในฐานะผู้ใช้ EOA รวมถึงการอนุมัติโทเค็นให้กับ DEX ไปที่ DEX เพื่อไถ่ถอน เมื่อเทียบกับ Limit Order ที่ DEX จัดหาให้ผู้ใช้ไม่จําเป็นต้องส่งธุรกรรมไปยัง DEX เพื่อขออนุมัติล่วงหน้า
เมื่ออลิซทําตามคําสั่งเธอจะดําเนินการอนุมัติในเวลาเดียวกันโดยไม่จําเป็นต้องได้รับการอนุมัติล่วงหน้า
หากเงื่อนไขได้รับการออกแบบให้มีลักษณะทั่วไปมากขึ้นมันจะกลายเป็นเหมือนสัญญาเจตนา: ตราบใดที่เป็นไปตามเงื่อนไขที่กําหนดโดยผู้ใช้ทุกคนสามารถดําเนินการตามเจตนาในนามของ EOA ของพวกเขาได้
ตราบใดที่ตรงตามเงื่อนไขเจตนาทุกคนสามารถเริ่มการดําเนินการในชื่อของ EOA ของผู้ใช้
เมื่อผู้ใช้สูญเสียคีย์ส่วนตัว EOA เธอ (อลิซ) สามารถใช้การอนุญาต EIP-3074 ที่เธอลงนามพร้อมกับลายเซ็นของผู้มีอํานาจของเธอ (สามีและตัวแทนทรัสต์) เพื่อโอนทรัพย์สินทั้งหมดของ EOA ในความเป็นจริงสิ่งที่กู้คืนคือสินทรัพย์ (โอนได้) ไม่ใช่การควบคุมบัญชี หลังจากคีย์ส่วนตัว EOA สูญหาย EOA จะไม่สามารถใช้งานได้อีกต่อไป
เมื่อผู้ใช้สูญเสียคีย์ส่วนตัว EOA ผู้มีอํานาจอื่น ๆ สามารถลงนามและอนุมัติการโอนสินทรัพย์ EOA ได้
การปรับปรุงวิธีการอนุญาตโทเค็น และอาจแทนที่การอนุมัติ/ใบอนุญาต?
ปัจจุบัน 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 บางอย่างหรือไม่ (แต่จะใช้สําหรับการหลอกลวง)
ผู้ใช้ไม่ได้อนุญาตที่อยู่ที่แน่นอนอีกต่อไป แต่อนุญาตที่อยู่ที่แน่นอนและสิ่งที่ต้องทําและแม้แต่ดูผลการดําเนินการจําลอง
หมายเหตุ: นี่ไม่ได้หมายความว่าการหลอกลวงสามารถถูกบล็อกได้อย่างสมบูรณ์! ผู้ใช้อาจยังคงถูกหลอกให้เข้าสู่เว็บไซต์หลอกลวงและเว็บไซต์หลอกลวงยังสามารถจัดระเบียบการดําเนินการอนุมัติหรือถ่ายโอนเพื่อให้ผู้ใช้ลงนาม แต่ในเวลานี้ผู้ใช้อย่างน้อยสามารถดูว่าลายเซ็นนี้กําลังทําอะไรและกระเป๋าเงินยังสามารถจําลองผลการดําเนินการแสดงผลและนําเสนอต่อผู้ใช้เพื่อให้ผู้ใช้สามารถรู้ได้อย่างชัดเจนว่าใครจะเสียเงินเท่าไหร่และใครจะได้รับเงินเท่าไหร่ เมื่อเทียบกับใบอนุญาตที่ไม่ทราบว่าการดําเนินการหรือแม้แต่ผลการดําเนินการผู้ใช้มีข้อมูลเพิ่มเติมเพื่อตัดสินใจว่าจะอนุญาตหรือไม่ แม้ว่าจะไม่ใช่วิธีรักษาที่สมบูรณ์แบบ แต่ก็ยังเป็นการปรับปรุงที่สําคัญสําหรับสถานการณ์ปัจจุบัน
การออกแบบ 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 ใน EOA nonce ก่อนการตรวจสอบลายเซ็น EIP-3074 จะล้มเหลวเนื่องจาก EOA nonce ไม่ตรงกัน
หากผู้ใช้เพิ่ม 1 ลงใน EOA nonce ในลายเซ็น EIP-3074 ก่อนที่จะนําเข้าสู่ห่วงโซ่เองการตรวจสอบสามารถดําเนินการได้อย่างราบรื่น
ประสบการณ์การใช้งานที่ดีขึ้นและปลอดภัยยิ่งขึ้น
EIP-3074 ช่วยให้ EOA (บัญชีที่เป็นเจ้าของภายนอก) สามารถถ่ายโอนการควบคุมไปยังสัญญาที่ระบุจึงได้รับความสามารถในการดําเนินการที่หลากหลายเช่นเดียวกับสัญญา ก่อน EIP-3074 EOA สามารถดําเนินการได้เพียงหนึ่งครั้งต่อธุรกรรม เช่น การอนุมัติ ERC20 หรือการแลกเปลี่ยนบน Uniswap หลังจาก EIP-3074 EOA สามารถดําเนินการหลายอย่างพร้อมกันหรือแม้แต่ทํางานที่เป็นไปไม่ได้ก่อนหน้านี้ พูดง่ายๆก็คือ EIP-3074 ช่วยเพิ่มประสบการณ์ของผู้ใช้ได้อย่างมากและวิธีการอนุมัติโทเค็นที่คุ้นเคยจะถูกปรับเปลี่ยนใหม่เพิ่มความปลอดภัยโดยไม่ต้องเปลี่ยนประสบการณ์ของผู้ใช้
ยิ่งไปกว่านั้นผ่าน EIP-3074 EOA ไม่จําเป็นต้องส่งธุรกรรมไปยังห่วงโซ่ด้วยตัวเองอีกต่อไปขจัดปัญหาที่ต้องเพิ่ม ETH เพื่อชําระค่าธรรมเนียมการทําธุรกรรม
สัญญาที่สามารถควบคุม EOA ได้เรียกว่าสัญญา Invoker แน่นอนว่าไม่ใช่แค่สัญญาใด ๆ เท่านั้นที่สามารถควบคุม EOA ได้: EOA จะต้องลงนามด้วยคีย์ส่วนตัวและเนื้อหาของลายเซ็นจะระบุอย่างชัดเจนว่าเป็นสัญญา Invoker ใดและ Invoker ได้รับอนุญาตให้ดําเนินการใด
เนื้อหาลายเซ็นของ EOA จะระบุอย่างชัดเจนว่าสัญญา Invoker ใด (ที่อยู่ผู้เรียกใช้) และอนุญาตให้ดําเนินการตามสัญญา Invoker นั้น (ผูกมัด)
กระบวนการดําเนินการจริงอาจมีลักษณะดังนี้:
หมายเหตุ 1: ไม่จําเป็นต้องใช้ Relayer อลิซยังสามารถนําเนื้อหาลายเซ็นของเธอเองและประทับตราไปยังห่วงโซ่
หลังจาก Invoker ตรวจสอบลายเซ็นและเริ่มดําเนินการแล้วมันจะถูกดําเนินการเป็น Alice EOA ซึ่งเหมือนกับการได้รับการควบคุม (จํากัด ) ของ EOA
อย่างไรก็ตามควรสังเกตว่าค่า nonce ของ EOA จะไม่เพิ่มขึ้นหลังจากการดําเนินการดังนั้นลายเซ็นเดียวกันอาจถูกนํากลับมาใช้ใหม่ (ตราบใดที่ EOA nonce ยังคงไม่เปลี่ยนแปลง) ดังนั้น Invoker จึงจําเป็นต้องใช้กลไก nonce ของตัวเองเพื่อหลีกเลี่ยงการเล่นซ้ํา
หากสัญญา Invoker ไม่สามารถเล่นซ้ําได้การอนุญาตเดียวกันสามารถดําเนินการได้ตลอดเวลา
สําหรับการแนะนํากลไกการทํางานจริงของ EIP-3074 โปรดดูที่: ความรู้เบื้องต้นเกี่ยวกับ EIP3074
อนุญาตให้ผู้ใช้รวมการดําเนินการหลายธุรกรรมเป็นหนึ่งเดียวช่วยประหยัดกระบวนการของลายเซ็นที่ได้รับอนุญาตหลายรายการและค่าใช้จ่ายก๊าซบางส่วน
หมายเหตุ: สิ่งนี้จะต้องใช้ dApp เพื่อรองรับฟังก์ชัน Batchcall เช่น EIP-5792 ซึ่งกําลังถูกผลักดันโดยชุมชน มิฉะนั้น dApp จะแจ้งให้ผู้ใช้ลงนามเพียงครั้งเดียวสําหรับแต่ละการดําเนินการหากถือว่าผู้ใช้เป็น EOA ปกติ
Users ยังสามารถอนุญาตให้บุคคลที่สามดําเนินการในนามของพวกเขาภายใต้เงื่อนไขบางประการ คีย์ผู้รับมอบสิทธิ์ในแผนภาพด้านล่างเป็นบุคคลที่สามที่ได้รับอนุญาต นโยบายการเข้าถึงคือข้อ จํากัด ในการดําเนินการเช่นการ จํากัด ให้ใช้งาน Uniswap เท่านั้นโอนสูงสุด 1 ETH ต่อวันระยะเวลาการอนุญาตเป็นต้น เงื่อนไขเหล่านี้ได้รับการออกแบบและตรวจสอบภายในสัญญา Invoker ตราบใดที่การตรวจสอบผ่านไปบุคคลที่สามสามารถดําเนินการในฐานะ EOA ของผู้ใช้ได้
Telegram Bot สามารถให้สิทธิ์เฉพาะในการดําเนินการในนามของ EOA ของผู้ใช้
ตราบใดที่ตรงตามเงื่อนไข (นั่นคือลายเซ็นใบอนุญาตถูกกฎหมาย) การถ่ายโอน ETH สามารถดําเนินการในฐานะผู้อนุญาต EOA ซึ่งบรรลุผลของใบอนุญาต ETH ดั้งเดิม
ผู้ใช้กรอกเงื่อนไขคําสั่งจํากัดและเมื่อตรงตามเงื่อนไขก็สามารถดําเนินการในฐานะผู้ใช้ EOA รวมถึงการอนุมัติโทเค็นให้กับ DEX ไปที่ DEX เพื่อไถ่ถอน เมื่อเทียบกับ Limit Order ที่ DEX จัดหาให้ผู้ใช้ไม่จําเป็นต้องส่งธุรกรรมไปยัง DEX เพื่อขออนุมัติล่วงหน้า
เมื่ออลิซทําตามคําสั่งเธอจะดําเนินการอนุมัติในเวลาเดียวกันโดยไม่จําเป็นต้องได้รับการอนุมัติล่วงหน้า
หากเงื่อนไขได้รับการออกแบบให้มีลักษณะทั่วไปมากขึ้นมันจะกลายเป็นเหมือนสัญญาเจตนา: ตราบใดที่เป็นไปตามเงื่อนไขที่กําหนดโดยผู้ใช้ทุกคนสามารถดําเนินการตามเจตนาในนามของ EOA ของพวกเขาได้
ตราบใดที่ตรงตามเงื่อนไขเจตนาทุกคนสามารถเริ่มการดําเนินการในชื่อของ EOA ของผู้ใช้
เมื่อผู้ใช้สูญเสียคีย์ส่วนตัว EOA เธอ (อลิซ) สามารถใช้การอนุญาต EIP-3074 ที่เธอลงนามพร้อมกับลายเซ็นของผู้มีอํานาจของเธอ (สามีและตัวแทนทรัสต์) เพื่อโอนทรัพย์สินทั้งหมดของ EOA ในความเป็นจริงสิ่งที่กู้คืนคือสินทรัพย์ (โอนได้) ไม่ใช่การควบคุมบัญชี หลังจากคีย์ส่วนตัว EOA สูญหาย EOA จะไม่สามารถใช้งานได้อีกต่อไป
เมื่อผู้ใช้สูญเสียคีย์ส่วนตัว EOA ผู้มีอํานาจอื่น ๆ สามารถลงนามและอนุมัติการโอนสินทรัพย์ EOA ได้
การปรับปรุงวิธีการอนุญาตโทเค็น และอาจแทนที่การอนุมัติ/ใบอนุญาต?
ปัจจุบัน 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 บางอย่างหรือไม่ (แต่จะใช้สําหรับการหลอกลวง)
ผู้ใช้ไม่ได้อนุญาตที่อยู่ที่แน่นอนอีกต่อไป แต่อนุญาตที่อยู่ที่แน่นอนและสิ่งที่ต้องทําและแม้แต่ดูผลการดําเนินการจําลอง
หมายเหตุ: นี่ไม่ได้หมายความว่าการหลอกลวงสามารถถูกบล็อกได้อย่างสมบูรณ์! ผู้ใช้อาจยังคงถูกหลอกให้เข้าสู่เว็บไซต์หลอกลวงและเว็บไซต์หลอกลวงยังสามารถจัดระเบียบการดําเนินการอนุมัติหรือถ่ายโอนเพื่อให้ผู้ใช้ลงนาม แต่ในเวลานี้ผู้ใช้อย่างน้อยสามารถดูว่าลายเซ็นนี้กําลังทําอะไรและกระเป๋าเงินยังสามารถจําลองผลการดําเนินการแสดงผลและนําเสนอต่อผู้ใช้เพื่อให้ผู้ใช้สามารถรู้ได้อย่างชัดเจนว่าใครจะเสียเงินเท่าไหร่และใครจะได้รับเงินเท่าไหร่ เมื่อเทียบกับใบอนุญาตที่ไม่ทราบว่าการดําเนินการหรือแม้แต่ผลการดําเนินการผู้ใช้มีข้อมูลเพิ่มเติมเพื่อตัดสินใจว่าจะอนุญาตหรือไม่ แม้ว่าจะไม่ใช่วิธีรักษาที่สมบูรณ์แบบ แต่ก็ยังเป็นการปรับปรุงที่สําคัญสําหรับสถานการณ์ปัจจุบัน
การออกแบบ 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 ใน EOA nonce ก่อนการตรวจสอบลายเซ็น EIP-3074 จะล้มเหลวเนื่องจาก EOA nonce ไม่ตรงกัน
หากผู้ใช้เพิ่ม 1 ลงใน EOA nonce ในลายเซ็น EIP-3074 ก่อนที่จะนําเข้าสู่ห่วงโซ่เองการตรวจสอบสามารถดําเนินการได้อย่างราบรื่น