تنفق شركة Anagram Build معظم وقتنا في البحث عن النوى الجديدة للعملات المشفرة وتطبيق هذه النوى في منتجات محددة. أحد مشاريع البحث الأخيرة لدينا أدت بنا إلى عالم الحوسبة القابلة للتحقق (VC)؛ فاستفاد فريقنا من هذا البحث لإنشاء نظام مفتوح المصدر جديد يسمىبونسول. اخترنا هذا المجال من البحث نظرًا لظهور حالات الاستخدام الفعالة التي يمكن أن يمكنها VC والجهود المبذولة عبر مختلف L1s لتحسين فعالية تكلفة VC وقابلية توسعها.

في هذه المدونة، لدينا هدفان.

• أولاً، نريد التأكد من أنك ستنتهي بفهم أفضل لـ VC كمفهوم والمنتجات الممكنة التي يمكنها تمكينها في نظام Solana.
• ثانيًا، نريد أن نقدم لكم أحدث إبداع لدينا، Bonsol.

ما هو الحوسبة التي يمكن التحقق منها، على أي حال؟

قد لا يظهر مصطلح 'الحوسبة القابلة للتحقق' في عروض الاستثمار لشركات البداية في سوق الثيران، ولكن مصطلح 'المعرفة الصفرية' يفعل. إذا، ماذا تعني هذه المصطلحات؟

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

كيف تساعدنا رأس المال الاستثماري في بناء منتجات العملات المشفرة بشكل أفضل؟

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

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

بينما هناك العديد من الأمثلة الواعدة على استخدام VC و ZK في البرية، يعتمد الكثير من تلك الأمثلة حالياً على التطوير الجاري على جميع مستويات برمجيات العملات المشفرة لجعلها سريعة وكفؤة بما يكفي لاستخدامها في الإنتاج.

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

هيا بنا! فكيف تعمل أنظمة VC/ZK اليوم؟

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

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

التحقق الكامل على السلسلة

بالنسبة لأنظمة إثبات VC و ZK التي يمكنها إنتاج أدلة صغيرة ، مثل Groth16 أو بعض أصناف Plonk ، يتم بعد ذلك تقديم الدليل على السلسلة والتحقق منه على السلسلة باستخدام التعليمات البرمجية التي تم نشرها مسبقا. أصبحت هذه الأنظمة شائعة جدا الآن ، وأفضل طريقة لتجربة ذلك هي استخدام Circom ومدقق Groth16 على Solana أو EVM. العيب هو أن أنظمة الإثبات هذه بطيئة للغاية. كما أنها تتطلب عادة تعلم لغة جديدة. للتحقق من تجزئة 256 بت في Circom ، تحتاج بالفعل إلى التعامل يدويا مع كل من تلك ال 256 بت. هناك العديد من المكتبات التي تسمح لك فقط باستدعاء وظائف التجزئة ، ولكن وراء الكواليس ، تحتاج إلى إعادة تنفيذ هذه الوظائف في كود Circom الخاص بك. هذه الأنظمة رائعة عندما يكون عنصر ZK و VC في حالة الاستخدام الخاصة بك أصغر ، وتحتاج إلى أن يكون الدليل صالحا قبل اتخاذ بعض الإجراءات الحتمية الأخرى. يقع Bonsol في هذه الفئة الأولى حاليا.

التحقق خارج السلسلة

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

شبكات التحقق

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

التحقق المتزامن على السلسلة

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

إعادة تلخيص

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

تقديم بونسول!

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

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

قبل أن نغوص في تفاصيل النظام، دعونا نبدأ بتوضيح قوة بونسول من خلال حالتي استخدام مختلفتين.

سيناريو واحد

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

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

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

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

السيناريو الثاني

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

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

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

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

هندسة بونسول

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

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

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

هل كان من السهل بناؤها؟ بالطبع لا!

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

