Zcash-এর Shielded Pool, Unified Address ও Viewing Key ব্যাখ্যা

Zcash-এ pool কোনো exchange বা জমা রাখা প্রতিষ্ঠান নয়; এটি নির্দিষ্ট consensus নিয়মে পরিচালিত মূল্যের অবস্থা। স্বচ্ছ pool-এ প্রকাশ্য UTXO ব্যবহৃত হয়। যে কেউ chain দেখে কোন output তৈরি হয়েছে, পরে কোন transaction তা খরচ করেছে এবং দৃশ্যমান পরিমাণ কত—এসব জানতে পারে। একটি ঠিকানা নিজে আইনি পরিচয় প্রকাশ করে না, তবে প্রকাশ্য ইতিহাস ঠিকানার ব্যবহার ও মূল্যপ্রবাহের সংযোগ দেখায়।

Shielded pool দৃশ্যমান UTXO-এর বদলে note দিয়ে মূল্য উপস্থাপন করে। Network এনক্রিপ্ট করা note-এর তথ্য, commitment tree এবং pool balance যাচাইয়ের তথ্য রাখে। প্রমাণ consensus-কে বৈধতা, মূল্য সংরক্ষণ ও double-spend প্রতিরোধ যাচাই করতে দেয়; সাধারণ পর্যবেক্ষক স্বচ্ছ output-এর মতো গ্রহীতা ও note-এর পরিমাণ পড়তে পারে না। Zcash Protocol Specification দুই ধরনের ব্যবস্থাই ব্যাখ্যা করে।

Sapling ও Orchard পৃথক shielded pool; তাদের protocol এবং note commitment tree আলাদা, তাই তাদের balance একটিই বিনিময়যোগ্য অবস্থা নয়। Sprout ছিল Zcash-এর প্রথম shielded protocol। ZIP 211 সক্রিয় হওয়ার পর Sprout pool-এ নতুন মূল্য যোগ করা যায় না, যদিও পুরোনো Sprout transaction chain-এর ইতিহাসে আছে।

Network-এর অবস্থা তারিখসহ লিখুন। সরকারি ZIP সূচি অনুযায়ী NU6.2 সর্বশেষ সম্পন্ন Mainnet upgrade; এটি ৩ জুন ২০২৬-এ block 3,364,600-এ সক্রিয় হয়েছে। সাময়িক vulnerability mitigation-এর পর NU6.2 সংশোধিত circuit নিয়মে Orchard action আবার চালু করে। NU6.3 ও Ironwood pool এখনো draft প্রস্তাব, বর্তমান Mainnet নিয়ম নয়। দেখুন ZIP 257, ZIP সূচি ও draft ZIP 258।

একটি shielded note pool-এর মূল্যকে গ্রহীতার খরচ করার ক্ষমতার সঙ্গে যুক্ত করে। মূল্য, গ্রহীতার বিবরণ ও memo এনক্রিপ্ট করা হয়, যাতে প্রয়োজনীয় receiving information থাকা wallet তা পড়তে পারে। Chain note-এর plaintext নয়, এনক্রিপ্ট করা তথ্য ও note-এর commitment রাখে। Commitment note-এর বিষয়বস্তু প্রকাশ না করেই যাচাই করতে সাহায্য করে।

Note খরচ হলে transaction সংশ্লিষ্ট nullifier প্রকাশ করে। খরচকারী note জানার প্রমাণ দেয় এবং nullifier প্রকাশ করে; network যাচাই করে সেটি আগে ব্যবহার হয়েছে কি না। পর্যবেক্ষক nullifier ও commitment tree দেখতে পারে, তবে nullifier কোন পুরোনো commitment-এর তা শনাক্ত করতে পারার কথা নয়। এভাবে double-spend ঠেকে, কিন্তু consensus-এর সব তথ্য গোপন হয় না। Sapling ও Orchard একই সাধারণ ধারণা ভিন্ন cryptography ও proof দিয়ে বাস্তবায়ন করে; খরচ করতে সংশ্লিষ্ট ব্যক্তিগত ক্ষমতা লাগে।

Unified Address (UA) হলো একটি encoded string, যাতে Orchard, Sapling, transparent P2SH ও transparent P2PKH receiver থাকতে পারে। চালু Revision 0 UA-তে অন্তত একটি shielded receiver থাকতেই হবে। String-টি ইচ্ছাকৃতভাবে এমনভাবে তৈরি যে শুধু দেখে ভেতরে কোন receiver আছে বোঝা যায় না। ZIP 316 চালু Revision 0 ও প্রস্তাবিত Revision 2-কে আলাদা করে।

প্রেরকের wallet সব receiver-এ অর্থ পাঠায় না। Revision 0-তে অগ্রাধিকারের ক্রম Orchard, Sapling, transparent P2SH, তারপর transparent P2PKH। প্রেরককে wallet যে receiver-গুলো সমর্থন করে তাদের মধ্যে সর্বোচ্চ অগ্রাধিকারেরটি ব্যবহার করতে হয়। Wallet Orchard সমর্থন করলে সেটি বেছে নেয়; Orchard না থাকলেও Sapling থাকলে Sapling বেছে নিতে পারে। তাই ব্যবহৃত pool নির্ভর করে প্রেরক wallet-এর সক্ষমতার ওপর, শুধু দেখানো ঠিকানার ওপর নয়।

