What Is a Smart Contract—and Why Its Rules Cannot Be Changed Retroactively?

Disclaimer: This article is for educational purposes only. It is not financial, legal, or investment advice.

A smart contract is often described as a “digital agreement.” That is a useful analogy, but it is not the full picture. More precisely, a smart contract is a program deployed on a blockchain that stores data and executes predefined instructions.

যেমন, এটি শর্ত পূরণ হলে transfer অনুমতি দিতে, participant track রাখতে বা সফল operation-এর পর record update করতে পারে। কেউ transaction submit করলে network code execute করে result record করে।

শুরু থেকেই দুটি সীমাবদ্ধতা গুরুত্বপূর্ণ:

‘Smart’ মানে program চিন্তা বা intent বিচার করতে পারে—এমন নয়।
‘Contract’ শব্দটি code-কে স্বয়ংক্রিয়ভাবে agreement-এর legal status দেয় না।

স্মার্ট কন্ট্র্যাক্ট তার code যা অনুমতি দেয় ঠিক তাই করে। Logic-এ bug, অনিরাপদ administrative function বা ভুল assumption থাকলে blockchain নিজে তা ঠিক করে না।

মূল বিষয়

স্মার্ট কন্ট্র্যাক্ট হলো ব্লকচেইন ঠিকানায় সংরক্ষিত code ও data।

Network পূর্বনির্ধারিত rule অনুযায়ী function execute করে।

নিশ্চিত হওয়া কোনো অপারেশন পরে সরাসরি সম্পাদনা করা যায় না।

কিছু contract adjustable parameter বা upgradeable logic দিয়ে তৈরি।

User-দের শুধু contract address নয়, এর role, permission ও upgrade mechanism-ও যাচাই করা উচিত।

স্মার্ট কন্ট্র্যাক্ট বোঝার সহজ উপায়

একটি automated storage locker কল্পনা করুন।

এর rule বলে: “নির্দিষ্ট তারিখের পরেই recipient locker খুলতে পারবেন।”
Sender একটি asset deposit করেন।
Recipient সময়ের আগে এটি খুলতে চেষ্টা করেন, আর machine তা প্রত্যাখ্যান করে।
তারিখটি এলে এবং অন্য সব শর্ত পূরণ হলে একই অনুরোধ সফল হয়।

পার্থক্য হলো smart contract কোনো এক কোম্পানির server execute করে না। Blockchain network instruction process করে, shared result-এ পৌঁছায় এবং তা record করে।

এর মানে contract স্বয়ংক্রিয়ভাবে জানে না package delivered হয়েছে কি না, weather কেমন বা exchange rate কত হওয়া উচিত। Blockchain তার কাছে থাকা data নিয়ে নির্ভরযোগ্যভাবে কাজ করে। বাইরের বিশ্বের তথ্যের জন্য অতিরিক্ত source দরকার, যাকে প্রায়ই oracle বলা হয়। তখন outcome সেই source-এর ওপরও নির্ভর করে।

Code, state ও transaction

স্মার্ট কন্ট্র্যাক্ট বোঝার তিনটি গুরুত্বপূর্ণ দিক:

Code: its available functions and checks.
State: its current data, such as balances, statuses, and configuration values.
Transaction history: the sequence of operations that changed that state.

Public data পড়লে সাধারণত state বদলায় না। Token transfer বা participation register করার মতো state পরিবর্তনকারী action-এর জন্য transaction দরকার। User সেটি sign করেন, network process করে এবং সাধারণত fee কাটা হয়।

একবার included ও finalized হলে transaction chain-এর history-এর অংশ হয়ে যায়। Code অনুমতি দিলে পরের transaction current state বদলাতে পারে, কিন্তু আগের record rewrite করে না। দুটি event-ই দৃশ্যমান থাকে।

‘Retroactively বদলানো যায় না’ কথাটির প্রকৃত অর্থ

ধরা যাক একটি contract address A থেকে address B-তে 100 token transfer record করেছে। Confirmation-এর পর administrator সেই block খুলে 100-কে 10 দিয়ে এমনভাবে বদলাতে পারে না যেন original operation ঘটেইনি। Already confirmed transaction-এর recipient-ও নীরবে বদলাতে পারে না।

If the code includes a refund, reversal, or compensation function, using it creates a new transaction. The blockchain will show the original action and the later response.

এ কারণেই অন-চেইন history independent verification সম্ভব করে: বিভিন্ন observer network query করে একই event sequence পরীক্ষা করতে পারেন।

Blockchain “কোনো পরিস্থিতিতেই বদলায় না” বলা ঠিক নয়। Network-এর নিজস্ব finality model আছে এবং protocol failure বা attack-এর ঝুঁকি থাকে। বাস্তব বিষয়টি সীমিত: normal operation-এ user বা app administrator private database-এর row-এর মতো confirmed blockchain record edit করতে পারে না।

এর অর্থ কি contract কখনো বদলাতে পারে না?

সব সময় নয়। ‘Immutable contract’ কথাটি এখানেই প্রায়ই ভুল বোঝা হয়।

1. আপগ্রেড-অযোগ্য কন্ট্র্যাক্ট

