Immutable

ما معنى Immutable في الكريبتو؟

تعني كلمة Immutable أن البيانات لا يمكن تغييرها أو حذفها أو التراجع عنها أو إعادة كتابتها بسهولة بعد تسجيلها.

في الكريبتو، تشير عدم القابلية للتغيير عادةً إلى سجلات البلوكشين، وشيفرات العقود الذكية، وقواعد عرض التوكنات، وسجل المعاملات، وبيانات الملكية على السلسلة.

غالبًا ما توصف البلوكشين بأنها غير قابلة للتغيير لأن كل كتلة ترتبط بالكتل السابقة عبر هاشات تشفيرية وقواعد إجماع.

يصف المعهد الوطني للمعايير والتقنية البلوكشين بأنها سجل رقمي يكشف العبث ويقاومه، وتحافظ عليه مجموعة من المشاركين.

ببساطة، تعني عدم القابلية للتغيير أن تعديل بيانات البلوكشين الصحيحة يصبح بالغ الصعوبة بعد تأكيدها بعمق كافٍ.

وهذا أحد أسباب قدرة شبكات الكريبتو على العمل دون الاعتماد على جهة مركزية واحدة لحفظ السجلات.

يمكن للمستخدمين والمحافظ والتطبيقات والمدققين والعُقد التحقق بصورة مستقلة من السجل العام نفسه.

لا تعني عدم القابلية للتغيير أن تغيير أي بلوكشين مستحيل في جميع الظروف.

بل تعني أن النظام مصمم لجعل تغيير السجلات السابقة أمرًا صعبًا تقنيًا أو اقتصاديًا أو اجتماعيًا.

تعتمد قوة عدم القابلية للتغيير على اللامركزية، وأمان الإجماع، وسلوك المدققين أو المعدّنين، وتوزيع العُقد، والتشفير، وحوكمة الشبكة.

أهمية عدم القابلية للتغيير في البلوكشين

تكتسب عدم القابلية للتغيير أهميتها لأن الأصول المشفرة تعتمد على سجلات موثوقة للملكية وسجل المعاملات.

لو استطاع أي شخص إعادة كتابة البلوكشين بحرية، لما أمكن للمستخدمين الوثوق بالأرصدة أو تحويلات التوكنات أو نتائج العقود الذكية أو ملكية NFT أو مراكز DeFi.

تساعد عدم القابلية للتغيير على حماية دفتر السجل من التعديلات الخفية والتلاعب السري.

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

على سبيل المثال، ينشئ تحويل توكن مسجل على السلسلة سجلًا عامًا للمعاملات يمكن التحقق منه لاحقًا.

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

يفيد سجل التدقيق هذا المستخدمين والمطورين والباحثين وفرق الامتثال ومحللي الأمن.

من دون عدم القابلية للتغيير، ستبدو بيانات البلوكشين أشبه بقاعدة بيانات خاصة عادية يستطيع مشغّلها تعديلها.

أما معها، فتصبح البلوكشين سجلًا مشتركًا يصعب تغييره كثيرًا بعد قبول الإجماع له.

وهذا أحد الأسباب الأساسية لأهمية شبكات البلوكشين العامة في العملات المشفرة.

كيف تعمل عدم القابلية للتغيير في البلوكشين؟

تعمل عدم القابلية للتغيير في البلوكشين عبر الربط التشفيري والتحقق الموزع وقواعد الإجماع.

تحتوي كل كتلة على بيانات، وتُلخَّص هذه البيانات باستخدام هاش تشفيري.

وتتضمن كتلة لاحقة إشارة إلى هاش كتلة سابقة.

إذا غيّر أحدهم بيانات في كتلة قديمة، فسيتغير هاش تلك الكتلة.

ويؤدي هذا التغيير إلى قطع الرابط مع الكتل اللاحقة، ما يجعل العبث ظاهرًا للعُقد الأخرى.

توضح الورقة البيضاء لـ Bitcoin أن المعاملات تُؤرَّخ زمنيًا عبر تجزئتها ضمن سلسلة مستمرة من إثبات العمل.

يجعل هذا التصميم إعادة كتابة السجل مكلفة، إذ سيتعين على المهاجم إعادة العمل على الكتلة المعدّلة ثم اللحاق بالسلسلة المقبولة.

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

تحتاج الشبكة إلى طريقة للاتفاق على السجل الصحيح وجعل استبدال السجل السابق أمرًا صعبًا.

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

المعاملات غير القابلة للتغيير

المعاملة غير القابلة للتغيير هي معاملة لا يمكن التراجع عنها بسهولة بعد قبولها في البلوكشين.

في كثير من شبكات البلوكشين العامة، لا تتوفر للمستخدمين آلية اعتيادية لاسترداد المدفوعات بعد تأكيد التحويل.

قد يكون ذلك مفيدًا لأنه يقلل الاعتماد على الوسطاء والنزاعات المتعلقة بالتسوية.

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

توضح وثائق معاملات Ethereum أن المعاملات تعليمات موقعة من الحسابات وتُحدّث حالة الشبكة.

بعد إدراج معاملة في كتلة تم التحقق منها ثم تثبيتها نهائيًا أو تأكيدها بعمق، يصبح تغييرها أصعب بكثير.

لذلك، يجب على المستخدمين التحقق بعناية من عناوين المستلمين، والشبكة المختارة، وكميات التوكنات، وتفاصيل المعاملة قبل التوقيع.

قد تساعد المحفظة في عرض معلومات المعاملة، لكن المستخدم هو من يوافق على تنفيذها.

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

قد تحمي البلوكشين السجل، لكنها لا تستطيع دائمًا حماية المستخدم من توقيع معاملة خاطئة.

العقود الذكية غير القابلة للتغيير

العقد الذكي غير القابل للتغيير هو شيفرة يصعب تغييرها بعد نشرها.

توضح وثائق العقود الذكية لـ Ethereum أن العقود الذكية برامج مخزنة في عناوين على البلوكشين وتعمل وفق قواعد مبرمجة.

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

وهذا مهم لأن المستخدمين يستطيعون فحص شيفرة العقد وفهم قواعده قبل التفاعل معه.

إذا كان العقد غير قابل للتغيير فعلًا، فلن يتمكن المطور من تغيير قواعده سرًا لاحقًا.

وقد يدعم ذلك الثقة لأن الشيفرة تصبح التزامًا عامًا ومستقرًا.

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

إذا نُشرت شيفرة معيبة وتعذر تحديثها، فقد يظل المستخدمون عالقين مع الخلل إلى الأبد.

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

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

العقود الذكية غير القابلة للتغيير مقابل العقود القابلة للترقية

لا يمكن تغيير العقود الذكية غير القابلة للتغيير بعد نشرها في الظروف المعتادة.

أما العقود الذكية القابلة للترقية فتستخدم أنماط تصميم تتيح للمطورين أو الحوكمة تغيير منطق العقد لاحقًا.

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

لكنها تقلل من عدم القابلية للتغيير بالمفهوم الصرف، لأن جهة ما تملك صلاحية تغيير طريقة عمل النظام.

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

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

قد يعرض البروتوكول عنوان عقد واحدًا، لكنه يستخدم وكيلًا يشير إلى منطق قابل للتغيير.

ليس هذا التصميم سيئًا بالضرورة، لكنه يتطلب الثقة بضوابط المسؤولين والحوكمة والتأخير الزمني وإجراءات الأمان.

السؤال الأساسي هو: من يستطيع تغيير الشيفرة، وبموجب أي قواعد؟

تعني عدم القابلية الحقيقية للتغيير عدم وجود صلاحية ترقية خفية بعد النشر.

دفتر السجل غير القابل للتغيير

دفتر السجل غير القابل للتغيير هو نظام تسجيل مصمم بحيث لا يمكن تغيير القيود السابقة سرًا.

في الكريبتو، يسجل دفتر السجل الأرصدة والتحويلات واستدعاءات العقود وأحداث سك التوكنات وعمليات Staking وأنشطة أخرى على السلسلة.

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

إذا عرضت عقدة واحدة نسخة زائفة من السجل، تستطيع العُقد النزيهة الأخرى رفضها.

وهذا يجعل دفتر السجل أكثر مرونة من قاعدة بيانات خاصة واحدة.

ومع ذلك، تكون عدم القابلية للتغيير أقوى عندما تخزن سلسلة البلوكشين وتتحقق منها عُقد مستقلة كثيرة.

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

تدعم اللامركزية وعدم القابلية للتغيير إحداهما الأخرى.

تزداد مصداقية دفتر السجل عندما لا تستطيع جهة واحدة إعادة كتابته بسهولة.

لذلك، يهم تنوع العُقد والتحقق المفتوح وقواعد الإجماع الشفافة لبناء الثقة بالبلوكشين على المدى الطويل.

عدم القابلية للتغيير والنهائية

تعني النهائية أن المعاملة أو الكتلة تُعد مستقرّة ومن غير المرجح جدًا التراجع عنها.

ترتبط عدم القابلية للتغيير بالنهائية، لكنهما ليستا المفهوم نفسه تمامًا.

تصف عدم القابلية للتغيير مقاومة التغييرات.

أما النهائية فتصف المرحلة التي يمكن عندها للمستخدمين التعامل مع المعاملة على أنها مستقرة.

تتمتع بعض شبكات البلوكشين بنهائية احتمالية، إذ تزداد الثقة كلما أُضيفت كتل أكثر بعد المعاملة.

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

توضح وثائق معاملات Ethereum أن الكتلة تصبح أكثر يقينًا بعد تبريرها وتثبيتها نهائيًا.

والسؤال العملي للمستخدمين هو عدد التأكيدات أو حالة النهائية المطلوبة قبل اعتبار المعاملة مكتملة.

قد تتطلب التحويلات الصغيرة عددًا أقل من التأكيدات.

أما التحويلات الكبيرة وإيداعات الجسور والتسويات المؤسسية، فقد تتطلب تحققًا أقوى من النهائية.

عدم القابلية للتغيير والتأكيدات

يحدث التأكيد عندما تُدرج معاملة في كتلة ثم تُضاف كتل أخرى بعدها.

عادةً ما تجعل التأكيدات الإضافية التراجع عن المعاملة أصعب.

في أنظمة إثبات العمل، يتطلب تغيير معاملة استبدال الكتلة التي تتضمنها والكتل التي تليها.

أما في أنظمة إثبات الحصة، فقد تعتمد النهائية على تصويت المدققين ووزن الحصة والعقوبات وقواعد البروتوكول.

تكتسب التأكيدات أهميتها لأن سجل البلوكشين قد يعاد تنظيمه أحيانًا قبل أن يستقر بعمق.

وتحدث إعادة التنظيم، التي تسمى غالبًا reorg، عندما تستبدل الشبكة فرعًا حديثًا من السلسلة بفرع صالح آخر.

قد تحدث عمليات إعادة تنظيم صغيرة بصورة طبيعية في بعض الأنظمة.

أما عمليات إعادة التنظيم الكبيرة أو الخبيثة فهي أخطر بكثير لأنها قد تهدد الثقة بالتسوية.

ينبغي للمستخدمين إدراك أن وصف البيانات بأنها غير قابلة للتغيير لا يعني أنها نهائية فور ظهور المعاملة.

تزداد قوة عدم القابلية للتغيير كلما ازداد قبول الشبكة للمعاملة بعمق.

عدم القابلية للتغيير والهاشات التشفيرية

تُعد الهاشات التشفيرية سببًا رئيسيًا في قدرة سجلات البلوكشين على كشف العبث.

تحول دالة الهاش بيانات الإدخال إلى ناتج ثابت الحجم.

إذا تغيرت بيانات الإدخال ولو قليلًا، يتغير الناتج بشكل كبير.

وهذا يجعل الهاشات مفيدة لاكتشاف التغييرات في بيانات البلوكشين.

عندما تتضمن الكتل هاشات الكتل السابقة، تصبح السلسلة مترابطة.

يؤدي تغيير كتلة قديمة إلى تغيير هاشها وكسر الإشارات اللاحقة إليها.

وتستطيع العُقد النزيهة اكتشاف هذا التعارض ورفض السجل المعدّل.

لا تجعل الهاشات البيانات مستحيلة التغيير بمفردها.

بل تجعل اكتشاف التغييرات سهلًا عند اقترانها بشبكة تتفق على السجل الصحيح.

في تصميم البلوكشين، يعمل الهاش كنظام إنذار، بينما يعمل الإجماع كطبقة إنفاذ.

عدم القابلية للتغيير والإجماع

الإجماع هو العملية التي يتفق عبرها المشاركون في البلوكشين على الحالة الصحيحة للشبكة.

من دون الإجماع، قد تختلف العُقد بشأن الأرصدة والمعاملات والكتل ونتائج العقود.

تحدد قواعد الإجماع الكتل الصحيحة والمعاملات المقبولة والسجل الذي يصبح معتمدًا للسلسلة.

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

في إثبات العمل، ينفق المعدّنون موارد حاسوبية لإنتاج الكتل.

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

تنشئ أنظمة الإجماع المختلفة افتراضات مختلفة بشأن عدم القابلية للتغيير.

تجعل الشبكة القوية إعادة كتابة السجل صعبة لأن على المهاجمين تجاوز عوائق تقنية أو اقتصادية أو اجتماعية كبيرة.

أما الشبكة الضعيفة فقد يسهل إعادة تنظيمها أو فرض الرقابة عليها.

لذلك، ينبغي تقييم عدم القابلية للتغيير بناءً على أمان الشبكة الفعلي، لا الادعاءات التسويقية وحدها.

عدم القابلية للتغيير وملكية التوكنات

تعتمد ملكية التوكنات على البلوكشين على الأرصدة المسجلة والتوقيعات الصحيحة.

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

عند تأكيد تحويل توكن، يحدّث دفتر السجل سجلات الملكية.

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

وهذا مهم للتوكنات القابلة للاستبدال وNFTs وتوكنات الحوكمة وتوكنات Staking والأصول المغلفة.

لو كان تعديل سجلات الملكية سهلًا، لأمكن مصادرة التوكنات أو نسخها دون دليل عام واضح.

لكن عدم القابلية للتغيير لا تعني أن كل توكن يقاوم الرقابة.

تتضمن بعض عقود التوكنات صلاحيات إدارية مثل الإيقاف والتجميد والإدراج في القائمة السوداء والسك والحرق والترقية.

قد تكون هذه الضوابط مصممة للامتثال أو الأمان أو الاستجابة للطوارئ.

ينبغي للمستخدمين مراجعة صلاحيات عقد التوكن قبل افتراض أن قواعد الملكية غير قابلة للتغيير بالكامل.

عدم القابلية للتغيير وNFTs

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

يمكن لسجل ملكية NFT على السلسلة أن يوضح العنوان الذي يملك التوكن وكيف انتقل بين العناوين.

لكن الوسائط أو البيانات الوصفية المرتبطة بـ NFT قد لا تكون غير قابلة للتغيير بالكامل دائمًا.

تشير بعض NFTs إلى ملفات مخزنة خارج السلسلة على خوادم عادية.

وتستخدم بعض NFTs تخزينًا لامركزيًا أو أنظمة تعتمد على عناوين المحتوى.

ويمكن لمسؤولي المشروع تغيير بيانات بعض NFTs الوصفية إذا أتاح العقد ذلك.

لذلك، ينبغي للمستخدمين التمييز بين ملكية غير قابلة للتغيير وبيانات وصفية غير قابلة للتغيير.

قد يكون لـ NFT معرّف توكن غير قابل للتغيير، بينما تكون بيانات صورته قابلة للتغيير.

وقد تكون بياناته الوصفية غير قابلة للتغيير، بينما يظل منطق عقده قابلًا للترقية.

يتطلب التحليل الجيد لـ NFT التحقق من مكان تخزين بيانات الأصل وما إذا كان بوسع أي جهة تغييرها.

عدم القابلية للتغيير وDeFi

تستخدم بروتوكولات DeFi عدم القابلية للتغيير لإنشاء قواعد شفافة للإقراض والتداول ومجمعات السيولة والضمانات وStaking والحوكمة.

عندما يكون عقد DeFi غير قابل للتغيير، يستطيع المستخدمون فحص القواعد ومعرفة أن المسؤول لن يغيرها لاحقًا.

وقد يقلل ذلك من مخاطر الحوكمة والسيطرة الخفية.

لكن أنظمة DeFi معقدة وتعتمد غالبًا على مكونات خارجية.

قد تكون عقود المجمعات في البروتوكول غير قابلة للتغيير، بينما تكون الموجّهات قابلة للترقية.

وقد يكون منطق الخزائن غير قابل للتغيير، بينما يمكن تغيير إعدادات Oracle.

وقد تكون عقود التوكنات غير قابلة للتغيير، بينما تخضع المعلمات للحوكمة.

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

يتحقق التحليل الحقيقي لمخاطر DeFi من كل تبعية يمكن أن تغير النتائج للمستخدم.

عدم القابلية للتغيير ميزة قيّمة، لكنها طبقة واحدة فقط من أمان البروتوكول.

البيانات غير القابلة للتغيير مقابل البيانات القابلة للتغيير

البيانات غير القابلة للتغيير هي بيانات لا يمكن تغييرها بعد كتابتها.

أما البيانات القابلة للتغيير فيمكن تعديلها أو استبدالها أو تحديثها أو حذفها.

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

فعلى سبيل المثال، يمكن تغيير واجهة تطبيق dApp حتى إن لم يتغير العقد الذكي.

وقد يتغير شعار توكن في واجهة المحفظة مع بقاء ملكية التوكن كما هي.

وقد يتغير موقع المشروع الإلكتروني حتى إن كان عقده على السلسلة غير قابل للتغيير.

ويمكن تحديث موجز بيانات Oracle باستمرار حتى إن كان العقد الذي يقرأه دائمًا.

هذا التمييز مهم لأن المستخدمين يرون غالبًا مزيجًا من المعلومات على السلسلة وخارجها.

