ইথেরিয়াম অ্যাকাউন্ট স্টেট: একটি ন্যূনতম টোকেনের জন্য QA পাইপলাইন

পূর্ববর্তী পোস্টে একটি সম্পূর্ণ বাস্তবায়ন তুলে ধরা হয়েছিল: একটি ন্যূনতম টোকেন কন্ট্রাক্ট, অফ-চেইন স্থিতি পুনর্গঠন, এবং একটি React ফ্রন্টএন্ড — `mint()` থেকে MetaMask পর্যন্ত সম্পূর্ণ পথ। এই পোস্টটি সেখান থেকে এগিয়ে যায়: এই ধরনের কিছু কীভাবে QA করবেন?

আমি (এখনও) একজন ব্লকচেইন ইঞ্জিনিয়ার নই, কিন্তু QA প্যাটার্নগুলি বিভিন্ন ডোমেইন জুড়ে ভালভাবে স্থানান্তরিত হয়, এবং যা অন্যত্র ইতিমধ্যে কাজ করে তা ধার করা হল আমার দ্রুততম শেখার উপায়।

কন্ট্রাক্টটি শুধুমাত্র তিনটি কাজ করে: `mint`, `transfer`, এবং `burn`, কিন্তু এটিই সম্পূর্ণ QA টুলচেইন অনুশীলনের জন্য যথেষ্ট: স্ট্যাটিক বিশ্লেষণ, মিউটেশন টেস্টিং, গ্যাস প্রোফাইলিং, ফর্মাল ভেরিফিকেশন।

কোডটি `egpivo/ethereum-account-state`-এ রয়েছে।

আমরা যা নিয়ে শুরু করেছিলাম

নতুন কিছু যোগ করার আগে, প্রকল্পে ইতিমধ্যে ছিল:

• ২১টি Foundry ইউনিট টেস্ট যা প্রতিটি স্থিতি রূপান্তর কভার করে (সাফল্য, অবৈধ ইনপুটে রিভার্ট, ইভেন্ট নির্গমন)
• ৩টি ইনভেরিয়েন্ট টেস্ট একটি `TokenHandler`-এর মাধ্যমে যা ১০ জন অ্যাক্টরের উপর `mint`/`transfer`/`burn`-এর র‍্যান্ডম ক্রম চালায় (প্রতিটিতে ১২৮k কল)
• ফাজ টেস্ট যা র‍্যান্ডম পরিমাণের জন্য `sum(balances) == totalSupply` যাচাই করে
• TypeScript ডোমেইন টেস্ট (Vitest) অন-চেইন স্টেট মেশিনকে প্রতিফলিত করে
• CI: কম্পাইল, টেস্ট, লিন্ট (Prettier + solhint)

সমস্ত টেস্ট পাস হয়েছে। কভারেজ ভালো লাগছিল। তাহলে আরও কেন বিরক্ত করবেন?

কারণ "সমস্ত টেস্ট পাস" মানে "সমস্ত বাগ ধরা পড়েছে" নয়। ১০০% লাইন কভারেজ এখনও একটি প্রকৃত বাগ মিস করতে পারে যদি কোনো অ্যাসার্শন সঠিক জিনিস চেক না করে।

ফেজ ১: স্মার্ট কন্ট্রাক্ট স্ট্যাটিক বিশ্লেষণ এবং কভারেজ

Slither

Slither(Trail of Bits) এমন সমস্যাগুলি ধরে যা টেস্টে অদৃশ্য: রিএন্ট্র্যান্সি, আনচেকড রিটার্ন ভ্যালু, ইন্টারফেস মিসম্যাচ।

./scripts/run-qa.sh slither

ফলাফল: ১টি মাঝারি খুঁজে পাওয়া: `erc20-interface`: `transfer()` `bool` রিটার্ন করে না।

এটি প্রত্যাশিত। কন্ট্রাক্টটি ইচ্ছাকৃতভাবে সম্পূর্ণ ERC20 নয়: এটি একটি শিক্ষামূলক স্টেট মেশিন। কিন্তু খুঁজে পাওয়াটি একাডেমিক নয়:

যদি কেউ পরে এই টোকেনটি ERC20 প্রত্যাশা করে এমন প্রোটোকলে আমদানি করে, ইন্টারফেস মিসম্যাচ নীরবে ব্যর্থ হবে। Slither এখনই এটি ফ্ল্যাগ করে যাতে সিদ্ধান্তটি সচেতন হয়।

কভারেজ

./scripts/run-qa.sh coverageকভারেজ ফলাফল।

একটি আনকভার্ড ফাংশন: `BalanceLib.gt()`। আমরা এটিতে ফিরে আসব।

গ্যাস স্ন্যাপশট

./scripts/run-qa.sh gas

তিনটি অপারেশনের বেসলাইন গ্যাস খরচ:

পরবর্তী রানে, `forge snapshot — diff` বেসলাইনের সাথে তুলনা করে। `transfer()`-এ ২০% গ্যাস রিগ্রেশন প্রতিটি ব্যবহারকারীর জন্য প্রকৃত খরচ — মার্জের আগে এটি ধরা সস্তা।

ফেজ ২: মিউটেশন টেস্টিং এবং ফর্মাল ভেরিফিকেশন

মিউটেশন টেস্টিং (Gambit)

এখানেই বিষয়গুলি আকর্ষণীয় হয়ে উঠেছিল। Gambit(Certora) মিউট্যান্ট তৈরি করে: `Token.sol`-এর কপি ছোট ইচ্ছাকৃত বাগ সহ (`+=` থেকে `-=`, `>=` থেকে `>`, শর্ত নেগেট করা)। পাইপলাইন প্রতিটি মিউট্যান্টের বিরুদ্ধে সম্পূর্ণ টেস্ট স্যুট চালায়। যদি একটি মিউট্যান্ট বেঁচে থাকে (সমস্ত টেস্ট এখনও পাস হয়), তা একটি সুনির্দিষ্ট টেস্ট ফাঁক।

./scripts/run-qa.sh mutation

ফলাফল: ৯৭.০% মিউটেশন স্কোর — ৩৩টি মিউট্যান্টের মধ্যে ৩২টি নিহত, ১টি বেঁচে গেছে।

Gambit-এর আউটপুট লগ প্রতিটি মিউট্যান্ট এবং এটি কী পরিবর্তন করেছে তা দেখায়। কয়েকটি উদাহরণ:

Generated mutant #7: BinaryOpMutation — Token.sol:168
totalSupply = totalSupply.add(amountBalance) → totalSupply = totalSupply.sub(amountBalance)
KILLED by test_Mint_Success
Generated mutant #19: RelationalOpMutation — Token.sol:196
if (!fromBalance.gte(amountBalance)) → if (fromBalance.gte(amountBalance))
KILLED by test_Transfer_Success
Generated mutant #28: SwapArgumentsMutation — Token.sol:81
return Balance.unwrap(a) > Balance.unwrap(b) → return Balance.unwrap(b) > Balance.unwrap(a)
SURVIVED ← কোনো টেস্ট এটি ধরেনিGambit মিউটেশন টেস্টিং: ৩২টি নিহত, ১টি বেঁচে গেছে, মিউটেশন স্কোর ৯৭.০% 

বেঁচে যাওয়া মিউট্যান্ট `BalanceLib.gt()`-এ `a > b` থেকে `b > a` স্ব্যাপ করেছে। কোনো টেস্ট এটি ধরেনি কারণ `gt()` হল ডেড কোড। এটি `Token.sol`-এর কোথাও কল করা হয় না।

কভারেজ ৯১.৬৭% ফাংশন ফ্ল্যাগ করেছে কিন্তু ফাঁক ব্যাখ্যা করতে পারেনি। মিউটেশন টেস্টিং করেছে: `gt()` হল ডেড কোড, কিছুই এটি কল করে না, এবং কেউ লক্ষ্য করবে না যদি এটি ভুল হয়।

