المؤلف: تشيهاولو (chihaolu.eth) المصدر: متوسطة الترجمة: شانوبا ، جولدن فاينانس

تركز هذه المقالة على تطوير تجريد الحساب (AA) في حل Aztec Layer 2 والمحتويات ذات الصلة. أستشهد بعدد من الموارد الرسمية للأزتك ، بما في ذلك الوثائق الرسمية والمدونات والبرامج التعليمية. يرجى العثور على هذه الموارد الممتازة في قسم المراجع في نهاية المقالة!

خلفية

نظرا لزيادة تعقيد Aztec مقارنة بتطبيقات Native AA الأخرى في ZK-Rollups ، قد يستفيد القراء من وجود بعض السياق لفهم هذه المقالة بشكل أفضل.

• الإلمام بمحافظ العقود الذكية وميزاتها
• الإلمام ب EIP-4337
• الإلمام بتجريد الحساب الأصلي في ZK-Rollups
• المفاهيم الأساسية UTXO
• المفهوم الأساسي ل ZK-Rollups
• المفاهيم الأساسية لبرامج إثبات المعرفة الصفرية

مقدمة

ألق نظرة سريعة على الأزتك

Aztec هي شبكة مفتوحة المصدر من الطبقة 2 مصممة لتوفير قابلية التوسع وحماية الخصوصية ل Ethereum. تستفيد Aztec من براهين zkSNARK لتوفير حماية الخصوصية وقابلية التوسع من خلال خدمة ZK-Rollup. لا يحتاج مستخدمو Aztec إلى أي أطراف ثالثة موثوقة أو آليات إجماع إضافية للوصول إلى المعاملات الخاصة.

نعلم جميعا أنه في ZK-Rollups التقليدية ، لا تعني كلمة “ZK” بالضرورة الخصوصية. وهذا يعني استخدام براهين المعرفة الصفرية (ZKPs) لإثبات أن بعض الحسابات قد تم إجراؤها بشكل صحيح خارج السلسلة. ومع ذلك ، في Aztec ، يتم تنفيذ الخصوصية في ZK-Rollup بالإضافة إلى قابلية التوسع. بالتعمق أكثر ، في الماضي ، كانت تفاصيل كل معاملة مرئية للجمهور على السلسلة ، ولكن في Aztec ، يتم تشفير مدخلات ومخرجات كل معاملة. يتم التحقق من هذه المعاملات بواسطة ZKP لإثبات أن المعلومات المشفرة دقيقة ونشأت في نص عادي. فقط المستخدم الذي ينشئ هذه المعاملات الخاصة يعرف معلومات النص العادي الفعلية.

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

كيفية تنفيذ المعاملات الخاصة وكيفية التحقق من أساسياتها هو موضوع كبير خارج نطاق هذه المقالة. بعبارات بسيطة ، ما نحتاجه هو “طبقة إضافية للتحقق من إثبات المعرفة الصفرية” للتحقق من صحة قوائم ZKP ، كل منها يتحقق من صحة معاملة خاصة. لهذا السبب يطلق عليهم “ZK-ZK-Rollups”.

ما هو نوير؟

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

Noir هي لغة لكتابة برامج SNARK ، على غرار Circcom و ZoKrates. فهو لا يسمح لك فقط بإنشاء عقود Solidity Verifier تلقائيا بعد إنشاء الدائرة ، ولكن يمكن استخدامه أيضا لكتابة البروتوكولات الخاصة بك أو حتى blockchains. نظرا لأن Noir لا يعتمد كليا على Aztec (لا يتم تجميعه إلى نظام إثبات محدد) ، يمكنك تحقيق أهدافك من خلال تنفيذ خادم خلفي وواجهة عقد ذكية لنظام الإثبات.

في Aztec ، يتم استخدام Noir لكتابة العقود الذكية حيث يمكن حماية المتغيرات (الحالات) والوظائف من خلال الخصوصية.

ما هي الحالة الخاصة والملاحظات الخاصة

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

يتم تخزين الحالة الخاصة عن طريق إرفاق شجرة قاعدة البيانات فقط. يتم ذلك لأن تغيير قيمة الحالة مباشرة يمكن أن يؤدي إلى تسرب الكثير من المعلومات من مخطط المعاملة. ومع ذلك ، لا تخزن قاعدة البيانات مباشرة قيمة الدولة الخاصة. بدلا من ذلك ، يسجلها كملاحظات خاصة في شكل مشفر (على سبيل المثال ، x = 0 -> x = 1) addr = 0x00 -> addr = 0x01. لذلك ، في الواقع ، هذه المتغيرات الخاصة ، بينما تبدو متغيرات ، تتكون في الواقع من مجموعة من الملاحظات الخاصة غير القابلة للتغيير. هذا هو تجريد المتغيرات. إذا لم يكن الأمر واضحا ، فلننتقل.

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

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