البيانات التي يؤمّنها نظام إجماع البلوكشين فعلًا وحدها تتمتع بعدم القابلية للتغيير على مستوى البلوكشين.

أما البيانات الأخرى، فينبغي تقييمها وفق نموذج التخزين والتحكم الخاص بها.

عدم القابلية للتغيير والشفافية على السلسلة

تدعم عدم القابلية للتغيير الشفافية لأن بيانات البلوكشين التاريخية تظل متاحة للمراجعة.

يمكن للمستخدمين فحص المعاملات القديمة وتحويلات التوكنات ونشر العقود وتصويتات الحوكمة وتحركات السيولة.

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

كما يستطيع المدققون التحقق مما إذا كان المشروع قد التزم باقتصاديات التوكن المعلنة.

ويستطيع الباحثون دراسة سلوك المحافظ واستخدام البروتوكولات ونشاط السوق.

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

إذ يمكنهم التحقق مباشرة من كثير من الادعاءات على السلسلة.

لكن الشفافية لا تجعل البيانات سهلة الفهم تلقائيًا.

قد تكون المعاملات معقدة، واستدعاءات العقود صعبة القراءة، ومالكو المحافظ مجهولين.

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

فوائد عدم القابلية للتغيير

أول فوائد عدم القابلية للتغيير تقليل الحاجة إلى الثقة.

يمكن للمستخدمين الاعتماد بدرجة أكبر على الشيفرة والإجماع وبدرجة أقل على مشغّل مركزي.

والفائدة الثانية هي قابلية التدقيق.

يمكن مراجعة المعاملات السابقة والتفاعلات مع العقود لاحقًا.

والفائدة الثالثة هي الثقة بالتسوية.

يصعب التراجع عن المعاملات المؤكدة بعد بلوغ عدد كافٍ من التأكيدات أو تحقق النهائية.

والفائدة الرابعة مقاومة التعديلات الخفية.

تجعل البلوكشين العامة اكتشاف العبث أسهل.

والفائدة الخامسة تعزيز الملكية الرقمية.

يمكن للمستخدمين إثبات سجل الأصول وملكيتها عبر سجلات عامة.

والفائدة السادسة هي إمكانية التنبؤ بسلوك العقود الذكية.

تستطيع العقود غير القابلة للتغيير تطبيق القواعد دون تغييرات غير متوقعة من المطورين.

مخاطر عدم القابلية للتغيير وحدودها

الخطر الأول هو الأخطاء التي لا يمكن التراجع عنها.

إذا أرسل المستخدم أموالًا إلى عنوان خاطئ، فقد يستحيل استردادها.

والخطر الثاني هو الأخطاء البرمجية الدائمة.

إذا احتوى عقد ذكي على خلل وتعذرت ترقيته، فقد يبقى الخلل إلى الأبد.

والخطر الثالث عمليات الاحتيال والعقود الخبيثة.

قد تحفظ عدم القابلية للتغيير الشيفرة الضارة كما تحفظ الشيفرة المفيدة.

والخطر الرابع الثقة الزائفة.

قد يفترض المستخدمون أن النظام غير قابل للتغيير دون التحقق من صلاحيات الترقية أو ضوابط المسؤولين.

والخطر الخامس تجاوز الحوكمة.

تستطيع بعض الأنظمة تغيير القواعد عبر الحوكمة أو Fork أو إجراءات الطوارئ.

والخطر السادس ضعف المكونات خارج السلسلة.

قد يكون سجل البلوكشين غير قابل للتغيير، بينما تظل المواقع والبيانات الوصفية والخوادم وواجهات API المرتبطة به قابلة للتغيير.

عدم القابلية للتغيير وForks

يحدث Fork عندما تنقسم قواعد البلوكشين أو سجلاتها إلى مسارات مختلفة.

بعض عمليات Fork ترقيات مخططة تغير قواعد الشبكة ابتداءً من نقطة معينة.

وتحدث عمليات أخرى بسبب الخلافات أو الأخطاء أو الهجمات أو التنافس بين نسخ مختلفة من السجل.

توضح عمليات Fork أن عدم القابلية للتغيير في البلوكشين تقنية واجتماعية جزئيًا.

قد تجعل البرمجيات تغيير السجل صعبًا، لكن المجتمعات تظل قادرة على اختيار السلسلة التي تتبعها بدلًا من أخرى.

هذا لا يعني أن عدم القابلية للتغيير زائفة.

بل يعني أنها تعتمد على السجل الذي يعترف به المستخدمون والعُقد والمطورون والمدققون والمحافظ والتطبيقات على أنه صالح.

النقطة المهمة للمستخدمين هي أن النهائية واختيار السلسلة لهما أهمية.

لا تكون المعاملة مفيدة إلا إذا واصل النظام البيئي الاعتراف بالسلسلة التي توجد عليها.

يمكن للإجماع الاجتماعي القوي أن يعزز مصداقية عدم القابلية للتغيير بمرور الوقت.

عدم القابلية للتغيير والحوكمة

قد تؤثر الحوكمة في عدم القابلية للتغيير عندما يسمح البروتوكول بإجراء تغييرات عبر التصويت أو العمليات الإدارية.

تستخدم بعض المشاريع الحوكمة لتعديل الرسوم والمكافآت وقواعد الضمانات وإعدادات Oracle وعناوين العقود وإصدار التوكنات.

قد تساعد هذه المرونة البروتوكول على التكيف.

لكنها قد تقلل اليقين أيضًا لأن القواعد المستقبلية قد تتغير.

ينبغي للمستخدمين التحقق مما إذا كانت الحوكمة تستطيع ترقية العقود أو نقل أموال الخزينة أو تغيير عرض التوكنات أو تجميد الأصول أو تعديل المعلمات الأساسية.

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

وقد يكون ذلك مقبولًا إذا فهم المستخدمون هذه المفاضلة.

تنشأ المشكلات عندما يسوق مشروع لنفسه على أنه غير قابل للتغيير بينما لا تزال الحوكمة أو الإدارة تملك صلاحيات مؤثرة.

الإفصاح الواضح مهم لأن المستخدمين بحاجة إلى معرفة ما يمكن تغييره.

تكون عدم القابلية للتغيير أقوى عندما تكون صلاحيات التغيير محدودة ومعلنة ومؤجلة ويسهل التحقق منها.

عدم القابلية للتغيير والأمان

تحسن عدم القابلية للتغيير الأمان بجعل تغيير السجلات صعبًا بعد التأكيد.

كما تخلق تحديات أمنية لأن إصلاح الأخطاء المنشورة قد يكون صعبًا.

تستطيع شركة برمجيات تقليدية تحديث تطبيق خادم بعد اكتشاف خلل.

لكن العقد الذكي غير القابل للتغيير بالكامل قد لا يتيح النوع نفسه من التحديث.

وهذا يرفع معايير الاختبار قبل النشر.

ينبغي للمطورين استخدام التدقيق ومراجعة الشيفرة والتحليل الثابت واختبار الثوابت واختبارات Fuzz والتحقق الرسمي والإطلاق المرحلي عند الاقتضاء.

وينبغي للمستخدمين تفضيل العقود ذات الوثائق الواضحة والشيفرة المصدرية المتحقق منها والصلاحيات الشفافة وسجل التشغيل الآمن.

يتطلب الأمان في الأنظمة غير القابلة للتغيير اتخاذ إجراءات قبل النشر وبعده.

الهدف قبل النشر هو تجنب تثبيت أخطاء خطرة.

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

عدم القابلية للتغيير ومسؤولية المستخدم

تنقل عدم القابلية للتغيير مزيدًا من المسؤولية إلى المستخدمين.

عندما يصعب التراجع عن المعاملات، يجب على المستخدمين توخي الحذر قبل التوقيع.

ينبغي لهم التحقق من العناوين والشبكات وعقود التوكنات والموافقات وملخصات المعاملات.

كما ينبغي لهم تجنب توقيع رسائل أو معاملات لا يفهمونها.

ويجب توخي الحذر من إيردروبات مجهولة ورسائل دعم مزيفة وروابط خبيثة وتطبيقات dApp مشبوهة.

يمكن استخدام محافظ الأجهزة أو محافظ التوقيع المتعدد للأرصدة الكبيرة عند الاقتضاء.

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

ينبغي تذكر أن دفتر السجل غير القابل للتغيير لا يستطيع دائمًا تصحيح الخطأ البشري.

وهذه هي المفاضلة المرتبطة بالحفظ الذاتي.

فالنظام نفسه الذي يمنع التراجع الخفي قد يجعل أخطاء المستخدم دائمة أيضًا.

كيفية التحقق مما إذا كان شيء ما غير قابل للتغيير

الخطوة الأولى هي تحديد الشيء الموصوف بأنه غير قابل للتغيير.

قد يكون معاملة أو عقد توكن أو وظيفة عقد ذكي أو بيانات وصفية أو قاعدة حوكمة أو معلمة بروتوكول.

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

والخطوة الثالثة مراجعة ما إذا كان العقد يتضمن وظائف المالك أو المسؤول أو الوكيل أو الترقية أو الإيقاف أو السك أو التجميد أو الإدراج في القائمة السوداء.

