النص الكامل لخطاب فيتاليك في مهرجان هونج كونج Web3: الوصول إلى حدود تصميم البروتوكول

بتنسيق: دينغ تونغ، Golden Finance

خلال كرنفال Web3 في هونغ كونغ لعام 2024، المؤسس المشارك لـ Ethereum ألقى فيتاليك بوتيرين كلمة رئيسية بعنوان "الوصول إلى حدود تصميم البروتوكول". قامت Golden Finance بتجميع محتوى الخطاب على النحو التالي لصالح القراء.

Blockchain وZK-SNARKS

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

الآن، لا بد أن الكثير من هذه الأشياء كانت موجودة منذ فترة طويلة. من الناحية الفنية، لدينا ZK-SNARKS منذ بداية نظرية PCP، والتي عمرها عقود. لذا من الناحية النظرية، كانت هذه التقنيات موجودة منذ فترة طويلة، ولكن من الناحية العملية، هناك حاجز كفاءة كبير بين ما يمكنك القيام به في ورقة أكاديمية وما يمكنك القيام به في التطبيقات الحقيقية.

في الواقع، أعتقدإن blockchain نفسه لديه الكثير ليقدمه أهنئها لأنها سهّلت بالفعل اعتماد هذه التقنيات ووضعها موضع التنفيذ.

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

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

ستستخدم العديد من تطبيقات التشفير والذكاء الاصطناعي في النهاية MPC وFHE، وكلاهما شهد تحسينات سريعة في الكفاءة على مدار العقد الماضي.

يعد تجميع مفاتيح BLS تقنية مثيرة للاهتمام تتيح لك بشكل أساسي إنشاء بيانات من مجموعة من المشاركين المختلفين (ربما عشرات الآلاف) احصل على مجموعة من التوقيعات من المشاركين في المخطط) ثم التحقق من التوقيع المدمج بنفس سرعة التحقق من التوقيع الفردي.

هذا قوي. إن تجميع مفاتيح BLS هو في الواقع تقنية تقع في قلب الحالة الحديثة لنظرية إثبات الإجماع.

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

الكفاءة والأمان والوظائف الموسعة

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

فما هي التحديات هنا؟ أعتقد أن هناك مشكلتين كبيرتين الآن: إحداهما الكفاءة والأخرى الأمان. الآن، هناك نوع ثالث، والذي يمكن القول بأنه وظائف موسعة.  أعتقد،تحسين كفاءة وأمان ما لدينا اليوم< / قوي>أكثر أهمية.

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

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

لذا فإنهم لا يصدقون حتى ما إذا كانوا يفضلون التحقق من الحصة، لأنهم في الواقع يتحققون بشكل مباشر من القواعد ويتأكدون بشكل مباشر من صحة الكتل. كيف نستخدم التاريخ للقيام بذلك؟ لكي ينجح هذا الأمر حقًا، يجب إجراء براهين ZK-SNARKS في الوقت الفعلي، ولكن يجب أن تكون هناك طريقة لإثبات كل من النظرية والكتلة في 5 ثوانٍ. لذا فإن السؤال هو، هل يمكننا تحقيق ذلك؟ الآن، لدى MPC وFHE مشكلات مماثلة. كما ذكرت من قبل، هناك حالة استخدام قوية لـ MPC و FHE هي التصويت، أليس كذلك؟ لقد بدأ الأمر يحدث بالفعل.

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

كيف نحقق مثل هذا المطلب؟ بالنسبة إلى ZK-SNARKS، أعتقد أن تحسينات الكفاءة تنقسم إلى ثلاث فئات رئيسية. إحداهما هي التوازي والتجميع لذلك إذا كنت تتخيل في نظرية حول الكتل، ففي عملية تحقق واحدة، تتطلب الكتل حوالي 10 ملايين خطوة حسابية على الأكثر. يمكنك تنفيذ كل خطوة حسابية وإثبات ذلك بشكل فردي. ثم تقوم بتجميع الأدلة.  

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

تستطيع أجهزة ASIC إجراء التجزئة بشكل أسرع 100 مرة تقريبًا من وحدات معالجة الرسومات بنفس تكلفة الأجهزة ونفس تكلفة الكهرباء. والسؤال هو: هل يمكننا الحصول على نفس الفائدة بالضبط مع وجود دليل صارم؟ أعتقد أن الإجابة هي أننا يجب أن نكون قادرين على ذلك. هناك الكثير من الشركات التي بدأت بالفعل في بناء منتجات مخصصة لإثبات ZK-SNARKS، ولكن في الواقع، يجب أن تكون عامة جدًا. هل يمكننا تقليل 20 دقيقة إلى 5 ثوان ونصبح أكثر كفاءة؟

لذا لدينا بروتوكول GKR، ولدينا 64 بت، ولدينا ZK-SNARKS وجميع أنواع الأفكار المختلفة. هل يمكننا تحسين كفاءة الخوارزمية؟ هل يمكننا إنشاء المزيد من ZK-SNARKS، ووظائف التجزئة الودية، والمزيد من ZK-SNARKS، وخوارزميات التوقيع الودية؟ هناك الكثير من الأفكار هنا، وأنا أشجع الناس بشدة على بذل المزيد من العمل على هذه الأفكار. لدينا كل هذه الأشكال المذهلة من التشفير، لكن هل سيثق بها الناس؟ إذا كان الناس قلقين من وجود نوع من الخلل فيه، سواء كان ذلك في ZK-SNARKS، أو في دوائر zkevm، فهم عبارة عن 7000 سطر من التعليمات البرمجية. إذا فعلوا ذلك بفعالية كبيرة. من الناحية النظرية، فإن المتوسط ​​هو 15 إلى 50 خطأ لكل ألف سطر من التعليمات البرمجية. نحن نحاول جاهدين. أقل من 15 لكل ألف صف، ولكنها لا تزال أكبر من الصفر. إذا كان لديك هذه الأنظمة التي تحتوي على مليارات الدولارات من أصول الأشخاص، وإذا حدث خطأ في أحدها، بغض النظر عن مدى تقدم التشفير، فسيتم فقدان تلك الأموال.

السؤال هو، ما الذي يمكننا فعله لأخذ التشفير الحالي وتقليل عدد الأخطاء فيه؟  

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

استخدام أدوات الذكاء الاصطناعي للتحقق الرسمي

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

في عام 2019، لم يكن أحد يعتقد أن الذكاء الاصطناعي يمكنه إنتاج صور جميلة جدًا اليوم. لقد حققنا الكثير من التقدم، وشاهدنا الذكاء الاصطناعي يفعل ذلك.

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

إذن ما هي القيود هنا؟ الحد الأقصى هو 1 بت لجميع البيانات لكل فتحة لكل مشارك، حيث يتعين عليك بث معلومات حول من شارك في التوقيع ومن لم يشارك. هذا هو القيد الأساسي فوق هذا. إذا كان الأمر كذلك، فلا توجد قيود أخرى. الحساب، لا يوجد حد أدنى. يمكنك القيام بتجميع الأدلة. يمكنك التكرار لكل شجرة، ويمكنك أيضًا التوقيع. يمكنك القيام بمجموعات التوقيع المختلفة. يمكنك استخدام SNARKS، ويمكنك استخدام التشفير، تمامًا كما يمكنك استخدام SNARKS 32 بت، وجميع أنواع التقنيات المختلفة.

أفكار حول شبكات نظير إلى نظير

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

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

أولاً، كما نفعل اليوم، لدينا شبكة نظير إلى نظير مقسمة إلى 64 جزءًا مختلفًا، كل عقدة هي مجرد واحدة منها أو جزء من عدة عقدة الشبكات. لذا فإن وضع مشروعين في طبقات والسماح بـ Rollup هو حل رخيص جدًا وقابلية التوسع عبقرية. ويعتمد هذا أيضًا على بنية أكثر تعقيدًا من نظير إلى نظير. هل تقوم كل عقدة بتنزيل 1/8 فقط من إجمالي البيانات؟ هل يمكنك حقا جعل شبكة مثل هذه آمنة؟ كيف نحفظ البيانات؟ كيف يمكننا تحسين أمن شبكات نظير إلى نظير؟

الاستنتاج

لذا،ما نحتاج إلى مراعاته هو البروتوكولات التي يمكنها تنفيذ قيود التشفير. لقد أصبح التشفير لدينا بالفعل أقوى بكثير مما كان عليه قبل بضعة عقود، ولكن يمكن أن يكون أقوى بكثير، وأعتقد أننا الآن بحاجة حقًا إلى البدء في التفكير في ما هو السقف وكيف يمكننا تحقيقه بالفعل إليها؟

هناك اتجاهان على نفس القدر من الأهمية هنا:

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

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

ولكن لتحقيق ذلك، يجب أن تكون التعليمات البرمجية جديرة بالثقة. والسؤال هو: هل يمكننا أن نجعل الكود جديرًا بالثقة؟ هل يمكننا أن نجعل الويب جديرًا بالثقة؟ هل يمكننا أن نجعل اقتصاديات هذه المنتجات من هذه البروتوكولات جديرة بالثقة؟ أعتقد أن هذه هي التحديات الأساسية وآمل أن نتمكن جميعًا من مواصلة العمل معًا للتحسين. شكرًا.