بگذارید در همین ابتدا خیال‌تان را راحت کنم؛ تراکنش بدون گس وجود ندارد! شاید بپرسید پس تکلیف این مطلب چه می‌شود؟ آیا تنها عنوانی برای جذب شما به باز کردن لینک بوده است؟ باید بگم که خیر. تراکنش gasless معمولا به دسته‌ای از تراکنش‌ها اطلاق می‌شود که کاربر نهایی هزینه تراکنش را نمی‌پردازد – برای مثال پروتکل این امر را به عهده می‌گیرد – و یا کاربر با ارزی به جز کوین بومی (فرضا توکن ERC20 به جای اتر) این هزینه را پرداخت می‌کند. با ادامه این مطلب با میهن بلاکچین همراه باشید تا با تراکنش‌های بدون گس و نحوه کار آن آشنا شوید.
گس چیست؟
پیش از هر چیز، بیایید کمی در خصوص گس صحبت کنیم. شبکه اتریوم (و همه شبکه‌های دیگری که با الهام از اتریوم ایجاد شدند) یک ماشین حالت (State Machine) جهانی است. در واقع اتریوم یک کامپیوتر جهانی است که علاوه بر نگهداری یک نسخه قابل وثوق از دفتر کل (Ledger)، به کاربران اجازه می‌دهد تا محاسبات خود را به نوبت در این ماشین پشته‌ای انجام دهند و نتیجه قابل تایید و تکرارپذیر آن را ذخیره کنند. دستور آغاز این کار و پارامترهای ورودی توسط تراکنش‌ها صادر می‌شود. با توجه به بار محاسباتی و برای جلوگیری از دستورات اسپم یا دستوراتی که شبکه را وارد حالت بدون توقف کند، مفهومی به اسم گس (gas) در این شبکه گنجانده شده است که واحد آن، ارز دیجیتال بومی شبکه – اتر ETH – است. هر تراکنش با توجه به منابعی که مصرف می‌کند، مقدار مشخصی گس لازم دارد و قیمت هر واحد از این گس، طی حراجی تعیین می‌شود. بنابراین قیمت تمام شده هر تراکنش برای کاربر، بسته به عملیات مورد نظر و تقاضای دیگر کاربران، برای گنجاندن تراکنش خود در هر بلوک دارد. بدین ترتیب گس را می‌توان سوخت این کامپیوتر نامید. برای آشنایی بیشتر با این مفهوم، مقاله زیر را مطالعه کنید:
تراکنش بدون گس چیست؟
با توجه به اینکه گس مفهومی بنیادین در شبکه است، نمی‌توان آن را حذف کرد اما می‌توان موارد استفاده جدید و راهکارهایی برای بهبود پروتکل ارائه کرد. برای انجام تراکنش بدون گس، باید بتوان به نحوی ثابت کرد که کاربر – با وجود عدم پرداخت گس – به راستی آغازکننده تراکنش است. باید بتوان به نحوی امن، بدون به خطر افتادن کلید خصوصی وی، ثابت کرد که کاربر امضا کننده تراکنش است. برای این منظور می‌بایست تغییرات و تمهیداتی در سطح پروتکل صورت می‌گرفت چرا که هر تراکنش در شبکه اتریوم باید توسط حسابی با مالکیت خارجی (EOA) آغاز شود و تابع approve استاندارد ERC-20، می‌بایست از طرف msg.sender صادر شود.
نیاز به داشتن ETH در حساب، از کیفیت تجربه کاربری می‌کاهد. حتی اگر میلیون‌‌ها دلار از توکن‌های مختلف در حساب خود داشته باشید، بدون اتر قادر به انجام هیچ کاری نیستید. برای رفع این مساله، چندین طرح بهبود اتریوم (EIP) در طول سالیان پیشنهاد شده است که هر یک سعی در رفع برخی از موانع داشته‌اند. در ادامه سه EIP را بررسی می‌کنیم:
EIP 712
در این پروپوزال که برای نخستین بار در سال ۲۰۱۷ ایجاد شد، استانداردی برای استفاده از امضای دیجیتال یک پیغام خارج از زنجیره برای استفاده در زنجیره ایجاد شد. در واقع پس از این EIP، مجموعه پیغام‌های قابل امضا علاوه بر تراکنش‌ها و bytestringها، شامل داده‌های ساختاریافته (Structured Data) نیز شد. این پیشنهاد، قدم اول در زمینه کسب تایید خرج کردن توکن‌ها (token approval) بود.
EIP 2612
توکن‌های ERC 20 دو تابع اصلی به نام approve و transferFrom دارند. یک مشکل اساسی در طراحی این توکن‌ها، تابع approve است که منجر به انتزاع‌سازی (abstraction) msg.sender شده است؛ بدین معنی که فرستنده این فراخوان عملا باید یک حساب با مالکیت خارجی (EOA) باشد؛ بنابراین اگر کاربر بخواهد با قرارداد هوشمندی کار کند، احتیاج به دو تراکنش دارد. حال این پروپوزال با پیشنهاد تابعی به نام permit، با تغییر نگاشت اجازه (allowance) به وسیله یک پیغام امضا شده (به جای msg.sender)، امکانات بیشتری به ارمغان می‌آورد. برای مثال، این دو تابع را در قرارداد هوشمند توکن دای (DAI) که با استفاده از EIP 2612 ایجاد شده، بررسی می‌کنیم:
function approve(address usr, uint wad) external returns (bool) function permit(address holder, address spender, uint256 nonce, uint256 expiry, bool allowed, uint8 v, bytes32 r, bytes32 s) external
در تابع نخست (approve)، شما به خرج‌کننده (spender) اجازه می‌دهید تا سقف wad از توکن‌های شما را خرج کند. اما در تابع دوم، شما می‌توانید به فردی ثالث امضای دیجیتال معتبری از خود را دهید (به کمک EIP 712 و به شکل off-chain) و آن فرد می‌تواند با فراخوانی permit، اجازه خرج کردن توکن‌های شما را پیدا کند. این چنین از دید کاربر اصلی، تراکنش می‌تواند بدون گس باشد.
EIP 2771
پروپوزال EIP 2771 تغییرات لازم در قرارداد هوشمند پذیرای تراکنش‌های متا (meta transaction) را مشخص می‌کند. با انجام این تغییرات، قرارداد هوشمند می‌تواند تراکنش‌های امضا شده توسط کاربر را از جانب یک واسطه (Forwarder) پذیرا شود. تغییرات پیشنهاد شده در این طرح، در سطح EVM نیست. انگیزه طرح چنین پیشنهادی، مهیا کردن پذیرش تراکنش‌ها توسط قراردادهای هوشمند از جانب حساب‌های EOAای است که اتر برای پرداخت گس ندارند.
به واسطه مفهومی به اسم تراکنش متا، تراکنش به وسیله امضاکننده (Transaction Signer) آغاز می‌شود که حسابی با مالکیت خارجی است. سپس هزینه این تراکنش توسط طرف ثالثی به نام رله‌کننده گس (Gas Relay) پرداخت می‌شود. عواملی که در این ساختار تعریف می‌شوند و نقش دارند به شرح زیر است:
- امضاکننده تراکنش: فردی که تراکنش را امضا کرده و درخواست خود را به رله‌کننده گس می‌فرستد.
- رله گس: درخواستی off-chain از طرف امضاکننده تراکنش دریافت می‌کند و با پرداخت هزینه گس، آن را به تراکنشی معتبر تبدیل کرده و به حامل قابل اعتماد (trusted Forwarder) می‌فرستد.
- حامل قابل اعتماد: قراردادی است که مورد وثوق قرارداد هوشمند پذیرنده است تا به درستی صحت امضا و نانس (nonce) را بررسی کرده و سپس آن را منتقل کند.
- پذیرنده: قرارداد هوشمندی است که منطبق با این استاندارد طراحی شده و می‌تواند تراکنش‌های متا را از حامل قابل اعتماد بپذیرد.
چند نمونه عملی
چندین روش برای فراهم آوردن زیرساخت تراکنش‌های بدون گس یا امکان پرداخت گس به وسیله توکن‌های ERC 20 وجود دارد. در ادامه به توضیح دو نمونه خواهیم پرداخت:
پلتفرم بیکونومی
پروتکل بیکونومی (Biconomy) یکی از پلتفرم‌هایی است که امکان ایجاد چنین امکانی را به کمک زیرساخت‌های خود ممکن ساخته است. تاکنون ۹۵ برنامه غیرمتمرکز، از سرویس‌های این پروتکل استفاده کرده‌اند. این پلتفرم به کمک زیرساختی از رله‌ها و قالب‌های قراردادی که آماده کرده است، به پروژه‌ها اجازه می‌دهد تا بتوانند امکان اسپانسرشیپ گس برای کاربران خود را متقبل شوند. همچنین به کمک اوراکل‌ها، این پلتفرم امکان پرداخت هزینه گس به وسیله برخی توکن‌ها (فعلا توکن‌های نقدپذیری همچون دای و USDC) را فراهم آورده است. نمونه فلوچارت نحوه کار این ساختار در شکل زیر آمده است:
Ethereum Gas Station Network (GSN)
این شبکه به منظور بهبود تجربه کاربری و ایجاد شبکه‌ای غیرمتمرکز برای پرداخت گس تراکنش‌ها به وجود آمده است. نحوه عمل مشابه چیزی است که پیش‌تر بیان کردیم، تفاوت‌های اندکی در این معماری وجود دارد؛ قراردادهای پرداخت‌کننده (Paymaster)، RelayHub و Relay Server. قرارداد پرداخت‌کننده، حاوی کدهای منطق پرداخت گس است. این قرارداد دارای مخزن گسی از اتر نزد هاب رله است و تصمیم می‌گیرد که یک تراکنش متا را بپذیرد یا نه. برای مثال می‌توان لیست سفیدی از آدرس‌های مجاز تهیه کرد و یا پرداخت را تنها برای آدرس‌هایی تقبل کرد که مابه‌ازای قیمت را به شکل توکن‌های دیگر پرداخت کنند.
بهتر است سرور رله توسط هر dApp به شکل مجزا مستقر شود؛ این چنین می‌تواند برای کاربران بومی پروتکل این خدمت را به شکل رایگان و برای دیگر کاربران، در ازای اخذ هزینه انجام دهد. همچنین با چنین معماری، در صورت بروز مشکل برای این سرور، کاربران می‌توانند به سرورهای رله دیگر مراجعه کنند.
هاب رله (Relay Hub) کاربران مختلف را به سرورهای رله و قراردادهای پرداخت متصل می‌کند. این چنین شرکت‌کنندگان نیازی به شناخت یکدیگر و اعتماد نخواهند داشت. معماری پیشنهادی شبکه پمپ گاز اتریوم را می‌توانید در شکل زیر مشاهده کنید:
جمع‌بندی
در این مقاله با مفهوم تراکنش‌های بدون گس و یا Gas-less transaction آشنا شدید. همچنین چند راهکار پیشنهادی برای پرداخت گس کاربران توسط پروتکل میزبان را مشاهده کردید و از نحوه پرداخت گس به وسیله توکن ERC-20 اطلاع پیدا کردید. برخی اعتقاد دارند برای ترویج هر چه بیشتر وب ۳ و ارزهای دیجیتال بین عموم مردم، باید تجربه کار با شبکه‌ها و پلتفرم‌های مختلف کریپتویی بیش از پیش آسان شود و همه‌چیز تنها یک کلیک با کاربر فاصله داشته باشد؛ بی‌شک حذف موانعی همچون انجام تراکنش بدون داشتن کوین بومی (گس)، یکی از کارهایی است که باید در راستای رسیدن به این آینده صورت پذیرد.
نظر شما در خصوص تراکنش‌های بدون گس چیست؟ آیا تاکنون به خاطر نداشتن موجودی اتر (و یا دیگر ارزها) از انجام تراکنشی منصرف شده‌اید؟ دیدگاه‌های خود را با ما در میان بگذارید.
