اس صفحے سے یہ معلوم کریں کہ کوئی ٹرانزیکشن کب حتمی ہوتی ہے، کتنے تصدیق کنندگان کا فعال ہونا ضروری ہے، اور RPC اور ایکسپلورر میں نظر آنے والے بلاک کے فیلڈز کا کیا مطلب ہے۔ اتفاقِ رائے کا طریقہ زنجیر بند (chained) HotStuff BFT ہے جس کے کورم اسٹیک کے وزن سے طے ہوتے ہیں؛ چین 20 پر اس کا مطلب 26 میں سے 18 تصدیق کنندگان ہے۔
نوڈ جن قواعد پر چلتا ہے
| قاعدہ | نفاذ کی صورت |
|---|---|
| کورم | کورم سرٹیفکیٹ (QC) ان تصدیق کنندگان کے Dilithium2 ووٹوں کا مجموعہ ہے جن کے پاس کل اسٹیک کا 2/3 سے قطعی زیادہ حصہ ہو |
| لیڈر کی ترتیب | خالص باری باری (round robin): ویو v کا لیڈر validators[v mod n] ہے، اور مجموعہ پتے کے لحاظ سے ترتیب دیا جاتا ہے۔ اسٹیک ووٹوں کو وزن دیتا ہے، لیڈر کے انتخاب کو نہیں |
| تجویز پیش کرنا | ویو v کا لیڈر اس وقت تجویز پیش کرتا ہے جب اس کے پاس v − 1 کا QC ہو، یا v کے لیے NewView پیغامات کا کورم ہو۔ جو تجویز کسی غیر درست ٹرانزیکشن کو لاگو کرتی ہو، وہ بلاک کے بجائے اسی ٹرانزیکشن کو خارج کر دیتی ہے |
| ووٹنگ اور سلامتی | تصدیق کنندہ ہر ویو میں ایک بار ووٹ دیتا ہے، اور صرف ایسے بلاک کو جو اس کے لاک کے لحاظ سے محفوظ ہو (اس کا justify QC لاک شدہ QC سے نیا ہو، یا بلاک لاک شدہ بلاک کو آگے بڑھاتا ہو)۔ ووٹ کے نوڈ سے نکلنے سے پہلے سلامتی کی حالت RocksDB میں fsync کر دی جاتی ہے |
| دستخط کا دائرہ | جس جینیسس میں consensus_domain: 1 ہو (چین 20، اور چین 15 کے بعد سے ہر چین) اس میں ہر ووٹ، new-view اور تجویز کا دستخط جینیسس ہیش کا احاطہ کرتا ہے (rand-vote-2، rand-newview-2، rand-block-2)، لہٰذا ایک چین کا دستخط کسی دوسری چین پر تصدیق نہیں پاتا۔ چین 14 اور اس سے پہلے کی چینز اس کے بغیر دستخط کرتی تھیں۔ چین 20 کا binding_domain: 1 یہی قاعدہ ٹرانزیکشن کے ثبوتوں اور دستخط شدہ کارروائیوں تک بڑھاتا ہے (ٹرانزیکشنز) |
| متوازی تجاویز | ریپلیکا ہر (ویو، لیڈر) کے لیے ایک بلاک رکھتا ہے؛ اسی ویو کے لیے اسی لیڈر کا دوسرا، مختلف بلاک دوغلے پن (equivocation) کے طور پر رد کر دیا جاتا ہے۔ جو تجویز ریپلیکا کے اپنے ویو سے 8 سے زیادہ ویو آگے ہو (PROPOSAL_VIEW_WINDOW) وہ دستخط جانچنے سے پہلے ہی رد کر دی جاتی ہے؛ قیاسی درخت بھر جانے پر وہ کچھ بھی رد کرنے سے پہلے مرکزی شاخ سے باہر کے بلاک نکال دیتا ہے |
| لاک کی رہائی | لاک کبھی خودکار طور پر نیچے نہیں کیا جاتا (CON-4، v0.6.8)۔ یہ صرف اس تجویز کے سامنے ہٹتا ہے جس کا justify QC اس سے بلند درجے کا ہو، یا لاک شدہ بلاک کے پہنچ جانے پر۔ دستخط شدہ NotHeld جوابات کا کورم آپریٹر کے لیے لاگ کیا جاتا ہے اور کچھ بھی رہا نہیں کرتا، اور تصدیق کنندہ اپنے ووٹ محفوظ رکھتا ہے تاکہ کسی ایسے بلاک کے لیے کبھی NotHeld پر دستخط نہ کرے جسے اس نے ووٹ دیا ہو۔ ہیڈ سے اوپر کا ہر تصدیق شدہ بلاک محفوظ کیا جاتا ہے اور دوبارہ آغاز پر بحال کیا جاتا ہے، لہٰذا پورے بیڑے کے دوبارہ آغاز سے کوئی QC ایسے بلاک پر معلق نہیں رہتا جو کسی کے پاس نہ ہو۔ جس تصدیق کنندہ کا لاک شدہ بلاک مستقل طور پر ضائع ہو جائے، اسے آف لائن، ہاتھ سے رہا کیا جاتا ہے: rand-node safety release-lock |
| QC کی تشکیل | ہر تصدیق کنندہ گوسپ کے ذریعے آنے والے ووٹوں سے مقامی طور پر QC تشکیل دیتا ہے، لہٰذا اگلا لیڈر آف لائن ہو تب بھی چین کمٹ کرتی رہتی ہے |
| کمٹ | زنجیر بند تین-QC قاعدہ: کوئی بلاک اس وقت کمٹ ہوتا ہے جب اس کے اوپر تین سرٹیفکیٹ مسلسل ویوز v, v+1, v+2 میں زنجیر بنائیں اور یہ زنجیر کمٹ شدہ ہیڈ تک واپس جڑتی ہو |
| ٹائم آؤٹ اور ویو کی تبدیلی | بنیادی --view-timeout-ms 3,000 ms، ہر مسلسل ٹائم آؤٹ پر دگنا، اور کسی بھی پیش رفت پر دوبارہ ابتدائی قدر۔ ٹائم آؤٹ سرٹیفکیٹ پیس میکر (CH-1، v0.6.8): جس ریپلیکا کا ٹائمر ختم ہو جائے وہ اپنے ویو میں رہتا ہے اور اگلے ویو کی درخواست کرتے ہوئے NewView پر دستخط کرتا ہے۔ وہ کسی ویو میں اس وقت داخل ہوتا ہے جب اس سے پچھلے ویو کا QC مل جائے، یا جب 2/3 سے زیادہ اسٹیک رکھنے والے تصدیق کنندگان اس ویو یا اس کے بعد کے کسی ویو کی درخواست کر چکے ہوں؛ جب 1/3 سے زیادہ اس کے اپنے ویو سے آگے کے کسی ویو کی درخواست کریں تو وہ ان میں شامل ہو جاتا ہے (اپنی درخواست پر دستخط کرتا ہے)۔ کسی ایک تصدیق کنندہ کا NewView کسی کو آگے نہیں بڑھاتا۔ ویوز محدود ہیں (MAX_VIEW_AHEAD = 10⁶) |
| رفتار | جب کچھ زیرِ التوا نہ ہو تو لیڈر خالی بلاک تجویز کرتا ہے، کسی بھی تجویز کنندہ کے آخری دیکھے گئے بلاک کے کم از کم --block-interval-ms (طے شدہ قدر 1,000 ms) بعد |
| ووٹ اور گوسپ کی حدود | 8 سے زیادہ ویو آگے کے ووٹ نظرانداز کیے جاتے ہیں اور ہر (ویو، ووٹر) کا ایک ووٹ شمار ہوتا ہے؛ اتفاقِ رائے کی گوسپ ہر آگے بھیجنے والے پیئر کے لحاظ سے ناپی جاتی ہے (burst 256، 64/s)؛ جس تجویز کا والد بلاک نامعلوم ہو اسے یتیم بلاک کے طور پر صرف اس صورت میں رکھا جاتا ہے جب اس کا تجویز کنندہ موجودہ ایپوک یا اگلے ایپوک کے مجموعے میں اپنے ویو کا لیڈر ہو، وہ کمٹ شدہ ہیڈ سے درخت کی حد کے اندر ہو، اور اس کا سائز اور tx root درست نکلیں (یتیم بلاکوں کا ذخیرہ 64 MiB تک محدود، اور v0.6.1 سے ہر تجویز کنندہ کے 16 یتیم بلاک تک)۔ v0.6.8 سے کوئی تجویز آگے بھیجی جاتی ہے، اور کوئی یتیم بلاک رکھا جاتا ہے، صرف اس صورت میں جب اس کی ٹرانزیکشن فہرست کا ہیش اسی root کے برابر ہو جس کا اس کا ہیڈر عہد کرتا ہے اور کوئی ٹرانزیکشن دہرائی نہ گئی ہو (GOSSIP-2) |
| بلاک کی حدود | چین کا max_block_bytes ٹرانزیکشن بائٹس (طے شدہ طور پر 4 MiB، چین 20 کے جینیسس میں 20 MiB) اور 2,000 ٹرانزیکشنز، جن کا نفاذ تجویز کنندہ کرتا ہے اور پھر ہر ریپلیکا Ledger::apply_block میں دوبارہ کرتا ہے |
| بلاک کا وقت | جس چین میں bridge سیکشن ہو: کسی بلاک کا timestamp_ms اپنے والد بلاک سے پہلے کا نہیں ہو سکتا (TimestampRewind) اور نہ اس سے 60 s سے زیادہ آگے ہو سکتا ہے (TimestampLeap)، اور تصدیق کنندہ ایسے بلاک کو ووٹ نہیں دیتا جو اس کی اپنی گھڑی سے 15 s سے زیادہ آگے ہو؛ نیچے دیکھیں |
تین مسلسل ویوز والا کمٹ قاعدہ بنیادی اہمیت رکھتا ہے: اسے نرم کرنے سے متضاد حتمیت کا وہ نقص دوبارہ کھل جاتا ہے جس کے لیے fullnode میں ایک regression ٹیسٹ موجود ہے۔ کلائنٹ کو RPC کے ذریعے جو کچھ نظر آتا ہے وہ سب کمٹ شدہ ہے: صرف کمٹ شدہ بلاک پیش کیے جاتے ہیں، اور WebSocket کی newHeads اسٹریم ہر کمٹ شدہ بلاک کے لیے ترتیب سے ایک اطلاع بھیجتی ہے۔
یہ جدول v0.6.8 کا ہے، وہ ریلیز جس پر چین 20 چلتی ہے۔ اس کے تین قواعد v0.6.8 میں نئے ہیں (آڈٹ v6) اور 2026-10-01 کو چین 20 کے فعال ہونے سے نافذ ہیں: ٹائم آؤٹ سرٹیفکیٹ پیس میکر (CH-1)، لاک کی خودکار رہائی کا خاتمہ (CON-4) اور تجویز کی ٹرانزیکشن فہرست کی جانچ (GOSSIP-2)۔ چین 18 اور 19 (v0.6.7) پر کسی ایک تصدیق کنندہ کا دستخط شدہ NewView ہر ریپلیکا کو اپنے ویو میں لے جاتا تھا، اور اسٹیک کے کورم کی طرف سے دستخط شدہ NotHeld جوابات پر لاک نیچے کر دیا جاتا تھا۔ پیس میکر اور لاک کا قاعدہ یہ بدلتے ہیں کہ تصدیق کنندگان کس چیز پر اور کب دستخط کرتے ہیں، اس لیے v0.6.8 چین 20 کے آغاز کے ساتھ سب کو روک کر اور سب کو ایک ساتھ شروع کر کے نافذ کیا گیا، نوڈ بہ نوڈ کبھی نہیں۔
testnet کے اعداد و شمار
چین 20 میں 26 تصدیق کنندگان ہیں، ہر ایک کا اسٹیک ٹھیک 1,000 RAND، اور سب 26 اس کے جینیسس میں ان ہی کلیدوں اور پیئر شناختوں پر ہیں جن پر چین 17 سے 19 چلیں۔ چین 15 پر اٹھارہ جینیسس میں تھے، چین 14 کی کلیدوں پر، اور مزید آٹھ نے 2026-09-27 کو v2 رجسٹریشنز کے تحت بانڈ کیا اور ایپوک 43 سے فعال ہوئے۔ اسٹیک یکساں ہے، اس لیے کورم محض گنتی ہے: کچھ بھی کمٹ کرنے کے لیے 26 میں سے 18 کا آن لائن ہونا لازم ہے۔ 17 فعال ہوں تو ویوز آگے بڑھتے ہیں مگر کچھ حتمی نہیں ہوتا۔ n مساوی تصدیق کنندگان کے مجموعے کو اسٹیک کے 2/3 سے زیادہ کی ضرورت ہوتی ہے: 2 میں سے 2، 4 میں سے 3، 6 میں سے 5، 18 میں سے 13، 26 میں سے 18۔ جینیسس کی وزن کی حد (ہر تصدیق کنندہ کے لیے 3,333 bps) مساوی اسٹیک والے مجموعے پر لاگو نہیں ہوتی۔
بلاکوں کی رفتار طے شدہ 1,000 ms پر رکھی گئی ہے۔ چین 15 پر عملاً یہ تقریباً ہر 1.2 s بعد آتے تھے (اس کے پہلے 29 گھنٹوں کا اوسط 1.18 s)؛ چین 20 پر ایکسپلورر نے بلندی 3,270 پر 1.34 s کا اوسط بتایا (2026-10-01، avg_block_time_ms)۔ ایکسپلورر بلاک کا وہ اوسط وقت بتاتا ہے جس کا وہ مشاہدہ کرتا ہے (GET /stats میں avg_block_time_ms)۔ جب بھی ویوز کا ٹائم آؤٹ ہوتا ہے، تصدیق کنندہ کا ویو بلندی سے آگے نکل جاتا ہے، اسی لیے rand_getHead دونوں بتاتا ہے۔
ایپوکس
تصدیق کنندگان کا مجموعہ ہر epoch_blocks = 1,000 بلاکوں (ایک جینیسس پیرامیٹر) کے بعد رجسٹر سے دوبارہ اخذ کیا جاتا ہے۔ epoch(h) = h / 1000؛ ایپوک e ≥ 1 کا مجموعہ ایپوک e − 1 کے آخری بلاک کے وقت کے رجسٹر سے اخذ کیا جاتا ہے: ہر وہ قطار جس میں stake ≥ 1,000 RAND ہو، اسٹیک کے لحاظ سے سرِفہرست 100، پتے کے لحاظ سے ترتیب شدہ۔ جس چین میں staking سیکشن نہ ہو اس پر بانڈ اگلی حد پر وزن بن جاتا ہے۔ چین 20 پر یہ مزید دو ایپوک انتظار کرتا ہے اور اس پر حد کے وقت فعال بانڈ شدہ وزن کے 2,500 bps کا فی ایپوک داخلہ بجٹ لاگو ہوتا ہے (جب تک مجموعے میں 26,000 ہوں، 6,500 RAND)، اور جو بانڈ نئے تصدیق کنندہ کو رجسٹر کرتا ہو وہ رد کر دیا جاتا ہے جب تک مجموعہ پہلے AdmitValidator کے ذریعے کلید کو ووٹ دے کر شامل نہ کر لے (staking.admission_by_vote)۔ چین 19 کا بجٹ فی ایپوک مقررہ 10,000 RAND تھا، اور اس میں داخلے کا ووٹ نہیں تھا۔ بانڈ ختم کرنے سے وزن اگلی حد پر کم ہو جاتا ہے، جبکہ رقم قابلِ نکاسی ہونے کے لیے دو ایپوک انتظار کرتی ہے۔ rand_getEpoch ایپوک، ایپوک کی طوالت اور اگلے مجموعے کا تخمینہ لوٹاتا ہے۔ دیکھیں اسٹیکنگ۔
بلاک میں کیا ہوتا ہے
{
"hash": "647b…", "height": 50, "view": 92, "parent": "2d41…",
"proposer": "3v3VBJ…", "timestamp_ms": 1788000123456,
"tx_root": "0000…", "state_root": "a1b2…", "justify_view": 91,
"tx_count": 0, "transactions": []
}view وہ ویو ہے جس میں بلاک تجویز کیا گیا، اور justify_view اس QC کا ویو ہے جو بلاک اپنے والد بلاک کے لیے ساتھ رکھتا ہے۔ timestamp_ms تجویز کنندہ طے کرتا ہے، اگلے سیکشن کی حدود کے اندر۔ state_root بلاک کے بعد کے لیجر کا عہد کرتا ہے۔ چین 20 پر:
inner = blake3("rand-state-8" || tree_root || nullifier_root || validators_root || programs_root
|| bridge_root || tokens_root
|| faucet_epoch || faucet_minted_in_epoch || bond_queue_root
|| gas_price || byte_price
|| program_state_root)
state_root = blake3("rand-state-admitted-1" || inner || admitted_root)چین 19 انہی فیلڈز کا عہد program_state_root کے بغیر، rand-state-7 کے تحت، بغیر کسی ریپر کے کرتی تھی۔
اجزاء جینیسس پر منحصر ہیں۔ جس چین میں کوئی اختیاری سیکشن نہ ہو وہ پہلے چار اجزاء کو rand-state-2 کے تحت کمٹ کرتی ہے۔ bridge سیکشن bridge_root کا اضافہ کرتا ہے۔ tokens سیکشن اس کے بعد tokens_root جوڑتا ہے اور پورے ہیش کا ڈومین بدل کر rand-state-4 کر دیتا ہے؛ جس جینیسس میں bridge سیکشن ہو اس میں tokens سیکشن کا ہونا لازم ہے، اس لیے چین 20 میں دونوں موجود ہیں۔ aggregation سیکشن اس کے بعد ایگریگیٹرز کا روٹ جوڑتا ہے (ٹوکنز کے بغیر چین پر rand-state-3 کے تحت)؛ چین 20 میں یہ سیکشن نہیں ہے۔ staking سیکشن سب سے آخر میں فاسٹ کے دو ایپوک کاؤنٹر اور بانڈ قطار کا روٹ (rand-bond-queue-1) جوڑتا ہے اور پورے ہیش کا ڈومین بدل کر rand-state-5 کر دیتا ہے، خواہ باقی کچھ بھی فعال ہو؛ چین 14 میں یہ سیکشن نہیں تھا اور وہ rand-state-4 کے تحت ہیش کرتی تھی، اور چین 15 تا 17 rand-state-5 کے تحت ہیش کرتی تھیں۔ vesting سیکشن اس کے بعد ویسٹنگ رجسٹر کا روٹ جوڑتا ہے اور ہیش کا ڈومین بدل کر rand-state-6 کر دیتا ہے؛ چین 20 میں یہ سیکشن نہیں ہے۔ dynamic کنٹرولر والا gas سیکشن باقی سب کے بعد موجودہ gas_price اور byte_price جوڑتا ہے، ہر ایک big-endian u64 کی صورت میں، اور ہیش کا ڈومین بدل کر rand-state-7 کر دیتا ہے۔ یہ چین 19 کا ڈومین تھا، اور چین 20 بھی قیمتیں اپنے روٹ میں رکھتی ہے: یہ ہر بلاک میں ایک بار بدلتی ہیں، بلاک کی ٹرانزیکشنز کے بعد اور روٹ سے پہلے (فیس)۔ مقررہ قیمتوں والا gas سیکشن روٹ میں شامل نہیں ہوتا۔ program_state سیکشن (RPL-2) قیمتوں کے بعد ہر پروگرام کے سیلز اور والٹس کا روٹ جوڑتا ہے اور ہیش کا ڈومین بدل کر rand-state-8 کر دیتا ہے: یہی چین 20 کا ڈومین ہے۔ آڈٹ v6 کی اسٹیکنگ اسٹیٹ اس ہیش کے اندر نہیں بلکہ اس کے گرد شامل کی جاتی ہے: staking.admission_by_vote کے تحت (چین 20) روٹ blake3("rand-state-admitted-1" || inner || admitted_root) ہوتا ہے، اور staking.slashing کے تحت (جو ابھی کسی چین پر نہیں) ایک دوسرا ریپر معطل شدہ سیٹ کا اضافہ کرتا ہے۔ tokens_root انڈیکس کی ترتیب میں blake3("rand-token-leaf-1" || bincode(TokenInfo)) لیفز کا Merkle روٹ ہے، لہٰذا ہر ٹوکن کا میٹا ڈیٹا، اتھارٹی، mint_nonce، سپلائی اور ہر بیکنگ کی locked مقدار کنسینسس اسٹیٹ کا حصہ ہے: جو دو نوڈ کسی ایک ٹوکن کی قطار پر اختلاف رکھیں وہ چین پر اختلاف رکھتے ہیں۔ چین 20 پر ٹوکن روٹ رجسٹری کی توسیع (max_tokens کی حد، جلائی گئی رجسٹریشن فیس، نوٹ کی قدر کی حد اور برج کی رولنگ منٹ کیپ ونڈوز) کو بھی rand-token-registry-3 کے تحت شامل کرتا ہے۔ برج روٹ ایمیٹرز، گارڈین سیٹس، خرچ شدہ اٹیسٹیشن ڈائجسٹس، برن سیکوئنس، PQ گارڈین کلیدوں، توقف کی کلید، توقف کے فلیگ اور دو گورننس نانسز کا احاطہ کرتا ہے؛ اثاثہ رجسٹری اس سے نکل کر tokens_root میں منتقل ہو گئی ہے۔ چین 20 کے برج میں rules_v2 ہے، اس لیے روٹیشن نانس اور عالمی کیپ کے پیرامیٹرز جوڑے جاتے ہیں اور ڈومین rand-bridge-state-5 ہے (چین 14 کا ڈومین rand-bridge-state-4 تھا)؛ پھر اس روٹ کو اِن باؤنڈ ری پلے فلور (rand-bridge-replay-floor-1) میں لپیٹا جاتا ہے، اور چین 20 پر روٹیشن کے قواعد اور زیرِ التوا روٹیشنز (rand-bridge-rotation-1) اور فیس گروپ (rand-bridge-fees-1) میں بھی۔ ویلیڈیٹر رجسٹر کو validators_root میں ہیش کیا جاتا ہے (چین 20 پر لیف ڈومین rand-validator-leaf-4 ہے، ہر قطار کے activation_epoch کے ساتھ؛ staking سیکشن کے بغیر چین پر rand-validator-leaf-2)، لہٰذا جو نوڈ رجسٹر کی کسی ایک قطار پر اختلاف رکھے وہ چین پر اختلاف رکھتا ہے۔
بلاک کا وقت محدود ہے (B2)
برج سے منسلک چین پر بلاک کا ٹائم اسٹیمپ یہ طے کرتا ہے کہ گارڈین سیٹ کی میعاد کب ختم ہو گی اور کسی بیکنگ کی یومیہ منٹ کیپ کس دن کے کھاتے میں شمار ہو گی، اس لیے جو لیڈر گھڑی کو اچانک آگے بڑھا سکے وہ تبدیل شدہ سیٹ کی رعایتی مدت قبل از وقت ختم کر سکتا ہے یا کسی دن کی کیپ کو پھلانگ سکتا ہے۔ چین 20 میں bridge سیکشن موجود ہے، اس لیے تین قواعد لاگو ہوتے ہیں، اور تینوں اسی سیکشن سے مشروط ہیں:
| قاعدہ | حد | نوعیت |
|---|---|---|
| پیچھے جانے کی ممانعت | timestamp_ms ≥ parent.timestamp_ms (برابر ہونے کی اجازت ہے)، ورنہ BlockError::TimestampRewind؛ تجویز کنندہ max(now, parent.timestamp_ms) جاری کرتا ہے | درستگی کا قاعدہ، ری پلے اور سنک پر بھی جانچا جاتا ہے |
| چھلانگ کی ممانعت | timestamp_ms ≤ parent.timestamp_ms + MAX_TIMESTAMP_STEP_MS (60,000 ms)، ورنہ BlockError::TimestampLeap | درستگی کا قاعدہ، ری پلے اور سنک پر بھی جانچا جاتا ہے |
| گھڑی کا انحراف | ویلیڈیٹر کسی ایسے بلاک کو ووٹ دینے سے انکار کرتا ہے جو اس کی اپنی گھڑی سے MAX_CLOCK_DRIFT_MS (15,000 ms) سے زیادہ آگے ہو | صرف ووٹ کا قاعدہ: بلاک قیاسی درخت میں موجود رہتا ہے، جس کورم کی گھڑیاں متفق ہوں وہ اب بھی اس کی تصدیق کر سکتا ہے، اور کمٹ شدہ تاریخ کے ری پلے پر یہ قاعدہ کبھی لاگو نہیں ہوتا |
برج سے منسلک چین کے ہر ویلیڈیٹر کو NTP درکار ہے۔ جس ویلیڈیٹر کی گھڑی 15 سیکنڈ سے زیادہ غلط ہو وہ ناقص لیڈر بھی ہے (ممکن ہے اس کی تجاویز کو کوئی ووٹ نہ ملے) اور ناقص ووٹر بھی (ممکن ہے وہ کسی دیانت دار لیڈر کے بروقت بلاک کو رد کر دے)۔ جب تک دیانت دار اکثریت کی گھڑیاں متفق ہوں، ان دونوں میں سے کوئی صورت چین کو نہیں روکتی، لیکن غیر ہم وقت فلیٹ بلاوجہ لائیونس کا حاشیہ کھو دیتا ہے۔
جینیسس کا timestamp_ms اصل لانچ کے وقت کے قریب ہونا چاہیے۔ اگر یہ ماضی میں بہت پیچھے ہو تو بلاک کا وقت حقیقی وقت سے پیچھے رہتا ہے جب تک قدم کی حد اسے برابر نہ آنے دے، جو فی بلاک زیادہ سے زیادہ 60 s ہے۔ اگر یہ 15 s سے زیادہ مستقبل میں ہو تو بلاک 1 کمٹ ہی نہیں ہوتا: ہر ووٹ، لیڈر کے اپنے ووٹ سمیت، اس وقت تک روکا جاتا ہے جب تک حقیقی وقت وہاں تک نہ پہنچ جائے۔ طویل تعطل کے بعد یہی برابری کا عمل منٹ کیپ کے دن کو ایک حقیقی دن میں ایک بار سے زیادہ تیزی سے بدل سکتا ہے، جس کی حد جمع شدہ تاخیر کے ہر پورے دن کے بدلے ایک اضافی دن کی کیپ ہے۔
کلائنٹ کے لیے حتمیت
- ٹرانزیکشن اس وقت حتمی ہوتی ہے جب
rand_getTransaction(hash)ایک بلاک لوٹائے۔rand_sendTransactionکی جانب سے قبولیت محض میم پول میں داخلہ ہے۔ - RPC کے ذریعے فراہم کردہ یا ایکسپلورر میں انڈیکس شدہ بلاک کمٹ شدہ ہوتا ہے۔ حتمیت کی کسی مدت کا انتظار نہیں کرنا پڑتا؛ ایکسپلورر کی گائیڈ بھی یہی کہتی ہے۔
rand_subscribe["newHeads"]سے ملنے والا ہیڈ ایسا ہیڈ ہے جسے نوڈ نہیں کھوئے گا: بلاک کے اسٹوریج میں کمٹ ہونے سے پہلے کچھ نہیں بھیجا جاتا۔- پیچھے رہ جانے والا نوڈ ہر چیز کی دوبارہ توثیق کرتا ہے: کسی سنک شدہ بلاک کو قبول کرنے سے پہلے وہ ہر سرٹیفکیٹ، ہر بنڈل اور کال پروف اور ہر رسید کی توثیق کرتا ہے۔ حتمیت کے دستخطوں پر کبھی پروفس کی جگہ اعتماد نہیں کیا جاتا۔
بحالی کی فوری رہنمائی، جو فل نوڈ کی اپنی رہنمائی سے لی گئی ہے: کم peer_count کے ساتھ اونچائی کا آگے نہ بڑھنا نیٹ ورکنگ کا مسئلہ ہے؛ پیئرز ٹھیک ہونے کے باوجود اونچائی کا آگے نہ بڑھنا اس بات کی علامت ہے کہ اسٹیک کا 2/3 سے کم حصہ آن لائن ہے؛ اسٹارٹ اپ پر CORRUPT CHAIN کا مطلب ہے کہ نوڈ نے خراب شدہ آخری حصہ کاٹ دیا ہے اور دوبارہ سنک کر رہا ہے۔