Mempool

ددې پاڼې په مرسته پوهېږئ چې یوه راکړه ورکړه وروسته له هغه چې rand_sendTransaction یې ومني او مخکې له دې چې یو بلاک یې ولېږدوي، له څه سره مخ کېږي: که رد شوې وي ولې رد شوې، ولې ښايي له حوض څخه پرته له کومې ناکامۍ ورکه شي، بلاک په کوم ترتیب ډکېږي، او د ناسمو ثبوتونو سېلاب یو تاییدوونکي ته څه زیان رسولی شي او څه نه. ممپول crates/randprotocol-node/src/mempool.rs دی؛ د هغه مخې ته ساتونکي admission.rs دي.

لېږونکي نشته، نو nonce هم نشته

په حساب‌پر بنسټ ځنځیر کې ممپول د هر لېږونکي راکړې ورکړې د nonce له مخې ترتیبوي. خوندي ځنځیر لېږونکي نه لري: یو بنډل نه پته لري او نه لاسلیک، او دوه بنډلونه یوازې هغه وخت سره تړلي وي چې یو ورته نوټ ته لاس ورووړي. نو د هر لېږونکي لپاره د ترتیب کومه اړتیا نه پاتې کېږي. د nonce د حساب‌ساتنې پر ځای د ټکر څارنه راځي: حوض د هرې ځنډېدلې راکړې ورکړې باطلوونکي او ژمنې فهرست کوي، او هغه نوې راغلې راکړه ورکړه ردوي چې په دوی کې پر هر یوه ادعا وکړي. همدا حکم د هغو څو شمېرونکو لپاره هم دی چې لیجر د هر ارزښت لپاره یې یوازې یوه راکړه ورکړه مني: د یو تاییدوونکي د ثبت nonce (یو Unbond یا یو Withdraw)، د یو ټوکن mint_nonce (چې TokenMint او SetAuthority یې شریکوي)، د ثبت هغه شاخص چې یو RegisterToken پرې تړل کېږي، او د برج pause_nonce او list_nonce. هر یو داسې ځای دی چې په حوض کې تر ټولو ډېر یوه راکړه ورکړه یې نیولی شي. له داسې دوو راکړو ورکړو څخه هېڅکله له یوې څخه زیاته نه شي شاملېدی، او د بلې ساتل به وړاندیز کوونکي ته د بلاک ځای او هر نوډ ته د ګاسپ په هر پړاو کې د یو ثبوت تصدیق بیه ورکړي.

حوض تر ټولو ډېر 10,000 راکړې ورکړې ساتي (Mempool::new(10_000) په node.rs کې) او، له v0.6.8 راهیسې، تر ټولو ډېر د اتو بلاکونو په اندازه بایټونه: MAX_POOL_BLOCKS = د ځنځیر د max_block_bytes اته چنده، چې په chain 20 کې 160 MiB کېږي (audit v6, CH-7). تر هغه مخکې یوازې شمېر محدود و، په داسې حال کې چې یوه ثبوت‌لرونکې راکړه ورکړه له نږدې 1.3 MB څخه تر 12 MB زیاتې پورې رسېږي. هره یوه د لیجر په وړاندې د اجماع د ونې په سر کې تاییدېږي، نه د وروستي ثبت شوي بلاک په وړاندې: هغه حالت چې وړاندیز کوونکی به یې په حقیقت کې پر سر جوړونه کوي.

منل، لومړی ارزان بیا ګران

هغه راکړه ورکړه چې د RPC یا ګاسپ له لارې راځي، په ترتیب سره له دې ګامونو تېرېږي، او لومړنی رد هغه تېروتنه ده چې تاسې یې ګورئ:

1. تکرار. هش لا دمخه په حوض کې دی: already in mempool.
2. ټکر. یو باطلوونکی، یوه ژمنه یا د پورتنیو nonce او شاخص ځایونو څخه یو یې لا دمخه د یوې ځنډېدلې راکړې ورکړې له خوا نیول شوی: conflicts with a pending transaction over <hex>. د ټوکن د ځای لپاره hex د ښودلو کیلي ده: یوه نښه‌لرونکې کلمه (tokn د mint_nonce لپاره، tidx د ثبت د شاخص لپاره)، بیا شاخص او nonce. د برج هغه تصدیق چې دوو ریلې کوونکو پرې سیالي کړې وي د خپل ډایجسټ له مخې جلا کېږي: conflicts with a pending transaction over bridge attestation <hash>.
3. ډک. mempool full. د ظرفیت ازموینه له دې درېو څخه وروستۍ ده. د بایټ په حد کې یوه نوې راغلې راکړه ورکړه کولی شي د حوض د هغو ننوتو ځای ونیسي چې په کلکه له هغې ټیټه درجه لري — لومړی د هرې یوې د اوسني ټیټ حد څخه پورته فیس په هر KiB، بیا د فیس له مخې — او تر هغه پورې چې ځای شي تر ټولو ارزانې لومړی وباسي؛ که دا بس نه وي، یا یوازې برابره وي، همدا نوې راکړه ورکړه ردېږي. د حکومتولۍ کړنې له دواړو حدونو بهر دي او هېڅکله نه ایستل کېږي: د برج د حکومتولۍ څلور کړنې PauseMints، UnpauseMints، RegisterBridgedToken، ListBacking، او له v0.6.8 راهیسې RotatePqGuardians، RotatePauseKey، د دوی …V2 بڼې، CancelRotation، AdmitValidator او SlashEquivocation. د دوی بایټونه او ننوتې بیا هم په حدونو کې حسابېږي. PauseMints د ساتونکې کیلي د افشا کېدو لپاره بریک دی: بې بنډله، بې فیسه، او هغه یوازینۍ راکړه ورکړه چې باید بلاک ته ورسېږي په داسې حال کې چې برید کوونکی ټوکن جوړوي، نو ډک حوض باید هغه بهر ونه ساتي. دا معافیت د ټکر په ګام پورې محدود دی: pause_nonce او list_nonce هر یو په یو وخت کې یوازې یوه راکړه ورکړه حوض ته پرېږدي، نو د برج څلور کړنې تر ټولو ډېر دوې ننوتې له حد څخه پورته زیاتولی شي؛ نورې هر یوه خپل nonce یا خپل کورم لګوي.
4. د Ledger::validate ارزانه نیمایي. هر هغه څه چې د منلو او شاملېدو ترمنځ زوړ کېدای شي او هېڅ ثبوت ته اړتیا نه لري: لنګر په chain 20 کې د وروستیو 1,024 ریښو څخه یوه ده (د جینېسس proof_window_blocks؛ پرته له هغې 256)، time د کړکۍ دننه دی، باطلوونکي نه دي لګول شوي، ژمنې نشته، د یو تصدیق ډایجسټ نه دی ادعا شوی، د سټېکینګ د یوې کړنې د ثبت nonce اوسنی دی، د ټوکن د یوې کړنې mint_nonce یا د ثبت شاخص هماغه دی چې ثبت‌پاڼه پرې ولاړه ده (wrong mint nonce، wrong token index کله چې ځنځیر ترې تېر شوی وي)، د یو درول یا لیست کولو nonce د برج اوسنی nonce دی. هغه ژمنې چې یوه راکړه ورکړه یې جوړوي هم دلته محاسبه کېږي، په شمول د هغه نوټ چې لیجر پخپله د یو Withdraw، یو BridgeAttest یا د ټولوونکي د تادیې لپاره ترلاسه کوي، کوم چې په لېږد کې نشته خو باید ټکر هم ونه کړي. د اندازې حدونه د هر ډول کوډ‌ماتونې مخکې ازمویل کېږي: هغه ثبوت چې د ځنځیر له max_proof_bytes څخه لوی وي (په ډیفالټ ډول 2 MiB، په chain 20 کې 4 MiB)، هغه تصدیق چې له 16 KiB څخه لوی وي، یا هغه راکړه ورکړه چې له بلاک څخه لویه وي (max_block_bytes: په ډیفالټ ډول 4 MiB، په chain 20 کې 20 MiB) سمدستي ردېږي، نو یو ډېر لوی بلاب هېڅ کار نه شي اخیستلی. د بنډل هغه ثبوت چې په مهر شوې (پرون شوې) نښه‌لرونکې بڼه وي، په همدې ګام کې د مهر شوې بڼې له همغږۍ بهر د PrunedFormOutsideSync په توګه ردېږي. بیا، لا هم پرته له دې چې څه تصدیق کړي، حوض د ثبوت سرپاڼې لولي. درې پالیسۍ لومړی راځي: هغه کال چې د ننوتې، keccak یا sha256 جدول یې له 2^7 قطارونو کم وي حوض ته نه داخلېږي (CallRevealsPrivateInputs)، او نه هغه ځای پر ځای کول چې هېڅ کال یې نه شي ساتلی (ProgramUncallable)، او نه هغه راکړه ورکړه چې د بنډل یا کال ثبوت یې د سرپاڼې داسې ساحه ولري چې صادق ثبوت جوړوونکی به یې نه لیکي (NonCanonicalProof). وروستۍ دوه په chain 20 کې د hardening_v6 لاندې د لیجر قواعد هم دي. له v0.6.8 راهیسې هغه سرپاڼه چې اعلان شوې درجه یې د تر ټولو اوږد جدول له سقف څخه تېره وي، مخکې له دې چې ازموینه پرې تېره شي، د NonCanonicalProof په توګه ردېږي (audit v6, ZKV-4)، او په دې مخکېنۍ کتنه کې هر ډول panic د هماغې راکړې ورکړې رد دی (VerifierPanicked)، نه د نوډ مړینه. بیا د فیس ټیټ حد: په chain 20 کې حوض هغه د ګاز حد کوډ‌ماتوي چې د کال یا invoke ثبوت یې اعلانوي، او هغه فیس چې د سر په بیو له BUNDLE_BASE + gas_price × limit + byte_price × ⌈bytes/1024⌉ څخه، جمع د invoke د حجرې فیس، کم وي د FeeTooLow په توګه ردوي (فیسونه). دا د بلاک خپل قاعده ده، نو حوض دقیقاً هغه څه غواړي چې بلاک یې غواړي.
5. ګرانه نیمایي، د اجماع له لوپ څخه بهر. راکړه ورکړه د څلورو تصدیق کاري ګرانو څخه یو ته په کتار کې ږدل کېږي، چې تر ټولو ډېر 64 ژور دی. یو کاري ګر د Ledger::validate پاتې برخه په یو بلاک کوونکي کار کې چلوي: د بنډل ډایجسټ، هغه د ګاز حد چې د بنډل ثبوت یې اعلانوي (په chain 20 کې دقیقاً 20,479، کنه BundleGasLimit)، د بنډل ثبوت او، له chain 17 راهیسې، د راکړې ورکړې د تړنې په وړاندې د هغې د اجازې ثبوت، او د کال لپاره د هغه خپل ثبوت او د فیس ټیټ حد. دا د سر د یوې کاپي په وړاندې تاییدوي چې په ټمبلۍ سره کلون کېږي، د سر په هر بدلون کې تر ټولو ډېر یو ځل او یوازې هغه وخت چې څه انتظار باسي. هغه ګاسپ شوې راکړه ورکړه چې کتار ډک ومومي، پرېښودل کېږي، نه تصدیقېږي او نه وړاندې لېږل کېږي، د دې پر ځای چې هغه لوپ بند کړي چې رایه ورکوي؛ د همتا د ګاسپ راتلونکی پړاو یې بیا راوړي.
6. بیا ازموینه او حوض ته ننوتل. insert_verified څلورم ګام د هغه سر په وړاندې بیا چلوي چې راکړه ورکړه په حقیقت کې پرې حوض ته ننوځي، ځکه چې سر ښايي د ثبوت د تصدیق پر مهال حرکت کړی وي، بیا یې مني او، د ګاسپ شوي ترافیک لپاره، یې وړاندې لېږي.

