لماذا لا يستطيع Web3 القراءة — ForkLog

# لماذا لا تجيد Web3 القراءة

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

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

كلما كانت أسرع، طال الوقت أكثر

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

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

• أرصدة العناوين؛
• سجل المعاملات؛
• حالة العقود الذكية؛
• الأحداث والسجلات (logs)؛
• التحليلات السوقية؛
• بيانات لإدارة المخاطر؛
• الرسائل بين الشبكات.

كلما كانت الشبكة تعمل بسرعة أكبر، زادت كمية هذه البيانات التي يتعين معالجتها

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

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

تم ترتيب العملية على النحو التالي:

1. جمع البيانات: تقوم برامج خاصة بـ«قراءة» البلوكتشين بشكل مستمر مع ظهور كتل جديدة.
2. الفهرسة (الهيكلة): تقوم هذه البرامج بتحليل تلك البيانات وترتيبها داخل قواعد بيانات تقليدية سريعة جدًا (مثل PostgreSQL أو ClickHouse). هناك تُهيكل البيانات بصيغة مناسبة: «العنوان — قائمة جميع توكناته».
3. إجابة فورية: تحصل المحفظة على إجابة جاهزة ومفلترة من الكاش خلال ملّية من الثانية.

وبشكل عملي، تعمل أغلب تطبيقات Web3 الشهيرة عبر مستوى إضافي لمعالجة المعلومات. تخيل أن البلوكتشين يعالج 50 000 عملية في الثانية، وفي الوقت نفسه ترسل ملايين المحافظ طلبات RPC لتحديث الشاشات. لا تستطيع خوادم مزودي الخدمة التعامل مع هذا الضغط. إن قراءة البيانات وفهرستها وترتيبها للمستخدم تعد مهمة حسابية بالغة التعقيد. غالبًا ما تتأخر الفهارس وخدمات الوصول إلى البيانات عن الحالة الفعلية للشبكة بعدة كتل، لأن معالجة البيانات وتهيئتها وتسليمها تتطلب وقتًا إضافيًا. والأمر ليس مجرد «بنية تحتية قديمة» — وإن كان ذلك موجودًا بالطبع. بل هو صراع عميق في معماريّة Web2 وWeb3

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

يختلف البلوكتشين عن ذلك؛ فهو غير مهيأ للأجهزة لذلك. حتى وقت قريب، كان العائق الرئيسي للسرعة هو الرياضيات والتشفير. كان يتعين إجبار آلاف أجهزة الكمبيوتر في جميع أنحاء العالم على التوصل بسرعة إلى اتفاق (إجماع) بأن المعاملة صحيحة. وقد عالج المطورون هذه المشكلة عبر «تعليم» الآلات تنفيذ المهام بالتوازي وفصل الإجماع عن التنفيذ. على سبيل المثال، تدعم Solana وMonad وAptos تنفيذًا متوازيًا للمعاملات المستقلة، على عكس نموذج Ethereum التسلسلي التقليدي. وفي الوقت نفسه، يكون فصل ترتيب المعاملات عن تنفيذها في Monad واضحًا بشكل خاص، بينما في Solana وAptos يتم تطبيق التوازي عبر بنية runtime وإدارة التعارضات بناءً على الحالة.

في المحصلة، يمكن الموافقة على عشرات آلاف المعاملات في الثانية (TPS). لكن هنا تكمن المفارقة.

تاريخيًا، كان البلوكتشين يؤدي أربع وظائف في آن واحد:

• تنفيذ المعاملات؛
• الإجماع (consensus)؛
• تخزين البيانات؛
• توفير الوصول إلى البيانات.

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

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

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

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

تصل سرعات Web3 إلى فيزياء مبتذلة (وليست وحدها)

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

لنفترض شبكة تعمل بـ 100 000 TPS. لن يكون المطلوب فقط تسجيل المعاملة، بل أيضًا:

• حفظ الحالة؛
• تحديث الفهارس؛
• الرد على طلبات المحافظ؛
• تقديم الخدمة للروبوتات (bots)؛
• تقديم الخدمة للمحللين (analytics)؛
• تقديم الخدمة لمحركات البحث؛
• تقديم الخدمة لوكلاء الذكاء الاصطناعي (AI-агентов).

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

إن التطور المتوازي لبعض التقنيات المشاركة في هذه المنظومة يدفع إلى حل هذه المشكلة الآن. بالنسبة للإنسان، قد تكون الإطالة بالثواني أو حتى الدقائق مقبولة تمامًا. أما بالنسبة لوكلاء الذكاء الاصطناعي وأنظمة التداول والخدمات الذاتية — فذلك غير مقبول. إذا كانت آلة تتخذ قراراتها بناءً على بيانات on-chain، فإن المعلومات المتقادمة تعني خطأ، أو فقدان فرصة، أو خسارة مالية مباشرة.

في الوقت نفسه، تشير Ethereum Foundation في وثائقها المحدثة لعام 2026 إلى أن العقد الأرشيفية تتطلب من 3 إلى 12 ТБ من مساحة القرص، وقد تستغرق المزامنة الأولية حتى شهرًا حتى على أجهزة قوية بما يكفي. وتتمثل القيود في سرعات SSD وحجم الذاكرة وأداء المعالج.

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

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

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

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

كيف رد السوق

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

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

• execution layer — مستوى التنفيذ (أو القيام بالتنفيذ)؛
• settlement layer — مستوى التسويات/الاحتساب (الاستيطان)؛
• consensus layer — مستوى الإجماع؛
• data availability layer — مستوى إتاحة البيانات.

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

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

قبل بضع سنوات، كان RPC يُنظر إليه كتفصيل تقني. اليوم أصبح أحد أهم عناصر البنية التحتية للعملات المشفرة. في مايو 2026، أصدرت Triton One بالتعاون مع Solana Foundation إعلانًا محدثًا لـ RPC 2.0 — وهي نهج جديد لبناء بنية قراءة البيانات في الشبكة

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

بهذه الطريقة، يحاول Triton وSolana إزالة سلسلة من القيود النظامية: بنية RPC أحادية مكلفة وغير فعالة، ومجموعة محدودة من طلبات JSON-RPC القياسية، واعتماد المطورين على حلولهم الخاصة أو حلول مملوكة للعمل مع البيانات. في النموذج الجديد، يتم توسيع القراءة بشكل منفصل عن الإجماع، ويصبح الوصول إلى التاريخ أسرع عبر استخدام مستودعات عمودية (columnar) وبيانات مُفرزّة مسبقًا.

يعتمد المشروع على الأدوات التي تم إدخالها في المنظومة بالفعل — بما في ذلك تدفق نقل البيانات من المُدققين (Geyser, Yellowstone gRPC) وحلول معالجة التاريخ. تُوزع كل البنية التحتية بمصدر مفتوح (open source)، ويجري تنسيق تطورها بمشاركة Solana Foundation.

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

هل تحل النمطية المشكلة؟

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

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

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

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