پروپزال EIP-3009 چیست؟ ستون اصلی پروتکل پرداخت x402

پروپزال EIP-3009 یکی از مهم‌ترین به‌روزرسانی‌ها در نحوه انتقال توکن‌ها بر بستر بلاکچین است که بسیاری از موانع ورود کاربران به وب ۳ را از میان برداشته است. در الگوهای سنتی، کاربر برای انجام هر تراکنش مجبور است علاوه‌بر توکن موردنظر، توکن بومی شبکه را هم برای پرداخت گس داشته باشد. در مدل EIP-3009، کاربر فقط یک پیام امضاشده ایجاد می‌کند و شخص دیگری مانند سرور یا برنامه می‌تواند با آن امضا، انتقال را در بلاکچین انجام دهد. این کار باعث می‌شود کاربر نیازی به توکن گس نداشته باشد. علاوه بر این، هر مجوز فقط برای مدت محدودی اعتبار دارد و تنها یک‌بار قابل استفاده است که باعث افزایش امنیت تراکنش می‌شود.

این معماری به‌طور خاص برای پروتکل‌ پرداخت x402 ارزشمند است؛ زیرا سرورها می‌توانند امضای پرداخت را در هدر درخواست HTTP دریافت کنند و خودشان تراکنش را روی بلاکچین ثبت کنند. اگر علاقه‌مند هستید بدانید پروپزال EIP-3009 چیست، چطور به تسهیل فرآیند انتقال توکن‌ها کمک می‌کند و چرا به‌عنوان ستون اصلی پروتکل پرداخت x402 شناخته می‌شود، با این مطلب از میهن بلاکچین همراه باشید.

پروپزال EIP-3009 چیست؟

استاندارد EIP-3009 یکی از مهم‌ترین پیشنهادهای بهبود اتریوم (EIP) است که در سال ۲۰۲۰ توسط تیمی از مهندسان کوین‌بیس (Coinbase) شامل پیتر جی‌هون کیم (Peter Jihoon Kim)، کوین بریتز (Kevin Britz) و دیوید نات (David Knott) ارائه شد. این استاندارد، شیوه انتقال توکن‌ها در شبکه‌های سازگار با اتریوم را به‌طور بنیادی بازطراحی کرد.

در مدل سنتی، کاربران برای انتقال یک توکن باید دو تراکنش جداگانه ارسال می‌کردند؛ یکی برای تایید (approve) و دیگری برای انتقال (transferFrom). پروپزال EIP-3009، این فرآیند را با معرفی مفهوم «مجوز امضا‌‌شده خارج از زنجیره» متحول کرد. در این مدل، کاربر یک امضای رمزنگاری‌شده تولید می‌کند که شامل اطلاعاتی مانند فرستنده، گیرنده، مقدار انتقال، زمان اعتبار و یک نانس تصادفی است. سپس یک گیرنده یا واسطه می‌تواند با استفاده از همین امضا، تراکنش را در بلاکچین ثبت کند. دیگر نیازی به تعامل مستقیم کاربر با بلاکچین و پرداخت گس‌فی توسط او نیست.

همین ویژگی‌ها باعث شده است استاندارد EIP-3009 در نسخه دوم USDC پیاده‌سازی شود. امروز ماهانه بیش از ۵۰ میلیارد دلار تراکنش از طریق همین معماری انجام می‌گیرد. در ادامه با نحوه عملکرد این استاندارد بیشتر آشنا می‌شویم.

تابع انتقال با مجوز

در پروپزال EIP-3009، تابعی به نام انتقال با مجوز (transferWithAuthorization) قرار دارد که مسئول اجرای فرایند انتقال توکن‌ها بر اساس مجوزهای امضاشده خارج از زنجیره است. این تابع از طریق هفت پارامتر اصلی و سه مولفه چارچوب «انتقال مجاز توکن» را مشخص می‌کنند:

• From: آدرس دارنده‌ توکن که قرار است از موجودی‌اش کم شود.
• To: آدرس گیرنده‌ای که قرار است توکن را دریافت کند.
• Value: مقدار توکنی که باید منتقل شود (بر حسب کوچک‌ترین واحد توکن).
• validAfter: این برچسب زمانی مشخص می‌کند که مجوز انتقال از چه زمانی قابلیت اجرا پیدا می‌کند. اگر این مقدار در آینده تنظیم شود، انتقال در همان لحظه خاص فعال می‌شود و درواقع نوعی «انتقال با تاخیر زمانی» ایجاد می‌کند.
• validBefore: زمان پایان اعتبار مجوز را تعیین می‌کند و بعد از آن، مجوز برای همیشه نامعتبر می‌شود. محدودشدن اعتبار زمانی باعث می‌شود خطر امنیتی امضاهای فاش‌شده کاهش پیدا کند.
• Nonce: نانس یک مقدار تصادفی ۳۲ بایتی است که فقط باید منحصربه‌فرد باشد. برخلاف نانس حساب‌ها، اینجا دیگر لازم نیست نانس‌ها متوالی باشند. این مقدار معمولاً از طریق توابع تولید عدد تصادفی امن مانند crypto.getRandomValues() در جاوااسکریپت ساخته می‌شود.
• پارامترهای v، r و s: این سه پارامتر بخش‌های مختلف یک امضای دیجیتال منحنی بیضوی (ECDSA) هستند که با امضای هش پیام EIP-712 (شامل تمام پارامترهای قبلی) تولید می‌شوند. این امضا اثبات می‌کند که صاحب کلید خصوصی، مجوز تراکنش را صادر کرده است.

زمانی که تابع فراخوانی می‌شود، چند مرحله بررسی پشت سر هم انجام می‌شود تا امنیت انتقال تضمین شود.

• بررسی زمان اعتبار: ابتدا قراداد بررسی می‌کند که برچسب زمانی بلاک (block.timestamp) میان مقادیر validAfter و validBefore باشد؛ اگر هنوز زمان اجرای بلاک نرسیده باشد، تراکنش با یک پیام خطا برگشت داده می‌شود و اگر زمان آن گذشته باشد، مجوز منقضی و تراکنش لغو می‌شود. این قابلیت، هم از اجرای پیش‌از موعد و هم از اعتبار نامحدود جلوگیری می‌کند.
• بررسی منحصر‌به‌فرد بودن نانس: در گام بعدی قرارداد بررسی می‌کند که آیا نانس ارائه شده قبلا استفاده شده است یا خیر. این کار از طریق نگاشت آدرس به نانس و تبدیل آن به مقدار بولی (Boolean) انجام می‌شود. اگر مقدار مرتبط با آن نانس برابر با “True” باشد، اجرای تراکنش متوقف می‌شود تا از وقوع حملات اجرای مجدد (Replay attacks) جلوگیری شود.
• بازسازی پیام امضا‌شده: پس از آن، قرارداد هش پیام EIP-712 را با استفاده از تمام پارامترها بازسازی می‌کند و مقادیر جداکننده دامنه شامل آدرس قرارداد و شناسه‌ زنجیره را هم در خود جای می‌دهد. جداسازی دامنه تضمین می‌کند که امضا فقط برای همین قرارداد و در همین شبکه معتبر بماند. به‌این ترتیب، اگر کسی بخواهد این پیام را مجددا در شبکه‌های دیگر اجرا کند، به‌دلیل متفاوت بودن شناسه زنجیره، امضا بی‌اعتبار می‌شود.
• تایید امضا: در فرآیند تایید امضا، تابع از‌پیش کامپایل‌شده ecrecover فراخوانی می‌شود تا از روی سه پارامتر امضا (v، r و s) و هش پیام، آدرس امضا کننده استخراج شود. سپس، آدرس بازیابی‌شده با آدرس موجود در پارامتر From مقایسه می‌شود؛ اگر این دو آدرس یکی باشند، امضا معتبر شناخته می‌شود و اجرای تراکنش ادامه می‌یابد. اگر آدرس‌ها متفاوت باشند، به‌معنای این است که کسی قصد جعل مجوز را داشته است. بنابراین، تراکنش متوقف می‌شود.
• تایید استفاده از نانس: درصورت تایید امضا، مقدار نانس مربوطه به حالت “True” تغییر پیدا می‌کند تا این مجوز دیگر قابل استفاده نباشد.
• اجرای انتقال: در این مرحله، منطق استاندارد ERC-20 فعال می‌شود؛ توکن‌ها از حساب فرستنده (From) کسر و به حساب گیرنده (To) واریز می‌شوند و رویداد “Transfer” در بلاکچین ثبت می‌شود.
• ثبت مجوز مصرف‌شده: در پایان نیز رویدادی به نام “AuthorizationUsed” منتشر می‌شود که حاوی آدرس صادرکننده‌ مجوز و نانس استفاده‌شده است. سامانه‌های خارج از زنجیره با استفاده از این اطلاعات می‌فهمند که مجوز موردنظر مصرف شده است.

