البلوكشين وWeb3 والعقود الذكية

لماذا أصبح البلوكشين وWeb3 قرارًا هندسيًا لا مجرد موجة تقنية؟

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

ما تغيّر في السنوات الأخيرة ليس وعد البلوكشين فقط، بل نضج أدواته. أصبح تطوير العقود الذكية ممكنًا ببيئة عمل منظمة عبر Solidity وFoundry وHardhat، وأصبحت المكتبات الأمنية مثل OpenZeppelin تخفض الأخطاء المتكررة، وأصبحت المحافظ وواجهات Web3 أكثر قابلية للاستخدام. وفي المقابل، أصبحت الهجمات أكثر تخصصًا: استغلال إعادة الدخول، وسرقة المفاتيح، وهجمات الموافقات، والتلاعب بأسعار الأوراكل. لذلك لم يعد السؤال «هل نستخدم البلوكشين؟» بل «هل نموذج العمل يتحمل مسؤولية الأمان والامتثال التي تأتي معه؟».

السياق السعودي: طموح رقمي مع حرص تنظيمي

السوق السعودي من أكثر الأسواق حيوية في المنطقة من ناحية التحول الرقمي، لكنه أيضًا من أكثرها حرصًا على التنظيم. رؤية 2030 دفعت نحو مجتمع غير نقدي وخدمات مالية مفتوحة وريادة أعمال تقنية، والبنوك وشركات التقنية المالية تعمل ضمن أطر واضحة يصدرها البنك المركزي السعودي (ساما) وهيئة السوق المالية. هذا الحرص ليس عائقًا؛ بل يحدد شكل المنتج الصحيح. المشروع الذي يفهم حدود التمويل والمدفوعات وحماية البيانات منذ البداية يصمم منتجًا قابلًا للاستمرار، أما المشروع الذي يبني على افتراض «سنقنع الجهة التنظيمية لاحقًا» فيتحمل مخاطرة قد توقف العمل كله.

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

أما ترميز الإيصالات فله معنى مختلف عن رفع الفاتورة نفسها إلى سجل عام. البيانات الضريبية وبيانات العميل تبقى في نظام الفوترة الإلكترونية المتوافق مع متطلبات الزكاة والضريبة والجمارك، بينما تُسجَّل بصمة (Hash) للفاتورة أو الإيصال على السلسلة. هذه البصمة تسمح بالتحقق من أن المستند لم يتغير، ويمكن ربطها برمز استجابة سريع في نسخة العميل. الفائدة هنا ليست «وضع الفاتورة على البلوكشين»، بل إثبات سلامتها ومشاركتها مع جهة تدقيق أو شريك دون كشف تفاصيلها. وهذا مثال جيد على الترميز المسؤول: ننقل إثباتًا صغيرًا، ونبقي البيانات الحساسة في مكانها المحكوم بـPDPL.

الفرق بين «مشروع بلوكشين» و«فكرة على بلوكشين»

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

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

من يحتاج هذا القسم؟

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

• لديك أكثر من طرف يحتاج إلى سجل مشترك أو تحقق مستقل.
• تبني منتجًا يعتمد على ملكية رقمية أو نقاط أو مكافآت قابلة للنقل.
• تفكر في إطلاق توكن أو سوق NFT وتريد تقييم الجدوى والالتزام قبل التصميم.
• لديك عقد ذكي جاهز وتحتاج تدقيقًا أو مراجعة أمنية قبل النشر.
• تريد ربط محفظة Web3 بموقع أو متجر أو تطبيق قائم.
• تعمل في مجال تنظيمي وتحتاج إلى خطة تعامل مع PDPL وساما وهيئة السوق المالية.

ما لا نعنيه بالبلوكشين

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

ما الذي يشمله قسم البلوكشين وWeb3 والعقود الذكية؟

يغطي القسم دورة كاملة من أول قرار معماري إلى التشغيل بعد الإطلاق: تحديد الحاجة، واختيار الشبكة، وتصميم البيانات، وكتابة العقود، وبناء الواجهة، والتدقيق، والنشر، والمراقبة، والامتثال. يمكن تنفيذ فرع واحد فقط، مثل تدقيق عقد قائم، أو دمج عدة فروع في منتج متكامل. نعمل مع فرق EVM باستخدام Solidity وFoundry وHardhat، ومع Solana باستخدام Rust وAnchor عند وجود سبب واضح لاختيارها، ونستخدم Polygon أو Base عندما تكون تكلفة المعاملات وسرعة التجربة عاملًا حاسمًا.

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

مبادئ نعمل بها

