تشغيل validator وaggregator

استخدم هذه الصفحة لتحديد حجم الجهاز قبل تشغيله. المدقِّق رخيص، أما الإثبات فلا: تنمو ذاكرة الإثبات نموًا حادًا مع مستواه (tier)، وهذا الرقم وحده هو ما يحدد ما إذا كان الجهاز قادرًا على أداء المهمة. كل رقم هنا قياس من testnet أو من سجلات fullnode. الأرقام غير النهائية موسومة بذلك.

ما يفعله كل دور

المدقِّقون والمراقبون لا يُثبتون أبدًا. التحويل المحمي (shielded) أو الاستدعاء تُثبته المحفظة التي ترسله، أو، لإثبات الحزمة وحده، مُثبِت اقترنت به تلك المحفظة (تشغيل عقدة). ولا يُثبت أي من مدقِّقي الأسطول شيئًا اليوم.

تجميع الكتل مبني لكنه غير مفعّل. فهو يحتاج إلى قسم aggregation في genesis. والسلسلة 20 لا تملكه: التجميع معطّل، كما في السلاسل من 9 إلى 19، ويرفض البناء البدء على genesis يحمل هذا القسم.

الأحجام في لمحة

المُثبِت أحادي الخيوط اليوم. عمل droplet بـ16 vCPU بنسبة 99% من نواة واحدة. زيادة الأنوية لا تُسرّع إثباتًا واحدًا؛ أما زيادة الذاكرة فهي التي تحدد ما إذا كان الإثبات سينتهي.

المدقِّقون والمراقبون

الذاكرة والمعالج

يعمل المدقِّقون الثمانية عشر الأصليون على droplets بسعة 2 GB. التحقق من إثبات رخيص:

الذاكرة التي يحتاجها المدقِّق للتحقق من إثبات استدعاء من المستوى 18 أو 20 مقيسة الآن جزئيًا، على حاسوب محمول بمعالج Apple-silicon وذاكرة 48 GB، بمعزل عن droplet الخاص بـDigitalOcean الذي أنتج كل إثبات: استغرق التحقق من إثبات transfer من المستوى 18 ما مقداره 50.2 ث بذروة RSS قدرها 3.66 GB (المترجَم) أو 49.6 ث (المفسِّر، دون تسجيل RSS منفصلة)؛ واستغرق التحقق من إثبات approve من المستوى 16 ما مقداره 12.2 ث (دون تسجيل RSS منفصلة). المستوى 20 غير مقيس، إذ لا يوجد بعد إثبات من المستوى 20 للتحقق منه. ومنذ v0.5.6 لا يبني المدقِّق أبدًا مفتاحًا بهذا الحجم: يُفحص رأس إثبات الاستدعاء قبل بناء أي مفتاح تحقق، ويُرفض أي استدعاء فوق المستوى 14 (أو بجدول keccak فوق 2^12، أو جدول sha256 فوق 2^13)، عند القبول وكقاعدة لصحة الكتلة. وبلغ أسوأ رأس استدعاء مقبول 4.7 ث و312 MB للتحقق.

لا يستطيع droplet بـ1 vCPU و2 GB بناء الملفات التنفيذية. ابنِها على جهاز أكبر وانسخها (انظر الإعداد).

القرص

على السلسلة 20، كما على السلسلة 19، يشغّل 24 من المدقِّقين الـ26 الخيار --prune-history 24h ويحتفظون بنحو يوم من الكتل؛ أما السجل نفسه (الملاحظات، وnullifiers، وanchors، والسجل register) فلا يُقلَّم أبدًا. أما الأرشيفان obs1 وrand-archive-2 (وكلاهما مدقِّق أيضًا) فيعملان دون هذا الخيار. وعقدة mainnet لا تمرّره أبدًا. ترفض العقدة البدء إذا كان المتاح أقل من --min-free-disk-mb (1,024 MB افتراضيًا) على نظام ملفات دليل بياناتها، ويجيب rand_getHealth بـdisk_low تحت أربعة أمثال ذلك؛ وإطلاق متدرّج ينتظر ok يتوقف عند عقدة توشك أن تمتلئ. انظر تقليم التاريخ لمعرفة ما تظل العقدة المُقلَّمة تجيب عنه.

