Signet

تريد آنا معرفة ما تعرضه محفظة جديدة بعد إرسال دفعة وبعد تأكيدها داخل كتلة. المحفظة تطبيق أو جهاز لاستقبال البيتكوين وإرساله. تجمع الكتلة معاملات في دفعة تُضاف إلى السجل المشترك. يمكن لآنا على Signet استخدام عملات اختبار، مثل التي توزعها خدمة faucet المخصصة للتجارب. ليست هذه BTC على mainnet، أي الشبكة الرئيسية، ولا يحولها البروتوكول إلى بيتكوين حقيقي. وتحتاج العناوين أيضًا إلى انتباه: يشترك Signet مع Testnet في بعض صيغ عناوين الاختبار. لذلك لا يكفي شكل العنوان وحده لتحديد الشبكة الصحيحة. [1] [2] [8]

كتب Karl-Johan Alm وAnthony Towns المقترح BIP 325 (المستند التقني الذي يصف Signet)، وأضاف Bitcoin Core v0.21.0 دعم Signet. يوفر البرنامج شبكة عامة افتراضية، لكن يمكن لفريق تحديد شرطه الخاص لإنشاء الكتل والمشاركين فيه. لذلك لا تكفي عبارة «نستخدم Signet»: يجب أن يستخدم الطرفان الشبكة نفسها. يُشتق معرّف رسائل الشبكة من ذلك الشرط، لا من اسم المشروع. [1] [3] [4]

العقدة من نوع Full Node تتحقق من القواعد بنفسها. وتظل تفحص المعاملات وProof of Work، أي نتيجة العمل الحسابي اللازم لإنشاء الكتلة، ثم تفحص شرط Signet الإضافي. لذا لا يكفي التعدين وحده على الشبكة الافتراضية؛ يلزم أيضًا التوقيع المناسب. ولا يغني رأس الكتلة، وهو ملخصها الموجز، عن هذا الفحص الإضافي، لأن البيانات المطلوبة موجودة داخل الكتلة. [1] [9]

يتيح التوقيع الرقمي التحقق من أن حامل المفتاح الخاص المعني قد أجاز الرسالة، دون الكشف عن المفتاح، وهو قيمة عددية سرية. من يستطيع استيفاء شرط التوقيع يؤثر في إضافة الكتل. يمكنه تأخير التوقيع أو تقييد المعاملات التي يدرجها. لكن ذلك لا يمنحه مفاتيح آنا الخاصة، ولا حق إجبار عقدتها على قبول أي معاملة غير صالحة. تبقى القواعد الأخرى سارية. هذه المشاركة المنظمة مفيدة للاختبارات، وهي أيضًا سبب عدم اعتبار Signet نسخة من نموذج أمان mainnet. [1] [9]

لا يكفي أثناء التطوير مشاهدة دفعة ناجحة واحدة. يحتاج الفريق إلى معرفة تصرف التطبيق عند توقف الكتل أو حدوث إعادة تنظيم، أي عندما تستبدل العقدة كتلًا حديثة بفرع صالح آخر. يستطيع اختبار منسق إعداد هذه الحالة ومراقبة تحديث المحفظة لحالة التأكيدات. إذن لا يعد Signet بخدمة دون انقطاع، بل يساعد على اختبار الإخفاقات بصورة أكثر قابلية للتوقع. [1] [5] [6]

إنشاء الكتل في Testnet مفتوح، وقد تعقّد تقلباته تجربة مشتركة. أما Regtest فيتيح إنشاء الكتل بسهولة عند الطلب، وهو مناسب للاختبارات الآلية الخاصة بالمطور. ويمكنه ربط عدة حواسيب؛ ليس بالضرورة برنامجًا منفردًا. يلبي Signet حاجة أخرى: تعاونًا أطول بين مشاركين مستقلين مع شروط متفق عليها لإنشاء الكتل. ولا يغني أي من هذه الأوضاع عن جميع الاختبارات الأخرى. [1] [2]

الـchallenge سكربت، أي برنامج قصير يحدد ما يجب أن تثبته الكتلة. قد يتطلب توقيعًا واحدًا أو Multisig، أي عددًا متفقًا عليه من تواقيع عدة مفاتيح. ويمكن لشبكة Signet خاصة استخدام OP_TRUE، وهو شرط يتحقق دون توقيع، فتكون الإجابة الفارغة كافية. لذلك الأدق الحديث عن شرط سكربت إضافي، لا القول إن كل Signet يحتاج دائمًا إلى موقّع. [1] [9]

يضع BIP 325 الإجابة غير الفارغة في بيانات خاصة ضمن Coinbase Transaction، أول معاملة في الكتلة. ولا علاقة لهذا المصطلح هنا بالبورصة التي تحمل الاسم نفسه. توسع البيانات الالتزام التشفيري (commitment) وفق BIP 141، وهو سجل يربط الكتلة ببيانات witness التي تتضمن التواقيع، وتُعرف بالعلامة 0xecc7daa2. ليست دفعة عادية إضافية إلى الموقّع. يمكن حذف الإجابة الإضافية عندما يكون الشرط متحققًا بصورة بديهية، لكن ذلك لا يلغي تلقائيًا بقية قواعد الكتلة. [1] [9] [10]

لو احتوت الرسالة الموقعة على التوقيع نفسه، لنشأت علاقة دائرية. لذلك يستخدم التحقق بصمة معدّلة للمعاملات تُفرغ فيها الإجابة، مع معاملتين افتراضيتين. تُستخدمان للحساب ولا تُرسلان كدفعات إضافية. كذلك لا يشمل التوقيع nonce رأس الكتلة، الرقم الذي يتغير أثناء البحث عن Proof of Work. تغييره لا يتطلب توقيعًا جديدًا، لكن ذلك لا يسمح بتغيير بقية محتوى الكتلة بحرية. [1] [9]

تتأكد آنا أولًا من أن المحفظة والعقدة ومستكشف الكتل تستخدم شبكة الاختبار نفسها. مستكشف الكتل تطبيق للبحث عن المعاملات والكتل في شبكة معينة. في Bitcoin Core يساعد الأمر getblockchaininfo وحقل signet_challenge في عرض الشرط المضبوط. ثم تراقب تأكيدًا فعليًا، لا مجرد رسالة «أُرسلت»، وتستخدم محفظة اختبار منفصلة. يُظهر النجاح سلوك التطبيق في تلك الظروف؛ ولا يضمن أمان الأموال أو مقاومة مهاجم على mainnet. [7] [8]