• الأمان قبل الميزات: كل وظيفة جديدة تزيد سطح الهجوم؛ نضيفها بعد اختبار الأساس.
• أصغر عقد ممكن: لا نضيف منطقًا لا يخدم هدفًا واضحًا، ولا نعتمد على مكتبات غير مدققة.
• الوضوح قبل اللامركزية: نحدد من يملك الصلاحيات، وكيف تُغيّر القواعد، ومن يحاسب عند الخطأ.
• البيانات خارج السلسلة عندما يجب: لا نضع بيانات شخصية أو مستندات حساسة على سجل دائم لا يمكن حذفه.
• الاختبار قبل النشر: اختبارات وحدة وتكامل واختبارات عشوائية وتحليل ثابت قبل أي معاملة حقيقية.
• الامتثال ليس خطوة أخيرة: نراجع الترخيص والضريبة وحماية البيانات قبل تصميم التجربة.
• التوثيق جزء من المنتج: كل قرار معماري وكل خطر متبقٍ له سجل يمكن مراجعته لاحقًا.

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

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

الفروع والخدمات الثمانية

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

حالات استخدام عملية

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

1. ترميز نقاط الولاء لسلسلة تجزئة

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

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

2. سوق NFT لفنانين سعوديين

جهة ثقافية تريد منصة تتيح لفنانين سعوديين إصدار أعمال رقمية محدودة وبيعها، مع الحفاظ على الحقوق وشفافية الإصدار. التحدي ليس تقنيًا فقط: كيف نحمي الفنان من نسخ عمله؟ كيف نوضح ما يشتريه المشتري؟ كيف نتعامل مع الدفع بالبطاقة؟ وكيف ندير المحتوى المخالف؟ نبني سوقًا بعقود ERC-721، وميتاداتا على IPFS، وصفحات فنانين، وإصدارات محدودة موثقة، ورسوم إعادة بيع شفافة.

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

3. تدقيق عقد ذكي لشركة تقنية مالية

شركة تبني عقد ضمان لمدفوعات المشاريع، وتريد إطلاقه بعد شهر. لديها كود مكتوب داخليًا واختبارات أساسية، لكنها لا تملك مراجعة مستقلة. نبدأ بجلسة نموذج تهديد: من يودع؟ من يحرر الدفعة؟ ماذا يحدث عند النزاع؟ هل يمكن للمسؤول سحب الأموال؟ ثم نراجع الكود يدويًا ونشغل Slither وMythril، ونكتب اختبارات Foundry للثوابت مثل «لا يمكن أن يتجاوز مجموع السحوبات الرصيد» و«لا يمكن تحرير الدفعة مرتين».

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

4. ربط المحافظ بمتجر إلكتروني

متجر أزياء يريد ميزة لحاملي NFT: خصم دائم أو وصول مبكر لإصدار محدود. لا نريد أن نعطل رحلة الشراء العادية أو نجبر كل عميل على إنشاء محفظة. نبني طبقة اختيارية: زر «تحقق من العضوية» يظهر بجانب الخصومات، ويفتح اتصال WalletConnect، ويقرأ العقد للتحقق من الملكية، ثم يمنح كودًا لمرة واحدة مرتبطًا بالجلسة. من لا يملك محفظة يكمل الشراء بالطريقة المعتادة.

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

5. حوكمة على نمط DAO لمجتمع تقني

مجتمع تقني يريد أن يشارك أعضاؤه في قرارات الفعاليات والمحتوى والميزانية. الفكرة ليست تحويل المجتمع إلى كيان قانوني افتراضي، بل إضافة طبقة تصويت شفافة. نستخدم عضوية NFT أو توكن حوكمة محدود، ونصمم تصويتًا خارج السلسلة عبر Snapshot لتقليل التكلفة، ثم تنفيذًا على السلسلة عبر خزانة متعددة التوقيعات وفترة تأخير (Timelock). هذا يجمع بين مشاركة واسعة وحماية الأصول.

نصمم وزن التصويت، والنصاب، وتفويض الصوت، ومدة التصويت، وآلية الطوارئ. ونضع ميثاقًا مكتوبًا يوضح قرارات المجتمع والقرارات التي تحتاج إلى مراجعة قانونية. ننصح دائمًا بعدم منح توكن حوكمة قيمة مالية معلنة إذا كان الغرض تنظيميًا بحتًا، وبعدم استخدام كلمة «DAO» كبديل عن الكيان القانوني. مؤشر النجاح: مشاركة متزايدة، وشفافية القرارات، وعدم تعرض الخزانة لخطر سحب سريع.

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

مخاطر لا يجب تجاهلها

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

إعادة الدخول (Reentrancy)

إعادة الدخول تحدث عندما يستدعي عقد خارجي عقدك مرة أخرى قبل أن يكتمل تحديث الحالة، فيتمكن من السحب مرتين أو تغيير رصيد لم يُحدّث بعد. الهجوم الشهير على DAO عام 2016 جعل هذا النمط معروفًا، لكنه يظهر بأشكال جديدة. الوقاية تبدأ بترتيب المنطق: تحقق من الشروط، ثم حدّث الحالة، ثم حوّل القيمة (Checks-Effects-Interactions)، واستخدم ReentrancyGuard في الوظائف الحساسة، وقيّد استدعاء العقود الخارجية. لا يكفي وجود الحارس؛ يجب اختبار السيناريو بعقد خبيث يحاول إعادة الاستدعاء.

إدارة المفاتيح الخاصة

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

التصيد وهجمات الموافقات

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

عدم اليقين التنظيمي

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

السيولة ومخاطر السوق

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

مخاطر إضافية نراها متكررة

• الجسور بين الشبكات: تضيف طبقة ثقة جديدة وغالبًا تكون هدفًا لهجمات كبيرة؛ لا نستخدمها إلا عند حاجة واضحة.
• الأوراكل: أي قرار يعتمد على سعر خارجي يحتاج إلى مصادر متعددة وحماية من التلاعب وتعريف واضح للفشل.
• الترقية: العقد القابل للترقية يمنح المسؤول قدرة كبيرة؛ يجب تأمين المفاتيح وفترة تأخير ومراجعة مجتمعية أو داخلية.
• الاعتماد على مكتبات قديمة: نثبت الإصدارات ونراجع التنبيهات الأمنية ونختبر التحديث قبل الإنتاج.
• تجربة المستخدم: رسالة خطأ غامضة قد تدفع المستخدم إلى تكرار المعاملة أو الموافقة على عملية خاطئة.
• الاحتيال الداخلي: الصلاحيات الواسعة والاحتفاظ بالمفاتيح لدى شخص واحد يخلقان خطرًا حتى دون اختراق خارجي.

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

كيف نعمل؟ منهجية من ست مراحل

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

الأدوات التي نستخدمها

نختار الأدوات بحسب الشبكة ونوع المنتج، لا بحسب الموضة. على EVM نستخدم Solidity مع Foundry وHardhat، ومكتبات OpenZeppelin، وأدوات تحليل مثل Slither وMythril، وشبكات مثل Ethereum وPolygon وBase. على Solana نستخدم Rust وAnchor. في الواجهة نعتمد على wagmi وviem وWalletConnect، وللتخزين اللامركزي على IPFS. ونضيف أدوات المراقبة والاختبار المناسبة لكل مشروع. الأداة لا تصنع الجودة؛ المنهجية والخبرة في تفسير النتائج هما الفرق.

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

المخرجات والتسليمات

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

• وثيقة المتطلبات والقرارات: النموذج التجاري، الأطراف، الوظائف، الافتراضات، وما هو خارج النطاق.
• مخطط المعمارية ونموذج التهديد: ما يُكتب على السلسلة، والأدوار، والمفاتيح، والاعتماديات، وسيناريوهات الفشل.
• الكود المصدري: عقود منظمة ومعلقة، مع مستودع Git وسجل تغييرات وسكربتات نشر.
• حزمة الاختبارات: اختبارات وحدة وتكامل وعشوائية، وتقرير تغطية المسارات الحرجة.
• تقرير التدقيق: ملاحظات مصنفة بالخطورة، وأدلة إعادة الإنتاج، وخطة معالجة، وإعادة تحقق.
• دليل التشغيل: النشر، والترقية، والطوارئ، وإدارة المفاتيح، والمراقبة، وجهات الاتصال.
• واجهة المستخدم ولوحة الإدارة: تجربة عربية متجاوبة، وحالات الخطأ، وأدوات للمحتوى أو المزايا بحسب المشروع.
• مذكرة الامتثال: الأسئلة التنظيمية، ومصفوفة البيانات، والالتزامات المقترحة، وما يحتاج إلى رأي قانوني.
• سجل المخاطر وقرارات القبول: ما تم إغلاقه، وما بقي، ومن وافق على المخاطرة المتبقية ولماذا.
• جلسة تسليم وتدريب: شرح للإدارة والفريق التقني، وأسئلة وأجوبة، وتسليم الوصول.

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

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

التسعير والعوامل المؤثرة

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

العوامل التي ترفع أو تخفض التكلفة

• عدد العقود وتعقيدها: كل عقد وواجهة وترقية تضيف مساحة مراجعة واختبار.
• الشبكة: Ethereum وSolana تختلفان في الأدوات والتكلفة وطريقة النشر، والشبكات منخفضة التكلفة لا تلغي تكلفة الأمان.
• هل يحتفظ العقد بأصول؟ وجود أموال مستخدمين يرفع متطلبات التدقيق والمراقبة والطوارئ.
• التكاملات: المحافظ، والدفع، والأوراكل، والفهرسة، وأنظمة الشركة الخلفية تضيف عملًا واختبارًا.
• الامتثال: مراجعة PDPL وKYC وAML والضرائب تتطلب وقتًا ووثائق، وأحيانًا مستشارًا قانونيًا.
• التصميم وتجربة المستخدم: واجهة عربية كاملة وحالات خطأ متعددة ليست «لمسة أخيرة»، بل جزء من التكلفة.
• الاستعجال: التنفيذ في نافذة ضيقة قد يتطلب موارد إضافية دون التنازل عن الاختبار.

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

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

الأسئلة الشائعة

خدمات ذات صلة

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