فهم الوحدة

متوسط5/21/2024, 2:17:47 AM
لقد كانت قابلية توسيع المعاملات موضوعًا ساخنًا دائمًا، ويستكشف هذا المقال كيف يساعد Monad في توسيع TPS (عدد المعاملات في الثانية)، جنبًا إلى جنب مع شرح مفصل لكيفية عمله. العقبة ليست في إعادة التنفيذ؛ العقبة هي الوصول إلى ذاكرة Ethereum. طريقة Ethereum في تخزين الحالة في قاعدة البيانات تجعل الوصول إلى الحالة صعبًا (مستهلكًا للوقت وبالتالي مكلفًا)، وهو تحسين آخر من قبل Monad.

مرحبا،

قد كانت قدرة التحويل محور حديث البلدة. لقد كنا نستكشف كيف يساعد Monad في زيادة TPS خلال الأسابيع القليلة الماضية.

الملاحظة أدناه هي تفصيل لكيفية عمل Monad مكتوبة بواسطة @desh_saurabh. النظر في التسجيل في Gate.ioDecentralised.coإذا كنت تستمتع بقراءة شروحات مدعومة بالبيانات حول كل شيء يتعلق بـ Web3. أراك على الجانب الآخر!

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

ماذا نفعل إذا أردنا زيادة TPS؟

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

موناد، وهو L1 جديد متوافق مع EVM تم جمع 225 مليون دولار مؤخرًا، يقوم ببناء EVM من الصفر بدلاً من استخدامه كما هو. اختار هذا النهج الثالث لزيادة قابلية التوسع.

نناقش بعض التغييرات الهامة التي يقدمها Monad.

التنفيذ المتوازي

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

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

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

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

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

كيف؟ يقوم بأداء شيء يُسمى التنفيذ المتوازي المتفائل. يمكن للبروتوكول تنفيذ المعاملات المستقلة فقط بشكل متوازٍ. على سبيل المثال، تعتبر 4 معاملات برصيد جويل عبارة عن 1 إثريوم -

  1. جويل يرسل 0.2 ETH إلى سوراب.
  2. سيد يطبع NFT.
  3. جويل يرسل 0.1 ETH إلى سيد.
  4. يشتري شلوك بيبي.

جميع هذه المعاملات يتم تنفيذها بشكل متوازٍ مع النتائج المعلقة التي يتم تنفيذها واحدة تلو الأخرى. يتم إعادة تنفيذ المعاملات إذا تعارضت النتائج المعلقة مع مداخل المعاملة الأصلية. المعاملات 2 و 4 ليس لديها نتائج معلقة تتعارض مع مداخل المعاملات الأخرى لأنها مستقلة عن بعضها البعض. ولكن 1 و 3 ليستا مستقلتين.

لاحظ أنه بما أن جميع الصفقات الأربعة تبدأ من نفس الحالة، فإن الصفقة التي تهمنا هنا هي رصيد جويل من 1 إث. نتيجة لإرسال جويل 0.2 إث تكون 0.8 إث. بعد أن يرسل جويل 0.1 إث إلى سيد، يكون رصيده 0.9 إث. يتم تأكيد النتائج واحدة تلو الأخرى، مما يضمن عدم تعارض النواتج مع أي من المداخل. بعد تأكيد النتيجة المعلقة من 1، يكون رصيد جويل الجديد 0.8 إث.

هذا الإخراج يتعارض مع إدخال 3. لذلك يتم تنفيذ 3 مرة أخرى الآن بإدخال 0.8 ETH. بعد تنفيذ 3، رصيد جويل هو 0.7 ETH.

MonadDb

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

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

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

بيان:

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

  2. تنويه: تعبر وجهات النظر والآراء المعبر عنها في هذه المقالة فقط عن وجهات نظر الكاتب الشخصية ولا تشكل أي نصيحة استثمارية.

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

แชร์

เนื้อหา

فهم الوحدة

