أصدرت Sei ورقة بيضاء جديدة تتناول آخر تحديثات Giga. وجد معظم القراء أن المحتوى الفني العميق المكون من 17 صفحة يصعب قراءته. لذلك، ستشرح هذه المقالة محتوى هذا التحديث وكيفية تحسين أداء blockchain على مستويات مختلفة.
حول توليد الكتل بالتنفيذ غير المتزامن
الفكرة الرئيسية والأساسية لـ Giga كما يلي:
"إذا كانت قائمة معاملاتنا مرتبة وكانت الحالة الأولية لسلسلة الكتل متسقة، وجميع العقد الصادقة تعالج هذه المعاملات بنفس الترتيب، فإن العقد ستصل إلى نفس الحالة النهائية."
في هذه الحالة، تعتمد النتيجة فقط على الحالة الأولية وترتيب المعاملات. وهذا يعني أن التوافق يحتاج فقط إلى الاتفاق على ترتيب المعاملات داخل الكتلة، ويمكن لكل عقدة حساب الحالة النهائية بشكل مستقل.
في هذا النموذج، يتم فصل الإجماع عن التنفيذ، مما يسمح بتنفيذ الكتل بشكل غير متزامن.
بمجرد أن يتم تأكيد الكتلة نهائيًا، ستقوم العقدة بمعالجتها وتقديم حالتها في الكتل اللاحقة.
ثم يتم التحقق من الكتلة من خلال توافق الحالة لضمان أن جميع العقد قد حسبت الحالة النهائية الصحيحة.
تفصيل مهم هنا هو أن التنفيذ مع الإجماع (التوليد) يحدثان بالتوازي. يقوم العقد عند تنفيذ حساب كتلة ما، بتلقي كتل أخرى أيضاً.
لذلك، يتم تنفيذ الكتل فعليًا وفقًا لترتيب إجمالي (وليس بالتوازي)، بينما تحدث عملية إنشاء الكتلة نفسها بالتوازي مع الإجماع. ومع ذلك، بالنسبة لأي كتلة معينة، تكون هذه العمليات غير متزامنة تمامًا.
من الواضح أنه من المستحيل القيام بالإجماع والتنفيذ على نفس الكتلة في نفس الوقت. لذلك، أثناء تنفيذ الكتلة n، ستتلقى العقدة الكتلة n+1 للخطوة التالية.
إذا حدث انحراف في الإجماع (على سبيل المثال، إذا تصرف ثلث العقد في الشبكة بشكل خبيث)، فسيتوقف السلسلة، وهذا مشابه لبروتوكول BFT القياسي.
لن تؤدي المعاملات التي تفشل أثناء التنفيذ داخل الكتلة إلى جعل تلك الكتلة غير صالحة، بل ستظل في حالة الفشل، لأن إنشاء الكتلة والتنفيذ منفصلان، وسيتم تقديم الحالة النهائية للكتلة الحالية في الكتل اللاحقة.
كيف يتم تنفيذ نموذج متعدد المقترحين وما هو Autobahn؟
تُعرف بروتوكولات الإجماع نفسها باسم "Autobahn" (مثل الطريق السريع الألماني بدون حدود للسرعة). تفصل Autobahn بين توفر البيانات وترتيب المعاملات، وهناك نموذج مثير للاهتمام وراء ذلك.
تمامًا مثل أي ممر في طريق سريع، هناك عدة ممرات، حيث يتمتع كل عقدة بممر خاص بها. تستخدم العقد هذه الممرات لتقديم اقتراحات حول ترتيب المعاملات. الاقتراحات هي مجرد مجموعة مرتبة من المعاملات.
أوتوبان أحيانًا يقوم بتنفيذ عملية "tipcut"، أي تجميع عدة اقتراحات لتحديد ترتيب المعاملات بشكل نهائي.
كما ذُكر سابقًا، لكل مُصادق قناة خاصة به لاقتراح دفعات المعاملات.
بعد جمع الاقتراحات والتصويت عليها، سيتم تشكيل إثبات القابلية للاستخدام (PoA) لضمان أن البيانات قد تم استلامها بواسطة عقدة واحدة على الأقل نزيهة في الشبكة.
يحدث Tipcut بالمللي ثانية، وأخيرًا سيتم "قطع" عدة مقترحات من Autobahn.
يكون لدى المقترح حافز للانتظار لنشر الكتل وعند الإمكان لنشر كتلة واحدة، لكن الحد الزمني لتنفيذ كل كتلة (على غرار حد الغاز) سيغير قليلاً من هذه الديناميكية.
اقتراح واحد على قناة عادة ما يعادل كتلة، مما يعني أنه عندما يحدث Tipcut، سيتم قطع عدة كتل في نفس الوقت.
بعد ذلك، سيرسل قائد هذا slot Tipcut إلى العقد الأخرى لإكمال الترتيب. في الواقع، بينما تقوم العقد بالتصويت على Tipcut واحد، فإنها تكون بالفعل في إعداد Tipcut التالي.
يمكن للعقد التي فاتتها الدفعة الحصول على البيانات بشكل غير متزامن من المدققين المدرجين في PoA: هذه هي طبيعة الحاجة إلى توفر البيانات.
في ظل ظروف التزامن، إذا كان القائد صحيحًا، فإن Autobahn سيكمل تأكيد الاقتراح في جولتين من الاتصالات. إذا فشل القائد، فإن هذه الآلية ستنتخب قائدًا جديدًا للحفاظ على سير العملية.
يمكن أن يبدأ الاقتراح التالي لقطع النصائح فعليًا في مرحلة تقديم قطع النصائح الحالية، مما يقلل من التأخير، حيث يتم تنفيذ العمليات بالتوازي مع التوليد.
في الواقع، النموذج بأكمله هو نموذج متعدد المقترحين، حيث يمكن للعديد من العقد تقديم اقتراحات لترتيب كتلها في نفس الوقت. كل مدقق يقترح كتلته الخاصة ويتلقى إثباتات (PoA) من الشبكة التي تمتلك هذه الكتل، مما يساعد على تحسين قدرة الشبكة على معالجة البيانات والكفاءة العامة.
التنفيذ المتوازي وحالات استخدامه
كما تم الإشارة إليه سابقًا، فإن عملية تنفيذ الكتل تحدث بالتوازي مع الإجماع، على الرغم من أن الكتلة نفسها تُنفذ فعليًا بالتسلسل. قد تتساءل عما إذا كان هذا يشكل تنفيذًا حقيقيًا بالتوازي.
الإجابة هي إيجابية وسلبية في آن واحد.
على الرغم من أن الكتل تُنفذ بالتسلسل، إلا أن المعاملات داخل الكتلة يمكن أن تُنفذ بالتوازي. إذا كانت المعاملات لا تعدل (تكتب) نفس الحالة، وكانت نتيجة معاملة واحدة لا تؤثر على معاملة أخرى، فيمكن تنفيذها بالتوازي.
باختصار، يجب أن تكون مسارات تنفيذها غير معتمدة على بعضها البعض. لا تحتوي Giga على تجمع ذاكرة، وستتم إضافة المعاملات على الفور من قبل العقد.
جيجا يفترض أن معظم المعاملات لا تتعارض مع بعضها البعض، ويتم معالجة هذه المعاملات في وقت واحد على عدة نوى معالج.
ستُخزن التغييرات في كل عملية تداول مؤقتًا في ذاكرة مؤقتة خاصة، ولن يتم تطبيقها على البلوكشين على الفور.
بعد الانتهاء من المعالجة، سيقوم النظام بالتحقق مما إذا كانت هذه المعاملة تتعارض مع المعاملات السابقة.
إذا كان هناك تعارض، سيتم إعادة معالجة المعاملة. إذا لم يكن هناك أي تعارض، سيتم تطبيق تغييراتها على blockchain وتأكيدها نهائيًا.
قد تحدث أيضًا حالات من التضارب عالي التردد، وفي هذه الحالة، سيقوم النظام بالتبديل إلى معالجة معاملة واحدة في كل مرة لضمان تقدم المعاملة.
بعبارة بسيطة، فإن التنفيذ المتوازي يوزع المعاملات على عدة أنوية، مما يسمح للمعاملات التي لا تتعارض مع بعضها البعض بالعمل في نفس الوقت.
مشاكل التخزين والتحسين
نظرًا لحجم التداول الكبير، تحتاج البيانات إلى أن تكون آمنة وسهلة الوصول، لذلك يجب أن يختلف أسلوب تخزينها قليلاً عن تخزين blockchain التقليدي. تقوم Giga بتخزين البيانات بتنسيق بسيط من القيم الرئيسية (key-value)، وهو هيكل نسبي مسطح يساعد في تقليل عدد التحديثات أو الفحوصات المطلوبة عند تغيير البيانات.
بالإضافة إلى ذلك، تعتمد Giga أيضًا على طريقة التخزين الهرمي: يتم الاحتفاظ بالبيانات الحديثة على SSD (عالي السرعة)، بينما يتم نقل البيانات الأقل استخدامًا إلى أنظمة تخزين أبطأ وأكثر فعالية من حيث التكلفة.
إذا تعطل عقدة معينة، يمكنها إعادة تشغيل السجل لاستعادة الحالة الصحيحة، وتطبيق التحديثات على RocksDB (وهو قاعدة بيانات مخصصة) لتنظيم البيانات.
يستخدم نظام التخزين هذا مجمع تشفير (Cryptographic Accumulator) يمكنه إثبات صحة البيانات دون الحاجة إلى حسابات معقدة. يتم تحديث المجمع بطريقة الدفع المسبق، مما يسمح للمحققين والعقد الخفيفة بالتوصل بسرعة إلى توافق بشأن الحالة الحالية لسلسلة الكتل.
ماذا يعني أن تصبح سلسلة كتل EVM L1 ذات مقترحات متعددة؟
يمكن تحسين بنية L1 التحتية بعدة طرق، كما تواجه أنواع مختلفة من L1 تحديات تقنية متنوعة، من القضايا الاقتصادية مثل MEV إلى القضايا التقنية مثل إدارة الحالة.
كونها أول سلسلة L1 تدعم العديد من المقترحات، فإنها تمثل تحديًا كبيرًا، خاصةً بالنسبة لسلسلة EVM L1، لأن التصميم الأصلي لـ EVM لم يكن يهدف إلى دعم نظام متعدد المقترحات.
ومع ذلك، تحاول Sei تجربة طرق مختلفة للاحتفاظ بـ EVM والعديد من الأدوات التي اعتاد المطورون على استخدامها.
إن تنفيذ المعاملات بالتوازي، والوصول إلى توافق أثناء التنفيذ، والعمليات المتوازية من قبل مقترحين متعددين تساعد جميعها في تحسين الأداء، حيث يمكن أن تزيد القدرة على المعالجة بحوالي 50 مرة. ومع ذلك، قد تواجه هذه التحسينات أيضًا بعض المخاطر المذكورة أعلاه.
هذا هو التحديث الكبير الثاني لـ Sei، حيث انتقلت Sei سابقًا من سلسلة Cosmos إلى سلسلة EVM، والآن أطلقت Sei عميل تنفيذ مُحسَّن للسرعة.
التطورات القادمة وتأثيرات هذه الإجراءات التحسينية اللاحقة تستحق الاهتمام.
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
تفسير ورقة بيضاء Sei الجديدة: ما هي الابتكارات التكنولوجية التي تقدمها ترقية Giga؟
كتبه: بافيل بارامونوف، مؤسس هايزفلو
ترجمة: PANews
أصدرت Sei ورقة بيضاء جديدة تتناول آخر تحديثات Giga. وجد معظم القراء أن المحتوى الفني العميق المكون من 17 صفحة يصعب قراءته. لذلك، ستشرح هذه المقالة محتوى هذا التحديث وكيفية تحسين أداء blockchain على مستويات مختلفة.
حول توليد الكتل بالتنفيذ غير المتزامن
الفكرة الرئيسية والأساسية لـ Giga كما يلي:
"إذا كانت قائمة معاملاتنا مرتبة وكانت الحالة الأولية لسلسلة الكتل متسقة، وجميع العقد الصادقة تعالج هذه المعاملات بنفس الترتيب، فإن العقد ستصل إلى نفس الحالة النهائية."
في هذه الحالة، تعتمد النتيجة فقط على الحالة الأولية وترتيب المعاملات. وهذا يعني أن التوافق يحتاج فقط إلى الاتفاق على ترتيب المعاملات داخل الكتلة، ويمكن لكل عقدة حساب الحالة النهائية بشكل مستقل.
في هذا النموذج، يتم فصل الإجماع عن التنفيذ، مما يسمح بتنفيذ الكتل بشكل غير متزامن.
بمجرد أن يتم تأكيد الكتلة نهائيًا، ستقوم العقدة بمعالجتها وتقديم حالتها في الكتل اللاحقة.
ثم يتم التحقق من الكتلة من خلال توافق الحالة لضمان أن جميع العقد قد حسبت الحالة النهائية الصحيحة.
تفصيل مهم هنا هو أن التنفيذ مع الإجماع (التوليد) يحدثان بالتوازي. يقوم العقد عند تنفيذ حساب كتلة ما، بتلقي كتل أخرى أيضاً.
لذلك، يتم تنفيذ الكتل فعليًا وفقًا لترتيب إجمالي (وليس بالتوازي)، بينما تحدث عملية إنشاء الكتلة نفسها بالتوازي مع الإجماع. ومع ذلك، بالنسبة لأي كتلة معينة، تكون هذه العمليات غير متزامنة تمامًا.
من الواضح أنه من المستحيل القيام بالإجماع والتنفيذ على نفس الكتلة في نفس الوقت. لذلك، أثناء تنفيذ الكتلة n، ستتلقى العقدة الكتلة n+1 للخطوة التالية.
إذا حدث انحراف في الإجماع (على سبيل المثال، إذا تصرف ثلث العقد في الشبكة بشكل خبيث)، فسيتوقف السلسلة، وهذا مشابه لبروتوكول BFT القياسي.
لن تؤدي المعاملات التي تفشل أثناء التنفيذ داخل الكتلة إلى جعل تلك الكتلة غير صالحة، بل ستظل في حالة الفشل، لأن إنشاء الكتلة والتنفيذ منفصلان، وسيتم تقديم الحالة النهائية للكتلة الحالية في الكتل اللاحقة.
كيف يتم تنفيذ نموذج متعدد المقترحين وما هو Autobahn؟
تُعرف بروتوكولات الإجماع نفسها باسم "Autobahn" (مثل الطريق السريع الألماني بدون حدود للسرعة). تفصل Autobahn بين توفر البيانات وترتيب المعاملات، وهناك نموذج مثير للاهتمام وراء ذلك.
تمامًا مثل أي ممر في طريق سريع، هناك عدة ممرات، حيث يتمتع كل عقدة بممر خاص بها. تستخدم العقد هذه الممرات لتقديم اقتراحات حول ترتيب المعاملات. الاقتراحات هي مجرد مجموعة مرتبة من المعاملات.
أوتوبان أحيانًا يقوم بتنفيذ عملية "tipcut"، أي تجميع عدة اقتراحات لتحديد ترتيب المعاملات بشكل نهائي.
كما ذُكر سابقًا، لكل مُصادق قناة خاصة به لاقتراح دفعات المعاملات.
عندما يتلقى عقدة اقتراحًا صالحًا، سيقوم بإرسال تصويت لتأكيد استلام الاقتراح.
بعد جمع الاقتراحات والتصويت عليها، سيتم تشكيل إثبات القابلية للاستخدام (PoA) لضمان أن البيانات قد تم استلامها بواسطة عقدة واحدة على الأقل نزيهة في الشبكة.
يحدث Tipcut بالمللي ثانية، وأخيرًا سيتم "قطع" عدة مقترحات من Autobahn.
يكون لدى المقترح حافز للانتظار لنشر الكتل وعند الإمكان لنشر كتلة واحدة، لكن الحد الزمني لتنفيذ كل كتلة (على غرار حد الغاز) سيغير قليلاً من هذه الديناميكية.
اقتراح واحد على قناة عادة ما يعادل كتلة، مما يعني أنه عندما يحدث Tipcut، سيتم قطع عدة كتل في نفس الوقت.
بعد ذلك، سيرسل قائد هذا slot Tipcut إلى العقد الأخرى لإكمال الترتيب. في الواقع، بينما تقوم العقد بالتصويت على Tipcut واحد، فإنها تكون بالفعل في إعداد Tipcut التالي.
يمكن للعقد التي فاتتها الدفعة الحصول على البيانات بشكل غير متزامن من المدققين المدرجين في PoA: هذه هي طبيعة الحاجة إلى توفر البيانات.
في ظل ظروف التزامن، إذا كان القائد صحيحًا، فإن Autobahn سيكمل تأكيد الاقتراح في جولتين من الاتصالات. إذا فشل القائد، فإن هذه الآلية ستنتخب قائدًا جديدًا للحفاظ على سير العملية.
يمكن أن يبدأ الاقتراح التالي لقطع النصائح فعليًا في مرحلة تقديم قطع النصائح الحالية، مما يقلل من التأخير، حيث يتم تنفيذ العمليات بالتوازي مع التوليد.
في الواقع، النموذج بأكمله هو نموذج متعدد المقترحين، حيث يمكن للعديد من العقد تقديم اقتراحات لترتيب كتلها في نفس الوقت. كل مدقق يقترح كتلته الخاصة ويتلقى إثباتات (PoA) من الشبكة التي تمتلك هذه الكتل، مما يساعد على تحسين قدرة الشبكة على معالجة البيانات والكفاءة العامة.
التنفيذ المتوازي وحالات استخدامه
كما تم الإشارة إليه سابقًا، فإن عملية تنفيذ الكتل تحدث بالتوازي مع الإجماع، على الرغم من أن الكتلة نفسها تُنفذ فعليًا بالتسلسل. قد تتساءل عما إذا كان هذا يشكل تنفيذًا حقيقيًا بالتوازي.
الإجابة هي إيجابية وسلبية في آن واحد.
على الرغم من أن الكتل تُنفذ بالتسلسل، إلا أن المعاملات داخل الكتلة يمكن أن تُنفذ بالتوازي. إذا كانت المعاملات لا تعدل (تكتب) نفس الحالة، وكانت نتيجة معاملة واحدة لا تؤثر على معاملة أخرى، فيمكن تنفيذها بالتوازي.
باختصار، يجب أن تكون مسارات تنفيذها غير معتمدة على بعضها البعض. لا تحتوي Giga على تجمع ذاكرة، وستتم إضافة المعاملات على الفور من قبل العقد.
جيجا يفترض أن معظم المعاملات لا تتعارض مع بعضها البعض، ويتم معالجة هذه المعاملات في وقت واحد على عدة نوى معالج.
ستُخزن التغييرات في كل عملية تداول مؤقتًا في ذاكرة مؤقتة خاصة، ولن يتم تطبيقها على البلوكشين على الفور.
بعد الانتهاء من المعالجة، سيقوم النظام بالتحقق مما إذا كانت هذه المعاملة تتعارض مع المعاملات السابقة.
إذا كان هناك تعارض، سيتم إعادة معالجة المعاملة. إذا لم يكن هناك أي تعارض، سيتم تطبيق تغييراتها على blockchain وتأكيدها نهائيًا.
قد تحدث أيضًا حالات من التضارب عالي التردد، وفي هذه الحالة، سيقوم النظام بالتبديل إلى معالجة معاملة واحدة في كل مرة لضمان تقدم المعاملة.
بعبارة بسيطة، فإن التنفيذ المتوازي يوزع المعاملات على عدة أنوية، مما يسمح للمعاملات التي لا تتعارض مع بعضها البعض بالعمل في نفس الوقت.
مشاكل التخزين والتحسين
نظرًا لحجم التداول الكبير، تحتاج البيانات إلى أن تكون آمنة وسهلة الوصول، لذلك يجب أن يختلف أسلوب تخزينها قليلاً عن تخزين blockchain التقليدي. تقوم Giga بتخزين البيانات بتنسيق بسيط من القيم الرئيسية (key-value)، وهو هيكل نسبي مسطح يساعد في تقليل عدد التحديثات أو الفحوصات المطلوبة عند تغيير البيانات.
بالإضافة إلى ذلك، تعتمد Giga أيضًا على طريقة التخزين الهرمي: يتم الاحتفاظ بالبيانات الحديثة على SSD (عالي السرعة)، بينما يتم نقل البيانات الأقل استخدامًا إلى أنظمة تخزين أبطأ وأكثر فعالية من حيث التكلفة.
إذا تعطل عقدة معينة، يمكنها إعادة تشغيل السجل لاستعادة الحالة الصحيحة، وتطبيق التحديثات على RocksDB (وهو قاعدة بيانات مخصصة) لتنظيم البيانات.
يستخدم نظام التخزين هذا مجمع تشفير (Cryptographic Accumulator) يمكنه إثبات صحة البيانات دون الحاجة إلى حسابات معقدة. يتم تحديث المجمع بطريقة الدفع المسبق، مما يسمح للمحققين والعقد الخفيفة بالتوصل بسرعة إلى توافق بشأن الحالة الحالية لسلسلة الكتل.
ماذا يعني أن تصبح سلسلة كتل EVM L1 ذات مقترحات متعددة؟
يمكن تحسين بنية L1 التحتية بعدة طرق، كما تواجه أنواع مختلفة من L1 تحديات تقنية متنوعة، من القضايا الاقتصادية مثل MEV إلى القضايا التقنية مثل إدارة الحالة.
كونها أول سلسلة L1 تدعم العديد من المقترحات، فإنها تمثل تحديًا كبيرًا، خاصةً بالنسبة لسلسلة EVM L1، لأن التصميم الأصلي لـ EVM لم يكن يهدف إلى دعم نظام متعدد المقترحات.
ومع ذلك، تحاول Sei تجربة طرق مختلفة للاحتفاظ بـ EVM والعديد من الأدوات التي اعتاد المطورون على استخدامها.
إن تنفيذ المعاملات بالتوازي، والوصول إلى توافق أثناء التنفيذ، والعمليات المتوازية من قبل مقترحين متعددين تساعد جميعها في تحسين الأداء، حيث يمكن أن تزيد القدرة على المعالجة بحوالي 50 مرة. ومع ذلك، قد تواجه هذه التحسينات أيضًا بعض المخاطر المذكورة أعلاه.
هذا هو التحديث الكبير الثاني لـ Sei، حيث انتقلت Sei سابقًا من سلسلة Cosmos إلى سلسلة EVM، والآن أطلقت Sei عميل تنفيذ مُحسَّن للسرعة.
التطورات القادمة وتأثيرات هذه الإجراءات التحسينية اللاحقة تستحق الاهتمام.