مؤخراً، أجرينا مقابلة مع خبير في البلوكتشين، لاستكشاف تعقيد وقابلية توسيع بنية Sui التحتية، وكيف يسهم نظام معالجة المعاملات في Sui في تعزيز شبكة عالية الأداء. هذا الخبير هو أستاذ في مجال الأمن والخصوصية في جامعة معروفة.
التالي هو محتوى المقابلة هذه:
س1: أنت من المجال الأكاديمي، هل يمكنك تقديم لمحة عن تركيز بحثك؟
أنا أستاذ في جامعة معينة، وتركز أبحاثي بشكل عام على الأمان والخصوصية. في أوائل القرن العشرين، أجريت الكثير من الأبحاث حول أنظمة الند للند والأنظمة المجهولة، وكانت معظم هذه الأنظمة أنظمة موزعة كبيرة تركز على التخزين. عندما أصبحت البلوكتشين أكثر تركيزًا على التنفيذ، وخاصة تمثيلها في الإيثيريوم، تولدت لدي اهتمام بالدفاتر الموزعة والبلوكتشين وكيفية تنفيذ العقود الذكية. كنت على دراية كبيرة بخصائصها غير المصرح بها من خلال عملي في أنظمة الند للند في وقت مبكر. لذا، بدأت مجموعة الأبحاث في الجامعة بالعمل على كيفية بناء أنظمة ذات أداء أعلى. أسسنا شركة لتجارية بعض أفكارنا، وفيما بعد تم الاستحواذ على الفريق من قبل شركة تقنية كبيرة. ثم ساعدنا تلك الشركة في تقديم حلول لتوسيع البلوكتشين. ولكن عندما لم تحقق تلك الحلول تقدمًا، تركت الشركة وواصلت البحث عن فرص أخرى لتحقيق فكرة البلوكتشين عالية الأداء.
Q2: أنت ما زلت أستاذًا، فما رأيك في الفرق بين التطبيق والبحث؟
في الواقع لا يوجد فرق كبير. عندما نقوم بالبحث، سنأخذ بعين الاعتبار جميع الاحتمالات لتحقيق أهداف محددة، مثل بناء بلوكتشين عالي الأداء أو ميزات معينة. بالطبع، عند بناء بلوكتشين أو اختيار الميزات المحددة التي سيتم استخدامها في النظام الفعلي، يجب علينا اختيار واحدة من هذه الاحتمالات. يجب علينا باستمرار اتخاذ القرارات، أي من هذه الأفكار الجيدة هو الأكثر فائدة للناس؟ أيها يبحث عنه الناس؟ ما هي العقبات التي تواجه اعتماد البلوكتشين؟ ما الذي يمنع الناس من تحقيق ما يريدون القيام به؟ عند بناء النظام، ستظل تأخذ بعين الاعتبار جميع الاحتمالات، وتحاول فهم الحالات المحتملة من الأدبيات الأكاديمية، ثم اختيار الأكثر صلة. هذا ليس مجرد اهتمام بالمعرفة، بل هو خلق قيمة للمستخدمين.
Q3: كيف تحدد المشاكل التي يجب حلها عند الانتقال من النظرية إلى التطبيق العملي؟
المشكلة الرئيسية التي أدرسها هي كيفية توسيع وظائف مختلفة للبلوكتشين. أركز على الجوانب النظامية للبلوكتشين، مثل كيفية زيادة حجم المعاملات وتقليل التأخير. هذه المشكلة واضحة، كلما رأينا عقدة معينة على منصة ما تصبح شديدة الشعبية، فإن تلك المنصة لا تستطيع تحمل هذا الحجم الكبير من المعاملات، مما يؤدي إلى ازدحام المعاملات وارتفاع الرسوم بشكل كبير. في كل مرة يحقق فيها البلوكتشين النجاح، نرى أن حجم المعاملات التي يمكن معالجتها يتجاوز القدرة الحالية. لذلك، من الواضح أن المشكلة تكمن في عدم وجود القدرة الكافية لتلبية ما يريده الناس من هذه البلوكتشينات. هذا ليس مجرد فكرة لدينا، فنحن نرى هذه الحالة تتكرر مرة تلو الأخرى. لفترة من الزمن، كان يُعتبر هذا تحديًا ذا قيمة، ليس فقط في فريقي، بل في الواقع في جميع الأوساط الأكاديمية التي تدرس البلوكتشين، حيث يحاول الجميع حل هذه المشكلة بطرق مختلفة. الآن، تم تطوير عدد كبير من التقنيات لتوسيع قدرة البلوكتشين لمواجهة هذه التحديات. لكن في ذلك الوقت، كان معروفًا أن العديد من الأشخاص يحاولون حلها بطرق مختلفة.
س4: شبكة L2 هي وسيلة اقترحها الناس لحل مشكلة التوسع، ما الفرق والفوائد بينها وبين إنشاء شبكة L1 جديدة مثل Sui؟
L2 هو حل للتوسع في نظام بيئي معين. لكن بالنسبة لمطوري التطبيقات، فإن استخدام شبكة L2 قد يكون معقدًا قليلاً. عندما تحاول شبكة L2 التفاعل مع L1، يجب إجراء نشاط الجسر، على الرغم من أن هذا ينطبق على أي علاقة L2/L1. يجب أن يتم عكس الحالة التي تمثل coin أو الأصول أو أي شيء آخر في L1 في L2، والعكس صحيح. بالإضافة إلى ذلك، يجب أن يكون لدى L2 بعض الآليات بحيث يمكن لـ L1 التحقق من كل ما يحدث فيه. لكن هذه هي الجزء الأول فقط، أي أن أي أصول موجودة على L1 تحتاج إلى الانتقال إلى L2، ويجب أن تحدث بعض الأنشطة على L2، ثم بطريقة ما يجب إعادة الأصول إلى L1. هذا أمر مرهق.
بالنسبة للأصول القابلة للاستبدال مثل tokens، كان هذا النشاط الجسري سلسًا إلى حد ما، لأن الناس لديهم حسابان ووسيط جسر. ولكن بالنسبة للأصول الأكثر عمومية، لم يكن الأمر كذلك. لاستخدام شبكة L2 المطورة على L1 لتطبيقات أكثر تعقيدًا من tokens، تحتاج إلى وجود عقود ذكية على كلا الجانبين، واحدة للتعدين (mint) وأخرى للحرق (burn). يجب أن تتنقل بين نظامين بيئيين مختلفين، وهذا هو النشاط المخصص لكل عقد. لا يمكنك ببساطة أن تقول، سأقوم بإنشاء شبكة L2 ثم أنقل جميع الأصول، ثم أتصرف كما أريد، ثم أعيدها، لا يوجد مثل هذا المفهوم. إنها عملية يدوية، ومن السهل جدًا أن تخطئ. لذلك، ليست تجربة جيدة. تخيل أنك تمتلك أصولًا في شبكات L2 مختلفة، ولديك هذه العقود الذكية المخصصة في شبكات L2 المختلفة. في كل مرة تريد فيها إجراء عملية على حالة تقع في شبكة L2 أخرى، يجب عليك الانتقال عبر الجسر مرة أخرى إلى L1، ثم العودة إلى L2. لا يمكنك ببساطة أن تقول، لقد قمت للتو ببعض الأشياء على هذه البلوكتشين، والآن أريد أن أفعل أشياء أخرى على بلوكتشين أخرى، ولا أحتاج إلى التفكير في أي L1 أو L2 هو. كل شيء هنا، وأنا الآن أحتفظ به في يدي، وهو جاهز لإجراء المزيد من المعاملات على أي حالة أريد الوصول إليها. هذا هو السبب في أن تجربة توزيع الحالة عبر شبكات L2 ليست جيدة. إن نقل الأصول بين سلاسل مختلفة أمر معقد للغاية، وهذا واضح للمستخدمين. هذا هو السبب في أن شبكة L2 لم تثير اهتمامي حقًا أبدًا.
هناك مثال آخر لمشروع معروف لديه نظام بيئي مثير جدًا للاهتمام، حيث اعتمد طريقة أخرى تتمثل في توسيع نطاقه من خلال استخدام بلوكتشينات مختلفة لتطبيقات مختلفة. يمكننا إجراء سرعات معاملات مختلفة على سلاسل مختلفة، وعند الحاجة إلى إجراء عمليات بين تطبيقات مختلفة، يمكننا جسر الأصول بين السلاسل، ولكن يواجه نفس المشكلة. في كل مرة ترغب في استخدام تطبيقات مختلفة، يجب عليك أولاً إجراء عملية الجسر، وهو ما قد يبدو دقيقًا وملحوظًا للمستخدمين، ثم يمكنك استخدام ذلك التطبيق والعودة عبر الجسر. ستجد نفسك تقضي المزيد من الوقت في نقل الأصول من سلسلة إلى أخرى بدلاً من القيام بما تريده حقًا.
على Sui ، خطتنا هي إنشاء قاعدة بيانات كبيرة ، في الواقع ، إنها تحتوي على جميع حالات العقد الموثقة المكررة. بمجرد أن تكمل صفقة ، يمكن استخدام جميع الحالات الموجودة في نفس قاعدة البيانات لإجراء الصفقة التالية ، دون الحاجة إلى تحريك حالة الأصول باستمرار بين L1 و L2.
Q5: Sui Lutris هو الأساس لبروتوكول Sui، ما هو الابتكار الرئيسي الذي يمكن أن يجعل Sui تتمتع بقدرة عالية على المعالجة وتأخير منخفض؟
يتكون Sui Lutris من مفهومين رئيسيين: (1) العديد من العمليات على البلوكتشين لا تحتاج في الواقع إلى إجماع؛ (2) عندما تحتاج فعلاً إلى إجماع، هناك طريقة ذات قدرة عالية جداً على المعالجة تجمع بين هذين المنهجين. Sui Lutris هو جوهر النظام الموزع Sui، ويضمن أنه عند إجراء المعاملات على شبكة موزعة، فإن عقدتي التحقق المختلفتين اللتين تتبعان البروتوكول لن تكون أبداً في حالة عدم توافق. وبالتالي، لن يحدث أن تعتقد عقدة التحقق أنك أنفقت coin وأرسلته إلى Alice، بينما تعتقد عقدة التحقق الأخرى أن نفس coin قد أرسل بالفعل إلى Bob.
طريقتان مختلفتان، واحدة لا تحتاج إلى توافق (مسار سريع)، والأخرى تحتاج إلى توافق (مسار توافق). عندما يكون الشيء الذي تريد التعامل معه ينتمي فقط إليك، مثل شخصية NFT الخاصة بك والقبعة التي تريد دمجها، حتى يتمكن شخصيتك من ارتداء القبعة، من الناحية النظرية، لا ينبغي أن يتعامل الآخرون معها. في هذه الحالات، تستخدم Sui المسار السريع، مما يعني أنه يمكنك التعامل مع أغراضك الخاصة، يمكنك الحصول على نهائية المعاملة دون انتظار التوافق، مما يضمن حدوث المعاملة، وارتداء القبعة على رأس NFT الخاص بك.
لكن في بعض الحالات، لا تتعلق المعاملات فقط بالأشياء التي تخصك، بل يتم مشاركتها من قبل العديد من الأشخاص. على سبيل المثال، إذا كان هناك مزاد لبيع قبعات صغيرة، فإن هذا النوع من المزادات يتم تمثيله في Sui ككائن مشترك. يمكن للناس تقديم العروض، والفائز هو من يقدم أعلى عرض للفوز بالقبعة. هذا المزاد هو كائن لا ينتمي إلى كيان واحد، ويجب أن يتمكن الجميع من تقديم العروض ومشاركة وتحديث حالة أحدث العروض، وهذه الأنواع من العمليات تتطلب إجماعًا إضافيًا. يسمح Sui Lutris بامتلاك كائنات مشتركة وإجراء المعاملات عليها، بحيث يمكنك امتلاك كائنات أخرى، وتغيير حالة الكائن المشترك، أو إنشاء كائن مشترك جديد. إنه يسمح بتعايش مسارين، وتفاعل بين الكائنات الخاصة المملوكة لأفراد معينين والكائنات المشتركة التي يشاركها عدة أشخاص.
تتمتع المسارات المختلفة بفوائد مختلفة. يتمتع المسار السريع للكائنات الخاصة بتأخير منخفض للغاية، حيث يستغرق أقل من ثانية واحدة، وهو سريع للغاية ويمكن توسيعه على نطاق واسع. بينما يكون تأخير مسار الإجماع أعلى، وعادة ما يتجاوز ثانية واحدة، وسعته مرتفعة بشكل ملحوظ، ولكنه أكثر صعوبة في التوسع مقارنةً بالمسار الأول. على Sui، عادة ما يدفع أولئك الذين يدفعون التطبيقات على السلسلة من خلال ملايين المعاملات يوميًا المسار الأول، ويقومون إلى حد كبير بتهيئة هيكل تطبيقاتهم لإجراء أكبر عدد ممكن من المعاملات على الكائنات الخاصة بدلاً من المعاملات المشتركة. من ناحية أخرى، عادةً ما تنفذ البروتوكولات التي تقوم بأعمال معقدة (مثل DeFi) النوع الثاني من المعاملات لأنها يجب أن تجمع بين عطاءات أو سيولة العديد من الأشخاص المختلفين لتنفيذ العمليات.
Q6: هل يمكن لمطوري التطبيقات على Sui تصميم تطبيقاتهم للاستفادة من المسار السريع؟
نعم، بالتأكيد يمكن. أعتقد أن هذه هي الوظيفة الأساسية لمصممي التطبيقات الموسعة. يمكن لمطوري العقود الذكية التحكم تمامًا في ما إذا كانت الكائنات التي يتعاملون بها في العقد هي كائنات فردية خاصة أو كائنات مشتركة في أي لحظة معينة. إحدى الحيل لتوسيع التطبيقات في Sui هي التأكد من أن معظم العمليات تتم في الأساس على الكائنات الخاصة، لأنه يمكن لـ Sui إدارة العديد من العمليات التي تريدها بوقت تأخير منخفض جدًا، مما يوفر تجربة جيدة. يجب أن تكون العمليات الضرورية للألعاب في هذه الفئة، حيث أن تأخيرها منخفض جدًا مقارنة بالعمليات التي تحتاج إلى تدخل عبر حالة مشتركة وكائنات مشتركة. بمجرد النقر، يمكن إتمام المعاملة على الشبكة على الفور.
مصممو العقود الذكية لديهم السيطرة الكاملة على ذلك، حيث يمكنهم بشكل أساسي تحديد بدقة ما هي المعاملات في كل فئة. بالطبع، يمكن أن يعتبر الإصدار الأول من العقد كل شيء حالة مشتركة، وسيتم تمرير كل شيء عبر مسار إجماع ذو تأخير أعلى، ولكن مع الحاجة إلى التوسع، يحتاج المطورون إلى التفكير في مدى إمكانية القيام بذلك دون الحاجة إلى هذه الأجزاء.
Q7: كيف تلعب الكتل القابلة للبرمجة دورًا في هذا؟
يمكن أن تلعب كتل المعاملات القابلة للبرمجة دورًا على المسار السريع أو مسار الإجماع. إذا كانت كتلة المعاملات القابلة للبرمجة تتعلق فقط بالأشياء المملوكة لك، فهذا يعني أنه يمكنك تنفيذ العديد من العمليات في عملية واحدة على سلسلة. على سبيل المثال، افترض أنك تطبيق CEX، حيث يشتري العديد من الأشخاص ويبيعون عملات مختلفة، يمكنك إجراء معاملة واحدة على السلسلة، وهو ما يتوافق نظريًا مع المحتوى الذي يشتريه الناس ويبيعونه. ولكن لأنك بورصة، فهي جميعًا تابعة لك، وبالتالي يمكنك تسوية ألف معاملة في نفس الوقت، وهذا هو المسار السريع. من ناحية أخرى، إذا كانت بعض الأشياء داخل كتلة المعاملات القابلة للبرمجة مشتركة، فإنك تدخل في مسار الإجماع، وفي هذه الحالة سيكون هناك تأخير أكبر قليلاً، ليس أقل من ثانية واحدة ولكن بضع ثوان.
Q8: لقد مرت أكثر من 100 يوم على إطلاق الشبكة الرئيسية، هل أثبت أداء Sui فرضيات بحثك؟ هل هناك شيء فاجأك؟
هناك عدة أشياء تؤكد تصميم Sui، لكن هناك أيضًا بعض الأمور التي تجعل المرء يفكر. واحدة منها هي أنه خلال فترات التداول الكثيفة، وحتى في لحظة معينة، تجاوز حجم التداول اليومي 60 مليون معاملة، حيث كانت معظم المعاملات في المسار السريع. Sui Lutris قابل للتوسع بشكل كبير ويتميز بتأخير منخفض جدًا. قبل ذلك، لم يكن من الواضح ما إذا كان سيتستخدم أحد هذا المسار، لكن عندما كانت هناك حاجة إلى عدد كبير من المعاملات وتأخير منخفض، تم استخدامه، وكان فعالًا للغاية! من السهل رؤية ذلك، إنه هذا الأسلوب. في تلك الأيام، تجاوز حجم تداول Sui
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 20
أعجبني
20
8
إعادة النشر
مشاركة
تعليق
0/400
LiquidatedDreams
· منذ 4 س
لماذا هي مرة أخرى مقالة بحثية
شاهد النسخة الأصليةرد0
NotSatoshi
· 08-13 13:15
ما فائدة هذه العملية الغامضة في البلوكتشين؟
شاهد النسخة الأصليةرد0
BlockDetective
· 08-13 10:09
مرة أخرى تتحدث عن نظريات عميقة، من الأفضل أن تتحدث عن بعض الرؤى القيمة.
شاهد النسخة الأصليةرد0
RooftopVIP
· 08-13 10:07
حصلت على الكثير من الأوراق العلمية ولا أستطيع التحمل بعد الآن
شاهد النسخة الأصليةرد0
GateUser-7b078580
· 08-13 10:06
ما هي فائدة الأداء العالي، الحد الأقصى لـ tps هو 7.8k فقط.
تفسير خبراء Sui لتصميم البلوكتشين عالي الأداء: التطبيق الابتكاري لمسارات السرعة ومسارات الإجماع
مؤخراً، أجرينا مقابلة مع خبير في البلوكتشين، لاستكشاف تعقيد وقابلية توسيع بنية Sui التحتية، وكيف يسهم نظام معالجة المعاملات في Sui في تعزيز شبكة عالية الأداء. هذا الخبير هو أستاذ في مجال الأمن والخصوصية في جامعة معروفة.
التالي هو محتوى المقابلة هذه:
س1: أنت من المجال الأكاديمي، هل يمكنك تقديم لمحة عن تركيز بحثك؟
أنا أستاذ في جامعة معينة، وتركز أبحاثي بشكل عام على الأمان والخصوصية. في أوائل القرن العشرين، أجريت الكثير من الأبحاث حول أنظمة الند للند والأنظمة المجهولة، وكانت معظم هذه الأنظمة أنظمة موزعة كبيرة تركز على التخزين. عندما أصبحت البلوكتشين أكثر تركيزًا على التنفيذ، وخاصة تمثيلها في الإيثيريوم، تولدت لدي اهتمام بالدفاتر الموزعة والبلوكتشين وكيفية تنفيذ العقود الذكية. كنت على دراية كبيرة بخصائصها غير المصرح بها من خلال عملي في أنظمة الند للند في وقت مبكر. لذا، بدأت مجموعة الأبحاث في الجامعة بالعمل على كيفية بناء أنظمة ذات أداء أعلى. أسسنا شركة لتجارية بعض أفكارنا، وفيما بعد تم الاستحواذ على الفريق من قبل شركة تقنية كبيرة. ثم ساعدنا تلك الشركة في تقديم حلول لتوسيع البلوكتشين. ولكن عندما لم تحقق تلك الحلول تقدمًا، تركت الشركة وواصلت البحث عن فرص أخرى لتحقيق فكرة البلوكتشين عالية الأداء.
Q2: أنت ما زلت أستاذًا، فما رأيك في الفرق بين التطبيق والبحث؟
في الواقع لا يوجد فرق كبير. عندما نقوم بالبحث، سنأخذ بعين الاعتبار جميع الاحتمالات لتحقيق أهداف محددة، مثل بناء بلوكتشين عالي الأداء أو ميزات معينة. بالطبع، عند بناء بلوكتشين أو اختيار الميزات المحددة التي سيتم استخدامها في النظام الفعلي، يجب علينا اختيار واحدة من هذه الاحتمالات. يجب علينا باستمرار اتخاذ القرارات، أي من هذه الأفكار الجيدة هو الأكثر فائدة للناس؟ أيها يبحث عنه الناس؟ ما هي العقبات التي تواجه اعتماد البلوكتشين؟ ما الذي يمنع الناس من تحقيق ما يريدون القيام به؟ عند بناء النظام، ستظل تأخذ بعين الاعتبار جميع الاحتمالات، وتحاول فهم الحالات المحتملة من الأدبيات الأكاديمية، ثم اختيار الأكثر صلة. هذا ليس مجرد اهتمام بالمعرفة، بل هو خلق قيمة للمستخدمين.
Q3: كيف تحدد المشاكل التي يجب حلها عند الانتقال من النظرية إلى التطبيق العملي؟
المشكلة الرئيسية التي أدرسها هي كيفية توسيع وظائف مختلفة للبلوكتشين. أركز على الجوانب النظامية للبلوكتشين، مثل كيفية زيادة حجم المعاملات وتقليل التأخير. هذه المشكلة واضحة، كلما رأينا عقدة معينة على منصة ما تصبح شديدة الشعبية، فإن تلك المنصة لا تستطيع تحمل هذا الحجم الكبير من المعاملات، مما يؤدي إلى ازدحام المعاملات وارتفاع الرسوم بشكل كبير. في كل مرة يحقق فيها البلوكتشين النجاح، نرى أن حجم المعاملات التي يمكن معالجتها يتجاوز القدرة الحالية. لذلك، من الواضح أن المشكلة تكمن في عدم وجود القدرة الكافية لتلبية ما يريده الناس من هذه البلوكتشينات. هذا ليس مجرد فكرة لدينا، فنحن نرى هذه الحالة تتكرر مرة تلو الأخرى. لفترة من الزمن، كان يُعتبر هذا تحديًا ذا قيمة، ليس فقط في فريقي، بل في الواقع في جميع الأوساط الأكاديمية التي تدرس البلوكتشين، حيث يحاول الجميع حل هذه المشكلة بطرق مختلفة. الآن، تم تطوير عدد كبير من التقنيات لتوسيع قدرة البلوكتشين لمواجهة هذه التحديات. لكن في ذلك الوقت، كان معروفًا أن العديد من الأشخاص يحاولون حلها بطرق مختلفة.
س4: شبكة L2 هي وسيلة اقترحها الناس لحل مشكلة التوسع، ما الفرق والفوائد بينها وبين إنشاء شبكة L1 جديدة مثل Sui؟
L2 هو حل للتوسع في نظام بيئي معين. لكن بالنسبة لمطوري التطبيقات، فإن استخدام شبكة L2 قد يكون معقدًا قليلاً. عندما تحاول شبكة L2 التفاعل مع L1، يجب إجراء نشاط الجسر، على الرغم من أن هذا ينطبق على أي علاقة L2/L1. يجب أن يتم عكس الحالة التي تمثل coin أو الأصول أو أي شيء آخر في L1 في L2، والعكس صحيح. بالإضافة إلى ذلك، يجب أن يكون لدى L2 بعض الآليات بحيث يمكن لـ L1 التحقق من كل ما يحدث فيه. لكن هذه هي الجزء الأول فقط، أي أن أي أصول موجودة على L1 تحتاج إلى الانتقال إلى L2، ويجب أن تحدث بعض الأنشطة على L2، ثم بطريقة ما يجب إعادة الأصول إلى L1. هذا أمر مرهق.
بالنسبة للأصول القابلة للاستبدال مثل tokens، كان هذا النشاط الجسري سلسًا إلى حد ما، لأن الناس لديهم حسابان ووسيط جسر. ولكن بالنسبة للأصول الأكثر عمومية، لم يكن الأمر كذلك. لاستخدام شبكة L2 المطورة على L1 لتطبيقات أكثر تعقيدًا من tokens، تحتاج إلى وجود عقود ذكية على كلا الجانبين، واحدة للتعدين (mint) وأخرى للحرق (burn). يجب أن تتنقل بين نظامين بيئيين مختلفين، وهذا هو النشاط المخصص لكل عقد. لا يمكنك ببساطة أن تقول، سأقوم بإنشاء شبكة L2 ثم أنقل جميع الأصول، ثم أتصرف كما أريد، ثم أعيدها، لا يوجد مثل هذا المفهوم. إنها عملية يدوية، ومن السهل جدًا أن تخطئ. لذلك، ليست تجربة جيدة. تخيل أنك تمتلك أصولًا في شبكات L2 مختلفة، ولديك هذه العقود الذكية المخصصة في شبكات L2 المختلفة. في كل مرة تريد فيها إجراء عملية على حالة تقع في شبكة L2 أخرى، يجب عليك الانتقال عبر الجسر مرة أخرى إلى L1، ثم العودة إلى L2. لا يمكنك ببساطة أن تقول، لقد قمت للتو ببعض الأشياء على هذه البلوكتشين، والآن أريد أن أفعل أشياء أخرى على بلوكتشين أخرى، ولا أحتاج إلى التفكير في أي L1 أو L2 هو. كل شيء هنا، وأنا الآن أحتفظ به في يدي، وهو جاهز لإجراء المزيد من المعاملات على أي حالة أريد الوصول إليها. هذا هو السبب في أن تجربة توزيع الحالة عبر شبكات L2 ليست جيدة. إن نقل الأصول بين سلاسل مختلفة أمر معقد للغاية، وهذا واضح للمستخدمين. هذا هو السبب في أن شبكة L2 لم تثير اهتمامي حقًا أبدًا.
هناك مثال آخر لمشروع معروف لديه نظام بيئي مثير جدًا للاهتمام، حيث اعتمد طريقة أخرى تتمثل في توسيع نطاقه من خلال استخدام بلوكتشينات مختلفة لتطبيقات مختلفة. يمكننا إجراء سرعات معاملات مختلفة على سلاسل مختلفة، وعند الحاجة إلى إجراء عمليات بين تطبيقات مختلفة، يمكننا جسر الأصول بين السلاسل، ولكن يواجه نفس المشكلة. في كل مرة ترغب في استخدام تطبيقات مختلفة، يجب عليك أولاً إجراء عملية الجسر، وهو ما قد يبدو دقيقًا وملحوظًا للمستخدمين، ثم يمكنك استخدام ذلك التطبيق والعودة عبر الجسر. ستجد نفسك تقضي المزيد من الوقت في نقل الأصول من سلسلة إلى أخرى بدلاً من القيام بما تريده حقًا.
على Sui ، خطتنا هي إنشاء قاعدة بيانات كبيرة ، في الواقع ، إنها تحتوي على جميع حالات العقد الموثقة المكررة. بمجرد أن تكمل صفقة ، يمكن استخدام جميع الحالات الموجودة في نفس قاعدة البيانات لإجراء الصفقة التالية ، دون الحاجة إلى تحريك حالة الأصول باستمرار بين L1 و L2.
Q5: Sui Lutris هو الأساس لبروتوكول Sui، ما هو الابتكار الرئيسي الذي يمكن أن يجعل Sui تتمتع بقدرة عالية على المعالجة وتأخير منخفض؟
يتكون Sui Lutris من مفهومين رئيسيين: (1) العديد من العمليات على البلوكتشين لا تحتاج في الواقع إلى إجماع؛ (2) عندما تحتاج فعلاً إلى إجماع، هناك طريقة ذات قدرة عالية جداً على المعالجة تجمع بين هذين المنهجين. Sui Lutris هو جوهر النظام الموزع Sui، ويضمن أنه عند إجراء المعاملات على شبكة موزعة، فإن عقدتي التحقق المختلفتين اللتين تتبعان البروتوكول لن تكون أبداً في حالة عدم توافق. وبالتالي، لن يحدث أن تعتقد عقدة التحقق أنك أنفقت coin وأرسلته إلى Alice، بينما تعتقد عقدة التحقق الأخرى أن نفس coin قد أرسل بالفعل إلى Bob.
طريقتان مختلفتان، واحدة لا تحتاج إلى توافق (مسار سريع)، والأخرى تحتاج إلى توافق (مسار توافق). عندما يكون الشيء الذي تريد التعامل معه ينتمي فقط إليك، مثل شخصية NFT الخاصة بك والقبعة التي تريد دمجها، حتى يتمكن شخصيتك من ارتداء القبعة، من الناحية النظرية، لا ينبغي أن يتعامل الآخرون معها. في هذه الحالات، تستخدم Sui المسار السريع، مما يعني أنه يمكنك التعامل مع أغراضك الخاصة، يمكنك الحصول على نهائية المعاملة دون انتظار التوافق، مما يضمن حدوث المعاملة، وارتداء القبعة على رأس NFT الخاص بك.
لكن في بعض الحالات، لا تتعلق المعاملات فقط بالأشياء التي تخصك، بل يتم مشاركتها من قبل العديد من الأشخاص. على سبيل المثال، إذا كان هناك مزاد لبيع قبعات صغيرة، فإن هذا النوع من المزادات يتم تمثيله في Sui ككائن مشترك. يمكن للناس تقديم العروض، والفائز هو من يقدم أعلى عرض للفوز بالقبعة. هذا المزاد هو كائن لا ينتمي إلى كيان واحد، ويجب أن يتمكن الجميع من تقديم العروض ومشاركة وتحديث حالة أحدث العروض، وهذه الأنواع من العمليات تتطلب إجماعًا إضافيًا. يسمح Sui Lutris بامتلاك كائنات مشتركة وإجراء المعاملات عليها، بحيث يمكنك امتلاك كائنات أخرى، وتغيير حالة الكائن المشترك، أو إنشاء كائن مشترك جديد. إنه يسمح بتعايش مسارين، وتفاعل بين الكائنات الخاصة المملوكة لأفراد معينين والكائنات المشتركة التي يشاركها عدة أشخاص.
تتمتع المسارات المختلفة بفوائد مختلفة. يتمتع المسار السريع للكائنات الخاصة بتأخير منخفض للغاية، حيث يستغرق أقل من ثانية واحدة، وهو سريع للغاية ويمكن توسيعه على نطاق واسع. بينما يكون تأخير مسار الإجماع أعلى، وعادة ما يتجاوز ثانية واحدة، وسعته مرتفعة بشكل ملحوظ، ولكنه أكثر صعوبة في التوسع مقارنةً بالمسار الأول. على Sui، عادة ما يدفع أولئك الذين يدفعون التطبيقات على السلسلة من خلال ملايين المعاملات يوميًا المسار الأول، ويقومون إلى حد كبير بتهيئة هيكل تطبيقاتهم لإجراء أكبر عدد ممكن من المعاملات على الكائنات الخاصة بدلاً من المعاملات المشتركة. من ناحية أخرى، عادةً ما تنفذ البروتوكولات التي تقوم بأعمال معقدة (مثل DeFi) النوع الثاني من المعاملات لأنها يجب أن تجمع بين عطاءات أو سيولة العديد من الأشخاص المختلفين لتنفيذ العمليات.
Q6: هل يمكن لمطوري التطبيقات على Sui تصميم تطبيقاتهم للاستفادة من المسار السريع؟
نعم، بالتأكيد يمكن. أعتقد أن هذه هي الوظيفة الأساسية لمصممي التطبيقات الموسعة. يمكن لمطوري العقود الذكية التحكم تمامًا في ما إذا كانت الكائنات التي يتعاملون بها في العقد هي كائنات فردية خاصة أو كائنات مشتركة في أي لحظة معينة. إحدى الحيل لتوسيع التطبيقات في Sui هي التأكد من أن معظم العمليات تتم في الأساس على الكائنات الخاصة، لأنه يمكن لـ Sui إدارة العديد من العمليات التي تريدها بوقت تأخير منخفض جدًا، مما يوفر تجربة جيدة. يجب أن تكون العمليات الضرورية للألعاب في هذه الفئة، حيث أن تأخيرها منخفض جدًا مقارنة بالعمليات التي تحتاج إلى تدخل عبر حالة مشتركة وكائنات مشتركة. بمجرد النقر، يمكن إتمام المعاملة على الشبكة على الفور.
مصممو العقود الذكية لديهم السيطرة الكاملة على ذلك، حيث يمكنهم بشكل أساسي تحديد بدقة ما هي المعاملات في كل فئة. بالطبع، يمكن أن يعتبر الإصدار الأول من العقد كل شيء حالة مشتركة، وسيتم تمرير كل شيء عبر مسار إجماع ذو تأخير أعلى، ولكن مع الحاجة إلى التوسع، يحتاج المطورون إلى التفكير في مدى إمكانية القيام بذلك دون الحاجة إلى هذه الأجزاء.
Q7: كيف تلعب الكتل القابلة للبرمجة دورًا في هذا؟
يمكن أن تلعب كتل المعاملات القابلة للبرمجة دورًا على المسار السريع أو مسار الإجماع. إذا كانت كتلة المعاملات القابلة للبرمجة تتعلق فقط بالأشياء المملوكة لك، فهذا يعني أنه يمكنك تنفيذ العديد من العمليات في عملية واحدة على سلسلة. على سبيل المثال، افترض أنك تطبيق CEX، حيث يشتري العديد من الأشخاص ويبيعون عملات مختلفة، يمكنك إجراء معاملة واحدة على السلسلة، وهو ما يتوافق نظريًا مع المحتوى الذي يشتريه الناس ويبيعونه. ولكن لأنك بورصة، فهي جميعًا تابعة لك، وبالتالي يمكنك تسوية ألف معاملة في نفس الوقت، وهذا هو المسار السريع. من ناحية أخرى، إذا كانت بعض الأشياء داخل كتلة المعاملات القابلة للبرمجة مشتركة، فإنك تدخل في مسار الإجماع، وفي هذه الحالة سيكون هناك تأخير أكبر قليلاً، ليس أقل من ثانية واحدة ولكن بضع ثوان.
Q8: لقد مرت أكثر من 100 يوم على إطلاق الشبكة الرئيسية، هل أثبت أداء Sui فرضيات بحثك؟ هل هناك شيء فاجأك؟
هناك عدة أشياء تؤكد تصميم Sui، لكن هناك أيضًا بعض الأمور التي تجعل المرء يفكر. واحدة منها هي أنه خلال فترات التداول الكثيفة، وحتى في لحظة معينة، تجاوز حجم التداول اليومي 60 مليون معاملة، حيث كانت معظم المعاملات في المسار السريع. Sui Lutris قابل للتوسع بشكل كبير ويتميز بتأخير منخفض جدًا. قبل ذلك، لم يكن من الواضح ما إذا كان سيتستخدم أحد هذا المسار، لكن عندما كانت هناك حاجة إلى عدد كبير من المعاملات وتأخير منخفض، تم استخدامه، وكان فعالًا للغاية! من السهل رؤية ذلك، إنه هذا الأسلوب. في تلك الأيام، تجاوز حجم تداول Sui