Что такое смарт-контракт: код, состояние и вызовы в Ethereum

Смарт-контракт — это программа, работающая в блокчейне Ethereum. Она объединяет код и данные по определённому адресу. Код содержит функции, а данные называют состоянием контракта. Эти три элемента — код, состояние и адрес — дают конкретный ответ на вопрос, что такое смарт-контракт.

Чтобы понять взаимодействие с такой программой, нужно добавить ещё один элемент: вызов определённой в ней функции посредством транзакции. Ниже разберём, как связаны эти понятия, чем управление внешним аккаунтом отличается от управления аккаунтом контракта и почему для информации извне нужен отдельный механизм передачи данных.

Код, состояние и адрес: из чего состоит контракт

В документации Ethereum о смарт-контрактах контракт описан как совокупность кода и данных, находящаяся по конкретному адресу блокчейна. Каждая составляющая отвечает на свой вопрос:

• Код: какие функции определены в программе?
• Состояние: какие данные относятся к контракту?
• Адрес: о каком именно контракте идёт речь?

Слово «состояние» здесь обозначает данные. Например, в вымышленном учебном контракте частью состояния может быть переменная counter. Её название позволяет обсуждать конкретный элемент примера, но само по себе не сообщает ни начальное значение, ни правила его изменения.

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

Из этого определения следует ограниченный вывод: адрес указывает, какой контракт рассматривается, а код и состояние описывают разные стороны его устройства. Поэтому одного адреса недостаточно для объяснения поведения программы. Это вывод из структуры определения, а не дополнительное свойство, которое можно приписать любому адресу.

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

Чем отличается управление EOA и аккаунтом контракта

Документация Ethereum об аккаунтах различает внешний аккаунт, или EOA, и аккаунт контракта. Внешним аккаунтом управляет тот, кто располагает его приватными ключами. Аккаунтом контракта управляет код смарт-контракта.

В этих формулировках важно сохранять предмет обсуждения. Для EOA источник описывает управление посредством приватных ключей. Для аккаунта контракта управляющей логикой служит программа. Сами по себе эти определения не дают оценки защищённости конкретного аккаунта или программы.

Управление кодом не означает, что люди не могут взаимодействовать с контрактом. Здесь рассматриваются два разных вопроса: кто обращается к программе и какая логика определяет её поведение. Пользовательское обращение совместимо с тем, что действия контракта задаются его кодом.

Чтобы не смешивать участников, заменяйте расплывчатое слово «аккаунт» более точным обозначением: «внешний аккаунт отправителя» или «аккаунт контракта», когда это соответствует контексту. Такой приём помогает проследить объяснение без предположения, что все аккаунты Ethereum устроены и действуют одинаково.

Например, фраза «аккаунт обращается к аккаунту» почти ничего не поясняет новичку. Формулировка «пользовательский аккаунт обращается к функции определённого контракта» уже показывает участников и предмет взаимодействия. При этом она ещё не описывает результат обращения.

Что означает вызов функции через транзакцию

Пользовательские аккаунты могут взаимодействовать со смарт-контрактами, отправляя транзакции, которые вызывают определённые в этих контрактах функции. На этом уровне объяснения важна связь между отправителем, конкретным контрактом и выбранной функцией.

При чтении описания взаимодействия задайте три вопроса:

1. Какой пользовательский аккаунт отправляет запрос?
2. К какому адресу контракта направлено обращение?
3. Какая функция этого контракта вызывается?

Ответы раскрывают механизм взаимодействия, но сами по себе не устанавливают успешное исполнение или определённое итоговое состояние. Из описания отправки транзакции не следует конкретный результат: для такого вывода нужны дополнительные сведения о рассматриваемом случае.

Это различие полезно сохранять и в собственных заметках. Запись «отправлена транзакция для вызова функции» фиксирует известное действие. Добавление «после этого значение стало таким-то» требует отдельного основания. Здесь мы разбираем устройство обращения к программе, без стадий проверки транзакций и разбора возможных исходов.

Последовательность транзакций — отдельная тема. Если в дальнейшем встретится соответствующий термин, материал о nonce аккаунта Ethereum и последовательности транзакций поможет разобраться с контекстом. Для понимания смарт-контракта сейчас достаточно связи «аккаунт — контракт — определённая функция».

Условный пример: переменная counter и функция recordVisit

Представим вымышленный контракт для учебного разбора. По условию у него есть переменная состояния counter и функция recordVisit. Названия выбраны только для примера; речь не идёт о реально существующем контракте.

Описание можно записать в три строки:

• Контракт: условная программа по неуказанному адресу Ethereum.
• Состояние: переменная с именем counter.
• Функция: определённая в программе функция recordVisit.

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

На этом условие заканчивается. В нём не задано начальное значение переменной, не установлено правило увеличения и не описано другое изменение данных. Поэтому нельзя приписать counter какое-либо итоговое число лишь на основании названий.

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

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

Почему для внешних данных нужен оракул

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

Документация Ethereum называет оракулами инструменты, которые получают данные извне и делают их доступными смарт-контрактам. Так обозначается роль механизма передачи информации. В объяснении полезно отдельно описывать сам контракт и источник поступающих к нему внешних данных.

Для условного продолжения учебного примера предположим, что значение счётчика хотят связать с посещаемостью занятия, сведения о которой записаны вне Ethereum. В условии появляется потребность во внешних данных. Одно название recordVisit ещё не объясняет, каким способом эти сведения становятся доступны программе.

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

Для базового понимания достаточно удерживать два вопроса: откуда берутся данные и как они становятся доступны контракту? Ответ на второй вопрос не заменяет обоснование первого. Подробная оценка конкретного оракула выходит за рамки этого вводного разбора.

Проверочный список для чтения объяснений

• Определите программу. Уточните, что речь идёт об Ethereum и конкретном рассматриваемом контракте.
• Разделите код и состояние. Отнесите функции к коду, а переменные — к данным, не придумывая их значения.
• Уточните управление. Различайте управление EOA посредством приватных ключей и управление аккаунтом контракта посредством кода.
• Назовите обращение. Найдите в описании отправителя, контракт и вызываемую функцию.
• Соотнесите вывод с основаниями. Отправка транзакции сама по себе не устанавливает результат, а название функции не раскрывает её поведение.
• Найдите внешние данные. Если пример зависит от информации вне блокчейна, выясните, как она поступает к контракту.

Этот список помогает увидеть предположения, на которых построено объяснение. Ссылки на документацию обосновывают изложенные понятия, но сами по себе не устанавливают безопасность или корректность конкретного контракта.

Образовательный материал подготовлен с помощью ИИ. Вымышленный пример предназначен для разбора понятий и не является рекомендацией отправлять транзакцию или подписывать запрос в кошельке.