تضيف Sui عمليات تحقق اختيارية من الأسماء المستعارة للعناوين إلى VerifySignature
تضيف Sui خيارًا للتحقق من أسماء العناوين المستعارة ضمن طلب gRPC VerifySignature. عند تفعيل هذا الخيار، يجب أن يتضمن الطلب عنوانًا، ويُتحقق من التوقيع بمقارنته بالأسماء المستعارة الحالية لذلك العنوان. وإذا لم تُضبط أي أسماء مستعارة، يُعامل العنوان نفسه على أنه الاسم المستعار الوحيد.
يتضمن الرد الحقل address_aliases_checked للإشارة إلى ما إذا كان الخادم قد أجرى التحقق. يجب على العملاء اعتبار غياب هذا الحقل دليلًا على أن التحقق لم يُجرَ، لأن الخوادم الأقدم تتجاهل خيار الطلب الجديد. عند تعطيل الخيار، يبقى السلوك الحالي كما هو. ويضيف التحديث أيضًا الدعم عبر اعتماد مُحدّث لـ Sui Rust SDK، ويتضمن اختبارات محاكاة لسيناريوهات الأسماء المستعارة والتوقيعات.
Neutral
هذا تغيير تقني في واجهة برمجة التطبيقات الخاصة بالتحقق من التوقيعات في Sui، وليس إعلاناً موجهاً للسوق بشأن اقتصاديات الرمز أو أرقام التبني أو التمويل أو المستجدات التنظيمية. ويضيف خياراً يمكن تفعيله لتمكين التطبيقات من التحقق من التوقيعات بالاستناد إلى الأسماء المستعارة الحالية لعنوان ما، وهو ما قد يحسّن التعامل مع الهوية ويقلل أخطاء التكامل لدى الخدمات التي تستخدم الأسماء المستعارة. والتغيير متوافق مع الإصدارات السابقة عند عدم تفعيل الخيار، لكن على العملاء مراعاة أن الخوادم القديمة لا تعيد حقل الحالة الجديد.
من المرجح أن يكون الأثر المباشر على تداول SUI واستقرار السوق عموماً محدوداً على المدى القصير. وقد يراقب المتداولون مدى اعتماد المحافظ والتطبيقات ومزودي البنية التحتية لهذا التغيير، لكن المقال لا يقدم دليلاً على زيادة فورية في الاستخدام أو على نشاط ملموس في الشبكة. وكما هو الحال مع تحديثات البروتوكولات وأدوات المطورين الأخرى، ستعتمد استجابة السوق عموماً على ما إذا كان التغيير سيؤدي إلى تحسن ملحوظ في الموثوقية أو الأمان أو استخدام المنظومة. وعلى المدى الأطول، قد يسهم تحسين وضوح التحقق من التوقيعات في دعم تطوير التطبيقات على Sui، لكن هذا الاحتمال وحده لا يكفي لتحديد إشارة صعودية أو هبوطية. لذلك، فإن الأثر المتوقع على السوق محايد.