Jeff Garzik مطوّر معروف بحساب jgarzik. عمل على برمجيات البيتكوين ومقترحات BIP، وهي وثائق تصف تغييرات أو إجراءات محددة. وتوضح مساهماته كيف يتطور البيتكوين: يستطيع المؤلف كتابة الشيفرة واقتراح قاعدة، لكنه لا يستطيع أن يأمر الشبكة كلها بقبولها.
يستخدم Jeff Garzik اسم jgarzik على GitHub. ويمكن تتبع عمله في مستودعات محددة، وهي أماكن عامة للشيفرة وسجل تعديلاتها. هذا أنفع من إسناد دور مبهم لشخص واحد باعتباره «من يدير البيتكوين». بالنسبة إلى البرنامج، يهمنا ما يفعله وأي إصدار ننظر إليه؛ وبالنسبة إلى المقترح، ما الذي كان يريد تغييره. ملف المطوّر وحده لا يحدد إصدار البرنامج الذي يشغله الآخرون. [1]
يصف ملف README التعريفي برنامج cpuminer الذي كتبه Garzik بأنه برنامج لتعدين Bitcoin باستخدام CPU، أي معالج الحاسوب. ويتيح تعدد خيوط التنفيذ توزيع الحسابات على مسارات تعمل بالتزامن. ويذكر مشروع pooler/cpuminer المخصص لـLitecoin وBitcoin صراحة أنه مشتق من ذلك البرنامج. أخذ شيفرة قائمة وتطويرها بصورة مستقلة يسمى fork للمشروع. هذا وحده لا يقسم شبكة البيتكوين، كما أن الميزات المضافة لاحقًا إلى النسخة المشتقة لم تكن بالضرورة موجودة في نسخة Garzik الأصلية. [2] [3]
Picocoin مثال آخر. فهو يضم libccoin، مكتبة بلغة C يمكن للمطورين استخدام وظائفها لبناء تطبيقات البيتكوين. لكن README يصف محفظة HD وعقدة brd المرتبطتين بالمشروع بأنهما WIP، أي قيد التطوير. تشتق محفظة HD مجموعة من المفاتيح من أصل مشترك، أما العقدة فمصممة للتواصل مع شبكة البيتكوين. أُرشف المستودع في 15 فبراير 2024. وهو مصدر مفيد لدراسة التاريخ، لكن إتاحة الشيفرة وحدها لا تثبت أنه منتج مكتمل وتجري صيانته وآمن لمدخراتك. [4]
تخيّل عقدة تريد معرفة المعاملات غير المؤكدة التي تعرفها العقدة المتصلة بها. يعالج BIP 35 من Garzik هذه المهمة: تطلب رسالة mempool قائمة، ويحتوي الرد inv على معرّفات المعاملات، أي تجزئاتها، ثم يمكن طلب البيانات نفسها عبر getdata. والـMempool «غرفة انتظار» محلية قبل التأكيد، لا قائمة واحدة مشتركة في العالم كله. كذلك يعيد أمر getrawmempool في وثائق Bitcoin Core محتوى عقدة محددة؛ والعثور على معاملة فيه لا يعني أنها تأكدت داخل كتلة. [5] [8]
يؤثر حجم الكتل في المساحة المتاحة للمعاملات وفي الموارد اللازمة لنقلها والتحقق منها. اقترح Garzik وTom Harding وDagur Valberg Johannsson في BIP 100 تعديل الحد وفق أصوات يكتبها المعدّنون داخل الكتل. تجري إعادة الحساب كل 2016 كتلة، مع اشتراط دعم بنسبة 75% في الكتل وتقييد مقدار كل تعديل. إذن ليس التصويت محسوبًا بعدد الأشخاص. يسجل الفهرس المقترح بحالة Closed، أي مغلق؛ ولا يثبت وصفه أن شبكة البيتكوين بأكملها تبنت الآلية. [6]
لنأخذ عقدة عادية ما زالت تتحقق من الحد الأصلي البالغ 1 MB. عندما تصلها كتلة أكبر، ترفضه حتى لو كان المعدّن الذي أنتجه يؤيد حدًا أعلى. يحذر BIP 100 تحديدًا من هذا الانقسام. فالصوت داخل الكتلة بيانات يمكن للبرنامج الجديد تفسيرها، وليس أمرًا يعيد كتابة برنامج قديم. والتغيير الذي يسمح بكتل ترفضها القواعد القديمة هو Hard Fork. هذا المعنى لكلمة fork مختلف عن مجرد إنشاء مشروع مشتق على GitHub. [6]
اقترح BIP 102 من Garzik طريقًا آخر: رفع الحد مرة واحدة إلى 2 MB. وكان التفعيل يتطلب استيفاء شرط زمني محدد، مع الإشارة إلى الدعم في 95% من آخر 1000 كتلة. استيفاء الشرطين لا يعدّل برامج التحقق القديمة تلقائيًا؛ إذ ستواصل رفض الكتل الأكبر. ويسجل هذا المقترح أيضًا بحالة Closed. إنه يوثق تغييرًا مقترحًا، ولا يشرح قواعد حجم كتل البيتكوين المطبقة اليوم. [7]
ينبغي قراءة محتوى كل BIP وحالته معًا. يسجل BIP 35 بحالة Deployed، أي مطبق، ضمن طبقة Peer Services التي تتناول الخدمات والاتصال بين العقد. أما BIP 100 وBIP 102 فهما Closed ضمن Consensus (hard fork)، لأنهما يتعلقان بالكتل التي تعتبرها العقد صالحة. يمكن للمؤلف نفسه أن يعمل في المجالين بنتائج مختلفة. نجاح إدخال رسالة شبكية لا يعني تطبيق جميع تغييرات القواعد التي اقترحها ذلك المؤلف. [5] [6] [7]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Cynthia Lummis, Mike Hearn, حرب حجم الكتلة. تشير إلى هذا المدخل أيضًا Mike Hearn.