সিগন্যাল

প্রতিটি ওয়াচ ধরনের এক বা একাধিক সিগন্যাল আছে। একটি সিগন্যাল একটি শর্ত পরীক্ষা করে, যেমন একটি অনুপস্থিত FTSO কমিট বা আপনার সীমার নিচে নেমে যাওয়া ক্রেডিট ব্যালেন্স। ওয়াচ এডিটরের ৩. সংকেত অংশে আপনি প্রতিটি সিগন্যাল চালু বা বন্ধ করতে, তার পুনরুদ্ধার বার্তা চালু বা বন্ধ করতে এবং তার প্যারামিটার বদলাতে পারেন। ডিফল্টে রিসেট করুন স্ট্যান্ডার্ড মানগুলো ফিরিয়ে আনে।

সিগন্যালগুলো FTSO, FDC বা ব্যালান্স-এর মতো সিগন্যাল গ্রুপের অন্তর্ভুক্ত। রাউটিংয়ের জন্য গ্রুপ গুরুত্বপূর্ণ, কারণ আপনি একটি গ্রুপকে বাকিদের চেয়ে ভিন্ন প্রাপকের কাছে পাঠাতে পারেন; দেখুন প্রাপক ও রাউটিং।

নিচের রেফারেন্সে প্রতিটি সিগন্যাল চারটি প্রশ্নের উত্তর দেয়: কী পরীক্ষা করা হয়, কেন এটি গুরুত্বপূর্ণ, সাধারণ কারণ, এবং আপনি কী করতে পারেন। অ্যাপে কোনো সিগন্যালের পাশের তথ্য আইকনে ক্লিক করলে একই লেখা দেখা যায়।

প্রায় প্রতিটি সিগন্যাল ডিফল্টভাবে চালু থাকে এবং পুনরুদ্ধার বার্তা পাঠায়। ব্যতিক্রমগুলো নিচের রেফারেন্সে চিহ্নিত আছে। প্রোভাইডার ওয়াচের পর্যবেক্ষণের প্রাপ্যতা সিগন্যালটি সবসময় চালু থাকে এবং বন্ধ করা যায় না, কারণ পর্যবেক্ষণ নিজেই কখন সম্ভব নয় তা এটি আপনাকে জানায়।

কিছু প্রোভাইডার সিগন্যালে পরপর রাউন্ড প্যারামিটার আছে। এটি একটি মাত্র দেরিতে আসা বা অনুপস্থিত জমা যেন রাতে আপনার ঘুম না ভাঙায় তা নিশ্চিত করে। ডিফল্ট ২।

ডিফল্ট ২ সহ উদাহরণ:

• রাউন্ড 1000: কমিট অনুপস্থিত। পরপর প্রথম রাউন্ড, এখনও কোনো অ্যালার্ট নেই।
• রাউন্ড 1001: কমিট আবার অনুপস্থিত। পরপর দ্বিতীয় রাউন্ড, অ্যালার্ট।
• রাউন্ড 1002: কমিট সময়মতো আসে। পুনরুদ্ধার বার্তা, যদি সেটি চালু থাকে।

রাউন্ড 1001 ঠিক থাকলে কিছুই পাঠানো হতো না। একটি অ্যালার্ট সক্রিয় থাকাকালীন আরও খারাপ রাউন্ড সেটি আবার পাঠায় না; আপনি প্রতি সমস্যায় একটি অ্যালার্ট পান, প্রতি রাউন্ডে একটি নয়। প্রতিটি একক মিস সম্পর্কে জানতে চাইলে মানটি ১ করুন।

পুনরুদ্ধার বার্তা আপনাকে জানায় যে অবস্থা আবার স্বাভাবিক হয়েছে। এটি অ্যালার্টের একই প্রাপকদের কাছে যায়। আপনি যদি শুধু সমস্যার খবর চান, প্রতিটি সিগন্যালের জন্য এটি বন্ধ করুন।

কুলডাউন হলো প্রতি ওয়াচের একটি সেটিং, যার নাম অ্যালার্টের মধ্যে ন্যূনতম ব্যবধান। এটি ওই সময়ের মধ্যে একই ঘটনার পুনরাবৃত্তি আটকায়, কিন্তু পুনরুদ্ধার বার্তার মতো ভিন্ন কোনো ঘটনা কখনো আটকায় না। এটি বিস্তারিতভাবে কীভাবে কাজ করে তা বার্তা ও নীরব সময় পাতায় আছে।

Watchdog কোনো মান পড়তে না পারলে, যেমন কোনো ডেটা উৎস দেরি করায়, সেটিকে সুস্থ অবস্থা বলে ধরে না। প্রমাণ ছাড়া একটি রাউন্ড খারাপ রাউন্ডের ধারাবাহিকতা ভাঙে, কিন্তু কখনো পুনরুদ্ধার বার্তা ট্রিগার করে না। প্রোভাইডার ওয়াচের ক্ষেত্রে, অ্যানালাইজারের ডেটা ১০ মিনিটের বেশি পুরোনো হলে পর্যবেক্ষণের প্রাপ্যতা সিগন্যাল আপনাকে জানায়; যতক্ষণ এমন থাকে, ওই ওয়াচের অন্যান্য প্রোভাইডার অ্যালার্ট অনুমান করার বদলে বিরতিতে থাকে।

