1. مقدمة المفهوم

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

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

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

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

2. لماذا نحتاج إلى جهاز مساعد ZK؟

أحد أكبر العقبات التي تواجه مطوري العقود الذكية تبقى التكاليف العالية المرتبطة بالحوسبة على السلسلة. نظرًا لأنه يجب قياس الغاز لكل عملية، سيصبح تكلفة المنطق التطبيقية المعقدة بسرعة مرتفعة جدًا لتنفيذها، لأن على الرغم من أنه يمكن للعقد الذكي أرشيفي في طبقة DA من البلوكشين تخزين البيانات التاريخية، إلا أن هذا هو السبب في أن أشياء مثل تطبيقات Dune Off-chain analysis مثل Analytics و Nansen و 0xscope و Etherscan يمكن أن تحتوي على الكثير من البيانات من البلوكشين ويمكن أن تعود إلى وقت طويل، ولكن من الصعب على العقود الذكية الوصول إلى كل هذه البيانات. يمكنها فقط الوصول بسهولة إلى البيانات المخزنة في حالة الجهاز الظاهري، وبيانات الكتلة الأخيرة، وبيانات عقود الذكاء الاصطناعي العامة الأخرى. بالنسبة للمزيد من البيانات، قد تضطر العقود الذكية إلى بذل الكثير من الجهد للوصول إليها:

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

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

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

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

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

3. التنفيذ التقني

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

3.1 التقاط البيانات

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

تقوم معالجة ZK بحل هذه المشكلة بثلاث طرق مختلفة، متوازنة من حيث التكلفة والأمان وسهولة التطوير:

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

3.2 حساب

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

لذلك، الطرق الرئيسية الثلاثة لتحديد الحسابات في معالجات ZK هي في المقام الأول تنازلات بين الأداء والمرونة وسهولة التطوير:

1. الدوائر المخصصة: يقوم المطورون بكتابة دوائرهم الخاصة لكل تطبيق. هذا النهج لديه أكبر إمكانية أداء، لكنه يتطلب جهدا كبيرا من المطور.
2. eDSL/DSL للدوائر: يكتب المطورون دوائر لكل تطبيق، لكنهم يجردون المشاكل الخاصة بـ ZK في إطار مُؤَيَّد (مشابه لاستخدام PyTorch للشبكات العصبية). ولكن الأداء أقل قليلاً.
3. يكتب مطورو zkVM الدوائر في الأجهزة الظاهرية الحالية ويتحققون من تنفيذها في ZK. يوفر هذا أبسط تجربة للمطورين عند استخدام أجهزة الكمبيوتر الظاهرية الحالية، لكنه يؤدي إلى أداء أقل ومرونة بسبب النماذج الحسابية المختلفة بين الأجهزة الظاهرية و ZK.

4. التطبيق

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

4.1 Defi

4.1.1 DEX

خذ الخطاف في Uniswap V4 كمثال:

يسمح Hook للمطورين بأداء العمليات المحددة في أي نقطة رئيسية في الدورة الحياة الكاملة لبركة السيولة - مثل قبل أو بعد تداول الرموز، أو قبل أو بعد تغييرات موقف LP، وبرك السيولة المخصصة، والتبادلات، والرسوم كيفية التفاعل مع مواقف LP، على سبيل المثال:

• الوقت المرجح المتوسط لصانع السوق (TWAMM)
• الرسوم الديناميكية بناءً على التقلبات أو مدخلات أخرى؛
• أمر حد السعر المتسلسل؛
• إيداع سيولة خارج نطاق العمل في بروتوكولات الإقراض؛
• بوابة البوابة المخصصة على سلسلة الكتل أوقران. مثل الوسط الهندسي أوقران؛
• تراكم رسوم LP تلقائيًا على مواقع LP؛
• توزع أرباح MEV من Uniswap على LP؛
• برنامج خصم الولاء للشركاء السيولة أو التجار؛

