ทําไมเราถึงต้องการ Account Abstraction?

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

ตัวอย่างเช่น หลายคนคิดว่าการใช้คีย์นั้นซับซ้อนกว่าการใช้อีเมลเพื่อจัดการบัญชี การจัดการคีย์เป็นเรื่องยากและไม่ปลอดภัย และการถ่ายโอนแต่ละครั้ง (เช่น USDC) ต้องใช้โทเค็นดั้งเดิม (เช่น Ether และ Sol) ซึ่งขัดกัน

ในบริบทนี้ผู้คนจํานวนมากหันมาให้ความสนใจกับสาขานามธรรมของบัญชีเพื่อปรับปรุงประสบการณ์ของผู้ใช้ในการโต้ตอบแบบ on-chain และอํานวยความสะดวกในการยอมรับจํานวนมาก

ในกระบวนการสํารวจ Ethereum เสนอโซลูชันนามธรรมบัญชีเช่น ERC-4337, EIP-3074 และ EIP-7702 L1 อื่น ๆ เช่น Solana มีคุณสมบัติที่เปิดใช้งานนามธรรมบัญชีระดับโปรโตคอลเช่น Program Derived Addresses (PDA) และ Cosmos ยังมีการออกแบบที่คล้ายกันเช่น x / authz และ Fee Abstraction Module ในบทความนี้เราจะแนะนําและเปรียบเทียบโซลูชันที่กล่าวถึงข้างต้นจัดเรียงรายละเอียดปลีกย่อยของการออกแบบโซลูชันที่แตกต่างกันและแสดงให้เห็นถึงการแลกเปลี่ยนและการพิจารณาโซลูชันที่แตกต่างกัน

Background

EOA เทียบกับบัญชีสัญญา

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

Account Abstraction

