دليل المطور إلى zkGalaxy

هذا دليل مفيد للغاية للتمييز بين الأساليب لدعم zkEVM. ومع ذلك ، فإن zkEVMs هي مجموعة فرعية من جميع الطرق الممكنة لبناء تطبيقات المعرفة الصفرية. للمبرمج الذي يريد الاستفادة من الخصائص الفريدة لحساب zk ، وهي الإيجاز ، والمعرفة الصفرية ، والصواب، قد لا يكون zkEVM هو الخيار الأفضل. من خلال وضع مجموعة كاملة من أدوات المطور ، آمل أن أقدم دليلًا يساعد في عملية اتخاذ القرار حول مكدس zk المناسب لتطبيقك.

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

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

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

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

Arkworks-RS هو نظام بيئي لمكتبات Rust يوفر عمليات تنفيذ فعالة وآمنة للمكونات الفرعية لتطبيق zkSNARK. يوفر Arkworks الواجهات اللازمة للمطورين لتخصيص حزمة البرامج لتطبيق zk دون الحاجة إلى إعادة تنفيذ القواسم المشتركة مع المكتبات الأخرى الموجودة.

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

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

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

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

القاهرة - Starkware DSL ضروري لبناء تطبيقات على Starknet. تجميع وصولاً إلى لغة التجميع الخاصة بالقاهرة والتي يمكن تفسيرها بواسطة القاهرة zkVM.

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

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

الأسد - تم تطوير Leo كلغة لـ Aleo blockchain. يحتوي Leo على بعض البنية الشبيهة بالصدأ وهو مصمم خصيصًا لتحولات الحالة داخل blockchain.

نوير - تركيب مستوحى من الصدأ. تمت هندستها حول IR بدلاً من اللغة نفسها ، مما يعني أنه يمكن أن يكون لها واجهة أمامية عشوائية. 

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

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

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

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

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

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

تستخدم تطبيقات zkEVM اليوم استراتيجيات مختلفة للتخفيف من تأثير هذه المشكلة ... على سبيل المثال ، تقوم zkSync بتمزيق العمليات الأكثر تكلفة (معظمها عمليات تشفير مُسبقة مثل التجزئة و ECDSA) من دائرة إثبات التنفيذ الرئيسية إلى دوائر منفصلة يتم تجميعها معًا في نهاية عن طريق العودية snark. اتخذ zkSync هذا النهج بعد أن أدركوا أن معظم تكاليفهم تأتي من بعض التعليمات المعقدة.

في الأساس ، السبب في أن إثبات مجموعة تعليمات أكثر مكافئًا لـ EVM أكثر تكلفة هو أن EVM لم يتم تصميمه لحسابات zk. يتيح التخلي عن EVM في وقت سابق في المكدس تشغيل zkEVMs على مجموعات التعليمات التي تم تحسينها بشكل أكبر لـ zk ، وبالتالي أرخص لإثباتها.

العملاء المثاليون لـ zkEVM هم تطبيقات العقود الذكية التي تحتاج إلى أوامر معاملات أرخص بكثير مما هو متاح في L1 Ethereum. لا يمتلك هؤلاء المطورون بالضرورة الخبرة أو النطاق الترددي لكتابة تطبيقات zk من البداية. لذلك ، يفضلون كتابة طلباتهم بلغات عالية المستوى مألوفة لهم ، مثل Solidity. 

تحجيم الإيثيريوم هو حاليًا التطبيق الأكثر طلبًا لتقنية zk.

يعد zkEVM أحد حلول تحجيم Ethereum الذي يخفف بدون احتكاك مشكلة الازدحام التي تقيد مطوري L1 dApp.

الهدف من zkEVM هو دعم تجربة مطور قريبة قدر الإمكان من تطوير Ethereum الحالي. يعني دعم Solidity الكامل أنه لا يتعين على الفرق إنشاء العديد من قواعد التعليمات البرمجية والحفاظ عليها. هذا غير عملي إلى حد ما للقيام به بشكل مثالي لأن zkEVMs تحتاج إلى مقايضة بعض التوافق لتكون قادرة على إنشاء أدلة ذات حجم معقول في فترة زمنية معقولة.

يتمثل الاختلاف الأساسي بين zkSync و Scroll في مكان / عندما يتم إجراء الحساب في المكدس - أي حيث يتم التحويل من تركيبات EVM العادية إلى تمثيل متوافق مع SNARK. بالنسبة إلى zkSync ، يحدث هذا عندما يقومون بتحويل YUL bytecode إلى مجموعة تعليمات zk المخصصة الخاصة بهم. بالنسبة إلى Scroll ، يحدث هذا في النهاية ، عندما يتم إنشاء تتبع التنفيذ الفعلي باستخدام أكواد تشغيل EVM الفعلية.