تابع دریافت با مجوز

تابع دریافت با مجوز (receiveWithAuthorization) پارامترهایی شبیه به تابع انتقال با مجوز دارد؛ اما یک لایه امنیتی مهم به آن اضافه شده است. این تابع پیش از اجرای منطق تایید یا انتقال، ابتدا بررسی می‌کند که آیا msg.sender با آدرس مشخص‌شده در مجوز برابر است یا خیر. اگر شخص دیگری به‌غیر از گیرنده اصلی درخواست را ارسال کرده باشد، تراکنش بلافاصله لغو می‌شود. این مکانیسم ساده از بروز حملاتی به نام فرانت رانینگ (Front-running) جلوگیری می‌کند. در چنین حملاتی، فرد مهاجم مجوزهای در حال‌انتظار در ممپول (Mempool) را شناسایی می‌کند و قبل از گیرنده‌ واقعی آن‌ها را اجرا می‌کند تا پرداخت را به نفع خود تغییر دهند.

مکانیزم کنترل گیرنده به‌طور خاص در پرداخت‌های تجاری اهمیت دارد؛ زیرا مشتری یک مجوز پرداخت را امضا می‌کند و فروشنده در زمان مناسب آن را برای دریافت وجه به شبکه می‌فرستد. این مکانیزم تضمین می‌کند که تنها شخص مجاز (مثلا فروشنده واقعی) پرداخت را دریافت خواهد کرد.

ویژگی دیگر این تابع، پنجره اعتبار زمانی است که مانند یک ضمانت خودکار عمل می‌کند. مشتری می‌تواند مجوز را به‌گونه‌ای صادر کند که اگر فروشنده تا زمان مشخصی آن را ثبت نکند، منقضی شود و عملاً پرداختی انجام نشود. برای مثال، فرض کنید مشتری قصد خرید یک محتوای دیجیتال با تحویل ۲۴ ساعته را دارد. او مجوزی را با استفاده از تابع receiveWithAuthorization ایجاد می‌کند که مقدار validBefore برابر با زمان فعلی به‌اضافه ۸۶٬۴۰۰ ثانیه (۲۴ ساعت) تعیین می‌شود. اگر فروشنده در این بازه محتوا را تحویل دهد، می‌تواند مجوز را ارسال و وجه را دریافت کند؛ اما اگر تحویل ظرف ۲۴ ساعت انجام نشود، مجوز منقضی می‌شود و مشتری هرگز پرداختی را انجام نمی‌دهد.

این مدل، جریان سنتی بازپرداخت را کاملاً برعکس می‌کند؛ به جای آنکه ابتدا پول پرداخت شود و بعد در صورت بروز مشکل به بازگشت وجه نیاز باشد، پرداخت تنها زمانی انجام می‌شود که شرایط تحویل واقعاً برآورده شده باشد. چنین الگویی برای تراکنش‌های باارزش بالا بسیار کارآمد است، زیرا بدون نیاز به واسطه‌ شخص ثالث یا سیستم‌های اسکرو (Escrow) اطمینان لازم را به طرفین معامله می‌دهد.

تابع لغو مجوز و بی‌اعتبارسازی نانس

