في الواقع، يوجد كتابان مترابطان لكن مختلفان في مكدس @Dusk : أحدهما هو دفتر تنفيذ DuskEVM، والذي يُقدَّم للعالم على أنه Ethereum JSON-RPC؛ والآخر هو دفتر التسوية الخاص بـ Dusk L1، والذي يُقدَّم للعالم على أنه GraphQL / RUES. يجب أن تُقرأ DUSK في الدفترين كقيمة واحدة، لكن ساعاتهما ووحداتهما وعدد منازل الفاصلة ليست متطابقة.
DuskEVM هو طبقة تنفيذ EVM على نمط OP Stack؛ فهي تُرجع كتلًا وسجلات وإيصالات بالشكل القياسي لـ EVM. ثم تتم تسويتها النهائية — وكذلك قابلية توفر البيانات — عبر batcher و التزامات الحالة و التثبيت عبر الأقفال/المراسي (bridging) وصولًا إلى DuskDS. أي أن هذا ليس “محوّلًا يقوم بترجمة GraphQL إلى JSON-RPC لحظيًا”، بل آلية للحفاظ على الاتساق النهائي بين الطبقتين من خلال الجسر والالتزامات على الحالة. النقطة الحقيقية التي يجب الانتباه لها هي سيناريوهات عبر الطبقات: inclusion على DuskEVM يحدث بسرعة، لكن التسوية الكاملة والتأكيد عبر الجسر يتطلبان خطوات إضافية؛ وخلال هذه الفترة قد تَرَى كل جهة حالة مختلفة مؤقتًا.
إن دور $DUSK يجعل هذا الخطر أكثر وضوحًا. من جهة L1 الأصلية، يتم تمثيل القيمة باستخدام LUX، حيث يساوي 1 DUSK = 10^9 LUX. أما DuskEVM، وللتوافق مع سلسلة أدوات Ethereum، فقد كشف DUSK مع 18 منزلة عشرية. وعند إجراء الربط/الجسر، إذا تم التعامل مع التحويل أو الدقة بشكل غير صحيح، فقد لا تتطابق قيمة المعاملة نفسها بين الدفترين لفترة قصيرة. بالنسبة للحوّالات العادية قد يكون الأمر مجرد خطأ في العرض، لكن بالنسبة لتسويات خاضعة للرقابة فقد يتحول إلى نافذة لإجراء خاطئ مثل: “عرض وصول على أحد الجانبين، بينما لم يتم تأكيده نهائيًا بعد” على الجانب الآخر.
استنتاجي بعد قراءتي هو: تقييم #dusk ، لا يكفي النظر إليها على أنها “متوافقة مع EVM”، بل يجب النظر إلى ضمان الاتساق بين دفتر تسوية L1 ودفتر تنفيذ EVM. المعلومات الحالية لا توضح بشكل كافٍ أولوية مصادر البيانات الموثوقة، ولا آليات كشف التعارضات وإصلاحها، وDUSK تحديدًا هي الرقم الذي لا يجوز تلاوته/قراءته بالخطأ في هذين الدفترين. DYOR.
DuskEVM هو طبقة تنفيذ EVM على نمط OP Stack؛ فهي تُرجع كتلًا وسجلات وإيصالات بالشكل القياسي لـ EVM. ثم تتم تسويتها النهائية — وكذلك قابلية توفر البيانات — عبر batcher و التزامات الحالة و التثبيت عبر الأقفال/المراسي (bridging) وصولًا إلى DuskDS. أي أن هذا ليس “محوّلًا يقوم بترجمة GraphQL إلى JSON-RPC لحظيًا”، بل آلية للحفاظ على الاتساق النهائي بين الطبقتين من خلال الجسر والالتزامات على الحالة. النقطة الحقيقية التي يجب الانتباه لها هي سيناريوهات عبر الطبقات: inclusion على DuskEVM يحدث بسرعة، لكن التسوية الكاملة والتأكيد عبر الجسر يتطلبان خطوات إضافية؛ وخلال هذه الفترة قد تَرَى كل جهة حالة مختلفة مؤقتًا.
إن دور $DUSK يجعل هذا الخطر أكثر وضوحًا. من جهة L1 الأصلية، يتم تمثيل القيمة باستخدام LUX، حيث يساوي 1 DUSK = 10^9 LUX. أما DuskEVM، وللتوافق مع سلسلة أدوات Ethereum، فقد كشف DUSK مع 18 منزلة عشرية. وعند إجراء الربط/الجسر، إذا تم التعامل مع التحويل أو الدقة بشكل غير صحيح، فقد لا تتطابق قيمة المعاملة نفسها بين الدفترين لفترة قصيرة. بالنسبة للحوّالات العادية قد يكون الأمر مجرد خطأ في العرض، لكن بالنسبة لتسويات خاضعة للرقابة فقد يتحول إلى نافذة لإجراء خاطئ مثل: “عرض وصول على أحد الجانبين، بينما لم يتم تأكيده نهائيًا بعد” على الجانب الآخر.
استنتاجي بعد قراءتي هو: تقييم #dusk ، لا يكفي النظر إليها على أنها “متوافقة مع EVM”، بل يجب النظر إلى ضمان الاتساق بين دفتر تسوية L1 ودفتر تنفيذ EVM. المعلومات الحالية لا توضح بشكل كافٍ أولوية مصادر البيانات الموثوقة، ولا آليات كشف التعارضات وإصلاحها، وDUSK تحديدًا هي الرقم الذي لا يجوز تلاوته/قراءته بالخطأ في هذين الدفترين. DYOR.
