Author

Topic: ترجمة الورقة البيضاء للبتكوين الى العربي (Read 148 times)

newbie
Activity: 5
Merit: 0
11. العمليات الحسابية
لنفترض سيناريو مهاجم يحاول توليد سلسلة بديلة أسرع من السلسلة الصادقة. حتى إذا تم تحقيق ذلك ، فإنه لن يجر النظام إلى تغييرات عشوائية ، مثل خلق قيمة من فراغ أو أخذ أموال لم تكن مملوكة للمهاجم. لن تقبل العقد أي معاملة غير صالحة كوسيلة للدفع ، ولن تقبل العقد الصادقة أبدًا كتلة تحتوي عليها. يمكن للمهاجم فقط محاولة تغيير أحد معاملاته الخاصة لاسترداد الأموال التي أنفقها مؤخرًا.
يمكن وصف السباق بين السلسلة الصادقة وسلسلة المهاجمين على أنه مسارعشوائي ذو حدين.
الحدث الناجح هو سلسلة صادقة يتم تمديدها بواسطة كتلة واحدة ، مما يزيد من سابقيتها بـ +1 ، وحدث الفشل هو سلسلة المهاجم التي يتم توسيعها بواسطة كتلة واحدة ، مما يقلل الفجوة بمقدار -1.
إن احتمال لحاق أحد المهاجمين من عجز معين مشابه لمشكلة إفلاس مقامر. لنفترض أن مقامر ذو رصيد غير محدود يبدأ عند عجز وأنه يلعب عددًا غير محدود من التجارب لمحاولة الوصول إلى نقطة التعادل. يمكننا حساب الاحتمال الذي سيصل فيه إلى التعادل ، أو  إحتمال أن  يدرك المهاجم السلسلة الصادقة

  حذف جزء من محتوى العمليات الحسابية هنا لصعوبة اضافة المعادلات والصور ،
رابط ترجمه كامل مع الصور والمعادلات :
https://medium.com/@alsayadii/%D8%A7%D9%84%D8%A8%D9%8A%D8%AA%D9%83%D9%88%D9%8A%D9%86-%D9%86%D8%B8%D8%A7%D9%85-%D9%86%D9%82%D8%AF-%D8%A7%D9%84%D9%83%D8%AA%D8%B1%D9%88%D9%86%D9%8A-%D9%82%D8%A7%D8%A6%D9%85-%D8%B9%D9%84%D9%89-%D9%85%D8%A8%D8%AF%D8%A3-%D8%A7%D9%84%D9%86%D8%AF-%D9%84%D9%84%D9%86%D8%AF-266df6637de


12. الإستنتاج
لقد اقترحنا نظامًا للمعاملات الإلكترونية بدون الاعتماد على الثقة. لقد بدأنا بالإطار المعتاد للعملات المصنوعة من التوقيعات الرقمية ، والتي توفر سيطرة قوية على الملكية ، لكنها غير كاملة وبدون وسيلة لمنع الإنفاق المزدوج. لحل هذه المشكلة ، اقترحنا شبكة ند إلى ند باستخدام إثبات العمل لتسجيل سجل عام للمعاملات التي تصبح بسرعة غيرعملية من الناحية الحسابية  لمهاجم أن يغيرها إذا كانت العُقد الصادقة تتحكم في غالبية قوة وحدة المعالجة المركزية.
الشبكة قوية في بساطتها غير المنظمة. تعمل العقد في وقت واحد مع قليل من التنسيق. لا يلزم تحديدها ، نظرًا لأن الرسائل لا يتم توجيهها إلى أي مكان معين وتحتاج فقط إلى تسليمها على أساس أفضل جهد.  يمكن للعقد المغادرة وإعادة الانضمام إلى الشبكة متى شاءت ، وقبول سلسلة إثبات العمل كدليل على ما حدث أثناء ذهابها. العقد تصوت مع قوة وحدة المعالجة المركزية لها ، معربة عن موافقتها على الكتل الصالحة من خلال العمل على تمديدها ورفض الكتل الغير صالحة من خلال رفض العمل عليها. يمكن تطبيق أي قواعد وحوافز مطلوبة بواسطة آلية التوافق هذه.
newbie
Activity: 5
Merit: 0
10. الخصوصية
يحقق النموذج المصرفي التقليدي مستوى من الخصوصية من خلال الحد من الوصول إلى المعلومات إلى الأطراف المعنية والطرف الثالث الموثوق به. إن ضرورة الإعلان عن جميع المعاملات بشكل علني تمنع هذه الطريقة ، ولكن لا يزال من الممكن الحفاظ على الخصوصية من خلال كسر تدفق المعلومات في مكان آخر: عن طريق إبقاء المفاتيح العامة مجهولة الهوية. يمكن للجمهور أن يرى أن شخصًا ما يرسل مبلغًا لشخص آخر ، ولكن بدون معلومات تربط المعاملة بأي شخص. ويشبه ذلك مستوى المعلومات التي تصدرها البورصات ، حيث يتم الإعلان عن وقت المعاملات وحجم المعاملات الفردية  ، لكن دون الإخبار عن هوية الشخص.



