المقابلة: يان
في 7 أبريل 2025، ظهر فيتاليك وشياو وي معًا في حدث Pop-X HK Research House الذي نظمته شركة DappLearning وETHDimsum وPanta Rhei وUETH.
أثناء الحدث، أجرى يان، مؤسس مجتمع DappLearning، مقابلة مع فيتاليك. تناولت المقابلة مواضيع مثل ETH POS، وLayer2، والتشفير والذكاء الاصطناعي. تم إجراء المقابلة باللغة الصينية، وكان فيتاليك يتحدث الصينية بطلاقة.

فيما يلي محتوى المقابلة (تمت إعادة تنظيم المحتوى الأصلي لسهولة القراءة والفهم):
آراء حول ترقية نقاط البيع
يان:
مرحباً فيتاليك، أنا يان من مجتمع DappLearning. إنه لشرف عظيم أن أجري معك مقابلة هنا. بدأت التعرف على الإيثريوم في عام 2017. أتذكر أنه في عامي 2018 و2019، كان لدى الجميع نقاش حاد حول إثبات العمل (POW) وإثبات البيع (POS). ربما يستمر مناقشة هذا الموضوع.
من الآن فصاعدًا، يعمل (ETH) POS بشكل مستقر منذ أكثر من أربع سنوات، وهناك ملايين من المحققين في شبكة الإجماع. لكن في الوقت نفسه، استمر سعر صرف ETH مقابل BTC في الانخفاض، وهو ما له جوانب إيجابية وبعض التحديات.
إذن في هذه المرحلة، ما رأيك في ترقية نظام نقاط البيع الخاص بـ Ethereum؟
فيتاليك:
أعتقد أن أسعار BTC وETH لا علاقة لها بـ POW وPOS.
هناك العديد من الأصوات المختلفة في مجتمعي BTC وETH، وما يفعله هذان المجتمعان مختلف تمامًا، وطريقة تفكير كل شخص مختلفة تمامًا أيضًا.
فيما يتعلق بسعر ETH، أعتقد أن هناك مشكلة. لدى ETH العديد من المستقبليات المحتملة. (من الممكن) أنه في هذه المستقبلات، سيكون هناك العديد من التطبيقات الناجحة على Ethereum، ولكن هذه التطبيقات الناجحة قد لا تجلب قيمة كافية لـ ETH.
هذه مشكلة تقلق الكثير من الناس في المجتمع، ولكن في الحقيقة هذه المشكلة طبيعية جدًا. على سبيل المثال، شركة جوجل هي شركة تصنع العديد والعديد من المنتجات وتقوم بالعديد من الأشياء المثيرة للاهتمام. ومع ذلك، لا يزال أكثر من 90% من إيراداتهم مرتبطًا بأعمال البحث الخاصة بهم.
العلاقة بين تطبيقات نظام Ethereum البيئي وETH (السعر) متشابهة. هناك بعض التطبيقات التي تدفع رسوم معاملات عالية وتستهلك الكثير من ETH. في الوقت نفسه، هناك أيضًا العديد من (التطبيقات) التي قد تكون أكثر نجاحًا، ولكن النجاح الذي تحققه لـ ETH ليس بالقدر الذي ينبغي أن يكون.
لذا فإن هذه مشكلة نحتاج إلى التفكير فيها ومواصلة تحسينها. نحن بحاجة إلى دعم المزيد من التطبيقات التي لها قيمة طويلة الأجل لحاملي Ethereum وETH.
لذا أعتقد أن النجاح المستقبلي لـ ETH قد يظهر في هذه المجالات. لا أعتقد أن الأمر له علاقة كبيرة بتحسين خوارزمية الإجماع.
مخاوف بشأن هندسة PBS والمركزية
يان:
نعم، إن ازدهار نظام ETH البيئي هو أيضًا أحد الأسباب المهمة التي تجذب مطورينا لبنائه.
حسنًا،ما رأيك في بنية PBS (فصل المقترح والمنشئ) الخاصة بـ ETH2.0؟ هذا اتجاه جيد جدًا. في المستقبل، يمكن لأي شخص استخدام الهاتف المحمول كعقدة ضوئية للتحقق من (ZK) الإثبات، وبعد ذلك يمكن لأي شخص أن يراهن بـ 1 إيثر ليصبح محققًا.
ولكن قد يصبح المنشئ أكثر مركزية. يجب أن يتعامل مع كل من مقاومة MEV وتوليد ZK Proof. إذا تم اعتماد التجميع المستند إلى البيانات، فقد يتعين على المنشئ القيام بالمزيد، مثل العمل كمتسلسل.
هل سيكون Builder مركزيًا للغاية في هذه الحالة؟ على الرغم من أن Validator لامركزي بدرجة كافية، فهو عبارة عن سلسلة. إذا كانت هناك مشكلة في أحد الروابط الموجودة في المنتصف، فسوف يؤثر ذلك أيضًا على تشغيل النظام بأكمله. إذن كيف يمكننا حل مشكلة الرقابة هذه؟
فيتاليك:
نعم، أعتقد أن هذا سؤال فلسفي مهم للغاية.
في الأيام الأولى لبيتكوين وإيثريوم، كان هناك افتراض لا شعوري على الأرجح:
إن بناء كتلة والتحقق من كتلة هي عملية واحدة.
افترض أنك تقوم ببناء كتلة، إذا كانت كتلتك تحتوي على 100 معاملة، فستحتاج إلى تشغيل هذا القدر من الغاز (100 معاملة) على العقدة الخاصة بك. عندما تقوم ببناء كتلة وتبثها للعالم، فسوف تحتاج كل عقدة في العالم أيضًا إلى القيام بنفس القدر من العمل (استهلاك نفس كمية الغاز). لذا، إذا قمنا بتعيين حد الغاز بحيث يتمكن كل كمبيوتر محمول أو ماك بوك، أو خادم بحجم معين في العالم، من بناء الكتل، فسيكون هناك حاجة إلى خادم عقدة مع التكوين المقابل للتحقق من هذه الكتل.
هذه هي التكنولوجيا السابقة. والآن لدينا ZK، وDAS، والعديد من التقنيات الجديدة، وانعدام الجنسية (التحقق بدون جنسية). قبل استخدام هذه التقنيات، كان من الضروري أن تكون كتل البناء وكتل التحقق متماثلة، ولكن الآن يمكن أن تصبح غير متماثلة. لذا فإن صعوبة بناء كتلة قد تصبح عالية جدًا، ولكن صعوبة التحقق من كتلة قد تصبح منخفضة جدًا.
استخدم عميلاً عديم الجنسية كمثال: إذا استخدمنا تقنية عديمة الجنسية وزدنا حد الغاز عشرة أضعاف، فإن قوة الحوسبة المطلوبة لبناء كتلة ستصبح ضخمة، وقد لا يكون الكمبيوتر العادي قادرًا على القيام بذلك. في هذا الوقت، قد تحتاج إلى استخدام استوديو MAC عالي الأداء بشكل خاص، أو خادم ذو تكوين أكثر قوة.
ولكن تكلفة التحقق ستصبح أقل لأن التحقق لا يتطلب أي مساحة تخزين على الإطلاق ويعتمد فقط على النطاق الترددي وموارد الحوسبة الخاصة بوحدة المعالجة المركزية. إذا تمت إضافة تقنية ZK، فمن الممكن أيضًا التخلص من تكلفة وحدة المعالجة المركزية للتحقق. إذا أضفت ذلك DAS، فإن تكلفة التحقق ستكون منخفضة للغاية. إذا أصبحت تكلفة بناء كتلة أعلى، فإن تكلفة التحقق ستصبح منخفضة للغاية.
فهل هذا أفضل من الوضع الحالي؟
هذا السؤال معقد إلى حد ما. أعتقد أن هذا هو ما أفكر به: إذا كان هناك بعض العقد الفائقة في شبكة Ethereum، أي بعض العقد ذات قوة الحوسبة الأعلى، فنحن بحاجة إليها للقيام بالحوسبة عالية الأداء.
فكيف يمكننا منعهم من فعل الشر؟ على سبيل المثال، هناك عدة أنواع من الهجمات.
أولاً: إنشاء هجوم بنسبة 51%.
ثانيا: هجوم الرقابة. ثالثا: العمليات المرتبطة بمكافحة MEV، كيف يمكننا الحد من هذه المخاطر؟
من حيث الهجوم بنسبة 51%، نظرًا لأن عملية التحقق تتم بواسطة Attester، فإن عقد Attester تحتاج إلى التحقق من DAS وZK Proof والعملاء عديمي الجنسية. ستكون تكلفة هذا التحقق منخفضة للغاية، وبالتالي فإن الحد الأدنى للتحول إلى عقدة إجماع سيظل منخفضًا نسبيًا.
على سبيل المثال، إذا كان هناك بعض العقد الفائقة التي تقوم ببناء الكتل، إذا حدث موقف حيث 90% من هذه العقد هي أنت، و5% هو، و5% هم أشخاص آخرون. إذا لم تقبل أي صفقة على الإطلاق، فهذا ليس بالأمر السيئ على الإطلاق. لماذا؟ لأنه ليس لديك أي وسيلة للتدخل في عملية الإجماع بأكملها.
لذا لا يمكنك القيام بهجوم بنسبة 51%، الشيء الوحيد الذي يمكنك فعله هو عدم الإعجاب بمعاملات مستخدمين معينين. قد يحتاج المستخدم فقط إلى الانتظار لمدة عشرة أو عشرين كتلة حتى يقوم شخص آخر بتضمين معاملته في الكتلة. هذه هي النقطة الأولى.
النقطة الثانية هي أن لدينا مفهوم الحفرية، فماذا تفعل الحفرية؟ يمكن لـ Fossil فصل دور "اختيار المعاملات" عن دور التنفيذ. بهذه الطريقة، يمكن جعل دور اختيار المعاملات التي سيتم تضمينها في الكتلة التالية أكثر لامركزية. وبالتالي، من خلال طريقة Fossil، بالنسبة لتلك العقد الصغيرة، سيكون لديها القدرة على تحديد المعاملات التي سيتم تضمينها في الكتلة التالية بشكل مستقل. بالإضافة إلى ذلك، إذا كنت عقدة كبيرة، فسيكون لديك في الواقع عدد قليل جدًا من الحقوق[1].
هذه الطريقة أكثر تعقيدًا من ذي قبل. في السابق، كنا نعتقد أن كل عقدة هي عبارة عن كمبيوتر محمول شخصي. ولكن إذا نظرت إلى البيتكوين، ستجد أنه يتمتع الآن بهندسة هجينة نسبيًا. لأن جميع عمال مناجم البيتكوين هم مراكز بيانات التعدين.
وهكذا يتم الأمر في نظام نقاط البيع، أي أن بعض العقد تتطلب قوة حوسبة أكبر وموارد أكبر. ومع ذلك، فإن حقوق هذه العقد محدودة، ويمكن جعل العقد الأخرى متفرقة للغاية ولامركزية، بحيث يمكنها ضمان أمن الشبكة ولامركزيتها. لكن هذه الطريقة أكثر تعقيدًا، لذا فهذا يشكل تحديًا لنا أيضًا.
يان:
فكرة جيدة جدًا. المركزية ليست بالضرورة أمراً سيئاً طالما أننا نستطيع الحد منها ومنعها من فعل الشر.
فيتاليك:
نعم.
المشاكل بين الطبقة 1 والطبقة 2، والاتجاهات المستقبلية
يان:
شكرًا لك على الإجابة على حيرتي على مر السنين. والآن نأتي إلى الجزء الثاني من السؤال. باعتبارها شاهدًا على رحلة Ethereum، فإن Layer2 ناجحة جدًا بالفعل. الآن تم حل مشكلة TPS بالفعل. إنه ليس مثل أيام ICO (العرض الأولي للعملة) عندما كان مزدحمًا للغاية. أعتقد شخصيًا أن L2 أصبح سهل الاستخدام للغاية الآن. ومع ذلك، اقترح العديد من الأشخاص حلولاً مختلفة لمشكلة تجزئة السيولة L2. ما رأيك في العلاقة بين الطبقة الأولى والطبقة الثانية؟ هل الشبكة الرئيسية الحالية لإيثريوم بوذية للغاية ولامركزية للغاية، ولا تحتوي على أي قيود على الطبقة 2؟ هل تحتاج الطبقة 1 إلى صياغة قواعد مع الطبقة 2، أو صياغة بعض نماذج تقاسم الأرباح، أو اعتماد حلول مثل Based Rollup؟ اقترح جاستن دريك مؤخرًا هذا الحل على Bankless، وأنا أتفق معه. ماذا تعتقد؟ أنا أيضًا أشعر بالفضول لمعرفة متى سيتم إطلاقه إذا كان هناك حل مماثل؟
فيتاليك:
أعتقد أن هناك العديد من المشاكل مع الطبقة الثانية لدينا الآن.
الأول هو أن التقدم الذي أحرزوه في مجال الأمن ليس سريعًا بما فيه الكفاية. لذا فقد كنت أسعى إلى ترقية الطبقة 2 إلى المرحلة 1، وآمل أن يتم ترقيتها إلى المرحلة 2 هذا العام. لقد كنت أحثهم على القيام بذلك، وفي الوقت نفسه كنت أدعم L2BEAT للقيام بمزيد من العمل الشفاف في هذا الصدد.
المشكلة الثانية هي مشكلة التوافق L2. وهذا يعني المعاملات والاتصالات عبر السلسلة بين شبكتين L2. إذا كان النظامان L2 في نفس النظام البيئي، فيجب أن يكون التشغيل المتبادل أبسط وأسرع وأقل تكلفة مما هو عليه الآن. لقد بدأنا هذا العمل في العام الماضي، والذي يسمى الآن Open Intents Framework، والعناوين الخاصة بالسلسلة، والتي هي في الغالب عمل UX.
في الواقع، أعتقد أن 80% من مشاكل سلسلة L2 المتقاطعة هي في الواقع مشكلات تتعلق بتجربة المستخدم. على الرغم من أن عملية حل مشكلات تجربة المستخدم قد تكون مؤلمة، إلا أنه طالما كان الاتجاه صحيحًا، يمكن تبسيط المشكلات المعقدة. وهذا أيضًا هو الاتجاه الذي نعمل نحوه.
تتطلب بعض الأمور الذهاب إلى خطوة أبعد، على سبيل المثال، وقت السحب لـ Optimistic Rollup هو أسبوع واحد. إذا كان لديك رمز مميز على Optimism أو Arbitrum، فسوف يتعين عليك الانتظار لمدة أسبوع لتوصيل هذا الرمز المميز إلى L1 أو إلى L2 آخر. يمكنك أن تطلب من صناع السوق الانتظار لمدة أسبوع (وسوف تحتاج إلى دفع رسوم معينة لهم وفقًا لذلك). يمكن للمستخدمين العاديين عبور السلسلة من L2 إلى L2 آخر من خلال طرق مثل Open Intents Framework Across Protocol. وهذا مقبول بالنسبة لبعض المعاملات الصغيرة. ومع ذلك، بالنسبة لبعض المعاملات الكبيرة، لا يزال صناع السوق يتمتعون بسيولة محدودة. وبالتالي، فإن رسوم المعاملات التي يحتاجونها ستكون أعلى. لقد نشرت مقالاً في الأسبوع الماضي [2] حيث دعمت فيه طريقة التحقق 2 من 3، وهي طريقة OP + ZK + TEE. لأنه إذا قمت بـ 2 من 3، يمكنك تلبية ثلاثة متطلبات في نفس الوقت.
المتطلب الأول هو عدم الثقة بشكل كامل. ليس هناك حاجة لمجلس الأمن. تلعب تقنية TEE دورًا داعمًا، لذا ليست هناك حاجة إلى الثقة بها بشكل كامل. ثانيًا، يمكننا البدء في استخدام تقنية ZK، ولكن تقنية ZK لا تزال في مراحلها الأولى، لذلك لا يمكننا الاعتماد كليًا على هذه التقنية. ثالثًا، يمكننا تقليل وقت السحب من أسبوع إلى ساعة واحدة. يمكنك أن تتخيل أنه إذا استخدم المستخدمون إطار عمل Open Intents، فسوف تنخفض تكلفة السيولة لصناع السوق بمقدار 168 مرة. لأن الوقت الذي يحتاجه صناع السوق للانتظار (لعمليات إعادة التوازن) سيتم تقليصه من أسبوع إلى ساعة واحدة. على المدى الطويل، نخطط لتقليل وقت السحب من ساعة واحدة إلى 12 ثانية (وقت الحظر الحالي)، وإذا اعتمدنا SSF، فيمكن تقليله إلى 4 ثوانٍ. في الوقت الحاضر، سوف نستخدم أيضًا تجميع zk-SNARK، على سبيل المثال، لتوازي عملية إثبات ZK وتقليل زمن الوصول. بالطبع، إذا كان المستخدم يستخدم ZK للقيام بذلك، فلا داعي للقيام بذلك من خلال Intents. ولكن إذا فعلوا ذلك من خلال النوايا، فإن التكلفة ستكون منخفضة للغاية، وهذا كله جزء من التفاعل. فيما يتعلق بدور L1، في المراحل المبكرة من خريطة طريق L2، قد يعتقد الكثير من الناس أنه يمكننا نسخ خريطة طريق Bitcoin بالكامل، وأن L1 سيتم استخدامها لأغراض قليلة جدًا، فقط لإجراء الإثباتات (وكميات صغيرة أخرى من العمل)، ويمكن لـ L2 القيام بكل شيء آخر.
ولكننا وجدنا أنه إذا لم يلعب L1 أي دور على الإطلاق، فسيكون ذلك خطيرًا على ETH. لقد تحدثنا عن هذا من قبل، وأحد أكبر مخاوفنا هو أن نجاح تطبيقات Ethereum لا يمكن أن يصبح نجاح ETH.
إذا فشل ETH، فلن يكون لدى مجتمعنا أموال ولن يكون لديه وسيلة لدعم الجولة التالية من التطبيقات. لذلك، إذا لم يلعب L1 أي دور على الإطلاق، فسيتم التحكم في تجربة المستخدم والهندسة المعمارية بأكملها بواسطة L2 وبعض التطبيقات. لن يكون هناك أحد يمثل ETH. لذا، إذا تمكنا من تعيين المزيد من الأدوار لـ L1 في بعض التطبيقات، فسيكون ذلك أفضل بالنسبة لـ ETH.
السؤال التالي الذي نحتاج إلى الإجابة عليه هو ماذا سيفعل L1؟ ماذا يفعل L2؟
لقد نشرت مقالاً في شهر فبراير[3]، في عالم يركز على اللغة الثانية، هناك العديد من الأشياء المهمة التي يجب على اللغة الأولى القيام بها. على سبيل المثال، يحتاج L2 إلى إرسال شهادة إلى L1. إذا واجهت إحدى المستويات L2 مشكلة، فسوف يحتاج المستخدم إلى عبور السلسلة إلى مستوى L2 آخر عبر L1. بالإضافة إلى ذلك، يمكن وضع محفظة مخزن المفاتيح وبيانات Oracle على L1، وما إلى ذلك. ويعتمد الكثير من هذه الآلات على L1.
هناك أيضًا بعض التطبيقات ذات القيمة العالية، مثل Defi، والتي تعد في الواقع أكثر ملاءمة لـ L1. أحد الأسباب المهمة لكون بعض تطبيقات Defi أكثر ملاءمة لـ L1 هو أفقها الزمني (فترة الاستثمار). يحتاج المستخدمون إلى الانتظار لفترة طويلة، مثل سنة أو سنتين أو ثلاث سنوات. ويظهر هذا جليا بشكل خاص في سوق التنبؤ، حيث يتم طرح أسئلة في بعض الأحيان، مثل ماذا سيحدث في عام 2028؟
هناك مشكلة هنا، إذا كانت هناك مشكلة في حوكمة L2. من الناحية النظرية، يمكن لجميع المستخدمين هناك الخروج، ويمكنهم الانتقال إلى L1، أو يمكنهم الانتقال إلى L2 آخر. ومع ذلك، إذا كان هناك تطبيق في هذا L2 تكون أصوله مقفولة في عقد ذكي طويل الأجل، فلن يكون لدى المستخدمين طريقة للخروج. لذلك، هناك العديد من أدوات Defis التي تعتبر آمنة من الناحية النظرية، ولكنها في الواقع ليست آمنة للغاية. وبناءً على هذه الأسباب، لا يزال من الضروري تنفيذ بعض التطبيقات على L1، لذا بدأنا نولي المزيد من الاهتمام لقابلية التوسع في L1.
لدينا الآن خريطة طريق، وبحلول عام 2026، سيكون هناك حوالي أربع أو خمس طرق لتحسين قابلية التوسع في L1.
الأول هو التنفيذ المتأخر (يتم فصل التحقق من الكتلة والتنفيذ)، مما يعني أنه يمكننا فقط التحقق من الكتلة في كل فتحة والسماح لها بالتنفيذ فعليًا في الفتحة التالية. وهذا له ميزة، حيث يمكن زيادة الحد الأقصى لوقت التنفيذ المقبول لدينا من 200 ميلي ثانية إلى 3 ثوانٍ أو 6 ثوانٍ. وهذا يسمح بوقت معالجة أطول[4].
الثانية هي قائمة الوصول على مستوى الكتلة، مما يعني أن كل كتلة ستحتاج إلى الإشارة في معلومات هذه الكتلة إلى حالة الحسابات التي تحتاج هذه الكتلة إلى قراءتها، بالإضافة إلى حالة التخزين ذات الصلة. يمكن القول أنها تشبه إلى حد ما عديم الجنسية بدون شاهد. إحدى مزايا هذا الأمر هي أننا نستطيع معالجة تشغيل EVM وعمليات الإدخال والإخراج بالتوازي. هذه طريقة تنفيذ بسيطة نسبيًا للمعالجة المتوازية.
الثالث هو تسعير الغاز متعدد الأبعاد [5]، والذي يمكنه تحديد الحد الأقصى لسعة الكتلة، وهو أمر مهم للغاية للأمان.
وهناك طريقة أخرى وهي معالجة البيانات التاريخية (EIP4444)، والتي لا تتطلب من كل عقدة تخزين كافة المعلومات بشكل دائم. على سبيل المثال، يمكن لكل عقدة توفير 1% فقط. يمكننا استخدام نهج p2p، حيث قد تقوم العقدة الخاصة بك بحفظ جزء وقد تقوم العقدة الخاصة به بحفظ جزء. بهذه الطريقة يمكننا تخزين هذه المعلومات بشكل أكثر تشتتًا.
لذا إذا تمكنا من الجمع بين هذه الحلول الأربعة معًا، فإننا نعتقد الآن أنه يمكننا زيادة حد الغاز لـ L1 بمقدار 10 مرات. ستتاح لجميع تطبيقاتنا الفرصة للبدء في الاعتماد بشكل أكبر على L1 والقيام بأشياء أكثر على L1، وهو ما سيكون جيدًا لـ L1 ولـ ETH أيضًا.
يان:
حسنًا، السؤال التالي، هل من الممكن أن نرى ترقية Pectra هذا الشهر؟
فيتاليك:
في الواقع، نأمل أن نفعل أمرين، وهما ترقية Pectra بحلول نهاية هذا الشهر، ثم ترقية Fusaka في الربع الثالث أو الربع الرابع.
يان:
واو، بهذه السرعة؟
فيتاليك:
أتمنى ذلك.
يان:
سؤالي التالي يتعلق بهذا أيضًا. باعتبارنا أحد الأشخاص الذين شاهدوا نمو Ethereum، فإننا نعلم أنه من أجل ضمان الأمان، يوجد لدى Ethereum حوالي خمسة أو ستة عملاء (عملاء الإجماع وعملاء التنفيذ) يتم تطويرهم في نفس الوقت. يوجد قدر كبير من العمل التنسيقي بينهما، مما يؤدي إلى دورة تطوير طويلة نسبيًا.
هذا له إيجابيات وسلبيات. قد يكون بطيئًا مقارنةً بـ L1s الأخرى، لكنه أيضًا أكثر أمانًا.
ولكن هل هناك أي حل يسمح لنا بعدم الانتظار لمدة عام ونصف للحصول على الترقية؟ لقد رأيت أيضًا أنك اقترحت بعض الحلول. هل يمكنك تعريفهم بالتفصيل؟
فيتاليك:
نعم، هناك خطة، يمكننا تحسين كفاءة التنسيق. لدينا الآن عدد أكبر من الأشخاص الذين يتنقلون بين الفرق المختلفة لضمان التواصل بشكل أكثر كفاءة بين الفرق.
إذا كان لدى فريق العميل مشكلة، فيمكنه التعبير عنها وإبلاغ فريق الباحثين بها. في الواقع، الميزة في أن يصبح توماس أحد أطبائنا الجدد في قسم الطوارئ هي هذا. لقد كان ضمن فريق العميل، وهو الآن ضمن فريق EF أيضًا. إنه قادر على القيام بالتنسيق، هذه هي النقطة الأولى.
النقطة الثانية هي أننا يمكن أن نكون أكثر صرامة مع فرق العملاء. نهجنا الحالي هو، على سبيل المثال، إذا كان هناك خمسة فرق، فإننا نحتاج إلى أن تكون جميع الفرق الخمسة مستعدة بالكامل قبل أن نعلن عن الشوكة الصعبة التالية (ترقية الشبكة). نحن نفكر الآن في الانتظار حتى تنتهي أربعة فرق فقط من المسابقة قبل البدء في الترقية. بهذه الطريقة لن نضطر إلى انتظار الشخص الأبطأ ويمكننا أيضًا تحفيز المزيد من الأشخاص.
كيف تنظر إلى التشفير والذكاء الاصطناعي؟
يان:
لذا يجب أن تكون هناك منافسة مناسبة. إنه جيد جدًا. أنا أتطلع حقًا إلى كل ترقية، ولكن لا تجعل الجميع ينتظرون لفترة طويلة.
لاحقًا، أود أن أطرح المزيد من الأسئلة المتعلقة بالتشفير، والتي هي أكثر اختلافًا. عندما تم إنشاء مجتمعنا لأول مرة في عام 2021، فقد جمع المطورين من البورصات المحلية الكبرى وباحثي المشاريع لمناقشة Defi. 21 هي في الواقع مرحلة يشارك فيها الجميع في فهم Defi وتعلم وتصميم Defi. إنها موجة من المشاركة من قبل الأمة بأكملها.
منذ التطوير اللاحق، بالنسبة لـ ZK، سواء كان الجمهور العام أو المطورين، الذين يتعلمون ZK، مثل Groth16، وPlonk، وHalo2، وما إلى ذلك، يجد المطورون اللاحقون صعوبة في اللحاق بالركب، والتكنولوجيا تتقدم بسرعة كبيرة.
بالإضافة إلى ذلك، يمكننا أن نرى أن ZKVM يتطور بسرعة كبيرة، مما يجعل ZKEVM ليس شائعًا كما كان من قبل. عندما يصل ZKVM إلى مرحلة النضج التدريجي، لن يحتاج المطورون إلى إيلاء الكثير من الاهتمام لـ ZK الأساسي.
ما هي اقتراحاتك وآراءك حول هذا الموضوع؟
فيتاليك:
أعتقد أن أفضل اتجاه لبعض أنظمة ZK البيئية هو أن يتمكن معظم مطوري ZK هؤلاء من معرفة بعض اللغات المتطورة، وهي HLL (لغة عالية المستوى). ومن ثم، يمكنهم كتابة كود التطبيق الخاص بهم في HLL، ويمكن لهؤلاء الباحثين في Proof System الاستمرار في تعديل وتحسين الخوارزمية الأساسية. يحتاج المطورون إلى الطبقات، ولا يحتاجون إلى معرفة ما يحدث في الطبقة التالية. قد تكون هناك مشكلة الآن لأن الأنظمة البيئية الحالية لـ Circom و Groth16 متطورة للغاية، ولكن هذا يشكل قيدًا كبيرًا نسبيًا على تطبيق النظام البيئي ZK. نظرًا لأن Groth16 يعاني من العديد من العيوب، مثل مشكلة أن كل تطبيق يحتاج إلى إجراء إعداد موثوق به خاص به، وكفاءته ليست عالية جدًا، لذلك نفكر أيضًا في أننا بحاجة إلى وضع المزيد من الموارد هنا ومساعدة المزيد من HLLs الحديثة على النجاح.
وهناك طريق آخر وهو طريق ZK RISC-V، وهو جيد جدًا أيضًا. نظرًا لأن RISC-V يصبح أيضًا HLL، فمن الممكن كتابة العديد من التطبيقات، بما في ذلك EVM وبعض التطبيقات الأخرى، على RISC-V[6].
يان:
حسنًا، سيكون ذلك رائعًا إذا كان على المطورين فقط تعلم Rust. لقد حضرت مؤتمر Devcon Bangkok العام الماضي وسمعت عن تطوير التشفير التطبيقي، الأمر الذي فتح عيني حقًا.
فيما يتعلق بالتشفير التطبيقي، ما رأيك في الجمع بين ZKP وMPC وFHE، وما هي الاقتراحات التي لديك للمطورين؟
فيتاليك:
نعم، هذا مثير للاهتمام للغاية. أعتقد أن FHE لديه مستقبل جيد الآن، ولكن لدي مخاوف. تتطلب MPC وFHE دائمًا لجنة، مما يعني أنهما بحاجة إلى تحديد، على سبيل المثال، سبع عقد أو أكثر. إذا تم مهاجمة 51% أو 33% من العقد، فسوف يواجه نظامك مشاكل. وهذا يعادل القول بأن للنظام مجلس أمن، ولكنه في الواقع أكثر خطورة من مجلس الأمن. لأنه إذا كانت L2 هي المرحلة 1، فيجب مهاجمة 75% من عقد مجلس الأمن قبل ظهور المشاكل[7]. هذه هي النقطة الأولى.
النقطة الثانية هي مجلس الأمن. إذا كانت موثوقة، فسيتم وضع معظمها في محافظ باردة، أي أن معظمها سيكون غير متصل بالإنترنت. ومع ذلك، في معظم MPC وFHE، يتعين على لجانها أن تكون متصلة بالإنترنت طوال الوقت لتشغيل النظام، لذا قد يتم نشرها على VPS أو خوادم أخرى. بهذه الطريقة سيكون من الأسهل مهاجمتهم.
هذا يجعلني أشعر بالقلق قليلاً. أعتقد أنه لا يزال من الممكن تقديم العديد من التطبيقات. إنها تمتلك مزايا، ولكنها ليست مثالية.
يان:
وأخيرًا، أود أن أطرح سؤالاً سهلاً نسبيًا. أرى أنك أيضًا أصبحت تهتم بالذكاء الاصطناعي مؤخرًا. وأود أن أذكر بعض الآراء. على سبيل المثال، قال إيلون ماسك أن البشر قد يكونون مجرد برنامج تمهيدي للحضارة القائمة على السيليكون.
ثم هناك وجهة نظر في "Network Nation" مفادها أن الدول الاستبدادية قد تفضل الذكاء الاصطناعي، في حين تفضل الدول الديمقراطية تقنية البلوك تشين.
بناءً على خبرتنا في عالم العملات المشفرة، فإن فرضية اللامركزية هي أن الجميع يلتزمون بالقواعد، ويراقبون ويوازنون بعضهم البعض، ويعرفون كيفية المخاطرة، مما سيؤدي في النهاية إلى السياسة النخبوية. إذن ما رأيك في هذه الآراء؟ فقط تحدث عن الآراء.
فيتاليك:
نعم، أفكر من أين أبدأ الإجابة.
نظرًا لأن مجال الذكاء الاصطناعي معقد للغاية، على سبيل المثال، قبل خمس سنوات، لم يكن أحد ليتوقع أن الولايات المتحدة ستمتلك أفضل ذكاء اصطناعي مغلق المصدر في العالم، وأن الصين ستمتلك أفضل ذكاء اصطناعي مفتوح المصدر. يمكن للذكاء الاصطناعي تحسين قدرات الجميع، وفي بعض الأحيان يمكنه أيضًا زيادة قوة بعض القوى المركزية (الدولة). ولكن يمكننا أن نقول في بعض الأحيان أن الذكاء الاصطناعي له تأثير أكثر ديمقراطية. عندما أستخدم الذكاء الاصطناعي بنفسي، أجد ذلك في المناطق التي أكون فيها بالفعل ضمن أفضل ألف شخص في العالم. على سبيل المثال، في بعض مجالات تطوير ZK، تساعدني الذكاء الاصطناعي بشكل أقل في جزء ZK، وما زلت بحاجة إلى كتابة معظم التعليمات البرمجية بنفسي. لكن في المجالات التي أكون فيها جديدًا نسبيًا، يمكن للذكاء الاصطناعي أن يساعدني كثيرًا، على سبيل المثال، تطوير تطبيقات Android، وهو ما لم أفعله من قبل. لقد قمت بإنشاء تطبيق منذ عشر سنوات، باستخدام إطار عمل مكتوب بلغة Javascript، ثم قمت بتحويله إلى تطبيق. وبصرف النظر عن ذلك، لم أكتب تطبيق Android أصليًا من قبل. لقد أجريت تجربة في بداية هذا العام. أردت أن أحاول كتابة تطبيق باستخدام GPT، وتم الانتهاء منه خلال ساعة واحدة. ومن الواضح أن الفجوة بين الخبراء والمبتدئين قد تقلصت كثيرًا بمساعدة الذكاء الاصطناعي، كما يمكن للذكاء الاصطناعي أن يوفر العديد من الفرص الجديدة.
يان:
شيء آخر أريد إضافته، أشكركم جزيل الشكر على إعطائي منظورًا جديدًا. كنت أعتقد أن الذكاء الاصطناعي قد يسمح للمبرمجين ذوي الخبرة بالتعلم بشكل أسرع، لكنه قد يكون غير ملائم للمبرمجين المبتدئين. ولكن في بعض النواحي فإنه سوف يعمل بالفعل على تحسين قدرات المبتدئين. ربما يكون هذا نوعاً من المساواة في الحقوق، وليس التمايز، أليس كذلك؟
فيتاليك:
نعم، ولكن الآن هناك قضية مهمة للغاية نحتاج إلى التفكير فيها وهي التأثير الذي سيحدثه الجمع بين بعض التقنيات التي نطورها، بما في ذلك تقنية البلوك تشين، والذكاء الاصطناعي، والتشفير، وبعض التقنيات الأخرى (على المجتمع).
يان:
لذا ما زلت تأمل ألا يحكم البشر نخبة واحدة فقط، أليس كذلك؟ ونأمل أيضًا في تحقيق الأمثلية الباريتوية للمجتمع بأكمله. يمكن للأشخاص العاديين أن يصبحوا أفرادًا خارقين من خلال تمكين الذكاء الاصطناعي والبلوكشين.
فيتاليك:
نعم، أفراد خارقون، مجتمعات خارقة، بشر خارقون.
التوقعات بشأن نظام الإيثريوم البيئي والاقتراحات للمطورين
يان:
حسنًا، دعنا ننتقل إلى السؤال الأخير. ما هي توقعاتك ورسائلك لمجتمع المطورين؟ هل لديك أي شيء لتقوله للمطورين في مجتمع Ethereum؟
فيتاليك:
يحتاج مطورو تطبيقات الإيثريوم هذه إلى التفكير في هذا الأمر.
توجد الآن العديد من الفرص لتطوير التطبيقات في Ethereum. العديد من الأشياء التي لم يكن من الممكن القيام بها من قبل يمكن القيام بها الآن.
هناك العديد من الأسباب لذلك، على سبيل المثال
أولاً: كان TPS الخاص بـ L1 غير كافٍ تمامًا من قبل، ولكن هذه المشكلة لم تعد موجودة الآن؛
ثانيًا: لم تكن هناك طريقة لحل مشكلة الخصوصية من قبل، ولكن الآن هناك؛
ثالثًا: بسبب الذكاء الاصطناعي، أصبحت صعوبة تطوير أي شيء أصغر. يمكن القول أنه على الرغم من زيادة تعقيد نظام Ethereum البيئي، إلا أنه من خلال الذكاء الاصطناعي، لا يزال بإمكان الجميع فهم Ethereum بشكل أفضل. لذا أعتقد أن العديد من الأشياء التي فشلت في الماضي، بما في ذلك ما حدث قبل عشر أو خمس سنوات، قد تكون ناجحة الآن.
في نظام تطبيقات blockchain الحالي، أعتقد أن المشكلة الأكبر هي أن لدينا نوعين من التطبيقات. يمكن القول أن النوع الأول مفتوح للغاية، ولامركزي، وآمن، ومثالي بشكل خاص (التطبيق). لكن لديهم 42 مستخدمًا فقط. ويمكن القول أن النوع الثاني هو الكازينو. المشكلة هي أن هذين طرفين متطرفين، وكلاهما غير صحي.
لذا فإن ما نأمل في القيام به هو إنشاء بعض التطبيقات التي
يحب المستخدمون استخدامها أولاً وقبل كل شيء، مما يعني أنها ستكون ذات قيمة حقيقية. ستكون هذه التطبيقات أفضل للعالم. والأمر الثاني هو أن هناك بعض نماذج الأعمال، على سبيل المثال من حيث الاقتصاد، التي يمكن أن تعمل بشكل مستدام ولا تحتاج إلى الاعتماد على أموال محدودة من المؤسسات أو المنظمات الأخرى. وهذا يشكل تحديا أيضا.
لكنني أعتقد الآن أن الجميع لديهم موارد أكثر من ذي قبل، لذا إذا تمكنت الآن من العثور على فكرة جيدة وإذا تمكنت من تنفيذها بشكل جيد، فإن فرص نجاحك ستكون كبيرة جدًا.
يان:
عند النظر إلى رحلته، أعتقد أن الإيثريوم ناجح بالفعل. لقد كانت دائمًا رائدة في الصناعة وتعمل بجد لحل المشكلات التي تواجهها الصناعة في ظل فرضية اللامركزية.
هناك نقطة أخرى أشعر بها بشدة وهي أن مجتمعنا كان دائمًا غير ربحي، من خلال منحة Gitcoin في نظام Ethereum البيئي، ومكافآت OP بأثر رجعي، ومكافآت airdrop من مشاريع أخرى. وجدنا أن Build يمكن أن يحصل على الكثير من الدعم في مجتمع Ethereum، ونحن نفكر أيضًا في كيفية ضمان قدرة المجتمع على الاستمرار في العمل بشكل مستقر.
إن بناء الإيثريوم مثير حقًا. ونأمل أيضًا أن نرى التحقيق الحقيقي للكمبيوتر العالمي في أقرب وقت ممكن. شكرا لك على وقتك الثمين.
مقابلة في جبل ديفيس، هونغ كونغ
7 أبريل 2025