ببساطة، هو آلية تتيح للمطورين التقاط البيانات التاريخية على أي سلسلة واستخدامها لتخصيص البركة في Uniswap وفقًا لأفكارهم الخاصة. ظهور Hook يجلب المزيد من التركيبية والكفاءة الأعلى للمعاملات على السلسلة. فعالية رأس المال. ومع ذلك، بمجرد أن تصبح منطقة الكود التي تحدد هذه معقدة، ستسبب عبء غاز هائل للمستخدمين والمطورين. ثم zkcoprocessor يأتي في الوقت المناسب هذا، الذي يمكن أن يساعد في توفير تلك التكاليف الغازية وتحسين الكفاءة.

من منظور طويل الأجل ، سيعمل المعالج المساعد ZK على تسريع تكامل DEX و CEX. منذ عام 2022 ، رأينا أن DEX و CEX أصبحا متسقين وظيفيا. تقبل جميع CEXs الرئيسية هذا الواقع وتتبنى محافظ Web3 ، وتبني EVM L2 وتتبنى البنية التحتية الحالية مثل Lightning Network أو المصدر المفتوح لاحتضان حصة السيولة على السلسلة. هذه الظاهرة لا تنفصل عن تعزيز المعالج المساعد ZK. جميع الوظائف التي يمكن أن تحققها CEX ، سواء كانت تداول الشبكة أو المتابعة أو الإقراض السريع أو استخدام بيانات المستخدم ، يمكن أيضا تنفيذ DEX من خلال معالج ZK المشترك. ، وقابلية تكوين وحرية Defi ، وكذلك معاملات العملات الصغيرة على السلسلة ، يصعب تحقيقها باستخدام CEX التقليدية. في الوقت نفسه ، يمكن لتقنية ZK أيضا حماية خصوصية المستخدم أثناء التنفيذ.

4.1.2 تسريب جوي

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

4.2 زكمل

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

4.3 KYC

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

4.4 الاجتماعية

السمة المضاربة لـ Friend.tech هي في الواقع أقوى من السمة الاجتماعية. النواة تكمن في منحنى الربط. هل من الممكن إضافة خطاف إلى منحنى الربط لـ friend.tech بحيث يمكن للمستخدمين تخصيص اتجاه منحنى الربط، مثل تنفيذ بعد انتهاء الجنون بشأن تداول المفاتيح ومغادرة المضاربين، سيتم تنعيم منحنى الربط، وسيتم خفض حاجز الدخول للمعجبين الحقيقيين، وسيرتفع حركة المرور الفعلية للنطاق الخاص. أو السماح للعقد الذكي بالحصول على رسم بياني اجتماعي للمستخدم على السلسلة/خارج السلسلة، وأن يكون قادرًا على متابعة أصدقائك على تطبيقات Dapps الاجتماعية المختلفة بنقرة واحدة. أو يمكنك إنشاء نادي خاص على السلسلة، مثل نادي Degen، ويمكن للعناوين فقط التي تفي بشروط استهلاك الغاز التاريخية الدخول، إلخ.

4.5 الألعاب

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

5. حفل المشروع

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

5.1 اكسيوم

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

لتنفيذ هذه الاستعلامات، تقوم Axiom بأداء الخطوات الثلاث التالية:

