بروتوكول OrcaRail: ورقة بيضاء لبنية دفع غير احتجازية ومتواصلة من Web2 إلى Web3
20 أبريل 2026 — هذه هي الورقة البيضاء لبروتوكول OrcaRail. إنها البيان المرجعي لما تتحول إليه OrcaRail: بنية دفع مفتوحة ومحايدة بشكل موثوق وغير احتجازية ومتواصلة، يمكن لتاجر Web2 ربطها عبر واجهات HTTP وwebhooks مألوفة، ويمكن لدافع Web3 استخدامها بأي محفظة، وتستمر في التسوية حتى لو اختفت شركة OrcaRail.
هذه الورقة توسّع خارطة الطريق غير الاحتجازية ونقاش البروتوكول، ولا تحل محلهما. تزيل خارطة الطريق غير الاحتجازية (المسار N، المراحل 0-7) الحفظ. وتضيف هذه الورقة مسارًا موازيًا P يجعل الباقي لامركزيًا: المفهرسات، والواجهات الأمامية، والمعايير، والـ keepers، والحوكمة.
الملخص
بروتوكول OrcaRail مجموعة من المكوّنات الأساسية على السلسلة (مصانع روابط الدفع ومستقبِلاتها، ومراكز اشتراك بسحب الـ allowance، وموزّعات الرسوم، وبرامج Anchor على سولانا، وواصفات توقيع متعدد taproot على بيتكوين)، إلى جانب مواصفات عامة للمفهرسات والـ keepers والواجهات الأمامية وحِزم SDK التي تعمل فوق هذه المكوّنات. يحقق البروتوكول أربعة ثوابت: غير احتجازي (لا يحتفظ أي طرف بالأموال أثناء انتقالها)، ومتواصل (تستمر التسوية المشروعة دون OrcaRail)، ومحايد بشكل موثوق (لا يستطيع أي طرف منفرد حجب معاملة مدفوعة سليمة البنية)، ومتوافق مع Web2 (يحتفظ التجار بمفاتيح API والـ webhooks ولوحات التحكم). يجري الإطلاق على مسارين متوازيين: المسار N يزيل الحفظ في سبع مراحل؛ والمسار P يجعل الفهرسة والواجهات الأمامية والمعايير وتوجيه التسوية لامركزية في خمس مراحل. لا يوجد أي رمز عند الإطلاق ولا يُخطَّط لأي رمز ضمن هذه الورقة؛ ورمز الحوكمة المستقبلي محجوز صراحةً كخيار لما بعد اللامركزية، وإن طُرح يومًا فسيصدر بورقة بيضاء خاصة به.
1. مقدمة: لماذا بروتوكول وليس مجرد منتج
تُقدَّم OrcaRail اليوم كمنتج مدفوعات مستضاف، مع خيارات استضافة ذاتية في الطريق. هذا منتج، لا بروتوكول. المنتجات يمكن تحسينها؛ أما البروتوكولات فيمكن الوثوق بها في غياب صانعها.
تُخرج خارطة الطريق غير الاحتجازية الحفظ من المسار. هذا ضروري لكنه غير كافٍ. فحتى دون حفظ، قد تتعطل بنية الدفع إذا توقفت الشركة المشغّلة عن دفع فواتير AWS، أو فُرضت عليها عقوبات، أو ببساطة غيّرت توجهها. يجب أن يستمر البروتوكول في العمل عند حدوث ذلك.
استعرض نقاش البروتوكول خمس بنى. وكانت الخلاصة: أطلق مسار «البراغماتي»، وحافظ على ضغط «المتشدد» عليه، واعتمد الـ intents لتجربة الدافع، واكتب المعايير على طول الطريق، وأبقِ السلسلة الخاصة مستقبلًا اختياريًا. هذه الورقة هي تلك الخلاصة مكتوبة كالتزامات.
2. أهداف التصميم
يُصاغ كل هدف بتعريف دقيق وقابل للاختبار. يجب أن يكون لسؤال «هل يحقق التصميم ذلك؟» جواب بنعم أو لا.
- غير احتجازي — في أي لحظة أثناء الدفع أو خصم الاشتراك، لا تحتفظ أي محفظة أو حساب تتحكم به OrcaRail أو معالج التاجر أو أي وسيط بأموال الدافع. الاختبار: هل يمكن لجهة تنظيمية تجميد الأموال أثناء انتقالها بمخاطبة OrcaRail وحدها؟ لا.
- متواصل — إذا توقفت خوادم OrcaRail إلى أجل غير مسمى، تستمر تسوية خصم الاشتراك المستحق المشروع على السلسلة، ويظل بإمكان الدافع إكمال دفعة فردية. الاختبار: بعد انقطاع OrcaRail لمدة 30 يومًا، هل فات أي اشتراك مضبوط بشكل صحيح خصمًا؟ لا.
- محايد بشكل موثوق — القواعد على السلسلة عامة، وغير قابلة للتغيير لكل رابط، وتُطبَّق بالتساوي. لا تستطيع OrcaRail حجب الخدمة انتقائيًا في طبقة التسوية (بل في واجهتها الأمامية فقط). الاختبار: هل يمكن لتاجر غير مرغوب فيه أن يتلقى المدفوعات عبر واجهة أمامية لطرف ثالث؟ نعم.
- متوافق مع Web2 — يحتفظ التجار بالسهولة التي اعتادوها (نقاط نهاية REST، وwebhooks، ومفاتيح API، ولوحات التحكم، والبريد الإلكتروني). التحول إلى بروتوكول لا يتطلب من التاجر تشغيل أدوات Ethereum لقبول دفعة. الاختبار: هل يستطيع تاجر غير متمرس في الكريبتو إتمام التكامل في أقل من ساعة؟ نعم.
- ند للند حقيقي — يُعرَّف بدقة في القسم التالي.
أي تصميم يخفق في أي هدف يُعدّ ناقصًا.
3. ماذا يعني «ند للند حقيقي» هنا
مصطلح «ند للند» (P2P) محمّل بمعانٍ كثيرة. في هذا البروتوكول له ثلاث طبقات ملموسة.
- P2P في التسوية — يوقّع الدافع؛ وتتدفق الأموال من الدافع إلى عقد على السلسلة (EVM) أو PDA مملوك للبرنامج (سولانا) أو توقيع متعدد اثنان من اثنين (بيتكوين)، ثم إلى التاجر ومستلمي الرسوم بشكل ذري. لا توجد أي محفظة لـ OrcaRail في المسار. يضمن المسار N ذلك.
- P2P في الاكتشاف — يمكن استخلاص رابط الدفع أو الاشتراك بالكامل من بياناته على السلسلة و(اختياريًا) من بيانات وصفية مثبّتة على IPFS. يمكن لأي محفظة أو واجهة أمامية أو معالج طرف ثالث عرضه وإكماله. لوحة التحكم المستضافة لـ OrcaRail هي إحدى تطبيقات طبقة العرض، وليست السجل.
- P2P في الاستمرارية —
SubscriptionHub.charge(id)وتعليمةchargeفي Anchor عامة. يمكن لأي EOA أو solver استدعاؤها. مُجدوِل OrcaRail مشارك واحد بين عدة مشاركين (Chainlink، وGelato، ومشغّلين من التجار، ومشغّلين من الـ solvers).
ما لا يعنيه «ند للند حقيقي» هنا: لسنا Lightning؛ ولسنا طبقة قنوات مباشرة من محفظة إلى محفظة؛ ولا نستبدل تطبيق دفع بـ DHT. OrcaRail بروتوكول على السلسلة بتجربة استخدام خارج السلسلة. خاصية P2P تأتي من استحالة تدخّل وسيط في التسوية أو الاكتشاف أو الاستمرارية، لا من تجنب البنية على السلسلة.
4. بنية النظام
على أعلى مستوى، يتكون البروتوكول من خمس طبقات.
طبقة التسوية غير قابلة للتغيير لكل رابط على EVM وسولانا، ومشتقة من الواصفات لكل رابط على بيتكوين. أما الطبقات الأربع الأخرى فقابلة للاستبدال. من يريد المخطط التقني الكامل فليتوجه إلى /docs/non-custodial/architecture.
5. مكوّنات التسوية الأساسية
المرجع الكامل: /docs/non-custodial/contract-reference. ملخص:
- EVM —
PaymentLinkFactory(عناوين حتمية عبر CREATE2)، وPaymentLinkReceiver(نسخة مصغّرة EIP-1167، غير قابلة للتغيير لكل رابط)، وFeeSplitter(تقسيم ذري بنقاط الأساس)، وSubscriptionHub(سحب الـ allowance معlastChargedAtرتيب). - سولانا — برنامج Anchor باسم
payment_link(PDA لكل رابط، وتقسيم عبر CPI) وبرنامج Anchor باسمsubscription(صلاحية delegate من SPL، بدلالةchargeمطابقة لمركز EVM). - بيتكوين — توقيع متعدد taproot اثنان من اثنين لكل رابط (موقّع التاجر + موقّع المنصة من HSM/MPC) مع PSBT استرداد موقّعة مسبقًا. لا مدفوعات BTC متكررة حتى تنضج المدفوعات المتكررة في Lightning BOLT12.
صُمم كل مكوّن بحيث يشير linkId أو subscriptionId نفسه دائمًا إلى العنوان الحتمي نفسه على الشبكة نفسها إلى الأبد: دون تدوير للعناوين، ودون إعادة إصدار، ودون ربط محفوظ على خادم.
6. العمليات عبر الشبكات كـ intents
البروتوكول الذي يتعامل مع العمليات عبر الشبكات على أنها «الخادم الخلفي لدينا يستدعي Relay» ما زال منتجًا. أما البروتوكول فيتعامل معها على أنها intent من الدافع:
- يوقّع الدافع: «ادفع للتاجر X مبلغ 50 دولارًا بـ USDC، من أي من محافظي على أي شبكة مدعومة، خلال ساعة واحدة، برسوم لا تتجاوز Y».
- تتنافس شبكات الـ solvers القائمة (Across وRelay وdeBridge وعلى نمط CoW) على تنفيذ الـ intent. ويحصل الـ solvers على مكافأة مضمّنة في الـ intent.
- للمسارات الطويلة غير المربحة اقتصاديًا (مبالغ صغيرة، شبكات غير شائعة) تشغّل OrcaRail solver احتياطيًا بسعر التكلفة لضمان تسوية هذه المسارات أيضًا. الاحتياطي عام، ويمكن لأي شخص آخر تشغيل واحد.
توقيع الدافع محدود بالمبلغ والمستلم والمهلة والحد الأقصى للرسوم. في أسوأ الأحوال يكون الـ solver الخبيث بطيئًا؛ ولا يستطيع تحويل الأموال إلى وجهة أخرى. هذه هي خلاصة «المؤمن بالـ intents» من نقاش البروتوكول، مكتوبة كالتزام.
7. المعايير والتشغيل البيني
مكوّنات روابط الدفع والاشتراكات في OrcaRail بنية عامة. ولا تتضاعف قيمتها إلا إذا طبّقتها معالجات ومحافظ ومفهرسات أخرى بشكل أصيل.
الالتزامات:
- صياغة مسودة EIP لروابط الدفع غير الاحتجازية باستخدام
PaymentLinkFactoryوPaymentLinkReceiverكواجهة مرجعية. والاشتراك في كتابتها مع فريق معالج أو محفظة آخر على الأقل لتجنب نمط «EIP من مزوّد واحد». - صياغة مسودة EIP لاشتراكات سحب الـ allowance باستخدام
SubscriptionHubكمرجع.lastChargedAtالرتيب ومجموعة أسبابChargeSkipped(reason)أهداف للتوحيد القياسي. - نشر مقابل لسولانا عبر IDL من Anchor ومواصفة مكتوبة، لتتمكن أي محفظة أو مفهرس على سولانا من عرض رابط دفع من الأساس.
- نشر مخطط الـ subgraph المرجعي ليكون أي مفهرس (The Graph أو Goldsky أو Envio أو مستضاف ذاتيًا) متوافقًا مباشرةً.
كتابة الـ EIP لا تقلّص ميزتنا التنافسية. كما جادلنا في النقاش، تكمن الميزة في التكاملات والامتثال واتفاقيات مستوى الخدمة وثقة التجار، ولا شيء من ذلك يُنسخ بـ EIP.
8. الحوكمة
للحوكمة أفقان.
اليوم وعلى المدى القريب
- EVM: توقيع متعدد Safe ثلاثة من خمسة على كل شبكة منشورة. موقّعون بمحافظ أجهزة. تدوير سنوي. قفل زمني (timelock) لمدة 48 ساعة على ترقيات الـ proxy. نسخ
PaymentLinkReceiverلكل رابط غير قابلة للتغيير. - سولانا: توقيع متعدد Squads ثلاثة من خمسة بمجموعة الموقّعين نفسها وسياسة التدوير نفسها.
- نطاق الترقية: المصانع والمراكز خلف proxies من نوع UUPS؛ ولا تتأثر المستقبِلات لكل رابط وسجلات كل اشتراك بالترقيات.
- قابلية التدقيق العام: يُنفَّذ كل نشر وترقية كمراسم توقيع متعدد مُعلنة مع تسجيل المعاملات الموقّعة.
هذه هي الحوكمة الموصوفة في /docs/non-custodial/security-model.
ما بعد اللامركزية
مع الوقت، لا تبقى مجموعة الموقّعين مقتصرة على موظفي OrcaRail، بل تصبح مجلسًا عامًا يضم متكاملين وشركات تدقيق ومشغّلي keepers ومساهمين مستقلين. تنتقل صلاحية الترقية إلى المجلس. عندها تصبح الحوكمة على السلسلة خيارًا فعليًا، لكن كآلية حوكمة فقط، لا كأداة مضاربة.
عتبة «ما بعد اللامركزية» صريحة: ثلاث واجهات أمامية مستقلة على الأقل في بيئة الإنتاج تستضيف البنية، وثلاثة keepers مستقلين على الأقل ينفّذون الخصومات، ومعالج واحد على الأقل من غير OrcaRail يطلق تكاملات. وحتى يتحقق ذلك فعليًا، لا يكون البروتوكول لامركزيًا بعد، بغض النظر عن آلية الحوكمة القائمة فوقه.
9. رمز حوكمة مستقبلي (حجز صريح)
هذا القسم قصير ودقيق عن قصد.
- لا رمز عند الإطلاق. لا بيع مسبق. لا تخصيصات. لا نقاط. لا مطالبات بأثر رجعي.
- رمز الحوكمة المستقبلي محجوز كخيار، لا كالتزام. لا يصبح مناسبًا إلا بعد بلوغ عتبة ما بعد اللامركزية في القسم 8 ووجود قاعدة نشطة من المتكاملين والـ keepers والواجهات الأمامية تستفيد من حقوق رسمية لإبداء الرأي.
- إن طرحنا رمزًا يومًا ما، فسيصدر بورقة بيضاء خاصة به، مع شفافية كاملة بشأن التوزيع وفترات القفل والمعروض ونطاق الحوكمة. وستُناقَش ورقة الرمز علنًا قبل الإصدار.
- سيكون الرمز للحوكمة أولًا، لا للمضاربة. آليات منطقية: تصويت لإبداء الرأي في الترقيات، وضبط المعاملات ضمن حدود آمنة، وسمعة مشغّلي الـ keepers. آليات غير منطقية: خصومات على الرسوم مرتبطة بالحيازة، والدفع مقابل الدفع، وزراعة العوائد (yield farming).
- لن ندّعي أن البروتوكول لامركزي لمجرد وجود رمز. تُقاس اللامركزية بما ورد في القسم 8. الرمز أداة يمكنها إضفاء الطابع الرسمي على لامركزية متحققة بالفعل؛ ولا يمكنها صنعها.
هذا الحجز مدوَّن في الورقة البيضاء للبروتوكول، أي هذه الوثيقة، وليس في أي مكان آخر. وأي تغيير مستقبلي في هذا الموقف هو تغيير في هذه الورقة، يُنشر علنًا، وليس إعلانًا أحادي الجانب.
10. الاقتصاد والرسوم: كيف يستدام البروتوكول دون رمز
نموذج إيرادات البروتوكول هو نموذج المنتج نفسه، لكنه مُرمَّز على السلسلة.
- يقع تقسيم الرسوم في إعداد نقاط الأساس لـ
FeeSplitterلكل دفعة. وهي الحصص نفسها التي تصفها صفحة السحوبات اليوم: التاجر، والمنصة (حصة OrcaRail المستضافة)، والإحالة/الشريك، ورسوم الجسر. - تُموَّل الخدمات المستضافة من OrcaRail (لوحة التحكم، والبريد الإلكتروني، وغاز الـ paymaster، ودعم العملاء) من حصة OrcaRail في التقسيم.
- يمكن للمستضيفين البدلاء (المعالجات من أطراف ثالثة، والمشغّلين بالاستضافة الذاتية، والواجهات المثبتة على IPFS) العمل بتقسيم صفري لحصة المنصة، أو ضبط مستلم رسوم خاص بهم. لا يفضّل البروتوكول رسوم OrcaRail على رسوم أي طرف آخر.
- لا إصدار رموز، ولا دعم، ولا عوائد staking. التكاليف نقدية والإيرادات نقدية. الطريقة الوحيدة ليصبح البروتوكول أرخص هي أن يرخص الغاز أو أن يقبل مستضيفٌ هامشًا أقل، لا إصدار رموز لتغطية تكاليف التشغيل.
11. نموذج الأمان
البيان الكامل: /docs/non-custodial/security-model. الموقف الأساسي:
- المستقبِلات لكل رابط وسجلات كل اشتراك غير قابلة للتغيير.
- لا تُرقّى المصانع والمراكز إلا عبر توقيع متعدد + قفل زمني.
- الـ keepers حسابات EOA تدفع الغاز فقط ولا تملك أي صلاحية لنقل الأموال.
- يستخدم توقيع BTC خدمة HSM أو MPC من جهة المنصة، إضافةً إلى مفتاح التاجر؛ ولا يملك أي خادم صلاحية إنفاق أحادية.
إضافة خاصة بالتحول إلى بروتوكول: يجب على مستضيفي الواجهات الأمامية المستقلين التحقق من عناوين العقود مقابل سجل على السلسلة (أو بيان إصدار موقّع) قبل عرض رابط الدفع. الواجهة المستنسخة الخبيثة التي توجّه المدفوعات إلى عقد مشابه هي أرجح وسيلة تصيّد عندما يضم النظام عدة مستضيفين. السجل المرجعي موجود على السلسلة، وتدفق التحقق موثّق كجزء من P2.
12. خارطة الطريق: مساران متوازيان
يجري إطلاق البروتوكول على مسارين في الوقت نفسه.
المسار N هو خارطة الطريق القائمة دون تغيير. ويحوّل المسار P التزامات M1-M5 من مقال النقاش إلى مراحل رسمية. يستهدف المساران الحالة النهائية نفسها: بنية تستمر في العمل إذا ابتعدت OrcaRail.
لا يعيق المسار P المسار N أبدًا، ولا يعيق المسار N المسار P أبدًا. يمكن لأي منهما إطلاق مرحلة قبل الآخر.
13. مراحل المسار P
خمس مراحل، كل منها امتداد طبيعي لأحد التزامات M في مقال النقاش.
P1 — subgraph عام ومفهرس مفتوح
النطاق: subgraph مرجعي (The Graph أو Envio أو ما يعادلهما) يفهرس كل أحداث Paid وSubscriptionCreated وCharged وChargeSkipped وCanceled وRefunded من PaymentLinkReceiver وSubscriptionHub عبر كل الشبكات المنشورة. المخطط منشور. وتعليمات الاستضافة الذاتية منشورة ليتمكن أي شخص من تشغيل الفهرس نفسه.
قائمة الحالة
- بيان الـ subgraph + الـ mappings لشبكات EVM المفعّلة في المرحلة 1 والمرحلة 3
- مقابل على سولانا (webhooks من Helius أو بث Triton) بأشكال الأحداث نفسها
- مخطط موثّق بإصدارات مستقرة
- إثبات تشغيل مفهرس خارجي للمخطط نفسه على أحداث حية
P2 — واجهات أمامية لامركزية (IPFS / ENS)
النطاق: تثبيت تطبيق الدفع ولوحة تحكم التاجر في OrcaRail على IPFS بحِزم إصدار معنونة بالمحتوى. والوصول إليها عبر ENS (pay.orcarail.eth وapp.orcarail.eth). بناء قابل لإعادة الإنتاج ليتحقق أي قارئ من مطابقة الحزمة للمصدر. على النسخة الخبيثة أن تنتحل عناوين العقود وسجل ENS معًا، لا اسم المضيف فقط.
قائمة الحالة
- بناء تطبيق الدفع قابل لإعادة الإنتاج
- بناء لوحة التحكم قابل لإعادة الإنتاج
- سجلات ENS تشير إلى معرّفات CID على IPFS
- مراسم توقيع الإصدارات من التوقيع المتعدد Safe
- سجل على السلسلة لعناوين العقود تتحقق منه الواجهات قبل العرض
P3 — المعايير (مسودة EIP)
النطاق: صياغة وتقديم EIP لروابط الدفع غير الاحتجازية وEIP مرافق لاشتراكات سحب الـ allowance. والاشتراك في الكتابة مع فريق معالج أو محفظة آخر على الأقل. التطبيق المرجعي هو عقود OrcaRail. وتُنشر مواصفة سولانا المقابلة إلى جانب الـ EIPs.
قائمة الحالة
- تأكيد الشريك في الكتابة
- مسودة EIP روابط الدفع في مرحلة سلسلة النقاش
- مسودة EIP الاشتراكات في مرحلة سلسلة النقاش
- نشر مواصفة سولانا إلى جانب IDLs من Anchor
- دمج ملاحظات محرري EIP حتى مرحلة Last Call
P4 — SDK للدافع قائمة على الـ intents
النطاق: واجهة SDK (orcarail.pay(intent)) تقبل intent موقّعًا من الدافع وتوجّهه عبر شبكات الـ solvers القائمة (Across وRelay وdeBridge)، مع solver احتياطي تشغّله OrcaRail للمسارات الطويلة. ويُوحَّد مخطط الـ intent بالتزامن مع P3.
قائمة الحالة
- إنهاء مخطط الـ intent
- محوّل SDK لشبكتي solvers على الأقل
- نشر الـ solver الاحتياطي وقياسه
- دعم تجربة الدافع في تطبيق الدفع للـ intent نفسه + العمليات عبر الشبكات
- نشر المواصفة كجزء من مرجع Node SDK
P5 — حزمة الاستضافة الذاتية / التطبيق المرجعي
النطاق: ملف Docker Compose (وHelm chart) يتيح لأي شخص تشغيل معالج متوافق مع OrcaRail من البداية إلى النهاية انطلاقًا من العقود العامة. يتضمن الـ subgraph والـ keeper والمفهرس ولوحة تحكم اختيارية ومواصفة OpenAPI لواجهة API الخاصة بالمعالج يمكن للآخرين الالتزام بها.
قائمة الحالة
- Docker Compose يعمل على شبكة حية ويخدم تاجرًا تجريبيًا
- مواصفة OpenAPI لواجهة API الخاصة بالمعالج
- Helm chart لمشغّلي Kubernetes
- اختبار شامل يثبت أن المشغّل بالاستضافة الذاتية يعالج المدفوعات تمامًا مثل النسخة المستضافة
- توثيق في
/docs/non-custodial/(يُضاف في تغيير مستقبلي خاص بالتوثيق؛ خارج نطاق هذه الورقة)
14. P6 اختيارية: تقييم سلسلة خاصة
تتبع P6 نمط تقييم EigenLayer. وهي ليست التزامًا، بل مراجعة ربع سنوية بمحفزات محددة.
التوصية الحالية: التأجيل.
المحفزات التي تستدعي فتح وثيقة تصميم لبناء المرحلة P6:
- تجاوز حجم المدفوعات على شبكة واحدة عتبةً يصبح عندها الغاز بندًا جوهريًا في رسوم المنصة.
- توفير سلسلة أدوات L2/L3 مرجعية لـ precompiles متخصصة لمنطق تقسيم المدفوعات بتكلفة شبه معدومة.
- طلب التجار لزمن تسوية بأجزاء من السنت لا تستطيع الشبكة الرئيسية / L2 تلبيته باستمرار.
- شريك rollup-as-a-service يتيح لـ OrcaRail الإطلاق بتسلسل مشترك من اليوم الأول.
إن تحققت المحفزات، فسيُفضَّل البناء على OP Stack مع تسلسل مشترك (Espresso، Astria) وجسر خروج موثوق إلى الشبكات المرجعية التي ندعمها بالفعل. وحتى حينها، يجب أن تكون المراحل N0-N7 وP1-P5 ناضجة بما يكفي لتكون السلسلة الخاصة تحسينًا لا اعتمادًا.
15. ما هي OrcaRail اليوم وما الذي ستصبح عليه
مقارنة قبل وبعد على مستوى البنية.
| البُعد | اليوم | بعد المسارين N وP |
|---|---|---|
| الحفظ أثناء الدفع | تحتفظ OrcaRail بمفتاح محفظة الإيداع | لا حفظ. الدافع ← العقد ← التاجر بتقسيم ذري |
| الـ spender في الاشتراكات | smart account تتحكم به OrcaRail | عقد SubscriptionHub عام؛ يمكن لأي طرف استدعاؤه |
| Keeper | مُجدوِل NestJS وحيد | NestJS + Chainlink + Gelato + AVS اختياري من EigenLayer |
| المفهرس | داخلي | subgraph عام بمخطط موثّق |
| تطبيق الدفع / لوحة التحكم | تستضيفهما OrcaRail | مستضافان + نسخ على IPFS/ENS؛ ومرحبًا بالمستضيفين من أطراف ثالثة |
| مكوّن رابط الدفع الأساسي | شكل API داخلي | مسودة EIP مع تطبيق مرجعي |
| التسوية عبر الشبكات | keeper من OrcaRail يستدعي Relay | intents الدافع توجّهها سوق solvers + احتياطي OrcaRail |
| الحوكمة | توقيع متعدد لـ OrcaRail (المؤسسون + الفريق) | مجلس عام؛ الحوكمة على السلسلة خيار فعلي |
| النطاق التنظيمي | «OrcaRail هي المعالج» | «OrcaRail معالج واحد بين معالجات كثيرة على البنية نفسها» |
| API المرئية للتاجر | REST + webhooks | REST + webhooks نفسها (مستقرة) |
| الرمز | لا يوجد | لا يوجد؛ محجوز كخيار مستقبلي (القسم 9) |
تبقى الواجهة الموجّهة لـ Web2 مستقرة عن قصد. التجار الذين تكاملوا مع REST API في 2026 لن يتعطلوا في 2028.
16. نموذج التهديدات
التهديدات التي نتعامل معها صراحةً، مع وسائل الحد منها:
- خلل في عقد ← عدة عمليات تدقيق لكل عقد؛ مستقبِلات غير قابلة للتغيير لكل رابط؛ ترقيات UUPS خلف قفل زمني 48 ساعة على المصانع والمراكز؛ برنامج مكافآت أخطاء عام.
- انقطاع الـ keeper ← تكرار الـ keepers في المرحلة 3 من المسار N (Chainlink/Gelato) + شبكة الـ solvers في P4 من المسار P + استدعاء
charge()يدوي عام كاحتياطي. - تصيّد عبر الواجهات الأمامية ← سجل العقود على السلسلة في P2 من المسار P + العنونة بالمحتوى عبر ENS + مراسم توقيع الإصدارات من التوقيع المتعدد Safe.
- الاستيلاء على الحوكمة ← تدوير موقّعي التوقيع المتعدد؛ عتبة ثلاثة من خمسة؛ مجلس ما بعد اللامركزية من مشغّلين مستقلين؛ مراسم علنية.
- إجراء تنظيمي ضد مستضيف واحد ← حزمة الاستضافة الذاتية في P5 من المسار P + عدة واجهات أمامية مستقلة ليحظى التجار ببنى بديلة.
- انحراف الـ subgraph أو المفهرس ← مخطط مرجعي + اختبارات قابلية إعادة الإنتاج؛ عدة مفهرسات مستقلة.
- ضعف عمق سوق الـ solvers ← solver احتياطي من OrcaRail بسعر التكلفة؛ دخول حر دون إذن للـ solvers الجدد.
- فقدان مفتاح BTC ← xpub احتياطي عند تسجيل التاجر؛ تبديل تلقائي لـ HSM؛ وPSBT الاسترداد الموقّعة مسبقًا تُبقي استرداد الدافع ممكنًا.
- إعادة تنظيم السلاسل (reorg) في EVM ←
lastChargedAtرتيب فيSubscriptionHub؛ ومقابله على سولاناlast_charged_at. - التشوّه الناتج عن الرمز ← لا رمز عند الإطلاق؛ حجز صريح؛ وأي رمز مستقبلي مشروط بعتبات المشغّلين المستقلين قبل أن يطالب بدور في الحوكمة.
17. أسئلة مفتوحة نعترف بها
كتابة هذه الوثيقة لا تحل كل الأسئلة التي تطرحها.
- متى تبدأ «ما بعد اللامركزية» بالضبط؟ يحدد القسم 8 عتبة (ثلاث واجهات أمامية مستقلة، وثلاثة keepers مستقلين، ومعالج واحد من غير OrcaRail). وما إذا كانت هذه العتبة صحيحة نقاش مفتوح.
- من يدفع تكلفة الـ subgraph العام على نطاق واسع؟ لدى The Graph سوق؛ والاستضافة الذاتية مجانية لكنها ثقيلة تشغيليًا. لم تُحسم الجوانب الاقتصادية بعد.
- ما مسار الخروج لتاجر يختفي مستضيف واجهته الأمامية الأساسي؟ تجعل P5 الاستضافة الذاتية ممكنة، لكنها لا تجعلها تلقائية. تدفق «نقل متجري إلى مستضيف آخر» عمل مستقبلي.
- ما الذي تقرره الحوكمة فعليًا في بروتوكول بعقود غير قابلة للتغيير لكل رابط؟ ترقيات المصانع، وضبط معاملات المراكز (قوائم الرموز الموقوفة، والنشر على شبكات جديدة)، والقيم الافتراضية لتقسيم الرسوم لحركة OrcaRail المستضافة، وليس أكثر من ذلك بكثير. وما إذا كان هذا النطاق كافيًا لتبرير حوكمة على السلسلة جزء من حوار ما بعد اللامركزية.
- ماذا يحدث للبروتوكول إذا غيّرت شركة OrcaRail رأيها بشأن الحجز في القسم 9؟ أي تغيير هو تغيير منشور في هذه الورقة. لا تحوّل أحادي صامت.
18. الخاتمة: دعوة للبنّائين
تُخرج خارطة الطريق غير الاحتجازية البنية من الحفظ. وتُخرج هذه الورقة البنية من يد OrcaRail. يجب إطلاق الاثنين ليكون لأيٍّ منهما معنى.
إذا كنت تبني محفظة أو لوحة تحكم أو مفهرسًا أو solver أو أداة امتثال أو معالجًا منافسًا، فالبروتوكول مصمم ليقبل مساهمتك دون طلب إذن. شارك في كتابة الـ EIP. شغّل الـ subgraph. ثبّت واجهتك الأمامية الخاصة. شغّل keeper أو solver. افتح issues على التطبيق المرجعي. كلما أنجز أشخاص لا يعملون في OrcaRail جزءًا أكبر من المسار P، استحق البروتوكول كلمة بروتوكول أكثر.
لن يلاحظ تجار Web2 الذين نعمل معهم اليوم أيًّا من هذا؛ فمفاتيح API والـ webhooks ولوحات التحكم لديهم تستمر في العمل. وهذا الاستقرار هو المقصود. نحن نغيّر أساس البنية، لا الواجهة التي تعامل معها التجار عند التسجيل.
المراجع
- خارطة طريق OrcaRail نحو نموذج غير احتجازي — المسار N
- نقاش البروتوكول: خمس رؤى لـ OrcaRail غير احتجازية بالكامل — أصل المسار P
- لماذا يتفوق سحب الـ allowance على الضمان ومفاتيح الجلسة — قرار نموذج الاشتراك
- البنية — البنية التقنية الكاملة
- مرجع العقود — ABIs والأحداث والعناوين
- نموذج الأمان — افتراضات الثقة وحفظ المفاتيح
- خارطة الطريق — حالة مراحل المسار N
- تقييم EigenLayer — النمط المعاد استخدامه في P6