05 / 736TIME

Timechain / Blockchain

سلسلة Bitcoin الزمنية

السجل المشترك لكتل Bitcoin: يحدد المدفوعات التي تأكدت وترتيبها من دون جهة مركزية واحدة تمسك بالسجل.

Timechain، أو Blockchain الخاصة بـ Bitcoin، هي السلسلة المترابطة من الكتل الصحيحة الممتدة من Genesis Block إلى الطرف الحالي للشبكة. تشير كل كتلة لاحقة إلى هاش سابقتها، أي بصمتها الرقمية، وتضيف Proof of Work لإثبات العمل الحاسوبي اللازم لإنشائها. لذلك تستطيع العقد التحقق بصورة مستقلة من التاريخ الذي يلتزم بالقواعد ويملك أكبر عمل متراكم. لا يعني «الزمن» هنا ساعة دقيقة لكل معاملة، بل يعني أساسًا ترتيبًا للأحداث يمكن إثباته.

تخيل سجلًا محاسبيًا عامًا تستطيع آلاف الحواسيب فحص كل صفحة جديدة فيه بصورة مستقلة. الصفحة الواحدة هي كتلة. تحتوي مجموعة معاملات ومرجعًا إلى الكتلة السابقة، ولذلك يكون للصفحات ترتيب محدد ولا يمكن خلطها اعتباطًا. Timechain هي هذا التسلسل المترابط كله، من الكتلة الأولى حتى الطرف الحالي. لا تسجل مقدار bitcoin الذي يملكه كل شخص معروف بالاسم؛ بل تحفظ تاريخ المعاملات الذي تستنتج منه العقد أي مخرجات بقيت غير منفقة. وهي ليست خادم شركة واحدة. يستطيع أي Full Node (عُقدة تتحقق بنفسها من المعاملات وقواعد الشبكة) تنزيل نسخة والتحقق منها. [1] [3]

في سياق Bitcoin يشير الاسمان إلى تاريخ الكتل نفسه. استخدم الكود المحفوظ السابق للإطلاق من نوفمبر 2008 كلمة timechain في التعليقات وأسماء المتغيرات أو الدوال. أما whitepaper فيتحدث عن الختم الزمني وسلسلة كتل وسلسلة Proof of Work، ولا تظهر فيه كلمة timechain نفسها. ثم أصبحت Blockchain المصطلح الشائع عالميًا. واليوم تُستخدم أيضًا كاسم واسع لشبكات وقواعد بيانات أخرى، بينما Bitcoin Timechain هي سلسلة Bitcoin المحددة. لذلك لا تدل الكلمتان في العنوان على بروتوكولين؛ إنهما تحفظان الاسم التاريخي إلى جانب المصطلح الشائع حاليًا. [2] [1] [8]

يمكن للتوقيع الرقمي أن يثبت أن صاحب المفتاح المطلوب أجاز المعاملة. لكنه وحده لا يمنع شخصًا من توقيع معاملتين متعارضتين تحاولان إنفاق المخرج نفسه غير المنفق من معاملة سابقة، ويسمى UTXO. قد تستقبل عقدة أولًا دفعة إلى تاجر، بينما تستقبل عقدة أخرى أولًا تحويل القيمة نفسها إلى المرسل. لذلك تحتاج الشبكة إلى تاريخ مشترك يحدد أي إنفاق تأكد وأيهما لم يعد صالحًا. تمنح الكتل المعاملات موضعًا قابلًا للتحقق داخل هذا الترتيب. لكنها لا تثبت أي رسالة أُنشئت أولًا وفق زمن البشر أو الشبكة؛ فقد ترى العقد المعاملات غير المؤكدة بترتيب مختلف. [1]

Block Header هو ترويسة تحمل بيانات الكتلة الأساسية. تشمل هاش الترويسة السابقة وMerkle Root الذي يجمع معرّفات معاملات الكتلة في هاش واحد. يشبه hash بصمة رقمية: فأي تغيير صغير في المدخل ينتج قيمة مختلفة. تغيير معاملة قديمة سيغير Merkle Root وhash تلك الكتلة والمرجع المخزن في الكتلة التالية. لن يبقى التعديل سطرًا واحدًا متغيرًا، بل سيكسر التسلسل اللاحق كله. لا يثبت الهاش وحده التزام المعاملات بالقواعد. على العقد أيضًا التحقق من المعاملات، وعلى كل كتلة استيفاء Proof of Work المطلوب. [3] [1]

لا تقبل العقدة فرعًا لمجرد أنه أطول أو لأن مُعدّنًا كبيرًا يروّج له. فهي تفحص القواعد أولًا: Proof of Work، والروابط بالكتل السابقة، والمكافأة المسموح بها، والمعاملات، وشروط الإنفاق، وما إذا كانت المدخلات تشير إلى أموال أُنفقت بالفعل. يظل الفرع غير الصحيح غير صحيح مهما بلغت قدرة صاحبه الحاسوبية. ولا تختار العقدة السلسلة ذات العمل المتراكم الأكبر إلا بين المرشحين الصحيحين. لذلك فقول «الفرع الصحيح ذو العمل الأكبر» أدق من مجرد «أطول سلسلة». يقدّر حقل chainwork العدد المتوقع من حسابات الهاش اللازمة لإنتاج السلسلة وفق صعوبة كل كتلة؛ وليس عدادًا للمحاولات التي نفذها المُعدّنون فعليًا. [4] [5] [6]

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

يضع المُعدّن الطابع الزمني في Block Header. تسمح قواعد الإجماع بهامش معين، لذلك لا تثبت قيمة time بدقة وقت إنشاء كتلة أو معاملة بعينها. ولا يلزم حتى أن يكون الطابع الزمني لكتلة ما أعلى من الطابع الزمني لسابقتها المباشرة. لذلك تستخدم Bitcoin في بعض القواعد Median Time Past، أي وسيط الطوابع الزمنية للكتل الإحدى عشرة السابقة. نحصل على الوسيط بترتيب هذه الطوابع الزمنية واختيار القيمة الواقعة في المنتصف. فهو يتقدم باستقرار أكبر من القيم المنفردة. كما أن متوسط عشر دقائق بين الكتل ليس جدولًا زمنيًا. قد تصل كتلتان متقاربتين جدًا، ثم يطول انتظار الكتلة التالية. يعطي ارتفاع الكتلة موضعًا دقيقًا في السلسلة، لا وقتًا دقيقًا في التقويم. [4] [7]

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

يمكن في Bitcoin إنشاء معاملة لا يمكن تأكيدها إلا ابتداءً من ارتفاع معين أو بعد وقت محدد. لا يأمر Timelock بتنفيذ المعاملة تلقائيًا في تلك الدقيقة، بل يحدد أبكر نقطة يمكن أن تدرجها فيها كتلة صحيحة. بالنسبة إلى nLockTime القائم على الزمن، يستخدم BIP 113 قيمة Median Time Past للكتلة السابقة بدل الطابع الزمني للكتلة الجاري إنشاؤها الذي يسهل تحريكه. وهكذا يعتمد الشرط على تاريخ عدة كتل. وحتى بعد تحققه، يجب بث المعاملة وقبول العقد لها واختيار مُعدّن إياها؛ ولا يضمن إدراجها في كتلة بعينها. [7] [4]

RPC واجهة لإرسال أوامر إلى العُقدة وقراءة إجاباتها. لا يحتاج Full Node إلى الثقة بقول مستكشف كتل عام إن كتلة أو معاملة تنتمي إلى التاريخ الحالي. بالنسبة إلى hash محدد، يستطيع RPC getblock عرض height وعدد التأكيدات وMerkle Root وtime وmediantime وhash السابق والصعوبة وchainwork. يجيب كل حقل عن سؤال مختلف: height يحدد الموضع؛ previousblockhash يبين الأسلاف؛ confirmations يبين العمق تحت الطرف الحالي؛ time هو قيمة الترويسة؛ mediantime وسيط؛ وchainwork يمثل العمل المتوقع المتراكم. لا يكفي رقم واحد بمفرده. ففكرة Timechain أن تتحقق العقدة من العلاقة بينها ومن كل قواعد الإجماع بوصفها كلًا واحدًا. [6] [4]

للحصول على صورة أوضح، اقرأ هذا المدخل مع Genesis Block, Proof of Work, معاملة, Full Node, Difficulty Adjustment. تشير إلى هذا المدخل أيضًا Bitcoin Whitepaper, Genesis Block, Proof of Work, Full Node.

DOC · 001Bitcoin whitepaperمصدر أولي DOC · 002Satoshi Nakamoto Institute — early Bitcoin codeمصدر أولي DOC · 003Bitcoin Developer Guide — Block Chainتوثيق DOC · 004Bitcoin Core — validation sourceمصدر أولي DOC · 005Bitcoin Core — chain sourceمصدر أولي DOC · 006Bitcoin Core RPC — getblockتوثيق DOC · 007BIP 113 — Median time-past for lock-time calculationsمصدر أولي DOC · 008NIST — blockchain glossaryمصدر أولي
تمت المراجعة: المصادر أولًا · ليست نصيحة استثمارية