1. قراءة: تستخدم Axiom براهين ZK لقراءة البيانات بشكل غير موثوق به من رؤوس الكتل والحالة والمعاملات والإيصالات الخاصة بكتل Ethereum التاريخية. نظرا لأن جميع بيانات Ethereum on-chain مشفرة بهذه التنسيقات ، فإن Axiom قادرة على الوصول إلى كل ما تستطيع عقد الأرشيف الوصول إليه. تتحقق Axiom من جميع بيانات الإدخال إلى المعالج المساعد ZK عبر إثباتات ZK لثلاثيات Merkle-Patricia وسلاسل تجزئة رأس الكتلة. في حين أن تطوير هذا النهج أكثر صعوبة ، إلا أنه يوفر أفضل أمان وتكلفة للمستخدمين النهائيين لأنه يضمن أن جميع النتائج التي يتم إرجاعها بواسطة Axiom مكافئة بشكل مشفر للحسابات على السلسلة التي يتم إجراؤها في EVM.
2. احتساب: بعد أن يتم استيعاب البيانات، يطبق Axiom الحسابات المثبتة عليها. يمكن للمطورين تحديد منطق الحساب الخاص بهم في واجهة JavaScript الأمامية، ويتم التحقق من صحة كل حساب في دليل ZK. يمكن للمطورين زيارة AxiomREPL أو عرض الوثائق لمعرفة الأساسيات الحسابية المتاحة. يسمح Axiom للمستخدمين بالوصول إلى البيانات على السلسلة وتحديد حساباتهم الخاصة من خلال eDSL. كما يسمح للمستخدمين بكتابة دوائرهم الخاصة باستخدام مكتبة دوائر ZK.
3. التحقق: يوفر Axiom دلائل صحة ZK لكل نتيجة للاستعلام. تضمن هذه الدلائل أن (1) تم استخراج البيانات المدخلة بشكل صحيح من السلسلة و (2) تم تطبيق الحسابات بشكل صحيح. يتم التحقق من هذه الدلائل ZK على السلسلة في عقود Axiom الذكية، مما يضمن استخدام النتائج النهائية بشكل موثوق في عقود المستخدمين.

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

5.2 خطر صفر

Bonsai: في عام 2023، أصدر RISC Zero Bonsai، خدمة دليل تسمح للتطبيقات داخل السلسلة وخارجها بطلب واستلام أدلة zkVM. Bonsai هي خدمة دليل عامة للصفر المعرفة تسمح لأي سلسلة، أي بروتوكول، وأي تطبيق باستخدام أدلة ZK. إنها عالية التوازن، قابلة للبرمجة وعالية الأداء.

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

zkVM هو أساس Bonsai ويدعم التوافق اللغوي الواسع، دعم رمز Rust القابل للإثبات، وربما رمز الإثبات بدون معرفة في أي لغة تم تجميعها إلى RISC-V (مثل C++، Rust، Go، الخ). من خلال الأدلة التكرارية، مترجمات الدوائر المخصصة، استمرار الحالة، والتحسينات المستمرة لخوارزميات البرهان، يتيح Bonsai لأي شخص إنشاء أدلة ZK عالية الأداء لمجموعة متنوعة من التطبيقات.

RISC Zero zkVM: أُصدر RISC Zero zkVM لأول مرة في أبريل 2022، ويمكنه إثبات تنفيذ الشيفرات التعسفية بشكل صحيح، مما يمكّن المطورين من ببناء تطبيقات ZK بلغات نضجة مثل Rust و C++. هذا الإصدار هو اختراق رئيسي في تطوير البرمجيات ZK: يجعل zkVM من الممكن بناء تطبيقات ZK دون بناء دوائر واستخدام لغات مخصصة.

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

تتضمن هذه التطبيقات:

• JSON: احترافي محتويات إدخال في ملف JSON مع الحفاظ على خصوصية البيانات الأخرى.
• أين والدو: أثبت أن والدو موجود في ملف JPG مع الاحتفاظ بأجزاء أخرى من الصورة بشكل خاص.
• ZK Checkmate: اثبت أنك رأيت حركة الخنزير دون الكشف عن الحركة الفائزة.
• دليل إثبات استغلال: دليل على أنه يمكنك استغلال حساب Ethereum دون الكشف عن الثغرة.
• التحقق من توقيع ECDSA: إثبات صحة توقيع ECDSA.

تم تنفيذ هذه الأمثلة من خلال استغلال بيئة برمجيات ناضجة: معظم أدوات Rust متاحة على الفور في Risc Zero zkVM. القدرة على أن تكون متوافقة مع Rust هي محول لعالم البرمجيات ZK: يمكن حل المشاريع التي قد تستغرق أشهرًا أو سنواتًا للبناء على منصات أخرى بسهولة على منصة RISC Zero.

