جدول العصور

ما جدول العصور؟

جدول العصور هو مجموعة قواعد بلوكشين تقسّم وقت الشبكة إلى عصور ووحدات أصغر تسمى الخانات.

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

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

يُعبّر عادةً عن جدول العصور بوحدات زمن البروتوكول، لا بالتواريخ التقويمية المعتادة.

مثلًا، قد تحدد الشبكة العصر بعدد ثابت من الخانات بدلًا من القول إن كل عصر يدوم يومين بالضبط.

قد تختلف المدة الفعلية على أرض الواقع عن التقدير إذا أُنتجت الخانات بوتيرة أسرع أو أبطأ من المعدل المستهدف.

قد يشير المصطلح عمومًا إلى بنية التوقيت في أي بلوكشين قائم على العصور.

وله معنى أكثر تحديدًا على Solana، حيث يصف Epoch Schedule معلمات المجموعة المستخدمة لربط الخانات بالعصور وتنسيق جداول القادة.

ما العصر؟

العصر مجموعة محددة من خانات البلوكشين المتتالية.

تستخدم شبكات إثبات الحصة العصور لتنظيم نشاط المدققين ضمن فترات يمكن إدارتها.

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

قد يوفر العصر فترة مرجعية مشتركة لقياس مشاركة المدققين أو حساب مكافآت التخزين أو تغيير حالة التفويض أو تناوب اللجان أو تفعيل قواعد البروتوكول.

تزداد أرقام العصور عادةً منذ بداية البلوكشين.

لكن رقم العصر لا يحمل معنى إلا ضمن شبكته؛ فالعصر 500 في بلوكشين ما لا يرتبط بالعصر 500 في بلوكشين آخر.

ما الخانة؟

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

تُجمع عدة خانات لتكوين عصر واحد.

قد تمر خانة من دون إنتاج كتلة.

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

لذلك، لا يتطابق رقم الخانة دائمًا مع رقم الكتلة.

ينبغي للتطبيقات ألا تفترض أن كل خانة تقابل كتلة ناجحة واحدة.

جدول العصور مقابل رقم العصر

يحدد رقم العصر عصرًا معينًا في تاريخ البلوكشين.

أما جدول العصور فيحدد القواعد المستخدمة لحساب هذا الرقم وتعيين حدود العصر.

مثلًا، قد يحدد الجدول عدد الخانات في كل عصر وما إذا كانت العصور الأولى ذات أطوال مختلفة.

يخبر الاستعلام عن العصر الحالي التطبيق بموقع الشبكة الآن.

أما الاستعلام عن جدول العصور فيوضح للتطبيق كيفية تنظيم بنية العصور في الشبكة.

أهمية جداول العصور

توفر جداول العصور إطارًا متوقعًا للمدققين والتطبيقات فيما يتعلق بأنشطة البلوكشين المرتبطة بالوقت.

يمكن للمدققين الاستعداد لواجبات إنتاج الكتل أو التصويت القادمة.

يستطيع المشاركون في Staking تقدير موعد سريان تغييرات التفويض أو حسابات المكافآت.

يمكن للمحافظ عرض التقدم نحو حد العصر.

تستطيع أنظمة المراقبة قياس أداء المدققين خلال فترة متسقة.

يمكن للمطورين جدولة العمليات المرتبطة برقم عصر أو نطاق خانات.

وقد يفعّل مطورو البروتوكول بعض الترقيات عند حد محدد بوضوح بدل الاعتماد على طابع زمني غير مؤكد وفق الساعة الفعلية.

كيفية تحديد جدول العصور

يتضمن جدول العصور عادةً عدد الخانات في العصر والعلاقة بين أرقام الخانات المطلقة وأرقام العصور.

وتصف بعض الجداول أيضًا فترة إحماء تكون فيها العصور الأولى أقصر من العصور المعتادة.

قد يحدد الجدول المدة التي تسبق بها عملية حساب قيادة المدققين أو تعيينات اللجان.

وقد يتضمن أول عصر وخانة يطبّق فيهما الطول الكامل المعتاد للعصر.

يجب تفسير هذه المعلمات وفق قواعد البلوكشين المحدد.

