Mike Hearn مطوّر في Bitcoin ومؤلف مشارك لعدد من مقترحات BIP، وهي وثائق تصف حلولًا تقنية مقترحة. عمل على مكتبة bitcoinj وطرق فحص الاتصالات وانتقاء المعاملات المطلوبة وتبادل الرسائل أثناء الدفع. ويسهل فهم إسهامه إذا تتبعنا المسار من محفظة الهاتف إلى المتجر الذي ينتظر الدفع.
لا يحتاج من يطوّر محفظة بيتكوين إلى كتابة كل وظائف الاتصال من البداية. يمكنه استخدام مكتبة برمجية، أي مجموعة من الوظائف الجاهزة يبني عليها تطبيقه. bitcoinj إحدى هذه المكتبات. يسرد ملف AUTHORS فيها اسم Mike Hearn بين مساهمين كثيرين، ويحيل إلى سجل التغييرات في Git. بذلك يمكن تتبع مساهمات محددة. ولا يعني ذلك أن Hearn كتب جميع الوظائف وحده، أو أنه يقود المشروع كله اليوم. [1]
bitcoinj مكتبة بلغة Java تتيح إدارة محفظة وإرسال المعاملات واستقبالها دون تثبيت Bitcoin Core محليًا. يناسب الهاتفَ نمط SPV، اختصار Simplified Payment Verification، أي التحقق المبسط من الدفع. يتعامل هذا النمط مع رؤوس الكتل والمعاملات المتعلقة بالمحفظة بدلًا من فحص كل معاملة فحصًا كاملًا، فيوفر البيانات وموارد الجهاز. وتصف الوثائق أيضًا نمطًا تجريبيًا للتحقق الكامل. هذان نمطان مختلفان؛ التشغيل الأخف لا يعني إجراء الفحص نفسه لجميع القواعد بسرعة أعلى فحسب. [2]
لنتخيل حاسوبًا محمولًا استيقظ من وضع السكون. قد يبدو الاتصال بعقدة أخرى مفتوحًا، مع أنه لم يعد يعمل. يتيح BIP 31 الذي كتبه Hearn إرسال ping يتضمن nonce، وهو هنا رقم لتمييز طلب معين. يعيد الطرف الآخر الرقم نفسه في رسالة pong. مع إصدارات البروتوكول الأعلى من 60000، يمكن بهذه الطريقة مطابقة الردود بالطلبات وقياس زمن الاستجابة. هذا فحص للاتصال؛ فالرد وحده لا يثبت نزاهة العقدة ولا صحة الدفع. [3]
لماذا ينزّل الهاتف معاملات لا تخصه؟ يصف BIP 37، الذي كتبه Hearn وMatt Corallo، مرشح Bloom: أداة صغيرة لانتقاء المطابقات المحتملة. يضبط filterload المرشح، ويضيف filteradd عنصرًا، ويحذف filterclear المرشح. وقد تمر معاملة غير مرتبطة بالمحفظة، وهذا ما يسمى نتيجة إيجابية كاذبة. تقلل الدقة الأعلى حجم البيانات المنقولة، لكنها قد تسهّل على الطرف الآخر ربط المعاملات بعنوان IP للمحفظة. لذلك لا يعني توفير البيانات حماية الخصوصية تلقائيًا. [4]
يحتاج الهاتف إلى معرفة ما إذا كانت المعاملة المستلمة تنتمي فعلًا إلى كتلة معينة. توفر رسالة merkleblock في BIP 37 بيانات لإثبات Merkle: تكفي بضع بصمات للبيانات، أي قيم هاش، لفحص ارتباط المعاملة بالبصمة المجمعة الموجودة في رأس الكتلة. ولا يلزم تنزيل الكتلة كاملة لهذا الغرض. لكن الإثبات لا يستبعد أن يكون الطرف الآخر قد أخفى معاملات أخرى. كما لا يحل SPV محل التحقق الكامل من صحة المعاملات. وتشرح وثائق bitcoinj خطر سيطرة مهاجم على جميع اتصالات المحفظة، بحيث يختار ما يعرضه عليها. [4] [5]
عند الشراء تحتاج إلى معرفة المبلغ والمستلم. يقدم BIP 70، الذي كتبه Gavin Andresen وHearn، رسالة PaymentRequest لهذا الغرض. تتضمن تفاصيل الدفع: المخرجات التي تحدد أين تخصص المعاملة الأموال، والمبلغ، ووقت انتهاء اختياري للطلب. ويمكن توثيق هوية التاجر بشهادات X.509، على نحو شبيه بخوادم الويب. لكن البروتوكول يسمح أيضًا بـ pki_type none، أي طلب دون هذا التوثيق. لذلك لا يكفي استخدام صيغة طلب الدفع لإثبات هوية موثقة للمتجر. [6]
إذا حدد الطلب خادمًا للدفع، ترسل المحفظة إليه رسالة Payment بعد موافقتك على العملية. وقد يفيد الرد PaymentACK بأن المتجر قبل الدفع للمعالجة. هذه معلومة مفيدة للعميل، لكنها تظل تصريحًا من خادم التاجر، وليست دليلًا على تأكيد المعاملة في كتلة. وبالمثل، يحدد refund_to فقط المكان الذي قد يرسل إليه المتجر مبلغ الاسترداد؛ ولا يعيد الحقل المال بنفسه. على التطبيق أن يميز بين الرسائل المتعلقة بالدفع وحركة الأموال الفعلية. [6]
قد يوحي دليل قديم بأن الإجراء الذي يشرحه يعمل في كل البرامج. يسجل الفهرس BIP 70 بحالة Deployed، أي أنه طُبق. ومع ذلك، توثق ملاحظات Bitcoin Core 0.20.0 إزالة دعمه بالكامل من هذا البرنامج. لا تناقض هنا: فالمواصفة التي استُخدمت في الماضي لا يلزم أن يدعمها كل برنامج اليوم. تساعد أعمال Hearn على فهم تطور المحافظ؛ أما التطبيق العملي فيحتاج أيضًا إلى فحص قدرات البرنامج المحدد وإصداره. [6] [7]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Jeff Garzik, Gloria Zhao, Merkle Tree. تشير إلى هذا المدخل أيضًا Jeff Garzik, Gloria Zhao.