Walrus Protocol কীভাবে decentralized storage চালায়, সেটা বুঝতে গেলে আগে একটা সহজ সত্য মেনে নিতে হয়—ইন্টারনেট কখনোই স্থির না। নোড আসে-যায়, নেটওয়ার্কে সমস্যা হয়, আর মানুষ বা মেশিন—কেউই সবসময় অনলাইনে থাকে না। Walrus এই বাস্তবতাকে অস্বীকার করে না, বরং ডিজাইনের মধ্যেই ধরে নেয়। এখান থেকেই আসে তাদের Clock-and-Committee মডেল, যেখানে স্টোরেজকে সময়ের সাথে যুক্ত করে দেখা হয়।
Walrus-এ সময় ভাগ করা হয় epoch-এ। প্রতিটা epoch-এ একটি নির্দিষ্ট storage committee থাকে, যারা সেই সময়টায় ডেটার availability নিশ্চিত করার দায়িত্বে থাকে। এর মানে, নেটওয়ার্কে কোনো অস্পষ্ট “সবাই দায়ী” অবস্থা নেই। সবসময়ই একটি পরিষ্কার, accountable গ্রুপ থাকে যারা জানে—এই epoch-এ এই ডেটাগুলো আমাদের দায়িত্ব। এই ধারণাটা decentralized storage-কে অনেক বেশি বাস্তব ও নিয়ন্ত্রণযোগ্য করে তোলে।
এই committee গঠিত হয় delegated proof-of-stake মডেলের মাধ্যমে। কারা স্টেক করেছে, কতটা বিশ্বাসযোগ্য—এসবের উপর ভিত্তি করেই নির্ধারিত হয় কোন নোডগুলো নির্দিষ্ট epoch-এ storage-এর দায়িত্ব পাবে। ফলে storage এখানে আর কেবল জায়গা ভাড়া দেওয়া নয়, বরং একটি নির্দিষ্ট সময়ের জন্য নেওয়া দায়িত্ব। Byzantine fault-এর কথা মাথায় রেখেই shard বা sliver বণ্টন করা হয়, যাতে কিছু নোড ব্যর্থ হলেও ডেটা পুনরুদ্ধার করা যায়।
Clock অংশটা Walrus-এ শুধু সময় গণনার জন্য না, বরং প্রতিশ্রুতি নির্ধারণের জন্য। যখন কেউ একটি blob স্টোর করে, তখন সে বলে দেয় এই ডেটা কত সময় পর্যন্ত available থাকতে হবে। এই commitment-টাই epoch-এর সাথে বাঁধা থাকে। এখানে Sui কাজ করে একটি control plane হিসেবে—ডেটার metadata, availability proof আর lifetime সব on-chain থাকে, আর আসল বড় ডেটা off-chain স্টোরেজ নোডগুলোতে রাখা হয়।
Walrus-এর write process-টা খুব ইচ্ছাকৃতভাবে ধাপে ধাপে করা। প্রথমে ডেটাকে erasure coding দিয়ে ছোট ছোট sliver-এ ভাগ করা হয়, তারপর সেগুলো current committee-র নোডগুলোতে পাঠানো হয়। পর্যাপ্ত সংখ্যক নোড থেকে signed acknowledgement পাওয়ার পর সেই প্রমাণগুলো একত্র করে Sui-তে একটি Proof of Availability হিসেবে প্রকাশ করা হয়। এই মুহূর্ত থেকেই সিস্টেম ধরে নেয় ডেটা সত্যিই available—এটা আর অনুমানের বিষয় থাকে না, এটা প্রমাণযোগ্য সত্য হয়ে যায়।
সবচেয়ে কঠিন জায়গা আসে epoch পরিবর্তনের সময়। বেশিরভাগ decentralized storage সিস্টেম এখানেই সমস্যায় পড়ে, কারণ দায়িত্ব হঠাৎ বদলে গেলে ডেটা হারানোর ঝুঁকি তৈরি হয়। Walrus এটা সমাধান করেছে staged transition দিয়ে। নতুন committee ধীরে ধীরে write নেওয়া শুরু করে, আর পুরোনো committee তখনও read সার্ভ করতে পারে। ফলে কোনো একক মুহূর্তে সবকিছু উল্টে যায় না, আর সেই ভঙ্গুর “handover point” তৈরি হয় না।
আজকে Walrus নিয়ে এত আলোচনা হওয়ার কারণও খুব বাস্তব। Blockchain-গুলো চুক্তি আর consensus-এ দারুণ, কিন্তু বড় ফাইল রাখার জন্য তৈরি না। অন্যদিকে, AI, gaming, social অ্যাপগুলো বিশাল storage চায়, কিন্তু আবার কেন্দ্রীয় সার্ভারের উপর নির্ভর করতে চায় না। Walrus ঠিক এই ফাঁকটাই পূরণ করে—logic আর commitment on-chain, ডেটা off-chain, কিন্তু সবকিছু যাচাইযোগ্য।
সবচেয়ে ভালো দিক হলো, Walrus obligation-গুলোকে অস্পষ্ট রাখে না। একটি blob আছে, তার metadata জানা, lifetime নির্দিষ্ট, এই মুহূর্তে কোন committee দায়ী সেটা পরিষ্কার, আর committee বদলালেও সেটা পরিকল্পিতভাবে হয়। এখানে সময় যায়, সদস্য বদলায়—এই বাস্তবতাকে মেনে নিয়েই সিস্টেমটা চলে। Web3-এ যেখানে অনেক প্রোজেক্ট বাস্তব সমস্যাকে উপেক্ষা করে, Walrus সেখানে বলে—সমস্যা থাকবেই, আমরা সেটার উপর দাঁড়িয়েই ইঞ্জিনিয়ারিং করব।
