شرح خوارزمية دليل الحصة POS – Proof of Stake -الجزء الاول

ضمن كل عملة الكترونية مشفرة يجب ان يوجد خوارزمية اتفاق، التي بدورها تبقي كامل الشبكة الموزعة متزامنة. عندما أتى الـ Bitcoin للوجود، قام بتعريف خوارزمية اتفاق دليل العمل Proof-Of-Work. يعمل POW بإنتاج هاش لقطعة من المعلومات (رأس الكتلة Block Header) مرارا وتكرارا حتى يتم إيجاد الهاش المناسب. بسبب طريقة عمل الـ One-way Hashing, فان أي تغيير طفيف ضمن البيانات يمكن أن ينتج هاش مختلف بشكل جذري. المشاركين في الشبكة يمكنهم ان يحددوا إذا كان دليل العمل صالح من خلال الحكم على الهاش المٌنتَج من أنه يحقق حالة معينة أو شرط معين، يسمى الصعوبة Difficulty. الصعوبة او صعوبة التعدين هو هدف متغير على الدوام، الذي على الهاش ان يساويه او يتجاوزه. كلما انتجت الشبكة بلوكات أكثر من اللازم، فان صعوبة التعدين تتغير بشكل آلي من قبل الشبكة بحيث يصبح تحقيق هدف صعوبة التعدين أعلى وأعلى. وهكذا تحتاج المزيد والمزيد من الطاقة الحسابية Computing Power لإيجاد الهاش الذي يحقق هدف صعوبة التعدين Difficulty Targetضمن الإطار الزمني المقدر بـ 10 دقائق.

تعريفات:

★ UTXO اختصار لـ Unspent Transaction Output, او خرج المعاملة الغير مصروف.
★ vin: ضمن معاملة يكون الـvin عبارة عن UTXO يتم صرفه كدخل للمعاملة input.
★ vout: ضمن معاملة يكون الـvout عبارة عن UTXO جديد يتم انشاءه كخرج للمعاملة output. الـ vouts هو فعليا جميع العملات المرسلة بعد تأكيد معاملة التحويل.
★ Hashing: هي عملية انشاء الـHash. بحيث تأخذ كمية عشوائية من البيانات كدخل، وتعطي كخرج عصارة محددة الحجم والذي بدوره من المستحيل عكسه (أي الرجوع من الخرج الى بيانات الدخل). بالإضافة، إذا قمت بتغيير أي شيء ببيانات الدخل، فان الخرج سيتغير بشكل جذري.
★ Hash: نتيجة تطبيق خوارزمية او عملية التهييش Hashing.
★ script: برنامج على البلوكتشين لتحديد كيفية صرف vout/UTXO.
★ pay-to-pubkeyhash script: النص البرمجي script الأكثر استخداما لإرسال المال ضمن الـBitcoin و عملات أُخرى. من أجل ارسال الأموال فان كل ما تحتاج معرفته هو هاش المفتاح العام للجهة المرسل اليها، ومن أجل إنفاق الأموال المستقبلة فكل ما تحتاجه هو توقيع رقمي من المفتاح العام المرسل اليه، والمفتاح العام نفسه.
★ pay-to-pubkey: نص برمجي script بسيط, الذي بدوره لديه وظيفة مشابها لوظيفة النص البرمجي السابق. ومع ذلك، عوضا عن ارسال الأموال الى هاش المفتاح العام، فان الأموال بتم ارسالها الى المفتاح العام نفسه. كل ما تحتاجه للإنفاق هو توقيع رقمي يثبت امتلاكك للمفتاح العام.
★ OP_RETURN: هي عملية تستخدم في النص البرمجي script الذي يجعل من الخرج للمعاملة بشكل فعال غير قابل للإنفاق. يستخدم عادة لحفظ كمية صغيرة من البيانات ضمن البلوكتشين دون تلويث مجموعة الـ UTXO للمعاملة.
★ Prevout: الـvout المُنفَق كـvin ضمن المعاملة, أي الخرج لمعاملة سابقة المنفق كدخل للمعاملة الحالية.

