في هذه المقالة ، سوف أخبرك عن DAG (Directed Acyclic Graph) واستخدامه في السجلات الموزعة ، وسنقوم بمقارنتها مع blockchain.
DAG ليست جديدة في عالم العملات المشفرة. ربما تكون قد سمعت عنه كحل لمشكلات قابلية التوسع في سلسلة المفاتيح. لكن اليوم لن نتحدث عن قابلية التوسع ، ولكن حول ما الذي يجعل العملات المشفرة مختلفة عن أي شيء آخر: اللامركزية ، وغياب الوسطاء ومقاومة الرقابة.
سأريكم أيضًا أن DAG في الواقع أكثر مقاومة للرقابة ، وليس هناك وسطاء للوصول إلى السجل.
في القيود المعتادة بالنسبة لنا ، لا يتمتع المستخدمون بوصول مباشر إلى السجل نفسه. عندما تريد إضافة معاملة إلى السجل ، يتعين عليك "مطالبة" منتج الكتلة (منتج الكتلة ، المعروف أيضًا باسم "عامل المناجم") للقيام بذلك. إن عمال المناجم هم الذين يقررون المعاملة التي يجب إضافتها إلى الكتلة التالية ، وأيها لا. هذا هو عمال المناجم الذين لديهم حق الوصول الحصري للكتل والحق في تحديد معاملاتهم التي يجب قبولها للإضافة إلى السجل.
عمال المناجم وسطاء بينك وبين السجل الموزع.
في الممارسة العملية ، عادة ما يكون هناك عدد صغير من مجمعات التعدين تتحكم بشكل جماعي في أكثر من نصف الطاقة الحاسوبية للشبكة. بالنسبة للبيتكوين ، هذه أربعة حمامات ، للإثريوم - اثنان. في حالة التواطؤ ، يمكنهم حظر أي معاملات يريدون.
خلال السنوات القليلة الماضية ، تم اقتراح العديد من الاختلافات في البلوكات ، والتي تختلف في مبادئ اختيار منتجي البلوكات. لكن منتجي البلوكات أنفسهم لا يذهبون إلى أي مكان ، فهم ما زالوا "يقفون على الحاجز": يجب أن تمر كل معاملة عبر منتج البلوك ، وإذا لم يقبلها ، فإن المعاملة ، في الواقع ، غير موجودة.
هذه مشكلة لا مفر منها في حالة blockchain. وإذا أردنا حلها ، فيجب علينا تغيير التصميم بشكل جذري والتخلص تمامًا من القطع والكتل المصنعة. وبدلاً من بناء سلسلة من الكتل ، سننضم إلى المعاملات نفسها ، بما في ذلك تجزئة العديد من المعاملات السابقة في كل معاملة. نتيجة لذلك ، نحصل على بنية معروفة في الرياضيات على أنها رسم بياني موجه - DAG.
الآن كل شخص لديه حق الوصول المباشر إلى التسجيل ، دون وسطاء. عندما تريد إضافة معاملة إلى السجل ، يمكنك ببساطة إضافتها. اختر عدة معاملات رئيسية ، وأضف بياناتك ، ثم قم بتوقيع وإرسال معاملتك إلى أقرانهم على الشبكة. القيام به. لا يوجد أحد يمنعك من القيام بذلك ، لذا فإن معاملتك موجودة بالفعل في السجل.
هذه هي الطريقة الأكثر اللامركزية وخالية من الرقابة لإضافة المعاملات إلى السجل دون وسطاء. لأن الجميع يريد ببساطة إضافة معاملاتهم إلى السجل دون طلب إذن من أي شخص.
يمكن اعتبار DAG المرحلة الثالثة من تطور السجل. في البداية ، كانت هناك سجلات مركزية ، حيث كان جانب واحد يتحكم في الوصول إليها. ثم جاءت الحواجز ، التي كان هناك بالفعل العديد من وحدات التحكم الذين سجلوا المعاملات في السجل. وأخيرًا ، في DAG لا توجد وحدات تحكم على الإطلاق ، يضيف المستخدمون معاملاتهم مباشرةً.
الآن بعد أن أصبح لدينا مثل هذه الحرية ، لا ينبغي أن يؤدي ذلك إلى الفوضى. يجب أن نتفق على حالة السجل. وهذه الموافقة ، أو الإجماع ، تعني عادة الاتفاق على شيئين:
- ماذا حدث
- بأي ترتيب حدث هذا؟
يمكننا الإجابة بسهولة على السؤال الأول: بمجرد إضافة معاملة تم إنشاؤها بشكل صحيح إلى السجل ، حدث ذلك. وهذه النقطة. يمكن أن تصل المعلومات حول هذا الأمر إلى جميع المشاركين في أوقات مختلفة ، ولكن في النهاية ستتلقى جميع العقد هذه المعاملة وتكتشف أنها حدثت.
إذا كانت كتلة سلسلة ، فإن عمال المناجم يقررون ما يجري. كل ما يقرر العامل المنجم إدراجه في الكتلة هو ما يحدث. لا يحدث كل ما لا يتضمنه في الكتلة.
فيما يتعلق بالعقود ، يحل عمال المناجم أيضًا مشكلة الإجماع الثانية: النظام. يسمح لهم بترتيب المعاملات داخل الكتلة كما يحلو لهم.
كيفية تحديد ترتيب المعاملات في DAG؟
فقط لأنه يتم توجيه الرسم البياني لدينا ، لدينا بالفعل بعض النظام. تشير كل معاملة إلى واحد أو أكثر من الوالدين السابقين. الآباء والأمهات ، بدوره ، تشير إلى والديهم ، وهلم جرا. من الواضح أن الآباء يظهرون قبل المعاملات الفرعية. إذا كان يمكن الوصول إلى أي من المعاملات من خلال النقر على الروابط بين الوالدين والطفل ، فنحن نعرف بالتأكيد الترتيب بين المعاملات في سلسلة المعاملات هذه.
ولكن لا يمكن تحديد الترتيب بين المعاملات دائمًا إلا من خلال شكل الرسم البياني. على سبيل المثال ، عندما تكمن معاملتان في فروع متوازية من الرسم البياني.
لحل الغموض في مثل هذه الحالات ، نعتمد على مزودي الطلبات المزعومين. نحن نسميهم أيضًا "شهود". هؤلاء هم المستخدمون العاديون الذين تتمثل مهمتهم في إرسال المعاملات باستمرار إلى الشبكة بطريقة منظمة ، أي بحيث يمكن تحقيق كل المعاملات السابقة من خلال النقر على الروابط "الوالد - الطفل". مقدمو الطلبات هم من المستخدمين الموثوق بهم ، وتعتمد الشبكة بالكامل عليهم في عدم انتهاك هذه القاعدة. من أجل الثقة بهم بشكل
عقلاني ، نطلب من كل مزود أوامر أن يكون شخصًا أو مؤسسة معروفة (غير مجهولة) وأن يكون لديه شيء يمكن أن يضيع إذا خرق القواعد ، على سبيل المثال ، سمعة أو عمل تجاري قائم على الثقة.
يتم اختيار موفري الطلبات من قبل المستخدمين ، ويتضمن كل مستخدم قائمة بموفري خدماته الموثوق بهم في كل معاملة يرسلها إلى الشبكة. هذه القائمة تتكون من 12 مزودي. هذا رقم صغير إلى حد ما بحيث يمكن للشخص التحقق من هوية وسمعة كل منهم ، ويكفي بحيث تستمر الشبكة في العمل في حالة وجود مشاكل لا مفر منها مع أقلية من مقدمي الطلبات.
تختلف قائمة مقدمي الخدمات هذه من مستخدم لآخر ، ولكن قد تختلف قوائم المعاملات المجاورة بحد أقصى لمزود واحد.
الآن بعد أن أصبح لدينا مزودي الطلبات ، يمكننا إبراز معاملاتهم في DAG وترتيب جميع المعاملات الأخرى حول الترتيب الذي أنشأوه. هناك إمكانية لإنشاء مثل هذه الخوارزمية (انظر
Obyte White Paper للحصول على التفاصيل الفنية).
ولكن لا يمكن تحديد الطلب في الشبكة بالكامل على الفور ، فنحن نحتاج إلى وقت لموفري الطلبات لإرسال عدد كافٍ من معاملاتهم للتأكد من الترتيب النهائي للمعاملات السابقة.
ونظرًا لأن الطلب يتم تحديده فقط من خلال مواقف معاملات مقدمي الخدمات في DAG ، ستتلقى جميع العقد في الشبكة عاجلاً أم آجلاً جميع المعاملات وتتوصل إلى نفس الاستنتاج فيما يتعلق بترتيب المعاملات.
لذلك ، لدينا اتفاق على ما نعتبره قد حدث: أي معاملة حصلت في DAG حدثت. نوافق أيضًا على ترتيب الأحداث: يكون هذا مرئيًا على أساس المعاملات ذات الصلة ، أو يتم استنباطه من ترتيب المعاملات المرسلة من قبل مزودي الطلبات. لذلك لدينا إجماع.
لدينا هذا الخيار الإجماع في Obyte. على الرغم من أن الوصول إلى سجل Obyte غير مركزي تمامًا ، فإن الإجماع على ترتيب المعاملات لا يزال مركزيًا ، يتم التحكم في 10 من أصل 12 من مقدمي الخدمات من قبل الخالق (Anton Churyumov) ، واثنان منهم فقط مستقلان. نحن نبحث عن المرشحين الذين يريدون أن يصبحوا أحد مقدمي الخدمات المستقلين من أجل مساعدتنا في تحقيق اللامركزية في إنشاء النظام في السجل.
في الآونة الأخيرة ، ظهر مرشح ثالث مستقل يريد إنشاء والحفاظ على عقدة لمزود الطلبات - جامعة نيقوسيا.
الآن ، كيف نتحكم في الإنفاق المزدوج؟
وفقًا للقواعد ، عند الكشف عن معاملتين تنفقان نفس العملة ، تفوز تلك المعاملة التي ظهرت سابقًا في الترتيب النهائي لجميع المعاملات. تم تعطيل الثاني من قبل خوارزمية الإجماع.
إذا كان من الممكن إنشاء أمر بين عمليتين تنفقان عملة واحدة (على العلاقات بين الوالدين والطفل) ، فكل العقد ترفض على الفور هذه المحاولة للإنفاق المزدوج.
إذا لم يكن الطلب مرئيًا من العلاقة الأبوية بين هاتين المعاملتين ، فسيتم قبولهما في السجل ، وسنحتاج إلى انتظار توافق الآراء وإنشاء ترتيب بينهما باستخدام موفري الطلبات. ثم تفوز المعاملة السابقة ، وتصبح الثانية غير صالحة.
على الرغم من أن المعاملة الثانية تصبح غير صالحة ، إلا أنها تظل موجودة في السجل ، لأنها تحتوي بالفعل على معاملات لاحقة تشير إليها ، والتي لم تنتهك أي شيء ولم تعلم أنه في المستقبل ستصبح هذه المعاملة غير صالحة. خلاف ذلك ، سيكون علينا إزالة الوالد من المعاملات اللاحقة الجيدة ، مما ينتهك المبدأ الرئيسي للشبكة - يتم قبول أي معاملة صحيحة في التسجيل.
هذه قاعدة مهمة للغاية تسمح للنظام بأكمله بمقاومة محاولات الرقابة.
دعنا نتظاهر بأن جميع مقدمي الطلبات يتآمرون في محاولة "لفرض رقابة" على معاملة معينة. يمكنهم تجاهلها وعدم اختيار "أحد الوالدين" لمعاملاتهم ، ولكن هذا لا يكفي ، لا يزال من الممكن إدراج هذه المعاملة بشكل غير مباشر بصفتها أصل بعض المعاملات الأخرى الصادرة عن أي مستخدم شبكة لا يشارك في المؤامرة. بمرور الوقت ، ستتلقى مثل هذه الصفقة المزيد والمزيد من الأطفال والأحفاد والأحفاد من المستخدمين العاديين ، وتتوسع مثل كرة الثلج ، وسيتعين على جميع مزودي الطلبات المتفق عليهم تجاهل هذه المعاملات أيضًا. في النهاية ، سيتعين عليهم فرض الرقابة على الشبكة بالكامل ، والتي هي بمثابة تخريب.
وبالتالي ، تظل DAG مقاومة للرقابة ، حتى لو كان هناك تواطؤ لمقدمي الطلبات ، وبالتالي تجاوز blockchain في مقاومة الرقابة ، والتي لا يمكننا فعل أي شيء إذا قرر عمال المناجم عدم إدراج أي من المعاملات. وهذا يأتي من الخاصية الرئيسية لـ DAG: المشاركة في السجل مستقلة تمامًا وبدون وسطاء ، والمعاملات لا رجعة فيها.