Forward the Original Title: تفسير نموذج عقد Starknet الذكي و AA الأصلي: عبقرية تقنية فريدة

المؤلفون الأصليون: شيو وفاوست، مستشارو Web3: CryptoNerdCn، مطوّر أساسي في Starknet، منصة تطوير Cairo على الجانب الخاص بالمتصفح مؤسس WASM Cairo

ملخص:

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

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

النص: بعد إصدار الرموز المميزة على Starknet ، أصبحت STRK تدريجيا عنصرا لا غنى عنه في نظر مراقبي Ethereum. هذه النجمة Ethereum Layer 2 ، المعروفة بموقفها "المستقل" و "تجاهل تجربة المستخدم" ، نحتت بهدوء أراضيها الخاصة في النظام البيئي المزدهر للطبقة 2 المتوافق مع EVM. نظرا لإهمالها المفرط للمستخدمين ، وحتى إنشاء قناة "متسول إلكتروني" علنا على Discord ، تعرض Starknet لانتقادات ذات مرة من قبل المجتمع. وسط اتهامات بأنها "غير إنسانية" ، بدا أن خبرتها الفنية العميقة قد تم التقليل من قيمتها على الفور ، كما لو أن تجربة المستخدم وخلق الثروة فقط هما كل شيء. السطر من "معبد الجناح الذهبي" - "حقيقة عدم فهمي من قبل الآخرين كان مصدر فخري الوحيد" - يكاد يكون صورة ذاتية لستاركنيت. ومع ذلك ، إذا وضعنا جانبا هذه الأمور التافهة في العالم ، استنادا إلى الذوق التقني لعشاق الكود ، فإن Starknet و StarkEx ، بصفتهما رائدين في ZK Rollup ، هما كنوز تقريبا في نظر عشاق القاهرة. في أذهان بعض مطوري ألعاب blockchain ، Starknet و Cairo هما ببساطة كل شيء في Web3 ، متجاوزين Solidity and Move. تعزى أكبر فجوة بين "المهووسين التقنيين" و "المستخدمين" اليوم إلى حد كبير إلى عدم فهم الناس ل Starknet. مدفوعا بالاهتمام بتكنولوجيا blockchain واستكشاف قيمة Starknet ، يبدأ مؤلف هذا المقال من نموذج العقد الذكي ل Starknet و AA الأصلي لتوضيح حلولها التقنية وتصميمات الآلية بإيجاز ، بهدف عرض ميزات Starknet التقنية لمزيد من الأشخاص ، بينما تأمل أيضا في مساعدة الناس على فهم هذا "الحارس الوحيد الذي يساء فهمه". بعد مقدمة موجزة للغة القاهرة في القسم التالي ، سنركز على مناقشة نموذج العقد الذكي ل Starknet وتجريد الحساب الأصلي ، موضحا كيف يحقق Starknet AA الأصلي. بعد قراءة هذا المقال ، سيفهم القراء أيضا سبب عدم خلط عبارات ذاكري من محافظ مختلفة في Starknet. ولكن قبل تقديم تجريد الحساب الأصلي ، دعنا أولا نفهم لغة القاهرة المبتكرة التي أنشأتها Starknet. في عملية تطوير القاهرة ، كانت هناك إصدارات مبكرة تسمى Cairo0 ، تليها النسخة الحديثة. يشبه التركيب العام للنسخة الحديثة من القاهرة Rust وهو في الواقع لغة ZK متعددة الاستخدامات. إلى جانب استخدامه لكتابة العقود الذكية على Starknet ، يمكن استخدامه أيضا لتطوير التطبيقات العامة. على سبيل المثال ، يمكننا تطوير نظام التحقق من الهوية ZK باستخدام لغة القاهرة ، ويمكن تشغيل هذا البرنامج على خادمنا الخاص دون الاعتماد على شبكة StarkNet. يمكن القول أن أي برنامج يتطلب خصائص حسابية يمكن التحقق منها يمكن تنفيذه باستخدام لغة القاهرة. وقد تكون القاهرة حاليا لغة البرمجة الأكثر ملاءمة لتوليد براهين ZK.

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

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

نموذج عقد Starknet الذكي: تجريد منطق الكود وتخزين الحالة

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

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

