چرا برداشت مبتنی بر allowance از اسکرو و session key بهتر است
۲۰ آوریل ۲۰۲۶ — هر محصول اشتراک کریپتو باید یک مسئله را حل کند: پرداخت‌کننده چطور پرداخت‌های آینده را مجاز کند بدون اینکه امانت‌داری را واگذار کند؟ سه پاسخ واقع‌بینانه وجود دارد. ما برداشت مبتنی بر allowance را انتخاب کردیم و این مطلب دلیلش را توضیح می‌دهد.
سه مدل
۱. برداشت مبتنی بر allowance (approve در ERC-20 + delegate در SPL)
پرداخت‌کننده یک بار روی قرارداد توکن approve(spender, cap) را امضا می‌کند. بعداً وقتی دوره‌ای سررسید شود، spender (همان SubscriptionHub ما یا برنامه سولانا) transferFrom را فراخوانی می‌کند (EVM) یا با اختیار delegate انتقال می‌دهد (SOL). امانت‌داری نزد پرداخت‌کننده می‌ماند؛ spender در طول عمر اشتراک حداکثر تا cap می‌تواند برداشت کند.
لغو: پرداخت‌کننده approve(spender, 0) یا Revoke را امضا می‌کند. از آن لحظه هیچ برداشتی موفق نمی‌شود.
این همان چیزی است که برداشت خودکار امروز استفاده می‌کند. مرحله ۲ spender را از یک کیف پول داغ تحت کنترل پلتفرم به یک قرارداد روی زنجیره منتقل می‌کند، اما سمت پرداخت‌کننده تغییری نمی‌کند.
۲. سپرده اسکرو
پرداخت‌کننده وجوه N دوره را در یک قرارداد اسکرو مخصوص هر اشتراک واریز می‌کند. قرارداد طبق زمان‌بندی وجه را به فروشنده آزاد می‌کند. پرداخت‌کننده هر زمان می‌تواند موجودی استفاده‌نشده (منهای دوره‌های پرداخت‌شده) را برداشت کند.
۳. کیف پول هوشمند با session key
پرداخت‌کننده از کیف پول هوشمند ERC-4337 استفاده می‌کند و یک session key با دامنه محدود به قرارداد اشتراک می‌دهد. session key فقط کارهایی را می‌تواند انجام دهد که دامنه‌اش اجازه می‌دهد (مثلاً «انتقال حداکثر X دلار USDC در هر ۳۰ روز به این آدرس»). پرداخت‌کننده با حذف session key مجوز را لغو می‌کند.
امتیازدهی
هر سه را روی پنج محور ارزیابی کردیم:
| محور | برداشت مبتنی بر allowance | اسکرو | session key |
|---|---|---|---|
| امانت‌داری در طول اشتراک فعال | پرداخت‌کننده | قرارداد اسکرو | پرداخت‌کننده (از طریق کیف پول هوشمند) |
| گام‌های راه‌اندازی برای پرداخت‌کننده | ۱ امضا | ۱ واریز (با گس) | ۱ ثبت‌نام در کیف پول 4337 |
| سازگاری کیف پول پرداخت‌کننده | همه کیف پول‌ها | همه کیف پول‌ها | فقط کیف پول‌های 4337 |
| وجوه قفل‌شده / سرمایه در گردش | ندارد | N ماه قفل | ندارد |
| تجربه لغو | لغو approve | برداشت + لغو | حذف session key |
| ریسک keeper | هر فراخواننده‌ای | هر فراخواننده‌ای | هر فراخواننده‌ای |
| پیچیدگی سمت فروشنده | حداقلی | حسابداری آزادسازی | راه‌اندازی bundler در 4337 |
| کار با MetaMask / Phantom | بله | بله | نه به‌صورت بومی |
| کار با Ledger / سخت‌افزاری | بله | بله | جزئی |
| شفافیت مقرراتی | بالا | کمتر (بوی اسکرو می‌دهد) | بالا |
چرا اسکرو نه
اسکرو جذاب‌ترین شعار را دارد («وجوه پرداخت‌کننده در قرارداد قفل است، نه نزد یک شرکت») اما بدترین تجربه واقعی را:
- پرداخت‌کنندگان دوست ندارند وجوه N ماه را قفل کنند. اشتراک ماهانه ۲۰ دلاری با اسکروی ۱۲ ماهه یعنی ۲۴۰ دلار قفل‌شده. سقفی روی نرخ تبدیل.
- برداشت‌ها پیچیده می‌شوند: قرارداد باید دوره‌های پرداخت‌شده و نشده را پیگیری کند، بازپرداخت جزئی را مدیریت کند و جلوی دسترسی فروشنده به وجوه آینده را بگیرد.
- «اسکرویی که وجوه مشتری را نگه می‌دارد» در چند حوزه قضایی بوی مقرراتی دارد که «allowance به یک قرارداد هوشمند» ندارد.
چرا session key نه
session key روی کیف پول‌های هوشمند 4337 زیباست. اما لازمه‌اش این است که کیف پول پرداخت‌کننده هوشمند باشد. بیشتر پرداخت‌کنندگان در ۲۰۲۶ هنوز از EOA استفاده می‌کنند (MetaMask، Rabby، کیف پول‌های سخت‌افزاری، امضاکنندگان Safe) و پرداخت‌کنندگان سولانا از کیف پول‌های keypair به سبک Phantom. اجبار به ثبت‌نام در 4337 برای یک اشتراک، نرخ تبدیل را نابود می‌کند.
مسیری هست که در آن 4337 کیف پول پیش‌فرض پرداخت‌کننده شود و session key ساده شود. هنوز به آنجا نرسیده‌ایم.
چرا امروز برداشت مبتنی بر allowance برنده است
- بدون هیچ تغییری در کیف پول پرداخت‌کننده. هر کیف پولی که بتواند
approveدر ERC-20 را امضا کند کار می‌کند؛ یعنی همه. - بدون وجوه قفل‌شده. امانت‌داری نزد پرداخت‌کننده می‌ماند؛ برداشت درست سر موعد انجام می‌شود.
- لغو همگانی است.
approve(0)یاRevokeجزئی است که رابط هر کیف پولی از قبل نشان می‌دهد. - keeper کالایی عمومی است.
SubscriptionHub.charge(id)عمومی و بدون نیاز به مجوز است. NestJS، Chainlink، Gelato یا یک AVS در EigenLayer (مرحله ۶ را ببینید) همه می‌توانند فراخوانی‌اش کنند. - روایت مقرراتی ساده‌تر است. پلتفرم هرگز وجوه در حال انتقال را نگه نمی‌دارد.
محدودیت‌های شناخته‌شده و راهکارهای ما
برداشت مبتنی بر allowance بی‌نقص نیست. معایب، صادقانه:
۱. تأیید نامحدود
کیف پول‌ها اغلب به‌طور پیش‌فرض مقدار approve نامحدود پیشنهاد می‌دهند. قراردادهای مخرب با allowance نامحدود کیف پول‌ها را خالی می‌کنند. راهکار ما: رابط کاربری صراحتاً تأیید محدود درخواست می‌کند (مثلاً 12 × monthly_amount برای اشتراک سالانه)، رقم دلاری را نشان می‌دهد و متن «هر زمان لغو کنید» را ارائه می‌دهد. قرارداد cap را جدا از allowance در ERC-20 اعمال می‌کند.
۲. لغو مجوز بین دو دوره
پرداخت‌کننده می‌تواند در میانه اشتراک مجوز را لغو کند و برداشت بعدی ناموفق می‌شود. همان حالت خرابی کارت ذخیره‌شده‌ای که باطل شده است. با وب‌هوک + ایمیل موجود مدیریت می‌شود: subscription-insufficient-allowance.hbs و subscription-past-due.hbs.
۳. allowance قدیمی پس از تغییر قیمت
اگر فروشنده در میانه اشتراک قیمت را بالا ببرد، cap قبلی ممکن است کافی نباشد. با اصل ثابت cap که charge() را revert می‌کند و رابط فروشنده که درخواست تأیید دوباره می‌دهد مدیریت می‌شود.
۴. برداشت دوباره بر اثر reorg
رباتی که از reorg بلاک سوءاستفاده کند می‌تواند charge() را تکرار کند. با lastChargedAt یکنوا در SubscriptionHub مدیریت می‌شود.
امروز برای پرداخت‌کنندگان چه تغییر می‌کند
هیچ. جریان فعلی برداشت خودکار از قبل approve(spender, amount) و SPL Approve را درخواست می‌کند؛ همان گام‌ها. مرحله ۲ spender را به آدرس یک قرارداد غیرامانی منتقل می‌کند. کیف پول شما همان صفحه مجوز را نشان می‌دهد.
برای فروشندگان چه تغییر می‌کند
هیچ تغییری در ساختار پاسخ API. فیلد approval_spender_address در شیء auto_charge اشتراک فقط به‌جای کیف پول داغ OrcaRail به قرارداد SubscriptionHub اشاره می‌کند. وب‌هوک‌ها در همان لحظه‌ها ارسال می‌شوند.
جمع‌بندی
| ملاحظه | برنده |
|---|---|
| تجربه ثبت‌نام پرداخت‌کننده | برداشت مبتنی بر allowance |
| سرمایه در گردش | برداشت مبتنی بر allowance / session key |
| سازگاری کیف پول | برداشت مبتنی بر allowance |
| شفافیت مقرراتی | برداشت مبتنی بر allowance / session key |
| انعطاف keeper | هر سه |
| سادگی قرارداد | برداشت مبتنی بر allowance |
برداشت مبتنی بر allowance در سازگاری کیف پول و سرمایه در گردش به‌طور قطعی برنده است و در همه محورهای دیگر مساوی یا برنده است. به همین دلیل اشتراک‌های OrcaRail بر پایه آن ساخته شده‌اند.
مرتبط: مرحله ۲: اشتراک مبتنی بر allowance · مستندات برداشت خودکار · مدل امنیتی