لذلك ، بالنسبة إلى zkSync ، كل شيء هو نفس التفاعل مع EVM حتى يتم إنشاء zk bytecode. بالنسبة إلى Scroll ، يظل كل شيء كما هو حتى يتم تنفيذ الرمز الثانوي الفعلي. هذا فرق دقيق ، والذي يستبدل الأداء بالدعم. على سبيل المثال ، لن يدعم zkSync أدوات EVM bytecode مثل مصحح الأخطاء خارج الصندوق ، لأنه رمز ثانوي مختلف تمامًا. بينما سيواجه Scroll صعوبة أكبر في الحصول على أداء جيد من مجموعة التعليمات ، لم يتم تصميم ذلك لـ zk. هناك إيجابيات وسلبيات لكلتا الاستراتيجيتين ، وفي النهاية هناك الكثير من العوامل الخارجية التي ستؤثر على نجاحهما النسبي.

؟؟؟؟ على الرغم من تسميتها ، فإن LLVM ليست آلة افتراضية (VM). LLVM هو اسم مجموعة من أدوات المترجم المرتبط بتمثيل وسيط (IR) لا يعرف اللغة.

= لا شيء مؤسسة (حول الاسم ، إنه أ نكتة حقن SQL إذا كنت تتساءل) تقوم ببناء مترجم يمكنه تحويل أي لغة أمامية LLVM إلى تمثيل وسيط يمكن إثباته داخل SNARK. تم تصميم zkLLVM كامتداد للبنية التحتية الحالية لـ LLVM ، وهي سلسلة أدوات متوافقة مع معايير الصناعة تدعم العديد من اللغات عالية المستوى مثل Rust و C و C ++ وما إلى ذلك.

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

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

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

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

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

بدلاً من إثبات EVM ، يمكن للنظام إثبات بنية مجموعة تعليمات مختلفة (ISA) ، مثل RISC-V أو WASM في جهاز افتراضي جديد. هناك مشروعان يعملان على zkVMs المعممة هما RISC Zero و zkWASM. دعنا نتعمق قليلاً في RISC Zero هنا لشرح كيفية عمل هذه الإستراتيجية وبعض مزاياها / عيوبها. 

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

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

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

من منظور المطور ، فإن استخدام RISC Zero للتعامل مع أدلة zk يشبه إلى حد كبير استخدام وظائف AWS Lambda للتعامل مع بنية الخادم الخلفية. يتفاعل المطورون مع RISC Zero أو AWS Lambda ببساطة عن طريق كتابة التعليمات البرمجية وتعالج الخدمة كل التعقيدات الخلفية.

بالنسبة إلى RISC Zero ، يكتب المطورون Rust أو C ++ (في النهاية أي شيء يستهدف RISC-V). ثم يأخذ النظام ملف ELF الذي تم إنشاؤه أثناء التجميع ويستخدم ذلك كرمز إدخال لدائرة VM. يقوم المطورون ببساطة باستدعاء كائن "إثبات" الذي يقوم بإرجاع إيصال (والذي يحتوي على دليل zk لتتبع التنفيذ) والذي يمكن لأي شخص الاتصال به "تحقق" من أي مكان. من وجهة نظر المطور ، ليست هناك حاجة لفهم كيفية عمل zk ، فالنظام الأساسي يتعامل مع كل هذا التعقيد.

بالنسبة لبعض الدوائر الأساسية والقابلة لإعادة الاستخدام والمفيدة بشكل خاص لتطبيقات blockchain أو في أي مكان آخر ، ربما تكون الفرق قد قامت بالفعل ببناء وتحسين هذه الدوائر من أجلك. يمكنك فقط تقديم المدخلات لحالة الاستخدام الخاصة بك. دليل تضمين Merkle على سبيل المثال هو شيء مطلوب بشكل شائع في تطبيقات التشفير (قوائم airdrop ، Tornado Cash ، إلخ). بصفتك مطور تطبيق ، يمكنك دائمًا إعادة استخدام هذه العقود التي تم اختبارها في المعركة وتعديل الطبقات في الأعلى لإنشاء تطبيق فريد.

على سبيل المثال ، يمكن إعادة استخدام دوائر Tornado Cash من أجل a تطبيق الإنزال الجوي الخاص أو تطبيق التصويت الخاص. يقوم مانتا وسيمافور ببناء مجموعة أدوات كاملة من أدوات الدوائر الشائعة مثل هذه التي يمكن استخدامها في عقود Solidity مع فهم بسيط أو معدوم لرياضيات zk moon الأساسية.

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

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

آمل أن أقنعك ، مطور البرامج الفضولي ، أنه يمكنك البدء في استخدام zk في تطبيقاتك اليوم. قرصنة سعيدة 🙂

افصاحات: Blockchain Capital هو مستثمر في العديد من البروتوكولات المذكورة أعلاه.

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