Vitalik: مفهوم جديد لتحسين الكفاءة – الهندسة المعمارية والمعالج المشترك

العنوان الأصلي: الغراء والمعالجات المشتركة

المؤلف: Vitalik ، مؤسس Ethereum ؛

شكر خاص لجوستين دريك ، جورجيوس كونستانتوبولوس ، أندريج كارباشي ، مايكل غاو ، تارون تشيترا ومختلف المساهمين في فلاش بوت على ملاحظاتهم وتعليقاتهم.

إذا قمت بتحليل أي حسابات كثيفة الموارد التي يتم إجراؤها في العالم الحديث بتفاصيل معتدلة ، فإن إحدى الميزات التي ستجدها مرارًا وتكرارًا هي أنه يمكن تقسيم الحساب إلى جزأين:

• كمية صغيرة نسبيا من “منطق الأعمال” المعقدة ولكن ليس مكثفًا للغاية ؛

• الكثير من “الوظائف باهظة الثمن” المكثفة ولكن منظم للغاية.

من الأفضل التعامل مع هذين الحوسبة بطرق مختلفة: قد تكون الهندسة المعمارية أقل كفاءة ولكنها يجب أن تكون متعددة الاستخدامات ؛

ما هي أمثلة هذا النهج المختلفة في الممارسة؟

أولاً ، دعونا نلقي نظرة على البيئة التي أنا على دراية بها: Ethereum Virtual Machine (EVM).فيما يلي تتبع DETTH DEBUG لمعاملة Ethereum الأخيرة: قم بتحديث تجزئة IPFS لمدونتي على ENS.استهلكت المعاملة ما مجموعه 46924 غازًا ويمكن تصنيفه على النحو التالي:

• التكلفة الأساسية: 21000

• بيانات الاتصال: 1،556

• EVM تنفيذ: 24،368

• Sload Opcode: 6،400

• Sstore Opcode: 10،100

• سجل Opcode: 2،149

• آخرون: 6،719

تتبع EVM لتحديث Hash.العمود قبل الأخير هو استهلاك الغاز.

إن أخلاق هذه القصة هي أن معظم التنفيذ (حوالي 73 ٪ إذا نظرت فقط إلى EVM ، أو حوالي 85 ٪ إذا قمت بتضمين جزء التكلفة الأساسية التي تغطي الحساب) يتركز في عدد قليل جدًا من عمليات باهظة الثمن: تخزين القراءة و الكتابة والسجلات والتشفير (تتضمن التكلفة الأساسية 3000 للتحقق من توقيع الدفع ، ويشمل EVM أيضًا 272 لتجزئة الدفع).ما تبقى من التنفيذ هو “منطق العمل”: تبديل بتات CallData لاستخراج معرف السجل الذي أحاول تعيينه وتجزئة قمت بتعيينها ، إلخ.في عمليات النقل الرمزية ، سيشمل ذلك إضافة وطرح الأرصدة ، في التطبيقات الأكثر تقدماً ، قد يشمل ذلك الحلقات ، وما إلى ذلك.

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

لتعزيز فهمنا لهذا النمط ، دعنا نستكشفه في سياق آخر: رمز الذكاء الاصطناعي المكتوب في بيثون باستخدام الشعلة.

التسليم إلى الأمام لكتلة من طراز المحول

ماذا رأينا هنا؟نرى كمية صغيرة نسبيًا من “منطق الأعمال” المكتوبة في بيثون تصف بنية العمليات التي يتم تنفيذها.في التطبيقات العملية ، هناك نوع آخر من منطق العمل الذي يحدد تفاصيل مثل كيفية الحصول على الإدخال وما هي العمليات التي يتم تنفيذها على الإخراج.ومع ذلك ، إذا كنا نحفر في كل عملية فردية نفسها (الخطوات داخل Self.norm ، Torch.cat ، +، *، Self.attn …) ، نرى حسابات ناقلات: نفس العملية تحسب عددًا كبيرًا من الحسابات المتوازية في حالة كبيرة عدد الحالات قيمة.على غرار المثال الأول ، يتم استخدام جزء صغير من الحسابات لمنطق الأعمال ، ويتم استخدام معظمها لأداء عمليات مصفوفة ومواقف منظمة كبيرة – في الواقع ، معظمها مجرد تكاثر المصفوفة.

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

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

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

مخططات من وثائق Risczero

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

يمكن تحسين التشفير القابل للبرمجة بخلاف ZK-Snark ، مثل الحوسبة متعددة الأحزاب (MPC) والتشفير المتجانس بالكامل (FHE) ، باستخدام طرق مماثلة.

بشكل عام ، ما هي الظاهرة؟

تتبع الحوسبة الحديثة بشكل متزايد ما أسميه الترابط والعمارة المشتركة: لديك بعض مكونات “الترابط” المركزية التي تتميز بدرجة كبيرة ولكنها غير فعالة ومسؤولة عن مكونات واحدة أو أكثر.

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

انطلاقًا من الأمثلة المذكورة أعلاه ، يمكن بالطبع تقسيم الحسابات بهذه الطريقة ، والتي يبدو أنها قانون طبيعي.في الواقع ، يمكنك العثور على أمثلة على التخصص الحسابي على مدار عقود.ومع ذلك ، أعتقد أن هذا الانفصال يتزايد.أعتقد أن هناك سببًا لهذا:

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

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

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

ماذا يعني ذلك؟

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

EVM

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

قد تكون أفضل طريقة لتحسين EVM هي (1) إضافة رموز opcodes مسبقة أو مخصصة بشكل أفضل ، مثل مزيج من EVM-MAX و SIMD ، و (2) تحسين تخطيطات التخزين ، مثل تغييرات شجرة Verkle ، كتأثير جانبي ، تقليل إلى حد كبير تكلفة الوصول إلى فتحات التخزين المجاورة.

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

حوسبة آمنة وفتح الأجهزة

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

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

جهاز الكمبيوتر المحمول RISC-V يدير Debian

ومع ذلك ، تظل الكفاءة مشكلة.كتب مؤلف المقال المذكور أعلاه:

من غير المرجح أن تكون تصميمات رقائق المصادر المفتوحة الأحدث مثل RISC-V قابلة للمقارنة مع تقنية المعالج التي كانت موجودة وتم تحسينها على مدار عقود.هناك دائمًا نقطة انطلاق للتقدم.

تواجه المزيد من الأفكار بجنون العظمة ، مثل هذا التصميم لبناء أجهزة الكمبيوتر RISC-V على FPGAs ، أكبر.ولكن ماذا لو تعني بنية الغراء والمعالج المشترك أن هذه النفقات العامة ليست مهمة فعليًا؟إذا قبلنا أن تكون الرقائق المفتوحة والآمنة ستكون أبطأ من رقائق الملكية ، إذا لزم الأمر ، حتى التخلي عن التحسينات الشائعة مثل تنفيذ المضاربة والتنبؤ بالفرع ، ولكن حاول التعويض عن ذلك عن طريق إضافة (ملكية ، إذا لزم الأمر) ASIC التي يتم استخدامها من أجل أكثر ما يحدث لأنواع محددة مكثفة من الحسابات؟يمكن إجراء الحوسبة الحساسة في “الشريحة الرئيسية” التي سيتم تحسينها للأمان ، وتصميم المصدر المفتوح ، ومقاومة القناة الجانبية.سيتم إجراء حسابات أكثر كثافة (على سبيل المثال ، ZK Proof ، AI) في وحدة ASIC ، والتي ستتعلم معلومات أقل حول الحساب الذي يتم إجراؤه (ربما ، من خلال التشفير ، وفي بعض الحالات معلومات صفر).

التشفير

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

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

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

ختاماً

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

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

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