متوسط5/21/2024, 2:17:47 AM
لقد كانت قابلية توسيع المعاملات موضوعًا ساخنًا دائمًا، ويستكشف هذا المقال كيف يساعد Monad في توسيع TPS (عدد المعاملات في الثانية)، جنبًا إلى جنب مع شرح مفصل لكيفية عمله. العقبة ليست في إعادة التنفيذ؛ العقبة هي الوصول إلى ذاكرة Ethereum. طريقة Ethereum في تخزين الحالة في قاعدة البيانات تجعل الوصول إلى الحالة صعبًا (مستهلكًا للوقت وبالتالي مكلفًا)، وهو تحسين آخر من قبل Monad.

مرحبا،

قد كانت قدرة التحويل محور حديث البلدة. لقد كنا نستكشف كيف يساعد Monad في زيادة TPS خلال الأسابيع القليلة الماضية.

الملاحظة أدناه هي تفصيل لكيفية عمل Monad مكتوبة بواسطة @desh_saurabh. النظر في التسجيل في Gate.ioDecentralised.coإذا كنت تستمتع بقراءة شروحات مدعومة بالبيانات حول كل شيء يتعلق بـ Web3. أراك على الجانب الآخر!

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

ماذا نفعل إذا أردنا زيادة TPS؟

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

موناد، وهو L1 جديد متوافق مع EVM تم جمع 225 مليون دولار مؤخرًا، يقوم ببناء EVM من الصفر بدلاً من استخدامه كما هو. اختار هذا النهج الثالث لزيادة قابلية التوسع.

نناقش بعض التغييرات الهامة التي يقدمها Monad.

التنفيذ المتوازي

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

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

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

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

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

كيف؟ يقوم بأداء شيء يُسمى التنفيذ المتوازي المتفائل. يمكن للبروتوكول تنفيذ المعاملات المستقلة فقط بشكل متوازٍ. على سبيل المثال، تعتبر 4 معاملات برصيد جويل عبارة عن 1 إثريوم -

  1. جويل يرسل 0.2 ETH إلى سوراب.
  2. سيد يطبع NFT.
  3. جويل يرسل 0.1 ETH إلى سيد.
  4. يشتري شلوك بيبي.

جميع هذه المعاملات يتم تنفيذها بشكل متوازٍ مع النتائج المعلقة التي يتم تنفيذها واحدة تلو الأخرى. يتم إعادة تنفيذ المعاملات إذا تعارضت النتائج المعلقة مع مداخل المعاملة الأصلية. المعاملات 2 و 4 ليس لديها نتائج معلقة تتعارض مع مداخل المعاملات الأخرى لأنها مستقلة عن بعضها البعض. ولكن 1 و 3 ليستا مستقلتين.

لاحظ أنه بما أن جميع الصفقات الأربعة تبدأ من نفس الحالة، فإن الصفقة التي تهمنا هنا هي رصيد جويل من 1 إث. نتيجة لإرسال جويل 0.2 إث تكون 0.8 إث. بعد أن يرسل جويل 0.1 إث إلى سيد، يكون رصيده 0.9 إث. يتم تأكيد النتائج واحدة تلو الأخرى، مما يضمن عدم تعارض النواتج مع أي من المداخل. بعد تأكيد النتيجة المعلقة من 1، يكون رصيد جويل الجديد 0.8 إث.

هذا الإخراج يتعارض مع إدخال 3. لذلك يتم تنفيذ 3 مرة أخرى الآن بإدخال 0.8 ETH. بعد تنفيذ 3، رصيد جويل هو 0.7 ETH.

MonadDb

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

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

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

بيان:

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

  2. تنويه: تعبر وجهات النظر والآراء المعبر عنها في هذه المقالة فقط عن وجهات نظر الكاتب الشخصية ولا تشكل أي نصيحة استثمارية.

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

เริ่มตอนนี้
สมัครและรับรางวัล
$100