ازدادت مشاكل تطبيق البلوكتشين مع توسّع استخداماتها، ومن أهمها أداء المعاملات داخل الشبكة. فإذا أردنا أن تتحول شبكة البلوكتشين من تقنية يستخدمها عدد محدود من الأشخاص إلى بنية تحتية تتحمل تشغيل تطبيقات يستخدمها ملايين الأشخاص، فستحتاج الشبكة إلى التعامل مع عدد كبير من المعاملات وبسرعة عالية.
من هنا بدأت شبكة بلوكتشين Solana، من خلال طرح سؤال مختلف عن أي شبكة أخرى:
هذه هي الفكرة التي تدور حولها الورقة البيضاء لشبكة Solana، التي كتبها Anatoly Yakovenko. ولتحقيق هذا الهدف، ركّزت الورقة على مشكلة قد لا تبدو مرتبطة بالسرعة للوهلة الأولى: الوقت.
ما هي مشكلة الوقت؟
تخيل أن لدينا آلاف الأجهزة الموزعة حول العالم، وصلت معاملة إلى جهاز في الرياض، وفي الوقت نفسه تقريبًا وصلت معاملة أخرى إلى جهاز في لندن، ثم وصلت معاملة ثالثة إلى جهاز في نيويورك. السؤال الجوهري: أي من هذه المعاملات يُنفَّذ أولًا؟
في النظام المركزي، يمكن أن تكون هناك جهة واحدة تمتلك ساعة واحدة وسجلًا مركزيًا يعتمد عليه الجميع. أما البلوكتشين فنظام موزع، حيث يمتلك كل جهاز ساعته الخاصة، وقد تصل الرسائل إلى أجهزة مختلفة في أوقات مختلفة. توضح Solana أن معظم شبكات البلوكتشين إما لا تعتمد على الوقت، أو تعتمد عليه بصورة ضعيفة، وكل جهاز يعتمد عادة على ساعته المحلية دون معرفة دقيقة بساعات بقية المشاركين. وهنا تظهر المشكلة: إذا لم نتفق على الوقت، فقد نحتاج مزيدًا من التواصل بين الأجهزة حتى نتفق على ما حدث وبأي ترتيب — وهذا التواصل يحتاج وقتًا.
المشكلة ليست في تنفيذ المعاملة
قد يتبادر إلى الذهن أن المشكلة هي: كم معاملة يستطيع جهاز الكمبيوتر تنفيذها في الثانية؟ لكن Solana تنظر إلى المشكلة من زاوية أوسع؛ فقبل تنفيذ مجموعة كبيرة من المعاملات، تحتاج الشبكة إلى الاتفاق حول الأحداث وترتيبها. لنفترض أن شخصًا يمتلك 100 ريال فقط، ثم أرسل معاملتين: 100 ريال لأحمد و100 ريال لخالد — هنا لا يمكن تنفيذ المعاملة الثانية، وهذا يوضح أن ترتيب المعاملات عامل مهم في إنجاز العمليات. فقد ترى إحدى الأجهزة معاملة أحمد أولًا، بينما ترى أجهزة أخرى معاملة خالد أولًا. وهنا برز سؤال مهم:
ظهور Proof of History
أجابت Solana على هذا السؤال باقتراح Proof of History (PoH) أو إثبات التاريخ، حيث يصف المشروع هذا البروتوكول بأنه تسلسل من العمليات الحسابية، نستطيع من خلاله التحقق من مرور الوقت بين حدثين، بالإضافة إلى التحقق من ترتيب الأحداث، بطريقة قائمة على عمليات التشفير. دعنا نبسّط الفكرة: لديك آلة تسمح لك بإدخال قيمة محددة، فتنتج قيمة جديدة، ثم تأخذ النتيجة وتُدخلها مرة أخرى، وتكرر العملية، فتصبح لديك سلسلة:
المهم هنا أن العملية متسلسلة، فلا نستطيع الوصول إلى النتيجة الثالثة دون المرور بالثانية، ولا الثانية دون المرور بالأولى.
أين الوقت من هذه العملية؟
قد يسأل أحدهم: هذه مجرد عمليات حسابية، فكيف أصبحت ساعة؟ نتخيل أننا نعرف أن تنفيذ كل هذه العمليات يحتاج وقتًا، وللوصول إلى Hash رقم 300 يجب تنفيذ العمليات التي سبقته بالتتابع — لا يمكن القفز من Hash رقم 1 إلى Hash رقم 300 مباشرة. لذلك، وجود هذا التسلسل يقدّم دليلًا على أن قدرًا من الوقت قد مرّ أثناء إنتاجه. يمكن تبسيط Proof of History بأنها:
ماذا يحدث إذا أدخلنا المعاملات داخل هذه الساعة؟
إذا أمكن إدخال البيانات والأحداث داخل تسلسل Proof of History، فإن إدخال أي بيانات عند نقطة معيّنة في التسلسل يؤثر في عمليات Hash التي تأتي بعدها، وبالتالي يصبح لدينا دليل على أن هذه البيانات كانت موجودة قبل إنتاج النتائج اللاحقة. وبذلك تستطيع الأجهزة التي ترى السجل تحديد ترتيب الأحداث وتقدير الوقت الذي مرّ بينها.
ما علاقة ذلك بالأداء؟
هذه هي النقطة الأهم: لم تخترع Solana خوارزمية Proof of History لمجرد إنشاء ساعة داخل البلوكتشين، بل كان الهدف الأكبر تحسين أداء النظام الموزع. فإذا احتاجت الأجهزة إلى التواصل باستمرار حتى تتفق على ترتيب الأحداث، فإن جزءًا كبيرًا من وقت الشبكة سيذهب إلى عملية التنسيق نفسها. أما إذا كان لدينا سجل يقدّم ترتيبًا يمكن التحقق منه، فمن الممكن تقليل تأثير هذا العبء. توضح Solana أنه يمكن استخدام Proof of History بجانب خوارزمية إجماع مثل Proof of Work أو Proof of Stake، للمساعدة في خفض عبء الرسائل Messaging Overhead بين المشاركين:
نجعل الترتيب والزمن قابلَين للتحقق → نستخدم Proof of History → تقليل عبء التنسيق → تحسين الأداء
والاستنتاج: خوارزمية Proof of History ليست الهدف بحد ذاتها، بل الأداء هو الغاية الأساسية من المشروع — وهذه نقطة ستصبح مهمة عندما نصل إلى تطور Solana لاحقًا.
هل Proof of History آلية للإجماع؟
هنا يوجد سوء فهم شائع؛ فقد نسمع أحيانًا أن Solana تستخدم Proof of History بدلًا من Proof of Stake، لكن هذا ليس ما تقوله وثائق المشروع الرئيسية. تتحدث الورقة البيضاء عن استخدام Proof of History إلى جانب خوارزمية إجماع مثل Proof of Stake أو Proof of Work. في التصميم، تُستخدم Proof of History للمساعدة في إثبات مرور الوقت وترتيب الأحداث، بينما تُستخدم Proof of Stake للتصويت واختيار القادة والمساعدة في الوصول إلى الإجماع — وظيفتان مختلفتان تمامًا.
كيف تنتقل المعاملة داخل الشبكة؟
في تصميم Solana، هناك فترة معيّنة لجهاز محدد يُدعى القائد (Leader)، حيث تصل معاملات المستخدمين إليه، ثم يقوم بترتيبها داخل تسلسل Proof of History، ثم تُنفَّذ المعاملات على الحالة الموجودة لديه، قبل إرسال المعاملات والنتائج إلى أجهزة أخرى يسمّيها المشروع المحقّقين (Verifiers). يعمل المحقّقون على إعادة تنفيذ المعاملات على نسخهم من الحالة، ثم ينشرون تأكيداتهم التي تُستخدم كأصوات في عملية الإجماع.
هل وجود Leader دليل على أن الشبكة مركزية؟
قد يبدو الأمر كذلك، لكن Leader في تصميم Solana ليس جهة ثابتة تتحكم في الشبكة، والدليل أنه يمكن لأجهزة أخرى أن تصبح Leader. تقترح وثائق المشروع استخدام Proof of Stake في عملية تحديد Leader، أي أن هذا الدور مؤقت داخل النظام وليس مالكًا له، كما تتضمن الورقة آليات لاختيار Leader جديد عندما يفشل الحالي.
أين يكمن دور Proof of Stake؟
حتى لو استطعنا ترتيب الأحداث، فنحن ما زلنا بحاجة إلى أن تتفق الشبكة على الحالة الصحيحة، وهنا يأتي دور Proof of Stake (إثبات الحصة)، وذلك من خلال حجز المتحقق كمية من العملة كضمان، تستخدم وثائق المشروع مصطلح Bond لوصفه — شبيه بالتكلفة التي يتحملها المعدّن في خوارزمية Proof of Work (معدّات وكهرباء)، بينما في Proof of Stake توجد عملة محجوزة كضمان. هذا الضمان يساعد على ربط الشبكة في الإجماع بتكلفة اقتصادية.
ماذا لو حاول المتحقق التزوير؟
من الممكن أن يصوّت المتحقق على عدة سجلات متعارضة دون أي تكلفة، بغرض الحصول على رسوم من الجميع أو إفساد الشبكة. لهذا يقترح المشروع فكرة Slashing: معاقبة بعض أشكال السلوك المخالف اقتصاديًا. فإذا ثبت أن المتحقق صوّت على تسلسلين منفصلين بصورة مخالفة للقواعد، فإن العقوبة هي حجز الـBond الذي منحه. ببساطة: للمشاركة بالشبكة تحتاج ضمانًا يكفلك، والسلوك المخالف له تكلفة اقتصادية من خلال سحب ذلك الضمان.
متى تصل الشبكة إلى الاتفاق؟
تستخدم وثائق المشروع مفهوم Super Majority (الأغلبية العظمى)، وتُعرَّف بثلثي المتحققين وفق الأوزان المرتبطة بضماناتهم. تُعتبر الشبكة قد وصلت إلى الإجماع عندما تحصل حالة معيّنة على هذا المستوى من التأييد. بذلك يعمل المكونان معًا: Proof of History على ترتيب الأحداث والأزمان، وProof of Stake بعمليات التصويت والاتفاق — لتكوين شبكة تحاول الوصول إلى الإجماع بأكبر سرعة.
ماذا يحدث إذا توقّف Leader؟
قد يتعطل الجهاز، أو يظهر خطأ برمجي، أو تحدث مشكلة اتصال، أو ينتج جهاز Leader حالة غير صحيحة. لذلك يتضمن مشروع Solana آلية مدمجة لانتخاب Leader جديد عند اكتشاف فشل مولّد Proof of History، كما تقترح إمكانية انتخاب جهاز Secondary يتولى المهمة عندما يفشل القائد الرئيسي، للحفاظ على قدرة الشبكة على الاستمرار.
ماذا يحدث إذا انقسمت الشبكة؟
تخيل مشكلة في الإنترنت تنتج عنها انقسام الشبكة إلى مجموعتين، وانعدام التواصل بينهما. هنا تظهر واحدة من أصعب مشكلات الأنظمة الموزعة: تحديد أي مجموعة تستمر وأي سجل نعتمد. ناقشت وثائق Solana هذا السيناريو، واقترحت استخدام المعلومات الزمنية التي توفرها Proof of History للمساعدة في معرفة مدة غياب بعض المتحققين، مع آليات تجعل حصص المتحققين غير المتاحين تصبح قديمة تدريجيًا — والهدف النهائي إعطاء الشبكة طريقة لاستعادة قدرتها على العمل بعد الانقسام.
ماذا عن تخزين البيانات؟
لا تقتصر المشكلة على الأداء فقط، بل سيؤدي استمرار الشبكة لسنوات إلى إنتاج كمية كبيرة من البيانات. من هنا تناقش وثيقة Solana فكرة Proof of Replication (PoRep)، محاولة الإجابة على:
تشير وثيقة Solana إلى أن الفكرة مستوحاة من Proof of Replication في Filecoin، لكنها تقترح تصميمًا يستفيد من خصائص الوقت التي توفرها Proof of History. يمكن تبسيط الفكرة بالنموذج التالي: "أنت تقول إنك تخزّن البيانات؟ هذا عظيم، لكن يجب أن تقدّم دليلًا على ذلك."
لماذا تستفيد Solana من الأجهزة القوية؟
نعود إلى الهدف الأساسي: إنتاج شبكة بلوكتشين عالية الأداء. لا يحاول المشروع ابتكار خوارزمية جديدة فحسب، بل يحاول جعل البلوكتشين يستفيد بصورة أكبر من الإمكانات الموجودة في الأجهزة الحديثة. لذلك تناقش الورقة فكرة المعالجات المتعددة الأنوية، GPUs، RAM، والشبكات عالية السرعة، بل تقترح أيضًا طريقة لتنفيذ العقود الذكية من خلال المعالجة المتوازية وGPU — وهذا يكشف جانبًا مهمًا من فلسفة التصميم: أن يستطيع البلوكتشين الاستفادة من أداء الأجهزة كلما أصبحت أسرع.
ماذا عن 710 ألف معاملة في الثانية؟
كتبت وثيقة Solana في تحليلها رقمًا لافتًا: إمكانية إنجاز 710,000 معاملة في الثانية. على أي حال، يجب فهم الرقم من سياقه الصحيح؛ فالوثيقة تحلل اتصالًا بسرعة 1Gbps، وتحسب الحد النظري لعدد المعاملات الذي يمكن أن يمر عبر الاتصال اعتمادًا على حجم المعاملة.
ما الفكرة الحقيقية وراء شبكة Solana؟
بعد كل التفاصيل السابقة، يمكن القول إن فكرة Solana ليست إنشاء خوارزمية Proof of History، ولا Proof of Stake، ولا التركيز على تطوير GPU — هذه كلها أدوات لهدفها الأكبر: بناء شبكة بلوكتشين عالية الأداء. ولذلك كان اسم ورقتها البيضاء: A new Architecture for a High-Performance Blockchain. ويمكن تلخيص منطقها بالنموذج التالي:
ندمجه مع Proof of Stake → نستفيد من قدرات الأجهزة الحديثة → شبكة بلوكتشين عالية الأداء
ماذا حدث بعد انتشار الورقة وبناء الشبكة؟
حتى هذه النقطة، شرحنا Solana كما قدّمتها وثيقتها الأساسية، لكن هناك فرق مهم بين فكرة المشروع الأصلية والتقنيات المستخدمة لتحقيقها. الهدف الأساسي استمر كما هو: زيادة أداء البلوكتشين وتقليل زمن معالجة وتأكيد المعاملات. لكن التقنيات المستخدمة استمرت في التطور — وهذا أمر طبيعي، فالوثيقة الأولى للمشروع ليست وصفًا أبديًا للنظام، بل تصور معماري في مرحلة معيّنة من تطوره. وأبرز مثال على ذلك اليوم هو Alpenglow.
من Proof of History إلى Alpenglow
قدّمت Anza تصميمًا جديدًا للإجماع في Solana باسم Alpenglow، في شهر مايو 2025، وتصفه بأنه أكبر تغيير في البروتوكول الأساسي لشبكة Solana منذ انطلاقها. والمثير للاهتمام أن Alpenglow يستهدف الاستغناء عن مكونات ارتبطت تاريخيًا بهوية Solana، أبرزها Tower BFT وProof of History في منطق الإجماع الجديد، ويقدّم بدلًا منها مكونًا يُسمى Votor للتصويت وإنهاء الكتل، مع تغيير طريقة الاتصال بين المشاركين.
إذا كانت Proof of History هي أشهر ابتكارات Solana، فكيف يمكن للمشروع الاستغناء عنها؟ الإجابة تعيدنا إلى بداية المقال: Proof of History لم تكن الهدف النهائي، بل كانت الوسيلة التي تحقق الهدف — إنتاج شبكة بلوكتشين عالية الأداء.
ما المشكلة التي يحاول Alpenglow حلها؟
يعود الموضوع مرة أخرى إلى الزمن، لكن هذه المرة زمن الوصول إلى النهاية Finality: كم نحتاج من الوقت قبل أن نعتبر الكتلة صالحة؟ وبحسب Anza، فإن النظام السابق المرتبط بـTower BFT لديه زمن إنهاء يقارب 12.8 ثانية، بينما يستهدف Alpenglow الوصول إلى إنهاء فعلي في حدود 150 مللي ثانية في المتوسط وفق المحاكاة المنشورة. أي أن الورقة الأصلية حاولت تقليل عبء التنسيق باستخدام Proof of History، بينما تعيد Alpenglow تصميم عملية الإجماع والاتصال نفسها لتحقيق زمن إنهاء أقل — الأداة تغيّرت، لكن الهدف لم يتغيّر.
هل انتقلت Solana بالفعل إلى Alpenglow؟
هنا يجب أن نكون دقيقين: لا ينبغي القول إن Solana تعمل بالكامل باستخدام Alpenglow، فالانتقال لا يزال جاريًا حتى تاريخ كتابة هذه الأسطر (سبتمبر 2026). على أي حال، ذكرت Anza في خطتها لهذا العام أن الهدف هو نقل Alpenglow من بيئات التطوير إلى Mainnet، وهناك بالفعل مكونات دخلت مراحل مختلفة من التفعيل والاختبار، بينما لا تزال مكونات أخرى مرتبطة بالإطلاق لم تُفعَّل بعد على Mainnet. لذلك، يمكن القول إن Solana تتجه نحو Alpenglow، لكنها تمر بعملية انتقال وتطوير، وليس من الصحيح التعامل معه باعتباره النظام الذي استبدل Proof of History بالكامل على الشبكة الرئيسية.
الخلاصة
شبكة Solana محاولة لبناء بلوكتشين عالي الأداء من خلال تقليل أعباء التنسيق والاستفادة من قدرات الأجهزة والشبكات الحديثة؛ حيث بدأت الشبكة باستخدام خوارزمية Proof of History كابتكار أساسي لتحقيق ذلك، بينما يواصل المشروع تطوير آليات جديدة مثل Alpenglow لتحقيق الهدف نفسه بزمن أقل وأداء أعلى.
وهذا يجعل السؤال الذي بدأت به Solana أهم من أي تقنية استخدمتها:
في البداية كانت Proof of History أحد الإجابات على هذا السؤال، واليوم يجري تطوير إجابة جديدة باسم Alpenglow، لكن الهدف الرئيسي بقي كما هو: بناء شبكة بلوكتشين عالية الأداء.