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

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

فكرة تصميم Walrus عكس ذلك تمامًا — فهي لا تبدأ من "كيف أكتب بسرعة أكبر"، بل من "كيف أضمن بقاء البيانات متاحة على المدى الطويل" وتُرجع ذلك إلى بنية تقنية. قد يبدو الفرق دقيقًا، لكنه في الواقع يحدد دورة حياة النظام بأكملها.

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

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

من ناحية المعايير التقنية، يدعم Walrus تخزين كائنات البيانات بحجم ميجابايت، ويضمن التوفر من خلال بنية متعددة العقد. في الأداء على شبكة الاختبار، استقر زمن الاستجابة عند مستوى الثواني، مما يدعم بشكل كامل متطلبات الوصول للتطبيقات في الوقت الحقيقي، وليس فقط أرشفة البيانات الباردة. هذا المستوى من الأداء حاسم لعملية تطبيقات Web3.