a16z: حول استحالة "البلوكشين عديمة الجنسية"

كتبه في الأصل ميراندا كريست وجوزيف بونو

تجميع النص الأصلي: Deep Tide TechFlow

نظرًا لأن blockchain يدعم المزيد من المستخدمين والمعاملات الأكثر تكرارًا، فإن كمية المعلومات (أو "الحالة") المخزنة بواسطة المدققين للتحقق من المعاملات تزداد. على سبيل المثال، في البيتكوين، تتكون الحالة من مجموعة من مخرجات المعاملات غير المنفقة (UTXOs). في الايثيريوم، تتكون الحالة من رصيد الحساب لكل حساب ورمز وتخزين كل عقد ذكي.

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

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

لا توجد حالة

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

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

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

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

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

خلفية بحثنا

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

نقوم أولاً ببناء شجرة Merkle حيث يتم تضمين كل زوج (معرف الحساب والرصيد) (أ، ب) كعقدة طرفية. الحالة ذات الحجم الثابت V المخزنة بواسطة المدققين هي جذر هذه الشجرة، والتي تعمل بمثابة التزام بمجموعة من أزواج رصيد الحساب. يحتفظ كل مستخدم بشهادته كدليل على إدراج Merkle. يتكون إثبات Merkle لتضمين ورقة (a,b) من العقد الشريكة (v1,...,vk) على طول المسار من تلك الورقة إلى جذر الشجرة. بالنظر إلى معاملة بواسطة الحساب a والرصيد المطالب به b، يمكن للمدقق التحقق من أن b هو بالفعل رصيد الحساب a عن طريق التحقق من الدليل (v1،...،vk) لـ (a،b) مقابل حالته الحالية V. إذا كان الأمر كذلك، يقوم المدقق بتنفيذ المعاملة ويجب عليه تحديث رصيد الحساب وفقًا لذلك. من الخصائص الملائمة لأشجار Merkle أنه، نظرًا لإثبات Merkle لإدراج ورقة ما، فمن السهل حساب جذر النتيجة عندما تتغير تلك الورقة. بمعنى آخر، يمكن للمدقق حساب الحالة المحدثة V' التي تلتقط الرصيد الجديد للحساب a بعد تنفيذ المعاملة.

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

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

استنتاجنا: انعدام الجنسية غير ممكن

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

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

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

من أجل التبسيط، نصف هنا دليلاً على عبارة أضعف قليلاً: لا يوجد blockchain عديم الحالة حيث لا يحتاج المستخدمون أبدًا إلى تحديث معلومات الشهود الخاصة بهم. النقطة المهمة هي أن أليس تستخدم نظام blockchain عديم الجنسية لتشفير رسالتها إلى بوب. في البداية، يعرف كل من أليس وبوب المجموعة الكاملة لأزواج أرصدة الحسابات لجميع المستخدمين n. افترض أن كل حساب لديه عملة واحدة على الأقل. يعرف كل من أليس وبوب أيضًا الحالة الموجزة V لسلسلة الكتل عديمة الجنسية والشهود من جميع أزواج أرصدة الحسابات (ai، bi). يتفق أليس وبوب أيضًا على التعيين بين الرسائل ومجموعات الحسابات. ستختار أليس مجموعة "أ" من الحسابات المقابلة لرسالتها، ثم ستقوم بعد ذلك بإنفاق العملات المعدنية من تلك الحسابات. ستستخدم سلسلة الكتل عديمة الجنسية لتوصيل المجموعة التي تختارها إلى بوب والتي يمكنه من خلالها التعرف عليها.

الترميز: تنفق أليس عملة واحدة من كل حساب في A. باستخدام نظام blockchain عديم الحالة، تحسب أليس الحالة V المحدثة وترسلها إلى بوب.

فك التشفير: لكل i، يتحقق بوب مما إذا كان Verify(wi, (ai, bi)) صحيحًا. يقوم Bob بإخراج مجموعة الحسابات B بحيث يكون Verify(wi, (ai, bi)) = false.

نجح بوب في إخراج نفس المجموعة التي اختارتها أليس: B = A. أولاً، لاحظ أنه إذا أنفقت أليس عملة معدنية من الحساب ai، فلن يتم قبول شاهد رصيدها القديم - وإلا فستتمكن أليس من الإنفاق المزدوج. لذلك، بالنسبة لكل حساب ai في A، Verify(wi, (ai, bi)) = false، وسيقوم Bob بتضمين هذا الحساب في B. من ناحية أخرى، لن يدرج بوب أبدًا حسابات B التي لم تنفق أليس منها عملات معدنية، لأن أرصدة هذه الحسابات تظل كما هي، و(تذكر البيان المخفف الذي نريد إثباته) لن يتغير شهودهم أبدًا. وبالتالي فإن B يساوي A تمامًا.

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

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

تأثير النتيجة

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

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

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

لكن لسوء الحظ، هذا يعني أن نتائج الاستحالة لدينا تنطبق مباشرة. يجب أن يتغير شاهد جلب مجموعة التحديثات الخاص بالمستخدم بشكل متكرر، وإلا فسيتعين كتابة حالة L2 بأكملها تقريبًا إلى L1. ونتيجة لذلك، تفترض مجموعات التحديثات اليوم عادةً وجود لجنة توفر البيانات (تسمى أحيانًا "فاليديوم")، على غرار "عقدة خدمة الإثبات" التي تساعد المستخدمين على حساب الشهود الجدد عندما يكونون مستعدين للسحب. تظهر نتائجنا أن التحذير الموجه للمستخدمين في وثائق Ethereum: "بدون بيانات المعاملات، لا يمكن للمستخدمين حساب أدلة Merkle لإثبات ملكية الأموال وإجراء عمليات السحب." سيتم تطبيقه دائمًا.