آلة الحالة

ما هي آلة الحالة في الكريبتو؟

آلة الحالة هي نظام ينتقل من حالة صالحة إلى أخرى عند تلقي إدخال وتطبيق مجموعة ثابتة من القواعد.

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

الحالة هي الوضع الحالي للبلوكشين.

ويكون الإدخال عادةً معاملة أو كتلة أو رسالة أو استدعاء لعقد ذكي.

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

إذا طُبق الإدخال الصالح نفسه على حالة البدء ذاتها، فينبغي أن تصل كل عقدة صادقة إلى حالة النهاية نفسها.

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

تصف الورقة البيضاء الرسمية لـ Ethereum حالة Ethereum بأنها تتكون من حسابات، وتصف انتقالات الحالة بأنها تحويلات للقيمة والمعلومات بين الحسابات.

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

لماذا تهم آلات الحالة في البلوكشين؟

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

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

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

عند اقتراح كتلة، تتحقق العقد من معاملات تلك الكتلة وتطبق قواعد البروتوكول.

إذا أدت معاملات الكتلة إلى حالة جديدة صالحة، يمكن قبول الكتلة.

أما إذا خالفت المعاملات القواعد، فترفض العقد الصادقة الكتلة.

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

كما تساعد آلة الحالة المستخدمين على فهم سبب عدم كفاية سجل البلوكشين وحده.

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

والنتيجة النهائية هي حالة جديدة يمكن لكل عقدة صادقة إعادة إنتاجها.

الحالة والإدخال ودالة الانتقال

تحتوي كل آلة حالة للبلوكشين على ثلاثة أجزاء أساسية: الحالة والإدخال ودالة الانتقال.

الحالة هي مجموعة البيانات الحالية التي يحتاجها البلوكشين لمعالجة الإجراءات الجديدة.

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

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

الإدخال هو الإجراء الجديد المقدم إلى النظام.

في معظم شبكات الكريبتو، يكون الإدخال الأكثر شيوعًا معاملة موقعة.

ودالة الانتقال هي مجموعة القواعد التي تتحقق من الإدخال وتحدث الحالة.

على سبيل المثال، قد تكون المعاملة صالحة فقط إذا كان التوقيع صحيحًا، وكان لدى المرسل رصيد كافٍ، وكان nonce صحيحًا، ودُفعت الرسوم.

إذا اجتازت جميع القواعد، تطبق آلة الحالة المعاملة وتنشئ حالة جديدة.

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

البلوكشين كآلة حالة مكررة

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

يعني التكرار أن العديد من أجهزة الكمبيوتر تحتفظ بالنظام وتحدثه بدلًا من خادم مركزي واحد.

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

ترتيب المعاملات مهم، لأن تطبيق المعاملات ذاتها بترتيب مختلف قد ينتج نتيجة مختلفة.

تساعد آليات الإجماع الشبكة على الاتفاق على ترتيب الكتل والمعاملات.

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

تصف وثائق CometBFT الرسمية CometBFT بأنه برنامج ينفذ تكرار آلة الحالة المتحملة للأخطاء البيزنطية لآلات الحالة الحتمية محدودة الحالات.

يجسد هذا الوصف الفكرة العامة وراء العديد من أنظمة البلوكشين.

يتفق الإجماع على المدخلات المرتبة، بينما تطبق آلة الحالة تلك المدخلات لإنتاج الحالة التالية.

ولا يعمل البلوكشين إلا عندما يكون كلا الجزأين صحيحين.

الحتمية في آلات الحالة الخاصة بالكريبتو

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

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

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

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

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

حتى الفروقات الصغيرة في التنفيذ قد تكون خطرة إذا غيرت جذر الحالة النهائي أو نتيجة دفتر الأستاذ.

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

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

وهذا يجعل برمجة البلوكشين أكثر صرامة من برمجة الويب العادية.

ولا تكون آلة الحالة موثوقة إلا عندما تكون قواعد انتقالها قابلة للتوقع وإعادة الإنتاج.

Ethereum كآلة حالة

تعد Ethereum من أوضح أمثلة آلة حالة البلوكشين.

تصف الورقة البيضاء لـ Ethereum Ethereum بأنها تمتلك حالة مكونة من حسابات، ويحتوي كل حساب على nonce ورصيد وكود عقد وتخزين.

تطلق المعاملات انتقالات الحالة عبر نقل القيمة أو إنشاء العقود أو استدعاء العقود أو تغيير تخزين العقود.

آلة Ethereum الافتراضية، أو EVM، هي بيئة التنفيذ التي تعالج كود العقود الذكية.

تصف وثائق Ethereum EVM الرسمية آلة EVM بأنها بيئة افتراضية لامركزية تنفذ الكود بصورة متسقة وآمنة عبر جميع عقد Ethereum.

وهذا يعني أن EVM جزء من آلية انتقال الحالة في Ethereum.

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

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

إذا نفذت كل عقدة المعاملة نفسها من حالة البدء ذاتها، ينبغي أن تصل كل عقدة صادقة إلى حالة النهاية نفسها.

لهذا تستطيع Ethereum دعم التطبيقات القابلة للبرمجة دون الاعتماد على خادم تطبيق مركزي.

الحالة العالمية لـ Ethereum

الحالة العالمية لـ Ethereum هي الحالة العامة الحالية لجميع حسابات Ethereum.

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

توضح وثائق Ethereum Merkle Patricia Trie أن لدى Ethereum شجرة حالة عالمية واحدة تُحدّث كلما عالج العميل كتلة.

وتنتج شجرة الحالة هذه جذر حالة يلتزم بالحالة العالمية الحالية.

يُخزن جذر الحالة في رأس الكتلة.

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

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

تحدث آلة الحالة الحالة العالمية، ويتيح جذر الحالة للعقد التحقق من اتفاقها على النتيجة.

يربط هذا التصميم التنفيذ والتخزين والإجماع.

من دون حالة عالمية مشتركة، لن تمتلك عقود Ethereum الذكية بيئة مشتركة للقراءة منها والكتابة إليها.

Bitcoin كآلة حالة

Bitcoin هي أيضًا آلة حالة، لكنها تستخدم نموذج حالة مختلفًا عن Ethereum.

لا تستخدم Bitcoin نظام حسابات عالميًا مثل Ethereum.

بل تستخدم Bitcoin نموذج UTXO، حيث تمثل مجموعة مخرجات المعاملات غير المنفقة الحالة الحالية القابلة للإنفاق.

يوضح دليل مطوري Bitcoin للمعاملات أن المعاملات تنفق مخرجات المعاملات غير المنفقة وتنشئ مخرجات جديدة.

تكون معاملة Bitcoin صالحة فقط إذا أنفقت UTXO موجودة لم تُنفق مسبقًا.

عند قبول معاملة صالحة، تُزال UTXO المستهلكة من المجموعة القابلة للإنفاق.

وتصبح المخرجات الجديدة التي تنشئها المعاملة UTXO جديدة.

يعني ذلك أن دالة انتقال الحالة في Bitcoin تحدّث مجموعة UTXO.

آلة حالة Bitcoin أقل عمومية من نموذج العقود الذكية في Ethereum، لكنها تظل نظامًا حتميًا لتحديث حالة الملكية.

الفكرة الأساسية واحدة: تنقل المعاملات الصالحة النظام من حالة صالحة إلى الحالة التالية.

نموذج الحسابات مقابل آلة حالة UTXO

نموذج الحسابات ونموذج UTXO طريقتان مختلفتان لتصميم آلة حالة للبلوكشين.

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

تؤدي المعاملة من مستخدم إلى آخر عادةً إلى خفض رصيد المرسل وزيادة رصيد المستلم.

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

في نموذج UTXO، تحتوي الحالة على المخرجات غير المنفقة بدلًا من أرصدة الحسابات.

تستهلك المعاملة مخرجات قديمة وتنشئ مخرجات جديدة.

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

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

وقد يجعل نموذج UTXO بعض أشكال التحقق المتوازي وتتبع العملات أكثر طبيعية.

كلا النموذجين آلات حالة لأن كليهما يحدد حالات صالحة وانتقالات حالة صالحة.

العقود الذكية وآلات الحالة

العقود الذكية برامج تعمل داخل آلة حالة البلوكشين.

يمكن للعقد الذكي تخزين البيانات وفرض القواعد واستلام الأصول وإرسالها والتفاعل مع عقود أخرى.

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

بل تنفذ الشبكة كود العقد وتحدث الحالة وفقًا للنتيجة.

على سبيل المثال، قد يخفض عقد تحويل توكن رصيد توكنات مستخدم ويزيد رصيد مستخدم آخر داخل تخزين العقد.

وقد يحدّث عقد إقراض أرصدة الضمان والديون ومؤشرات الفائدة وحالات التصفية.

وقد يحدّث عقد منصة تداول لامركزية احتياطيات مجمع السيولة ومراكز المستخدمين.

كل هذه الإجراءات انتقالات حالة.

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

قد يؤدي خلل في قواعد انتقال حالة العقد إلى فقدان الأموال أو تعطل سلوك التطبيق.

آلة الحالة والإجماع

آلة الحالة ليست هي آلية الإجماع.

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

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

يحتاج البلوكشين إلى كليهما.

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

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

يختار الإجماع تدفق المدخلات المرتب.

وتنفذ آلة الحالة تدفق المدخلات هذا.

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

يساعد هذا التمييز المستخدمين على فهم سبب امتلاك البلوكشين قواعد للمدققين وقواعد للتنفيذ.

دالة انتقال الحالة

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

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

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

إذا كان الإدخال صالحًا، تنتج الدالة حالة جديدة صالحة.

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

قد تشمل دالة انتقال الحالة في Ethereum تنفيذ EVM ومحاسبة الغاز وتحديثات التخزين وسجلات الأحداث.

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

قد تحدد بلوكشين أخرى انتقالات الحالة عبر الوحدات النمطية أو pallets أو كائنات Move أو الموارد أو منطق خاص بالتطبيق.

دالة الانتقال هي قلب آلة الحالة.

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

تكرار آلة الحالة

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

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

هذا النموذج مفيد لأنه يوفر تحمل الأعطال.

إذا انقطعت عقدة واحدة، تظل العقد الأخرى تحتفظ بالحالة وتحدثها.

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

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

يمثل CometBFT مثالًا قويًا لهذه الفكرة، لأن وثائقه تصف صراحةً تكرار آلة الحالة BFT لآلات الحالة الحتمية محدودة الحالات.

تفصل العديد من تصميمات appchain والبلوكشين المعيارية بين الإجماع ومنطق التطبيق باستخدام هذه الفكرة.

ترتب طبقة الإجماع المعاملات، بينما تحدد آلة حالة التطبيق معنى تلك المعاملات.

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

آلات الحالة الخاصة بالتطبيقات

البلوكشين الخاص بتطبيق معين هو بلوكشين يُبنى لتطبيق أو حالة استخدام محددة.

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

قد تحدد سلسلة المدفوعات أرصدة وتحويلات بسيطة.

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

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

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

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

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

وقد يسهل أيضًا فهمها لأن قواعدها مركزة.

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

آلة الحالة والآلات الافتراضية

آلة البلوكشين الافتراضية هي بيئة التنفيذ التي تشغل الكود داخل آلة الحالة.

وتعد EVM المثال الأكثر شهرة.

تستخدم منظومات البلوكشين الأخرى آلات افتراضية أو بيئات تنفيذ مختلفة.

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

تستخدم آلة الحالة الآلة الافتراضية لمعالجة المعاملات القابلة للبرمجة.

على سبيل المثال، عندما تنفذ Ethereum استدعاء عقد ذكي، تشغل EVM البايت كود وتنتج تغيرات الحالة.

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

الآلة الافتراضية ليست البلوكشين بأكمله، لكنها جزء أساسي من طبقة التنفيذ.

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

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

آلة الحالة والغاز

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

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

الغاز جزء من آلة الحالة لأن تنفيذ المعاملات يستهلك موارد.

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

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

ويؤثر الغاز أيضًا في انتقالات الحالة، إذ قد تفشل المعاملة إذا نفد منها الغاز.

حتى عند فشل التنفيذ، قد تظل الرسوم مستحقة لأن العقد أنفقت موارد لمحاولة التنفيذ.

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

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

يبين الغاز أن آلات الحالة يجب أن تدير الصحة واستخدام الموارد معًا.

آلة الحالة وجذور الحالة

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

في Ethereum، يلتزم جذر الحالة بالحالة العالمية بعد تنفيذ المعاملات.

جذر الحالة ليس الحالة نفسها.

إنه التزام مدمج قائم على الهاش بالحالة.

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

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

تدعم جذور الحالة أيضًا إثباتات وجود قيم محددة في حالة ملتزم بها.

يهم ذلك العملاء الخفيفين والجسور والمدققين وأنظمة عبر السلاسل.

تحدث آلة الحالة البيانات، ويساعد جذر الحالة على إثبات ماهية تلك البيانات المحدثة.

وهكذا تربط البلوكشين نتائج التنفيذ بالتحقق التشفيري.

آلة الحالة والعقد

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

يوضح المقدمة التقنية لـ Ethereum أن العقد تخزن حالة EVM وتتواصل مع بعضها لنشر تغيرات الحالة.

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

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

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

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

يمكنهم حساب الحالة بأنفسهم من الكتل المقبولة.

لكن تشغيل عقدة يتطلب أجهزة ونطاقًا تردديًا وتخزينًا وصيانة.

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

ولهذا يؤثر تصميم آلة الحالة في اللامركزية وكذلك التنفيذ.

آلة الحالة والنهائية

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

قبل النهائية، قد تُدرج المعاملة في كتلة لكنها تظل معرضة لخطر إعادة التنظيم.

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

تحدد البلوكشين المختلفة النهائية بطرق مختلفة.

تتمتع بعض السلاسل بنهائية احتمالية، حيث تنمو الثقة مع إضافة مزيد من الكتل.

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

تعد النهائية مهمة لأن آلة الحالة قد تمتلك مؤقتًا سجلات متنافسة محتملة أثناء الانقسامات.

ويحسم الإجماع أي سجل يصبح قانونيًا.

لا يهتم المستخدمون عادةً بحدوث انتقال الحالة فحسب، بل أيضًا ببقائه مقبولًا.

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

آلة الحالة والانقسامات

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

إذا تضمّن سجلان معاملات مختلفة، فيمكن أن ينتجا حالات مختلفة.

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

قد تحدث الانقسامات المؤقتة طبيعيًا في الشبكات اللامركزية.

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

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

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

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

لهذا يجب تنسيق ترقيات البروتوكول بعناية.

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

آلة الحالة وأخطاء العقود الذكية

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

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

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

وقد يحدّث العقد الأرصدة بالترتيب الخاطئ.

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

وقد يسمح بإعادة الدخول أو أخطاء حسابية أو سلوك ترقية غير آمن.

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

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

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

لذلك تعد صحة الكود جزءًا من سلامة الحالة.

آلة الحالة وOracle

توفر Oracle بيانات خارجية لتطبيقات البلوكشين.

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

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

وقد يحتاج سوق تنبؤ إلى نتيجة حدث.

وقد يحتاج نظام أصول اصطناعية إلى مؤشر مرجعي.

ترسل Oracle البيانات التي تصبح إدخالًا لآلة الحالة.

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

يعني ذلك أن تصميم Oracle حاسم للتطبيقات التي تعتمد على معلومات العالم الحقيقي.

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

ولا يمكنها ضمان صحة البيانات خارج السلسلة ما لم يكن نظام Oracle موثوقًا وآمنًا.

آلة الحالة وتضخم الحالة

يحدث تضخم الحالة عندما تكبر حالة البلوكشين النشطة كثيرًا.

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

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

إذا قلّ عدد من يستطيعون تشغيل العقد، فقد تتضرر اللامركزية.

لهذا تفرض العديد من شبكات البلوكشين رسومًا أو ودائع على التخزين المستمر.

تضخم الحالة مشكلة لآلة الحالة لأن كل انتقال حالة قد يضيف بيانات أو يعدلها أو يزيلها.

ينبغي لآلة الحالة المصممة جيدًا أن تثبط نمو الحالة غير المفيد مع استمرار دعم التطبيقات المفيدة.

ترتبط رسوم الغاز وإيجار التخزين وانتهاء الحالة والتشذيب وتحسينات التزام الحالة بهذه المشكلة.

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

لا يتعلق التوسع بعدد المعاملات في الثانية فحسب، بل أيضًا بنمو الحالة المستدام.

آلة الحالة وشبكات Layer 2

تستخدم شبكات Layer 2 أيضًا آلات حالة.

فعلى سبيل المثال، يمتلك rollup حالته الخاصة التي تتغير مع تقديم المستخدمين للمعاملات.

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

ولا تنفذ الطبقة الأساسية بالضرورة كل معاملة Layer 2 مباشرةً.

بل تساعد في تسوية حالة Layer 2 أو التحقق منها وفق تصميم rollup.

يعني ذلك أن Layer 2 يمكن فهمها كآلة حالة أخرى متصلة بآلة حالة Layer 1.

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

يهم توفر البيانات وأنظمة الإثبات والجسور والـ sequencers وقواعد التسوية جميعًا.

لا يلغي توسيع Layer 2 آلات الحالة.

بل يضيف آلات حالة أكثر تخصصًا تعتمد على أمان الطبقة الأساسية بطرق مختلفة.

آلة الحالة والجسور

تربط الجسور آلات الحالة عبر السلاسل أو الطبقات.

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

وهذا صعب لأن لكل بلوكشين إجماعه وقواعد نهائيته ونموذج حالته ونظام إثباته الخاص.

قد يصبح الجسر الذي يسيء فهم الحالة غير آمن.

فعلى سبيل المثال، قد يقبل الجسر رسالة قبل نهائيتها.

وقد يعتمد على مجموعة مدققين ضعيفة.

وقد يفشل في التحقق من جذر الحالة أو الإثبات الصحيحين.

وقد يحتوي على أخطاء عقود ذكية في آلة الحالة المستقبِلة.

لذلك تعد الجسور من أكثر المواضع خطورة التي تتفاعل فيها آلات الحالة.

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

آلة الحالة والحوكمة

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

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

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

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

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

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

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

يجب تنفيذ الترقيات بعناية عبر برمجيات العملاء.

إذا اختلف العملاء حول قواعد الانتقال، فقد تنقسم الشبكة.

تحمي الحوكمة الجيدة استمرارية آلة الحالة المشتركة.

آلة الحالة والمحافظ

المحافظ هي واجهات مستخدم للتفاعل مع آلات حالة البلوكشين.

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

وعندما تطلب المحفظة من المستخدم توقيع معاملة، فإنها تعد إدخالًا لآلة الحالة.

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

لهذا تكون مطالبات المحفظة مهمة جدًا.

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

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

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

لذلك تتعلق سلامة المحفظة بمساعدة المستخدمين على إنشاء مدخلات آمنة لآلة الحالة.

تجعل المحفظة الجيدة انتقالات الحالة مفهومة قبل وقوعها.

آلة الحالة وأرصدة التوكنات

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

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

عند حدوث تحويل توكن، يحدث العقد تعيين الأرصدة الداخلي هذا.

قد يرى المستخدم النتيجة كتغير بسيط في الرصيد داخل المحفظة.

لكنها في الخلفية انتقال حالة على مستوى العقد.

يعني ذلك أن أرصدة التوكنات ليست دائمًا من نوع الحالة نفسه لأرصدة العملات الأصلية.

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

وقد يكون رصيد التوكن جزءًا من حالة تخزين العقد.

يهم هذا التمييز للإثباتات والفهرسة وعرض المحفظة ومخاطر العقود الذكية.

إذا كان لعقد التوكن منطق غير آمن، فقد تتصرف آلة حالة التوكن بصورة غير متوقعة.

آلة الحالة وNFT

تعتمد توكنات NFT أيضًا على آلات الحالة.

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

عند نقل NFT، يحدث العقد العنوان الذي يمتلك معرف التوكن.

عند سك NFT، ينشئ العقد سجل ملكية جديدًا.

وعند حرق NFT، يزيل العقد التوكن أو يضع علامة عليه وفق قواعده.

قد تُخزن البيانات الوصفية على السلسلة أو يُشار إليها عبر أنظمة خارجية.

تقرر آلة الحالة ما إذا كان النقل صالحًا، ومن يمكنه الموافقة عليه، وكيف تتغير الملكية.

لهذا يعتمد أمان NFT على منطق العقد وكذلك حفظ المحفظة.

ليس NFT مجرد صورة أو مقتنى.

إنه أيضًا سجل حالة تحكمه قواعد العقود الذكية.

يساعد فهم آلات الحالة المستخدمين على فهم معنى ملكية NFT فعليًا على السلسلة.

فوائد آلات الحالة في الكريبتو

أولى فوائد آلة حالة البلوكشين هي التحقق المشترك.

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

الفائدة الثانية هي التنفيذ الحتمي.

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

الفائدة الثالثة هي قابلية البرمجة.

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

الفائدة الرابعة هي الشفافية.

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

الفائدة الخامسة هي تحمل الأعطال.

يمكن لعقد كثيرة تكرار آلة الحالة، ما يقلل الاعتماد على خادم واحد.

الفائدة السادسة هي قابلية التركيب.

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

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

قيود آلات الحالة في الكريبتو

القيد الأول هو التعقيد.

غالبًا لا يفهم المستخدمون انتقالات الحالة التي يوقعون عليها.

القيد الثاني هو نمو الحالة.

قد تصبح الحالة المستمرة مكلفة على العقد من حيث التخزين والتحقق.

القيد الثالث هو تكلفة التنفيذ.

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

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

قد يؤدي تغيير قواعد الانتقال إلى أخطاء أو انقسامات إذا لم يُدار بعناية.

القيد الخامس هو مخاطر التطبيق.

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

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

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

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

مفاهيم خاطئة شائعة حول آلات الحالة

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

البلوكشين آلة حالة أيضًا لأنه يحدد قواعد لتغيرات الحالة الصالحة.

ومن المفاهيم الخاطئة الأخرى أن الإجماع والتنفيذ هما الشيء نفسه.

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

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

تنفذ العقد العقود الذكية وفق قواعد آلة الحالة الحتمية للبلوكشين.

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

يسجل سجل المعاملات المدخلات، بينما تسجل الحالة النتيجة الحالية بعد معالجة تلك المدخلات.

والمفهوم الخاطئ الخامس هو أن التنفيذ الحتمي يضمن نتائج جيدة.

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

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

صمم العقود الذكية كآلات حالة صريحة ذات حالات وانتقالات وشروط فشل واضحة.

اختبر كل انتقال حالة في الظروف العادية والعدائية.

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

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

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

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

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

وثق تغير الحالة الذي تحدثه كل دالة.

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

تعامل مع منطق آلة الحالة باعتباره كودًا حاسمًا للأمان.

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

اقرأ مطالبات المحفظة بعناية قبل توقيع المعاملات.

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

تحقق من الصلاحيات التي تمنحها موافقة التوكن لعقد ما.

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

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

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

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

تذكر أن حالة البلوكشين قد تكون شفافة، لكن الشفافية لا تضمن الأمان.

توخ الحذر مع الجسور لأنها تربط آلات حالة مختلفة ذات افتراضات مختلفة.

استخدم أدوات الأمان وألغِ الموافقات غير الضرورية عند الاقتضاء.

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

ماذا تعني آلة الحالة في الكريبتو؟

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

لماذا يسمى البلوكشين آلة حالة؟

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

ما هي حالة البلوكشين؟

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

ما هو انتقال الحالة؟

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

هل Ethereum آلة حالة؟

نعم، يمكن فهم Ethereum كآلة حالة قائمة على المعاملات، حيث تحدّث المعاملات واستدعاءات العقود الذكية الحالة العالمية.

هل Bitcoin آلة حالة؟

نعم، يمكن فهم Bitcoin كآلة حالة قائمة على UTXO، حيث تستهلك المعاملات الصالحة المخرجات غير المنفقة وتنشئ مخرجات غير منفقة جديدة.

ما هو تكرار آلة الحالة؟

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

ما الفرق بين الإجماع وآلة الحالة؟

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

لماذا يجب أن تكون آلات حالة البلوكشين حتمية؟

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

كيف ترتبط العقود الذكية بآلات الحالة؟

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

الخلاصة

آلة الحالة إحدى أهم الأفكار الكامنة وراء شبكات العملات المشفرة.

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

تستخدم Bitcoin آلة حالة قائمة على UTXO، حيث تنفق المعاملات الصالحة المخرجات القديمة وتنشئ مخرجات جديدة.

تستخدم Ethereum آلة حالة قائمة على الحسابات، حيث تُحدّث الحسابات والأرصدة وكود العقود والتخزين عبر المعاملات وتنفيذ EVM.

تعمل آليات الإجماع وآلات الحالة معًا، لكن لكل منهما وظيفة مختلفة.

يرتب الإجماع المدخلات، بينما تنفذ آلة الحالة القواعد وتنتج الحالة الجديدة.

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

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

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

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

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

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

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