تصور کنید دو نفر در دو کشور مختلف، یک قرارداد هوشمند اتریوم را با ورودی یکسان اجرا کنند. اگر قواعد شبکه را رعایت کرده باشند، نتیجه محاسبه نباید به مدل رایانه یا سلیقه توسعه‌دهنده وابسته باشد. این هماهنگی بدون وجود محیطی با دستورهای مشترک ممکن نیست. ماشین مجازی اتریوم (Ethereum Virtual Machine یا EVM) نام همین محیط اجرای تعریف‌شده برای قراردادهای هوشمند است؛ البته نه به معنای یک رایانه مرکزی که همه کاربران به آن وصل می‌شوند.
EVM قواعد اجرای دستورها و تغییر وضعیت حساب‌ها را مشخص می‌کند. نودهای اجراکننده شبکه از این قواعد پیروی می‌کنند تا تراکنش معتبر، با شرایط یکسان، نتیجه سازگار تولید کند. اگر از خود پرسیده‌اید چرا یک قرارداد می‌تواند دارایی را منتقل کند، چرا بعضی تراکنش‌ها کارمزد دارند ولی به نتیجه نمی‌رسند یا چرا «سازگار با EVM» بودن یک شبکه به‌معنی یکی‌بودن امنیت آن با اتریوم نیست، این راهنما برای پاسخ به همین سؤال‌ها نوشته شده است.
EVM یک مشخصات اجرایی برای پردازش بایت‌کد قراردادهای هوشمند و تغییر وضعیت شبکه است. در اتریوم، علاوه بر انتقال ETH بین حساب‌ها، می‌توان تراکنشی فرستاد که تابعی از یک قرارداد را فراخوانی کند. نودهای لایه اجرا بر پایه قواعد توافق‌شده دستورهای قرارداد را پردازش و تغییر معتبر موجودی‌ها، داده‌های قرارداد و خروجی رخدادها را محاسبه می‌کنند. به همین دلیل اتریوم را گاهی «ماشین وضعیت توزیع‌شده» می‌نامند.
«مجازی» در اینجا به معنای اجرای قواعد یک ماشین انتزاعی روی رایانه‌های واقعی است. EVM یک نرم‌افزار دسکتاپ یا سیستم‌عامل عمومی مانند ویندوز نیست و کاربران عادی لازم نیست آن را جداگانه نصب کنند. پیاده‌سازی‌های کلاینت اتریوم وظیفه اجرای همین قواعد را بر عهده دارند؛ اجماع شبکه نیز فرایند توافق بر زنجیره معتبر و ترتیب بلوک‌ها را مدیریت می‌کند. برای نمای کلی معماری، مقاله بلاک‌چین اتریوم را در کنار این توضیح مطالعه کنید.
قرارداد هوشمند باید در محیط‌های مختلف نتیجه قابل تکرار داشته باشد. اگر هر نود برداشت متفاوتی از تقسیم اعداد، خواندن موجودی یا ذخیره داده داشته باشد، وضعیت شبکه از هم می‌پاشد. EVM دستورها، نوع داده‌ها، روش اجرای کد و هزینه عملیاتی را استاندارد می‌کند. این استانداردسازی امکان می‌دهد توسعه‌دهندگان برنامه بنویسند و بقیه شبکه، بدون اعتماد به سازنده برنامه، قواعد اجرایی آن را مستقل بررسی کنند.
خیر. نودهای مرتبط با شبکه و نقش اجرا و اعتبارسنجی باید بتوانند اجرای موردنیاز را طبق پروتکل بررسی کنند؛ هیچ الزام عملی وجود ندارد که تمام کاربران اینترنت قرارداد را اجرا کنند. تأمین امنیت شبکه نیز فقط به EVM مربوط نیست: سازوکار اجماع، پیاده‌سازی کلاینت‌ها، دسترس‌پذیری داده و امنیت قراردادها هم نقش دارند. بنابراین عبارت «کامپیوتر جهانی» بیشتر یک تشبیه آموزشی است، نه وعده توان پردازشی نامحدود.
توسعه‌دهنده ممکن است قراردادی را با Solidity یا Vyper بنویسد. کد منبع، پیش از قرارگرفتن در شبکه، معمولاً کامپایل می‌شود و بایت‌کد مناسب EVM تولید می‌کند. تفاوت مهم این است که ماشین مجازی متن Solidity یا برنامه پایتون را مستقیماً اجرا نمی‌کند؛ دستورهای بایت‌کد و عملیات از پیش تعریف‌شده را پردازش می‌کند. ابزار کامپایل نسخه مشخصی دارند و انتخاب نسخه در رفتار قرارداد و سازگاری آن مهم است.
فرض کنید قراردادی فقط یک عدد ذخیره و به درخواست مجاز آن را تغییر می‌دهد. توسعه‌دهنده منطق تابع، شرایط دسترسی و محل ذخیره را تعیین می‌کند. کامپایلر این دستورها را به بایت‌کد و اطلاعات رابط قرارداد مانند ABI تبدیل می‌کند. ABI به برنامه‌ها کمک می‌کند ورودی تابع را با قالب لازم رمزگذاری و خروجی را تفسیر کنند؛ خود ABI جایگزین کد اجرایی در شبکه نیست.
برای استقرار، تراکنش ایجاد قرارداد ارسال می‌شود. پس از پردازش موفق، حساب قراردادی و بایت‌کد مرتبط با آن در شبکه وجود خواهد داشت. برای اجرای تابع، تراکنشی به نشانی قرارداد همراه با داده ورودی ارسال می‌شود. کیف پول معمولاً درخواست را آماده و امضا می‌کند، اما اجرای واقعی تابع و تغییر وضعیت بر پایه قواعد EVM انجام می‌شود. فراخوانی خواندنی از طریق یک RPC ممکن است تنها شبیه‌سازی اجرای محلی باشد و به‌خودی‌خود تراکنش روی زنجیره ثبت نکند.
هنگام اجرا، ماشین بایت‌کد را دستوربه‌دستور پردازش می‌کند. اگر شرایط مجوز برقرار و گس کافی باشد، تغییر مجاز در وضعیت و رخدادهای مربوط به تراکنش اعمال می‌شود. اگر کد خطا بدهد یا شرطی باعث بازگشت عملیات شود، تغییرات وضعیت آن اجرا برگشت می‌خورند؛ بااین‌حال گس مصرف‌شده می‌تواند از بین برود. ثبت نهایی و نهایی‌شدن تراکنش به قواعد شبکه و اجماع نیز وابسته است، نه فقط به اجرای بایت‌کد.
یکی از بهترین راه‌های فهم EVM، تفکیک سه واژه‌ای است که در بسیاری از مقاله‌ها به‌جای یکدیگر به‌کار می‌روند: Stack، Memory و Storage. به این سه، Transient Storage نیز افزوده شده است. اگر ندانیم کدام داده موقتی است و کدام داده بعد از تراکنش باقی می‌ماند، هم محاسبه هزینه خطا می‌شود و هم ممکن است سازوکار امنیتی قرارداد را اشتباه درک کنیم.
EVM یک ماشین مبتنی بر پشته است. دستورها می‌توانند مقادیر را روی پشته بگذارند، بردارند یا با هم محاسبه کنند. اندازه هر خانه اصلی پشته ۲۵۶ بیت و عمق آن حداکثر ۱۰۲۴ خانه است. این بدان معنا نیست که هر قرارداد همیشه ۱۰۲۴ متغیر دارد؛ فقط یک محدودیت معماری برای فضای عملیات پشته است. برای مثال، دستور ADD دو مقدار لازم را می‌گیرد و نتیجه را به پشته بازمی‌گرداند.
Memory فضایی موقتی است که طی اجرای پیام یا تابع استفاده می‌شود. مثلاً داده‌های میان‌مرحله‌ای یا آرایه‌ای که لازم نیست برای فراخوانی‌های آینده در بلاک‌چین باقی بماند می‌تواند در این فضا قرار گیرد. پس از پایان چارچوب اجرا، این Memory برای آن فراخوانی باقی نمی‌ماند. رشد فضای حافظه نیز می‌تواند هزینه اجرای بیشتری تحمیل کند و رایگان یا بی‌انتها نیست.
Storage فضای پایدار و کلید-مقدار مرتبط با حساب قرارداد است و تغییرات معتبر آن وارد وضعیت شبکه می‌شود. موجودی ثبت‌شده برای کاربران در یک قرارداد توکن یا وضعیت یک رأی می‌تواند در چنین فضایی نگهداری شود. خواندن و به‌ویژه تغییر داده پایدار معمولاً نسبت به برخی عملیات موقتی هزینه‌برتر است. تعبیر «ذخیره رایگان اطلاعات در بلاک‌چین» درست نیست و همین هزینه، بخشی از اقتصاد اجرای برنامه‌ها را شکل می‌دهد.
دستورهای TLOAD و TSTORE طبق EIP-1153 امکان استفاده از فضای کلید-مقدار موقت در محدوده یک تراکنش را فراهم می‌کنند. برخلاف Storage، داده آن پس از اتمام تراکنش در وضعیت پایدار ثبت نمی‌شود؛ برخلاف Memory، می‌تواند میان فراخوانی‌های داخلی مرتبط در چارچوب همان تراکنش در دسترس باشد. استفاده نادرست از این قابلیت هم می‌تواند خطرات منطق برنامه ایجاد کند؛ بنابراین «موقت بودن» به معنی امن‌بودن خودکار نیست.
بایت‌کد از مجموعه دستورهای سطح پایین تشکیل می‌شود که به آن‌ها Opcode می‌گویند. دستورهای حسابی مثل ADD و MUL، دستورهای مدیریت پشته مانند PUSH و POP و دستورهای مرتبط با وضعیت مانند SLOAD و SSTORE هرکدام رفتار مشخصی دارند. اجرای یک قرارداد به معنی تفسیر متن زبان طبیعی یا دستورهای سیستم‌عامل نیست؛ ماشین روی بایت‌کد و حالت جاری اجرا عمل می‌کند.
برخی Opcodeها هزینه ثابت دارند و هزینه برخی دیگر با داده ورودی یا وضعیت شبکه تغییر می‌کند. دستورات مربوط به محاسبه، کپی حافظه، ایجاد قرارداد، ثبت رویداد و دسترسی به Storage رفتار یکسانی ندارند. حتی «یک تابع ساده» ممکن است با مسیرهای اجرایی متفاوت، گس متفاوتی مصرف کند. برای محاسبه دقیق باید بایت‌کد، داده ورودی و شرایط وضعیت در زمان اجرا را در نظر گرفت.
اگر اجرای برنامه بی‌هزینه و نامحدود باشد، یک قرارداد می‌تواند شبکه را با حلقه یا محاسبات بی‌پایان اشغال کند. Gas واحد سنجش مقدار کار محاسباتی و برخی دسترسی‌های داده در EVM است. هر تراکنش سقف گس دارد؛ هنگامی که گس اختصاص‌یافته برای ادامه کافی نباشد، اجرا متوقف می‌شود. گس با ETH یکسان نیست: Gas میزان کار است و نرخ Gas Price تعیین می‌کند هزینه آن کار چقدر ETH می‌شود.
هزینه بخش اجرای تراکنش به‌طور ساده برابر است با Gas Used × Effective Gas Price. فرض کنید برای یک انتقال ساده، مصرف دقیقاً ۲۱٬۰۰۰ واحد گس و قیمت مؤثر آن ۱۰ gwei باشد. در این مثال هزینه ۲۱۰٬۰۰۰ gwei یا ۰٫۰۰۰۲۱ ETH است؛ ۱ gwei برابر یک‌میلیاردم ETH است. با قیمت مؤثر ۲۰ gwei، همان میزان گس ۰٫۰۰۰۴۲ ETH هزینه دارد. این اعداد مثال آموزشی‌اند، نه نرخ فعلی شبکه یا برآورد هزینه یک قرارداد خاص.
در تراکنش‌های متعارف اتریوم، قیمت مؤثر می‌تواند از هزینه پایه هر بلوک و اولویت پرداختی شکل بگیرد؛ سقف کارمزد پیشنهادی کاربر لزوماً به معنای کسر کامل همان سقف نیست. همچنین انتقال توکن، تعامل با قرارداد و برخی عملیات روی لایه‌های دوم یا تراکنش‌های دارای داده خاص ممکن است ساختار و هزینه متفاوتی داشته باشند. بررسی شبکه، کیف پول و برآورد به‌روز قبل از امضا ضروری است.
وقتی اجرای قرارداد با revert متوقف شود، تغییرات وضعیت آن اجرا عموماً بازگردانده می‌شوند؛ اما شبکه برای انجام عملیات پیش از برگشت، منابع محاسباتی مصرف کرده است. پس ممکن است تراکنشی شکست‌خورده در فهرست عملیات ثبت شود و در عین حال کارمزد اجرا از حساب پرداخت‌کننده کسر شده باشد. «موفق نبودن انتقال» با «کارمزد صفر» یکسان نیست. خطای Out of Gas نیز نتیجه مشابهی از نظر ناموفق‌ماندن تغییر وضعیت دارد، با جزئیات مصرف گس متفاوت.
قرارداد هوشمند قطعه کدی است که پس از استقرار، طبق ورودی‌های معتبر و قواعد شبکه قابل فراخوانی است. EVM محیط اجرای آن کد را فراهم می‌کند؛ اما رابط کاربری DApp ممکن است روی وب‌سرورهای معمولی، حافظه مرورگر یا زیرساخت‌های دیگر قرار داشته باشد. بنابراین غیرمتمرکز نامیدن «کل برنامه» فقط به دلیل داشتن یک قرارداد روی زنجیره، اغراق‌آمیز است.
توکن‌های ERC-20 معمولاً مجموعه‌ای از توابع و رویدادها مطابق یک استاندارد قراردادی دارند؛ مانند انتقال موجودی و بررسی میزان دارایی یک نشانی. EVM کد قرارداد را اجرا می‌کند، ولی به‌تنهایی امنیت، ارزش اقتصادی یا مشروعیت توکن را تضمین نمی‌کند. اگر قصد دارید مراحل آزمایش عملی ساخت قرارداد را ببینید، راهنمای ساخت توکن آزمایشی تنها پس از تأیید نهایی URL در سایت قابل اتکا است؛ برای جلوگیری از لینک حدسی، اینجا آن را لینک فعال نکرده‌ایم.
قراردادهای وام‌دهی، استخرهای نقدینگی، بازارهای دارایی دیجیتال و رأی‌گیری سازمانی می‌توانند از منطق اجراشده در EVM استفاده کنند. اما نتیجه هر برنامه به قراردادهای مشخص و مجوزهای کاربر وابسته است. خطای برنامه‌نویسی، دسترسی مدیریتی، اوراکل معیوب یا وابستگی به سرویس بیرونی می‌تواند دارایی کاربران را در معرض خطر قرار دهد؛ حتی اگر خود EVM طبق مشخصات فنی درست کار کند.
در معرفی EVM گفته می‌شود قابلیت محاسباتی آن از مدل‌های تورینگ‌کامل الهام می‌گیرد، یعنی زبان‌های قرارداد امکان بیان گستره بزرگی از محاسبات عمومی را دارند. اما این توصیف در محیط بلاک‌چین قید مهمی دارد: هر تراکنش منابع و Gas محدود دارد. بنابراین یک حلقه بی‌پایان در شبکه به شکل نامحدود اجرا نمی‌شود و در نهایت با محدودیت منابع متوقف خواهد شد. «تورینگ‌کامل» را نباید با اجرای نامحدود یا توان پردازشی برابر ابررایانه اشتباه گرفت.
برخی شبکه‌ها و راهکارهای مقیاس‌پذیری، اجرای کد و ابزارهای مشابه EVM را پشتیبانی می‌کنند. این ویژگی کار توسعه‌دهنده را در انتقال بخشی از کد، استفاده از زبان‌ها و ابزارهای آشنا آسان‌تر می‌کند. بااین‌حال سازگاری فنی به معنی اشتراک کامل مجموعه اعتبارسنج‌ها، روش اجماع، کارمزدها، ریسک پل میان‌زنجیره‌ای یا تضمین امنیت برابر با اتریوم نیست. بعضی راهکارها معادل رفتاری بسیار نزدیک‌تری دارند و برخی فقط زیرمجموعه‌ای از قابلیت‌ها را بازتولید می‌کنند.
رول‌آپ‌ها بخشی از پردازش را خارج از لایه یک انجام می‌دهند و داده یا اثبات‌های لازم را طبق طراحی خود با اتریوم مرتبط می‌کنند. zkEVM می‌کوشد اجرای سازگار با ماشین اتریوم را در چارچوب اثبات‌های دانش صفر قابل بررسی کند، ولی میزان سازگاری پروژه‌ها متفاوت است. زنجیره جانبی ممکن است مدل امنیت و اجماع مستقلی داشته باشد. قبل از انتقال دارایی بین دو شبکه باید نشانی قرارداد، شبکه مقصد، هزینه و ریسک سازوکار انتقال را جداگانه بررسی کرد.
ارتقای Pectra در سال ۲۰۲۵، EIP-7702 را به شبکه اصلی آورد. با این سازوکار، یک حساب کنترل‌شده با کلید خصوصی (EOA) می‌تواند تحت شرایط مشخص به کد قراردادِ ازپیش‌استقرار‌یافته ارجاع دهد تا رفتارهای برنامه‌پذیرتری مانند تجمیع درخواست‌ها ممکن شود. این یعنی مرز سنتی میان «حساب معمولی» و «قابلیت‌های قرارداد» انعطاف بیشتری یافته است؛ بااین‌حال هر EOA به‌طور خودکار به حساب قراردادی جداگانه تبدیل نشده و کنترل کلید خصوصی اولیه هم به شکل عمومی حذف نشده است.
از دید کاربر، خطر اصلی این است که به کد ناسالم یا مجوز نامطمئن اجازه داده شود از طرف حساب اقدام کند. یک پیام امضا، مجوز توکن و تأیید تراکنش تفاوت فنی دارند؛ برچسب «بدون گس» یا «یک کلیک» هم تضمین‌کننده امنیت نیست. پیش از پذیرش هر درخواست، دامنه مجوز، نشانی قرارداد، شبکه و امکان لغو یا تغییر تفویض را در کیف پول و منابع رسمی بررسی کنید. این توضیح آموزشی است و تأیید امنیت هیچ برنامه خاصی نیست.
مهم‌ترین مزیت EVM وجود قوانین اجرا و ابزارهای مشترک در اکوسیستمی بزرگ است. توسعه‌دهنده می‌تواند از کامپایلرها، چارچوب‌های آزمون، کتابخانه‌ها و تجربه ممیزی‌های پیشین استفاده کند. قراردادهای هوشمند نیز به شکل ترکیبی با یکدیگر تعامل می‌کنند؛ البته ترکیب‌پذیری، مسیر سرایت خطا و حمله را هم بیشتر می‌کند و هزینه آزمون امنیتی را از بین نمی‌برد.
در مقابل، هر عملیات داخل زنجیره هزینه منابع دارد، ذخیره داده پایدار گران‌تر است، کد ناسالم می‌تواند زیان مالی واقعی ایجاد کند و تغییر قرارداد پس از استقرار همیشه ساده نیست. بعضی پروژه‌ها برای ارتقا از الگوی قرارداد نیابتی یا اختیارات مدیریتی استفاده می‌کنند که خود نیازمند شفافیت، کنترل مجوز و برنامه پاسخ‌گویی است. یک برنامه EVM-compatible الزاماً ارزان، غیرمتمرکز یا امن نیست.
اگر با قرارداد آشنا نیستید، از لینک شبکه اجتماعی یا پیام مستقیم برای اتصال کیف پول شروع نکنید. ابتدا نشانی رسمی پروژه، شبکه و نشانی قرارداد را از منابع مستقل تطبیق دهید. در مرورگر بلاک، وضعیت تراکنش، نشانی مقصد، رویدادها و مصرف گس را ببینید؛ برچسب «کد تأییدشده» معمولاً نشان می‌دهد بایت‌کد با منبع منتشرشده تطبیق یافته است، نه اینکه قرارداد از نظر امنیتی ممیزی یا بدون خطر است.
برای توسعه‌دهنده، آزمون روی محیط محلی و شبکه آزمایشی، بررسی مجوزها، آزمون حالت‌های شکست، کنترل Reentrancy و استفاده از بازبینی مستقل قبل از اجرای عمومی اهمیت دارند. حتی آزمون‌های موفق در شبکه آزمایشی جایگزین تضمین امنیت نیستند. برای کاربر غیرتوسعه‌دهنده، مهم‌ترین مهارت تشخیص میان امضای پیام، اجازه خرج‌کردن توکن و تأیید واقعی یک تراکنش است.
ماشین مجازی اتریوم به شبکه امکان می‌دهد کد قراردادها را با قواعد مشترک اجرا کند، بایت‌کد را به عملیات مشخص تبدیل کند و تغییر وضعیت معتبر را محاسبه کند. Stack و Memory داده موقتی را مدیریت می‌کنند، Storage اطلاعات پایدار را نگه می‌دارد و Gas اجرای منابع‌بر را محدود می‌کند. توسعه ابزارهای سازگار و تغییراتی مثل EIP-7702 ظرفیت بیشتری به برنامه‌ها داده‌اند، ولی خطرهای قرارداد، تفویض مجوز و شبکه‌های مستقل همچنان پابرجاست.
این مقاله برای فهم زیرساخت است، نه توصیه معامله؛ برای خدمات عمومی می‌توانید از صرافی ارز دیجیتال، بخش خرید ارز دیجیتال و فهرست قیمت ارزهای دیجیتال استفاده کنید. درباره انتخاب دارایی، هزینه معامله یا مقررات قابل‌اعمال به کاربران ایرانی، اطلاعات روز و شرایط واقعی ارائه‌دهنده باید جداگانه بررسی شود.
خیر. ETH دارایی بومی اتریوم و واحد پرداخت کارمزد است؛ EVM محیط اجرای کد و قواعد تغییر وضعیت قراردادهاست. می‌توان از نظر آموزشی یکی را اقتصاد دارایی و دیگری را موتور اجرای قراردادها در نظر گرفت. اگر قصد بررسی نرخ یا شرایط معامله دارید، صفحه قیمت اتریوم و خرید اتریوم برای آن هدف طراحی شده‌اند، نه این مقاله.
خیر؛ EVM بایت‌کد سازگار را پردازش می‌کند. زبان‌هایی مانند Solidity و Vyper به کد اجرایی مناسب کامپایل می‌شوند. برنامه‌های Python می‌توانند در توسعه، آزمون یا تعامل با شبکه استفاده شوند اما این با اجرای مستقیم اسکریپت Python به‌عنوان بایت‌کد EVM فرق دارد.
نه لزوماً. مسیر اجرای تابع، مقدار داده ورودی، تعداد عملیات ذخیره‌سازی و شرایط وضعیت می‌توانند مصرف گس را تغییر دهند. نرخ مؤثر گس شبکه نیز در زمان‌های مختلف متغیر است. بنابراین برآورد کارمزد باید در زمان اجرای واقعی و با اطلاعات همان شبکه بررسی شود.
خیر. سازگاری به رفتار اجرای قرارداد مربوط است؛ میزان تمرکز، سازوکار امنیت، پل‌های دارایی و سیاست ارتقا می‌توانند میان شبکه‌ها متفاوت باشند. انتخاب شبکه برای کاربرد یا انتقال دارایی نیازمند ارزیابی مستقل ریسک است.
بخش مربوط به تغییر وضعیت ممکن است برگشت بخورد، اما عملیات پردازش‌شده می‌توانند گس مصرف کنند. پس نباید فرض کرد هر تراکنش ناموفق بدون هزینه خواهد بود. نوع خطا و مقدار گس مصرفی را باید در رسید تراکنش بررسی کرد.
