Full Node برنامج يتحقق بنفسه من قواعد Bitcoin. يعمل على حاسوب ويستقبل الكتل والمعاملات ويحدد أيها يمكن قبوله في سجل صحيح. بعقدتك الخاصة، لا تحتاج إلى الاعتماد في هذا الفحص على ادعاء مُعدّن أو خادم آخر. لكن كي تستفيد محفظتك أيضًا، يجب أن تستخدم تلك العقدة فعلًا مصدرًا للبيانات.
تخيل أن محفظتك تعرض دفعة واردة. كيف تعرف أن المعاملة تنتمي فعلًا إلى سجل Bitcoin وتلتزم بالقواعد؟ يمكنها سؤال خادم آخر أو استخدام عقدتك. يحقق Full Node الخيار الثاني: يفحص صحة البيانات المستلمة بنفسه. لا يسأل أغلبية الحواسيب المتصلة كيف يقرر. وإذا أرسل أحد كتلة تخالف القواعد، يرفضها. لذلك لا يحل عدد الاتصالات محل فحص القواعد. عقدتك تتيح لك التحقق من البيانات التي تبني عليها دفعاتك. [1] [3]
تفحص العقدة ترابط الكتل وترويساتها وProof of Work، أي الدليل الحسابي المطلوب للكتلة. وفي المعاملات تتحقق، من جملة أمور، من وجود الأموال المشار إليها وعدم إنفاقها مرتين واستيفاء شروط استخدامها. تُكتب هذه الشروط في نصوص برمجية، وهي مجموعات صغيرة من القواعد. وتفحص أيضًا كمية البيتكوينات المنشأة حديثًا. النتيجة المتجددة هي UTXO set، مجموعة مخرجات المعاملات غير المنفقة: سجل الأموال المحددة التي لا تزال متاحة. قد يرجح العمل المتراكم الأكبر أحد فرعين صحيحين، لكنه لا يجعل كتلة غير صحيحة صحيحة. [1]
لا. يفحص Full Node الكتل والمعاملات، ولا يمنحه التحقق الاعتيادي وحده مكافأة كتلة. أما المُعدّن فيبني اقتراح كتلة ويكرر الحساب حتى يجد نتيجة تحقق الشرط. يستخدم الحساب قيمة تجزئة، وهي بصمة رقمية لترويسة الكتلة. يمكن للدورين العمل معًا؛ فالمُعدّن يحتاج إلى معرفة السجل الذي يواصله والمعاملات التي يجوز إدراجها. لكن ذلك لا يعني أن كل عقدة يجب أن تعدّن. الفحص والمنافسة للعثور على الكتلة التالية نشاطان مختلفان. [5] [1]
تحتاج العقدة الجديدة أولًا إلى اللحاق بسجل الشبكة. تنزل الكتل وتعالج بياناتها، فيما يسمى المزامنة الأولية. وينبغي التمييز بين طريقتين متقدمتين لتسريعها. يتيح assumevalid لبرنامج Bitcoin Core تجاوز فحوص قديمة للنصوص البرمجية ضمن شروط محددة؛ ويعطل assumevalid=0 هذا التحسين. أما AssumeUTXO فيتيح تحميل لقطة حالة، أو snapshot، تحفظ الأموال غير المنفقة عند كتلة معينة. يقارن البرنامج بصمتها بقيمة مضمنة في الشيفرة المصدرية ثم يتحقق من السجل الأقدم في الخلفية. لذلك لا تعني إتاحة الحالة الحالية وحدها اكتمال فحص التاريخ. [1] [2]
لا يلزم Full Node الاحتفاظ بكل ملفات الكتل القديمة إلى الأبد. يحذف Pruning بعض الملفات بعد معالجتها، مع إبقاء UTXO set الحالية والبيانات الأحدث اللازمة. وتستمر العقدة في فحص الكتل الجديدة. تحتفظ العقدة الأرشيفية بالكتل القديمة لتوفرها للآخرين أو تعيد مسحها. لذلك لا يساوي توفير القرص استخدام عميل SPV، أي عميل التحقق المبسط من الدفعات. فهذا لا يفحص جميع المعاملات وحالتها بالطريقة نفسها التي يفحص بها Full Node. الفرق في ما تتحقق منه، لا في عدد الملفات المخزنة فقط. [3]
في المزامنة المعتادة، تنزل العقدة التي تستخدم الحذف التدريجي الكتل التاريخية وتعالجها قبل إزالتها تباعًا. لذلك ليس Pruning مفتاحًا لتجاوز التحقق من الكتل القديمة؛ وظيفته توفير التخزين. التحسينات السابقة مسألة منفصلة: قد يتجاوز assumevalid فحوص نصوص برمجية قديمة بشروط معينة، بينما يتيح AssumeUTXO استخدام لقطة الحالة مع استمرار فحص التاريخ. لتقييم جاهزية العقدة، انظر إلى طريقة المزامنة وتقدمها الفعلي، لا إلى حجم بياناتها على القرص فقط. [3] [2]
تحتاج المحفظة معلومات عن المعاملات والتأكيدات. إذا أخذتها من خادم آخر، فإنها ترسل استعلامات قد يستنتج منها الخادم معلومات عن دفعاتها. يتيح وصلها بعقدتك Full Node استخدام بيانات فحصتها عقدتك دون هذه الاستعلامات إلى الخادم الخارجي. لكن تثبيت العقدة وتشغيلها لا يعيد توصيل المحفظة تلقائيًا. المهم مصدر البيانات الذي تدعمه وتستخدمه فعلًا. كما أن عقدتك لا تمنح إخفاء الهوية تلقائيًا؛ فالخصوصية تعتمد أيضًا على بيانات شبكة أخرى وطريقة استخدام المحفظة. [3] [4]
يمكن أن تعمل العقدة دون مفاتيحك الخاصة. تسمح المفاتيح بتوقيع الدفعات، بينما تتحقق العقدة من التزام المعاملات والكتل بالقواعد. لا يلزم أن يتولى الجهاز نفسه المهمتين. لذلك لا تكتفِ بالتأكد من أن عقدتك تعمل في مكان ما؛ افحص أيضًا من أين تقرأ المحفظة بياناتها وكيف تبث المعاملات. لا يحل التحقق المستقل محل نسخة احتياطية آمنة للمفاتيح ولا يزيل كل المعلومات التي قد يكشفها الاتصال الشبكي. إنه يساعد في جزء محدد من العملية: فحص بيانات Bitcoin باستقلالية. [3] [4]
للعقدة واجهتان مختلفتان. عبر اتصالات P2P تتبادل الكتل والمعاملات مع العقد الأخرى. أما RPC فهي الواجهة التي تعطي التطبيقات من خلالها الأوامر، وقد تتحكم أيضًا بالمحفظة عند توفرها. لذلك يختلف فتح منفذ P2P وارد لتبادل البيانات عن كشف RPC للغرباء. يوصي Bitcoin Core بعدم إتاحة RPC مباشرة على الإنترنت العام. وللوصول المحلي يستخدم عادة بيانات دخول في ملف .cookie لإثبات صلاحية التطبيق. هذا ليس ملف تتبع خاصًا بمتصفح الويب. [4]
تتيح أوامر العقدة فحص أكثر من أيقونة خضراء. في getblockchaininfo تحقق من الشبكة الصحيحة، ومن blocks لعدد الكتل المعالجة وheaders للترويسات المعروفة وinitialblockdownload لحالة المزامنة الأولية. وعند استخدام لقطة حالة، يساعد getchainstates في التمييز بين الحالة الحالية وفحص التاريخ في الخلفية. عدد الاتصالات وحده لا يثبت اكتمال التحقق. وأخيرًا، تأكد أن العقدة لم تبقَ عند قمة قديمة للسلسلة، وأن المحفظة تحصل فعلًا على البيانات منها. عندها فقط يستفيد استخدامك للمحفظة من فحص العقدة المستقل. [2] [1]
للحصول على صورة أوضح، اقرأ هذا المدخل مع Bitcoin, Timechain / Blockchain, معاملة, UTXO, Proof of Work. تشير إلى هذا المدخل أيضًا Bitcoin, Satoshi Nakamoto, Timechain / Blockchain, Proof of Work.