1. আপনার ওয়াচগুলি খুলুন এবং ওয়াচটিতে সম্পাদনা বেছে নিন।
2. ৩. সংকেত অংশ খুলুন এবং যে গ্রুপটি বদলাতে চান সেটি প্রসারিত করুন।
3. সিগন্যাল বা তার পুনরুদ্ধার বার্তা চালু বা বন্ধ করুন, অথবা একটি প্যারামিটার বদলান। কোনো মান অনুমোদিত সীমার বাইরে থাকলে অংশটিতে “এই বিভাগের মানগুলো পরীক্ষা করুন।” দেখায়, এবং আপনি ঠিক না করা পর্যন্ত সংরক্ষণ বন্ধ থাকে।
4. সংরক্ষণ করুন। পরিবর্তনটি পরের পরীক্ষা থেকে কার্যকর হয়।

নির্বাচিত watch target ও threshold-এর ঘটনা।

ব্যালেন্স পরিবর্তন

কনফিগার করা ওয়ালেট ব্যালেন্সের পরিবর্তন সীমা অতিক্রম করলে জানায়।

• কী পরীক্ষা করা হয়? আগের observation-এর সঙ্গে balance তুলনা করে নির্দিষ্ট direction-এ threshold ছুঁলে alert দেয়। প্রথম observation baseline।
• কেন এটি গুরুত্বপূর্ণ? Balance change পর্যবেক্ষণযোগ্য incoming বা outgoing transfer বোঝাতে পারে।
• সাধারণ কারণ: Observation-এর মাঝে transfer, gas fee বা অন্য balance change হয়েছে।
• কী করণীয়? Observed পরিমাণ recent wallet transaction ও configured token-এর সঙ্গে মিলিয়ে দেখুন।
• সিগন্যাল সক্রিয়: চালু

নির্বাচিত watch target ও threshold-এর ঘটনা।

মূল্য পরিবর্তন

কনফিগার করা ফিডের পরিবর্তন সীমা অতিক্রম করলে জানায়।

• কী পরীক্ষা করা হয়? window-এর প্রাচীনতম valid point-এর সঙ্গে USD price তুলনা করে। threshold-এ window-পিছু একবার alert; দ্বিগুণ হলে critical।
• কেন এটি গুরুত্বপূর্ণ? বড় observed price move মনোযোগ দাবি করতে পারে।
• সাধারণ কারণ: বর্তমান feed price নির্বাচিত window-এর আগের valid price থেকে আলাদা।
• কী করণীয়? সময় ও price তুলনা করে window ও percentage দেখুন।
• সিগন্যাল সক্রিয়: চালু

নির্বাচিত watch target ও threshold-এর ঘটনা।

প্রোভাইডার অবস্থা

প্রোভাইডারের নিবন্ধন বাতিল হলে বা যোগ্যতা হারালে জানায়।

• কী পরীক্ষা করা হয়? baseline-এর পরে registration/eligibility হারানো বা ফিরে আসা জানায়। dataset-এ provider না থাকলে unregistered ও ineligible ধরে।
• কেন এটি গুরুত্বপূর্ণ? অনিবন্ধিত বা অযোগ্য প্রোভাইডার ওই রিওয়ার্ড এপকে তার ডেলিগেটরদের জন্য কোনো পুরস্কার অর্জন করে না।
• সাধারণ কারণ: নিবন্ধন মিস হয়েছে, বা কোনো pass অবশিষ্ট না থাকা অবস্থায় একটি Minimal Condition পূরণ হয়নি।
• কী করণীয়? Flare Systems Explorer-এ প্রোভাইডারের Minimal Conditions ও passes এবং বর্তমান এপকের নিবন্ধন দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু

নির্বাচিত watch target ও threshold-এর ঘটনা।

কম ক্রেডিট ব্যালেন্স

আপনার ক্রেডিট ব্যালেন্স কনফিগার করা সীমার নিচে নামলে জানায়।

• কী পরীক্ষা করা হয়? wallet credit balance সীমার নিচে গেলে alert; সীমার সমান হলেও recovery।
• কেন এটি গুরুত্বপূর্ণ? কম credit balance credit-ব্যবহারকারী পরিষেবায় প্রভাব ফেলতে পারে।
• সাধারণ কারণ: Credit খরচ বা adjustment-এ balance নির্বাচিত সীমার নিচে গেছে।
• কী করণীয়? Credit balance ও সাম্প্রতিক entry দেখে প্রয়োজনে সীমা বদলান বা পূরণ করুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু

নির্বাচিত watch target ও threshold-এর ঘটনা।

রিওয়ার্ড স্বাক্ষর

খোলা, বিলম্বিত বা মিস হওয়া আপটাইম ও রিওয়ার্ড স্বাক্ষরের বিষয়ে জানায়।

• কী পরীক্ষা করা হয়? শেষ epoch-এর uptime ও reward signature দেখে। epoch শেষ বা প্রথম দেখা প্রকাশের দুই ঘণ্টা পরে alert; বারো ঘণ্টা পরে reminder, unsigned concluded vote critical।
• কেন এটি গুরুত্বপূর্ণ? প্রয়োজনীয় provider signature বাকি বা vote শেষের আগে মিস হয়েছে।
• সাধারণ কারণ: Uptime বা reward data-এর observed signer set-এ identity নেই।
• কী করণীয়? Configured identity-এর epoch, vote state ও signing process দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু

FTSO voting round-এ commit, reveal ও signature অংশগ্রহণ।

FTSO কমিট

পরপর রাউন্ডে কমিট অনুপস্থিত বা দেরিতে এসেছে।

