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

هكذا بدأت أفكر في DuskEVM. يمكن للمطوّر أن يبقى في منطقة مألوفة باستخدام Solidity والمحافظ وأدوات EVM العادية، بينما يبقى <c-1/>@Dusk </c-1/>‎ يعمل في الخلفية ضمن DuskDS للتعامل مع التسوية وتوافر البيانات. عندما كل شيء يعمل، تكون هذه التجريدات بالضبط ما تريده. لا أحد يريد بنية تحتية إضافية في رأسه.

لكن التجريد يخلق أيضًا تبعية. نشاط DuskEVM مُجمّع ومُثبت تحت طبقة التنفيذ. $DUSK also ينتقل أيضًا بين L1 وDuskEVM عبر جسر. لذلك عندما تتصرف التسوية بشكل غير متوقع، تصبح عملية الربط عبر الجسر أكثر تعقيدًا، أو لا يبدو الـ state بالطريقة التي يتوقعها المطوّر، فإن الطبقة الأساسية فجأة تهم.

هذه هي النقطة التي أعتقد أن @dusk سيتعين عليه إثباتها في النهاية. هل يستطيع المطورون استكشاف مشاكل تلك الحدود دون أن يصبحوا متخصصين في DuskDS؟ إذا أصبح فهم الطبقة المخفية ضروريًا كثيرًا، يبدأ بعض من البساطة التي توفرها توافقية EVM بالاختفاء.

ربما لا يتعلق التصميم المعماري الجيد بجعل الطبقة الأساسية غير ذات صلة.

بل بجعل المطورين يتجاهلونها معظم الأيام—ويفهمونها بسرعة في اليوم الذي لا يمكنهم فيه ذلك.$DUSK

#dusk