ASICBoost

عند معالجة طلبات متشابهة، يمكن إعداد معلوماتها المشتركة مرة واحدة، مع بقاء ضرورة إتمام كل طلب على حدة. هذا تشبيه مفيد لفكرة ⁦ASICBoost⁩. وصفها ⁦Timo Hanke⁩ عام ⁦2016⁩، مشيرًا إلى تعاونه مع ⁦Sergio Demian Lerner⁩. وشريحة ⁦ASIC⁩ مصممة لمهمة حسابية محددة؛ لذا قد يزيل تنظيم عملها بعض التكرار. لا تتغير دالة الهاش المستخدمة ⁦SHA-256⁩ ولا قواعد ⁦Bitcoin⁩. يجب أن تبقى نتيجة الهاش المزدوج النهائية للرأس أقل من القيمة المستهدفة أو مساوية لها، وأن تكون الكتلة كلها صالحة. [1]

البايت وحدة لقياس حجم البيانات الرقمية. الرأس ملخص لبيانات الكتلة حجمه ⁦80⁩ بايت. تعالج الجولة الأولى من الهاش ⁦64⁩ بايت، ثم الـ⁦16⁩ الباقية مع الحشو المحدد. وتعبر ⁦Merkle root⁩، البصمة المجمعة للمعاملات، هذا الحد: تقع آخر ⁦4⁩ بايت منها في الجزء الثاني. وتوجد هناك أيضًا قيمة الوقت و⁦bits⁩، الترميز المختصر لهدف التعدين، و⁦nonce⁩، العداد الذي يتغير بين المحاولات. لذلك تحدد الحقول التي نغيّرها أي الحسابات يمكن استخدامها مجددًا. [1]

يسمّي ⁦Hanke⁩ مجموعات المهام المناسبة ⁦colliding work items⁩. تختلف الأجزاء الأولى من رؤوسها فتنتج قيم ⁦midstate⁩ مختلفة، أي حالات وسيطة للحساب، بينما يبقى الجزء المسمّى ⁦Message⁩ متطابقًا. عند اختيار ⁦nonce⁩، يمكن مشاركة ⁦message schedule⁩، وهو مجموعة القيم المساعدة لمعالجة الجزء الثاني من تطبيق ⁦SHA-256⁩ الأول. ثم تستمر الحسابات بصورة مستقلة انطلاقًا من الحالات الوسيطة المختلفة. ليس ذلك اكتشاف هاشات نهائية متساوية ولا كسرًا للدالة. المقصود بالتصادم هنا تطابق جزء محدد من المدخل؛ أما الأجزاء الأولى من الرؤوس فمختلفة. [1]

يميّز ⁦Sergio Demian Lerner⁩ بين ⁦overt⁩ و⁦covert ASICBoost⁩. يغيّر ⁦overt⁩ البتات المسموح بها في ⁦nVersion⁩، حقل نسخة الرأس، فلا يحتاج إلى البحث عن تطابق جزئي في ⁦Merkle root⁩. أما ⁦covert⁩ فيبحث عنه: تبقى آخر ⁦4⁩ بايت من ⁦Merkle root⁩ متساوية بينما يتغير الجزء الأول. يمكن الاستفادة من تعديلات مسموحة في بيانات المعاملات أو ترتيبها، لكن يجب الحفاظ على علاقات اعتمادها، وأن تظل البصمات المسجلة مطابقة لبيانات الكتلة. اختلاف نسخ الرؤوس وحده لا يثبت مقدار توفير الطاقة ولا هوية المشغّل. [2]

ينسّق المجمّع عمل المعدّنين. وخادمه هو الخدمة الحاسوبية التي يتواصل معها الجهاز، وتقبل النتائج وفق الشروط المتفق عليها. لا يستطيع جهاز بيتر تغيير الرأس كيفما شاء. تصف الوثيقة التي تحمل الرقم ⁦BIP310⁩ التفاوض عبر ⁦mining.configure⁩: يحدد ⁦version-rolling.mask⁩ البتات القابلة للتغيير، وتختار الإجابة التقاطع بين قدرات المعدّن والخادم. القناع خريطة للمواضع المسموحة وليس وعدًا بزيادة السرعة. ويشترط التعبير ⁦version_bits & ~last_mask == 0⁩ أن تبقى البتات المقدمة ضمن آخر قناع صالح. عند وصول إشعار ⁦mining.set_version_mask⁩، يسري القناع الجديد فورًا دون انتظار المهمة التالية. وعلى ⁦firmware⁩، البرنامج الذي يتحكم بالجهاز، احترام هذا الاتفاق. [3]

يقترح ⁦BIP320⁩ تخصيص ⁦16⁩ بتًا عامًا في ⁦nVersion⁩، بينما يصف ⁦BIP323⁩، البديل المقترح له، ⁦24⁩ بتًا. وقت هذه المراجعة التحريرية، حالة الوثيقتين ⁦Draft⁩، أي مسودة. لا تعني الحالة وحدها أن لا تنفيذ موجود، ولا أن كل المجمّعات تدعمها. تصف الوثيقة الاستخدام المقصود للحقل، أما الاتصال الفعلي فيعتمد على القناع والبرامج المستخدمة. لذلك لا يستنتج بيتر صلاحيات جهازه من رقم ⁦BIP⁩، ولا يعدّ المقترح تغييرًا تلقائيًا لقواعد الشبكة. [4] [5]

يعبّر ⁦Hanke⁩ عن التوفير في النموذج بالصيغة ⁦x × (n − 1) / n⁩. يمثّل ⁦x⁩ حصة الحساب التي يمكن مشاركتها، و⁦n⁩ عدد المهام المناسبة. عند ⁦x = 25%⁩ و⁦n = 4⁩ تكون النتيجة ⁦18.75%⁩. تُنجز التحضيرات المشتركة معًا بدل تكرارها لكل مهمة. هذه نتيجة لنموذج حسابي، وليست تلقائيًا الانخفاض نفسه في الواط لأي جهاز. تؤثر الدوائر الأخرى وظروف التشغيل في الاستهلاك أيضًا. لذلك لا يجوز نقل النسبة دون قياس إلى توقع زيادة الأداء أو الإيراد. [1]

يتحقق بيتر أولًا من دعم الشريحة و⁦firmware⁩ والتعاون مع المجمّع. ثم يتأكد من قبول العمل ويقيس الجهاز كله في ظروف قابلة للمقارنة. تعني ⁦J/TH⁩ جولًا لكل تيراهاش، أي الطاقة اللازمة لتريليون محاولة هاش. ولكي تكون المقارنة مفيدة، يجب أن تشمل القياسات مكوّنات الجهاز نفسها والفترة الزمنية نفسها. لا يحل اسم ⁦ASICBoost⁩ محل هذا القياس. وهو ليس مرادفًا لرفع تردد التشغيل، ولا يضمن العثور على كتلة أو تحقيق الربح. إنه طريقة لإنجاز بعض العمل بكفاءة أفضل عندما تدعمه المنظومة المستخدمة كاملة. [1] [3]