Stratum V1

شغّلت إيفا جهاز ASIC، وهو جهاز مخصص لتعدين Bitcoin، ووصلته بمجمّع تعدين. ينسّق المجمّع عمل المعدّنين الباحثين عن الكتلة التالية، وهي مجموعة معاملات تُضاف إلى سجل Bitcoin. لكن القدرة الحسابية وحدها لا تكفي: يحتاج الجهاز إلى مهمة، ويحتاج المجمّع إلى معرفة العمل الذي أسهمت به إيفا. يتولى Stratum V1 هذا الحوار. يرسل المجمّع بيانات للبحث عن الكتلة التالية، ويحسب الجهاز ثم يعيد نتائج وسيطة. مثل لغة مكالمة هاتفية، يتيح البروتوكول للطرفين فهم بعضهما. لكنه لا يحدد سعر العمل. تحدد ذلك قواعد منفصلة لمكافآت المجمّع، بينما تتحقق عُقد Bitcoin من صلاحية الكتلة المكتشفة. [4] [2]

مع تسارع الأجهزة، أصبحت طريقة getwork القديمة أقل ملاءمة. كانت توزع كميات صغيرة من العمل، فيضطر الجهاز إلى طلب المزيد باستمرار. أعلن Marek Palatinus اقتراحًا جديدًا في 11 سبتمبر 2012. يُبقي Stratum الاتصال مفتوحًا، فيرسل المجمّع تغيير المهمة دون انتظار طلب آخر، مما يقلل عبء التواصل. هذا لا يستبدل جميع أجزاء التعدين: يستطيع المجمّع مواصلة الحصول على مسودة كتلة من عقدة Bitcoin عبر getblocktemplate الموصوفة في BIP 22. [11] [3] [5]

يرسل برنامج التحكم عادةً mining.subscribe أولًا لطلب استقبال العمل. ويتلقى بيانات الاتصال وما يميز حساباته عن غيرها. ثم تربط رسالة mining.authorize الجهاز بحساب. المقصود بكلمة worker هنا معرّف جهاز أو اتصال، وليس موظفًا. تستطيع إيفا بهذه الطريقة تمييز عدة أجهزة ضمن حساب واحد. لكن كلمة المرور المحتملة في هذه الرسالة لا تثبت وحدها هوية الخادم ولا تشفّر الاتصال. لذلك لا يعني نجاح تسجيل الدخول أن الاتصال آمن. [2] [13]

تحمل mining.notify مهمة جديدة يحددها job_id، مع رابط بالكتلة السابقة وبيانات تخص المعاملات والوقت ومعلومات أخرى لترويسة الكتلة، وهي مجموعة موجزة من البيانات التي تصف الكتلة. يهم هنا مؤشر clean_jobs. تفرض القيمة true ترك المهام القديمة، بينما تسمح false بمتابعة المهمة السابقة أثناء الانتقال إلى الجديدة. إذن ليست كل رسالة جديدة إبطالًا تلقائيًا لكل النتائج الجاري حسابها. والمهمة نفسها ليست كتلة صالحة جاهزة، بل مرشحًا يحتاج إلى الحساب. [2] [13]

هذا الجزء تقني، ولا يلزم حفظ كل حقل لتوصيل جهاز عادي. يرسل المجمّع جزأين من معاملة coinbase التي تدفع مكافأة الكتلة؛ والمقصود ليس منصة التداول ذات الاسم نفسه. يضع البرنامج بينهما extranonce1 الذي خصصه المجمّع وextranonce2 الخاص به، ليحصل على تنويعات إضافية للعمل. ومن المعاملة وMerkle branches المرسلة، وهي قيم وسيطة في تلخيص شجري للمعاملات، يحسب Merkle root. ويشكّل ذلك مع مرجع الكتلة السابقة والإصدار والوقت والحد الأعلى المرمّز لقيمة hash أساس ترويسة طولها 80 بايت. يحسب ASIC مرارًا hash الترويسة، أي بصمتها العددية، مع تغيير nonce، وهو عدد يتيح محاولات جديدة. [2] [4] [13] [14]

