فيتاليك: أفكار جديدة لتحسين الكفاءة - اللصق وبنية المعالج المشترك

العنوان الأصلي: بنيات الغراء والمعالج المساعد

المؤلف: فيتاليك، مؤسس Ethereum؛ المترجم: دينغ تونغ، Golden Finance

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

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

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

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

أولاً، دعونا نلقي نظرة على البيئة التي أعرفها كثيرًا: آلة الإيثريوم الافتراضية (EVM). فيما يلي تتبع تصحيح أخطاء geth لمعاملة Ethereum الأخيرة التي أجريتها: تحديث تجزئة IPFS لمدونتي على ENS. استهلكت الصفقة ما مجموعه 46924 غازًا، ويمكن تصنيفها على النحو التالي:

• التكلفة الأساسية : 21,000

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

• تنفيذ EVM: 24,368

• رمز التشغيل SLOAD: 6,400

• رمز تشغيل SSTORE: 10,100

• رمز تشغيل السجل: 2,149

• أخرى: 6,719



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

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

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

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



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

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

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

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

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



مخطط من وثائق RiscZero

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

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

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

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



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

< / p>

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

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

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

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

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

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

EVM

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

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



تحسين التخزين في مقترح شجرة Ethereum Verkle، ووضع مفاتيح التخزين المتجاورة معًا وتعديل تكاليف الغاز لتعكس ذلك. قد تكون تحسينات مثل هذه، إلى جانب الترجمة المسبقة الأفضل، أكثر أهمية من ضبط 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-SNARKs، وتقليل التعقيد في الأجهزة الافتراضية. تاريخياً، أدى السعي لتحقيق الكفاءة إلى تراجع هذه العوامل الأخرى. مع بنية الغراء والمعالج المساعد، لم تعد هناك حاجة إليها. يعمل جزء واحد من الماكينة على تحسين الكفاءة، بينما يعمل جزء آخر على تحسين تعدد الاستخدامات والقيم الأخرى، ويعمل الاثنان معًا.

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

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