مقدمة Layer1 | دليل بسيط لفهم النقاط البارزة في شبكة Sei Network V2

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

جدول المحتويات

ما هي شبكة Sei؟

Sei: ولدت للمعاملات

آلية المعالجة شبه المتوازية

اتجاه تحديث Sei v2

الجهاز الافتراضي: دعم EVM

التصميم الأصلي: يستخدم Sei v1 آلة CosmWasm الافتراضية

تركيز التحديث: Sei v2 يدمج دعم EVM

تحسين آلية المعالجة شبه المتوازية

التصميم الأصلي: يتطلب Sei v1 نطاق موارد محددًا للعقود

تركيز التحديث: يبسط Sei v2 آلية التنفيذ الموازي للعقد

تحسين بنية تخزين دفتر الأستاذ: SeiDB

التصميم الأصلي: Sei v1 يخزن كميات كبيرة من بيانات الدولة

تركيز التحديث: Sei v2 يفصل هيكل دفتر الأستاذ

آلية الإجماع

Sei تتنافس في الخطوط الأمامية من خلال المقايضات

ما هي شبكة Sei؟

Sei: ولدت للمعاملات

تتمتع Sei Network بموقع واضح في السوق، مما يوفر بيئة فعالة لتداول الأصول الافتراضية. بالإضافة إلى الرموز الشائعة، تشمل الأصول الافتراضية NFTs والرسوم البيانية الاجتماعية وعناصر اللعبة، بهدف إنشاء أفضل تجربة للمستخدم من خلال توفير بيئة أساسية مخصصة للمعاملات.

هناك العديد من أنواع معاملات الأصول الافتراضية(المصدر)

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

الإعلان - يرجى التمرير لأسفل إذا لم يتم الانتهاء من النص

• المعاملات غير المباشرة: يقوم معظم المستخدمين في السلسلة بإجراء معاملات الأصول الافتراضية باستخدام Uniswap و OpenSea.
• المعاملات المباشرة: المشاريع التي تخضع بشكل مباشر للمعاملات هي في الغالب ألعاب أو مشاريع NFT، مثل Axie Infinity أو BAYC.

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

آلية المعالجة شبه المتوازية

شبكة Sei Network الرئيسية متصلة بالإنترنت منذ أكثر من ثلاثة أشهر. وفقًا للبيانات الرسمية، يبلغ متوسط الشبكة حاليًا 20,000 TPS مع وقت تأكيد نهائي يبلغ 390 مللي ثانية. يدعي الفريق أنها الشبكة الأكثر كفاءة في الصناعة، وذلك بفضل آلية المعالجة المتوازية المبتكرة.

عندما لا تتضمن المعاملات على Sei blockchain نفس الموارد (العناوين)، يمكن معالجة جميع المعاملات في وقت واحد دون الحاجة إلى طلب تسلسلات المعاملات. هذا يحسن بشكل كبير الكفاءة التشغيلية للشبكة.

اتجاه تحديث Sei v2

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

التحديثات الرئيسية لشبكة Sei Network v2 (المصدر)

قال المؤسس Jayendra أن Sei v2 يضيف ميزات جديدة فقط ولن يؤثر على الميزات الحالية. لا يحتاج المستخدمون والمطورون إلى إجراء أي عمليات إضافية لهذا التحديث.

يحتوي اقتراح Sei v2 بشكل أساسي على ثلاثة تحديثات:

• دعم EVM
• تحسين آلية المعالجة المتوازية
• تحسين بنية تخزين دفتر الأستاذ

من المتوقع أن يكتمل هذا التحديث في الربع الأول من عام 2024.

الجهاز الافتراضي: يدعم EVM

التصميم الأصلي: يستخدم Sei v1 آلة CosmWasm الافتراضية

