مؤخراً، أجرينا مقابلة مع خبير في مجال البلوكتشين، حيث ناقشنا تعقيد ومرونة بنية Sui التحتية، بالإضافة إلى كيفية مساهمة نظام معالجة المعاملات في Sui في تحقيق شبكة عالية الأداء. هذا الخبير هو أستاذ في مجال الأمن والخصوصية في إحدى الجامعات المعروفة.
以下为本次 المقابلة内容：
Q1：هل يمكنك تقديم لمحة عن مجالات بحثك الرئيسية؟
تركز أبحاثي بشكل عام على الأمان والخصوصية. في البداية، قمت بالكثير من الأبحاث حول أنظمة نظير إلى نظير والأنظمة المجهولة، والتي كانت العديد منها أنظمة موزعة كبيرة تركز على التخزين. عندما بدأ مجال البلوكتشين في التركيز بشكل أكبر على التنفيذ، وخاصةً من خلال بعض المنصات، أصبحت مهتمًا بدفاتر الحسابات الموزعة والبلوكتشين وكيفية تنفيذ العقود الذكية. كنت على دراية بخصائص عدم الحاجة إلى إذن في عملي المبكر مع أنظمة نظير إلى نظير. لذا، بدأ فريقي البحث في كيفية بناء أنظمة ذات أداء أعلى. أنشأنا شركة لتسويق بعض أفكارنا، وبعد ذلك تم الاستحواذ على الفريق من قبل إحدى الشركات التكنولوجية الكبرى. ثم ساعدنا تلك الشركة في تقديم حلول لتوسيع البلوكتشين. ولكن عندما لم تحقق الحلول تقدمًا، تركت ذلك واستمرت في البحث عن فرص أخرى لتحقيق فكرة البلوكتشين عالية الأداء.
Q2：ما الفرق بين التطبيقات والبحوث؟
في الواقع، لا يوجد فرق كبير. في البحث، سنأخذ في الاعتبار جميع الاحتمالات لتحقيق أهداف محددة، مثل بناء بلوكتشين عالي الأداء أو وظيفة معينة. عند بناء النظام في الواقع، يجب علينا اختيار الأكثر صلة من هذه الأفكار الجيدة. هذا ليس مجرد اهتمام بالمعرفة، بل هو خلق قيمة للمستخدمين. يجب علينا أن نستمر في اتخاذ القرارات، واختيار الحلول الأكثر فائدة للناس، والتي يمكن أن تحل المشكلات العملية.
Q3: كيف حددت المشاكل التي تحتاج إلى حلها عند الانتقال من النظرية إلى التطبيق العملي؟
أنا أبحث بشكل رئيسي في كيفية توسيع الوظائف المختلفة للبلوكتشين. أركز على الجوانب النظامية للبلوكتشين، مثل كيفية زيادة قدرة معالجة المعاملات وتقليل التأخير. هذه المشكلة واضحة، كلما أصبح عقد ما شائعًا جدًا، يصبح النظام غير قادر على تحمل هذا الحجم الكبير من المعاملات، مما يؤدي إلى ازدحام في المعاملات وارتفاع حاد في الرسوم. لقد رأينا مرارًا وتكرارًا أن قدرة معالجة المعاملات في البلوكتشين لا تلبي احتياجات المستخدمين. هذه ليست مجرد فكرة لدينا، بل إن الأكاديميين في جميع أنحاء العالم يبحثون في طرق مختلفة لحل هذه المشكلة. الآن، هناك عدد كبير من التقنيات التي تم تطويرها لتوسيع قدرة البلوكتشين.
س4: ما الفرق والفوائد بين شبكة L2 وإنشاء شبكة L1 جديدة؟
L2 هو حل توسيع في بعض الأنظمة البيئية. لكن بالنسبة لمطوري التطبيقات، فإن استخدام شبكة L2 يمكن أن يكون معقدًا بعض الشيء. عندما تتفاعل شبكة L2 مع L1، يجب إجراء أنشطة جسر. يجب أن يتم عكس الحالة الممثلة في L1 في L2، والعكس صحيح. يجب أن تحتوي L2 أيضًا على آلية تسمح لـ L1 بالتحقق من كل ما يحدث فيها. هذه العملية مرهقة، خاصة بالنسبة للأصول المعقدة.
في شبكة L1 الجديدة لدينا، أنشأنا قاعدة بيانات ضخمة تحتوي على جميع حالات العقد الموثوقة المكررة. بمجرد إتمام صفقة، يمكن استخدام جميع الحالات الموجودة في نفس قاعدة البيانات للصفقة التالية، ولا يحتاج المستخدم إلى نقل حالة الأصول باستمرار بين مستويات مختلفة.
س5: هل يمكنك تقديم لمحة عن الابتكارات الرئيسية في بروتوكول الأساس لشبكة L1 الجديدة؟
يتكون هذا البروتوكول من فكرتين رئيسيتين: الأولى هي أن العديد من العمليات على البلوكتشين لا تتطلب في الواقع توافقًا؛ والثانية هي أنه عندما يكون هناك حاجة للتوافق، هناك طريقة عالية الإنتاجية. هذا البروتوكول هو جوهر النظام الموزع، ويضمن أن العقد التحقق المختلفة التي تتبع البروتوكول لن تكون أبدًا في حالة عدم توافق.
يوفر البروتوكول مسارين مختلفين: أحدهما لا يتطلب توافقًا (المسار السريع)، والآخر يتطلب توافقًا (مسار التوافق). عندما يتعلق الأمر بأشياء تخص الشخص فقط، يمكن استخدام المسار السريع للحصول على نهائية المعاملة دون انتظار التوافق. ولكن في بعض الحالات، مثل تلك التي تتضمن أشياء مشتركة، يجب استخدام مسار التوافق.
تتمتع هذين المسارين بمزايا مختلفة. المسار السريع لديه تأخير منخفض للغاية، ويستغرق أقل من ثانية واحدة. بينما المسار التوافقي لديه تأخير أعلى، وعادة ما يتجاوز ثانية واحدة، ولكن سعته مرتفعة أيضًا. التطبيقات التي تُجري عددًا كبيرًا من المعاملات يوميًا تستخدم عادة المسار السريع، بينما البروتوكولات التي تقوم بعمليات معقدة (مثل DeFi) تستخدم في الغالب المسار التوافقي.
Q6: هل يمكن للمطورين تصميم تطبيقاتهم للاستفادة من الطريق السريع؟
يمكن بالتأكيد. هذه هي العمل الأساسي لتصميم التطبيقات الموسعة. يمكن للمطورين السيطرة بالكامل على ما إذا كانت الكائنات التي يتعاملون معها في العقد هي كائنات حصرية أو كائنات مشتركة. إحدى الحيل في التطبيقات الموسعة هي التأكد من أن معظم العمليات تعتمد على الكائنات الحصرية، لأن هذا يمكن أن يدير العمليات بتأخير منخفض جداً، مما يوفر تجربة مستخدم ممتازة.
للمطورين السيطرة الكاملة على ذلك، حيث يمكنهم تحديد بدقة ما هي المعاملات في كل فئة. مع الحاجة إلى التوسع، يجب على المطورين التفكير في كيفية الاستفادة القصوى من المسار السريع.
Q7: كيف تعمل الكتل القابلة للبرمجة في هذا النظام؟
يمكن أن تلعب كتل التداول القابلة للبرمجة دورًا على مسار سريع أو مسار توافق. إذا كانت كتلة التداول القابلة للبرمجة تتعلق فقط بالأشياء الخاصة، فهذا يعني أنه يمكن تنفيذ عدة عمليات في عملية واحدة على سلسلة. على سبيل المثال، يمكن لبعض التطبيقات تسوية عدد كبير من المعاملات في وقت واحد، وهذا ينتمي إلى المسار السريع. إذا كانت بعض الكائنات داخل كتلة المعاملات مشتركة، فهذا يدخل في مسار التوافق، وسيكون هناك تأخير أعلى قليلاً.
Q8: كيف كان أداء النظام بعد إطلاق الشبكة الرئيسية؟ هل كان هناك ما أدهشك؟
أثبت أداء النظام صحة التصميم. في أوقات التداول الكثيف، تجاوز حجم التداول اليومي حتى 60 مليون صفقة، حيث أن معظمها كانت معاملات عبر المسارات السريعة. وهذا يدل على أن البروتوكول قابل للتوسع للغاية ويتميز بانخفاض التأخير.
في الوقت نفسه، نجد أن استخدام المسار السريع له بعض النقاط الدقيقة. أحيانًا قد يحدث قفل للأشياء، على الرغم من أنه عادةً ما يتم إلغاء قفلها بنهاية الدورة، إلا أن هذه ليست تجربة جيدة. نحن نعمل على تطوير مجموعة من التقنيات التي تسمح بإلغاء قفل الأشياء التي تم قفلها عن طريق الخطأ بسرعة خلال ثوانٍ.
بالإضافة إلى ذلك، نحن نستكشف كيفية جعل المزيد من أنواع الكائنات تتداول عبر مسار سريع، حتى لو كانت هذه الكائنات قد يتم مشاركتها من قبل عدة أشخاص. سيزيد هذا من كفاءة ومرونة النظام.
Q9: هل يمكنك توضيح الأسباب التي تؤدي إلى قفل الكائنات بالتفصيل؟
عادةً ما يحدث قفل الكائنات بسبب عدم اتساق ترتيب العمليات. عندما ينتمي كائن إلى مستخدم معين، يعتمد النظام على المستخدم لإبلاغ ترتيب العمليات. تظهر المشكلة عندما يرتكب المستخدم أو برامجه خطأ، مثل تقديم أجهزة مختلفة لترتيب عمليات متناقض.
هذا الوضع أكثر شيوعًا مما كان متوقعًا، حيث يستخدم الأشخاص أجهزة مختلفة، أو يحاولون إجراء معاملات متعددة على نفس الكائن في نفس الوقت. عندما يتم قفل الكائن، من المفترض أن ينتظر النظام حتى تنتهي دورة واحدة قبل أن يتم فتحه، مما قد يؤدي إلى مشاكل خطيرة.
نحن نعمل على تطوير حلول، وعندما يحدث هذا، سيقوم النظام بحلها من خلال الإجماع، وستتم هذه العملية في غضون ثوانٍ، بدلاً من الانتظار حتى نهاية الدورة.
Q10: ما رأيك في كيفية تحقيق توازن بين الشفافية، القابلية للتتبع والخصوصية في البلوكتشين؟
هذا يعتمد إلى حد كبير على التطبيق المحدد. موقفنا هو تقديم منصة جيدة تمكّن المطورين من بناء حماية الخصوصية وفقًا لاحتياجاتهم.
لمساعدة المطورين، نقدم بعض الدعم الأصلي للعملات المشفرة، مثل القدرة على التحقق من الإثباتات الصفرية. هذا يسمح لمصممي التطبيقات بالتحقق من بعض الأحداث خارج السلسلة، دون الحاجة إلى الكشف عن المحتوى المحدد على السلسلة. هذه هي الوحدة الأساسية لبناء تطبيقات صديقة للخصوصية.
يمكن للمطورين الجمع بين هذه الدعم الأصلي، واستخدام استراتيجيات على السلسلة، وخارج السلسلة، والتشفير للتعامل مع مشاكل الخصوصية التي قد يواجهونها.
Q11：هل يوجد دعم أصلي أكبر للخصوصية في النظام؟
نحن نفكر في الدعم الإضافي الذي قد يحتاجه المطورون عند بناء تطبيقات صديقة للخصوصية. بالإضافة إلى إثباتات المعرفة الصفرية، اقترح البعض الحاجة إلى المزيد من الدوال الرياضية أو التشفير العامة. نحن نرحب بتعليقات المطورين حول الأجزاء المفقودة.
هناك تقنيات أخرى مثل الحساب متعدد الأطراف أو الأجهزة الموثوقة التي يمكن استخدامها لحماية الخصوصية. إذا أبدت المجتمع حاجة كافية، سنأخذ في الاعتبار التطور في هذه الاتجاهات. ولكن قد يتطلب ذلك إجراء بعض التغييرات الأساسية على بنية النظام، لذا يتعين تقييمها بعناية.
Q12: كيف تعتقد أن النظام سيتطور في الأشهر الستة إلى الاثني عشر المقبلة؟
على المدى القصير، سيتم توجيه العديد من التحسينات نحو احتياجات التطبيقات العملية. على المدى الطويل، سنعمل على تحسين البروتوكول الأساسي لتحقيق تأخير أقل وبنية أكثر بساطة، وزيادة القابلية للتوسع. سنبذل أيضًا جهدًا لتحسين الكفاءة الاقتصادية، مما يمكّن عقد التحقق من العمل على أجهزة أكثر تقييدًا، واستخدام الأجهزة الحالية بشكل أكثر كفاءة لتنفيذ المعاملات الفعلية، بدلاً من استهلاكها في التشفير أو غيرها من نفقات البلوكتشين. هذه هي الاتجاهات الرئيسية التي نتوقع أن نراها.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 14
أعجبني
14
2
إعادة النشر
مشاركة
تعليق
0/400
MemeKingNFT
· منذ 22 س
منذ بداية العام، شعرت بأن سوي سيحقق突破، احترافي قال ذلك بشكل صحيح.
خبير بلوكتشين Sui يفسر: كيف تعزز المسارات السريعة ومسارات الإجماع أداء الشبكة
مؤخراً، أجرينا مقابلة مع خبير في مجال البلوكتشين، حيث ناقشنا تعقيد ومرونة بنية Sui التحتية، بالإضافة إلى كيفية مساهمة نظام معالجة المعاملات في Sui في تحقيق شبكة عالية الأداء. هذا الخبير هو أستاذ في مجال الأمن والخصوصية في إحدى الجامعات المعروفة.
以下为本次 المقابلة内容：
Q1：هل يمكنك تقديم لمحة عن مجالات بحثك الرئيسية؟
تركز أبحاثي بشكل عام على الأمان والخصوصية. في البداية، قمت بالكثير من الأبحاث حول أنظمة نظير إلى نظير والأنظمة المجهولة، والتي كانت العديد منها أنظمة موزعة كبيرة تركز على التخزين. عندما بدأ مجال البلوكتشين في التركيز بشكل أكبر على التنفيذ، وخاصةً من خلال بعض المنصات، أصبحت مهتمًا بدفاتر الحسابات الموزعة والبلوكتشين وكيفية تنفيذ العقود الذكية. كنت على دراية بخصائص عدم الحاجة إلى إذن في عملي المبكر مع أنظمة نظير إلى نظير. لذا، بدأ فريقي البحث في كيفية بناء أنظمة ذات أداء أعلى. أنشأنا شركة لتسويق بعض أفكارنا، وبعد ذلك تم الاستحواذ على الفريق من قبل إحدى الشركات التكنولوجية الكبرى. ثم ساعدنا تلك الشركة في تقديم حلول لتوسيع البلوكتشين. ولكن عندما لم تحقق الحلول تقدمًا، تركت ذلك واستمرت في البحث عن فرص أخرى لتحقيق فكرة البلوكتشين عالية الأداء.
Q2：ما الفرق بين التطبيقات والبحوث؟
في الواقع، لا يوجد فرق كبير. في البحث، سنأخذ في الاعتبار جميع الاحتمالات لتحقيق أهداف محددة، مثل بناء بلوكتشين عالي الأداء أو وظيفة معينة. عند بناء النظام في الواقع، يجب علينا اختيار الأكثر صلة من هذه الأفكار الجيدة. هذا ليس مجرد اهتمام بالمعرفة، بل هو خلق قيمة للمستخدمين. يجب علينا أن نستمر في اتخاذ القرارات، واختيار الحلول الأكثر فائدة للناس، والتي يمكن أن تحل المشكلات العملية.
Q3: كيف حددت المشاكل التي تحتاج إلى حلها عند الانتقال من النظرية إلى التطبيق العملي؟
أنا أبحث بشكل رئيسي في كيفية توسيع الوظائف المختلفة للبلوكتشين. أركز على الجوانب النظامية للبلوكتشين، مثل كيفية زيادة قدرة معالجة المعاملات وتقليل التأخير. هذه المشكلة واضحة، كلما أصبح عقد ما شائعًا جدًا، يصبح النظام غير قادر على تحمل هذا الحجم الكبير من المعاملات، مما يؤدي إلى ازدحام في المعاملات وارتفاع حاد في الرسوم. لقد رأينا مرارًا وتكرارًا أن قدرة معالجة المعاملات في البلوكتشين لا تلبي احتياجات المستخدمين. هذه ليست مجرد فكرة لدينا، بل إن الأكاديميين في جميع أنحاء العالم يبحثون في طرق مختلفة لحل هذه المشكلة. الآن، هناك عدد كبير من التقنيات التي تم تطويرها لتوسيع قدرة البلوكتشين.
س4: ما الفرق والفوائد بين شبكة L2 وإنشاء شبكة L1 جديدة؟
L2 هو حل توسيع في بعض الأنظمة البيئية. لكن بالنسبة لمطوري التطبيقات، فإن استخدام شبكة L2 يمكن أن يكون معقدًا بعض الشيء. عندما تتفاعل شبكة L2 مع L1، يجب إجراء أنشطة جسر. يجب أن يتم عكس الحالة الممثلة في L1 في L2، والعكس صحيح. يجب أن تحتوي L2 أيضًا على آلية تسمح لـ L1 بالتحقق من كل ما يحدث فيها. هذه العملية مرهقة، خاصة بالنسبة للأصول المعقدة.
في شبكة L1 الجديدة لدينا، أنشأنا قاعدة بيانات ضخمة تحتوي على جميع حالات العقد الموثوقة المكررة. بمجرد إتمام صفقة، يمكن استخدام جميع الحالات الموجودة في نفس قاعدة البيانات للصفقة التالية، ولا يحتاج المستخدم إلى نقل حالة الأصول باستمرار بين مستويات مختلفة.
س5: هل يمكنك تقديم لمحة عن الابتكارات الرئيسية في بروتوكول الأساس لشبكة L1 الجديدة؟
يتكون هذا البروتوكول من فكرتين رئيسيتين: الأولى هي أن العديد من العمليات على البلوكتشين لا تتطلب في الواقع توافقًا؛ والثانية هي أنه عندما يكون هناك حاجة للتوافق، هناك طريقة عالية الإنتاجية. هذا البروتوكول هو جوهر النظام الموزع، ويضمن أن العقد التحقق المختلفة التي تتبع البروتوكول لن تكون أبدًا في حالة عدم توافق.
يوفر البروتوكول مسارين مختلفين: أحدهما لا يتطلب توافقًا (المسار السريع)، والآخر يتطلب توافقًا (مسار التوافق). عندما يتعلق الأمر بأشياء تخص الشخص فقط، يمكن استخدام المسار السريع للحصول على نهائية المعاملة دون انتظار التوافق. ولكن في بعض الحالات، مثل تلك التي تتضمن أشياء مشتركة، يجب استخدام مسار التوافق.
تتمتع هذين المسارين بمزايا مختلفة. المسار السريع لديه تأخير منخفض للغاية، ويستغرق أقل من ثانية واحدة. بينما المسار التوافقي لديه تأخير أعلى، وعادة ما يتجاوز ثانية واحدة، ولكن سعته مرتفعة أيضًا. التطبيقات التي تُجري عددًا كبيرًا من المعاملات يوميًا تستخدم عادة المسار السريع، بينما البروتوكولات التي تقوم بعمليات معقدة (مثل DeFi) تستخدم في الغالب المسار التوافقي.
Q6: هل يمكن للمطورين تصميم تطبيقاتهم للاستفادة من الطريق السريع؟
يمكن بالتأكيد. هذه هي العمل الأساسي لتصميم التطبيقات الموسعة. يمكن للمطورين السيطرة بالكامل على ما إذا كانت الكائنات التي يتعاملون معها في العقد هي كائنات حصرية أو كائنات مشتركة. إحدى الحيل في التطبيقات الموسعة هي التأكد من أن معظم العمليات تعتمد على الكائنات الحصرية، لأن هذا يمكن أن يدير العمليات بتأخير منخفض جداً، مما يوفر تجربة مستخدم ممتازة.
للمطورين السيطرة الكاملة على ذلك، حيث يمكنهم تحديد بدقة ما هي المعاملات في كل فئة. مع الحاجة إلى التوسع، يجب على المطورين التفكير في كيفية الاستفادة القصوى من المسار السريع.
Q7: كيف تعمل الكتل القابلة للبرمجة في هذا النظام؟
يمكن أن تلعب كتل التداول القابلة للبرمجة دورًا على مسار سريع أو مسار توافق. إذا كانت كتلة التداول القابلة للبرمجة تتعلق فقط بالأشياء الخاصة، فهذا يعني أنه يمكن تنفيذ عدة عمليات في عملية واحدة على سلسلة. على سبيل المثال، يمكن لبعض التطبيقات تسوية عدد كبير من المعاملات في وقت واحد، وهذا ينتمي إلى المسار السريع. إذا كانت بعض الكائنات داخل كتلة المعاملات مشتركة، فهذا يدخل في مسار التوافق، وسيكون هناك تأخير أعلى قليلاً.
Q8: كيف كان أداء النظام بعد إطلاق الشبكة الرئيسية؟ هل كان هناك ما أدهشك؟
أثبت أداء النظام صحة التصميم. في أوقات التداول الكثيف، تجاوز حجم التداول اليومي حتى 60 مليون صفقة، حيث أن معظمها كانت معاملات عبر المسارات السريعة. وهذا يدل على أن البروتوكول قابل للتوسع للغاية ويتميز بانخفاض التأخير.
في الوقت نفسه، نجد أن استخدام المسار السريع له بعض النقاط الدقيقة. أحيانًا قد يحدث قفل للأشياء، على الرغم من أنه عادةً ما يتم إلغاء قفلها بنهاية الدورة، إلا أن هذه ليست تجربة جيدة. نحن نعمل على تطوير مجموعة من التقنيات التي تسمح بإلغاء قفل الأشياء التي تم قفلها عن طريق الخطأ بسرعة خلال ثوانٍ.
بالإضافة إلى ذلك، نحن نستكشف كيفية جعل المزيد من أنواع الكائنات تتداول عبر مسار سريع، حتى لو كانت هذه الكائنات قد يتم مشاركتها من قبل عدة أشخاص. سيزيد هذا من كفاءة ومرونة النظام.
Q9: هل يمكنك توضيح الأسباب التي تؤدي إلى قفل الكائنات بالتفصيل؟
عادةً ما يحدث قفل الكائنات بسبب عدم اتساق ترتيب العمليات. عندما ينتمي كائن إلى مستخدم معين، يعتمد النظام على المستخدم لإبلاغ ترتيب العمليات. تظهر المشكلة عندما يرتكب المستخدم أو برامجه خطأ، مثل تقديم أجهزة مختلفة لترتيب عمليات متناقض.
هذا الوضع أكثر شيوعًا مما كان متوقعًا، حيث يستخدم الأشخاص أجهزة مختلفة، أو يحاولون إجراء معاملات متعددة على نفس الكائن في نفس الوقت. عندما يتم قفل الكائن، من المفترض أن ينتظر النظام حتى تنتهي دورة واحدة قبل أن يتم فتحه، مما قد يؤدي إلى مشاكل خطيرة.
نحن نعمل على تطوير حلول، وعندما يحدث هذا، سيقوم النظام بحلها من خلال الإجماع، وستتم هذه العملية في غضون ثوانٍ، بدلاً من الانتظار حتى نهاية الدورة.
Q10: ما رأيك في كيفية تحقيق توازن بين الشفافية، القابلية للتتبع والخصوصية في البلوكتشين؟
هذا يعتمد إلى حد كبير على التطبيق المحدد. موقفنا هو تقديم منصة جيدة تمكّن المطورين من بناء حماية الخصوصية وفقًا لاحتياجاتهم.
لمساعدة المطورين، نقدم بعض الدعم الأصلي للعملات المشفرة، مثل القدرة على التحقق من الإثباتات الصفرية. هذا يسمح لمصممي التطبيقات بالتحقق من بعض الأحداث خارج السلسلة، دون الحاجة إلى الكشف عن المحتوى المحدد على السلسلة. هذه هي الوحدة الأساسية لبناء تطبيقات صديقة للخصوصية.
يمكن للمطورين الجمع بين هذه الدعم الأصلي، واستخدام استراتيجيات على السلسلة، وخارج السلسلة، والتشفير للتعامل مع مشاكل الخصوصية التي قد يواجهونها.
Q11：هل يوجد دعم أصلي أكبر للخصوصية في النظام؟
نحن نفكر في الدعم الإضافي الذي قد يحتاجه المطورون عند بناء تطبيقات صديقة للخصوصية. بالإضافة إلى إثباتات المعرفة الصفرية، اقترح البعض الحاجة إلى المزيد من الدوال الرياضية أو التشفير العامة. نحن نرحب بتعليقات المطورين حول الأجزاء المفقودة.
هناك تقنيات أخرى مثل الحساب متعدد الأطراف أو الأجهزة الموثوقة التي يمكن استخدامها لحماية الخصوصية. إذا أبدت المجتمع حاجة كافية، سنأخذ في الاعتبار التطور في هذه الاتجاهات. ولكن قد يتطلب ذلك إجراء بعض التغييرات الأساسية على بنية النظام، لذا يتعين تقييمها بعناية.
Q12: كيف تعتقد أن النظام سيتطور في الأشهر الستة إلى الاثني عشر المقبلة؟
على المدى القصير، سيتم توجيه العديد من التحسينات نحو احتياجات التطبيقات العملية. على المدى الطويل، سنعمل على تحسين البروتوكول الأساسي لتحقيق تأخير أقل وبنية أكثر بساطة، وزيادة القابلية للتوسع. سنبذل أيضًا جهدًا لتحسين الكفاءة الاقتصادية، مما يمكّن عقد التحقق من العمل على أجهزة أكثر تقييدًا، واستخدام الأجهزة الحالية بشكل أكثر كفاءة لتنفيذ المعاملات الفعلية، بدلاً من استهلاكها في التشفير أو غيرها من نفقات البلوكتشين. هذه هي الاتجاهات الرئيسية التي نتوقع أن نراها.