له 1 څخه تر 4 پورې ګامونه Mempool::precheck دي؛ پنځم ګام یوازینی دی چې یو STARK تصدیقوي. ځکه چې دا لګښت په یو کاري ګر ورکول کېږي، د ناسمو ثبوتونو سېلاب څلور تارونه نیسي او هېڅکله د اجماع لوپ نه نیسي. راکړې ورکړې او کړنې د لیجر خپل د منلو ترتیب لیستوي، چې څلورم او پنځم ګامونه یې په ګډه چلوي.

د ګاسپ لپاره دوه ساتونکي او یو کش

د منلو مخې ته، دوه شیان یوازې پر هغو راکړو ورکړو پلي کېږي چې له همتایانو راځي؛ د RPC له لارې سپارل شوې ترې تېرېږي، ځکه چې هغه پورټ د چلوونکي خپل دی او لا دمخه د غوښتنې د بدنې په حد محدود دی. د RPC یوازینۍ لاره چې اندازه کېږي فاسېټ دی، لاندې.

• د هر ملګري لپاره د بایټونو میټر. له v0.6.8 راهیسې د ګاسیپ هر چوکاټ لا تر ډیکوډ کېدو مخکې د هغه د لېږدوونکي ملګري د بایټونو په بودیجه حسابېږي: د لېږد د اعظمي اندازې اته چوکاټه په یوه ځل، او په هره ثانیه کې دوه چوکاټه بیا ډکېږي. له دې حد هاخوا چوکاټ له ډیکوډ پرته غورځول کېږي (audit v6, GOSSIP-1). د راکړې ورکړې id، چې ټول ثبوت هش کوي، یوازې د لېږدوونکي ملګري د اجازې دننه محاسبه کېږي.
• د هر ملګري لپاره د راکړو ورکړو میټر. د هر لېږدوونکي ملګري لپاره د ټوکن یو سطل، په یوه ځل 16، چې په هره ثانیه کې 4 بیا ډکېږي (PEER_TX_BURST، PEER_TX_PER_SEC). دا هغه ملګری اندازه کوي چې راکړه ورکړه یې لېږلې ده، نه د هغې لیکوال، ځکه پټ زنځیر د هغه نوم نشي ښودلی.
• د پرېکړو کش. هغه راکړه ورکړه چې دې نوډ مخکې د داسې یو دلیل له امله رد کړې وي چې یوازې د هغې په بایټونو پورې اړه لري، لکه ناسم ثبوت، ناسم لاسلیک یا له حده لویه برخه، د 8,192 ننوتو FIFO کش (REFUSED_CACHE_ENTRIES) څخه بیا ردېږي او دوهم ځل نه تاییدېږي. هغه پرېکړه چې د دې نوډ د حالت په اړه څه وايي، لکه نامعلوم لنګر یا لګول شوی nullifier، هېڅکله کش نه کېږي: که داسې نه وي، یو نوډ چې یو بلاک وروسته وي، ځان به د هغو راکړو ورکړو پر وړاندې مسموم کړي چې ډېر ژر سمې کېږي. دا لېست د اجازې لېست دی، نو نوې تېروتنه تر هغه حالت ګڼل کېږي چې څوک بل ډول پرېکړه وکړي. دا ننوتې ښيي چې کرښه چېرته تېرېږي:
  • BadPauseSignature (the pause signature does not verify) له v0.6.8 راهیسې دایمي نه ده (audit v6, BRG-18). دا لاسلیک د زنځیر د ځنډولو د اوسنۍ کلي له مخې ازمويي، چې د پل قواعد v2 یې بدلولی شي، نو دا حالت دی: که داسې نه وای، یو نوډ چې د کلي له بدلون څخه یو بلاک وروسته وي، د نوي لرونکي PauseMints به تر بیا پیلېدو پورې رد کړې وای. د PQ ګډ لاسلیک له حد څخه بهر شاخص هم د همدې دلیل له امله له کش څخه وویستل شو. تر v0.6.7 پورې، په 18 او 19 زنځیرونو کې، دواړه د دایمي په توګه کش کېدل. اوس د ځنډولو یو تکراري ناسم پیغام په هر رسېدو کې د Dilithium2 یو تایید لګوي، چې د هر ملګري میټر یې محدودوي.
  • PrunedFormOutsideSync په قصدي ډول دایمي نه ده. د یوې مهر شوې بنډل نښه شوې بڼه د خامې راکړې ورکړې خپل id ته هش کېږي، او کش په همدې id کلي کېږي، نو د رد کش کول به هر ګاسیپ ملګري ته اجازه ورکړي چې صادقه راکړه ورکړه په ټوله شبکه کې سانسور کړي.
  • د ثبوت اعلان شوی د ګاز حد د هغه خپل بایټونه دي چې د جینیسس له یوه ثابت سره پرتله کېږي، نو BundleGasLimit او AuthGasLimit دایمي دي. FeeTooLow دایمي نه ده: په 20 زنځیر کې لږترلږه فیس له بیو سره بدلېږي. د څلورم ګام د سرلیک درې پالیسۍ هم هېڅکله نه کش کېږي: هره یوه د دې جوړښت پوهه ده، چې وروستی جوړښت یې بدلولی شي.
  • په هغه زنځیر کې چې د فاوسټ د اجازې لېست لري (20 زنځیر)، FaucetRecipientNotAllowed دایمي ده: دا د mint خپل ترلاسه کوونکی د جینیسس له یوه ثابت سره پرتله کوي. FaucetBudgetExhausted دایمي نه ده: دا حالت دی، او همغه mint په راتلونکي epoch کې بیا منل کېږي.
  • د ټوکن د عمل BadSignature هم دایمي نه ده، د سټېکینګ د عمل برعکس: د ټوکن د mint واک حالت دی، یو SetAuthority یې بلې کلي ته سپارلی شي، او همغه بایټونه د دې بدلون له تثبیت مخکې ردېدلی او وروسته منل کېدلی شي. د بایټ په کچه د ټوکن ردونه (ناسم نوم یا سمبول، ډېر اعشاري ځایونه، صفر مقدار، د ټوکن شاخص 0) کش کېږي؛ همداراز د سوځولو هغه ساحه چې عمل یې نشي ټاکلی، هغه mint چې ژمنه یې خپل مقدار ته نه پرانیستل کېږي، او د پل هغه زېرمه چې ړندوونکی یې مشتق شوی نه وي.