دليل العمل Proof of Work ونظم/خوارزميات الاتفاق للبلوكتشين:

دليل العمل او Proof of Work هو آلية اجماع او اتفاق التي جعلت من الـ Bitcoin شبكة آمنة وموثوقة لأكثر من عقد من الزمن. ومع ذلك، يوجد لديها حصتها من المشاكل. عيوب POW الرئيسية:
1- POW يضيع الكثير من الكهرباء, مؤذياً البيئة. (الا ان رأيي الشخصي ان المشكلة هي في انتاج الكهرباء المضر للبيئة وليس الصرف. بالإضافة لا يمكن اعتبار الأمان الذي يزودنا به الـ Bitcoin لتأمين المعاملات المالية تضييعا للكهرباء انما أضواء الأعياد تعتبر تضييعا للكهرباء، ماذا عن الكهرباء المستخدمة لتسيير عمل البنوك والمؤسسات المالية، ولكن البعض لا يزال يراها كمشكلة).
2- POW يفيد بشكل كبير اللاعبين الكبار على الأغلب, عوضا عن المشاركين الصغار في الشبكة.
3- POW لا يقدم أي تحفيز لاستخدام العملة او الاحتفاظ بها.
4- POW عرضة للمركزية, لأنه يشجع المعدنيين على الاشتراك بتجمعات التعدين الأكبر (عبارة عن مجموعة من المعدنين الذين يتشاركون مكافئة انتاج الكتل), بالتالي مُشَغِل أكبر تجمع معدنيين لديه الكثير من التحكم في الشبكة.

تم اختراع Proof of Stake لحل العديد من هذه المشكلات من خلال السماح للمشاركين في الشبكة بإنشاء وتعدين كتل جديدة (وبالتالي الحصول على مكافئة الكتل)، ببساطة من خلال التمسك او المحافظة على عملة الشبكة ضمن محفظتهم والسماح للمحفظة بتكديس العملات. تم اختراع الـ Proof Of Stake من قبل Sunny King وتم تطبيقها في peercoin. منذ ذلك الحين تم تحسين الخوارزمية و تم تبنيها من قبل العديد من المشاريع الأخرى.

سنقوم بشرح Proof of Stake Version 3, وهو تحسين فوق Version 2 الذي أوجد من قبل Pavel Vasin وتم تطبيقه ضمن مشروع Blackcoin, وهذا التطبيق الذي سوف نقوم بشرحه. ضمن الشرح، بعض المعرفة التقنية يفترض تواجدها بالقارئ، لكن سأحاول الشرح بحيث معظم المعرفة يمكن استنباطها من خلال السياق. بجب أن تكون على الأقل على دراية جيدة بمفهوم UTXO.
قبل البدء بالتكلم عن POS, فان فهم آلية عمل خوارزمية الاتفاق الأبسط POW سيساعد. عملية التعدين لـ POW يمكن تمثيلها بعدد قليل من السطور شبه برمجية pseudo-code:

While(blockHash > difficulty) {
	block.nonce = block.nonce + 1
	blochHash = sha256(sha256(block))
}

الهاش Hash عبارة عن خوارزمية تشفير تأخذ كمية غير محددة من البيانات، تقوم بمعالجتها، وتعطي كخرج عصارة Digest ثابتة الحجم للبيانات المدخلة. من المستحيل معرفة البيانات المدخلة من خلال العصارة Digest. لذا تميل خوارزمية POW لتعمل كمسألة حظ (يانصيب)، حيث يمكنك معرفة ما إذا فزت من خلال انشاء Hash والتحقق منه مقابل هدف صعوبة التعدين، ويمكنك انشاء تذكرة سحب أخرى من خلال تغيير طفيف في البيانات المدخلة (بيانات الكتلة) ثم انشاء Hash ومقارنته مع الهدف. في حالة الـ Bitcoin, الـ nonce هو المستخدم لإجراء التغيير في بيانات الادخال. بمجرد العثور على هاش أقل من هدف التعدين، فان البلوك يكون صالح، ويمكن ارساله الى باقي الشبكة. المعدنين سوف يرون البلوك الجديد، يتحققون من صحته ثم يضيفونه على البلوكتشين ويبدأن ببناء البلوك التالي بناءً عليه.