وقد تترتب على اسم الحقل نفسه نتائج تشغيلية مختلفة باختلاف أنظمة الإجماع.

أطوال العصور الثابتة والمتغيرة

يتضمن العصر ذو الطول الثابت العدد نفسه من الخانات دائمًا بعد أي فترة بدء أو إحماء.

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

حتى عندما يكون عدد الخانات ثابتًا، قد لا تكون المدة الفعلية ثابتة تمامًا.

قد يشهد البلوكشين ذو أوقات الخانات المستهدفة اختلافات زمنية بسبب ظروف الشبكة وأداء المدققين.

لذلك، ينبغي للتطبيقات التمييز بين عدد الخانات في العصر والمدة المقدرة بالدقائق أو الساعات أو الأيام.

حدود العصور

حد العصر هو الانتقال من الخانة الأخيرة في عصر إلى الخانة الأولى في العصر التالي.

غالبًا ما تستخدم البروتوكولات هذه الحدود نقاط مزامنة للتغييرات المتعلقة بالإجماع.

قد تُحدّث مجموعة المدققين أو توزيع الحصة أو حالة المكافآت أو جدول القيادة عند الحد أو قربه.

ينبغي للتطبيق الذي يعتمد على انتقال العصر استخدام بيانات السلسلة بدل الاعتماد على عدّ تنازلي محلي فقط.

قد تؤدي تأخيرات الشبكة واختلافات مستوى الالتزام في RPC إلى إبلاغ مزودي البيانات عن مواضع حالية مختلفة قليلًا قرب الحد.

جدول العصور على Solana

على Solana، يحدد العصر عدد الخانات التي يكون خلالها جدول القادة صالحًا.

يعرّف دليل مصطلحات Solana الرسمي العصر وفق علاقته بالخانات وجدول القادة.

توفر Solana طريقة RPC باسم

تعيد معلمات جدول عصور المجموعة.

يسرد التوثيق الرسمي لـ getEpochSchedule خمسة حقول في الاستجابة.

وهي

و و و و.

لا تتطلب الطريقة أي معلمات طلب.

ينبغي للمطورين الاستعلام عن المجموعة المقصودة بدل افتراض أن كل شبكات Solana تستخدم قيم الجدول نفسها.

slotsPerEpoch

يعرض الحقل

الحد الأقصى لعدد الخانات في العصر ذي الطول المعتاد.

تُعد هذه القيمة أساسية لحساب حدود العصور بعد فترة الإحماء.

إذا لم تستخدم المجموعة عصور الإحماء، فقد يُطبق الطول المعتاد منذ العصر الأول.

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

يمثل الحقل عدد الخانات، لا عددًا مضمونًا من الكتل.

قد لا تنتج بعض الخانات كتلًا مقبولة.

leaderScheduleSlotOffset

يصف الحقل

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

يربط جدول القادة المدققين بالخانات المتوقع أن يقودوا فيها إنتاج الكتل.

يتيح تحديد الجدول مسبقًا للمدققين الاستعداد للخانات المخصصة لهم.

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

warmup

الحقل

قيمة منطقية توضح ما إذا كانت العصور الأولى تبدأ بأطوال أقصر ثم تزداد حتى تبلغ الحجم المعتاد.

تعني القيمة

أن الجدول يتضمن سلوك بدء التشغيل هذا.

وتعني القيمة

أن المجموعة لا تستخدم عصور إحماء متزايدة الطول.

تؤثر معلمات الإحماء أساسًا في المراحل الأولى من تاريخ الشبكة.

يجب على التطبيقات التي تحسب حدود العصور التاريخية مراعاة الإحماء، لا تطبيق الطول المعتاد على جميع العصور المبكرة.

firstNormalEpoch

يحدد الحقل

أول عصر يستخدم العدد الكامل المعتاد من الخانات.

تزداد أهمية هذا الحقل عند تفعيل

.

قد تختلف أطوال العصور السابقة تدريجيًا.

ينبغي للبرمجيات التي تجري حسابات تاريخية تطبيق قواعد الإحماء في الجدول، بدل طرح عدد ثابت من الخانات لكل عصر سابق.

firstNormalSlot

يحدد الحقل

