যখন কেউ Web2 এবং Web3 এর মধ্যে পার্থক্য করতে চায়, তখন একটি মূল মান যা দুটিকে আলাদা করে তা হল মালিকানার ধারণা।
সহজ কথায়, আপনি যা তৈরি করেন তা আপনার মালিকানাধীন এবং নগদীকরণ করতে পারেন। ঠিক যেমনটা হওয়া উচিত। কম কিছু না, বেশি কিছু না। প্রকৃতপক্ষে, যেদিন আপনি আপনার প্রথম এনএফটি মিন্ট করবেন সেটি হল যখন আপনি এটিকে ওয়েব3-এ একজন মালিক হিসাবে তৈরি করেছেন, ব্লকচেইনের অপরিবর্তনীয়তার জন্য ধন্যবাদ। যদি কিছু থাকে তবে সুরক্ষিত হওয়ার অনুভূতি অমূল্য।
যার কথা বলতে গেলে, মালিকানার এই ধারণাটি অ্যাক্সেসযোগ্য ফাংশন এবং অনুমোদিত রাষ্ট্র পরিবর্তনের ক্ষেত্রে স্মার্ট চুক্তির মতোই গুরুত্বপূর্ণ।
তাহলে, কেন এটা গুরুত্বপূর্ণ যে আপনি যে স্মার্ট চুক্তিটি লিখেছেন তার 'মালিকানা'?
এটি সম্পর্কে চিন্তা করুন: আপনি যদি একটি বাইকের মালিক হন তবে আপনি কি মালিকানা রেকর্ড রাখতে দ্বিধা করবেন? শুধু যদি কেউ চুরি করে খারাপ উদ্দেশ্যে ব্যবহার করে? অবশ্যই না.
এটি একই কারণে আপনি কেন একটি NFT বা একটি স্মার্ট চুক্তির মালিকানা প্রমাণ করতে চান৷ আচ্ছা, কেউ হয়তো অননুমোদিত অ্যাক্সেস লাভ করতে পারে এবং এর থেকে আর্থিকভাবে লাভবান হতে পারে, তাই না?
ধরা যাক আপনি Dunzo-এর সাথে কাজ করেছেন এবং এই স্মার্ট চুক্তিটি লিখেছেন যেখানে আপনি প্যাকেজ মূল্য এবং ডেলিভারি চার্জগুলি ক্রেতার দ্বারা পরিশোধ করা হয়েছে কিনা তা সহ সেট করতে পারেন৷
আদর্শ পরিস্থিতিতে, আপনি ক্রেতার নাম, প্যাকেজের মোট মূল্য এবং একটি নির্দিষ্ট পরিমাণে ডেলিভারি সেট করতে পারেন এবং সেটপ্যাকেজ ডেলিভারডকে সত্যে সেট করতে পারেন। একবার আপনি অবশ্যই প্যাকেজ বিতরণ সম্পন্ন করেন।
কিন্তু, আমরা সবাই জানি, কিছুই কখনো পরিকল্পনা করতে যায় না।
এখন, ক্রেতার যদি চুক্তির কার্যাবলীতে অ্যাক্সেস থাকে এবং প্যাকেজ ডেলিভারড মানটিকে মিথ্যাতে রিসেট করার ক্ষমতা বা প্যাকেজ ডেলিভারিপ্রাইস মানটিকে কম করে পরিবর্তন করার ক্ষমতা থাকে তাহলে কী হবে? তারা কেবল পণ্যের জন্য কম অর্থ প্রদান করতে পারে না তবে কিছুতেই অর্থ প্রদান না করে পার পেয়ে যায়।
স্পষ্টতই, Dunzo ব্যতীত, অন্য কারোর এই ধরনের পরিবর্তন করার অ্যাক্সেস থাকা উচিত নয়, এবং সেজন্য অ্যাক্সেস নিয়ন্ত্রণের বিষয়গুলি সেট করা।
এখন, আসুন এই স্মার্ট চুক্তিটি স্থাপন করা যাক এবং দেখুন যে একজন অনুপ্রবেশকারীর পক্ষে রাষ্ট্রীয় ভেরিয়েবলের মানগুলি পরিবর্তন করা কতটা সহজ।
সেটপ্রাইস এবং সেটপ্যাকেজডেলিভারড ফাংশন উভয়ই অ্যাক্সেসযোগ্য, যে কেউ পরিবর্তন করতে পারে যার ফলে Dunzo ডেলিভারির জন্য আর্থিক ক্ষতি হতে পারে।
যদি Dunzo আইটেমের আসল মূল্য 5 ETH-এ সেট করে থাকে, তাহলে গ্রাহক এখন সেই মানটিকে 3 ETH-এ পরিবর্তন করতে পারবেন। অবশ্যই, যেহেতু গ্রাহক সেটপ্যাকেজডিলিভারড ফাংশনটি অ্যাক্সেস করতে পারে এবং বুলিয়ান মানটিকে মিথ্যাতে পরিবর্তন করতে পারে, সে একই আইটেমের আরেকটি ডেলিভারি পেতে পারে। সুতরাং, উভয় ক্ষেত্রেই, ডানজো অর্থ হারাতে দাঁড়িয়েছে, এবং খুব দেরি না হওয়া পর্যন্ত এটি বুঝতেও পারে না।
উদাহরণস্বরূপ, ধরা যাক যে পণ্যটি বিতরণ করা হচ্ছে তার মূল্য 5 ETH, নীচে দেখানো হয়েছে:
স্থাপনার পরে, Dunzo ছাড়া অন্য কেউ চুক্তির শর্তাবলী সংশোধন করতে সক্ষম হবেন না। তারপরও, যখন আমরা রিমিক্সে ঠিকানা পরিবর্তন করি এবং মূল্য 3-এ রিসেট করি, তখন কোনো সুরক্ষা না থাকার কারণে এটি সম্ভব হয়।
এমনকি আমরা সেটপ্যাকেজ ডেলিভারড স্ট্যাটাস সত্য থেকে মিথ্যাতে পরিবর্তন করতে পারি। এমনকি যদি প্যাকেজটি ইতিমধ্যে গ্রাহকের কাছে পৌঁছে দেওয়া হয়।
আপনি যেমন বলতে পারেন, কথিত স্মার্ট চুক্তির জন্য মালিক এবং অন্যান্য ব্যবহারকারীদের মধ্যে পার্থক্য করা গুরুত্বপূর্ণ। সুতরাং, আসুন 4টি সংশোধন দেখি যা এই স্মার্ট চুক্তির জন্য সঠিক অ্যাক্সেস নিয়ন্ত্রণ সেট করবে এবং এর ফলে এর নিরাপত্তা নিশ্চিত করবে।
সুতরাং, স্মার্ট চুক্তি লেখার সময় কীভাবে একজন মালিক এবং অন্যান্য ব্যবহারকারীদের মধ্যে পার্থক্য করতে পারে?
স্পষ্টতই, আর্থিক ক্ষতির কারণে এটি প্রয়োজনীয় যা উপেক্ষা করা হলে খরচ হতে পারে।
পদ্ধতি #1: একটি প্রয়োজনীয় বিবৃতি ব্যবহার করুন
আপনি নীচের কোডে দেখতে পাচ্ছেন, একটি 'প্রয়োজনীয়' বিবৃতির সাথে ঠিকানার প্রকারের একটি নতুন রাষ্ট্র পরিবর্তনশীল মালিক যোগ করা হয়েছে। কনস্ট্রাক্টরে, মালিক স্টেট ভেরিয়েবল সেই ঠিকানা সংরক্ষণ করে যা চুক্তি স্থাপন করার সময় ব্যবহৃত হয়। আপনি জানেন যে স্মার্ট চুক্তিতে কনস্ট্রাক্টরদের শুধুমাত্র একবার আহ্বান করা হয়, তাই ঠিকানা পরিবর্তন করা যাবে না।
এখন, যখন আপনি একটি কম মান এবং একটি ভিন্ন ঠিকানা সহ setPrice ফাংশনটি চালু করেন, তখন লেনদেনটি প্রাথমিক অবস্থায় ফিরে আসে, অনেকটা নীচের বার্তাটির মতো:
আপনি দেখতে পাচ্ছেন, চুক্তির দ্বারা প্রদত্ত কারণটির মধ্যে ত্রুটির বার্তা জড়িত যা আমরা 'প্রয়োজন' বিবৃতিতে যোগ করেছি। এটি বলেছে, চুক্তির মালিক ছাড়া আর কেউ - ডানজো, এই ক্ষেত্রে - বিক্রয় শর্তাবলী পরিবর্তন করতে পারবেন না।
পদ্ধতি #2: একটি ফাংশন মডিফায়ার ব্যবহার করুন
সঠিক শর্তের সাথে একটি 'প্রয়োজন' বিবৃতি যোগ করা যতটা সহজ, একটি মডিফায়ার হল কোডের একটি ব্লক যা আপনি বারবার ব্যবহার করতে পারেন। এই ধরনের চেকের জন্য অসংখ্য 'প্রয়োজনীয়' বিবৃতি লেখার চেয়ে এটি অবশ্যই অনেক বেশি অর্থবোধক করে তোলে।
আগে ভাগ করা কোডে, শুধুমাত্র setPrice ফাংশন একটি 'require' স্টেটমেন্ট দ্বারা সুরক্ষিত কিন্তু এখানে setPackageDelivered ফাংশনের জন্য কিছুই করা হয়নি। একটি সংশোধক ব্যবহার করে কৌশলটি করা উচিত, যেমনটি নীচের সলিডিটি কোডে দেখানো হয়েছে:
এখন, আপনি যদি setPrice বা setPackageDelivered ফাংশনগুলি অ্যাক্সেস করার চেষ্টা করেন, আপনি আগে প্রাপ্ত একই ত্রুটি বার্তা পাবেন, এবং নীচে দেখানো হয়েছে:
পদ্ধতি #3: মালিকানাধীন
এই সমাধানের জন্য আপনাকে OpenZeppelin দ্বারা প্রদত্ত মালিকানাধীন স্মার্ট চুক্তি ব্যবহার করতে হবে। প্রথমে, আপনাকে মালিকানাযোগ্য স্মার্ট চুক্তি আমদানি করতে হবে এবং তারপরে আপনি যে ফাংশনগুলি রক্ষা করতে চান তাতে একমাত্র মালিক সংশোধক যোগ করতে হবে। সুতরাং, নীচে দেখানো হিসাবে, setPrice এবং setPackageDelivered উভয় ফাংশনেরই নিচের একমাত্র মালিক সংশোধক রয়েছে।
এখন, যেহেতু dunzoDelivery স্মার্ট কন্ট্রাক্ট Ownable.sol-এর কিছু ফাংশন ব্যবহার করবে, তাই চুক্তির নামের সাথেও “Ownable” যোগ করা হয়েছে।
এটি বলেছে, মালিকানাযোগ্য স্মার্ট চুক্তি ব্যবহার করার সময় অন্য দুটি ফাংশন অ্যাক্সেস করতে পারে: মালিকানা ছেড়ে দেওয়া এবং মালিকানা স্থানান্তর। চুক্তিটি স্থাপন করার জন্য যে অ্যাকাউন্টটি ব্যবহার করা হয়েছিল সেটিকে সাধারণত মালিক হিসাবে বিবেচনা করা হয়, এই ফাংশনগুলি ব্যবহার করে এটি পরিবর্তন করা যেতে পারে।
মালিকের ঠিকানা এবং অন্যান্য চুক্তির বিশদ বিবরণ দেখার পাশাপাশি, আপনি নীচে ব্যবহারের জন্য মালিকানা ত্যাগ এবং মালিকানা স্থানান্তর ফাংশনগুলি দেখতে পারেন:
প্রত্যাশিত হিসাবে, আপনি যখন অন্য ঠিকানা ব্যবহার করে setPrice ফাংশন চালু করার চেষ্টা করবেন, তখন লেনদেন হবে না। পরিবর্তে, এটি মূল অবস্থায় ফিরে আসে, নীচে দেওয়া কারণ সহ:
আপনার যদি অন্য ব্যবহারকারীদের মধ্যে শুধুমাত্র একজন মালিকের প্রয়োজন হয় তবে মালিকানাধীন স্মার্ট চুক্তি ব্যবহার করা ভাল। আপনি যদি আরও শ্রেণীবিন্যাস খুঁজছেন, তাহলে AccessControl.sol স্মার্ট চুক্তি ব্যবহার করা উচিত।
পদ্ধতি #4: অ্যাক্সেস কন্ট্রোল
এই শেষ সমাধানের জন্য আপনাকে ওপেন জেপেলিনের অ্যাক্সেস কন্ট্রোল স্মার্ট কন্ট্রাক্ট অ্যাক্সেস করতে হবে।
শুরুর জন্য, আপনাকে আমদানি বিবৃতিতে অ্যাক্সেস কন্ট্রোল হাইপারলিঙ্ক যোগ করতে হবে এবং সেইসাথে চুক্তি বিবৃতিতে "ইজ অ্যাক্সেস কন্ট্রোল" যোগ করতে হবে।
যেমন আগে উল্লিখিত হয়েছে, এই স্মার্ট চুক্তিটি আপনাকে একটি শ্রেণিবিন্যাসের মধ্যে বেশ কয়েকটি ভূমিকা যুক্ত করতে দেয় এবং যা আপনাকে অবশ্যই ঘোষণা করতে হবে, যেমন নীচে দেখানো স্মার্ট চুক্তির প্রথম দুটি লাইনে:
এই চুক্তিতে, ডানজো এবং গ্রাহক নামে দুটি ভূমিকা রয়েছে। এখন, আপনি যখন চুক্তি স্থাপন করবেন, তখন আপনাকে উল্লিখিত ঠিকানাগুলিতে পূর্বোক্ত ঘোষিত ভূমিকাগুলি বরাদ্দ করতে হবে, যাতে কে কী অ্যাক্সেস করতে পারে তা নির্ধারণ করতে। এছাড়াও, সেটপ্রাইস এবং সেটপ্যাকেজ ডেলিভারড ফাংশনে দুটি 'প্রয়োজনীয়' বিবৃতি যোগ করা হয়েছে।
আপনি বলতে পারেন, শুধুমাত্র যে অ্যাকাউন্টটিকে Dunzo ভূমিকা নিযুক্ত করা হয়েছে তারা স্থাপনার সময় উল্লিখিত বিক্রয় শর্তাবলী পরিবর্তন করতে সক্ষম হবে কিন্তু অন্য কোনটি নয়। এটি বলেছে, আপনি AccessControl.sol ব্যবহার করে একটি স্মার্ট চুক্তির ফাংশনে বিভিন্ন স্তরের অ্যাক্সেস সহ বেশ কয়েকটি ভূমিকা বরাদ্দ করতে পারেন যখন Ownable.sol এত গভীরতায় যাবে না।
এখন, স্মার্ট কন্ট্রাক্টে অ্যাক্সেস কন্ট্রোল বাস্তবায়নের জন্য এগুলিই একমাত্র সমাধান নয়। RBAC.sol এবং WhitelistCrowdSale.sol অতীতেও উপলব্ধ ছিল এবং যা ঠিকানাগুলির সাথেও ভূমিকা যুক্ত করতে পারে, অনেকটা AccessControl.sol এবং Ownable.sol এর মতো।
সুতরাং, আপনি যদি অ্যাক্সেস কন্ট্রোল বাস্তবায়নের বিবর্তন সম্পর্কে একটি পুঙ্খানুপুঙ্খ বোঝাপড়া অর্জন করতে চান, তাহলে এই দুটি স্মার্ট চুক্তিতেও কোডের ওপরে গিয়ে আপনার সময় ব্যয় হবে।
এছাড়াও এখানে প্রকাশিত.
এই নিবন্ধের প্রধান চিত্রটিহ্যাকারনুনের এআই ইমেজ জেনারেটর দ্বারা "অ্যাক্সেস অস্বীকার করা বায়োমেট্রিক স্ক্যান" প্রম্পটের মাধ্যমে তৈরি করা হয়েছে।