Pectra 7702

সারাংশ

EIP 7702 একটি EOA-তে কোড যোগ করার একটি মেকানিজম সংজ্ঞায়িত করে। এই প্রস্তাবটি লিগ্যাসি ইথিরিয়াম একাউন্ট, EOA-গুলোকে স্বল্পমেয়াদী কার্যকারিতা উন্নত করার সুযোগ দেয়, যা অ্যাপ্লিকেশনগুলোর ব্যবহারযোগ্যতা বাড়ায়। এটি একটি নতুন লেনদেন টাইপ: 4 ব্যবহার করে ইতিমধ্যে ডিপ্লয় করা কোডের দিকে একটি পয়েন্টার সেট করার মাধ্যমে করা হয়।

এই নতুন লেনদেন টাইপটি একটি অথোরাইজেশন লিস্ট বা অনুমোদনের তালিকা প্রবর্তন করে। তালিকার প্রতিটি অথোরাইজেশন টুপল (tuple) এভাবে সংজ্ঞায়িত করা হয়:

[ chain_id, address, nonce, y_parity, r, s ]

address হলো ডেলিগেশন (ইতিমধ্যে ডিপ্লয় করা বাইটকোড যা EOA দ্বারা ব্যবহৃত হবে) chain_id একটি নির্দিষ্ট চেইনে অনুমোদন লক করে (অথবা সব চেইনের জন্য 0) nonce একটি নির্দিষ্ট একাউন্ট নন্স-এ অনুমোদন লক করে (y_parity, r, s) হলো অথোরাইজেশন টুপলের সিগনেচার, যা EOA-এর প্রাইভেট কি দ্বারা keccak(0x05 || rlp ([chain_id ,address, nonce])) হিসেবে সংজ্ঞায়িত, যার উপর অনুমোদন প্রযোজ্য (যাকে অথরিটি বা কর্তৃপক্ষও বলা হয়)

নাল (null) এডড্রেস-এ ডেলিগেট করার মাধ্যমে একটি ডেলিগেশন রিসেট করা যেতে পারে।

ডেলিগেশনের পরেও EOA-এর প্রাইভেট কি একাউন্ট-এর উপর সম্পূর্ণ নিয়ন্ত্রণ বজায় রাখে। উদাহরণস্বরূপ, একটি Safe-এ ডেলিগেট করলে একাউন্টটি মাল্টিসিগ হয়ে যায় না কারণ এখনও একটি একক কি (key) রয়েছে যা যেকোনো সাইনিং পলিসি বাইপাস করতে পারে। সামনের দিকে, ডেভেলপারদের এই ধারণা নিয়ে ডিজাইন করা উচিত যে সিস্টেমের যেকোনো অংশগ্রহণকারী একটি স্মার্ট কন্ট্রাক্ট হতে পারে। স্মার্ট কন্ট্রাক্ট ডেভেলপারদের জন্য, tx.origin একটি EOA-কে নির্দেশ করে এমনটা ধরে নেওয়া আর নিরাপদ নয়।

সর্বোত্তম অনুশীলন

একাউন্ট অ্যাবস্ট্রাকশন: সামঞ্জস্যতা সর্বাধিক করার জন্য একটি ডেলিগেশন কন্ট্রাক্ট ইথিরিয়ামের বৃহত্তর একাউন্ট অ্যাবস্ট্রাকশন (AA) স্ট্যান্ডার্ডগুলোর সাথে সামঞ্জস্যপূর্ণ হওয়া উচিত। বিশেষ করে, এটি আদর্শভাবে ERC-4337 কমপ্লায়েন্ট বা সামঞ্জস্যপূর্ণ হওয়া উচিত।