في هذه المرحلة ، ربما لاحظ القراء الأذكياء أن هذه البنية تشبه إلى حد كبير UTXOs (مخرجات المعاملات غير المنفقة) ، ويمكننا التكرار عبر UTXOs لتحديد الحالة الحالية للدولة الخاصة (على الرغم من أنه من المهم أن تتذكر أن المستخدم هو الذي يوقع المعاملة ، وليس UTXO ؛ سنشرح ذلك لاحقا).

! [TEg3TOpeZXF82AgjnmG7in3uwiZp3ZtIpGsNQvxc.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-2ad04801d9-dd1a6f-cd5cc0.webp “7128680”)

ما هي الملاحظة الخاصة؟ يطلق على UTXO اسم Note ، ونحن نجتاز شجرة الملاحظات هذه للحصول على معلومات حول الحالة الخاصة. عندما نريد تغيير الحالة الخاصة ، تكون الخطوات كما يلي:

1. يقوم المستخدم باسترداد جميع الملاحظات الخاصة المتعلقة بتلك الحالة الخاصة من قاعدة بيانات الملاحظات.
2. يشهد المستخدم (وهو في الواقع عقدة Aztec التي يديرها المستخدم) محليا على وجود كل تعليق توضيحي تم استرداده في شجرة قاعدة البيانات هذه.
3. يضيف المستخدم حرفا غير صالح لمنع الآخرين من قراءة نفس الورقة مرة أخرى.
4. يقوم المستخدم بإدراج صفحة جديدة (تعليق جديد) لتحديث قيمة هذه الحالة الخاصة.

آلية الأزتك AA

ما هي طبقة البروتوكول وما هي طبقة التطبيق؟

كما نعلم جميعا ، يهدف EIP-4337 إلى نقل عملية المعاملة بأكملها إلى طبقة التطبيق ، وتنفيذ نظام ترحيل مفتوح ، وتجريد التوقيع (آلية التحقق) ونموذج الدفع من خلال الطبيعة القابلة للبرمجة للعقود الذكية. ومع ذلك ، بالنسبة لتجريد الحساب الأصلي ، سواء في عصر StarkNet أو zkSync أو Aztec ، وهو محور هذه المقالة ، يجب حفر عناصر معينة في بروتوكول الطبقة 2 حتى تعمل بشكل صحيح. على سبيل المثال ، في Aztec ، يجب تنفيذ مفاتيح التشفير والمفاتيح غير الصالحة على مستوى البروتوكول.

يتطلب فهم تجريد الحساب الأصلي فهما أعمق لكيفية عمل السلسلة بأكملها (على افتراض أنها تسمى “أصلية” ، مع ارتباط منطق تنفيذ AA بشكل طبيعي ببروتوكول Layer2 محدد). على سبيل المثال ، في عصر zkSync ، هناك حاجة لفهم عقد النظام ، في StarkNet ، هناك حاجة لفهم كيفية عمل جهاز التسلسل ، وفي Aztec ، من الأهمية بمكان فهم دور هذه “المفاتيح وحالتها الخاصة الأساسية”.

نقاط دخول الحساب ومراحل التحقق

في Aztec ، على عكس التطبيقات الأخرى لتجريد الحساب ، لا يوجد اسم وظيفة محدد بدقة (توقيع الوظيفة) كنقطة دخول إلى عقد الحساب (على سبيل المثال ، validateUserOp في EIP-4337 و validateTransactionzkSync Era و __validate__StarkNet). المستخدم حر في اختيار أي وظيفة في عقد الحساب كنقطة دخول وإرسال معاملة مع المعلمات ذات الصلة.

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

حدود مرحلة التحقق

ويمتد هذا أيضا إلى مسألة ما إذا كان ينبغي فرض قيود على ما يمكن القيام به خلال مرحلة التحقق أم لا. من المعروف أنه نظرا لعدم وجود حد للتكلفة للتحقق من صحة المعاملات (بشكل أساسي ، يعد التحقق من صحة المعاملات طريقة عرض وظيفية) ، يمكن للمهاجم تنفيذ هجوم رفض الخدمة (DOS) على mempool لاختراق المجمع (EIP-4337) أو المشغل / جهاز التسلسل (AA الأصلي). يحدد EIP-4337 رموز التشغيل المحظورة وكيفية تقييد الوصول إلى التخزين. يخفف zkSync Era بعض استخدام OpCode ، بينما لا يسمح StarkNet بمكالمات العقود الخارجية على الإطلاق.

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