بالإضافة إلى أنه من السهل بناؤه، يوفر RISC Zero أيضًا أداءًا ممتازًا. يحتوي zkVM على تسريع GPU باستخدام CUDA و Metal، ويحقق دليلًا موازيًا لبرامج كبيرة من خلال الاستمرارية.

سابقًا، حصلت Risc Zero على 40 مليون دولار أمريكي في تمويل السلسلة A من Galaxy Digital، IOSG، RockawayX، Maven 11، Fenbushi Capital، Delphi Digital، Algaé Ventures، IOBC ومؤسسات أخرى.

5.3 بريفيس

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

واجهة التطبيق: يدعم نظام بريفيس الحالي دلائل ZK فعالة وموجزة، ويوفر معلومات سلسلة المصدر المثبتة ZK التالية لعقود تطبيقات اللامركزية (dApp) المتصلة بسلسلة الكتل:

1. تجذر كتلة البيانات والحالة المرتبطة بها، وجذور المعاملات، والإيصالات لأي كتلة على سلسلة المصدر.
2. قيمة الفتحة والبيانات الوصفية ذات الصلة لأي كتلة محددة، عقد، فتحة على سلسلة المصدر.
3. إيصالات المعاملات والبيانات الوصفية ذات الصلة لأي معاملة على سلسلة المصدر.
4. مدخلات المعاملات والبيانات الوصفية ذات الصلة لأي معاملة على سلسلة المصدر.
5. أي رسالة ترسلها أي كيان على سلسلة المصدر إلى أي كيان على سلسلة الهدف.

نظرة عامة على الهندسة: تتكون هندسة بريفيس من ثلاثة أجزاء رئيسية:

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

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

5.4 لانجرانج

لدى Langrange و Brevis رؤية مماثلة ، تهدف إلى تعزيز قابلية التشغيل البيني بين سلاسل متعددة من خلال ZK Big Data Stack ، والتي يمكن أن تخلق براهين حالة عالمية على جميع سلاسل الكتل السائدة. من خلال التكامل مع بروتوكول Langrange ، يمكن للتطبيقات تقديم إثباتات مجمعة لحالة متعددة السلاسل ، والتي يمكن التحقق منها بعد ذلك بشكل غير تفاعلي من خلال العقود على سلاسل أخرى.

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

سيكون بروتوكول لانجرانج متوافقًا في البداية مع جميع L1 و L2 rollups التي تتوافق مع EVM. بالإضافة إلى ذلك، تخطط لانجرانج أيضًا لدعم سلاسل غير متوافقة مع EVM في المستقبل القريب، بما في ذلك على سبيل المثال لا الحصر سولانا، سوي، آبتوس، وسلاسل عامة شهيرة تعتمد على Cosmos SDK.

الفرق بين بروتوكول Langrange والبروتوكولات التقليدية للجسور والرسائل:

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

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

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

لقد تلقت Langrange استثمارات سابقة من 1kx، Maven11، Lattice، CMT Digital و gumi crypto.

5.5 هيرودوتس

تم تصميم Herodotus لتوفير عقود ذكية مع وصول متزامن للبيانات على السلسلة من طبقات Ethereum الأخرى. إنهم يعتقدون أن إثبات التخزين يمكن أن يوحد حالة التراكمات المتعددة وحتى يسمح بالقراءات المتزامنة بين طبقات Ethereum. ببساطة ، إنه التقاط البيانات بين السلسلة الرئيسية ل EVM والتراكم. يدعم حاليا شبكة ETH الرئيسية و Starknet و Zksync و OP و Arbitrum و Polygon.

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

يتم تقسيم عملية إنشاء دليل التخزين تقريبًا إلى ثلاث خطوات:

الخطوة 1: الحصول على تراكم تخزين رأس الكتلة للالتزامات التي يمكن التحقق منها

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

الخطوة 2: إثبات وجود حساب محدد

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

الخطوة 3: إثبات البيانات المحددة في شجرة الحسابات

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

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

هيرو دوتس مدعومة بالفعل من قبل Geometry، Fabric Ventures، Lambda Class، و Starkware.

