---
title: পেকট্রা 7702
metaTitle: Pectra EIP-7702 guidelines
description: পেকট্রা রিলিজে 7702 সম্পর্কে আরও জানুন
lang: bn
---

## সারাংশ
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-এ অর্পণ করলে অ্যাকাউন্টটি মাল্টিসিগ হয়ে যায় না কারণ এখনও একটি একক কী রয়েছে যা যেকোনো স্বাক্ষরকরণ নীতিকে বাইপাস করতে পারে। ভবিষ্যতে, ডেভেলপারদের এই ধারণা নিয়ে ডিজাইন করা উচিত যে সিস্টেমের যেকোনো অংশগ্রহণকারী একটি স্মার্ট কন্ট্রাক্ট হতে পারে। স্মার্ট কন্ট্রাক্ট ডেভেলপারদের জন্য, `tx.origin` একটি EOA-কে নির্দেশ করে এমনটা ধরে নেওয়া আর নিরাপদ নয়।
## সর্বোত্তম অনুশীলন
**অ্যাকাউন্ট বিমূর্তকরণ**: সামঞ্জস্যতা সর্বাধিক করার জন্য একটি অর্পণ কন্ট্রাক্ট ইথেরিয়ামের বৃহত্তর অ্যাকাউন্ট বিমূর্তকরণ (AA) মানগুলোর সাথে সামঞ্জস্যপূর্ণ হওয়া উচিত। বিশেষ করে, এটি আদর্শভাবে ERC-4337 অনুগত বা সামঞ্জস্যপূর্ণ হওয়া উচিত।