পারমিশনলেস এবং সেন্সরশিপ-প্রতিরোধী ডিজাইন: ইথিরিয়াম পারমিশনলেস অংশগ্রহণকে মূল্য দেয়। একটি ডেলিগেশন কন্ট্রাক্ট অবশ্যই কোনো একক “বিশ্বস্ত” রিলেয়ার বা পরিষেবার উপর হার্ড-কোড বা নির্ভর করবে না। রিলেয়ার অফলাইনে গেলে এটি একাউন্টটিকে অকেজো করে দেবে। ব্যাচিংয়ের মতো বৈশিষ্ট্যগুলো (যেমন, approve+transferFrom) কোনো রিলেয়ার ছাড়াই EOA নিজেই ব্যবহার করতে পারে। অ্যাপ্লিকেশন ডেভেলপার যারা 7702 দ্বারা সক্ষম উন্নত বৈশিষ্ট্যগুলো (গ্যাস অ্যাবস্ট্রাকশন, প্রাইভেসি-প্রিজার্ভিং উইথড্রয়াল) ব্যবহার করতে চান, তাদের একটি রিলেয়ার প্রয়োজন হবে। যদিও বিভিন্ন রিলেয়ার আর্কিটেকচার রয়েছে, আমাদের সুপারিশ হলো 4337 bundlers (opens in a new tab) ব্যবহার করা যা অন্তত entry point 0.8 (opens in a new tab)-কে নির্দেশ করে কারণ:

এগুলো রিলে করার জন্য প্রমিত ইন্টারফেস প্রদান করে
বিল্ট-ইন পেমাস্টার সিস্টেম অন্তর্ভুক্ত করে
ফরোয়ার্ড সামঞ্জস্যতা নিশ্চিত করে
একটি public mempool (opens in a new tab)-এর মাধ্যমে সেন্সরশিপ প্রতিরোধ সমর্থন করতে পারে
init ফাংশনটি শুধুমাত্র EntryPoint (opens in a new tab) থেকে কল করার প্রয়োজন হতে পারে

অন্য কথায়, যে কেউ লেনদেন স্পনসর/রিলেয়ার হিসেবে কাজ করতে সক্ষম হওয়া উচিত যতক্ষণ না তারা একাউন্ট থেকে প্রয়োজনীয় বৈধ সিগনেচার বা UserOperation প্রদান করে। এটি সেন্সরশিপ প্রতিরোধ নিশ্চিত করে: যদি কোনো কাস্টম অবকাঠামোর প্রয়োজন না হয়, তবে একজন ব্যবহারকারীর লেনদেন কোনো গেটকিপিং রিলে দ্বারা ইচ্ছামতো ব্লক করা যাবে না। উদাহরণস্বরূপ, MetaMask’s Delegation Toolkit (opens in a new tab) স্পষ্টভাবে যেকোনো চেইনে যেকোনো ERC-4337 বান্ডলার বা পেমাস্টারের সাথে কাজ করে, এর জন্য কোনো MetaMask-নির্দিষ্ট সার্ভারের প্রয়োজন হয় না।

ওয়ালেট ইন্টারফেসের মাধ্যমে ডিএ্যাপস ইন্টিগ্রেশন:

যেহেতু ওয়ালেটগুলো EIP-7702-এর জন্য নির্দিষ্ট ডেলিগেশন কন্ট্রাক্টগুলোকে হোয়াইটলিস্ট করবে, তাই ডিএ্যাপস-এর সরাসরি 7702 অনুমোদনের অনুরোধ করার আশা করা উচিত নয়। এর পরিবর্তে, প্রমিত ওয়ালেট ইন্টারফেসের মাধ্যমে ইন্টিগ্রেশন হওয়া উচিত:

ERC-5792 (wallet_sendCalls): ডিএ্যাপস-কে ব্যাচ করা কলগুলো কার্যকর করার জন্য ওয়ালেটগুলোকে অনুরোধ করতে সক্ষম করে, যা লেনদেন ব্যাচিং এবং গ্যাস অ্যাবস্ট্রাকশনের মতো কার্যকারিতাগুলোকে সহজতর করে।
ERC-6900: ডিএ্যাপস-কে ওয়ালেট-পরিচালিত মডিউলগুলোর মাধ্যমে মডুলার স্মার্ট একাউন্ট ক্ষমতাগুলো, যেমন সেশন কি এবং একাউন্ট রিকভারি ব্যবহার করার অনুমতি দেয়।

