العقود الآجلة
وصول إلى مئات العقود الدائمة
TradFi
الذهب
منصّة واحدة للأصول التقليدية العالمية
الخیارات المتاحة
Hot
تداول خيارات الفانيلا على الطريقة الأوروبية
الحساب الموحد
زيادة كفاءة رأس المال إلى أقصى حد
التداول التجريبي
مقدمة حول تداول العقود الآجلة
استعد لتداول العقود الآجلة
أحداث مستقبلية
"انضم إلى الفعاليات لكسب المكافآت "
التداول التجريبي
استخدم الأموال الافتراضية لتجربة التداول بدون مخاطر
إطلاق
CandyDrop
اجمع الحلوى لتحصل على توزيعات مجانية.
منصة الإطلاق
-التخزين السريع، واربح رموزًا مميزة جديدة محتملة!
HODLer Airdrop
احتفظ بـ GT واحصل على توزيعات مجانية ضخمة مجانًا
منصة الإطلاق
كن من الأوائل في الانضمام إلى مشروع التوكن الكبير القادم
نقاط Alpha
تداول الأصول على السلسلة واكسب التوزيعات المجانية
نقاط العقود الآجلة
اكسب نقاط العقود الآجلة وطالب بمكافآت التوزيع المجاني
المؤسس المشارك لسولانا: بناء آلة دولة عالمية وتحليل بنية سولانا النهائية
** كلمات: أناتولي ياكوفينكو ، الرئيس التنفيذي (المؤسس المشارك والرئيس التنفيذي) ، سولانا
** مترجم: 1912212.eth ، أخبار التبصر **
هدف Solana هو مزامنة آلة دولة عالمية واحدة بدون إذن في أسرع وقت ممكن ، وفقا لقوانين الفيزياء. أعتقد أن البنية التي ستكون قادرة على تحقيق ذلك ستبدو كما يلي:
لكي تعمل الشبكة كآلة حالة عالمية ، فإنها تحتاج إلى دعم العديد من العقد الكاملة. أثبتت التوربينات أن النسخ المتماثل السريع للشبكات الكبيرة جدا قابل للتطوير على الأجهزة والشبكات الحديثة.
يتيح Concurrency Leader للشبكة أن يكون لها مواقع متعددة في جميع أنحاء العالم لطلب معاملات المستخدم. إنه يقلل المسافة بين المستخدمين والشبكة ، مما يلغي الحاجة إلى التحقق الكامل من العقدة قبل إضافة المعاملات إلى السلسلة.
تخلق أوقات الحظر القصيرة نقاط نهائية سريعة ، وتعزز مقاومة الرقابة ، وتحسن تجربة المستخدم ، وتقلل من النوافذ لإعادة ترتيب المعاملات ، وتسريع الشبكة بشكل عام.
الإجماع ضروري لاختيار شوكة ، والتي تحدث بسبب تقسيم الشبكة. ستكون عينة من 200 عقدة أو أكثر ممثلة إحصائيا لجميع الأقسام الرئيسية في الشبكة وتتطابق بشكل وثيق مع توزيعها الفعلي. لذلك ، جميع أصوات العقدة الكاملة غير مطلوبة ، 200 كافية. قصر الموافقة على اللجان الفرعية لتقليل الذاكرة وعرض النطاق الترددي للشبكة المطلوب لدعم كتل 120 مللي ثانية. يؤدي تقليل وقت الكتلة بشكل طبيعي إلى زيادة عدد الأصوات المرسلة في الثانية ، مما يضع بعض الضغط على الموارد المخصصة لتوافق الآراء.
التحدي الحقيقي في كتلة 120ms هو إعادة تشغيل جميع معاملات المستخدم. نظرا لأن الشبكة بدون إذن ، فمن الصعب للغاية ضمان بيئة تنفيذ متجانسة مع وقت موثوق به لتنفيذ رمز مستخدم تعسفي. في حين أن هناك احتمالا ، لا يمكن تحقيقه إلا من خلال الحد من موارد الحوسبة المتاحة لمعاملات المستخدم والتأكد من أن كل عقدة يتم تخصيصها بشكل زائد لأسوأ السيناريوهات.
ومع ذلك ، لا يوجد سبب لفرض حالة كاملة لعقد الإجماع التي تصوت لصالح شوكة أو زعيم يبني على مفترق طرق. من أجل الحفاظ على تزامن موافقات عقد الإجماع والقادة ، يجب حساب الحالة مرة واحدة فقط في كل فترة.
التنفيذ غير المتزامن
الدافع
يتطلب التنفيذ المتزامن تكوين جميع العقد التي تصوت وتنشئ كتلا فائقة التكوين في أي كتلة لتحديد وقت التنفيذ في أسوأ الحالات. التنفيذ غير المتزامن هو واحد من الحالات القليلة جدا التي يوجد فيها عدد قليل من المقايضات. يمكن لعقد الإجماع أداء عمل أقل قبل التصويت. يمكن تجميع العمل وتجميعه ، مما يجعله فعالا في التنفيذ دون أي فقدان لذاكرة التخزين المؤقت. يمكن حتى تنفيذه على جهاز مختلف تماما عن عقدة الإجماع أو القائد. يمكن للمستخدمين الذين يريدون التنفيذ المتزامن تخصيص موارد أجهزة كافية لتنفيذ كل انتقال حالة في الوقت الفعلي دون الحاجة إلى انتظار الشبكة بالكامل.
نظرا لتنوع التطبيقات والمطورين الأساسيين ، يجدر التخطيط لتغيير كبير في البروتوكول كل عام. إذا اضطررت إلى اختيار واحد ، فسيكون خياري هو التنفيذ بشكل غير متزامن.
نظرة عامة
في الوقت الحالي ، يكرر المدققون بسرعة جميع المعاملات على كل كتلة ويصوتون فقط بعد حساب الحالة الكاملة للكتلة. الهدف من هذا الاقتراح هو فصل قرارات التصويت على الشوكات عن حساب انتقالات الحالة الكاملة للكتل.
يحتاج المدققون الذين يصوتون في الموافقة فقط إلى تحديد الشوكة ؛ لا يحتاجون إلى أداء أي حالة على الإطلاق. فقط في كل حقبة يحتاجون إلى الحالة لحساب الموافقة التالية.
تم تعديل إجراءات التصويت بحيث يمكن تنفيذها بشكل مستقل. تقوم العقد بتنفيذ إجراءات التصويت فقط قبل التصويت. نظرا لأن المدققين لا يشغلون مساحة كبيرة ، يجب أن تكون متطلبات الذاكرة صغيرة نسبيا. نظرا لأن التصويت له وقت تنفيذ يمكن التنبؤ به للغاية ، يجب أن يكون هناك القليل من التوتر في تنفيذ إجراءات التصويت.
يمكن حساب جميع المعاملات غير التصويتية بشكل غير متزامن. يسمح ذلك بإعادة التشغيل بتنفيذ جميع المعاملات غير التصويتية على دفعات ، والجلب المسبق و JIT جميع البرامج مقدما ، مما يلغي فعليا جميع خسائر ذاكرة التخزين المؤقت. الهدف على المدى الطويل هو أنه سيتم تكوين الأجهزة التي تتطلب حسابات كاملة الحالة في الوقت الفعلي وزمن انتقال منخفض فقط لهذه المهمة. من المفترض أن يدفع المستخدمون مقابل الأجهزة الإضافية.
بمجرد فصل اختيار الشوكة وتنفيذ الحالة ، يصبح من الأسهل تسريع الأمور:
نظرا لأن إعادة تشغيل معاملة المستخدم لا تمنع اختيار الشوكة ، لم يعد التقلب يمثل مشكلة عند طرح وقت الكتلة. الشيء الوحيد الذي يجب مراعاته هو أنه عند 200 مللي ثانية ، يتضاعف معدل تصويت المدقق. سيسمح لنا إجراء تغيير مباشر إلى حد ما على كيفية حساب الحصة للموافقات بتحديد حجم الموافقة عند 200 أو 400 ، أو أي رقم يبدو مناسبا.
ومن الطبيعي أيضا أن نفصل التنفيذ تماما عن توافق الآراء. سيكون من الأسرع إعادة تشغيل عقدة الإجماع التي تحتاج فقط إلى التحقق من حساب برنامج التصويت في الموافقة على الحجم الثابت.
في الواقع ، أعتقد أن وقت التأكيد سيزداد لأن الغالبية العظمى من الموافقات يتم التصويت عليها في أسرع وقت ممكن ، وبينما يتم نشر هذه الأصوات ، يمكن للعقد التي تزود المستخدمين بنتائج تنفيذ الحالة الكاملة تنفيذ المعاملات في نفس الوقت. لذلك ، يجب أن يحدث أي ارتعاش إعادة نراه اليوم في نفس وقت انتشار شبكة التصويت.
تصويت
تنظيم القائد والموافقة عليه
يستوفي المدققون فقط المعايير التالية:
لإدخال جدول القائد والعد نحو الموافقة. بالنسبة للإصدار 2 ، يمكننا فصل LeaderSchedule عن النصاب القانوني ، وليس من الضروري أن يكون لكل منهما نفس المتطلبات.
حساب VoteBankHash
على عكس Bankhash ، الذي يحسب جميع المعاملات ، يقوم المدققون فقط بحساب VoteBankHash لمعاملات التصويت البسيطة المتعلقة بالمدققين في LeaderScheduler. يتم تجاهل جميع المعاملات الأخرى. بعد إعادة تشغيل جميع الأصوات ، يتم حساب VoteBankHash بنفس تنسيق BankHash الحالي.
يجب أن يقوم VoteBankHash بتجميع VoteBankHash السابق ، وليس BankHash الكامل.
حسابات بانك هاش
بالنسبة لجميع الكتل المؤكدة المتفائلة (القابلة للتكوين لجميع الكتل) ، يبدأ المدقق في حساب UserBankHash ، والذي يتضمن جميع انتقالات الحالة ، ولكنه يستبعد المعاملات التي تم أخذها في الاعتبار في حساب VoteBankHash.
ثم يتم اشتقاق BankHash من تراكم (VoteBankHash ، UserBankHash). يقدم أفضل 99.5٪ من المدققين BankHash كجزء من تصويتهم كل 100 فترة زمنية. أثناء الالتزام بكل 100 فترة زمنية ، يتم حسابها في كل فترة زمنية. تجدر الإشارة إلى أنه قد يكون من المفيد لنسبة صغيرة من العقد أن تقدم BankHash باستمرار في القيل والقال كإشارة ناعمة دون ملاحظة غير حتمية.
إذا قدم أقل من 67٪ من المدققين حسابات BankHash كاملة ، فيجب على القادة تقليل مساحة الكتلة المتاحة لمعاملات المستخدم والحسابات القابلة للكتابة بنسبة 50٪. هذا الإجراء هو حماية السلسلة من الانتهاكات التي يمكن أن تزيد بشكل مفرط من وقت الإعادة.
يجب أن تقوم BankHash بتجميع BankHashes السابقة.
اذهب إلى قائد البنك
أثناء إنشاء الكتلة ، من المحتمل ألا يتمكن القائد من الحصول على الحالة المستخدمة لإنشاء الكتلة ، وليس من المثالي تنفيذ جميع المعاملات خلال فترة إنشاء الكتلة.
تتكبد الشبكة تكلفة قليلة نسبيا لفشل المعاملات غير المرغوب فيها ، والتي تتكون فقط من البايتات المخزنة في الأرشيف وعرض النطاق الترددي المطلوب لنشر المعاملات في الكتلة.
بالنظر إلى أن المدققين يتطلعون بالفعل إلى زيادة أرباحهم إلى أقصى حد ، فإن لديهم حوافز وافرة للحفاظ على ذاكرة تخزين مؤقت دقيقة للحسابات المدفوعة. بالإضافة إلى ذلك ، إذا لم تكن هناك عقوبة مطبقة ، فيمكن لأي شخص في أي شبكة خدمة ذاكرة التخزين المؤقت بسهولة على المدى الطويل. في حالة تلف الخادم ، يجب أن يكون المشغل الرائد غير المصرفي قادرا على التبديل بسهولة أو أخذ عينات من مصادر متعددة.
هذا يعني أنه نظرا لدوافع المدققين لزيادة الأرباح إلى أقصى حد ، فسوف يسعون جاهدين للحفاظ على ذاكرة تخزين مؤقت دقيقة للحسابات المدفوعة. في حالة عدم وجود آلية جزاء ، قد يتم تقديم ذاكرة التخزين المؤقت هذه بواسطة أي عقدة في الشبكة لفترة طويلة. بالإضافة إلى ذلك ، في حالة فشل الخادم ، يجب أن يكون المشغل بدون قائد بنك قادرا على التبديل بسهولة أو أخذ عينات من مصادر متعددة.
المقايضات
المقايضة الرئيسية هي عدم وجود توقيع إقرار على العقدة الكاملة التي تخدم حالة المستخدم لتأكيد أن حالة التسليم الخاصة بها هي بالضبط نفس حالة البقية المعتمدة. يجب أن يظل التفسير الرسمي الوحيد للدولة كما هو ، حتى لو تم إعادة كل معاملة بالتتابع في دفتر الأستاذ. يجب ألا تؤدي أي تحسينات في الأداء إلى تغيير النتائج. لذلك ، بمجرد الانتهاء من الشوكة ، يتم ترك الحالة الصحيحة فقط للحساب ، طالما أن تنفيذ وقت التشغيل خال من الأخطاء.
يجب أن تقوم العقد المصممة لتوفير الحالة بشكل موثوق بتشغيل العديد من الأجهزة والعملاء ، وإذا كان هناك تباين في تنفيذ الحالة ، فيجب أن يتوقفوا عن العمل. هذا هو في الأساس ما يجب أن يفعله المشغلون اليوم ، لأن الاعتماد فقط على بقية الشبكة يقدم معظم افتراضات النزاهة.
يمكن للمستخدمين أيضا توقيع المعاملات التي تؤكد BankHash أو تؤدي إلى إجهاض. ستقوم بقية الشبكة بتنفيذ هذه المعاملات فقط إذا كان حساب BankHash الدقيق هو بالضبط نفس BankHash المقدم للمستخدم من قبل مزود RPC.
خارطة طريق عقدة إجماع عديمي الجنسية طويلة الأجل
لا تتطلب الشبكات ذات الموافقات ذات الحجم الثابت سوى قدر صغير جدا من الحالة للبدء. الموافقة نفسها ووزنها المرهون ، وكذلك جميع أرصدة حسابات التصويت. هذه كمية صغيرة جدا من الذاكرة وملف لقطة صغير يمكن توزيعه بسرعة وتهيئته بسرعة عند إعادة التشغيل.
إذا كانت الموافقة غير متوافقة مع العقدة الكاملة، فستتوقف العقدة الكاملة التي تتعقب كل من الموافقة والحالة عن التشغيل. هذا يعني أنه إذا كان هناك خلاف بين الموافقة والحالة ، فإن التبادل ، وقناة فيات ، و RPC ، والجسر ، وما إلى ذلك ، ستتوقف جميعها عن العمل. وهذا لا يتطلب سوى نسبة صغيرة جدا من العقد التوافقية المعيبة عديمة الجنسية.
يمكن للقادة غير المصرفيين الاعتماد على عينة من العقد الكاملة المتعددة لتوفير ذاكرة تخزين مؤقت للرصيد الأولي للحساب المدفوع. حتى لو كانت معيبة ، فستكون النتيجة رسائل غير مرغوب فيها في الكتلة بدلا من فشل الإجماع. يجب أن يكون المشغلون قادرين على مراقبة صحة قادتهم والنسبة المئوية للرسائل غير المرغوب فيها التي يحقنونها في كتلهم ، والاستجابة بسرعة للفشل.