• কী পরীক্ষা করা হয়? পরপর voting round-এ অনুপস্থিত বা দেরি হওয়া FTSO commit পরীক্ষা করে।
• কেন এটি গুরুত্বপূর্ণ? বৈধ commit ছাড়া আপনার মান ওই ভোটিং রাউন্ডে গণনা হয় না, তাই মিডিয়ানের কাছাকাছি থাকার পুরস্কার হারান। বাদ পড়া রাউন্ড anchor-feed Minimal Condition পূরণেও বাধা দেয় (প্রতি রিওয়ার্ড এপকের ৮০% রাউন্ডে মিডিয়ানের ০.৫% এর মধ্যে থাকা)।
• সাধারণ কারণ: FTSO ক্লায়েন্ট বা Flare System Client বন্ধ বা রিস্টার্ট হচ্ছে, C-chain ইনডেক্সার চেইনের সর্বশেষ ব্লক থেকে পিছিয়ে, RPC সমস্যা আছে, বা submit ঠিকানায় নেটিভ ব্যালান্স কম।
• কী করণীয়? দেখুন সিস্টেম ক্লায়েন্ট প্রতি রাউন্ডে “Submitter submit1 successfully sent tx” লগ করছে কি না, ইনডেক্সার সর্বশেষ ব্লক পর্যন্ত এসেছে কি না এবং submit ঠিকানায় অর্থ আছে কি না।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু
• পরপর রাউন্ড: ডিফল্ট ২ (১–২০)। পরপর খারাপ voting round-এর সংখ্যা; ২ হলে একক ব্যর্থতা বাদ। তথ্য না থাকলে streak reset হয়, recovery প্রমাণ হয় না।

FTSO রিভিল

পরপর রাউন্ডে রিভিল অনুপস্থিত, আগে বা দেরিতে এসেছে।

• কী পরীক্ষা করা হয়? পরপর voting round-এ অনুপস্থিত, আগাম বা দেরি হওয়া FTSO reveal পরীক্ষা করে।
• কেন এটি গুরুত্বপূর্ণ? মিল থাকা reveal ছাড়া commit-এর জন্য জরিমানা হয়: আপনার মান বাদ যায় এবং রাউন্ডের পুরস্কার কমে বা হারিয়ে যায়। reveal না থাকলে আপনার র‌্যান্ডম সংখ্যাও রাউন্ড থেকে বাদ যায়।
• সাধারণ কারণ: ক্লায়েন্ট commit ও reveal-এর মাঝে রিস্টার্ট হয়েছে, reveal (submit2) দেরিতে পাঠানো হয়েছে, বা submit ঠিকানার অর্থ শেষ হয়েছে।
• কী করণীয়? উল্লিখিত রাউন্ডগুলির submit2 লেনদেন, লগে commit ও reveal-এর সময়ের ব্যবধান এবং মাঝে ক্লায়েন্ট রিস্টার্ট হয়েছিল কি না দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু
• পরপর রাউন্ড: ডিফল্ট ২ (১–২০)। পরপর খারাপ voting round-এর সংখ্যা; ২ হলে একক ব্যর্থতা বাদ। তথ্য না থাকলে streak reset হয়, recovery প্রমাণ হয় না।

FTSO স্বাক্ষর

পরপর রাউন্ডে স্বাক্ষর অনুপস্থিত বা আগে এসেছে।

• কী পরীক্ষা করা হয়? পরপর round-এ অনুপস্থিত বা আগাম FTSO signature দেখে; grace period মিস আলাদা সংকেত।
• কেন এটি গুরুত্বপূর্ণ? শুধু চূড়ান্ত হওয়া Merkle root-এর ওপর সময়মতো আসা স্বাক্ষরই স্বাক্ষর পুরস্কার পায়। স্বাক্ষর না থাকলে ওই অংশ হারান এবং রাউন্ড চূড়ান্ত করতেও সহায়তা হয় না।
• সাধারণ কারণ: স্বাক্ষর ধাপ (submitSignatures) ব্যর্থ বা দেরি হয়েছে, Merkle root গণনা করা যায়নি, বা স্বাক্ষর জমার ঠিকানায় অর্থ কম।
• কী করণীয়? সিস্টেম ক্লায়েন্টের লগে “Submitter submitSignatures successfully sent tx” খুঁজুন এবং স্বাক্ষর জমার ঠিকানার ব্যালান্স দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু
• পরপর রাউন্ড: ডিফল্ট ২ (১–২০)। পরপর খারাপ voting round-এর সংখ্যা; ২ হলে একক ব্যর্থতা বাদ। তথ্য না থাকলে streak reset হয়, recovery প্রমাণ হয় না।

FDC bitvote, signature ও consensus request-এর সঙ্গে মিল।

FDC বিটভোট

পরপর রাউন্ডে বিটভোট অনুপস্থিত, আগে বা দেরিতে এসেছে।

