تعرف على Raiku: طبقة الحوسبة الحافة عالية الأداء من Solana

حققت سلاسل الكتل الحديثة توسعًا كبيرًا، لكنها لم تحقق الاكتمال. فبينما تتفوق سولانا في الإنتاجية وزمن الوصول، إلا أنها لا تزال تفتقر إلى ضمانات تنفيذ موثوقة للتطبيقات عالية المخاطر. تقدم رايكو طبقة تنسيق قابلة للبرمجة تُعيد الاكتمال والقدرة على التنبؤ والثقة إلى أنظمة السلسلة دون المساس بالأداء. وبُنيت رايكو كأداة مساعدة لشبكة التحقق سولانا، وهي تُمكّن المطورين من حجز مساحة كتلة مسبقًا، وجدولة المعاملات بدقة، وتجنب فوضى تجمعات الذاكرة. تستكشف هذه المقالة كيف تُضيف رايكو ضمانات التنفيذ، ومقاومة MEV، والتأكيد المسبق إلى بنية سولانا المتجانسة، مما يوفر نظامًا لا يركز فقط على السرعة، بل أيضًا على الموثوقية في عالم مُتنافس موزع. الوضع الحالي لبنية سلسلة الكتل والحاجة إلى التنفيذ الحتمي: تتطلب الأسواق العالمية الحتمية. غالبًا ما تُقدم العملات المشفرة وعودًا فقط. البنية التحتية لسلسلة الكتل اليوم مليئة بالتنازلات الهيكلية. سعيًا وراء التوسع، بنينا أنظمة تنتهك مبادئ الحوسبة الموزعة الأساسية، بافتراض نطاق ترددي غير محدود، وتجاهل حدود زمن الوصول، وإجبار التطبيقات على استخدام نماذج حالة شائعة لا تحتاجها. والنتيجة؟ تجريدات هشة، وأداء غير موثوق، وتجربة مطور تركز على البقاء أكثر من الابتكار. تخيل أنك تطلق منتجًا ماليًا حديثًا ويُقال لك إن معاملتك قد تفشل ما لم تُرسل رسائل غير مرغوب فيها، أو تُرشي المُحققين، أو ببساطة تدعو للشمول. من المفترض أن تُجرد أنظمة بلوكتشين هذا التعقيد في نهاية المطاف، مُوفرةً بنية تحتية لامركزية فعّالة. لكن عمليًا، استبدلنا رفوف الخوادم بعقد مُحققين، مُحوّلين مخاوف زمن الوصول من الأجهزة المادية إلى ازدحام الطبقة الأولى. هذا هو الواقع اليومي لـ Web3. تُعالج إيثريوم، منصة العقود الذكية الأكثر استخدامًا، 15-30 معاملة فقط في الثانية. خلال فترات الطلب المرتفع، مثل مبادلات NFT والتصفية وموسم memecoin، تُصبح الشبكة الأساسية مُزدحمة وترتفع الرسوم بشكل كبير، مما يجعل الطبقة الثانية هي المخرج الوحيد. توفر عمليات تجميع الطبقة الثانية هذه إنتاجية هائلة مع خفض رسوم الغاز بنقل التنفيذ خارج السلسلة، ولكنها تُدخل أيضًا مقايضات جديدة: سيولة مجزأة، وربط جسور معقدة، ونماذج ثقة متمايزة، وتجربة مستخدم معيبة بعض الشيء. في الوقت نفسه، يُدخل نظام إعادة التخزين في إيثريوم نقاط ضعف أكبر. تتطلب بروتوكولات مثل EigenLayer من المُحققين الاستفادة من توافق إيثريوم الاجتماعي لحماية أنظمة الجهات الخارجية، مما يُراهن فعليًا على أن المجتمع سيُنسق عملية إنقاذ في حال ظهور أي مشاكل. حتى فيتاليك يعتبر هذا النهج محفوفًا بالمخاطر. لا يزال توسيع إيثريوم خارطة طريق لعشر سنوات. على المطورين التحرك الآن. من ناحية أخرى، تسعى سولانا إلى تصميم متجانس عالي الأداء: فهي تُركز التوافق والتنفيذ على سلسلة واحدة، مما يُتيح أوقات كتلة سريعة للغاية وتنفيذًا متوازيًا. في الواقع، يُمكن لسولانا معالجة 3000-4000 TPS بشكل روتيني على آلة الحالة العالمية الخاصة بها، وهو ما يتجاوز بكثير إنتاجية إيثريوم. يتيح هذا التصميم رسومًا منخفضة ونهاية شبه فورية في الظروف العادية. ومع ذلك، أظهرت بنية Solana أحادية السلسلة أيضًا علامات إجهاد تحت الحمل الشديد. خلال فترات ارتفاع الاستخدام، يمكن أن تواجه Solana ازدحامًا وحتى انقطاعات حيث تتنافس جميع التطبيقات اللامركزية على نفس الموارد العالمية. على سبيل المثال، تاريخيًا، أدت الزيادات الحادة في حركة المرور (مثل تلك القادمة من سك NFT الشهير أو روبوتات التحكيم) إلى توقف الكتل وفشل المعاملات. والجدير بالذكر أنه في فبراير 2024، تسبب خلل ناتج عن وقت تشغيل Solana في توقف الشبكة لمدة خمس ساعات تقريبًا. حتى عندما تظل الشبكة قيد التشغيل، غالبًا ما يواجه المستخدمون والروبوتات فشل المعاملات أو انقطاعات الوقت أثناء ذروة الطلب، مما يقوض تجربة المستخدم القوية لـ Solana. في الواقع، لاحظ المتداولون عاليو التردد على Solana معدلات فشل المعاملات تصل إلى 75٪ عندما تكون الشبكة مزدحمة. يحدث هذا لأن جدولة القادة في سولانا وأولوية جودة الخدمة (QoS) تُفضّل بعض المُصدّقين، وعندما تتدفق معاملات كثيرة جدًا، يتعذّر إدراج العديد منها في الوقت المناسب. بالإضافة إلى قيود الإنتاجية، يواجه كلا النظامين مشاكل في استخدام MEV وتنفيذها غير المتوقع. على الرغم من آلية جدولة القادة العامة، لا تزال سولانا تواجه ديناميكيات MEV الخاصة بها. تعني آلية جدولة المعاملات المُرجّحة حسب الحصة في سولانا أن كبار المُصدّقين أو مُختصي تدفق الطلبات يُمكنهم التفاوض على الصفقات، مع إعطاء الأولوية لبعض المعاملات خارج دفتر الأستاذ. يؤدي هذا النقص في الشفافية إلى مشاكل في المركزية: تحصل الروبوتات أو الشركات ذات الاتصالات الجيدة على وصول سريع، بينما يُكافح المستخدمون العاديون لمعالجة المعاملات. في حين أن سولانا قد طرحت حلولاً مثل رسوم الأولوية وJito (عميل مُتخصص في MEV) لتعزيز سوق رسوم أكثر انفتاحًا، إلا أن المشكلة الأساسية لا تزال قائمة: عندما تكون الشبكة مشغولة، يُصبح التضمين حرب مزايدة أو لعبة بين المُطلعين، مما يُترك المستخدمين العاديين في مواجهة حالة من عدم اليقين وتأخير المعاملات. من منظور الحالة، يُجزّئ نموذج إيثريوم المُركّز على التجميع التطبيقات عبر سلاسل مُختلفة. تُصبح كل عملية تجميع جزيرةً معزولةً، تتطلب جسورًا وأدواتٍ مُكررة، وافتراضاتٍ أمنيةً إضافية. عندما لا تتعايش السيولة والعقود، يضيع سحر التمويل اللامركزي - قابلية التجميع -. ما تفتقر إليه سلاسل الكتل هو قابلية التوسع، والقدرة على تجنّب ارتفاعات زمن الوصول، وتجزئة الحالة، أو فشل المعاملات. لا تزال سلاسل الكتل تفتقر إلى الدقة اللازمة للتمويل العالمي. هذا هو مجال التصميم الذي تشغله رايكو. انبثقت رايكو من سنواتٍ من الإحباط من بنية إيثريوم التحتية واحترامها العميق لبساطة تصميم النظام، وتُقدّم نوعًا جديدًا من البنية التحتية إلى سولانا، لا يُركّز على المزيد من التجميعات، بل على التنفيذ الدقيق. إنها تُوسّع جوهر سولانا من خلال توفير لبنة بناء قابلة للبرمجة - بيئة حوسبة طرفية - تُوفّر للتطبيقات مساراتٍ سريعةً مُخصّصةً، ونطاقًا تردديًا مضمونًا، وتسويةً حتميةً دون الحاجة إلى إدارة سلاسل مُنفصلة أو المساس بقابلية التجميع. إذا كان Solana هو الطريق السريع العالمي، فإن Raiku هو نظام التحكم الذكي في حركة المرور، والذي يوفر مسارات سريعة للتطبيقات التي تحتاج إليها بشدة. إنه ليس تجميعًا آخر، ولا هو سلسلة جانبية. Raiku هو إعادة تفكير في تنفيذ blockchain: سريع، معياري، قابل للبرمجة، ويمكن التنبؤ به. تم بناء النظام ليس لمطاردة الاتجاهات ولكن لتلبية احتياجات المؤسسات والمطورين والتطبيقات ذات النطاق العالمي التي تتطلب اليقين، وليس الأمل. من القيود إلى الرؤية: أصول Raiku وُلد Raiku من ملاحظة بسيطة: ليس من الضروري تشغيل جميع أحمال عمل blockchain في نفس المطبخ المزدحم. في أواخر عام 2023، بدأت مجموعة من الباحثين وقدامى Solana في التساؤل عن كيفية تفريغ العمليات الحسابية الثقيلة من الطبقة 1 من Solana دون فقدان ميزة السلسلة. في البداية كان مشروعًا بحثيًا (بدعم من Super Team ومؤسسة Solana)، ونبعت المبادرة من إحباطهم من ركود البنية التحتية التي تركز على Ethereum. على الرغم من غنى نظام إيثريوم البيئي بالطبقات الثانية، إلا أنه لم يحقق القفزات النوعية في الأداء أو خبرة المطورين التي كان يأملها الباحثون. كانت عمليات التجميع تُحرز تقدمًا تدريجيًا، لكنها لا تزال تعتمد على طبقة أساسية بطيئة ومزدحمة نسبيًا. في المقابل، تُمثل سولانا فرصة لتجربة شيء مختلف: فطبقتها الأولى (L1) سريعة بالفعل، وتُثبت إمكانية إنشاء سلاسل كتل على نطاق الويب، ولكن يُمكن أيضًا تحسينها من خلال تحسين بنيتها. أشار فريق رايكو إلى أنه بحلول يناير 2024، كانت العديد من تطبيقات سولانا "تتجه بشكل طبيعي" نحو هياكل التوسع. بمعنى آخر، كانت المشاريع تحاول بناء عمليات تجميع صغيرة خاصة بها أو طبقات تنفيذ معزولة لزيادة إنتاجية الطبقة الأساسية. ونظرًا لعدم وجود إطار عمل رسمي، حاولت بعض الفرق إعادة استخدام أدوات مثل Sovereign SDK (للسلاسل المستقلة) لإنشاء امتدادات أو عمليات تجميع. كانت النتائج أقل من مثالية: فقد أدى سوء استخدام أطر التجميع القائمة على إيثريوم على سولانا إلى ضعف الأداء ومشاكل كبيرة. أدى كل مشروع يُطلق امتداده الخاص إلى تجزئة الحالة (مع الأخذ في الاعتبار جميع مشاكل إيثريوم تقريبًا) وتكرار الجهود. علاوة على ذلك، فشلت هذه الحلول الذاتية في التكامل بسلاسة مع تصميم سولانا، حيث واجهت قيودًا في معدل نقل البيانات، وقيودًا زمنية، وعدم القدرة على مشاركة الحالة أو الحسابات مع الطبقة الأولى. يُبرز هذا النمط مشكلة تصميمية واضحة: تحتاج سولانا إلى إطار عمل مُصمم خصيصًا للتوسع، وليس إطارًا مُدمجًا من مصدر آخر. شرع الفريق المؤسس لرايكو، بقيادة روبن أ. نوردنس وآخرين، في معالجة هذه المشكلة من خلال بناء طبقة "حوسبة حافة" مرتبطة ارتباطًا وثيقًا بسولانا. بعد دراسة طبقات L1 جديدة أخرى، مثل Aptos وSui، اختاروا سولانا، إيمانًا منهم بأنها في وضع فريد لدعم رؤيتهم. تتمتع سولانا بقاعدة مستخدمين كبيرة، ومجتمع مطورين قوي، وبنية تحتية متينة (غالبًا ما تُقارن بالأيام الأولى السريعة التطور لإيثريوم). الأهم من ذلك، أن قيادة سولانا ونظامها البيئي منفتحان على الابتكار، حيث يُصدر المطورون الأساسيون تحديثات كل بضعة أسابيع ويتطلعون بشغف إلى أساليب التوسع الجديدة. لم تكن الفكرة إطلاق طبقة L1 مستقلة أخرى أو إنشاء شريحة منفصلة تمامًا، بل توسيع نطاق سولانا بطريقة متكاملة. وكما قال أحد أعضاء الفريق: "لسنا L2، لسنا L1... نحن في مكان ما بينهما". وبشكل أكثر رسمية، تُقدم رايكو نفسها كبنية بناء كتل، وهي بروتوكول بنية تحتية يربط بين المُتحققين والتطبيقات والسلسلة الأساسية لتنظيم تنفيذ عالي الأداء، متجاوزًا ما يمكن أن توفره الطبقة الأساسية نفسها. إذا كانت سولانا L1 بمثابة الطريق السريع، فإن رايكو تُنشئ المسارات السريعة وأنظمة التحكم في حركة المرور، مما يُمكّن بعض التطبيقات من العمل بشكل أسرع وأكثر قابلية للتنبؤ عند الحاجة. من الأفكار الرئيسية في تصميم رايكو أن العديد من التطبيقات اللامركزية عالية النطاق لا تحتاج إلى التفاعل المستمر مع الحالة العالمية بأكملها. يمكن لبعض التطبيقات العمل بشكل مستقل إلى حد كبير (باستخدام دفاتر أوامرها أو منطق محرك اللعبة الخاص بها)، طالما أنها تستطيع أحيانًا الاستقرار في السلسلة الرئيسية والاستفادة من أمانها وسيولتها عند الحاجة. وكما أوضح نوردنس، "معظم حالات الاستخدام ذات إمكانات التوسع الكبيرة لا تتطلب دائمًا إمكانية تكوين الحالة". يمكنك وضع تطبيقك في بيئة تشغيل خاصة به (مثل الطبقة الثانية) مع الاستفادة في الوقت نفسه من مزايا السلسلة الرئيسية المتمثلة في نهائية التسوية، وحسابات المستخدمين المشتركة، وبيانات الأسعار على السلسلة، وأمان الأصول. تُشكل هذه الرؤية أساس بنية Raiku: فهي تسعى جاهدة لتزويد التطبيقات ببيئة تنفيذ مستقلة خاصة بها (حتى لا تُعيقها بيئات أخرى) مع الحفاظ على مزايا الطبقة الأولى في Solana (مساحة موحدة للأصول والهويات، وطبقة تسوية عالية الأداء). في عالم الإيثريوم، يُمكن بذل محاولات لتحقيق أهداف مماثلة من خلال إطلاق Optimistic Rollup أو ZK Rollup، ولكن كما يُشير الفريق، "يمكنك بناء طبقة ثانية في الإيثريوم، لكنك ستظل مُقيدًا بشدة بالطبقة الأولى الأساسية". حتى أفضل طبقة تجميع محدودة بمعدل نقل بيانات الإيثريوم، وزمن الوصول، والجدول الزمني للترقية (سيستغرق إصلاح الطبقة الأولى عقدًا من الزمن). بدلًا من الانتظار، رأى فريق Raiku فرصةً للاستفادة من نقاط قوة Solana الحالية والابتكار بناءً عليها. سيُقدم Raiku طبقة جديدة تعمل بالتوازي مع إجماع Solana، تُشغّلها (وتتوافق اقتصاديًا مع) مجتمع المُصادقين، لتنسيق قدرات التنفيذ المُتقدمة. رؤيته جريئة: الاستفادة من أنظمة Web2 وTradFi (مثل AWS أو NASDAQ) لجعل التطبيقات على السلسلة "أسرع وأكثر موثوقية وأكثر تنافسية في السوق" دون المساس باللامركزية. بحلول أوائل عام 2024، اكتسبت هذه الرؤية زخمًا واسع النطاق. أصبح مفهوم التوسع في سولانا موضوعًا ساخنًا، واستقر المجتمع في النهاية على استخدام مصطلح "توسع الشبكة" بدلًا من "المستوى الثاني" للتأكيد على التوسع على المستوى الأول بدلًا من تقسيمه. وأصبح رايكو أحد المشاريع الرائدة في تطبيق هذا المفهوم. من الناحية الفنية، يُشبه التوسع التجميع أو السلسلة الجانبية، وهو مصطلح ربما يُقلل من شأن الإمكانيات التي يبنيها فريق رايكو. اعتمدت رايكو مصطلح "الحوسبة الطرفية" لوصف منطقة التنفيذ الخاصة بها. مصطلح "الحوسبة الطرفية" مُستعار من تكنولوجيا المعلومات التقليدية (يشير إلى الحوسبة التي تُجرى على حافة الشبكة، أقرب إلى حيث الحاجة). بيئة الحوسبة الطرفية في رايكو ليست سلسلة كتل مستقلة تُنافس سولانا، بل هي منطقة تنفيذ معيارية على حافة شبكة سولانا، مُصممة خصيصًا للتعامل مع أحمال عمل مُحددة بأداء مُحدد. يتردد صدى هذا المصطلح لدى فرق البنية التحتية لـ Web2 والجهات الفاعلة المؤسسية، مما يُسهم في سد الفجوة المفاهيمية بين التجميع وخوادم الحافة المألوفة. بشكل أساسي، توفر Raiku بيئات مخصصة شبيهة بـ Rollup (امتدادات) مدمجة في منطقة حوسبة الحافة في Solana. يمنح هذا المطورين استقلالية في التنفيذ - أي حرية تشغيل منطقهم وجدولهم الزمني الخاص دون عناء إطلاق سلسلة جديدة تمامًا أو توزيع المستخدمين عبر النظام البيئي.