تم تصميم Sei باستخدام Cosmos SDK ويستخدم الجهاز الافتراضي CosmWasm، وهو مكون يوفره الأخير. CosmWasm هو مكون آلة افتراضية تم تصميمه خصيصًا لنظام Cosmos البيئي. الطبقة الأساسية هي WebAssembly (Wasm) وتم تسميتها باسمها. يمكن للبلوكشين التي تم إنشاؤها باستخدام Cosmos SDK إضافة CosmWasm إلى سلسلتها دون تعديل المنطق الحالي.

يمكن لـ WebAssembly دعم مجموعة متنوعة من لغات البرمجة الشائعة، بما في ذلك Rust و C و C ++ وما إلى ذلك، لذلك إذا كنت مطورًا لـ Rust، فيمكنك بسهولة كتابة عقود ذكية على CosmWasm، لذلك يجذب Sei المطورين خارج الدائرة.

أبرز التحديثات: سيدعم Sei v2 تكامل EVM

ومع ذلك، وجد فريق Sei Labs أنه على الرغم من المشاركة العالية للمطورين، إلا أنهم فقدوا النظام البيئي لـ Ethereum Virtual Machine (EVM). EVM هي الآلة الافتراضية المستخدمة في معظم تطبيقات ومنتجات الصناعة الحالية. قد يؤدي فقدان هذا النظام البيئي إلى إعاقة التطور السريع لشركة Sei في هذه المرحلة، على سبيل المثال، لا يمكن لمشاريع Ethereum الحالية أن تتفرع إلى نظام Sei البيئي.

لمعالجة هذه المشكلة، قام الفريق بتحديث مستودع التعليمات البرمجية المخصص، Core Sei Binary، حيث قدم واجهة مخصصة لعقدتي EVM RPC و Geth. يتيح ذلك نشر معاملات EVM بسلاسة والتفاعل مع شبكة Sei.

استند اختيار Geth إلى استقرارها النسبي. ذكر Jayendra Jog أنه حاليًا، تستخدم 80٪ من عقد Ethereum Geth، وهي تدعم التوافق الكامل لرمز البايت الخاص بـ EVM. هذا يعني أنه يمكن للمطورين نسخ العقود من EVMs الأخرى وتشغيلها بسلاسة على شبكة Sei.

التحديثات الرئيسية لشبكة Sei Network v2 (المصدر)

سيستخدم Sei v2 أيضًا EVM RPC، مما يسمح للمستخدمين باستخدام عمليات المحفظة بسهولة مثل Metamask، بينما يمكن للمطورين الاستمرار في استخدام أدوات مثل Foundry و Remix و Hardhat.

لذلك، سيتيح Sei v2 إمكانية التركيب بين معاملات EVM و Cosmwasm. يحتوي Sei's Geth على مترجم مسبق يسمح باستدعاء عقود Cosmwasm، ويمكن لوحدة Sei wasmd أيضًا استدعاء عقود EVM بشكل عكسي، مما سيجعل الأصول في النظام البيئي لشركة Sei أكثر قيمة.

تحسين آلية المعالجة المتوازية Sei

التصميم الأصلي: يحتاج عقد Sei v1 إلى تحديد فئات الموارد

في شبكة Sei Network الأصلية، لكي تتم معالجة المعاملات بالتوازي، يحتاج المطورون إلى تعلم كيفية «تحديد استخدام موارد العقد». عندما يكتب المطورون عقودًا على Sei، يُطلب منهم تحديد الموارد التي قد يحتاجها العقد للوصول إليها واستقلاليتها. يعد هذا أمرًا بالغ الأهمية لشركة Sei للتمييز بسرعة بين استقلالية الموارد عند تنفيذ العقود، وتحديد ما إذا كان سيتم معالجة المعاملات بالتوازي أو بترتيب معين.

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

تركيز التحديث: يبسط Sei v2 آلية التشغيل الموازي للعقد

سيعمل Sei v2 على تحسين آلية المعالجة المتوازية ولم يعد يطلب من المطورين تحديد التبعيات يدويًا. بدلاً من ذلك، يمكنها التعامل مع آلية الموازاة بنفسها، مما يقلل العبء على المطورين.

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

