مُضمَّن. مُنفَّذ. مُقبول. مُؤكَّد. أربع كلمات في سجلّ تكامل، ولا واحدة منها تعني أن المال قد تحرّك.
تقول @Dusk ذلك بنفسها في وثائقها، بسطر واحد واضح: لا تستخدم «مُضمَّن» أو «مُزال» أو «مُقبول» أو «مُؤكَّد» كإشارة نهائية لتسديد/دفع. إن 202 من عقدة واحدة يعني فقط أن بياناتك (الـ bytes) تم قبولها للتوجيه.
تمرّ دورة حياة L1 بسبع خطوات: الإنشاء والتوقيع، الإرسال، القبول، الانتشار، الاختيار، التنفيذ، ثم الإنهاء. التنفيذ ليس نهاية المطاف. يمكن أن يُعاد التراجع عن كتلة “مقبولة” أيضًا، ولا يُغلق السؤال إلا عند وصول حدث statechange يحمل حالة “finalized” (مُنهَّاة). تُكتب حينها سجلات التاريخ لحسابات Moonlight، وليس قبل ذلك.
الأساس تحت ذلك هو Consensus (الاتفاق) الموجز: Succinct Attestation—اقتراح، تحقق، تصديق، ولجان تُختار عشوائيًا من المُورِّدين كل دورة. نهائية حتمية بالتصميم، لأن السوق لا “يتصالح” ضد «على الأرجح».
وهذه هي النقطة التي أعود إليها باستمرار. قضيت سنوات أختبر تدفّق الطلبات داخل تطبيق أوراق مالية، وأكثر ما أسمعه عن T+2 أنه مشكلة قاعدة بيانات. ليس كذلك. توجد يومان لأن الصفقة تمر عبر التنفيذ، والمطابقة، والتأكيد، والمقاصة، واحتساب صافي الالتزام، والتسوية، والحفظ/الوصاية، ثم التسوية والتحقق (reconciliation)، ويمتلك شخص ما كل نقطة تسليم. تضغط سلسلة/Chain واحدة من تلك الخطوات. أما السبع الباقية فلا تتحرك لأن كتلة “finalized” تُغلق الأمور خلال ثوانٍ.
وهذا أيضًا هو الحدّ الصريح. النهائية الحتمية تُغلق مسار دفتر الأستاذ. لا تقرر من سُمح له بالاحتفاظ بالأصل، ولا ما الذي تفعله عملية قرار/إجراء شركي (corporate action) بالدفتر، ولا من يفكّ قيْدَ صفقة خاطئة عند الساعة 4 عصرًا يوم الجمعة.
رأيي: تسمية الكلمات الأربع التي لا تُحتسب أفضل من أي رقم إنتاجية في صفحة هبوط. كل جهة تقوم بتوصيل السلسلة تختار حدثًا واحدًا، تسميه “settled”، ثم تدافع عنه أمام مُدقِّق. اختارت Dusk خوض تلك المعركة في الوثائق بدل أن تتركها لجهات التكامل. $DUSK يدفع رسوم الغاز ويؤمّن الشبكة عبر التكديس (staking).
لذا: في مكدسِك، أي حدث أنت مستعدّ أن تُسميه مُستوفى/مُسوّى (settled)، ومن مسموح له أن يتجاوزه؟
#dusk
تقول @Dusk ذلك بنفسها في وثائقها، بسطر واحد واضح: لا تستخدم «مُضمَّن» أو «مُزال» أو «مُقبول» أو «مُؤكَّد» كإشارة نهائية لتسديد/دفع. إن 202 من عقدة واحدة يعني فقط أن بياناتك (الـ bytes) تم قبولها للتوجيه.
تمرّ دورة حياة L1 بسبع خطوات: الإنشاء والتوقيع، الإرسال، القبول، الانتشار، الاختيار، التنفيذ، ثم الإنهاء. التنفيذ ليس نهاية المطاف. يمكن أن يُعاد التراجع عن كتلة “مقبولة” أيضًا، ولا يُغلق السؤال إلا عند وصول حدث statechange يحمل حالة “finalized” (مُنهَّاة). تُكتب حينها سجلات التاريخ لحسابات Moonlight، وليس قبل ذلك.
الأساس تحت ذلك هو Consensus (الاتفاق) الموجز: Succinct Attestation—اقتراح، تحقق، تصديق، ولجان تُختار عشوائيًا من المُورِّدين كل دورة. نهائية حتمية بالتصميم، لأن السوق لا “يتصالح” ضد «على الأرجح».
وهذه هي النقطة التي أعود إليها باستمرار. قضيت سنوات أختبر تدفّق الطلبات داخل تطبيق أوراق مالية، وأكثر ما أسمعه عن T+2 أنه مشكلة قاعدة بيانات. ليس كذلك. توجد يومان لأن الصفقة تمر عبر التنفيذ، والمطابقة، والتأكيد، والمقاصة، واحتساب صافي الالتزام، والتسوية، والحفظ/الوصاية، ثم التسوية والتحقق (reconciliation)، ويمتلك شخص ما كل نقطة تسليم. تضغط سلسلة/Chain واحدة من تلك الخطوات. أما السبع الباقية فلا تتحرك لأن كتلة “finalized” تُغلق الأمور خلال ثوانٍ.
وهذا أيضًا هو الحدّ الصريح. النهائية الحتمية تُغلق مسار دفتر الأستاذ. لا تقرر من سُمح له بالاحتفاظ بالأصل، ولا ما الذي تفعله عملية قرار/إجراء شركي (corporate action) بالدفتر، ولا من يفكّ قيْدَ صفقة خاطئة عند الساعة 4 عصرًا يوم الجمعة.
رأيي: تسمية الكلمات الأربع التي لا تُحتسب أفضل من أي رقم إنتاجية في صفحة هبوط. كل جهة تقوم بتوصيل السلسلة تختار حدثًا واحدًا، تسميه “settled”، ثم تدافع عنه أمام مُدقِّق. اختارت Dusk خوض تلك المعركة في الوثائق بدل أن تتركها لجهات التكامل. $DUSK يدفع رسوم الغاز ويؤمّن الشبكة عبر التكديس (staking).
لذا: في مكدسِك، أي حدث أنت مستعدّ أن تُسميه مُستوفى/مُسوّى (settled)، ومن مسموح له أن يتجاوزه؟
#dusk