تابع لغو مجوز “cancelAuthorization”در استاندارد EIP-3009 به دارندگان توکن اجازه می‌دهد مجوزهایی را که قبلاً صادر کرده‌اند، بدون آنکه نیازی به انتقال واقعی توکن باشد، باطل کنند. این تابع در واقع نوعی دکمه‌ اضطراری است که با آن می‌توان یک مجوز معلق را بی‌اثر کرد. ورودی‌های این تابع شامل آدرس صادرکننده‌ مجوز و نانس مربوطه می‌شود. درست مانند تابع انتقال با مجوز، عملیات لغو نیز به امضای معتبر نیاز دارد تا ثابت شود خود صادرکننده مجوز، درخواستِ لغو را تایید کرده است. به‌این ترتیب، هچ شخص ثالثی نمی‌تواند مجوزی را که خودش ایجاد نکرده است، لغو کند.

همان‌طور که قبلا گفتیم، قرارداد هوشمند در زمان اجرا، مقدار نانس مربوطه را در همان ساختار داده‌ای که هنگام انتقال بررسی می‌شود، به‌عنوان استفاده‌شده علامت‌گذاری می‌کند. بنابراین، اگر بعدا کسی بخواهد با استفاده از همان مجوز اصلی تراکنشی انجام دهد، تراکنش با خطا مواجه می‌شود؛ زیرا نانس قبلاً مصرف شده است.

با این حال، لغو مجوز مستلزم پرداخت کارمزد گس از سوی صادرکننده مجوز است و یک هزینه غیراقتصادی را ایجاد می‌کند. افزون بر این، ارسال دستور لغو مجوز، یک شرایط رقابتی را با تراکنش‌های اجرایی در ممپول ایجاد می‌کند. اگر یک رله (Relayer) مجوزی را برای اجرا ارسال کند و همزمان صادرکننده مجوز بخواهد آن را لغو کند، هر تراکنشی که زودتر در بلاک تأیید شود، نتیجه را تعیین می‌کند. در نتیجه، تراکنش دوم شکست می‌خورد و گس‌فی آن عملا به‌هدر می‌رود. به همین دلیل، تابع لغو مجوز بیشتر برای مواقع اضطراری و جلوگیری از خسارت در شرایط خاص طراحی شده است.

نحوه عملکرد EIP-3009 در پروتکل x402

پروتکل x402 از استاندارد EIP-3009 به‌عنوان پایه‌ اصلی برای انتقال توکن‌ در فرآیند لزوم پرداخت در بستر اینترنت (HTTP 402 Payment Required) استفاده می‌کند. در این مدل، هنگامی که کاربر برای دسترسی به یک منبع محافظت‌شده درخواست می‌دهد، سرور در پاسخ، کد وضعیت HTTP 402 را برمی‌گرداند و جزئیات پرداخت را در هدر WWW-Authenticate قرار می‌دهد. این جزئیات شامل آدرس قرارداد توکن، مبلغ پرداخت، آدرس گیرنده و مهلت انجام تراکنش می‌شوند.

کلاینت (کاربر) این پارامترها را تحلیل می‌کند و بر اساس آن‌ها یک امضا از نوع transferWithAuthorization می‌سازد. در این امضا، مقدار validAfter برابر با زمان فعلی و validBefore برابر با مهلت تعیین‌شده توسط سرور تنظیم می‌شود تا مجوز تنها در همان بازه زمانی معتبر باشد. سپس، کلاینت با استفاده از منابع امن رمزنگاری یک نانس تصادفی تولید می‌کند و یک پیام ساختاریافته که شامل همه پارامترها باشد را بر اساس استاندارد EIP-712 می‌سازد. در مرحله بعد، کلاینت به‌عنوان دارنده توکن، این پیام را با کلید خصوصی خودش امضا می‌کند و هنگام ارسال مجدد درخواست به سرور، مجوز کامل را در هدر X-PAYMENT قرار می‌دهد.