العثور على كتلة كاملة نادر. لذلك يضع المجمّع حدًا أسهل للنتيجة، يسمى target. والنتيجة التي تفي به تسمى mining share، وهي دليل على عمل منفذ. لا تحقق معظم shares الحد الأكثر صرامة لشبكة Bitcoin، لكن إحداها قد تحققه أيضًا فتساعد على إنتاج كتلة صالحة. تعدّل mining.set_difficulty والآلية التلقائية vardiff صعوبة shares كي لا تصل النتائج بكثرة مفرطة أو بندرة شديدة. وهما لا تغيران صعوبة الشبكة. يتطلب تحقيق شرط أصعب حسابات أكثر في المتوسط، ولذلك يكون للنتيجة وزن أكبر عند قياس العمل. قلة shares الأصعب لا تعني وحدها مكافأة أقل؛ فوزنها وقواعد الدفع مهمان أيضًا. [2] [4] [13]

يرسل الجهاز عبر mining.submit معرّف worker وjob_id وextranonce2 وnTime (الوقت المسجل في الترويسة) وnonce. يعيد المجمّع بناء النتيجة ويتحقق منها. تعني duplicate تكرار العمل نفسه، وlow difficulty نتيجة لا تحقق المطلوب، وstale عملًا على مهمة لم تعد مقبولة. لهذا تراقب إيفا النتائج المرفوضة وتأخر الاتصال، لا سرعة الجهاز فقط. وحتى قبول share ليس تحويلًا إلى المحفظة بعد: يتولى Stratum نقل العمل، أما احتساب المكافأة ودفعها فلهما قواعد مستقلة. [2] [13]

يصف BIP 310، المطروح في عام 2018، الاتفاق على إمكانات إضافية عبر mining.configure. ظلت الوثيقة التي روجعت في 17 أكتوبر 2026 تحمل حالة Draft، أي مسودة. تسمح version-rolling بتغيير البتات المتفق عليها فقط في إصدار الترويسة؛ وبعد الاتفاق تضيف حقلًا سادسًا إلى mining.submit. وليست إذنًا بتغيير قواعد Bitcoin كما يشاء الطرفان. تتناول minimum-difficulty وsubscribe-extranonce الحد الأدنى المطلوب لصعوبة shares وإشعارات قيم extranonce الجديدة. الاتفاق على الإمكانات يمنع سوء الفهم بين البرامج، لكنه لا يوفر التشفير بنفسه. [6]

يعمل V1 غالبًا عبر TCP غير مشفّر. دون حماية إضافية، قد يقرأ طرف على مسار الاتصال الرسائل أو يغيّرها ويحاول إعادة توجيه العمل. تناول بحث Hardening Stratum عام 2017 هذه المخاطر عمليًا. يتعلق الأمر باتصال الجهاز بالمجمّع، لا بكسر Bitcoin نفسه. وفي الترتيب المعتاد يختار المجمّع أيضًا معاملات الكتلة. امتلاك إيفا للجهاز لا يعني أنها تحدد هذا المحتوى. وتظل عُقد Bitcoin ترفض الكتل المخالفة للقواعد حتى إن أنتجها مجمّع كبير. [7] [4]

يقدم Stratum V2 رسائل ثنائية أكثر اختصارًا واتصالًا محميًا بالتشفير. وقد يتيح المكوّن المنفصل Job Declaration للمعدّن اقتراح مجموعة معاملات يختارها لإدراجها في الكتلة، إذا دعمه الطرفان واستخدماه. وجود مترجم بين V1 وV2 أو مجرد علامة V2 لا يثبت هذه القدرة. على إيفا التحقق من دعم البرنامج الثابت وعنوان الخادم الصحيح وحماية الاتصال والنتائج المرفوضة والاتصالات الاحتياطية. الفكرة الأساسية لـV1 بسيطة: إيصال العمل وإثبات الحساب، مع الفصل بينهما وبين اختيار محتوى الكتلة ودفع المكافأة. [8] [12] [10]