احذف دليل بيانات السلسلة المتقاعدة بعد الانتقال. الأدلة مفهرسة بتجزئة التكوين (data-<name>-<hash8>: ‏-6210cf07 للسلسلة 20، و-a3defc93 للسلسلة 19؛ ويستخدم مضيفو الحراسة الستة /var/lib/randnode/data-20)، لذا تبقى الأدلة القديمة حتى تزيلها. عند الانتقال إلى السلسلة 20 ظهر أحد المدققين الإقليميين (syd1) بحالة disk_low مع 3.9 GB فارغة، وأبقى بدء التشغيل عند 25 من 26، لأن أدلة السلاسل من 14 إلى 17 كانت لا تزال عليه؛ وحذفها حرّر 22 GB. احتفظ بدليل السلسلة السابقة يوماً واحداً هدفاً للتراجع، ثم أزله. عند امتلاء الكتل يبلغ إثبات كل حزمة خام نحو 1.42 MB منذ السلسلة 14 (نحو 1.3 MB حتى السلسلة 13). ومنذ السلسلة 17 تحمل كل حزمة أيضاً إثبات تفويض، فيبلغ التحويل نحو 2.85 MB من الإثباتات: نحو 1.49 MB لإثبات الحزمة و1.36 MB لإثبات التفويض (ملف الإنتاج، قيس في 2026-09-29). وعندما يُفعَّل التجميع، يُقلَّص إثبات الحزمة المختومة إلى نحو 3 KB، ما لم تعمل العقدة بالخيار --keep-raw-proofs. ولا يشمل ذلك إثبات التفويض، الذي يبقى بحجمه الكامل.

الشبكة

افتح المنفذ TCP 30303 للاتصالات الواردة على العقدة العامة. أما العقد الواقعة خلف NAT فتتصل إلى الخارج باستخدام --bootstrap. وعند الكتل الكاملة بحجم 4 MiB يحمل رابط المدقق نحو 2 MB/s.

الساعة

يحتاج المدقق إلى NTP. السلسلة 14 هي أول سلسلة يدخل فيها وقت الساعة الفعلي في الإجماع (تحصين الجسر B2):

المدقق الذي تتأخر ساعته 20 s يتوقف عن التصويت بصمت: فهو يرى كل كتلة سليمة متقدمة على ساعته فيمتنع عن التصويت، دون أن يفشل شيء. وفي السلسلة 20 يجب أن يصوّت ثمانية عشر مدققاً من ستة وعشرين لإقرار أي شيء. افحص كل مدقق، وثبّت chrony حيث لا تكون الساعة متزامنة:

timedatectl                     # want "System clock synchronized: yes" and "NTP service: active"
chronyc tracking 2>/dev/null || timedatectl show-timesync --all 2>/dev/null
apt-get install -y chrony && systemctl enable --now chrony

ينطبق حد 15 s نفسه على كتلة التكوين. اضبط timestamp_ms قريباً من وقت الإطلاق ولا تجعله يسبقه أبداً: كتلة التكوين التي تسبق الوقت الحالي بأكثر من 15 s لا تُقرّ الكتلة 1 حتى يبلغ وقت الساعة وقتها، أما التي تتأخر عنه كثيراً فتترك زمن الكتلة خلف ساعة الحائط، ويلحق بها بما لا يزيد على 60 s لكل كتلة (docs/deploy.md). والمراقب لا يصوّت، فلا تسري عليه قاعدة التصويت.

أحجام DigitalOcean التي تعمل عليها testnet

يغطي هذا الجدول المدققين الثمانية عشر الأصليين. ومنذ 2026-09-27 يعمل المدقق A أيضاً على droplet (في sgp1) لا على حاسوب محمول. وأُودع ضمان ثمانية مدققين آخرين في السلسلة 15 (2026-09-27): الأرشيفان obs1 وrand-archive-2 (fra1)، ومضيفو الحراسة الستة. ولا تُسجَّل هنا أحجام droplets الخاصة بهم، ولا ما إذا غُيّر حجم mkc1 وmem1. وجميع المدققين الستة والعشرين هم مدققو تكوين في السلسلة 20، كما في السلسلة 19، بواقع 1,000 RAND لكل منهم، ومنذ 2026-09-30 تقع مفاتيح الستة والعشرين كلها بيد مشغّل واحد.

ذاكرة الإثبات