এই ইন্টারফেসগুলো ব্যবহার করে, ডিএ্যাপস সরাসরি ডেলিগেশন পরিচালনা না করেই EIP-7702 দ্বারা প্রদত্ত স্মার্ট একাউন্ট কার্যকারিতাগুলো অ্যাক্সেস করতে পারে, যা বিভিন্ন ওয়ালেট বাস্তবায়নের মধ্যে সামঞ্জস্যতা এবং নিরাপত্তা নিশ্চিত করে।

দ্রষ্টব্য: ডিএ্যাপস-এর জন্য সরাসরি 7702 অনুমোদন সিগনেচার অনুরোধ করার কোনো প্রমিত পদ্ধতি নেই। EIP-7702 বৈশিষ্ট্যগুলোর সুবিধা নিতে ডিএ্যাপস-কে অবশ্যই ERC-6900-এর মতো নির্দিষ্ট ওয়ালেট ইন্টারফেসের ওপর নির্ভর করতে হবে।

আরও তথ্যের জন্য:

ভেন্ডর লক-ইন এড়ানো: উপরের কথার সাথে সামঞ্জস্য রেখে, একটি ভালো বাস্তবায়ন হলো ভেন্ডর-নিরপেক্ষ এবং ইন্টারঅপারেবল। এর মানে প্রায়শই স্মার্ট একাউন্ট-এর জন্য উদীয়মান স্ট্যান্ডার্ডগুলো মেনে চলা। উদাহরণস্বরূপ, Alchemy’s Modular Account (opens in a new tab) মডুলার স্মার্ট একাউন্ট-এর জন্য ERC-6900 স্ট্যান্ডার্ড ব্যবহার করে এবং এটি “পারমিশনলেস ইন্টারঅপারেবল ব্যবহার”-এর কথা মাথায় রেখে ডিজাইন করা হয়েছে।

প্রাইভেসি সংরক্ষণ: যদিও অনচেইন প্রাইভেসি সীমিত, একটি ডেলিগেশন কন্ট্রাক্ট-এর উচিত ডেটা এক্সপোজার এবং লিংকেবিলিটি কমানোর চেষ্টা করা। এটি ERC-20 টোকেনে গ্যাস পেমেন্টের মতো বৈশিষ্ট্যগুলো সমর্থন করার মাধ্যমে অর্জন করা যেতে পারে (যাতে ব্যবহারকারীদের একটি পাবলিক ETH ব্যালেন্স বজায় রাখার প্রয়োজন না হয়, যা প্রাইভেসি এবং UX উন্নত করে) এবং ওয়ান-টাইম সেশন কি (যা একটি একক দীর্ঘমেয়াদী কি-এর ওপর নির্ভরতা কমায়)। উদাহরণস্বরূপ, EIP-7702 স্পনসর করা লেনদেন-এর মাধ্যমে টোকেনে গ্যাস পেমেন্ট করতে সক্ষম করে, এবং একটি ভালো বাস্তবায়ন প্রয়োজনের চেয়ে বেশি তথ্য ফাঁস না করে এই ধরনের পেমাস্টারগুলোকে একীভূত করা সহজ করে তুলবে। উপরন্তু, নির্দিষ্ট অনুমোদনের অফচেইন ডেলিগেশন (অনচেইন যাচাই করা সিগনেচার ব্যবহার করে) মানে ব্যবহারকারীর প্রাইমারি কি-এর সাথে কম অনচেইন লেনদেন, যা প্রাইভেসি বজায় রাখতে সাহায্য করে। যেসব একাউন্ট-এ রিলেয়ার ব্যবহার করার প্রয়োজন হয় সেগুলো ব্যবহারকারীদের তাদের আইপি (IP) এডড্রেস প্রকাশ করতে বাধ্য করে। PublicMempools এটি উন্নত করে, যখন একটি লেনদেন/UserOp মেমপুলের মাধ্যমে ছড়ায় তখন আপনি বলতে পারবেন না যে এটি যে আইপি থেকে পাঠানো হয়েছে সেখান থেকেই উদ্ভূত হয়েছে, নাকি p2p প্রটোকল-এর মাধ্যমে শুধু রিলে করা হয়েছে।

