آلية إثبات التاريخ (PoH) الخاصة بسولانا: كيف تعمل

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

إثبات التاريخ في سولانا هو آلية ترتيب زمني تشفيري، وليس بروتوكول توافق مستقل. إنه يعمل مع Tower BFT وإثبات الحصة (Proof of Stake) لمساعدة المدققين على ترتيب الأحداث والاتفاق على دفتر الأستاذ.

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

جدول المحتويات

1. ما هو إثبات التاريخ؟ شرح ساعة سولانا التشفيرية
2. كيف تعمل آلية إثبات التاريخ: سلسلة هاش SHA-256 خطوة بخطوة
3. لماذا يمكن لإثبات التاريخ تقليل أعباء الترتيب الإضافية
4. إثبات التاريخ مقابل إثبات العمل مقابل إثبات الحصة: مقارنة مباشرة
5. كيف يتفاعل إثبات التاريخ مع بنية سولانا الكاملة
6. قيود وانتقادات إثبات التاريخ: تقييم صادق
7. الأسئلة الشائعة حول إثبات التاريخ وسولانا
8. الخاتمة: هل إثبات التاريخ ابتكار حقيقي؟

ما هي آلية إثبات التاريخ في سولانا؟

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

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

هناك تمييز حاسم يجب توضيحه على الفور: إثبات التاريخ ليس آلية توافق. آلية التوافق الفعلية لسولانا هي Tower BFT. إثبات التاريخ (PoH) هي طبقة التوقيت التي تعتمد عليها Tower BFT لتعمل بكفاءة. الخلط بين الاثنين هو الخطأ الأكثر شيوعاً في تغطية تقنية سولانا، وهذا المقال يصحح ذلك في جميع أجزائه.

اخترع أناتولي ياكوفينكو آلية إثبات التاريخ، وهو المؤسس المشارك لـ Solana Labs وكبير مهندسين سابق في شركة Qualcomm. قدم المفهوم في ورق ابيض عام 2017 بعنوان سولانا: بنية جديدة لبلوكتشين عالي الأداء. تم إطلاق نسخة المينيت التجريبية (mainnet beta) لسولانا في مارس 2020، وهي مبنية على البنية التي وصفتها تلك الورق ابيض.

سولانا هي بلوكتشين عالية الأداء من طبقة 1 والرمز الأصلي لها هو SOL. سقف الإنتاجية النظري الخاص بها، والذي تم تمكينه بواسطة إثبات التاريخ الذي يعمل جنباً إلى جنب مع العديد من الابتكارات المعمارية الأخرى، هو رقم نظري تاريخي يبلغ حوالي 65,000 معاملة في الثانية (TPS). الإنتاجية المستدامة في العالم الحقيقي في ظل ظروف الشبكة النموذجية أقل بكثير، وهو تمييز يتناوله هذا المقال بالتفصيل.

إذا سمعت أن إثبات التاريخ يوصف بأنه "مثل إثبات الحصة (Proof of Stake)" أو افترضت أنه آلية توافق سولانا، فكلا التوصيفين غير صحيحين. تظهر المقارنة الكاملة والعلاقة الدقيقة بين هذه الآليات في الأقسام أدناه.

كيف تعمل آلية إثبات التاريخ: سلسلة هاش SHA-256 خطوة بخطوة

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

ما هي دالة هاش التشفير؟ (اللبنة الأساسية)

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

تغيير حرف واحد في المدخلات يغير المخرجات تماماً وبشكل غير متوقع. هذه الحساسية للمدخلات هي بالضبط ما يجعل التجزئة المتسلسلة (sequential hashing) أساساً موثوقاً لضبط الوقت.

دالة الهاش المحددة التي يستخدمها إثبات التاريخ هي SHA-256 (خوارزمية التجزئة الآمنة، 256 بت)، وهي نفس الخوارزمية التي تؤمن معاملات البيتكوين. تتطلب خوارزمية SHA-256 جهداً حسابياً مكثفاً للتشغيل ولكن التحقق منها سريع جداً. هذا التباين هو أمر مركزي: إنتاج الهاش بطيء، لكن التحقق منه فوري. هذه الخاصية هي بالضبط ما يجعل SHA-256 مناسبة لوظيفة توقيت PoH.

