پروتکل OrcaRail: وایت‌پیپر زیرساخت پرداخت غیرامانی، بی‌وقفه و از وب۲ به وب۳
۲۰ آوریل ۲۰۲۶ — این وایت‌پیپر پروتکل OrcaRail است. بیانیه مرجع درباره چیزی است که OrcaRail در حال تبدیل شدن به آن است: یک زیرساخت پرداخت باز، بی‌طرف به‌طور معتبر، غیرامانی و بی‌وقفه که فروشنده وب۲ می‌تواند با APIهای HTTP و وب‌هوک‌های آشنا یکپارچه‌اش کند و پرداخت‌کننده وب۳ می‌تواند با هر کیف پولی از آن استفاده کند؛ و حتی اگر شرکت OrcaRail ناپدید شود، همچنان به تسویه ادامه می‌دهد.
این سند نقشه راه غیرامانی و مناظره پروتکل را گسترش می‌دهد و جایگزین آن‌ها نمی‌شود. نقشه راه غیرامانی (مسیر N، مراحل ۰ تا ۷) امانت‌داری را حذف می‌کند. این وایت‌پیپر یک مسیر موازی P اضافه می‌کند که بقیه چیزها را غیرمتمرکز می‌کند: ایندکسرها، فرانت‌اندها، استانداردها، keeperها و حاکمیت.
چکیده
پروتکل OrcaRail مجموعه‌ای از اجزای پایه روی زنجیره است (کارخانه‌ها و گیرنده‌های لینک پرداخت، هاب‌های اشتراک مبتنی بر allowance، تقسیم‌کننده‌های کارمزد، برنامه‌های Anchor روی سولانا و توصیف‌گرهای مولتی‌سیگ taproot روی بیت‌کوین) به‌همراه مشخصات عمومی برای ایندکسرها، keeperها، فرانت‌اندها و SDKهایی که روی این اجزا کار می‌کنند. پروتکل چهار اصل ثابت را برآورده می‌کند: غیرامانی (هیچ طرفی وجوه در حال انتقال را نگه نمی‌دارد)، بی‌وقفه (تسویه مشروع بدون OrcaRail ادامه می‌یابد)، بی‌طرف به‌طور معتبر (هیچ طرف واحدی نمی‌تواند تراکنش پرداخت‌شده و درست‌ساخت را سانسور کند) و سازگار با وب۲ (فروشندگان کلید API، وب‌هوک و داشبورد خود را حفظ می‌کنند). استقرار در دو مسیر موازی انجام می‌شود: مسیر N امانت‌داری را در هفت مرحله حذف می‌کند؛ مسیر P ایندکس‌گذاری، فرانت‌اندها، استانداردها و مسیریابی تسویه را در پنج مرحله غیرمتمرکز می‌کند. هنگام راه‌اندازی هیچ توکنی وجود ندارد و در این وایت‌پیپر هم برنامه‌ای برای آن نیست؛ توکن حاکمیتی آینده صراحتاً به‌عنوان یک گزینه برای پس از غیرمتمرکزسازی رزرو شده و اگر روزی معرفی شود، با وایت‌پیپر مخصوص خودش منتشر خواهد شد.
۱. مقدمه: چرا پروتکل، نه فقط محصول
OrcaRail امروز یک محصول پرداخت میزبانی‌شده است و گزینه‌های نصب روی سرور خودتان در راه است. این یک محصول است، نه پروتکل. محصولات را می‌توان بهتر کرد؛ به پروتکل‌ها می‌توان در غیاب سازنده‌شان اعتماد کرد.
نقشه راه غیرامانی امانت‌داری را از مسیر خارج می‌کند. این لازم است اما کافی نیست. حتی بدون امانت‌داری، یک زیرساخت پرداخت ممکن است از کار بیفتد اگر شرکت گرداننده‌اش قبض‌های AWS را نپردازد، تحریم شود یا فقط مسیرش را عوض کند. پروتکل باید وقتی این اتفاق‌ها می‌افتد همچنان کار کند.
مناظره پروتکل پنج معماری را بررسی کرد. جمع‌بندی این بود: مسیر «عمل‌گرا» را منتشر کن، فشار «حداکثرگرا» را روی آن حفظ کن، intentها را برای تجربه پرداخت‌کننده بپذیر، در طول راه استاندارد بنویس و زنجیره اختصاصی را آینده‌ای اختیاری نگه دار. این وایت‌پیپر همان جمع‌بندی است که به شکل تعهد نوشته شده است.
۲. اهداف طراحی
هر هدف با تعریفی دقیق و قابل آزمون بیان شده است. پرسش «آیا طراحی این را برآورده می‌کند؟» باید پاسخ بله یا خیر داشته باشد.
- غیرامانی — در هیچ لحظه‌ای از پرداخت یا برداشت اشتراک، کیف پول یا حسابی که در کنترل OrcaRail، پردازشگر فروشنده یا هر واسطه‌ای باشد وجوه پرداخت‌کننده را نگه نمی‌دارد. آزمون: آیا یک نهاد ناظر می‌تواند فقط با ابلاغ به OrcaRail وجوه در حال انتقال را مسدود کند؟ خیر.
- بی‌وقفه — اگر سرورهای OrcaRail برای مدت نامعلوم خاموش شوند، برداشت مشروع و سررسیدشده اشتراک همچنان روی زنجیره تسویه می‌شود و پرداخت‌کننده همچنان می‌تواند پرداخت یک‌باره را تکمیل کند. آزمون: پس از ۳۰ روز قطعی OrcaRail، آیا اشتراکی که درست تنظیم شده برداشتی را از دست داده است؟ خیر.
- بی‌طرف به‌طور معتبر — قواعد روی زنجیره عمومی‌اند، برای هر لینک تغییرناپذیرند و برای همه یکسان اعمال می‌شوند. OrcaRail نمی‌تواند در لایه تسویه به‌طور گزینشی از ارائه خدمت خودداری کند (فقط در فرانت‌اند خودش). آزمون: آیا فروشنده‌ای ناخواسته همچنان می‌تواند از طریق فرانت‌اند شخص ثالث پول دریافت کند؟ بله.
- سازگار با وب۲ — فروشندگان همان راحتی فعلی را حفظ می‌کنند (اندپوینت‌های REST، وب‌هوک، کلید API، داشبورد، ایمیل). تبدیل شدن به پروتکل از فروشنده نمی‌خواهد برای پذیرش پرداخت ابزارهای اتریوم اجرا کند. آزمون: آیا فروشنده‌ای که با کریپتو آشنا نیست می‌تواند در کمتر از یک ساعت یکپارچه‌سازی کند؟ بله.
- همتا‌به‌همتای واقعی — در بخش بعد دقیقاً تعریف شده است.
طراحی‌ای که هر یک از این اهداف را از دست بدهد ناقص است.
۳. «همتا‌به‌همتای واقعی» اینجا یعنی چه
اصطلاح همتا‌به‌همتا (P2P) معانی زیادی دارد. در این پروتکل سه لایه مشخص دارد.
- P2P در تسویه — پرداخت‌کننده امضا می‌کند؛ وجوه از پرداخت‌کننده به قرارداد روی زنجیره (EVM) یا PDA متعلق به برنامه (سولانا) یا مولتی‌سیگ دو از دو (بیت‌کوین) و از آنجا به‌صورت اتمیک به فروشنده و دریافت‌کنندگان کارمزد می‌رود. هیچ کیف پول OrcaRailی در مسیر نیست. مسیر N این را تضمین می‌کند.
- P2P در کشف — لینک پرداخت یا اشتراک به‌طور کامل از داده‌های روی زنجیره و (به‌طور اختیاری) فراداده سنجاق‌شده روی IPFS قابل بازیابی است. هر کیف پول، هر فرانت‌اند و هر پردازشگر شخص ثالثی می‌تواند آن را نمایش دهد و تکمیل کند. داشبورد میزبانی‌شده OrcaRail یکی از پیاده‌سازی‌های لایه نمایش است، نه ثبت‌کننده مرکزی.
- P2P در زنده‌بودن —
SubscriptionHub.charge(id)و دستورchargeدر Anchor عمومی‌اند. هر EOA یا solverی می‌تواند آن‌ها را فراخوانی کند. زمان‌بند OrcaRail یکی از چند مشارکت‌کننده است (Chainlink، Gelato، اجراشده توسط فروشنده، اجراشده توسط solver).
آنچه «همتا‌به‌همتای واقعی» اینجا نیست: ما Lightning نیستیم؛ لایه کانال مستقیم کیف پول به کیف پول نیستیم؛ اپ پرداخت را با DHT جایگزین نمی‌کنیم. OrcaRail یک پروتکل روی زنجیره با تجربه کاربری خارج از زنجیره است. ویژگی P2P از این می‌آید که هیچ واسطه‌ای نمی‌تواند در تسویه، کشف یا زنده‌بودن خودش را وارد کند؛ نه از دوری از زیرساخت روی زنجیره.
۴. معماری سیستم
در بالاترین سطح، پروتکل پنج لایه دارد.
لایه تسویه روی EVM و سولانا برای هر لینک تغییرناپذیر است و روی بیت‌کوین برای هر لینک از توصیف‌گر مشتق می‌شود. چهار لایه دیگر قابل جایگزینی‌اند. اگر نمودار فنی کامل را می‌خواهید، به /docs/non-custodial/architecture بروید.
۵. اجزای پایه تسویه
مرجع کامل: /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های بازپرداخت از پیش امضاشده. تا بلوغ پرداخت دوره‌ای Lightning BOLT12، BTC دوره‌ای نداریم.
هر جزء طوری طراحی شده که یک linkId یا subscriptionId مشخص برای همیشه به همان آدرس قطعی روی همان زنجیره برسد؛ بدون چرخش آدرس، بدون صدور مجدد و بدون نگاشت ذخیره‌شده روی سرور.
۶. بین‌زنجیره‌ای به‌شکل intent
پروتکلی که بین‌زنجیره‌ای را «بک‌اند ما Relay را صدا می‌زند» ببیند، هنوز یک محصول است. پروتکل بین‌زنجیره‌ای را intent پرداخت‌کننده می‌بیند:
- پرداخت‌کننده امضا می‌کند: «به فروشنده X مبلغ ۵۰ دلار USDC بپرداز، از هر یک از کیف پول‌هایم روی هر زنجیره پشتیبانی‌شده، ظرف ۱ ساعت، با کارمزد حداکثر Y.»
- شبکه‌های solver موجود (Across، Relay، deBridge و سبک CoW) برای انجام intent رقابت می‌کنند. به solverها پاداشی پرداخت می‌شود که در خود intent گنجانده شده است.
- برای مسیرهای کم‌سود دنباله بلند (مبالغ کم، زنجیره‌های کمتر شناخته‌شده)، OrcaRail یک solver پشتیبان به قیمت تمام‌شده اجرا می‌کند تا این دنباله هم تسویه شود. این پشتیبان عمومی است و هر کس دیگری هم می‌تواند یکی اجرا کند.
امضای پرداخت‌کننده به مبلغ، گیرنده، مهلت و سقف کارمزد محدود است. در بدترین حالت، solver مخرب کند عمل می‌کند؛ نمی‌تواند وجوه را به جای دیگری بفرستد. این همان جمع‌بندی «باورمند به intent» از مناظره پروتکل است که به شکل تعهد نوشته شده است.
۷. استانداردها و تعامل‌پذیری
اجزای پایه لینک پرداخت و اشتراک OrcaRail یک زیرساخت عمومی‌اند. ارزش آن‌ها فقط وقتی چند برابر می‌شود که پردازشگرها، کیف پول‌ها و ایندکسرهای دیگر به‌طور بومی پیاده‌سازی‌شان کنند.
تعهدات:
- نوشتن پیش‌نویس EIP برای لینک‌های پرداخت غیرامانی با
PaymentLinkFactoryوPaymentLinkReceiverبه‌عنوان سطح مرجع. هم‌نویسی با دست‌کم یک تیم پردازشگر یا کیف پول دیگر تا از الگوی «EIP یک فروشنده» دوری شود. - نوشتن پیش‌نویس EIP برای اشتراک مبتنی بر allowance با
SubscriptionHubبه‌عنوان مرجع.lastChargedAtیکنوا و مجموعه دلایلChargeSkipped(reason)اهداف استانداردسازی‌اند. - انتشار معادل سولانا از طریق IDL انکر و یک مشخصات مکتوب، تا هر کیف پول یا ایندکسر سولانا بتواند لینک پرداخت را از پایه نمایش دهد.
- انتشار طرح‌واره مرجع subgraph تا هر ایندکسری (The Graph، Goldsky، Envio، روی سرور خودتان) بدون تغییر سازگار باشد.
نوشتن EIP مزیت رقابتی ما را کم نمی‌کند. همان‌طور که در مناظره استدلال شد، مزیت رقابتی در یکپارچه‌سازی‌ها، انطباق، SLAها و اعتماد فروشندگان است و هیچ‌کدام با یک EIP کپی نمی‌شود.
۸. حاکمیت
حاکمیت دو افق دارد.
امروز و کوتاه‌مدت
- EVM: مولتی‌سیگ Safe سه از پنج روی هر زنجیره مستقرشده. امضاکنندگان با کیف پول سخت‌افزاری. چرخش سالانه. timelock چهل‌وهشت ساعته روی ارتقای proxyها. نمونه‌های
PaymentLinkReceiverهر لینک تغییرناپذیرند. - سولانا: مولتی‌سیگ Squads سه از پنج با همان مجموعه امضاکنندگان و همان سیاست چرخش.
- دامنه ارتقا: کارخانه‌ها و هاب‌ها پشت proxyهای UUPS قرار دارند؛ گیرنده‌های هر لینک و رکوردهای هر اشتراک با ارتقا جابه‌جا نمی‌شوند.
- قابل حسابرسی عمومی: هر استقرار و ارتقا به‌صورت مراسم مولتی‌سیگ اعلام‌شده با ثبت تراکنش‌های امضاشده انجام می‌شود.
این همان حاکمیتی است که در /docs/non-custodial/security-model شرح داده شده است.
پس از غیرمتمرکزسازی
به‌مرور، مجموعه امضاکنندگان دیگر فقط کارمندان OrcaRail نیستند و به یک شورای عمومی متشکل از یکپارچه‌کنندگان، شرکت‌های حسابرسی، گردانندگان keeper و مشارکت‌کنندگان مستقل تبدیل می‌شود. اختیار ارتقا به شورا منتقل می‌شود. در این مرحله حاکمیت روی زنجیره به گزینه‌ای واقعی تبدیل می‌شود؛ اما فقط به‌عنوان سازوکار حاکمیت، نه ابزار سفته‌بازی.
آستانه «پس از غیرمتمرکزسازی» صریح است: دست‌کم سه فرانت‌اند مستقل در محیط عملیاتی که زیرساخت را میزبانی کنند، دست‌کم سه keeper مستقل که برداشت‌ها را اجرا کنند، و دست‌کم یک پردازشگر غیر از OrcaRail که یکپارچه‌سازی منتشر کند. تا این‌ها واقعی نشوند، پروتکل غیرمتمرکز نیست؛ فارغ از اینکه چه سازوکار حاکمیتی رویش باشد.
۹. توکن حاکمیتی آینده (رزرو صریح)
این بخش عمداً کوتاه و عمداً دقیق است.
- هنگام راه‌اندازی توکنی نیست. پیش‌فروشی نیست. تخصیصی نیست. امتیازی نیست. ادعای عطف به ماسبق نیست.
- توکن حاکمیتی آینده به‌عنوان یک گزینه رزرو شده است، نه به‌عنوان تعهد. فقط پس از رسیدن به آستانه غیرمتمرکزسازی بخش ۸ و وجود پایه فعالی از یکپارچه‌کنندگان، keeperها و فرانت‌اندها که از حق رسمی اعلام نظر سود ببرند، مناسب می‌شود.
- اگر روزی آن را معرفی کنیم، با وایت‌پیپر مخصوص خودش و با شفافیت کامل درباره توزیع، قفل‌ها، عرضه و سطح حاکمیت منتشر می‌شود. وایت‌پیپر توکن پیش از انتشار به‌طور عمومی به بحث گذاشته می‌شود.
- توکن اول برای حاکمیت است، نه سفته‌بازی. سازوکارهای معقول: رأی‌گیری اعلام نظر درباره ارتقاها، تنظیم پارامترها در محدوده‌های امن، اعتبار گردانندگان keeper. سازوکارهای نامعقول: تخفیف کارمزد وابسته به میزان دارایی، پرداخت برای پرداخت، yield farming.
- به‌خاطر وجود توکن ادعا نمی‌کنیم پروتکل غیرمتمرکز است. غیرمتمرکز بودن با موارد بخش ۸ سنجیده می‌شود. توکن ابزاری است که می‌تواند غیرمتمرکزسازیِ به‌دست‌آمده را رسمی کند؛ نمی‌تواند آن را بسازد.
این رزرو در وایت‌پیپر پروتکل (همین سند) ثبت شده و جای دیگری نه. هر تغییر آینده در این موضع، تغییری در همین وایت‌پیپر است که به‌طور عمومی منتشر می‌شود، نه اعلامیه‌ای یک‌جانبه.
۱۰. اقتصاد و کارمزدها: پروتکل چطور بدون توکن پایدار می‌ماند
مدل درآمدی پروتکل همان مدل محصول است، فقط روی زنجیره کدگذاری شده است.
- تقسیم کارمزد در پیکربندی واحد پایه
FeeSplitterبرای هر پرداخت قرار دارد. همان سهم‌هایی که صفحه برداشت‌ها امروز توضیح می‌دهد: فروشنده، پلتفرم (سهم میزبانی OrcaRail)، معرف/همکار فروش و کارمزد پل. - سطح میزبانی‌شده OrcaRail (داشبورد، ایمیل، گس paymaster، پشتیبانی مشتری) از سهم OrcaRail در تقسیم پرداخت می‌شود.
- میزبان‌های جایگزین (پردازشگرهای شخص ثالث، گردانندگان نصب روی سرور خود، فرانت‌اندهای سنجاق‌شده روی IPFS) می‌توانند با سهم صفر برای پلتفرم کار کنند یا دریافت‌کننده کارمزد خودشان را تنظیم کنند. پروتکل کارمزد OrcaRail را بر کارمزد هیچ‌کس دیگری برتری نمی‌دهد.
- بدون انتشار توکن، بدون یارانه، بدون سود استیکینگ. هزینه‌ها نقدی و درآمدها نقدی‌اند. پروتکل فقط وقتی ارزان‌تر می‌شود که گس ارزان‌تر شود یا میزبانی حاشیه سود کمتری بپذیرد؛ نه با انتشار توکن برای پوشاندن هزینه‌های جاری.
۱۱. مدل امنیتی
بیان کامل: /docs/non-custodial/security-model. رویکرد اصلی:
- گیرنده‌های هر لینک و رکوردهای هر اشتراک تغییرناپذیرند.
- کارخانه‌ها و هاب‌ها فقط از طریق مولتی‌سیگ + timelock قابل ارتقا هستند.
- keeperها EOAهایی هستند که فقط گس می‌پردازند و اختیار جابه‌جایی وجوه ندارند.
- امضای BTC در سمت پلتفرم از سرویس HSM یا MPC به‌علاوه کلید فروشنده استفاده می‌کند؛ هیچ سروری اختیار یک‌جانبه خرج کردن ندارد.
یک افزوده مخصوص پروتکل‌سازی: میزبان‌های مستقل فرانت‌اند باید پیش از نمایش لینک پرداخت، آدرس قراردادها را با یک رجیستری روی زنجیره (یا یک مانیفست انتشار امضاشده) بررسی کنند. فرانت‌اند کلون مخربی که پرداخت‌ها را به قراردادی شبیه به اصل بفرستد، محتمل‌ترین راه فیشینگ پس از چندمیزبانی شدن اکوسیستم است. رجیستری مرجع روی زنجیره است و جریان بررسی به‌عنوان بخشی از P2 مستند می‌شود.
۱۲. نقشه راه: دو مسیر موازی
استقرار پروتکل هم‌زمان در دو مسیر پیش می‌رود.
مسیر N همان نقشه راه موجود است، بدون تغییر. مسیر P تعهدات M1 تا M5 از مطلب مناظره را به شکل مرحله رسمی می‌کند. هر دو مسیر یک وضعیت نهایی را هدف گرفته‌اند: زیرساختی که اگر OrcaRail کنار برود همچنان کار کند.
مسیر P هرگز مسیر N را متوقف نمی‌کند و مسیر N هرگز مسیر P را. هر کدام می‌تواند زودتر از دیگری مرحله‌ای را منتشر کند.
۱۳. مراحل مسیر P
پنج مرحله، که هر کدام ادامه طبیعی یکی از تعهدات M در مطلب مناظره است.
P1 — subgraph عمومی و ایندکسر باز
دامنه: یک subgraph مرجع (The Graph، Envio یا معادل) که همه رویدادهای Paid، SubscriptionCreated، Charged، ChargeSkipped، Canceled و Refunded از PaymentLinkReceiver و SubscriptionHub را روی همه زنجیره‌های مستقرشده ایندکس کند. طرح‌واره منتشر شود. دستورالعمل نصب روی سرور خود منتشر شود تا هر کسی بتواند همان ایندکس را اجرا کند.
چک‌لیست وضعیت
- مانیفست + mappingهای subgraph برای زنجیره‌های EVM فعال در مرحله ۱ و مرحله ۳
- معادل سولانا (وب‌هوک‌های 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 است. مشخصات معادل سولانا همراه با EIPها منتشر می‌شود.
چک‌لیست وضعیت
- تأیید هم‌نویسنده
- پیش‌نویس EIP لینک پرداخت در مرحله رشته بحث
- پیش‌نویس EIP اشتراک در مرحله رشته بحث
- انتشار مشخصات سولانا همراه با IDLهای Anchor
- اعمال بازخورد ویراستاران EIP تا مرحله Last Call
P4 — SDK پرداخت‌کننده مبتنی بر intent
دامنه: یک سطح SDK (orcarail.pay(intent)) که intent امضاشده پرداخت‌کننده را بپذیرد و از طریق شبکه‌های solver موجود (Across، Relay، deBridge) مسیریابی کند، با یک solver پشتیبان که OrcaRail برای مسیرهای دنباله بلند اجرا می‌کند. طرح‌واره intent هم‌گام با P3 استاندارد می‌شود.
چک‌لیست وضعیت
- نهایی شدن طرح‌واره intent
- آداپتور SDK برای دست‌کم دو شبکه solver
- استقرار و اندازه‌گیری solver پشتیبان
- پشتیبانی تجربه پرداخت‌کننده در اپ پرداخت از intent یکسان + بین‌زنجیره‌ای
- انتشار مشخصات به‌عنوان بخشی از مرجع SDK نود
P5 — کیت نصب روی سرور خود / پیاده‌سازی مرجع
دامنه: یک Docker Compose (و Helm chart) که به هر کسی اجازه دهد یک پردازشگر سازگار با OrcaRail را سرتاسر از روی قراردادهای عمومی اجرا کند. شامل subgraph، keeper، ایندکسر، داشبورد اختیاری و مشخصات OpenAPI برای API پردازشگر که دیگران بتوانند با آن منطبق شوند.
چک‌لیست وضعیت
- Docker Compose که روی یک زنجیره واقعی بالا می‌آید و به یک فروشنده آزمایشی سرویس می‌دهد
- مشخصات OpenAPI برای API پردازشگر
- Helm chart برای گردانندگان Kubernetes
- آزمون سرتاسری که نشان دهد گرداننده نصب روی سرور خود پرداخت‌ها را دقیقاً مثل نسخه میزبانی‌شده پردازش می‌کند
- مستندات در
/docs/non-custodial/(در یک تغییر آینده فقط برای مستندات اضافه می‌شود؛ خارج از دامنه این وایت‌پیپر)
۱۴. P6 اختیاری: ارزیابی زنجیره اختصاصی
P6 از الگوی ارزیابی EigenLayer پیروی می‌کند. این یک تعهد نیست. یک بازبینی فصلی با محرک‌های مشخص است.
توصیه فعلی: به تعویق انداختن.
محرک‌هایی که باعث باز شدن سند طراحی برای ساخت مرحله P6 می‌شوند:
- حجم پرداخت روی یک زنجیره از آستانه‌ای بگذرد که گس به قلم قابل توجهی از کارمزد پلتفرم تبدیل شود.
- یک زنجیره ابزار مرجع L2/L3 پیش‌کامپایل‌های تخصصی برای منطق تقسیم پرداخت با هزینه تقریباً صفر ارائه دهد.
- تقاضای فروشندگان برای تأخیر تسویه کسری از سنت که شبکه اصلی / L2 به‌طور مداوم نتواند برآورده کند.
- یک شریک rollup-as-a-service به OrcaRail اجازه دهد از روز اول با توالی‌دهی مشترک راه‌اندازی شود.
در صورت فعال شدن، ساخت ترجیحاً با OP Stack و توالی‌دهی مشترک (Espresso، Astria) و یک پل خروج معتبر به زنجیره‌های مرجعی که هم‌اکنون پشتیبانی می‌کنیم انجام می‌شود. حتی در آن صورت، مراحل N0 تا N7 و P1 تا P5 باید آن‌قدر بالغ باشند که زنجیره اختصاصی یک بهینه‌سازی باشد، نه یک وابستگی.
۱۵. OrcaRail امروز چیست و به چه تبدیل می‌شود
مقایسه قبل و بعد در سطح زیرساخت.
| بُعد | امروز | پس از مسیرهای N و P |
|---|---|---|
| امانت‌داری هنگام پرداخت | OrcaRail کلید کیف پول واریز را نگه می‌دارد | بدون امانت‌داری. پرداخت‌کننده ← قرارداد ← فروشنده با تقسیم اتمیک |
| spender اشتراک | smart account تحت کنترل OrcaRail | قرارداد عمومی SubscriptionHub؛ هر کسی می‌تواند فراخوانی کند |
| Keeper | زمان‌بند واحد NestJS | NestJS + Chainlink + Gelato + AVS اختیاری EigenLayer |
| ایندکسر | داخلی | subgraph عمومی با طرح‌واره مستند |
| اپ پرداخت / داشبورد | میزبانی‌شده توسط OrcaRail | میزبانی‌شده + نسخه‌های IPFS/ENS؛ میزبان‌های شخص ثالث خوش‌آمدند |
| جزء پایه لینک پرداخت | ساختار داخلی API | پیش‌نویس EIP با پیاده‌سازی مرجع |
| تسویه بین‌زنجیره‌ای | keeper اورکاریل Relay را صدا می‌زند | intentهای پرداخت‌کننده از طریق بازار solver + پشتیبان OrcaRail |
| حاکمیت | مولتی‌سیگ OrcaRail (بنیان‌گذاران + تیم) | شورای عمومی؛ حاکمیت روی زنجیره به‌عنوان گزینه واقعی |
| سطح مقرراتی | «OrcaRail پردازشگر است» | «OrcaRail یکی از پردازشگرهای متعدد روی یک زیرساخت است» |
| API قابل مشاهده برای فروشنده | REST + وب‌هوک | همان REST + وب‌هوک (پایدار) |
| توکن | ندارد | ندارد؛ به‌عنوان گزینه آینده رزرو شده (بخش ۹) |
سطح رو به وب۲ عمداً پایدار می‌ماند. فروشندگانی که در ۲۰۲۶ با API نوع REST یکپارچه شده‌اند، در ۲۰۲۸ دچار مشکل نمی‌شوند.
۱۶. مدل تهدید
تهدیدهایی که صراحتاً در نظر داریم، همراه با راهکار کاهش آن‌ها:
- باگ قرارداد ← چند حسابرسی برای هر قرارداد؛ گیرنده‌های تغییرناپذیر برای هر لینک؛ ارتقای UUPS پشت timelock چهل‌وهشت ساعته روی کارخانه‌ها و هاب‌ها؛ برنامه عمومی پاداش کشف باگ.
- قطعی keeper ← افزونگی keeper در مرحله ۳ مسیر N (Chainlink/Gelato) + شبکه solver در P4 مسیر P + فراخوانی دستی عمومی
charge()به‌عنوان پشتیبان. - فیشینگ فرانت‌اند ← رجیستری قرارداد روی زنجیره در P2 مسیر P + آدرس‌دهی مبتنی بر محتوا با ENS + مراسم امضای انتشار از مولتی‌سیگ Safe.
- تصاحب حاکمیت ← چرخش امضاکنندگان مولتی‌سیگ؛ آستانه سه از پنج؛ شورای پس از غیرمتمرکزسازی از گردانندگان مستقل؛ مراسم عمومی.
- اقدام مقرراتی علیه یک میزبان ← کیت نصب روی سرور خود در P5 مسیر P + چند فرانت‌اند مستقل تا فروشندگان زیرساخت جایگزین داشته باشند.
- انحراف subgraph یا ایندکسر ← طرح‌واره مرجع + آزمون‌های تکرارپذیری؛ چند ایندکسر مستقل.
- کم‌عمقی بازار solver ← solver پشتیبان OrcaRail به قیمت تمام‌شده؛ ورود بدون نیاز به مجوز برای solverهای جدید.
- گم شدن کلید BTC ← xpub پشتیبان هنگام ثبت‌نام فروشنده؛ جایگزینی خودکار HSM؛ PSBTهای بازپرداخت از پیش امضاشده امکان بازیابی برای پرداخت‌کننده را حفظ می‌کنند.
- بازسازمان‌دهی (reorg) زنجیره‌های EVM ←
lastChargedAtیکنوا درSubscriptionHub؛ معادل سولانا درlast_charged_at. - انحراف ناشی از توکن ← بدون توکن هنگام راه‌اندازی؛ رزرو صریح؛ هر توکن آینده پیش از اینکه بتواند نقش حاکمیتی بگیرد، مشروط به آستانه گردانندگان مستقل است.
۱۷. پرسش‌های باز که صادقانه می‌پذیریم
نوشتن این سند همه پرسش‌هایی را که مطرح می‌کند حل نمی‌کند.
- «پس از غیرمتمرکزسازی» دقیقاً کی شروع می‌شود؟ بخش ۸ یک آستانه می‌دهد (سه فرانت‌اند مستقل، سه keeper مستقل، یک پردازشگر غیر از OrcaRail). اینکه این آستانه درست است یا نه، بحثی باز است.
- هزینه subgraph عمومی در مقیاس بالا را چه کسی می‌پردازد؟ The Graph بازار دارد؛ نصب روی سرور خود رایگان است اما از نظر عملیاتی سنگین. اقتصاد آن هنوز روشن نیست.
- مسیر خروج فروشنده‌ای که میزبان اصلی فرانت‌اندش ناپدید می‌شود چیست؟ P5 نصب روی سرور خود را ممکن می‌کند، اما خودکارش نمی‌کند. جریان «انتقال فروشگاهم به میزبان دیگر» کار آینده است.
- حاکمیت در پروتکلی با قراردادهای تغییرناپذیر برای هر لینک واقعاً درباره چه تصمیم می‌گیرد؟ ارتقای کارخانه‌ها، تنظیم پارامترهای هاب‌ها (فهرست توکن‌های متوقف‌شده، استقرار روی زنجیره‌های جدید)، مقادیر پیش‌فرض تقسیم کارمزد برای ترافیک میزبانی‌شده OrcaRail؛ اما نه خیلی بیشتر. اینکه این دامنه برای توجیه حاکمیت روی زنجیره کافی است یا نه، بخشی از گفت‌وگوی پس از غیرمتمرکزسازی است.
- اگر شرکت OrcaRail نظرش را درباره رزرو بخش ۹ عوض کند، چه بر سر پروتکل می‌آید؟ هر تغییری، تغییری منتشرشده در همین وایت‌پیپر است. هیچ چرخش یک‌جانبه و بی‌سروصدایی در کار نیست.
۱۸. جمع‌بندی: دعوت از سازندگان
نقشه راه غیرامانی زیرساخت را از امانت‌داری جدا می‌کند. این وایت‌پیپر زیرساخت را از OrcaRail جدا می‌کند. هر دو باید منتشر شوند تا هر کدام معنا پیدا کند.
اگر در حال ساختن کیف پول، داشبورد، ایندکسر، solver، ابزار انطباق یا پردازشگر رقیب هستید، پروتکل طوری طراحی شده که مشارکت شما را بدون نیاز به اجازه بپذیرد. در نوشتن EIP مشارکت کنید. subgraph را اجرا کنید. فرانت‌اند خودتان را سنجاق کنید. keeper یا solver اجرا کنید. برای پیاده‌سازی مرجع issue ثبت کنید. هرچه بخش بیشتری از مسیر P توسط کسانی انجام شود که در OrcaRail کار نمی‌کنند، پروتکل بیشتر شایسته واژه پروتکل می‌شود.
فروشندگان وب۲ که امروز با آن‌ها کار می‌کنیم متوجه هیچ‌کدام از این‌ها نمی‌شوند؛ کلیدهای API، وب‌هوک‌ها و داشبوردهایشان همچنان کار می‌کنند. همین پایداری هدف است. ما پایه زیرساخت را تغییر می‌دهیم، نه سطحی را که فروشندگان هنگام ثبت‌نام با آن سروکار داشتند.
منابع
- نقشه راه غیرامانی OrcaRail — مسیر N
- مناظره پروتکل: پنج چشم‌انداز برای OrcaRail کاملاً غیرامانی — خاستگاه مسیر P
- چرا برداشت مبتنی بر allowance از اسکرو و session key بهتر است — تصمیم درباره مدل اشتراک
- معماری — معماری فنی کامل
- مرجع قراردادها — ABIها، رویدادها و آدرس‌ها
- مدل امنیتی — فرض‌های اعتماد و نگهداری کلیدها
- نقشه راه — وضعیت مراحل مسیر N
- ارزیابی EigenLayer — الگویی که برای P6 تکرار شده است