المؤلف: toly، Solana Labs شارك في إنشائه: >في Solana، يتم تنظيم الحالة كمخزن قيمة مفتاح مسطح، ويتم تنفيذ البرامج على هذه الحالة لتحديث القيم، بما في ذلك برامج التصويت الرئيسية للتوافق. الغرض الرئيسي من التنفيذ غير المتزامن هو السماح لبرنامج التصويت بالعمل بشكل مستقل عن جميع البرامج الأخرى. ولتحقيق ذلك باستمرار، نحتاج إلى ضمان العديد من المبادئ الأساسية.
مجال التنفيذ
مجال التنفيذ هو مجموعة من المفاتيح والقيم للبرامج وعملياتها التي تكون مستقلة عن بعضها البعض عند تنفيذها. يمكن تشغيل مجالات التنفيذ على مؤشرات ترابط ونوى مختلفة وإكمالها في أوقات مختلفة على أجهزة مختلفة. الأهم من ذلك، أن مجال تنفيذ واحد (على سبيل المثال، المجال أ) لا يمكنه قراءة أو كتابة أي قيمة في مجال آخر (على سبيل المثال، المجال ب). ومع ذلك، يمكن للنطاقات مشاركة الحالة التي تظل متسقة أثناء تنفيذ أي نطاق واحد. هناك حاجة إلى بروتوكول لمزامنة الحالة بين المجالات وتسهيل حركة المفاتيح والقيم.
يحدد دافع رسوم المعاملة المجال الذي سيتم تنفيذ المعاملة فيه.
المجالات الرئيسية: VED وUED
في Solana، نركز بشكل أساسي على مجالين: مجال تنفيذ التصويت (VED) ومجال تنفيذ المستخدم (UED). الهدف هو تمكين المدققين من التصويت قبل اكتمال تنفيذ برنامج المستخدم.
مكونات VED
برنامج النظام: مستخدم للتحويلات
متغيرات نظام برنامج التصويت: متغيرات نظام برنامج التصويت المستخدمة للتصويت
< strong>إجراءات التصويت: إجراءات التصويت الأساسية. البرنامج ثابت ومتسق ويجب أن يكون موجودًا في كل من UED وVED.
أذونات التصويت: الحسابات التي تتمتع بحق التصويت
دافع رسوم التصويت : حساب يدفع الرسوم المتعلقة بالتصويت
صندوق دافع الرسوم: حساب متجدد يمكن استخدامه لنقل sol إلى VED
يتم وضع جميع الحسابات الأخرى في UED
احسب حالة VED
بعد N-1 وحدود عصر N، يتم حساب حالة VED للمجال N + 1 في وقت التشغيل. يجب إكمال هذا الحساب قبل نهاية العصر N. لا يمكن أن يبدأ حساب UED حتى اكتمال Epoch N-1.
معايير حالة VED
حسابات التصويت: الحسابات التي تحتوي على أكثر من 5000 يوم مركّز ونشطة.
دافع الرسوم وحقوق التصويت، صندوق دافع الرسوم: مرتبط بحساب التصويت أعلاه.
يتم في البداية تعيين حسابات التصويت المنشأة حديثًا على أنها غير نشطة. يجب على المستخدمين تنشيط هذه الحسابات وبمجرد تنشيطها، سيتم تضمينها في حساب حالة VED التالي. يمكن للمستخدمين إلغاء تنشيط الحساب وستتم إزالة الحساب من حالة VED في Epoch N+1.
تحريك الأموال في VED
يمكن استخدام حساب صندوق دافع الرسوم المعلن في حساب التصويت لنقل الأموال في VED. بعد تحديث حساب تمويل دافع الرسوم في حساب التصويت، سيظل صندوق دافع الرسوم الحالي نشطًا حتى نهاية الفترة التالية. بمجرد تنشيط VED المُعاد حسابه، سيدخل صندوق دافع الرسوم الجديد إلى حالة VED ويمكن استخدامه لإضافة sol إضافي إلى دافعي الرسوم. ستدخل أموال دافع الرسوم القديم في حالة UED بحيث يمكن تحويل الأموال مرة أخرى إلى الحساب بالـ UED.
على الرغم من أنه من الممكن دمجها مع دافع الرسوم، من أجل تقليل عدد التوقيعات المستخدمة لكل صوت، إلا أنه يتم تعيين دافع الرسوم عادةً على نفس قيمة سلطة التصويت، وبالتالي يتطلب الأمر منفصلاً حساب في VED نقل سول بين وUED.
مجال التنفيذ العام
الطريقة المذكورة أعلاه خاصة جدًا بإجراءات التصويت. يمكن تعميم هذا النهج على أي عدد من مجالات التنفيذ. تقوم الحسابات بتتبع مجال التنفيذ الذي تم تعيينها إليه، تمامًا كما يتتبع برنامج Hypervisor لنظام التشغيل VMID في الصفحة الفعلية. بالنسبة لهذا المشروع تحديدًا، تكون مجموعة صغيرة من التعيينات مفيدة:
RX-UED: في UED فقط للقراءة وقابل للتنفيذ
RX-UED-VED: للقراءة فقط وقابل للتنفيذ في UED وVED
RW-UED: القراءة والكتابة باللغة UED Write< /p>
نظرًا لعدم تمكن الحسابات من القراءة والكتابة في مجالات متعددة في وقت واحد، فإن التعيينات الأخرى غير صالحة.
البرنامج: لا يمكن تعيينه إلا إلى RX-UED أو RX-UED-VED، أي بين المستخدم أو كليهما المجال قابل للقراءة والتنفيذ، ولكنه غير قابل للكتابة. يجب أن تفشل أي معاملة تتضمن البرنامج كبرنامج قابل للكتابة.
الحساب: لا يمكن تعيينه إلا إلى RW-VED أو RW-UED.
تقوم لقطة النظام بتكوين برنامج التصويت وبرنامج النظام كـ RX-UED-VED. يوفر برنامج النظام واجهات لنقل حسابات النظام وحسابات برنامج التصويت من وإلى VED. لا يزال التحديث الفعلي يتطلب فترة كاملة للتنشيط.
لا يمكن إعادة تعيين الحسابات بين النطاقات إلا إذا كان برنامج المالك موجودًا في النطاق المستهدف. لذلك، يمكن فقط نقل حسابات برنامج التصويت وبرنامج النظام بين VED وUED.
باستخدام النهج المشترك، لم يعد هناك حاجة إلى حساب تمويل صريح لدافع الرسوم. يمكن للمطورين إعادة تعيين أي حساب نظام بين VED وUED لنقل الأموال بين المجالات.
احسب تجزئة VED
بعد استلام الكتلة، تنفذ العقدة جميع المعاملات. تتم العملية كما يلي:
تنفيذ المعاملات التي تتضمن حسابات VED فقط.
فشلت المعاملات ذات الحسابات المختلطة التي تحتوي على دافعي رسوم VED.
تخطي جميع المعاملات الأخرى.
يتم استخدام تحديث حالة VED الذي تم إنشاؤه لحساب تجزئة البنك، تجزئة VED. يمكن الآن للجهات المصادق عليها التصويت باستخدام تجزئة VED بدلاً من تجزئة البنك القديمة. إذا كان هناك تحديث تجزئة UED منذ التصويت الأخير على تلك التفرع، فسيتم تضمين هذا التجزئة والفتحة في التصويت.
احسب تجزئة UED
بعد استلام الكتلة، تقوم العقدة بمعالجة جميع المعاملات:
- < p> تعتبر الحسابات غير الموجودة في VED جزءًا من UED.
تنفيذ المعاملات التي تتضمن حسابات UED فقط.
فشلت المعاملات مع دافعي رسوم UED ولكن الحسابات المختلطة.
تخطي جميع المعاملات الأخرى.
يتم استخدام تحديث حالة UED الذي تم إنشاؤه لحساب تجزئة البنك، تجزئة UED.
النهائية
تبقى النهاية دون تغيير.
رموز حالة تنفيذ المعاملة
أحد الآثار الجانبية للتنفيذ غير المتزامن هو أنه قد لا يتم اكتشاف عدم الحتمية بشكل متزامن على الفور عند حدوث شوكات التصويت. إذا أرسل 1/3 أو أكثر من المدققين تجزئات UED مختلفة، فيجب أن تتوقف جميع العقد عن التأكيد والتصويت، وتنبيه المشغلين.
للحصول على رمز الحالة، يجب أن يسمح طلب RPC API للمستخدم بتحديد تعهد تمت ملاحظته يحسب نفس تجزئة UED. يمكن تمثيل حالة التنفيذ كحالة التنفيذ (التوقيع، التعهد = X)، حيث يمكن أن تكون X 0 أو بعض القيمة الافتراضية. في الإعداد الذي يحتوي على عقد وعملاء متعددين، تكون قيمة X 0 مقبولة، مما يمنح المستخدم الثقة في أن عدم الحتمية أمر مستبعد إلى حد كبير.
عدم الحتمية هو الفشل الوحيد الذي يجب اكتشافه قبل إرجاع رمز الحالة لمعاملة مؤكدة إلى المستخدم، لذلك يمكن أن تكون القيمة الافتراضية لـ X عادةً منخفضة مثل حد التأكيد المتفائل أو حوالي 5٪.
القادة وإنشاء الكتل
يجب أن يكون القائد قادرًا على البدء في إنشاء الكتل فورًا بعد اكتمال VED. وهذا يعني أن القائد سيكون لديه معلومات جزئية وغير كاملة حول حالة أي دافع رسوم UED.
تنشيط وظيفة عملية التصويت
يجب تشغيل عملية التصويت على افتراض أن التصويت VED قد يعبر العصور عندما يتم تنشيط الوظيفة، تم تصميم الحالات الحدودية لتعمل في وقت مختلف عن المعاملات الأخرى في UED التي تمس عملية التصويت.
المكافآت
فقط حسابات التصويت في حالة VED هي التي يجب أن تتلقى المكافآت.
العقوبة
جميع حسابات التصويت، سواء كانت نشطة أو VED، معرضة لخطر العقوبة.
تحديث الساعة العالمية
يتم تحديث متغيرات نظام الساعة عن طريق التصويت. ينبغي استخدام طرق بديلة. وبدلاً من ذلك، يمكن لكل قائد كتلة تحريك الساعة للأمام بما يصل إلى ثانية واحدة. يجب أن يكون ما لا يقل عن 40% من الشبكة ضارًا حتى تعمل الساعة بشكل أسرع من الوقت الفعلي. يمكن أيضًا تحريك الساعة للأمام بمقدار 400 مللي ثانية افتراضيًا. وبافتراض انحراف قدره 50 مللي ثانية، يحتاج 12.5% فقط من القادة إلى ضبط أوقات ساعاتهم للبقاء متزامنين.
JinseFinance
Beincrypto
cryptopotato
Tristan
Bitcoinist
Cointelegraph