سلسلة الهاش: كيف يشفر إثبات التاريخ الوقت تشفيرياً

تعمل PoH عن طريق تشغيل SHA-256 في تسلسل غير منقطع، حيث يصبح كل مخرج هو المدخل للحساب التالي. ونظراً لأن كل خطوة تتطلب وقتاً حسابياً حقيقياً وغير قابل للاختزال، فإن سلسلة المخرجات تشكل سجلاً قابلاً للتحقق من الوقت المنقضي. لا يمكن لأحد تزييف الوصول إلى الخطوة 500,000 دون حساب الخطوات من 1 إلى 499,999 فعلياً.

فكر فيها كأنها ساعة توقيت تشفيرية. كل دقة في الساعة هي مخرج SHA-256 مسجل، وتثبت سلسلة الدقات أن قدراً معيناً من الحساب، وبالتالي قدراً قابلاً للقياس من الوقت، قد انقضى بين الأحداث.

إليك كيفية تشغيل التسلسل:

1. يبدأ المدقق القائد السلسلة. يقوم مدقق معين ("القائد" لتلك الفترة الزمنية) بتشغيل SHA-256 على مدخل أولي، والذي يمكن أن يكون أي قيمة عشوائية أو هاش كتلة سابقة.
2. يصبح كل مخرج هو المدخل التالي. يتم إرجاع الهاش الناتج إلى SHA-256 كمدخل جديد. هذه هي السلسلة. تعتمد كل حلقة بالكامل على الحلقة التي سبقتها.
3. يقوم عداد التسلسل بتتبع المركز. تحمل كل عملية تكرار رقم عد: هاش رقم 1، هاش رقم 2، هاش رقم 347,891. هذا العداد هو عدد دقات الساعة.
4. يتم دمج المعاملات في السلسلة فور وصولها. عندما تدخل معاملة إلى الشبكة، يقوم القائد بتجزئتها (hashing) في التسلسل في تلك اللحظة الدقيقة. يتم دمج بيانات المعاملة في مخرج الهاش عند مركز العد المحدد ذاك.
5. يثبت المركز المدمج توقيت المعاملة. المعاملة التي تم تجزئتها في المركز 347,891 حدثت بشكل مثبت بعد المركز 347,890 وقبل المركز 347,892. لا حاجة لختم زمني خارجي. السلسلة نفسها هي الدليل.
6. يتحقق المدققون الآخرون من التسلسل. التحقق سريع لأن فحص الهاش يستغرق جزءاً بسيطاً من الوقت الذي يستغرقه إنتاجه. يمكن للمدقق تأكيد صحة التسلسل بالكامل دون إعادة تشغيل كل عملية حسابية.
7. السلسلة الناتجة هي جدول زمني لا يمكن التلاعب به. يؤدي تغيير أي هاش في أي مركز إلى إبطال كل هاش يليه، مما يجعل تزوير السجل مستحيلاً دون إعادة كل العمل اللاحق.

يلتقط تشبيه الصور الفوتوغرافية خاصية عدم التلاعب جيداً. تخيل التقاط صورة كل ثانية، حيث تتضمن كل صورة الصورة السابقة داخل الإطار. يمكن لأي شخص ينظر إلى الصورة رقم 1,000 التحقق من التسلسل دون أن يكون حاضراً في كل لقطة، لأن كل صورة متداخلة تشفيرياً في الصورة التالية. سيؤدي تغيير الصورة رقم 400 إلى إفساد كل صورة لاحقة بشكل واضح.

سلسلة الهاش المتسلسلة هذه هي ما يطلق عليه خبراء التشفير وظيفة مشابهة وظيفياً لـ دالة التأخير القابلة للتحقق (VDF). إن دالة VDF المعرفة رسمياً، كما وصفها بونيه، وبونو، وبونز، وفيش في ورقتهم البحثية لعام 2018 المنشورة في CRYPTO (IACR ePrint 2018/601)، هي دالة تتطلب قدراً محدداً من الوقت للحساب، ولا يمكن معالجتها بالتوازي لتسريع ذلك الحساب، وتنتج إثباتاً يسمح بالتحقق السريع. ويحقق PoH نفس التأثير العملي من خلال هاش SHA-256 المتسلسل. وهي ليست دالة VDF رسمياً بالمعنى الدقيق لنظرية التعقيد، ولكن التشابه الوظيفي دقيق. فالباحثون الأكاديميون الذين يصفون PoH بأنها "شبيهة بـ VDF" أو "VDF غير رسمية" يستخدمون صياغة دقيقة.

