منهجية درجة مشغّل FTSO

إصدار الخوارزمية: v4.11 · آخر تحديث: 2026-07-04

تُسند FlareWatch إلى كل موفر بيانات FTSO درجة مركبة من 0–100 عبر 12 بُعد مسجل. الحسابات حتمية، والمدخلات عبارة عن بيانات عامة على السلسلة وبيانات من نظام Flare البيئي[Flaremetrics] [FSE] [Flare Explorer] وتنطبق نفس الخوارزمية على كل موفر — بما في ذلك موفر FTSO الخاص بـ FlareWatch، والذي تُسجل درجته بواسطة هذه الدالة الدقيقة بدون معاملة خاصة. توثق هذه الصفحة كل بعد وحد بحيث يمكن للمفوّضين والمشغّلين رؤية بالضبط كيفية حساب النقاط ولماذا تم اختيار كل قيمة. كل مطالبة هنا ترتبط بمصدرها الأساسي الأعلى — انظر المصادر والمراجع في الأسفل.

النطاق: توثق هذه الصفحة درجة مزود FTSO — ما تراه في وضع التفويض على صفحة المدققين (تفويض WFLR إلى موفري بيانات FTSO لحصة تضخم FTSO). تستخدم درجة المدقق الموضحة في وضع الرهان (تفويض FLR إلى مدقق سلسلة P لمكافآت VRM + MIRROR) خوارزمية منفصلة من 9 أبعاد تركز على عمليات المدقق — وقت التشغيل والرسوم والموثوقية وما إلى ذلك. وهي أدوار على السلسلة الفعلية متميزة مع مكافآت متميزة، يتم تسجيلها بشكل منفصل. اطلع على منهجية درجة المدقق للجانب الرهان.
تغطية سلسلة FLR / SGB: يحتوي علامة التبويب التفويض على صفحة المدققين على FLR / SGB بديل للمحافظ التي تحتفظ بأي Songbird (SGB). توثق هذه المنهجية درجة الجانب FLR فقط. يتم إدراج موفري FTSO في Songbird بدون درجة مركبة — نفس بيانات الدقة / الاتساق / مكافآت FSP التي نستخدمها لـ FLR لم يتم توصيلها بعد في خط أنابيب Songbird الخاص بنا (Flaremetrics، مصدر بيانات FLR الأساسي لدينا، لا يغطي Songbird). ما يراه مفوضو SGB اليوم: اسم المزود + شعار من سجل TowoLabs متعدد الشبكات، الوزن الحالي (WSGB مفوض، قراءة مباشرة من عقد Songbird's WNat عبر خادم RPC Songbird الخاص بنا)، وعنوان URL المزود. الترتيب حسب الوزن؛ الوزن الأكبر هو الإشارة البديلة حتى تصل بيانات الدقة. عندما نوصل خط أنابيب دقة Songbird + معدل المكافأة، ستنطبق نفس صيغة 13 البعد على موفري SGB — بدون خوارزمية تسجيل جديدة، فقط صيغة FLR المحسوبة مقابل بيانات Songbird. لا يحتوي تسجيل مدقق FlareWatch (علامة التبويب الرهان) على ما يعادل SGB على الإطلاق: تم تقييد مجموعة مدققي سلسلة Songbird's P بالكيانات المعتمدة من Flare Foundation، لذا فإن تفويض SGB P-Chain بالتجزئة نادر وتبقى علامة التبويب الرهان بـ FLR فقط.
فئات الدرجات
90+الفئة العليا — أفضل ~10–20% من موفري FTSO. الملف الشخصي النموذجي: معدل مكافآت أعلى من المتوسط، دقة عالية، مشاركة كاملة في بروتوكول V2 (FTSO Scaling + Fast Updates + FDC)، رسوم منخفضة / صفر، قاعدة مفوضين كبيرة، عقد مدقق تدفع MIRROR، علامة تجارية مسماة. لا يوجد بُعد واحد مطلوب — يصل موفرو الفئة العليا بتراكم القوة عبر معظم الفئات.
80–89قوي — يلبي معظم المعايير الرئيسية؛ بُعد واحد أو اثنان أقل من الفئة العليا.
70–79جيد — يلبي جميع معايير الأساس؛ بدون فجوات كبيرة.
60–69مقبول — قابل للاستخدام ولكن غير متميز.
<60أقل من المتوسط — فجوات كبيرة في بُعد واحد أو أكثر. حقيقة رياضية، وليست حكماً على الجودة.
الأبعاد (الأوزان الخام — مجموعها 172، معايير إلى 100)
«نشط» يحكم بعدين (الرسم والمشاركة في V2): يجب ألا يجمع مزود لا يعمل رصيداً لإعلانه رسماً منخفضاً. يُعتبر المزود نشطاً إذا كان لديه معدل مكافآت منشور أو إذا أظهرت بيانات مكافآت بروتوكول أنظمة Flare أنه دفع في فترة واحدة على الأقل من نافذة التسجيل. حتى 2026-07-31 كان المعدل المنشور وحده، الذي جاء من واجهة برمجية لطرف ثالث واحد — لذا فإن المزود الذي لا تغطيه تلك الواجهة البرمجية سجّل صفراً على كلا البعدين بينما يوزع المكافآت بشكل واضح كل فترة. النشاط خاصية المزود، وليس لمن يحتفظ بقائمة به.
معدل المكافأة25 نقاط كحد أقصى
ما: معدل مكافآت المزود لكل عصر، مرتبط بمتوسط الشبكة.
كيف: النسبة = معدل المزود / معدل المتوسط. خطي: النسبة 1.0 (المتوسط) → 12.5 نقطة، النسبة 2.0 → 25 نقطة (الحد الأقصى). مزود غير نشط (المكافأة ≤ 0) → 0. v4.0 (2026-05-11): تم إعادة تعيين الحد الأقصى بحيث يكون المتوسط = نصف نقاط البعد (وليس 40% كما كان من قبل).
if (rate <= 0 || medianRate <= 0): score = 0
else:
  ratio = rate / medianRate
  score = min(25, round(ratio * 12.5 * 10) / 10)   // 1 decimal place

// Anomaly detection: providers > 3× the median are capped at
// median × 3 for scoring purposes (prevents data outliers from
// distorting the linear curve).
لماذا: معدل المكافأة هو الشيء الأول الذي يختبره المفوضون. ترساء المتوسط يحافظ على الدرجة صادقة مع تحول اقتصاديات المكافآت في الشبكة — يتم تصنيف المزود بـ 1.2 × المتوسط في عصر المكافآت المنخفضة بنفس طريقة 1.2 × في عصر المكافآت العالية. تمنع الحد الأقصى وفلاتر الحالات الشاذة أحاديات العصر من الهيمنة.
الدقة25 نقاط كحد أقصى
ما: دقة سعر FTSO من Flare Systems Explorer (FSE) — معدلات هبوط فئة المكافآت الأساسية (IQR الضيقة) والثانوية (الأوسع).
كيف: مزيج 40/60 من معدلات هبوط فئة FTSO الأساسية (IQR الضيقة) والثانوية (الأوسع) (v4.8)، يعكس تقسيم مكافآت Flare الخاص — FIP.11 يدفع مكافآت خلاصة الارتساء 40% أساسية / 60% ثانوية. الثانوية تستخدم المنحنى الجزئي السابق (97% → 25 … 70% → 2)؛ إنها مشبعة تقريباً عبر الحقل (95–99%)، لذا بالكاد تميز. الأساسية تستخدم منحنى خطي مطلق — 28% → 0 حتى 78% → كامل 25 — لذا فإن هندسة الفئة الضيقة الأصعب بكثير، حيث يتفرق المزودون فعلياً من ~28% إلى ~80%، هي ما يميز الحقل. مراسي ثابتة (ليس نسب مئوية للحقل)، لذا تبقى الدرجة قابلة للاستنتاج من مدخلات مزود الخدمة الخاصة به. مرجع أحادي الفئة عند توفر فئة واحدة فقط؛ محايد 12.5 بدون بيانات FSE.
if (fseAccuracySecondary > 0):
  pct = fseAccuracySecondary / 100
  if (pct >= 97) score = 25
  elif (pct >= 95) score = 18 + (pct - 95) * 3.5     // 95 → 18,  97 → 25
  elif (pct >= 93) score = 16 + (pct - 93) * 1       // 93 → 16,  95 → 18
  elif (pct >= 90) score = 13 + (pct - 90) * 1       // 90 → 13,  93 → 16
  elif (pct >= 85) score = 10 + (pct - 85) * 0.6     // 85 → 10,  90 → 13
  elif (pct >= 80) score = 6  + (pct - 80) * 0.8     // 80 → 6,   85 → 10
  else              score = max(0, 2 + (pct - 70) * 0.4)
elif (fseAccuracyPrimary > 0):
  // Primary fallback: similar piecewise linear curve.
else:
  score = WEIGHT_ACCURACY / 2   // Neutral — no FSE data
لماذا: الحقب المفقودة = دخل مكافآت مفقود للمفوضين. الدقة هي ما يحدد ما إذا كانت تقديمات المزود تحسب فعلاً لإجماع FTSO، والمقياس الثانوي (الذي يزن الحقب الأحدث بشكل أكبر) هو الذي ينطبق بأنظف طريقة على الأداء الحالي.
الاتساق20 نقاط كحد أقصى
ما: مدى استقرار معدل مكافآت المزود عبر حقبه الكسبية الأخيرة.
كيف: التقلب الهبوطي عبر فترات الكسب الأخيرة للموفر، مقاس فقط بين الفترات التي تكون متتالية بحقيقة — فترة لم يكسب فيها الموفر شيئاً لا تترك سجلاً، والفترتان على جانبي هذه الفجوة لا تُقارن أبداً ببعضهما. فقط انخفاضات فترة تلو فترة تُحتسب — الارتفاع يساهم بصفر — لذا المعدل المستقر أو الصاعد يسجل درجة قريبة من الكاملة والتعافي يرفع الدرجة مع حدوثه. يتم تجميع الانخفاضات باستخدام RMS بحيث يكون الانخفاض الحاد أثقل وزناً من الانخفاض الطفيف، وموزون نحو الأزواج الأخيرة (decay 0.8) بحيث يرفع التعافي النشط الدرجة بينما تشيخ الانخفاضات القديمة. cv = 0 → 20 نقطة؛ cv ≥ ~0.167 → 0. محايد 10 عندما توجد أقل من 3 أزواج فترات متتالية في آخر 12 فترة كسب.
earned = last 12 epochs where rewardRate > 0, keyed by epochId
pairs  = [earned[i-1], earned[i]] where epochId[i] - epochId[i-1] == 1
if (pairs.length < 3) return 10        // Neutral — too few consecutive pairs

// DOWNSIDE volatility only: rises never hurt, so a stable or RISING
// rate scores near full and a recovery lifts the score. Only drops
// between CONSECUTIVE epochs count, in proportion to depth (RMS),
// weighted toward recent pairs so an active recovery pulls the score up.
drops[i] = max(0, (prev - cur) / prev)     // rise -> 0
w[i]     = 0.8 ^ (age of pair)             // newest pair = highest
cv       = sqrt( sum(w[i] * drops[i]^2) / sum(w[i]) )
score    = max(0, round((1 - min(1, cv * 6)) * 20 * 10) / 10)
لماذا: يمكن لمزودي الخدمة اثنين بنفس معدل المكافآت المتوسط أن يقدما تجارب مختلفة جداً للمستثمرين: واحد ينخفض بشدة أسوأ من واحد يبقى مستقراً أو يرتفع. تكافئ الاتساقية ما يريده المفوض فعلاً — معدل مستقر أو صاعد — وتعاقب فقط الانخفاضات، بما يتناسب مع العمق. معدل يعود للأعلى لا يعاقب أبداً (المقياس المتماثل الأقدم كان يفعل، وهو خاطئ). الانخفاض القوي الأخير يحقق درجة منخفضة ثم يتعافى مع تلاشيه.
مشاركة V215 نقاط كحد أقصى
ما: ما إذا كان المزود يقوم بتشغيل مكدس V2 الحديث (FTSO Scaling + Fast Updates + FDC).
كيف: تراكم البروتوكول القاعدي. خط أساس نشط (مكافأة > 0) +3، جزء V1 (إرسال + توقيع + ناخب) +4، كل بروتوكول V2 (FTSO Scaling / Fast Updates / FDC) +~2.67 لكل واحد، الحد الأقصى 15. غير نشط → 0. v4.0 (2026-05-11) قسم المستوى السابق الكل أو لا شيء (حيث جزء V1 = V2 كامل = 15 — لا حافز للترقية) إلى مكافآت بروتوكول منفصلة تتراكم.
if (!isActive) score = 0     // see "Active" below
else:
  score = 3   // active baseline
  if (hasSubmitAddress AND hasSigningPolicyAddress AND voterRegistered):
    score += 4   // V1 registered
  if (fseFtsoScaling)  score += 8/3   // ~2.67 each
  if (fseFastUpdates)  score += 8/3
  if (fseFdc)          score += 8/3
  score = min(15, round(score * 10) / 10)
لماذا: V2 هو المكان الذي تتجه إليه الشبكة. تراكم البروتوكول في v4.0 يعني أن الترقية من جزء V1 إلى V2 كامل تحرك الدرجة بالفعل (قبل الإصلاح لم تكن كذلك — جزء V1 و V2 كامل كليهما أرجع 15). إضافة أي بروتوكول V2 واحد الآن يحسن البعد.
الرسوم15 نقاط كحد أقصى
ما: الرسوم التي يفرضها المزود على المكافآت المفوضة.
كيف: استيفاء خطي عبر نقاط الانقطاع: 0% → 15، 5% → 13، 10% → 10، 15% → 7، 20% → 4، ≥25% → 0. مزود غير نشط → 0.
anchor = max(lowest active fee observed, protocol fee floor)
// FIP-16 sets a 20% minimum entity fee. All 98 providers charge
// exactly 20%, so the anchor is 20% and nobody is docked for
// charging the only fee the protocol permits. Same curve and
// same anchor the validator page's Fee dimension uses.

if (!isActive) score = 0
d = fee - anchor              // distance ABOVE the best real offer
if (d <= 0)  score = 15       // at or below the anchor → full marks
elif (d <= 5)  score = 15 - d * 0.43
elif (d <= 10) score = 12.9 - (d - 5) * 0.64
elif (d <= 15) score = 9.6 - (d - 10) * 0.86
elif (d <= 20) score = 5.4 - (d - 15) * 1.07
else: score = 0               // extractive
لماذا: الرسوم تقلل مباشرة ما يتلقاه المفوضون. الاستيفاء الخطي (بدلاً من الدلاء) يعني أن رسوم 7% تسجل بين 10% و 15% بدلاً من الانقطاع إلى دلو واحد — المشغلون لا يحصلون على رصيد لتقريب رسومهم لأسفل إلى حد الدلو التالي.
مشاركة MIRROR12 (+3 مكافأة إضافية) نقاط كحد أقصى
ما: ما إذا كانت عقد مدقق سلسلة P الخاصة بالمشغل تدفع بنشاط حصة تضخم FTSO إلى أصحاب الرهان، بالإضافة إلى مكافأة الأداء الفائق.
كيف: تتسع نقاط الأساس بشكل خطي مع كسر معرّفات العُقد (nodeIDs) للمشغِّل التي تدفع مكافآت MIRROR. جميع العُقد نشطة → 12 نقطة. جزئية → متناسبة. بلا عُقد → 0. اعتبارًا من 2026-05-11، يقرأ إشارة "النشطة" من مصدرين قانونيين: أحداث RewardClaimed(claimType=3) على السلسلة في مدير المكافآت V2 AND تخصيصات claimType=3 في JSON ملف Merkle الرسمي لـ FSP — أي منهما كافٍ. قبل التحديث كنا نستخدم سيل الشبكة كالإشارة الوحيدة، مما أنتج إيجابيات كاذبة لمقدمي الخدمات الذين يتم تسوية MIRROR لديهم عبر مسار مطالبة غير قياسي. بالإضافة إلى مكافأة أداء إضافية بقيمة حتى +3 نقاط عندما تسلّم عُقد المشغِّل بشكل متسق أكثر من 100% من المتوقع (vrm + mirror) / المتوقع — الانكماش البايزي مع بوابة تراكم بيانات 30 يومًا وحد أدنى من عينة 3 حصص يمنع المشغِّلين الصغار أو الجدد من التلاعب بالمكافأة على بعض القراءات الحظية.
if (no fseNodeIDs) score = 0
if (mirrorStatsMap empty) score = 12 / 2 = 6   // Neutral seed before data lands

activeCount = nodes_with_status_active
fraction = activeCount / fseNodeIDs.length
base = 12 * fraction

// Overperformance bonus per node, applied only when ALL gates pass:
//   - >= 30 days observed since first reading (firstObservedAtMs)
//   - >= 3 paid stake observations
//   - finite medianOverpaymentRatio
// Bayesian shrinkage with prior k=5 toward 1.0 (neutral):
//   shrunken = (observedRatio * N + 1.0 * 5) / (N + 5)
// Bucketed bonus from shrunken:
//   < 1.05 → 0    < 1.15 → 1    < 1.30 → 2    >= 1.30 → 3

avgBonus = sum_per_node(bonus) / fseNodeIDs.length
score = round((base + avgBonus) * 10) / 10
لماذا: مشاركة MIRROR هي ما تفوّض حصة التضخم FTSO إلى معسكرك. مقدّم خدمات نشط في V2 الذي لا تدفع عُقده MIRROR يشحن حوالي 5-15% أقل من العائد إلى المفوّضين مقابل نفس مقدّم الخدمة مع عُقد نشطة. تكافئ مكافأة الأداء الإضافية التسليم الأفضل بشكل متسق من المتوقع دون تضخيم مشغِّلي جديد على عينات صغيرة — الانكماش البايزي وبوابة التراكم لمدة 30 يومًا تحافظ عليه منصفًا.
عدد المفوّضين12 نقاط كحد أقصى
ما: عدد المحافظ المميزة التي تفوض حالياً إلى هذا المزود، محسوبة من حالة السلسلة.
كيف: يتم رسمه بمقياس لوغاريتمي من 5 → 500 مُفوّضين مرسومة إلى 0 → 12. ≤5 → 0، ≥500 → 12 (حد). يطابق أسلوب إشارة العدد لبُعد Trust في المدقق. v4.0 (2026-05-11): أصلحنا خطأ حقيقي حيث كان لديه خطة الجرافة السابقة حافزًا معكوسًا تمامًا عند 500 مفوّض بالضبط (قبل الإصلاح: 500 → 14، 501 → 12 — الحصول على مفوّض عبر هذا الحد فقد 2 نقطة).
if (count <= 5)   score = 0
elif (count >= 500) score = 12
else:
  ratio = log(count / 5) / log(100)   // maps [5, 500] → [0, 1]
  score = round(min(12, max(0, ratio * 12)) * 10) / 10
لماذا: عدد المفوّضين هو إشارة ثقة — مستقلة عن حجم الحصة. مقدّم خدمة لديه 200 مُفوّض تم اختياره من قبل 200 محفظة مستقلة؛ واحد به 5 تم اختياره من قبل المشغِّل بشكل وثيق. يعطي الرسم اللوغاريتمي عوائد متناقصة بعد حوالي 50 مُفوّض دون الانعكاس (الطريقة التي فعلتها التنقيط قبل v4.0).
مشاركة الحقبة10 نقاط كحد أقصى
ما: ما إذا كان مقدّم الخدمة يشارك بنشاط في الحقب.
كيف: يضع FSE العلم النشط لمقدّم الخدمة → 10. مقدّم الخدمة لديه rewardRate > 0 (Flaremetrics) لكن بدون علم نشط FSE → 7 (نشط حسب بيانات السوق، مفقود تأكيد FSE). خلاف ذلك → 0.
if (fseActive) score = 10
elif (rewardRate > 0) score = 7
else score = 0
لماذا: يمسك مقدّمي الخدمات الذين توقف تيار مكافآتهم حتى لو لا تزال Flaremetrics تدرجهم. مختلفة عن الدقة (التي تتعلق بصحة كل حقبة) — المشاركة تتعلق بالظهور على الإطلاق.
استقرار قوة التصويت10 نقاط كحد أقصى
ما: التغير نسبة مئوية من يوم إلى يوم في قوة التصويت لمقدّم الخدمة.
كيف: خطي متعدد الأجزاء في قيمة مطلقة من يوم إلى يوم بالمئة. <1% → 10. خطي من 1% → 3% (10 → 7). خطي من 3% → 5% (7 → 4). خطي من 5% → 10% (4 → 2). يستمر نحو 0 بعد 10%. v4.0 (2026-05-11): خطّية الأخطار السابقة (كانت حتى 3 نقاط أخطار في كل حد).
change = abs(votePowerDailyChangePct * 100)
if (change < 1)  score = 10
elif (change < 3) score = 10 - (change - 1) * 1.5     // 1 → 10, 3 → 7
elif (change < 5) score = 7  - (change - 3) * 1.5     // 3 → 7,  5 → 4
elif (change < 10) score = 4 - (change - 5) * 0.4     // 5 → 4, 10 → 2
else               score = max(0, 2 - (change - 10) * 0.1)
لماذا: التأرجحات الكبيرة من يوم إلى يوم في قوة التصويت غالبًا ما تشير إلى موجة مفوّض تتحرك داخل أو خارج — المراهنون الذين يقرؤون الجدول يرون هدفًا متحركًا. قوة تصويت مستقرة تشير إلى مقدّم خدمة مستقر مع مفوّضين ملتصقين.
الامتثال10 نقاط كحد أقصى
ما: ما إذا تم الدفع لمقدّم الخدمة في كل حقبة مكافآت منذ أصبح نشطًا في بيانات مكافآت FSP.
كيف: 10 نقاط كاملة لصفر حقب مفقودة ضمن نافذة نشاط مقدّم الخدمة. كل حقبة مفقودة تخصم 3 نقاط (محصورة عند 0). محايد 5 عندما لا تتوفر بيانات FSP. v4.4 (2026-06-30): الحقب المفقودة يتم عدها الآن فقط من أول حقبة مشاركة لمقدّم الخدمة فصاعدًا — لم يعد يتم فرض رسوم على مقدّم خدمة جديد عن الحقب قبل وجوده (التي احتفظت سابقًا بعُقد جديدة ولكن نظيفة عند 0/10 لأسابيع).
if (no fspData OR totalEpochs <= 0) score = 5

// active window = epochs from the provider's first paid epoch to now
missed = (active-window epochs) - (epochs the provider was paid)
score = max(0, 10 - missed * 3)
لماذا: حقبة مفقودة في توزيع مكافآت بروتوكول أنظمة Flare الرسمي تعني أن مقدّم الخدمة فشل في الامتثال للبروتوكول لتلك الحقبة — الحد الأدنى من الشروط، سياسة التوقيع، إلخ. عد الحقب فقط من المشاركة الأولى يحافظ على الإجراء منصفًا لمقدّمي الخدمات الجدد مع الاستمرار في معاقبة الغيابات الفعلية. ثلاث نقاط لكل غياب شديدة لذا فإن غياب واحد هو إشارة ملحوظة لكن قابلة للاسترجاع؛ حوالي 3 غيابات يضع البُعد عند الصفر.
الهوية8 نقاط كحد أقصى
ما: ما إذا كان لدى مقدّم الخدمة اسم علامة تجارية حقيقي أم مجرد عنوان سادس عشري.
كيف: علامة تجارية معروفة (≥4 أحرف، لا تبدأ بـ 0x) → 8. قصير أو مجهول (<4 أحرف) → 4. عنوان سادس عشري نقي / 0x كاسم → 0.
if (no name) score = 0
elif (name starts with 0x or matches hex regex) score = 0
elif (name.length < 4) score = 4
else score = 8
لماذا: مقدّم الخدمة المسمى اختار أن يكون قابلاً للعثور والمساءلة — يمكن البحث عنهم والاتصال بهم والاحتفاظ بهم حسب الالتزامات المنشورة. مقدّمو الخدمات المجهولون حسب العنوان وظيفيون لكنهم يقدمون عددًا أقل من إشارات الثقة للمفوّضين الذين يقيّمونهم.
السند الذاتي7 نقاط كحد أقصى
ما: رابط عقدة P-Chain الخاص بالمشغِّل (الجلد في اللعبة) — باستثناء الحصة التي يفوّض بها آخرون إلى العقدة. بوابة التزام محايدة بالحجم، وليس تصنيفًا للثروة.
كيف: مُعترَف به على الأكبر من محورين مشبّعين: (1) الانتظام — السند الخاص كحصة من إجمالي الحصة الملتزمة (≥10% → كامل)؛ أو (2) مطلق — رأس مال المشغِّل في الخطر، محدود بـ 5M FLR بحيث يسجل 5M و 80M نفس الشيء. v4.4 (2026-06-30): أعاد الاستطلاع من السند الذاتي الحقيقي لـ P-Chain للمشغِّل (وزن المدقق عبر الإشارة بـ nodeID) — حقل Flaremetrics السابق كان متوقفًا، لذا سجّل كل مقدّم خدمة 0. v4.5 (2026-06-30): أضاف المحور المطلق + الإشباع بحيث لا يتم تسجيل سند ذاتي كبير بنسبة منخفضة أقل من واحد صغير بنسبة عالية، دون ترك الحجم يفوز أو معاقبة المشغِّلين الصغار.
ownBond      = operator's own P-Chain node bond (FLR)
total        = ownBond + delegated WFLR vote power
alignment    = piecewise-linear ratio curve (0% → 0 … ≥10% → 7)
absolute     = min(7, ownBond / 5,000,000 * 7)   // saturates at 5M FLR
score        = max(alignment, absolute)
لماذا: الجلد في اللعبة — مشغِّل لديه رأس مال خاص به في الخطر متوافق مع المفوّضين. لكن حجم السند الذاتي ليس وكيلاً عن جودة المشغِّل (التي تعيش في الأبعاد الأخرى)، لذا فإن مشغِّل صغير محاذى بالكامل واحد كبير ملتزم كلاهما يكسب علامات كاملة. فقط مشغِّل بقليل من رأس ماله الخاص الملتزم — حصة صغيرة AND مبلغ صغير — يسجل أقل من كامل.
كيفية تسجيل 100/100 — دليل مقدّم خدمة FTSO
تم تصميم تدقيق العدالة v4.0 على وجه التحديد بحيث يؤدي تعظيم كل بُعد درجة فعلاً إلى جعلك مقدّم FTSO أفضل لمفوّضيك. تحسين درجتك ليس تلاعبًا بالنظام — إنه النظام يعمل كما هو مصمم. إليك دليل التشغيل لكل بُعد.
معدل المكافآت — 25 نقطة. سلّم ≥ 2× معدل مكافآت FSP الوسطي للشبكة لكل حقبة (بعد الرسم، بعد توزيع البروتوكول). خطي من 0 إلى 2× الوسطي: الوسطي → 12.5، 2× الوسطي → 25. لماذا هذا متوافق: هذا هو مبلغ الدولار الذي يصل بالفعل إلى مفوّضيك لكل حقبة.
الدقة — 25 نقطة. استهدف ≥97% معدل هبوط نطاق ثانوي على FSE للنقاط الكاملة. خطي متعدد الأجزاء بحيث 95% → 18، 93% → 16، 90% → 13، إلخ. — كل تحسن بنسبة 1% يحرّك الدرجة. هذه QUALITY الأسعار، وليس مشاركة الحقبة: يقيس الكسر من الأسعار المُرسلة التي تهبط داخل الفرقة المقبولة على السلسلة. مقدّم خدمة بدقة عالية ينشر أسعارًا قريبة من الإجماع؛ واحد بدقة منخفضة يُرسل بموثوقية لكن خارج الإجماع في كثير من الأحيان. لماذا هذا متوافق: عمليات الإرسال خارج النطاق تنتج مكافآت أصغر للمفوّضين حتى عندما يشارك مقدّم الخدمة في كل حقبة. يتبع بُعد الامتثال المنفصل أدناه مشاركة الحقبة.
الاتساق — 20 نقطة. قلّل تباين معدل المكافآت لكل حقبة (CV = stddev/mean عبر حقب حديثة). CV = 0 → 20، CV = 0.2+ → 0. لماذا هذا متوافق: اثنين من مقدّمي الخدمات بنفس معدل المكافآت الوسيط ليسا متكافئين — المدفوعات القابلة للتنبؤ تفوز على الأسواق المتقلبة لـ UX المراهن.
مشاركة V2 — 15 نقطة. كومة البروتوكولات بشكل إضافي: الخط الأساسي النشط + تسجيل V1 الجزئي + كل بروتوكول V2 (التحجيم، FastUpdates، FDC). V2 الكامل + نشط + مسجل V1 = 15. لماذا هذا متوافق: V2 هي المكان الذي تتجه إليه الشبكة؛ كل بروتوكول إضافي تعتمده هو استثمار مستقبلي يستفيد مفوّضوك منه.
الرسم — 15 نقطة. اشحن ≤ 5% لـ 13 نقطة، 0% لـ 15. منحدر خطي متعدد الأجزاء من خلال نقاط فاصلة 5%/10%/15%/20%/25% إلى 0. لماذا هذا متوافق: رسم أقل = مزيد من المكافآت تصل إلى مفوّضيك بشكل مباشر.
مشاركة MIRROR — 12 + حتى 3 مكافأة إضافية. قم بتشغيل جميع عُقد مدقق P-Chain التابعة لمشغِّلك كـ MIRROR-نشطة (إما عبر أحداث RewardClaimed على السلسلة OR تخصيصات JSON ملف Merkle FSP — مصدر ثنائي v3.6). الأداء الزائدة المستدامة (نسبة (vrm+mirror)/المتوقع متوسط أعلى من 1.05) على ≥3 حصص مدفوعة بعد 30 يومًا من المراقبة تكسب حتى +3 مكافأة إضافية. لماذا هذا متوافق: MIRROR هي حصة مفوّضيك من تضخم FTSO؛ عُقد لا تدفع MIRROR تشحن حوالي 5-15% أقل من العائد إلى المراهنين.
عدد المفوّضين — 12 نقطة. يتم رسمه بمقياس لوغاريتمي 5 → 500 مفوّض مرسومة إلى 0 → 12. بناء قاعدة من المراهنين المستقلين، وليس فقط بعض الحيتان. لماذا هذا متوافق: العد هو إشارة ثقة مستقلة عن حجم الحصة؛ 200 مفوّض يختارونك يعني 200 موافقة مستقلة.
مشاركة الحقبة — 10 نقاط. ظهر في كل حقبة برسم معدل مكافآت إيجابي وعلم نشط FSE. لماذا هذا متوافق: يمسك تيارات المكافآت المتوقفة التي قد تفتقدها الأبعاد لكل حقبة.
الاستقرار — 10 نقاط حافظ على تغيير قوة التصويت من يوم لآخر تحت 1%. منحدر خطي متدرج من هناك. السبب في توافقه: قوة التصويت المستقرة تشير إلى مندوبين مستقرين (مجتمع لصيق) بدلاً من موجات الحيتان العابرة.
الامتثال — 10 نقاط لا توجد حقب مكافآت مفقودة في بيانات FSP. كل حقبة مفقودة تكلف 3 نقاط؛ حوالي 3 حقب مفقودة تصفر البعد. هذا هو المشاركة، وليس جودة السعر: يحسب الحقب حيث عوقب المزود لعدم استيفاء الحد الأدنى من الشروط أو سياسة التوقيع أو متطلبات البروتوكول الأخرى — مختلف عن بعد الدقة أعلاه الذي يسجل هبوط السعر ضمن النطاق. السبب في توافقه: حقبة مفقودة في توزيع المكافآت الخاص بالبروتوكول يعني أن المزود فشل في استيفاء الحد الأدنى من الشروط والمندوبون لم يكسبوا شيئاً في تلك الحقبة. يمكن لمزود أن يتمتع بدقة ممتازة في الحقب المشاركة وقد يزال يفقد حقب بالكامل.
الهوية — 8 نقاط سجل اسم علامة تجارية حقيقية (≥4 أحرف، وليس عنوان سادس عشري) على Flaremetrics أو FSE. المزودون المجهولون حسب العنوان يسجلون 0؛ المزودون المسمون يسجلون 8. السبب في توافقه: المزودون المسمون يمكن العثور عليهم وتحمل المسؤولية؛ هذا هو إشارة الثقة الأساسية.
الالتزام الذاتي — 7 نقاط التزم برابط عقدة P-Chain الخاص بك (وليس stake الآخرين الذي يندفعون إليك). علامات كاملة إما لحصة ذات مغزى من إجمالي stake الخاص بك (≥10%) أو مبلغ مطلق ذي مغزى (محور المبلغ المطلق يصل إلى 5M FLR، لذلك لا يمكن لمشغل كبير الحصول على نقاط أعلى من مشغل صغير على الحجم). السبب في توافقه: جلد في اللعبة — المشغلون برأس مال خاص بهم معرضون للخطر يشاركون نتائج العائد الخاصة بمندوبيهم. إنها بوابة التزام محايدة للحجم، وليست تصنيف الثروة: مشغل صغير محاذي بالكامل ومشغل كبير ملتزم كلاهما يضعهما في الحد الأقصى، وتُحكم جودتك التشغيلية بالأبعاد الأخرى.
إشارات مقفلة زمنياً لا يمكنك الالتفاف حولها: الاتساق يحتاج ≥3 حقب من السجل. مكافأة فرط الأداء MIRROR تحتاج 30 يوماً من الملاحظة بالإضافة إلى ≥3 عينات stake مدفوعة. الامتثال يحتاج بيانات FSP تمتد عبر حقب كافية للعد. بناء سجل؛ ستتبع النتيجة.
الدرجة الخام مجموعها الأقصى هو 172 عبر جميع الأبعاد المسجلة الـ 12 ويتم تطبيعها بعد ذلك إلى 100. تشغيل مثالي على المدخلات يحقق 172/172 → 100 معروض. يتم تطبيق عقوبة تخفيف قوة التصويت بحد أقصى −3 نقاط للموفرين الكبيرين جداً (>1.34B VP) كمقسم.
كيفية التحقق من درجتك الخاصة
كل درجة في جدول المزودين قابلة للتكرار من البيانات العامة. إذا كنت مشغلاً والعملية الحسابية هنا لا تطابق الدرجة التي تراها، فالحركة الصحيحة هي التحقق بنفسك قبل افتراض أننا ارتكبنا خطأ. شرح:
  1. ابحث عن إحصائيات مزودك العامة على flaremetrics.io (ابحث بالاسم أو الصق عنوان التفويض الخاص بك). لاحظ fspRewardRate وdelegationFeePercentage وwNatWeight وvotePowerDailyChangePct.
  2. تحقق من FTSO V2 + الدقة الخاصة بك على flare-systems-explorer.flare.network. ابحث عن كيانك. تحقق من providersuccessrate.secondary للدقة، بالإضافة إلى علامات entityminimalconditionslatest.ftso_scaling / ftso_fast_updates / fdc لحالة V2.
  3. تحقق من مشاركة MIRROR على عقد V2 RewardManager عبر flare-explorer.flare.network. ابحث عن أحداث RewardClaimed مع claimType=3 التي تشير إلى nodeIDs الخاصة بك. إذا لم تكن هناك أحداث حديثة لأي من عقدك، ستظهر كـ MIRROR-inactive على الدرجة.
  4. ضع مدخلاتك في الصيغ أعلاه. يخبرك كتلة الكود الخاصة بكل بُعد بالضبط ما هي العملية الحسابية التي يجب تشغيلها. اجمع الأبعاد، اقسم على 172 (الحد الأقصى الخام)، اضرب في 100، وستحصل على درجتك المركبة الخام.
  5. تطبيق عقوبة التخفيف إذا كنت كبيراً. قوة التصويت فوق 1.34B هي −3، فوق 1B هي −1. بطاقة الدرجة النهائية أدناه لديها الحدود الدقيقة.
  6. قارن بدرجتك المعروضة. الدرجة المعروضة تعكس أيضاً إعادة توزيع الوزن الديناميكي — عندما يتجمع معظم المزودين في بعد واحد (الانحراف المعياري المنخفض عبر المجموعة النشطة)، يتم إعادة توزيع وزن البعد هذا إلى أبعاد حيث يكون الانتشار أوسع. لوحة تفاصيل الدرجة على كل صف مزود تعرض القيم الحالية لكل بعد.
  7. إذا لم تضف العملية الحسابية، أرسل بريداً إلى [email protected] مع عنوان التفويض الخاص بك والمدخلات التي استخدمتها والدرجة التي حسبتها. سنرد، وإذا ارتكبنا خطأ فسنصلحه علناً.
المخاوف العامة للمشغلين
معدل المكافأة الخاص بي أعلى من الوسيط لكن درجة معدل المكافأة الخاصة بي ليست 25/25 — لماذا؟
معدل المكافأة خطي في النسبة إلى الوسيط: score = ratio × 12.5، لذا 1.0× الوسيط = 12.5/25 وتحتاج إلى نسبة 2.0× للوصول إلى الحد الأقصى. مزود بـ 1.2× الوسيط يسجل 15، بـ 1.5× يسجل ~18.8، بـ 2.0× يسجل الـ 25 الكامل. الحد الأقصى (بالإضافة إلى مرشح شذوذ 3×-median) يوجد بحيث لا يمكن لحقبة مكافأة واحدة شاذة عالية السيطرة على البعد؛ إذا كان معدلك متسقاً في decile العلوي، فإن النتيجة تزال تكافئه بشدة.
لقد قمت بالترقية إلى V2 — متى تتحدث درجة V2 الخاصة بي؟
حالة V2 تأتي من علامات FSE's entityminimalconditionslatest (ftso_scaling, ftso_fast_updates, fdc). منذ v4.0 يتراص البعد لكل بروتوكول: baseline نشط +3، تسجيل V1 (submit + signing + voter) +4، وكل بروتوكول V2 +~2.67. لذا مزود مسجل كـ voter مع عناوين submit + signing لكن لا أي من البروتوكولات الثلاثة V2 يسجل 7/15، وكل بروتوكول V2 فردي تشغله ينقل النتيجة — الثلاثة حي يحصل على الـ 15 الكامل. التغييرات تهبط على تشغيل FlareWatch cron التالي (كل 5 دقائق) بعد أن يعكسها FSE.
دقتي على FSE هي 96% لكنني أسجل أقل من المتوقع.
بعد الدقة يستخدم مقياس دقة FSE's secondary (دقة أعلى في نطاق 94–97% حيث معظم المزودين يتجمعون). 95–96% يعيّن إلى 18 نقطة؛ تحتاج ≥97% للـ 25 الكامل. الدلاء ضيقة في الأعلى لأن بضعة أعشار من النسبة المئوية في نطاق 95–97% تمثل فصل أداء حقيقي بين المزودين.
أنا أسلم MIRROR — لماذا يعرض FlareWatch لي كـ MIRROR-inactive على درجة مزودي؟
اعتباراً من 2026-05-11، يتم اكتشاف مشاركة MIRROR من مصدرين: أحداث RewardClaimed(claimType=3) على السلسلة على V2 RewardManager، و تخصيصات claimType=3 في JSON Merkle FSP الرسمي. nodeID الظاهر في أي مصدر يحسب كـ نشط. بالنسبة لمشغلي متعدد العقدة تستخدم النتيجة كسر عقدك التي تكون نشطة (1/3 نشطة = 4/12 base، إلخ). إذا كان يجب تصنيف nodeID كـ نشط لكن ليس بعد دورة sweep التالية، أرسل لنا البريد مع nodeID والحقبة المحددة التي تتوقع ظهورها فيها — سنتحقق من المصدرين.
تحركت قوة التصويت الخاصة بي 8% بالأمس — لماذا تسجل درجة الاستقرار ~2.8/10؟
استقرار قوة التصويت هو piecewise خطي في تغيير يومي مطلق يوماً بعد يوم (معاير خطي في v4.0 — لا حواف bucket): <1% → 10، منحدر 1→3% لأسفل إلى 7، 3→5% لأسفل إلى 4، 5→10% لأسفل إلى 2، ثم نحو 0 past 10%. حركة 8% تهبط على منحدر 5–10% بـ 4 − (8 − 5) × 0.4 = 2.8. القصد هو وضع علم للمزودين الذين يعانون من turnover مندوب ذي مغزى بحيث يمكن للمراهنين رؤيته على الجدول. الدرجة تتعافى بمجرد استقرار قوة التصويت الخاصة بك؛ يوم متقلب واحد لا يثبتك بشكل دائم منخفضاً.
مزودي مسمى بعنوان كياني (0x…). لماذا درجة الهوية 0؟
الهوية تمنح 8 نقاط لاسم علامة تجارية حقيقية (≥4 أحرف، لا يبدأ بـ 0x أو hex فقط) و0 لاسم عنوان نقي. لا يمكننا اختلاق اسم — اضبط profile.name على Flaremetrics وسنختاره على تشغيل cron التالي. إذا كان لديك الكيان ملف تعريف لكن حقل الاسم فارغ، فينطبق نفس الشيء.
لدي قاعدة مندوب صغيرة لكن ملتزمة — لماذا درجة عدد المندوبين الخاصة بي مقفلة؟
يستخدم عدد المفوضين عدادات حقيقية: يتم التحقق من كل محفظة تحتفظ بـ WFLR على السلسلة بحثاً عن تفويضاتها الحالية، ويتم حساب المفوضين المميزين لكل مزود (يتم التحديث كل ~6 ساعات، والتحقق المتبادل مقابل دفتر الأحداث المستقل). منذ الإصدار 4.0، يتم تطبيق مقياس لوغاريتمي من 5 → 500 مفوض يُمَثَّل على 0 → 12 نقطة، مع حد أقصى 500 (≤5 يحصل على 0). يعني المقياس اللوغاريتمي أن المزودين الأصغر الذين يتمتعون بنمو قوي في عدد المفوضين يرتقيان بأسرع ما يكون؛ بعد ~50 مفوض تقريباً، يؤثر المفوضون الإضافيون على المؤشر بشكل أقل — لكن المنحنى رتيب، لذا فإن الحصول على مفوض لا يمكن أن يقلل أبداً من النتيجة (يمكن أن تفعل الفئات السابقة للإصدار 4.0).
انخفضت درجتي بعد إضافة عقدة — ماذا حدث؟
إذا لم تكن العقدة الجديدة تعرض بعد أحداث MIRROR claimType=3، فإن كسر MIRROR الخاص بك ينخفض (مثلاً، من 1/1 = 100% إلى 1/2 = 50%)، مما يقلل درجة قاعدة مشاركة MIRROR. بمجرد بدء العقدة الجديدة في دفع MIRROR (عادةً في حقبة مكافأة واحدة أو اثنتين من التنشيط)، تتعافى الكسر وترتفع الدرجة.
هل يمكنني الطعن في درجتي أو طلب مراجعة يدوية؟
نعم. أرسل بريداً إلى [email protected] مع عنوان التفويض الخاص بك وقلق محدد. نرد على كل مشغل. الأشياء التي سننفذها: تصحيحات تصنيف MIRROR، أخطاء رياضيات خاصة بالبعد، إصلاحات الاسم/الشعار عبر Flaremetrics. الأشياء التي لن نفعلها: طلبات لرفع درجة يدوياً خارج الخوارزمية، طلبات لاستبعاد أو تخفيض ترتيب منافس.
ماذا سنفعل ولن نفعل
لإزالة الغموض حول كيفية تشغيلنا الدرجة، إليك التزامات صريحة. إذا انتهكنا أحدها على الإطلاق، وثقها وأرسل بريداً إلى [email protected] — سنصححها علناً.
✓
لن نقبل الدفع لدرجات أعلى أو تموضع مرعي أو معاملة تفضيلية من أي نوع. يتم حساب الدرجة بشكل حتمي من البيانات العامة.
✓
لن نرمز يدويًا bumps لكل مزود. لا توجد خط "X gets +5 لأننا نحبهم" في أي مكان في الكود. نفس الخوارزمية تنطبق على كل مزود بما في ذلك مزود FlareWatch الخاص بنا، الذي يتم تسجيله بهذه الدالة بالضبط.
✓
لن نستبعد المزودين من الجدول لأسباب غير عامة. يتم الحصول على القائمة من Flaremetrics + FSE؛ عرضنا يشمل كل مزود نشط تلك المصادر تسطح.
✓
سننشر تغييرات الخوارزمية. يتم توثيق كل تحديث إصدار في بطاقة الإصدارات على هذه الصفحة مع المنطق وما تحرك. التغييرات الرئيسية تحصل على إدخال سجل تغييرات إضافي مرئي من صفحة سجل التغييرات في التطبيق.
✓
سنرد على رسائل البريد الإلكتروني للمشغلين. كل مشغل يرسل بريداً إلكترونياً إلى [email protected] بخصوص قلق موضوعي حول درجته يحصل على رد حقيقي في غضون بضعة أيام عمل.
✓
سنصحح علناً أخطاءنا. إذا اكتشفنا خطأ في الخوارزمية أو خطأ في مصدر البيانات أو فجوة في المنهجية، فإننا نطلق إصلاحاً ونوثقه. نحن لا نعيد ترتيب بصمت.
✗
لن نشارك محتويات البريد الإلكتروني علناً دون إذن المرسل، أو نستخدم رسائل البريد الإلكتروني للمشغلين لأي شيء آخر غير محادثة الدرجات التي أنتجتها.
✗
لن نشارك خططنا المستقبلية لتغيير الخوارزمية مع مشغلين معينين مقدماً — كل إصدار يتم إطلاقه للجميع في نفس الوقت.
الدرجة النهائية (كيفية دمج الأبعاد)
تجتمع جميع الأبعاد المحسوبة البالغ عددها 12 بُعدًا في مؤشر مركب خام (أقصى 172). يتم تطبيع المؤشر المركب الخام إلى مقياس 0–100، ثم يتم تطبيق إعادة توزيع الأوزان الديناميكية لإنتاج النقاط النهائية المعروضة.
// Step 1 — Raw composite (sum of 12 dimensions, max 172)
raw = rewardRate + accuracy + consistency + v2 + fee + mirror
    + delegators + participation + stability + compliance
    + identity + selfBond

// An UNMEASURED reward rate is not a FAILED one. When a provider is
// demonstrably distributing but we hold no rate figure for it, the
// Reward Rate weight leaves the DENOMINATOR rather than scoring 0
// against it — we score what we measured, over what we could measure.
maxRaw = (rewardRate figure missing AND isActive) ? 172 - 25 : 172
normalized = round((raw / maxRaw) * 100)

// (The separate vote-power dilution penalty was REMOVED in v4.9. It
//  double-counted: an over-cap provider already earns a below-median
//  realized reward rate, so the median-anchored Reward Rate dimension
//  docks it for dilution once. Cap proximity is now a neutral DISPLAY
//  signal on every provider, not a second deduction in the score.)

// Step 2 — Dynamic weight redistribution
//   Across the active provider set, dimensions where everyone clusters
//   (stddev < 1.0) become non-discriminating. Their weight gets
//   redistributed evenly across dimensions where the spread is wider
//   (stddev >= 1.0). The redistribution recomputes the score:
//
//   for each dim d:
//     multiplier[d] = 1.0                 if stddev[d] < 1.0
//                   = (weight[d] + bonus) / weight[d]   otherwise
//   bonus = sum(weights of low-stddev dims) / count(high-stddev dims)
//
//   adjusted_raw = sum(breakdown[d] * multiplier[d])
//   adjusted_max = sum(weight[d]    * multiplier[d])
//   final = round((adjusted_raw / adjusted_max) * 100)

// Step 3 — Final score (capped at 100)
score = min(100, final)
قرب الحد الأقصى هو إشارة عرض فقط، وليس خصم نقاط. حتى الإصدار 4.9، كانت النقاط تطرح أيضًا 1-3 نقاط ثابتة من المزودين الكبار جدًا، لكن هذا أدى إلى عد مزدوج — المزود الذي يتجاوز الحد الأقصى يحقق بالفعل معدل عائد محقق أقل من المتوسط، والذي يسجله بُعد معدل العائد المرتكز على المتوسط مرة واحدة. لذلك تم إزالة العقوبة. الآن يعرض كل مزود مقدار حد FSP (2.5% من قوة التصويت الإجمالية المباشرة لعقد WNat) الذي يملأه، كإشارة محايدة للتفويض الهامشي: كلما اقتربت من 100%، كلما تم تخفيف التفويض الجديد أكثر.
علم الشذوذ في طبقة العرض: المزود الذي يقع معدل مكافأته الحالي أعلى بأكثر من ثلاثة انحرافات قوية (الانحراف المطلق الوسيطي، مقياس ×1.4826) فوق وسيط المجال — وأعلى بنسبة 50% على الأقل — يحمل شارة Outlier في جدول المزودين. الشارة لا تغيّر النقاط؛ حماية الشذوذ الخاصة بالنقاط نفسها تحد بشكل منفصل من المعدلات التي تتجاوز 3× الوسيط قبل حساب النقاط. ارتفاعات معدل الحقبة المحسّوبة سنويًا عادة ما تأتي من قوة تصويت صغيرة جدًا وتعود للطبيعي خلال حقبة واحدة.
مصادر البيانات (كل مدخل عام)
عقود Flare، مقروءة مباشرة على السلسلة: مجموعة المزودين المسجلة (VoterRegistry)، روابط الكيان → عنوان التفويض و nodeID بالإضافة إلى تسجيل عناوين الإرسال/التوقيع (EntityManager)، قوة التصويت المفوضة (WNat)، وسعر التفويض (WNatDelegationFee). هذا ما يجعل قائمة المزودين مستقلة عن أي فهرس واحد: في فترة المكافآت 420 احتفظت السلسلة بـ 98 مزوداً مسجلاً مقابل 80 في قائمة الطرف الثالث، والـ 18 في الفجوة كانت غائبة سابقاً عن هذا الموقع تماماً.
واجهة برمجة تطبيقات Flaremetrics العامة: معدل المكافأة، رسم الوفد، قوة التصويت، التغيير اليومي لقوة التصويت، قوة التصويت المقفلة (الرابط الذاتي)، اسم الملف الشخصي + الشعار + المنطقة، fspRewardRate.
مستكشف أنظمة Flare (FSE): دقة FTSO (أولية + ثانوية)، علامات حالة V2 (ftso_scaling وftso_fast_updates وfdc)، ربط عنوان الكيان، وجود عنوان التوقيع والإرسال، تسجيل الناخبين، ربط معرّف العقدة P-Chain، ومعدل المكافأة المفوضة لكل كيان (reward_rate_wnat). يتم الحصول على معدل المكافأة عن قصد من FSE و Flaremetrics معاً: ينشران نفس الرقم بوحدات مختلفة (FSE عشري، Flaremetrics نسبة مئوية — تم التحقق من تطابقهما عبر جميع مزودي الخدمة الـ 72 الذين يحملان كليهما، إلى خمس منازل عشرية)، و FSE يغطي 154 كياناً مقابل 80 كياناً من Flaremetrics. أي مصدر بمفرده يترك مزودي الخدمة بدون معدل بلا ذنب منهم.
بيانات مكافآت بروتوكول أنظمة Flare (FSP): توزيع المكافآت لكل حقبة لكل مزود، يُستخدم لبعد الامتثال (يحسب الحقب بدون مكافآت) وكمصدر موثوق لإجمالي مكافآت التفويض.
RewardManager V2 (أحداث claimType=3): توزيع MIRROR المطلوب على السلسلة لكل nodeID المدقق. تم تصفيته بصرامة على النوع 3 — لا خلط مع VRM أو تفويض FTSO أو مكافآت DIRECT. مُفهرسة FlareWatch الخاصة تعرض هذه لبعد مشاركة MIRROR.
JSON Merkle FSP (تخصيصات claimType=3): السجل المنشور الأساسي لمن يستحق MIRROR لكل حقبة (نفس البيانات التي تقرأ أداة التوقيع الخاصة بـ Flare). تمت إضافته كمصدر موثوق ثانٍ 2026-05-11 — يمسك المدققين الذين تم تخصيص MIRROR الخاص بهم ولكن لم يتم المطالبة به بعد على السلسلة.
لقطات FlareWatch التاريخية: معدلات المكافآت لكل حقبة تغذي سيرة ذاتية الاتساق؛ ملاحظات الحصة المدفوعة لكل مدقق تغذي مكافأة الأداء الزائد MIRROR (مع بوابة تراكم البيانات لمدة 30 يوماً).
ما هو غير موجود في الدرجة
• الترويج الذاتي أو التنسيب المدفوع. لا يمكن لأي مزود أن يدفع أو يرعى درجة أعلى.
• تحسينات محددة للمزود مشفرة يدوياً. لا توجد أسطر "X يحصل على +5 لأننا نحبهم" في أي مكان في الكود. تنطبق نفس الخوارزمية على كل مزود بما في ذلك مزود FlareWatch الخاص بنا، والذي يتم تسجيله بهذه الدالة الدقيقة.
• جودة البنية التحتية الذاتية. نحن لا نحاول تقييم اتفاقيات مستوى الخدمة للوقت التشغيلي أو التوزيع الجغرافي أو مواصفات الأجهزة بما يتجاوز ما تعرضه FSE و Flaremetrics كبيانات عامة.
• الأقفال أو الالتزامات مع FlareWatch. لا توجد نقاط تفضيلية للمراهنين الذين يستخدمون FlareWatch مقابل أداة أخرى.
• إشارات المستقبل غير المرتبطة بعد. حضور المجتمع (الشبكات الاجتماعية المتحققة، المشاركة في الحوكمة)، الخفض التاريخي، كمون الاستجابة، وخطوط الاتجاه لكل حقبة موجودة في النطاق للإصدارات المستقبلية ولكنها ليست في v3 اليوم. لا يتم ترجيح أي منها بسرية.
تعليقات المشغل
هل تلاحظ شيئاً غريباً في درجة المزود الخاص بك؟ أرسل بريداً إلكترونياً إلى [email protected] بعنوان التفويض الخاص بك والقلق. نحن نرد على كل مشغل. الطلبات الشائعة التي سنتصرف بناءً عليها:
  • تصحيحات تصنيف MIRROR (نسبة claimType=3 إلى nodeIDs الخاصة بك).
  • أخطاء الرياضيات الخاصة بالبعد مع المدخلات التي استخدمتها.
  • تصحيحات الاسم / الشعار / الملف الشخصي عبر Flaremetrics أو FSE.
  • نقد الخوارزمية العام.
المصادر والمراجع
كل مدخل للدرجة يأتي من مصادر عامة وقابلة للتحقق من نظام Flare البيئي. يمكن لأي شخص التحقق المتقاطع من مطالباتنا مقابل هذه المصادر الأساسية وإعادة إنتاج الرياضيات من البيانات الخام. إذا لاحظت عدم تطابق بين هذه الصفحة وما تقوله المصادر الأصلية، فأرسل بريداً إلكترونياً إلى [email protected] وسنصلحه.
وثائق البروتوكول الموثوقة. تغطي FTSO V2 و FSP و P-Chain validation و FAssets والباقي من مجموعة Flare.
بوابة حوكمة Flare (FIPs) ↗https://proposals.flare.network
اقتراحات تحسين Flare — مصدر الحقيقة لشروط الحد الأدنى لبروتوكول V2 وميكانيكا الرسوم والتغييرات في اقتصاديات المكافآت التي تغذي هذه الدرجة.
مستكشف أنظمة Flare (FSE) ↗https://flare-systems-explorer.flare.network
سجل FTSO مُشغّل من قبل Flare رسمياً لمزودي البيانات وعناوين الكيان وربط nodeID سلسلة P والأعلام الدنيا. المصدر الأساسي لأبعادنا في الدقة و V2 والمشاركة.
Flaremetrics ↗https://flaremetrics.io
مزود مقاييس نظام Flare البيئي المستقل. مصدر معدلات المكافآت والرسوم وقوة التصويت والتغيير اليومي لقوة التصويت وقوة التصويت المقفلة وأسماء الملفات الشخصية + الشعارات ومقياس fspRewardRate.
مستكشف كتل Flare ↗https://flare-explorer.flare.network
متصفح للقراءة فقط لجميع حالات على السلسلة. يسمح لأي شخص بالتحقق من أحداث RewardClaimed للمدير RewardManager V2 (claimType=3 لـ MIRROR) وانتقالات حقبة المكافأة والبقية.
مستودع Flare Foundation reward-scripts ↗https://github.com/flare-foundation/reward-scripts
JSON منشور لكل حقبة مكافأة من قبل مؤسسة Flare يعرض المكافآت المسلمة لكل مدقق. مدخل غير مباشر — يغذي حساب مكافأة الأداء الزائد MIRROR عبر مفهرس ملاحظات الحصة لكل FlareWatch.
واجهة برمجية عامة من Flaremetrics (موفرو FTSO) ↗https://api.flaremetrics.io/api/v1/ftso/providers?limit=200
نقطة النهاية الدقيقة التي يستهلكها cron الخاص بنا، وتُرجع ملفات تعريف الكيانات ومعدلات المكافآت والرسوم وقوة التصويت. يمكن لأي شخص الوصول إليها مباشرة.
واجهة برمجية عامة من Flaremetrics (تسجيلات العُقد) ↗https://api.flaremetrics.io/api/v1/node-registrations?limit=500
جدول تحويل Hex → cb58 NodeID. نقوم بتقسيم هذا إلى أجزاء لبناء بحث الكيان إلى NodeID الذي يدفع بُعد MIRROR Participation.
لا بيانات خاصة، لا نماذج مغلقة المصدر. تم تطبيق خوارزمية التسجيل في services/ftso/scoring.ts في قاعدة كود FlareWatch. يمكن للمشغلين أو الباحثين الذين يريدون فحص التطبيق مباشرة (بدلاً من قراءة النصوص والصيغ أعلاه) — أو الذين يريدون نسخه لاستخدامهم الخاص — إرسال بريد إلكتروني إلى [email protected] لطلب الوصول. سننشر الملف كحزمة مفتوحة المصدر مستقلة إذا كان هناك طلب حقيقي.
كيف تتحدث الدرجات
يعمل تسجيل موفر FTSO كـ pass داخل cron على /api/cron/refresh-validators، الذي يعيد حساب درجة كل موفر نشط كل 5 دقائق (نفس التشغيل الذي يعيد تسجيل محققي P-Chain). يتم جلب المدخلات (Flaremetrics وFSE وFSP rewards وأحداث V2 RewardManager) بشكل جديد في كل تشغيل.
يستخدم Consistency CV سجل الحقبة الأخير — يمكن للبُعد أن يتحرك مع تحول النافذة المتدحرجة. موفرو البدايات الجدد الذين لديهم أقل من 3 حقب تاريخية يسجلون 10 محايد حتى تتراكم البيانات الكافية.
يتم إعادة حساب إعادة توزيع الوزن الديناميكي في كل تشغيل بناءً على مجموعة الموفرين النشطين الحالية. مع تحرك الموفرين (مثل موجة من ترقيات V2 الجديدة)، يتحول البُعد الذي يصبح غير تمييزي؛ تتكيف إعادة التوزيع تلقائياً.
يتم وضع إصدار الخوارزمية في رأس هذه الصفحة. عندما نطلق إصدار جديد، يتغير سلسلة الإصدار هنا وتوثق بطاقة الإصدارات أدناه ما تحرك.
الإصدارات
v4.8 (2026-08-20) — الدقة الآن تكافئ فئة المكافآت الصعبة. كانت تستخدم فئة FTSO الثانوية فقط (الأوسع)، حيث يصل كل مزود خدمة جدي تقريباً إلى 95–99% — لذا كان هذا البعد درجة قريبة من 25/25 عبر أعلى الحقل، قريب من عدم قياس أي شيء. الفئة الأساسية (IQR الضيقة) هي الهندسة الصعبة حقاً ويفرق المزودين ~28–80%. شبكة Flare تكافئ هذه الفئات 40% أساسية / 60% ثانوية (FIP.11، مباشرة منذ 2024، مع زيادات فئة ثانوية إضافية موصولة)، لذا الدقة الآن تعكس ذلك: مزيج 40/60. الثانوية تحافظ على منحنيها السابق؛ الأساسية تستخدم منحنى مطلق (28% → 0، 78% → كامل 25)، ثابت لذا تبقى الدرجة قابلة للاستنتاج من مدخلات مزود الخدمة الخاصة به. فحص شامل قبل/بعد عبر جميع 100 مزود مسجل، مؤرشف قبل الشحن: إعادة الترتيب تتبع قوة الفئة الأساسية — المزودون الذين يقومون بهندسة الفئة الضيقة الصعبة يرتفعون، المزودون الذين يعتمدون على رقم ثانوي سهل ينخفضون. تنطبق نفس القاعدة على مزودنا الخاص، الذي لديه فئة أساسية ضعيفة اليوم: ينخفض من 84 إلى 77 وينخفض عدة أماكن. تم الشحن على أي حال — درجة تكافئ الهندسة الحقيقية، حتى منافس و حتى على نفقتنا، هي النوع الوحيد الذي يستحق النشر.
v4.7 (2026-07-31) — توقفت قائمة مزودي الخدمة عن الاعتماد على فهرس واحد، وتوقفت النقاط عن معاقبة فجواتنا البيانية. (1) تُبنى القائمة الآن من مجموعة الناخبين المسجلة على السلسلة ويتم ملؤها حيث يفتقد الفهرس الخارجي كيانات: 98 مزود خدمة مقابل 80 الذي تم عرضه سابقاً، لذا يظهر الآن 18 مزود خدمة حقيقي لم يكن قابلاً للبحث وغير قابل للتفويض من هنا. (2) كان "نشط" يعني "لديه معدل مكافأة من هذا الفهرس"، مما أصفر البعد الرسوم (15) و V2 (15) لكل مزود خدمة ممتلئ حتى عندما أظهرت بيانات FSP الخاصة بنا أنهم يدفعون كل حقبة؛ يقبل الآن دليل التوزيع. (3) معدل مكافأة مفقود لم يعد يسجل 0 مقابل المقسوم عليه الكامل — الوزن البالغ 25 نقطة يترك المقسوم عليه بدلاً من ذلك، لذا يتم تقييم مزود الخدمة على ما قسناه بدلاً من فرض رسوم عليه لما لم نتمكن من قياسه. (4) كان بعد الرسوم لا يزال يتم تقييمه على منحنى ما قبل FIP-16، حيث حصلت رسوم 0٪ على درجات كاملة. يجعل FIP-16 20٪ الحد الأدنى لرسوم الكيان القانوني وكل واحد من 98 مزود خدمة يفرض بالضبط ذلك، لذا منح البعد 4.00/15 لكامل المجال بدون تباين — 11 نقطة لا يمكن لأحد أن يكسبها، تستحق حوالي 4.3 نقاط من كل نقاط منشورة بما في ذلك الأعلى. يتم ربط الرسوم الآن بـ max(أقل رسوم مرصودة، حد البروتوكول)، بنفس الطريقة التي تم بها ربطه في صفحة المدقق منذ شوكة Granite: فرض الحد الأدنى القانوني يكسب الدرجات الكاملة، وفقط الرسوم فوقه تُعاقَب بالمسافة. هذا يرفع كل نقاط بمقدار مماثل ولا يغير الترتيب. لم يتأثر مزودو الخدمة بمعدل منشور بالتغييرات (1) إلى (3). لا يتم تقدير أو استنتاج معدل مكافأة: تلك الصفوف تقرأ "لا توجد بيانات". (5) معدل المكافأة لم يعد يعتمد على فهرس واحد. تم قراءته من Flaremetrics وحده، لذا فإن مزود الخدمة الذي توقف هذا الفهرس عن تغطيته فقد معدل APR الصافي والإجمالي وسجل 0/25 على معدل المكافأة — عقوبة بقيمة 25 نقطة لفجوة تغطية شخص آخر. ينشر مستكشف أنظمة Flare نفس الرقم ويغطي كيانات أكثر، لذا يملأ الآن أي فجوة؛ معدل Flaremetrics المباشر لا يتم الكتابة فوقه أبداً. في اليوم الذي تم شحنه فيه، استعاد معدل منشور لـ 15 مزود خدمة لم يكن لديهم واحد.
v4.6 (2026-07-01) — تم تحرير Consistency من التحيز للعقد الجديدة. كانت mean/stddev لمعدل المكافآت على سجل الحقبة الكامل البالغ 30، لذا كان أول حقبة ربح لعقدة جديدة ذات منحدر منتفخ (وزن تصويت ضئيل → معدل عالي لكل وحدة، الذي يعود إلى طبيعته) بمثابة خارج النطاق الذي أبقى CV مرتفعاً — يسجل 0 — لأشهر حتى تجاوز عمره. الآن يستخدم نافذة متأخرة (آخر 12 حقبة ربح) و dispersion قوية median/MAD، لذا فإن حقبة المنحدر هي خارج نطاق غير ضار بينما التقلب الجوهري المستمر لا يزال يسجل منخفضاً.
v4.5 (2026-06-30) — تم جعل Self-Bond محايد الحجم. كان المنحنى النسبي وحده يمكنه تسجيل self-bond مطلق كبير بنسبة منخفضة أقل من self-bond صغير بنسبة عالية. الآن Self-Bond يعتمد على ما يزيد عن نسبة المحاذاة أو مبلغ مطلق مشبع (محدود بـ 5M FLR)، لذا يحصل المشغل الملتزم الكبير والصغير المحاذى بالكامل على علامات كاملة — يكافئ الالتزام، وليس الثروة، وتبقى جودة المدقق في الأبعاد الأخرى.
v4.4 (2026-06-30) — إصلاحا الأخطاء الحقيقية. (1) كان Self-Bond بُعد ميت: كان يقرأ حقل Flaremetrics الذي أسقطته واجهة برمجية، لذا سجل كل موفر 0/7. إعادة المصدر من self-bond عقدة P-Chain الحقيقية للمشغل (مرجع متقاطع من مجموعة محقق حسب nodeID). (2) توقفت Compliance عن معاقبة الحقب قبل تفعيل موفر — كانت عقدة جديدة تربح بنظافة منذ إطلاقها في السابق يتم تحميلها لكل حقبة سابقة لها، مما يبقيها عند 0/10 لأسابيع. يتم حساب الحقب المفقودة فقط ضمن نافذة نشط كل موفر.
v4.3 (2026-06-03) — توضيح المنهجية، لا تغيير في رياضيات التسجيل. يتم تعريف بُعد Accuracy الآن بشكل صريح كـ معدل هبوط الفرقة الثانوية على السلسلة (جودة السعر — ما هي الكسور من الأسعار المُرسلة التي تهبط داخل الفرقة المقبولة)، مميزة عن بُعد Compliance، الذي يحسب حقب المكافآت المفقودة (مشاركة FSP). تمت إعادة كتابة هذه الصفحة وتلميحات جدول المحققين لجعل الفرق واضحاً، وتمت إضافة عمود Compliance بجانب Accuracy. يحتفظ كلا البُعدين بأوزانهما السابقة (25 و 10) والمدخلات (fseAccuracySecondary و epochsWithoutRewards).
v4.2 (2026-05-20) — تم إصلاح بُعد Rewards Distributed. كان موصول إلى حقل توزيع مكافآت Flaremetrics الذي أسقطته واجهة برمجية الموفر v3، لذا قرأ البُعد 0 لكل موفر ولم يساهم بشيء. يتم إعادة توصيل بمجموع مكافآت تفويض FSP على السلسلة — نفس بيانات المطالبة بالمكافآت التي تجمعها بُعد Compliance بالفعل — لذا يفرق البُعد مرة أخرى.
v4.1 (2026-05-20) — تم تشديد بُعد Compliance. يمكن أن يصل epochsWithoutRewards بشكل سلبي لأن cron مكافآت FSP جمع عدد وجود الحقبة الخاص به بعد النافذة المتدحرجة، مما سمح لـ Compliance بتجاوز حد 10 نقاط (لوحظ حتى ~58) وجعل المركب يتجاوز حده الأقصى — تشبع تقريباً 70٪ من الموفرين عند 100 ثابت. يتم الآن تشديد Compliance إلى وزنه، و cron FSP يعيد حساب ملخصات المكافآت بدون حالة لكل نافذة حتى لا يمكن للعد أن يتحرك.
v4.0 (2026-05-11) — تمرير تدقيق العدالة الكامل المكافئ لإصدار محقق الدرجات v4.0. تم إصلاح خطأين حقيقيين: (1) كان لدى Delegator Count حافز معكوس عند 500 — قبل الإصلاح، أرجع bucket 500-مندوب 14 نقطة لكن >500 حد أرجع WEIGHT_DELEGATORS الأساسي (12)، لذا أكسب مندوب عبر هذا الحد خسر 2 نقطة. الآن مقياس log من 5 → 500، رتيب صعودي. (2) تم انهيار tiers V2 Participation — التسجيل الجزئي V1 والكامل V2 (Scaling + FastUpdates + FDC) كلاهما أرجع 15، لذا الترقية من V1 جزئي إلى V2 كامل قدمت تحسن درجة صفري. الآن stacking كل بروتوكول (نشط +3، V1 +4، كل بروتوكول V2 ~+2.67). تم حذف cliffs الحدود في Accuracy (كان لديه cliff 7-pt عند 97٪)، Stability، و Self-Bond Ratio — كلها خطية مع الحفاظ على القيم عند حدود الدلو. منحنى Reward Rate معاد توازن بحيث median = نصف نقاط البُعد (كان 40٪). تم التوفيق بين docstrings البُعد القديم مع قيم الوزن الفعلية. التأثير الصافي: كل بُعد رتيب صعودي على محور الإدخال، و لا يمكن لأي موفر خفض درجة FlareWatch الخاصة بهم بتحسين مقياس تشغيلي فعلي.
v3 (2026-05-09 → 2026-05-11) — تسجيل 13-بُعد مع إعادة توزيع وزن ديناميكي وعقوبة تخفيف قوة التصويت. تم تقديم MIRROR Participation كبُعد من الدرجة الأولى (12 أساسي + حتى +3 مكافآت الأداء الزائد مع shrinkage بايزيان وبوابة تراكم البيانات 30 يوماً). تمت إضافة Identity و Self-Bond كأبعاد منفصلة. تم نقل Reward Rate إلى median-anchored. يستخدم Accuracy مقياس FSE الثانوي للفرقة عالية الدقة. يستخدم Consistency CV عبر الحقب الأخيرة.
v2 والإصدارات السابقة — لم يتم توثيق الإصدارات السابقة v3 هنا؛ استخدمت مجموعة فرعية أبسط من الأبعاد وسبقت إعادة توزيع الوزن الديناميكي. تم إيقاف الإصدارات لصالح النموذج الحالي.
FlareWatch FTSO delegation addresses. Flare (chainId 14): 0x973B899Fe1422efDdeBE1d54E9A6487a70966aC5. Songbird (chainId 19): 0xaf4eF2A0Ecf8d914Db6b721D3eb79C46CA612796.