رقم الخانة المطلق الذي يبدأ عنده أول عصر ذي طول معتاد.

وهو نقطة مرجعية لربط أرقام الخانات اللاحقة بالعصور المعتادة.

يفصل

و معًا جزء الإحماء عن الجزء المنتظم من الجدول.

يمكن للتطبيق استخدام هذين الحقلين لتجنب الحسابات التاريخية الخاطئة للعصور.

متغير Epoch Schedule في Solana

يمكن لبرامج Solana الوصول إلى معلومات جدول العصور عبر متغير النظام EpochSchedule، الذي يُعرف عادةً باسم sysvar.

يوفر sysvar معلومات تديرها الشبكة ويمكن للبرامج على السلسلة قراءتها أثناء التنفيذ.

يتضمن مرجع استدعاءات النظام الرسمي لـ Solana استدعاءً لتحميل sysvar الخاص بـ EpochSchedule إلى ذاكرة البرنامج.

يتيح ذلك للبرنامج على السلسلة حساب العلاقات بين العصور والخانات دون الاعتماد على موقع خارج السلسلة.

ومع ذلك، ينبغي للبرنامج تجنب الافتراضات غير الضرورية بشأن الوقت الفعلي، لأن الجدول معبّر عنه بالخانات.

مقارنة getEpochSchedule وgetEpochInfo

تعيد

المعلمات البنيوية التي تحدد نظام العصور في المجموعة.

أما

فتعيد موضع العقدة الحالي ضمن العصر والعدادات المرتبطة به.

يتضمن التوثيق الرسمي لـ getEpochInfo العصر الحالي والخانة المطلقة وفهرس الخانة وعدد خانات العصر الحالي وارتفاع الكتلة وعدد المعاملات عند توفرها.

يعرض الحقل

الموضع الحالي داخل العصر.

ويعرض الحقل

عدد الخانات في ذلك العصر.

يمكن للتطبيقات استخدام الطريقتين معًا لفهم الجدول وعرض التقدم الحالي.

جدول العصور مقابل جدول القادة

يحدد جدول العصور كيفية تقسيم الخانات إلى عصور.

أما جدول القادة فيحدد المدقق المسؤول عن قيادة خانات معينة ضمن عصر.

يرتبط المفهومان، لكنهما ليسا قابلين للاستبدال.

تعيد طريقة Solana getLeaderSchedule هويات المدققين وفهارس خانات القيادة النسبية لعصر محدد.

قد يستخدم تطبيق المراقبة جدول العصور لتحديد العصر، وجدول القادة لمعرفة منتج الكتلة المتوقع.

عصور Solana ومكافآت التخزين

توفر العصور فترة محاسبية لمعلومات التخزين المهمة على Solana.

تتيح الشبكة بيانات المكافآت بحسب العصر عبر نظام RPC.

تعيد طريقة getInflationReward معلومات مكافآت التخزين أو التصويت المسجلة لعصر محدد متى توفرت البيانات.

قد يتضمن سجل مكافأة العصر رقم العصر والخانة الفعلية والمبلغ المقيد والرصيد الناتج ومعلومات عمولة المدقق.

لا ينبغي تفسير المكافأة المرتبطة بعصر على أنها دفعة ثابتة مضمونة.

تعتمد نتائج Staking الفعلية على قواعد الشبكة وأداء المدقق وحالة الحصة والعمولة وظروف البروتوكول الأخرى.

جدول العصور في Ethereum

تنظم Ethereum أيضًا إجماع إثبات الحصة ضمن خانات وعصور.

تستخدم Ethereum حاليًا خانات مدتها 12 ثانية، و32 خانة في كل عصر.

وهذا يمنح العصر مدة مجدولة قدرها 384 ثانية، أي نحو 6.4 دقائق.

يوضح توثيق إثبات الحصة الرسمي في Ethereum اختيار مدقق واحد لاقتراح كتلة في كل خانة.

تقدم لجان المدققين التصديقات، ويتلقى كل مدقق نشط عادةً واجب تصديق خلال كل عصر.

قد تبقى الخانة فارغة إذا لم ينشر المقترح المحدد كتلة مقبولة.