**পারমিশনলেস এবং সেন্সরশিপ-প্রতিরোধী ডিজাইন**: ইথেরিয়াম পারমিশনলেস অংশগ্রহণকে মূল্য দেয়। একটি অর্পণ কন্ট্রাক্টকে অবশ্যই কোনো একক "বিশ্বস্ত" রিলেয়ার বা পরিষেবার ওপর নির্ভর বা হার্ড-কোড করা উচিত নয়। রিলেয়ার অফলাইনে গেলে এটি অ্যাকাউন্টটিকে অকেজো করে দেবে। ব্যাচিং (যেমন, approve+transferFrom)-এর মতো বৈশিষ্ট্যগুলো রিলেয়ার ছাড়াই EOA নিজেই ব্যবহার করতে পারে। অ্যাপ্লিকেশন ডেভেলপার যারা EIP-7702 দ্বারা সক্ষম উন্নত বৈশিষ্ট্যগুলো (গ্যাস বিমূর্তকরণ, গোপনীয়তা-সংরক্ষণকারী উত্তোলন) ব্যবহার করতে চান, তাদের জন্য একটি রিলেয়ার প্রয়োজন হবে। যদিও বিভিন্ন রিলেয়ার আর্কিটেকচার রয়েছে, আমাদের সুপারিশ হলো [ERC-4337 বান্ডলার](https://www.erc4337.io/bundlers) ব্যবহার করা যা অন্তত [এন্ট্রি পয়েন্ট 0.8](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0)-কে নির্দেশ করে, কারণ:

- এগুলো রিলে করার জন্য প্রমিত ইন্টারফেস প্রদান করে
- বিল্ট-ইন পেমাস্টার সিস্টেম অন্তর্ভুক্ত করে
- ফরোয়ার্ড সামঞ্জস্যতা নিশ্চিত করে
- একটি [পাবলিক মেমপুল](https://notes.ethereum.org/@yoav/unified-erc-4337-mempool)-এর মাধ্যমে সেন্সরশিপ প্রতিরোধের সমর্থন করতে পারে
- init ফাংশনটিকে শুধুমাত্র [EntryPoint](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) থেকে কল করার প্রয়োজন করতে পারে

অন্য কথায়, যে কেউ ট্রানজ্যাকশন স্পনসর/রিলেয়ার হিসেবে কাজ করতে সক্ষম হওয়া উচিত যতক্ষণ না তারা অ্যাকাউন্ট থেকে প্রয়োজনীয় বৈধ স্বাক্ষর বা ব্যবহারকারী অপারেশন প্রদান করে। এটি সেন্সরশিপ প্রতিরোধ নিশ্চিত করে: যদি কোনো কাস্টম পরিকাঠামোর প্রয়োজন না হয়, তবে একজন ব্যবহারকারীর ট্রানজ্যাকশনগুলো কোনো গেটকিপিং রিলে দ্বারা ইচ্ছাকৃতভাবে ব্লক করা যাবে না। উদাহরণস্বরূপ, [মেটামাস্ক-এর ডেলিগেশন টুলকিট](https://github.com/MetaMask/delegation-framework/releases/tag/v1.3.0) মেটামাস্ক-নির্দিষ্ট সার্ভারের প্রয়োজন না করে যেকোনো চেইনে যেকোনো ERC-4337 বান্ডলার বা পেমাস্টারের সাথে স্পষ্টভাবে কাজ করে।

**ওয়ালেট ইন্টারফেসের মাধ্যমে বিকেন্দ্রীকৃত অ্যাপ্লিকেশন (dapp) ইন্টিগ্রেশন**:

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

- **ERC-5792 (`wallet_sendCalls`)**: dapp-গুলোকে ওয়ালেটগুলোকে ব্যাচ করা কলগুলো কার্যকর করার অনুরোধ করতে সক্ষম করে, যা ট্রানজ্যাকশন ব্যাচিং এবং গ্যাস বিমূর্তকরণের মতো কার্যকারিতাগুলোকে সহজতর করে।

- **ERC-6900**: dapp-গুলোকে ওয়ালেট-পরিচালিত মডিউলগুলোর মাধ্যমে সেশন কী এবং অ্যাকাউন্ট পুনরুদ্ধারের মতো মডুলার স্মার্ট অ্যাকাউন্ট ক্ষমতাগুলো ব্যবহার করার অনুমতি দেয়।

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

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

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

- [ERC-5792 স্পেসিফিকেশন](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5792.md)
- [ERC-6900 স্পেসিফিকেশন](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6900.md)

**ভেন্ডর লক-ইন এড়ানো**: ওপরের কথার সাথে সামঞ্জস্য রেখে, একটি ভালো বাস্তবায়ন হলো ভেন্ডর-নিরপেক্ষ এবং আন্তঃক্রিয়াশীল। এর অর্থ প্রায়শই স্মার্ট অ্যাকাউন্টগুলোর জন্য উদীয়মান মানগুলো মেনে চলা। উদাহরণস্বরূপ, [Alchemy-এর মডুলার অ্যাকাউন্ট](https://github.com/alchemyplatform/modular-account) মডুলার স্মার্ট অ্যাকাউন্টগুলোর জন্য ERC-6900 মান ব্যবহার করে এবং এটি "পারমিশনলেস আন্তঃক্রিয়াশীল ব্যবহার"-এর কথা মাথায় রেখে ডিজাইন করা হয়েছে।

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

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

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

- **আপগ্রেডযোগ্যতা**: প্রক্সিটিকে একটি নতুন বাস্তবায়ন কন্ট্রাক্টে নির্দেশ করে কন্ট্রাক্ট লজিক আপডেট করুন।

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

উদাহরণস্বরূপ, [SafeEIP7702Proxy](https://docs.safe.global/advanced/eip-7702/7702-safe) প্রদর্শন করে যে কীভাবে EIP-7702-সামঞ্জস্যপূর্ণ অ্যাকাউন্টগুলোতে নিরাপদে ইনিশিয়ালাইজ করতে এবং অর্পণগুলো পরিচালনা করতে একটি প্রক্সি ব্যবহার করা যেতে পারে।

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

- **বাহ্যিক অভিনেতাদের ওপর নির্ভরতা**: একটি অনিরাপদ কন্ট্রাক্টে আপগ্রেড না করার জন্য আপনাকে একটি বাহ্যিক দলের ওপর নির্ভর করতে হবে।
## নিরাপত্তা বিবেচনা {#security-considerations}

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

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

ভবিষ্যতে, ডেভেলপারদের এই ধারণা নিয়ে ডিজাইন করা উচিত যে সিস্টেমের যেকোনো অংশগ্রহণকারী একটি স্মার্ট কন্ট্রাক্ট হতে পারে। বিকল্পভাবে তারা একটি `nonReentrant` মডিফায়ার প্যাটার্ন সহ রিএন্ট্রান্সি গার্ড ব্যবহার করে স্পষ্ট রিএন্ট্রান্সি সুরক্ষা বাস্তবায়ন করতে পারে। আমরা একটি অডিটেড মডিফায়ার অনুসরণ করার পরামর্শ দিই, যেমন [Open Zeppelin-এর রিএন্ট্রান্সি গার্ড](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/ReentrancyGuard.sol)। তারা একটি [ট্রানজিয়েন্ট স্টোরেজ ভেরিয়েবল](https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html)-ও ব্যবহার করতে পারে।

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

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

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

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

- `initWithSig` বাস্তবায়ন করুন  
  স্ট্যান্ডার্ড `init` ফাংশনটিকে একটি `initWithSig` ফাংশন দিয়ে প্রতিস্থাপন করুন যার জন্য ব্যবহারকারীকে ইনিশিয়ালাইজেশন প্যারামিটারগুলোতে স্বাক্ষর করতে হবে। এই পদ্ধতিটি নিশ্চিত করে যে ইনিশিয়ালাইজেশন শুধুমাত্র ব্যবহারকারীর স্পষ্ট সম্মতির সাথেই এগিয়ে যেতে পারে, যার ফলে অননুমোদিত ইনিশিয়ালাইজেশন ঝুঁকিগুলো প্রশমিত হয়।

- ERC-4337-এর EntryPoint ব্যবহার করুন  
  ইনিশিয়ালাইজেশন ফাংশনটিকে একচেটিয়াভাবে ERC-4337 EntryPoint কন্ট্রাক্ট থেকে কল করার প্রয়োজন করুন। এই পদ্ধতিটি ERC-4337 দ্বারা প্রদত্ত প্রমিত বৈধতা এবং এক্সিকিউশন ফ্রেমওয়ার্ক ব্যবহার করে, যা ইনিশিয়ালাইজেশন প্রক্রিয়ায় নিরাপত্তার একটি অতিরিক্ত স্তর যোগ করে।  
  _(দেখুন: [Safe ডক্স](https://docs.safe.global/advanced/eip-7702/7702-safe))_

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

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

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

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

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

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

| কন্ট্রাক্ট ঠিকানা | সোর্স | অডিট |
| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 0x000000009B1D0aF20D8C6d0A44e162d11F9b8f00 | [Uniswap/calibur](https://github.com/Uniswap/calibur)                                                                                      | [audits](https://github.com/Uniswap/calibur/tree/main/audits)                                                                                                 |
| 0x69007702764179f14F51cdce752f4f775d74E139 | [alchemyplatform/modular-account](https://github.com/alchemyplatform/modular-account)                                                      | [audits](https://github.com/alchemyplatform/modular-account/tree/develop/audits)                                                                              |
| 0x5A7FC11397E9a8AD41BF10bf13F22B0a63f96f6d | [AmbireTech/ambire-common](https://github.com/AmbireTech/ambire-common/blob/feature/eip-7702/contracts/AmbireAccount7702.sol)              | [audits](https://github.com/AmbireTech/ambire-common/tree/feature/eip-7702/audits)                                                                            |
| 0x63c0c19a282a1b52b07dd5a65b58948a07dae32b | [MetaMask/delegation-framework](https://github.com/MetaMask/delegation-framework)                                                          | [audits](https://github.com/MetaMask/delegation-framework/tree/main/audits)                                                                                   |
| 0x4Cd241E8d1510e30b2076397afc7508Ae59C66c9 | [Ethereum Foundation AA team](https://github.com/eth-infinitism/account-abstraction/blob/develop/contracts/accounts/Simple7702Account.sol) | [audits](https://github.com/eth-infinitism/account-abstraction/blob/develop/audits/SpearBit%20Account%20Abstraction%20Security%20Review%20-%20Mar%202025.pdf) |
| 0x17c11FDdADac2b341F2455aFe988fec4c3ba26e3 | [Luganodes/Pectra-Batch-Contract](https://github.com/Luganodes/Pectra-Batch-Contract)                                                      | [audits](https://certificate.quantstamp.com/full/luganodes-pectra-batch-contract/23f0765f-969a-4798-9edd-188d276c4a2b/index.html)                             |
## হার্ডওয়্যার ওয়ালেট নির্দেশিকা {#hardware-wallet-guidelines}

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

### কম্প্যানিয়ন অ্যাপগুলোর জন্য ইন্টিগ্রেশন পরিস্থিতি {#integration-scenarios-for-companion-apps}

#### লেজি (Lazy) {#lazy}

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

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

#### সচেতন (Aware) {#aware}

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

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

ভিন্ন কোনোটিতে অর্পিত EOA-গুলোকে স্ট্যান্ডার্ড EOA হিসেবে পরিচালনা করা হবে।
#### কাস্টম অর্পণ
হার্ডওয়্যার প্রদানকারী নিজস্ব অর্পণ কন্ট্রাক্ট বাস্তবায়ন করে এবং এটিকে তালিকায় যুক্ত করে সফ্টওয়্যার কম্প্যানিয়নে এর সমর্থন বাস্তবায়ন করে। সম্পূর্ণ ERC-4337 সমর্থনসহ একটি কন্ট্রাক্ট তৈরি করার পরামর্শ দেওয়া হয়。

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