تجزئة الحالة

ما هي تجزئة الحالة في الكريبتو؟

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

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

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

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

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

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

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

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

لكن تجزئة الحالة صعبة لأن تطبيقات البلوكشين تحتاج غالباً إلى التفاعل عبر الشظايا.

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

لماذا تُعد تجزئة الحالة مهمة؟

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

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

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

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

تحاول تجزئة الحالة حل هذه المشكلة بالسماح للشبكة بالتوسع أفقياً.

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

تصف صفحة أوراق NEAR الرسمية Nightshade بأنه تصميم تجزئة تُقسَّم فيه البلوكشين إلى سلاسل أو شظايا متوازية متعددة للتوسع أفقياً مع الطلب.

وهذا النهج جذاب لأنه قد يزيد السعة دون مطالبة كل عقدة بمعالجة كل معاملة.

لذلك، لا تمثل تجزئة الحالة مجرد ترقية للسرعة.

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

كيف تعمل تجزئة الحالة؟

تقسم البلوكشين التي تستخدم تجزئة الحالة الحالة العالمية إلى شظايا متعددة.

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

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

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

أما المعاملات التي تؤثر في عدة شظايا فتتطلب اتصالاً بين الشظايا.

وقد يساعد منسق، أو Beacon Chain، أو سلسلة رئيسية، أو طبقة إجماع عالمية، أو بروتوكول اتصال بين الشظايا في الحفاظ على اتساق النظام.

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

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

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

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

تجزئة الحالة مقابل تجزئة المعاملات

تقسم تجزئة المعاملات معالجة المعاملات بين مجموعات مختلفة.

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

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

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

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

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

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

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

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

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

تجزئة الحالة مقابل تجزئة البيانات

تختلف تجزئة الحالة عن تجزئة البيانات.

فتجزئة الحالة تقسم حالة التنفيذ النشطة للبلوكشين.

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

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

تنص وثائق Ethereum الخاصة بـ danksharding على أن neither danksharding nor proto-danksharding يتبعان نموذج التجزئة التقليدي الذي يقسم البلوكشين إلى أجزاء متعددة.

وتوضح هذه الوثائق أن danksharding مصمم حول كتل بيانات كبيرة للـ rollups بدلاً من تقسيم Ethereum Mainnet إلى شظايا تنفيذ تقليدية.

وهذا يعني أنه لا ينبغي للمستخدمين افتراض أن كل ذكر لتجزئة Ethereum يعني تجزئة الحالة.

تضمنت النقاشات القديمة لخارطة طريق Ethereum أفكاراً حول تجزئة التنفيذ والحالة.

أما توسع Ethereum الحديث فيستخدم rollups وblobs وأبحاث أخذ عينات توافر البيانات ومفاهيم danksharding بدلاً من نموذج التنفيذ التقليدي متعدد الشظايا.

تُعد كل من تجزئة الحالة وتجزئة البيانات فكرتين للتوسع، لكنهما تحلان اختناقات مختلفة.

تجزئة الحالة مقابل Rollups

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

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

وقد يكون من الأسهل إضافة Rollups إلى سلسلة قائمة، لأنها لا تتطلب من الطبقة الأساسية تقسيم حالة تنفيذها.

أما تجزئة الحالة فهي تغيير أعمق في بنية الطبقة الأساسية.

ولا تزال Rollups تحتاج إلى توافر البيانات والتسوية والتحقق من الإثباتات من السلسلة الأساسية.

وتحتاج السلاسل ذات تجزئة الحالة إلى تخصيص الشظايا والاتصال بين الشظايا وأمن الشظايا والنهائية المشتركة.

توضح وثائق Ethereum الخاصة بتوافر البيانات أن توافر البيانات مهم لأن Rollups تحتاج إلى أن تكون بيانات المعاملات متاحة كي يتمكن الآخرون من التحقق من حالة Rollup أو إعادة بنائها.

ولهذا تدعم خارطة طريق Ethereum الحالية توسع Rollups باستخدام بيانات blobs بدلاً من تجزئة الحالة التقليدية.

ولا يزال من الممكن أن تستخدم تصاميم Layer 1 أخرى تجزئة الحالة.

والفرق الأساسي هو أن Rollups تفصل التنفيذ إلى أنظمة Layer 2، بينما تقسم تجزئة الحالة التنفيذ والحالة داخل Layer 1 نفسها.

لماذا تجزئة الحالة صعبة؟

تُعد تجزئة الحالة صعبة لأن سلاسل البلوكشين يجب أن تظل آمنة ومتسقة ولامركزية أثناء تقسيم العمل.

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

وإذا لم يُخصص المدققون عشوائياً وبصورة آمنة، فقد يركز المهاجمون القوة في شظية واحدة.

وإذا كانت الرسائل عبر الشظايا بطيئة، فقد تبدو التطبيقات مجزأة.

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

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

وإذا احتاج المستخدمون إلى فهم الشظايا يدوياً، تسوء تجربة المستخدم.

تحدد الدراسة الأكاديمية Building Blocks of Sharding Blockchain Systems مكونات التجزئة الرئيسية، مثل اختيار العقد والعشوائية وتخصيص العقد والإجماع داخل الشظية ومعالجة المعاملات عبر الشظايا وإعادة تهيئة الشظايا وآليات الحوافز.

وهذا يبين أن تجزئة الحالة ليست ميزة واحدة.

إنها بنية نظام كاملة تضم العديد من الأجزاء المتحركة.

الشظايا

الشظية هي قسم واحد من حالة البلوكشين وبيئة التنفيذ.

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

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

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

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

وهذه المعالجة المتوازية هي فائدة التوسع الرئيسية.

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

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

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

لذلك، تمثل الشظية وحدة للتوسع وتحدياً للتنسيق في آن واحد.

مدققو الشظايا

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

في بعض التصاميم، يتناوب المدققون بين الشظايا لتقليل خطر الاستيلاء طويل الأمد على الشظية.

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

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

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

لذلك تعد العشوائية مهمة في كثير من أنظمة التجزئة.

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

ولا تلغي تجزئة الحالة الحاجة إلى الإجماع.

بل تنشئ مسؤوليات إجماع أصغر عديدة يجب أن تظل مرتبطة بأمن الشبكة بأكملها.

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

المعاملات عبر الشظايا

المعاملة عبر الشظايا هي معاملة تؤثر في الحالة في أكثر من شظية واحدة.

وتُعد المعاملات عبر الشظايا من أصعب جوانب تجزئة الحالة.

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

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

وقد يكون استدعاء عقد ذكي يشمل شظايا متعددة أكثر تعقيداً.

ويجب أن يضمن النظام اتفاق الشظية المصدر والشظية الوجهة على ما حدث.

كما يجب أن يضمن عدم إنفاق الأموال مرتين، وأن آثار العقد تقع بالترتيب الصحيح.

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

وتستكشف أبحاث أخرى التنفيذ المتزامن عبر الشظايا أو الالتزام على مرحلتين أو التنسيق القائم على الإثباتات.

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

التنفيذ غير المتزامن

يعني التنفيذ غير المتزامن أن الإجراءات عبر الشظايا لا تحدث فوراً ضمن خطوة عالمية واحدة.

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

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

لكن التنفيذ غير المتزامن يغير طريقة بناء المطورين للتطبيقات.

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

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

وقد يجعل ذلك DeFi والألعاب والأسواق والتطبيقات القابلة للتركيب عبر الشظايا أكثر صعوبة.

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

والمقايضة هنا هي السرعة والتوازي مقابل بساطة التطبيقات المتزامنة.

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

قابلية التركيب الذرية

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

وإذا فشل أي جزء، تفشل المعاملة كاملة.

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

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

قد تحتاج صفقة DeFi إلى التفاعل مع بروتوكول إقراض ومجمع سيولة وOracle وخزينة في معاملة واحدة.

وإذا كانت هذه العقود على شظايا مختلفة، فقد يكون التنفيذ المتزامن صعباً أو مكلفاً.

وهذا أحد أسباب أن تجزئة الحالة تخلق تحديات تصميمية لـ DeFi.

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

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

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

تجزئة الحالة والعقود الذكية

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

يمكن لنظام دفع بسيط تخصيص الحسابات للشظايا وإرسال الرسائل بينها.

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

وإذا كان بإمكان كل عقد استدعاء كل عقد آخر بصورة متزامنة، فقد تفقد الشبكة جزءاً كبيراً من فائدة التجزئة.

وإذا كانت الاستدعاءات عبر الشظايا غير متزامنة، يحتاج المطورون إلى نموذج برمجة مختلف.

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

تُعد تجزئة الحالة أسهل لتحويلات الحسابات البسيطة منها لأنظمة DeFi عالية قابلية التركيب.

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

فمثلاً، قد تبقي بيئة ألعاب أو بيئة شبيهة بـ appchain معظم النشاط داخل شظية واحدة.

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

تجزئة الحالة وNEAR

تُعد NEAR واحدة من أشهر أمثلة البلوكشين المصممة حول التجزئة.

تنص وثائق NEAR الرسمية على أن تجزئة Nightshade تتيح توسعاً خطياً في معدل المعالجة مع زيادة عدد المدققين.

Nightshade هو تصميم التجزئة الخاص بـ NEAR.

وتصف صفحة أوراق NEAR الرسمية Nightshade بأنه تصميم تُقسَّم فيه الحالة والمعالجة بين الشظايا في صورته المحدثة.

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

كما عملت NEAR على التحقق عديم الحالة، الذي يغير طريقة مشاركة المدققين في التحقق من الشظايا.

يشير منشور إطلاق NEAR Nightshade 2.0 الرسمي إلى أن Nightshade 2.0 أدخل التحقق عديم الحالة إلى NEAR Mainnet في أغسطس 2024.

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

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

تجزئة الحالة وEthereum

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

لكن خارطة طريق Ethereum الحالية لا تركز على تجزئة التنفيذ أو الحالة التقليدية لـ Mainnet.

وتنص صفحة Ethereum الرسمية الخاصة بـ danksharding على أن proto-danksharding وdanksharding لا يتبعان نموذج التجزئة التقليدي.

وبدلاً من ذلك، تركز Ethereum الآن على توسيع Rollups عبر توفير توافر بيانات أقل تكلفة بواسطة blobs وdanksharding المستقبلي.

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

وقد تكون هذه الأوصاف القديمة مضللة إذا عُرضت كحقائق عن خارطة الطريق الحالية.

واتجاه توسع Ethereum الحالي يتمحور حول Rollups.

وهذا يعني أن أنظمة Layer 2 تنفذ معظم العمليات، بينما توفر Ethereum التسوية والأمن وتحسينات توافر البيانات.

وتظل تجزئة الحالة مفهوماً مهماً في البلوكشين، لكن لا ينبغي وصفها بأنها خطة تنفيذ Ethereum الحالية لـ Mainnet.

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

تجزئة الحالة والتحقق عديم الحالة

يعني التحقق عديم الحالة أن المدقق يستطيع التحقق من تنفيذ كتلة أو شظية دون تخزين الحالة ذات الصلة كاملةً محلياً.

وبدلاً من ذلك، يتلقى المدقق شهوداً أو إثباتات تتضمن بيانات الحالة اللازمة للتحقق.

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

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

ويُعد Nightshade 2.0 من NEAR مثالاً عملياً على إضافة التحقق عديم الحالة إلى بنية تجزئة.

كما استكشفت أبحاث Ethereum العملاء عديمي الحالة والشهود الأصغر عبر تغييرات التزامات الحالة.

ولا يتطابق التحقق عديم الحالة مع تجزئة الحالة.

فتجزئة الحالة تقسم الحالة بين الشظايا.

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

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

تجزئة الحالة وتوافر البيانات

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

ولا يمكن أن تكون تجزئة الحالة آمنة إذا لم يتمكن المدققون من الوصول إلى البيانات اللازمة للتحقق من كتل الشظايا.

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

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

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

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

وينطبق هذا المفهوم على نطاق واسع على أنظمة التوسع، بما فيها Rollups والسلاسل المجزأة.

وتزيد تجزئة الحالة من أهمية توافر البيانات لأن كل شظية قد تنتج بيانات تحتاج إليها أجزاء أخرى من الشبكة للثقة بها.

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

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

تجزئة الحالة والأمن

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

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

ويُسمى هذا أحياناً مشكلة الاستيلاء على شظية واحدة.

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

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

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

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

وتحتاج المعاملات عبر الشظايا إلى أنظمة إثبات تمنع شظية من الكذب على شظية أخرى.

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

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

تجزئة الحالة واللامركزية

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

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

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

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

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

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

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

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

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

ولا تساعد تجزئة الحالة إلا إذا ظل النظام الكامل مفتوحاً وقابلاً للتحقق.

تجزئة الحالة وتجربة المستخدم

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

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

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

وينبغي للتطبيق اللامركزي (dApp) أن يوضح التأخيرات أو الخطوات عبر الشظايا بوضوح عند حدوثها.

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

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

وقد تتطلب تفاعلات العقود الذكية عبر الشظايا تأكيدات أكثر أو عمليات استدعاء راجع غير متزامنة.

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

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

وتبدو أفضل الأنظمة المجزأة كسلسلة واحدة رغم عملها في الأساس كبيئات تنفيذ متوازية عديدة.

تجزئة الحالة والمطورون

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

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

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

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

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

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

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

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

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

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

تجزئة الحالة وDeFi

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

وقد تعتمد المبادلة على مجمع سيولة.

وقد تعتمد التصفية على Oracle وسوق إقراض ورصيد ضمانات وسجل دين.

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

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

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

وقد تحتاج أنظمة DeFi ذات تجزئة الحالة إلى توجيه السيولة أو المراسلة عبر الشظايا أو مجمعات سيولة خاصة بالشظايا أو تجميع التطبيقات.

وقد تختار بعض التطبيقات إبقاء جميع العقود الأساسية على شظية واحدة للبساطة.

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

تستطيع تجزئة الحالة توسيع معدل المعالجة الإجمالي، لكن على مطوري DeFi إدارة خطر التجزؤ بعناية.

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

تجزئة الحالة وNFTs

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

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

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

لكن NFT تخلق أيضاً تحديات عبر الشظايا.

فقد تحتاج NFT على شظية إلى البيع لمشترٍ على شظية أخرى.

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

وقد تحتاج المحفظة إلى عرض أرصدة NFT عبر شظايا عديدة.

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

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

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

تجزئة الحالة والجسور

ترتبط تجزئة الحالة بالجسور لأن الاتصال عبر الشظايا يشبه الاتصال عبر السلاسل من بعض الجوانب.

إذ يجب أن تنتقل رسالة من بيئة حالة إلى بيئة حالة أخرى.

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

ويجب أن تمنع البيئة المرسلة الاستخدام المزدوج أو إعادة التشغيل.

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

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

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

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

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

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

تجزئة الحالة وإعادة التجزئة

إعادة التجزئة هي عملية تغيير بنية الشظايا بمرور الوقت.

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

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

وتحاول إعادة التجزئة الديناميكية ضبط حدود الشظايا أو عددها وفقاً للطلب.

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

ويجب أن يكون نقل الحالة بين الشظايا آمناً ومتسقاً.

ويجب أن تواصل التطبيقات عملها مع تغير تخصيصات الشظايا.

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

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

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

فوائد تجزئة الحالة

أولى فوائد تجزئة الحالة هي زيادة معدل المعالجة.

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

والفائدة الثانية هي قابلية توسيع التخزين بصورة أفضل.

فقد لا تحتاج العقد إلى تخزين كل جزء من الحالة العالمية.

والفائدة الثالثة هي تحسن التوسع الأفقي.

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

والفائدة الرابعة هي تقليل الازدحام للتطبيقات التي تستطيع العمل غالباً ضمن شظية واحدة.

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

والفائدة السادسة هي تخصص أفضل، إذ قد تخدم الشظايا المختلفة مجموعات تطبيقات أو أعباء عمل مختلفة بحسب التصميم.

وهذه الفوائد هي سبب بقاء تجزئة الحالة مفهوماً مهماً للتوسع.

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

مخاطر وقيود تجزئة الحالة

الخطر الأول هو التعقيد عبر الشظايا.

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

والخطر الثاني هو تجزؤ الأمن.

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

والخطر الثالث هو تجزؤ السيولة.

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

والخطر الرابع هو ضعف قابلية التركيب الذرية.

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

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

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

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

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

والخطر السابع هو تفاوت الحمل.

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

تجزئة الحالة قوية، لكنها ليست حلاً مجانياً للتوسع.

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

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

في الواقع، تجزئة الحالة بنية معقدة تقسم مسؤوليات الحالة والتنفيذ والتحقق والاتصال.

ومفهوم خاطئ آخر هو أن تجزئة الحالة هي نفسها Rollups.

تنقل Rollups التنفيذ إلى أنظمة Layer 2، بينما تقسم تجزئة الحالة حالة الطبقة الأساسية وتنفيذها.

والمفهوم الخاطئ الثالث هو أن خارطة طريق Ethereum الحالية هي تجزئة حالة تقليدية.

تركز خارطة طريق Ethereum الحالية على Rollups وblobs وتوافر البيانات بأسلوب danksharding بدلاً من سلاسل شظايا حالة تنفيذ تقليدية.

والمفهوم الخاطئ الرابع هو أن تجزئة الحالة تحافظ تلقائياً على قابلية التركيب.

فقابلية التركيب عبر الشظايا من أصعب أجزاء التصميم.

والمفهوم الخاطئ الخامس هو أن السلسلة المجزأة مجرد سلاسل منفصلة كثيرة.

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

كيفية تقييم بلوكشين تستخدم تجزئة الحالة

ابدأ بالتحقق مما إذا كانت السلسلة تجزئ الحالة فعلياً أم تجزئ البيانات أو المعاملات فقط.

ثم تحقق من كيفية تخصيص المدققين للشظايا.

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

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

وراجع ما إذا كان التنفيذ عبر الشظايا متزامناً أم غير متزامن.

وتحقق مما إذا كانت التطبيقات تستطيع الحفاظ على قابلية التركيب الذرية عبر الشظايا.

وراجع كيفية تعامل البروتوكول مع توافر البيانات لكتل الشظايا.

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

وراجع تجربة المستخدم للتحويلات عبر الشظايا.

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

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

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

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

استخدم محافظ تتعامل تلقائياً مع توجيه الشظايا عندما يكون ذلك ممكناً.

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

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

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

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

لا تفترض أن المعاملة نهائية على جميع الشظايا إلى أن يؤكدها البروتوكول أو المحفظة.

راجع وثائق التطبيق عند استخدام DeFi عبر الشظايا أو أسواق NFT.

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

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

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

صمم التطبيقات مع مراعاة موقع الشظية والسلوك عبر الشظايا.

تجنب الاستدعاءات غير الضرورية عبر الشظايا عندما يكون التصميم داخل الشظية ممكناً.

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

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

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

راقب تجزؤ السيولة إذا كان التطبيق يعتمد على أسواق التوكنات.

اشرح التأخيرات عبر الشظايا بوضوح في واجهات المستخدم.

استخدم SDKs الرسمية ووثائق البروتوكول لتمرير الرسائل وتوجيه الشظايا.

خطط لإعادة التجزئة إذا كانت الشبكة تدعم تغييرات ديناميكية في الشظايا.

تعامل مع التنفيذ عبر الشظايا باعتباره جزءاً حساساً أمنياً من تصميم التطبيق.

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

ماذا تعني تجزئة الحالة؟

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

ما هي الشظية؟

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

لماذا تستخدم سلاسل البلوكشين تجزئة الحالة؟

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

هل تجزئة الحالة هي نفسها تجزئة البيانات؟

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

هل تجزئة الحالة هي نفسها Rollups؟

لا، تنفذ Rollups المعاملات خارج الطبقة الأساسية، بينما تقسم تجزئة الحالة حالة الطبقة الأساسية وتنفيذها.

هل تستخدم Ethereum حالياً تجزئة الحالة؟

لا، تركز خارطة طريق Ethereum الحالية على Rollups وblobs وتوافر البيانات بأسلوب danksharding بدلاً من تجزئة التنفيذ أو الحالة التقليدية.

أي بلوكشين معروفة بتجزئة الحالة؟

تشتهر NEAR على نطاق واسع بتصميم Nightshade للتجزئة، الذي يقسم الحالة والمعالجة بين الشظايا.

ما هي المعاملات عبر الشظايا؟

المعاملات عبر الشظايا هي معاملات تؤثر في الحالة في أكثر من شظية وتتطلب اتصالاً بين الشظايا.

لماذا تُعد تجزئة الحالة صعبة بالنسبة إلى DeFi؟

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

هل تجعل تجزئة الحالة البلوكشين خالية من المخاطر؟

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

الخلاصة

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

وهدفها الرئيسي هو زيادة معدل المعالجة وخفض العبء على المدققين أو العقد الفردية.

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

كما تختلف عن Rollups لأنها تغير بنية الطبقة الأساسية بدلاً من نقل التنفيذ إلى بيئة Layer 2 منفصلة.

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

ويمثل تصميم Nightshade من NEAR مثالاً قائماً مهماً لتحول أبحاث التجزئة إلى بنية تحتية إنتاجية.

وتكتسب Ethereum أهمية تاريخية، لكن خارطة طريقها الحالية تستخدم توسعاً يتمحور حول Rollups وتوافر البيانات بأسلوب danksharding بدلاً من تجزئة الحالة التقليدية.

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

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

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

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

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