ইথেরিয়ামের হেগোটা আপগ্রেডে নেটিভ অ্যাকাউন্ট অ্যাবস্ট্রাকশন কেন একটি হেডলাইন ফিচার নয়

লেখাঃ imToken

গত সপ্তাহে, এথারিয়াম কোর ডেভেলপার মিটিংয়ে EIP-8141 কে হেগোটা আপগ্রেডে অন্তর্ভুক্ত করা হবে কিনা তা আনুষ্ঠানিকভাবে আলোচনা করা হয়, এবং এটি অপ্রত্যাশিতভাবে, ভাইটালিক দ্বারা সমর্থিত এই প্রস্তাবটিকে হেগোটার "হেডলাইন ফিচার" হিসাবে চিহ্নিত করা হয়নি, বরং এটি "বিবেচনার জন্য" (CFI) স্ট্যাটাস পায়।

এবারের সপ্তাহে, গুগল কোয়ান্টাম এআই দল একটি নতুন সাদা কাগজ প্রকাশ করেছে, যাতে বলা হয়েছে যে তাদের প্রদত্ত হার্ডওয়্যার ধারণার ভিত্তিতে, ECDLP-256 ভাঙার জন্য প্রয়োজনীয় ভৌত কিউবিটের আনুমানিক সংখ্যা আগের তুলনায় 20 গুণ কমেছে। যদিও এটি কোয়ান্টাম আক্রমণকে অত্যন্ত নিকটবর্তী বলে নির্দেশ করে না, তবুও এটি আমাদের সতর্ক করেছে যে, যদি ভবিষ্যতে আমাদের অ্যাকাউন্ট সিস্টেমটি যাচাইকরণের যুক্তি পরিবর্তনের জন্য নমনীয় না হয়, তবে আজকের অনেক ওয়ালেট অভিজ্ঞতা নিয়ে আলোচনা শেষপর্যন্ত নিরাপত্তা সমস্যায় পরিণত হতে পারে।

প্রোটোকল এগিয়ে নেওয়ার বাস্তবিক দিক থেকে দেখলে, EIP-8141 এখনও খুব ভারী, বিশেষ করে ক্লায়েন্ট ব вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн বাস্তবায়ন, ট্রানজেকশন পুল নিরাপত্তা এবং যাচাইয়ের জটিলতার ক্ষেত্রে যথেষ্ট শক্তিশালী সমঝোতা গড়ে উঠেনি।

কিন্তু বর্তমান সময়ের প্রেক্ষাপটে, EIP-8141 এর জন্য আলোচনা এবং গুরুত্বপূর্ণভাবে পর্যালোচনা করার বিষয়গুলি আসলে বাড়তে থাকছে।

EIP-8141 কে ভাইটালিক বুটেরিন এবং টিমবেইকো সহ মূল অবদানকারীদের দ্বারা এগিয়ে নেওয়া হয়েছে, যার আনুষ্ঠানিক নাম ফ্রেম ট্রানজেকশন।

এটি শুধু একটি ওয়ালেট ফিচার যোগ করার চেষ্টা করছে না, বরং প্রোটোকল লেভেলে যেকোনো অ্যাকাউন্টকে একক ECDSA সিগনেচার পাথের সীমাবদ্ধতা থেকে মুক্ত করে আরও নমনীয় ভেরিফিকেশন এবং এক্সিকিউশন লজিক দিতে চায়।

এর অর্থ এই যে, মাল্টি-সিগনেচার, গ্যাস স্পনসরশিপ, কী রোটেশন, সোশ্যাল রিকভারি, এমনকি ভবিষ্যতে কোয়ান্টাম-প্রতিরোধী সিগনেচার সমাধানের সাথে যোগাযোগও আর ওয়ালেটের বাইরের একটি অতিরিক্ত ক্ষমতা নয়, বরং এথেরিয়াম অ্যাকাউন্ট সিস্টেমের একটি 'মূল সদস্য' হওয়ার সুযোগ পাবে।