والخطوة الرابعة التحقق مما إذا كانت التغييرات خاضعة لحساب واحد أو محفظة متعددة التوقيعات أو قفل زمني أو تصويت DAO أو لا أحد.

والخطوة الخامسة مراجعة الوثائق ومقارنتها بسلوك العقد الفعلي.

والخطوة السادسة التحقق من وجود بيانات خارج السلسلة.

والخطوة السابعة فهم نموذج النهائية الخاص بالبلوكشين نفسها.

ينبغي اختبار ادعاء عدم القابلية للتغيير في ضوء الشيفرة والحوكمة والتخزين والإجماع.

ويُفضّل أن يثق المستخدمون بما يمكن التحقق منه أكثر مما يُعلن عنه.

مفاهيم خاطئة شائعة عن عدم القابلية للتغيير

من المفاهيم الخاطئة الشائعة أن عدم القابلية للتغيير تعني استحالة التغيير في جميع الظروف.

عمليًا، تعني أن التغيير بالغ الصعوبة وفق قواعد النظام وافتراضاته الأمنية.

ومن المفاهيم الخاطئة الأخرى أن كل عقد ذكي غير قابل للتغيير بالكامل.

فبعض العقود قابل للترقية أو خاضع لصلاحيات المسؤولين.

أما المفهوم الخاطئ الثالث فهو أن عدم القابلية للتغيير تعني الأمان.

فقد تكون الشيفرة غير الآمنة غير قابلة للتغيير أيضًا.

والمفهوم الخاطئ الرابع هو أن عدم القابلية للتغيير تعني الخصوصية.

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

والمفهوم الخاطئ الخامس هو أن ملكية التوكن غير القابلة للتغيير تعني أن بياناته الوصفية غير قابلة للتغيير.

قد تكون ملكية NFT على السلسلة، بينما تظل الصور أو البيانات الوصفية قابلة للتغيير في أماكن أخرى.

أما المفهوم الخاطئ السادس فهو أن عدم القابلية للتغيير تلغي الحاجة إلى الأمان.

في الواقع، تجعل عدم القابلية للتغيير الأمان أكثر أهمية لأن إصلاح الأخطاء قد يصبح أصعب.

أفضل الممارسات للمطورين

ينبغي للمطورين أن يقرروا مبكرًا ما إذا كان العقد يجب أن يكون غير قابل للتغيير أو قابلًا للترقية أو قابلًا للضبط جزئيًا.

كما ينبغي لهم توثيق كل دور يستطيع تغيير سلوك العقد.

ويجب تجنب صلاحيات المسؤول الخفية التي تتعارض مع توقعات المستخدمين.

ينبغي اختبار كل الوظائف الأساسية قبل النشر.

ويُستحسن إجراء عمليات تدقيق مستقلة للعقود التي ستحتفظ بقيمة معتبرة.

وعند الحاجة إلى قابلية الترقية، ينبغي استخدام التأخير الزمني وضوابط التوقيع المتعدد.

كما ينبغي إتاحة التحقق من الشيفرة المصدرية للعقد متى أمكن.

ويجب حصر صلاحيات الطوارئ في حالات واضحة ومحدودة.

وينبغي مراقبة العقود المنشورة لرصد النشاط غير المعتاد.

على المطورين شرح المفاضلة بين عدم القابلية للتغيير وقابلية الترقية بلغة واضحة.

أفضل الممارسات للمستخدمين

ينبغي للمستخدمين التحقق مما إذا كان العقد غير قابل للتغيير قبل الاعتماد على قواعده.

ويجب ألا يفترضوا أن البروتوكول غير قابل للتغيير لمجرد أنه يعمل على البلوكشين.

ينبغي مراجعة صلاحيات المسؤول وأنماط الوكلاء وقواعد الحوكمة وضوابط التوكن.

ويجب التحقق من تفاصيل المعاملة قبل التوقيع، لأن المعاملات المؤكدة قد لا تقبل التراجع.

ينبغي استخدام محافظ موثوقة تعرض تفاصيل المعاملات بوضوح.

كما ينبغي الحذر من موافقات التوكنات غير المحدودة، إذ قد تظل سارية حتى تغييرها.

يجب التعامل مع العقود المجهولة على أنها محفوفة بالمخاطر حتى لو كانت غير قابلة للتغيير.

ينبغي فهم ما إذا كانت وسائط NFT وبياناتها الوصفية مخزنة على السلسلة أم خارجها.

ويُستحسن انتظار عدد كافٍ من التأكيدات أو تحقق النهائية قبل اعتبار التحويلات الكبيرة مستقرّة.