แนวคิดของบัญชีที่เป็นนามธรรมสามารถตรวจสอบย้อนกลับไปได้ในปี 2016 (https://github.com/ethereum/EIPs/issues/86) สิ่งที่เป็นนามธรรมของบัญชีขึ้นอยู่กับและสร้างบนบัญชีกระแสรายวันสองประเภทใน Ethereum - EOA และบัญชีสัญญา สิ่งนี้จะปรับปรุงประสบการณ์การโต้ตอบของผู้ใช้ Ethereum ด้วยวิธีต่อไปนี้:

1. อนุญาตให้ผู้ใช้ใช้ลายเซ็นหลายลายเซ็นเช่น Schnorr, BLS, ลายเซ็นหลังควอนตัม ฯลฯ
2. อนุญาตให้ผู้ใช้ชําระค่าธรรมเนียมก๊าซโดยใช้โทเค็น ERC20 หรือตรรกะการชําระเงินที่กําหนดเอง
3. อนุญาตให้ผู้ใช้ดึงบัญชีของตนโดยใช้อีเมลโซเชียลมีเดีย ฯลฯ
4. อนุญาตให้ผู้ใช้จัดการเงินในบัญชีของตนด้วยการอนุญาตอย่างละเอียดเช่นการตั้งค่าขีด จํากัด การถอนรายวัน
5. อนุญาตให้มีการดําเนินการแบบ on-chain หลายรายการในธุรกรรมอะตอมเดียว ตัวอย่างเช่น ผู้ใช้สามารถดําเนินการอนุมัติและสลับในธุรกรรม DEX ให้เสร็จสมบูรณ์ด้วยลายเซ็นเดียว

Ethereum Roadmap

แผนงาน Ethereum (https://ethereum.org/en/roadmap/) เน้นเส้นทางการอัปเกรดในอนาคตของ Ethereum ปัจจุบันการวิจัยส่วนใหญ่ในชุมชน Ethereum หมุนรอบแผนงาน Ethereum สิ่งที่เป็นนามธรรมของบัญชีเป็นส่วนสําคัญของสิ่งนี้:

ที่มา: https://x.com/VitalikButerin/status/1741190491578810445

ชุมชน Ethereum หวังว่าจะสร้าง ERC-4337 และใช้โซลูชันนามธรรมบัญชีภายในโปรโตคอลผ่านข้อเสนอเช่น EIP-3074 หรือ EIP-7702 และในที่สุดก็ถึงนามธรรมบัญชี Endgame

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

EIP-3074 vs ERC-4337

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

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

ERC-4337 รวมธุรกรรมสองรายการข้างต้นเป็นหนึ่งเดียว:

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

EIP-3074 และ ERC-4337 มีความคล้ายคลึงกัน แต่วิธีการใช้งาน EIP-3074 อยู่ในโปรโตคอลของ Ethereum:

ใน ERC-4337 เราอนุญาตให้ Bundler จัดการสินทรัพย์ในกระเป๋าเงินสัญญาอัจฉริยะแบบ on-chain ของเราผ่านลายเซ็น ใน EIP-3074 bundler ได้รับอนุญาตให้จัดการสินทรัพย์ในกระเป๋าเงิน EOA ของเราโดยตรงผ่านลายเซ็น ในการทําเช่นนี้ชุมชน Ethereum จําเป็นต้องเพิ่ม opcodes ใหม่สองตัวลงในโปรโตคอล Ethereum: AUTH และ AUTHCALL

AUTH ใช้เพื่อตรวจสอบว่าพฤติกรรมของ bundler ในการประมวลผลสินทรัพย์บัญชี EOA ของผู้ใช้ได้รับอนุญาตหรือไม่ และ AUTHCALL ใช้เพื่อ "หลอก" สัญญาอัจฉริยะของการโต้ตอบของผู้ใช้ (ในตัวอย่างของเรา USDC และ Uniswap) ทําให้สัญญาอัจฉริยะคิดว่าธุรกรรมนั้นมาจากบัญชี EOA ของผู้ใช้ ข้อดีของสิ่งนี้คือผู้ดูแล Uniswap และ USDC ไม่จําเป็นต้องอัปเกรดสัญญาอัจฉริยะที่ปรับใช้และในเวลาเดียวกันบัญชี EOA สามารถเพลิดเพลินกับฟังก์ชั่นของนามธรรมบัญชี

A การเปรียบเทียบระหว่าง EIP-3074 และ ERC-4337

ในชุมชน Ethereum โดยทั่วไป EIP หมายถึงข้อเสนอที่ต้องรองรับการอัปเกรด Ethereum ในขณะที่ ERC หมายถึงข้อกําหนดที่สามารถรองรับได้โดยไม่ต้องอัปเกรด Ethereum

ดังนั้นจึงเห็นได้จากการตั้งชื่อรูปแบบนามธรรมของบัญชีทั้งสองที่ ERC-4337 ใช้งานง่ายกว่า EIP-3074 เนื่องจาก ERC-4337 ไม่ต้องการฮาร์ดฟอร์คของเครือข่าย Ethereum นี่เป็นหนึ่งในเหตุผลที่ ERC-4337 เปิดตัวและมีการใช้มากขึ้นบนรูปหลายเหลี่ยมและฐาน แต่ EIP-3074 เพิ่งได้รับการยอมรับจาก 183rd Ethereum All Core Developers Execution Call (ACDE)

ที่มา: https://dune.com/niftytable/account-abstraction

นอกจากนี้ ERC-4337 กําหนดให้ผู้ใช้โยกย้ายบัญชีปัจจุบันไปยังบัญชีสัญญาใหม่และจําเป็นต้องได้รับการสนับสนุน DApp สําหรับ EIP-1271 เพื่อให้ทํางานได้ EIP-3074 ไม่ต้องการการสนับสนุนเพิ่มเติมเหล่านี้ นี่คือเหตุผลสําคัญสําหรับอัตราการยอมรับต่ําของ ERC-4337 ในเวลาเดียวกัน ERC-4337 ไม่สามารถรองรับลายเซ็นเดียวเพื่ออนุญาตการดําเนินการแบบ on-chain หลายรายการโดยไม่ต้องแนะนําสัญญาหลายสายระดับกลาง แต่ EIP-3074 สามารถทําได้ซึ่งทําให้เกิดข้อ จํากัด ของ ERC-4337

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

ในเรื่องนี้ lightclient หนึ่งในผู้เขียน EIP-3074 ได้เสนอวิธีการบรรเทาเพื่อสกัดกั้นลายเซ็นที่เป็นอันตรายในระดับกระเป๋าเงิน สําหรับรายละเอียดโปรดดูที่: https://x.com/lightclients/status/1778823652584120497 ERC-4337 ไม่มีปัญหานี้แม้ว่าแฮกเกอร์จะยังคงสามารถหลอกลวงผู้ใช้ให้ลงชื่อเข้าใช้ UserOps ที่เป็นอันตรายได้ นี่เป็นเพราะความยากลําบากสําหรับ UserOp ที่จะได้รับอํานาจในการกําจัดสินทรัพย์ทั้งหมดในบัญชีผู้ใช้ ในขณะที่เขียนนักพัฒนาใน ACDE ตกลงที่จะลบ EIP-3704 ออกจาก Pectra Devent 0 และรวม EIP-7702 ใน Pectra Devnet 1 ถัดไป

มีอะไรเปลี่ยนแปลงใน EIP-7702?

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

ประโยชน์ของ EIP-7702 มีดังนี้:

1. สืบทอดข้อดีทั้งหมดของ EIP-3074: ไม่ต้องการให้ผู้ใช้เปลี่ยนจากบัญชี EOA เป็นบัญชีสัญญาอัจฉริยะที่มีที่อยู่ใหม่ สามารถดําเนินการหลายอย่างในธุรกรรมอะตอมเดียว
2. รหัสบัญชีสัญญาอัจฉริยะและโครงสร้างพื้นฐานของ ERC-4337 สามารถนํากลับมาใช้ใหม่ได้
3. abstraction บัญชีสัญญาอัจฉริยะที่แสดงโดย ERC-4337 และโซลูชันนามธรรมบัญชี EOA ที่แสดงโดย EIP-3074 สามารถรวมเข้าด้วยกันเพื่อป้องกันไม่ให้ Ethereum แยกออกเป็นสองระบบที่เป็นนามธรรมของบัญชีที่แตกต่างกันและปูทางสําหรับบัญชี Endgame Abstraction ในแผนงาน Ethereum
4. สอง opcodes AUTH และ AUTHCALL จะไม่ถูกเพิ่มลงใน EVM ของ Ethereum: เมื่อคํานึงถึงแผนงาน Ethereum บัญชี EOA จะถูกแปลงเป็นนามธรรมบัญชีในอนาคตและ opcodes ทั้งสองนี้จะซ้ําซ้อน

นอกเหนือจากนั้น EIP-7702 สืบทอดความเสี่ยงด้านความปลอดภัยทั้งหมดจาก EIP-3074

ชุมชนตัดสินใจที่จะรวม EIP-7702 ในการอัพเกรด Pectra ครั้งต่อไปในปี 2025 หากนําไปใช้จะเปลี่ยนแปลงระบบนิเวศของ Ethereum อย่างมากและนําการปรับปรุงที่เพิ่มขึ้นมาสู่โครงสร้างพื้นฐานที่เป็นนามธรรมของบัญชีเวอร์ชัน ERC-4337 ในปัจจุบัน

Solana's Program Derived Address

Account Abstraction on

Solana Solana's account abstraction is similar to Ethereum's ERC-4337. พวกเขาเป็นบัญชีที่ได้มาจากบัญชีเดิม (คล้ายกับบัญชี EOWA) คล้ายกับบัญชีสัญญา 4337 ก่อนที่จะเข้าใจสิ่งที่เป็นนามธรรมของบัญชีของ Solana จําเป็นต้องเข้าใจรูปแบบบัญชีที่ Solana ใช้

พูดอย่างกว้าง ๆ บัญชีสามารถจัดประเภทเป็นบัญชีปฏิบัติการซึ่งสามารถรันโค้ดหรือบัญชีที่ไม่สามารถดําเนินการได้ซึ่งไม่สามารถทําได้ การตรวจสอบเพิ่มเติมนี้มีบัญชีสามประเภทใน Solana: Native Program, Program Account และ Data Account

โปรแกรมเนทีฟเป็นส่วนหนึ่งของการใช้งานตัวตรวจสอบความถูกต้องและให้ฟังก์ชันหลักสําหรับเครือข่าย Solana เช่นการสร้างบัญชีข้อมูลใหม่และโปรแกรมที่กําหนดเอง บัญชีโปรแกรมเป็นโปรแกรมแบบกําหนดเองที่มีรหัสปฏิบัติการ บัญชีข้อมูลสามารถจัดเก็บข้อมูลและจัดการสถานะโปรแกรมตามที่กําหนดโดยบัญชีโปรแกรมเจ้าของ

รูปแบบบัญชีนี้ช่วยให้บัญชีโปรแกรมสามารถสร้างและจัดการบัญชีเฉพาะทําให้นักพัฒนาสามารถกําหนดกฎและตรรกะที่กําหนดเองสําหรับการจัดการได้ เปิดใช้งานโดยรูปแบบบัญชีนี้ Program Derived Address (PDA) ซึ่งเป็นบัญชีข้อมูลประเภทหนึ่งขยายความเป็นไปได้ของความสามารถในการเป็นนามธรรมของบัญชีบน Solana จากการเพิ่มความปลอดภัยของผู้ใช้ผ่านกระเป๋าเงิน multisig และการตรวจสอบสิทธิ์แบบสองปัจจัยไปจนถึงการเปิดใช้งานกลไกการกู้คืนทางสังคม

Program Derived Address

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

PDA และ Account Abstraction

โอเคตอนนี้เราเข้าใจแล้วว่า PDA ได้มาอย่างไรคุณอาจสงสัยว่าแนวคิดเหล่านี้เชื่อมโยงกับนามธรรมของบัญชีอย่างไร สิ่งที่เป็นนามธรรมของบัญชีเกิดขึ้นภายใต้ประทุนผ่านประสิทธิภาพของฟังก์ชันที่เรียกว่า Cross Program Invocation (CPI)

CPI เป็นฟังก์ชันที่ช่วยให้โปรแกรมสามารถเรียกใช้คําแนะนําของโปรแกรมอื่นทําให้สามารถเขียนโปรแกรม Solana ได้ เมื่อโปรแกรมเริ่มต้น CPI ผ่าน invoke_signed โปรแกรมจะสามารถลงนามในนามของพีดีเอ

ที่มา: Solana

ในการตรวจสอบความถูกต้องของธุรกรรมที่เกี่ยวข้องกับพีดีเอรันไทม์ Solana จะเรียก create_program_address ภายในโดยใช้ signers_seeds และ program_id ของโปรแกรมการโทร หากพบ PDA ที่ถูกต้องรันไทม์จะเชื่อมโยง PDA กับโปรแกรมการโทรและจดจําโปรแกรมในฐานะผู้ลงนามที่ได้รับอนุญาต

ปัจจุบัน Squads กําลังพัฒนาโซลูชันนามธรรมบัญชีบน Solana ตาม PDA อย่างไรก็ตามผลิตภัณฑ์ที่จัดทําโดย Squads นั้นคล้ายกับโซลูชันบัญชีสัญญาอัจฉริยะของ Gnosis Safe มากกว่าและยังไม่ได้พัฒนาฟังก์ชันนามธรรมของบัญชีอย่างเต็มที่

ประโยชน์ของพีดีเอ

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

ข้อจํากัดของพีดีเอ

1. พีดีเอแม้ว่าจะเป็นประโยชน์ในการวางรากฐานสําหรับความสามารถในการเป็นนามธรรมของบัญชี แต่ก็อาจมีความซับซ้อนในการใช้งานเมื่อเทียบกับบัญชี keypair
2. และเช่นเดียวกับ ERC-4337 ผู้ใช้ต้องทําการโยกย้ายบัญชีไปยังบัญชีใหม่ซึ่งอาจระงับอัตราการยอมรับของนามธรรมบัญชี Solana

Account Abstraction on Cosmos (Authz & Fee Grant)

Cosmos x/authz

ด้วยบัญชีที่เป็นนามธรรมมากขึ้นโดยใช้ mindshare ของนักพัฒนามากขึ้น authz ซึ่งเป็นส่วนหนึ่งของ Cosmos SDK หลักได้เปิดตัวเพื่อให้บัญชีดําเนินการบางอย่างในนามของบัญชีอื่นผ่านการใช้การให้สิทธิ์ซึ่งคล้ายกับ EIP-3074 และ EIP-7702

Authz มาพร้อมกับการอนุญาตที่กําหนดไว้ล่วงหน้าหลายประเภทซึ่งมอบหมายประสิทธิภาพของการกระทําบางอย่างเช่นการปักหลักให้กับผู้รับสิทธิ์ซึ่งช่วยเพิ่มประสบการณ์ของผู้ใช้

ด้วย authz สามารถให้การอนุญาตได้ 3 ประเภท:

1. GenericAuthorization การให้สิทธิ์นี้ให้สิทธิ์ที่ไม่จํากัดสําหรับผู้รับสิทธิ์ในการดําเนินการข้อความในนามของผู้ให้สิทธิ์
2. SendAuthorization การอนุญาตนี้เช่นเดียวกับการอนุมัติใน ERC20 พยายามที่จะให้ผู้รับสิทธิ์เข้าถึงวงเงินใช้จ่ายที่เป็นบวกซึ่งกําหนดจํานวนเงินสูงสุดที่สามารถใช้จ่ายในนามของผู้ให้ทุนได้
3. StakeAuthorization เงินช่วยเหลือนี้ช่วยให้ผู้รับทุนสามารถจัดการการดําเนินการปักหลักเช่นผู้รับมอบสิทธิ์ยกเลิกการมอบสิทธิ์หรือการมอบสิทธิ์ใหม่ในนามของผู้ให้สิทธิ์

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

การทําความเข้าใจกรอบการดําเนินงาน

Authz สามารถใช้เพื่อให้สิทธิ์สําหรับการดําเนินการที่หลากหลาย แต่เพื่อความเรียบง่ายเราจะตรวจสอบว่า authz ทํางานอย่างไรเพื่อเปิดใช้งานธุรกรรมการลงคะแนนทั่วไป

1. ใช้อินเทอร์เฟซการอนุญาตก่อนที่จะสามารถดําเนินการอนุญาตใด ๆ ในขั้นตอนนี้จะมีการกําหนดประเภทข้อความซึ่งในกรณีนี้จะเป็น MsgVote ที่นี่เราเห็นการอนุญาตจากอลิซสําหรับการดําเนินการลงคะแนนการกํากับดูแล
2. บ๊อบสร้างธุรกรรมการลงคะแนนเสียงที่ไม่ได้ลงนาม
3. บ๊อบสร้างธุรกรรมที่ลงนามและดําเนินการของการลงคะแนนเสียงจากผู้รับทุน การทําธุรกรรมเสร็จสมบูรณ์และการอนุญาตจะถูกลบออกหากหมดอายุ

ประโยชน์ที่ authz นํามา?

1. ความปลอดภัยในการดําเนินงาน: ผู้ตรวจสอบความถูกต้องและผู้ใช้รายอื่นสามารถให้สิทธิ์แก่บัญชีแยกต่างหากเพื่อลงคะแนนในข้อเสนอการกํากับดูแลหรือดําเนินการบางอย่างเพิ่มความปลอดภัยของบัญชีและลดภาระด้านความปลอดภัย
2. การดําเนินงานที่คล่องตัว: การทําธุรกรรมสามารถทําได้โดยต้องการเข้าถึงคีย์ผู้ตรวจสอบความถูกต้องธุรกรรมกระเป๋าเงิน multisig ยังสามารถปรับปรุงได้โดยใช้ธุรกรรมเดียวเพื่อให้ Authz แก่บัญชีผู้รับทุน
3. ไม่จําเป็นต้องย้ายข้อมูล: คล้ายกับ EIP-3074 และ EIP-7702 การดําเนินการให้สิทธิ์จะเกิดขึ้นในบัญชีเดิมของผู้ใช้ ผู้ใช้ไม่จําเป็นต้องโอนสินทรัพย์จากบัญชีเดิมไปยังบัญชีใหม่เพื่อเปิดใช้บทคัดย่อบัญชี
4. ประสิทธิภาพและความยืดหยุ่นในการดําเนินงานของ DAO: สามารถมอบสิทธิ์การดําเนินการบางส่วนให้กับสมาชิก DAO แต่ละคนสําหรับการดําเนินการเฉพาะ
5. Staking Reward Compounding: Authz อํานวยความสะดวกในการใช้งาน restaking และบริการเทียบเท่าสําหรับการทบต้นรางวัลการปักหลักโดยอัตโนมัติ

ข้อจํากัดและความเสี่ยงต่อ Authz:

ใส่ใจกับประเภทของธุรกรรมที่คุณอนุญาตผ่าน Authz การอนุญาตที่เป็นอันตรายสามารถดําเนินการการอนุญาตประเภทต่างๆ ที่อาจเป็นอันตรายต่อผู้ใช้

1. GenericAuthorization: ให้สิทธิ์ที่ไม่จํากัดในการดําเนินการ Msg ที่ให้ไว้ในนามของผู้ให้สิทธิ์ หากไม่ทราบอย่างถ่องแท้ถึงสิ่งที่คุณกําลังลงนามขอแนะนําอย่างยิ่งให้หลีกเลี่ยงการลงนามในประเภทการอนุญาตดังกล่าว กระเป๋าเงินบางใบอาจไม่มีคําเตือนเมื่อลงนามในธุรกรรม Authz
2. SendAuthorization: อนุญาตให้ผู้รับสิทธิ์ส่งจํานวนโทเค็นสูงสุดที่ผู้รับสามารถใช้จ่ายได้หากไม่ได้ระบุโดยผู้ให้สิทธิ์ สิ่งสําคัญคือต้องตรวจสอบรายการที่อนุญาตซึ่งระบุที่อยู่เฉพาะที่ผู้รับสิทธิ์สามารถส่งโทเค็นไปได้

Fee Grant Module

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

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

ประเภทของการให้สิทธิ์ค่าธรรมเนียม

ค่าเผื่อค่าธรรมเนียมสามารถแบ่งออกเป็นสองประเภท: BasicAllowance และ PeriodicAllowance

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

PeriodicAllowance ช่วยให้สามารถให้สิทธิ์ค่าธรรมเนียมต่ออายุเป็นระยะหลังจากแต่ละช่วงเวลาที่กําหนด Period_spend_limit ระบุจํานวนเหรียญสูงสุดที่สามารถใช้จ่ายในช่วงเวลานั้น Period_reset ติดตามว่าช่วงเวลาถัดไปควรเกิดขึ้นเมื่อใดและ period_can_spend ติดตามจํานวนเหรียญที่เหลือก่อนที่ช่วงเวลาใหม่จะเริ่มขึ้น

การทําความเข้าใจกรอบการดําเนินงาน

การใช้ AllowedMsgAllowance จะสร้างค่าเผื่อสําหรับชนิดข้อความที่ระบุ ค่าเผื่อสามารถเป็น BasicAllowance หรือ PeriodicAllowance ก็ได้ หากมีการตั้งเวลาหมดอายุ FeeAllowance จะถูกจัดคิวในรัฐโดยมีคํานําหน้าการหมดอายุต่อท้ายทุนและ Endblocker จะตรวจสอบสถานะ FeeAllowanceQueue สําหรับเงินช่วยเหลือที่หมดอายุ นอกเหนือจาก MsgGrantAllowance แล้ว ยังสามารถเพิกถอนค่าเผื่อค่าธรรมเนียมได้โดยใช้ MsgRevokeAllowance

เมื่อนํามารวมกันโมดูล Authz และ Fee Grant จะปลดล็อกกรณีการใช้งานที่เป็นนวัตกรรมและหลากหลายซึ่งท้ายที่สุดจะสร้างประสบการณ์การใช้งานที่ดีขึ้นในระบบนิเวศของ Cosmos

บทสรุป

บัญชีนามธรรม ณ วันที่ 27 พฤษภาคม 2024 ตัวเลขจะถูกประมาณการ

ด้วยการอนุมัติ Spot BTC ETF และ ETH ETF ความต้องการสถาบันและการค้าปลีกเพิ่มขึ้นอย่างมากโดยสัญญาว่าจะนําผู้ใช้คลื่นลูกใหม่ที่ต้องการสัมผัสกับอุตสาหกรรม สิ่งที่เป็นนามธรรมของบัญชีจะกลายเป็นเรื่องเล่าที่สําคัญในปีนี้เนื่องจากโปรโตคอลและ dapps พยายามสร้างประสบการณ์ที่ราบรื่นเพื่อขยายชุมชนของพวกเขา

การปฏิเสธความรับผิด

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

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

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

ติดตามข่าวสารล่าสุดของ HashKey Capital -

เว็บไซต์ — https://hashkey.capital/

ทวิตเตอร์ — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

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

1. บทความนี้พิมพ์ซ้ําจาก [Medium] ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [HashKey Capital] หากมีการคัดค้านการพิมพ์ซ้ํานี้ โปรดติดต่อทีม Gate Learn team และพวกเขาจะจัดการทันที

2. ข้อจํากัดความรับผิดชอบความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนและไม่ถือเป็นคําแนะนําการลงทุนใด ๆ

3. การแปลบทความเป็นภาษาอื่นทําโดยทีม Gate Learn ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปล

   แล้ว เว้นแต่จะกล่าวถึง