Testnet

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

Testnet ليست حساب تدريب داخل شبكة Bitcoin الرئيسية، بل سلسلة أخرى تبدأ من Genesis Block خاص بها. تجمع الكتلة معاملات في السجل المشترك، وGenesis Block هي كتلة البداية فيه. ولشبكة Testnet أيضاً مجموعة UTXO خاصة، أي مخرجات معاملات لم تُنفق بعد. يحدد المخرج مبلغًا وشروط إنفاقه، مثل التوقيع المطلوب. لذلك لا ينشئ وصول عملات إلى آنا على شبكة رصيداً على الأخرى. تميّز البرامج بين الشبكات من خلال معلماتها، مثل معرّفات بداية الرسائل والمنافذ. لكن اختلاف الشبكة لا يعني بالضرورة اختلاف شكل العنوان. المفتاح الخاص بيانات سرية تستخدمها المحفظة لإنشاء توقيع يجيز إنفاق الأموال المرتبطة به. وحتى استخدام مفاتيح خاصة متطابقة لا يدمج السجلّين في محفظة ذات رصيد مشترك. [12] [15]

قد تنتمي العناوين التي تبدأ بـtb1 إلى Testnet3 أو Testnet4 أو Signet. لذا تتفق آنا وبافل على الشبكة المحددة ويتحققان منها في التطبيقين؛ فكلمة «اختبار» وحدها لا تكفي. تستخدم آنا مفاتيح جديدة ونسخة احتياطية منفصلة للتجارب. ولا تدخل Seed Phrase، أي كلمات الاستعادة، لمحفظة فيها أموال حقيقية في تطبيق تجريبي، لأن تبديل الوضع لا يجعل البرنامج غير الموثوق آمناً. كذلك لا تحتاج خدمة faucet إلا إلى عنوان استقبال عام على الأكثر، وليس كلمات الاستعادة أو مفتاحاً خاصاً. فصل ملفات المحافظ والمفاتيح والنسخ الاحتياطية يقلّل الالتباس والربط غير المقصود بين التجارب والمدفوعات الشخصية. [12] [14]

تتيح Testnet العامة التجربة مع مشاركين غير معروفين وتعدين مفتوح. أما Signet فهي بيئة اختبار أيضاً، لكنها تشترط، إلى جانب Proof of Work، أي العمل الحسابي اللازم للعثور على كتلة صالحة،، استيفاء شرط للكتلة يكون عادة توقيعاً بمفاتيح مخوّلة. وهذا يساعد على تنسيق إنتاج الكتل، لكنه لا يضمن العمل بلا انقطاع. وتناسب Regtest المطوّر الذي يحتاج إلى التحكم في تجربته: يشغّل بيئته الخاصة وينشئ الكتل عند الطلب، مثلاً داخل اختبار آلي. وإذا كانت آنا تتعلّم استخدام المحفظة فقط، فمن المهم أيضاً معرفة الشبكات التي يدعمها التطبيق. لا تحوّل أي من هذه الشبكات عملاتها إلى بيتكوين على الشبكة الرئيسية. [10] [11] [16]

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

تذكر الأدلة القديمة Testnet3 التي بدأت عام 2011. ومع سنوات التشغيل ظهرت مشكلات في توزيع العملات وقواعد صعوبة التعدين. وكانت ظاهرة block storms تعني اندفاعاً من الكتل المعدّنة بسرعة كبيرة؛ فارتفع عدد الكتل على نحو غير معتاد وانخفضت إعانة الكتل الجديدة أسرع مما يوحي به مرور الوقت على التقويم. كما جرى تداول عملات الاختبار رغم أنها يفترض أن تكون أداة متاحة بسهولة. لذلك يعني الجيل الجديد بداية سجل جديد، لا إعادة تسعير الأرصدة القديمة. عند قراءة دليل، تحقّق من رقم الشبكة وليس من اسم Testnet فقط. [1]

تصف وثيقة المقترح التقني BIP 94 شبكة Testnet4، وبدأ دعمها في Bitcoin Core 28.0. إلى جانب Genesis Block جديد، عُدّلت طريقة حساب الصعوبة وقواعد توقيت الكتل للحد من وسائل معروفة لإحداث block storms. لكن بقي استثناء: باستثناء أول كتلة في فترة الصعوبة، تفرض علامة زمنية تتجاوز توقيت الكتلة السابقة بأكثر من 20 دقيقة استخدام الحد الأدنى للصعوبة. هذا ليس وعداً بتأكيد دفعة خلال 20 دقيقة. وتطبّق Testnet4 منذ البداية أيضاً تغييرات القواعد التي كانت فعّالة على mainnet عند اقتراحها في مايو 2024. هذه التحسينات لا تجعلها نموذجاً خالياً من الأعطال للشبكة الرئيسية. [1] [9]

في 17 أكتوبر 2026، تحمل BIP 95 الخاصة بـTestnet5 حالة Draft، أي مسودة قيد التطوير. وتقترح إزالة استثناء الحد الأدنى للصعوبة، ورفع هذا الحد، وتطبيق BIP 54 من أول كتلة؛ وهي مجموعة تغييرات مقترحة لقواعد الإجماع. لكن الوثيقة لم تستكمل بعد بيانات Genesis Block ولا رابط التطبيق المرجعي. لذلك لا يصح الاستناد إليها لتقديم Testnet5 بوصفها شبكة منشورة بصورة اعتيادية في Bitcoin Core. كما أن اختبار قواعد جديدة لا يفعّلها على mainnet. وعند القراءة لاحقاً، ينبغي مراجعة حالة المقترح ووثائق إصدار البرنامج المستخدم، لا الاعتماد على الرقم الأكبر في الاسم. [2]

في Bitcoin Core يختار الخيار testnet4 شبكة Testnet4؛ وتوضح وثائق الإصدار المستخدم الصيغة الدقيقة للأمر. في ملف الإعدادات تشير [test] إلى Testnet3، بينما تشير [testnet4] إلى Testnet4. وتُحفظ البيانات في مجلدات فرعية منفصلة باسم testnet3 أو testnet4 أو signet أو regtest. لكن يجب التحقق أيضاً من البرنامج أثناء عمله: يعيد getblockchaininfo معرّف الشبكة في الحقل chain. ويُضاف إلى ذلك فحص بصمة Genesis Block وحالة المزامنة والعقد المتصلة. وفي Signet مخصّصة لا تكفي كتلة البداية المشتركة؛ بل يجب التأكد من شرط الكتلة الخاص بها أيضاً. عنوان النافذة أو تشابه العنوان لا يعوّضان هذه الفحوص. [8] [12] [13] [14] [10]

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