كنت أبحث أعمق في تصميم «نقـر» ديُسك (Dusk) لطيـر الفينيق (Phoenix)، وكلما نظرت إليه أكثر، زاد اقتناعي بأن خيار العمق 34 منطقي جدًا.

يبدو أن 17.2B من الأوراق يترك أصواتًا/انطباعًا شبه سخيفًا في البداية. لكن الرقم نفسه هو ما لم يلفت انتباهي.

بل الطريقة التي يصل بها Phoenix إلى ذلك.

يمنح العمق 32 سعة تبلغ تقريبًا 4.3B ورقة. وعند الانتقال إلى 34 تقفز السعة بنحو 4×. ثم إن إضافة مستوى واحد آخر تجعلها تتضاعف مرة أخرى.

ومع ذلك، فإن مسار الإثبات لا ينمو إلا خطوة واحدة في كل مرة.

وهذا هو الجزء الذي أراه ذكيًا.

بالطبع، لا تعني السعة النظرية الضخمة أن المشكلة قد حُلّت. فمع إنشاء المزيد من الملاحظات، ستظل مضطرًا إلى التعامل مع الإثبات، وبيانات الشهود، والتخزين، والوصول إلى الحالة.

وهنا أعتقد أن الاختبار الحقيقي يبدأ.

بالنسبة لي، ليس Phoenix مثيرًا للاهتمام فقط لأنه يستطيع نظريًا حمل مليارات من الملاحظات. بل لأنه يحاول الموازنة بين الخصوصية والتحقق ونمو الحالة على المدى الطويل ضمن التصميم نفسه.

الخصوصية على نطاق صغير شيء واحد.

لكن الحفاظ على ذلك عمليًا مع نمو الاستخدام هو تحدٍ أصعب بكثير.

لذا لا أنظر إلى رقم 17B بوصفه خط النهاية. أراه كمساحة احتياط.

والسؤال الذي سأراقبه بسيط:

عندما يبدأ النشاط الحقيقي في ملء تلك الشجرة، هل يستطيع Phoenix الحفاظ على التوازن الأنيق نفسه بين سعة ضخمة وإثباتات يمكن إدارتها؟

ستكون تلك الإجابة أكثر أهمية بكثير من الرقم الرئيسي.

#Dusk @Dusk $DUSK