سرور بعد از دریافت درخواست، هدر X-PAYMENT را تجزیه می‌کند و قبل از ارسال به بلاکچین، اعتبارسنجی گسترده‌ای انجام می‌دهد. اول، مطمئن می‌شود که آدرس گیرنده‌ (to) همان آدرس پرداخت سرور است. دوم، بررسی می‌کند که آیا مبلغ پرداخت با مقدار تعیین‌شده مطابقت دارد یا خیر. سوم اینکه آیا آدرس قرارداد توکن، مربوط به همان توکن پرداخت است. چهارم، تایید می‌کند که مهلت اعتبار منقضی نشده است و در نهایت با بازسازی هش پیام EIP-712، امضای رمزنگاری‌شده را اعتبارسنجی می‌کند.

تنها در صورتی که تمام این مراحل با موفقیت طی شود، سرور مجوز را با استفاده از یک کیف‌پول تسهیل‌گر (Facilitator wallet) که موجودی اتر دارد، به بلاکچین ارسال می‌کند. این کیف‌پول، تابع transferWithAuthorization را در قرارداد توکن فراخوانی می‌کند و کارمزد گس را از موجودی خود می‌پردازد. به‌محض تأیید تراکنش در شبکه، سرور منبعِ درخواستی را به همراه اثبات تراکنش در هدر X-PAYMENT-RESPONSE در اختیار کاربر قرار می‌دهد. این اثبات معمولا شامل جزئیاتی مانند هش تراکنش و شماره بلاک است تا کاربر بتواند تسویه پرداخت را به‌صورت مستقل بررسی کند.

این الگو هزینه گس را از دوش کاربران برمی‌دارد و به سرورها منتقل می‌کند. پذیرش این هزینه برای سرورها از نظر اقتصادی منطقی‌تر است؛ زیرا مبالغ دریافتی آن‌ها معمولا به‌طور قابل‌توجهی از کارمزدهای گس بالاتر است. برای مثال، کارمزد گس فراخوانی یک API با قیمت ۵ دلار در شرایط متوسط شبکه حدود ۰.۵ دلار است. درنتیجه، سرور ۴.۵ دلار سود خالص دارد و کاربر هم فقط هزینه سرویس را می‌پردازد. در این مدل، دیگر لازم نیست کاربر هم توکن پرداخت و هم توکن بومی شبکه را داشته باشد. این الگو به‌ویژه در شرایطی که کاربران باید پرداخت‌های مکرر و کوچکی را انجام دهند، سودمند است.

از آنجایی‌که سرور می‌تواند چندین مجوز پرداخت را در قالب یک تراکنش واحد روی بلاکچین ثبت کند، هزینه پایه کارمزد گس که حدود ۲۱٬۰۰۰ واحد جیوی (Gwei) است، میان تمام پرداخت‌ها تقسیم می‌شود. به‌طور مثال، اگر ۱۰ مجوز در یک تراکنش اجرا شوند، مجموع گس حدود ۶۵۰٬۰۰۰ واحد خواهد بود و اگر هر مجوز جداگانه ارسال شود، مجموع هزینه به حدود ۷۰۰٬۰۰۰ واحد جیوی می‌رسد. این یعنی حدود ۷٪ در گس‌فی صرفه‌جویی می‌شود. اگر صدها انتقال در هر بلاک را در نظر بگیریم، این صرفه‌جویی باعث کاهش هزینه قابل‌توجهی می‌شود.

مزایای استاندارد EIP-3009

حالا که با نحوه عملکرد و توابع استاندارد EIP-3009 آشنا شدیم، در ادامه به بررسی مزایای آن می‌پردازیم:

۱. کاهش تعداد تراکنش‌ها و صرفه‌جویی در کارمزد گس

در الگوی سنتی تایید انتقال از (approve-transferFrom)، انتقال توکن توسط شخص ثالث به دو تراکنش جداگانه نیاز دارد. ابتدا کاربر با دستور approve به آدرس مشخصی اجازه خرج کردن توکن‌های خود را می‌دهد که به حدود ۴۵٬۰۰۰ گس نیاز دارد. سپس پرداخت‌کننده با فراخوانی دستور transferFrom، تراکنش انتقال را انجام می‌دهد که حدود ۵۵٬۰۰۰ گس مصرف می‌کند. این دو پرداخت در مجموع، حدود ۱۰۰٬۰۰۰ گس هزینه دارند. این ساختار علاوه بر مصرف گس بیشتر، باعث ایجاد تأخیر (Latency) بین دو مرحله تایید و اجرا می‌شود.

در مقابل، استاندارد EIP-3009 تمام این فرآیند را در یک تراکنش واحد با دستور transferWithAuthorization انجام می‌دهد و تنها حدود ۶۵ تا ۷۰ هزار گس مصرف می‌کند. این یعنی، نسبت به روش سنتی نزدیک به ۳۰٪ در هزینه گس صرفه‌جویی می‌شود. در مقیاس‌های بزرگ، این صرفه‌جویی به رقم قابل‌توجهی تبدیل می‌شود. به‌طور مثال، یک صرافی ارز دیجیتال که ماهانه یک میلیون انتقال را پردازش می‌کند، بیش از ۳۰ میلیون گس در ماه صرفه‌جویی می‌کند و برحسب قیمت گس هزاران دلار کاهش هزینه خواهد داشت.

۲. محدودیت زمانی و امنیت بیشتر مجوزها

در الگوهای تایید سنتی، محدودیتی برای پایان اعتبار مجوز تعیین نمی‌شود و این مجوز تا زمانی که کاربر آن را لغو نکند فعال باقی می‌ماند. این مسئله باعث آسیب‌پذیری‌های امنیتی می‌شود؛ زیرا ممکن است بسیاری از کاربران در گذر زمان فراموش کنند در چه برنامه‌هایی چه مجوزهایی را صادر کرده‌اند. ممکن است کاربری مجوز یک برنامه غیرمتمرکز را در سال ۲۰۲۰ تایید کرده است و حالا اصلا آن را به خاطر نداشته باشد؛ اگر برنامه‌ در هر زمانی هک شود، مهاجم می‌تواند از همان مجوز قدیمی برای برداشت توکن‌ها استفاده کند. این مشکل که به نام مجوز نامحدود (indefinite allowance) شناخته می‌شود، یکی از دلایل اصلی سرقت ارزهای دیجیتال در فضای کریپتو است.

درمقابل، مجوزهایی که براساس استاندارد EIP-3009 صادر می‌شوند، محدوده زمانی مشخصی دارند. کاربر می‌تواند از طریق پارامتر validBefore تعیین کند که مجوز تا چه زمانی معتبر باشد. مثلاً اگر اعتبار را برای ۲۴ ساعت تنظیم کند، پس از گذشت این زمان صرف‌نظر از اینکه مجوز اجرا شده است یا خیر، به‌طور خودکار منقضی می‌شود. این ویژگی هم امنیت را بالا می‌برد و هم بار مسئولیت کاربر را کمتر می‌کند، زیرا نیازی به لغو دستی مجوزها نیست.

۳. ایجاد مجوزهای موازی

در روش سنتی که مبتنی بر نانس ترتیبی است تا زمانی که تراکنش با نانس N کامل نشده باشد، نانس N+1 قابل اجرا نیست. به‌همین دلیل، کاربران و برنامه‌ها همیشه باید مقدار فعلی نانس را دنبال کنند، آن را برای هر تراکنش یکی افزایش دهند و مطمئن شوند که تراکنش‌ها دقیقاً به همان ترتیب تأیید می‌شوند. به‌طور مثال، در برنامه‌ای که ۱۰۰ درخواست پرداخت ایجاد شده است، باید نانس‌های ۰ الی ۹۹ را به‌ترتیب تولید و ارسال کند.

حالا اگر تراکنش شماره ۵۰ با شکست مواجه شود، تمام تراکنش‌های بعدی به دلیل نامعتبر شدن نانس‌ها متوقف می‌شوند. این موضوع برای برنامه‌هایی که در آن‌ها در لحظه تعداد زیادی تراکنش تولید می‌شود (مانند اپلیکیشن‌های پرداخت) یک مشکل جدی است، زیرا به هماهنگی مداوم و مدیریت دقیق ترتیب نانس نیاز دارد.