Deployed code তার original logic অনুযায়ী চলতে থাকে। Developer নতুন address-এ নতুন contract deploy করতে পারেন, কিন্তু পুরোনো address ও তার history থেকে যায়। User-কে সচেতনভাবে নতুন version-এ যেতে হয়।

2. পরিবর্তনযোগ্য প্যারামিটারসহ কন্ট্র্যাক্ট

Code-এ এমন administrator function থাকতে পারে যা limit বদলায়, operation pause করে, allowlist manage করে বা fee recipient update করে। এসব function-এর জন্যও নতুন transaction লাগে এবং code-এ থাকা ক্ষমতাই শুধু ব্যবহার করতে পারে।

এটি অতীত rewrite করে না, তবে future operation-এর rule বদলাতে পারে।

3. আপগ্রেডযোগ্য আর্কিটেকচার

একটি প্রচলিত নকশায় proxy contract ব্যবহৃত হয়। Proxy address একই থাকে, কিন্তু কল আলাদা implementation contract-এ পাঠায়। Governance যদি সেই implementation বদলাতে পারে, ভবিষ্যতে proxy address-এর আচরণও বদলাতে পারে।

এর মানে ‘address বদলায়নি’ কথাটি সব সময় ‘logic কখনো বদলায়নি’ বোঝায় না। সতর্ক review-এ প্রশ্ন করা হয়:

Address কি proxy?
কে implementation upgrade করতে পারে?
একটি signature যথেষ্ট, নাকি কয়েকটি দরকার?
Time delay আছে কি?
অপারেশন কি বিরতি দেওয়া যায়?
Administrator কোন parameter বদলাতে পারেন?

উদাহরণ: limit পরিবর্তন

দৈনিক 1,000 unit limit-সহ একটি contract কল্পনা করুন।

সোমবার একজন user 800-unit operation সম্পন্ন করেন।
মঙ্গলবার একটি authorized address নতুন transaction-এর মাধ্যমে limit 500-তে পরিবর্তন করে।
সোমবারের operation হারিয়ে যায় না বা অন্য record-এ পরিণত হয় না।
Tuesday থেকে contract 500-unit limit প্রয়োগ করবে, যদি তার logic তাই নির্ধারণ করে।

ব্লক এক্সপ্লোরার দুটি লেনদেনই দেখাতে পারে। তবে সেগুলোর প্রভাব বুঝতে কোন ফাংশন কল হয়েছে এবং সেই ফাংশনের কী ক্ষমতা আছে তা জানতে হবে।

Blockchain কী প্রমাণ করে—এবং কী করে না

পাবলিক ব্লকচেইন যা যাচাই করতে সহায়তা করে:

Participating address;
Transaction time ও status;
Transferred asset ও amount;
Data সঠিকভাবে decoded হলে called function;
Event ও operation-এর sequence;
Deployed bytecode-এর সঙ্গে verified হলে source code।

Deployment on a blockchain does not by itself guarantee:

Bug বা vulnerability-এর অনুপস্থিতি;
সৎ developer;
Economic sustainability;
সঠিক external data;
Administrator power-এর অনুপস্থিতি;
Legal protection;
ভুল transfer-এর পর recovery।

Transparency মানে evidence পরীক্ষা করা যায়। এর মানে visible সবকিছু safe নয়।

ইন্টারঅ্যাকশনের আগের ব্যবহারিক checklist

Verify the address. Obtain it from an official project source and compare it carefully.
Verify the network. The same address format may exist across several EVM networks.
Check source verification. Published source code makes analysis easier, but it is not a security audit.
Look for proxies and upgrades. Identify the implementation and the upgrade authority.
Review administrator powers. Look for owner, admin, pause, upgrade, fee, and access-control functions.
Review token approvals. Before approving, confirm the token, spender, and allowance.
Start small. For a first interaction, consider a small test amount while accounting for fees.

User-এর signature কেন গুরুত্বপূর্ণ

স্মার্ট কন্ট্র্যাক্ট স্বয়ংক্রিয়ভাবে পুরো ওয়ালেটে access পায় না। এটি নির্দিষ্ট call পায় এবং শুধু দেওয়া permission ব্যবহার করতে পারে।

একটি signature সাধারণ transfer-এর চেয়ে বেশি কিছুর অনুমতি দিতে পারে। এটি token spending approve, unlimited allowance grant, asset exchange, NFT transfer বা জটিল call sequence শুরু করতে পারে।

Wallet request স্পষ্টভাবে ব্যাখ্যা করতে না পারলে user “blind signing” risk-এ থাকেন। Familiar chat থেকে link এসেছে বা website official site-এর মতো দেখায়—শুধু এ কারণে transaction approve করা উচিত নয়।

উপসংহার

স্মার্ট কন্ট্র্যাক্ট কোনো প্রতিশ্রুতি বা ন্যায্যতার জাদুকরি নিশ্চয়তা নয়। এটি encoded rule কার্যকর করে এবং যাচাইযোগ্য history রেখে যায়।

A confirmed operation cannot be quietly edited after the fact. However, future parameters or logic may be changeable if the architecture was designed that way. The most useful question is therefore not only “Is there a smart contract?” but also: “What does its code allow, and who can influence how it works in the future?”

মূল বিষয়