a16z: لماذا لا يمكن وجود blockchain عديمة الجنسية

المؤلف: ميراندا كريست (طالبة دكتوراه في علوم الكمبيوتر في جامعة كولومبيا/متدربة في أبحاث التشفير a16z)، جوزيف بونو (a16zcrypto) المصدر: a16z crypto؛ المترجم: Yvonne, MarsBit

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

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

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

دولة عديمة الجنسية

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

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

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

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

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

خلفية البحث

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

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

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

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

استنتاجنا: انعدام الجنسية أمر مستحيل

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

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

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

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

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

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

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

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

(قد يلاحظ القراء المطلعون على علم التشفير أننا نتجاهل بعض التفاصيل هنا؛ على سبيل المثال، فشل بوب في فك التشفير باحتمال ضئيل. ويتضمن بحثنا دليلاً كاملاً).

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

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

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

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

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

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

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