• কী পরীক্ষা করা হয়? পরপর voting round-এ অনুপস্থিত, আগাম বা দেরি হওয়া FDC bitvote পরীক্ষা করে।
• কেন এটি গুরুত্বপূর্ণ? সময়মতো bitvote ছাড়া আপনি ওই রাউন্ডের FDC কনসেনসাসে অংশ নেন না। FDC Minimal Condition অনুযায়ী প্রতি রিওয়ার্ড এপকের ৬০% ভোটিং রাউন্ডে সফল অংশগ্রহণ প্রয়োজন।
• সাধারণ কারণ: FDC ক্লায়েন্ট বা verifier অনুপলব্ধ, attestation উৎস (যেমন BTC, DOGE বা XRP নোড) সিঙ্ক হয়নি, বা bitvote নির্বাচন ধাপের বাইরে পাঠানো হয়েছে (রাউন্ড শুরুর ৯০–১৩৫ সেকেন্ডে নির্বাচন ধাপ)।
• কী করণীয়? FDC ক্লায়েন্টের লগ, প্রতিটি verifier-এর /health এন্ডপয়েন্ট এবং bitvote লেনদেন নির্বাচন ধাপের মধ্যে পৌঁছাচ্ছে কি না দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু
• পরপর রাউন্ড: ডিফল্ট ২ (১–২০)। পরপর খারাপ voting round-এর সংখ্যা; ২ হলে একক ব্যর্থতা বাদ। তথ্য না থাকলে streak reset হয়, recovery প্রমাণ হয় না।

FDC স্বাক্ষর

পরপর রাউন্ডে স্বাক্ষর অনুপস্থিত বা আগে এসেছে।

• কী পরীক্ষা করা হয়? পরপর voting round-এ অনুপস্থিত বা আগাম FDC signature পরীক্ষা করে।
• কেন এটি গুরুত্বপূর্ণ? সঠিক Merkle root জমা দিলেই FDC অংশগ্রহণ গণনা হয়। আপনার স্বাক্ষর ছাড়া রাউন্ডটি ৬০% শর্তে গণনা হয় না এবং তার স্বাক্ষর পুরস্কার হারান।
• সাধারণ কারণ: FDC Merkle root তৈরি বা স্বাক্ষর করা যায়নি, verifier-এর ডেটা অসম্পূর্ণ ছিল, বা স্বাক্ষর জমার ঠিকানায় অর্থ কম।
• কী করণীয়? FDC ক্লায়েন্ট ও verifier-এর স্বাস্থ্য এবং উল্লিখিত রাউন্ডগুলির submitSignatures লেনদেন দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু
• পরপর রাউন্ড: ডিফল্ট ২ (১–২০)। পরপর খারাপ voting round-এর সংখ্যা; ২ হলে একক ব্যর্থতা বাদ। তথ্য না থাকলে streak reset হয়, recovery প্রমাণ হয় না।

অপ্রত্যাশিত FDC submit1

একটি FDC submit1 দেখা গেছে।

• কী পরীক্ষা করা হয়? জমার তথ্য পাওয়া গেলে পর্যবেক্ষিত FDC submit1 জানায়।
• কেন এটি গুরুত্বপূর্ণ? FDC-এর জন্য এই submission phase অপ্রত্যাশিত; configuration দেখুন।
• সাধারণ কারণ: Submitter ভুল protocol বা submission method ব্যবহার করতে পারে।
• কী করণীয়? Reported transaction ও submitter protocol configuration দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু

অনিশ্চিত সম্মতি অনুরোধ

পরপর রাউন্ডে অনিশ্চিত সম্মতি অনুরোধের জন্য একটি সমন্বিত সতর্কতা।

• কী পরীক্ষা করা হয়? পরপর voting round-এ অন্তত একটি unconfirmed consensus request থাকলে একত্রে alert দেয়।
• কেন এটি গুরুত্বপূর্ণ? কনসেনসাস নিশ্চিত করেছে কিন্তু আপনি করেননি এমন অনুরোধ সাধারণত বোঝায় আপনার verifier সেগুলি যাচাই করতে পারেনি। ওই ডেটা ছাড়া প্রায়ই আপনি কনসেনসাসের Merkle root তৈরি ও স্বাক্ষর করতে পারেন না, এবং রাউন্ডটি আপনার জন্য গণনা হয় না।
• সাধারণ কারণ: কোনো চেইনের verifier বন্ধ বা পিছিয়ে আছে, বা তার ডেটার উৎস (যেমন BTC, DOGE বা XRP নোড) সিঙ্ক হয়নি।
• কী করণীয়? অনিশ্চিত অনুরোধগুলি কোন চেইন বা attestation ধরনের তা বের করুন এবং সংশ্লিষ্ট verifier-এর স্বাস্থ্য ও সিঙ্ক অবস্থা দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু
• পরপর রাউন্ড: ডিফল্ট ২ (১–২০)। পরপর খারাপ voting round-এর সংখ্যা; ২ হলে একক ব্যর্থতা বাদ। তথ্য না থাকলে streak reset হয়, recovery প্রমাণ হয় না।

FDC বিটভোটের দৈর্ঘ্য

বিটভোটের দৈর্ঘ্য যাচাইকৃত অনন্য অনুরোধের সংখ্যার সঙ্গে মেলে না।

• কী পরীক্ষা করা হয়? FDC bitvote-এর দৈর্ঘ্য যাচাইকৃত unique request সংখ্যার সঙ্গে মেলে কি না দেখে।
• কেন এটি গুরুত্বপূর্ণ? ভুল দৈর্ঘ্যের bitvote রাউন্ডের অনুরোধগুলির সঙ্গে মেলানো যায় না, তাই তা কনসেনসাস বা আপনার FDC অংশগ্রহণ কোনোটিতেই গণনা হয় না।
• সাধারণ কারণ: FDC ক্লায়েন্ট চেইনের থেকে আলাদা অনুরোধ দেখেছে, যেমন ইনডেক্সারের বিলম্ব বা আপগ্রেডের পরে ক্লায়েন্ট সংস্করণের সমস্যার কারণে।
• কী করণীয়? C-chain ইনডেক্সার সর্বশেষ ব্লক পর্যন্ত এসেছে কি না এবং FDC ক্লায়েন্ট বর্তমান সংস্করণে চলছে কি না দেখুন, তারপর লগে অনুরোধের সংখ্যা তুলনা করুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু

reveal অমিল, ভুল signer বা signature grace period মিসের প্রমাণ।

রিভিল লঙ্ঘন

কমিট ও রিভিল মেলে না; তাৎক্ষণিক গুরুতর সতর্কতা।

• কী পরীক্ষা করা হয়? যাচাইকৃত FTSO commit/reveal অমিল সঙ্গে সঙ্গে critical alert দেয়।
• কেন এটি গুরুত্বপূর্ণ? নিজের commit-এর সঙ্গে না মেলা reveal-এর জন্য জরিমানা হয়: রাউন্ডের পুরস্কার কমে বা হারিয়ে যায়, এবং জরিমানা কোনো এপকের রিওয়ার্ড ক্লেম ঋণাত্মক করতে পারে।
• সাধারণ কারণ: commit ও reveal আলাদা ডেটা থেকে তৈরি হয়েছে, সাধারণত রিস্টার্টের পরে, অথবা দুটি চালু ইনস্ট্যান্স একই ঠিকানা দিয়ে জমা দিচ্ছে।
• কী করণীয়? নিশ্চিত করুন আপনার ঠিকানাগুলির জন্য ঠিক একটি ক্লায়েন্ট জমা দিচ্ছে এবং উল্লিখিত রাউন্ডের আশপাশের লগ দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু

ভুল স্বাক্ষরকারী

স্বাক্ষর signing policy ঠিকানার সঙ্গে মেলে না।

• কী পরীক্ষা করা হয়? FTSO বা FDC signature-এর signer signing policy address-এর সঙ্গে অমিল কি না দেখে।
• কেন এটি গুরুত্বপূর্ণ? ভুল কী দিয়ে করা স্বাক্ষর আপনার ওজনে গণনা হয় না। আপনি স্বাক্ষর পুরস্কার হারান এবং এটি রাউন্ড চূড়ান্ত করতেও সাহায্য করে না।
• সাধারণ কারণ: ক্লায়েন্ট এমন কী দিয়ে স্বাক্ষর করছে যা আপনার entity-র নিবন্ধিত signing policy ঠিকানার সঙ্গে মেলে না, যেমন কী বদলের পরে বা কনফিগারেশনে ভুল কী থাকলে।
• কী করণীয়? উল্লিখিত লেনদেনের স্বাক্ষরকারীকে আপনার identity-র নিবন্ধিত signing policy ঠিকানার সঙ্গে তুলনা করুন এবং কনফিগার করা স্বাক্ষর কী ঠিক করুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু

স্বাক্ষরের সময়সীমা পেরিয়েছে

স্বাক্ষর পুরস্কারের সময়সীমা পেরিয়েছে।

• কী পরীক্ষা করা হয়? FTSO বা FDC signature reward grace period মিস করেছে কি না দেখে।
• কেন এটি গুরুত্বপূর্ণ? স্বাক্ষর শুরু হওয়ার পর ১০ সেকেন্ডের ছাড়ের সময়ে আসা স্বাক্ষর সবসময় পুরস্কার পায়। পরেরগুলি কেবল চূড়ান্তকরণের আগে পৌঁছালে গণনা হয়, আর চূড়ান্তকরণ সাধারণত দ্রুত হয়।
• সাধারণ কারণ: ধীর RPC বা ইনডেক্সার, ব্যস্ত হোস্ট, বা স্বাক্ষর জমার ঠিকানায় সারিবদ্ধ লেনদেন।
• কী করণীয়? লগে স্বাক্ষর শুরুর সময় ও আপনার স্বাক্ষর লেনদেন তুলনা করুন এবং RPC সাড়ার সময় ও হোস্টের লোড দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু

FDC প্রকাশ লঙ্ঘন

বিটভোটে সম্মতি রয়েছে কিন্তু বৈধ স্বাক্ষর নেই।

• কী পরীক্ষা করা হয়? analyzer-এর FDC reveal offence জানায়: bitvote consensus কভার করে, কিন্তু valid signature নেই।
• কেন এটি গুরুত্বপূর্ণ? আপনার bitvote কনসেনসাসকে কভার করলে আপনাকে তৈরি হওয়া Merkle root-এ স্বাক্ষর করতে হয়। অ্যানালাইজার বৈধ স্বাক্ষর না থাকাকে FDC লঙ্ঘন হিসেবে দেখে, এবং জরিমানা আপনার এপকের পুরস্কার কমাতে পারে।
• সাধারণ কারণ: bitvote-এর পরে FDC স্বাক্ষর ধাপ ব্যর্থ হয়েছে, প্রায়ই verifier-এর উত্তর না থাকায় Merkle ট্রি তৈরি করা যায়নি।
• কী করণীয়? উল্লিখিত রাউন্ডের জন্য FDC ক্লায়েন্ট ও verifier-এর স্বাস্থ্য এবং submitSignatures লেনদেন দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু

পর্যবেক্ষিত submission phase-এ ব্যর্থ transaction।

ব্যর্থ লেনদেন

জমা দেওয়ার একটি ধাপ ব্যর্থ হয়েছে।

• কী পরীক্ষা করা হয়? পর্যবেক্ষিত পাঁচটি submission phase-এর একটিতে ব্যর্থ transaction জানায়।
• কেন এটি গুরুত্বপূর্ণ? রিভার্ট হওয়া submission-এ gas খরচ হয় কিন্তু ডেটা নথিভুক্ত হয় না, তাই রাউন্ডে ওই ধাপটি বাদ পড়েছে বলে গণনা হয়।
• সাধারণ কারণ: একই ঠিকানায় দুটি ক্লায়েন্টের nonce সংঘাত, কম gas, বর্তমান এপকে অনিবন্ধিত প্রেরক ঠিকানা, বা প্রোটোকল আপগ্রেডের পরে contract revert।
• কী করণীয়? উল্লিখিত লেনদেন এক্সপ্লোরারে খুলুন, revert-এর কারণ পড়ুন এবং নিশ্চিত করুন প্রতিটি submit ঠিকানা শুধু একটি ক্লায়েন্ট ব্যবহার করছে।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু

signing weight ও অতিবাহিত block-এর তুলনায় Fast Updates activity।

Fast Updates নিষ্ক্রিয়তা

নিষ্ক্রিয়তা পরিসংখ্যানগতভাবে অসম্ভাব্য হলে সতর্কতা। ব্লক-সংখ্যার সতর্কতা ডিফল্টভাবে বন্ধ।

• কী পরীক্ষা করা হয়? signing weight ও অতিবাহিত block দিয়ে Fast Updates না হওয়ার মডেল সম্ভাবনা সীমার সঙ্গে তুলনা করে। ঐচ্ছিক সতর্কতা epoch-এর ১% block ব্যবহার করে।
• কেন এটি গুরুত্বপূর্ণ? Fast Updates (ব্লক-ল্যাটেন্সির feeds) Minimal Conditions-এর অংশ: প্রতি রিওয়ার্ড এপকে প্রত্যাশিত আপডেটের অন্তত ৮০% জমা দিতে হবে, যদি না আপনার ওজন মোটের ০.২% এর কম হয়।
• সাধারণ কারণ: Fast Updates ক্লায়েন্ট বন্ধ হয়েছে, তার অ্যাকাউন্টগুলিতে gas-এর অর্থ শেষ (“insufficient funds”), বা sortition কী নিবন্ধিত নয়।
• কী করণীয়? Fast Updates ক্লায়েন্টের লগ এবং সব Fast Updates অ্যাকাউন্টের ব্যালান্স দেখুন। ওজন কম হলে নির্বাচনের মধ্যে দীর্ঘ বিরতি স্বাভাবিক।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু
• সম্ভাবনার সীমা: ডিফল্ট ১E-৭ (১E-১৫–০.১)। ছোট probability threshold-এ Fast Updates নিষ্ক্রিয়তার শক্তিশালী পরিসংখ্যান দরকার।
• ব্লক-সংখ্যার সতর্কতা চালু করুন: ডিফল্ট বন্ধ। update ছাড়া block epoch-এর ১% হলে অতিরিক্ত সতর্ক; ডিফল্টে বন্ধ।

পরবর্তী epoch-এর registration ও active signing policy membership।

পরবর্তী এপকে নিবন্ধন

নির্ধারিত সময়ের পরও নিবন্ধন বাকি থাকলে একবার সতর্কতা।

• কী পরীক্ষা করা হয়? registration খোলার পর নির্ধারিত সময়েও পরবর্তী reward epoch-এর নিবন্ধন অনুপস্থিত কি না দেখে।
• কেন এটি গুরুত্বপূর্ণ? কোনো রিওয়ার্ড এপকের নিবন্ধন মিস করলে সেই পুরো এপকে অংশগ্রহণ ও FSP পুরস্কার কোনোটিই থাকে না, এবং আপনার passes শূন্য হয়।
• সাধারণ কারণ: সিস্টেম ক্লায়েন্ট ৩০ মিনিটের নিবন্ধন সময়ে চলছিল না, নিবন্ধন লেনদেন ব্যর্থ হয়েছে, বা entity-র কোনো ঠিকানায় অর্থ কম ছিল।
• কী করণীয়? সিস্টেম ক্লায়েন্টের লগে “Voter … registered for epoch …” খুঁজুন এবং নিশ্চিত করুন ক্লায়েন্ট পুরো নিবন্ধন সময়ে চলে; শুধু তখনই নিবন্ধন সম্ভব।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু
• অপেক্ষা (মিনিট): ডিফল্ট ১৫ (১–১,৪৪০)। registration খোলার পরে এত মিনিট অপেক্ষা করে অনুপস্থিত registration জানায়।

Signing policy সদস্যপদ

Identity সক্রিয় signing policy-তে নেই।

• কী পরীক্ষা করা হয়? সক্রিয় signing policy-তে identity অনুপস্থিত কি না দেখে।
• কেন এটি গুরুত্বপূর্ণ? শুধু সক্রিয় signing policy-র entities বর্তমান রিওয়ার্ড এপকে জমা দিতে, স্বাক্ষর করতে ও পুরস্কার পেতে পারে।
• সাধারণ কারণ: এই এপকের নিবন্ধন মিস হয়েছে বা সফল হয়নি।
• কী করণীয়? বর্তমান এপকে আর যোগ দেওয়া যাবে না। পরের নিবন্ধন সফল হওয়া নিশ্চিত করুন এবং আগের নিবন্ধন সময়ের লগ দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু

transaction-এর operational provider address-এ native funds।

কম পরিচালন ব্যালান্স

Submit, signatures ও signing policy ঠিকানার নেটিভ ব্যালান্স প্রতি ঘণ্টায় পরীক্ষা।

• কী পরীক্ষা করা হয়? ক্যাশ করা operational address-এর native balance সীমার সঙ্গে দেখে; read failure recovery প্রমাণ করে না।
• কেন এটি গুরুত্বপূর্ণ? কম native balance operational transaction-এর gas দিতে বাধা হতে পারে।
• সাধারণ কারণ: Gas খরচ বা outgoing transfer operational address-এর balance কমিয়ে থাকতে পারে।
• কী করণীয়? পূরণ করার আগে কম balance-এর address ও সাম্প্রতিক transaction দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু
• এর নিচে সতর্কতা (FLR/SGB): ডিফল্ট ২৫ (০.০০১–১০,০০,০০০)। পড়া যায় এমন native balance এই amount-এর নিচে হলে সতর্ক।
• এর নিচে গুরুতর (FLR/SGB): ডিফল্ট ৫ (০–১০,০০,০০০)। এই amount-এর নিচে low-balance alert critical হয়; warning threshold-এর বেশি হতে পারে না।

monitoring data-এর প্রাপ্যতা ও সাম্প্রতিকতা।

পর্যবেক্ষণের প্রাপ্যতা

সবসময় চালু। বিশ্লেষক বা ফলাফল পুরোনো হলে প্রদানকারীর সতর্কতা স্থগিত থাকে।

• কী পরীক্ষা করা হয়? সবসময় analyzer দেখে। অনুপস্থিত, ব্যর্থ বা দশ মিনিটের বেশি পুরোনো run/round data provider মূল্যায়ন থামায়।
• কেন এটি গুরুত্বপূর্ণ? পুরোনো monitoring provider-এর অবস্থা নির্ভরযোগ্যভাবে মূল্যায়ন করে না।
• সাধারণ কারণ: Analyzer বন্ধ, ব্যর্থ বা সম্পূর্ণ round না পেতে পারে।
• কী করণীয়? Analyzer status, শেষ run ও indexed round-এর সময় দেখুন।
• সিগন্যাল সক্রিয়: সবসময় চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু

পর্যবেক্ষিত FTSO/FDC আগাম সতর্কতা, official Minimal Conditions সিদ্ধান্ত থেকে আলাদা।

Anchor আগাম সতর্কতা

পর্যবেক্ষিত সাফল্যের হার সীমার নিচে; এটি আনুষ্ঠানিক যোগ্যতার সিদ্ধান্ত নয়।

• কী পরীক্ষা করা হয়? যথেষ্ট সাম্প্রতিক sample থাকলে window-তে FTSO anchor hit rate দেখে। শূন্য signing weight-এ প্রযোজ্য নয়।
• কেন এটি গুরুত্বপূর্ণ? আনুষ্ঠানিকভাবে, প্রতি রিওয়ার্ড এপকের ৮০% ভোটিং রাউন্ডে anchor-feed অনুমান মিডিয়ানের ০.৫% এর মধ্যে থাকতে হবে। এই window আগাম সূচক, আনুষ্ঠানিক ফল নয়।
• সাধারণ কারণ: কম অংশগ্রহণ, সংযোগ বিচ্ছিন্নতা বা অসম্পূর্ণ পর্যবেক্ষণ মান কমাতে পারে।
• কী করণীয়? provider বা validator পরীক্ষা করার আগে window, নমুনাসংখ্যা ও উৎসের সাম্প্রতিকতা দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু
• এর নিচে সতর্কতা (%): ডিফল্ট ৮০% (১%–১০০%)। যথেষ্ট recent observation-এ এই শতাংশের নিচে সতর্ক; recovery-তে ২ percentage point বেশি, সর্বোচ্চ ১০০%।
• সময়সীমা: ডিফল্ট ২ ঘণ্টা। ঘণ্টায় observation window বেছে নিন; সম্পূর্ণ reward epoch মূল্যায়ন নয়।
• ন্যূনতম পর্যবেক্ষণ: ডিফল্ট ৪০ (১০–২৪০)। শতাংশ মূল্যায়নের আগে অন্তত এত observation দরকার।

FDC আগাম সতর্কতা

পর্যবেক্ষিত অংশগ্রহণ সীমার নিচে। সম্মতিহীন রাউন্ড বাদ দেওয়া হয়।

• কী পরীক্ষা করা হয়? যথেষ্ট recent sample-এ consensus round-এর FDC participation দেখে; consensus নেই বা signing weight শূন্য হলে বাদ।
• কেন এটি গুরুত্বপূর্ণ? আনুষ্ঠানিকভাবে FDC-তে প্রতি রিওয়ার্ড এপকের ৬০% ভোটিং রাউন্ডে সফল অংশগ্রহণ (সঠিক Merkle root) প্রয়োজন। এখানে আপনার সীমা আরও আগে সতর্ক করতে পারে।
• সাধারণ কারণ: কম অংশগ্রহণ, সংযোগ বিচ্ছিন্নতা বা অসম্পূর্ণ পর্যবেক্ষণ মান কমাতে পারে।
• কী করণীয়? provider বা validator পরীক্ষা করার আগে window, নমুনাসংখ্যা ও উৎসের সাম্প্রতিকতা দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু
• এর নিচে সতর্কতা (%): ডিফল্ট ৮০% (১%–১০০%)। যথেষ্ট recent observation-এ এই শতাংশের নিচে সতর্ক; recovery-তে ২ percentage point বেশি, সর্বোচ্চ ১০০%।
• সময়সীমা: ডিফল্ট ২ ঘণ্টা। ঘণ্টায় observation window বেছে নিন; সম্পূর্ণ reward epoch মূল্যায়ন নয়।
• ন্যূনতম পর্যবেক্ষণ: ডিফল্ট ৪০ (১০–২৪০)। শতাংশ মূল্যায়নের আগে অন্তত এত observation দরকার।

পর্যবেক্ষিত P-chain connectivity ও registered NodeID validator membership।

ভ্যালিডেটর সংযোগ

একাধিক P-chain দৃষ্টিকোণ; সমান্তরাল যাচাই পর্যন্ত সতর্কতা বন্ধ।

• কী পরীক্ষা করা হয়? বিভিন্ন P-chain viewpoint থেকে validator connectivity দেখে, official Uptime নয়। ডিফল্টে বন্ধ।
• কেন এটি গুরুত্বপূর্ণ? স্টেকিংয়ে প্রতি রিওয়ার্ড এপকে মোট ৮০% আপটাইম প্রয়োজন। এটি পর্যবেক্ষিত সংযোগের সংকেত, আনুষ্ঠানিক আপটাইম নয়।
• সাধারণ কারণ: কম অংশগ্রহণ, সংযোগ বিচ্ছিন্নতা বা অসম্পূর্ণ পর্যবেক্ষণ মান কমাতে পারে।
• কী করণীয়? provider বা validator পরীক্ষা করার আগে window, নমুনাসংখ্যা ও উৎসের সাম্প্রতিকতা দেখুন।
• সিগন্যাল সক্রিয়: বন্ধ
• পুনরুদ্ধার বার্তা পাঠান: চালু
• এর নিচে সতর্কতা (%): ডিফল্ট ৮০% (১%–১০০%)। যথেষ্ট recent observation-এ এই শতাংশের নিচে সতর্ক; recovery-তে ২ percentage point বেশি, সর্বোচ্চ ১০০%।
• সময়সীমা: ডিফল্ট ২ ঘণ্টা। ঘণ্টায় observation window বেছে নিন; সম্পূর্ণ reward epoch মূল্যায়ন নয়।
• ন্যূনতম পর্যবেক্ষণ: ডিফল্ট ৪০ (১০–২৪০)। শতাংশ মূল্যায়নের আগে অন্তত এত observation দরকার।

ভ্যালিডেটর তালিকাভুক্ত নয়

কোনো নিবন্ধিত NodeID বর্তমান ভ্যালিডেটর নয়। স্টেক অনুপস্থিত বা মেয়াদোত্তীর্ণ কি না দেখুন। NodeID না থাকলে প্রযোজ্য নয়।

• কী পরীক্ষা করা হয়? সব registered NodeID current validator set-এ নিশ্চিত অনুপস্থিত হলে সতর্ক করে। NodeID নেই বা ফল অজানা হলে অনুপস্থিতি প্রমাণ হয় না।
• কেন এটি গুরুত্বপূর্ণ? সক্রিয় ভ্যালিডেটর নয় এমন নোড স্টেকিং পুরস্কার পায় না, এবং স্টেকিং Minimal Condition অনুযায়ী প্রতি রিওয়ার্ড এপকে মোট ৮০% আপটাইম প্রয়োজন।
• সাধারণ কারণ: ভ্যালিডেটরের স্টেকের মেয়াদ শেষ হয়েছে, নোড কখনো ভ্যালিডেটর হিসেবে যোগ করা হয়নি, বা entity-র সঙ্গে যুক্ত NodeID বদলেছে।
• কী করণীয়? নোডের স্টেকের শেষ সময় দেখুন, প্রয়োজনে নবায়ন করুন এবং আপনার identity-র সঙ্গে যুক্ত NodeID নিশ্চিত করুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু

provider address-এর ব্যক্তিগত unclaimed reward, epoch অনুযায়ী।

দাবি না করা ব্যক্তিগত পুরস্কার

প্রতি যুগে প্রমাণ দিয়ে যাচাই করা দাবিযোগ্য DIRECT/FEE পুরস্কারের সারসংক্ষেপ। ডেলিগেটর পুল বাদ দেওয়া হয়।

• কী পরীক্ষা করা হয়? প্রতি reward epoch-এ minimum-এর বেশি ব্যক্তিগত direct ও fee reward একবার জানায়; সমান বা কম হলে recovery।
• কেন এটি গুরুত্বপূর্ণ? FSP পুরস্কারের মেয়াদ ২৫ রিওয়ার্ড এপক (প্রায় তিন মাস) পরে শেষ হয়; তখন ক্লেম না করা সরাসরি ও ফি-পুরস্কার হারিয়ে যায়।
• সাধারণ কারণ: Reward claimable হয়েছে বা claim cache-এ এখনও দেখা যায়নি।
• কী করণীয়? Reward view-এ epoch, পরিমাণ ও claim status দেখুন।
• সিগন্যাল সক্রিয়: চালু
• পুনরুদ্ধার বার্তা পাঠান: চালু
• ন্যূনতম পরিমাণ (FLR/SGB): ডিফল্ট ১ (০–১,০০,০০,০০,০০০)। ব্যক্তিগত unclaimed reward এই native-token amount-এর বেশি হলেই alert।