كجدار ناري إضافي ، يجب استخدام زوج مفاتيح جديد لكل معاملة لمنعهم من الارتباط بمالك مشترك. لا تزال بعض الروابط لا يمكن تجنبها من خلال المعاملات متعددة المدخلات ، والتي تكشف بالضرورة أن مدخلاتها كانت مملوكة لنفس المالك. ويكمن الخطر في أنه في حالة الكشف عن مالك المفتاح ، قد يكشف الارتباط عن معاملات أخرى تخص  نفس المالك
newbie
Activity: 5
Merit: 0
البيتكوين: نظام نقد الكتروني قائم على مبدأ الند للند

Satoshi Nakamoto
ترجمة :
أحمد الصيادي
[email protected]
[/b]مُلخص: نسخة ند إلى ند على نحو محض من النقد الإلكتروني سوف يسمح للمدفوعات عبر الإنترنت أن ترسل مباشرة من طرف إلى آخر دون المرور عبر مؤسسة مالية. التوقيعات الرقمية توفر جزءًا من الحل ، ولكن يتم فقدان الفوائد الرئيسية إذا كان لا يزال مطلوبًا طرف ثالث موثوق به لمنع الإنفاق المزدوج. نقترح حلاً لمشكلة الإنفاق المزدوج باستخدام شبكة الند للند.  تقوم هذه الشبكة بعمل ختومات زمنية لكل  معاملة  عن طريق  دمجها في سلسلة مستمرة من إثبات العمل القائم على هاش، مشكلا بذلك سجلا لا يمكن تغييره دون إعادة عمل إثبات العمل. لا تعمل أطول سلسلة كدليل على تسلسل الأحداث التي شهدتها فحسب ، بل إنها دليل على أنها جاءت من أكبرتجمع لقوة وحدة المعالجة المركزية. طالما يتم التحكم في معظم قوة وحدة المعالجة المركزية من خلال العقد الصادقة ، فإنها سوف تولد أطول سلسلة و تتفوق على المهاجمين.
الشبكة نفسها تتطلب حد أدنى من البنية. كما يتم بث الرسائل على أساس أفضل جهد ، ويمكن للعقد أن تغادر وتعيد الانضمام إلى الشبكة متى شاءت ، وبقبول أطول سلسلة إثبات للعمل يعتبر كدليل على ما حدث أثناء اختفائها.

1. المقدمة

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

2. المعاملات

نُعًرف أي عملة إلكترونية  على أنها سلسلة من التوقيعات الرقمية. يقوم كل مالك بتحويل العملة إلى التالي من خلال التوقيع رقمياً على هاش المعاملة السابقة والمفتاح العمومي للمالك القادم وإضافتهم إلى نهاية العملة. يمكن للمستفيد التحقق من التوقيعات للتأكد من سلسلة الملكية.


المشكلة بالطبع هي أن المستلم لا يمكنه التحقق من أن أحد المالكين لم ينفق العملة مرتين ( بشكل مزدوج). الحل الشائع هو تقديم سلطة مركزية موثوق بها  أو مصنع صك عملة  يقوم بالتحقق من كل معاملة لمنع الإنفاق المزدوج. بعد كل معاملة ، يجب أن تعاد العملة إلى مصنع صك العملة لإصدار عملة جديدة ، ولا يوثق إلا بالعملات التي تصدر مباشرة من مصنع صك العملة للتأكد من عدم إنفاقها أكثر من مرة.  تكمن المشكلة في هذا الحل في أن مصير النظام المالي بأكمله يعتمد على الشركة التي تدير مصنع صك العملة ، كل معاملة يجب أن تمر بها ، تمامًا مثل البنك.
نحن بحاجة إلى وسيلة للمستلم أن يعلم أن المالكين السابقين لم يوقعوا على أي معاملات سابقة. هدفنا هو أن تكون المعاملة السابقة هي المعاملة التي يتم احتسابها ، لذا فنحن لا نهتم بالمحاولات اللاحقة للإنفاق المزدوج . الطريقة الوحيدة لتأكيد فقدان معاملة هي أن تكون على علم بجميع المعاملات. في النموذج القائم على مصنع صك العملة ، كان مصنع صك العملة على علم بجميع المعاملات ويمكنه تحديد المعاملات التي حصلت أولاً. لإنجاز هذا دون طرف موثوق به ، يجب الإعلان عن المعاملات بشكل علني [1]، كما نحن بحاجة إلى نظام للمشاركين للاتفاق على تاريخ واحد للترتيب الذي تم  به إستلام المعاملات. ويحتاج المستلم  إلى إثبات أنه في وقت كل معاملة، وافقت أغلبية العقد على أنها المرة الأولى التي تم استلام هذه المعاملة فيها.
3. خادم الطابع الزمني
يبدأ الحل الذي نقترحه بخادم الطابع الزمني.  يعمل خادم الطابع  الزمني على أخذ هاش لكتلة من العناصر ليتم ختمها زمنيا ونشرها على نطاق واسع ، كما هو الحال في الصحف أو بريد المجموعات الأخبارية[2-5]. من الواضح ، ومن أجل الوصول إلى سلسلة هاش ، يثبت الطابع الزمني أن البيانات يجب أن تكون موجودة في ذلك الوقت. يتضمن كل طابع زمني الطابع الزمني السابق له في الهاش  ، مشكلا سلسلة ، و كل طابع زمني إضافي  يعزز ذلك الذي قبله.

4. إثبات العمل

لتنفيذ خادم طابع زمني موزع  يقوم على مبدأ الند للند، سوف نحتاج إلى نظام إثبات العمل، وهو نظام مشابه ل (Adam Back's Hashcash) [6] بدلا من الصحف أو بريد المجموعات الأخبارية.
إثبات العمل يشمل البحث عن قيمة هاش، كاستخدام خوارزمية هاش SHA-256، قيمة هاش هذه تبدأ بالعديد من البتات الصفرية.  علاقة متوسط العمل المطلوب و عدد البتات الصفرية المطلوبة هي علاقة أسيّة ويمكن التحقق منها عن طريق تنفيذ عملية هاش واحدة.
  بالنسبة إلى شبكة الطابع الزمني الخاصة بنا ، نقوم بتطبيق إثبات العمل عن طريق زيادة قيمة مؤقتة في الكتلة حتى يتم العثور على قيمة تعطي هاش الكتلة البتات الصفرية المطلوبة. بمجرد أن يتم إنفاق جهد وحدة المعالجة المركزية لجعله يستوفي متطلبات إثبات العمل ، لا يمكن تغيير الكتلة دون إعادة العمل. كما يتم تقييد الكتل التالية بعد ذلك ، فإن العمل على تغيير الكتلة سيشمل إعادة عمل كل الكتل التي بعدها.


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

5. الشبكة

خطوات تشغيل الشبكة هي كما يلي:
1) يتم بث المعاملات الجديدة لجميع العقد.
2) كل عقدة تجمع المعاملات الجديدة في كتلة.
3) تعمل كل عقدة على العثور على إثبات عمل صعب لكتلتها.
4) عندما تجد العقدة  إثبات عمل، فإنها تبث الكتلة لجميع العقد.
5) العقد تقبل الكتلة فقط إذا كانت جميع المعاملات الموجودة فيها صالحة ولم تنفق بالفعل.
6) تعرب العقد عن قبولها للكتلة من خلال العمل على إنشاء الكتلة التالية في السلسلة ، باستخدام هاش الكتلة المقبولة كهاش سابق.
العقد دائمًا تعتبر أطول سلسلة لتكون السلسلة الصحيحة وستستمر في العمل على توسيعها. إذا قامت عقدتان ببث إصدارات مختلفة من الكتلة التالية في نفس الوقت ، فقد تتلقى بعض العقد واحدة منهما أولاً أو الأخرى.  في هذه الحالة ، تعمل على أول واحد يتلقونها ، ولكن يحفظ الفرع الآخر لحالة أن يصبح أطول. سيتم كسر هذه الحالة عندما يتم العثور على إثبات العمل التالي ويصبح فرع واحد أطول ؛ ستنتقل العقد التي كانت تعمل في الفرع الآخر إلى السلسلة الأطول.
بث المعاملات الجديدة لا يحتاج بالضرورة إلى الوصول إلى جميع العقد. طالما أنها تصل إلى العديد من العقد ، فإنها سوف تدخل في كتلة قبل فترة طويلة. بث الكتل هو أيضا متسامح مع فقدان الرسائل. فإذا لم تتلقى العقدة كتلة ما ، فستطلبها عند استلامها للكتلة التالية وتدرك أنها قد فقدتها.

6. الحافز

حسب الاتفاقية ، فإن المعاملة الأولى في كتلة هي معاملة خاصة تبدأ عملة جديدة يملكها منشئ الكتلة. وهذا يضيف حافزا للعقد لدعم الشبكة ، ويوفر طريقة لتوزيع القطع النقدية في التداول في البداية ، حيث لا توجد سلطة مركزية لإصدارها. إن الإضافة الثابتة لكمية من العملات الجديدة يشبه عمال مناجم الذهب الذين ينفقون الموارد لإضافة الذهب إلى التداول. في حالتنا ، هو وقت وحدة المعالجة المركزية والكهرباء التي يتم إنفاقها.
 ويمكن أيضا أن يتم تمويل الحافز من خلال رسوم الصفقة. إذا كانت قيمة المخرجات للمعاملة أقل من قيمة مدخلاتها ، يكون الفرق عبارة عن رسوم معاملة تتم إضافتها إلى القيمة الحافزة للكتلة المحتوية على الصفقة. بمجرد أن يتم تداول عدد محدد من العملات ، يمكن أن ينتقل الحافز بالكامل إلى رسوم المعاملات ويكون خالٍ من التضخم تمامًا.
قد يساعد الحافز في تشجيع العقد على البقاء صادقة. إذا كان المهاجم الجشع قادرًا على تجميع المزيد من قوة وحدة المعالجة المركزية أكبر من جميع العقد الصادقة ، فسيتعين عليه الاختيار بين استخدامها للاحتيال على الأشخاص عن طريق سرقة و إستعادة مدفوعاته ، أو استخدامها لتوليد عملات معدنية جديدة. سوف يجب عليه أن يجد أن اللعب بالقواعد أكثر ربحية ، مثل القواعد التي تجعله يحصل على قطع نقدية جديدة أكثر من الأشخاص الآخرين مجتمعين ، بدلاً من تقويض النظام وصحة ثروته الخاصة.

7. إستعادة مساحة القرص

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



سيكون رأس أي كتلة بدون معاملات حوالي 80 بايت. إذا افترضنا أن الكتل يتم إنشاؤها كل 10 دقائق ، 80 بايت * 6 * 24 * 365 = 4.2 ميغابايت في السنة. مع أنظمة الكمبيوتر التي تباع عادة مع 2 غيغابايت من ذاكرة الوصول العشوائي اعتبارا من عام 2008 ، ويتوقع قانون مور النمو الحالي ب 1.2 غيغابايت في السنة ، لا ينبغي أن يكون التخزين مشكلة حتى إذا كان يجب الاحتفاظ برؤوس الكتل في الذاكرة.

8. التحقق المبسط من الدفع

من الممكن التحقق من المدفوعات دون تشغيل عقدة شبكة كاملة. يحتاج المستخدم فقط إلى الاحتفاظ بنسخة من رؤوس الكتل لأطول سلسلة من إثباتات العمل ، والتي يمكن الحصول عليها من خلال الاستعلام عن عقد الشبكة حتى يتم اقتناعه بامتلاك أطول سلسلة ، والحصول على فرع Merkle الذي يربط المعاملة بالكتلة المختمة زمنيا.  لا يمكنه التحقق من المعاملة بنفسه ، ولكن عن طريق ربطها بمكان في السلسلة ، يمكنه أن يرى أن هناك عقدة شبكة قد قبلتها ، والكتل التي تمت إضافتها بعد  تعمل على مزيد من التأكد من قبول الشبكة لها.



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

9. دمج وتقسيم القيمة

على الرغم من أنه سيكون من الممكن التعامل مع العملات بشكل فردي ، سيكون من غير العملي إجراء معاملة منفصلة لكل سنت في عملية التحويل. للسماح بتقسيم القيمة ودمجها ، تحتوي المعاملات على العديد من المدخلات والمخرجات. عادةً ما يكون هناك إما إدخال واحد من معاملة سابقة أكبر أو مدخلات متعددة تجمع بين مقادير أصغر ، وفي الغالب مخرجين : أحدهما للدفع ، والآخر للإرجاع ، إن وجد ، إلى المرسل.
 وتجدر الإشارة إلى أن المعاملة الواحدة تعتمد على عدة معاملات، وتلك المعاملات تعتمد على عدد أكبر من ذلك ،وهذه ليست مشكلة هنا. لا توجد حاجة مطلقًا إلى استخراج نسخة مستقلة كاملة من سجل المعاملات.
Jump to: