Byzantine Fault Tolerance
- ●Byzantine fault মানে নোড শুধু মরে না, বরং মিথ্যা বলে, পরস্পরবিরোধী বার্তা পাঠায় বা ক্ষতিকরভাবে আচরণ করে।
- ●এমন faulty নোড সহ্য করে সঠিক consensus পেতে কমপক্ষে 3f+1 নোড লাগে, যেখানে f হলো faulty নোডের সংখ্যা।
- ●PBFT ও blockchain consensus এই BFT সমস্যা সমাধান করে, যেখানে অংশগ্রহণকারীদের বিশ্বাস করা যায় না।
সমস্যাটা কী?
এতক্ষণ আমরা ধরে নিয়েছি নোড হয় ঠিকঠাক কাজ করে, নয়তো একদম মরে যায় (crash)। কিন্তু বাস্তবে আরও ভয়ংকর একটা সম্ভাবনা আছে — নোড বেঁচে আছে, কিন্তু মিথ্যা বলছে। হয়তো একটা bug-এর কারণে, হয়তো hacker দখল করেছে, হয়তো hardware corruption-এ ভুল data পাঠাচ্ছে।
এমন নোড একজনকে বলবে "হ্যাঁ", আরেকজনকে একই সময়ে বলবে "না"। ভুল data পাঠাবে কিন্তু signature ঠিক রাখবে। এই দু'মুখো, প্রতারক আচরণ সামলে কীভাবে সবাই একটা সঠিক সিদ্ধান্তে আসবে?
এই সমস্যাটার নাম Byzantine Generals Problem — কয়েকজন সেনাপতি দূর থেকে বার্তাবাহক দিয়ে যোগাযোগ করে আক্রমণের সিদ্ধান্ত নিতে চান, কিন্তু কেউ কেউ বিশ্বাসঘাতক হতে পারেন। সবাই বিশ্বস্ত না হলেও বিশ্বস্তরা যেন একমত হতে পারেন — এটাই চ্যালেঞ্জ।
মূল ধারণা
Byzantine fault: একটি নোডের যেকোনো রকম স্বেচ্ছাচারী (arbitrary) ত্রুটি — মিথ্যা বলা, পরস্পরবিরোধী বার্তা পাঠানো, কিছু নোডকে এক কথা ও অন্যদের ভিন্ন কথা বলা, কিংবা ক্ষতিকরভাবে আচরণ — কেবল থেমে যাওয়া (crash) নয়।
Byzantine Fault Tolerance (BFT) হলো এমন কিছু faulty/প্রতারক নোড থাকা সত্ত্বেও সঠিক, সামঞ্জস্যপূর্ণ consensus অর্জনের ক্ষমতা।
মূল পার্থক্য:
- Crash fault tolerance (CFT) — নোড শুধু থামে; Raft, Paxos এটা সামলায়। তুলনামূলক সহজ।
- Byzantine fault tolerance (BFT) — নোড মিথ্যা বলতে পারে; অনেক কঠিন ও ব্যয়বহুল।
কীভাবে কাজ করে
কেন 3f+1 নোড?
ধরো f সংখ্যক নোড faulty হতে পারে। কেন 2f+1 যথেষ্ট নয়?
কারণটা quorum-এর। সিদ্ধান্ত নিতে আমাদের একটা quorum দরকার যা — (১) faulty নোড গরহাজির থাকলেও তৈরি হতে পারে, এবং (২) দুটো quorum এমনভাবে overlap করবে যে overlap-এ অন্তত একজন honest নোড থাকবেই (faulty নোড উভয় দিকে মিথ্যা বললেও)। গণিত কষলে দেখা যায় এর জন্য মোট নোড N কমপক্ষে 3f+1 হতে হবে, আর quorum হবে 2f+1।
| Fault model | মোট নোড দরকার | উদাহরণ protocol |
|---|---|---|
| Crash (CFT) | 2f+1 | Raft, Paxos |
| Byzantine (BFT) | 3f+1 | PBFT, Tendermint |
অর্থাৎ ১টা প্রতারক সামলাতে কমপক্ষে ৪টা নোড, ২টা সামলাতে ৭টা। ক্ষতিকর নোড সামলানোর দাম অনেক বেশি।
PBFT-এর অন্তর্দৃষ্টি
Practical Byzantine Fault Tolerance (PBFT, ১৯৯৯) তিন ধাপে কাজ করে:
- Pre-prepare: primary (leader) একটা request নিয়ে ক্রম প্রস্তাব করে।
- Prepare: নোডরা একে অপরকে বলে "আমি এই ক্রম দেখেছি"; কেউ 2f+1 prepare পেলে নিশ্চিত হয় honest সংখ্যাগরিষ্ঠ একমত।
- Commit: নোডরা commit বার্তা বিনিময় করে; 2f+1 commit পেলে সিদ্ধান্ত চূড়ান্ত।
প্রতিটা নোড অন্যদের সাথে কথা বলে, তাই message সংখ্যা প্রায় N-এর বর্গের সমানুপাতিক — তাই PBFT ছোট cluster-এ ভালো চলে, হাজার হাজার নোডে নয়। primary প্রতারণা করলে নোডরা view change করে নতুন primary বেছে নেয়।
প্রকারভেদ
ভাবো একটা পরীক্ষার হলে কয়েকজন invigilator মিলে চূড়ান্ত নম্বর ঘোষণা করবেন, কিন্তু সন্দেহ আছে দু'একজন ঘুষ খেয়ে মিথ্যা নম্বর বলবেন এবং একেকজনকে একেক রকম বলবেন। সমাধান: এত বেশি সৎ invigilator রাখো যে, প্রতারকরা একজোট হয়ে মিথ্যা বললেও সৎদের সংখ্যাগরিষ্ঠ ভোট মিলিয়ে গেলে আসল নম্বর বেরিয়ে আসে। ১ জন প্রতারক সামলাতে অন্তত ৪ জন দরকার, যাতে যেকোনো ৩ জনের মতামতেও সৎ সংখ্যাগরিষ্ঠতা নিশ্চিত থাকে — এটাই 3f+1।
কৌশল
- PBFT-ধাঁচা (Tendermint, HotStuff): known, permissioned অংশগ্রহণকারী; দ্রুত finality; ছোট-মাঝারি validator set।
- Proof of Work (Bitcoin): কোনো নির্দিষ্ট নোড-গণনা নেই; কাজের (hash) খরচ দিয়ে প্রতারণা অর্থনৈতিকভাবে অলাভজনক করে — probabilistic BFT।
- Proof of Stake (Ethereum): validator-রা টাকা (stake) বন্ধক রাখে; প্রতারণা করলে stake কেটে নেওয়া হয় (slashing)।
PoW/PoS হলো permissionless পরিবেশের BFT — যেখানে কে অংশ নেবে আগে জানা নেই; PBFT হলো permissioned — অংশগ্রহণকারীরা পরিচিত।
কখন ব্যবহার করবে / করবে না
ব্যবহার করবে যখন অংশগ্রহণকারীদের বিশ্বাস করা যায় না — public blockchain, cross-organization consortium, যেখানে একটি পক্ষ প্রতারণা করতে পারে।
ব্যবহার করবে না যখন সব নোড তোমার নিজের, একই trusted datacenter-এ। সেখানে শুধু crash সামলালেই হয়, তাই Raft/Paxos যথেষ্ট — BFT-র বাড়তি জটিলতা ও খরচ অপ্রয়োজনীয়।
BFT বিনামূল্যে আসে না। 3f+1 নোড আর প্রতি সিদ্ধান্তে বহু message মানে বিশাল overhead ও কম throughput। তাই ভুল করেও internal microservices-এ BFT চাপিয়ে দিও না — সেখানে নোডরা প্রতারক নয়, শুধু মাঝে মাঝে crash করে; Raft যথেষ্ট। আবার মনে রেখো — 3f+1-এর বেশি নোড faulty হয়ে গেলে BFT-ও আর নিরাপত্তা দেয় না, তাই f বাছাই বাস্তবসম্মত হওয়া চাই।
বাস্তব উদাহরণ
- Bitcoin: Proof of Work দিয়ে বিশ্বাসহীন, উন্মুক্ত নেটওয়ার্কে double-spend ঠেকায় — বৃহত্তম BFT সিস্টেম।
- Ethereum: Proof of Stake (Gasper) দিয়ে BFT-style finality দেয়।
- Hyperledger Fabric / Tendermint (Cosmos): permissioned blockchain-এ PBFT-জাতীয় consensus।
- এভিয়নিক্স ও মহাকাশযান: বিমানের flight control computer-এ Byzantine fault tolerance ব্যবহার হয়, যাতে একটি সেন্সর/কম্পিউটার ভুল data দিলেও সিস্টেম সঠিক সিদ্ধান্ত নেয়।
ইন্টারভিউতে BFT বললে অবশ্যই crash fault-এর সাথে পার্থক্য স্পষ্ট করো এবং 3f+1-এর যুক্তি দাও — "faulty নোড দু'মুখো মিথ্যা বললেও দুটি quorum-এর overlap-এ honest সংখ্যাগরিষ্ঠতা দরকার, তাই 3f+1।" আর জোর দিয়ে বলো — BFT কেবল বিশ্বাসহীন (blockchain) পরিবেশে দরকার; নিজের datacenter-এ Raft-ই যথেষ্ট। এই প্রয়োগ-প্রসঙ্গের বিচারটাই পরিপক্বতার লক্ষণ।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Byzantine fault আর crash fault-এর মূল পার্থক্য কী?
2. f সংখ্যক Byzantine নোড সহ্য করতে কমপক্ষে কতগুলো নোড দরকার?
3. PBFT-এর মতো BFT consensus কোথায় সবচেয়ে প্রাসঙ্গিক?