Как работает Эфириум (завершение обзора): учетные записи и смарт контракты
Действительная транзакция nonce. Напомним, что nonce учетной записи - это количество транзакций, отправленных с этой учетной записи. Чтобы быть действительным, транзакция nonce должна быть равна nonce.
Газовый предел транзакции должен быть равен или больше, чем собственный газ, используемый транзакцией. Внутренний газ включает:
- предопределенная стоимость 21 000 газа для выполнения транзакции
- плата за газ для данных, отправленных с транзакцией (4 газа для каждого байта данных или кода, который равен нулю, и 68 газов для каждого ненулевого байта данных или кода)
- если сделка является сделкой по созданию контракта, дополнительно 32 000 газа
В балансе счета отправителя должно быть достаточно эфира для покрытия «авансовых» расходов на газ, которые отправитель должен заплатить. Расчет для первоначальной стоимости газа прост: во-первых, предел газа на транзакцию умножается на цену сделки для определения максимальной стоимости газа. Затем эта максимальная стоимость добавляется к общей величине, передаваемой от отправителя получателю.
)
Если транзакция соответствует всем вышеперечисленным требованиям для действительности, мы переходим к следующему шагу.
Во-первых, мы вычитаем первоначальную стоимость исполнения из баланса отправителя и увеличиваем счет nonce учетной записи отправителя на 1 для учета текущей транзакции. На этом этапе мы можем рассчитать оставшийся газ как общий предел газа для транзакции за вычетом используемого собственного газа.
)
Затем начинается выполнение транзакции. На протяжении всего транзакции Ethereum отслеживает «подстанцию». Это подстанция - это способ записи информации, набранной во время транзакции, которая будет необходима сразу после завершения транзакции. В частности, он содержит:
- Набор саморазрушения: набор учетных записей (если есть), которые будут отброшены после завершения транзакции.
- Серию журналов: архивированные и индексируемые контрольные точки выполнения кода виртуальной машины.
- Баланс возврата: сумма, подлежащая возврату на счет отправителя после транзакции. Помните, как мы упоминали, что хранение в Ethereum стоит денег, и что отправитель возвращается для очистки хранилища? Ethereum отслеживает это с помощью счетчика возврата. Счетчик возврата начинается с нуля и увеличивается каждый раз, когда контракт удаляет что-то в хранилище.
Затем обрабатываются различные вычисления, требуемые транзакцией.
После того, как все шаги, необходимые для транзакции, будут обработаны, и если предполагается, что нет недопустимого состояния, состояние завершается путем определения количества неиспользованного газа, подлежащего возврату отправителю. В дополнение к неиспользованному газу отправитель также возмещает часть пособий из «баланса возврата», который мы описали выше. После возврата отправителя:
- эфир для газа подается майнеру
- газ, используемый транзакцией, добавляется к счетчику газовых газов (который отслеживает общий газ, используемый всеми транзакциями в блоке, и полезен при проверке блока)
- все учетные записи в наборе самоуничтожения (если таковые имеются) удаляются
- Наконец, у нас осталось новое состояние и набор журналов, созданных транзакцией.
Теперь, когда мы рассмотрели основы выполнения транзакции, давайте рассмотрим некоторые различия между транзакциями, создающими контракты, и вызовами сообщений.
Создание контракта
Напомним, что в Эфириум существует два типа счетов: учетные записи договоров и внешние счета. Когда мы говорим, что транзакция «создает контракты», мы подразумеваем, что целью транзакции является создание новой учетной записи контракта.
Чтобы создать новую контрактную учетную запись, мы сначала объявляем адрес новой учетной записи, используя специальную формулу. Затем мы инициализируем новую учетную запись:
Установка нуля в ноль
Если отправитель отправил некоторое количество эфира в качестве значения с транзакцией, установив баланс счета на это значение. Вычитая добавленную стоимость на баланс новой учетной записи с баланса отправителя
- Установка хранилища как пустая
- Установка кода контракта Хэш как хэш пустой строки
После инициализации учетной записи мы можем создать учетну запись, используя код инициализации, отправленный с транзакцией (см. Раздел «Транзакция и сообщения» для обновления кода инициализации). То, что происходит во время выполнения этого кода инициализации, варьируется. В зависимости от конструктора контракта он может обновлять хранилище учетной записи, создавать другие учетные записи, делать другие вызовы и т. д.
Поскольку код для инициализации контракта выполняется, он использует газ. Транзакции не разрешено использовать больше газа, чем оставшийся газ. Если это произойдет, выполнение приведет к исключению из-за газа (OOG) и выходу. Если транзакция завершается из-за исключения, то состояние возвращается к точке непосредственно перед транзакцией. Отправитель не возвращает газ, который был израсходован до истечения срока.
Boo hoo.
Однако, если отправитель отправил какое-либо значение Ether с транзакцией, значение Ether будет возвращено, даже если создание контракта завершится с ошибкой.
Если код инициализации выполняется успешно, оплачивается окончательная стоимость создания договора. Это стоимость хранения и пропорциональна размеру кода созданного контракта (опять же, без бесплатного обеда!) Если запаса газа недостаточно, чтобы оплатить эту окончательную стоимость, тогда сделка снова объявит исключение вне газа и прекращается.
Если все будет хорошо, и мы сделаем это без исключения, то оставшийся неиспользованный газ будет возвращен первоначальному отправителю транзакции, и теперь измененное состояние будет сохранено!
Вызов сообщений
Выполнение вызова сообщения аналогично исполнению контракта с несколькими отличиями. Выполнение вызова сообщения не содержит кода инициализации, поскольку новые учетные записи не создаются. Однако он может содержать входные данные, если эти данные были предоставлены отправителем транзакции. После выполнения вызовов сообщений также есть дополнительный компонент, содержащий выходные данные, который используется, если последующему исполнению нужны эти данные.
Как и при создании контракта, если выполнение вызова сообщения завершается из-за нехватки газа или из-за того, что транзакция недействительна (например, переполнение стека, неверное назначение перехода или неверная инструкция), ни один из используемых газов не возвращается первоначальному абоненту, Вместо этого весь оставшийся неиспользованный газ потребляется, и состояние сбрасывается до точки непосредственно перед передачей баланса.
До самого последнего обновления Эфириум не было возможности остановить или отменить выполнение транзакции, не имея в виду, что система потребляет весь газ, который вы предоставили. Например, предположим, что вы создали контракт, который сделал ошибку, когда вызывающему абоненту не было разрешено выполнять какую-либо транзакцию. В предыдущих версиях Эфириум оставшийся газ все равно будет потребляться, и никакой газ не будет возвращен отправителю. Но обновление Byzantium включает в себя новый «обратный» код, который позволяет контракту прекратить выполнение и вернуть изменения состояния, не потребляя оставшийся газ, и с возможностью вернуть причину неудачной транзакции. Если транзакция завершается из-за возврата, то неиспользованный газ возвращается отправителю.
Модель исполнения
До сих пор мы узнали о серии шагов, которые должны произойти для транзакции, выполняемой от начала до конца. Теперь мы рассмотрим, как транзакция фактически выполняется внутри виртуальной машины.
Часть протокола, который фактически обрабатывает транзакции, является собственной виртуальной машиной Эфириум, известной как виртуальная машина Эфириум (EVM).
EVM - полная виртуальная машина Turing, как было определено ранее. Единственное ограничение, которое имеет EVM, заключается в том, что типичная полная машина Turing не заключается в том, что EVM неразрывно связан газом. Таким образом, общая сумма вычислений, которая может быть выполнена, по существу ограничена количеством предоставленного газа.
)
Более того, EVM имеет стек-архитектуру. Стоп-компьютер - это компьютер, в котором используется последний, первый-стоп-файл для хранения временных значений.
Размер каждого элемента стека в EVM составляет 256 бит, а стек имеет максимальный размер 1024.
EVM имеет память, где элементы хранятся в виде массивов байтов с обращением к словам. Память нестабильна, то есть она не является постоянной.
)
EVM также имеет свой собственный язык: «EVM bytecode». Когда программист, как вы или я, пишете смарт-контракты, которые работают на Ethereum, мы обычно пишем код на более высоком уровне, таком как Solidity. Затем мы можем скомпилировать этот байт-код EVM, который EVM может понять.
Перед выполнением определенного вычисления процессор гарантирует, что следующая информация будет доступна и действительна:
- Состояние системы
- Оставшийся газ для расчета
- Адрес учетной записи, которой принадлежит исполняемый код
- Адрес отправителя транзакции, инициировавшей это исполнение
- Адрес учетной записи, которая вызвала выполнение кода (может отличаться от исходного отправителя)
- Цена газа на транзакцию, которая инициировала это исполнение
- Входные данные для этого выполнения
- Значение (в Вэй) передано этому счету как часть текущего исполнения
- Машинный код, который должен быть выполнен
- Заголовок блока текущего блока
- Глубина текущего вызова сообщения или стека создания контракта
В начале выполнения память и стек пустые, а счетчик программ равен нулю.
PC: 0 STACK: [] MEM: [], STORAGE: {}
Затем EVM выполняет транзакцию рекурсивно, вычисляя состояние системы и состояние машины для каждого цикла. Состояние системы - просто глобальное состояние Ethereum. Состояние машины состоит из:- доступный газ
- счетчик команд
- содержимое памяти
- активное количество слов в памяти
- содержимое стека.
Элементы стека добавляются или удаляются из самой левой части серии. В каждом цикле соответствующее количество газа уменьшается от оставшегося газа, а счетчик программ увеличивается.
В конце каждого цикла есть три возможности:- Машина достигает исключительного состояния (например, недостаточный газ, недействительные инструкции, недостаточные элементы стека, элементы стека превышают 1024, недействительный пункт JUMP / JUMPI и т. Д.), И поэтому их необходимо остановить, при этом любые изменения будут отменены
- Последовательность продолжает обрабатываться в следующем цикле
- Машина достигает контролируемой остановки (конец процесса выполнения)
Предполагая, что выполнение не достигло исключительного состояния и достигло «контролируемой» или нормальной остановки, машина генерирует результирующее состояние, оставшийся газ после этого выполнения, начисленное подзадачу и результат.
Мы прошли через одну из самых сложных частей Эфириума. Даже если вы не полностью понимаете эту часть, все в порядке. Вам действительно не нужно разбираться в деталях детализации детализации, если вы не работаете на очень глубоком уровне.
Как блок завершается
Наконец, давайте посмотрим, как будет завершен блок многи транзакций.
Когда мы говорим «финализировано», это может означать две разные вещи, в зависимости от того, является ли блок новым или существующим. Если это новый блок, мы имеем в виду процесс, необходимый для разработки этого блока. Если это уже существующий блок, мы говорим о процессе проверки блока. В любом случае для блока, который должен быть «финализирован», требуется четыре требования:- Подтвердить (или, если добывать, определить) ommers. Каждый блок ommer в заголовке блока должен быть допустимым заголовком и находиться в шестом поколении настоящего блока.
- Проверять (или, если добывать, определять) транзакции. Номер GasUsed на блоке должен быть равен кумулятивному газу, используемому транзакциями, перечисленными в блоке. (Напомним, что при выполнении транзакции мы отслеживаем счетчик газа блока, который отслеживает общий газ, используемый всеми транзакциями в блоке).
- Примените награды (только в случае добычи) Адрес получателя получает 5 эфиров за добычу блока. (В предложении Эфириума EIP-649 это вознаграждение в размере 5 ETH скоро будет уменьшено до 3 ETH). Кроме того, для каждого омпера бенефициару текущего блока присуждается дополнительно 1/32 от текущего вознаграждения в блоке. Наконец, бенефициар блока (ов) ommer также получает определенную сумму (есть специальная формула для того, как это рассчитывается).
- Проверьте (или, если вы хотите, выведите правильное состояние) и nonce. Убедитесь, что все транзакции и результирующие изменения состояния применяются, а затем определяют новый блок как состояние после того, как вознаграждение блока было применено к результирующему состоянию последней транзакции. Проверка происходит путем проверки этого конечного состояния на состояние, хранящееся в заголовке.
Доказательство работы
Раздел «Блоки» кратко остановился на концепции сложности блоков. Алгоритм, который дает смысл блокировать трудности, называется Доказательством работы (PoW).
Алгоритм доказательства работы Эфириума называется «Ethash» (ранее известный как Dagger-Hashimoto). Алгоритм формально определяется как:
)
где m - mixHash, n - nonce, Hn - заголовок нового блока (исключая компоненты nonce и mixHash, которые должны быть вычислены), Hn - это nonce заголовка блока, а d - DAG, что является большой набор данных.
В разделе «Блоки» мы говорили о различных элементах, которые существуют в заголовке блока. Два из этих компонентов назывались mixHash и nonce. Как вы помните:- mixHash - это хеш, который в сочетании с nonce доказывает, что этот блок выполнил достаточное вычисление
- nonce - хэш, который в сочетании с mixHash доказывает, что этот блок выполнил достаточные вычисления
- Функция PoW используется для оценки этих двух элементов.
Как точно вычисляются mixHash и nonce с использованием функции PoW, является несколько сложной, и мы можем углубиться в отдельную запись. Но на высоком уровне он работает следующим образом:
Для каждого блока рассчитывается «семя». Это семя отличается для каждой «эпохи», где каждая эпоха составляет 30 000 блоков. Для первой эпохи семена являются хешем из серии из 32 байтов нулей. Для каждой последующей эпохи это хэш предыдущего хеша. Используя это семя, узел может вычислить псевдослучайный «кеш».
Этот кеш невероятно полезен, поскольку он позволяет использовать концепцию «легких узлов», о которой мы говорили ранее в этом сообщении. Целью легких узлов является предоставление некоторым узлам возможности эффективно проверять транзакцию без бремени хранения всего набора данных блок-цепей. Световой узел может проверить достоверность транзакции, основанной исключительно на этом кеше, поскольку кеш может регенерировать конкретный блок, который необходимо проверить.
Используя кеш, узел может генерировать набор данных DAG, где каждый элемент в наборе данных зависит от небольшого количества элементов псевдослучайного выбора из кеша. Чтобы быть майнером, вы должны создать этот полный набор данных; все полные клиенты и майнеры хранят этот набор данных, а набор данных растет линейно с течением времени.
Майнеры могут затем взять случайные фрагменты набора данных и поместить их через математическую функцию, чтобы сместить их вместе в «mixHash». Майнер будет многократно генерировать mixHash, пока результат не окажется ниже желаемого целевого значения. Когда выход соответствует этому требованию, это nonce считается действительным и блок может быть добавлен в цепочку.
Добыча как механизм безопасности
В целом цель PoW заключается в том, чтобы криптографически безопасно доказать, что определенный объем вычислений был израсходован для генерации некоторого результата (т. Е. Nonce). Это потому, чт нет лучшего способа найти nonce, который ниже требуемого порога, кроме как перечислять все возможности. Выходы многократного применения хеш-функции имеют равномерное распределение, и поэтому мы можем быть уверены, что в среднем время, необходимое для нахождения такого nonce, зависит от порога сложности. Чем выше сложность, тем больше времени требуется для решения nonce. Таким образом, алгоритм PoW дает смысл концепции трудности, которая используется для обеспечения безопасности цепочки блоков.
Что мы подразумеваем под защитой blockchain? Это просто: мы хотим создать блок-цепочку, которой доверяет каждый. Как мы обсуждали ранее в этом сообщении, если существовало несколько цепочек, пользователи теряют доверие, потому что они не смогут разумно определить, какая цепь была «действительной» цепочкой. Чтобы группа пользователей принимала базовое состояние, которое хранится в блочной цепочке, нам нужна единственная каноническая блок-цепочка, в которую верит группа людей.
Это именно то, что делает алгоритм PoW: он гарантирует, что конкретная блок-цепочка останется канонической в будущем, что делает невероятно трудным для злоумышленника создание новых блоков, которые перезаписывают определенную часть истории (например, путем стирания транзакций или создания поддельных транзакций) или поддерживать вилку. Чтобы сначала проверить свой блок, злоумышленнику необходимо будет последовательно решать для nonce быстрее, чем кто-либо еще в сети, так что сеть считает, что их цепочка является самой тяжелой цепью (основанной на принципах протокола GHOST, о котором мы упоминали ранее). Это было бы невозможно, если у злоумышленника не было более половины мощности сети, сценарий, известный как 51% -ная атака
Добыча как механизм распределения богатства
Помимо обеспечения надежной блокировки, PoW также способ распределения богатства для тех, кто расходует свои вычисления для обеспечения этой безопасности. Напомним, что майнер получает вознаграждение за добычу блока, в том числе:
- статический блок вознаграждения в 5 эфиров за «выигрышный» блок (вскоре он будет изменен на 3 эфира)
- стоимость газа, расходуемого внутри блока, транзакциями, включенными в блок
- дополнительная награда за включение оммеров как часть блока
В целях обеспечения того, чтобы использование консенсусного механизма для обеспечения безопасности и богатства в рамках ПОР было устойчивым в долгосрочной перспективе, Эфириум стремится привить эти два свойства:
- Сделайте его доступным как можно большему числу людей. Другими словами, людям не нужно специализированное или необычное оборудование для запуска алгоритма. Цель этого заключается в том, чтобы сделать модель распределения богатства настолько открытой, насколько это возможно, чтобы каждый мог предоставить любую вычислительную мощность в обмен на Ether.
- Уменьшите возможность для любого отдельного узла (или небольшого набора) сделать непропорциональную сумму прибыли. Любой узел, который может сделать непропорциональную сумму прибыли, означает, что узел оказывает большое влияние на определение канонической блок-цепи. Это хлопотно, потому что это снижает безопасность сети.
В сети блочной сети Bitcoin одна проблема, возникающая в связи с указанными выше двумя свойствами, заключается в том, что алгоритм PoW является хэш-функцией SHA256. Слабость этого типа функции заключается в том, что ее можно решить гораздо более эффективно с помощью специализированного оборудования, также известного как ASIC.
Чтобы смягчить эту проблему, Эфириум решил сделать свой алгоритм PoW (Ethhash) последовательной памятью. Это означает, что алгоритм сконструирован таким образом, что для вычисления nonce требуется много памяти и пропускной способности. Большие требования к памяти затрудняют использование компьютером параллельной памяти для одновременного обнаружения нескольких несов, а высокие требования к пропускной способности затрудняют одновременное обнаружение нескольких нечетких компьютеров. Это снижает риск централизации и создает более ровное игровое поле для узлов, которые выполняютпроверку.
Следует отметить, что Эфириум переходит от консенсусного механизма PoW к тому, что называется «доказательством». Действительно нужно много времени, чтобы переварить эту инструкцию. Если вам потребуется многократное чтение, чтобы полностью понять, что происходит, все в порядке. Это нормально много раз прочитать желтую книгу Эфириума, и различные части кода, прежде чем понять и собрать вместе то, что происходит. Тем не менее, надеюсь, вы нашли этот обзор полезным.
Публикация адаптирована на русский по материалам Preethi Kasireddy. Огромное спасибо за такой подробный обзор. Команда ICO CryoGen под управлением компании «КриоРус» планирует пригласить Preethi Kasireddy для участия в своем проекте, объединяющим две инновационные технологии крионику и блокчейн.