يستمر تسلسل الخانات والعصور حتى عند تفويت كتلة.

عصور Ethereum والنهائية

تستخدم Ethereum نقاط تحقق العصور ضمن آلية النهائية لإثبات الحصة.

يصوت المدققون على علاقات نقاط التحقق عبر تصديقاتهم.

في ظروف الشبكة العادية، قد يبرر دعم كافٍ من المدققين نقاط التحقق ويثبتها نهائيًا عبر عصور متعاقبة.

توفر النهائية للمستخدمين ثقة قوية بأن الكتلة لن تُزال من دون إخفاق كبير في الإجماع وعواقب اقتصادية جسيمة.

لا يعني حد العصر أن كل معاملة في العصر السابق تصبح نهائية فورًا.

تعتمد النهائية على مشاركة المدققين وقواعد نقاط التحقق في البروتوكول.

عصور Ethereum وواجبات المدققين

توزع Ethereum مسؤوليات المدققين على الخانات والعصور.

يصادق المدقق عادةً مرة واحدة في كل عصر.

وقد يُختار أيضًا لاقتراح كتلة أو للمشاركة في لجنة مزامنة.

يهم تنفيذ الواجبات في الوقت المحدد، إذ قد يؤدي التأخير أو تفويت الواجبات إلى خفض المكافآت.

يشرح دليل المكافآت والعقوبات في Ethereum مكافآت التصويت في الوقت المناسب على المصدر والهدف والرأس، واقتراح الكتل والمشاركة في لجنة المزامنة.

ينبغي لمشغلي المدققين مراقبة توقيت الخانات بدل التعامل مع العصر كموعد نهائي واحد واسع.

جدول العصور في Cardano

تقسم آلية إجماع إثبات الحصة في Cardano الوقت أيضًا إلى عصور وخانات.

تذكر وثائق عقدة Cardano الحالية أن الخانة تدوم ثانية واحدة وأن العصر يضم 432,000 خانة.

وهذا يعادل مدة مجدولة للعصر قدرها خمسة أيام.

قد تختار آلية إجماع Cardano صفرًا أو أكثر من عقد إنتاج الكتل في الخانة.

ليس من الضروري أن تنتج الشبكة كتلة في كل خانة مدتها ثانية واحدة.

يوضح دليل إجماع Cardano أن جمع الخانات في عصور يدعم اختيار القادة وفق توزيع الحصة المتغير.

اختلاف جداول العصور بين البلوكشينات

لا توجد مدة عصر موحدة تشترك فيها جميع العملات المشفرة.

تدوم عصور Ethereum دقائق، بينما قد تقيس شبكات أخرى عصورها بالساعات أو الأيام.

تربط بعض الشبكات العصور ارتباطًا وثيقًا بالنهائية وتناوب اللجان.

وتستخدمها شبكات أخرى أساسًا لجداول القادة أو محاسبة التخزين أو تحديثات التفويض أو توزيع المكافآت.

ينبغي للمحفظة أو تطبيق Staking ألا يطبق افتراضات العصور في بلوكشين على بلوكشين آخر.

يجب اعتبار توثيق البروتوكول المعني وبيانات العقدة المباشرة مصدر الحقيقة.

العصور واختيار المدققين

تستخدم شبكات إثبات الحصة معلومات الحصة غالبًا للتأثير في المدققين الذين يتولون الواجبات.

قد يأخذ البروتوكول لقطة للمدققين المؤهلين أو للحصة قبل بدء سريان الواجبات.

يساعد ذلك على منع المشاركين من تغيير الحصة فورًا بعد معرفة تعيين ملائم لهم.

يمكن لجدول العصور توفير إطار التوقيت الخاص باللقطة وحساب التعيينات وفترة الواجبات.

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

العصور وتفعيل التخزين

قد لا تصبح الأصول المفوضة أو المخزنة نشطة فور تأكيد المعاملة.

قد ينتظر البروتوكول حتى عصر لاحق أو يطبق طابور تفعيل.

يتيح هذا التأخير للشبكة تحديث سجلات المدققين والحصص بطريقة منظمة.

وقد يتطلب فك التخزين أيضًا انتقالًا بين العصور أو طابور خروج أو فترة انتظار أو تأخيرًا في السحب.