تُثبت المحفظة كل معاملة ترسلها، فيحتاج مستدعي البرنامج إلى الذاكرة اللازمة لطبقة ذلك البرنامج. هذه هي الحدود المقيسة. اكتملت عمليات الطبقة 18 وأُثبتت وتُحقق منها على DigitalOcean؛ أما الطبقة 20 فلم تكتمل. منذ v0.5.6 ترفض السلسلة إثبات استدعاء أعلى من الطبقة 14 (MAX_CALL_TIER)، لذا فإن صفوف الطبقات 16 و18 و20 أدناه قياسات لا استدعاءات تقبلها السلسلة 20؛ وكل استدعاء أُقرّ في السلسلة 14 كان من الطبقة 10.

تقع استدعاءات ERC-20 عند الطبقتين 16 و18، وSPL Token عند الطبقة 20 (Ethereum، Solana). ولم يُنتج أي إثبات من الطبقة 18 أو 20 على جهاز بذاكرة 48 GB.

المُجمِّعون

يراقب المُجمِّع السلسلة، ويأخذ إثباتات الحزم لنافذة من الكتل النهائية، ويُثبت تجميعاً تعاودياً واحداً فوقها، ثم يرسله. وتسمى الكتلة التي تتضمنه كتلة ختم. ويُدفع للمُجمِّع حصة الإثبات للحزم المشمولة إضافةً إلى إعانة الكتلة من RAND جديد، إلى عنوان الدفع المسجَّل له. والتجميع بلا إذن: يستطيع أي مشغّل لديه ضمان أن يسجّل.

وهو لا يوجد إلا في سلسلة يحتوي تكوينها على قسم aggregation. والسلسلة 20 لا تحتوي عليه، ويرفض إصدارها البدء على تكوين يحتوي عليه.

العتاد

قيست أرقام N = 2 وN = 3 على droplet من DigitalOcean بذاكرة 256 GB في 2026-09-28/29، في مجموعة القيود 7، واحتاج إثبات خروج الإنتاج إلى أكثر من 256 GB لتلك الآلة. ولم يُعد قياس أيٍّ منها في مجموعة القيود 8 التي تعمل بها السلاسل من 18 إلى 20، فعامِل صف N = 1 بوصفه حداً أدنى. وقد عملت خلفية CUDA أول مرة على عتاد حقيقي في 2026-09-28، على NVIDIA H100: تُبنى نواتها إلى PTX للمعماريتين sm_80 وsm_90 وتطابق مرجع CPU. أما قياس الإنتاج على عقدة GPU في الأسطول فلا يزال مطلوباً. وتتحمل كل عقدة أيضاً كلفة بناء مفاتيح لمرة واحدة عند بدء التشغيل لبرنامج التجميع: من 13.0 إلى 13.4 s في ملف الاختبار (2¹⁹)، والمتوقع من 30 إلى 70 s في الإنتاج (2²¹).

الأوامر

# print a signed registration; the bond burns out of a wallet bundle as the register bundle's burn
rand-node aggregator register --key agg.key.json --bond <RAND> --payout rand1… --rpc http://127.0.0.1:8545

# the daemon: poll rand_getUnsealed, fetch the raw bundles, prove, seal the payment note, submit
rand-node aggregate --key agg.key.json --rpc http://127.0.0.1:8545 --watch

# leave, then withdraw the released bond into a note at the payout address
rand-node aggregator unbond --key agg.key.json --rpc http://127.0.0.1:8545
rand-node aggregator withdraw --key agg.key.json --rpc http://127.0.0.1:8545

يعرض rand status قسم aggregation على سلسلة كهذه: المُجمِّعون المسجَّلون، والكتل غير المختومة، وفهرس جدول الإعانة. وrand_getUnsealed هي قائمة العمل.

الإعداد

تتبع هذه الخطوات السكربتات التي تستخدمها testnet (deploy/vps-setup.sh وdeploy/update-droplet.sh). وهي تُنتج مدقِّقًا أو مراقِبًا على Linux.

1. البناء على مضيف بناء

يتطلب البناء build-essential clang cmake pkg-config libssl-dev، وRust 1.98.1 (مثبَّت بواسطة rust-toolchain.toml)، ونسخة circuits مجاورة لنسخة fullnode. يستغرق البناء الأول من 10 إلى 20 دقيقة.