এক্সটেনসিবিলিটি এবং মডুলার সিকিউরিটি: একাউন্ট বাস্তবায়নগুলো এক্সটেনসিবল হওয়া উচিত যাতে সেগুলো নতুন বৈশিষ্ট্য এবং নিরাপত্তা উন্নতির সাথে বিকশিত হতে পারে। EIP-7702-এর সাথে আপগ্রেডযোগ্যতা স্বভাবতই সম্ভব (যেহেতু একটি EOA ভবিষ্যতে তার লজিক আপগ্রেড করার জন্য সর্বদা একটি নতুন কন্ট্রাক্ট-এ ডেলিগেট করতে পারে)। আপগ্রেডযোগ্যতার বাইরে, একটি ভালো ডিজাইন মডুলারিটির অনুমতি দেয় – যেমন, বিভিন্ন সিগনেচার স্কিম বা স্পেন্ডিং পলিসির জন্য প্লাগ-ইন মডিউল – সম্পূর্ণভাবে পুনরায় ডিপ্লয় করার প্রয়োজন ছাড়াই। Alchemy-এর Account Kit এর একটি প্রধান উদাহরণ, যা ডেভেলপারদের ভ্যালিডেশন মডিউল (ECDSA, BLS ইত্যাদির মতো বিভিন্ন সিগনেচার টাইপের জন্য) এবং কাস্টম লজিকের জন্য এক্সিকিউশন মডিউল ইনস্টল করার অনুমতি দেয়। EIP-7702-সক্ষম একাউন্ট-এ বৃহত্তর নমনীয়তা এবং নিরাপত্তা অর্জনের জন্য, ডেভেলপারদের সরাসরি কোনো নির্দিষ্ট বাস্তবায়নের পরিবর্তে একটি প্রক্সি কন্ট্রাক্ট-এ ডেলিগেট করতে উৎসাহিত করা হয়। এই পদ্ধতিটি প্রতিটি পরিবর্তনের জন্য অতিরিক্ত EIP-7702 অনুমোদনের প্রয়োজন ছাড়াই নির্বিঘ্ন আপগ্রেড এবং মডুলারিটির অনুমতি দেয়।

প্রক্সি প্যাটার্নের সুবিধা:

আপগ্রেডযোগ্যতা: প্রক্সিকে একটি নতুন ইমপ্লিমেন্টেশন কন্ট্রাক্ট-এর দিকে নির্দেশ করে কন্ট্রাক্ট লজিক আপডেট করুন।
কাস্টম ইনিশিয়ালাইজেশন লজিক: প্রয়োজনীয় স্টেট ভেরিয়েবলগুলো নিরাপদে সেট আপ করতে প্রক্সির মধ্যে ইনিশিয়ালাইজেশন ফাংশনগুলো অন্তর্ভুক্ত করুন।

উদাহরণস্বরূপ, SafeEIP7702Proxy (opens in a new tab) প্রদর্শন করে যে কীভাবে EIP-7702-সামঞ্জস্যপূর্ণ একাউন্ট-এ নিরাপদে ডেলিগেশন ইনিশিয়ালাইজ এবং পরিচালনা করতে একটি প্রক্সি ব্যবহার করা যেতে পারে।

প্রক্সি প্যাটার্নের অসুবিধা:

বাহ্যিক অ্যাক্টরদের ওপর নির্ভরতা: কোনো অনিরাপদ কন্ট্রাক্ট-এ আপগ্রেড না করার জন্য আপনাকে একটি বাহ্যিক টিমের ওপর নির্ভর করতে হবে।

নিরাপত্তা বিবেচনা

রিএন্ট্রান্সি গার্ড: EIP-7702 ডেলিগেশন প্রবর্তনের সাথে, একজন ব্যবহারকারীর একাউন্ট গতিশীলভাবে একটি এক্সটার্নালি ওনড একাউন্ট (EOA) এবং একটি স্মার্ট কন্ট্রাক্ট (SC)-এর মধ্যে পরিবর্তন হতে পারে। এই নমনীয়তা একাউন্টটিকে লেনদেন শুরু করতে এবং কলের লক্ষ্য হতে উভয় ক্ষেত্রেই সক্ষম করে। ফলস্বরূপ, এমন পরিস্থিতিতে যেখানে একটি একাউন্ট নিজেকে কল করে এবং বাহ্যিক কল করে সেখানে msg.sender এবং tx.origin সমান হবে, যা নির্দিষ্ট নিরাপত্তা অনুমানগুলোকে ক্ষুণ্ন করে যা আগে সর্বদা tx.origin একটি EOA হওয়ার ওপর নির্ভর করত।

স্মার্ট কন্ট্রাক্ট ডেভেলপারদের জন্য, tx.origin একটি EOA-কে নির্দেশ করে এমনটা ধরে নেওয়া আর নিরাপদ নয়। একইভাবে, রিএন্ট্রান্সি অ্যাটাকের বিরুদ্ধে সুরক্ষাকবচ হিসেবে msg.sender == tx.origin ব্যবহার করা আর কোনো নির্ভরযোগ্য কৌশল নয়।

সামনের দিকে, ডেভেলপারদের এই ধারণা নিয়ে ডিজাইন করা উচিত যে সিস্টেমের যেকোনো অংশগ্রহণকারী একটি স্মার্ট কন্ট্রাক্ট হতে পারে। বিকল্পভাবে তারা একটি nonReentrant মডিফায়ার প্যাটার্নের সাথে রিএন্ট্রান্সি গার্ড ব্যবহার করে স্পষ্ট রিএন্ট্রান্সি সুরক্ষা বাস্তবায়ন করতে পারে। আমরা একটি অডিটেড মডিফায়ার অনুসরণ করার পরামর্শ দিই, যেমন Open Zeppelin's Reentrancy Guard (opens in a new tab)। তারা একটি transient storage variable (opens in a new tab)-ও ব্যবহার করতে পারে।

ইনিশিয়ালাইজেশন নিরাপত্তা বিবেচনা

EIP-7702 ডেলিগেশন কন্ট্রাক্ট বাস্তবায়ন করা নির্দিষ্ট নিরাপত্তা চ্যালেঞ্জ তৈরি করে, বিশেষ করে ইনিশিয়ালাইজেশন প্রক্রিয়া সম্পর্কিত। একটি গুরুতর দুর্বলতা দেখা দেয় যখন ইনিশিয়ালাইজেশন ফাংশন (init) ডেলিগেশন প্রক্রিয়ার সাথে পারমাণবিকভাবে (atomically) যুক্ত থাকে। এই ধরনের ক্ষেত্রে, একজন ফ্রন্টরানার ডেলিগেশন সিগনেচার আটকাতে পারে এবং পরিবর্তিত প্যারামিটারগুলোর সাথে init ফাংশনটি কার্যকর করতে পারে, যা সম্ভাব্যভাবে একাউন্ট-এর নিয়ন্ত্রণ নিতে পারে।

এই ঝুঁকিটি বিশেষত প্রাসঙ্গিক যখন তাদের ইনিশিয়ালাইজেশন মেকানিজম পরিবর্তন না করেই EIP-7702-এর সাথে বিদ্যমান স্মার্ট কন্ট্রাক্ট একাউন্ট (SCA) বাস্তবায়নগুলো ব্যবহার করার চেষ্টা করা হয়।

