مرحله ۰: طراحی یک پشته پرداخت غیرامانی
۲۰ آوریل ۲۰۲۶ — پیش از نوشتن حتی یک خط Solidity، مشخصات را نهایی می‌کنیم. مرحله ۰ مرحله طراحی و تأیید نقشه راه غیرامانی است: چه چیزی روی زنجیره می‌رود و چه چیزی نه، کدام زنجیره اول راه‌اندازی می‌شود، چه کسی قراردادها را حسابرسی می‌کند و چه کسی کلیدهای استقرار را نگه می‌دارد.
خلاصه
- تقسیم کارمزد در چهار سهم نهایی شده است: فروشنده، پلتفرم، معرف/همکار فروش، کارمزد پل. همه‌چیز در تقسیم‌کننده روی زنجیره بر حسب واحد پایه (basis points) قابل بیان است؛ بدون اصلاحات خارج از زنجیره.
- Base زنجیره راه‌اندازی مرحله ۱ است. ارزان، سریع، از قبل در فهرست زنجیره‌های سرویس کیف پول و دارای USDC بومی.
- اشتراک‌ها از approve + برداشت در ERC-20 (EVM) و delegate در SPL (سولانا) استفاده می‌کنند. طرح‌های اسکرو و session key رد شدند؛ ماتریس تصمیم را در ادامه ببینید.
- قراردادها توسط مولتی‌سیگ Safe سه از پنج (EVM) و مولتی‌سیگ Squads سه از پنج (سولانا) مستقر می‌شوند. گیرنده‌های هر لینک تغییرناپذیرند. کارخانه‌ها و
SubscriptionHubپشت یک proxy کوچک با timelock چهل‌وهشت ساعته قرار دارند.
این مرحله چه چیزی را تغییر می‌دهد
هیچ چیزی در محیط عملیاتی. مرحله ۰ شامل یک مشخصات مکتوب، سه پیشنهاد حسابرسی، یک مراسم کلید استقرار و چند ADR ادغام‌شده است.
مشخصات تقسیم کارمزد (نهایی‌شده)
امروز، SmartAccountWalletService.drainSmartAccountWallet در api/src/withdrawals/services/smart-account-wallet.service.ts انتقال‌ها را در یک UserOperation با سه گیرنده ترکیب می‌کند: فروشنده (toAddress)، کیف پول پشتیبانی (supportWalletAddress) و کیف پول کمیسیون. نسخه قراردادی دقیقاً همین را بازتاب می‌دهد:
struct Split {
address merchant; // main receiver
address platform; // support / platform fee
address referral; // commission / affiliate (optional, zero = skip)
address bridgeFee; // Relay bridge fee carrier (optional, zero = skip)
uint16 platformBps;
uint16 referralBps;
uint16 bridgeFeeBps;
}
هر کاری که keeper امروز در TypeScript انجام می‌دهد از روی این struct و مبلغ پرداخت قابل محاسبه است. هر چیزی که keeper فعلی نمی‌تواند بیان کند (مثلاً مالیات پویا یا مبالغ نگه‌داشته‌شده در سطح فروشنده) خارج از دامنه مرحله ۱ است و در صورت نیاز در مرحله‌ای بعدی اضافه می‌شود.
انتخاب زنجیره
زنجیره راه‌اندازی مرحله ۱ Base است:
- از قبل در نگاشت chainId ما (
8453 → base،84532 → baseSepolia) درapi/src/payments/wallet.service.tsوجود دارد. - گس آن‌قدر ارزان است که استقرار
PaymentLinkReceiver+ تقسیم در اولین پرداخت، برای هر تراکنش فقط چند سنت هزینه دارد. - سیاست paymaster آلکمی از قبل از آن پشتیبانی می‌کند؛ اگر بخواهیم هزینه keeper روی
SubscriptionHub.charge()را حمایت کنیم، راه فرار داریم. - USDC بومی (نه پل‌شده) دارد که برای allowance اشتراک‌ها مهم است.
Ethereum mainnet، Arbitrum، Optimism و Polygon در مرحله ۳ اضافه می‌شوند. سولانا یک برنامه جداگانه است که در مرحله ۴ پیگیری می‌شود.
مدل اشتراک: ماتریس تصمیم
سه طرح را ارزیابی کردیم. فقط یکی برای ما کار می‌کند.
| مدل | امانت‌داری | تجربه پرداخت‌کننده | سازگاری کیف پول | نیاز به keeper | نتیجه |
|---|---|---|---|---|---|
| approve + برداشت در ERC-20 (انتخاب‌شده) | ندارد | یک approve یک‌باره | MetaMask، Phantom، Ledger، Safe؛ بومی | هر فراخواننده‌ای؛ keeper اختیاری | همین را منتشر کن |
| سپرده اسکرو | ندارد | سپرده N ماه | همه کیف پول‌ها | هر فراخواننده‌ای | تجربه بدتر؛ وجوه قفل می‌شوند |
| کیف پول هوشمند + session key | ندارد | ثبت‌نام در 4337 | فقط کیف پول‌های 4337 | امضاکننده session key | سازگاری بیش از حد محدود |
approve + برداشت تنها طرحی است که با کیف پول‌هایی که پرداخت‌کنندگان همین حالا استفاده می‌کنند (MetaMask، Phantom، کیف پول‌های سخت‌افزاری، Safeها) کار می‌کند. همچنین همان طرحی است که در برداشت خودکار منتشر کرده‌ایم و approve(spender, amount) و delegation در SPL را مستند می‌کند. مرحله ۲ سمت برداشت را با یک قرارداد هوشمند جایگزین می‌کند و سمت پرداخت‌کننده را تغییر نمی‌دهد.
استدلال کامل در چرا برداشت مبتنی بر allowance از اسکرو و session key بهتر است آمده است.
نگهداری کلیدهای استقرار
- EVM: Safe (پیش‌تر Gnosis Safe) روی Base با آستانه سه از پنج. امضاکنندگان: دو بنیان‌گذار، یک مسئول عملیات، یک مشاور و یک نسخه پشتیبان سرد. هر امضاکننده از کیف پول سخت‌افزاری استفاده می‌کند؛ هیچ کلیدی روی سرور نیست.
- سولانا: مولتی‌سیگ Squads با همان تنظیم سه از پنج و همان امضاکنندگان.
- چرخش: هر امضاکننده سالانه یا هنگام جدایی چرخش می‌یابد؛ هر چرخش یک تراکنش Safe/Squads است.
- هیچ keeper داغی نمی‌تواند استقرار دهد. EOA مربوط به keeper در NestJS (که در مرحله ۲ برای فراخوانی
charge()استفاده می‌شود) هیچ اختیار استقرار، ارتقا یا آدرس کارمزدی ندارد.
سیاست ارتقا
PaymentLinkReceiverهر لینک: تغییرناپذیر. بدون ارتقا. این برای پرداخت‌کنندگان امتیاز اعتمادی است؛ کدی که به آن پرداخت می‌کنند بعداً تغییر نمی‌کند.PaymentLinkFactory: proxy کوچک UUPS متعلق به مولتی‌سیگ، با timelock چهل‌وهشت ساعته رویupgradeTo. ارتقاها نمی‌توانند گیرنده‌های مستقرشده را تغییر دهند.SubscriptionHub: همان الگو. معنایcharge()وcancel()بین نسخه‌ها پایدار است؛ اگر روزی تغییر ناسازگاری لازم شود، به‌جای ارتقاSubscriptionHubV2را مستقر و مهاجرت می‌کنیم.- معنای بازپرداخت و اختلاف:
refund(txId)روی زنجیره که امضاکننده فروشنده (از طریق کلید API او ← EOA مربوط به keeper) یا مولتی‌سیگ استقرار می‌تواند فراخوانی کند. پرداخت‌کننده نمی‌تواند خودش بازپرداخت بگیرد (مطابق محصول فعلی).
راهبرد انتخاب شرکت حسابرسی
سه شرکت را در فهرست کوتاه قرار می‌دهیم و یک حسابرسی اصلی + یک بازبینی رقابتی انجام می‌دهیم:
- نامزدهای اصلی (EVM): Spearbit، Trail of Bits، Zellic.
- نامزدهای ثانویه (سولانا): OtterSec، Neodyme.
- دامنه:
PaymentLinkFactory،PaymentLinkReceiver،FeeSplitter،SubscriptionHub. برنامه‌های Anchor در مرحله ۴ حسابرسی جداگانه دارند. - بودجه: حسابرسی پیش‌نیاز قطعی راه‌اندازی روی Base mainnet است. پیش از گزارش رفع همه موارد، mainnet نداریم.
- افشای عمومی: گزارش‌های حسابرسی در مخزن قرار می‌گیرند و از /docs/non-custodial/security-model لینک می‌شوند.
ریسک‌ها و راهکارها
- گسترش بی‌رویه مشخصات. راهکار: هر چیزی که به شکل تقسیم بر حسب واحد پایه قابل بیان نباشد به مرحله بعد موکول می‌شود. مرحله ۱ منتظر مالیات پویا یا تنظیمات اختصاصی هر فروشنده نمی‌ماند.
- در دسترس بودن امضاکنندگان مولتی‌سیگ. راهکار: سه از پنج، نه دو از سه؛ تا اگر هر دو امضاکننده‌ای در دسترس نباشند استقرارها متوقف نشوند.
- زمان‌بندی حسابرسی. راهکار: گفت‌وگو با شرکت‌ها از همین حالا شروع شود؛ قراردادها در حین حسابرسی روی شبکه آزمایشی منتشر شوند؛ استقرار روی mainnet مشروط است.
- فراموش شدن یک حالت کارمزد. راهکار: بازتولید همه مسیرهای فعلی
drainSmartAccountWallet(بومی + ERC-20، با/بدون پشتیبانی، با/بدون کمیسیون) به‌صورت آزمون invariant در Foundry پیش از حسابرسی.
چک‌لیست وضعیت
- تأیید و برچسب‌گذاری struct تقسیم کارمزد
- انتخاب Base به‌عنوان زنجیره راه‌اندازی مرحله ۱
- قرار گرفتن سه شرکت حسابرسی در فهرست کوتاه
- ساخت و آزمایش مولتی‌سیگ‌های استقرار Safe (Base) و Squads (سولانا)
- ادغام ADR درباره سیاست ارتقا و timelock
- ادغام ADR درباره تصمیم مدل اشتراک
- مستندسازی معنای بازپرداخت / اختلاف
قدم بعدی
مرحله ۱ این مشخصات را پیاده‌سازی می‌کند: لینک‌های پرداخت مبتنی بر قرارداد روی EVM.
مستندات مرجع: وضعیت مرحله ۰ · مدل امنیتی · معماری