هناك تمييز واضح تصنعه وثائق Dusk نفسها بشكل صريح ويتجاوزه معظم منشئي الـrollup. لا تمثل الإضافة (inclusion) والتسوية (settlement) حدثًا واحدًا. وتُظهر دورة حياة DuskEVM هذه الفجوة بدلاً من إخفائها خلف شاشة تأكيد لطيفة.
إليك التسلسل الحقيقي: يتم أولاً إرسال معاملة إلى مُجمِّع (sequencer) DuskEVM. تقوم طبقة التنفيذ بتضمينها في كتلة L2 تقريبًا فورًا؛ وهذا هو الجزء الذي يبدو “فوريًا” — فالجزء الذي تعرضه المحافظ كـ "confirmed" لحظة حدوثه. لكن تلك الكتلة ليست مُسَوَّاة بعد، وليس بالطريقة التي تهم في حركة القيمة عبر الطبقات. الطبقة الفعلية للتسوية وإتاحة البيانات الكامنة تحت ذلك.
فقط بعد ذلك ينتج DuskDS التزامات الحالة (state commitments) وإثباتات الأعطال (fault proofs) التي تربط حالة DuskEVM الناتجة بشيء مُرسَخ على الطبقة الأساسية.
لذا توجد نافذة حقيقية، أحيانًا تكون صغيرة وأحيانًا لا، تُصبح فيها المعاملة مُدرجة لكن غير مُسَوَّاة بعد بالمعنى الذي تتطلبه “النهائية” فعلاً. الوثائق تتحدث عن هذا بوضوح؛ إذ تحذّر صراحةً أن التطبيقات التي تنقل قيمة بين DuskEVM وDusk L1 يجب أن تتحقق من حالة البروتوكول أو حالة المحفظة، بدل افتراض النهائية لمجرد مرور بضع ثوانٍ وعدم ظهور أي شيء خاطئ.
ما أحترمه هنا فعلاً هو الصدق في رسم تلك الحدود بدل تجميل الصورة. كثير من الـrollups يطمسون بين الإضافة والنهائية في تجربة المستخدم، فيجعلون المستخدمين يظنون أنهما الشيء نفسه لأن معظم الوقت لا يحدث شيء خاطئ. تسمّي Dusk الفجوة مباشرةً بدل أن تأمل بهدوء ألا يلاحظها أحد حتى يحين وقت أن تصبح مهمة.
لكن تسمية الفجوة لا تُغلقها تلقائيًا. إذا كنت تبني شيئًا يربط قيمة أو يُطلق منطقًا بناءً على معاملة على DuskEVM، فأنت الآن تتحمل مسؤولية التحقق من حالة التسوية الفعلية بنفسك بدل الاعتماد على “التأكيد السريع” الذي رأيته أولاً.
فهل ستُبنى هذه الخطوة الإضافية بشكل صحيح بواسطة كل مُدمِج يتعامل مع هذا؟ أم أن الإفصاح الصريح عن الحقيقة سينقل المخاطر بهدوء إلى من يفترض أن السرعة تعني أن الأمور قد انتهت.
@Dusk $DUSK #dusk
إليك التسلسل الحقيقي: يتم أولاً إرسال معاملة إلى مُجمِّع (sequencer) DuskEVM. تقوم طبقة التنفيذ بتضمينها في كتلة L2 تقريبًا فورًا؛ وهذا هو الجزء الذي يبدو “فوريًا” — فالجزء الذي تعرضه المحافظ كـ "confirmed" لحظة حدوثه. لكن تلك الكتلة ليست مُسَوَّاة بعد، وليس بالطريقة التي تهم في حركة القيمة عبر الطبقات. الطبقة الفعلية للتسوية وإتاحة البيانات الكامنة تحت ذلك.
فقط بعد ذلك ينتج DuskDS التزامات الحالة (state commitments) وإثباتات الأعطال (fault proofs) التي تربط حالة DuskEVM الناتجة بشيء مُرسَخ على الطبقة الأساسية.
لذا توجد نافذة حقيقية، أحيانًا تكون صغيرة وأحيانًا لا، تُصبح فيها المعاملة مُدرجة لكن غير مُسَوَّاة بعد بالمعنى الذي تتطلبه “النهائية” فعلاً. الوثائق تتحدث عن هذا بوضوح؛ إذ تحذّر صراحةً أن التطبيقات التي تنقل قيمة بين DuskEVM وDusk L1 يجب أن تتحقق من حالة البروتوكول أو حالة المحفظة، بدل افتراض النهائية لمجرد مرور بضع ثوانٍ وعدم ظهور أي شيء خاطئ.
ما أحترمه هنا فعلاً هو الصدق في رسم تلك الحدود بدل تجميل الصورة. كثير من الـrollups يطمسون بين الإضافة والنهائية في تجربة المستخدم، فيجعلون المستخدمين يظنون أنهما الشيء نفسه لأن معظم الوقت لا يحدث شيء خاطئ. تسمّي Dusk الفجوة مباشرةً بدل أن تأمل بهدوء ألا يلاحظها أحد حتى يحين وقت أن تصبح مهمة.
لكن تسمية الفجوة لا تُغلقها تلقائيًا. إذا كنت تبني شيئًا يربط قيمة أو يُطلق منطقًا بناءً على معاملة على DuskEVM، فأنت الآن تتحمل مسؤولية التحقق من حالة التسوية الفعلية بنفسك بدل الاعتماد على “التأكيد السريع” الذي رأيته أولاً.
فهل ستُبنى هذه الخطوة الإضافية بشكل صحيح بواسطة كل مُدمِج يتعامل مع هذا؟ أم أن الإفصاح الصريح عن الحقيقة سينقل المخاطر بهدوء إلى من يفترض أن السرعة تعني أن الأمور قد انتهت.
@Dusk $DUSK #dusk