المصدر: أناتولي ياكوفينكو، "سولانا: بنية جديدة لبلوكتشين عالي الأداء"، 2017. متاح على solana.com/solana-whitepaper.pdf

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

لماذا يمكن لإثبات التاريخ في سولانا تقليل أعباء الترتيب الإضافية

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

المقارنات مع فيزا (Visa) أو إيثيريوم (Ethereum) أو بيتكوين (Bitcoin) ليست مقارنات متكافئة: فهي تحسب أحداثاً مختلفة وتستخدم نماذج ثقة وتسوية ونهائية مختلفة. يعد PoH جزءاً واحداً من تصميم سولانا، إلى جانب Sealevel وTurbine وGulf Stream وأسواق الرسوم والبنية التحتية للموثقين.

كيف يستخدم Tower BFT إثبات التاريخ (PoH) لتخطي جولات الاتصال

لا تتعلق زيادة السرعة من PoH بإجراء الهاش بشكل أسرع. بل تتعلق بالتخلص من فئة كاملة من الاتصالات التي تتطلبها آليات التوافق التقليدية.

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

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

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

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

Sealevel وGulf Stream: سرعة تتجاوز الساعة

لا ينتج PoH وحده 65,000 TPS. إنه الطبقة التأسيسية التي تجعل ابتكارات الأداء الأخرى في سولانا ممكنة.

إن Sealevel هو بيئة تشغيل العقود الذكية المتوازية في سولانا. العقود الذكية هي برامج مخزنة على البلوكتشين ويتم استدعاؤها من خلال المعاملات. وفي حين تعالج EVM الخاصة بإيثيريوم المعاملات بالتسلسل، يمكن لـ Sealevel تشغيل المعاملات غير المتعارضة عبر عدة نوى للمعالجات. يأتي هذا التوازي من الحسابات التي تعلن كل معاملة أنها ستقرأ منها أو تكتب فيها؛ حيث يوفر PoH مرجعاً للترتيب ولكنه لا يحدد الحسابات المستقلة.

إن Gulf Stream هو بروتوكول إعادة توجيه المعاملات بدون ميمبول في سولانا. فبدلاً من الاحتفاظ بالمعاملات غير المؤكدة في مجمع انتظار، يقوم Gulf Stream بدفع المعاملات إلى قائد الموثقين المتوقع التالي قبل الانتهاء من الكتلة الحالية، وذلك باستخدام جدول القادة في PoH لمعرفة من سيأتي تالياً. ثم يقوم Turbine، بروتوكول نشر الكتل في سولانا والمستوحى من BitTorrent، بتقسيم الكتل المؤكدة إلى حزم أصغر وتوزيعها عبر شبكة الموثقين بكفاءة.

يمثل PoH الأساس. ويُبنى كل من Sealevel وGulf Stream فوقه مباشرة، وكذلك Turbine. يعكس رقم 65,000 TPS كل هذه الابتكارات التي تعمل معاً، مع اعتبار PoH طبقة الترتيب التي يعتمد عليها كل منها.

تتطلب تطبيقات DeFi، بما في ذلك المنصات اللامركزية وبروتوكولات الإقراض، إنتاجية عالية للمعاملات لتعمل على نطاق واسع. إن بنية سولانا المدعومة بـ PoH تجعل من الممكن لهذه التطبيقات معالجة آلاف العمليات في الثانية في الطبقة الأساسية، وهي قدرة لا تضاهيها معظم سلاسل البلوكتشين الحالية من الطبقة 1، على الرغم من أن حلول الطبقة 2 على السلاسل الأخرى تعمل على تضييق هذه الفجوة لحالات استخدام محددة.

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