إعادة تعريف التجميعات: من "الامتدادات" إلى "بيئات الحوسبة الحافة"

تجدر الإشارة إلى أن Raiku تُعيد صياغة مشهد بيئات التنفيذ المخصصة. في دوائر Solana، يُستخدم مصطلح "الامتدادات" لوصف هذه التجميعات المخصصة من Solana. ومع ذلك، يعتقد فريق Raiku أن هذا المصطلح ضيق نوعًا ما (بل ووصم بسبب محاولات مبكرة وغير مدروسة). ولجذب انتباه كل من جمهور العملات المشفرة وWeb2 التقليدي، لا يقتصر Raiku على مجرد التوسع؛ بل يبني "بيئة حوسبة حافة". مع بيئة الحوسبة الحافة الخاصة بشركة Raiku، لم نعد ننظر إلى شبكة الطبقة 2 كإضافة خارجية أعلى شبكة الطبقة 1 (L1)، ولكن كجزء لا يتجزأ من بنية الشبكة وشبكة الطبقة 1 (مناطق التنفيذ المعيارية الخاصة بشركة Raiku هي امتداد للطبقة 1 (L1)، وتقع على حافة الشبكة، بالقرب من المستخدمين والتطبيقات. تسمي Raiku هذه "مناطق التنفيذ المعيارية"، مؤكدة على أنه يمكن توصيل وحدات مختلفة (كل وحدة هي وقت تشغيل/آلة افتراضية للتنفيذ) بنظام موحد. تسمح مناطق التنفيذ المعيارية هذه للمطورين بتوصيل أوقات تشغيل تنفيذ مختلفة أو آلات افتراضية مخصصة بنظام موحد، مما يمنحهم تحكمًا لا مثيل له في منطق التطبيق الأساسي. يعتقد فريق Raiku أن الأداء على نطاق واسع لا يتم تعلمه، ولكنه مدمج من الألف إلى الياء. تبدأ Raiku من حيث تتوقف التقنيات الأخرى: من خلال اختراق الحدود المادية للشبكات الموزعة، مثل النطاق الترددي والجغرافيا والقيود الزمنية. على وجه التحديد، توفر Raiku: موثوقية النظام التي تحافظ على التشغيل القوي حتى في ظل الحمل الشديد و الضغط. يضمن التنفيذ الحتمي نتيجة متوقعة لكل معاملة. من خلال وضع قدرات الحوسبة الطرفية عالية الأداء (HPEC) مباشرةً على حافة شبكة Solana، يتم تحقيق زمن وصول منخفض، مما يتيح معالجة المعاملات في غضون مللي ثانية. يمكن للمطورين تخصيص منطق المستوى المنخفض بحرية، مما يوفر مرونة وتحكمًا لا مثيل لهما. ينسق محرك التنسيق Raiku المعاملات بدقة، مما يضمن إرسالها وجدولتها وتأكيدها بسرعة، مدعومًا بسوق قوي لمساحة الكتلة المتقدمة لضمان تضمين المعاملات (المزيد حول هذا في قسم لاحق). تدعم إضافات Validator كلاً من التنفيذ المسبق (AOT) والتنفيذ الفوري (JIT). إلى جانب أدلة البث، تتيح هذه الإضافات التأكيد المسبق الفوري للمعاملات، مما يحول تفاعلات اليوم غير الموثوقة التي تتطلب أفضل جهد إلى تنفيذ موثوق وقابل للجدولة. بيئات الحوسبة الطرفية ذات مغزى حقيقي. إنها تساعد على التمييز بشكل سرديّ بين نهج Solana ونهج Ethereum: يستخدم Ethereum "Layer-2 Rollups"، بينما يستخدم Solana (عبر Raiku) "الحوسبة الطرفية". تعني الأخيرة التحسين، وليس الفصل. وهو مصطلح يفهمه التمويل التقليدي. في حوسبة المؤسسات، تُعد الحوسبة الطرفية مفهومًا إيجابيًا، إذ تعني أوقات استجابة أسرع من خلال تقريب الحوسبة إلى حيث تكون مطلوبة. تقول رايكو: "نحن نقرب التنفيذ من التطبيق (منطقيًا)، مع الحفاظ على ارتباطه بالشبكة الرئيسية". لذلك، سنستخدم في هذا التقرير مصطلحات "بيئة الحوسبة الطرفية" و"الامتداد" و"منطقة التنفيذ المعيارية" بالتبادل لتعكس تفاصيل فلسفة رايكو. في المستقبل، مع إطلاق الشبكة الرئيسية لرايكو وزيادة اعتمادها في السوق، قد ترى أن "الحوسبة الطرفية لرايكو" أصبحت مصطلحًا ذا علامة تجارية، مثل "السلسلة الفرعية" في بولكادوت أو "الشبكة الفرعية" في أفالانش. كما يُسهّل هذا المصطلح التعبير عن الميزات الجديدة: على سبيل المثال، يمكن لرايكو أن تقول: "انشر بيئة الحوسبة الطرفية الخاصة بك على سولانا في غضون أسبوع"، وهو ما يبدو تمامًا مثل إعداد بيئة سحابية، وبالتالي فهو مألوف للمطورين. من خلال التركيز على "الحوسبة الطرفية" "الحوسبة"، يتماشى Raiku مع اتجاه أوسع في البنية التحتية للويب: لزيادة السرعة، يقترب المنطق من المستخدمين (شبكات الحافة، شبكات توصيل المحتوى، إلخ)، إلا أن "المستخدم" هنا يشير إلى معاملات التطبيق، بينما تشير الحافة إلى منطقة خاصة داخل الشبكة. هذا تشبيه قوي يساعد المزيد من الناس على فهم كيفية اختلاف Raiku عن اختراقات التوسع العادية. يتبع تصميم Raiku عدة مبادئ رئيسية: لا تتطلب جميع التطبيقات اللامركزية حالة عالمية ثابتة: يمكن لبعض التطبيقات ذات الإنتاجية العالية (البورصات، الألعاب، شبكات الدفع) العمل في بيئات معزولة لمعظم أنشطتها، باستخدام السلسلة الرئيسية فقط عند الحاجة. يعالج Raiku هذا الوضع من خلال توفير عزل اختياري، مما يحرر هذه التطبيقات من التنافس العالمي على مجموعات الذاكرة مع السماح لها بالوصول إلى السيولة/الحالة من الطبقة الأولى عند الحاجة. يتناقض هذا مع فلسفة Ethereum DeFi، حيث تتشابك كل شيء بشكل كبير على سلسلة واحدة (وهي فلسفة قوية، ولكنها غير قابلة للتوسع عندما يتطلب كل تطبيق صغير قابلية تجميع ذرية عالمية). يدرك Raiku أن السياق أو الزمان... القدرة على التركيب (عند الحاجة فقط) كافية في كثير من الحالات، مما يؤدي إلى تحسينات كبيرة في الأداء. الحفاظ على شعور الشبكة الواحدة: على الرغم من إدخال التقسيم المعياري، تسعى Raiku جاهدةً لتجنب تحديات تجربة المستخدم التي تواجهها السلاسل المتعددة. تضمن الحسابات العالمية ومحرك التنسيق بقاء Solana شبكة واحدة من منظور المستخدم. لا حاجة لإدارة رموز متعددة على سلاسل/أقسام مختلفة لتغطية تكاليف الوقود، ولا حاجة لتبديل نقاط نهاية RPC يدويًا. تتفاعل مع Solana، وفي الخلفية، يوجه Raiku معاملاتك إلى سلسلة امتداد أو السلسلة الرئيسية، حسب الحاجة. يتناقض هذا تمامًا مع نموذج سلسلة تطبيقات Cosmos، أو حتى بنية الطبقة الثانية في Ethereum، حيث يعني اعتماد سلسلة جديدة رمزًا جديدًا، ومستكشف كتل جديد، وتغييرًا في طريقة التفكير. تعمل مناطق الحوسبة الطرفية في Raiku كـ "امتدادات شبكة" أكثر من كونها شبكات مستقلة، مما يشير إلى أنها توسع Solana بدلاً من منافستها. تكمن الميزة المعمارية في الحفاظ على تأثيرات الشبكة: حيث تظل فائدة رمز SOL داعمة. (الرسوم، التخزين)، ومجتمع سولانا ليس مجزأً إلى عشرات السلاسل الأصغر. يُعالج هذا انتقادًا شائعًا لخارطة طريق إيثريوم المُركزة على التجميع: وهو أن إيثريوم تُخاطر بأن تصبح مجرد طبقة تسوية بينما ينتقل نشاط المستخدم إلى رموز وأنظمة بيئية مُختلفة من الطبقة الثانية، مما قد يُضعف الأمن الاقتصادي لإيثريوم. يزيد نهج رايكو من السعة ويُدمجها تحت مظلة سولانا الاقتصادية. استفد من الأمان الحالي، لا تُعيد ابتكاره: لا تُنشئ رايكو آلية إجماع أساسية جديدة ولا تُلزم المستخدمين بتفويض الأموال إلى مجموعة جديدة تمامًا من المُصادقين (في الواقع، لا تحتفظ رايكو بالأموال؛ تبقى الأصول على سولانا). يُوفر هذا مزايا كبيرة مُقارنةً بإطلاق سلسلة تطبيقات ذاتية الاستضافة أو طبقة أولى جديدة. إذا اختار مشروعٌ ما إطلاق سلسلته الخاصة اليوم (سواءً من خلال مجموعة أدوات تطوير البرمجيات كوزموس، أو شبكة فرعية أفالانش، أو تجميع ذاتي)، فإنه يُواجه مهمةً شاقةً تتمثل في تمهيد المُصادقين، وتحفيزهم (عادةً من خلال التضخم). مكافآت التوكنات الجديدة)، وتأمين جسور للتواصل مع الأنظمة البيئية الأخرى. تُبسط Raiku هذه العملية بالاعتماد على مجتمع مُصادقي Solana والربط محليًا عبر حساب عالمي. لا حاجة لعقد جسر مُنفصل؛ فالامتداد جزءٌ منطقي من Solana. يُقلل هذا بشكل كبير من مخاطر الأمان وتكاليف التطوير مُقارنةً بنهج السلسلة السيادية. على سبيل المثال، حاولت بعض الفرق استخدام Sovereign SDK على Solana، مما أدى في النهاية إلى تجزئة الحالة وضعف الأداء لعدم تصميمه لحالة استخدام Solana. يتجنب حل Raiku المُخصص هذه المشاكل ويُعزز إعادة استخدام مكونات Solana المُجربة (مثل الشبكة، وحوافز المُصادق، إلخ). القدرة على التنبؤ والشفافية كميزات أساسية: يُقدّر كلٌ من المُنشئين والمستخدمين معرفة ما سيحدث في المستقبل. تُطبّق Raiku القدرة على التنبؤ على مستوى البروتوكول. يُزيل تضمين الإشارات التخمين من عملية إرسال المعاملات. تصميم MEV يجعلها أكثر كفاءة (لا يوجد تجمع ذاكرة خاص؛ تُجرى جميع المعاملات من خلال المزادات أو قنوات معروفة). هذا يُعزز نظام بيئي أكثر صحة. على منصة إيثريوم، ورغم التحسينات، لا يزال المستخدمون قلقين بشأن استهدافهم من قِبل روبوتات المراجحة عند إرسال معاملات Uniswap. أما على منصة سولانا، فيقلق المستخدمون بشأن "عدم اكتمال" المعاملات عندما تكون الشبكة مشغولة. تهدف رايكو إلى إزالة هذه المخاوف وجعل تقنية البلوك تشين، في أفضل حالاتها، موثوقة و"مملة"، مثل بنية أمازون ويب سيرفيسز (AWS) - فإذا قمت بجدولة مهمة، فأنت تثق في أنها ستعمل في الوقت المحدد. تُعد هذه نقطة جذب رئيسية لكل من التبني المؤسسي (الذي يتطلب اتفاقيات مستوى الخدمة (SLA) والقدرة على التنبؤ) والاستخدام الجماعي للمستهلكين (لا أحد يرغب في إرسال أوامر "إرسال" باستمرار على أمل نجاح المعاملة). حالات استخدام واقعية مُمكّنة بتصميم حوسبة الحافة من رايكو. ما الذي يمكن للمطورين فعله بالفعل باستخدام رايكو ولم يكن ممكنًا من قبل؟ الإجابة: بناء تطبيقات على السلسلة بسرعة وضمانات الأنظمة خارج السلسلة، ونشر أنواع جديدة من الخدمات على سولانا التي ربما كانت تتطلب سابقًا سلاسل منفصلة أو حلولًا مركزية. دعونا نستكشف بعض حالات الاستخدام التوضيحية التي تصورها فريق ومجتمع رايكو، مع تسليط الضوء على كيف يمكن لنهج حوسبة الحافة أن... كن فعّالاً: التداول عالي التردد والبورصات (باستخدام بروتوكول سويفت من دريفت كمثال): دريفت منصة رائدة لتداول المبادلات الدائمة، مبنية على سولانا، وتعالج أحجام تداول هائلة. في أوائل عام 2025، أطلقوا بروتوكول سويفت، وهو محرك مطابقة على السلسلة، يتميز بزمن وصول منخفض للغاية، مبني مباشرةً على سولانا. يخزن هذا المحرك سجل الطلبات ومنطق المطابقة على السلسلة، ثم يوجه الصفقات المكتملة إلى مبادلات دريفت الدائمة للتسوية. على الرغم من ابتكار سويفت، إلا أنه يواجه قيدًا: عندما تحتاج هذه الصفقات المتطابقة إلى التسوية على الطبقة الأولى من سولانا، فإنها تخضع لظروف الشبكة النموذجية، وقد تواجه تأخيرات أو تعارضات (خاصة في الأسواق المتقلبة ذات العديد من البورصات النشطة). دخول رايكو: يمكن للمنصات اللامركزية مثل دريفت نشر ملحقات حوسبة حافة متخصصة لمحركات التداول الخاصة بها. في هذا الملحق، يمكن مطابقة الطلبات على السلسلة (في الملحق) بدقة ميكروثانية، وتسويتها فورًا، أسرع بكثير من وقت كتلة سولانا البالغ 400 مللي ثانية. باستخدام آلة دعم موجهة خفيفة مُحسّنة لـ التداول، يُمكن لهذه الإضافة إنجاز آلاف العمليات في الثانية (مثل مطابقة أسعار العطاءات والطلبات، وتحديث مراكز المتداولين) بجدولة حتمية. والأهم من ذلك، باستخدام ميزة التضمين المضمونة في Raiku، بمجرد مطابقة أي صفقة، يُمكن جدولتها للتسوية في كتلة Solana التالية دون أي شك. لا مزيد من التسابق مع الزمن أو انتظار إضافة صفقة؛ تسوية الصفقة محجوزة ومؤكدة مسبقًا. البنية التحتية للمدفوعات والتكنولوجيا المالية (مثل المدفوعات "المشابهة لـ Stripe"، Squads): تتطلب تطبيقات الدفع إنتاجية عالية وموثوقية عالية. تخيل سيناريو مثل Stripe على Solana، وهي خدمة تُعالج آلاف المعاملات في الثانية للتجار، وكشوف الرواتب، والمدفوعات الصغيرة، وغيرها. في الطبقة الأولى من Solana، هذا ممكن نظريًا (نظرًا لارتفاع TPS)، ولكن عمليًا، إذا كانت الشبكة مزدحمة أو استهلكت عملية واحدة في عملية دفع عددًا كبيرًا من وحدات الحوسبة، فقد تتعطل العمليات الأخرى. باستخدام Raiku، يُمكن إنشاء امتداد دفع، وهو في الأساس منطقة مخصصة (حوسبة الحافة) لـ معاملات الدفع. يمكن تحسين هذا الامتداد لعمليات تحويل الرموز البسيطة، ويتضمن بيئة متخصصة/مُحسّنة أو آلة دعم افتراضية خفيفة الوزن لتحقيق أقصى قدر من الكفاءة. من خلال حجوزات النطاق الترددي لـ Raiku، يمكن لمشغلي الدفع (مثل مُصدري العملات المستقرة أو منصات العملات الرقمية للبنوك المركزية) حجز معدل نقل بيانات باستمرار، على سبيل المثال، 500 نقطة في الثانية، لضمان سير معاملاتهم بسلاسة، بغض النظر عن الطلب الخارجي. يتلقى المستخدمون الذين يرسلون الأموال تأكيدًا فوريًا (بدون تأخير في المعاملات). للاستخدام المؤسسي أو المؤسسي، يمكن لـ Raiku تمكين شبكات التسوية الخاصة على Solana: "قنوات تسوية خاصة بين المؤسسات المالية الكبرى ذات نهائية حتمية وتدفقات مشفرة". تخيل أن تقوم بنوك كبيرة بتسوية تداولات العملات الأجنبية أو الأوراق المالية على سلسلة كتل Solana مشتركة. يمكن أن يكون لديهم امتداد Raiku خاص بهم، مع معاملات مرئية فقط للأطراف المعنية (مشفرة ولكن لا تزال قابلة للتحقق) وضمان نهائية مضمونة. سيفتح هذا المجال لحالات استخدام مثل المدفوعات عبر الحدود، والتحويلات المالية، أو التسويات بين البنوك على سلسلة كتل عامة، مع توفير إمكانية التنبؤ التي توفرها SWIFT أو FedWire. من جانب المستهلك، أدوات مثل يمكن لـ SquadX (أداة Solana الشائعة للتوقيعات المتعددة والتنسيق) استخدام Raiku لضمان تنفيذ معاملات التوقيعات المتعددة (التي قد تتضمن تعليمات متعددة) بكفاءة حتى خلال أوقات الذروة على الشبكة. من أبرز نقاط الضعف التي تواجهها صناديق DAO أو عمليات التوقيعات المتعددة هي محاولة تنفيذ معاملة معقدة وفشلها بسبب مشاكل في الشبكة. يتخلص Raiku من هذه المشكلة بتخصيص فترة زمنية محددة بعد موافقة جميع الموقعين عليها، مما يسمح بإكمال معاملات التوقيعات المتعددة تلقائيًا.