1. يقوم المطور ببدء معاملة لنشر العقد الذكي، نشر بيانات البايت للآر إلى سلسلة الكتل الإيثريوم.

المصدر: not-satoshi.com

على الرغم من أن عقود Starknet الذكية تتبع أيضًا فكرة "الترجمة أولاً ثم النشر"، إلا أن العقود الذكية يتم نشرها على السلسلة بصيغة بايت كود CASM المدعومة بواسطة CairoVM. ومع ذلك، هناك اختلافات كبيرة بين Starknet وسلاسل EVM-compatible في طريقة الاستدعاء ووضع تخزين حالة العقود الذكية. بالضبط، عقد Ethereum الذكي = منطق الأعمال + معلومات الحالة. على سبيل المثال، عقد USDT لا ينفذ فقط وظائف شائعة مثل النقل والموافقة، ولكنه أيضًا يخزن حالة الأصول لجميع حائزي USDT. الكود والحالة مرتبطان معًا، مما يسبب الكثير من المتاعب. أولاً وقبل كل شيء، فإن ذلك لا يسهل عملية ترقية عقد DAPP وهجرة الحالة، ولا يسهل معالجة المعاملات بشكل متوازٍ. إنه عبء تقني ثقيل.

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

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

(المصدر: موقع شبكة ستاركنت الرسمي)

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

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

1. ملائم لتحقيق تقسيم التخزين ونظام تأجير التخزين

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

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

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

تحت نماذج العقود الذكية لـ Starknet، Sui، CKB، و Solana، يكون تقسيم ملكية العقود الذكية أكثر وضوحًا، مما يجعل من الأسهل جمع أموال التخزين [حاليًا، لا يطلق Starknet نظام تأجير تخزين مباشرة، ولكن سيتم تنفيذه في المستقبل]

1. تحقيق إعادة استخدام الشيفرة الحقيقية وتقليل نشر العقود الزائدة

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

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

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

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

المصدر: أكاديمية واو

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

1. ملائم لمعالجة المعاملات بشكل متوازي

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

نشر الحساب العقد الذكي الأصلي لشبكة ستارك وحساب

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

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

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

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

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

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

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

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

1. المفتاح الخاص المشتق من المفتاح العام المستخدم من قبل المحفظة هو نفسه كخوارزمية التوقيع؛
2. عملية حساب الملح في المحفظة هي نفسها؛
3. ليست فئات عقد المحفظة مختلفة بشكل جوهري في تفاصيل التنفيذ؛ \

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

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

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

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

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

المصدر: ArgentWallet

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

1. التحقق مما إذا كان التوقيع الرقمي للمعاملة صحيحًا، في هذه النقطة يتم استدعاء وظيفة التحقق المخصصة لحساب الموقع؛
2. التحقق مما إذا كان رصيد حساب المبادر يمكن أن يغطي رسوم الغاز. \

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

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

يكون مخطط تدفق معاملات Starknet كما يلي:

تجدر الإشارة إلى أنه لزيادة تسريع عملية التحقق من المعاملات ، قام عميل عقدة Starknet بتنفيذ خوارزميات التحقق من التوقيع الخاصة بمحافظ Braavos و Argent مباشرة. عندما تكتشف العقدة المعاملات التي تم إنشاؤها من محفظتي Starknet الرئيسيتين الرئيسيتين ، فإنها ستستدعي خوارزميات توقيع Braavos / Argent المضمنة في العميل. من خلال هذا النهج الشبيه بالتخزين المؤقت ، يمكن ل Starknet تقصير وقت التحقق من المعاملة. بعد التحقق من صحة بيانات المعاملة بواسطة جهاز التسلسل (تكون خطوات التحقق الخاصة بجهاز التسلسل أكثر شمولا من خطوات تجمع الذاكرة) ، سيقوم جهاز التسلسل بحزم المعاملات وإرسالها من تجمع الذاكرة إلى مولد إثبات ZK. سيتم فرض رسوم الغاز على المعاملات التي تدخل هذه المرحلة حتى لو فشلت. ومع ذلك ، إذا كان القراء على دراية بتاريخ Starknet ، فسوف يلاحظون أن الإصدارات السابقة من Starknet لم تفرض رسوما على المعاملات الفاشلة. السيناريو الأكثر شيوعا لفشل المعاملة هو عندما يكون لدى المستخدم 1 ETH فقط ولكنه يحاول نقل 10 ETH خارجيا ، مما يشير بوضوح إلى وجود خطأ منطقي وسيفشل حتما ، ولكن لا أحد يعرف النتيجة قبل التنفيذ. ومع ذلك ، في الماضي ، لم تفرض StarkNet رسوما على مثل هذه المعاملات الفاشلة. تهدر هذه المعاملات الخاطئة المجانية الموارد الحسابية لعقدة Starknet ويمكن أن تؤدي إلى سيناريوهات هجوم DDoS. على السطح ، يبدو فرض رسوم على المعاملات الخاطئة واضحا ، لكنه في الواقع معقد للغاية. قدمت ستاركنت نسخة جديدة من لغة كايرو 1 إلى حد كبير لمعالجة قضية رسوم الغاز للمعاملات الفاشلة. كما نعلم جميعا ، فإن إثبات ZK هو دليل على الصلاحية ، ونتيجة المعاملة الفاشلة غير صالحة ولا يمكن أن تترك نتيجة إخراج على السلسلة. إن محاولة استخدام إثبات صحة لإثبات أن تنفيذ تعليمات معينة غير صالح ولا يمكن أن ينتج عنه نتائج مخرجات يبدو غريبا وغير عملي في الواقع. لذلك ، في الماضي ، استبعدت Starknet المعاملات الفاشلة التي لا يمكن أن تنتج نتائج مخرجات عند إنشاء البراهين. اعتمد فريق Starknet لاحقا حلا أكثر ذكاء وبنى لغة عقد جديدة ، Cairo1 ، والتي تضمن أن "جميع تعليمات المعاملات يمكن أن تؤدي إلى نتائج مخرجات وأن تكون على السلسلة". للوهلة الأولى ، حقيقة أن جميع المعاملات يمكن أن تنتج نتائج مخرجات تعني أن الأخطاء المنطقية لا تحدث أبدا. ومع ذلك ، في معظم الأحيان ، تفشل المعاملات لأنها تواجه أخطاء تقاطع تنفيذ التعليمات. من الصعب تحقيق ضمان عدم مقاطعة المعاملات أبدا وإنتاج نتائج المخرجات بنجاح ، ولكن هناك في الواقع حل بديل بسيط ، وهو السماح للمعاملات بإنتاج نتائج مخرجات عند مواجهة أخطاء منطقية تؤدي إلى الانقطاعات ، وإن كانت ترجع قيمة خاطئة تشير إلى أن تنفيذ المعاملة لم يكن سلسا. من المهم ملاحظة أن إرجاع قيمة False يرجع أيضا نتيجة مخرجات، مما يعني أنه في Cairo1، بغض النظر عما إذا كانت التعليمات تواجه خطأ منطقيا أو تمت مقاطعتها مؤقتا، يمكن أن تنتج نتائج مخرجات وتكون على السلسلة. يمكن أن تكون نتيجة الإخراج هذه صحيحة أو رسالة خطأ خاطئة. على سبيل المثال، ضع في اعتبارك مقتطف الشفرة التالي:

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

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

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

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

1. تفويض الرموز لعقد ديفي في المعاملة الأولى.
2. تنشيط منطق العقد DeFi في الصفقة الثانية.
3. سحب الإذن لعقد الديفي في المعاملة الثالثة.

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

ملخص

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

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

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

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

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

تنصل:

1. تم نقل هذه المقالة من [GateWeb3 الهواة]. *Forward the Original Title‘解读Starknet智能合约模型与原生AA：特立独行的技术巨匠’.All copyrights belong to the original author [Shew & Faust]. If there are objections to this reprint, please contact the بوابة تعلمالفريق، وسيتولون بذلك بسرعة.
2. تنصل المسؤولية: الآراء والآراء الواردة في هذه المقالة هي فقط تلك التي تعود إلى الكاتب ولا تشكل أي نصيحة استثمارية.
3. يتم إجراء ترجمات المقال إلى لغات أخرى من قبل فريق Gate Learn. ما لم يذكر، يُحظر نسخ أو توزيع أو نسخ المقالات المترجمة.