يعالج Sei v2 تلقائيًا مشكلات تداخل الموارد (المصدر)

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

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

لحسن الحظ، وفقًا لبيانات إيثريوم التاريخية، فإن حوالي ١٥٪ فقط من المعاملات ستتداخل فعليًا في الموارد وستحتاج إلى إعادة معالجتها بالترتيب، لذلك قيّم الفريق أن الأداء العام لـ Sei سيظل يتحسن بشكل كبير.

تحسين بنية تخزين دفتر الأستاذ: SeiDB

التصميم الأصلي: يخزن Sei v1 كمية كبيرة من بيانات الحالة

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

تكلفة المعالجة المتوازية هي تسجيل العديد من بيانات الحالة الوسيطة غير الصالحة. وفقًا لـ RFC الذي اقترحه فريق Sei، على سبيل المثال، في عقدة testnet atlantic-2، من أصل 25 غيغابايت من البيانات المخزنة، تحتوي 10 غيغابايت فقط على معلومات المعاملات المفيدة. ينتج عن هذا استخدام غير فعال لمساحة قرص العقدة.

نظرًا لتضخم البيانات، ينمو استخدام القرص لعقد Sei بسرعة. يزداد استخدام القرص الصلب للعقدة الأرشيفية على atlantic-2 بأكثر من 150 غيغابايت في اليوم ويتجاوز 1 تيرابايت في الأسبوع. مع استمرار حالة السلسلة في النمو، سيزداد معدل نمو مساحة التخزين أيضًا (يصبح أسرع).

سوف يسبب العديد من المشاكل:

• ستصبح تكلفة صيانة العقد أعلى وأعلى
• ستصبح عمليات قاعدة البيانات أبطأ وأبطأ
• لا يمكن تشغيل عقد RPC لفترات طويلة من الوقت حيث يمتلئ القرص بسرعة

إلى جانب تصميم المعالجة المتوازية لمعالجة v2 المستقبلية ذهابًا وإيابًا وإعادة التحقق، ستتغير حالة الشبكة الإجمالية بشكل متكرر، مما يؤدي إلى زيادة كبيرة في كمية بيانات الحالة.

تركيز التحديث: هيكل دفتر الأستاذ المنفصل Sei v2

يحتوي Sei v2 أيضًا على آلية تخزين محسّنة لحل المشكلات المذكورة أعلاه لمنع توسيع بيانات الحالة وزيادة سرعة قراءة البيانات من قبل جميع العقد.

يقسم Sei v2 دفتر الأستاذ الخاص بتخزين الحالة إلى نوعين، يُطلق عليهما SeiDB:

• التزام الدولة (SC): يسجل معلومات شجرة MeMiaVL
• متجر الدولة (SS): يسجل معلومات كاملة

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

يقلل Sei v2 من عبء نمو البيانات على نقاط التحقق (المصدر)

مع التحسينات في SeiDB، شهدت Sei تحسينات في جوانب مختلفة من الأداء. يتضمن ذلك زيادة بمقدار 100 مرة في وقت إرسال الكتلة، وضغط توليد البيانات اليومية من 100 غيغابايت إلى 5 غيغابايت، وتحسين 10 أضعاف في وقت اللحاق بالركب لجميع العقد أو العقد التي تتطلب معلومات المزامنة.

آلية الإجماع

لم تغير Sei Network v2 آلية الإجماع الأصلية الخاصة بها وتستمر في الحفاظ على تصميم Twin Turbo. من خلال تعزيز واجهة توافق Cosmos Tendermint ABCI، تم تقليل وقت تأكيد الكتلة بشكل كبير.

Sei تدخل مسابقة الدرجة الأولى

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

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

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

(ملاحظة: لا تشكل هذه المقالة أي نصيحة استثمارية.)

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

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