نموذج العقد الذكي Starknet وAA الأصلي: عملاق التكنولوجيا المنشق

المؤلف: شو وفاوست، مهووس الويب 3

الملخص

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

• Cairo هي لغة ZK عالمية يمكن استخدامها لتنفيذ العقود الذكية على Starknet ولتطوير المزيد من التطبيقات التقليدية. تقديم Sierra كلغة برمجة تسمح اللغة الوسيطة في عملية التجميع لـCairo بالتكرار بشكل متكرر دون الحاجة إلى تغيير أدنى رمز بايت، وتحتاج فقط إلى نقل التغييرات إلى اللغة الوسيطة؛ وفي مكتبة القاهرة القياسية، يتم أيضًا تضمين الحسابات العديد من هياكل البيانات الأساسية مطلوب للتجريد.

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

< li>< p>يساعد نموذج العقد الذكي المذكور أعلاه لـ Starknet على إعادة استخدام التعليمات البرمجية، وإعادة استخدام حالة العقد، وتقسيم طبقات التخزين، واكتشاف العقود غير المرغوب فيها. كما أنه يفضي إلى تحقيق تأجير التخزين وموازاة المعاملات. وعلى الرغم من أن الخيارين الأخيرين لم يتم تنفيذهما بعد، إلا أن هيكل العقود الذكية في القاهرة قد خلق "الظروف الضرورية" لهما.

• لا يوجد سوى حسابات العقود الذكية في سلسلة Starknet، ولا توجد حسابات EOA. وهو يدعم تجريد حساب AA على المستوى الأصلي من البداية. وتستوعب خطة AA الخاصة بها أفكار ERC-4337 إلى حد ما، مما يسمح للمستخدمين باختيار حلول معالجة المعاملات المخصصة للغاية. من أجل منع سيناريوهات الهجوم المحتملة، اتخذت Starknet العديد من الإجراءات المضادة وأجرت استكشافات مهمة في النظام البيئي AA.

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

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

ولكن بغض النظر عن هذه الأمور التافهة، القائمة على "الذوق الفني" البحت لمهوسي البرمجة، فإن Starknet وStarkEx، أحد رواد ZK Rollup، يكاد يكونان بمثابة كنوز في عيون المتحمسين للقاهرة. في البعض في أذهان مطوري الألعاب ذات السلسلة الكاملة، Starknet وCairo هما ببساطة كل شيء في web3، ولا يمكن مقارنة Solidity أو Move بهما. تُعزى الفجوة الأكبر بين الأجيال بين "المهووسين بالتكنولوجيا" و"المستخدمين" اليوم في الواقع إلى افتقار الناس إلى الوعي بشبكة Starknet.

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

علم الحد الأدنى للغة القاهرة

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

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

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

من عملية التجميع، تستخدم القاهرة لغة وسيطة تعتمد على طريقة التجميع كما هو موضح في الشكل أدناه. سييرا في الصورة هي نموذج متوسط ​​(IR) في عملية تجميع لغة القاهرة، وسيتم تجميع سييرا في نموذج كود ثنائي ذي مستوى أدنى، يسمى CASM، والذي يعمل مباشرة على جهاز عقدة Starknet.

تقديم Sierra كنموذج وسيط لتسهيل إضافة ميزات جديدة إلى لغة القاهرة. في كثير من الحالات، نحتاج فقط إلى التعامل مع لغة Sierra المتوسطة دون تغيير كود CASM الأساسي مباشرةً، وهذا يوفر الكثير من المتاعب ولا يحتاج عميل عقدة Starknet إلى التحديث بشكل متكرر. وبهذه الطريقة، يمكن تحقيق التكرارات المتكررة للغة القاهرة دون تغيير المنطق الأساسي لـ StarkNet. تتضمن مكتبة القاهرة القياسية أيضًا العديد من هياكل البيانات الأساسية المطلوبة لتجريد الحساب.

تتضمن ابتكارات القاهرة الأخرى حلاً نظريًا يُسمى "Cairo Native"، والذي يخطط لتجميع القاهرة في كود آلي منخفض المستوى يمكن أن يتكيف مع الأجهزة المختلفة، ويتم تشغيل عقد Starknet عند كتابة العقود الذكية ، ليست هناك حاجة للاعتماد على الجهاز الظاهريCairoVM، والذي يمكنه تحسين سرعة تنفيذ التعليمات البرمجية بشكل كبير [لا يزال في المرحلة النظرية ولم يتم تنفيذه بعد].

نموذج العقد الذكي Starknet: فصل منطق الكود وتخزين الحالة< /strong>

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

1. بعد أن يكتب المطور العقد الذكي محليًا، يقوم بتجميع برنامج Solidity في رمز بايت EVM من خلال المحرر، بحيث يمكن فهمه ومعالجته مباشرة بواسطة EVM؛