تدفق التفاعل

بمزيد من التفصيل ، في zkSync Era و StarkNet ، يمكن فقط ل “عقد الحساب” بدء معاملة ، لأن البروتوكول يستدعي وظيفة محددة كنقطة دخول ، مما يفرض هذا القيد. ومع ذلك ، في Aztec ، يمكن ل “جميع العقود” بدء المعاملات ، حيث لا يوجد حد للوظيفة التي يسميها البروتوكول كنقطة دخول. هذا يعني أنه في Aztec ، لم يعد تدفق تفاعل ثابتا حيث يرسل المستخدم معاملة إلى دور معين (مثل عقد EntryPoint في EIP-4337 أو جهاز التسلسل / المشغل في Native AA) ثم يستدعي العقد المستهدف. يمكن للمستخدمين إرسال المعاملات من خلال المحفظة ، والسماح مباشرة للعقد المستهدف بإكمال التفاعلات ذات الصلة ، مما يعزز المرونة بشكل كبير.

إذا كنت معتادا على EIP-2938 ، وهو تطبيق آخر ل AA ، فستجد أن Aztec أقرب إلى النهج متعدد المستأجرين فيه. ومع ذلك ، هذا موضوع أعمق يمكنك استكشافه بنفسك.

مفاتيح في حساب Aztec الخاص بك

في Aztec ، يحتوي كل حساب عادة على مفتاحين رئيسيين: مفتاح التوقيع ومفتاح الخصوصية الرئيسي.

مفتاح التوقيع

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

اختيار الخوارزمية للمنحنى الإهليلجي للتوقيعات الرقمية متروك للمستخدم. على سبيل المثال ، يستخدم Ethereum secp256k1 ، بينما يوفر Aztec مثالا على schnorr لاستخدامه. في عقد الحساب ، تعمل وظيفة entrypoint() كنقطة دخول (مصدر المكالمة) ويتم استخدامها بواسطة منطق التحقق من الصحة (is_valid_impl()) للتحقق مما إذا كان توقيع Schnorr يطابق المفتاح العام للسجل std::schnorr::verify_signature(…).

! [eWwFvxmMF7pNt0axLcucSvjcig6QHMXl2HKH3luz.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-3454e57f80-dd1a6f-cd5cc0.webp “7128683”)

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

مفتاح الخصوصية الرئيسي

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

! [9WujRrvfd8YccfQkh9kbCtz0O1GVAKvNVJI7kXtm.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-709665cdb6-dd1a6f-cd5cc0.webp “7128684”)

نحن public_master_key account_address المستخدم partial_address وبشكل جماعي كعنوان كامل للحساب. عند التعامل مع الدولة الخاصة ، يحتاج المستخدم إلى تقديم هذه الأجزاء الثلاثة من المعلومات حتى يتمكن أي شخص من التحقق من أن المفتاح العام يتوافق مع العنوان المقصود.

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

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

المعنى الضمني هنا هو أن هذا المفتاح لا يقل أهمية عن المفتاح الخاص ل EOA (حساب مملوك خارجيا) في Ethereum ، مما يجعله نقطة فشل واحدة (SPoF) للحساب. إذا فقد المستخدم أو سرق المفتاح الرئيسي لخصوصية الحساب ، فلا شك في أن الحساب لن يكون قابلا للاسترداد.

يستخدم المفتاح الرئيسي للخصوصية أيضا عملية مشابهة ل BIP-32 لتصدير مفاتيح التشفير والمفاتيح غير الصالحة. يمكن للمستخدمين استخدام مفاتيح تشفير مختلفة ومفاتيح غير صالحة في تطبيقات أو إجراءات مختلفة لضمان الخصوصية والأمان.

مفتاح التشفير

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

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

حرف فارغ

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

معاملات الأزتك

قد يكون وصف مفهوم المعاملة في Aztec أمرا صعبا لأنه يمكن الخلط بينه وبين UTXO (ملاحظات خاصة) ووضع تنفيذ المعاملة في EVM و Aztec مختلف تماما.