إثبات التاريخ مقابل إثبات العمل مقابل إثبات الحصة: مقارنة مباشرة

أهم نقطة هيكلية قبل هذه المقارنة: إثبات التاريخ ليس آلية توافق. إثبات العمل وإثبات الحصة هما آليتا توافق. ومقارنة PoH مباشرة بـ PoW أو PoS تشبه مقارنة ساعة بنظام تصويت. فهما يحلان مشكلات مختلفة، وهذا التمييز يشكل كل شيء آخر في هذا الجدول.

ملاحظة: يمثل TPS النظري لسولانا المخرجات المجمعة لـ PoH وSealevel وTurbine وGulf Stream في الظروف المثالية. لا يتم الوصول إلى هذا الرقم بشكل روتيني في الإنتاج.

PoH مقابل إثبات العمل: السرعة والطاقة

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

لا يحل PoH محل نموذج أمان PoW. بل يحل مشكلة مختلفة، وهي مشكلة الترتيب الزمني، بهدر حوسبي أقل بكثير. حيث ينتج موثق واحد فقط (القائد الحالي) تسلسل PoH بدلاً من تنافس كل المعدنين في آن واحد.

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

آلية PoH مقابل إثبات الحصة (Proof of Stake): ليسا الشيء نفسه

لا، إثبات التاريخ (Proof of History) ليس هو نفسه إثبات الحصة (Proof of Stake). ولا تستخدم Solana آلية PoH بدلاً من PoS، بل تستخدم كلتيهما في آن واحد لأغراض مختلفة.

إثبات الحصة (Proof of Stake) هي آلية توافق يتم فيها اختيار المدققين لإنتاج الكتل بناءً على كمية العملة الرقمية التي قاموا بعمل Stake (تخزين) لها كضمان. انتقلت Ethereum إلى إثبات الحصة في سبتمبر 2022 مع ترقية Merge الخاصة بها. وتُعالج آلية PoS في Ethereum ما يقرب من 15 إلى 30 عملية في الثانية (TPS) على طبقتها الأساسية، مع حلول طبقة 2 مثل منصة Arbitrum وOptimism التي تزيد من معدل النقل الفعلي بشكل كبير بما يتجاوز هذا الرقم.

تستخدم Solana نظاماً قائماً على PoS لاختيار المدققين، وهو ما يحدد من يصبح القائد المسؤول عن إنتاج تسلسل PoH لفتحة زمنية معينة. بعد ذلك، توفر آلية PoH الترتيب الزمني الذي تستخدمه آلية Tower BFT للوصول إلى التوافق. الآليتان مكملتان لبعضهما البعض وليستا متنافستين؛ فآلية PoH هي الساعة، وآلية PoS تحدد من يقوم بتعبئة هذه الساعة.

كيف تتفاعل آلية إثبات التاريخ مع بنية Solana الكاملة

بالنسبة للمطورين الذين يقيمون Solana باعتبارها المنصَّة، فإن السؤال لا يقتصر فقط على ما تفعله آلية PoH بمعزل عن غيرها، بل يتعلق بكيفية ملاءمة آلية PoH لبنية الابتكارات الثمانية الكاملة التي وصفها أناتولي ياكوفينكو في ورق ابيض الخاص به عام 2017، وما تتطلبه تلك البنية من الأجهزة التي تشغلها.

Tower BFT: استخدام سجل PoH كساعة تصويت

تستخدم Tower BFT سجل PoH الزمني القابل للتحقق لتنفيذ آلية قفل التصويت التي ستكون مستحيلة بدون تسلسل مشترك وموثوق للفتحات الزمنية.

إليك كيفية عمل ذلك في الممارسة العملية. يقوم المدققون على Solana بالإدلاء بأصواتهم للكتل التي يعتقدون أنها صالحة. يرتبط كل تصويت برقم فتحة PoH محدد. وتفرض Tower BFT قاعدة حظر (lockout): بمجرد أن يصوت المدقق لفتحة ما، لا يمكنه التصويت لصالح انقسام متعارض لعدد متزايد أسيًا من الفتحات اللاحقة. وكلما طالت مدة الحظر، زادت مخاطر فقدان المدقق لعملات SOL التي قام بعمل Stake لها بسبب عقوبة "slashing" إذا حاول التصويت على جانبي الانقسام.