د فاوسټ حد

rand_mint بې فیسه دی او په هر ځل غوښتلو کې په ډنډ کې یوه راکړه ورکړه نیسي، او په 20 زنځیر کې فاوسټ فعال دی او شاته یې یو پل دی چې ارزښت ساتي. جینیسس هغه څه محدودوي چې دا یې کولی شي: یو mint یوازې 16 اجازه لرونکو والټونو ته او په هر 1,000 بلاکي epoch کې تر 10,000 RAND پورې ورکوي (سټېکینګ)، او یوازې د جینیسس د staking.faucet_minters لېست له 18 کلیو څخه یوه یې لاسلیکولی شي (MinterNotAllowed، هېڅکله نه کش کېږي: له 16 زنځیر راهیسې د لیجر قاعده، او په 15 زنځیر کې د نوډ پالیسي، چېرې چې لېست د جینیسس تصدیقوونکي وو). سربېره پر دې، هر نوډ خپل فاوسټ اندازه کوي: اته mint پرله پسې، چې په هره ثانیه کې یو بیا ډکېږي (FAUCET_MINT_BURST، FAUCET_MINT_PER_SEC). له دې هاخوا غوښتنه دا ځواب ورکوي: faucet is rate limited on this node (8 mints back to back, refilling at 1/s); try again shortly. حد د نوډ په هره پروسه دی، نه د هر غوښتونکي لپاره، ځکه چې د RPC پورټ د اندازه کولو لپاره د ملګري هویت نه لري او ساتل شوې سرچینه د دې نوډ ډنډ دی. د پورته ذکر شوې ظرفیت له معافیت سره یوځای، د فاوسټ سیلاب نشي کولی ډنډ د یوه PauseMints له مخه ډک کړي.

Gossipsub د اپلیکیشن په کچه له تایید سره چلېږي، نو یوه راکړه ورکړه نورو ملګرو ته یوازې هغه وخت لېږل کېږي چې دلته تایید شوې وي. هغه ملګری چې ناسمې راکړې ورکړې سیلاب کوي، د میټر له خوا محدودېږي، له کش څخه ځواب اخلي، او د اجماع په حلقه کې د هېڅ شي لګښت نه پېښوي.

د بلاک جوړول

کله چې یو تصدیقوونکی د یوه view مشري کوي، له ډنډ څخه کاندیدان غواړي. candidates_within یوازې هغه راکړې ورکړې ساتي چې په هغه لیجر چې پرې جوړوي لا هم پلي کېږي، او د منلو ارزانه نیمایي بیا چلوي: لنګر لا هم په کړکۍ کې وي، time لا هم په کې وي، nullifierونه لا نه وي لګول شوي، ژمنې لا نه وي موجودې. همداراز د ټوکن هغه عمل غورځوي چې زنځیر یې له mint_nonce یا د ثبت له شاخص څخه تېر شوی وي، او هغه ځنډول یا لېست کول چې په زاړه nonce وي. له v0.6.8 راهیسې دا هره غوښتنه او invoke د هغه سر په نافذو بیو بیا قیمت کوي چې پرې جوړوي، د هغه ګاز حد له مخې چې د منلو پر وخت یاد ساتل شوی، او هغه یوه پرېږدي چې فیس یې اوس له خپل لږترلږه حد څخه ټیټ دی؛ دا په ډنډ کې پاتې کېږي، او کله چې بیې راښکته شي بیا وړاندې کېږي (audit v6, CH-9). په 20 زنځیر کې بیا پاتې نورې داسې ترتیبوي: لومړی حکومتولي، بیا د اوسني لږترلږه حد څخه د پورته فیس له مخې د راکړې ورکړې په هر KiB، بیا د فیس له مخې، تر ټولو لوړ لومړی، او مساوي حالتونه د هش له مخې پرې کېږي، نو هر صادق وړاندیزکوونکی چې په همغه ډنډ جوړوي همغه بلاک غوره کوي، او تر 2,000 راکړو ورکړو او د زنځیر د بلاک تر حد پورې ډکوي (MAX_BLOCK_TXS؛ max_block_bytes، په ډیفالټ ډول 4 MiB او په 20 زنځیر کې 20 MiB). بلاک د بایټونو کمښت لري، له همدې امله اضافي فیس په هر KiB حسابېږي. هغه زنځیر چې د gas برخه نه لري او هغه نوډ چې د ګاز پالیسي نه لري، دا کلي پرېږدي او د حکومتولۍ، فیس او هش له مخې ترتیبوي، لکه څنګه چې 15 زنځیر کاوه. لومړی حکومتولي د ځنډولو د تضمین بله نیمایي ده: یو PauseMints په قصدي ډول فیس نه ورکوي، ځکه باید له داسې والټ څخه کار وکړي چې RAND نه لري، نو ساده د فیس ترتیب به اضطراري بریک د هرې فیس ورکوونکې راکړې ورکړې شاته وغورځوي.

یوه بله قاعده هغه وخت پلي کېږي چې یوه غوښتنه یا invoke چمتو وي (audit v6, POOL-2؛ په هر زنځیر کې د نوډ پالیسي، نه د اعتبار قاعده). یوازې دوی د بایټ بیه ورکوي، او هغه لېږد چې له خپل ثابت بنسټ څخه لږ ډېر ورکوي، په هر KiB کې له دوی څخه لوړ درجه اخلي، نو د لېږدونو یوه لړۍ کولی شي یوه چمتو غوښتنه له هر بلاک څخه بهر وساتي. له همدې امله ثابت فیس لرونکې راکړې ورکړې په لومړي پړاو کې د بلاک تر ډېره درې څلورمه بایټونه نیسي؛ کله چې غوښتنې ځای پر ځای شي، هر پاتې ځای د شاته ساتل شویو لېږدونو په واسطه، د هغوی په ترتیب، ډکېږي. د بلاک هېڅ ځای نه ضایع کېږي، او که هېڅ غوښتنه چمتو نه وي هېڅ شی نه بدلېږي (فیسونه).

هغه راکړه ورکړه چې د پاتې ځای لپاره ډېره لویه وي، پرېښودل کېږي، نه دا چې د بلاک پای وي: یوه کوچنۍ چې شاته یې وي لا هم ځي. د 18 زنځیر یو لېږد شاوخوا 2.85 MB دی، یو 1.49 MB د بنډل ثبوت او یو 1.36 MB د اجازې ثبوت، نو د هغه 20 MiB بلاک د شاوخوا اوو لپاره ځای لري او د ډیفالټ 4 MiB بلاک د یوه لپاره. په 15 زنځیر کې، په هر لېږد کې د شاوخوا 1.43 MB سره، همغه 20 MiB څوارلس ځای کول. د بار لاندې فیس پرېکړه کوي چې کومې (فیسونه).

پرې کول

د هر تثبیت وروسته، prune له ډنډ څخه دقیقاً هغه څه غورځوي چې candidates_within به پرې ایښي وای: هغه راکړې ورکړې چې یادښت یې بل چا لګولی وي، ژمنه یې اوس موجوده وي، زنځیر یې له nonce یا د ثبت له شاخص څخه تېر شوی وي، یا لنګر یا time یې له کړکۍ څخه وتلی وي (په 20 زنځیر کې 1,024 بلاکونه، تر 19 زنځیر پورې 256). نو هغه بنډل چې د دوه ځله لګولو سیالي بایلي، پخپله ورکېږي، پرته له دې چې هېچا ته کومه تېروتنه وښيي. د rand_sendTransaction له خوا منل تثبیت نه دی: rand_getTransaction تر هغه وپوښتئ چې بلاک بېرته راکړي، او که د لنګر کړکۍ له هغه پرته تېره شي، بنډل په یوه تازه لنګر بیا جوړ کړئ او بیا یې وسپارئ.

څارل

rand_status دا راپور ورکوي: mempool_size، verify_queue (هغه راکړې ورکړې چې د کارکوونکي په تمه دي) او refused_cache (د پرېکړو په کش کې ننوتې). هغه verify_queue چې په 64 کې ولاړ وي پدې معنا ده چې ثبوتونه له هغه څخه ګړندي رسېږي چې څلور کارکوونکي یې تاییدوي، د ګرمې کلي سره هر یو شاوخوا 16 ms؛ هغه mempool_size چې وده کوي په داسې حال کې چې بلاکونه ډک پاتې کېږي، پدې معنا ده چې فیس، نه د رسېدو ترتیب، د شاملولو پرېکړه کوي.

هغه څه چې لا نشته

• بدلون نشته. د زنځیر 20 د ګاز او بایټ بیې په هر بلاک کې د یوې غوښتنې لږترلږه فیس بدلوي، تر خپلو پورتنیو حدونو پورې؛ د یوه لېږد لږترلږه فیس ثابت دی. په حوض کې پرته معامله په ورته نوټونو د لوړ فیس لرونکې معاملې په واسطه نه بدلېږي، ځکه د ټکر قاعده دا ردوي. هغه غوښتنه چې بیې یې له وسه ووځي په حوض کې پاتې کېږي او نه وړاندې کېږي، تر هغه چې بیې راټیټې شي یا یې د لنګر کړکۍ تېره شي. په v0.6.7 (زنځیرونه 18 او 19) کې، په حوض کې پرتې غوښتنې هغه لږترلږه فیس ساته چې پرې منل شوې وه، د بیې له لوړېدو وروسته هم وړاندې کېده، او د وړاندیز کوونکي په آزمایښتي تطبیق کې د FeeTooLow په توګه ناکامه کېده. د fullnode د بلاک د ځای سند د فیس له مخې ترتیب شوی ممپول له لوی بلاک څخه مخکې ګام ګڼي، او د بلاک په کچه راټولونه هغه څه ګڼي چې په هر بلاک کې پورتنی حد لوړوي.
• د عمر له مخې پای ته رسېدل نشته. په حوض کې پرته معامله یوازې په بلاک کې د شاملېدو، د بایټ په حد کې د ایستلو، یا د لنګر او وخت د کړکیو له لارې وځي: په زنځیر 20 کې 1,024 بلاکونه، چې د هر بلاک لپاره د 1.34 s په هغه کچه چې لټوونکي هلته راپور کړې، نږدې 23 دقیقې کېږي. تر زنځیر 19 پورې دا کړکۍ 256 بلاکونه وې، نږدې پنځه دقیقې.
• د ممپول RPC نشته. داسې کومه طریقه نشته چې پاتې معاملې لست کړي؛ په rand_status کې mempool_size او په rand_getMempoolInfo کې شمېر، بایټونه او تر ټولو زوړ عمر یوازینۍ لیدلوري دي، او لټوونکی یوازې ثبت شوي بلاکونه انډکس کوي.