نمای کلی غیرامانی
OrcaRail در حال گذار از مدل امانی جمعآوری (یک کیف پول HD روی سرور برای هر لینک پرداخت، که وجوه پس از مشاهده جمعآوری و تقسیم میشوند) به مدل قراردادی غیرامانی است (وجوه به یک قرارداد هوشمند مخصوص هر لینک میرسند که آنها را بهصورت اتمیک تقسیم میکند، و اشتراکها از allowanceای که در اختیار پرداختکننده است برداشت میکنند). این بخش مرجع اصلی این گذار است.
اطلاعیه روایی در /blog/non-custodial-roadmap است. این صفحه نقطه ورود پایدار است؛ پستهای هر فاز و صفحات مستندات به اینجا لینک میدهند.
چه کسانی تحت تأثیر قرار میگیرند
- پذیرندگان: سطح API شما تغییر نمیکند. آدرس لینکهای پرداخت، وبهوکها و اشیای اشتراک ساختار خود را حفظ میکنند. آنچه در زیر تغییر میکند جای نگهداری وجوه در حین انتقال است.
- پرداختکنندگان: پرداختهای یکباره دقیقاً هماناند. اشتراکها همچنان
approveآنچین یکباره (EVM) یا delegate در SPL (سولانا) را دارند، اما گیرنده مجوز به جای یک کیف پول داغ OrcaRail، یک قرارداد هوشمند قابل حسابرسی میشود. - یکپارچهسازان: فقط فیلدهای افزوده (آدرس قراردادها، متادیتای allowance). هیچ چیز موجودی بدون دوره منسوخسازی حذف نمیشود.
صورت مسئله
در سیستم فعلی، هر لینک پرداخت یک EOA مشتقشده از HD یا یک smart account از Alchemy میگیرد. واریزها آنجا مینشینند، سپس یک keeper در api/src/withdrawals/ آنها را جمعآوری میکند و تقسیم بین پذیرنده، پلتفرم و معرف را انجام میدهد. keeper هم مواد کلید (یک mnemonic رمزنگاریشده در hd_wallet_seed) و هم وجوه در حال انتقال را نگه میدارد.
همین پنجره حضانت مشکل است. حذف آن یک برد امنیتی، یک سادهسازی در انطباق مقرراتی و یک برد عملیاتی است (دیگر نه گس جمعآوری لازم است و نه کلید رمزنگاری mnemonic که باید از آن محافظت کرد).
وضعیت هدف
- EVM:
PaymentLinkFactoryبرای هر لینک یک آدرس CREATE2 محاسبه میکند؛ کلونهایPaymentLinkReceiverوجوه را میپذیرند و از طریقFeeSplitterبهصورت اتمیک تقسیم میکنند. اشتراکها رویSubscriptionHubباapproveدر ERC-20 اجرا میشوند. - سولانا: برنامه Anchor با نام
payment_linkبرای هر لینک یک PDA دارد؛ برنامهsubscriptionاز طریق اختیار delegate در SPL برداشت میکند. - بیتکوین: مولتیسیگ taproot دو از دو برای هر لینک با یک امضاکننده پذیرنده و PSBTهای بازپرداخت از پیش امضاشده. پرداخت دورهای BTC تا بلوغ Lightning BOLT12 خارج از محدوده است.
- Keeper: نقاط ورود عمومی
charge()؛ NestJS بهعنوان اصلی، Chainlink Automation یا Gelato بهعنوان پشتیبان؛ و در صورت نیاز یک AVS اختیاری روی EigenLayer.
برای نمودار کامل معماری را ببینید.
مسیر مطالعه
- با معماری برای تصویر کلی سیستم شروع کنید.
- مدل امنیتی را برای فرضهای اعتماد و حضانت کلید بخوانید.
- برای توابع و ABIها به مرجع قراردادها سر بزنید.
- اگر لینک یا اشتراک موجود دارید راهنمای مهاجرت را بخوانید.
- از استراتژی keeper برای فهم نحوه اجرای برداشتها و SLOها استفاده کنید.
- ملاحظات بیتکوین را برای محدوده واقعی BTC ببینید.
- ارزیابی EigenLayer را برای موضع ما درباره keeperهای غیرمتمرکز بخوانید.
- نقشه راه را برای وضعیت فاز به فاز دنبال کنید.
وضعیت فازها (خلاصه)
فهرست کامل فازها با وضعیت در نقشه راه است. فهرست سریع:
- فاز ۰: طراحی و راهبرد حسابرسی
- فاز ۱: قراردادهای لینک پرداخت EVM
- فاز ۲: اشتراکهای EVM (برداشت از allowance)
- فاز ۳: گسترش چند-EVM و افزونگی keeper
- فاز ۴: سولانا (برنامههای Anchor)
- فاز ۵: بیتکوین (حضانت کاهشیافته)
- فاز ۶: keeperهای غیرمتمرکز (EigenLayer)
- فاز ۷: بازنشستگی زیرساخت امانی
مستندات مرتبط
- اشتراکها: برداشت خودکار: جریان approve/revoke سمت پرداختکننده (سازگار با گیرنده مجوز غیرامانی جدید).
- برداشتها: استراتژی: مسیرهای تسویه برای هر خانواده زنجیره چگونه کار میکنند.
- مرجع: چندزنجیرهای: شبکههای پشتیبانیشده و پوشش توکنها.