একটি Safe Guard ইনস্টল করুন। আপনার মালিক, থ্রেশহোল্ড আর ইতিহাস ঠিক আগের মতোই থাকে — কিন্তু প্রতিটি ট্রান্সফারের জন্য একটি পোস্ট-কোয়ান্টাম অনুমোদনও লাগে, যা অন-চেইনে যাচাই করা হয়।
একজন মালিক আসল Safe{Wallet}-এ ট্রান্সফারে স্বাক্ষর করেন। এটি কার্যকর হবে না। কোয়ান্টাম অ্যাডমিনিস্ট্রেটর ডিভাইসে পেমেন্টটি পড়েন — টোকেন, পরিমাণ, প্রাপক, বৈধতার সময়সীমা, Safe ও চেইন — এবং একবার-ব্যবহারযোগ্য পোস্ট-কোয়ান্টাম স্বাক্ষর দিয়ে অনুমোদন করেন। তখনই কেবল টাকা সরে।
লোকাল ডেমো পরিবেশে শুরু থেকে শেষ পর্যন্ত রেকর্ড করা — একটি আসল Safe, আসল Safe{Wallet} এবং অন-চেইনে নিয়ম প্রয়োগকারী Guard। ডিভাইসটি সিমুলেটেড Ledger, হার্ডওয়্যার নয় — Ledger অ্যাপ কতদূর এগিয়েছে তা অবস্থা অংশে দেখুন।
পূর্ণ আকারে খুলুন · নিজে চালিয়ে দেখুন →
প্রত্যেক Safe মালিক ECDSA দিয়ে স্বাক্ষর করেন। যথেষ্ট বড় একটি কোয়ান্টাম কম্পিউটার ECDSA ভেঙে দেয় — আপনার সব স্বাক্ষরকারীর জন্য একসাথে। দশ বছর ধরে রাখা সম্পদের জন্য এমন স্বাক্ষর দরকার যা সেই দিনটি পেরিয়েও টিকে থাকে।
এটি ঠিক করে কে স্বাক্ষর করতে পারবে। স্বাক্ষর পদ্ধতিটাই ভেঙে গেলে এটি কিছু করতে পারে না।
কিন্তু একই কার্ভে জাল স্বাক্ষর ঠেকায় না — চাবিকে কখনো ডিভাইস ছেড়ে বেরোতেই হয় না।
যে পলিসি ইঞ্জিনের সাথে চেইন পরামর্শই করে না, তাকে এড়িয়ে যাওয়া যায়। শেষ কথাটা অন-চেইনে থাকতে হবে।
FermionGuard একটি Safe Guard — Safe-এর অফিসিয়াল প্রি-এক্সিকিউশন হুক। মালিকরা আজকের মতোই স্বাক্ষর করে যান। লেনদেনটির সাথে একটি মিলে যাওয়া পোস্ট-কোয়ান্টাম অনুমোদন থাকলেই কেবল Guard তাকে চলতে দেয়।
একই মালিক, একই থ্রেশহোল্ড, একই হার্ডওয়্যার ওয়ালেট। অসৎ অপারেটর, হারানো ডিভাইস আর অভ্যন্তরীণ ব্যর্থতা থেকে রক্ষা করে।
একজন নির্ধারিত কোয়ান্টাম অ্যাডমিনিস্ট্রেটর একটি Ledger-এ XMSS চাবি দিয়ে প্রতিটি ট্রান্সফার অনুমোদন করেন। আপসকৃত স্বাক্ষরকারী, পুনরায় ব্যবহৃত অনুমোদন, অ্যালাউন্স লুট — এবং ভবিষ্যতের কোয়ান্টাম আক্রমণ থেকে রক্ষা করে।
একজন অপারেটর Safe{Wallet}-এ একটি ট্রান্সফার সারিতে রাখেন। মালিকরা যথারীতি স্বাক্ষর করেন।
FermionGuard Safe App সেটিকে 🟡 কোয়ান্টাম অনুমতি প্রয়োজন হিসেবে চিহ্নিত করে।
অ্যাডমিনিস্ট্রেটর দুটি স্বাধীন উৎস থেকে ডিকোড করা বিবরণ পর্যালোচনা করেন।
Ledger প্রয়োগ করা প্রতিটি ফিল্ড দেখায়। অনুমোদন করতে চেপে ধরে রাখুন।
সারিটি 🟢 হয়ে যায়। যে কেউ এটি চালাতে পারে; Guard অনুমোদনটি যাচাই করে খরচ করে ফেলে।
অ্যাডমিনিস্ট্রেটর ঠিক কী অনুমোদন করছেন তা স্পষ্ট দেখেন
একটি অনুমোদনে Safe, চেইন, টোকেন, প্রাপক, পরিমাণ আর একটি বৈধতার সময়সীমা উল্লেখ থাকে। পরে কেউ সারির লেনদেনটি বদলালে অনুমোদনটি আর মেলে না এবং Guard সেটি প্রত্যাখ্যান করে।
অন্ধভাবে স্বাক্ষর নয় — Guard যে ফিল্ডগুলো প্রয়োগ করে, ডিভাইস তার প্রতিটি দেখায়
FermionGuard আসে Safe{Wallet}-এর ভেতরে একটি Safe App আর অ্যাডমিনিস্ট্রেটরের জন্য একটি Ledger অ্যাপ হিসেবে। ঝুঁকি-সংকেত কেউ স্বাক্ষর করার আগেই নতুন প্রাপক, অস্বাভাবিক পরিমাণ এবং যে লেনদেনগুলো Guard এমনিতেই প্রত্যাখ্যান করত সেগুলো তুলে ধরে।
বেতন দিচ্ছেন? সর্বোচ্চ ১০০টি ট্রান্সফারের পুরো একটি ব্যাচের জন্য একটিই অনুমোদন লাগে।
নতুন ওয়ালেট নয়, নতুন চেইন নয়, সম্পদ স্থানান্তরও নয়। চারটি ধাপ, যা আপনার বর্তমান মালিকরা সাধারণ Safe লেনদেনের মাধ্যমে সম্পন্ন করেন।
Safe{Wallet}-এ FermionGuard যোগ করুন। কিছু বদলানোর আগে এটি আপনার Safe-এর সংস্করণ ও মডিউল যাচাই করে।
অ্যাডমিনিস্ট্রেটরের চাবি Ledger-এর ভেতরেই তৈরি হয়। মালিকরা সেটি নিশ্চিত করেন এবং এর নিবন্ধনে একসাথে স্বাক্ষর করেন।
মালিকরা অন্য যেকোনো Safe লেনদেনের মতোই একটি setGuard লেনদেনে স্বাক্ষর করেন।
খুব সামান্য পরিমাণের একটি ট্রান্সফার পুরো প্রক্রিয়াটি পেরিয়ে যায়। সেটি সম্পন্ন হলে আপনার ড্যাশবোর্ডে দেখায় সুরক্ষিত ✓।
গ্রাহকের সম্পদ হেফাজতে একটি স্বাধীন, মান-ভিত্তিক ক্রিপ্টোগ্রাফিক নিয়ন্ত্রণ যোগ করুন।
আপনার অনুমোদন প্রক্রিয়া বজায় রাখুন, আর এমন ব্যবস্থা করুন যাতে একজন আপসকৃত স্বাক্ষরকারী একা তহবিল সরাতে না পারে।
সবচেয়ে গুরুত্বপূর্ণ পদক্ষেপগুলোতে — পরিচালনা-সংক্রান্ত পরিবর্তনে — একটি প্রকাশ্য, সময়-নির্ধারিত যাচাই বসান।
Guard হলো অন-চেইনে শেষ ভেটো — আর এমনভাবে নকশা করা যাতে হারানো চাবি বা কোনো বাগ কখনো আপনার তহবিল আটকে দিতে না পারে।
Ledger হারিয়েছেন? ১৪ দিনের প্রকাশ্য কাউন্টডাউনের পর মালিকরা নিজেরাই Guard সরাতে পারেন। নষ্ট ডিভাইস কখনো Safe লক করে না।
Guard সরাতে বা মালিক বদলাতে একটি অনুমোদন এবং ৪৮ ঘণ্টার একটি প্রকাশ্য কাউন্টডাউন লাগে, যার খবর প্রত্যেক মালিক পান।
আপগ্রেড-অযোগ্য Guard, ঘটনার সময় সবকিছু দ্রুত আটকানোর একটি বিরতি সহ। কোনো অ্যাডমিন ব্যাকডোর নেই।
Safe মডিউল guard-কে এড়িয়ে যায়, তাই নিবন্ধনের জন্য কোনো মডিউল চালু থাকা চলবে না — অথবা Safe 1.5+-এ একটি জোড়া module guard থাকতে হবে।
approve, permit আর transferFrom সরাসরি প্রত্যাখ্যাত হয়, এবং ব্যাচগুলো অন-চেইনে প্রতিটি অংশ ধরে যাচাই করা হয়।
মালিকরা নিজেদের ডিভাইসে চাবির সম্পূর্ণ পাবলিক রুটে একসাথে স্বাক্ষর করেন, তাই আপসকৃত কোনো ওয়েবসাইট অন্য চাবি বসিয়ে দিতে পারে না।
পরিচালনার পরিবর্তন ধীর ও প্রকাশ্য; বাতিল করা দ্রুত
অ্যাডমিনিস্ট্রেটরের Ledger হাতে পেলেও আক্রমণকারী আপনার মালিকদের স্বাক্ষর ছাড়া তহবিল সরাতে পারে না, এবং আপনার মালিকরা বাতিল করতে পারেন এমন ৪৮ ঘণ্টার প্রকাশ্য কাউন্টডাউন ছাড়া Guard সরাতেও পারে না।
XMSS পুরোপুরি হ্যাশিং-নির্ভর, তাই চেইন সরাসরি এটি যাচাই করে — কোনো ওরাকল নেই, কোনো বিশ্বস্ত সার্ভার নেই। যাচাইকারীটি RFC 8391-এর একটি স্বাধীনভাবে লেখা বাস্তবায়ন, আর এর প্রমাণ কতদূর যায় তা আমরা স্পষ্ট করে বলি: RFC-এর প্রতিটি মৌলিক উপাদান এবং ত্রুটিপূর্ণ ইনপুট প্রত্যাখ্যানকারী যাচাইগুলো, RFC-এর লাইন-বাই-লাইন প্রতিলিপির বিপরীতে সব ইনপুটের জন্য যন্ত্রে যাচাই করা। এগুলোকে সেই রুট তুলনায় জোড়া দেওয়া, যা শেষ পর্যন্ত একটি সঠিকভাবে গঠিত স্বাক্ষর গ্রহণ বা প্রত্যাখ্যান করে, হাতে-কলমে যুক্তি দিয়ে প্রতিষ্ঠিত, ট্রি উচ্চতা ২-এ প্রতীকীভাবে যাচাই করা এবং h = 4, 10 ও 20-এ RFC ভেক্টর দিয়ে নির্দিষ্ট করা।
XMSS অবস্থা-নির্ভর: একবার-ব্যবহারযোগ্য লিফ আবার ব্যবহার করলে আক্রমণকারী জাল স্বাক্ষর তৈরি করতে পারে। Ledger স্বাক্ষর দেওয়ার আগে তার কাউন্টার সংরক্ষণ করে, আর কন্ট্র্যাক্ট ব্যবহৃত লিফের একটি বিটম্যাপ রাখে যা যেকোনো পুনর্ব্যবহার বাতিল করে দেয়।
কন্ট্র্যাক্টগুলো দেখুন → · Guard স্পেসিফিকেশন → · আনুষ্ঠানিক প্রমাণ →
function _verifyAndConsumeXmss( bytes32 keyId, bytes32 digest, bytes calldata xmssSignature ) internal { XMSS.Signature memory sig = abi.decode(xmssSignature, (XMSS.Signature)); BitMaps.BitMap storage used = _usedLeaves[xmssRoot(keyId)]; // per KEY, not per registration if (used.get(sig.leafIdx)) revert LeafAlreadyUsed(keyId, sig.leafIdx); if (!XMSS.verify(digest, sig, publicKey(keyId), treeHeight(keyId))) revert InvalidXmssSignature(); // whole tx rolls back used.set(sig.leafIdx); // burn the one-time leaf emit LeafConsumed(keyId, sig.leafIdx, digest); }
নকশা আর পোস্ট-কোয়ান্টাম যাচাইকারী আজ সবার জন্য উন্মুক্ত। আগাম অ্যাক্সেস পাওয়া দলগুলো বাকিটা গড়তে সাহায্য করে।
স্ট্যান (কনস্তানতিন) ক্লাদকো — কোয়ান্টাম হুমকি সৃষ্টিকারী পদার্থবিদ্যা থেকে সেই হুমকি টিকে থাকার ক্রিপ্টোগ্রাফি পর্যন্ত।
ম্যাক্স প্ল্যাঙ্ক ইনস্টিটিউট থেকে পিএইচ.ডি.। স্ট্যানফোর্ডে নোবেলজয়ী রবার্ট বি. লাফলিনের সাথে কোয়ান্টাম সিস্টেম নিয়ে কাজ করেছেন। লস আলামোস ন্যাশনাল ল্যাবরেটরিতে Director's Fellow ছিলেন।
NIST-স্বীকৃত একটি ক্রিপ্টোগ্রাফিক-মডিউল পরীক্ষাগার (CMVP) পরিচালনা করেছেন, যা FIPS 140-2 ও সাইড-চ্যানেল নিরাপত্তা সনদ দিত।
SKALE-এর সহ-প্রতিষ্ঠাতা ও CTO, যিনি BLS থ্রেশহোল্ড ক্রিপ্টোগ্রাফিকে কাগজ থেকে Ethereum-সামঞ্জস্যপূর্ণ mainnet-এ নিয়ে গেছেন।
না। আপনি আপনার বিদ্যমান Safe-এ একটি Guard ইনস্টল করেন। মালিক, থ্রেশহোল্ড, ইতিহাস আর ঠিকানা ঠিক আগের মতোই থাকে।
কোয়ান্টাম চাবি ছাড়াই, ১৪ দিনের প্রকাশ্য কাউন্টডাউনের পর, আপনার মালিকরা নিজেরাই Guard সরাতে পারেন। অনুরোধটি বৈধ না হলে মালিকরা সেই সময়ের মধ্যে যেকোনো মুহূর্তে একটি সাধারণ Safe লেনদেন দিয়ে তা বাতিল করতে পারেন। হারানো ডিভাইস কখনো আপনার Safe চিরতরে লক করতে পারে না।
প্রতিটি ট্রান্সফারে Ledger-এ অ্যাডমিনিস্ট্রেটরের একটি অতিরিক্ত অনুমোদন লাগে। ব্যাচ — যেমন সর্বোচ্চ ১০০টি ট্রান্সফারের বেতন প্রদান — পুরো ব্যাচের জন্য মাত্র একটি অনুমোদন চায়।
পোস্ট-কোয়ান্টাম স্বাক্ষর যাচাইয়ে প্রায় ৭,৪৫,০০০ গ্যাস লাগে, যা অনুমোদন তৈরির সময় একবারই দেওয়া হয় (h = 20-এ মাপা ৭,৪৫,০০৩ গ্যাস)। লেনদেন কার্যকরের সময়ের যাচাইটি কেবল একটি খোঁজ।
Safe v1.3.0 ও তার পরের সংস্করণ। Safe-এ কোনো মডিউল চালু থাকা চলবে না, কারণ মডিউল guard-কে এড়িয়ে যায় — অথবা সেটি Safe 1.5+-এ থাকতে হবে এবং সাথে FermionGuard-এর module guard-ও ইনস্টল থাকতে হবে। এতে fallback handler-ও থাকা চলবে না: ERC-20 টোকেন ও ETH স্বাভাবিকভাবে কাজ করে, কিন্তু স্বাক্ষরিত-বার্তার সুবিধা (Permit, CowSwap অর্ডার, সাইন-ইন) এবং safeTransferFrom দিয়ে NFT গ্রহণ এখনো সমর্থিত নয়।
XMSS একটি NIST-অনুমোদিত (SP 800-208) হ্যাশ-ভিত্তিক স্বাক্ষর, তাই EVM প্রায় 1M গ্যাসে এটি যাচাই করতে পারে। ML-DSA ও Falcon-এর মতো ল্যাটিস পদ্ধতি আজ অন-চেইনে যাচাই করতে কোটি কোটি গ্যাস লাগত।
এখনো নয়। পোস্ট-কোয়ান্টাম যাচাইকারীটি উপরে বর্ণিত সীমা পর্যন্ত RFC 8391-এর বিপরীতে যন্ত্রে যাচাই করা, আর Guard কন্ট্র্যাক্টগুলো বাস্তবায়িত ও পরীক্ষিত, কিন্তু এখনো কিছুই অডিট করা হয়নি; Ledger অ্যাপ ও Safe App উন্নয়নাধীন, এবং যেকোনো mainnet ডিপ্লয়মেন্টের আগে বহিরাগত অডিট আবশ্যক। প্রথম দলগুলোর একটি হতে আগাম অ্যাক্সেসের অনুরোধ করুন।
আমরা Safe-এ সম্পদ রাখা দলগুলোর প্রথম একটি দলকে যুক্ত করছি। আপনার সেটআপ সম্পর্কে আমাদের জানান, পাইলট শুরু হলেই আমরা যোগাযোগ করব।
একটি ছোট, প্রকাশ্য GitHub ফর্ম খোলে — অনুগ্রহ করে গোপনীয় কিছু লিখবেন না।