ينبغي للمستخدمين التمييز بين تأكيد المعاملة وتفعيل التخزين أو الأهلية للسحب.

قد تصبح معاملة التخزين نهائية على السلسلة بينما تظل الحصة المرتبطة بها معلقة وفق قواعد العصور.

العصور وحساب المكافآت

تقيس أنظمة إثبات الحصة كثيرة مشاركة المدققين وتحسب المكافآت على مدى العصور.

قد تحتسب الشبكة الواجبات المسندة والتصويتات الناجحة وإنتاج الكتل والحصة المفوضة والعقوبات والعمولات خلال الفترة.

قد تُحسب المكافآت عند حد العصر، لكنها تُضاف لاحقًا.

توزع بعض الأنظمة المكافآت تلقائيًا، بينما يتطلب بعضها المطالبة بها أو تنفيذ عملية تحديث.

المكافأة المقدرة للعصر ليست معدلًا مضمونًا، لأن أداء المدقق وظروف الشبكة قد يتغيران.

ينبغي للمستخدمين أيضًا احتساب رسوم المشغّل وتغير أسعار التوكنات والضرائب وشروط السحب.

العصور وترقيات البروتوكول

يمكن أن يوفر حد العصر نقطة تفعيل دقيقة لترقية البلوكشين.

تستطيع جميع العقد المتوافقة تحديد نقطة التفعيل من جدول البروتوكول نفسه.

غالبًا ما يكون ذلك أكثر قابلية للتوقع من استخدام رقم كتلة في شبكة تتغير أوقات إنتاج كتلها.

يبدأ تفعيل الترقية المعلن عنها لعصر محدد عندما تصل الشبكة إلى ذلك العصر وفق السلسلة المعتمدة.

ينبغي لمشغلي العقد تثبيت برمجيات متوافقة قبل نقطة التفعيل.

قد تتوقف العميلة التي تتبع القواعد القديمة عن المزامنة أو تنفصل عن الشبكة بعد التفعيل.

جداول العصور والحوكمة

تستخدم بعض أنظمة حوكمة الكريبتو العصور لفترات تقديم المقترحات أو التصويت أو التنفيذ أو التفويض.

قد تُقاس قوة التصويت عند لقطة محددة لعصر أو خانة.

قد يظل المقترح مفتوحًا لعدد محدد من العصور بدل مدة تقويمية ثابتة.

يسهل ذلك التحقق من توقيت الحوكمة على السلسلة.

لكن يجب على المستخدمين فهم الجدول، لأن الموعد النهائي المحدد برقم عصر فقط قد لا يكون واضحًا وفق التقويم المعتاد.

هل يمكن تغيير جدول العصور؟

لا يتغير جدول العصور إلا إذا سمح بروتوكول البلوكشين وآلية الحوكمة بذلك.

تُثبّت بعض معلمات الجدول عند إنشاء الشبكة.

وقد تعدّل شبكات أخرى توقيت الخانات أو طول العصور أو قواعد الواجبات عبر ترقية منسقة للبروتوكول.

يجب أن تنفذ العقد المتوافقة التغيير باتساق لتجنب اختلاف الإجماع.

ينبغي للتطبيقات عدم تثبيت افتراضات التوقيت في الشيفرة نهائيًا عندما توفر الشبكة واجهة API أو متغير نظام موثوقًا.

تقدير نهاية العصر

يمكن للتطبيق تقدير الوقت المتبقي للعصر بجمع عدد الخانات المتبقية مع مدة الخانة المستهدفة للشبكة.

يُحسب التقدير الأساسي بضرب عدد الخانات المتبقية في الزمن المستهدف لكل خانة.

هذا تقدير فقط في الشبكات التي يتغير فيها تقدم الخانات الفعلي.

لا يؤدي تفويت الكتل بالضرورة إلى توقف ترقيم الخانات، لأن الخانات قد تمر بصرف النظر عن نجاح إنتاج الكتل.

ينبغي تحديث العد التنازلي ببيانات العقدة المباشرة ووصفه بأنه تقريبي عند الاقتضاء.