كما ينبغي تذكر أن عدم القابلية للتغيير تحمي السجلات، لا كل قرار يتخذه المستخدم.

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

ماذا تعني Immutable في الكريبتو؟

تعني أن بيانات البلوكشين أو المعاملات أو قواعد العقود الذكية مصممة بحيث يصعب جدًا تغييرها بعد تسجيلها.

هل تعني عدم القابلية للتغيير استحالة التغيير؟

لا. تعني عادةً أن التغيير بالغ الصعوبة وفق افتراضات أمان الشبكة، وليس أنه مستحيل في كل الظروف الممكنة.

لماذا توصف البلوكشين بأنها غير قابلة للتغيير؟

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

هل معاملات الكريبتو غير قابلة للتغيير؟

تصبح معاملات كثيرة غير قابلة للتغيير عمليًا بعد عدد كافٍ من التأكيدات أو تحقق النهائية، ما يجعل التراجع عنها صعبًا.

هل العقود الذكية غير قابلة للتغيير؟

بعض العقود الذكية غير قابل للتغيير بعد النشر، لكن عقودًا أخرى قابلة للترقية أو خاضعة لصلاحيات المسؤولين.

هل عدم القابلية للتغيير مفيدة دائمًا؟

لا. فهي مفيدة للثقة وقابلية التدقيق، لكنها قد تثبّت الأخطاء البرمجية والهفوات والشيفرات الخبيثة.

ما الفرق بين عدم القابلية للتغيير والنهائية؟

تعني عدم القابلية للتغيير مقاومة التغييرات، بينما تعني النهائية أن المعاملة أو الكتلة مستقرة بما يكفي للاعتماد عليها.

هل يمكن ترقية عقد غير قابل للتغيير؟

لا يمكن ترقية العقد غير القابل للتغيير فعلًا، لكن العقد القائم على وكيل أو الخاضع للحوكمة قد يكون قابلًا للترقية حتى إن بدا مستقرًا للمستخدمين.

هل يمكن أن تكون بيانات NFT الوصفية غير قابلة للتغيير؟

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

هل تحمي عدم القابلية للتغيير المستخدمين من الاحتيال؟

لا. قد تحفظ عدم القابلية للتغيير سجلات المعاملات، لكنها لا تمنع المستخدمين من توقيع معاملات خبيثة أو التفاعل مع عقود غير آمنة.

كيف أتحقق مما إذا كان العقد غير قابل للتغيير؟

يمكنك مراجعة شيفرة العقد الموثقة وأدوار المسؤول وإعدادات الوكيل ووظائف الترقية والتأخير الزمني وصلاحيات الحوكمة.

لماذا تهم عدم القابلية للتغيير في DeFi؟

تكتسب أهميتها في DeFi لأن المستخدمين يعتمدون على قواعد شفافة ومستقرة للإقراض والتداول والسيولة والضمانات والتسوية.

الخلاصة

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

وهي تساعد على جعل المعاملات قابلة للتدقيق والملكية قابلة للتحقق وسلوك البروتوكول أكثر قابلية للتوقع.

تنبع عدم القابلية للتغيير في البلوكشين من الهاشات التشفيرية والكتل المترابطة والعُقد الموزعة وقواعد الإجماع والأمان الاقتصادي.

وقد تمنح عدم القابلية للتغيير في العقود الذكية المستخدمين الثقة بأن الشيفرة المنشورة ستواصل العمل كما كُتبت.

لكن عدم القابلية للتغيير لا تعني الأمان المطلق.

فقد تكون المعاملة غير القابلة للتغيير معاملة خاطئة.

وقد يحتوي العقد غير القابل للتغيير على خلل.

وقد يشير سجل الملكية غير القابل للتغيير إلى بيانات وصفية خارج السلسلة قابلة للتغيير.

وقد يظل البروتوكول الذي يبدو غير قابل للتغيير خاضعًا لصلاحيات الترقية عبر الوكلاء أو الحوكمة أو أدوار المسؤولين.

تُلزم عدم القابلية للتغيير المطورين باختبار العقود وتدقيقها قبل النشر، لأن إصلاح الأخطاء لاحقًا قد يكون صعبًا.

كما تلزم المستخدمين بالتحقق قبل التوقيع، لأن التراجع عن الإجراءات المؤكدة قد يكون صعبًا أو مستحيلًا.

وأفضل طريقة لفهم عدم القابلية للتغيير هي طرح الأسئلة التالية: ما الشيء الذي لا يمكن تغييره تحديدًا؟ ومن قد يظل قادرًا على تغييره؟ وما الافتراضات التي تحمي السجل؟

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