"سلاسل دوران. دمج. تحسين. لا كمال أبداً. الكمال هدف يتغير."
— Abathur، StarCraft II: Heart of the Swarm
Kerrigan هي عملة رقمية متعددة الخوارزميات بإثبات العمل تجمع بين تنوع الأجهزة وخصوصية المعرفة الصفرية وطبقة إجماع جديدة قائمة على الختم تُسمى بروتوكول Hivemind. تعمل أربع خوارزميات تعدين (X11 وKawPoW وEquihash 200,9 وEquihash 192,7) في وقت واحد منذ كتلة التكوين، كل منها بتعديل صعوبة مستقل مستمد من نهج DigiByte متعدد الخوارزميات. توفر معاملات zk-SNARK المحمية من Sapling للمستخدمين خيار الخصوصية الكاملة للمعاملات. يضيف بروتوكول Hivemind بُعداً ثانياً للإجماع فوق PoW، حيث يقوم المعدنون بشكل جماعي بختم الكتل من خلال شهادات موقعة بـ BLS واختيار لجان عشوائي قابل للتحقق. يُطلق الإصدار V1 كسلسلة تركز على التعدين مع عقد رئيسية وحوكمة على السلسلة. يوسع الإصدار V2 الشبكة إلى حوسبة GPU للاستدلال بالذكاء الاصطناعي، معيداً توجيه مكافآت الكتل لتحفيز مزودي الاستدلال إلى جانب المعدنين.
تعتمد معظم سلاسل الكتل بإثبات العمل على خوارزمية تعدين واحدة. يخلق هذا شبكة هشة حيث يمكن لمصنع أجهزة واحد أو تصميم ASIC واحد أن يهيمن على معدل التجزئة، ويمكن لثغرة خوارزمية واحدة أن تُعرّض السلسلة بأكملها للخطر. يُعدَّن SHA-256 الخاص ببيتكوين حصرياً تقريباً بواسطة أجهزة ASIC المتخصصة. تعرض Ethereum Classic باستخدام Ethash لهجمات 51% متكررة بعد انتقال معدني GPU إلى Ethereum بإثبات الحصة. السلاسل أحادية الخوارزمية تُركّز المخاطر.
الخصوصية هي الفجوة الأخرى. تكشف سلاسل PoW الشفافة كل معاملة للتحليل العام. يمكن لشركات تحليل السلاسل تتبع الأموال عبر القفزات وربط العناوين بالهويات وبناء ملفات مالية كاملة. بعض السلاسل تُضيف خصوصية اختيارية كفكرة لاحقة؛ وأخرى تضحي بالشفافية بالكامل. لا يخدم أي من الطرفين المستخدمين بشكل جيد.
تعالج Kerrigan كلتا المشكلتين. أربع خوارزميات تعدين تضمن عدم احتكار أي فئة أجهزة واحدة لإنتاج الكتل. يتنافس معدنو ASIC على X11 بينما ينتشر معدنو GPU عبر KawPoW وEquihash 200,9 وEquihash 192,7. لكل خوارزمية تعديل صعوبة خاص بها، لذا لا تؤدي تحولات معدل التجزئة بين الخوارزميات إلى زعزعة استقرار الشبكة. توفر معاملات zk-SNARK المحمية من Sapling خصوصية مشفرة للمستخدمين الذين يريدونها، دون إزالة طبقة المعاملات الشفافة.
بُنيت السلسلة على تفرع من Dash، وورثت قائمة العقد الرئيسية الحتمية (DIP3) والخدمات القائمة على النصاب (LLMQ) ونظام spork للتفعيل الآمن للميزات. أزلنا ما لم نحتجه، واستبدلنا ما لم يناسب، وبنينا أنظمة جديدة حيث قصّر الكود الموروث. محرك PoW متعدد الخوارزميات ودمج Sapling وبروتوكول Hivemind كلها أصلية في Kerrigan.
تُشغّل Kerrigan أربع خوارزميات تعدين بالتوازي، جميعها نشطة من كتلة التكوين. يُعدَّن كل كتلة بواسطة خوارزمية واحدة بالضبط، ويتم ترميز الخوارزمية مباشرة في حقل إصدار الكتلة.
X11 هي دالة التجزئة الأصلية لـ Dash: إحدى عشرة دالة تشفيرية متسلسلة (BLAKE وBMW وGroestl وJH وKeccak وSkein وLuffa وCubeHash وSHAvite وSIMD وECHO). يمكن تعدينها بأجهزة ASIC، مما يعني أن معدل تجزئة X11 سيهيمن عليه على الأرجح أجهزة متخصصة. هذا مقصود. توفر أجهزة ASIC تجزئة متسقة وعالية الإنتاجية تُثبّت الطبقة الأساسية.
KawPoW هو متغير ProgPoW الخاص بـ Ravencoin، وهو خوارزمية محسّنة لـ GPU تقاوم تطوير ASIC من خلال توليد البرامج العشوائية. تنفيذ KawPoW في Kerrigan متوافق سلكياً مع Ravencoin، مما يعني أن معدني RVN الحاليين يمكنهم توجيه أجهزتهم إلى مجمعات Kerrigan بأقل تكوين. تحمل كتل KawPoW حقول رأس إضافية: nHeight وnNonce64 (رقم عشوائي 8 بايت) وmix_hash (32 بايت).
Equihash 200,9 هي خوارزمية Zcash كثيفة الذاكرة. تتطلب معلمات (200,9) حوالي 700 ميجابايت من الذاكرة العاملة لكل محاولة حل. توجد أجهزة ASIC لـ Equihash 200,9 (أبرزها سلسلة Bitmain Z9)، لذا هذا المسار ليس حصرياً لـ GPU. تستخدم Kerrigan تنسيق رأس متوافق مع Zcash بحجم 140 بايت: 108 بايت من CEquihashInput (الإصدار، التجزئة السابقة، جذر ميركل، التجزئة المحجوزة، الوقت، البتات) بالإضافة إلى nNonce256 بحجم 32 بايت. يتم تسلسل الحلول بحد أقصى 1400 بايت.
Equihash 192,7 تستخدم معلمات مختلفة تقلل متطلبات الذاكرة مقارنة بـ (200,9) مع الحفاظ على مقاومة ASIC. اشتُهرت مجموعة معلمات (192,7) من خلال ZClassic وتفرعات Equihash الأخرى. نفس تنسيق الرأس كـ Equihash 200,9 لكن بمساحة حل ومنحنى صعوبة خاصين بها.
يتم ترميز خوارزمية التعدين في البتات من 8 إلى 11 من حقل nVersion الخاص بالكتلة، باستخدام قناع 0x0F00:
| الخوارزمية | التعداد الداخلي | بتات الإصدار | السداسي عشري |
|---|---|---|---|
| X11 | ALGO_X11 = 0 | 0 << 8 | 0x0000 |
| KawPoW | ALGO_KAWPOW = 1 | 2 << 8 | 0x0200 |
| Equihash 200,9 | ALGO_EQUIHASH_200 = 2 | 4 << 8 | 0x0400 |
| Equihash 192,7 | ALGO_EQUIHASH_192 = 3 | 6 << 8 | 0x0600 |
تُستخدم قيم التعداد الداخلية (0-3) في الكود لفهرسة المصفوفات. تستخدم بتات الإصدار تباعداً زوجياً (0، 2، 4، 6) لترك مجال لخوارزميات مستقبلية. التعيين بينها هو عملية بحث وليس إزاحة بتات مباشرة لقيمة التعداد.
أي كود يفحص nVersion لإشارات التفرع الناعم BIP9 يجب أن يُزيل البتات 8-11 أولاً. يتخطى WarningBitsConditionChecker هذه البتات لتجنب التنبيهات الكاذبة.
تستخدم Kerrigan تجزئتين مميزتين لكل كتلة: تجزئة هوية للفهرسة وتجزئة إثبات العمل للتحقق من التعدين.
تجزئة الهوية هي X11 محسوبة على الرأس الأساسي للكتلة. لكتل X11 وKawPoW، هذا هو الرأس القياسي بحجم 80 بايت (الإصدار، التجزئة السابقة، جذر ميركل، الوقت، البتات، الرقم العشوائي). لكتل Equihash، حجمه 140 بايت (الإصدار، التجزئة السابقة، جذر ميركل، hashReserved، الوقت، البتات، nNonce256). هذا ما يشير إليه hashPrevBlock، وما تُرجعه استدعاءات RPC، وما يستخدمه فهرس السلسلة. يُستخدم X11 لتجزئة الهوية على جميع الخوارزميات بحيث يمكن لكل عقدة فهرسة كل كتلة بنفس الطريقة.
تجزئة إثبات العمل خاصة بالخوارزمية وتلتزم بجميع الحقول الحرجة للإجماع لتلك الخوارزمية:
يعني تصميم التجزئتين هذا: توفر تجزئة الهوية معرّف كتلة مستقر وموحد عبر جميع الخوارزميات، بينما تضمن تجزئة PoW أن الحقول الخاصة بالخوارزمية (الحلول، تجزئات المزج، الأرقام العشوائية الممتدة) ملتزمة بالكامل ومقاومة للتلاعب. انظر الملحق أ للتخطيطات الدقيقة للبايتات المتسلسلة لكل خوارزمية.
لكل خوارزمية صعوبة مستقلة خاصة بها، يتم تعديلها باستخدام مخطط مشتق من صعوبة DigiByte متعددة الخوارزميات (DigiShield v4). المعلمات:
تعني هذه الصعوبة لكل خوارزمية أن تدفقاً مفاجئاً من معدني GPU على KawPoW لن يؤثر على صعوبة X11 أو صعوبة Equihash. تجد كل خوارزمية توازنها الخاص بشكل مستقل.
يتبع العرض جدول تنصيف قياسي: 25 KRGN لأول 1,051,200 كتلة، ثم 12.5، ثم 6.25، وهكذا. تتقارب السلسلة الهندسية إلى 52,560,000 KRGN إجمالاً.
تُقسَم معاملة coinbase لكل كتلة مكافأة 25 KRGN على خمسة أوجه:
| المستلم | الحصة | KRGN/كتلة | الوصاية | الغرض |
|---|---|---|---|---|
| صندوق النمو | 40% | 10.00 | ضمان مقفل بالإجماع | إدراجات المنصات، الشراكات، تطوير النظام البيئي |
| المعدنون | 20% | 5.00 | إصدار فوري | مكافأة كتلة PoW |
| العقد الرئيسية | 20% | 5.00 | إصدار فوري | خدمات الشبكة (تذهب للمعدن إذا لم تُسجَّل عقد رئيسية) |
| الخزينة | 15% | 3.75 | توقيع متعدد 2-من-3 | التكاليف التشغيلية، التسويق، المجتمع، رواتب الفريق |
| المطورون / المؤسسون | 5% | 1.25 | إصدار فوري | تعويض المؤسسين والتزام مستمر بالمشروع |
صندوق النمو ليس خزينة. إنه ضمان مقفل بالإجماع لا يمكن للفريق إنفاقه دون موافقة العقد الرئيسية (انظر القسم 3.4). تخصيصات الخزينة والمطورين/المؤسسين (20% مجتمعة) هي ميزانية تشغيل المشروع، مماثلة لصندوق تطوير Zcash التاريخي بنسبة 20%. عنوان الخزينة هو محفظة P2SH متعددة التوقيع 2-من-3 تتطلب اثنين من ثلاثة حاملي مفاتيح لتفويض أي إنفاق. إذا لم تُسجَّل عقد رئيسية على الشبكة، تبقى حصة العقدة الرئيسية 20% مع المعدن كآلية تدهور رشيق.
ليس لدى Kerrigan تمويل مغامر ولا طرح أولي للعملة ولا تعدين مسبق ولا بيع عملات. تعمل الأجهزة من الجيب الشخصي. الكود مكتوب من قبل الفريق. لا يوجد صندوق حرب بقيمة 5 ملايين دولار في توقيع متعدد من جولة تمويل أولية.
هذا يعني أن الشبكة يجب أن تمول نموها الخاص. إدراجات المنصات وتوفير السيولة ونشر الجسور وصفقات الشراكة تكلف أموالاً حقيقية، وبدون تمويل خارجي، السلسلة نفسها هي المصدر الوحيد. ضمان النمو هو الآلية التي تحوّل العملات المعدنة إلى أصل قابل للتداول. لا إدراج في المنصات يعني لا سيولة. لا سيولة تعني أن العملات التي يكسبها المعدنون لا قيمة لها.
يتراكم ضمان النمو بمعدل 10 KRGN لكل كتلة:
إليك كيف يبدو ذلك عند أسعار KRGN مختلفة، بافتراض إدراج نموذجي في منصة من المستوى الثاني بـ 150,000 دولار وإدراج من المستوى الثالث بـ 30,000 دولار:
| سعر KRGN | الضمان / شهر | الوقت لإدراج المستوى الثالث (30 ألف دولار) | الوقت لإدراج المستوى الثاني (150 ألف دولار) |
|---|---|---|---|
| $0.01 | $2,160 | ~14 شهراً | ~69 شهراً |
| $0.05 | $10,800 | ~3 أشهر | ~14 شهراً |
| $0.10 | $21,600 | ~6 أسابيع | ~7 أشهر |
| $0.50 | $108,000 | ~8 أيام | ~6 أسابيع |
| $1.00 | $216,000 | ~4 أيام | ~3 أسابيع |
حتى عند 0.05 دولار لكل KRGN، يمكن للضمان تمويل إدراج من المستوى الثالث خلال ربع واحد. عند 0.10 دولار، يصبح إدراج المستوى الثاني قابلاً للتحقيق خلال السنة الأولى.
الضمان مؤقت. له سقف صارم عند الكتلة 262,800 (حوالي 12 شهراً). كل عملة فيه مقفلة من لحظة سكها. لا تخرج أي عملة من الضمان دون تصويت العقد الرئيسية الذي يوافق على إنفاق محدد. المعدنون الذين يمولون النمو المبكر يُكافأون بنظام بيئي فعّال وعملة تُتداول في منصات حقيقية.
تُسكّ حصة صندوق النمو البالغة 40% في كل كتلة وتُرسل إلى عنوان ضمان مقفل بالإجماع. العملات موجودة على السلسلة، تُحسب ضمن إجمالي العرض، وقابلة للتدقيق بالكامل، لكن لا يمكن إنفاقها. لا موقّع متعدد، ولا عضو فريق، ولا كيان واحد يمكنه نقلها. يتطلب الإنفاق موافقة شبكة العقد الرئيسية على اقتراح محدد.
تصويت الاستمرار: في كل دورة كتلة خارقة (16,616 كتلة، حوالي 23 يوماً)، يجب أيضاً تجديد تراكم الضمان المستمر بتصويت العقد الرئيسية. إذا فشل تصويت الاستمرار، يُحرق ناتج coinbase البالغ 40% للدورة التالية بدلاً من دخول الضمان. لا تصويت يعني لا تراكم. اللامبالاة تقتل الصندوق وليس الفعل.
ماذا يحدث عند الانتهاء: عندما ينتهي ضمان النمو (بفشل تصويت الاستمرار أو السقف الصارم عند الكتلة 262,800)، تُحرق العملات المقفلة المتبقية عبر OP_RETURN. يُحرق تخصيص coinbase البالغ 40% لجميع الكتل اللاحقة. هذا لا يُعاد توجيهه للمعدنين أو العقد الرئيسية أو أي طرف آخر. العملات المحروقة تقلل العرض المتداول، مما يفيد جميع الحاملين بالتساوي. إعادة هيكلة مكافأة كتلة V2 (القسم 3.6) هي ترقية إجماع منفصلة تعيد توجيه 40% لمزودي الاستدلال بالذكاء الاصطناعي.
الـ 20% المتبقية من مكافآت الكتل (الخزينة 15% + المطورون/المؤسسون 5%) هي الميزانية التشغيلية للمشروع. هذه العملات تُصدر بشكل طبيعي وليست مقفلة بالضمان.
الخزينة (15% / 3.75 KRGN لكل كتلة): التكاليف التشغيلية التي تحافظ على استمرار المشروع. التسويق، إدارة المجتمع، تعويض المشرفين، تكاليف الخوادم، التوزيعات المجانية، الهدايا، ونفقات الشراكات. عنوان الخزينة هو محفظة P2SH متعددة التوقيع 2-من-3 تتطلب اثنين من ثلاثة حاملي مفاتيح لتفويض أي إنفاق.
المطورون / المؤسسون (5% / 1.25 KRGN لكل كتلة): تعويض لبناء Kerrigan من الصفر والتزام مستمر بصيانة وتطوير البروتوكول. يُصدر مباشرة بدون قفل.
هذه الميزانية التشغيلية بنسبة 20% مماثلة لصندوق تطوير Zcash التاريخي بنسبة 20%. الفرق: رأس مال نمو Kerrigan (الـ 40% الأخرى) موجود في ضمان مقفل بالإجماع لا يمكن للفريق الوصول إليه دون موافقة الشبكة. فقط 20% قابل للإنفاق بحرية.
يُعيد V2 هيكلة مكافأة الكتلة حول شبكة الاستدلال بالذكاء الاصطناعي. يكسب مشغلو GPU إيرادات الدفع مقابل الاستدلال بالإضافة إلى حصتهم من مكافأة الكتل، مما يجعل أجهزة تعدين Kerrigan منتجة بين الكتل:
| المستلم | حصة V1 | حصة V2 | ملاحظات |
|---|---|---|---|
| استدلال AI GPU | 0% | 40% | بالإضافة إلى أرباح الدفع مقابل الاستدلال |
| التعدين | 20% | 20% | دون تغيير |
| العقد الرئيسية | 20% | 20% | دون تغيير |
| الخزينة | 15% | 15% | دون تغيير |
| المطورون / المؤسسون | 5% | 5% | دون تغيير |
| صندوق النمو | 40% | 0% | أتمّ غرضه |
ينخفض صندوق النمو إلى صفر بمجرد تأسيس النظام البيئي. تتحول الـ 40% التي غذّت إدراجات المنصات المبكرة والشراكات إلى المشاركين في استدلال AI GPU، محوّلةً Kerrigan إلى سلسلة ثنائية الغرض: التعدين يؤمّن الشبكة بينما حوسبة GPU تخدم أعباء عمل الذكاء الاصطناعي. يُضاف تخصيص الاستدلال بنسبة 40% فوق رسوم الدفع المباشر مقابل الاستدلال، مما يمنح مشغلي GPU تدفقي إيرادات لنفس الأجهزة.
تدمج Kerrigan بروتوكول Sapling من Zcash للمعاملات المحمية بالمعرفة الصفرية. يمكن للمستخدمين نقل الأموال بين العناوين الشفافة (التي تبدأ بـ 'K') والعناوين المحمية باستخدام إثباتات Groth16 zk-SNARK التي لا تكشف شيئاً عن المرسل أو المستلم أو المبلغ.
تستخدم المعاملات المحمية nType = 10 (TRANSACTION_SAPLING). يحتوي الحمل الإضافي على:
الحد الأقصى هو 500 وصف إنفاق و500 وصف مخرجات لكل معاملة. يُحشّي بانٍ Sapling المكتوب بـ Rust حزم المخرجات إلى حد أدنى من مخرجين (بإضافة مخرجات وهمية إذا لزم الأمر) لمنع تحليل رسم المعاملات بناءً على عدد المخرجات.
تعمل دائرة Sapling على المنحنى الإهليلجي Jubjub المضمن داخل BLS12-381. تُولّد الإثباتات وتُحقق من خلال جسر FFI بلغة Rust باستخدام حزم bellman وjubjub وgroup، مُترجمة عبر CXX إلى عقدة C++.
البدائيات الأساسية:
تُخزَّن واجهة شجرة ميركل (الحد الأدنى من البيانات المطلوبة لإلحاق أوراق جديدة) لكل كتلة في LevelDB. تتبع شهود جانب المحفظة مسار مصادقة كل ملاحظة لإثباتات الإنفاق.
الإعداد الموثوق: تعيد Kerrigan استخدام معلمات Sapling الخاصة بـ Zcash (مفاتيح الإثبات والتحقق المولّدة بواسطة حفل Powers of Tau الخاص بـ Zcash وحساب MPC لـ Sapling). الدوائر مطابقة لـ Zcash Sapling. لا حاجة لحفل إعداد موثوق جديد للمعاملات المحمية.
يتبع توقيع المعاملات مخطط sighash بأسلوب ZIP 243. تتضمن صورة sighash الأولية hashPrevouts وhashSequence وhashOutputs التي تغطي المكونات الشفافة والمحمية. يمنع هذا تلاعب التوقيع ويضمن أن الأجزاء الشفافة والمحمية من المعاملة مرتبطة معاً تشفيرياً.
تستخدم المعاملات المحمية نموذج رسوم قائم على الإجراءات:
يتفعّل Sapling عند الكتلة 500 على الشبكة الرئيسية، بعد حوالي 16 ساعة من التكوين. توفر تسعة استدعاءات RPC وظائف محفظة كاملة:
| RPC | الوظيفة |
|---|---|
| z_getnewaddress | إنشاء عنوان محمي جديد |
| z_listaddresses | سرد جميع العناوين المحمية في المحفظة |
| z_getbalance | الحصول على الرصيد المحمي لعنوان |
| z_listunspent | سرد الملاحظات المحمية غير المنفقة |
| z_sendmany | الإرسال من/إلى عناوين محمية (شفاف→محمي، محمي→محمي، محمي→شفاف) |
| z_exportkey | تصدير مفتاح إنفاق محمي |
| z_importkey | استيراد مفتاح إنفاق محمي |
| z_exportviewingkey | تصدير مفتاح عرض Sapling الكامل |
| z_importviewingkey | استيراد مفتاح عرض Sapling الكامل |
تدعم Kerrigan مستويين من العقد الرئيسية موروثين من إطار تطور Dash:
| النوع | الضمانة | وزن التصويت |
|---|---|---|
| عادي | 10,000 KRGN | 1x |
| Evo (HPMN) | 40,000 KRGN | 4x |
تُسجَّل العقد الرئيسية على السلسلة باستخدام معاملات تسجيل حتمية DIP3:
تُشتق قائمة العقد الرئيسية الحتمية بالكامل من المعاملات على السلسلة. تحسب كل عقدة نفس القائمة من نفس حالة السلسلة، مما يلغي خلافات الإجماع التي ابتليت بها أنظمة العقد الرئيسية غير الحتمية.
تُمكّن نصابات العقد الرئيسية طويلة العمر (LLMQ) خدمتين رئيسيتين:
InstantSend يقفل مدخلات المعاملات في ثوانٍ، مانعاً محاولات الإنفاق المزدوج. يوقّع نصاب من العقد الرئيسية رسالة قفل، وأي معاملة متعارضة تُرفض من قبل الشبكة.
ChainLocks يُنهي الكتل بتوقيع النصاب على أول كتلة تُرى عند كل ارتفاع. بمجرد انتشار توقيع ChainLock، لا يمكن إعادة تنظيم الكتلة، حتى من قبل مهاجم بنسبة 51%.
كلتا الخدمتين محكومتان بالـ spork ومعطلتان عند التكوين. يتطلب LLMQ حداً أدنى من العقد الرئيسية المسجلة لتشكيل النصابات، لذا تتفعّل هذه الميزات عبر spork بمجرد وصول مجموعة العقد الرئيسية إلى الكتلة الحرجة:
يمكن لمشغلي العقد الرئيسية تقديم اقتراحات ميزانية والتصويت عليها. تمرّ الاقتراحات إذا كان YES - NO >= max(10, weighted_masternode_count / 10). يتعامل نظام الحوكمة مع اقتراحات المجتمع ومبادرات التسويق وتمويل البنية التحتية. كما يتحكم في تصويت استمرار صندوق النمو (القسم 3.4): يجب تجديد تخصيص صندوق النمو بنسبة 40% بشكل فعال بتصويت العقد الرئيسية كل دورة كتلة خارقة (حوالي 23 يوماً) أو يُحرق تلقائياً.
في مستعمرة نحل حقيقية، يحمل كل عضو علامات كيميائية تعرّفه كجزء من الخلية. لا نحلة واحدة تنتج رائحة المستعمرة. إنها تنبثق من الجماعة. يعمل بروتوكول Hivemind بنفس الطريقة: تنتج مجمعات التعدين بشكل جماعي "فرموناً" تشفيرياً يُنسج في كل كتلة. مثل خلط ألوان الطلاء، يدخل الأزرق والأصفر والأحمر وتحصل على درجة محددة من البني. يمكنك التحقق من صحة البني. لا يمكنك فك مزجه لاستخراج الألوان الفردية. لكن إذا حاول شخص ما صنع ذلك البني بدون الأزرق، فهو الدرجة الخاطئة. قابل للكشف فوراً.
يقع HMP فوق إثبات العمل. يحدد PoW من يعدّن الكتلة. يحدد HMP ما إذا كان المعدنون النشطون في الشبكة يشهدون لتلك الكتلة. المهاجم الذي يتفرع من السلسلة سراً لا يستطيع إحضار فرمون المستعمرة معه، لأن المعدنين الشرفاء لم يشاركوا أبداً في التفرع. سلسلة الهجوم رائحتها خاطئة.
متطلب تصميم حاسم: لا تغييرات في برمجيات التعدين. يعمل HMP بالكامل داخل العقدة. برمجيات المجمع (s-nomp أو Miningcore أو أي مكدس متوافق مع Stratum) تتواصل مع العقدة عبر استدعاءات RPC القياسية getblocktemplate وsubmitblock. تتعامل العقدة مع إدارة الهوية وتوقيع الختم وتجميع الختم وبث الالتزامات وترحيل P2P داخلياً. قوالب الكتل تتضمن بالفعل بيانات ختم HMP المضمنة في معاملة coinbase، نفس النمط المستخدم في BIP34 (الارتفاع في coinbase) وSegWit (جذر الشاهد في coinbase) والتعدين المدمج (AuxPoW في coinbase). يجزّئ المعدنون القالب بشكل أعمى. بروتوكول Stratum دون تغيير.
تُولّد كل عقدة زوج مفاتيح BLS دائم عند التشغيل الأول (يُخزَّن كـ hmp_identity.dat). تُحمَّل هذه الهوية تلقائياً عند بدء التشغيل. مع تعدين الكتل والمشاركة في الختم، تبني العقدة سجل امتياز:
| المستوى | المتطلبات | القدرات |
|---|---|---|
| UNKNOWN | لا تاريخ، أو في فترة إحماء 10 كتل | لا يمكنه الختم |
| NEW | أكمل الإحماء، يشارك | يمكنه الختم بوزن قياسي |
| ELDER | حلّ أكثر من 10 كتل ومشاركة في الختم ضمن نافذة 100 كتلة | وزن كامل، مؤهل لمكافأة عبر الخوارزميات |
نافذة الامتياز هي 100 كتلة. المعدن الذي يتوقف عن المشاركة يعود إلى UNKNOWN بعد خروجه من النافذة. يتطلب الامتياز عملاً حقيقياً: لا يمكنك أن تصبح ELDER دون حل كتل فعلياً، مما يحوّل أي هجوم Sybil إلى عملية تعدين نزيهة مكلفة.
قبل الختم، يجب على العقدة الالتزام بمفتاحها العام BLS على السلسلة. فكّر في هذا كقائمة الحضور. كل عقدة تريد المشاركة تبث مفتاحها العام. تصل هذه المفاتيح إلى السلسلة بطريقتين: ضمنياً (بتعدين كتلة، مما يُضمّن المفتاح العام للمعدن في حقل minerIdentity في CCbTx v4) أو صراحة (حتى 16 التزام مفتاح عام إضافي لكل كتلة في حقل vCommitments في CCbTx v5).
يجب أن ينضج المفتاح الملتزم لمدة 10 كتل قبل أن يصبح الموقّع مؤهلاً. هذه عقوبة الإحماء. إذا كانت خدمة تبديل الأرباح مثل NiceHash تعمل بدورات أقصر من الإحماء (حوالي 20 دقيقة)، فإن هؤلاء المعدنين لا يساهمون أبداً في الفرمون. يُعدّنون، يكسبون المكافآت، يغادرون. تأثير صفري على هوية المستعمرة.
إذا بقي المفتاح الملتزم طويلاً بما يكفي لكسب الامتياز، يصبح صوتاً متساوياً في المستعمرة. عندما يغادر، يختفي صوت واحد. رائحة المستعمرة بالكاد تتغير.
عند وصول كتلة جديدة، تتحقق العقدة تلقائياً من الأهلية، وتحسب إثبات VRF، وتوقّع تجزئة الكتلة بمفتاح BLS الخاص بها، وتبث حصة الختم إلى الشبكة. يحدث هذا في ConnectBlock دون تدخل المجمع.
تحتوي كل حصة ختم على:
كان لدى الموقّع معرفة بحالة السلسلة العامة عند ارتفاع حديث، وأن الالتزام تم إنشاؤه بعد مراقبة تلك الحالة (يمنع الحساب المسبق)، وأن مادة المفتاح جديدة لهذه الجولة (يمنع إعادة التشغيل).
معدل تجزئة الموقّع المحدد، والتوقيت الدقيق لمراقباته، ومادة المفتاح الخاص المستخدمة في الالتزام. لاحظ أن حصص الختم تتضمن المفتاح العام للموقّع (الهوية المستعارة مرئية لتتبع الامتياز)، لكن إثبات zk يضمن بقاء التفاصيل التشغيلية ومادة المفتاح خاصة.
المهاجم الذي يعدّن تفرعاً سرياً لا يمكنه إنتاج إثباتات صالحة لأنه لم يكن يراقب السلسلة العامة في اللحظات المطلوبة. تشير مدخلات الإثبات إلى إنتروبيا مشتقة من حالة السلسلة العامة الموجودة فقط على السلسلة النزيهة. الإثباتات مرتبطة بتجزئات كتل محددة، لذا لا يمكن نقلها بين السلاسل.
تنتشر حصص الختم عبر رسائل SEALSHARE P2P. بعد نافذة توقيع مدتها 5 ثوانٍ، تجمّع العقدة الحصص المجمعة في CAssembledSeal مع توقيع BLS مجمّع. يُضمَّن ختم الكتلة N في coinbase الكتلة N+2، مما يمنح الشبكة وقتاً لجمع الحصص دون إيقاف إنتاج الكتل. لا ينتظر التعدين أبداً التوقيعات.
الإعداد لإثباتات HMP: تستخدم دائرة التزام MiMC نظام Groth16 على BLS12-381. الدائرة صغيرة عمداً (وقت الإثبات أقل من ثانيتين على أجهزة عادية، وقت التحقق أقل من 50 مللي ثانية، حجم الإثبات أقل من 256 بايت). تُولّد مفاتيح الإثبات والتحقق عبر حفل حساب متعدد الأطراف. افتراض الأمان قياسي لـ Groth16: الإعداد آمن إذا كان مشارك واحد على الأقل نزيهاً ودمّر نفاياته السامة. تُنشر نصوص الحفل وتجزئات المعلمات للتحقق.
يعدّل HMP اختيار السلسلة بإضافة مكافأة ختم لكل كتلة إلى عمل PoW التراكمي القياسي:
لكل كتلة، يُحسب مضاعف الختم كقيمة نقطة أساس تُطبق على block_pow_work:
يستخدم مضاعف الختم نظام مستويات متدرج. فقط توقيعات مستوى ELDER التي يتطابق algoId فيها مع خوارزمية تعدين الكتلة تُحتسب نحو اكتمال نفس الخوارزمية. ضمن كل مستوى، يُحسب المضاعف خطياً بناءً على نسبة ELDER الحاضرين إلى إجمالي ELDER للخوارزمية. تضيف مكافأة عبر الخوارزميات +500 نقطة أساس ثابتة لكل نطاق خوارزمية ELDER إضافي (بخلاف خوارزمية الكتلة الخاصة)، بحد أقصى +1500 نقطة أساس (جميع الخوارزميات الأربع ممثلة). كتلة مختومة بالكامل مع جميع نطاقات الخوارزميات الأربع تصل إلى 1.95 ضعف عمل PoW الخاص بها. كتلة غير مختومة تساوي 1.0 ضعف. على مدى مئات الكتل، تتراكم سلسلة ذات فرمونات كاملة باستمرار وزن أكبر بشكل ملحوظ من سلسلة ذات فرمونات ضعيفة أو غائبة، حتى لو كان عمل PoW الخام متكافئاً.
يتوسع اتفاق الموقعين المطلوب مع عدد ELDER لكل خوارزمية:
| ELDER (لكل خوارزمية) | الاتفاق المطلوب | المبرر |
|---|---|---|
| 6+ | 80% | أمان كامل، يستوعب الإخفاقات الفردية |
| 4-5 | 75% | قوي، أكثر تسامحاً قليلاً |
| 3 | 66% (2 من 3) | متدهور لكن فعّال |
| 2 | 100% (كلاهما) | حذر أقصى |
| 0-1 | غير متاح، وضع PoW خالص | المستعمرة لم تتأسس بعد |
هذا يعني أن الشبكة تبدأ في وضع PoW الخالص وتنتقل إلى إجماع مؤمّن بـ HMP عضوياً مع نمو مستعمرة التعدين. ينبثق الأمان من المشاركة وليس من يوم محدد.
لا يشارك كل موقّع مسجل في كل ختم. تحدد BLS-VRF (دالة عشوائية قابلة للتحقق) أي حصص موقعين تُرحَّل عبر شبكة P2P. تجزئة الكتلة السابقة تُغذي VRF. كل عقدة مؤهلة تُشغل VRF بمفتاحها طويل الأمد. الاختيار حتمي (يمكن لجميع العقد التحقق من كان مؤهلاً) لكن غير قابل للتنبؤ (يعتمد على تجزئات كتل لا يستطيع أحد التنبؤ بها مسبقاً).
في V1، VRF هو مرشح طبقة ترحيل وليس قاعدة إجماع. تُسقط العقد حصص الختم من الموقعين الذين يفشلون في أهلية VRF، مما يقلل عرض النطاق الترددي للشبكة ويصعّب على المهاجم الطحن أو إغراق مجمع الحصص. تسجيل اختيار السلسلة يحتسب جميع توقيعات BLS الصالحة في الختم المجمّع بغض النظر عن حالة VRF (انظر الملحق أ.4). قد تُرقّي تحديثات البروتوكول المستقبلية أهلية VRF إلى فحص صلاحية ختم على مستوى الإجماع.
يكون المجمع مميّزاً إذا حلّ كتلة في آخر 100 كتلة، أو إذا كان أحد آخر 6 مجمعات فريدة حلّت كتلة على تلك الخوارزمية، أيهما يصل أبعد. هذا يعني أن مجموعة المميّزين على أي خوارزمية لا يمكن أن تنكمش أبداً إلى أقل من 6 (بافتراض أن 6 مجمعات مميزة عدّنت تلك الخوارزمية من قبل).
إذا عدّن مجمع كبير يبدّل الأرباح 100 كتلة KawPoW متتالية، فإن المجمعات الخمس الأخرى التي حلّت كتل KawPoW مؤخراً قبل تلك السلسلة لا تزال تُعتبر مميّزة. تبقى أصواتها في المستعمرة. يُحدّ الاسترجاع الممتد بـ 1,000 كتلة (حوالي 33 ساعة). بعد ذلك، المشاركة قديمة جداً لتُحتسب.
ترث Kerrigan نظام ChainLock من Dash (إنهاء الكتل القائم على LLMQ بواسطة العقد الرئيسية)، وسيتم تفعيله عبر spork بمجرد تسجيل عدد كافٍ من العقد الرئيسية. لكن ChainLocks يتطلب نصاب عقد رئيسية فعّال، والذي يستغرق وقتاً للبناء بعد التكوين. يملأ HMP الفجوة: يوفر مقاومة إعادة التنظيم من اليوم الأول باستخدام المعدنين الموجودين بالفعل على الشبكة. مع نمو مجموعة العقد الرئيسية، يُضاف ChainLocks فوق HMP لنهائية إضافية. يُكمّلان بعضهما البعض.
أنت في صالة سينما. تغادر في منتصف الفيلم لجلب الفشار. في طريقك للخروج، تلاحظ رجلاً بقميص أحمر عند الباب، وزوجين مسنين في الصف الثالث، ومجموعة مراهقين بالقرب من الأمام. تحصل على الفشار، تعود إلى الداخل، وفوراً هناك شيء خاطئ. القميص الأحمر اختفى. الزوجان المسنان انتقلا. المراهقون اختفوا. لا أحد من الوجوه صحيح. أنت في غرفة العرض الخاطئة. لم يحتج أحد لإخبارك — لقد لاحظت فقط أن الأشخاص الذين كنت تتوقعهم ليسوا هنا.
هكذا يكشف HMP سلسلة الهجوم. تعرف الشبكة أي معدنين كانوا يحضرون — يحلون الكتل، يشاركون في الأختام، يكسبون حالة ELDER. عندما تظهر سلسلة منافسة، يتحقق البروتوكول مما إذا كانت تلك الوجوه المألوفة حاضرة. إذا كان الدائمون مفقودين، رائحة السلسلة خاطئة. لا حاجة لمقارنة عبر السلاسل. لقد دخلت ببساطة الغرفة الخاطئة.
الآن ضاعفها إلى أربع غرف. Kerrigan لا تُشغّل عرضاً واحداً — إنها تُشغّل متعدداً رباعي الشاشات. X11 وKawPoW وEquihash 200,9 وEquihash 192,7 لكل منها غرفتها الخاصة مع دائميها. يكسب مجمع X11 سمعته في غرفة X11. يكسب مجمع KawPoW سمعته في غرفة KawPoW. إنها مجتمعات مستقلة تماماً بأجهزة مختلفة تماماً.
تكون الكتلة أقوى عندما يشهد لها الدائمون من غرف متعددة. كتلة KawPoW معتمدة فقط من دائمي KawPoW تحصل على مكافأة جزئية. أضف توقيعات من دائمي X11 ودائمي Equihash 200,9 ودائمي Equihash 192,7، وتكسب الكتلة مكافأة عبر الخوارزميات (القسم 6.6)، حتى 1.95 ضعف وزن PoW الخام. يحتاج المهاجم لملء جميع الغرف الأربع بوجوه مقنعة في وقت واحد — أربعة حشود مستقلة، أربعة أنظمة أجهزة مستقلة، أربعة تواريخ مستقلة من التعدين النزيه، كلها مزيفة في وقت واحد.
اعتبر المهاجم الأكثر تطوراً ممكناً: ميزانية غير محدودة، خبرة تقنية، صبر.
الطبقات ليست عقبات مستقلة. إنها تتعزز بشكل متبادل. لا يمكنك كسب الامتياز دون التعدين بنزاهة، مما يُقوّي السلسلة التي تحاول مهاجمتها. لا يمكنك إنتاج فرمون صالح على تفرع سري لأن المجمعات النزيهة لم تساهم بطلائها أبداً. المهاجم لا يواجه سبع مشاكل. يواجه مشكلة واحدة مستحيلة يُنظر إليها من سبع زوايا: هل يمكنك أن تكون معزولاً وتعاونياً في نفس الوقت؟
HMP هو آلية تنسيق، وآليات التنسيق يمكن إساءة استخدامها. كارتل من موقعي ELDER يتحكم في امتياز كافٍ لملء expected_signers يمكنه حجب الأختام انتقائياً عن الكتل المعدّنة بواسطة مجمعات مستهدفة. كتل المجمع المستهدف ستتراكم وزن سلسلة أقل (نسبة اكتمال أقل)، مما يجعلها أكثر عرضة لخسارة سباقات إعادة التنظيم أمام الكتل المختومة.
عدة عوامل تحدّ من سطح هذا الهجوم:
التقييم الصادق: يزيد HMP تكلفة هجمات 51% بهامش كبير، لكنه يُدخل سطح تنسيق يفتقده PoW الخالص. كارتل كبير بما يكفي من العقد المعدّلة يمكنه استخدام حجب الختم كأداة رقابة ناعمة. التخفيفات أعلاه تجعل هذا مكلفاً وقابلاً للكشف، لكن ليس مستحيلاً. هذه المقايضة مقصودة. البديل (PoW خالص بدون HMP) أكثر عرضة بشكل صارم للهجوم الأبسط والأرخص لاستئجار معدل التجزئة.
يتفعّل HMP على مراحل على الشبكة الرئيسية:
| المرحلة | الارتفاع | الوصف |
|---|---|---|
| المرحلة 2 | الكتلة 100 | تُفتح التزامات المفتاح العام |
| المرحلة 3 | الكتلة 300 | يبدأ الختم الناعم (أوزان إيجابية فقط) |
| المرحلة 4 | الكتلة 500 | HMP الكامل مع الإثباتات السلبية |
الإثباتات الإيجابية مقابل السلبية: في المرحلة 3، تتلقى الكتل المختومة وزن سلسلة إضافي (إثبات إيجابي: "هذه الكتلة لها دعم المستعمرة"). في المرحلة 4، يصبح غياب الموقعين المتوقعين أيضاً إشارة (إثبات سلبي: "هذه السلسلة تفتقد معدنين نعلم أنهم يجب أن يكونوا هنا").
تُحسب الإثباتات السلبية بشكل حتمي من السلسلة المرشحة وحدها، بدون مقارنة عبر السلاسل. كل سلسلة تحمل حالة امتيازها الخاصة: مجموعة موقعي ELDER مشتقة من تاريخ كتل تلك السلسلة (من حلّ الكتل، من شارك في الأختام، ضمن نافذة الاسترجاع). إذا أظهر متتبع امتياز سلسلة ما 6 موقعين ELDER لـ KawPoW، لكن الأختام على الكتل الأخيرة تحتوي على 2 فقط منهم، نسبة الاكتمال منخفضة ومكافأة الختم جزئية. لا حاجة لمرجع أي سلسلة أخرى. تُقيّم العقد كل سلسلة مرشحة بشكل مستقل باستخدام حالة تلك السلسلة الخاصة.
هذا هو اختبار صالة السينما من القسم 6.10: دخلت غرفة العرض الخاطئة والدائمون ليسوا في مقاعدهم. لا حاجة لمقارنة — أنت فقط تلاحظ من المفقود.
في V1، الإثباتات السلبية تؤثر على تسجيل وزن السلسلة فقط. إنها استدلال اختيار وليست قاعدة صلاحية صارمة. سلسلة بموقعين مفقودين ليست باطلة؛ إنها ببساطة تتراكم وزن أقل من سلسلة يكون فيها الموقعون المتوقعون حاضرين. هذا النهج المحافظ يتجنب العقوبات الكاذبة في ظل تقسيمات الشبكة أو مشاكل الاتصال العابرة. قد تشدد تحديثات البروتوكول المستقبلية تطبيق الإثبات السلبي مع نضج الشبكة.
مفتاح إيقاف وقت التشغيل (SPORK_25_HMP_ENABLED) يسمح بإلغاء التفعيل الطارئ إذا ظهرت مشاكل بعد الإطلاق.
| المعلمة | القيمة |
|---|---|
| بادئة عنوان المفتاح العام | K (بايت 45) |
| بادئة عنوان البرنامج | 7 (بايت 16) |
| معرف HRP لـ Sapling bech32m | ks |
| نوع عملة BIP44 | 99888 (غير مسجل؛ التسجيل الرسمي في SLIP-0044 معلق) |
| سحر الشبكة | 0x4B 0x52 0x47 0x4E ("KRGN") |
| الشبكة | منفذ P2P | منفذ RPC |
|---|---|---|
| الرئيسية | 7120 | 7121 |
| الاختبارية | 17120 | 17121 |
| شبكة التطوير | 37120 | 19798 |
| اختبار الانحدار | 27120 | 19898 |
تتولى أربع عقد بذور موزعة جغرافياً اكتشاف الأقران الأولي:
| البذرة | المنطقة |
|---|---|
| seed1.kerrigan.network | الولايات المتحدة |
| seed2.kerrigan.network | الهند |
| seed3.kerrigan.network | اليابان |
| seed4.kerrigan.network | ألمانيا |
تعرّف Kerrigan رؤوس كتل مضغوطة قائمة على DIP25 مع امتدادات لحقول الخوارزميات المتعددة. الرؤوس المضغوطة معطلة حالياً بانتظار حل حالات حافة إلغاء تسلسل الخوارزميات المتعددة؛ يستخدم تنزيل الكتل الأولي رؤوساً كاملة. يتحكم حقل بت واحد في الحقول المضمنة:
يقلل هذا عرض نطاق الرأس بشكل كبير أثناء تنزيل الكتل الأولي، حيث يحتاج جزء فقط من الكتل إلى نقل حلول Equihash الكاملة أو بيانات KawPoW.
| المعلمة | القيمة |
|---|---|
| الطابع الزمني | 1,773,446,400 (11 مارس 2026 12:00 UTC) |
| الرقم العشوائي | 1,338,121 |
| البتات | 0x1e0ffff0 |
| الدعم | 25 KRGN |
| التجزئة | 0x00000444f8dbee14c599ac723b35cc8021b12d48d092c7ac67d45f6d8a0b9c32 |
أكثر فوائد الأمان المباشرة لأربع خوارزميات تعدين هي المقاومة ضد الهجمات أحادية المتجه. المهاجم الذي يتحكم في 51% من معدل تجزئة X11 يتحكم تقريباً في 25% من إجمالي إنتاج كتل الشبكة. لتنفيذ هجوم 51% مستدام، سيحتاج للهيمنة على خوارزميتين على الأقل في وقت واحد، أو إغراق خوارزمية واحدة مع التفوق على المعدنين النزيهين عبر البقية. يجعل بروتوكول Hivemind هذا أصعب: قوة التجزئة وحدها غير كافية عندما يزن اختيار السلسلة أيضاً شهادات الختم من موقعين مسجلين وملتزمين.
تمنع مجموعة المُبطلات في Sapling الإنفاق المزدوج للملاحظات المحمية. لكل ملاحظة مُبطل فريد مشتق من موقعها في شجرة ميركل ومفتاح الإنفاق. بمجرد ظهور مُبطل على السلسلة، تُرفض أي معاملة تحاول إنفاق نفس الملاحظة على مستوى الإجماع. إثباتات Groth16 سليمة حسابياً تحت افتراض اللوغاريتم المنفصل على BLS12-381؛ تزوير إثبات دون معرفة الشاهد غير ممكن.
جميع البيانات المُلغى تسلسلها من شبكة P2P تُفحص حدودها قبل أن تقود تخصيص الذاكرة أو تكرار الحلقات أو فهرسة المصفوفات. حلول Equihash محدودة بـ 1,400 بايت. قوائم موقعي الختم محدودة بـ 200 إدخال. إثباتات ZK محدودة بـ 256 بايت. قوائم التزام المفتاح العام محدودة بـ 16 لكل كتلة. لا يمكن لأي حقل من بيانات الشبكة أن يُفعّل تخصيصاً غير محدود.
يسمح نظام spork لفريق التطوير بتعطيل الميزات في الإنتاج دون تفرع صعب. تشمل Spork الحرجة:
تستخدم مفاتيح Spork عتبة 2-من-3، تتطلب اثنين من ثلاثة حاملي مفاتيح لتفويض أي تغيير spork.
V1 هو إطلاق يركز على التعدين مع جميع الأنظمة الأساسية نشطة:
يوسع V2 Kerrigan من سلسلة تعدين خالصة إلى شبكة حوسبة GPU للاستدلال بالذكاء الاصطناعي. تقدير التطوير الأساسي حوالي 12 أسبوعاً، مع جدول زمني إجمالي 48 أسبوعاً يشمل الاختبار والتدقيق وجاهزية النظام البيئي. البنية معيارية، لذا يمكن إطلاق V2 بمجرد جاهزيته؛ تقدير 12 شهراً محافظ وليس التزاماً.
مكونات V2:
تسجيل مزودي الاستدلال: يسجّل مشغلو GPU على السلسلة مع متطلبات الرهن وشهادة الأجهزة ونقاط نهاية الخدمة. تتبع معاملات التسجيل نفس نمط القائمة الحتمية كعقد DIP3 الرئيسية، مما يضمن أن كل عقدة تحسب نفس مجموعة المزودين.
توزيع المهام P2P: تُوزع طلبات الاستدلال على المزودين عبر بروتوكول نقل الشائعات. تستخدم تعيينات المهام اختيار VRF مرجّح بحصة المزود وتاريخ أدائه. تُلتزم النتائج على السلسلة مع إثباتات تجزئة لحل النزاعات.
الحوسبة القابلة للتحقق: يقدّم المزودون شهادات حوسبة يمكن فحصها عشوائياً بواسطة مزودين آخرين. النتائج غير الصحيحة تُفعّل خفض حصة المزود. يوازن مخطط التحقق بين الإنتاجية (ليس كل نتيجة تُحقق) والأمان (الغش يُكتشف إحصائياً ويُعاقب).
إعادة هيكلة مكافأة الكتلة: يتغير تقسيم coinbase لتوجيه 40% من مكافآت الكتل لمشاركي استدلال AI GPU، بالإضافة إلى أرباحهم من الدفع مقابل الاستدلال. يبقى التعدين عند 20%، والعقد الرئيسية عند 20%، والخزينة عند 15%، والمطورون/المؤسسون عند 5%. ينخفض صندوق النمو إلى صفر، بعد أن خدم غرضه خلال مرحلة إطلاق V1.
مع اكتمال V1 وV2، يتحول التركيز إلى نضج النظام البيئي:
تحل Kerrigan مشكلة مركزية الأجهزة بجعل أربع خوارزميات تعدين تتنافس بالتوازي، كل منها على منحنى صعوبتها الخاص. توفر معاملات Sapling المحمية للمستخدمين خصوصية حقيقية مدعومة بإثباتات Groth16 للمعرفة الصفرية. يضيف بروتوكول Hivemind بُعداً ثانياً للإجماع يجعل هجمات 51% أصعب بشكل جوهري من خلال طلب شهادات ختم من معدنين ملتزمين ومُثبتين.
يضمن صندوق النمو بنسبة 40% أن المشروع لديه الموارد المالية لبناء وجود في المنصات والبنية التحتية للنظام البيئي عند أي نقطة سعر للعملة. يُطلق V1 كسلسلة كتل كاملة تركز على التعدين. يوسع V2 نفس بنية GPU التحتية إلى الاستدلال بالذكاء الاصطناعي، محوّلاً أجهزة التعدين إلى موارد حوسبة للأغراض العامة.
الكود مفتوح المصدر. معلمات السلسلة ثابتة. يبدأ التعدين عند التكوين.
| المكوّن | الملفات المصدرية |
|---|---|
| PoW متعدد الخوارزميات | src/primitives/block.h، src/primitives/block.cpp، src/pow.cpp |
| اقتصاديات العملة | src/chainparams.cpp، src/masternode/payments.cpp |
| Sapling | src/sapling/، src/rust/src/bridge.rs، src/sapling/sapling_tx_payload.h |
| العقد الرئيسية | src/evo/dmn_types.h، src/evo/deterministicmns.h |
| HMP | src/hmp/، src/rust/src/hmp/ |
| معلمات الشبكة | src/chainparams.cpp، src/chainparamsbase.cpp |
| الرؤوس المضغوطة | src/primitives/block.h (CompressibleBlockHeader) |
تجزئة الهوية: X11(أعلاه). تجزئة PoW: نفسها.
تجزئة الهوية: X11(أول 80 بايت). تجزئة PoW: ProgPoW(sha256d(أول 80 بايت)، nHeight، nNonce64) تُحقق مقابل mix_hash. تجزئة بذرة ProgPoW هي sha256d (وليس X11)، مطابقة لمعيار Ravencoin الذي يستخدمه جميع معدني KawPoW. ترتيب البايتات: يستخدم ethash النهاية الكبرى (bytes[0] = MSB)، يستخدم بيتكوين النهاية الصغرى (begin() = LSB). تُعكس البايتات عند كل حدود تحويل.
تجزئة الهوية: X11(الإصدار + prevHash + merkleRoot + hashReserved + الوقت + البتات + nNonce256، تخطيط 140 بايت). تجزئة PoW: التحقق من حل Equihash مقابل نفس المدخل 140 بايت. الحل ملتزم في التسلسل الكامل للكتلة.
مدخل تجزئة هوية Equihash: تستخدم كتل Equihash المدخل 140 بايت (بما في ذلك hashReserved وnNonce256) لتجزئة الهوية، وليس رأس 80 بايت القياسي. حقل nNonce بحجم 4 بايت غير مستخدم لكتل Equihash. بما أن تجزئة الهوية تلتزم مباشرة بـ nNonce256، لا توجد قابلية تلاعب بين الرقم العشوائي للتعدين ومعرف الكتلة.
معرف الكتلة (المشار إليه بـ hashPrevBlock في الكتلة التالية) هو تجزئة الهوية: X11 على الرأس الأساسي للكتلة (80 بايت لـ X11/KawPoW، 140 بايت لمتغيرات Equihash). يُستخدم X11 لتجزئة الهوية على جميع الخوارزميات.
ضمان التفرد: يتضمن الرأس 80 بايت جذر ميركل، الذي يلتزم بمعاملة coinbase الكاملة. يحتوي coinbase على: ارتفاع الكتلة المطلوب بـ BIP34، عنوان دفع المعدن، بيانات هوية HMP (CCbTx v4+ تتضمن المفتاح العام BLS للمعدن)، بيانات ختم مضمنة، ورقم عشوائي إضافي خاص بالمجمع. كتلتان معدنتان بشكل مستقل عند نفس الارتفاع ستنتجان دائماً معاملات coinbase مختلفة (معدنون مختلفون، أرقام عشوائية إضافية مختلفة، هويات HMP مختلفة)، وبالتالي جذور ميركل مختلفة، وبالتالي تجزئات هوية مختلفة.
لجعل هذا الضمان صريحاً على مستوى البروتوكول: تشترط Kerrigan أن تتضمن معاملة coinbase المفتاح العام HMP للعقدة المعدنة في حقل minerIdentity في CCbTx (v4 HMP_SEAL وv5 HMP_COMMITMENT، بعد تفعيل HMP المرحلة 3 عند الكتلة 300). بما أن كل عقدة لديها زوج مفاتيح BLS فريد، فإن coinbase مضمون التفرد لكل عقدة لكل ارتفاع. قبل التفعيل (الكتل 0-299)، يعتمد التفرد على آلية ارتفاع BIP34 القياسي + الرقم العشوائي الإضافي، وهو كافٍ للسلسلة المبكرة منخفضة المنافسة. خلال المرحلة 2 (الكتل 100-299)، يسجّل المعدنون هوياتهم عبر التزامات ضمنية وصريحة لكن التطبيق مؤجل لمنح النظام البيئي وقتاً للتبني.
تطبيق الإجماع: ترفض العقد أي كتلة عند أو فوق ارتفاع تفعيل HMP المرحلة 3 يفتقد CCbTx فيها حقل minerIdentity صالح. هذه قاعدة إجماع وليست افتراضاً عن سلوك المعدن. كتلة بدون هوية معدن بعد تفعيل المرحلة 3 باطلة، نقطة.
التزام الحقل الخاص بالخوارزمية: حلول Equihash وتجزئات مزج KawPoW والأرقام العشوائية الممتدة تلتزم بفحص التحقق من PoW وليس بمعرف الكتلة. تغيير أي حقل خاص بالخوارزمية يُبطل إثبات PoW. ربط السلسلة (prevHash) موحد ولا يعتمد على الخوارزمية.
شهود صالحة متعددة: في الحدث المستبعد للغاية أن معدناً واحداً يجد حلين PoW صالحين لنفس الرأس 80 بايت (نفس تجزئة الهوية، شاهد خاص بالخوارزمية مختلف)، يعاملهما البروتوكول كنفس الكتلة. أول شاهد صالح يُستقبل يُقبل؛ الشهود اللاحقة لتجزئة هوية معروفة بالفعل تُتجاهل. هذا آمن لأن تجزئة الهوية تلتزم بجذر ميركل (وبالتالي جميع المعاملات)، لذا كلا الشاهدين يمثلان نفس محتوى الكتلة بنفس الأثر الاقتصادي.
تخفيف تسميم الكتل الباطلة: لأن تجزئة الهوية لا تلتزم بالحقول الخاصة بالخوارزمية، يمكن لمرحّل خبيث نظرياً تعديل حل Equihash أو mix_hash لـ KawPoW لكتلة صالحة لإنتاج كتلة باطلة بنفس تجزئة الهوية. إذا خزّنت عقدة مؤقتاً "هذه التجزئة باطلة" ثم استقبلت الكتلة الحقيقية لاحقاً، قد ترفضها. تخفف Kerrigan هذا بالتحقق من إثبات PoW الخاص بالخوارزمية قبل الالتزام برأس الكتلة في الفهرس. الكتلة التي يفشل فحص PoW الخاص بها تُسقط على طبقة الشبكة دون تسميم فهرس الكتل. هذا نفس النهج المستخدم بواسطة DigiByte وسلاسل الخوارزميات المتعددة الأخرى التي تفصل تجزئة الهوية عن التحقق من PoW.
elders_present وelder_count وblock_pow_work مُعرّفة في القسم أ.4. عند مقارنة سلسلتين متنافستين عند نفس الارتفاع، السلسلة ذات total_chain_weight الأعلى تفوز.
| ELDER (لكل خوارزمية) | الاتفاق المطلوب | required_count (مثال) |
|---|---|---|
| 6 | 80% | ceil(0.80 * 6) = 5 |
| 5 | 75% | ceil(0.75 * 5) = 4 |
| 4 | 75% | ceil(0.75 * 4) = 3 |
| 3 | 66% | ceil(0.66 * 3) = 2 |
| 2 | 100% | ceil(1.00 * 2) = 2 |
| 0-1 | غير متاح | وضع PoW الخالص (seal_multiplier = 10000 لجميع الكتل) |
اختيار لجنة VRF وإثباتات Groth16 zk محمولة في حصص الختم على طبقة P2P وتعمل كحمايات ضد هجمات الحرمان من الخدمة والطحن. في V1، هي ليست حرجة للإجماع: صلاحية الختم تعتمد فقط على توقيعات BLS ونضج الالتزام وفحوصات الامتياز المذكورة أعلاه. تتحقق العقد من VRF وإثباتات zk قبل ترحيل حصص الختم (الإثباتات الباطلة تُسقط على طبقة الشبكة)، لكن الأختام المجمّعة في coinbase تُسجّل بناءً على توقيعات BLS فقط. هذا النهج المحافظ يبقي قواعد الإجماع في حدها الأدنى عند الإطلاق. قد ترقّي تحديثات البروتوكول المستقبلية أهلية VRF والتحقق من إثبات zk إلى قواعد إجماع بمجرد اختبار نظام الإثبات على الشبكة الرئيسية.
يُضمَّن ختم الكتلة N في coinbase الكتلة N+2 (nHMPSealTrailingDepth = 2). هذا يعني:
تتبع العقد هذه القواعد عند معالجة الكتل ذات حقول PoW الخاصة بالخوارزمية:
| المكوّن | المعلمات | المصدر |
|---|---|---|
| Sapling (معاملات محمية) | مفاتيح إثبات/تحقق Groth16 على BLS12-381 | Powers of Tau الخاص بـ Zcash + Sapling MPC (مُعاد استخدامها، دوائر مطابقة) |
| دائرة HMP MiMC | مفاتيح إثبات/تحقق Groth16 على BLS12-381 | حفل متعدد الأطراف؛ آمن إذا كان مشارك واحد على الأقل نزيهاً؛ النصوص منشورة |