পৃষ্ঠার দিক থেকে দেখলে, EIP-8141 এর আলোচনা হচ্ছে কিছু অত্যন্ত নির্দিষ্ট ক্ষমতার উপর: স্থিতিশীল মুদ্রা দিয়ে গ্যাস পরিশোধ করা, একাধিক ধাপের অপারেশনকে একটি ট্রানজেকশনে একত্রিত করা, আরও নমনীয় স্বাক্ষর পদ্ধতির সমর্থন, এমনকি ভবিষ্যতের কোয়ান্টাম-প্রতিরোধী স্বাক্ষরের জন্য জায়গা সংরক্ষণ। বলা যায়, ERC-4337 থেকে EIP-7702 পর্যন্ত, ওয়ালেট অভিজ্ঞতার উন্নতির অধিকাংশই মূলত এই লক্ষ্যেই নিয়োজিত—যেন একটি অ্যাকাউন্ট শুধুমাত্র একটি ব্যক্তিগত চাবি নয়, বরং একটি কাস্টমাইজযোগ্য নিয়মের প্রবেশদ্বার।

সমস্যা হলো, এই উন্নতিগুলি পরিষেবাগুলিকে স্মার্ট অ্যাকাউন্টের মতো করে তুলেছে, কিন্তু এথারিয়ামের সবচেয়ে মৌলিক ডিফল্ট অ্যাকাউন্ট মডেলটিকে বাস্তবিকই স্পর্শ করেনি।

পরিচিতভাবে, বর্তমান ব্যবস্থার অধীনে, এথেরিয়াম অ্যাকাউন্ট মূলত দুই ধরনের। একটি হল বাহ্যিক স্বামিত্ব অ্যাকাউন্ট, যা সবচেয়ে পরিচিত EOA, যা প্রাইভেট কী দ্বারা নিয়ন্ত্রিত হয় এবং সক্রিয়ভাবে লেনদেন শুরু করতে পারে, কিন্তু প্রোগ্রামযোগ্যতা অভাব রয়েছে; অন্যটি হল কনট্রাক্ট অ্যাকাউন্ট, অর্থাৎ স্মার্ট কনট্রাক্ট, যা জটিল লজিক সম্পাদন করতে পারে, কিন্তু নিজেই সক্রিয়ভাবে লেনদেন শুরু করতে পারে না।

এর ফলে ট্রানজেকশন শুরু করার ক্ষমতা একটি একক প্রাইভেট কী দ্বারা স্বাক্ষর করার সাথে দীর্ঘদিন বেঁধে থাকে। এই পূর্বশর্তটি অপরিবর্তিত থাকা পর্যন্ত, বহু ব্যবহারকারী আজ যা নিজেদের জন্য স্বাভাবিক মনে করেন—যেমন স্বাক্ষর নিয়ম পরিবর্তন করা, অন্যকে গ্যাস পরিশোধ করতে দেওয়া, প্রাইভেট কী হারানোর পরে অ্যাকাউন্টের নিয়ন্ত্রণ পুনরুদ্ধার করা, বা ভবিষ্যতে নতুন ক্রিপ্টোগ্রাফিক সিস্টেমে সহজে স্থানান্তরিত হওয়া—সবকিছুই অ্যাকাউন্টের ডিফল্ট ক্ষমতা হয়ে ওঠা কঠিন হয়ে পড়ে।

আপনি যদি imToken বা অন্য কোনও Web3 ওয়ালেট ব্যবহার করে থাকেন, তাহলে আপনি সম্ভবত এই সমস্যাগুলির সম্মুখীন হয়েছেন, যেমন: আপনার ওয়ালেটে অনেক USDC আছে, কিন্তু ETH না থাকায় ট্রানজেকশন পাঠাতে পারছেন না (কারণ Gas শুধুমাত্র ETH দিয়ে পরিশোধ করা যায়); মনেমন্ত্র হারিয়ে ফেললে আপনার টাকা চিরতরে হারিয়ে যায়, পুনরুদ্ধার করা সম্ভব নয়; একটি “অনুমোদন + বিনিময়” অপারেশনের জন্য দুইবার স্বাক্ষর এবং দুইবার নিশ্চিতকরণের প্রয়োজন হয় ইত্যাদি।