git clone https://github.com/randprotocol/fullnode
git clone https://github.com/randprotocol/zkp-circuits circuits
cd fullnode
git checkout v0.6.8                       # c9c9bd3c, the build chain 20 runs
git -C ../circuits checkout "$(sed -n 's/^circuits: //p' crates/randprotocol-zkvm/guests-compiled/PROVENANCE.md)"   # aeacf31 for v0.6.8
git show origin/main:deploy/genesis-chain20.json > deploy/genesis-chain20.json   # committed after the tag
cargo build --release -p randprotocol-node -p randprotocol-client
sha256sum target/release/rand-node         # compare on every node you copy it to

تحتاج السلسلة 20 إلى v0.6.8 على كل عقدة قبل init. يحمل genesis الخاص بها حقولًا لا تقرؤها أي نسخة أقدم (testnet وbinding_domain وproof_window_blocks وprogram_state ومجموعتا rotation وfees للجسر وسقوف الغاز وقبول التخزين بالتصويت)، وتحمل v0.6.8 تغييرَي الإجماع CON-4 وCH-1 من التدقيق v6. وما زالت البراهين تُنتَج وفق مجموعة القيود 8، كما في السلسلتين 18 و19، مع برهان تفويض إلى جانب كل برهان حزمة (hc_auth). ترفض نسخة v0.6.8 genesis السلاسل من 14 إلى 17 عند run وverify. شغّل البناء الواحد نفسه الذي يشغّله الأسطول. ملف genesis موجود في فرع main الخاص بـ fullnode (الإيداع 74cfaca0)، وليس في الوسم v0.6.8، ومن هنا سطر git الثالث. يجب أن تكون نسخة circuits عند الإيداع الذي اشتُقّ منه الإصدار، وهو ما يقرأه سطر git الثاني أعلاه من شجرة fullnode. أضف -p randprotocol-prover لبناء rand-prover أيضًا.

2. تثبيت الملفات التنفيذية على العقدة

scp target/release/rand-node target/release/rand deploy/genesis-chain20.json root@<node>:/root/
ssh root@<node> 'install -m 755 /root/rand-node /root/rand /usr/local/bin/'

3. المفتاح وgenesis وجدار الحماية

على العقدة:

install -d -m 700 /root/keys
test -e /root/keys/node.key.json || rand-node keygen --out /root/keys/node.key.json   # prints the address; keep the seed secret
rand-node init --datadir /root/data-6210cf07 --genesis /root/genesis-chain20.json
timedatectl                                        # "System clock synchronized: yes" (see Clock)
ufw allow 22/tcp && ufw allow 30303/tcp && ufw enable

ولِّد المفتاح على العقدة نفسها كما سبق، وأبقِه خارج أي نسخة مستودع. لم يعد أي مفتاح متتبَّعًا في مستودع fullnode (التدقيق v3، OPS-1). أما ملفات deploy/node-*.key.json المودَعة للسلاسل من 8 إلى 13 فهي بذور منشورة؛ أما مفاتيح مدقِّقي السلسلة 20 (الثمانية عشر المولَّدة للسلسلة 14 والثمانية المربوطة على السلسلة 15) فقد وُلِّدت خارج المستودع، ويحتفظ الأسطول بمفتاح كل droplet في /root/keys/node-<name>.key.json، خارج شجرة المصدر. ويهم الموقع على عقدة جُهِّزت بسكربتات الأسطول: فـ deploy/rebuild-vps.sh وdeploy/push-to-vps.sh يزامنان /root/fullnode عبر rsync مع --delete، فيُحذف المفتاح المحفوظ داخل تلك الشجرة عند إعادة البناء التالية، ثم تفشل الوحدة في إعادة التشغيل. منذ v0.6.8 يرفض keygen الكتابة فوق ملف موجود (وكانت v0.6.7 تكتب فوقه دون سؤال)؛ ويُبقي test -e السطر آمنًا عند إعادة تشغيله في الحالتين. انسخ المفتاح احتياطيًا خارج المضيف قبل ربطه.

يطبع init تجزئة genesis. ويجب أن تكون 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135 (السلسلة 20). ملف genesis هو genesis-chain20.json في deploy/ ضمن مستودع fullnode على main. سمِّ دليل البيانات بأول ثمانية أحرف من التجزئة، كما يفعل الأسطول (data-<name>-6210cf07)، حتى لا يتعارض أبدًا مع دليل السلسلة 19 (-a3defc93) ولا مع دليل سلسلة لاحقة. يحدد genesis هذه الحدود. كان سقف البرهان 8 MiB على السلاسل من 13 إلى 16، وهو 4 MiB منذ السلسلة 17، حيث صارت المعاملة تحمل حتى ثلاثة براهين:

ويحمل genesis السلسلة 20 كذلك consensus_domain: 1 وbinding_domain: 1 وtestnet: true، وقسم staking مع القبول بالتصويت، وقسم gas مع سقوف الأسعار، ومجموعتي rotation وfees للجسر، وhardening_v6، وتثبيتَي guest هما hc_bundle وhc_auth؛ ويسرد تشغيل عقدة ما تضبطه.

4. وحدة systemd

هذه هي الوحدة التي يكتبها deploy/vps-setup.sh، بالمسارات المذكورة أعلاه:

[Unit]
Description=RAND full node
After=network-online.target
[Service]
Environment=RUST_LOG=info,libp2p=warn,libp2p_mdns=off
ExecStart=/usr/local/bin/rand-node run --datadir /root/data-6210cf07 --key /root/keys/node.key.json --validator --listen /ip4/0.0.0.0/tcp/30303 --rpc 127.0.0.1:8545 --no-mdns --prune-history 24h --bootstrap <multiaddr> --bootstrap <multiaddr>
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target

احذف --validator للحصول على مراقِب. إن --prune-history 24h هو ما يشغّله مدقِّقو testnet، عدا الأرشيفات؛ احذفه لعقدة تحتفظ بالتاريخ الكامل، ولا تمرّره أبدًا على mainnet. عناوين multiaddr للإقلاع للسلسلة 20 هي العقد C (fra1) وD (ric1) وE (sgp1)، دون تغيير عن السلسلة 19. تعمل السلسلة 20 بمفاتيح المدقِّقين المولَّدة للسلسلة 14، وهوية p2p مشتقة من مفتاح المدقِّق، فمعرّفات الأقران هذه هي نفسها التي استخدمتها السلسلة 14. وتحتاج العقدة الجديدة التي تتزامن من genesis أيضًا إلى قرين يحتفظ بالتاريخ الكامل، فأضف أحد الأرشيفين (obs1 ثم rand-archive-2):

/ip4/164.90.239.200/tcp/30303/p2p/12D3KooWEQEbUwZRgqhDPXhW7vNBmcRcnhUDGUADe81VFdv3ALYe
/ip4/165.245.173.74/tcp/30303/p2p/12D3KooWJyc5oDHggAr89e9QrRFBy9Tg8TxXh18yzrb1SM6KKLYw
/ip4/188.166.235.187/tcp/30303/p2p/12D3KooWSyX84P1DAbWByLHpRBMLRWD53r3Jj4aqVt6tHoF8B2ZQ
/ip4/168.144.46.203/tcp/30303/p2p/12D3KooWS5usdMPvsbaWSaT2xtKndHvDYurwmueoNvaRRarb2wRf
/ip4/206.81.29.236/tcp/30303/p2p/12D3KooWPocyZGcNB9Vp68VSfgVvNXhSzBBoJa4h9R1yMkp71XHh

أبقِ RPC على 127.0.0.1 ما لم يحمِه جدار حماية. وعلى العقدة التي ينبغي أن تخدم الجمهور أن تفتح المستمِع العام في v0.6.8 إلى جانبه (--public-rpc <ADDR>) وأن تضع الوكيل أمامه، وليس أمام --rpc أبدًا (JSON-RPC). ويجب ألا تمرّر وحدة منقولة من v0.6.7 العلم --prover-accept-spend-key، الذي ترفضه v0.6.8 عند بدء التشغيل.

systemctl daemon-reload && systemctl enable --now rand-node
journalctl -u rand-node -f
rand status                       # height climbing, peer_count rising

5. الانضمام إلى مجموعة المدقِّقين

المفتاح الجديد ليس ضمن مجموعة أي حقبة. وعلى السلسلة 20 يجب أولًا التصويت على قبوله: إذ يضبط genesis الخاص بها staking.admission_by_vote، فيوقّع المدقِّقون الذين يملكون أكثر من ثلثي وزن التصويت كلٌّ منهم عليه بالأمر rand-node admit sign --candidate <key or registration> --key <validator key> --genesis-hash <chain 20's hash>، ويرسل أحدهم الأصوات بالأمر rand-node admit submit؛ ثم يسرده rand_getAdmitted. بعد ذلك اربط له ما لا يقل عن 1,000 RAND: اطبع تسجيلًا بالأمر rand-node register --key /root/keys/node.key.json --payout rand1… --v2 (ترفض السلسلة 20 التسجيل v1)، ثم اربط من محفظة بالأمر rand bond <address> 1000 --registration <hex>. ينتظر الربط حقبة تفعيله، أي ثلاث حدود من 1,000 كتلة بعد إيداعه على أقرب تقدير، ولا يصير أكثر من 2,500 bps من الوزن النشط وزنًا جديدًا عند كل حد (وكانت السلسلة 19 تحدّه بـ 10,000 RAND ثابتة). يشرح التخزين الخطوات.