Revision 2 খসড়ায় শুধু shielded ঠিকানার জন্য zu এবং transparent receiver থাকতে পারে এমন format-এর জন্য tu prefix প্রস্তাব করা হয়েছে। সরকারি ZIP সূচি এখনো Revision 2-কে draft বলে; এগুলোকে প্রচলিত live Mainnet UA format হিসেবে দেখাবেন না। পাঠানোর আগে wallet-এর preview-তে address type, network ও নির্বাচিত receiver দেখুন।

Transparent থেকে shielded স্থানান্তর (t→z) প্রকাশ্য UTXO খরচ করে Sapling বা Orchard note তৈরি করতে পারে। Chain পর্যবেক্ষক transparent input, transparent pool-এর পরিবর্তন এবং shielded pool-এ ঢোকা নিট মূল্য দেখতে পারে। তবে সাধারণ shielded receiving address বা প্রতিটি note-এর পরিমাণ transparent UTXO-এর মতো পড়তে পারে না। Shielding করলেও pool boundary-র তথ্য থেকে যায়।

উল্টো স্থানান্তরে (z→t) transparent output-এর ঠিকানা ও পরিমাণ প্রকাশ্য হয়, এবং shielded pool-এর মূল্যে সংশ্লিষ্ট পরিবর্তনও দেখা যেতে পারে। একই pool-এ note তৈরি করা shielded payment গ্রহীতা ও পরিমাণ আড়াল করতে পারে; Sapling থেকে Orchard-এ স্থানান্তরে আলাদা pool-এর balance পরিবর্তন তথ্যবহ হতে পারে। শুধু প্রকাশ্য boundary value দিয়ে কোনো ব্যক্তি বা পুরোনো note শনাক্ত হয় না, তবে পরিমাণ, সময় ও বাইরের রেকর্ডের সঙ্গে মিলিয়ে দেখা যায়।

তাই শুধু ঠিকানাটি shielded কি না জিজ্ঞেস না করে, মূল্য কোথা থেকে এসেছে এবং কোন pool পার হয়েছে তাও দেখুন। Exchange থেকে উত্তোলন, দোকানে পেমেন্ট বা পরিচিত সময়/পরিমাণের ব্যক্তিগত স্থানান্তর প্রকাশ্য boundary তথ্যের সঙ্গে মেলানো যেতে পারে। এতে সব note-এর মালিক বা ভেতরের পথ প্রকাশ পায় না, তবে সম্ভাবনা কমে আসতে পারে।