এই সমস্যাগুলি ওয়ালেট পণ্যের "অপর্যাপ্ততা" নয়, বরং ইথারিয়াম অ্যাকাউন্ট মডেলের নিজস্ব ডিজাইনের ফলাফল।

এই দৃষ্টিকোণ থেকে, গত দুই বছরের বিকাশ প্রকৃতপক্ষে খুব স্পষ্ট, ERC-4337 প্রোটোকল পরিবর্তন না করেই অ্যাকাউন্ট অ্যাবস্ট্রাকশনকে অ্যাপ্লিকেশন লেয়ারে চালু করেছে; EIP-7702 আরও প্রমাণ করেছে যে EOA সম্পূর্ণরূপে বিস্তারযোগ্য নয়, অন্তত অস্থায়ীভাবে স্মার্ট অ্যাকাউন্টের কিছু ক্ষমতা অর্জন করা যায়।

অর্থাৎ, ইথেরিয়াম একটি অ্যাকাউন্ট অ্যাবস্ট্রাকশন করতে চায়নি না, বরং এটি সবসময় আরও মৃদু এবং সাবধানে পদক্ষেপ নিয়ে এই বিষয়ের দিকে এগিয়ে যাচ্ছিল। EIP-8141-এর উত্থান এই পথের একটি নতুন পর্যায়ের সূচনা করে। এটি শুধুমাত্র বর্তমান ব্যবস্থার বাইরে একটি স্মার্ট অ্যাকাউন্ট ক্ষমতা যোগ করার সীমায় সন্তুষ্ট হয়নি, বরং এটি অ্যাকাউন্ট অ্যাবস্ট্রাকশনকে সরাসরি ট্রানজেকশন মডেলের মধ্যে এমবেড করার চেষ্টা করছে, যাতে অ্যাকাউন্টগুলি প্রোটোকল-স্তরেই প্রোগ্রামযোগ্য যাচাইকরণ এবং বাস্তবায়নের যুক্তি ধারণ করতে পারে।

এই কারণেই আজ EIP-8141 আবার গুরুত্বপূর্ণ হয়ে উঠেছে। একদিকে, উপরের স্তরের ওয়ালেট অভিজ্ঞতা ধীরে ধীরে ন্যাটিভ অ্যাকাউন্ট অ্যাবস্ট্রাকশনের কাছাকাছি চলে আসছে, প্রোটোকল স্তরকে অবশ্যই এগিয়ে যেতে হবে; অন্যদিকে, কোয়ান্টাম কম্পিউটিংয়ের দীর্ঘমেয়াদী চাপও "অ্যাকাউন্ট কি সহজেই স্বাক্ষর পদ্ধতি পরিবর্তন করতে পারবে" এই দূরবর্তী প্রযুক্তিগত প্রশ্নটিকে একটি অবশ্যই বিবেচনা করা প্রয়োজনীয় বাস্তব সমস্যায় পরিণত করছে।

শেষ পর্যন্ত, EIP-8141 একটি সম্পূর্ণ নতুন ট্রানজেকশন টাইপ—ফ্রেম ট্রানজেকশন (Frame Transaction)—কে চালু করেছে, যার ট্রানজেকশন টাইপ নম্বর 0x06।

যদি প্রাচীন ইথেরিয়াম লেনদেনের মূল যুক্তি হয় যে একটি লেনদেন একটি কলের সাথে মিলে যায়, তাহলে EIP-8141 এর উদ্দেশ্য হল একটি লেনদেনকে নিয়মিত ক্রমে বাস্তবায়নযোগ্য একটি সেটের মধ্যে "ফ্রেম" এ বিভক্ত করা, যাতে যাচাই, পরিশোধ এবং বাস্তবায়ন—এই তিনটি কাজকে আলাদাভাবে পরিচালনা করা যায়।

প্রতিটি «ফ্রেম»-এ তিনটি এক্সিকিউশন মোড রয়েছে:

• VERIFY (যাচাইকরণ ফ্রেম): এটি ট্রানজেকশনটি বৈধ কিনা তা যাচাই করে, এটি অ্যাকাউন্টের কাস্টম যাচাইকরণ লজিক চালায়, যদি এটি সফল হয়, তবে এটি গ্যাস সীমা নির্দিষ্ট করে নতুনভাবে পরিচিত APPROVE অপারেকোডটি কল করে।
• SENDER (ফ্রেম প্রেরণকারী): ট্রান্সফার, স্মার্ট কন্ট্রাক্ট কল ইত্যাদি বাস্তব অপারেশনগুলি সম্পাদন করে। কলকারীর ঠিকানা হল ট্রানজেকশনের প্রেরক।
• DEFAULT (ইনপুট ফ্রেম): সিস্টেম ইনপুট ঠিকানাকে কলার হিসাবে ব্যবহার করা হয়, স্মার্ট কনট্রাক্ট ডিপ্লয়, পেমাস্টার যাচাইকরণ ইত্যাদি পরিস্থিতিতে;

এই মেকানিজমের অর্থ হল ট্রেডিংকে আরও জটিল করা নয়, বরং প্রথমবারের মতো 'ভেরিফিকেশন, পেমেন্ট, এক্সিকিউশন'—এই তিনটি কাজকে অ্যাকাউন্ট অ্যাকশন থেকে আলাদা করে প্রোটোকলের নিজস্ব স্কিডিউলারের হাতে সুপুর্দ করা।

অতীতে, ট্রানজেকশন যাচাই করা, গ্যাস পরিশোধ করা এবং বাস্তব অপারেশন সম্পাদন করা—এই সবকিছু প্রায়শই একই অ্যাকাউন্টের একক অ্যাকশনের সাথে বাঁধা ছিল। কিন্তু EIP-8141-এর ডিজাইনের অধীনে, এই তিনটি কাজকে আলাদা ফ্রেমে ভাগ করা যায়, যা প্রোটোকল দ্বারা স্পষ্ট ক্রমে ক্রমানুসারে সম্পাদিত হয়। এই কারণেই, অ্যাকাউন্টগুলি এখন শুধুমাত্র একটি একক প্রাইভেট কীর উপর নির্ভরশীল নয়, যা "সমগ্র স্বাক্ষর" করে, বরং এগুলি আরও প্রোগ্রামযোগ্য এক্সিকিউশন এজেন্টের মতো আকৃতি ধারণ করতে শুরু করেছে।

একটি নির্দিষ্ট উদাহরণ হিসাবে, ধরুন আপনি একটি সুইপ সম্পন্ন করতে USDC দিয়ে গ্যাস পরিশোধ করতে চান, EIP-8141-এর কাঠামোর অধীনে, এটি তত্ত্বগতভাবে একটি সম্পূর্ণ ফ্রেম প্রক্রিয়া হিসাবে সংগঠিত করা যেতে পারে: প্রথমে অ্যাকাউন্টটি স্বাক্ষর এবং কার্যকরী অনুমতি যাচাই করে, তারপর পেমেন্ট প্রদানকারী বা পেমেস্টার নিজেদের খরচ বহনের শর্তগুলি যাচাই করে, তারপর সংশ্লিষ্ট সম্পদের জন্য খরচ পরিশোধ করে, এবং শেষে প্রকৃত সুইপ অপারেশনটি সম্পন্ন করে।

এইভাবে, গ্যাস পেমেন্ট এবং মূল ট্রানজেকশন একই পরম প্রক্রিয়ায় অন্তর্ভুক্ত করা যায়, যা একসাথে সফল হবে বা সম্পূর্ণভাবে রোলব্যাক হবে।

ব্যবহারকারীদের জন্য সবচেয়ে স্পষ্ট পরিবর্তন হল যে আগে যেসব অপারেশন দুই বা তিনটি ধাপে বিভক্ত করে করতে হত এবং মধ্যবর্তীতে ব্যর্থ হওয়ার ঝুঁকি ছিল, ভবিষ্যতে এগুলো একটি সম্পূর্ণ ক্রিয়ার মতো হয়ে উঠবে, তাই এই পরমাণবিকতা হল EIP-8141-এর একটি মূল বিষয় যা ব্যবহারকারীর অভিজ্ঞতার বিচ্ছিন্নতা সমাধান করতে চায়।