رقم العصر مقابل ارتفاع الكتلة

يحدد رقم العصر مجموعة من خانات البروتوكول.

أما ارتفاع الكتلة فيحصي الكتل المقبولة في تاريخ السلسلة.

قد ينموان بمعدلين مختلفين لأن بعض الخانات لا تنتج كتلًا.

وقد ينشئ البروتوكول أكثر من مرشح كتلة في خانة واحدة، فيما يقبل الإجماع في النهاية تاريخ سلسلة واحدًا.

ينبغي للمطورين استخدام القيمة الصحيحة لكل مهمة، لا تحويل ارتفاع الكتلة إلى عصر بالاعتماد على افتراض كتلة واحدة لكل خانة.

رقم العصر مقابل الطابع الزمني

رقم العصر مرجع زمني أصلي في البروتوكول.

أما الطابع الزمني فيمثل الوقت التقويمي.

يمكن للبلوكشين تقدير الطابع الزمني المرتبط بحد العصر، لكن ذلك قد يعتمد على توقيت الخانات والسلسلة المعتمدة.

ينبغي للعقود الذكية عدم التعامل مع نهاية عصر مقدرة كموعد خارجي دقيق، إلا إذا ضمن البروتوكول هذه العلاقة.

يمكن للواجهات عرض رقم العصر وتاريخ محلي مقدر معًا للتوضيح.

بيانات جدول العصور والثقة بـ RPC

توفر نقطة نهاية RPC عامة وصولًا مريحًا لمعلومات العصور، لكن المستخدم يثق بهذه النقطة في دقة البيانات التي تعرضها.

قد تعيد نقطة النهاية غير المتاحة أو المتأخرة أو الخبيثة حالة قديمة أو غير صحيحة للعصر.

يمكن للتطبيقات مقارنة عدة عقد أو تشغيل عقدة خاصة بها عندما تكون المعلومات بالغة الأهمية للأمان.

كما ينبغي لها اختيار مستوى الالتزام أو النهائية المناسب للبيانات المطلوبة.

قد تعكس قيمة مرصودة عند مستوى التزام منخفض حالة سلسلة تتغير لاحقًا.

استخدام بيانات العصور في العقود الذكية

ينبغي للبرنامج على السلسلة استخدام مصدر معتمد من البروتوكول لمعلومات العصر أو الساعة.

ولا ينبغي له الوثوق بمستخدم عشوائي يقدم العصر الحالي من دون التحقق منه.

يجب أن تحدد القواعد المعتمدة على العصور ما يحدث بدقة عند الحد الفاصل.

ينبغي للمطورين اختبار الخانة الأخيرة من عصر والخانة الأولى من العصر التالي.

كما ينبغي اختبار عصور الإحماء التاريخية عندما يجري التطبيق حسابات تاريخية.

قد تؤدي أخطاء الوحدة بفارق واحد إلى بدء فترة التخزين أو الحوكمة أو المكافأة أو انتهائها قبل موعدها بخانة أو بعده.

مخاطر الأمان في المنطق المعتمد على العصور

قد تؤدي الحسابات الخاطئة للعصور إلى أخطاء في المكافآت أو التصويت أو السحب أو التحكم بالوصول.

قد يستخدم العقد جدولًا غير صحيح بعد نشره على شبكة أخرى.

قد يفترض التطبيق أن العصور المبكرة ذات طول معتاد رغم مرورها بفترة إحماء.

قد تعرض واجهة المستخدم موعدًا مضللًا إذا حولت الخانات إلى وقت فعلي باستخدام تقدير قديم.

قد يفوّت المدقق واجباته بسبب حساب جدول القادة بطريقة خاطئة.

قد يقبل نظام الحوكمة تصويتًا خارج الفترة المقصودة بسبب خطأ عند الحد.

ينبغي للشيفرة الحساسة للعصور استخدام حسابات صحيحة آمنة وبيانات شبكة موثوقة واختبارات تغطي الحالات الحدية.

كيفية استخدام المطورين لجدول العصور

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

والثانية استرجاع الجدول من واجهات العقد الرسمية أو بيانات النظام.

والثالثة مراعاة عصور الإحماء وأول عصر معتاد إن وُجدا.