স্মার্ট কন্ট্রাক্টে মৃত বা অরক্ষিত কোডের প্রকৃত নজির রয়েছে।

ফাংশনটি কলযোগ্য হওয়ার উদ্দেশ্য ছিল না, কিন্তু কেউ সেই অনুমান টেস্ট করেনি। আমাদের `gt()` তুলনায় ক্ষতিকর নয়, কিন্তু প্যাটার্নটি একই: যে কোড বিদ্যমান কিন্তু কখনও ব্যবহার করা হয় না তা এমন কোড যা কেউ দেখছে না।

ফর্মাল ভেরিফিকেশন (Halmos)

Halmos(a16z) সমস্ত সম্ভাব্য ইনপুট সম্পর্কে প্রতীকীভাবে যুক্তি করে। যেখানে ফাজ টেস্ট র‍্যান্ডম মান নমুনা করে এবং এজ কেস হিট করার আশা করে, Halmos সম্পত্তি সম্পূর্ণভাবে প্রমাণ করে।

./scripts/run-qa.sh halmos

ফলাফল: ৯/৯ প্রতীকী টেস্ট পাস — সমস্ত ইনপুটের জন্য সমস্ত সম্পত্তি প্রমাণিত।

যাচাইকৃত সম্পত্তি:

একটি ব্যবহারিক নোট: Halmos 0.3.3 `vm.expectRevert()` সমর্থন করে না, তাই আমি সাধারণ Foundry উপায়ে রিভার্ট টেস্ট লিখতে পারিনি। ওয়ার্কঅ্যারাউন্ড হল একটি try/catch প্যাটার্ন — যদি কলটি সফল হয় যখন এটি রিভার্ট করা উচিত, `assert(false)` প্রমাণ ব্যর্থ করে:

function check_mint_reverts_on_zero_address(uint256 amount) public {
vm.assume(amount > 0);
try token.mint(address(0), amount) {
assert(false); // এখানে পৌঁছানো উচিত নয়
} catch {
// প্রত্যাশিত রিভার্ট - Halmos প্রমাণ করে এই পথ সবসময় নেওয়া হয়
}
}

সবচেয়ে সুন্দর নয়, কিন্তু এটি কাজ করে — Halmos এখনও সমস্ত ইনপুটের জন্য সম্পত্তি প্রমাণ করে। এই ধরনের জিনিস আপনি শুধুমাত্র টুলটি চালিয়ে খুঁজে পান।

ফর্মাল ভেরিফিকেশন কেন গুরুত্বপূর্ণ তার প্রসঙ্গে:

ভালনারেবিলিটি কোডে ছিল, যে কেউ পর্যালোচনা করতে পারে, কিন্তু ডিপ্লয়মেন্টের আগে কোনো টুল বা টেস্ট এটি ধরেনি। Halmos-এর মতো প্রতীকী প্রুভার ঠিক সেই ফাঁক বন্ধ করার জন্য বিদ্যমান — তারা নমুনা করে না; তারা ইনপুট স্পেস নিঃশেষ করে।

টেস্ট ফাইল হল `contracts/test/Token.halmos.t.sol`।

ফেজ ৩: ক্রস-লেয়ার প্রপার্টি টেস্টিং

প্রথম পোস্টের আর্কিটেকচারে একটি TypeScript ডোমেইন লেয়ার রয়েছে যা অন-চেইন স্টেট মেশিনকে প্রতিফলিত করে। এই ফেজ টেস্ট করে যে দুটি আসলে একমত কিনা।

fast-check সহ প্রপার্টি-বেসড টেস্টিং

আমি TypeScript ডোমেইন লেয়ারের জন্য fast-check প্রপার্টি টেস্ট যোগ করেছি, যা Foundry-এর ফাজার Solidity-এর জন্য যা করে তা প্রতিফলিত করে:

npm test - tests/unit/property.test.ts

ফলাফল: প্রকৃত বাগ ঠিক করার পরে ৯/৯ প্রপার্টি টেস্ট পাস।

টেস্ট করা সম্পত্তি:

• `Balance`: কম্যুটেটিভিটি, অ্যাসোসিয়েটিভিটি, আইডেন্টিটি, ইনভার্স, তুলনা সামঞ্জস্যতা
• `Token`: র‍্যান্ডম অপারেশন ক্রমের অধীনে ইনভেরিয়েন্ট `sum(balances) == totalSupply` (২০০ রান, প্রতিটিতে ৫০টি অপস)
• `Token`: র‍্যান্ডম ক্রমের পরে `totalSupply` অ-নেগেটিভ
• বৈধ ইনপুটের জন্য `mint` সবসময় সফল হয়
• `transfer` `totalSupply` সংরক্ষণ করে

fast-check যে বাগ খুঁজে পেয়েছে

fast-check `Token.ts` `transfer()`-এ একটি প্রকৃত ক্রস-লেয়ার সামঞ্জস্যতা বাগ খুঁজে পেয়েছে। সঙ্কুচিত কাউন্টারএক্সাম্পল অবিলম্বে স্পষ্ট ছিল:

Property failed after 3 tests
Shrunk 2 time(s)
Counterexample: transfer(from=0xaaa…, to=0xaaa…, amount=1n)
→ from == to (self-transfer)
→ verifyInvariant() returned false

সেল্ফ-ট্রান্সফার (`from == to`) `sum(balances) == totalSupply` ইনভেরিয়েন্ট ভাঙ্গে। `toBalance` `fromBalance` আপডেট হওয়ার আগে পড়া হয়েছিল, তাই যখন `from == to`, পুরানো মান ডিডাকশন ওভাররাইট করেছে:

// আগে (ত্রুটিপূর্ণ)
const fromBalance = this.getBalance(from);
const toBalance = this.getBalance(to); // ← from == to হলে পুরানো
this.accounts.set(from.getValue(), fromBalance.subtract(amount));
this.accounts.set(to.getValue(), toBalance.add(amount)); // ← বিয়োগ ওভাররাইট করে

ফিক্স: `fromBalance` লেখার পরে `toBalance` পড়ুন, Solidity-এর স্টোরেজ সিমান্টিক্সের সাথে মিলে:

// পরে (ঠিক করা)
const fromBalance = this.getBalance(from);
this.accounts.set(from.getValue(), fromBalance.subtract(amount));
const toBalance = this.getBalance(to); // ← এখন আপডেট করা মান পড়ে
this.accounts.set(to.getValue(), toBalance.add(amount));

Solidity কন্ট্রাক্ট প্রভাবিত হয়নি: এটি প্রতিটি লেখার পরে স্টোরেজ পুনরায় পড়ে। কিন্তু TypeScript মিররের একটি সূক্ষ্ম ক্রম নির্ভরতা ছিল যা কোনো বিদ্যমান ইউনিট টেস্ট কভার করেনি।

বৃহত্তর স্কেলে ক্রস-লেয়ার মিসম্যাচ বিপর্যয়কর হয়েছে।

আমাদের সেল্ফ-ট্রান্সফার বাগ কারো টাকা হারাতো না, কিন্তু ব্যর্থতার মোড কাঠামোগতভাবে একই: দুটি লেয়ার যা একমত হওয়ার কথা, নয়।

পথে আঘাত করা সমস্যা

একটি বিদ্যমান প্রকল্পে QA টুল চালানো কখনই শুধু "ইনস্টল এবং চালান" নয়। কিছু জিনিস কাজ করার আগে ভেঙে গিয়েছিল:

• `foundry.toml`-এ কোনো টেস্ট পথ না থাকায় ০% কভারেজ: প্রথম `forge coverage` রান বোর্ড জুড়ে ০% ফিরিয়ে দিয়েছে। দেখা যাচ্ছে `foundry.toml` `test = "contracts/test"` বা `script = "contracts/script"` নির্দিষ্ট করেনি, তাই Forge কোনো টেস্ট আবিষ্কার করছিল না। কভারেজ কমান্ড নীরবে সফল হয়েছে — এটি কভার করার কিছুই ছিল না। এটি সবচেয়ে বিভ্রান্তিকর ব্যর্থতা ছিল: কোনো দরকারী আউটপুট ছাড়াই একটি সবুজ রান।
• forge-std v1.14.0-এ `InvariantTest` ইমপোর্ট চলে গেছে: `Invariant.t.sol` `forge-std` থেকে `InvariantTest` ইমপোর্ট করেছে, যা একটি সাম্প্রতিক রিলিজে সরানো হয়েছে। কম্পাইলেশন একটি অস্পষ্ট "symbol not found" ত্রুটি সহ ব্যর্থ হয়েছে। ফিক্স ছিল ইমপোর্ট বাদ দেওয়া — `Test` একা এখন Foundry-এর ইনভেরিয়েন্ট টেস্টিংয়ের জন্য যথেষ্ট।
• `uint256(token.totalSupply())` বনাম `Balance.unwrap()`: টেস্টগুলি ব্যবহারকারী-সংজ্ঞায়িত `Balance` টাইপ থেকে অন্তর্নিহিত `uint256` বের করতে একটি স্পষ্ট কাস্ট ব্যবহার করছিল। এটি কম্পাইল হয়েছে, কিন্তু এটি ভুল ইডিয়ম — `Balance.unwrap(token.totalSupply())` হল UDVT সিস্টেম যার জন্য ডিজাইন করা হয়েছে। `Token.t.sol`, `Invariant.t.sol`, এবং `DeploySepolia.s.sol` জুড়ে প্রয়োগ করা হয়েছে।

পাইপলাইন ডিজাইন

সবকিছু দুটি স্ক্রিপ্টের মাধ্যমে চলে:

• scripts/setup-qa-tools.sh`: Slither, Halmos, Gambit ইনস্টল করে (আইডেমপোটেন্ট)
• `scripts/run-qa.sh`: চেক চালায়, `qa-results/`-এ টাইমস্ট্যাম্পড ফলাফল সংরক্ষণ করে

./scripts/run-qa.sh slither gas # শুধু স্ট্যাটিক বিশ্লেষণ + গ্যাস
./scripts/run-qa.sh mutation # শুধু মিউটেশন টেস্টিং
./scripts/run-qa.sh all # সবকিছু

প্রতিটি চেক দ্রুত নয়। Slither এবং কভারেজ প্রতিটি কমিটে চলে। মিউটেশন টেস্টিং এবং Halmos ধীর — সাপ্তাহিক বা প্রি-রিলিজ রানের জন্য আরও উপযুক্ত।

সারসংক্ষেপ

পাঁচটি QA লেয়ার, প্রতিটি একটি ভিন্ন শ্রেণীর সমস্যা ধরছে।

Gambit এবং fast-check এই রাউন্ডে সবচেয়ে কার্যকর ফলাফল দিয়েছে।

CI পাইপলাইন

QA চেকগুলি এখন GitHub Actions-এ ছয়-পর্যায়ের পাইপলাইন হিসাবে সংযুক্ত:

GitHub Actions পাইপলাইন: Build & Lint সমস্ত ডাউনস্ট্রিম পর্যায় গেট করে।

রেফারেন্স

• Ethereum Account State উৎস: [github.com/egpivo/ethereum-account-state](https://github.com/egpivo/ethereum-account-state)
• পূর্ববর্তী পোস্ট: Ethereum Account State
• Slither: github.com/crytic/slither
• Gambit: github.com/Certora/gambit
• Halmos: github.com/a16z/halmos
• fast-check: github.com/dubzzz/fast-check
• Foundry: getfoundry.sh

নোট

• এই পোস্টটি আমার মূল ব্লগ পোস্ট থেকে অভিযোজিত।

Ethereum Account State: QA Pipeline for a Minimal Token মূলত Coinmonks-এ Medium-এ প্রকাশিত হয়েছিল, যেখানে লোকেরা এই গল্পটি হাইলাইট এবং প্রতিক্রিয়া জানিয়ে কথোপকথন চালিয়ে যাচ্ছে।