Что такое ABI и зачем он нужен для взаимодействия с контрактами?

ABI означает двоичный интерфейс приложения .

В общем, ABI — это интерфейс между двумя программными модулями, один из которых часто находится на уровне машинного кода. Интерфейс является методом де-факто для кодирования/декодирования данных в/из машинного кода.

В Ethereum это в основном то, как вы можете кодировать вызовы контрактов Solidity для EVM и, наоборот, как считывать данные из транзакций.

ABI, Application Binary Interface, — это в основном то, как вы вызываете функции в контракте и возвращаете данные .

ABI определяет такие детали, как то, как вызываются функции и в каком двоичном формате информация должна передаваться от одного компонента программы к другому...

Смарт-контракт Ethereum — это байт-код, развернутый в блокчейне Ethereum. В договоре может быть несколько функций. ABI необходим для того, чтобы вы могли указать, какую функцию в контракте вызывать, а также получить гарантию, что функция вернет данные в ожидаемом вами формате.

Из спецификации ABI Ethereum пример:

contract Foo {
  function bar(real[2] xy) {}
  function baz(uint32 x, bool y) returns (bool r) { r = x > 32 || y; }
  function sam(bytes name, bool z, uint[] data) {}
}

Если бы мы хотели вызвать baz с параметрами 69 и true, мы бы передали всего 68 байт, которые можно разбить на:

0xcdcd77c0: селектор функций . Это получается как первые 4 байта хэша Keccak-256 формы ASCII сигнатуры функции baz(uint32,bool). 0x0000000000000000000000000000000000000000000000000000000000000045: Первый параметр, aint32 Значение 69 Padded до 32 байтов 0x0000000000000000000000000000000000000000000000000000000001: второй параметр -Boolan, Padsedes Troutes To 32.

68 байт — это то, что будет указано в dataполе транзакции, также называемом calldata : примечание по безопасности здесь . (Подводя итог, будьте осторожны с тем, что вы вводите в поле данных, потому что это может иметь непреднамеренные, возможно, вредоносные побочные эффекты при передаче их в вызывающий контракт.)

Чтобы избежать распространенной ошибки при выводе селектора функций, необходимо использовать канонические типы, например, uint256вместоuint .

Вот пример в Solidity вычисления селектора функций для samприведенного выше:

bytes4(keccak256("sam(bytes,bool,uint256[])")

Использование библиотеки более высокого уровня, такой как web3.js, позволяет абстрагироваться от большинства этих деталей, но ABI в формате JSON все же необходимо предоставить web3.js.

Примечание: ABI — это абстракция, которая не является частью основного протокола Ethereum . Любой может определить свой собственный ABI для своих контрактов ( начальный пример ), и любые вызывающие стороны таких контрактов должны будут соответствовать этому ABI, чтобы получить значимые результаты. Однако всем разработчикам проще использовать текущие компиляторы (например, Solidity) и библиотеки (например, web3.js, ethers.js), которые соответствуют приведенному выше ABI.

Определение контракта : Формальное определение в коде высокого уровня (например, Solidity).

Скомпилированный контракт : Контракт преобразуется в байт-код для работы на виртуальной машине Ethereum (EVM) в соответствии со спецификацией . Обратите внимание, что имена функций и входные параметры хэшируются во время компиляции. Следовательно, чтобы другая учетная запись могла вызвать функцию, ей сначала должны быть присвоены имя функции и аргументы — отсюда и ABI.

Двоичный интерфейс приложения — ABI: список функций и аргументов контракта (в формате JSON ¹ ). Учетная запись, желающая использовать функцию смарт-контракта, использует ABI для хеширования определения функции, поэтому он может создать байт-код EVM, необходимый для вызова функции. Затем он включается в поле данных T _d транзакции и интерпретируется EVM с кодом целевого счета (адрес контракта).

¹ Использование JSON является стандартом де-факто ; его нет в формальной спецификации, но его изменение приведет к необходимости внесения поправок во многие инструменты.

думайте об «ABI» как об «API» на низком уровне.

Думайте об этом как о скомпилированной версии API (или как API на низком уровне). Как вы знаете, контракты хранятся в виде байт -кодов в двоичном формате в блокчейне по определенному адресу. Никто не понимает двоичный код, поэтому ABI определяет структуры и методы, которые вы будете использовать для взаимодействия с этим бинарным контрактом (точно так же, как это делал API), только на более низком уровне. ABI указывает вызывающей стороне необходимую информацию (сигнатуры функций и объявления переменных) для кодирования осмысленного (понимаемого виртуальной машиной) вызова байт-кода (контракта).

дополнительная информация "из официального документа"

Двоичный интерфейс приложения (ABI) предназначен для использования в качестве метода де-факто для кодирования и декодирования данных в транзакциях и из них.

.

Мы утверждаем, что все контракты будут иметь определения интерфейса любых контрактов, которые они вызывают, доступные во время компиляции.

Если вы хотите использовать простой онлайн-инструмент для кодирования параметров, вы можете использовать https://abi.hashex.org .

Вы вводите abi-код для автоматического разбора типов параметров или просто вводите их вручную. В селекторе типа функции должен быть выбран конструктор.

Вот пример, внизу находятся abi-кодированные параметры, которые вы вводите в поле ввода параметров конструктора etherscan.io.

Мне было ужасно трудно понять, почему часть этого вопроса, поэтому я хотел бы добавить одну вещь благодаря этому превосходному ответу :

«То, как эти байты интерпретируются в структурированные данные, зависит от программы и, следовательно, от используемого языка программирования. Чтобы две программы, написанные на разных языках программирования, могли вызывать друг друга, компиляторы таких языков должны реализовывать сериализация и десериализация данных одинаковы, т.е. они должны реализовывать спецификацию ABI, но не обязаны."

Вкратце: контракт, написанный на Solidity, может взаимодействовать с контрактом, написанным на Viper или Bamboo, потому что все они реализуют спецификацию ABI и придерживаются ее.

Просто скопируйте этот json. Это контракт ABI

ABI (Application Binary Interface) в контексте информатики — это интерфейс между двумя программными модулями, часто между операционными системами и пользовательскими программами.

EVM (виртуальная машина Ethereum) — это основной компонент сети Ethereum, а смарт-контракт — это фрагменты кода, хранящиеся в блокчейне Ethereum, которые выполняются на EVM. Смарт-контракты, написанные на языках высокого уровня, таких как Solidity или Vyper, должны быть скомпилированы в исполняемый байт-код EVM; при развертывании смарт-контракта этот байт-код сохраняется в блокчейне и связывается с адресом. Для Ethereum и EVM смарт-контракт — это просто последовательность байт-кода. Чтобы получить доступ к функциям, определенным на языках высокого уровня, пользователям необходимо преобразовать имена и аргументы в байтовые представления, чтобы байтовый код мог с ними работать. Чтобы интерпретировать байты, отправленные в ответ, пользователям необходимо преобразовать обратно в кортеж возвращаемых значений, определенных в языках более высокого уровня. Языки, которые компилируются для EVM, придерживаются строгих соглашений об этих преобразованиях. но для их выполнения необходимо знать точные названия и типы, связанные с операциями. ABI документирует эти имена и типы точно, в легко анализируемом формате, делая переводы между вызовами методов, предназначенными для человека, и операциями смарт-контрактов, обнаруживаемыми и надежными.

Он очень похож на API (интерфейс прикладных программ), удобочитаемое представление интерфейса кода. ABI определяет методы и структуры, используемые для взаимодействия с бинарным контрактом, точно так же, как это делает API, но на более низком уровне. ABI указывает вызывающей функции кодировать необходимую информацию, такую ​​как сигнатуры функций и объявления переменных, в формате, который EVM может понять для вызова этой функции в байт-коде; это называется кодировкой ABI. Кодирование ABI в основном автоматизировано, об этом заботятся компиляторы, такие как REMIX, или кошельки, взаимодействующие с блокчейном. ABI контракта представлен в формате JSON. Существуют четкие спецификации того, как кодировать и декодировать ABI контракта.

Источник

ABI, как и другие, сказал, что двоичный интерфейс приложения - это интерфейс более низкого уровня, но он не должен быть недоступен для программистов, например, в Linux: /sys/bus/usb/devices/.../power/persist
это пример ABI. Вы можете получить доступ ко многим другим Linux ABI через/sys/bus/

См.: https://www.kernel.org/doc/Documentation/ABI/

Введение Двоичный интерфейс приложения (ABI) смарт-контракта дает контракту возможность общаться и взаимодействовать с внешними приложениями и другими смарт-контрактами. Получение данных из внешних источников может иметь решающее значение для достижения целей приложения и пользователя.

В традиционной веб-разработке обмен данными между приложениями и серверами происходит через API (интерфейс прикладных программ). Серверы действуют как централизованные источники информации, которые передают данные в приложение по запросу.

В блокчейне такой централизации данных не существует. Узлы, по сути, действуют как серверы, а смарт-контракты выполняют «размещенные» в цепочке функции. Приложениям вне блокчейна (и другим смарт-контрактам) нужен способ взаимодействия со смарт-контрактами, которые находятся в сети. Здесь в игру вступает ABI.

‍

Почему АБИ? Прежде чем вдаваться в подробности о том, что такое ABI, хорошо бы понять, почему он у нас есть.

Смарт-контракты — это основные приложения EVM (виртуальная машина Ethereum). Целью смарт-контрактов является выполнение транзакций при соблюдении определенных условий, определенных в контракте. Эти условия могут быть событиями как в сети, так и за ее пределами. Смарт-контракты написаны на языках высокого уровня, таких как Solidity, но они хранятся в EVM в виде исполняемого байт-кода в двоичном формате.

Источник: https://hackernoon.com/hn-images/1*Sz1a7G2pQ62UnkHoieve4w.jpeg .

Поскольку этот байт-код не читается человеком, для его понимания требуется интерпретация. ABI позволяет любому, кто пишет смарт-контракт, иметь возможность взаимодействовать между веб-приложением, написанным на языке высокого уровня, таком как Javascript, и байт-кодом, который понимает EVM. ‍

Что такое АБИ? Как и его двоюродный брат Web2, API, ABI действует как селектор функций, определяя конкретные методы, которые можно вызывать в смарт-контракте для выполнения. Эти конкретные методы и связанные с ними типы данных перечислены в сгенерированном файле JSON RPC.

Источник: https://static.packt-cdn.com/products/9781789954111/graphics/assets/fe0f2ffc-2f3c-4615-9cb5-43c8e036239b.png

В отличие от API, мы не можем просто отправить запрос напрямую в формате JSON в смарт-контракт и ожидать ответа, поскольку контракт взаимодействует только в байт-коде. Чтобы преобразовать это в то, что понимает EVM, эта информация кодируется с помощью кодирования ABI. Эти кодировки включают сигнатуры функций и объявления переменных, чтобы EVM точно знала, какую функцию выполнять в смарт-контракте.

Ответы также находятся в байт-коде, поэтому перед их обработкой веб-приложением требуется их интерпретация. Преимущество использования байт-кода в ответе состоит в том, что мы также можем ожидать возврата определенной структуры после вызова функции контракта.

‍

Как использовать АБИ?

Генерация Если вы используете такие инструменты, как Hardhart/Truffle, или IDE, например Remix, ABI контракта создается автоматически. Вы также можете вручную создать ABI с помощью пакета Solidity Compiler NPM. После установки пакета вы можете запустить команду solcjs contractname.sol --abi в терминале. В случае успешного выполнения будет создан файл .abi.

Теперь, когда у вас есть сгенерированный ABI, давайте посмотрим на некоторые элементы в этом файле:

Выполнение Поскольку ABI работает как интерпретатор между байт-кодом EVM и Javascript веб-сайта, он необходим, когда вы хотите выполнить какие-либо функции смарт-контракта. В дополнение к ABI требуется адрес контракта в блокчейне. Вот небольшой фрагмент кода Javascript, показывающий, как это делается:

Если вы хотите найти ABI уже развернутого контракта, вы можете найти его, выполнив поиск на Etherscan по адресу контракта. Например здесь:

Кодирование Поскольку все коммуникации осуществляются в байт-коде, было бы трудно ожидать, что разработчики сами будут кодировать эти сообщения. К счастью, популярные компиляторы, такие как Remix, также могут обрабатывать кодировку за вас. Эти кодировки следуют определенному шаблону, поэтому можно лучше понять, что происходит, просмотрев спецификацию ABI.

Первые четыре байта — это сигнатура функции, которая указывает, какой тип функции в смарт-контракте выполняется. Популярный идентификатор функции — a9059cbb, что указывает на то, что это перевод ERC20. Здесь есть каталог базы данных сигнатур функций, где вы можете изучить больше.

Источник: https://miro.medium.com/max/1400/1*YDi7sDUmAc3wjN8TcIBrog.png

Начиная с пятого байта, здесь кодируются аргументы. Ответы имеют аналогичную структуру, но без сигнатуры функции.

‍

Заключение ABI часто упускают из виду при работе со смарт-контрактами, но он играет важную роль в удобстве использования этой технологии. Использование руководств по смарт-контрактам — отличный способ понять мощь этой бесшумной рабочей лошадки и отличный способ применить свои знания.

Источник этой статьи - https://www.alchemy.com/overviews/what-is-an-abi-of-a-smart-contract-examples-and-usage .