والرابعة التمييز بين أرقام الخانات المطلقة وفهارس الخانات داخل العصر.

والخامسة استخدام معلومات العصر المباشرة عند عرض التقدم الحالي.

والسادسة اعتبار أوقات الانتهاء وفق الساعة الفعلية تقديرات، ما لم يحدد البروتوكول توقيتًا دقيقًا.

والسابعة اختبار كل الحسابات حول حدود العصور.

والثامنة متابعة ترقيات البروتوكول التي قد تغير القواعد ذات الصلة.

مثال على حساب جدول العصور

لنفترض أن بلوكشين خياليًا قائمًا على إثبات الحصة يستخدم 10,000 خانة لكل عصر بعد فترة الإحماء.

ولنفترض أن أول عصر معتاد هو العصر 5، وأن أول خانة فيه هي الخانة المطلقة 9,000.

تقع الخانات المطلقة من 9,000 إلى 18,999 ضمن العصر 5.

وتبدأ الخانة المطلقة 19,000 العصر 6.

يشير فهرس الخانة صفر إلى أول خانة في العصر.

ويشير فهرس الخانة 9,999 إلى آخر خانة في العصر المعتاد.

يوضح المثال سبب حاجة البرمجيات إلى معرفة أول خانة معتادة، إلى جانب عدد الخانات في العصر.

الأرقام توضيحية ولا ينبغي تطبيقها على بلوكشين مباشر.

أخطاء شائعة في جداول العصور

من الأخطاء الشائعة افتراض أن كلمة «عصر» تعني المدة نفسها على كل بلوكشين.

ومنها التعامل مع رقم الخانة كأنه ارتفاع الكتلة.

ومنها افتراض وجود كتلة في كل خانة.

ومنها استخدام الطول المعتاد للعصر في عصور الإحماء المبكرة.

ومنها الخلط بين جدول العصور وجدول قادة المدققين.

ومنها اعتبار الوقت المقدر لنهاية العصر ضمانًا دقيقًا.

ومنها افتراض تفعيل معاملة التخزين فور تأكيدها.

ومنها تثبيت قيم الجدول في الشيفرة من دون التحقق من الشبكة المتصلة.

ومنها الاعتماد على نقطة نهاية RPC واحدة غير موثقة لحساب عصر بالغ الأهمية للأمان.

ومنها عدم اختبار الخانتين الأخيرة والأولى حول حد العصر.

الأسئلة الشائعة

ماذا يعني جدول العصور في الكريبتو؟

جدول العصور مجموعة قواعد بلوكشين تحدد كيفية تجميع الخانات في عصور وموعد بدء كل عصر أو انتهائه.

ما الفرق بين العصر والخانة؟

الخانة وحدة زمنية قصيرة للإجماع، بينما العصر مجموعة من الخانات المتتالية.

هل تحتوي كل خانة على كتلة؟

لا، قد تمر خانة من دون كتلة مقبولة إذا كان المنتج المحدد غير متصل أو متأخرًا أو غير ناجح.

هل تتساوى مدة العصر في كل بلوكشين؟

لا، يحدد كل بروتوكول للبلوكشين مدة العصور والخانات بصورة مستقلة.

ما Epoch Schedule في Solana؟

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

ماذا تعيد getEpochSchedule؟

تعيد

و و و و.

هل تعرض getEpochSchedule العصر الحالي؟

لا، تستخدم تطبيقات Solana

للحصول على العصر الحالي والموضع داخله.

ما slotsPerEpoch؟

هو الحد الأقصى لعدد الخانات في كل عصر ذي طول معتاد ضمن المجموعة التي يجري الاستعلام عنها.

ما عصر الإحماء؟

هو عصر مبكر يضم خانات أقل من الطول الكامل المعتاد للجدول.

ما firstNormalEpoch؟

يحدد أول عصر يستخدم العدد الكامل المعتاد من الخانات.

ما firstNormalSlot؟

يحدد رقم الخانة المطلق الذي يبدأ عنده أول عصر ذي طول معتاد.

ما leaderScheduleSlotOffset؟

يصف المدة بالخانات التي تسبق حد العصر ويُحسب خلالها جدول قيادة المدققين المعني.