6. التحديث

ينطبق هذا على بناء يشغّل السلسلة نفسها. أما الانتقال من سلسلة أقدم إلى السلسلة 20 فليس تحديثًا: فهو يحتاج إلى الملف التنفيذي الجديد وgenesis الجديد ودليل بيانات جديد، ويمكن حذف دليل بيانات السلسلة القديمة بعد ذلك (deploy/retire-chain-dirs.sh؛ ويبقيه الأسطول يومًا للتراجع). ولطرح بناء جديد دون قطع سلسلة: ابنِ مرة واحدة، وقارن sha256 لكل من rand-node وrand، وأوقف الخدمة، وثبّت، ثم أعد التشغيل، عقدة واحدة في كل مرة. وبعض الإصدارات تُطرح بإيقاف الجميع ثم تشغيل الجميع بدلًا من ذلك (قاعدة طبقة الاستدعاء في v0.5.6، وتغيير سلك Status في v0.5.7، والتحقق الأشد من البراهين في v0.6)؛ وتذكر ملاحظات كل إصدار أيّهما. طُرحت v0.6.7 على السلسلة 18 عقدةً عقدة؛ أما v0.6.8 فجاءت مع السلسلة 20، بإيقاف الجميع ثم تشغيل الجميع، لأن تغييرَي الإجماع CON-4 وCH-1 فيها يجب ألا يُطرحا عقدةً عقدة أبدًا. انتظر انضمام كل عقدة من جديد قبل التالية، حتى لا ينقص النصاب بأكثر من واحد. وdeploy/update-droplet.sh <ip> [build-host] يفعل ذلك تمامًا عبر SSH.

الإصدارات حتى v0.6.8 بُنيت يدويًا على مضيف واحد وهي غير موقَّعة. يحمل إصدار v0.6.8 على GitHub الملفات rand-node وrand وrand-prover وSHA256SUMS، وقد بُنيت على العقدة E؛ ويكشف هذا المجموع التحققي تنزيلًا تالفًا ولا يضمن سلامة مضيف البناء. تأتي v0.6.8 بسير عمل إصدار يبني الملفات التنفيذية من الوسم، ويرفض deploy/update-droplet.sh أي تثبيت دون SHA256SUMS موقَّع ما لم تُضبط ALLOW_UNSIGNED=1. ولا يسرد deploy/release-signers أي مفتاح بعد، فلم يُستخدم المسار الموقَّع.

دخلت السلاسل 15 و16 و17 و18 مرحلة التشغيل خلال 2.7 يوم (من 2026-09-26 إلى 2026-09-29)، وكلٌّ منها بإيقاف كامل للأسطول. ثم تلتها السلسلة 19 في 2026-10-01 عند 03:43 UTC، وهي إعادة genesis للسلسلة 18 على البناء نفسه، والسلسلة 20 في اليوم نفسه عند 06:17 UTC، مقتطعة من لقطة للسلسلة 19 عند الانقسام الصلب v0.6.8؛ وتوقفت كل العقد عند ارتفاع 7,700 للسلسلة 19. وتسري سياسة قطع مكتوبة (2026-09-30) منذ السلسلة 20؛ وقد أعفى سجلّ قطع السلسلة 20 من إعادة بناء المشغّل الثاني، لأن مشغّلًا واحدًا يحتفظ بكل المفاتيح. ويحتاج القطع إلى سبب لا يستطيع التحديث المتدرج تلبيته، وقائمة منشورة بما يحمله وما يسقطه، وقائمة تحقق لإعادة بناء العملاء أُنجزت مسبقًا، ومشغّلًا ثانيًا يعيد بناء genesis إلى التجزئة نفسها، وخطة تراجع، ومعرّف سلسلة لم يُستخدم من قبل.