ইনিশিয়ালাইজেশন দুর্বলতা কমানোর সমাধান

initWithSig বাস্তবায়ন করুন
স্ট্যান্ডার্ড init ফাংশনটিকে একটি initWithSig ফাংশন দিয়ে প্রতিস্থাপন করুন যার জন্য ব্যবহারকারীকে ইনিশিয়ালাইজেশন প্যারামিটারগুলোতে সাইন করতে হবে। এই পদ্ধতিটি নিশ্চিত করে যে ইনিশিয়ালাইজেশন শুধুমাত্র ব্যবহারকারীর স্পষ্ট সম্মতির সাথেই এগিয়ে যেতে পারে, যার ফলে অননুমোদিত ইনিশিয়ালাইজেশন ঝুঁকি কমে যায়।
ERC-4337-এর EntryPoint ব্যবহার করুন
ইনিশিয়ালাইজেশন ফাংশনটি একচেটিয়াভাবে ERC-4337 EntryPoint কন্ট্রাক্ট থেকে কল করার প্রয়োজন করুন। এই পদ্ধতিটি ERC-4337 দ্বারা প্রদত্ত প্রমিত ভ্যালিডেশন এবং এক্সিকিউশন ফ্রেমওয়ার্ক ব্যবহার করে, যা ইনিশিয়ালাইজেশন প্রক্রিয়ায় নিরাপত্তার একটি অতিরিক্ত স্তর যোগ করে।
(দেখুন: Safe Docs (opens in a new tab))

এই সমাধানগুলো গ্রহণ করার মাধ্যমে, ডেভেলপাররা EIP-7702 ডেলিগেশন কন্ট্রাক্ট-এর নিরাপত্তা বাড়াতে পারে, যা ইনিশিয়ালাইজেশন পর্যায়ে সম্ভাব্য ফ্রন্টরানিং অ্যাটাকের বিরুদ্ধে সুরক্ষা দেয়।

স্টোরেজ কলিশন কোড ডেলিগেট করা বিদ্যমান স্টোরেজ পরিষ্কার করে না। একটি ডেলিগেশন কন্ট্রাক্ট থেকে অন্যটিতে মাইগ্রেট করার সময়, পূর্ববর্তী কন্ট্রাক্ট থেকে অবশিষ্ট ডেটা থেকে যায়। যদি নতুন কন্ট্রাক্ট একই স্টোরেজ স্লটগুলো ব্যবহার করে কিন্তু সেগুলোকে ভিন্নভাবে ব্যাখ্যা করে, তবে এটি অনাকাঙ্ক্ষিত আচরণের কারণ হতে পারে। উদাহরণস্বরূপ, যদি প্রাথমিক ডেলিগেশন এমন একটি কন্ট্রাক্ট-এ হয় যেখানে একটি স্টোরেজ স্লট একটি bool উপস্থাপন করে, এবং পরবর্তী ডেলিগেশন এমন একটি কন্ট্রাক্ট-এ হয় যেখানে একই স্লট একটি uint উপস্থাপন করে, তবে এই অমিল অপ্রত্যাশিত ফলাফলের দিকে নিয়ে যেতে পারে।