5.6 هايبراوراكل

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

يتكون جهاز zkOracle الخاص بـ Hyper Oracle بشكل رئيسي من مكونين: zkPoS و zkWASM.

1. zkPoS: هذا المكون مسؤول عن الحصول على رأس الكتلة وجذر البيانات لسلسلة الكتل Ethereum من خلال دليل المعرفة الصفري (zk) لضمان صحة اتفاقية Ethereum. كما يعمل zkPoS كدائرة خارجية لـ zkWASM.
2. zkWASM: يستخدم البيانات التي تم الحصول عليها من zkPoS كمدخل رئيسي لتشغيل zkGraphs. يتحمل zkWASM مسؤولية تشغيل خرائط البيانات المخصصة التي حددها zkGraphs وتوليد البراهين على عدم المعرفة لهذه العمليات. يمكن لمشغلي عقدة zkOracle اختيار عدد zkGraphs الذين يرغبون في تشغيله، والذي يمكن أن يكون من واحد إلى جميع zkGraphs المنشورة. يمكن تفويض عملية توليد براهين zk إلى شبكة موزعة من المثبتين.

إن إخراج zkOracle هو بيانات خارج سلسلة الكتلة، ويمكن للمطورين استخدام هذه البيانات من خلال معيار Hyper Oracle's zkGraph. البيانات تأتي أيضًا مع شهادات zk للتحقق من صحة البيانات والحسابات.

للحفاظ على أمان الشبكة، يتطلب شبكة Hyper Oracle وجود عقدة واحدة فقط من zkOracle. ومع ذلك، يمكن أن توجد عدة عقد zkOracle في الشبكة، تعمل ضد zkPoS وكل zkGraph. وهذا يسمح بتوليد البراهين zk بشكل متوازي، مما يعزز الأداء بشكل كبير. بشكل عام، توفر Hyper Oracle للمطورين منصة تفاعلية بلوكشين فعالة وآمنة عن طريق دمج تكنولوجيا zk المتقدمة وهندسة عقدة مرنة.

في يناير 2023، أعلن Hyper Oracle أنها تلقت 3 ملايين دولار أمريكي في جولة تمويل ما قبل البذرة شاركت فيها بشكل مشترك Dao5، Sequoia China، Foresight Ventures، و FutureMoney Group.

5.7 المسار

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

5.8 القارن بين معالج ZK وآلة الأوراق المالية

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

الشكل أدناه يظهر سير عمل Pado:

يستخدم Pado عقد التشفير كدليل خلفي. من أجل تقليل افتراضات الثقة ، سيتبنى فريق Pado استراتيجية تطورية ويحسن تدريجيا اللامركزية في خدمة البروفر. يشارك البروفير بنشاط في عملية استرجاع بيانات المستخدم ومشاركتها مع إثبات صحة بيانات المستخدم التي تم الحصول عليها من مصادر بيانات الشبكة. ما يجعلها فريدة من نوعها هو أن Pado تستفيد من MPC-TLS (الحوسبة الآمنة متعددة الأطراف لطبقة النقل) و IZK (إثبات المعرفة الصفرية التفاعلية) لتمكين المثبتين من إثبات البيانات "بشكل أعمى". هذا يعني أن المدققين لا يمكنهم رؤية أي بيانات أصلية ، بما في ذلك معلومات المستخدم العامة والخاصة. ومع ذلك ، لا يزال بإمكان المدقق ضمان أصل البيانات لأي بيانات TLS مرسلة من خلال طرق التشفير.

