حوار متعمق مع كبير العلماء في Mysten Labs: من النظرية إلى التطبيق، كيف يحل Sui مشكلة قابلية التوسع في الشبكة؟

لقد أجرينا مؤخرًا مقابلة مع جورج دانيزيس لمناقشة مدى تعقيد البنية التحتية لـ Sui وقابلية التوسع، وكيف يعمل نظام معالجة المعاملات الخاص بـ Sui على تمكين شبكة عالية الأداء. جورج دانيزيس هو المؤسس المشارك وكبير العلماء في Mysten Labs (والمساهم الأصلي لـ Sui)، وأستاذ في مجال هندسة الأمن والخصوصية في جامعة كاليفورنيا.

وفيما يلي محتوى هذه المقابلة:

**س1: أنت من المجال الأكاديمي، هل يمكنك التعريف بمحور بحثك؟ **

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

**س2: مازلت أستاذاً، فما هو الفرق بين التطبيق والبحث في نظرك؟ **

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

**س3: عند الانتقال من النظرية إلى التطبيق العملي، كيف يمكنك تحديد المشكلات التي يجب حلها؟ **

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

**Q4: شبكة L2 هي طريقة يقترحها الأشخاص لحل مشكلة القياس. ما الفرق والفائدة من بناء شبكة L1 جديدة مثل Sui؟ **

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

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

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

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

**Q5: Sui Lutris هو أساس بروتوكول Sui. ما هي ابتكاراته الرئيسية التي تمكن Sui من الحصول على إنتاجية عالية وزمن وصول منخفض؟ **

يتكون Sui Lutris من فكرتين رئيسيتين: (1) بالنسبة للعديد من العمليات على blockchain، لا يلزم الإجماع فعليًا؛ (2) عندما تحتاج إلى إجماع، هناك طريقة عالية الإنتاجية للغاية من شأنها الجمع بين هاتين الطريقتين. Sui Lutris هو جوهر نظام Sui الموزع، مما يضمن أن عقدتي التحقق المختلفتين اللتين تتبعان البروتوكول لن تكونا أبدًا في حالة غير متناسقة عند إجراء المعاملات على الشبكة الموزعة. لا يوجد موقف حيث يعتقد أحد المدققين أنك أنفقت عملة معدنية وأرسلتها إلى أليس، بينما يعتقد مدقق آخر أن نفس العملة قد تم إرسالها بالفعل إلى بوب.

🌟القضاعة الذاتية:

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

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

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

**س6: هل يمكن لمطوري التطبيقات على Sui تصميم تطبيقاتهم للاستفادة من المسار السريع؟ **

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

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

**س7: كيف تلعب كتلة المعاملات القابلة للبرمجة دورًا في هذا؟ **

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

**س 8: الشبكة الرئيسية موجودة على الإنترنت منذ أكثر من 100 يوم. هل أكد أداء Sui نظرية البحث الافتراضية الخاصة بك؟ هل هناك أي شيء فاجأك؟ **

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

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

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

**س9: هل يمكنك مشاركة المزيد من التفاصيل حول السبب الحالي لقفل الكائنات؟ **

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

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

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

**س10: معظم أبحاثك تدور حول الخصوصية. ما هي أفكارك حول كيف يمكن لأنظمة blockchain العامة تحقيق التوازن الأفضل بين الشفافية وإمكانية التتبع والخصوصية؟ **

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

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

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

**س11: هل يوجد المزيد من الدعم الأصلي للخصوصية على Sui؟ **

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

**س12: كيف تعتقد أن Sui سوف يتطور خلال الـ 6 إلى 12 شهرًا القادمة؟ **

يعتمد الأمر على نوع التطبيقات التي يبنيها الأشخاص على Sui، وعلى المدى القصير، سيتم إدخال الكثير من التحسينات على التطبيقات التي يبنيها الأشخاص بالفعل. من منظور طويل المدى جدًا، وفقًا لمعايير blockchain، يمكن اعتبار من 6 إلى 12 شهرًا وقتًا طويلًا جدًا، وسوف نقوم بتحسين بروتوكول Sui Lutris لتحقيق زمن استجابة أقل، وبروتوكولات أبسط، وجعل مقاييس Sui أفضل. بالإضافة إلى ذلك، فإنه سيجعل الاقتصاد أكثر كفاءة، مما يمكّن عقد التحقق من العمل على أجهزة أكثر تقييدًا واستخدام الأجهزة الموجودة للتنفيذ الفعلي للمعاملات بدلاً من القيام بالتشفير أو أي نفقات أخرى لـ blockchain. وهذا ما نتوقع رؤيته.