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