পেকট্রা 7702

সারাংশ

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

এই নতুন ট্রানজ্যাকশন টাইপটি একটি অনুমোদন তালিকা (authorization list) প্রবর্তন করে। তালিকার প্রতিটি অনুমোদন টুপল (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])) হিসেবে সংজ্ঞায়িত করা হয়, যার উপর অনুমোদনটি প্রযোজ্য (যাকে কর্তৃপক্ষ বা authority-ও বলা হয়)

নাল (null) ঠিকানায় অর্পণ করার মাধ্যমে একটি অর্পণ রিসেট করা যেতে পারে।

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

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

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

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

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

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

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

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

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

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

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

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

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

• ERC-5792 স্পেসিফিকেশন (opens in a new tab)
• ERC-6900 স্পেসিফিকেশন (opens in a new tab)

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

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

সম্প্রসারণযোগ্যতা এবং মডুলার নিরাপত্তা: অ্যাকাউন্ট বাস্তবায়নগুলো সম্প্রসারণযোগ্য হওয়া উচিত যাতে সেগুলো নতুন বৈশিষ্ট্য এবং নিরাপত্তা উন্নতির সাথে বিকশিত হতে পারে। EIP-7702-এর সাথে আপগ্রেডযোগ্যতা স্বভাবতই সম্ভব (যেহেতু একটি EOA তার লজিক আপগ্রেড করার জন্য ভবিষ্যতে সর্বদা একটি নতুন কন্ট্রাক্টে অর্পণ করতে পারে)। আপগ্রেডযোগ্যতার বাইরে, একটি ভালো ডিজাইন মডুলারিটির অনুমতি দেয় – যেমন, বিভিন্ন স্বাক্ষর স্কিম বা ব্যয়ের নীতিগুলোর জন্য প্লাগ-ইন মডিউল – সম্পূর্ণভাবে পুনরায় ডিপ্লয় করার প্রয়োজন ছাড়াই। Alchemy-এর অ্যাকাউন্ট কিট এর একটি প্রধান উদাহরণ, যা ডেভেলপারদের বৈধতা মডিউল (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-এর রিএন্ট্রান্সি গার্ড (opens in a new tab)। তারা একটি ট্রানজিয়েন্ট স্টোরেজ ভেরিয়েবল (opens in a new tab)-ও ব্যবহার করতে পারে।

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

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

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

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

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

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

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

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

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

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

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

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

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

হার্ডওয়্যার ওয়ালেট নির্দেশিকা

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

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

লেজি (Lazy)

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

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

সচেতন (Aware)

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

সাধারণ অর্পণ

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

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

কাস্টম অর্পণ

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

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

পেজ সর্বশেষ আপডেট করা হয়েছে: 3 এপ্রিল, 2026

p (opens in a new tab)

c (opens in a new tab)

j (opens in a new tab)

+6

অবদানকারীদের দেখুন