এটি ওয়ালেট ব্যবহারকারীদের জন্য কী অর্থ বহন করে? ফলাফলের ভিত্তিতে, সবচেয়ে সরাসরি পরিবর্তনগুলি কমপক্ষে চারটি স্তরে বিদ্যমান:

• গ্যাস পেমেন্ট অ্যাবস্ট্র্যাক্ট করা হয়েছে: আপনার ওয়ালেটে স্টেবলকয়েন থাকা মানে এখন আপনাকে অতিরিক্ত কিছু ETH রাখার দরকার হবে না যাতে আপনি অপারেশন চালাতে পারেন; ভবিষ্যতে DApp, Paymaster বা অন্যান্য স্পনসরদের দ্বারা গ্যাস পরিশোধ করা আরও প্রাকৃতিকভাবে হবে;
• একাধিক ধাপের কাজ একত্রিত হয়েছে: যেমন «অনুমতি + স্ব্যাপ» বা «অনুমতি + স্টেকিং»-এর মতো যেসব প্রক্রিয়ায় এখন প্রায়শই একাধিক স্বাক্ষরের প্রয়োজন হয়, সেগুলিকে একটি আরও সম্পূর্ণ অপারেশনের মধ্যে প্যাক করার সুযোগ রয়েছে;
• অ্যাকাউন্ট নিরাপত্তা নিয়ম সক্রিয় হয়েছে: মাল্টি-সিগনেচার, সোশ্যাল রিকভারি, দৈনিক সীমা, টাইম লক এবং কী রোটেশন—এগুলি এখন শুধুমাত্র কোনও ওয়ালেট পণ্যের অতিরিক্ত উন্নত ফিচার হিসেবে নয়, বরং আরও মূল অ্যাকাউন্ট লজিকের উপর ভিত্তি করে গড়ে উঠছে;
• সাইনেট স্কিম এখন শুধুমাত্র ECDSA একক পথে বন্ধ করা হয়নি: এটি অ্যাকাউন্টকে ভবিষ্যতে বিভিন্ন ক্রিপ্টোগ্রাফিক সিস্টেমে, পোস্ট-কোয়ান্টাম সাইনেট স্কিমসহ, স্থানান্তরিত করার প্রথমবারের মতো প্রোটোকল-লেভেলের সম্ভাবনা প্রদান করে;

একটি খুব সহজেই উপেক্ষিত কিন্তু ওয়ালেট ব্যবহারকারীদের জন্য অত্যন্ত গুরুত্বপূর্ণ বিষয় হল: যদিও EIP-8141 চূড়ান্তভাবে বাস্তবায়িত হয়, বর্তমান অ্যাকাউন্ট সিস্টেম এর কারণে সম্পূর্ণরূপে বাতিল হবে না।

আপনি যদি এখন imToken এর মতো বিদ্যমান Web3 ওয়ালেট ব্যবহার করেন, তাহলে এটি মাইগ্রেট করার দরকার নেই, কারণ এটি ব্যাকওয়ার্ড কম্প্যাটিবল, এবং বিদ্যমান EOA ঠিকানা ব্যবহার করা যাবে, শুধুমাত্র উপযুক্ত সময়ে "আপগ্রেড" অ্যাকাউন্টের ভেরিফিকেশন লজিক নির্বাচন করুন।

কিন্তু বিপরীতভাবে দেখলে, এটি যথেষ্ট গভীরভাবে পরিবর্তন করা হয়েছে বলেই এটি সর্বশেষ আলোচনায় হেগোটা-এর প্রধান ফিচার হয়ে উঠেনি। তবে 2026 সালের EIP চ্যাম্পিয়ন প্রক্রিয়া অনুযায়ী, CFI (Considered for Inclusion) এর অর্থ হলো এটি অস্বীকৃত হয়নি, বরং এটি গুরুত্বপূর্ণভাবে বিবেচনার জন্য প্রবেশ করেছে, কিন্তু এখনও চূড়ান্তভাবে চালুর পর্যায়ে পৌঁছায়নি।

অর্থাৎ, কোর ডেভেলপাররা EIP-8141-এর দিকনির্দেশকে অস্বীকার করছেন না, বরং এর মূল্যকে স্বীকার করে এটিকে এখনও খুব ভারী বলে মনে করছেন।