1. MPC-TLS: بروتوكول TLS هو بروتوكول أمان يُستخدم لحماية الخصوصية وسلامة البيانات للاتصالات عبر الإنترنت. عندما تزور موقعًا وترى رمز "القفل" و "https" في عنوان URL ، فهذا يعني أن زيارتك مؤمنة من خلال TLS. يقوم MPC-TLS بتقليد وظيفة عميل TLS، مما يتيح لمصادق Pado التعاون مع عميل TLS لأداء المهام التالية:
   من المهم أن نلاحظ أن هذه العمليات المتعلقة بـ TLS تتم بين العميل والمحقق من خلال بروتوكول الحساب الثنائي (2PC). تعتمد تصميم MPC-TLS على بعض تقنيات التشفير، مثل دائرة الإرباك (GC)، ونقل النسيان (OT)، IZK، إلخ.
   • إنشاء اتصال TLS، بما في ذلك حساب المفتاح الأساسي، ومفتاح الجلسة، ومعلومات التحقق.
   • تنفيذ الاستعلامات عبر قناة TLS، بما في ذلك إنشاء طلبات مشفرة وفك تشفير استجابات الخادم.
2. EXC: الدليل التفاعلي الصفري للبرهان هو دليل صفري للبرهان يمكن فيه للمثبت والتحقق التفاعل. في بروتوكول IZK، نتيجة المحقق هي قبول أو رفض مطالبة المثبت. بالمقارنة مع NIZKs البسيطة (مثل zk-STARKs أو zk-SNARKs)، يحتوي بروتوكول IZK على عدة مزايا، مثل التوسع العالي للمطالبات الكبيرة، وتكلفة الحوسبة المنخفضة، وعدم الحاجة إلى إعداد موثوق، وتقليل استخدام الذاكرة.

بادو يطور بنشاط خطة kyc لـ Uniswap، ويسعى إلى المزيد من البيانات حول سيناريوهات تطبيق on-chain، وقد تم اختياره للانضمام إلى الدفعة الأولى من برنامج Consensys Fellowship.

6. توقعات المستقبل

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

من جانب الطلب وحده ، يعد المعالج المساعد ZK ضرورة. من منظور مسار DEX وحده ، يتمتع هذا الخطاف بإمكانات كبيرة ويمكنه القيام بأشياء كثيرة. إذا لم يكن لدى sushiswap خطافات ، فلن يكون قادرا على التنافس مع uniswap ، وسيكون كذلك سيتم القضاء عليه قريبا. إذا لم يتم استخدام zkcoprocessor للخطافات ، فسيكون الغاز مكلفا للغاية للمطورين والمستخدمين ، لأن الخطافات تقدم منطقا جديدا وتجعل العقود الذكية أكثر تعقيدا ، مما يؤدي إلى نتائج عكسية. حتى الآن ، يعد استخدام المعالج المساعد zk هو الحل الأفضل. سواء من منظور التقاط البيانات أو حسابها ، فإن العديد من الطرق لها مزايا وعيوب مختلفة. المعالج المساعد المناسب لوظائف محددة هو معالج مساعد جيد. يتمتع سوق الحوسبة التي يمكن التحقق منها على السلسلة بآفاق واسعة وسيعكس قيمة جديدة في المزيد من المجالات.

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

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

7. فهرس

https://blog.axiom.xyz/what-is-a-zk-coprocessor/

https://crypto.mirror.xyz/BFqUfBNVZrqYau3Vz9WJ-BACw5FT3W30iUX3mPlKxtA

https://dev.risczero.com/api

https://blog.uniswap.org/uniswap-v4

https://blog.celer.network/2023/03/21/brevis-a-zk-omnichain-data-attestation-platform/

https://lagrange-labs.gitbook.io/lagrange-labs/overview/what-is-the-lagrange-protocol

https://docs.herodotus.dev/herodotus-docs/

https://docs.padolabs.org/

اخلاء المسؤولية:

1. تم نشر هذا المقال مرة أخرى من [Gateأبحاث الرؤية]. كل حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [مايك]. إذا كانت هناك اعتراضات على إعادة النشر هذه، يرجى الاتصال بالبوابة تعلمالفريق، وسيتولون بسرعة.
2. إخلاء المسؤولية عن الضرر: تعبر الآراء والآراء المعبر عنها في هذه المقالة فقط عن وجهة نظر الكاتب ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى من قبل فريق Gate Learn. يحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها، ما لم يذكر ذلك.