علاوة على ذلك، ومن خلال تكامل السيولة الشبيه بـ RFQ، يمكن لـ Raiku تمكين نماذج دفع جديدة: على سبيل المثال، يمكن لتطبيقات الدفع اللامركزية الاستعلام من صناع السوق عبر نظام Raiku RFQ للحصول على أفضل سعر صرف لمعاملات مبادلة العملات، كل ذلك ضمن امتداد واحد دون انزلاق أو قيمة متوسطة (MEV). وعلى غرار طريقة Stripe في توجيه المدفوعات عبر مختلف البنوك لتحسين الرسوم ومعدلات النجاح، يسمح Raiku بتوجيه مدفوعات العملات المشفرة إلى مصادر سيولة مختلفة بطريقة مُتحكم بها وحتمية. بروتوكولات وخدمات التمويل اللامركزي (DeFi). (خارج التداول): بعيدًا عن البورصات، يمكن للعديد من بروتوكولات التمويل اللامركزي (DeFi) الاستفادة من بيئة الحوسبة الطرفية من Raiku. يمكن لمنصات الإقراض استخدامها لإجراء عمليات تصفية فورية عبر قنوات مخصصة (حتى أن Raiku تُمكّن "إدارة المخاطر الآلية بدقة متناهية"، مما يعني أن بروتوكولات الإقراض يمكنها مراقبة المراكز وتنفيذ معاملات التصفية ضمن نوافذ زمنية مضمونة، مما يُقلل من الديون المعدومة). يمكن لمنصات الخيارات والمشتقات استخدام مناطق الحوسبة الطرفية كمراكز تنسيق لتنسيق استراتيجيات معقدة ومتعددة المراحل عبر المنصات، مع ضمان Raiku تنفيذ جميع المراحل تلقائيًا ضمن أطر زمنية متواصلة. على سبيل المثال، يمكن لبورصة الخيارات اللامركزية (DEX) ضمان تنفيذ كلا الصفقتين بالتتابع عند قيام المستخدم بتجديد عقده (إغلاق مركز خيار وفتح آخر)، مما يضمن تقلبات أسعار متواصلة. هذا المستوى من التحكم متاح حاليًا فقط في الأنظمة المركزية. يمكن لمُصدري العملات المستقرة أيضًا الاستفادة: تخيل استخدام USDC لامتداد Raiku لإعطاء الأولوية لعملية سك/استرداد العملات عالية الحجم، مما يضمن عدم ازدحام الشبكة أو تفوق عمليات الاسترداد الكبيرة. من خلال تخصيص كتلة مساحة، يمكنها الحفاظ على سلاسة التشغيل حتى في فترات الضغط. منصات CEX/DEX الهجينة والوصول المؤسسي: تتمتع Raiku بالقدرة على طمس الخط الفاصل بين البورصات المركزية والتمويل اللامركزي (DeFi). تسمح بنيتها بنموذج مشابه لـ"منطقة التمويل اللامركزي المنظمة"، حيث تشارك فيها فقط الكيانات التي تم التحقق من صحتها من خلال KYC (مثل المؤسسات)، مما يضمن الامتثال مع الاستمرار في التسوية على Solana. يلمح الموقع الإلكتروني إلى "بورصة هجينة مركزية/لامركزية مع تجربة مستخدم فائقة"، حيث يتم توفير السيولة من خلال بورصة مركزية (أو اتحاد)، ولكن تتم تسوية الصفقات على امتداد شبكة عامة. بالاستفادة من الحوسبة الطرفية، يمكن لهذه المنصة أن توفر سرعة البورصة المركزية (محرك مطابقة على أجهزة مخصصة) مع مزايا الشفافية والحفظ التي توفرها DeFi (المستقرة على Solana). التطبيقات غير المالية (الألعاب الفورية، والتواصل الاجتماعي، ووكلاء الذكاء الاصطناعي، وإنترنت الأشياء): بينما يبدو أن تركيز Raiku الأولي ينصب على التمويل اللامركزي والأسواق المالية، إلا أن إطار العمل لديه مجموعة واسعة من التطبيقات. بالنسبة للألعاب الفورية أو العوالم الافتراضية، يمكن لـ Raiku دعم الإضافات التي تتعامل مع تحديثات سريعة لحالة اللعبة (تخيل لعبة سريعة الوتيرة تعمل بالكامل على السلسلة؛ تضمن آلية جدولة Raiku إتمام العمليات ضمن نظام توقيت دقيق). بالنسبة للشبكات الاجتماعية أو تطبيقات المراسلة على Solana، يمكن لـ Raiku توفير الإنتاجية اللازمة للتعامل مع ارتفاع النشاط (على سبيل المثال، يمكن للإضافات معالجة منشور شائع يُولّد آلاف الردود دون إرهاق السلسلة الرئيسية). تشير حالات استخدام الموقع صراحةً إلى "وكلاء الذكاء الاصطناعي، وDePIN، والشبكات الاجتماعية، والبنية التحتية للدفع، وأسواق رأس المال، والتداول عالي التردد، والإنترنت على Solana". تشير هذه الرؤية الشاملة إلى أن Raiku ترى نفسها قادرة على دعم أي تطبيق عالي الطلب قد تجد سلاسل الكتل اليوم غير قادرة على التوسع أو التعامل معه. على سبيل المثال، يمكن لوكلاء الذكاء الاصطناعي الذين يُجرون عشرات العمليات على السلسلة في الثانية (مثل المشاركة في المزادات، وإعادة موازنة المحافظ، وما إلى ذلك) الاستفادة من Raiku للتعامل مع هذه العمليات بشكل موثوق. عادةً ما يتطلب DePIN (مشروع مشابه لـ Helium أو مفهوم Uber/Airbnb اللامركزي) عددًا كبيرًا من المعاملات الصغيرة و... التفاعلات، ويمكن لـ Raiku ضمان تخصيص أجهزة إنترنت الأشياء لمعدل نقل بيانات ثابت لتسجيل البيانات أو تسوية المدفوعات باستمرار.

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

نهج Raiku المبتكر: فصل التنفيذ والإجماع من أجل أداء متوقع

تقدم Raiku بنية جديدة لبناء الكتل تُحسّن طبقة Solana الأساسية من الداخل. ويتم ذلك من خلال تمكين التنسيق القابل للبرمجة، مما يمنح المحققين والتطبيقات تنفيذًا أكثر دقة دون الحاجة إلى آلية إجماع منفصلة أو بيئة مجزأة.

يمكننا تخيل شبكة Raiku كطبقة تنفيذ متخصصة تعمل في بالتوازي مع سلسلة Solana الرئيسية، مدفوعةً بمجموعة المُحققين نفسها، ويمكن ربطها ببساطة بتشغيل Raiku Sidecar. هذا يُحرر منطق التطبيق المُكثف من التنافس على كامل حركة مرور Solana، لكن Raiku ليس جزيرةً معزولة، بل مُتزامنٌ بشكلٍ وثيق مع Solana لضمان النهائيية وتوافر البيانات. على عكس الأنظمة البيئية الأخرى التي لا تزال تُعاني من مُفاضلات الوحدات النمطية أو نماذج التنفيذ المُجزأة، تُوفر Solana طبقةً أساسيةً مُتجانسةً وعالية الأداء. تُوفر أوقات كتلة أقل من الثانية، ورسومًا منخفضة للغاية، وتنفيذًا مُتوازيًا عبر Sealevel. هذه الميزات تجعلها سلسلة الكتل الأكثر ترجيحًا لتطبيق مفاهيم مثل مزادات الكتل في الوقت المُناسب (JIT) أو مُسبقًا (AOT) على نطاق واسع دون تكبد زمن وصول عالٍ. في حين أن Solana تُحقق أوقات كتلة سريعة، ورسومًا منخفضة، وتنفيذًا مُتوازيًا عبر Sealevel، إلا أن عملية بناء الكتل الحالية لا تزال تُعاني من بعض القيود: لا تزال ربحية المُحقق مُتقلبة، وتعتمد بشكل كبير على دعم التضخم المحلي وارتفاعات MEV العرضية.

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

يظهر تنسيق خارج البروتوكول، مع تدخل بروتوكولات مثل Jito لمعالجة نقص آليات المزاد القوية وضمانات التنفيذ المجمعة.

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

يتطور إطار Solana للحوافز والإطار الاقتصادي بسرعة، مسترشدًا بسلسلة من وثائق تحسين Solana الرئيسية (SIMD). تُعيد هذه المقترحات صياغة حوافز المحققين الأساسية، وتحديد أولويات المعاملات، وتوزيع المكافآت، مما يضع الأساس لبيئة أكثر تنافسية ومتانة. النظام البيئي:

• SIMD-0096: إعادة توجيه 100% من رسوم الأولوية إلى جهات التحقق، مما يزيد ربحية جهات التحقق بشكل كبير ويمنع المعاملات خارج الشبكة. SIMD-0123: تقديم آلية بروتوكول أصلية وقابلة للتطوير لجهات التحقق لتوزيع المكافآت مباشرةً على أصحاب المصلحة، مما يعزز الاتساق الاقتصادي والشفافية. SIMD-0228: سيتم طرح جدول إصدار ديناميكي مدفوع بالسوق، مع تعديل معدل التضخم بناءً على المشاركة في الرهان لتحسين الكفاءة الاقتصادية والأمان. (مع ذلك، لم يحقق الاقتراح أغلبية الثلثين المطلوبة في تصويت مارس 2025، ولم يُطبق بعد). في حين تركز هذه التغييرات على مواءمة الحوافز، فإنها تزيد أيضًا من المنافسة بين جهات التحقق، مما يدفعها للبحث عن مصادر جديدة للإيرادات الخارجية، وهو أمر بالغ الأهمية خلال أسواق الهبوط عندما تتناقص فرص MEV ورسوم الأولوية. يُرسي التطور المستمر لهيكل سوق سولانا الأساس لمحرك التنسيق الخاص بـ Raiku، المصمم لتنفيذ لامركزي موثوق، وقابل للتنبؤ، وعالي الأداء. فوائد هذا الفصل بين التنفيذ والإجماع عميقة. أولاً، تضمين الكتل بشكل متوقع: بينما قد تبقى معاملات المستخدمين عادةً في مجموعة الذاكرة أو قائمة الانتظار، على أمل تضمينها في الكتلة التالية (أو استبعادها بسبب زيادة في الحمل)، صُممت Raiku لتوفير ضمانات صارمة بشأن تضمين الكتل وسرعة تنفيذها. تتلقى المعاملات المُقدمة عبر Raiku تأكيدات تضمين "مبكرة"، مما يُحفظها فعليًا للتضمين في الكتل القادمة. يتحقق ذلك من خلال آليات الجدولة والمزاد المبتكرة الخاصة بـ Raiku (والتي سنناقشها لاحقًا). بالنسبة للمستخدمين ومطوري التطبيقات اللامركزية، هذا يعني عدم الحاجة إلى إرسال رسائل غير مرغوب فيها أو الانتظار بقلق لاستخراج المعاملات الرئيسية؛ يمكنك معرفة ما إذا كانت معاملتك ستُجدول في إطار زمني محدد في المستقبل في غضون أجزاء من الثانية. هذا التركيز على التنفيذ الحتمي والقابل للتنبؤ هو عامل تمييز رئيسي. يمكن لبروتوكول L2 التقليدي على إيثريوم تحسين الرسوم والإنتاجية، ولكنه لا يضمن عادةً موعد وصول المعاملات بدقة على L1 (خاصةً في عمليات التجميع المتفائلة ذات الأطر الزمنية الصعبة). في المقابل، يوفر Raiku ضمانات للإطار الزمني على Solana، وهي منصة L1 معروفة بأوقات كتلها البالغة 400 مللي ثانية. يمدد Raiku Solana بشكل أساسي بـ"مجدول عالمي" يمكن للتطبيقات الاستفادة منه لحجز مساحة كتلة. ومن المزايا الرئيسية الأخرى عزل الأخطاء. على L1 متجانس، إذا استهلك تطبيق واحد (مثل برنامج سك NFT شائع) موارد زائدة فجأةً أو تعطل، فقد يتسبب ذلك في تدهور السلسلة بأكملها أو توقفها. لقد رأينا هذا بالفعل على Solana، حيث يمكن أن يؤدي عبء عمل تطبيق لامركزي واحد إلى تعطيل الشبكة بأكملها. مع Raiku، يمكن تشغيل التطبيقات في مناطق تنفيذ معزولة (تُعرف أيضًا باسم الحوسبة الطرفية). إذا واجهت إحدى المناطق مشكلة - على سبيل المثال، برنامج خارج عن السيطرة يستهلك قدرًا كبيرًا من الحوسبة - فإنها لا تحظر سلسلة Solana الرئيسية أو المناطق الأخرى مباشرةً. يقتصر العطل على تلك البيئة الممتدة. لم يتأثر توافق سولانا، وتواصل الامتدادات الأخرى العمل بشكل طبيعي. يُشبه عزل الأعطال هذا وجود عدة "صناديق حماية" على الشبكة: يمكن لكل تطبيق (أو مجموعة تطبيقات) استخدام شريحة مخصصة من السعة، بل ويمكنها أيضًا تخصيص معلمات دون المساس بالاستقرار العام. والأهم من ذلك، أن بنية رايكو تحافظ على الأهداف المشتركة لكل من المستويين الأول والثاني: الأمان والسيادة. تحافظ كل بيئة توسع في رايكو على سيادة التنفيذ، مما يعني أن مطوري التطبيقات يمكنهم تخصيص منطق التنفيذ والآلة الافتراضية والمعلمات وفقًا لاحتياجاتهم (بهذا المعنى، إنها "سلسلتهم الخاصة") دون الحاجة إلى بناء مجموعة جديدة من المُعدِّنين أو المُصدِّقين من الصفر. تستفيد رايكو من شبكة مُصدِّقين تعمل بالتزامن مع مجموعة مُصدِّقي سولانا. في الواقع، سيكون مُصدِّقو رايكو هم مُصدِّقو سولانا الذين يختارون تشغيل برنامج رايكو (برنامج جانبي لعميل المُصدِّق) وقد يحصلون على رسوم إضافية مقابل ذلك. هذا يعني أمانًا احترافيًا وقويًا منذ البداية، مع فريق من المُحققين ذوي الخبرة على رأس العمل، دون الحاجة إلى رهن الرموز لأغراض الأمان فقط. بفصل الإجماع (الذي لا يزال آلية إثبات صحة/إثبات الحصة في Solana المسؤولة عن إتمام الكتل) عن التنفيذ (الذي تُديره شبكة جدولة ومُحققي Raiku)، يُحسّن الإنتاج بشكل ملحوظ. لم تعد Solana بحاجة إلى تنفيذ جميع تعليمات كل برنامج بنفسها؛ إذ يُمكنها الاستعانة بمصادر خارجية لتنفيذ برامج مُعينة من خلال ملحقات Raiku، وتحتاج فقط إلى التحقق من النتائج أو البراهين.

  باختصار، Raiku ليست L1 مستقلة ولا L2 نموذجية، إنها طبقة تنفيذ Solana التي تقدم:

  • (أ) فصل التنفيذ والإجماع (تحرير التطبيقات من قيود الإنتاجية لـ L1)،

  • (ب) التضمين والجدولة المتوقعين (لا مزيد من ألعاب mempool الاحتمالية)، و،

  • (ج) عزل قوي للأخطاء (مشكلة في امتداد واحد لا تهدد الكل)

  يحول Solana من شبكة ذات طبقة واحدة إلى نظام متعدد الطبقات: طبقة أساسية للإجماع والحالة العالمية، وطبقات عليا للتنفيذ عالي الأداء الخاص بالتطبيق. داخل حزمة تقنيات رايكو: التسوية الحتمية والتنفيذ المعياري. للوفاء بوعودها، تُقدم رايكو العديد من المكونات وأنواع المعاملات الجديدة. يمكن اعتبار هذه المكونات وأنواع المعاملات بمثابة وحدات بناء للبنية التحتية تعمل معًا لتحسين سولانا. دعونا نحلل العناصر الرئيسية لمجموعة تقنيات رايكو: 1. مزادات الكتل المبكرة وإشارات التضمين: يكمن جوهر رايكو في نهج جديد جذريًا لإدارة مساحة الكتل. فبدلاً من نموذج تجمع الذاكرة المخصص، الذي يُعطى الأولوية لمن يأتي أولاً، تُطبق رايكو سوق مزادات الفترات الزمنية. يمكن للتطبيقات أو المستخدمين تقديم عروض أسعار مسبقًا للفترات الزمنية القادمة على سولانا (أو، بتعبير أدق، للجدولة التي تُنسقها رايكو)، مما يضمن أولوية معاملاتهم. يتلقى الفائزون في المزايدات "إشارة تضمين" مسبقًا، مما يضمن بشكل أساسي إدراج معاملتهم (أو حزمة معاملاتهم) في كتلة أو سلسلة كتل مستقبلية محددة. هذه المزادات مرجحة بالحصص وذرية، مما يعني أن جدولتها تتبع توزيع الحصص في سولانا (المصادقون ذوو الحصص الأكبر لديهم قدرة أكبر على تضمين المعاملات المحجوزة، مما يُحسّن الحوافز)، ويمكن حجز المعاملات في حزم وتنفيذها بالتتابع دون انقطاع. ونتيجةً لذلك، يمكن لمستخدمي رايكو الآن استلام التأكيدات بشكل أسرع لأن "تذكرة" التنفيذ الخاصة بهم مضمونة بالفعل. قارن هذا بالتجربة التقليدية: على إيثريوم، تُرسل معاملة وتأمل أن يلتقطها عمال المناجم بأسرع ما يمكن (ربما بزيادة الرسوم إذا كنت في أمس الحاجة)، أو حتى على سولانا، قد تُرسل معاملات متعددة لضمان التقاط إحداها خلال فترات الازدحام. مع رايكو، تُشبه العملية بأكملها حجز مقعد في قطار مُسبقًا، دون التدافع على رصيف مزدحم. يُقلل هذا النظام بشكل كبير من معدلات فشل المعاملات وعدم اليقين، وأحد الأهداف الأساسية لرايكو هو ضمان تنفيذ المعاملات. بث الأدلة: فتح آفاق تنفيذ الحمولات الكبيرة باستخدام مساحة الكتل المتسلسلة. من أهمّ القيود التي تواجهها Solana اليوم قيود بيانات الكتل الصارمة المصممة لضمان سرعة انتشارها. بالنسبة للتطبيقات التي تحتاج إلى إرسال تحديثات حالة كبيرة، مثل محركات التسوية أو أدلة التجميع ZK، قد يُشكّل هذا عائقًا. تُعالج Raiku هذه المشكلة من خلال حجز مساحة الكتل المتسلسلة، وهو مفهوم مُتاح من خلال نموذج مزاد الكتل المسبق (AOT). من خلال حجز مساحة لسلسلة من الكتل القادمة، يُمكن للتطبيقات إرسال الأدلة أو الحمولات الكبيرة بشكل موثوق في أجزاء أصغر وقابلة للتحقق دون الوصول إلى حد سعة Solana لكل كتلة. تكمن الفكرة في تقسيم المعاملات أو الأدلة الكبيرة إلى أجزاء أصغر يُمكن بثها والتحقق منها عبر فترات زمنية متعددة، وبالتالي تجاوز حدود بيانات Solana الصارمة لكل كتلة. عمليًا، يعني هذا أن التطبيقات يمكنها إرسال تحديثات أو إثباتات حالة ضخمة جدًا (مثل إثباتات المعرفة الصفرية أو دفعات من مئات المعاملات) عبر Raiku، والتي ستُغذي هذه البيانات إلى Solana في مجموعات يمكن للمدققين معالجتها. بدلًا من إرسال معاملات كبيرة قد تُعرّضها للفشل أو التضخم، يمكن للتطبيقات جدولة البيانات المُهيكلة ونقلها عبر عدة خانات، بينما تُعالجها المدققات وتتحقق منها بطريقة مُتحكّم فيها. 2. تسوية سريعة وحتمية ("تنفيذ مضمون"): تتطلب العديد من تطبيقات الجيل التالي التي صُممت Solana لدعمها، مثل منصات التداول عالية التردد، وأنظمة الألعاب الفورية، وشبكات الدفع المؤسسية، ضمانات صارمة بأن المعاملات ستصل بالضبط في الوقت والمكان المُتوقعين. في هذه المجالات، لا يُعدّ عدم اليقين في التنفيذ مجرد عائق في تجربة المستخدم؛ بل يُشكّل ضررًا على المعاملات. يُمكن أن يُؤدي ازدحام الشبكة غير المُتوقع وديناميكيات تجمع المعاملات إلى فشل المعاملات أو إعادة ترتيبها أو تأخيرها. في حالات الاستخدام المتقدمة، مثل التصفية الآلية، أو مبادلات الأصول المتزامنة، أو استراتيجيات المراجحة، قد يؤدي هذا الغموض إلى ضياع الفرص وعدم كفاءة رأس المال. يعالج Raiku هذه المشكلة من خلال ضمان تضمين المعاملات من خلال الفترات الزمنية المحجوزة مسبقًا (AOT) وفي الوقت المناسب (JIT). على سبيل المثال، قد يفضل برنامج بوت يعمل بناءً على تقلبات الأسعار في الوقت الفعلي تضمين JIT، بينما قد يختار نظام خارجي فترة زمنية مجدولة لـ AOT. في كلتا الحالتين، يدفع المستخدمون مقابل دقة الوقت وعرض النطاق الترددي (باستخدام مزيج من رموز Raiku وSOL). عند إرسال معاملة تضمين مضمونة عبر Raiku، يتم تخصيص نافذة تنفيذ محجوزة لها، مما يضمن معالجتها في الوقت المحدد وعدم فقدها أو إعادة ترتيبها بسبب سلوك المُحقق أو ازدحام الشبكة. في حين أن قادة الفترات الزمنية فقط هم من يمكنهم تضمين المعاملات، فإن جميع المُحققين الذين يشغلون وحدة Raiku الجانبية ينشرون ويؤكدون جدول المعاملات مسبقًا. تستخدم Raiku نظام جدولة مسبق التوافق لتنسيق جداول التداول، والتي يُنفذها قادة الفترات الزمنية أثناء إنتاج الكتل. من خلال حجز مساحة الكتل مسبقًا وتخصيص فترات زمنية محددة للتنفيذ، تُخفف Raiku من حدة سيناريوهات ذروة الفشل، والتي شهدت سابقًا معدلات فشل تتجاوز 90% لمستخدمي التردد العالي على Solana. كما توفر عرض نطاق ترددي مضمونًا، وزمن وصول دقيقًا، وتسوية متوقعة حتى في فترات التحميل الشديد. كما صُممت آلية التنفيذ المضمونة لإدخال مقاومة MEV. نظرًا لأن الصفقات تُجدول وتُؤكد مسبقًا عبر الشبكة بالكامل، يتم تقليل عمليات التشغيل المسبق والحد من هجمات الساندويتش من خلال دمج استخراج القيمة المتوقعة في آلية المزاد نفسها. لم تعد عمليات تبادل تدفق الطلبات الخاصة، التي كانت تُدار سابقًا خارج البروتوكول، ضرورية. بدلاً من ذلك، يتم دمج تدفق الطلبات بشفافية من خلال مزاد جدولة عادل أو نظام حجز. 3. نموذج الحساب العالمي والحالة الموحدة: من أبرز جوانب Raiku المبتكرة وحدة الحساب العالمية. هذا المكون (المقرر إطلاقه في الإصدار الثاني مع أدلة البث) يعالج مشكلة تجزئة الحالة بشكل مباشر. الفكرة هي السماح للمستخدمين والتطبيقات بالحفاظ على هوية وحالة موحدة عبر بيئات تنفيذ متعددة. عمليًا، سيظل لدى المستخدمين محفظة/عنوان Solana واحد للطبقة الأولى الرئيسية وأي ملحقات Raiku تتفاعل معها. يمكن نقل الأصول والبيانات بسلاسة بين السلسلة الرئيسية والملحقات دون الحاجة إلى "جسور" تقليدية. سيُمكّن نموذج الحساب العالمي من إمكانية التركيب عبر الملحقات، مما يسمح لملحقَي Raiku بالتفاعل أو الوصول إلى حالة المستخدم المشتركة حسب الحاجة. هذا فرق كبير عن أنظمة الطبقة الثانية التقليدية. في نظام L2 النموذجي، تكون كل عملية تجميع أشبه بحديقة مسوّرة، تتطلب جسرًا لنقل الأصول، وقد تكون عناوين الحسابات/العقود خاصة بالسلسلة. من ناحية أخرى، تُشبه ملحقات Raiku "مناطق" داخل منظومة Solana، مما يضمن اتساق تجربة المستخدم. يمكن للمطورين النشر داخل بيئة الملحقات مع الاستمرار في التكامل بسهولة مع برامج أو حسابات Solana الأصلية. على سبيل المثال، بفضل الحسابات الموحدة، يُمكن تسوية الطلبات المُقدمة في ملحق دفتر الطلبات المُشغّل بواسطة Raiku في محفظة Solana الرئيسية للمستخدم أو التعرّف عليها بواسطة برامج الطبقة الأولى. من الناحية الفنية، يُمكن تحقيق ذلك من خلال مشاركة Raiku لمساحة عنوان حساب Solana والتحقق من التوقيع، أو من خلال إنشاء آلية لمزامنة جذور الحالة بين الملحق والطبقة الأولى. والنتيجة النهائية هي حل لمشكلة تجزئة الحالة، مما ينتج عنه حالة واحدة مُدمجة تشمل بيئات تنفيذ متعددة. وكما يوضح فريق Raiku، يُتيح هذا إمكانية التركيب عبر بيئات التوسع، وهو أمر لا يُمكن تحقيقه لا في الطبقة الثانية من Ethereum (جميعها تعمل بشكل مستقل) ولا في محاولات Solana Rollup المبكرة. هذا نهج قائم على المبادئ الأساسية مُصمم لضمان ألا يؤدي التوسع إلى تجزئة قاعدة المستخدمين أو السيولة. تدعم وحدة الحساب العالمية أيضًا أجهزة افتراضية متعددة. لا يقتصر Raiku على الجهاز الافتراضي الأصلي لـ Solana (SVM)؛ بل يُمكنه استضافة أجهزة افتراضية مختلفة ضمن إطار التنسيق نفسه. في الواقع، صُممت Raiku لدعم الإضافات المتوافقة مع EVM، مما يسمح لمشاريع Ethereum بنشر برمجيات Solidity الخاصة بها كإضافات لـ Solana. يشير ذكر "مشاريع مثل Arbitrum Orbit سيتم نشرها على Solana" إلى أن طبقة Ethereum الثالثة أو السلاسل المخصصة يمكنها الاتصال بفعالية بـ Solana من خلال Raiku. هذا مهم: فهو يعني أن تطبيقات Ethereum اللامركزية (dApps) يمكنها الاستفادة من أداء Solana وقاعدة مستخدميها دون التخلي عن قاعدة برمجياتها. هذا يشير إلى أن Raiku تتميز ببنية عقد هرمية نوعًا ما: يتواصل المستخدمون/التطبيقات العادية مع عقدة Ackermann (أو مجموعة)، والتي تتفاعل بدورها مع المدققين لجدولة التنفيذ. هذا تصميم مثير للاهتمام يوسع نطاق معالجة المدخلات ويضمن قدرة النظام على التعامل مع دفعات المعاملات من خلال توزيع المعاملات بكفاءة على المدققين.

  ملخص

  يُمثل ظهور Raiku نقطة تحول في تاريخ Solana وهندسة blockchain ككل. فهو يُبرز رؤيةً واضحةً: شبكات لامركزية قادرة على تحقيق الموثوقية والسرعة والمرونة التي كانت حكرًا على سحابة Web2 أو الأنظمة المالية التقليدية. من خلال تقديم محرك تنسيق ذي تنفيذ حتمي، يُمكّن Raiku Solana من تجاوز وصف "مجرد مستوى L1 آخر" ليصبح منصةً حقيقيةً للتطبيقات عالية الأداء والحيوية.

  فكّر في معنى هذا للمطورين: مع Raiku، يُشبه البناء على Solana البناء على خدمة سحابية قابلة للتوسع.

  • هل تحتاج إلى إنتاجية أعلى؟ ما عليك سوى تشغيل ملحق وحجز الفواصل الزمنية المطلوبة. هل تحتاج إلى منطق تنفيذ مُخصص أو جهاز افتراضي مختلف؟ قم بتوصيله كمنطقة حوسبة طرفية. هل أنت قلق بشأن تجربة المستخدم خلال ساعات الذروة؟ نضمن لك تضمين المعاملات حتى لا يواجه المستخدمون أي فشل في المعاملة مرة أخرى. كما تم تحسين تجربة المطور بشكل كبير. يمكن للمطورين البناء بثقة، مدركين أن البنية التحتية ستلبي احتياجات تطبيقاتهم، وليس العكس. تعمل سلسلة Solana الأساسية كأساس مستقر، بينما توفر Raiku هيكلًا مرنًا وقابلًا للبرمجة لمساعدتهم على تجاوز الحدود. هذا لديه القدرة على جذب ليس فقط مطوري التشفير الأصليين، ولكن أيضًا مطوري Web2 ذوي متطلبات الأداء الصارمة. يمكنهم استخدام Solana دون القلق بشأن تباطؤ الشبكة. في الواقع، يمكن لـ Raiku أن تجعل Solana المنصة المفضلة لأي تطبيق يتطلب اللامركزية والإنتاجية العالية. على المستوى المؤسسي، قد يكون Raiku هو المفتاح لإطلاق العنان لتبني الشركات الجاد لـ Solana. يمكن للبنوك وصناديق التحوط وشركات الألعاب وشركات وسائل التواصل الاجتماعي الناشئة - كل هذه الشركات - البناء على السلسلة بثقة، مدركين أن الأداء والتحكم اللذين يحتاجونهما متوفران بالفعل. أصبحت Solana بالفعل واحدة من سلاسل الكتل الأكثر ملاءمة للمؤسسات (مع شركات مثل Jump تستثمر في تقنيتها)؛ إن وعد Raiku بتحكم دقيق في التنفيذ وموثوقية عالية يعزز جاذبية Solana. المستوى المؤسسي يعني وقت تشغيل بنسبة 99.999%، ومواعيد نهائية للمعاملات، وحماية خصوصية أساسية، وميزات امتثال تنظيمي - وكلها مزايا تقدمها Raiku (من خلال التوسع المنعزل والجدولة وغيرها). لقد بدأت الرحلة للتو؛ Raiku حاليًا في مرحلة تجريبية، ومن المقرر إطلاقها على الشبكة الرئيسية في أواخر عام 2025، لكن البنية التحتية والحلول جاهزة بالفعل. يعالج Raiku نقاط الضعف التي ذكرناها في البداية: قيود التوسع (التي تُعالج من خلال زيادة الإنتاجية المعيارية)، واستغلال MEV (التي تُقلل من خلال آليات الطلب والمزاد المتوقعة)، وتحديات إعادة الرهان (التي يتم تجنبها بطريقة أكثر تحكمًا)، وتجزئة الحالة (التي تُعالج من خلال الحسابات العالمية)، ومشاكل الأداء (التي تُعالج من خلال ضمان الشمولية وعزل الأخطاء). لذلك، يُعد Raiku حلاً شاملاً، وليس حلاً جزئيًا.