في Aztec ، يتم بث كل معاملة في شكل دليل على المعرفة الصفرية (من الواضح لأسباب تتعلق بالخصوصية). يجب على المستخدمين إجراء العمليات الحسابية محليا على العقد الخاصة بهم (تطبيقات المحفظة أو العملاء) لإنشاء إثباتات تتوافق مع المعاملات ، بدلا من مجرد إرسال كائنات المعاملات إلى mempool الخاص بعامل المنجم أو أي مشغل Layer 2 عبر RPC API كما اعتدنا أن نفعل.

تجزئات المعاملات و nonces

عندما ينشئ المستخدم معاملة محليا ، هناك عنصران مهمان:

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

! [xReWU4p6VrxP45q5EYNXZGAziaZhIG1DTrjeO4yD.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-c9db8c15b3-dd1a6f-cd5cc0.webp “7128688”)

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

نظرا لعدم وجود متطلبات صارمة على مستوى البروتوكول ، فإن Aztec غير قادر على إلغاء معاملة معلقة عن طريق تقديم معاملة جديدة بنفس رسوم الغاز ورسوم الغاز الأعلى.

تنفيذ الطلب

كما ذكرنا سابقا ، يمكن للمستخدم تحديد أي وظيفة في عقد الحساب كنقطة دخول حسب الموقف ، ولا يتم التحكم في العملية في Aztec بواسطة كائن تداول بسيط. في الواقع ، ما يخبر حساب العقد بما يجب فعله هو كائن يسمى “طلب التنفيذ”. يمثل الكائن سلوك المستخدم ، مثل “استدعاء وظيفة النقل في العقد مع 0x1234 من المعلمات التالية”.

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

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

من خلال هذه العملية ، نحصل على معلومتين: الإثبات و private_data (إخراج دائرة النواة الخاصة لهذه المعاملة). ثم ترسل المحفظة كائن المعاملة الذي يحتوي على هاتين المعلومتين إلى مجمع Sequencer الخاص ب Aztec وتكمل المعاملة.

ZKP القائم على العميل بدلا من بيئة تنفيذ نوع EVM

في Aztec ، لا نقوم ببساطة بإدخال جميع المعلومات في آلة تورينج مثل EVM لإنشاء الحالة المحدثة. بدلا من ذلك ، يعتمد على الدوائر داخل كل Dapp لتحديد كيفية عمل معلومات الخصوصية. هذا يعني أن مطوري Dapp بحاجة إلى طريقة لإثبات حالة متغيرات العقد. على سبيل المثال ، دعنا نفكر في رصيد المستخدم في عقد رمز ERC-20. إذا أردنا نقل 10 رموز DAI ، فقد يكون للعقد المنطق التالي:

1. تحقق مما إذا كان رصيد المرسل أكبر من 10 DAI (أي > 10 DAI).
2. إذا كان لدى المرسل رصيد كاف ، يتم إنشاء حرف غير صالح للإشارة إلى إتلاف 10 DAI للمرسل (والذي يمكن أن يعوض حيازة المرسل للملاحظة الخاصة 10 DAI).
3. إنشاء ملاحظة خاصة جديدة للمستلم.
4. بث وتشفير جميع الرسائل المرسلة مع 10 DAI.

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

! [B2NwqMIhntBOllrlchIWeaetEbkSSdoTARJiM27A.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-e6bc34e04b-dd1a6f-cd5cc0.webp “7128690”)

تعرف على المزيد حول عقود حساب Aztec

محفظة

تعد المحافظ في Aztec جزءا مهما من إدارة تفاعلات المستخدمين مع blockchain وبياناتهم الخاصة. فيما يلي ملخص للمهام التي يتعين على محفظة Aztec التعامل معها:

1. إنشاء حساب: يجب أن تسمح المحفظة للمستخدمين بإنشاء عقود حساب جديدة ، مما يعني بشكل أساسي نشر عقود حساب جديدة على blockchain.
2. إدارة المفتاح الخاص: المحفظة مسؤولة عن إدارة العبارة الأولية للمستخدم والمفتاح الخاص ، بما في ذلك مفتاح الخصوصية الرئيسي ومفتاح التوقيع (اعتمادا على تصميم عقد الحساب). يمكن أيضا توسيع هذه الإدارة لتشمل تكامل محفظة الأجهزة.
3. عرض الحسابات: يجب أن يكون المستخدمون قادرين على عرض حساباتهم والحالات ذات الصلة ، بما في ذلك الأرصدة والحالات الخاصة الأخرى. هذا يعني أن المحفظة تحتاج إلى الاحتفاظ بقاعدة بيانات محلية لجميع الملاحظات الخاصة المتعلقة بالمستخدم.
4. التفاعل مع Dapps: تحتاج المحافظ إلى تسهيل التفاعل بين المستخدمين و Dapps. عندما يتفاعل المستخدم مع Dapp ، قد يطلب Dapp إرسال معاملة من حساب المستخدم.
5. موافقة المستخدم: قد تتطلب Dapps موافقة المستخدم لعرض حالات عقد معينة ، مثل الرصيد في عقد الرمز المميز. لكشف هذه الحالات ، يجب أن تكون المحفظة قادرة على تلقي طلبات المستخدم (حيث يتطلب كشف الأرصدة موافقة مفتاح المستخدم).
6. إنشاء دليل: لإرسال معاملة نيابة عن مستخدم ، يجب أن تكون المحفظة قادرة على إنشاء دليل محليا. يتضمن ذلك إنشاء ومعالجة إثباتات المعرفة الصفرية لصحة المعاملات.

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

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

عقد الحساب

في Aztec ، تتمثل المهام الرئيسية لعقد الحساب في التحقق من التوقيعات (تأكيد أن المعاملات مصرح بها من قبل مالك الحساب ، وبالتالي فهي مصرح بها على نطاق أوسع ، بدلا من “التحقق منها بالضرورة بواسطة خوارزمية توقيع رقمي محددة”) ، وإدارة استهلاك الغاز ، واستدعاء العقود الأخرى.

هذا مثال رسمي لعقد حساب Aztec باستخدام خوارزمية توقيع Schnorr. نقطة الدخول لجميع المعاملات هي وظيفة entrypoint() (أنت حر في اختيار الوظيفة أو الاسم كنقطة بداية ، ولكن في هذه الحالة يتم استخدام entrypoint().

! [LahY9kfNGKkYkSm5ULPlReKATiTA3K5bjFGIClh0.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-be4c89f0e2-dd1a6f-cd5cc0.webp “7128692”)

عندما نستدعي حساب entrypoint() مع حمولة المرفقات ، فإن نقطة إدخال عقد الحساب () ستتصل بنقطة دخول مكتبة حساب Aztec AA ().

! [OskBKScb0LqWpcTMIuhBMjeSB151sFvSWbwXl.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-c46b7b5d32-dd1a6f-cd5cc0.webp “7128697”)

لا تتطلب Aztec عقود حساباتنا للاستيراد إلى مكتبات حسابات EntrypointPayload و Aztec AA ؛ أنت حر في تصميم منطق عقد الحساب الخاص بك.

! [HNskT1CkOOPiZZaAVvqlJNf7L5VxU39Fz9ir2Ica.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-dbf6df09b4-dd1a6f-cd5cc0.webp “7128698”)

هو السياق ، كائن متوفر في كل وظيفة في Aztec.nr. يحتوي على جميع معلومات kernel المطلوبة لتنفيذ تطبيق السياق. مقتبس من وثائق الأزتك الرسمية. - ما هي الخلفية

ما ورد أعلاه هو نقطة إدخال الكود () لمكتبة حساب Aztec AA. وهي مسؤولة عن تحديد ما إذا كانت العملية مصرح بها من قبل مالك الحساب بناء على وظيفة التحقق من الصحة () المحددة في عقد الحساب هو _valid_impl ، ويقوم بإجراء المكالمات اللازمة لتنفيذ العملية _calls المطلوبة للمعاملة.

هذا يعني أنه إذا كنت تريد الرجوع إلى مكتبة Aztec AA هذه ، ولم يكن عقد حسابك يحتوي على تنفيذ هو \ _valid \ _impl بنفس توقيع الوظيفة ، فستفشل هذه الخطوة.

! [QZuhkG4BTiKMQF4hFZKGw0gi9MBlU5VGcDjyQyU9.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-92b47183b4-dd1a6f-cd5cc0.webp “7128699”)

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

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

السبب في تسميته “شاهد” بدلا من مجرد “توقيع” هو أن الطريقة التي يتم بها التحقق من عقد الحساب لا تتضمن بالضرورة التحقق من التوقيع.

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

! [WJkuu8NWicgcHvCyH08YpHjYtTtYiP8GbRxwwKs.png] (https://img-cdn.gateio.im/webp-social/moments-40baef27dd-a797a836e2-dd1a6f-cd5cc0.webp “7128700”)

خاتمة

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