در این مقاله ، ما توضیح می دهیم که ABI در استحکام چیست ، چگونه به توصیف قراردادهای هوشمند و نحوه ترجمه آن به Bytecode EVM کمک می کند. ما همچنین به چندین روش داخلی استحکام برای رمزگذاری + رمزگشایی طبق مشخصات ABI خواهیم پرداخت.

جدول محتویات

قراردادهای هوشمند ABI

ABI در مقابل Bytecode ABI = مشخصات رمزگذاری و رمزگشایی

درک JSON ABI از یک قرارداد

مشخصات JSON ABI برای توابع مشخصات JSON ABI برای رویدادها

ABI + استحکام - رمزگذاری داده ها

ABI + استحکام-رمزگذاری غیر استاندارد / بسته بندی شده

ABI + استحکام - توابع رمزگذاری تماس می گیرند

abi. encodewithselector (…) abi. encodewithsignature (…)

نقشه برداری استحکام به انواع ABI

منابع

قرارداد هوشمند ABI

ABI vs Bytecode

قراردادهای هوشمند موجودات کوچک بسیار آرام هستند. آنها هنوز در شبکه ، زیر آفتاب blockchain می نشینند و منتظرند که فراخوانده شوند.

به خودی خود ، آنها بی معنی هستند و از آن استفاده نمی کنند. اما نباید "هوش" آنها را رد کرد! در حقیقت ، آنچه باعث شده است که آنها عنوان "قرارداد هوشمند" را بدست آورند ، بایت کد مرتبط با آنهاست.

هنگامی که یک قرارداد هوشمند در یک شبکه مستقر می شود ، کد بایت آن با آدرس آن همراه می شود و در blockchain ذخیره می شود. به طور دقیق تر ، کد بایت یک قرارداد هوشمند در ایالت جهان ، تحت عنوان "کد" آدرس قرارداد هوشمند ذخیره می شود.

بیایید در اینجا عملی شویم تا درک کنیم ، و بایت کد پشت آدرس قرارداد هوشمند UNISWAPV3Factory را در شبکه اصلی اتریوم مشاهده کنیم! SNIPPET کد JavaScript و Web3. JS شما را قادر می سازد این کار را انجام دهید:

const web3 = نیاز ("web3") ؛const ارائه دهنده = "your_infura_or_quicknode_http_endpoint" ؛const Web3 = New Web3 (ارائه دهنده) ؛const uniswapv3factory = "0x1f98431C8AD98523631AE4A59F267346EA31F984" ؛web3. eth. getCode (uniswapv3factory) . Then (console. log) ؛>بایت کد یک قرارداد هوشمند را به عنوان "مغز" خود فکر کنید. این منطق قرارداد را به شکل کد دستگاه توصیف می کند. این کد ماشین با تهیه یک زبان برنامه نویسی با قرارداد هوشمند سطح بالا مانند استحکام در یک زبان دستگاه اجرایی: EVM Bytecode به دست می آید. 

Bytecode EVM در بالا چیزی غیر از دنباله ای از opcodes EVM است که در hexadecimals نوشته شده است.

این مسئله ما را با مشکل اول قرار می دهد: کد اجرایی کد دستگاه است. این قابل خواندن انسانی نیست ، بلکه فقط قابل خواندن با ماشین است. و فقط یک دستگاه ویژه (= دستگاه مجازی Ethereum) می تواند آن را درک کند و می داند چگونه آن را اجرا کند.

این همه برای EVM خوب است. اما برای انسان چطور؟برای انسان ، کد BYTECODE هیچ زمینه ای را ارائه نمی دهد (مانند باینری اجرایی یک پرونده C ++).

مشکل دوم ما این است که قراردادهای هوشمند از کاربرد زیادی استفاده نمی کنند ، مگر اینکه شما با آنها تعامل برقرار کنید تا آنها بتوانند منطق خود را تحریک و اجرا کنند. اما آنچه که قراردادهای هوشمند را در blockchain اجرا می کند ، کد واقعی آنهاست.

در اینجا می توانیم ببینیم که به یک منطق متضاد ختم می شویم ، جایی که 2 مشکل بالاتر از یکدیگر تغذیه می کنند.

