03 / 736DOC·001

Bitcoin Whitepaper

الورقة البيضاء لبيتكوين

تسع صفحات عن إرسال النقود الرقمية من دون بنك وسيط. دليل إلى الفكرة الأصلية، وإلى ما لا تتناوله الوثيقة أيضًا.

Bitcoin Whitepaper هي الوثيقة التي قدّم فيها Satoshi Nakamoto تصميم Bitcoin. أعلنها في 31 أكتوبر 2008 بعنوان Bitcoin: A Peer-to-Peer Electronic Cash System. تشرح صفحاتها التسع، بما فيها المراجع، كيف نجمع التوقيعات الرقمية وسجل المدفوعات العام والعمل الحاسوبي في نظام بلا مدير مركزي. إنها شرح للفكرة الأولى، وليست دليلًا كاملًا لبرامج اليوم أو ضمانًا لأمان كل خدمة Bitcoin.

تعرض whitepaper مشكلة وتقترح حلًا. تبدأ وثيقة Bitcoin بسؤال يومي: عندما أرسل المال عبر الإنترنت، هل يجب دائمًا أن يقف بيننا بنك أو مدير آخر؟ أرسل Satoshi اقتراحه إلى قائمة بريدية للتشفير في 31 أكتوبر 2008 ووضع رابطًا للنص. لم يعد بسعر للـbitcoin أو عائد للمستثمر، بل شرح كيف نستقبل المدفوعات من دون تسليم قرارات تاريخها إلى شركة واحدة. هذه المشكلة هي الخيط الذي يربط الوثيقة كلها. [2] [1]

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

تشرح الأقسام 3–5 تجميع المدفوعات في كتل. تشير كل كتلة جديدة إلى سابقتها بواسطة hash، أي بصمة رقمية قصيرة للبيانات. تغيير سجل قديم يغير بصمته ويكسر الترابط. وتضيف Proof of Work عملًا حاسوبيًا مكلفًا: يتطلب إنتاج كتلة مقبولة محاولات كثيرة، بينما يسهل التحقق من النتيجة. عند تنافس الفروع، يعتد بالعمل المتراكم في تاريخ يلتزم بالقواعد، لا بعدد الحسابات أو عناوين IP المنشأة. تسميه الوثيقة السلسلة الأطول. لكن كثرة العمل لا تجعل معاملة غير صحيحة صحيحة. والسلسلة ترتب الأحداث، ولا تحدد الوقت الدقيق لكل دفعة. [1] [3]

الحواسيب والكهرباء تكلف مالًا. لذلك يضيف القسم 6 حافزًا اقتصاديًا: يمكن لمنشئ كتلة مقبولة الحصول على عملات مصدرة حديثًا ورسوم مدفوعاتها. الرسوم هي الفرق بين القيمة التي تنفقها المعاملة وقيمة مخرجاتها الجديدة، وليست عملات إضافية تُخلق من العدم. وتناقش الوثيقة مستقبلًا تمول فيه الرسوم وحدها المكافأة. لكن علينا معرفة حدود الاقتراح: لا تذكر whitepaper حدًا دقيقًا قدره 21 مليونًا ولا خفض الإصدار إلى النصف كل 210,000 كتلة. يجب التحقق من هذه القواعد في مراجع Bitcoin الأخرى. [1] [3]

لا يريد الجميع تنزيل كل المعاملات والتحقق منها. لذلك يقترح القسم 8 طريقة SPV، أي التحقق المبسط من المدفوعات. يحصل العميل على رؤوس الكتل التي تحتوي بياناتها الأساسية، وعلى إثبات Merkle: مسار من قيم hash يثبت إدراج معاملة محددة في كتلة. يشبه ذلك الفرق بين التأكد من وجود قيد في كتاب معين والتحقق من صحة الكتاب كله. إثبات الإدراج وحده لا يتحقق من كل القواعد أو كامل تاريخ الإنفاق. وتقر whitepaper بهذا القيد: العميل المبسط أكثر عرضة لبعض الهجمات من Full Node تتحقق من المعاملات بنفسها. [1]

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

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

تشرح الوثيقة التصميم الأصلي. تطورت الشبكة والبرامج لاحقًا؛ فمثلًا لا تتناول SegWit، التغيير الموصوف في اقتراح BIP 141. وBIP وثيقة تقترح تحسينًا، لا قرار يتحول تلقائيًا إلى قاعدة للشبكة عند نشره. لفهم المسائل الحالية يجب التمييز بين الاقتراح والبرنامج والقواعد المشتركة المطبقة فعلًا وقرارات العُقدة المحلية بشأن تمرير المعاملات. قد ترفض عُقدة تمرير معاملة ثم تقبلها لاحقًا ضمن كتلة صحيحة. لا تناقض بين الحالتين. [4] [3]

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

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

للحصول على صورة أوضح، اقرأ هذا المدخل مع Satoshi Nakamoto, Bitcoin, Proof of Work, معاملة, Timechain / Blockchain. تشير إلى هذا المدخل أيضًا Bitcoin, Satoshi Nakamoto, Genesis Block, السايفربانك.

DOC · 001Original Bitcoin whitepaperمصدر أولي DOC · 002Original announcement — 31 October 2008مصدر أولي DOC · 003Bitcoin Developer Guide — Block Chainمصدر أولي DOC · 004BIP 141 — Segregated Witnessمصدر أولي
تمت المراجعة: المصادر أولًا · ليست نصيحة استثمارية