ব্যাংকিং blockchain শুধু token contract বা host করা node নয়; এটি একটি পরিচালন পরিবেশ। এতে EVM-সামঞ্জস্যপূর্ণ network, validator-এর দায়িত্ব, canonical native balance, নিয়ন্ত্রিত প্রশাসন, transaction policy, interface এবং কোনো প্রতিষ্ঠানকে সমন্বিতভাবে এসব ব্যবহার করতে সহায়ক পরিচালনাগত সিদ্ধান্ত একত্রিত হয়।
এই অধ্যায়ে production ব্যবহারের সিদ্ধান্তের আগে ব্যাংকের যেসব প্রশ্নের উত্তর স্থির করা দরকার, সেগুলোর সঙ্গে এসব সক্ষমতার সম্পর্ক দেখানো হয়েছে। প্ল্যাটফর্মটি কনফিগারযোগ্য প্রযুক্তি ও সম্মত সেবা দেয়; প্রতিষ্ঠান তার policy, asset ও reserve, অনুমোদন, গ্রাহকের প্রতি অঙ্গীকার এবং গৃহীত কাজের পরিধির জন্য দায়ী থাকে।
Network-এর ভিত্তি ও পরিচালন সীমা
ভিত্তি হলো নির্ধারিত validator set ও network policy-সহ একটি স্বতন্ত্র EVM-সামঞ্জস্যপূর্ণ network। পরিচিত EVM tool দিয়ে application তৈরি করা যেতে পারে; তবে network identity, node resource, RPC access, storage ও validator operation কোনো package-এর নাম দেখে ধরে নেওয়া নয়, বরং প্রতিষ্ঠানের workload এবং deployment scope অনুযায়ী নির্বাচন করা হয়।
তৈরির আগে environment-এর সীমা, দায়িত্বপ্রাপ্ত operator, access model, maintenance প্রত্যাশা এবং dependency-তে একমত হন। Network তৈরি হওয়ার পর Chain ID অপরিবর্তনীয়; তাই launch-এর আগে application, wallet, interface ও integration team-কে একই identifier নিয়ে সিদ্ধান্তে পৌঁছাতে হবে। Capacity ও সেবার অঙ্গীকার discovery এবং স্বাক্ষরিত চুক্তির মাধ্যমে নিশ্চিত হয়, উদাহরণমূলক বিবরণ থেকে ধরে নেওয়া যায় না।
ব্যাংকিং network হলো পরস্পর-সহযোগী স্তরের সমষ্টি
- প্রতিষ্ঠানের application
ব্যাংকিং workflow ও অনুমোদিত EVM application নথিভুক্ত interface ব্যবহার করে।
- ব্যাংকিং নিয়ন্ত্রণ
নিয়ন্ত্রিত asset, restriction, pause এবং fee policy কোন কাজগুলো করা যাবে তা নির্ধারণ করে।
- EVM-এর প্রামাণ্য লেজার
Native balance ও network transaction একই canonical ledger state ব্যবহার করে।
- Validator ও operation
কনফিগার করা validator ও operator সম্মত governance এবং service scope মেনে চলে।
সক্ষমতা ও প্রতিষ্ঠানের দায়িত্ব
Production platform-এর সক্ষমতার মধ্যে রয়েছে native asset administration, কনফিগারযোগ্য পরিমাণ hold এবং যোগ্য account বা wallet restriction, প্রযোজ্য transfer pause, governance workflow, banking explorer এবং মূল Paymaster architecture। নির্বাচিত configuration-ই উপলভ্য scope ও আচরণ নির্ধারণ করে; কোনো control পরিচালনাগতভাবে নির্ভরযোগ্য ধরে নেওয়ার আগে প্রতিষ্ঠানকে প্রতিনিধিত্বমূলক পরিস্থিতিতে তা যাচাই করতে হবে।
প্রযুক্তি ব্যবসায়িক সিদ্ধান্ত নেয় না। কে প্রশাসনিক কাজ প্রস্তাব, অনুমোদন, বাস্তবায়ন, পর্যালোচনা ও প্রত্যাহার করতে পারবেন এবং এসব দায়িত্ব অভ্যন্তরীণ policy-র সঙ্গে কীভাবে খাপ খায়, তা প্রতিষ্ঠান নির্ধারণ করে। Asset reserve, custody ব্যবস্থা, redemption অঙ্গীকার, গ্রাহকের সঙ্গে আচরণ এবং আইনি ব্যাখ্যার দায় প্রতিষ্ঠানকেই নিতে হবে; network configuration এগুলো সরবরাহ করে না।
Integration ও পরিচালন মডেল
Integration পরিকল্পনা শুরু হয় প্রতিটি system-এর প্রয়োজনীয় তথ্য ও কাজ, identity ও authorization model, data mapping এবং error ও reconciliation-এর দায়িত্ব নির্ধারণ দিয়ে। Core banking, identity, HSM, SIEM, KYC ও অন্যান্য external connection engagement অনুযায়ী মূল্যায়ন ও scope নির্ধারণ করা হয়; পণ্যের বিবরণ থেকে প্রস্তুত connector বা স্বয়ংক্রিয় compatibility ধরে নেওয়া যায় না।
Validator-এ অংশগ্রহণ, key management, monitoring, support escalation, change review এবং recovery সিদ্ধান্তের জন্যও নির্দিষ্ট দায়িত্বপ্রাপ্ত ব্যক্তি বা দল দরকার। Deployment design-এ dependency এবং প্রতিষ্ঠান পরিচালিত কাজ ও সম্মত service-provider কাজের বিভাজন নথিভুক্ত থাকা উচিত। প্রযোজ্য ক্ষেত্রে ঐচ্ছিক সেবা ও third-party component-এর জন্য আলাদা feasibility ও commercial review প্রয়োজন।
নির্ধারিত সীমানায় প্রতিষ্ঠানের system network-এর সঙ্গে যুক্ত হয়
- সম্মত interfaceপ্রতিটি integration-এর জন্য মূল্যায়িত নথিভুক্ত API ও identity scope।
- ব্যাংকিং নেটওয়ার্কEVM ledger, নিয়ন্ত্রিত control, validator এবং explorer সক্ষমতা।
- পরিচালন দলপ্রতিষ্ঠান ও service-এর ভূমিকা স্পষ্টভাবে সম্মত দায়িত্বের মধ্যে কাজ করে।
প্রস্তুতি, সীমাবদ্ধতা ও পরবর্তী সিদ্ধান্ত
কার্যকর readiness review-তে প্রত্যাশিত workload, ব্যবহারকারী, network environment, integration dependency, security প্রত্যাশা, support-এর সীমানা, recovery-এর চাহিদা এবং governance কর্তৃত্ব নথিভুক্ত থাকে। এসব input ও সম্মত architecture-এর ভিত্তিতে capacity নির্ধারণ হয়। প্রযোজ্য চুক্তিতে স্পষ্টভাবে উল্লেখ না থাকলে কোনো throughput, availability স্তর, certification বা response time ধরে নেওয়া উচিত নয়।
নির্দিষ্ট সময়ের pilot non-production scope-এ architecture, integration fit, control ও পরিচালন অনুমান যাচাই করতে পারে; এটি production service দেওয়ার অঙ্গীকার নয়। Production-এর জন্য technical ও commercial discovery, আনুষ্ঠানিক quote এবং স্বাক্ষরিত চুক্তি প্রয়োজন। Policy-সংক্রান্ত সিদ্ধান্তগুলো নির্দিষ্ট করতে native asset, restriction control, Paymaster এবং governance অধ্যায়গুলো পড়ুন।