راه حل این مشکل خود تغذیه در ABI نهفته است ، که در اسناد استحکام شرح داده شده است:

"ABI روش استاندارد برای تعامل با قراردادهای موجود در اکوسیستم اتریوم است. هم از خارج از blockchain و هم برای تعامل قرارداد به قرارداد ".

"من" در ABI مخفف رابط است. این همان چیزی است که با ترجمه ورودی های داده شده به یک فرمت "قابل خواندن با دستگاه" برای EVM ، ارتباط با کد EVM یک قرارداد را امکان پذیر می کند.

از ABI به عنوان روشی ساده تر و قابل درک تر برای توصیف یک قرارداد هوشمند برای یک انسان فکر کنید. ABI یک قرارداد هوشمند رابط عمومی خود و نحوه تعامل با آن را توصیف می کند.

این تعریف را تعریف می کند که کدام توابع را می توانید فراخوانی کنید و تضمین می کند که این عملکرد داده ها را با فرمت مورد نظر خود باز می گرداند.

ABI = مشخصات رمزگذاری + رمزگشایی

ما قبلاً دیدیم که ABI همان چیزی است که پیوند تعامل بین مشتری (مستقیماً از EOA یا رابط) و یک کد بایت قرارداد هوشمند (منطق قرارداد در EVM Opcodes) ایجاد می کند.

با این حال ، ABI نه تنها پیوند بین این دو لایه (انسان و EVM) است. از همه مهمتر ، ABI مشخصات روشنی در مورد نحوه رمزگذاری و رمزگشایی داده ها و تماس های قرارداد را تعریف می کند.

بنابراین در Ethereum و هر زنجیره مبتنی بر EVM ، ABI اساساً چگونگی رمزگذاری قراردادها برای EVM است (به طوری که EVM می فهمد کدام دستورالعمل ها را اجرا می کند).

همین امر به عقب می رود. ABI نحوه خواندن و رمزگشایی داده ها را از معاملات مشخص می کند زیرا تمام داده های مشخص شده در معاملات به عنوان شش ضلعی خام رمزگذاری می شوند.

بنابراین ، ABI روشی برای رمزگذاری و رمزگشایی داده ها در/خارج از کد دستگاه است.

ما این را در یک بخش جداگانه مشاهده خواهیم کرد که چگونه انواع مختلف داده ها توسط ABI رمزگذاری و رمزگشایی می شوند.

درک JSON ABI از یک قرارداد

درک JSON ABI از یک قرارداد

برای یک رابط DAPP ، ABI از یک قرارداد هوشمند استحکام به عنوان مجموعه ای از اشیاء ارائه می شود.

هر شی می تواند با:

یک روش (تابع) در روش قرارداد که به طور عمومی قابل تماس است (= می تواند توسط هر کسی فراخوانی شود ، مگر اینکه اصلاح کننده های محدود کننده به آن وصل شوند).

• یک تعریف رویداد
• عملکرد Fallback () یا دریافت ().
• هنگام تدوین قرارداد استحکام در ترافل یا هاردهات ، می توانید ABI را در داخل مصنوعات تولید شده . Json پیدا کنید. این پرونده JSON شامل زمینه ای به نام "ABI" خواهد بود.

در اینجا یک مثال اساسی از Uniswapv3Factory آورده شده است:

به طور خلاصه ، متغیری از نوع آدرس قابل پرداخت یا قرارداد توسط ABI به عنوان یک آدرس استاندارد در زیر کاپوت رمزگذاری و رمزگذاری می شود.

در مورد ساختار نیز همین اتفاق می افتد. ABI یک ساختار را به عنوان یک نوع از انواع ابتدایی رمزگذاری می کند.

enums قبلاً در ABI توسط کوچکترین نوع UINT به اندازه کافی بزرگ تعریف می شد تا تمام مقادیر تعریف شده در enum را نگه داشته باشد.

به عنوان مثال ، شماری از 255 مقادیر یا کمتر توسط ABI به UINT8 نقشه برداری می شد ، در حالی که یک مجموعه 256 مقادیر یا بیشتر به UINT16 نقشه برداری می شد.

این از زمان استحکام نسخه 0. 8. 0 تغییر کرده است ، زیرا Enum دیگر نمی تواند بیش از 256 عضو داشته باشد.