هل جدول العصور هو نفسه جدول القادة؟

لا، يحدد جدول العصور الحدود بين العصور، بينما يربط جدول القادة المدققين بخانات إنتاج الكتل.

ما مدة عصر Ethereum؟

تستخدم Ethereum حاليًا 32 خانة، مدة كل منها 12 ثانية، ما يمنح العصر مدة مجدولة تقارب 6.4 دقائق.

ما مدة عصر Cardano؟

تحدد وثائق Cardano الحالية 432,000 خانة مدة كل منها ثانية واحدة في العصر، أي ما يعادل خمسة أيام.

هل يمكن أن ينتهي العصر من دون إنتاج كتلة في كل خانة؟

نعم، يمكن أن يستمر تقدم الخانات حتى إذا لم تتضمن بعض الخانات كتلًا مقبولة.

هل تصل مكافآت التخزين عند كل حد عصر؟

ليس بالضرورة، إذ تختلف قواعد الحساب والإضافة والمطالبة والسحب بين بروتوكولات البلوكشين.

هل يمكن أن يعتمد تفعيل التخزين على العصر؟

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

هل يمكن تغيير جدول العصور؟

يمكن تغييره إذا سمح بروتوكول البلوكشين بترقية منسقة، مع أن بعض معلمات الجدول قد تكون مثبتة منذ إنشاء الشبكة.

هل يمكن للمطورين حساب وقت دقيق لنهاية العصر؟

يمكنهم حساب الخانات المتبقية، لكن تقدير الوقت التقويمي قد يتغير عندما يختلف توقيت الخانات الفعلي عن المستهدف.

لماذا تستخدم ترقيات البروتوكول أرقام العصور؟

يوفر رقم العصر نقطة تفعيل حتمية على السلسلة تستطيع العقد المتوافقة حسابها من قواعد الإجماع نفسها.

هل يمكن للعقود الذكية قراءة جدول العصور؟

يعتمد ذلك على البلوكشين، بينما تستطيع برامج Solana الوصول إلى sysvar الخاص بـ EpochSchedule عبر طرق وقت التشغيل المدعومة.

هل رقم العصر هو نفسه رقم الكتلة؟

لا، يضم العصر خانات وكتلًا كثيرة، وقد تمر بعض الخانات من دون إنتاج كتل.

لماذا يهم جدول العصور المدققين؟

يساعدهم على فهم فترات الواجبات وتعيينات القادة وتغييرات التخزين ومحاسبة المكافآت وحدود تفعيل البروتوكول.

ما الطريقة الأكثر موثوقية للحصول على بيانات العصور؟

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

الخلاصة

جدول العصور هو بنية البروتوكول التي تقسم وقت البلوكشين إلى خانات وعصور.

وهو يوفر فترات متوقعة لواجبات المدققين وتناوب القادة وتحديثات التخزين والمكافآت والنهائية والحوكمة وترقيات الشبكة.

العصر مجموعة خانات، والخانة فرصة قصيرة لنشاط إجماع مثل إنتاج كتلة أو التصويت.

الخانات والكتل ليست شيئًا واحدًا، فقد تمر خانة من دون كتلة مقبولة.

على Solana، يشير Epoch Schedule أيضًا إلى بنية محددة للشبكة تتضمن طول العصر المعتاد وإزاحة جدول القادة وحالة الإحماء وحقولًا مرجعية للعصور المعتادة.

تستخدم Ethereum حاليًا 32 خانة مدتها 12 ثانية لكل عصر، بينما تستخدم Cardano حاليًا 432,000 خانة مدتها ثانية واحدة لكل عصر.

توضح هذه الاختلافات ضرورة تفسير توقيت العصور وفق البلوكشين المتصل به دائمًا.

ينبغي للمطورين استرجاع بيانات الجدول من واجهات عقد موثوقة ومراعاة الإحماء واختبار كل حسابات حدود العصور.

ينبغي للمستخدمين اعتبار العد التنازلي التقويمي تقديريًا عندما يتغير توقيت الخانات، وألا يفترضوا إتاحة تغييرات التخزين أو المكافآت فورًا عند كل حد.

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