ফিশিং ঝুঁকি EIP-7702 ডেলিগেশন বাস্তবায়নের সাথে, একজন ব্যবহারকারীর একাউন্ট-এর সম্পদগুলো সম্পূর্ণভাবে স্মার্ট কন্ট্রাক্ট দ্বারা নিয়ন্ত্রিত হতে পারে। যদি কোনো ব্যবহারকারী অজান্তে তাদের একাউন্ট একটি ক্ষতিকারক কন্ট্রাক্ট-এ ডেলিগেট করে, তবে একজন আক্রমণকারী সহজেই নিয়ন্ত্রণ নিতে পারে এবং তহবিল চুরি করতে পারে। chain_id=0 ব্যবহার করার সময় ডেলিগেশন সমস্ত চেইন আইডিতে প্রয়োগ করা হয়। শুধুমাত্র একটি ইমমিউটেবল কন্ট্রাক্ট-এ ডেলিগেট করুন (কখনও প্রক্সিতে ডেলিগেট করবেন না), এবং শুধুমাত্র সেই কন্ট্রাক্টগুলোতে যা CREATE2 ব্যবহার করে ডিপ্লয় করা হয়েছিল (স্ট্যান্ডার্ড initcode সহ - কোনো মেটামরফিক কন্ট্রাক্ট নয়) যাতে ডিপ্লয়ার অন্য কোথাও একই এডড্রেস-এ ভিন্ন কিছু ডিপ্লয় করতে না পারে। অন্যথায় আপনার ডেলিগেশন অন্যান্য সমস্ত EVM চেইনে আপনার একাউন্ট-কে ঝুঁকিতে ফেলে।

যখন ব্যবহারকারীরা ডেলিগেটেড সিগনেচার সম্পাদন করে, তখন ফিশিং ঝুঁকি কমাতে সাহায্য করার জন্য ডেলিগেশন গ্রহণকারী টার্গেট কন্ট্রাক্টটি স্পষ্টভাবে এবং বিশিষ্টভাবে প্রদর্শন করা উচিত।

ন্যূনতম বিশ্বস্ত সারফেস এবং নিরাপত্তা: নমনীয়তা প্রদান করার সময়, একটি ডেলিগেশন কন্ট্রাক্ট-এর মূল লজিক ন্যূনতম এবং অডিটেবল রাখা উচিত। কন্ট্রাক্টটি কার্যকরভাবে ব্যবহারকারীর EOA-এর একটি এক্সটেনশন, তাই যেকোনো ত্রুটি বিপর্যয়কর হতে পারে। বাস্তবায়নগুলোর স্মার্ট কন্ট্রাক্ট নিরাপত্তা সম্প্রদায়ের সর্বোত্তম অনুশীলনগুলো অনুসরণ করা উচিত। উদাহরণস্বরূপ, কনস্ট্রাক্টর বা ইনিশিয়ালাইজার ফাংশনগুলো অবশ্যই সাবধানে সুরক্ষিত করতে হবে – যেমনটি Alchemy দ্বারা হাইলাইট করা হয়েছে, যদি 7702-এর অধীনে একটি প্রক্সি প্যাটার্ন ব্যবহার করা হয়, তবে একটি অরক্ষিত ইনিশিয়ালাইজার একজন আক্রমণকারীকে একাউন্ট-এর নিয়ন্ত্রণ নিতে দিতে পারে। টিমগুলোর অনচেইন কোড সহজ রাখার লক্ষ্য রাখা উচিত: Ambire-এর 7702 কন্ট্রাক্টটি শুধুমাত্র ~200 লাইনের Solidity, যা বাগ কমানোর জন্য ইচ্ছাকৃতভাবে জটিলতা কমিয়ে দেয়। বৈশিষ্ট্য-সমৃদ্ধ লজিক এবং অডিটিং সহজ করে এমন সরলতার মধ্যে একটি ভারসাম্য বজায় রাখতে হবে।

পরিচিত বাস্তবায়নগুলো

EIP 7702-এর প্রকৃতির কারণে, ব্যবহারকারীদের কোনো ৩য় পক্ষের কন্ট্রাক্ট-এ ডেলিগেট করতে সাহায্য করার সময় ওয়ালেটগুলোকে সতর্কতা অবলম্বন করার পরামর্শ দেওয়া হয়। নিচে অডিট করা হয়েছে এমন পরিচিত বাস্তবায়নগুলোর একটি সংগ্রহ তালিকাভুক্ত করা হলো:

কন্ট্রাক্ট এডড্রেস	সোর্স	অডিট
0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00	Uniswap/calibur (opens in a new tab)	audits (opens in a new tab)
0x69007702764179f14F51cdce752f4f775d74E139	alchemyplatform/modular-account (opens in a new tab)	audits (opens in a new tab)
0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d	AmbireTech/ambire-common (opens in a new tab)	audits (opens in a new tab)
0x63c0c19a282a1b52b07dd5a65b58948a07dae32b	MetaMask/delegation-framework (opens in a new tab)	audits (opens in a new tab)
0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9	Ethereum Foundation AA team (opens in a new tab)	audits (opens in a new tab)
0x17c11FDdADac2b341F2455aFe988fec4c3ba26e3	Luganodes/Pectra-Batch-Contract (opens in a new tab)	audits (opens in a new tab)

হার্ডওয়্যার ওয়ালেট গাইডলাইন

হার্ডওয়্যার ওয়ালেটগুলোর নির্বিচারে ডেলিগেশন প্রকাশ করা উচিত নয়। হার্ডওয়্যার ওয়ালেট স্পেসে কনসেন্সাস হলো বিশ্বস্ত ডেলিগেটর কন্ট্রাক্টগুলোর একটি তালিকা ব্যবহার করা। আমরা উপরে তালিকাভুক্ত পরিচিত বাস্তবায়নগুলোকে অনুমতি দেওয়ার এবং কেস-বাই-কেস ভিত্তিতে অন্যদের বিবেচনা করার পরামর্শ দিই। যেহেতু আপনার EOA-কে একটি কন্ট্রাক্ট-এ ডেলিগেট করা সমস্ত সম্পদের ওপর নিয়ন্ত্রণ দেয়, তাই হার্ডওয়্যার ওয়ালেটগুলোর 7702 বাস্তবায়নের ক্ষেত্রে সতর্ক হওয়া উচিত।

কম্প্যানিয়ন অ্যাপগুলোর জন্য ইন্টিগ্রেশন দৃশ্যপট

লেজি (Lazy)

যেহেতু EOA এখনও যথারীতি কাজ করে, তাই করার কিছু নেই।

দ্রষ্টব্য: কিছু সম্পদ ডেলিগেশন কোড দ্বারা স্বয়ংক্রিয়ভাবে প্রত্যাখ্যাত হতে পারে, যেমন ERC 1155 NFT, এবং সাপোর্ট টিমের এটি সম্পর্কে সচেতন হওয়া উচিত।

অ্যাওয়ার (Aware)

এর কোড চেক করে ব্যবহারকারীকে জানান যে EOA-এর জন্য একটি ডেলিগেশন রয়েছে এবং ঐচ্ছিকভাবে ডেলিগেশনটি সরিয়ে ফেলার প্রস্তাব দিন।

সাধারণ ডেলিগেশন

হার্ডওয়্যার প্রদানকারী পরিচিত ডেলিগেশন কন্ট্রাক্টগুলোকে হোয়াইটলিস্ট করে এবং সফটওয়্যার কম্প্যানিয়নে তাদের সাপোর্ট বাস্তবায়ন করে। সম্পূর্ণ ERC 4337 সাপোর্টসহ একটি কন্ট্রাক্ট বেছে নেওয়ার পরামর্শ দেওয়া হয়।

ভিন্ন একটিতে ডেলিগেট করা EOA-গুলোকে স্ট্যান্ডার্ড EOA হিসেবে পরিচালনা করা হবে।

কাস্টম ডেলিগেশন

হার্ডওয়্যার প্রদানকারী তার নিজস্ব ডেলিগেশন কন্ট্রাক্ট বাস্তবায়ন করে এবং এটিকে তালিকায় যোগ করে সফটওয়্যার কম্প্যানিয়নে এর সাপোর্ট বাস্তবায়ন করে। সম্পূর্ণ ERC 4337 সাপোর্টসহ একটি কন্ট্রাক্ট তৈরি করার পরামর্শ দেওয়া হয়।