কারণ নেটিভ অ্যাকাউন্ট অ্যাবস্ট্রাকশন এআরসি-৪৩৩৭-এর মতো কয়েকটি ওয়ালেট, ইনফ্রাস্ট্রাকচার এবং অ্যাপ্লিকেশন দ্বারা ধাপে ধাপে এগিয়ে নেওয়া যায় না, এটি যদি প্রোটোকল লেয়ারে প্রবেশ করে, তাহলে এর অর্থ হলো সমস্ত একিউজিউশন লেয়ার ক্লায়েন্টকে এটিকে বাস্তবায়ন, পরীক্ষা এবং সমন্বয় করতে হবে, যা স্বাভাবিকভাবেই এগিয়ে যাওয়ার বাধা বাড়ায় এবং কোর ডেভেলপারদের ফর্ক পরিকল্পনায় আরও সতর্কতা অবলম্বনের দিকে নিয়ে যায়।

এরপর কী ঘটবে? এটিকে দুটি লাইনে ভাগ করে দেখা যাক:

• EIP-8141 যেহেতু CFI স্ট্যাটাসে আছে, তাই এটি এখনও নিয়মিত মূল্যায়নের অধীনে; প্রস্তাবক ট্রানজেকশন পুল নিরাপত্তা, যাচাইকরণ নিয়ম এবং ক্লায়েন্ট ব вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн вн ব вн ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব ব व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व व ।
• যদি এই অনিশ্চয়তাগুলি ধারাবাহিকভাবে কমানো যায়, তবে এটি পরবর্তী আপগ্রেডে আরও বাস্তবসম্মত অন্তর্ভুক্তির পর্যায়ে যাওয়ার সুযোগ পাবে; যদি না যায়, তবে এটি সম্পূর্ণরূপে পরবর্তী আপগ্রেড চক্রে স্থানান্তরিত হতে পারে;

বাস্তববাদীভাবে বলা যায়, EIP-8141 একমাত্র নেটিভ অ্যাকাউন্ট অ্যাবস্ট্রাকশন প্রস্তাব নয়, এটি নিজেই কোনো প্রস্তুত পর-কোয়ান্টাম সিগনেচার স্কিমও নয়, যা কোয়ান্টাম কম্পিউটিং সমস্যার সরাসরি সমাধান করতে পারে না, কিন্তু এর গুরুত্ব হলো, এটি প্রথমবারের মতো অ্যাকাউন্টকে ECDSA-এর একক পথ থেকে মুক্তি দেওয়ার জন্য প্রোটোকল-লেভেলের একটি আউটলেট প্রদান করে।

এই দৃষ্টিকোণ থেকে, EIP-8141-এর প্রকৃত মূল্য এটি একমাত্র সঠিক উত্তর কিনা তার উপর নির্ভর করে না, বরং এটি প্রথমবারের মতো "ন্যাটিভ অ্যাকাউন্ট অ্যাবস্ট্রাকশনের চূড়ান্ত রূপটি কী হওয়া উচিত" এই প্রশ্নটিকে এথারিয়াম প্রোটোকলের আলোচনার টেবিলে খুব সম্পূর্ণভাবে রেখেছে।

এটি একমাত্র সমাধান নয়, তবে এটি বর্তমানে সবচেয়ে আকাঙ্ক্ষী এবং "পূর্ণাঙ্গ ন্যাটিভ AA"-এর কল্পনার সীমানা পর্যন্ত সবচেয়ে কাছাকাছি সমাধানগুলির মধ্যে একটি।

EIP-8141 চূড়ান্তভাবে Hegotá-এর সাথে পাল্লা দিতে পারবে কিনা তা নির্ভর করছে না, এই আলোচনাটি কমপক্ষে একটি বিষয় প্রমাণ করেছে:

এথেরিয়াম সমস্যাগুলির বিকাশকে অপেক্ষা করছে না, বরং পরবর্তী প্রজন্মের অ্যাকাউন্ট সিস্টেমের জন্য ধীরে ধীরে পথ প্রশস্ত করছে।