استاندارد EIP-3009 این محدودیت را با استفاده از نانس تصادفی برطرف می‌کند. در این روش، برنامه‌ها می‌توانند بدون نیاز به آگاهی از وضعیت فعلی شبکه و آخرین نانس، یک مقدار ۳۲ بایتی تصادفی و رمزنگاری‌شده را به‌عنوان نانس برای هر مجوز تولید کنند. اپلیکیشن‌ها می‌توانند صدها مجوز را با نانس‌های تصادفی مستقل به‌صورت موازی ایجاد و با هر ترتیبی که خواستند به شبکه ارسال کنند. گیرنده هم می‌تواند مجوزها را با ترتیب دلخواه اجرا کند، بدون آنکه مشکلی در اعتبار تراکنش‌ها به‌وجود آید.

این ساختار جدید، منطق برنامه‌ها را بسیار ساده‌تر و تجربه کاربر را روان‌تر می‌کند. ایجاد مجوزهای موازی در فرآیندهای چندطرفه کاربرد قابل‌توجهی دارد؛ مثلاً در یک سیستم اسکرو که سه طرف باید مجوزهای خود را امضا کنند، هر طرف می‌تواند بدون هماهنگی مقادیر نانس با دیگران، مجوز خود را به‌طور مستقل صادر کند.

۴. الگوهای تولید امضای خارج از زنجیره

جداسازی مرحله ایجاد مجوز از اجرای آن، الگوی کاملاً جدیدی از تجربه کاربری را ممکن می‌سازد که در تراکنش‌های سنتی آنچین غیرممکن بود. در این مدل، برنامه‌های موبایلی می‌توانند بدون نیاز به اتصال شبکه، امضاها را تولید کنند. ابتدا پیام‌هایی مطابق با استاندارد EIP-712 ساخته و به‌صورت محلی امضا می‌شود. سپس، برنامه مجوزهای امضا‍‌شده را در پایگاه‌ داده محلی ذخیره می‌کند و به محض اتصال به شبکه آن‌ها را برای گیرندگان ارسال می‌کند.

این قابلیت، انجام تراکنش‌ها را در محیط‌هایی که دسترسی به اینترنت مقدور نیست مانند هواپیما، مناطق دورافتاده یا هنگام قطعی شبکه امکان‌پذیر می‌کند. در چنین شرایطی کاربران می‌توانند با خیال راحت «پرداخت» خود را با تولید امضای آفلاین انجام دهند و مطمئن باشند که طرف مقابل به‌محض اتصال شبکه، پرداخت را دریافت می‌کند.

 جمع‌بندی

استاندارد EIP-3009 یک روش پیشرفته برای انتقال توکن‌ها است که چند ویژگی مهم دارد؛ در این استاندارد، کاربران به‌جای ارسال مستقیم تراکنش روی بلاکچین، تنها یک امضای رمزنگاری‌شده خارج از زنجیره ایجاد می‌کنند و مجوز انتقال را به گیرنده یا اجراکننده می‌سپارند. این مجوزها فقط در بازه‌ زمانی مشخصی معتبر هستند. با استفاده از نانس‌های تصادفی، امکان ایجاد چندین مجوز به‌صورت موازی و هم‌زمان وجود دارد و لزومی برای پرداخت کارمزد گس توسط ارسال‌کننده نیست، طرف مقابل یا یک واسطه هم می‌تواند گس را بپردازد.

این ویژگی‌ها باعث شده است که استاندارد EIP-3009 به‌طور گسترده در نسخه دوم USDC مورد استفاده قرار گیرد و اکنون ماهانه بیش از ۵۰ میلیارد دلار تراکنش از طریق آن انجام شود. همچنین، ترکیب EIP-3009 با پروتکل پرداخت x402 کوین‌بیس هم نشان می‌دهد که این استاندارد به‌راحتی با پروتکل‌های برنامه سطح بالاتر هم ترکیب می‌شود و انجام میکروپرداخت‌ها را در بستر اینترنت آسان‌تر می‌کند.