⚙️ ماذا يحدث فعليًا عند إرسال معاملة على Solana؟

عند الضغط على “Send” في محفظة Solana، تحدث عدة عمليات خلفية قبل أن تصبح المعاملة نهائية.

1️⃣ يتم إنشاء المعاملة

محفظتك تنشئ وتوقّع معاملة تتضمن:

• التعليمات

• الحسابات المعنية

• بصمة الكتلة الحديثة (Recent blockhash)

• التوقيع التشفيري

بعد ذلك تكون المعاملة الموقّعة جاهزة للدخول إلى شبكة Solana.

2️⃣ تدخل المعاملة إلى الشبكة

يتم إرسال المعاملة إلى عقدة Solana RPC، والتي تقوم بتمريرها عبر الشبكة باتجاه القائد (leader) المقرر حاليًا.

عُقدة RPC هي بشكل أساسي بوابة بين محفظتك/تطبيقك وشبكة البلوكشين.

3️⃣ يقوم القائد بمعالجته

تستخدم Solana مُتحقق إثبات رصيد مجدولاً (scheduled Proof-of-Stake validator) كقائد لفترة قصيرة.

يتلقى القائد المعاملات، وينفذ تعليماتها، ويتحقق من أشياء مثل:

✔️ صحة التوقيع

✔️ حالة الحساب

✔️ تعليمات البرنامج

✔️ رسوم المعاملات المطلوبة

✔️ أذونات الحساب

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

4️⃣ يسجل الإثبات التاريخي (Proof of History) التسلسل

هنا تصبح Proof of History (PoH) مهمة.

يُولّد PoH باستمرار تسلسلاً من تجزئات تشفيرية:

H0 → H1 → H2 → H3 → H4 → H5 → ...

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

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

إذن:

PoH = ساعة تشفيرية + ترتيب يمكن التحقق منه

لكن PoH نفسه لا يُنهِي المعاملة.

5️⃣ يتحقق المُتحقّقون (Validators) من البيانات

يتلقى مُتحقّقو Solana الآخرون بيانات القائد.

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

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

6️⃣ يصل Tower BFT إلى الإجماع

هنا يأتي دور Tower BFT.

Tower BFT هو آلية إجماع بنمط BFT من سولانا مبنية على إثبات الرصيد (Proof of Stake).

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

جزء مهم من Tower BFT هو مفهوم الـ lockouts.

عندما يصوّت مُتحقق (validator) على كتلة، فإن هذا التصويت ينشئ التزاماً مؤقتاً بتلك السلسلة. إذا استمر المُتحقق في التصويت على أحفاد (descendants) تلك الكتلة، يصبح lockout أطول تدريجياً.

بعبارات بسيطة:

يتلقى المُتحقّق (Validator) الكتلة

↓

يتحقق منها

↓

يصوّت لها

↓

التصويت ينشئ lockout

↓

التصويت المستمر يزيد الالتزام

↓

يتقارب المُتحقّقون على سلسلة واحدة

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

7️⃣ التأكيد → الإنهاء

مع تصويت المزيد من المُتحقّقين على السلسلة، تنتقل المعاملة عبر مراحل التأكيد (confirmation) الخاصة بـ Solana.

في النهاية، يتم التصويت بما يكفي من الرصيد للسلسلة ذات الصلة بحيث تصل الكتلة إلى حالة الإنهاء (finalized).

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

🔗 تدفق الواجهة الخلفية بالكامل (backend)

المحفظة

↓

توقيع المعاملة

↓

عُقدة RPC

↓

القائد الحالي

↓

تنفيذ المعاملة

↓

ترتيب PoH / ساعة تشفيرية

↓

التحقق من المُتحقّق (Validator)

↓

Tower BFT + أصوات مُرجّحة بالرصيد

↓

قفل (Lockouts) واتفاق الأغلبية الفائقة

↓

🔒 تم الإنهاء على Solana

التمييز المهم

PoH → تُنشئ تسلسلاً قابلاً للتحقق من الزمن والأحداث

إثبات الرصيد (Proof of Stake) → يحدد وزن تصويت المُتحقق

Tower BFT → يستخدم أصوات المُتحققين وlockouts للوصول إلى الإجماع

لذا عندما تضغط ببساطة “Send SOL”، تتضمن الواجهة الخلفية (backend) أكثر بكثير من مجرد نقل عملات من محفظة إلى أخرى.

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

#Solana #SOL #ProofOfHistory #TowerBFT #ProofOfStake #Blockchain #Web3 #CryptoTechnology #BlockchainBackend