كنت أعتقد أن البنية التحتية الأفضل تعني منح المطورين مزيدًا من التحكم....

لكن في الآونة الأخيرة بدأت أتساءل إن كان العكس أحيانًا هو الصحيح.

فكل إذن قابل للتكوين، وفحص أمني مخصص، وقاعدة تفويض خاصة بالتطبيق، يخلق قرارًا إضافيًا يجب على فريق التطوير أن ينجح في اتخاذه.

ومعظم هذه القرارات تكون غير مرئية للمستخدمين.

لكنها غالبًا ما تكون النقطة التي ينجح فيها الأمان أو يفشل.

وأثناء قراءتي عن Newton Mainnet Beta، برزت لي فكرة ظلت تتكرر.

البروتوكول لا يقدّم فقط تفويضًا قابلًا للبرمجة. بل يحاول أيضًا توحيد كيفية التعبير عن التفويض والتحقق منه عبر تطبيقات مختلفة بدلًا من تشجيع كل فريق على ابتكار نموذج أمنه الخاص.

قد يكون ذلك أهم من ميزة أخرى.

عندما يبني كل بروتوكول التفويض بشكل مختلف، يصبح على كل تكامل أن يفهم افتراضات مختلفة، وأنماط فشل مختلفة، ومخاطر تشغيلية مختلفة.

ولا يجعل إطار تفويض مشترك بالضرورة البرمجيات أكثر أمانًا.
ما يمكنه فعله هو تقليل عدد قرارات الأمان الفريدة التي يحتاج المطورون إلى اتخاذها من الصفر.

وهذا شكل مثير للاهتمام من أشكال القابلية للتوسع.
ليس بتوسيع المعاملات.

بل بتوسيع ممارسات الأمان الجيدة.
بالطبع، للتوحيد ثمن.

إذا اعتمد عدد كبير جدًا من التطبيقات على أنماط تفويض متشابهة، فقد تصبح نقاط الضعف أكثر منهجية. أحيانًا توفر التنوع نوعًا من المرونة.

لهذا أعتقد أن Newton Mainnet Beta لا ينبغي الحكم عليه فقط بعدد التطبيقات التي تتكامل معه.

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

والسؤال الذي بقيت معه هو هذا:
عندما يصبح Web3 أكثر تعقيدًا، هل ستكون البنية التحتية الرابحة هي التي تمنح أكبر عدد من الخيارات—أم تلك التي تقلّل عدد القرارات الحرجة التي يجب على منشئي التطبيقات اتخاذها بشكل صحيح؟

$NEWT #Newt @NewtonProtocol

$TLM $MAGMA #Binance #TradingCommunity #TrendingTopic