ZIP 316 viewing key-কে ঠিকানায় আসা পেমেন্ট দেখতে প্রয়োজনীয় তথ্য হিসেবে সংজ্ঞায়িত করে। Full Viewing Key (FVK) ওই ঠিকানা থেকে যাওয়া পেমেন্টের তথ্যও দেখাতে পারে। FVK থেকে Incoming Viewing Key (IVK তৈরি করা যায়, আর IVK থেকে address পাওয়া যায়। Unified Viewing Key একাধিক protocol-এর viewing-key item একত্র করে।

শুধু viewing key দিয়ে খরচে স্বাক্ষর করা যায় না; আলাদা spending key বা signing ব্যবস্থা লাগে। তবু viewing key প্রকাশ্য বা নিরীহ তথ্য নয়। Key-এর ধরন ও wallet-এর বাস্তবায়ন ঠিক করে কোন transaction দেখা যাবে; account-level key একটি receiving address-এর চেয়ে বেশি কিছু প্রকাশ করতে পারে। Auditor বা service-কে দেওয়ার আগে scope, রাখার সময়, মুছে ফেলার উপায় এবং অন্য address-এর সঙ্গে যুক্ত হয়েছে কি না যাচাই করুন।

Viewing key আগে থেকেই প্রকাশ্য তথ্য মুছে দেয় না: transparent input/output, পরিমাণ ও সময় key ছাড়াও বিশ্লেষণ করা যায়। উল্টোভাবে, প্রয়োজনীয় support না থাকা explorer বা wallet chain-এ লেখা shielded transaction দেখাতে নাও পারে। “অ্যাপে দেখা যায় না” মানে “chain-এ নেই” নয়।

কী দেখা যায় তা pool ও receiver type-এর ওপর নির্ভর করে। পুরোপুরি transparent প্রবাহে address, পরিমাণ ও UTXO link দেখা যায়। Shielded payment note-এর recipient ও মূল্য এনক্রিপ্ট করলেও commitment, nullifier, সময় ও protocol তথ্য chain-এ থাকে। Pool boundary, wallet কোন pool সমর্থন করে, জানা payment time, exchange record ও ভাগ করা viewing key—প্রতিটি আলাদা সূত্র হতে পারে।

Unified Address প্রতিটি payment Orchard-এ পাঠাতে বাধ্য করে না। নির্বাচিত receiver wallet version, setting, implementation ও transaction path অনুযায়ী বদলাতে পারে। Address paste করে privacy ধরে না নিয়ে preview বা চূড়ান্ত transaction result দেখুন। [Monero privacy guide](/bn/learn/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained) ভিন্ন নকশা ব্যাখ্যা করে; [Bitcoin address reuse guide](/bn/learn/bitcoin-address-reuse-privacy-transaction-linkability-explained) স্বচ্ছ ledger-এর সঙ্গে তুলনা করে।

Network privacy আলাদা স্তর। RPC provider, light-wallet server, exchange বা payment service transaction তৈরির বা relay করার অনুরোধ দেখতে পারে এবং IP, account বা সময়ের তথ্য chain-এর বাইরে রাখতে পারে। Cryptographic proof নিজে থেকে service log মুছে দেয় না। সম্পূর্ণ anonymity দাবি না করে কে metadata পেয়েছে এবং কীভাবে রাখে তা জানুন।

প্রথমে নিশ্চিত হোন wallet প্রত্যাশিত Mainnet বা Testnet-এ আছে। Payment review-তে দেখুন প্রাপক Unified Address দিয়েছেন কি না এবং wallet কোন receiver বেছে নেবে। UA string দেখে receiver-এর ধরন বোঝা যায় না; wallet-এ pool, পরিমাণ, memo ও fee দেখুন। প্রাপক shielded payment চাইলেও preview transparent output দেখালে পাঠানোর আগে দুই wallet-এর protocol support পরীক্ষা করুন।

বিদ্যমান transaction যাচাই করতে transaction ID ও network মিলিয়ে input ও output-এ কোন pool আছে দেখুন। Transparent address ও পরিমাণ public explorer-এ দেখা যায়; shielded support নেই এমন tool note-এর তথ্য নাও দেখাতে পারে। Viewing key লাগলে কেন লাগছে এবং কী প্রকাশ করবে ঠিক করুন; অচেনা website-এ spending key বা viewing key paste করবেন না। Custodial ও non-custodial wallet guide signing-এর দায়িত্বও ব্যাখ্যা করে।

“Shielded address ব্যবহার করেছি, তাই payment পুরো ব্যক্তিগত” বা “explorer মূল্য দেখায় না, তাই transfer হয়নি”—এমন সিদ্ধান্তে যাবেন না। Wallet history, network, transaction ID, chain status, confirmation ও viewing authority আলাদা তথ্য। প্রাপককে receipt নিশ্চিত করতে হলে তার wallet সংশ্লিষ্ট pool support করে এবং sync হয়েছে কি না দেখুন।

ধরা যাক Lee একটি transparent UTXO থেকে 1.25 ZEC এমন Unified Address Revision 0-তে পাঠায় যাতে Orchard, Sapling ও transparent receiver আছে। অঙ্কটি শুধু উদাহরণ; এটি fee rate বা wallet default বোঝায় না। Lee-র wallet Orchard support করলে ZIP 316-এর অগ্রাধিকার Orchard receiver বেছে নেয়। Public chain transparent input ও shielded pool-এ যাওয়া নিট মূল্যের মতো boundary তথ্য দেখায়, কিন্তু গ্রহীতার shielded note address ও পরিমাণ সাধারণ public output হিসেবে দেখায় না।

Lee-র wallet Orchard support না করলেও Sapling করলে সেটি Sapling বেছে নিতে পারে। কোনো shielded pool support না করা wallet ঠিকানা ও payment format-এ transparent receiver থাকলে সেটি ব্যবহার করতে পারে। Revision 0 UA-তে shielded receiver থাকতে হবে, কিন্তু sender কেবল wallet-সমর্থিত receiver বেছে নেয়। ফলে একই UA ভিন্ন ক্ষমতার wallet-এ ভিন্ন pool ও public boundary তথ্য তৈরি করতে পারে।

শেষে, প্রাপক আলাদাভাবে কোনো accounting service-কে viewing key দিলে service key-এর scope-এ থাকা shielded activity দেখতে পারে। Wallet-এ receipt দেখা, explorer-এ note detail না দেখা এবং consensus অনুযায়ী chain-এ transaction লেখা—তিনটি আলাদা বিষয়। Unified Address protocol প্রজন্মের মধ্যে compatibility সহজ করে, কিন্তু সম্পূর্ণ privacy নিশ্চিত করে না; receiver নির্বাচন, key management বা network exposure-এর দায়িত্বও নেয় না।

• Спецификация протокола Zcash v2026.7.0 (NU6.2)
• ZIP 316: Unified Addresses и Unified Viewing Keys
• ZIP 211: запрет добавления новой стоимости в пул Sprout
• ZIP 257: NU6.2 и временная мера для Orchard
• ZIP 258: проект обновления NU6.3
• সরকারি ZIP সূচি: Mainnet অবস্থা ও প্রস্তাবের পর্যায়