عندما بدأنا في بناء Bonsol واستخدام الأدوات الحالية لتغليف Stark ب Snark ، بحثنا عن طرق لتقليل التبعيات وزيادة السرعة. يسمح Circom بتجميع كود Circom في C ++ أو wasm. حاولنا أولا تجميع دائرة Circom في ملف wasmu الذي أنتجته LLVM. هذه هي الطريقة الأسرع والأكثر فعالية لجعل أدوات Groth16 محمولة ولا تزال سريعة. لقد اخترنا wasm نظرا لقابليته للنقل حيث يعتمد رمز C ++ على بنية وحدة المعالجة المركزية x86 ، مما يعني أن أجهزة Macbook الجديدة أو الخوادم المستندة إلى Arm لن تكون قادرة على استخدام هذا. لكن هذا أصبح طريقا مسدودا بالنسبة لنا في الجدول الزمني الذي كان علينا العمل معه. نظرا لأن معظم تجارب أبحاث منتجاتنا محاصرة بالوقت حتى تثبت قيمتها ، فقد كان لدينا 2-4 أسابيع من وقت التطوير لاختبار هذه الفكرة. لم يتمكن مترجم llvm wasm من التعامل مع رمز wasm الذي تم إنشاؤه. مع المزيد من العمل ، كان بإمكاننا تجاوز هذا ، لكننا جربنا العديد من علامات التحسين والطرق لجعل مترجم llvm يعمل كمكون إضافي wasmer لتجميع هذا الرمز مسبقا في llvm ، لكننا لم ننجح. نظرا لأن دائرة Circom تحتوي على حوالي 1.5 مليون سطر من التعليمات البرمجية ، يمكنك أن تتخيل أن كمية Wasm أصبحت ضخمة. ثم حولنا أنظارنا إلى محاولة إنشاء جسر بين C ++ وقاعدة كود ترحيل Rust الخاصة بنا. واجه هذا أيضا هزيمة سريعة حيث احتوى C ++ على بعض رموز التجميع الخاصة ب x86 التي لم نرغب في العبث بها. من أجل إخراج النظام للجمهور ، انتهى بنا الأمر ببساطة إلى تمهيد النظام بطريقة تستخدم رمز C ++ ولكنها تزيل بعض التبعيات. في المستقبل ، نود التوسع في خط تحسين آخر كنا نعمل عليه. كان ذلك لأخذ رمز C ++ وتجميعه بالفعل في رسم بياني للتنفيذ. هذه القطع الأثرية C ++ من تجميع Circom هي في الغالب مجرد حساب معياري على حقول محدودةمع عدد أولي كبير جدًا جدًا كمولد. أظهرت هذه بعض النتائج الواعدة للقطع الأصغر والأبسط بلغة C++، ولكن هناك حاجة إلى المزيد من العمل لجعله يعمل مع نظام Risc0. يرجع ذلك إلى أن الشيفرة البرمجية بلغة C++ المولدة حوالي 7 مليون سطر من الشيفرة، ويبدو أن مولد الرسوم يصطدم بحدود حجم الكومة، ورفع تلك الحدود يبدو أنه ينتج أخطاء أخرى لم نكن لدينا الوقت لتحديدها. على الرغم من أن بعض هذه الطرق لم تؤتِ ثمارها، إلا أننا تمكنا من الإسهام في مشاريع المصدر المفتوح ونأمل أن تتم دمج تلك المساهمات في وقت ما.

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

ملاحظة أخيرة حول Bonsol لم نرها في أماكن أخرى باستخدام Risc0 حتى الآن هي أننا نفرض التزاما (تجزئة) على بيانات الإدخال في برنامج zk. ونحن في الواقع نتحقق من العقد أن المدخلات التي كان على البروفير الالتزام بها لمطابقة ما توقعه المستخدم وإرساله إلى النظام. يأتي هذا ببعض التكلفة ، ولكن بدونه يعني أن المحترف يمكنه الغش وتشغيل zkprogram على المدخلات التي لم يحددها المستخدم. سقطت بقية تطوير Bonsol في تطوير Solana العادي ولكن تجدر الإشارة إلى أننا جربنا عمدا بعض الأفكار الجديدة هناك. في العقد الذكي ، نستخدم Flatbuffers كنظام التسلسل الوحيد. هذه تقنية جديدة إلى حد ما نود أن نراها تتطور وتتحول إلى إطار عمل لأنها تفسح المجال بشكل جيد لحزم SDK التي يتم إنشاؤها تلقائيا عبر الأنظمة الأساسية. ملاحظة أخيرة حول Bonsol هي أنها تحتاج حاليا إلى ترجمة مسبقة للعمل بكفاءة أكبر ، ومن المقرر أن تهبط هذه الترجمة المسبقة في Solana 1.18 ، ولكن حتى ذلك الحين نعمل لمعرفة ما إذا كانت الفرق مهتمة بهذا البحث والنظر إلى ما وراء Bonsol إلى تقنيات أخرى.

اختتام

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

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

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

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

1. تم نشر هذه المقالة من [Solanaالجدول], جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [austbotإذا كانت هناك اعتراضات على هذا إعادة الطبع، يرجى الاتصال بالبوابة تعلمالفريق، وسوف يتولى التعامل معها بسرعة.

2. تنصل المسؤولية: الآراء والآراء الواردة في هذه المقالة هي فقط تلك للمؤلف ولا تشكل أي نصيحة استثمارية.

3. تتم ترجمة المقال إلى لغات أخرى من قبل فريق Gate Learn. ما لم يكن مذكورًا، فإن نسخ أو توزيع أو نسخ المقالات المترجمة ممنوع.