يمكن لـ Tower BFT فرض عمليات الحظر القائمة على الوقت هذه تحديداً لأن PoH توفر تسلسلاً مشتركاً وقابلاً للتحقق للفتحات. وبدون PoH، لن يكون هناك مرجع مشترك موثوق للقول بأن "الفتحة 347,891 حدثت قبل الفتحة 347,892". يتطلب قفل التصويت القائم على الوقت ساعة موثوقة، وآلية PoH هي تلك الساعة.

يتم تحديد جدول القائد مسبقاً باستخدام أوزان عملات SOL المخزنة (staked). ويعرف المدققون أي عقدة من المتوقع أن تنتج دفق PoH وتقترح كتلة لكل فتحة قادمة. وتسمح هذه القابلية للتنبؤ بإعادة التوجيه مع معرفة القائد قبل الانتهاء من الكتلة الحالية، مما يقلل الاعتماد على ميمبول عالمي تقليدي دون القضاء تماماً على الازدحام أو سقوط المعاملات أو رسوم الأولوية أو مخاطر القيمة القصوى المستخرجة (MEV).

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

Sealevel: كيف يتيح ترتيب معاملات PoH التوازي

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

تحل تقنية Sealevel ذلك من خلال قراءة زمام معاملات PoH الموثقة وتحليل مجموعات حسابات القراءة والكتابة المعلنة لكل معاملة. وبما أن كل معاملة في Solana يجب أن تحدد الحسابات التي تقرأ منها وتكتب إليها، يمكن لـ Sealevel تحديد المعاملات المستقلة في وقت التقديم. المعاملات المستقلة (التي تمس حسابات مختلفة تماماً) يمكن تنفيذها في وقت واحد عبر نوى معالج متعددة أو خيوط معالجة الرسوميات (GPU). أما المعاملات المترابطة، فيتم تنفيذها بالتسلسل وفقاً لترتيب PoH الموثق الخاص بها.

يتمثل دور PoH في توفير زمام المعاملات المرتب والمختوم زمنياً والذي تستهلكه Sealevel. وبدون الترتيب الموثق الذي تنتجه PoH، فإن التنفيذ الموازي سيتطلب تكاليف تنسيق باهظة لمنع التعارضات. تشير Solana إلى برامجها داخل الكتلة باسم "برامج" (programs) بدلاً من العقود الذكية في وثائقها الأصلية، مما يعكس تمييزاً معمارياً عن نموذج تنفيذ Ethereum، على الرغم من أن مصطلح "العقود الذكية" مفهوم ومستخدم على نطاق واسع في الصناعة.

تستخدم Gulf Stream جدول القائد الخاص بـ PoH لدفع المعاملات غير المؤكدة مباشرة إلى قادة المدققين القادمين، وتستخدم Turbine كتل PoH المرتبة كأساس لشجرة انتشار الكتل بأسلوب BitTorrent. كل مكون أداء رئيسي في بنية Solana يعتمد على PoH كأساس للترتيب.

هذا الترابط المعماري هو أيضاً مصدر لبعض أهم الانتقادات الموجهة لـ PoH، وتحديداً متطلبات الأجهزة التي تفرضها على المدققين.

قيود وانتقادات إثبات التاريخ: تقييم صادق

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

يتطلب تشغيل مدقق Solana أجهزة خوادم متطورة: وحدة معالجة مركزية ذات عدد كبير من النوى، وحد أدنى 128 جيجابايت من ذاكرة الوصول العشوائي (RAM)، وأقراص NVMe SSD، واتصال شبكة متعدد الجيجابايت. توصي وثائق Solana بمواصفات أجهزة تتراوح تكلفة تجميعها وتشغيلها بين 5,000 و 20,000 دولار أو أكثر.