2. يبدأ المطور في نشر يقوم طلب المعاملة الخاص بالعقد الذكي بنشر الكود الثانوي EVM المترجم إلى سلسلة Ethereum.

(مصدر الصورة: not-satoshi.com)

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

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

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

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

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

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

بعد ذلك، يصدر موزع العقد معاملة "إعلان" لنشر كود CASM الثانوي للعقد ورمز Sierra الوسيط إلى السلسلة، المسماة فئة العقد.

(مصدر الصورة: موقع Starknet الرسمي)

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

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

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

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

1. ملائم لطبقات التخزين و"التخزين" تنفيذ "نظام التأجير"

يعني ما يسمى بطبقات التخزين أنه يمكن للمطورين وضع البيانات في مواقع مخصصة وفقًا لاحتياجاتهم الخاصة، مثل سلسلة Starknet. StarkNet جاهز للتوافق مع طبقات DA مثل Celestia، ويمكن لمطوري DAPP تخزين البيانات في طبقات DA الخارجية هذه. على سبيل المثال، يمكن للعبة تخزين بيانات أصولها الأكثر أهمية على شبكة Starknet الرئيسية، وتخزين البيانات الأخرى في طبقات DA خارج السلسلة مثل Celestia. تم تسمية هذا الحل لتخصيص طبقة DA وفقًا لمتطلبات الأمان باسم "Volition" بواسطة Starknet.

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

في نموذج العقد الذكي لـ Ethereum، تكون ملكية العقد غير واضحة، ومن الصعب التمييز بين ما إذا كان يجب على الناشر أو صاحب الأصل دفع "الإيجار" مقابل عقد ERC-20، لم يتم إطلاق وظيفة تأجير التخزين لفترة طويلة، ولا يتم فرض رسوم على الناشر إلا عند نشر العقد، ونموذج رسوم التخزين هذا غير معقول.

2. تحقيق إعادة الاستخدام الحقيقي للتعليمات البرمجية وتقليل نشر العقود غير المرغوب فيها

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

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

3. إعادة استخدام "حالة" العقد الحقيقي

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

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

(مصدر الصورة: wtf Academy)

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

4. ملائم للمعالجة المتوازية للمعاملات

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

AA الأصلي لـ Starknet ونشر عقد الحساب

في الواقع، ما يسمى بتجريد الحساب و AA هما اختراعان فريدان اخترعتهما Ethereum مفهوم المجتمع، في العديد من السلاسل العامة الجديدة، لا يوجد تمييز بين حسابات EOA وحسابات العقود الذكية، مما يؤدي إلى تجنب مخاطر نظام الحسابات على غرار Ethereum من البداية. على سبيل المثال، في ظل إعداد Ethereum، يجب أن يكون لدى وحدة التحكم في حساب EOA ETH على السلسلة قبل أن يتمكن من بدء المعاملة، ولا توجد طريقة لاختيار مجموعة متنوعة من طرق المصادقة مباشرة، كما أن إضافة بعض منطق الدفع المخصص أمر مزعج للغاية. . حتى أن بعض الناس يعتقدون أن تصميم حساب Ethereum هو ببساطة معادٍ للإنسان.

إذا نظرنا إلى سلاسل مثل Starknet أو zkSyncEra التي تركز على "AA الأصلي"، فيمكننا ملاحظة اختلافات واضحة: أولاً، Starknet وzkSyncEra لهما أنواع حسابات موحدة لا يوجد سوى حسابات العقود الذكية في السلسلة، ولا يوجد شيء مثل حساب EOA من البداية (سوف يقوم zkSync Era بنشر مجموعة من رموز العقود افتراضيًا على حساب المستخدم الذي تم إنشاؤه حديثًا لمحاكاة خصائص Ethereum EOA الحساب، لذلك فهو ملائم للتوافق مع Metamask).

ولم تفكر Starknet في التوافق المباشر مع مرافق Ethereum الطرفية مثل Metamask،< strong> عندما يستخدم المستخدم محفظة Starknet لأول مرة، سيتم نشر حساب عقد مخصص تلقائيًا. وبصراحة، يتم نشر مثيل العقد المذكور أعلاه. سيتم ربط مثيل العقد هذا بـ تم نشر فئة العقد مسبقًا بواسطة مشروع المحفظة ويمكن استدعاؤها مباشرة لبعض الوظائف المكتوبة في الفصل.

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

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

pedersen() في الصيغة أعلاه عبارة عن خوارزمية تجزئة سهلة الاستخدام في نظام ZK. عملية إنشاء الحساب هي في الواقع إعطاء وظيفة pedersen Enter عدة معلمات خاصة لإنشاء التجزئة المقابلة، وهذا التجزئة هو عنوان الحساب الذي تم إنشاؤه.

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

