تعمل الوظائف المضمنة على تحسين عملية الإثبات. ومع ذلك ، يتم حساب كل برهان من التخطيط. بالنسبة لأعمال إثبات معينة ، سيتم تقليل مزايا الوظائف المضمنة بشكل كبير إذا كان التخطيط غير فعال. توجد حاليًا قائمة صغيرة ثابتة من التخطيطات ، ويتم حساب كل برهان بناءً على التخطيط الأكثر ملاءمة من تلك القائمة. هذه الطريقة في تخطيط القوائم الثابتة لها عيبان. أولاً ، هناك مجموعة محدودة من التخطيطات. هذا غير فعال لمعظم أعمال الإثبات ويخلق آليات رسوم معقدة تفرض تكاليف غير ضرورية على المستخدمين. ثانيًا ، من الصعب الاحتفاظ بالقائمة يدويًا. بمجرد أن يصبح عدد البنايات مرتفعًا جدًا ، تصبح الصيانة اليدوية صعبة ويمكن أن تعيق فعليًا عملية إثبات الهياكل المبنية الفعالة التي تدعم عددًا كبيرًا من الفروق الدقيقة. لمعالجة هذه المشكلات ، يقوم فريق StarkWare بتطوير نظام تخطيط ديناميكي حيث تكون التخطيطات مخصصة لكل إثبات عمل.
تسهل حزمة Cairo Stack الحوسبة للأغراض العامة بشكل يمكن إثباته عن طريق تجميع كود Cairo في تعليمات لبنيات وحدة المعالجة المركزية الصديقة لـ STARK: جهاز Cairo VM (يشار إليه فيما بعد باسم CVM). تأتي العديد من مزايا وحدات المعالجة المركزية للأغراض العامة بتكلفة متأصلة ، ولا يتم تحسين CVM لبعض العمليات الشائعة. تعد وظائف Keccak و Pedersen و Poseidon hash شائعة مثل عمليات المنحنى البيضاوي وفحص النطاق (أي التحقق مما إذا كان رقم معين ضمن نطاق معين من القيم) وغيرها.
لمعالجة عدم الكفاءة النسبية لـ CVMs ، يقدم Cairo Stack مفهوم العناصر المدمجة للعمليات الحرجة: المكونات الإضافية التي تعمل على تحسين مثل هذه العمليات لإثبات التعقيد. يمكن مقارنة الوظائف المضمنة بـ ASICs: ASICs هي دوائر متكاملة خاصة بالتطبيق ، والوظائف المضمنة هي قيود جبرية خاصة بالتطبيق (AIR). إذا كنت لا تعرف ما هو AIR أو لا تتذكره ، فسيتم تناوله بإيجاز لاحقًا في هذه المقالة ؛ اقرأ هذه المقالة لمزيد من التفاصيل.
باختصار ، يرتبط تعقيد الإثبات (خطي تقريبًا) بموارد تسمى وحدات التتبع ، وتعمل الوظائف المضمنة على تبسيط البراهين لعمليات معينة باستخدام وحدات تتبع أقل بكثير من Cairo VM.
الآن بعد أن تم شرح فوائد الوظائف المضمنة ، أصبح من الواضح لماذا تم تطوير الوظائف المضمنة للعديد من العمليات المشتركة. القول اسهل من الفعل. تتكون العملية الحالية لإدخال عناصر مدمجة جديدة في Starknet من الخطوات التالية:
الكتابة AIR
تكامل مع المُثبِت عن طريق إنشاء تخطيط جديد (موضح أدناه)
الاندماج في Starknet ، أي تعديل قاعدة التعليمات البرمجية وأدوات المطور لاستخدام وظائف مضمنة جديدة
بالإضافة إلى تحديات كتابة AIR ، هناك مجال كبير للتحسين في المرحلتين المتبقيتين. ستصف هذه المقالة المتقدمة بمزيد من التفصيل وظائف AIR المضمنة مثل التطبيقات الخاصة ، والقضايا المذكورة أعلاه ، والخطط المستقبلية.
الوظائف المدمجة: AIR خاص بالتطبيق
AIR هو اختصار للتمثيل الوسيط الجبري. في هذا المقال وغيره من مقالات StarkWare ، يعد AIR نظامًا متعدد الحدود يمثل الأجهزة الافتراضية. على سبيل المثال ، أخذت القاهرة اسمها من CPU AIR: نظام متعدد الحدود يمثل بنية وحدة معالجة مركزية معينة. تمثل حلول هذا النظام متعدد الحدود انتقالات فعالة للحالة ، تسمى مسارات التنفيذ الجبرية الفعالة (AETs).
يثبت STARK أن تشغيل الجهاز الظاهري صحيح من خلال إثبات صحة مسار التنفيذ المطابق لـ AIR معين. بشكل تقريبي ، مسار التنفيذ هو جدول أرقام ، ويثبت بروتوكول STARK أن هذه الأرقام معًا تحل نظامًا متعدد الحدود.
يمكن حساب نفس العملية بعدة طرق ، بعضها أكثر كفاءة. في هذه الورقة ، يعتمد تعقيد الإثبات بشكل أساسي على حجم المسار ، أي عدد خلايا المسار في الجدول. نظرًا لأنه يتم إنشاء التتبع لـ AIR ، تم تصميم AIR للتطبيقات لتقليل آثار التنفيذ بشكل كبير لحسابات محددة. الوظائف المدمجة هي وظائف AIR متخصصة ومحسّنة للتطبيق.
يوضح الجدول أدناه تحسينات الكفاءة لوظائف مضمنة محددة (كلها في الإنتاج).
كما ذكرنا سابقًا ، AET عبارة عن جدول تقريبًا للأرقام يمثل ترتيب الخطوات في الجهاز الظاهري المشفر (أي تنفيذ البرنامج). لحساب الإثبات ، يقوم المُثبِّت بتشغيل بروتوكول STARK على مسار تنفيذ AIR المرتبط.
أعلاه ، قدمنا وظائف مدمجة مثل AIR الخاص بالتطبيق المصمم لتقليل تعقيد البراهين عن طريق تقليل عدد وحدات التتبع المطلوبة لتشفير العمليات الحسابية. ومع ذلك ، إذا تم دمج الوظائف المدمجة بشكل عشوائي في Starknet ، فقد يتم إهدار العديد من وحدات المسار ، وسيتم تقليل الفوائد المتوقعة. دعنا نوضح بالتفصيل أدناه.
باختصار ، تخطيط المسار هو تعيين خلايا المسار إلى "مكونات" مختلفة. في هذه المقالة ، هذه المكونات هي CVM والوظائف المضمنة. على وجه التحديد ، يحدد التخطيط العدد النسبي لخلايا المسار التي يحصل عليها كل مكون. (تُستخدم تركيبات التخطيط دائمًا لتبسيط عملية التحقق. لمعرفة المزيد ، اقرأ قسم "البساطة" في هذا المنشور).
النقطة الأساسية هي أن تعقيد الإثبات يعتمد على العدد الإجمالي لخلايا المسار المخصصة بواسطة التخطيط ، وقد يكون تخصيص خلية المسار أكبر مما هو مطلوب بالفعل. على سبيل المثال ، لتوضيح الترتيب التدريجي لـ CVMs ، يكون التخطيط الذي يعيّن فقط خلايا التتبع لمكونات CVM ضعف كفاءة التخطيط الذي يعين نصف خلايا التتبع لوظائف Poseidon المضمنة. في الختام ، يمكن أن يقلل التخطيط المناسب بشكل كبير من تعقيد إثبات عملية حسابية معينة.
توجد حاليًا قائمة تخطيطات يتم الاحتفاظ بها يدويًا والتي تنمو بمرور الوقت لسببين رئيسيين:
لا يمكن استخدام الوظائف المدمجة إلا لتخطيط وحدة المسار المخصصة لها. لذلك ، تتطلب إضافة عناصر مدمجة تخطيطًا جديدًا على الأقل.
التخطيط المصمم لتنفيذ كود القاهرة يحسن تخصيص الخلايا. لذلك ، غالبًا ما يتطلب تحسين حالات الاستخدام في الخلايا تخطيطات جديدة.
تم تكوين كود المُثبِت والمدقق (Solidity and Cairo validators) وفقًا لقائمة التخطيط.
مع إضافة بنايات Keccak و Poseidon ، أصبح من الصعب بشكل متزايد الاحتفاظ بقوائم التخطيط صغيرة بما يكفي لاستيعاب العديد من المباني والحفاظ على تنفيذ معظم كتل Starknet بكفاءة. علاوة على ذلك ، من المتوقع أن تنخفض الكفاءة بشكل كبير مع إدخال عناصر مدمجة إضافية ، نظرًا لأن التخطيط يجب أن يأخذ في الاعتبار العديد من التركيبات والنسب الممكنة بين العناصر المضمنة.
يعمل فريق StarkWare حاليًا على تحسين النظام عن طريق التخلص من قوائم التخطيط المعدة مسبقًا لصالح "التخطيطات الديناميكية" ، والتي تعد تخصيصات فورية لكل تنفيذ لكود القاهرة. سيقوم التخطيط الديناميكي دائمًا بأفضل تخصيص تناسبي لوظيفة التحقق في متناول اليد. من وجهة نظر هندسية ، قد يتطلب دعم الكتابة الديناميكية تغييرات كبيرة في قاعدة الكود. ومع ذلك ، يأمل فريق StarkWare في تبسيط طبقة الإثبات الخاصة بـ Starknet من خلال الاستفادة من التخطيط الديناميكي ، واستخدام وحدة المسار المحسن ، والاستفادة بشكل أفضل من المحفزات.
مع التخطيطات الديناميكية ، تختفي متاعب الصيانة اليدوية للعديد من المكونات الإضافية ، مما يبسط عملية دمج المزيد من العناصر المدمجة الجديدة في Starknet.
التصميم الديناميكي والرسوم
يتمثل أحد أغراض رسوم المعاملات في تحميل المستخدمين تكلفة البروتوكول الهامشية التي تتكبدها المعاملات. نظرًا لأن وحدة رسوم المعاملة هي العملة ، فإن آلية الرسوم تتضمن التحويل من الموارد (على سبيل المثال ، خطوات الآلة الافتراضية ، والوظائف المضمنة ، وبيانات الاتصال ، وغاز Ethereum) إلى الرموز المميزة (على سبيل المثال ، STRK ، ETH).
حاليًا ، نظرًا لأن المحاضر يفرض رسومًا على أساس إجمالي التتبع بدلاً من نسب الاستخدام ، يتحمل المستخدمون الموارد المهدرة. سيعمل التخطيط الديناميكي على تحسين استخدام وحدة التتبع ، وبالتالي تقليل فرض رسوم المعاملات "غير الضرورية" (بما في ذلك استهلاك الموارد غير الناجم مباشرة عن معاملات المستخدم).
تكامل الوظائف المضمنة في Starknet
في هذه المرحلة ، يكون تكامل الوظائف المدمجة أقل من الخطوة الأخيرة ، وهي تعديل قاعدة كود Starknet لتحقيق الاستخدام العملي. يرتبط مدى تعديل الكود بتطبيق التخطيط ، ومن الضروري تعديل الكود للتأكد من أن نظام التشغيل Starknet يستدعي الوظائف المدمجة عندما يكون ذلك ممكنًا. على سبيل المثال ، يستدعي نظام التشغيل Starknet وظيفة تجزئة بوسيدون أثناء تنفيذ كود القاهرة ، وفي نفس الوقت يستدعي وظيفة بوسيدون المدمجة.
على غرار التنسيقات ، يمكن الآن دعم مدمجة Starknet يدويًا. ومع ذلك ، على عكس حالة التخطيط ، لا يمثل هذا الدعم اليدوي عائقًا أمام التكامل على الرغم من وجود العديد من الوظائف المضمنة. بمعنى آخر ، دعم Starknet المبني ليس عائقًا أمام التكامل ، فالتخطيط الديناميكي سيمهد حقًا الطريق لإنشاء ودمج بنى إضافية.
لخص
في هذه المقالة نشرح ما هي الوظائف المضمنة ، وفوائدها ، والتحديات التي تنطوي عليها ، وخطط StarkWare. ينصب التركيز الحالي على التخطيط الديناميكي ، والذي لن يؤدي فقط إلى تحسين كفاءة عملية الإثبات ، بل سيسهل أيضًا تكامل العناصر المضمنة الجديدة.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
مزايا وتحديات وظائف Starknet المدمجة
الأصل: المدمج والتخطيطات الديناميكية
الترجمة والتدقيق اللغوي: "مجتمع StarkNet الصيني"
! [فوائد وتحديات وظائف Starknet المضمنة] (https://img.gateio.im/social/moments-69a80767fe-9b43317f1c-dd1a6f-e5a980)
ملخص
تعمل الوظائف المضمنة على تحسين عملية الإثبات. ومع ذلك ، يتم حساب كل برهان من التخطيط. بالنسبة لأعمال إثبات معينة ، سيتم تقليل مزايا الوظائف المضمنة بشكل كبير إذا كان التخطيط غير فعال. توجد حاليًا قائمة صغيرة ثابتة من التخطيطات ، ويتم حساب كل برهان بناءً على التخطيط الأكثر ملاءمة من تلك القائمة. هذه الطريقة في تخطيط القوائم الثابتة لها عيبان. أولاً ، هناك مجموعة محدودة من التخطيطات. هذا غير فعال لمعظم أعمال الإثبات ويخلق آليات رسوم معقدة تفرض تكاليف غير ضرورية على المستخدمين. ثانيًا ، من الصعب الاحتفاظ بالقائمة يدويًا. بمجرد أن يصبح عدد البنايات مرتفعًا جدًا ، تصبح الصيانة اليدوية صعبة ويمكن أن تعيق فعليًا عملية إثبات الهياكل المبنية الفعالة التي تدعم عددًا كبيرًا من الفروق الدقيقة. لمعالجة هذه المشكلات ، يقوم فريق StarkWare بتطوير نظام تخطيط ديناميكي حيث تكون التخطيطات مخصصة لكل إثبات عمل.
تسهل حزمة Cairo Stack الحوسبة للأغراض العامة بشكل يمكن إثباته عن طريق تجميع كود Cairo في تعليمات لبنيات وحدة المعالجة المركزية الصديقة لـ STARK: جهاز Cairo VM (يشار إليه فيما بعد باسم CVM). تأتي العديد من مزايا وحدات المعالجة المركزية للأغراض العامة بتكلفة متأصلة ، ولا يتم تحسين CVM لبعض العمليات الشائعة. تعد وظائف Keccak و Pedersen و Poseidon hash شائعة مثل عمليات المنحنى البيضاوي وفحص النطاق (أي التحقق مما إذا كان رقم معين ضمن نطاق معين من القيم) وغيرها.
لمعالجة عدم الكفاءة النسبية لـ CVMs ، يقدم Cairo Stack مفهوم العناصر المدمجة للعمليات الحرجة: المكونات الإضافية التي تعمل على تحسين مثل هذه العمليات لإثبات التعقيد. يمكن مقارنة الوظائف المضمنة بـ ASICs: ASICs هي دوائر متكاملة خاصة بالتطبيق ، والوظائف المضمنة هي قيود جبرية خاصة بالتطبيق (AIR). إذا كنت لا تعرف ما هو AIR أو لا تتذكره ، فسيتم تناوله بإيجاز لاحقًا في هذه المقالة ؛ اقرأ هذه المقالة لمزيد من التفاصيل.
باختصار ، يرتبط تعقيد الإثبات (خطي تقريبًا) بموارد تسمى وحدات التتبع ، وتعمل الوظائف المضمنة على تبسيط البراهين لعمليات معينة باستخدام وحدات تتبع أقل بكثير من Cairo VM.
الآن بعد أن تم شرح فوائد الوظائف المضمنة ، أصبح من الواضح لماذا تم تطوير الوظائف المضمنة للعديد من العمليات المشتركة. القول اسهل من الفعل. تتكون العملية الحالية لإدخال عناصر مدمجة جديدة في Starknet من الخطوات التالية:
الكتابة AIR
تكامل مع المُثبِت عن طريق إنشاء تخطيط جديد (موضح أدناه)
الاندماج في Starknet ، أي تعديل قاعدة التعليمات البرمجية وأدوات المطور لاستخدام وظائف مضمنة جديدة
بالإضافة إلى تحديات كتابة AIR ، هناك مجال كبير للتحسين في المرحلتين المتبقيتين. ستصف هذه المقالة المتقدمة بمزيد من التفصيل وظائف AIR المضمنة مثل التطبيقات الخاصة ، والقضايا المذكورة أعلاه ، والخطط المستقبلية.
الوظائف المدمجة: AIR خاص بالتطبيق
AIR هو اختصار للتمثيل الوسيط الجبري. في هذا المقال وغيره من مقالات StarkWare ، يعد AIR نظامًا متعدد الحدود يمثل الأجهزة الافتراضية. على سبيل المثال ، أخذت القاهرة اسمها من CPU AIR: نظام متعدد الحدود يمثل بنية وحدة معالجة مركزية معينة. تمثل حلول هذا النظام متعدد الحدود انتقالات فعالة للحالة ، تسمى مسارات التنفيذ الجبرية الفعالة (AETs).
يثبت STARK أن تشغيل الجهاز الظاهري صحيح من خلال إثبات صحة مسار التنفيذ المطابق لـ AIR معين. بشكل تقريبي ، مسار التنفيذ هو جدول أرقام ، ويثبت بروتوكول STARK أن هذه الأرقام معًا تحل نظامًا متعدد الحدود.
يمكن حساب نفس العملية بعدة طرق ، بعضها أكثر كفاءة. في هذه الورقة ، يعتمد تعقيد الإثبات بشكل أساسي على حجم المسار ، أي عدد خلايا المسار في الجدول. نظرًا لأنه يتم إنشاء التتبع لـ AIR ، تم تصميم AIR للتطبيقات لتقليل آثار التنفيذ بشكل كبير لحسابات محددة. الوظائف المدمجة هي وظائف AIR متخصصة ومحسّنة للتطبيق.
يوضح الجدول أدناه تحسينات الكفاءة لوظائف مضمنة محددة (كلها في الإنتاج).
! [فوائد وتحديات وظائف Starknet المدمجة] (https://img.gateio.im/social/moments-69a80767fe-2ba605193b-dd1a6f-e5a980)
تخطيط المسار: الحاضر والمستقبل
كما ذكرنا سابقًا ، AET عبارة عن جدول تقريبًا للأرقام يمثل ترتيب الخطوات في الجهاز الظاهري المشفر (أي تنفيذ البرنامج). لحساب الإثبات ، يقوم المُثبِّت بتشغيل بروتوكول STARK على مسار تنفيذ AIR المرتبط.
أعلاه ، قدمنا وظائف مدمجة مثل AIR الخاص بالتطبيق المصمم لتقليل تعقيد البراهين عن طريق تقليل عدد وحدات التتبع المطلوبة لتشفير العمليات الحسابية. ومع ذلك ، إذا تم دمج الوظائف المدمجة بشكل عشوائي في Starknet ، فقد يتم إهدار العديد من وحدات المسار ، وسيتم تقليل الفوائد المتوقعة. دعنا نوضح بالتفصيل أدناه.
باختصار ، تخطيط المسار هو تعيين خلايا المسار إلى "مكونات" مختلفة. في هذه المقالة ، هذه المكونات هي CVM والوظائف المضمنة. على وجه التحديد ، يحدد التخطيط العدد النسبي لخلايا المسار التي يحصل عليها كل مكون. (تُستخدم تركيبات التخطيط دائمًا لتبسيط عملية التحقق. لمعرفة المزيد ، اقرأ قسم "البساطة" في هذا المنشور).
النقطة الأساسية هي أن تعقيد الإثبات يعتمد على العدد الإجمالي لخلايا المسار المخصصة بواسطة التخطيط ، وقد يكون تخصيص خلية المسار أكبر مما هو مطلوب بالفعل. على سبيل المثال ، لتوضيح الترتيب التدريجي لـ CVMs ، يكون التخطيط الذي يعيّن فقط خلايا التتبع لمكونات CVM ضعف كفاءة التخطيط الذي يعين نصف خلايا التتبع لوظائف Poseidon المضمنة. في الختام ، يمكن أن يقلل التخطيط المناسب بشكل كبير من تعقيد إثبات عملية حسابية معينة.
توجد حاليًا قائمة تخطيطات يتم الاحتفاظ بها يدويًا والتي تنمو بمرور الوقت لسببين رئيسيين:
لا يمكن استخدام الوظائف المدمجة إلا لتخطيط وحدة المسار المخصصة لها. لذلك ، تتطلب إضافة عناصر مدمجة تخطيطًا جديدًا على الأقل.
التخطيط المصمم لتنفيذ كود القاهرة يحسن تخصيص الخلايا. لذلك ، غالبًا ما يتطلب تحسين حالات الاستخدام في الخلايا تخطيطات جديدة.
تم تكوين كود المُثبِت والمدقق (Solidity and Cairo validators) وفقًا لقائمة التخطيط.
مع إضافة بنايات Keccak و Poseidon ، أصبح من الصعب بشكل متزايد الاحتفاظ بقوائم التخطيط صغيرة بما يكفي لاستيعاب العديد من المباني والحفاظ على تنفيذ معظم كتل Starknet بكفاءة. علاوة على ذلك ، من المتوقع أن تنخفض الكفاءة بشكل كبير مع إدخال عناصر مدمجة إضافية ، نظرًا لأن التخطيط يجب أن يأخذ في الاعتبار العديد من التركيبات والنسب الممكنة بين العناصر المضمنة.
يعمل فريق StarkWare حاليًا على تحسين النظام عن طريق التخلص من قوائم التخطيط المعدة مسبقًا لصالح "التخطيطات الديناميكية" ، والتي تعد تخصيصات فورية لكل تنفيذ لكود القاهرة. سيقوم التخطيط الديناميكي دائمًا بأفضل تخصيص تناسبي لوظيفة التحقق في متناول اليد. من وجهة نظر هندسية ، قد يتطلب دعم الكتابة الديناميكية تغييرات كبيرة في قاعدة الكود. ومع ذلك ، يأمل فريق StarkWare في تبسيط طبقة الإثبات الخاصة بـ Starknet من خلال الاستفادة من التخطيط الديناميكي ، واستخدام وحدة المسار المحسن ، والاستفادة بشكل أفضل من المحفزات.
مع التخطيطات الديناميكية ، تختفي متاعب الصيانة اليدوية للعديد من المكونات الإضافية ، مما يبسط عملية دمج المزيد من العناصر المدمجة الجديدة في Starknet.
التصميم الديناميكي والرسوم
يتمثل أحد أغراض رسوم المعاملات في تحميل المستخدمين تكلفة البروتوكول الهامشية التي تتكبدها المعاملات. نظرًا لأن وحدة رسوم المعاملة هي العملة ، فإن آلية الرسوم تتضمن التحويل من الموارد (على سبيل المثال ، خطوات الآلة الافتراضية ، والوظائف المضمنة ، وبيانات الاتصال ، وغاز Ethereum) إلى الرموز المميزة (على سبيل المثال ، STRK ، ETH).
حاليًا ، نظرًا لأن المحاضر يفرض رسومًا على أساس إجمالي التتبع بدلاً من نسب الاستخدام ، يتحمل المستخدمون الموارد المهدرة. سيعمل التخطيط الديناميكي على تحسين استخدام وحدة التتبع ، وبالتالي تقليل فرض رسوم المعاملات "غير الضرورية" (بما في ذلك استهلاك الموارد غير الناجم مباشرة عن معاملات المستخدم).
تكامل الوظائف المضمنة في Starknet
في هذه المرحلة ، يكون تكامل الوظائف المدمجة أقل من الخطوة الأخيرة ، وهي تعديل قاعدة كود Starknet لتحقيق الاستخدام العملي. يرتبط مدى تعديل الكود بتطبيق التخطيط ، ومن الضروري تعديل الكود للتأكد من أن نظام التشغيل Starknet يستدعي الوظائف المدمجة عندما يكون ذلك ممكنًا. على سبيل المثال ، يستدعي نظام التشغيل Starknet وظيفة تجزئة بوسيدون أثناء تنفيذ كود القاهرة ، وفي نفس الوقت يستدعي وظيفة بوسيدون المدمجة.
على غرار التنسيقات ، يمكن الآن دعم مدمجة Starknet يدويًا. ومع ذلك ، على عكس حالة التخطيط ، لا يمثل هذا الدعم اليدوي عائقًا أمام التكامل على الرغم من وجود العديد من الوظائف المضمنة. بمعنى آخر ، دعم Starknet المبني ليس عائقًا أمام التكامل ، فالتخطيط الديناميكي سيمهد حقًا الطريق لإنشاء ودمج بنى إضافية.
لخص
في هذه المقالة نشرح ما هي الوظائف المضمنة ، وفوائدها ، والتحديات التي تنطوي عليها ، وخطط StarkWare. ينصب التركيز الحالي على التخطيط الديناميكي ، والذي لن يؤدي فقط إلى تحسين كفاءة عملية الإثبات ، بل سيسهل أيضًا تكامل العناصر المضمنة الجديدة.