في سنواتي الأولى، آمنتُ أنا أيضًا بإمكانية حماية الخصوصية عبر حلول تُضاف إلى الطبقات العليا. لكنني لاحقًا، وأنا أراقب سلاسل الكتل العامة وهي تكدّس الطبقات وتزداد بنيتها ترهّلًا، وما يتبع ذلك من ثغرات ومشكلات توافق، أدركت تدريجيًا أن الترقيع بعد وقوع المشكلة لا يعالج أصلها.
قرأت مؤخرًا الورقة البيضاء لـDusk بتمعّن، ووجدت فيها @Dusk نقاشًا مخصصًا للفارق بين التكامل من البداية والتركيب الإضافي، يشرح بوضوح لماذا أدرجوا الخصوصية مباشرةً في طبقة البروتوكول. فمن قواعد الإجماع وتنسيق المعاملات إلى بيئة تنفيذ العقود، وضع Dusk منذ البداية شرط «عدم الظهور افتراضيًا» ضمن التصميم. وصُممت الخصوصية والامتثال والأداء معًا باعتبارها منظومة واحدة، بدلًا من محاولة حجب المشكلات مؤقتًا بعد ظهورها. تشبه سلاسل الكتل العامة التقليدية هيكلًا يُبنى أولًا ثم تُضاف إليه الفواصل؛ يبدو مكتملًا، لكن الوصلات تظهر في كل مكان. أما Dusk فقد دمج الخصوصية في صميم بنيته بأكملها، لتعمل وفق هذا المعيار منذ لحظة إطلاقها. #dusk
يمنح التكامل الأصلي اتساقًا أنقى وأساسًا أكثر متانة، فتصبح الخصوصية جزءًا حاملًا للبنية لا إضافةً خارجية. لكن إذا كان اللحام محكمًا إلى هذا الحد، فهل سيصبح تحديث البنية أو إدخال أساليب تحقق جديدة لاحقًا أصعب من تفكيك المكونات الإضافية وتركيبها؟ كما أن البناء من الصفر يتطلب عتبة دخول مرتفعة، ويظل إطلاق المنظومة البيئية من نقطة الصفر وتقديم تجربة ملائمة للناس العاديين اختبارين واقعيين؛ فكل ذلك لن يجدي إذا كانت الإجراءات معقدة أكثر من اللازم. $DUSK $BTC
أؤيد توجه Dusk، لكنني سأواصل متابعة مرونة التطوير وتقدم المنظومة البيئية. ابحثوا بأنفسكم؛ هذا ليس نصيحة استثمارية، فالأولوية هي الحفاظ على رأس المال. ما رأيكم: هل جعل الخصوصية جزءًا أصيلًا من النظام أكثر أمانًا، أم أنه يجعله جامدًا كأنه ملحوم؟