EVM-блокчейны. Классификация
Казалось бы: зачем? Но не всё так очевидно, если начать разбираться, а разбираться уже есть в чём и зачем. Попробуем?
Что такое EVM?
Странно, если открыли статью с столь специфичным названием и не знаете, о чём речь. Поэтому здесь будет не просто ответ на поставленный (если он нужен — то пройдите по ссылке : “EVM (Ethereum Virtual Machine) — это «распределённый компьютер», отвечающий за выполнение смарт-контрактов”) вопрос, но три важных тезиса:
— EVM-блокчейны — ответ на вопрос об “ убийцах ” Эфира: вместо того, чтобы устранить Ethereum — блочейны взяли свойство интероперабельности и создали кроссчейн-механики самого разного образца;
— EVM-блокчейны хотя бы из-за количества не могут быть однородны, поэтому гетерогенность — второе, после функциональной совместимости, свойство;
— EVM-блокчейны, наконец, имеют в себе опыт тех многих проблем, которые раскроются в мире Cosmos, Polkadot, Avalanche и мультичейновости вообще.
Поговорим же о переходах?
В том смысле, что классифицировать EVM-совместимость можно по-разному. В сей раз попробую зайти со стороны одно- и/или дву-направленности. Сразу — примеры:
Скажем, BNB-chain (BSC) имеет почти полное сходство с Ethereum с разницей лишь в алгоритме консенсуса (D PoS +PoA — ещё точнее: Proof of Staked Authority (PoSA) — vs. PoW). В этом смысле сохраняется:
— Подход к архитектуре смарт-контрактов;
— Отсюда: dApss и токены — совместимы двунаправленно.
Проще говоря: если отправлю USDt в сети Ethereum, Polygon, BSC и держатель имеет адрес в MetaMask , то с огромной долей вероятности он получит платёж, если даже ему будет необходимо помучаться с добавлением новой сети.
Другое дело, скажем, Tron.
- Изначально “Ethereum VM address is 20 bytes, but TRON’s VM address is 21 bytes”, — то есть: “Адрес EVM составлял 20 байт, а адрес EV TRON — 21 байт”.
- Далее: “В TVM используется концепция Bandwidth. В отличие от газового механизма EVM в Ethereum, операции транзакций или смарт-контрактов на TVM бесплатны, токены не расходуются. Технически, исполняемая вычислительная мощность на TVM не ограничена общим количеством токенов” ( чем это чревато — уже описывал в ряде статей);
- Или ещё: “благодаря тщательно продуманной парадигме проектирования и тонкому коду базовых операций, TVM может гарантировать точность каждого шага вычислений, максимально снижая неоднозначность. Из соображений безопасности трансферы и выполнение смарт-контрактов обходятся только в очки пропускной способности, а не в TRX, что освобождает TRON от атак по аналогии с Ethereum в отношении режима потребления GAS. Стабильность потребления пропускной способности достигается при фиксированной стоимости каждого вычислительного шага” (опять же — у этого подхода есть проблемы, но сегодня речь не о них).
Проще всего описанное понять на таком сравнении:
- Адрес ETH: 0x23802e21c6cd72c091792bfb9f7afc2265cc68d6
- Адрес BSC: 0x23802e21c6cd72c091792bfb9f7afc2265cc68d6
- Адрес Polygon: 0x23802e21c6cd72c091792bfb9f7afc2265cc68d6
- Адрес Tron: TNrvCZqdzcZ7gib49WpM7k4uJfoe6pACH6
При этом изменения могут быть и не существенными при трансфере, но всё же они явно бывают/есть, а отсюда: Tron можно отнести к EVM-блокчейнам с однонапраленной совместимостью.
А как же быть с Fantom, Aurora, Optimism, Arbitrum и другими? Здесь, прежде всего, надо остановиться, поскольку к общей классификации (двунаправленная совместимость, однонаправленная и несовместимость), которая проводит градацию горизонтально между чейнами, стоит добавить вертикальную градацию: L1 — L2.
Поэтому получаем, что Optimism, Arbitrum будут двунаправленной совместимости, но на L2, тогда как BSC, Polygon, etc. — двунаправленные, но на L1.
Учебник по Solidity. Все об адресах
Продолжаем серию статей про язык Solidity и платформу Ethereum. В этой статье будет рассказываться про адреса в Ethereum. Статья была написана в августе 2019 года, с той порой язык изменился, поэтому несоответствия в описании автора были исправлены.
Во введении проведено сравнение Ethereum адресов с почтовыми адресами в реальном мире.
Техническая часть начинается с раздела «Что такое (технически) адрес в Ethereum?»
Оглавление
Что такое (технически) адрес Ethereum?
Основы адресов в Solidity
address vs address payable
Методы доступные при работе с адресами
Преобразование типов address и address payable
Методы возвращающие тип address
1. Введение
На август 2021 года в блокчейне Ethereum насчитывается почти 166 миллионов уникальных адресов!
Давайте начнем с очень простого примера, чтобы понять, что такое адреса в Ethereum (и в блокчейне в целом). Для этого нам нужно представить себе сценарий.
Вы находитесь в отпуске в Суздали. Вы впервые посещаете этот город, и он вам очень понравился! Настолько, что вы решили сказать своему другу Алексу Цветкову, что он обязательно должен его посетить.
Хорошим способом намекнуть ему об этом будет отправка открытки с изображением Суздальского Кремля.
Вы идете на почту, и почтальон спрашивает вас: «Куда отправить?», на что вы отвечаете: «Моему другу, Алексу Цветкову».
Сотрудник за стойкой обязательно скажет, что:
он не знает, КТО этот ваш друг и
он не знает, ГДЕ он живет.
Поскольку вы знаете адрес Алекса, вы напишете его на открытке и передадите ее сотруднику почтового отделения.
Затем почтовая компания отправит вашу открытку, используя свою курьерскую сеть и отделения по всему миру. Открытка будет передаваться между почтовыми отделениями и перевозчиками.
Когда письмо прибудет в Москву, почтальон возьмет его и опустит в почтовый ящик Алекса Цветкова: это его домашний адрес.
Простые аналогии
Эта история с открыткой может показаться слишком упрощенным примером. Ведь каждый знает, как отправить письмо и проверить свой почтовый ящик, чтобы посмотреть, что ему принес курьер.
Адрес в Ethereum имеет схожие характеристики с почтовыми адресами. Благодаря использованию криптографии с открытым ключом.
Уникальность адреса
В реальном мире почтовый адрес связан с почтовым ящиком, а вернее он связан с его географическим расположением.
Даже если в мире существует несколько Алексов Цветковых, но есть только один Алекс Цветков, проживающий по адресу «RU, 121552, Москва, ул. Ярцевская, д. 30«.
Почтовый адрес — это как этикетка на почтовом ящике, которая соответствует имени человека и месту, где находится этот почтовый ящик.
Ethereum адрес — это последние 20 байт хэша (хэш функция keccak-256) открытого ключа.
Поскольку функции хэширования детерминированы, это значит, что для разных входных данных будет разный хэш, при этом для одних и тех же входных данных хэш функция будет возвращать всегда еднообразный хэш. Поэтому для уникального закрытого ключа => создаётся уникальный хэш.
Личное и секретное
Ключ вашего почтового ящика не только уникален, но также личный и секретный. С уникальностью мы уже познакомились, теперь давайте рассмотрим «личный» и «секретный».
Личный — только вы владеете ключом, который открывает ваш почтовый ящик. Вы храните ключ в тайне, прикрепив его к кольцу для ключей вместе со всеми остальными ключами.
Секретный (закрытый) — вы и только вы знаете, для чего может быть использован данный физический ключ. Если я дам вам свой набор ключей, вы не будете знать, каким именно ключом вам открыть мой почтовый ящик.
Аналогично в Ethereum, ваш закрытый ключ хранится в вашем кошельке. Только вы должны знать его и никогда не делиться им!
Управление секретным (закрытым) ключом
В реальном мире вы можете открыть свой почтовый ящик уникальным физическим ключом. Ваш почтовый ящик имеет встроенный замок, к которому привязан уникальный секретный ключ для его открытия.
В Ethereum вы можете использовать свой аккаунт с уникальным закрытым ключом.
Заметка: закрытый или секретный ключ? По сути это одно и тоже. Если вы говорите про “открытый ключ”, то в пару к нему говорите “закрытый ключ”. Если говорите “публичный ключ”, то говорите “секретный ключ”. Зависит от ваших предпочтений как использовать русский язык. Далее по тексту будет использоваться “закрытый” ключ.
В мире криптографии «личный» и «закрытый» ключ являются взаимозаменяемыми терминами. Открытый ключ является производным от закрытого ключа, поэтому они связаны между собой.
Закрытые ключи в Ethereum позволяют отправлять ether путем подписания транзакций. Единственным исключением являются смарт-контракты, как мы увидим позже.
Различные типы адресов
Ethereum адрес — это то же самое, что и почтовый адрес: он представляет собой адресата сообщения.
Адрес в платежной части транзакции Ethereum — это то же самое, что и счет получателя при банковском переводе.
Виды адресов в Ethereum: Externally owned accounts, contract accounts
External owned accounts (учетные записи, принадлежащие внешним пользователям, EOA): контролируются закрытыми ключами.
Закрытый ключ даёт контроль над ether на счёте и над процессами аутентификации, необходимой счёту при взаимодействии со смарт-контрактами. Они (закрытые ключи) используются для создания цифровых подписей, которые требуются для транзакций по расходованию любых средств на счете.
Contract accounts (учетные записи смарт-контрактов, CA): самоуправляемы своим своим кодом.
В отличие от EOA, у смарт-контрактов нет открытых или закрытых ключей. Смарт-контракты поддерживаются не закрытым ключом, а присущим им кодом. Можно сказать, что они «владеют собой».
Адрес каждого смарт-контракта определяется в ходе выполнения транзакции по созданию смарт-контракта, как результат функции от источника транзакции и nonce. Ethereum адрес смарт-контракта можно использовать в транзакции в качестве получателя, отправляя средства на смарт-контракт или вызывая одну из функций смарт-контракта.
2. Что такое (технически) адрес Ethereum?
Хэш-функции являются ключевым элементом при создании адресов. Ethereum использует хэш-функцию keccak-256 для генерации адресов.
В Ethereum и Solidity адрес имеет размер в 20 байт (160 бит или 40 шестнадцатеричных символов). Он соответствует последним 20 байтам хэша (keccak-256) открытого ключа. Адрес всегда имеет префикс 0x, поскольку он представлен в шестнадцатеричном формате (нотация base16).
Это определение довольно техническое и звучит сложно. Я выделил жирным шрифтом основные элементы адресного типа. Однако я считаю, что объяснять эти 3 элемента по отдельности — не лучший подход. Скорее, я бы выбрал альтернативный путь, который даст вам более полную картину. Пошагово посмотрим как создаётся адрес в Ethereum.
Как создается адрес Ethereum?
Очень полезно понять процесс создания адреса в Ethereum. Это позволит по-другому взглянуть и понять, как устроена платформа Ethereum.
Мы будем ссылаться на официальную техническую спецификацию блокчейна Ethereum: желтую бумагу. Хотя она выглядит сложной и трудночитаемой, я помогу вам понять ее, разбив описание на небольшие шаги, которые легко усвоить.
Процесс создания адресов в Ethereum можно разделить на два типа: создание EOA адресов и создание адресов смарт-контрактов.
Как создаются EOA адреса?
Давайте используем спецификацию Yellow Paper и создадим адрес Ethereum с нуля. Мы будем использовать эту статью Винсента Кобеля в качестве пошагового руководства по созданию адреса Ethereum.
1. Начнём с открытого ключа (128 символов / 64 байта)
Примечание: открытый ключ получается из закрытого ключа с помощью ECDSA (алгоритм цифровой подписи на эллиптической кривой). Ethereum использует тот же тип кривой, что и биткоин: secp256k1.
2. Применим хэш (keccak-256) к открытому ключу. Должна получиться строка длиной 64 символа / 32 байта.
3. Возьмем последние 40 символов / 20 байт из полученного хэша или отбросьте первые 24 символа / 12 байт.
Эти 40 символов / 20 байт являются адресом.
С префиксом 0x адрес фактически становится длиной 42 символа. Кроме того, важно отметить, что они нечувствительны к регистру. Все кошельки должны понимать адреса Ethereum, выраженные заглавными или строчными символами. (Начиная с EIP-55, адреса в верхнем регистре используются для проверки контрольной суммы)
0x001d3f1ef827552ae1114027bd3ecf1f086ba0f9 или 0X001D3F1EF827552AE1114027BD3ECF1F086BA0F9
Как создаются адреса смарт-контрактов?
Адреса смарт-контрактов создаются по-другому. Они детерминировано вычисляются из двух вещей:
Адрес создателя смарт-контракта: sender
Сколько транзакций отправил создатель: nonce
Ниже описаны шаги по созданию адреса смарт-контракта
Возьмите значения sender и nonce.
Закодируйте их с помощью RLP
Захэшируйте результат с помощью Keccak-256
Адреса в кратком изложении
В целом, основными характеристиками адресного типа в Solidity являются:
Длина 20 байт (160 бит): как уже было сказано, Ethereum адрес соответствует последним 20 байтам хэша Keccak-256 связанного с ним открытого ключа.
Шестнадцатеричный формат (нотация base16): Ethereum адрес содержит ровно 40 символов (2 символа = 1 байт) из шестнадцатеричного диапазона (0 1 2 3 4 5 6 7 8 9 или a b c d e f).
Префикс 0x: поскольку это шестнадцатеричный формат, он должен иметь префикс 0x. Поэтому его общая длина составляет 42 символа, если считать 0x.
3. Основы адресов в Solidity
Как определить переменную адресного типа?
Чтобы определить переменную адресного типа, укажите ключевое слово address перед именем переменной.
address user = msg.sender;
Мы использовали встроенную функцию Solidity msg.sender для получения адреса текущего аккаунта, взаимодействующего со смарт-контрактом.
Но вы можете жёстко закодировать определенные адреса в коде Solidity, используя адресные литералы. Они описаны в следующем разделе.
Адресные литералы
Адресные литералы — это шестнадцатеричное представление Ethereum адреса, жёстко закодированное в файле Solidity.
Вот пример того, как объявить литерал адреса в Solidity.
address owner = 0xc0ffee254729296a45a3885639AC7E10F9d54979;
Как уже отмечалось ранее, литерал адреса должен:
содержать 40 символов (длиной 20 байт), и
должны иметь префикс 0x.
имеют правильную контрольную сумму
Что касается пункта 3), адресные литералы должны иметь правильную контрольную сумму. Если они не проходят тест на контрольную сумму, Remix или компилятор Solidity выдадут предупреждение и будут рассматривать их как обычные интервалы чисел. Формат контрольной суммы адреса в смешанном регистре определен в EIP-55.
Наконец, адресные литералы по умолчанию устанавливаются как address .
4. address vs address payable?
Различие между address и address payable было введено в Solidity версии 0.5.0. Идея заключалась в том, чтобы разграничить адреса, которые могут получать ether, и теми, которые не могут (используются для других целей). Проще говоря, address payable может получать ether, а обычный address — нет.
В Solidity, с точки зрения отправителя:
Вы можете отправить ether в переменную, определенную как address payable
Вы не можете отправить ether в переменную, определенную как address
Вы можете использовать ключевое слово payable перед именем переменной типа address, чтобы позволить переменной принимать ether.
Примечание: Тип, возвращаемый msg.sender, является типом address payable.
5. Методы, доступные при работе с адресами
Примечание: количество ether в _amount, указанное в качестве параметра в приведенных ниже методах, выражается в Wei (18 нулей):
1 ether = 1¹⁸ wei = 1 000 000 000 000 000 000 000 000 000 000 wei
Все методы типа address в Solidity:
<address payable>.transfer(uint256 _amount)
<address payable>.send(uint256 _amount) returns (bool)
<address>.call(bytes memory) returns (bool, bytes memory)
<address>.delegatecall(bytes memory) returns (bool, bytes memory)
<address>.staticcall(bytes memory) returns (bool, bytes memory)
Мы разделим методы, связанные с адресами, на 3 категории и 2 типа транзакций:
методы связанные с ether: balance() , transfer() и send()
методы связанные с взаимодействием со смарт-контрактами: call() , delegatecall() и staticcall()
методы связанные с возможным кодом внутри адрес: code() , codehash()
Методы, связанные с ether
возвращает баланс счета в wei.
Любая переменная, определенная как address, имеет метод balance(). Этот метод позволяет получить количество ether, хранящегося на счете, принадлежащем внешнему владельцу (EOA / пользователю) или смарт-контракту. Возвращаемое число представляет собой количество ether в wei.
В приведенном ниже коде показано, как получить ether баланс вашего адреса. В примере мы используем msg.sender.
На самом деле существует два способа посмотреть баланс Ethereum адреса.
Если вы хотите получить остаток по текущему смарт-контракту, мы можем использовать address(this) (это явное преобразование).
Утверждение типа <address>.balance считается способом чтения информации из состояния, поскольку оно обращается к данным блокчейна. Поэтому любая функция в Solidity, возвращающая <address>.balance, может быть определена как view.
Переводит указанное количество ether (в wei) на указанный address.
Возвращает при неудаче и выбрасывает исключение при ошибке.
Потребляет 2 300 gas.
Под капотом функция transfer() запрашивает баланс адреса, применяя свойство balance, перед отправкой ether.
Метод: address.send(uint256) returns (bool)
send — это низкоуровневый аналог transfer. При неудачном выполнении текущий смарт-контракт не прекратится с выбросом исключением, просто send вернет false.
Использование send сопряжено с некоторыми опасностями: передача не состоится, если глубина стека вызовов равна 1024 (это всегда может быть принудительно исправлено вызывающей стороной), а также если у получателя закончится gas. Поэтому для безопасных переводов ether всегда проверяйте возвращаемое значение send, используйте transfer или даже лучше: используйте шаблон, в котором получатель снимает деньги.
Возвращает false при неудаче (Внимание: всегда проверяйте возвращаемое значение send).
Потребляет газ в размере 2300.
Методы взаимодействия со смарт-контрактами
Solidity предлагает удобный способ вызова функций удалённых смарт-контрактов (например: targetContract.doSomething(. ) ). Однако этот высокоуровневый синтаксис доступен только в том случае, если интерфейс удалённого смарт-контракта известен на этапе компиляции.
В EVM представлено 4 специальных операционных кодов (opcode) для взаимодействия с другими смарт-контрактами, из которых 3 доступны, как методы типа address: call, delegatecode и staticcall.
Примечание: callcode устарел, но все еще доступен в низкоуровневых ассемблерных вставках.
Все низкоуровневые функции, определенные ниже, принимают один аргумент: необработанное сообщение (Может быть создано в библиотеке web3 с помощью encodeABI()).
В этом разделе мы опишем эти низкоуровневые методы. Для лучшего понимания нам необходимо разделить контекст сценария на три части:
Мы рассматриваем сценарий, в котором смарт-контракт A взаимодействует с смарт-контрактом B
Кто вызывает функции удалённого смарт-контракта (отправляет сообщения)? Хранилище какого смарт-контракта обновляется?
Технические детали (возвращаемые значения, передаваемый gas и т.д.)
Метод: address.call(bytes memory) returns (bool, bytes memory)
Типичный случай: смарт-контракт A хочет выполнить функцию смарт-контракта B, которая обращается или изменяет хранилище смарт-контракта B. Вызов B.function() может обновить только хранилище B.
ПРЕДУПРЕЖДЕНИЕ: НЕБЕЗОПАСНО! Получатель может (случайно или злонамеренно) израсходовать весь ваш газ, в результате чего ваш смарт-контракт остановится с исключением out of gas (OOG); всегда проверяйте возвращаемое значение метода call.
Следует избегать использования .call() при выполнении функции другого смарт-контракта, так как она обходит проверку типов, проверку существования функции и упаковку аргументов.
Спецификация
Отправляет сообщение (низкоуровневый CALL, см. опкод OxF1), передавая полезную нагрузку полученную в аргументе и помеченную как memory.
Передаёт весь доступный газ.
Возвращает кортеж с:
истинностное значение результата вызова (true при успехе, false при неудаче или ошибке).
данные в байтовом формате.
Предупреждение: callcode() устарел, вместо него используется .delegatecall(). Однако его все еще можно использовать в assembly вставках в коде смарт-контракта.
Типичный случай: смарт-контракт A по сути копирует себе функцию B. Выполнение функции смарт-контракта В будет происходить в контексте смарт-контракта A, возможно взаимодействие со хранилищем смарт-контракта А. Вызов B.function() обновит хранилище A.
Спецификация
Низкоуровневая функция CALLCODE, подобная address(this).call(. ), но с заменой кода этого смарт-контракта на код адреса.
Возвращает false при ошибке.
Метод: address.delegatecall(bytes memory) returns (bool, bytes memory)
Типичный случай: смарт-контракт A хочет выполнить функцию смарт-контракта B, при этом функция будет выполнена в контексте смарт-контракта А. При этом функция B может перезаписать хранилище A и выдать себя за A для любого другого смарт-контракта. Тогда msg.sender будет адресом A, а не B.
В этом случае смарт-контракт A по сути делегирует вызов функции смарт-контракту B. Разница с прежним методом callcode заключается в том, что использование delegatecall позволяет не только перезаписать хранилище смарт-контракта A. Но и если смарт-контракт B вызовет другой смарт-контракт C, смарт-контракт C увидит, что отправителем msg.sender является смарт-контракт A.
Спецификация
Низкоуровневая операция DELEGATECALL (см. опкод OxF4) (с полным контекстом msg, видимым текущим смарт-контрактом), передавая полезную нагрузку полученную в аргументе и помеченную как memory.
Передаёт весь доступный газ
Возвращает кортеж с:
истинностным значением как результатом вызова (true при успехе, false при неудаче или ошибке).
данные в байтовом формате.
Метод: address.staticcall(bytes memory) returns (bool, bytes memory)
Спецификация
Низкоуровневая операция STATICCALL (см. опкод OxF4) (с полным контекстом msg, видимым текущим смарт-контрактом), передавая полезную нагрузку полученную в аргументе и помеченную как memor.
Возвращает кортеж с:
истинностным значением как результат вызова (true при успехе, false при неудаче или ошибке).
данные в байтовом формате.
Передаёт весь имеющийся газ
Дополнительные параметры для вызовов низкого уровня
При взаимодействии с смарт-контрактами в Solidity через низкоуровневые вызовы call(. ), delegatecall(. ) и staticcall(. ) у вас есть возможность добавить некоторые пользовательские параметры (немного похоже на web3js). Это позволит вам указать, например, сколько ether вы хотите отправить по адресу, указанному в вызове (value), а также сколько gas вы готовы использовать.
В приведенном ниже фрагменте кода приведен пример.
6. Преобразование типов address и address payable
Допускаются неявные преобразования из address payable в address
Неявные преобразования из address в address payable невозможен (за исключением address payable к address payable).
Примечание: для версии 0.5.* способ преобразования из address в address payable заключался в промежуточном преобразовании в uint160 (160 бит = 20 байт, размер Ethereum адреса). Для версии 0.6.* можно использовать ключевое слово payable, как функцию и передать в неё адрес — payable(address).
Явное преобразование из и в address разрешено для: целых чисел uint160, целочисленных литералов, bytes20 и типа contract.
Только выражения типа address и contract могут быть преобразованы в тип address payable с помощью явного преобразования payable(. ). Для типа contract это преобразование допустимо только в том случае, если смарт-контракт может получать ether, т.е. смарт-контракт либо имеет функцию receive, либо функцию fallback c payable. Обратите внимание, что payable(0) допустимо и является исключением из этого правила.
Контракты как address
Начиная с версии 0.5.0 Solidity, смарт-контракты больше не cодержат тип address, но все еще могут быть явно преобразованы в address или address payable (если у них есть функция receive или fallback payable).
Примечание: преобразование выполняется с использованием address(переменная) и payable(address(переменная)).
Операторы используемые с address
С address доступны следующие операторы: <=, <, ==, !=, >= и >.
7. Методы, возвращающие тип address
msg.sender
msg.sender() возвращает address payable.
Как следует из названия, функция msg.sender возвращает адрес, который инициировал вызов этого смарт-контракта. Однако важно отметить следующее:
msg.sender возвращается в текущем вызове. Он не обязательно возвращает отправителя EOA, который отправил транзакцию.
Если смарт-контракт A вызван непосредственно в транзакции отправленной с EOA, то в msg.sender будет адрес EOA.
Если смарт-контракт A вызван другим смарт-контрактом B, где B был вызван транзакцией отправленной с EOA, то в msg.sender будет адрес смарт-контракта B.
tx.origin
Предупреждение: небезопасно!
tx.origin() возвращает address.
tx.origin возвращает EOA адрес отправителя изначальной транзакции. Таким образом, возвращается полная цепочка вызовов.
block.coinbase
block.coinbase() возвращает address payable.
Адрес добытчика текущего блока, т.е. адрес получателя платы за текущий блок и вознаграждения за блок.
ecrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) returns (address)
ecrecover восстанавливает адрес, связанный с открытым ключом, из подписи эллиптической кривой или возвращает ноль при ошибке. Параметры функции соответствуют значениям ECDSA подписи:
r = первые 32 байта подписи
s = вторые 32 байта подписи
v = последний 1 байт подписи
ecrecover возвращает address, а не address payable.
8. Нулевой адрес
После написания смарт-контракта он развертывается в сети Ethereum с помощью специальной транзакции. Однако транзакция подразумевает наличие отправителя и получателя. Поэтому эта специальная транзакция должна быть отправлена на специальный адрес.
Так какой же адрес следует указывать в качестве получателя, когда речь идет о создании смарт-контракта?
Создание смарт-контракта в Ethereum предполагает создание специальной транзакции, адресом назначения которой является адрес: 0x00000000000000000000000000000000000000000000000000, также известный как нулевой адрес.
Раздел, связанный с нулевыми адресами из YellowPaper.
Виртуальная машина Ethereum (EVM) понимает, что транзакция направлена на создание нового смарт-контракта, если в поле получателя указан этот нулевой адрес. Этот адрес также имеет длину 20 байт, но содержит только пустые байты 0x0.
В сети Ethereum майнеры выполняют такую транзакцию (содержащую нулевой адрес), как инструкцию по созданию нового смарт-контракта.
Виртуальная машина Ethereum (EVM)
Физическую установку EVM нельзя описать также, как объекты вроде облака или океанской волны. Виртуальная машина существует как единое целое благодаря тысячам компьютеров, подключенных к клиенту Ethereum.
Сам протокол Ethereum существует исключительно с целью сохранения непрерывного, бесперебойного и неизменяемого функционирования этой виртуальной машины. Это среда, в которой находятся все аккаунты и умные контракты Ethereum. При любом заданном блоке в цепочке Ethereum есть один и только один «каноничный» режим, и EVM определяет правила вычисления нового допустимого состояния от блока к блоку.
Прежде чем начать
Некоторые базовые знания в информатике, например термины байт (opens in a new tab) ↗ , память (opens in a new tab) ↗ и стек (opens in a new tab) ↗ , необходимы для понимания работы EVM. Также было бы полезно ознакомиться с такими понятиями криптографии и блокчейна, как хэш-функции (opens in a new tab) ↗ , доказательство работы (PoW) (opens in a new tab) ↗ и дерево Меркла (opens in a new tab) ↗ .
От реестра к государственной машине
Аналогия с «распределенным реестром» часто используется для описания таких блокчейнов, как Биткойн, которые позволяют децентрализовать валюту с использованием фундаментальных инструментов криптографии. Криптовалюта ведет себя как «обычная» валюта из-за правил, которые определяют, что можно и что нельзя делать для изменения реестра. Например, биткойн-адрес не может потратить больше биткойнов, чем получил ранее. Эти правила лежат в основе всех транзакций во многих блокчейнах, включая Биткойн.
Хотя у Ethereum есть собственная криптовалюта (Эфир), которая следует почти точно таким же интуитивным правилам, она также обеспечивает гораздо более мощную функцию: умные контракты. Для этой более сложной функции требуется более сложная аналогия. Вместо распределенного реестра Ethereum представляет собой распределенную машину состояний (opens in a new tab) ↗ . Состояние Ethereum — это большая структура данных, в которой хранятся не только все счета и балансы, но и состояние машины, которая может изменяться от блока к блоку в соответствии с заранее определенным набором правил и которая может выполнять произвольный машинный код. Конкретные правила изменения состояния от блока к блоку определяются EVM.
(opens in a new tab) ↗ Источник адаптированной диаграммы: Ethereum EVM illustrated (opens in a new tab) ↗
Функция перехода состояния Ethereum
EVM ведет себя как математическая функция: при вводе данных производится детерминированный вывод. Поэтому весьма полезно более формально описать Ethereum как имеющий функцию перехода между состояниями:
Учитывая старое допустимое состояние (S) и новый набор действительных транзакций (T) , функция перехода состояния Ethereum Y(S, T) создает новое допустимое состояние вывода S'
В контексте Ethereum состояние — это огромная структура данных, называемая модифицированным деревом Меркла Патрисии (opens in a new tab) ↗ , в которой все аккаунты связаны хэшами и сводятся к одному корневому хэшу, хранящемуся в блокчейне.
Транзакции — это криптографически подписанные инструкции от аккаунтов. Есть два типа транзакций: те, которые приводят к вызовам сообщений, и те, которые приводят к созданию контракта.
В результате создания контракта создается новый аккаунт контракта, содержащий скомпилированный байткод умного контракта. Всякий раз, когда другая учетная запись выполняет вызов сообщения для этого контракта, она выполняет свой байткод.
EVM работает как стековая машина (opens in a new tab) ↗ , вмещающая 1024 элементов. Каждый элемент стека — это 256-битное слово, выбранное для удобства использования в 256-битной криптографии (например, хэши Keccak-256 или подписи secp256k1).
Во время работы EVM использует временную область памяти (в виде байтового массива с адресацией по словам), которая не сохраняется между транзакциями.
Однако контракты содержат хэш-дерево Меркла Патрисии (в виде массива слов с адресацией по словам), связанное с аккаунтом и рассматриваемое как часть глобального состояния.
Скомпилированный байт-код умного контракта исполняется как последовательность машинных кодов EVM, таких как стандартные машинные операции XOR , AND , ADD , SUB , и т. д. В стековой машине EVM также есть и специальные блокчейновые опкоды, такие как ADDRESS , BALANCE , BLOCKHASH и т. д.
(opens in a new tab) ↗ Источник адаптированных диаграмм: Ethereum EVM illustrated (opens in a new tab) ↗
Все реализации EVM должны соответствовать спецификации, описанной в Желтой книге Ethereum.
За 5-летнюю историю Ethereum EVM претерпела несколько изменений, и существует несколько реализаций EVM на разных языках программирования.
Все клиенты Ethereum включают реализацию EVM. Кроме того, существует несколько автономных реализаций, в том числе:
What is Ethereum Virtual Machine (EVM)?
One way to think of the Ethereum blockchain is as a blockchain with a built-in programming language. A consensus-based, globally executed virtual machine is another way to describe it. The Ethereum Virtual Machine is the component of the Ethereum protocol responsible for all computing (EVM).
What is the Ethereum Virtual Machine? (EVM)
Ethereum’s ability to execute smart contracts depends on the EVM. Ethereum’s smart contracts allow for decentralized applications (dapps). Additionally, businesses can organize so-called ICOs, or initial coin offerings, on the Ethereum blockchain to introduce their tokens thanks to smart contracts.
ETHEREUM VIRTUAL MACHINE ESSENTIALS
- The Ethereum Virtual Machine (EVM) is a runtime environment for smart contracts used to develop and test smart contracts.
- The EVM is quasi-Turing complete, meaning it can perform any calculation as long as the user initiating the calculation has enough ether to pay the fee required for that calculation.
- The EVM is a sandboxed and isolated environment, meaning that the code it runs has no access to the network, filesystem, or other processes.
- Additionally, the EVM cannot access real-world data, e.g. the current date, time or weather. To acquire such data, it relies on so-called oracles.
- All full nodes of the Ethereum network run the EVM.
Environment for developing smart contracts
The EVM is sandboxed and isolated from the real world. It means that the code running in the EVM has no access to a network, file system, or other processes. It makes the EVM perfect for developing and testing smart contracts without interfering with the blockchain’s operations.
You might be asking yourself why it is a good idea to test smart contracts in a sandboxed environment. The thing is that flawed code can be detrimental to any smart contract, so making sure that there are no flaws in the smart contract code is a must.
Moreover, a sandboxed environment such as the EVM provides infinite opportunities to learn, iterate, improve and eventually complete robust smart contracts ready for deployment to the blockchain.
What does the EVM do?
Whenever a transaction is initiated on the Ethereum blockchain — and it does not matter whether it is a simple transfer of value or a smart contract deployment — the EVM must perform the following three checks:
It confirms whether a transaction has the correct number of values, whether the signature is valid, and whether the transaction nonce matches the nonce of that particular transaction account. In case of a mismatch, the transaction prompts an error.
It calculates the fee required for the transaction and initializes the gas payment.
It executes the transfer of the ether or tokens to the assigned address.
The transaction will fail if the EVM notices that the sender did not allocate enough gas to the initiated transaction. The transaction charge is not reimbursed to the initiator in this instance. Instead, the miner receives payment.
However, if a transaction is unsuccessful due to an error on the recipient’s address, the EVM will return the amount sent and the associated fee to the sender.
EVM is where the magic of Ethereum happens, bringing added value to blockchain technology and the world of cryptocurrencies. Because of features such as the EVM, the Ethereum platform has enjoyed great popularity, with ether, its native crypto, remaining one of the largest cryptos by market cap.
Limitations of the EVM
Turing complete is the term used to characterize the Ethereum Virtual Machine. The ability of a computer to perform every computation given to it is known as “Turing completeness.” Any acceptable analysis can be solved by programs or decentralized apps created in Ethereum.
But there is a limitation to the EVM, and it is a kind of safety precaution. Smart contracts can call other contracts, potentially allowing for infinite looping.
The EVM demands a gas fee for each on-network transaction, which means infinite computational loops are prevented by exhausting their ether. The EVM cannot be Turing-complete; instead, it is to be quasi-Turing-complete.
Another thing worth mentioning is that the EVM cannot access even the most basic real-world data. For example, the EVM cannot know on its own what day it is or tell the current temperature.
The EVM relies on real-world data providers known as oracles to acquire such data, which is required to execute smart contracts properly. An oracle can gather data from a website, an app or elsewhere and feed it to the smart contract.
Bottomline
The EVM makes Ethereum a platform and not just a blockchain. However, the EVM could be a better system. There are many challenges around transaction speed and network throughput.
It is an area of focus for the development community and the roadmap for Ethereum. If Ethereum is to fulfil its promises of revolutionizing how we transact amongst each other, it will be on the back of improvements to the EVM.