بنية وقواعد بروتوكول Proof Of Stake :

الآن سنبدأ بـ Proof of Stake. لدينا الأهداف التالية لـ POS:
1- من المستحيل تزييف كتلة او بلوك.
2- اللاعبون الكبار لا يحصلون على مكافآت أكبر بشكل غير متناسب.
3- المزيد من الطاقة الحسابية لا تجدي لبناء المزيد من الكتل.
4- لا يوجد عضو واحد في الشبكة يمكنه السيطرة على كامل البلوكتشين.

المفهوم الأساسي لـ POS مشابه جداً لـ POW, يانصيب. ومع ذلك، الفرق الكبير هو انه لا يمكن „الحصول على المزيد من التذاكر لليانصيب“ببساطة عن طريق تغيير بعض البيانات في الكتلة. فعوضا عن أن يكون هاش البلوك هو تذكرة اليانصيب لمقارنتها مع هدف صعوبة التعدين، فإن POS أوجد مفهوم هاش النواة Kernel Hash.
الـ Kernel Hash يتألف من عدة قطع من البيانات التي لا يمكن تعديلها بسهولة في البلوك الحالي. وهكذا، نظرا لأن المعدنين لا يملكون طريقة سهلة لتعديل هاش النواة، فلا يمكنهم ببساطة تكرار عملية الـ Hashing كما هو الحال في POW.
تضيف بلوكات او كتل Proof of Stake عدد من قواعد الإجماع الإضافية من أجل الوصول لهدفها. أولاً، على عكس POW, معاملة الـ coinbase (اول معاملة ضمن الكتلة) يجب ان تكون فارغة وتُكَافِئ بـ 0 عملة. عوضا عن ذلك، لمكافئة المكدسين فانه يوجد معاملة مميزة او خاصة تسمى معاملة التكديس/الحصة Stake Transaction التي يجب ان تكون المعاملة الثانية ضمن الكتلة.

يتم تعريف معاملة التكديس/الحصة Stake Transaction على أنها أي عملية:
1-    لديها على الأقل vin واحد صالح.
2-    أول vout لها يجب ان تكون فارغة.
3-    ثاني vout لها لا يجب ان يكون فارغ.

علاوة على ذلك، حتى تكون لدينا معاملة تكديس/حصة Stake Transaction صالحة ضمن الكتلة Blockيجب ان تتبع هذه القواعد:
1-    vout الثانية للمعاملة يجب ان تكون اما برنامج نصي „pubkey“ (و ليس الهاش pubkeyhash), او برنامج نصي „OP_RETURN“ غير قابل للإنفاق (فقط بيانات Data) لكن يخزن بيانات لمفتاح عام.
2-    الطابع الزمني „Timestamp“ضمن المعاملة يجب ان يكون مساوي للطابع الزمني للكتلة او البلوك.
3-    القيمة الكلية لخرج معاملة الحصة يجب ان يكون مساوي لـِ او اقل من قيمة مجموع المدخلات مضافة عليها مكافئة الكتلة وإجمالي رسوم معاملات البلوك او الكتلة.
output <= (input + block reward + tx fees).
4-    أول vin مصروفة لخرج معاملة الحصة يجب ان يتم تأكيدها من قبل 500 بلوك على الأقل.
5-    على الرغم من أنه يكمن استخدام أكثر من دخل „vin“في معاملة الحصة، فانه فقط أول دخل سيستخدم لمُعَامِلات خوارزمية الاتفاق.
هذه القواعد تضمن ان معاملة الحصة يمكن معرفتها وتحديدها بسهولة، وتضمن أن تعطي معلومات كافية للشبكة لتأكيد البلوك. ان طريقة الخرج الأول الفارغ „vout“ليست الطريقة الوحيدة لتحديد معاملة الحصة، لكن هذا يعتبر التصميم الأصلي من قبل Sunny Kind وقد عملت بشكل جيد.