يحد حاجز التكلفة هذا من المشاركة في مجموعة المدققين ليقتصر على المشغلين ذوي الموارد الجيدة. فمن الممكن تشغيل عقدة بيتكوين كاملة على جهاز Raspberry Pi بتكلفة تقل عن 100 دولار، لكن لا يمكن لمدقق Solana فعل ذلك. والنتيجة هي ضغط المركزية: فكلما ارتفعت تكلفة المشاركة، صغرت مجموعة المدققين المحتملين، وأصبحت قوة التوافق في الشبكة أكثر تركيزاً بين المشغلين المؤسسيين الممولين جيداً.

ضغط المركزية هو التوصيف الدقيق هنا، وليس المركزية المكتملة. فقد حافظت Solana على ما يقرب من 1,500 إلى 2,000 مدقق نشط، وهو رقم أقل من مجموعة مدققي Ethereum التي تضم عدة مئات الآلاف من المدققين، على الرغم من أن عتبة أجهزة Ethereum المنخفضة تنطوي على متطلبات اقتصادية مختلفة (يلزم 32 ETH للقيام بعمل Stake). نفذت مؤسسة Solana برامج تفويض الحصة لدعم المدققين الأصغر، ولكن متطلبات الأجهزة الأساسية المدفوعة بمتطلبات إنتاجية PoH تظل هيكلية وليست عرضية.

المقايضة متعمدة: بنية ياكوفينكو تعطي الأولوية للإنتاجية على إمكانية الوصول، وتقبل ضغط المركزية كثمن للأداء. ويعتمد قبول هذه المقايضة من عدمه على ما يقدره المقيم أكثر من غيره.

انقطاعات الشبكة: هل كان إثبات التاريخ هو الملام؟

لم تكن آلية إثبات التاريخ في حد ذاتها هي السبب في انقطاعات الشبكة الرئيسية لـ Solana. بل نتجت الانقطاعات عن طوفان من معاملات البريد العشوائي (spam) التي طغت على سعة الحوسبة للشبكة، ومن أخطاء في برامج عميل المدقق.

الحوادث الموثقة محددة. ففي سبتمبر 2021، شهدت شبكة Solana انقطاعاً لمدة 17 ساعة بسبب زيادة في المعاملات التي أنشأها بوت خلال عرض DEX الأولي من Raydium. غمر حجم معاملات البريد العشوائي ذاكرة المدققين، مما تسبب في تعطل المدققين وتوقف الشبكة حتى أمكن تنظيم عملية إعادة تشغيل منسقة. ووقعت انقطاعات إضافية للشبكة في يناير 2022 ومايو 2022، كل منها يعزى إلى مزيج من هجمات البريد العشوائي وأخطاء برمجيات المدقق بدلاً من الإخفاقات في آلية PoH نفسها.

الارتباط المعماري الصريح هو كالتالي: إن تصميم إثبات التاريخ (PoH) يعطي الأولوية لمعدل المعالجة على حساب الإدارة المحافظة للموارد، مما يعني أن الشبكة لم تكن تمتلك تحديداً مدمجاً للمعدل أو منعاً للرسائل غير المرغوب فيها (spam) القائم على الرسوم في وقت حالات الانقطاع تلك. فالشبكة المصممة لمعالجة 65,000 عملية في الثانية (TPS) يجب أن تتعامل مع حركة مرور قادمة تعادل 65,000 عملية في الثانية، بما في ذلك حركة المرور الخبيثة. إن المعماريات الأكثر تحفظاً، من خلال خنق معدل المعالجة، تخنق أيضاً مساحة الهجوم.

بعد عام 2022، نفذت سولانا عدة استجابات هندسية: بروتوكول شبكة QUIC لاستيعاب معاملات أكثر مرونة، وأسواق رسوم المعاملات لجعل الرسائل غير المرغوب فيها مكلفة اقتصادياً، وجودة الخدمة المرجحة بالتخزين (stake-weighted quality-of-service) لإعطاء الأولوية للمعاملات من المدققين الذين لديهم تخزين (stake) ملموس. وقد أدت هذه الإجراءات إلى تحسين استقرار الشبكة بشكل ملحوظ.

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

تبعيات مزامنة الساعة

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

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

الأسئلة الشائعة حول إثبات تاريخ سولانا

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

ما هو الغرض من إثبات التاريخ في سولانا؟

يُنشئ إثبات التاريخ سجلاً زمنياً مشفراً يسمح لمدققي سولانا بالاتفاق على ترتيب وتوقيت المعاملات دون تبادل رسائل طابع زمني مع بعضهم البعض. من خلال حل سؤال "متى حدث هذا" تشفيراً، يفرغ إثبات التاريخ بروتوكول Tower BFT للتركيز حصرياً على سؤال "هل هذا صالح"، مما يقلل من عبء التوافق التوافقي ويمكّن معدل معالجة المعاملات العالي في سولانا.

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

قدم أناتولي ياكوفينكو، المؤسس المشارك والرئيس التنفيذي لشركة Solana Labs، إثبات التاريخ في ورق ابيض عام 2017 بعنوان Solana: A new architecture for a high performance blockchain. قبل تأسيس Solana Labs، كان ياكوفينكو مهندس برمجيات أول في Qualcomm، حيث عمل على أنظمة التشغيل الموزعة وخوارزميات الضغط. تم إطلاق المينيت التجريبي لسولانا في مارس 2020.

معدل المعالجة النظري لسولانا هو رقم نظري تاريخي يبلغ حوالي 65,000 معاملة في الثانية تحت الظروف المثالية؛ وعادة ما يتراوح معدل المعالجة الملاحظ في العالم الحقيقي من 2,000 إلى 4,000 معاملة في الثانية (TPS). تعالج الطبقة الأساسية للإيثيريوم ما يقرب من 15 إلى 30 معاملة في الثانية، مع حلول طبقة 2 التي توسع معدل المعالجة الفعلي بشكل كبير. ميزة سرعة الطبقة الأساسية في سولانا هي ميزة هيكلية، مدفوعة بترتيب الوقت في إثبات التاريخ الذي يتيح التنفيذ الموازي وتقليل أعباء التوافق.

القيود الثلاثة الرئيسية الموثقة هي: متطلبات أجهزة المدقق العالية (أكثر من 128 جيجابايت رام، وأقراص NVMe SSD، وشبكات متعددة الجيجابايت، وتكلفة أجهزة تتراوح من 5,000 دولار إلى أكثر من 20,000 دولار) مما يخلق ضغطاً نحو المركزية باستبعاد المشاركين ذوي الموارد المحدودة؛ ومشكلات موثوقية الشبكة التاريخية، بما في ذلك انقطاع سبتمبر 2021 لمدة 17 ساعة وتوقفات الشبكة المتعددة في عام 2022 الناجمة عن هجمات البريد العشوائي وأخطاء عميل المدقق؛ والتبعية لمزامنة الساعة، حيث يمثل الانحراف الكبير في ساعة المدقق مساحة هجوم نظرية تتم إدارتها عملياً من خلال مزامنة NTP.

الحد الأقصى النظري لسولانا هو رقم نظري تاريخي يبلغ حوالي 65,000 معاملة في الثانية، كما هو موضح في ورق ابيض ياكوفينكو لعام 2017. يمثل هذا الرقم جميع ابتكارات سولانا المعمارية التي تعمل بكامل طاقتها في ظل ظروف الشبكة المثالية. يتراوح معدل المعالجة الملاحظ في العالم الحقيقي في ظل ظروف الشبكة الحية النموذجية من 2,000 إلى 4,000 معاملة في الثانية. يعكس السقف النظري التصميم المعماري؛ بينما يعكس الرقم الواقعي أداء الإنتاج.

إن Tower BFT هو آلية التصويت المرجحة بالتخزين (stake) واختيار الانقسام في سولانا المبني حول فتحات إثبات التاريخ. يصوت المدققون مع فترات قفل متزايدة، مما يجعل الأصوات المتضاربة مكلفة. لا تساوِ بين فتحة مستهدفة واحدة والنهائية الكاملة؛ تحقق من مستويات الالتزام الحالية ومتطلبات التطبيق.

الآلية المشفرة نفسها، وهي سلسلة الهاش المتسلسلة SHA-256، آمنة. لم يتم اختراق SHA-256 بنجاح مطلقاً في بيئات الإنتاج ويعتبر سليماً تشفيراً من قبل مجتمع الأمن. تعد الموثوقية على مستوى الشبكة، بما في ذلك انقطاعات عامي 2021 و 2022، مصدر قلق منفصل عن الأمن التشفيري. لم يتم اختراق سلسلة هاش إثبات التاريخ خلال أي من انقطاعات شبكة سولانا؛ كانت تلك الأحداث ناجمة عن استنفاد الموارد وأخطاء البرمجيات، وليس بسبب أي فشل في البروتوكول التشفيري.

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

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

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

كود سولانا مفتوح المصدر، مما يجعل آلية إثبات التاريخ متاحة للمشاريع الأخرى للدراسة والتكيف. في الممارسة العملية، تم دمج إثبات التاريخ بعمق في بنية سولانا الكاملة. تعتمد أنظمة Tower BFT و Sealevel و Gulf Stream جميعها على تسلسل إثبات التاريخ. يتطلب استخراج وتطبيق إثبات التاريخ على بلوكتشين مختلف إعادة إنتاج الكثير من المكونات المحيطة بسولانا لتحقيق نفس فوائد الأداء.

استكشف SOL على Bybit

يمكن للقراء مراجعة معلومات سوق SOL الحالية أو سوق التداول الفوري لـ SOL/USDT.. توفر هذه الروابط وصولاً إلى السوق ولا تثبت أن Solana أو أي محفظة أو بروتوكول تابع لـ طرف ثالث مناسب لكل قارئ.

الخلاصة: هل إثبات التاريخ (PoH) ابتكار حقيقي؟

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

إن تداعيات الأداء حقيقية؛ فميزة إنتاجية الطبقة 1 الأساسية في Solana مقارنة بسلاسل البلوكتشين الكبرى الأخرى هي ميزة هيكلية وليست عرضية، كما أن إثبات التاريخ (PoH) هو الآلية التأسيسية التي تجعل ذلك ممكناً. يجب على المستثمرين الذين يقيمون ما إذا كانت هذه الميزة مستدامة أن يوازنوها مقابل المقايضات الموثقة: متطلبات أجهزة المدققين التي تخلق ضغطاً نحو المركزية، وتاريخ موثوقية الشبكة الذي يتضمن انقطاعات خطيرة، وتصميم محسن للأداء يمنح الأولوية للإنتاجية على حساب المرونة المحافظة.

هذه المقايضات هي تحديات هندسية، وليست عيوباً جوهرية في التصميم التشفيري. إن تنفيذ QUIC وأسواق الرسوم وجودة الخدمة المعتمدة على تخزين الحصص (stake-weighted QoS) بعد عام 2022 يثبت أن الفريق الهندسي لـ Solana قد عالج حالات فشل الموثوقية الأكثر حدة. أما مسألة ما إذا كان المزيد من النضج سيجعل ملف الموثوقية متوافقاً مع وعود الإنتاجية، فهي سؤال سيجيب عليه التاريخ التشغيلي المستمر للشبكة.

يمكن للقارئ الذي استوعب هذه المقالة الآن تعريف إثبات التاريخ بدقة وشرح كيف تنتج سلسلة هاش SHA-256 سجلاً زمنياً يمكن التحقق منه. كما يمكنهم التمييز بين إثبات التاريخ (PoH) وآليات التوافق مثل إثبات الحصة (PoS)، وتوضيح سبب تمكين إثبات التاريخ لميزة الإنتاجية في Solana، وتقييم القيود الموثقة مع السياق المناسب. هذه هي الصورة التقنية المطلوبة لتقييم هيكلية Solana بناءً على مزاياها.

تعكس المعلومات الواردة في هذه المقالة الوثائق التقنية المتاحة للجمهور وهي محدثة اعتباراً من تاريخ النشر. تتغير بروتوكولات البلوكتشين ومقاييس أداء الشبكة بمرور الوقت. هذا المحتوى ليس تابعاً لـ Solana Labs أو Solana Foundation ولا ترعاه أي منهما.

قراءات ذات صلة

• آلية التوافق في Solana
• هيكلية Solana
• سرعة Solana: المعاملات في الثانية الفعلية مقابل النظرية