يستخدم الملح لحساب قيمة الملح لعنوان العقد. ببساطة، هو رقم عشوائي. تم تقديم هذا المتغير فعليًا لتجنب ازدواجية عناوين العقد. class_hash هي قيمة التجزئة للفئة المقابلة لمثيل العقد كما تم تقديمه سابقًا. ويمثل buildor_calldata_hash تجزئة معلمات تهيئة العقد.

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

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

2. بعد أن يعرف المستخدم المكان الذي سينشر فيه العقد، يقوم أولاً يقوم بتحويل مبلغ معين من ETH إلى العنوان كرسوم نشر العقد. بشكل عام، يجب عبور هذا الجزء من ETH من L1 إلى شبكة Starknet من خلال جسر عبر السلسلة؛

3. يبدأ المستخدم طلب معاملة لنشر العقد.

في الواقع، يتم نشر جميع حسابات Starknet من خلال العملية المذكورة أعلاه، ولكن معظم المحافظ تحمي التفاصيل، ولا يمكن للمستخدمين إدراك العملية على الإطلاق، كما لو أنه بعد نقل ETH بنفسك، سيتم نشر حساب العقد.

يجلب الحل أعلاه بعض مشكلات التوافق لأن المحافظ المختلفة تنشأ عند إدخال عناوين الحساب ، النتائج التي تم إنشاؤها غير متسقة. يمكن خلط المحافظ التي تستوفي الشروط التالية فقط:

1. < p>المفتاح العام المشتق من المفتاح الخاص الذي تستخدمه المحفظة هو نفس خوارزمية التوقيع؛

2. عملية حساب الملح للمحفظة هي نفسها؛

   < /li>
3. < p>لا تختلف فئات العقد الذكي للمحفظة اختلافًا جوهريًا في تفاصيل التنفيذ؛

في الحالات المذكورة سابقًا، تم استخدام كل من Argent وBraavos خوارزمية توقيع ECDSA، لكن طرق حساب الملح لكلا الطرفين مختلفة، وستكون عناوين الحساب التي تم إنشاؤها بواسطة نفس العبارة التذكيرية في المحفظتين غير متسقة.

دعونا نعود إلى موضوع تجريد الحساب. لقد نقلت Starknet وzkSync Era سلسلة من العمليات المتضمنة في عملية معالجة المعاملات، مثل التحقق من الهوية (التحقق من التوقيعات الرقمية)، ودفع رسوم الغاز والمنطق الأساسي الآخر، ليتم تنفيذها خارج "الطبقة السفلية للسلسلة" ". يمكن للمستخدمين تخصيص تفاصيل تنفيذ المنطق أعلاه في حساباتهم الخاصة.

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

في تصميم Ethereum، يتم ترميز المنطق مثل التحقق من الهوية (التوقيع الرقمي) في رمز عميل العقدة ولا يمكنه دعم تخصيص وظائف الحساب أصلاً.

(رسم تخطيطي لحل AA الأصلي المحدد من قبل مهندس Starknet. يتم نقل التحقق من المعاملات والتحقق من أهلية رسوم الغاز إلى العقد الموجود على السلسلة للمعالجة. يمكن للآلة الافتراضية الأساسية للسلسلة استدعاء هذه الوظائف مخصصة أو محددة من قبل المستخدم. )

وفقًا لمسؤولي zkSyncEra وStarknet، تعتمد هذه المجموعة من أفكار وحدة وظائف الحساب على EIP-4337. لكن الفرق هو أن zkSync وStarknet قد دمجتا أنواع الحسابات منذ البداية، ووحدتا أنواع المعاملات، واستخدمتا مدخلًا موحدًا لتلقي ومعالجة جميع المعاملات. يحتوي Ethereum على أمتعة تاريخية وأساس نأمل أن نتجنبه الخطط التكرارية التقريبية مثل الهارد فورك قدر الإمكان، لذلك نحن ندعم خطة "منحنى لإنقاذ البلاد" مثل EIP-4337. ومع ذلك، فإن التأثير هو أن حساب EOA وخطة 4337 يعتمد كل منهما عمليات معالجة معاملات مستقلة. ، يبدو محرجًا ومنتفخًا، وليس مرنًا مثل AA الأصلي.

(مصدر الصورة: ArgentWallet)

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

نظرًا لوجود حسابات العقود الذكية فقط في Starknet، يتم أخذ تأثير العقد الذكي للحساب في الاعتبار في عملية المعاملة بأكملها. أولاً، بعد استلام المعاملة من خلال تجمع الذاكرة الخاص بعقدة Starknet (Mempool)، يجب التحقق منها، وتتضمن خطوات التحقق ما يلي:

1. سواء كان التوقيع الرقمي للمعاملة صحيحًا، فسيتم استدعاء وظيفة التحقق من التوقيع المخصص في حساب بادئ المعاملة؛

2. هل يمكن دفع رصيد حساب بادئ المعاملة تحمل رسوم الغاز؛

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

ولتجنب هذا الموقف، فرضت StarkNet القيود التالية على المعاملات:

1. هناك حد أعلى لعدد المعاملات التي يمكن لمستخدم واحد أن يبدأها خلال وحدة زمنية؛

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

المخطط الانسيابي لمعاملات Starknet هو كما يلي:

من الجدير بالذكر أنه من أجل زيادة تسريع عملية التحقق من المعاملات، يتم تنفيذ خوارزميات التحقق من التوقيع لمحفظتي Braavos وArgent مباشرة في Starknet عميل العقدة، عندما تكتشف العقدة أن معاملة تم إنشاؤها من محفظتي Starknet الرئيسيتين هاتين، فإنها ستستدعي خوارزمية توقيع Braavos/Argent التي تأتي مع العميل، ومن خلال هذه الفكرة الشبيهة بالتخزين المؤقت، يمكن لـ Starknet تقصير المعاملة وقت التحقق.

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

ولكن إذا فهم القراء تاريخ Starknet، فسوف يجدون أن Starknet المبكرة لم تفرض رسوم معالجة على المعاملات الفاشلة. الموقف الأكثر شيوعًا لفشل المعاملات هو أن المستخدم فقط لديه أموال 1ETH، ولكن تحويل 10 ETH للخارج.من الواضح أن هذه المعاملة بها خطأ منطقي وستفشل في النهاية، لكن لا أحد يعرف النتيجة قبل تنفيذها.

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

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

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

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

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

على سبيل المثال، في حالة وجود مقطع التعليمات البرمجية التالي:

قد يُبلغ _balances::read(from)-amount هنا عن خطأ بسبب التدفق الناقص، في هذا الوقت، ستتم مقاطعة تعليمات المعاملة المقابلة وإيقافها، ولن يتم ترك نتائج المعاملة في السلسلة؛ وإذا تمت إعادة كتابتها في النموذج التالي، فسيتم إرجاع نتيجة الإخراج عندما تفشل المعاملة وتبقى في السلسلة.من وجهة نظر مرئية بحتة، يبدو الأمر كما لو أن جميع المعاملات يمكن أن تترك مخرجات المعاملة بنجاح السلسلة، ومن المعقول بشكل خاص فرض رسوم مناولة موحدة.

نظرة عامة على عقد StarknetAA

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

يتم استخدام __validate_declare__ في الواجهة أعلاه للتحقق من المعاملات المعلنة التي بدأها المستخدمون، بينما يتم استخدام __validate__ للتحقق من المعاملات العامة، وبشكل أساسي للتحقق مما إذا كان توقيع المستخدم صحيح، ويتم استخدام __execute__ لتنفيذ المعاملة. يمكننا أن نرى أن حسابات عقود Starknet تدعم المكالمات المتعددة بشكل افتراضي. يمكن أن تحقق الاستدعاءات المتعددة بعض الوظائف المثيرة للاهتمام للغاية، مثل تجميع المعاملات الثلاث التالية عند إجراء تفاعلات DeFi معينة:

1. تسمح المعاملة الأولى بالرمز المميز لعقد DeFi

2. تؤدي المعاملة الثانية إلى تشغيل منطق عقد DeFi

< li>< p>تقوم المعاملة الثالثة بمسح التفويض لعقد DeFi

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

الملخص

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

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

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

• نموذج العقد الذكي أعلاه لـ Starknet يساعد على إعادة استخدام التعليمات البرمجية، كما أن إعادة استخدام حالة العقد وتقسيم طبقات التخزين والكشف عن العقود غير المرغوب فيها تساعد أيضًا على تحقيق تأجير التخزين وموازاة المعاملات. وعلى الرغم من أن الخيارين الأخيرين لم يتم تنفيذهما بعد، إلا أن هيكل العقود الذكية في القاهرة قد خلق "الظروف الضرورية" لهما.

• لا توجد سوى حسابات العقود الذكية في سلسلة Starknet، ولا توجد حسابات EOA، وقد تم دعم تجريد حساب AA على المستوى الأصلي منذ البداية. وتستوعب خطة AA الخاصة بها أفكار ERC-4337 إلى حد ما، مما يسمح للمستخدمين باختيار حلول معالجة المعاملات المخصصة للغاية. من أجل منع سيناريوهات الهجوم المحتملة، اتخذت Starknet العديد من الإجراءات المضادة وأجرت استكشافات مهمة في النظام البيئي AA.