الآن بعد فهمنا معاملة الحصة وما هي القواعد التي تحكمها، الموضوع التالي سيكون لتغطية قواعد بلوك POS:
1-    يجب ان يملك معاملة حصة واحدة فقط لا غير.
2-    معاملة الحصة يجب ان تكون المعاملة الثانية ضمن البلوك.
3-    يجب ان تملك معاملة الحصة او معاملة coinbase قيمة خرج 0 وvout فارغ واحد فقط.
4-    يجب ان يكون الـ 4 بتات الأواخر للطابع الزمني للبلوك قيمتها 0. هذا يعني ان وقت البلوك يمكن تمثيله في فواصل زمنية من 16 ثانية، مما يقلل من تقسماتها.
5-    اصدار البلوك يجب ان يكون الإصدار 7.
6-    الـ Kernel Hash للبوك يجب ان يقابل الصعوبة المقاسة او الموزونة لخوارزمية POS.
7-    هاش البلوك يجب ان يكون مُوَقَع الكترونيا باستخدام مفتاح عام وموضوع ضمن الـ vout الثاني لمعاملة الحصة. التوقيع يوضع ضمن البلوك لكن لا يدخل ضمن هاش البلوك ذاته.
8-    التوقيع المخزن في البلوك يجب ان يكون „LowS“, والذي يعني: انه يتألف من قطعة واحدة من المعلومات ويجب ان يكون مضغوط قدر المستطاع (أي لا وجود لأصفار إضافية في النهاية أو أكواد عمليات opcodes).
9-    يتم تطبيق معظم القواعد الأخرى لبلوك POW (merkle hash صالح، عمليات صالحة، الطابع الزمني يكون ضمن إطار الانزياح الزمني المسموح به، الخ).

يوجد الكثير من التفاصيل هنا التي سيتم تغطيتها لاحقاً.
الجزء الأهم الذي يجعل خوارزمية POS فعالة تعتمد على الـ Kernel Hash. استخدام الـ Kernel Hash مشابه لمثيله في الـ POW (في حال تساوي الهاش مع صعوبة التعدين، فإن البلوك يعتبر صالح). ومع ذلك فإن الـ Kernel Hash لا يمكن تعديله بشكل مباشر في سياق البلوك الحالي. سنبدأ أولا بتغطية ما الذي يدور بهذه الهياكل (البنى) والآليات، ولاحقا سنشرح لماذا تم تصميم POSبهذه الطريقة، وما هي العواقب التي يمكن ان تأتي من تغييرات طفيفة عليها.

إلى هنا نكون قد أنهينا الجزء الاول حتى لا يكون الموضوع طويل و ممل, سنكمل في الجزء الثاني بحيث سنتطرق إلى الـ Kernel Hash لـ Proof of Stake.

اترك رد

إملأ الحقول أدناه بالمعلومات المناسبة أو إضغط على إحدى الأيقونات لتسجيل الدخول:

شعار ووردبريس.كوم

أنت تعلق بإستخدام حساب WordPress.com. تسجيل خروج   /  تغيير )

Google photo

أنت تعلق بإستخدام حساب Google. تسجيل خروج   /  تغيير )

صورة تويتر

أنت تعلق بإستخدام حساب Twitter. تسجيل خروج   /  تغيير )

Facebook photo

أنت تعلق بإستخدام حساب Facebook. تسجيل خروج   /  تغيير )

Connecting to %s

WordPress.com. قالب: Baskerville 2 بواسطة Anders Noren.

أعلى ↑

%d مدونون معجبون بهذه: