فيتاليك: بنية الربط والمعالجات المساعدة، مفهوم جديد لتعزيز الكفاءة والأمان

يجب تحسين الغراء ليكون غراءً جيدًا، ويجب أيضًا تحسين المعالج المساعد ليكون معالجًا مساعدًا جيدًا.

العنوان الأصلي: "Glue and coprocessor architectures"

الكاتب: Vitalik Buterin، مؤسس Ethereum

الترجمة: Deng Tong، Jinse Finance

شكر خاص لـ Justin Drake، Georgios Konstantopoulos، Andrej Karpathy، Michael Gao، Tarun Chitra، ومجموعة من مساهمي Flashbots على تعليقاتهم وملاحظاتهم.

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

• كمية صغيرة نسبيًا من "المنطق التجاري" المعقد ولكن غير المكثف حسابيًا؛
• كمية كبيرة من "العمل المكلف" المكثف للغاية ولكنه منظم بدرجة عالية.

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

ما هي أمثلة هذه الطرق المختلفة في الممارسة العملية؟

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

• التكلفة الأساسية: 21,000
• بيانات الاستدعاء: 1,556
• تنفيذ EVM: 24,368
• تعليمة SLOAD: 6,400
• تعليمة SSTORE: 10,100
• تعليمة LOG: 2,149
• أخرى: 6,719

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

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

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

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

التمرير الأمامي لكتلة من نموذج Transformer

ماذا نرى هنا؟ نرى كمية صغيرة نسبيًا من "المنطق التجاري" مكتوبة بلغة Python، تصف بنية العمليات التي يتم تنفيذها. في التطبيق العملي، سيكون هناك نوع آخر من المنطق التجاري يحدد تفاصيل مثل كيفية الحصول على المدخلات وما يجب فعله بالمخرجات. ولكن إذا تعمقنا في كل عملية فردية (self.norm، torch.cat، +، *، الخطوات داخل self.attn...)، سنرى حسابات متجهة: نفس العملية تُحسب بالتوازي على العديد من القيم. كما في المثال الأول، جزء صغير من الحساب يُستخدم للمنطق التجاري، بينما الجزء الأكبر يُستخدم لتنفيذ عمليات مصفوفة ومتجهات ضخمة - في الواقع، معظمها مجرد ضرب مصفوفات.

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

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

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

رسم بياني من وثائق RiscZero

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

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

بشكل عام، كيف تبدو هذه الظاهرة؟

يتبع الحوسبة الحديثة بشكل متزايد ما أسميه بنية الغراء والمعالج المساعد: لديك بعض المكونات المركزية "الغراء"، وهي عامة للغاية ولكنها غير فعالة، مسؤولة عن نقل البيانات بين واحد أو أكثر من مكونات المعالج المساعد، والتي تكون أقل عمومية ولكنها عالية الكفاءة.

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

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

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

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

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

ماذا يعني هذا؟

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

EVM

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

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

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

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

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

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

كمبيوتر محمول RISC-V يعمل بنظام Debian

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

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

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

علم التشفير

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

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

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

الاستنتاج

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

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

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