Целевая аудитория этой серии — блокчейн-разработчики и студенты компьютерных наук.
Столкнувшись с интерпретацией и восхвалением технологий, связанных с блокчейном, в СМИ, многие люди на какое-то время были в растерянности. Инвесторы и крупные компании руководствуются психологией FOMO (страх упустить возможность) и спешат объявить обо всем в блокчейне. Различные знаменитости сели и рассказали о социальном, политическом, экономическом и даже философском значении технологии блокчейн. У людей есть естественная неуверенность в неизвестном и неизвестном, и как разработчик я думаю, что лучший способ преодолеть тревогу (и возникающие в результате предположения) — это как можно больше повысить свою осведомленность об основных принципах и реализациях.
С технической точки зрения, в настоящее время, будь то Биткойн, Эфириум или EOS и IPFS, официально не запущенные, все они носят ярко выраженный экспериментальный характер и имеют различные ограничения, которые неизбежно влияют на разработку приложений верхнего уровня. . . . Большинство приложений блокчейна также затрагивают важные области, такие как финансы и кредит, поэтому глубокое понимание основных принципов является основным требованием для разработчиков блокчейна, а не просто развертывание смарт-контракта за 10 минут после обучения, особенно на ранних стадиях различных технологий. В случае незрелости небольшая неосторожность приведет к большим потерям.
Первая статья в этой серии, в основномОдно из основных различий между архитектурой криптовалюты (блокчейн 1.0), представленной биткойном, и программируемой распределенной кредитной инфраструктурой (блокчейн 2.0), представленной Ethereum, — поддерживается ли полный по Тьюрингу язык., чтобы увидеть эволюцию архитектуры технологии блокчейн.
Происхождение Биткойна и Эфириума: Виталик Бутерин (1994 г.р.) — бесспорный бог для тех, кто работает в валютных и сетевых кругах. Многие люди могут не знать, что Бутерин, как активный член раннего биткойн-сообщества, первоначально предложил, что биткойну необходимо разработать общий язык сценариев для поддержки разработки приложений с богатыми функциями, но он не получил поддержки команды разработчиков биткойн. Таким образом, в 2013 году был перезапущен проект Ethereum с сегодняшними процветающими зашифрованными токенами, коллекционными играми и DAO. Давайте сначала посмотрим, что именно представляет собой система сценариев Биткойн, которой недоволен V God?
Часть I: Биткойн-скриптовый движок
торговля
Транзакция имеет очень широкое значение в мире блокчейна, в криптовалютных приложениях ее можно понимать в узком смысле как передачу биткойн-квот между разными адресами, то есть перевод. Денежные переводы — это проверенное временем занятие, но технологии денежных переводов постоянно совершенствуются.Понимание модели передачи биткойнов особенно важно, потому что механизм сценариев биткойнов построен на основе этой модели.
Два способа передачи
1. Упрощенная традиционная центральная передача:Алиса (счет А) переводит x юаней Бобу (счет Б), банку нужны атомарные операцииbalance[A]-=x,balance[B]+=x, конечно, неявным условием является то, что Алиса завершила аутентификацию учетной записи А.
2. Заявление, объясняющее принцип транзакций Биткойн:Каждый узел в сети поддерживает независимую базу данных, которая записывает баланс каждого адреса.Если Алиса (владелец адреса А) захочет перевести x юаней Бобу (владельцу адреса Б), она будет транслировать это в сети «адрес А дает Х «устройства на адрес Б», принести публичный ключ А и подписать приватным ключом А. После того, как каждый узел получает его, он выполняет атомарные операции в своей собственной базе данных после успешной проверки.balance[addressA]-=x,balance[addressB]+=x. (Примечание. Фактический адрес генерируется публичным ключом, который для упрощения здесь не указан).
Вышеупомянутый 1 является основным в действительности, и существуют зрелые схемы расширения, но централизация неизбежно приносит такие проблемы, как стоимость и зло платформы;
2 Описание взято изb-money, an anonymous, distributed electronic cash system(Эта статья очень важна и оказала глубокое влияние на разработку Сатоши Накамото Биткойна), но в то время ее нельзя было применять на практике, потому что она в значительной степени полагалась на синхронизированную, ненарушенную сетевую среду, иначе было бы очень сложно поддерживать согласованность. Более того, эта проблема представления распределенной базы данных (византийская проблема), существующие алгоритмы консенсуса paxos, raft (невизантийский), включая pbft (византийский), масштабируемость не могут поддерживать число биткойн-узлов, исчисляемое десятками тысяч.
Дизайн модели транзакций биткойнов
Что касается модели транзакций Биткойн, то она впервые была предложена Сатоши Накамото.Bitcoin: A Peer-to-Peer Electronic Cash System.Сатоши Накамото фактически предложил две сети, блокчейн (цепочка блоков), о котором сейчас все говорят, — это явный метод организации данных, а другой неявный — что цепочка транзакций — это цепочка потока стоимости Биткойн.
Как показано на рисунке, самая ранняя модель описания транзакции:
Если Алиса (владелец адреса A) хочет перевести x долларов Бобу (владельцу адреса B), ей также необходимо подписать транзакцию и передать ее в сеть.Отличие в том, что баланс адреса А хранится не в базе данных каждой ноды, а в неизрасходованном выводе транзакции, переданном другими на адрес А, то есть UTXO (неизрасходованный вывод транзакции). Мы запрашиваем баланс адреса A, и на самом деле мы получаем сумму всех UTXO, чей платежный адрес — addressA. Широковещательный контент похож на «адрес A (объединение UTXO1 ... UTXO3) дает X единиц для адреса B», принесите pubkeyA и подпишите с помощью privatekeyA.
После того, как транзакция будет подтверждена в сети, у Боба будет доступен еще один UTXO. Если он хочет потратить деньги, ему нужно доказать, что он владеет приватным ключом B, соответствующим адресу B, тогда Боб также подписывает приватным ключом. Таким образом, транзакция становится цепочкой подписей.
Очевидно, здесь есть три проблемы:
1. Если ввод любой транзакции требует вывода предыдущей транзакции, откуда вообще взялся Биткойн? Таким образом, в битовой транзакции есть транзакция, называемая coinbase, которая известна как вознаграждение за майнинг. Генерация биткойнов генерируется с помощью алгоритма майнинга, и вход здесь поступает из системного вознаграждения. Он также фактически проверяет, является ли coinbase «зрелым», то есть достаточно ли подтвержден блок. В биткойне, если он не попадает в самую длинную цепочку, он будет отброшен как потерянный блок, и вознаграждение также будет аннулировано.
2. Нужно ли откатывать всю цепочку блоков, чтобы определить, является ли вывод транзакции UTXO? Нет, поскольку транзакции организованы в соответствии со структурой дерева Меркеля, определено, что запрос транзакции из всей базы данных блокчейна будет очень неэффективным. UTXO хранятся исключительно в цепочке состояния базы данных leveldb и кэшируются в памяти. Всякий раз, когда генерируется новый блок, обновляется набор UTXO, когда на узле происходит перестроение цепочки, процесс откатывается. Здесь следует отметить, что набор UTXO — это не пул транзакций, подлежащих подтверждению (TxMemPool), а источник ввода всех транзакций, подлежащих подтверждению; UTXO также теоретически могут быть реконструированы из всего блокчейна с помощью --reindex.
3. Баланс счета Алисы состоит из четырех UTXO, а именно 0,05, 0,2, 0,2 и 0,3.Теперь ей нужно перевести 0,6 Бобу.Что мне делать?
Теоретически Алиса может перевести три раза, но на самом деле это очень неразумно.Ей не только приходится платить больше комиссионных за обработку, но и мало опыта.Поэтому Вход транзакции может включать несколько UTXO.Как выбрать комбинацию UTXO имеет особые правила.анализировать; Сумма нескольких Входов не обязательно точно равна сумме перевода Выход1, и требуется возврат сдачи (Выход2), и, конечно, есть комиссия (Выход3), поэтому транзакция будет включать несколько Выходов. Конечно, для пользователей им нужно только установить адрес перевода, квоту, плату за обработку, а комбинация UTXO и изменения прозрачна.
Примечание. Ethereum отказался от модели UTXO и принял парадигму счета, аналогичную bmoney. Конкретные причины будут проанализированы во введении к дизайну виртуальной машины Ethereum.
Сделав столько предзнаменований, мы, наконец, можем приступить к дизайну сценария Биткойн.
Script opcodes
Биткойн-транзакции выполняются скриптовым движком (Script)иметь дело с. Процитируйте исходный код ядра биткойна здесьinterpreter.cppПримечание в:
/**
* Script is a stack machine (like Forth) that evaluates a predicate
* returning a bool indicating valid or not. There are no loops.
*/
Скрипт это классForth, основанный на стеке, без сохранения состояния, не полный по Тьюрингу язык.
Коды операций делятся на несколько категорий, таких как константы, управление потоком, операции со стеком, арифметические операции, битовые операции, криптографические операции, зарезервированные слова и т. д., а также включают 3 псевдоинструкции, используемые внутри. Вот несколько команд, которые появятся в следующих скриптах, на все команды можно ссылатьсяофициальная документацияиисходный код.
OP_0 ... OP_16: поместить литеральное значение в стек.
OP_DUP: скопируйте верхний элемент стека и поместите его в стек.
OP_ADD: извлечь верхний элемент и следующий верхний элемент стека, добавить их и поместить в стек.
OP_EQUAL: извлечь верхний элемент стека и верхний элемент следующего стека, сравнить, равны ли они, поместить 1 в стек, если они равны, иначе поместить 0.
OP_SHA256: извлечь верхний элемент стека, выполнить операцию шифрования sha-256 и поместить результат в стек.
OP_HASH160: извлечь верхний элемент стека, сначала выполнить операцию шифрования sha-256, а затем выполнить операцию дайджеста ripemd160 и поместить результат в стек. Примечательно, что это часть процесса генерации адреса на основе открытого ключа.
OP_CHECKSIG: извлечь верхний элемент стека и верхний элемент подстека, здесь sig и pubkey соответственно; внутри есть функция VerifySignature для проверки соответствия подписи и открытого ключа.
OP_CHECKMULSIG: Поместите m подписей и n открытых ключей в стек и поочередно проверьте, соответствуют ли m подписей подмножеству n открытых ключей.
Pay-to-PubkeyHash(P2PKH)
Пример, который Алиса репостила Бобу выше, является типичным P2PKH. Сатоши Накамото только что описал модель транзакций в статье, давайте взглянем на более конкретную реализацию.
Как показано на рисунке выше, прежде чем Алиса перейдет к Бобу, Боб должен предоставить собственный адрес сбора, но хэш открытого ключа фактически используется в P2PKH. Вот простое дополнение к процессу генерации ключа, как показано на рисунке ниже, закрытый ключ генерирует открытый ключ в одном направлении, а открытый ключ генерирует 160-битный PKH (хэш открытого ключа) с помощью команды OP_HASH160. может быть преобразован в более читаемый адрес для пользователей, но кодирование, процесс проверки и т. д. являются двунаправленными. Таким образом, предоставление адреса эквивалентно предоставлению PKH.
Ниже Алиса переводит деньги Бобу.запираниеВ выходных данных TX1 передайте сценарий открытого ключа. Если Боб пытается потратить деньги, ему нужноразблокироватьЭтот PubkeyScript предоставляет сценарий подписи, подтверждая себя владельцем закрытого ключа хэша открытого ключа в выводе TX1.
Приведенное выше, заключенное между , является числом, которое будет помещено в стек, по умолчанию используется инструкция push. Во время фактического выполнения scriptSig и scriptPubkey подключаются, и сценарии запускаются в порядке слева направо.
Ситуация в стеке показана на следующих двух рисунках. Студенты с базой сборки будут знакомы с принципом работы компьютерной модели стека.
поколение вознаграждает майнеров
Вознаграждение майнеров можно рассматривать как упрощенный P2PKH, разница в том, что ввод транзакции происходит от базы монет, а не от UTXO.
Pay-to-Script-Hash(P2SH)
Схема P2PKH относительно проста, и получатель Боб напрямую предоставляет платежный адрес. В процессе фактического обращения стоимости будет задействовано множество условий. Для выполнения более сложных функций,BIP12Предлагается добавить инструкцию OP_EVAL (в конструкции языка программирования,evalозначает, что язык имеет возможности метапрограммирования), и позже заменяется наBIP16Предлагается более полный стандарт транзакций P2SH.
Получателю платежа Бобу необходимо разработать RedeemScript — сценарий вывода средств, а затем сгенерировать хэш сценария и предоставить его Алисе.
Если Боб хочет потратить UTXO, ему необходимо предоставить подпись и RedeemScript.После успешной проверки содержимое RedeemScript будет выполнено, и если условия будут выполнены, он будет успешно разблокирован.
Следующий redeemScript разработан в сочетании с конкретными сценариями. Соответствующие примеры приведены далее в сочетании с применением смарт-контрактов.
В транзакции P2SH, поскольку Боб предоставляет хэш сценария, Алиса на самом деле не знает деталей транзакции, и конкретное содержание транзакции должно быть разработано Бобом. Это называется «перенос ответственности за предоставление условий погашения транзакции с отправителя средств на искупителя. Они позволяют отправителю финансировать произвольную транзакцию, независимо от ее сложности, с использованием 20-байтового хэша». * Это не лишено разногласий по дизайну, но в технической структуре Биткойн это путь к поддержке большего количества функций с минимальными изменениями.
Смарт-контракты Биткойн
Хотя когда дело доходит до смарт-контрактов, люди больше думают об Ethereum. Но, как упоминалось ранее, технологическое развитие идет в том же направлении. Еще в 1997 году основополагающая статья Ника Сабо Formalizing and Securing Relationships on Public NetworksКонцепция смарт-контрактов предлагается в. Система сценариев Биткойн поддерживает разработку ограниченных смарт-контрактов,В основном через P2SH-транзакции.
мультиподпись MultiSig
BIP11Предлагаются M-из-N мультиподписных транзакций. Условием разблокировки транзакции является аутентификация M подписи (MOP_CHECKMULTISIGинструкция. Это может быть достигнуто с помощью следующего сценария.
Гэвин Андресен написал пример использования транзакций с мультиподписью 2 из 3.пример, очень подробно, я не буду его перемещать.
Часть II: Виртуальная машина Ethereum
Парадигма блокчейна
Гэвин Вуд вжелтая бумагаСистема блокчейна абстрагируется в конечный автомат на основе транзакций:
В формуле (1) S — множество состояний внутри системы, f — функция перехода состояния транзакции, T — информация о транзакции, начальное состояние — состояние Gensis; В формуле (2) F представляет собой функцию перехода состояния на уровне блока, а B представляет собой информацию о блоке; Формула (3) определяет B как серию блоков транзакций, и каждый блок включает несколько транзакций; Формула (4) G — это функция финализации блока, которая включает в себя проверку дяди-блока, вознаграждение майнерам, проверку POW и т. д. в Ethereum.
Эта математическая модель лежит в основе не только Ethereum, но и большинства современных систем децентрализованных транзакций, основанных на консенсусе. Улучшение Эфириума по сравнению с Биткойном отражено в сути этой парадигмы.fиS. Его основная идея — блокчейн с полным по Тьюрингу и неограниченным внутренним пространством для хранения транзакций. Соответствует:
Мощная функция f, способная выполнять любые вычисления, биткойн не поддерживает цикл;
Состояние S записывает данные любого типа (включая код), в то время как модель UTXO Биткойна может рассчитать только расходуемую сумму адреса.
структура данных
Что касается хранения данных, Биткойн вычисляет баланс адресов с помощью модели UTXO и не поощряет пользователей вносить другие данные; с помощью механизма сценариев P2SH теоретически могут быть разработаны различные смарт-контракты, но они ограничены выразительными возможностями языка сценариев. , сложно поддерживать разработку сложных контрактов. Этот дизайн имеет смысл для криптовалют.
Чтобы поддерживать запись произвольной информации и выполнение произвольных функций, Ethereum необходимо перепроектировать структуру данных.
Merkle Patricia Trie
Merkle Patricia Trie активно используется в Ethereum для организации и хранения данных.Как мы увидим ниже, эта новая структура данных достигает своей цели благодаря комбинированным инновациям дерева хэшей и дерева префиксов. Соглашение: MPT используется ниже вместо Merkle Patricia Trie.
Merkle Tree
Также известен как хэш-дерево: каждый листовой узел дерева является хэш-значением определенного блока данных, а каждый нелистовой узел является хэш-значением дочернего узла. Как показано, это дерево не хранит сами блоки данных. В сетевой среде P2P, если злонамеренный сетевой узел изменит данные в этом дереве, он не пройдет проверку Меркла, тем самым обеспечив целостность и достоверность данных. Это зависит от характера одностороннего хэш-шифрования. Это свойство делает его широко используемым при проверке данных распределенных систем, таких как IPFS, Git и т. д.
Сатоши Накамото также умело использовал это свойство для разработки функции Биткойн SPV (упрощенная проверка платежей). Как показано на рисунке ниже, пользователю не нужно запускать полный узел, а нужно только загрузить данные заголовка блока самой длинной цепочки, а затем получить дерево меркле блока, соответствующего проверяемой транзакции, для проверки. .
Patricia Trie
он жеRadix Trie,Дапрефиксное деревоОптимизированный по пространству вариант: если узел в дереве является единственным дочерним элементом своего родителя, то два узла можно объединить. Его применение здесь — сопоставление длинных целочисленных данных, которые сопоставляются с 20-байтовым адресом Ethereum с его учетной записью в форме
, Address будет зашифрован и закодирован в шестнадцатеричные числа — в Patricia Trie, которая представлена как путь, соединенный нелистовыми узлами.
Например, сохраните на Patricia Trie, "собака" будет закодирована как "64 6f 67", если корневой узел будет найден первым, маршрут запроса будет root->6->4- >6- >15->6->7->значение, значение представляет собой хэш, указывающий на "Snoopy". Преимущество этого метода по сравнению с хеш-таблицей в том, что не будет конфликтов, но если не проводить оптимизацию, шаг запроса будет слишком длинным.
точка улучшения
Для повышения эффективности Эфириум специально разработал тип данных узла в дереве.дизайн. Включая следующие четыре типа узлов
Нулевой узел представляет собой пустую строку
узел ветвления Нелистовой узел с 17 элементами в виде
конечный узел Конечный узел из 2 элементов в форме , encodedPath является частью строки длинного целого числа после шифрования и кодирования адреса.
Узел расширения является нелистовым узлом с 2 элементами в форме Функция расширения состоит в объединении узлов на пути без разветвлений для экономии ресурсов пространства.Как показано на рисунке, это упрощенное дерево состояний (дерево состояний будет подробно объяснено позже, и здесь не помешает схематическая диаграмма), а правый верхний угол — это отображение . Функция элемента префикса заключается в содействии кодированию и может быть проигнорирована. Адреса 4 аккаунтов, организованные по MPT. Все узлы расширения предназначены только для оптимизации и могут быть заменены несколькими узлами ответвления.
Для использования MPT требуется внутренняя база данных (levelDB используется в Ethereum) для поддержания связи между каждым узлом Эта база данных называется базой данных состояний. К преимуществам использования MPT относятся: (1) Корневой узел этой структуры зашифрован и зависит от всех внутренних данных, а его хэш можно использовать для проверки безопасности Это природа дерева Меркла, но он не хранит Различие между самим блоком данных состоит в том, что узел дерева MPT хранит адресные данные, которые являются свойством дерева Патрисии (2) и допускают любое предыдущее состояние (при условии, что корневой хеш известен) простым изменением корневое хэш-значение.
государство
Концепция дерева состояний была введена выше при объяснении MPT. Концепция состояния мира в Ethereum, в которой хранится любое состояние, записанное децентрализованной системой транзакций посредством отображения MPT. Это соответствует букве S в парадигме блокчейна и является основной концепцией в дизайне Ethereum.
Как показано на рисунке, в упрощенном блоке есть три корневых хэша, соответствующих трем MPT. Корень состояния — это корневой хэш дерева состояний, который представляет собой адрес (160 бит) к данным учетной записи (учетная запись, сериализованная и хранящаяся в levelDB). Каждая действующая транзакция будет вызывать изменение состояния.Например,на рисунке просто видно,что баланс Аккаунта175 изменился с 27 на 45,а на всех остальных счетах нет транзакций.Тогда блок175224 нужно только создать новые данные на соответствующих ветках Аккаунта175 , а другие ветки копировать не надо! Конечно, количество транзакций, содержащихся в новых блоках в сети Ethereum, варьируется от десятков до сотен, поэтому модификаций будет больше. Для обсуждения этой структурной производительности, обратитесь к этой статьестатья.Запись для запроса последнего состояния учетной записи должна быть деревом состояний последнего подтвержденного блока.
Модель учетной записи Ethereum нуждается в особом представлении.
Account
Биткойн использует модель UTXO для расчета балансов, которая не может удовлетворить потребности в записи произвольных состояний. Эфириум разработал модель учетной записи, которая будет хранить:
[nonce, balance, storageRoot, codeHash] где nonce — счетчик транзакций, balance — информация о балансе,storageRoot соответствует другому MPT, через который переменная информация контракта может быть получена в базе данных codeHash — значение хэш-кода, которое нельзя изменить после создания.
Есть два типа счетов
Внешние аккаунты Внешний аккаунт управляется приватным ключом, в соответствующей модели Account storageRoot и codeHash не существуют, то есть код не будет храниться и выполняться. Если есть только внешние аккаунты, то Эфириум может поддерживать только функцию перевода.
договорные счета Учетная запись контракта может быть создана путем инициирования транзакций из внешней учетной записи или другой учетной записи контракта. Когда учетная запись контракта получает вызов сообщения, она загружает код, выполняет соответствующую логику через EVM и меняет состояние внутреннего хранилища.
торговля
В модели UTXO транзакция по существу (через подписанные данные) разблокирует ввод и блокирует вывод. В модели Account транзакции делятся на два типа:
Создать контракт, создать новый контракт через код
Вызов сообщения, который может перевести деньги или активировать функцию контракта
Оба типа транзакций включают следующие поля:
[nonce,gasPrice,gasLimit,to,value,[v,r,s]]
nonce: количество транзакций, отправленных аккаунтом
gasPrice, gasLimit: используется для ограничения времени выполнения транзакции и предотвращения бесконечного цикла программы.
кому: получатель транзакции
value: сумма перевода, при создании контракта это сумма, пожертвованная контракту
v,r,s: данные, относящиеся к подписи транзакции, которые можно использовать для определения отправителя транзакции.
Для создания контракта также требуется:
init: код EVM, представленный массивом байтов неограниченного размера, который запускается только один раз при создании контракта; после выполнения init возвращается фрагмент основного кода, а последующие вызовы контракта будут запускать содержимое основного кода.Адрес учетной записи контракта определяется отправителем и одноразовым номером, поэтому успех развертывания любого контракта в результате двух адресов различен. Как видно из рисунка, код магазина и состояние разделены. На самом деле ПЗУ виртуальное, а память не может быть изменена, скомпилированный байт-код.
Вызов сообщения также требует:
data: массив байтов неограниченного размера, представляющий ввод при вызове сообщенияВызов сообщения изменит состояние учетной записи, которая может быть учетной записью EOA или учетной записью контракта.
Транзакции могут быть инициированы либо внешними счетами, либо контрактами. НапримерБлок 5228886Содержит 170 транзакций и 7 внутренних контрактных транзакций.
блокировать
Блок Эфириума добавляет больше элементов данных, что намного сложнее, чем Биткойн, но на самом деле разница по сути невелика. Например, хэш uncle chain добавляется для оптимизации мер поощрения, то есть для поддержки протокола майнинга; сам блок также будет иметь много проверок валидности и сериализации. Это содержание выходит за рамки данной статьи и не будет подробно обсуждаться.
Взгляните на правую половину рисунка выше, чтобы увидеть, как блоки Эфириума организуют данные, и вы можете увидеть интенсивное использование деревьев MPT; левая половина включает EVM, которому будет уделено следующее внимание.
Проектирование и реализация EVM
Виртуальная машина Ethereum — это среда выполнения для выполнения функции передачи состояния Ethereum.
Возникает простой вопрос, может ли Ethereum специально не разрабатывать низкоуровневую ВМ, а переиспользовать Java, Lisp, Lua и т.д.? Теоретически вполне возможно,CordaПроект полностью разработан на платформе JVM. Но все больше блокчейн-проектов будут развивать базовую инфраструктуру, включая скриптовый движок Биткойн. Официальное объяснение, данное Ethereum:
Спецификация виртуальной машины Ethereum проще, в то время как другие виртуальные машины общего назначения имеют много ненужной сложности.
Разрешить индивидуальную разработку, например 32-байтовые слова
Избегайте проблем с внешними зависимостями, вызванных другими виртуальными машинами, которые могут вызвать трудности при установке.
Использование других виртуальных машин требует полной проверки безопасности, что не обязательно может сэкономить много работы.
модель памяти
EVM также основана на компьютерной модели стека, но в дополнение к стеку она также включает память и хранилище:
Размер элементов на стековом стеке 32 байта, что отличается от обычных 4 байт и 8 байт, в основном направлен на адрес объекта операции Ethereum и криптографическую переменную 32 байта, размер стека не превышает 1024 ; глубина вызова стека не превышает 1024, в основном для предотвращения переполнения памяти.
память Хотя операции выполняются в стеке, временные переменные могут храниться в памяти, и размер памяти не ограничен
Переменные состояния хранилища помещаются в хранилище, в отличие от стека и памяти, которые исчезают при уничтожении экземпляра EVM, данные в хранилище сохранятся после модификации.Как показано на рисунке, это схематическая диаграмма архитектуры EVM, которая оказывает глубокое влияние на разработку приложений Ethereum, включая шаблоны проектирования и соображения безопасности.Классическая проблема — апгрейд контрактов: После развертывания контракта он компилируется в байт-код и хранится в виртуальном ПЗУ, код нельзя изменить, что является серьезным ограничением для многих DAPP. Одна из идей состоит в том, чтобы распределить код по разным контрактам и вызывать между контрактами через адреса, хранящиеся в хранилище, таким образом реализуя фактическую операцию обновления контракта.
модель исполнения
EVM — это именно квази-Тьюринговская машина, которая может грамматически выполнять произвольные операции, но чтобы предотвратить злоупотребление сетью и избежать проблем с безопасностью, вызванных целостностью Тьюринга, все операции в Эфириуме ограничены экономикой, то есть газовым механизмом, существуют три случая:
Общие эксплуатационные затраты на потребление, такие как SLOAD, SSTORE и т. д.
Вызов подсообщения или создание контракта потребляет газ, который является частью стоимости выполнения CREATE, CALL, CALLCODE.
Стоимость использования памяти пропорциональна количеству требуемых слов по 32 байта.
На следующем рисунке показан внутренний процесс выполнения EVM Инструкции извлекаются из кода EVM Все операции выполняются в стеке Память хранится как временная переменная, а хранилище — это состояние учетной записи. Исполнение ограничено наличием газа.
Теперь, вместе с EVM, давайте взглянем на детали выполнения ранее введенных транзакций. Как определено парадигмой блокчейна, T — это функция перехода между состояниями Эфириума и самая сложная часть Эфириума. Перед выполнением всех транзакций им необходимо пройти внутреннюю проверку валидности:
Транзакция представляет собой данные в формате RLP без дополнительных суффиксных байтов;
Подпись транзакции действительна;
Случайный номер транзакции действителен;
Верхний предел топлива не меньше топлива, использованного в фактической сделке;
Баланс счета отправителя как минимум больше, чем комиссия v0, которую необходимо оплатить заранее;
На следующем рисунке показан процесс вызова сообщения.Каждая транзакция может формировать глубокий стек вызовов, и транзакция вызывается внутри разными контрактами. Вызов осуществляется через инструкцию CALL, а параметры и возвращаемые значения передаются через память.
обработка ошибок
Когда EVM выполняет контракт, возникает несколько ошибок:
малый запас топлива
неверная инструкция
Отсутствуют данные стека
Недопустимый целевой адрес для инструкции JUMP JUMPI
Новый размер стека больше 1024
Глубина вызова стека превышает 1024
Существует простой принцип обработки ошибок EVM, называемый revert-state-and-consume-all-gas, то есть состояние восстанавливается до контрольной точки до выполнения транзакции, но потребленный газ не возвращается. Виртуальная машина рассматривает ошибки как ошибки кода и не обрабатывает конкретные ошибки.
EVM-подобная полная виртуальная машина Тьюринга (WIP)
Полная спецификация EVM очень сложна, но при наличии определенной основы сборки и возможности упростить модель реализация виртуальной машины, подобной EVM, является сложной задачей, которую можно попробовать. Я опубликую свою реализацию, когда у меня будет время. Заинтересованные студенты могут попробовать сами.