Глава 7. Азы Эфириума

Эфириум был сформулирован в виде понятия Виталиком Бутериным в ноябре 2013. Ключевая предложенная идея состояла в создании полного Тюринг языка, который позволит разрабатывать произвольные программы (адаптивные контракты, smart contracts) для блокчейна и децентрализованных приложений. Именно это сильно отличает его от биткойна, в случае которого язык сценария очень ограничен и допускает только базовые и необходимые операции.

С применением различных языков были разработаны разнообразные клиенты Эфириум, но в настоящее время наиболее популярными являются go-Ethereum и parity. go-Ethereum был разработан с использованием Golang, в то время как parity был построен с применением Rust. Также имеются доступными и прочие клиенты, однако, как правило, клиента go-Ethereum, также именуемого как geth достаточно для любых целей. Mist является дружественным к пользователю кошельком GUI (wallet Graphical User Interface - бумажником с Графическим интерфейсом пользователя), который исполняет geth в фоновом режиме для синхронизации с необходимой сетевой средой. Дополнительные подробности этого предоставляются позднее в данной главе, в разделах установки и майнинга.

Самый первый выпуск Эфириума имел название Frontier (Рубеж), а текущий выпуск Эфириум именуется как homestead (ферма). Выходящая далее версия имеет название metropolis (столица) и она сосредоточена на упрощении протокола и улучшении производительности. Окончательный выпуск имеет название serenity (безмятежность), что рисует в воображении наличие в нём реализации алгоритма Подтверждения Вехи (Proof of Stake, Casper). Прочие области исследований, имеющие целью serenity содержат масштабируемость, приватность и обновление EVM (Ethereum virtual machine, Виртуальной машины Эфириум). Поскольку это всё непрерывные усилия по разработке и экосистема Эфириум будет продолжать постоянные улучшения и наработки, serenity не следует рассматривать как окончательную версию, а всего лишь как придорожный указатель на дальней дистанции продолжающегося улучшения. Обдумываются и последующие выпуски, однако они пока не имеют названий. Уже была предложена версия web 3.0 и она обсуждается в сообществе. Web 3.0 является концепцией, которая в основном предлагает семантику и интеллектуальный веб как некое развитие имеющейся технологии web 2.0. Именно так видится некая экосистема, в которой люди, приложения, данные и веб все соединены воедино и способны взаимодействовать друг с другом интеллектуальным образом. По мере наступления технологии блокчейн, всплывает также некая идея децентрализации, что на самом деле было первоначальным представлением самого Интернета. Ключевая мысль состоит в том, что все основные службы, такие как DNS, механизмы поиска и идентификация в Интернете будут децентрализованными в web 3.0. Именно тут Эфириум представляется как некая платформа, которая способна помочь реализовать такое видение.

Стек Эфириум состоит из разнообразных компонентов. В самой сердцевине имеется блокчейн Эфириум, исполняемый в P2P {Прим. пер.: одноранговой, Peer-to-Peer} сетевой среде Эфириум, из которой выгружается блокчейн и сохраняется локально. Это предоставляет различные функциональности, такие как майнинг и управление учётными записями. Данная локальная копия блокчейна регулярно синхронизируется через имеющуюся сетевую среду. Другим компонентом является библиотека web3.js, которая делает возможным взаимодействие с geth через интерфейс RPC (Remote Procedure Call, Вызовов удалённых процедур).

Это можно отобразить для визуализации на следующей схеме:

Эфириум, также как и прочие блокчейны, может визуализироваться как основанная на транзакциях машина состояний. Именно это отмечается об Эфириуме в жёлтых страницах, написанных Dr. Gavin Wood. Основная мысль состоит в том, что порождающее (genesis) состояние преобразовывается в окончательное состояние путём инкрементального выполнения транзакций. Такое окончательное состояние затем принимается как абсолютно бесспорная версия данного состояния. На приводимой далее схеме отображается функция перехода состояния Эфириум, при которой исполнение некоторой транзакции имеет результатом какой- то переход состояния.

В нашем предыдущем примере инициируется некий переход 2 Эфиров из Address 4718bf7a в Address 741f7a2. Первоначальное состояние представляет само состояние до исполнения данной транзакции, а конечное состояние это то, что выглядит как трансвормированное. Это будет обсуждаться более подробно в данной главе, однако основная цель данного примера состоит во введении основной ключевой идеи перемещения состояний в Эфириуме.

В качестве поощрения майнеров Эфириум также награждает их своей естественной валютой с названием Эфир, имеющей сокращение ETH. После взлома DAO (описываемого позднее), было предложено жёсткое раздвоение для успокоения проблемы; поэтому в настоящее время имеется два блокчейна Эфириум: один классический (Claccic) и его валюта представляется как ETC, тогда как жёстко ответвлённой (Hard- forked) версией является ETH, который продолжает рост и на основе которой осуществляется активное развитие. Тем не менее, ETC имеет собственных последователей с обособленным сообществом, и именно это является дальнейшим развитием ETC, который является не ответвлённой, первоначальной версией Эфириума.

Начиная с самой последней версии homestead, из- за основных обновлений протокола, получилось жёсткое раздвоение. Данный протокол был обновлён на блоке с номером 1 150 000, что имело результатом миграцию с самой первой версии Эфириума, имеющей название Frontier (Рубеж), ко второй версии Эфириума с названием homestead (ферма).

Последняя непреднамеренная вилка произошла 24 ноября 2016, в 14:12:07 UTC было обусловлено ошибкой в механизме журналирования geth. Сетевое разветвление произошло на блоке с номером 2 686 351. Эта ошибка привела к тому, что geth не возвратил удаления пустых учётных записей в случае наличия исключения пустого out-of-gas. Это не было проблемой в paritet (другой популярный клиент Эфириума). Это означает, что начиная с блока 2 686 351 блокчейн Эфириум разделяется на два, причём первый работает с клиентами parity, а другой с geth. Данная проблема була решена с выпуском версии geth 1.5.3.

Другим ключевым понятием Эфириума является газ (gas) {Прим. пер.: более точным переводом является бензин, но ради созвучности мы будем придерживаться этой версии наименования}. Все транзакции в блокчейне Эфириум должны перекрывать те расходы на расчёты, которые они осуществляют. Стоимость покрывается чем-то, имеющим название газа или крипто- топлива, что является новым понятием, введённым Эфириумом. Этот газ выплачивается авансом в качестве вознаграждения. Это топливо потребляется при каждой операции. Всякая операция имеет предварительно определённое количество связанного с ним газа. Каждая транзакция определяет то количество газа, которое она желает потребить для своего выполнения. Если она расходует-весь- газ (out- of- gase) в то время, когда операция ещё не завершена, все выполнявшиеся данной транзакцией операции до данной точки откатываются назад. Если транзакция выполнена успешно, тогда весь оставшийся газ возвращается обратно организатору транзакции.

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

Механизм согласия в Эфириуме основан на протоколе GHOST, первоначально предложенном Zohar и Sompolinsky в декабре 2013. Те из вас, кого он интересует, могут изучить его более подробно в первоначальной статье http://eprint.iacr.org/2013/881.pdf.

Эфириум применяет более простую версию данного протокола, при которой та цепочка, которая имеет наиболее интенсивную вычислительную нагрузку, затраченную на её создание, идентифицируется как назначенная версия. Другим вариантом рассмотреть это - найти самую длинную цепочку, так как самая длинная цепочко должна была быть построена с потреблением достаточных усилий майнинга. GHOST (Greedy Heaviest Observed Subtree, Наиболее интенсивно обременённое наблюдаемое поддерево) впервые был введён как механизм, позволяющий облегчить проблемы, возникающие из- за быстрого времени генерации блоков, приводящей к потерявшим актуальность или осиротевшим блокам. При использовании GHOST потерявшие актуальность блоки добавляются в вычисления для определения самой длинной и самой загруженной цепочки блоков. Осиротевшие блоки в Эфириуме именуются Дядюшками (Uncles или Ommers).

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

Всемирное состояние в Эфириуме представляет глобальное состояние всего блокчейна Эфириум. В целом это соответствие между адресами Эфириум и состояниями учётных записей. Все адреса имеют длину 20 байт. Данное соответствие является структурой данных, которая упорядочивается при помощи RLP (Recursive Length Prefix, Рекурсивного префикса длины). RLP является специально разработанной схемой шифрования, которая применяется в Эфириуме для упорядочивания двоичных данных с целью их хранения и передачи в сетевой среде, а также сохранения определённого состояния в дереве Patricia. Эта функция RLP принимает некий элемент как входные данные, который может быть какой- то строкой, либо некий список элементов, а заетм продуцирует сырые байты данных, которые пригодны для хранения и обмена в сетевой среде. RLP не шифрует данные; вместо этого, его основной целью является кодирование структур.

Состояние учётной записи

Определённое состояние учётной записи состоит из четырёх полей: защитного слова (nonce), баланса (balance), корня хранения (storageroot) и хэшкода (codehash), которые описаны здесь подробнее.

Данное время

Это (Nonce) именно то значение, которое инкрементально увеличивается при каждой отправке какой- то транзакции с данного адреса. В случае учётных записей контракта, оно представляет определённое численное значение созданных данной учётной записью контрактов. Учётные записи контрактов являются одним из двух имеющихся в Эфириуме учётных записей; более подробно они будут объяснены позднее в э той главе.

Баланс

Данное значение представляет конкретное число Wei, которое является наименьшим элементом данной валюты (Эфира) в Эфириуме, удерживаемым данным адресом.

Корень хранения

Это поле представляет основной узел корня дерева Меркла Patrica, которое шифрует всё хранимое содержимое данной учётной записи.

Хэшкод

Это неизменяемое поле, которое содержит значение хэша данного кода адаптивного (smart) контракта, который связан с рассматриваемой учётной записью. Этот код активируется посредством вызова сообщения.

Всемирное состояние и его взаимосвязь с древом (trie) учётных записей, учётными записями и заголовком блока могут быть визуализированы приводимой далее схемой. Она отображает определённую структуру данных учётной записи в самой середине этой схемы, которая содержит некий хэш корня хранения, проистекающий из узла корня того древа хранения учётной записи, которое отображено слева. Эта структура данных учётной записи затем применяется в древе всемирного состояния, которое устанавливает соответствие между адресами и состояниями учётных записей. Окончательно, сам узел корня древа всемирного состоянияхэшируется с применением 256- битного алгоритма Keccak {Кечак, SHA-3} и составляет часть структуры данных этого заголовка блока, что отображается в правой стороне приводимой схемы как состояние хэша корня. {Прим. пер.: для Деревьев Patricia вводится понятие trie, упорядоченной древовидной (tree) структуры, применяемой для хранения наборов данных. Следуя англоязычному различию в написании trie и tree мы переносим его в свой русский перевод, обозначая разницу как древо (trie) и дерево (tree).}

Обычно древом учётных записей является дерево Merkle Patricia, используемое для кодирования самого хранимого содержимого некоторой учётной записи. Это содержимое сохраняется как соответствие между 256- битными хэшами Кечак 256- битных целочисленных ключей и зашифрованными RLP 256- битными целочисленными значениями.

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

Обе транзакции состоят из множество общих полей, которые мы описываем далее.

Nonce

Nonce (Данное время) является числом, которое последовательно увеличивается на единицу всякий раз, когда некая транзакция отсылается данным отправителем. Оно должно быть равным общему числу отосланных транзакций и применяется как уникальный идентификатор для конкретной транзакции. Некое значение Данного времени может применяться только один раз.

gasPrice

Поле gasPrice (цена газа) представляет общее число Wei необходимое чтобы произвести данную транзакцию.

gasLimit

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

To

Как это подразумевает его название, это поле To является значением, которое представляет сам адрес конкретного получателя данной транзакции.

Value

Value представляет общее число Wei, подлежащего передачи его получателю; в случае учётной записи контракта, оно представляет значение баланса, которое будет содержаться данный контракт.

Signature

Signature (подпись) состоит из трёх полей, а именно, v, r и s. Эти значения представляют цифровую подпись (R, S) и некую информацию, которая может применяться для восстановления значения общедоступного ключа (V). Помимо самой транзакции, из которой можно также определить конкретного отправителя этой транзакции. Данная подпись основана на схеме ECSDA и использует значения кривой SECP256k1. Теоретические основы криптографии эллиптических кривых обсуждались в Главе 3, Основы криптографии и техники. В этом разделе ECSDA будет представлена в том контексте, в котором она применяется в Эфириуме.

V является значением из одного байта, которое описывает значения размера и знака определённой точки эллиптической кривой и может быть равным 27 или 28. V применяется в контракте восстановления ECSDA как некий идентификатор восстановления. При использовании secp256k1, данный идентификатор восстановления ожидается раным либо 0, либо 1. В Эфириум, он смещён на 27. Дополнительные подробности по применяемой функции ECDSARECOVER будут предоставлены позднее в этой главе.

R имеет происхождение из вычисляемой на выбранной кривой точки. Во- первых, указывается некое случайное число, которое умножается на генерирующее значение данной кривой чтобы вычислить какую- то точку этой кривой. Частью координаты x данной точки является R. R кодируется как некая последовательность 32 байт. R должна быть больше 0, но меньше чем установленный предел secp256k1n (115792089237316195423570985008687907852837564279074904382605163141518161494337).

S вычисляется путём умножения R на значение частного ключа и добавляет го в значение хэша данного сообщения чтобы служить подписью и путём окончательного деления его на то случайное число, которое выбрано для вычилсения R. S также является последовательностью 32 байт. Совместно, R и S предоставляют необходимую подпись.

Для подписи некоторой транзакции применяется функция ECDSASIGN, которая берёт данное подлежащее подписыванию сообщение и значение частного ключа в качестве некоторого входного параметра и производит V, значение из одного байта; R, 32 байтовое значение; а также S, другое 32 байтовое значение. Данное уравнение выглядит следующим образом:

ECDSASIGN (Message, Private Key) = (V, R, S)
 	   

Init

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

Init также возвращает другой раздел кода с названием body, который удерживается и исполняется в ответ на вызовы сообщений, которые может получать данный контракт. Эти вызовы сообщений могут отправляться через какие- то транзакции или как исполнение внутреннего кода.

Data

Если рассматриваемая транзакция является каким- то вызовом сообщения, тогда такое поле Data применяется вместо Init, и оно представляет необходимые входные данные этого вызова сообщения. Оно также не ограничено в размере и организовано как массив байт.

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

Транзакции могут быть найдены либо в пулах транзакций, либо в блоках. Когда узел майнинга начинает свои операции определения блоков, он начинает с самых высокооплачиваемых транзакций в имеющемся пуле транзакций и исполняет их по одной. При достижении предела газа, либо когда больше не остаётся для обработки транзакций в рассматриваемом пуле транзакций, запускается сам майнинг. В этом процессе данный блок повторно хэшируется до тех пор, пока не обнаруживается правильный nonce который, после того как он хэширован совместно с данным блоком, приводит к результату, меньшему чем поставленная цель сложности. Раз данный блок успешно добыт (отмайнен) он будет немедленно широковещательно отправлен в имеющуюся сетевую среду. Данный процесс аналогичен процессу майнинга Биткойна, обсуждавшемуся в одной из предыдущих глав. Единственная разница состоит в том, что алгоритм Подтверждения Работы (Proof of Work) Эфириум является устойчивым к ASIC, имеющим название Ethash, при котором определение nonce требует большего объёма памяти.

Имеется ряд существенных параметров, которые необходимы при создании некоторой учётной записи. Вот эти параметры

Адреса, которые вырабатываются как некий результат транзакции создания контракта имеют 160 бит в длину. В точности так, как это определено в жёлтых страницах, они являются самыми правыми 160- битами хэша Кечак (Keccak) RLP- кодирования структуры, которая содержит только отправителя и Данное время (nonce). Первоначально, значения поля Данного времени в этой учётной записи установлено нулевым. Значение баланса данной учётной записи устанавливается в то значение, которое передано в контракт. Хранилище также устанавливается пустым. Хэш кодом является 256- битный хэш Кечак пустой строки.

Данная учётная запись устанавливается когда исполняется конкретный код EVM (код EVM инициализации). В случае любой исключительной ситуации на протяжении исполнения кода, например, в случае расходования газа, это состояние не изменяется. Если данное исполнение успешно, тогда эта учётная запись создаётся после оплаты соответствующей стоимости контракта. Текущая версия Эфириума (homestead) определяет что полученный результат транзакции контракта является либо новым контрактом с его балансом, либо никакого нового контракта не создаётся и не осуществляется обмен значением. Это отличается от предыдущих версий, в которых такой контракт может быть создан независимо от того, является ли развёртывание кода контракта успешным или нет из-за израсходования газа.

Для исполнения вызова сообщения необходимы некоторые параметры, которые перечислены ниже:

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

На приведённой далее схеме отображается различие между двумя типами транзакций:

В следующем разделе вам будет предложено введение в различные компоненты сетевой среды Эфириум и сам блокчейн. Вначале, в непосредственно идущем далее разделе задаются базовые понятия EVM.

EVM является простой машиной исполнения на основе стека, которая выполняет интрукции байтового кода для преобразования определённого состояния из одного в другое. Размер слова данной виртуальной машины установлен в 256- бит. Общий размер стека ограничен в 1024 элемента и основывается на очереди LIFO (Last in First Out, Последний пришёл - исполнен первым). EVM является полной машиной Тьюринга, однако она имеет ограничение по тому количеству газа, которое необходимо для исполнения всех инструкций. Это означает, что бесконечные циклы, которые могут иметь результатом атаки DoS (denial of service, отказа в обслуживании) не возможны из- за необходимости газа. EVM также поддерживает обработку исключительных ситуаций в случае их возникновения, например, недостаточности газа или неверной инструкции, при возникновении которых эта машина будет немедленно остановлена и возвращает определённую ошибку своему агенту исполнения.

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

Как уже обсуждалось ранее, EVM имеет основанную на стеке архитектуру. EVM является тупоконечной (big-endian) по своему строению и использует слова длиной в 256 бит. Такой размер слова делает возможными вычисления 256- битного хэша Кечак и и криптографии эллиптической кривой.

Иметются два вида хранения, доступные для контрактов и EVM. Первый называется памятью, которая является неким массивом байт. Когда некий контракт завершает исполнение данного кода, данная память очищается. Это повторяет понятие Оперативной памяти (RAM). Другой тип, называемый хранилищем, постоянно хранится в имеющемся блокчейне. Именно оно является местом содержания значения ключа.

Память не ограничена, однако ограничивается требованиями платежа газом. Имеющееся хранилище, связанное с определённой виртуальной машиной является адресуемым по словам массивом слов, который является энергонезависимым и сопровождается как часть присутствующего состояния системы. Ключи и значения имеют 32 байта размера и хранения. Сам код программы хранится в виртуальная ROM (virtual read-only memory, виртуальной памяти, доступной только для чтения), доступ к которой осуществляется по инструкции CODECOPY. Данная инструкция CODECOPY применяется для копирования самого кода программы в основную память. Изначально в конкретной EVM хранилище и память целиком установлены в нули.

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

Оптимизация EVM является активной областью исследований и маые последние исследования подсказывают, что EVM может быть оптимизирована и отрегулирована с очень высокой степенью чтобы достигать высокой производительности. Уже имеют ход исследования возможности использования WASM (Web assembly). WASM разработан Google, Mozilla и Microsoft и в настоящее время проектируется как некий открытый стандарт для группы сообщества W3C. Основная цель WASM состоит в исполнении машинного кода в самом браузере, что в результате приведёт к исполнению с естественной скоростью. Аналогично, основной целью EVM 2.0 является возможность исполнения всего набора инструкций EVM (Opcodes, кодов операций) естественным образом в ЦПУ, что делает их более быстрыми и более эффективными.

Среда исполнения

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

Вся среда исполнения может быть отображена как некий кортеж из девяти элементов следующим образом:

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

Машина состояний

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

Данная EVM спроектирована для обработки исключительных ситуаций и будет прервана (halt, остановит исполнение) в случае возникновения любой из следующих перечисленных исключительных ситуаций:

Функция итератор

Упомянутая ранее функция итератор осуществляет различные важные функции, которые используются для установки следующего состояния данной машины и, в конечном счёте, определённого Всемирного состояния (world state). Эти функции включают в себя:

Состояние машины можно рассматривать как некий кортеж, представленный следующей схемой:

Данная виртуальная машина способна также выполнять останов при обычных условиях если в процессе исполнения данного цикла встречается код операции STOP, или SUICIDE, или RETURN.

Написанный на языке верхнего уровня, таком как serpent, LLL или Solidity преобразуется в определённый понимаемый EVM код байт с целью его исполнения данной EVM. Solidity является тем языком высокого уровня, который был разработан Эфириумом с применением JavaScript такого как синтаксис для написания кода адаптивных контрактов (smart contract. После написания такого кода он компилируется в понимаемый EVM байтовый код при помощи компилятора Solidity, именуемого solc.

LLL (Lisp-like Low-level language, Лисп- подобный язык программирования нижнего уровня) является другим языком, который применяется для написания адаптивных контрактов. Serpent является Python- подобным языком высокго уровня, который может использоваться для написания адаптивных контрактов под Эфириум.

Например, простая программа на solidity выглядит следующим образом:

pragma solidity ^0.4.0;
contract Test1
  {
    uint x=2;
    function addition1(uint x) returns (uint y) {
      y=x+2;
    }
  }
 	   

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

Исполняемый байтовый код

606060405260e060020a6000350463989e17318114601c575b6000565b34600057602960043
5603b565b60408051918252519081900360200190f35b600281015b91905056
Opcodes PUSH1 0x60 PUSH1 0x40 MSTORE PUSH1 0x2 PUSH1 0x0 SSTORE CALLVALUE
PUSH1 0x0 JUMPI JUMPDEST PUSH1 0x45 DUP1 PUSH1 0x1A PUSH1 0x0 CODECOPY
PUSH1 0x0 RETURN PUSH1 0x60 PUSH1 0x40 MSTORE PUSH1 0xE0 PUSH1 0x2 EXP
PUSH1 0x0 CALLDATALOAD DIV PUSH4 0x989E1731 DUP2 EQ PUSH1 0x1C JUMPI
JUMPDEST PUSH1 0x0 JUMP JUMPDEST CALLVALUE PUSH1 0x0 JUMPI PUSH1 0x29 PUSH1
0x4 CALLDATALOAD PUSH1 0x3B JUMP JUMPDEST PUSH1 0x40 DUP1 MLOAD SWAP2 DUP3
MSTORE MLOAD SWAP1 DUP2 SWAP1 SUB PUSH1 0x20 ADD SWAP1 RETURN JUMPDEST
PUSH1 0x2 DUP2 ADD JUMPDEST SWAP2 SWAP1 POP JUMP
 	   

Коды операций и их значение

имеются различные коды операций (opcode), которые были введены в EVM. Коды операций подразделяются на множество категорий на основе выполняемых ими операций. Здесь мы представляем полный перечень кодов операций с их значениями и их использованием.

Арифметические операции

Вся арифметика в EVM выполняется по модулю 2²⁵⁶. Данная группа кодов операций применяется для выполнения основных арифметических операций. Значение этих операций стартует с 0x00 вплоть до 0x0b.

Таблица 7-1. Арифметические операции

Мнемоническое обозначение	Значе- ние	POP	PUSH	Газ	Описание
STOP	0x00	0	0	0	Останавливает исполнение
ADD	0x01	2	1	3	Складывает два значения
MUL	0x02	2	1	5	Умножает два значения
SUB	0x03	2	1	3	Операция вычитания
DIV	0x04	2	1	5	Операция целочисленного деления
SDIV	0x05	2	1	5	Операция целочисленного деления со знаком
MOD	0x06	2	1	5	Операция остатка по модулю
SMOD	0x07	2	1	5	Операция остатка по модулю со знаком
ADDMOD	0x08	3	1	8	Операция сложения по модулю
MULMOD	0x09	3	1	8	Операция умножения по модулю
EXP	0x0a	2	1	10	Операция экспоненты (повторяющееся умножение лежащего в основании числа)
SIGNEXTEND	0x0b	2	1	5	Операция двоичного сдвига (расширения длины двоичного дополнения) целого числа со знаком

Отметим, что операция STOP не является арифметической операцией, однако она подпадает в данный список арифметических операций из- за диапазона значения, в котором она находится (нулей).

Логические операции

Логические операции включают в свой состав операции, которые применяются для выполнения операций сравнений и Булевых логических операций. Значения этих операций лежат в диапазоне от0x10 до 0x1a.

Таблица 7-2. Логические операции

Мнемоническое обозначение	Значе- ние	POP	PUSH	Газ	Описание
LT	0x10	2	1	3	Меньше чем
GT	0x11	2	1	3	Больше чем
SLT	0x12	2	1	3	Сравнение меньше чем со знаком
SGT	0x13	2	1	3	Сравнение больше чем со знаком
EQ	0x14	2	1	3	Сравнение на равенство
ISZERO	0x15	1	1	3	Оператор отрицания
AND	0x16	2	1	3	Операция побитового И
OR	0x17	2	1	3	Операция побитового ИЛИ
XOR	0x18	2	1	3	Операция побитового исключающего ИЛИ (XOR)
NOT	0x19	1	1	3	Операция побитового Отрицания
BYTE	0x1a	2	1	3	Выборка отдельного байта из слова

Криптографические операции

В данной категории имеется только одна операция с названием SHA3. Следует отметить, что это не стандартная операция SHA3, стандартизованная NIST, а первоначальная реализация Кечак (Keccak)

Таблица 7-3. Криптографические операции

Мнемоническое обозначение	Значе- ние	POP	PUSH	Газ	Описание
SHA3	0x20	2	1	30	Применяется для вычисления 256- битного хэша Кечак

Информация окружения

В этой категории всего имеется 13 инструкций. Эти коды операций применяются для предоставления информации, связанной с операциями адресов, среды времени исполнения и копирования данных.

Таблица 7-4. Операции информации окружения

Мнемоническое обозначение	Значе- ние	POP	PUSH	Газ	Описание
ADDRESS	0x30	0	1	2	Применяется для получения определённого адреса исполняемого в настоящее время исполнения
BALANCE	0x31	1	1	20	Используется для получения баланса данной учётной записи
ORIGIN	0x32	0	1	2	Используется для получения конкретного адреса отправителя данной оригинальной транзакции
CALLER	0x33	0	1	2	Используется для получения конкретного адреса той учётной записи, которая инициировала данное исполнение
CALLVALUE	0x34	0	1	2	Выбирает то значение, которое депонировано данной инструкцией или транзакцией
CALLDATALOAD	0x35	1	1	3	Выбирает те входные данные, которые были переданы как параметр с этим вызовом сообщения
CALLDATASIZE	0x36	0	1	2	Применяется для выборки значения размера входных данных, которые были переданы как параметр с этим вызовом сообщения
CALLDATACOPY	0x37	3	0	3	Применяется для копирования входных данных переданных этим вызовом сообщения из текущей среды в имеющуюся память
CODESIZE	0x38	0	1	2	Осуществляет выборку значения размера исполняемого кода в текущей среде
CODECOPY	0x39	3	0	3	Копирует исполняемый код в имеющуюся память
GASPRICE	0x3a	0	1	2	Выполняет выборку стоимости газа, определённую данной инициированной транзакцией
EXTCODESIZE	0x3b	1	1	20	Получает значение размера кода, определённого данной учётной записью
EXTCODECOPY	0x3c	4	0	20	Применяется для копирования кода данной учётной записи в имеющуюся оперативную память

Информация блока

Этот набор инструкций относится к извлечению различных атрибутов, связанных с неким блоком:

Таблица 7-5. Операции информации блока

Мнемоническое обозначение	Значе- ние	POP	PUSH	Газ	Описание
BLOCKHASH	0x40	1	1	20	Получает значения хэша одного из 256 самых последних завершённых блоков
COINBASE	0x41	0	1	2	Выбирает определённый адрес набора бенефициаров в данном блоке
TIMESTAMP	0x42	0	1	2	Выбирает значение временного штампа в данном блоке
NUMBER	0x43	0	1	2	Получает номер данного блока
DIFFICULTY	0x44	0	1	2	Выбирает значение сложности данного блока
GASLIMIT	0x45	0	1	2	Получает предел значения газа данного блока

Операции стека, памяти, хранения и потока

Таблица 7-6. Операции стека, памяти, хранения и потока

Мнемоническое обозначение	Значе- ние	POP	PUSH	Газ	Описание
POP	0x50	1	0	2	Удаляет элементы из стека
MLOAD	0x51	1	1	3	Применяется для загрузки слова из имеющейся памяти
MSTORE	0x52	2	0	3	Применяется для сохранения слова в имеющуюся память
MSTORE8	0x53	2	0	3	Применяется для сохранения байта в имеющуюся память
SLOAD	0x54	1	1	50	Применяется для загрузки слова из имеющегося хранилища
MSTORE	0x55	2	0	0	Сохраняет слово в имеющееся хранилище
JUMP	0x56	1	0	8	Изменяет значение счётчика программы
JUMPI	0x57	2	0	10	Изменяет значение счётчика программы на основании некоторого условия
PC	0x58	0	1	2	Используется для выборки самого значения текущего счётчика программы перед его увеличением
MSIZE	0x59	0	1	2	Выбирает значение размера активной памяти в байтах
GAS	0x5a	0	1	2	Выбирает значение доступного газа
JUMPDEST	0x5b	0	0	1	Применяется для отметки разрешённого получателя для переходов без воздействия на текущее состояние машины в процессе этого исполнения

Операции активной доставки

Эти операции включают в свой состав операции PUSH, которые применяются для помещения элементов в имеющийся стек. Установленный для этих операций диапазон находится в пределах от 0x60 до 0x7f. Итого имеется доступными 32 операции PUSH в числе операций PUSH EVM, которые считывают данные из имеющегося массива байт данного кода программы.

Таблица 7-7. Операции активной доставки

Мнемоническое обозначение	Значе- ние	POP	PUSH	Газ	Описание
PUSH1 … PUSH32	0x60 … 0x7f	0	1	3	Применяется для помещения N выравненных справа тупоголовых (big-endian) байтовых элементов в имеющемся стеке. N является значением, которое находится в диапазоне от 1 байта до 32 байт (полное слово) на основании мнемонического применения.

Операции дублирования

Как и предполагает их название, операции дублирования применяются для дубирования элементов стека. Диапазон значений составляет от 0x80 до 0x8f. В EVM доступно 16 инструкций DUP. Элементы, помещаемые в имеющийся стек или удаляемые из этого стека также изменяются инкрементально в соответствии с их мнемоническим применением; например, DUP1 удаляет один элемент из имеющегося стека и помещает два элемента в этот стек, в то время как DUP16 удаляет 16 элементов из текущего стека и помещает в него 17 элементов.

Таблица 7-8. Операции дублирования

Мнемоническое обозначение	Значе- ние	POP	PUSH	Газ	Описание
DUP1 … DUP16	0x80 … 0x8f	X	Y	3	Применяется для дублирования N- го элемента стека, где N является тем номером, который соответствует данной используемой инструкции DUP. X и Y являются элементами, соответственно, удаляемыми из стека и помещаемым в него.

Операции обмена

Операции SWAP предоставляют возможность обмена элементов стека. Всего имеется 16 доступных инструкций SWAPи для каждой инструкции значения элементов стека удаляются и инкрементально помещают до 17 элементов в зависимости от применяемого типа кода операции.

Таблица 7-9. Операции обмена

Мнемоническое обозначение	Значе- ние	POP	PUSH	Газ	Описание
SWAP1 … SWAP16	0x90 … 0x9f	X	Y	3	Применяется для обмена N- го элемента стека, где N является тем номером, который соответствует данной используемой инструкции SWAP. X и Y являются элементами, соответственно, удаляемыми из стека и помещаемым в него.

Операции регистрации

Операции регистрации предоставляют код операции для его записи в конец элементов протоколирования в последовательности полей журнала кортежей суб-состояний. Всего имеются доступными четыре операции регистрации и они располагаются в диапазоне от 0xa0 до 0xa4.

Таблица 7-10. Операции протоколирования

Мнемоническое обозначение	Значе- ние	POP	PUSH	Газ	Описание
LOG1 … LOG4	0xa0 … 0xa4	X	Y(0)	375, 750, 1125, 1500, 1875	Применяется для добавления в конец записи журнала с N темами, где N является тем номером, который соответствует данной используемой инструкции LOG. Например, LOG0 означает протоколирование записи без темы, а LOG4 означает регистрацию записи с четырьмя темами. X и Y представляют те элементы, которые, соответственно, удаляемыми из стека и помещаются в него. X и Y изменяются инкрементально, начиная с 2,0 и вплоть до 6,0 в соответствии с применяемой операцией LOG.

Системные операции

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

кодом учётной записи

Таблица 7-11. Системные операции

Мнемоническое обозначение	Значе- ние	POP	PUSH	Газ	Описание
CREATE	0xf0	3	1	32000	Применяется для создания некоторой новой учётной записи со связанным с ней кодом
CALL	0xf1	7	1	40	Применяется для инициации какого- то вызова сообщения в некую учётную запись
CALLCODE	0xf2	7	1	40	Применяется для инициации какого- то вызова сообщения в этой учётной записи с неким альтернативным кодом учётной записи
RETURN	0xf3	2	0	0	Останавливает исполнение и возвращает данные вывода
DELEGATECALL	0xf4	6	1	40	То же самое, что и CALLCODE, однако не изменяет текущие значения самого отправителя и его значения.
SUICIDE	0xff	1	0	0	Останавливает (halt) исполнение и данная учётная запись регистрируется для её последующего удаления

В этом разделе были рассмотрены все коды операций EVM. Всего имеются доступными 129 кода операций в EVM для выпуска Эфириум homestead.

В Эфириум имеются четыре предварительно скомпилированных контракта. Ниже приводится их полный перечень и подробности.

ECDSARECOVER (Elliptic curve DSA recover function, Функция восстановления DSA эллиптической кривой) доступна по адресу 1. Он помечена как ECREC и требует для исполнения 3000 газа. Если подпись не верна, тогда эта функция не возвращает никакого вывода. Восстановление общедоступного ключа является стандартным механизмом, посредством которого такой общедоступный ключ может быть выведен и имеющегося частного ключа в криптографии эллиптической кривой.

Данная функция ECDSA восстановления общедоступного ключа отображается следующим образом:

       ECDSARECOVER(H, V, R, S) = Public Key
 	   

Она получает на вход четыре параметра: H, который является 32 битным хэшем того подлежащего подписыванию сообщения, а также V, R и S, которые представляют определённую подпись ECSDA для восстанавливаемого идентификатора т производства 64 байтов общедоступного ключа. V, R и S уже подробно обсуждались в этой главе.

Эта функция SHA-256 битного хэша является предварительно скомпилированным контрактом, который доступен по адресу 2 и производит хэширование 256 полученного на входе. Это почти как проходная функция. Необходимый для SHA-256 (SHA256) газ зависит от размера получаемых на входе данных. Вывод представляется как некое 32 байтовое значение.

Функция хэширования RIPEMD-160 применяется для создания 160- битного хэша RIPEMD и доступна по адресу 3. На выход этой функции выдаётся некое значение из 20 байт. Требуемый газ, аналогично SHA-256, зависит от общего объёма входных данных.

Функция идентификации доступна по адресу 4 и обозначается как ID. Она просто определяет вывод как вход; другими словами, всякий раз когда ввод предоставляется данной функции ID, она будет выводить одно и то же значение. Необходимый газ определяется по простой формуле: 15 + 3 [Id/32], где Id является входными данными. Это означает, что на некотором высоком уровне требуемый газ зависит от самого размера получаемых на входе данных, хотя и с некоторым проведением вычислений, что демонстрирует предыдущее уравнение.

Все приведённые предварительно скомпилированные контракты могут стать в будущем естественными расширениями и могут быть включены в коды EVM.

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

В Эфириум имеются два типа учётных записей (счетов, account):

Самыми первыми являются EOA (externally owned accounts, Учётные записи внешнего владельца), а все оставшиеся являются учётными записями контракта. EOA являются аналогичными учётным записям, которые управляются неким частным ключом в биткойне. Учётные записи контракта являются теми учётными записями, которые имеют связанный с ними код совместно с имеющимся частным ключом. Некая EOA имеет либо баланс, который доступен для отправки транзакциям, и при этом никакого связанного сней кода, в то время как CA (Contract Account, учётная запись контракта) имеет баланс эфира, связанный с ней код и саму возможность быть включённой и исполнить код в ответ на некую транзакцию или какое- то сообщение. Следует отметить, что из- за свойства полноты по Тьюрингу рассматриваемого блокчейна Эфириум, весь код внутри учётных записей контракта может иметь любой уровень сложности. Этот код исполняется EVM всеми узлами майнинга в имеющейся сетевой среде Эфириум. Кроме того, учётные записи контракта способны поддерживать своё собственное постоянное состояние и могут вызывать прочие контракты. Предусматривается, что в выпуске serenity может быть преодалено различие между учётными записями внешних владельцев и учётными записями контракта.

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

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

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

Родительский хэш

Это 256- битный хэш Кечак (Keccak) заголовка блока родителя (предыдущего блока).

Хэш дядюшки

Здесь содержится 256- битный хэш Кечак всего списка блоков Дядюшек (Ommers, Uncles), включаемых в анный блок.

Выгодополучатель

Поле Выгодополучателя (Beneficiary) содержит значение 160- битного адреса того получателя, который желает получить вознаграждение за майнинг, когда данный блок будет успешно добыт.

Корень состояния

Поле Корня состояния (State root) содержит значение 256- битного хэна Кечак узла корня данного древа состояния. Он вычисляется после того как все транзакции были осуществлены и финализированы.

Корень транзакций

Значением Корня транзакций (Transactions root) является 256- битный хэш Кечак узла корня данного древа транзакции. Древо транзакции представляет полный список транзакций, включённых в этот блок.

Корень квитанций

Значением Корня квитанций (Receipts root) являются 256 бит хэша Кечак узла корня имеющегося древа квитанций транзакции. Это древо состоит из квитанций всех транзакций, включённых в данный блок. Квитанции транзакции вырабатываются после осуществления каждой транзакции и содержат полезную информацию по завершению транзакции (post- transaction). Дополнительные свеления о квитанциях транзакции предоставлены в следующем разделе.

Журналы bloom

Журналы bloom являются bloom фильтром, который составляется из всех адресов зарегистрировавшихся и тем журналов от определённой записи журнала каждой квитанции транзакции вложенного списка транзакций в данном блоке. Ведение журнала подробно объясняется в следующем разделе.

Сложность

Это уровень сложности (difficulty) текущего блока.

Число

Общее число (number) всех предыдущих блоков; самым первым порождающим является блок ноль.

Предел газа

Это поле содержит то значение, которое представляет установленную величину предела значения потребления газа на блок.

Использованный газ

Это поле содержит общее потребление газа всеми включёнными в этот блок транзакциями.

Временной штамп

Временной штамп (Timestamp) является значением эпохи времени Unix общего времени инициализации блока.

Дополнительные данные

Поле Дополнительных данных (Extra data) может применяться для хранения произвольных данных, относящихся к данному блоку.

Смешанный хэш

Поле Смешанного хэша (Mixhash) содержит 256- битный хэш, который после соединения с Данным временем (nonce) применяется для подтверждения того, что на создание данного блока были затрачены адекватные вычислительные усилия.

Данное время

Данное время (nonce) это 64- битный хэш (некое число), которое используется, в комбинации со значением поля mixhash, для удостоверения того, что для создания данного блока были потрачены достаточные вычислительные усилия.

Следующий рисунок отображает подробную структуру всего блока и заголовка блока:

Порождающий блок (genesis block) может слегка отличаться в зависимости от тех данных, и того способа, которым он был создан из обычного блока. Он содержит 15 элементов, которые описываются здесь.

Исходя из Etherscan.io, текущая действующая версия отображается следующим образом:

Таблица 7-12. Порождающий блок

Элемент	Описание
Timestamp	(Jul-30-2015 03:26:13 PM +UTC)
Transactions	8893 transactions and 0 contract internal transactions in this block
Hash	0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3
Parent hash	0x0000000000000000000000000000000000000000000000000000000000000000
Sha3Uncles	0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347
Mined by	0x0000000000000000000000000000000000000000 IN 15 secs
Difficulty	17 179 869 184
Total Difficulty	17 179 869 184
Size	540 bytes
Gas Limit	5 000
Gas Used	0
Nonce	0x0000000000000042
Block Reward	5 Ether
Uncles Reward	0
Extra Data	»èÛN4{NŒ”|ƒpäµí3³ÛiËÛz8áå ‚ú (Hex:0x11bbe8db4e347b4e8c937c1c8370e4b5ed33adb3db69cbdb7a38e1e50b1b82fa)

Квитанции транзакции применяются как механизм для хранения полученного состояния после исполнения некоторой транзакции. Другими словами, эти структуры используются для записи выхода исполнения определённой транзакции. Они производятся после исполнения каждой транзакции. Все квитанции сохраняются в некотором индексированном ключами древе. Хэш (256- битный Кечак) корня этого древа помещается в имеющийся заголовок блока в качестве основного корня квитанций. Он составляется из представленных здесь четырёх элементов.

Состояние после транзакции

Данный элемент (post-transaction state) является структурой древа, которая содержит значение состояния после исполнения определённой транзакции. Он кодируется как некий массив байт.

Использованный газ

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

Набор журналов регистрации

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

Фильтр bloom

Фильтр bloom создаётся из той информации, которая содержится в имеющемся наборе регистрируемых записей, которые обсуждались ранее. протокольная запись уменьшается до хэша в 256 байт, который затем встраивается в имеющийся заголовок блока как текущая запись bloom. Запись регистрации состоит из определённого адреса регистрируемого и тем регистрации, а также протоколируемых данных. Регистрационные темы кодируются как последовательности структур из 32 байт. Протоколируемые данные делаются несколькими байтами данных.

Этот процесс может быть отображён следующей схемой:

Транзакции исполняются после проверки самих транзакций на их правильность. Начальные тесты перечислены ниже:

Субсостояния транзакции

Субсостояние некоторой транзакции создаётся в в процессе самого исполнения той транзакции, которая обрабатывается немедленно по завершению данного исполнения. Такое субсостояние является неким кортежем, который компонуется из трёх элементов.

Набор самоубийств

Данный элемент (Suicide set) содержит полный перечень тех учётных записей, которые освобождаются после исполнения данной транзакции.

Последовательности регистрации

Это некие последовательности контрольных точек с индексом, которые позволяют определённый мониторинг и уведомление вызовов контракта для внешних в отношении Эфириум сущностей таких, как интерфейсы приложений. Они работают как механизм включения, который исполняет всякий раз некую определённую активируемую функцию или происходит какое-то предписанное событие. Регистрации создаются в ответ на происходящие в адаптивном контракте (smart contract) события. События обсуждаются в практических примерах Главы 8, Разработка Эфириума.

Возмещение баланса

Это общая стоимость газа в той транзакции, которая инициируется для исполнения. Выплаты не инициируют немедленное исполнение; вместо этого они применяются для частичного сдвига всей стоимости исполнения.

Приводимая ниже схема описывает обсуждённый кортеж субсостояния

Блок Эфириум рассматривается как верный, если он проходит следующие проверки:

Если одна из этих проверок неудачна, данный блок отвергается.

Финализация блока

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

Проверка достоверности дядюшки

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

Проверка подлинности транзакции

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

Приложение вознаграждения

Применение вознаграждения, что означает обновление учётной записи выгодополучателя неким балансом награды. В Эфириум какая- то награда также выдаётся майнерам устаревших блоков, которая составляет 1/32 от общего вознаграждения блока. Включённые в данный блок Дядюшки также получают 7/8 от общей награды блока. Вознаграждение текущего блока составляет 5 Эфиров. Каждый блок может иметь максимально двух Дядюшек.

Проверка подлинности состояния и Данного времени

Проверяется состояние и Данное время. В случае майнинга вычисляются верное состояние и Данное время.

Сложность блока

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

    block_diff = parent_diff + parent_diff // 2048 *
    max(1 - (block_timestamp - parent_timestamp) // 10, -99) +
    int(2**((block.number // 100000) - 2))
 	   

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

Помимо регулированию сложности на основе разницы временных шатмпов, также имеется другая часть (отображённая в самой последней строке приведённого выше алгоритма), которая увеличивает значение сложности экспоненциально после каждых 100 000 блоков. Это так называемая временная бомба сложности или Ледниковый период, вводимый в сетевой среде Эфириум, который сделает очень трудным майнинг данного блокчейна Эфириум в некоторый момент в будущем. Это поощряет пользователей переключаться на Подтверждение Вех (Proof of Stake) по мере того как добыча (майнинг) данной цепочки PoW с течением времени станет скорее всего сложным. В соответствии с самыми последними обновлениями и оценками на основе данного алгоритма, значение времени выработки блока станет особенно тяжёлым в течении второй половины 2017 года и в 2021, она станет настолько тяжёлой, что будет фактически невозможно осуществлять майнинг в имеющейся цепи PoW. Таким образом, у майнеров не будет иного выбора кроме как переключится на схему Подтверждения Вех (POS)предлагаемому Эфириумом с названием Каспер (Casper).

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

Ниже отображается таблица достоинства единиц:

Таблица 7-13. Номиналы

Элемент	Значение Wei	Wei
Wei	1 Wei	1
Babbage	1e3 Wei	1 000
Lovelace	1e6 Wei	1 000 000
Shannon	1e9 Wei	1 000 000 000
Szabo	1e12 Wei	1 000 000 000 000
Finney	1e15 Wei	1 000 000 000 000 000
Ether	1e18 Wei	1 000 000 000 000 000 000

Вознаграждение полагается за все выполняемые конкретной EVM вычисления в имеющемся блокчейне. В последующих разделах поясняются подробности перечня гонорара.

Газ необходим для выплат за все выполняемые в блокчейне Эфириум операции. Именно этот механизм обеспечивает то, что бесконечные зацикливания не могут вызвать срыв потока всего блокчейна по причине Тьюринговской полноты используемой EVM. Некий гонорар транзакции назначается в качестве какого- то количества Эфира и выбирается из имеющегося баланса породителя данной транзакции. Вознаграждение выплачивается за подлежащие включению майнерами в добычу транзакции. Эсли это вознаграждение слишком низкое, такая транзакция может быть никогда не подцепленной; чем выше значение гонорара, тем выше шансы что эти транзакции будут подхвачены имеющимися майнерами для их включения в существующий блок. И наоборот, если та транзакция, которая имеет некий достаточный для оплаты гонорар включена в имеющийся блок майнерамы, однако имеет для своего выполнения слишком много сложных операций, она может привести в результате к исключительной ситуации расходования газа если этой стоимости газа не достаточно. В таком случае данная транзакция не выполнится , однако будет проделана часть данного блока и данный породитель транзакции не получит никакого вознаграждения.

Стоимость транзакции можно оценить с применением следующей формулы:

       Общая стоимость = gasUsed * gasPrice
 	   

Здесь gasUsed является общим количеством газа, который поддерживается для использования данной транзакцией на протяжении данного исполнения, а gasPrice определяется самим породителем транзакции как некий стимул для имеющихся майнеров для включения этой транзакции в такой следующий блок. Именно это определяется в Эфире. Каждый код операции EVM имеет некое назначенное ей вознаграждение. Это является оценкой, так как используемый газ может быть больше или меньше чем то значение, которое определяется первоначально породителем этой транзакции. Например, если вычисления продолжаются слишком долго или поведение этого адаптивного контракта (smart contract) изменяется в ответ на некие прочие факторы, тогда исполнение данной транзакции может выполнить больше или меньше операций, чем это предусматривалось первоначальнои может иметь результатом потребление большего или меньшего количества газа. Если данное исполнение исчерпывает газ, всё немедленно откатывается обратно; в противном случае, если это исполнение успешно и имеется некий оставшийся газ, тогда он возвращается породителю этой транзакции.

Всякая операция стоит определённого газа; некий перечень высокого уровня некоторых операций отображается в приводимом здесь примере:

Таблица 7-14. Перечень стоимостей

Название операции	Стоимость газа
шаг	1
останов	0
самоуничтожение	0
sha3	30
txdata	5
транзакция	500
создание контракта	53 000

На основании приведённого перечня гонораров и той формулы, которая обсуждалась ранее, может быть вычислен некий пример вычисления определённой операции SHA3:

Итого, значение в 0.000 000 75Эфира является общим количеством газа, который будет снаряжён.

Газ снаряжается в трёх сценариях в качестве предварительного требования для исполнения некоторой операции:

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

Сообщения, как это определено в жёлтой книге, являются теми данными изначениями, которые передаются между двумя учётными записями. Некоторое сообщение является пакетом данных, пересылаемым между двумя учётными запсиями (счетами). Такой пакет данных содержит данные и значение (количество эфира). Оно может быть отправлено либо через адаптивный контракт (smart contract, автономный объект), либо от некоторого внешнего действующего лица (actor, учётная запись внешнего владельца- EOA) в виде какой- то транзакции, которая была подписана цифровым образом её отправителем.

Контракты могут отправлять сообшения другим контрактам. Сообщения могут присутствовать только в определённой среде исполнения и никогда не запоминаются. Сообщения аналогичны транзакциям; однако, основное отличие состоит в том, что они воспроизводятся контрактами, в то время как транзакции продуцируются внешними сущностями (EOA- externally owned accounts) для существующей среды Эфириума.

Некое сообщение составляется из следующих компонентов:

Сообщение создаётся когда определённый контракт исполняет код операции CALL или DELEGATECALL.

Вызов ничего не распространяет широковещательно в имеющемся блокчейне; вместо этого он является локальным вызовом некоторой функции контракта и исполняется локально в данном узле. Это почти то же, что и вызов локальной функции. Он не потребляет никакого газа, в силу того, что является операцией, доступной только для чтения. Он похож на пробный прогон. Вызовы исполняются локально на некотором узле и обычно не имеют результатом никакого изменения состояния. Как определятся в жёлтой книге, это определённое действие передачи сообщения от одной учётной записи к другой. Если учётная запись получателя имеет некий связанный с ней код EVM, тогда по получению такого сообщения будет запущена определённая виртуальная машина для выполнения необходимых операций. Если этим отправителем сообщения является некий автономный объект, тогда данный вызов передаёт все данные, возвращаемые из операции данной виртуальной машины.

Состояние изменяется транзакциями. Они создаются внешними движущими силами и подписываются, а затем широковещательно распространяются по всей сетевой среде Эфириум.

Мацнинг (Добыча) является тем процессом, посредством которого новая валюта добавляется в имеющийся блокчейн. Именно он является привлекательной стороной для существующих майнеров (добытчиков) чтобы проверять и удостоверивать блоки, составляемые транзакциями. Такой процесс майнинга помогает обезопасить имеющуюся сетевую среду проверкой вычислений.

На некотором теоретическом уровне майнер выполняет следующие функции:

Текущий метод майнинга основывается на Подтверждении Работы (PoW, Proof of Work), что аналогично тому же самому в Биткойне. Когда блок полагается верным, он должен удовлетворять не только общим требованиям согласованности, но также должен содержать значение Подтверждения Работы для заданной сложности.

Данный алгоритм Подтверждения Работы должен быть заменён на алгоритм Подтверждения Вех (POS, Proof of Stake) с выпуском serenity. Была проведена существенная исследовательская работа чтобы построить такой алгоритм Подтверждения Вех (POS), который подойдёт Сетевой среде Эфириум.

Был разработан некий алгоритм с названием Каспер (Casper), который заменит имеющийся в Эфириум алгоритм Подтверждения Работ (PoW). Это некий безопасный вклад, основанный на экономичном протоколе, в котором узлам необходимо помещать некий вклад безопасности прежде чем они смогут производить блоки. В Каспере узлы именуются связанными валидаторами (bonded validator), в то время как само действие размещения депозита безопасности имеет название привязки (bonding).

Ethash является названием применяемого в Эфириум алгоритма Подтверждения Работ (PoW, Proof of Work). Первоначально он был пердложен как алгоритм Даггера- Хашимото (Dagger-Hashimoto), однако с момента первой реализации многое изменилось и данный алгоритм PoW теперь развился в то, что именуется теперь как Ethash. Аналогично Биткойну, центральной идеей в основе майнинга является нахождение некоторого Данного времени (nonce), которое однажды было хэшировано определённым результатом в каком- то предварительно определённом уровне сложности. Изначально сложность была низкой, когда Эфириум был новостью и даже майнинг ЦПУ и отдельным GPU были приносящими прибыль до определённой степени, однако это больше не имеет места. Теперь выгоду имеет либо майнинг в пуле, либо для целей добычи применяются большие фермы майнинга GPU.

Ethash является алгоритмом с интенсивным использованием памяти, который делает его трудным для реализации на специализированном оборудовании. В случае Bitcoin были разработаны ASIC, которые в результате привели к централизации майнинга на протяжении последних лет, однако жадные в отношении памяти алгоритмы Подтверждения Работы (PoW) являюся одним из способом срыва таких попыток и Эфириум реализует Ethash для демотивации разработки ASIC под майнинг. Этот алгоритм требует выбора подмножеств фиксированных ресурсов с названием DAG (Directed Acyclic Graph, Направленных графов без циклов), зависящих от значения Данного времени (nonce) и заголовков блока. DAG составляет примерно 2 ГБ в размере и изменяется для каждых 30 000 блоков. Добыча может начинаться только когда DAG полностью создан при самом первом запуске какого- то узла майнинга. Значение промежутка времени между каждыми 30 000 блоков составляет около 5.2 дней и имеет название эпохи. Такой DAG применяется как посевочное зерно алгоритмом Подтверждения работы (PoW) с названием Ethash. В соответствии с текущей спецификацией, значение времени эпохи определяется как 30 000 блоков.

Текущая схема вознаграждения состоит в 5 Эфирах за успешное обнаружение верного Данного времени (nonce). Помимо получению 5 Эфиров, удачливый майнер также получает полную стоимость того газа, который потреблён внутри данного блока и некий дополнительный гонорар за включение устаревших блоков (Дядющек, Uncles) в построенный блок. На блок допускается максимально два Дядюшки и они вознаграждаются 7/8 от обычного вознаграждения за блок. Чтобы достичь некоторого времени блока 12 секунд, сложность блока регулируется в каждом блоке. Получаемое вознаграждение находится в прямо пропорциональной зависимости от текущей скорости хэша майнера, что в основном означает, как быстро некий майнер может выполнять хэширование.

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

В последующих разделах обсуждаются различные методы майнинга.

Даже хотя он и не приносит выгоды в основной сетевой среде, майнинг CPU всё ещё возможен в определённой тестовой сетевой среде или даже в какой- то частной сети для экспериментов с майнингом и разработкой контракта. Частные и тестовые сетевые среды будут обсуждены в практических примерах в нашей следующей главе. Здесь показан пример geth того как запустить майнинг CPU. Geth может быть запущен ключом mine чтобы начать добычу:

geth --mine --minerthreads <n>
		

Майнинг CPU также может быть запущен с использованием консоли geth web 3. Консоль geth может стартовать путём исполнения такой команды:

geth attach
		

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

Miner.start(4)
True
		

Предыдущая команда запустит конкретного майнера с четырьмя потоками. Посмотрим на такую команду:

Miner.stop
True
		

Приведённая команда остановит имеющегося майнера. Эта команда в случае успеха возвращает true.

На некотором основном уровне майнинг GPU легко может быть выполнен двумя командами:

geth --rpc
		

Когда geth поднят и исполняется, а необходимый блокчейн полностью выгружен, для начала добычи может быть выполнен Ethminer. Ethminer является неким отдельным добытчиком, который может также применться в имеющемся режиме фермы для внесения своего вклада в пулы майнинга. Он может быть выгружен и https://github.com/Genoil/cpp-ethereum/tree/master/releases:

ethminer -G
		

Исполнение с ключом G, который подразумевает, что соответствующая графическая плата установлена и правильно настроена. Если не будет обнаружено никакой надлежащей графической карты, ethminer вернёт некую ошибку, как это отображдает следующий снимок экрана:

Майнинг GPU нуждается в некоторой графической карте AMD или nVidia и пригодного SDK OpenCL. Для набора микросхем nVidia он может быть выгружен с https://developer.nvidia.com/cuda-downloads. Для наборов микросхем AMD он доступен по адресу http://developer.amd.com/tools-and-sdks/opencl-zone/amd-accelerated-parallel-processing-app-sdk.

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

Ethminer также может применяться для исполнения эталонного тестирования, как это показано в последующих снимках экрана. Имеются два режима, которые могут вызываться для эталонного тестирования. Это может быть или CPU, или GPU. Соответствующие команды показаны ниже.

Эталонное тестирование CPU

$ ethminer -M -C
		

Последующий снимок экрана является примером, отображающим эталонное тестирование CPU:

Эталонное тестирование GPU

$ ethminer -M -G
		

Подлежащее использованию устройство GPU также может быть определено в командной строке:

$ ethminer -M -G --opencl-device 1
		

Так как майнинг GPU реализуется с применением OpenCL, основанные на наборе микросхем GPU AMD имеют тенденцию работать быстрее в сопоставлении с GPU nVidia. Из- за высоких требований к памяти (создание DAG), FPGA и ASIC не предоставляют никаких существенных преимуществ в сравнении с GPU. Это делается намеренно, чтобы препятствовать разработке специализированного оборудования под майнинг.

По мере того, как сложность добычи Эфира растёт со временем, участвующие в ней майнеры начинают строить экипировку со множеством GPU. Обычно комплект майнинга содержит порядка пыти карт GPU и все они работают одновременно над добычей, тем самым повышая вероятность обнаружения верных значений Данного времени (nonce) для майнинга.

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

Материнская плата

Необходима специализированная материнская плата со множеством слотов PCI-E x1 или x16, например, BIOSTAR HiFi или ASRock H81.

Жёсткий диск SSD

Необходим жёсткий диск SSD. Он рекомендуется по той причине, что он имеет намного более высокую производительность, чем его эквиваленты {по ёмкости}. В основном он применятся для хранения самого блокчейна.

GPU

GPU является наиболее важным компонентом в данной экипировке, поскольку является основной рабочей лошадкой, которая будет применяться для майнинга. Например, это может быть Sapphire AMD Radeon R9 380 с 4 ГБ видео памяти.

В качестве операционной системы для такой экипировки обычно выбирается Linux Ubuntu. имеется также другой доступный вариант Linux с названием EthOS (доступный по адресу http://ethosdistro.com/), который специально разработан для майнинга Эфириума и поддерживает естественным образом операции добычи.

Наконец, устанавливается программное обеспечение майнинга, такое как Ethminer и geth. Кроме того, также устанавливаются некоторое программное обеспечение удалённого мониторинга и администрирования. также важно разместить надлежащие кондиционеры воздуха или механизмы охлаждения в этом месте, так как работа множества GPU может вырабатывать большое количество тепла. Это также влечёт за собой необходимость использования соответствующего программного обеспечения мониторинга,которое может оповещать пользователей в случае, если возникают какие- либо проблемы, например, если GPU перегреваются. {Прим. пер.: автор также пропускает необходимость надлежащего подвода электропитания, помните, вычислительная техника имеет КПД равный нулю с точки зрения термодинамики: всё что выделяется в тепло вы получаете из розеток! Аппаратные средства непрерывно совершенствуются, поэтому за новинками рекомендуем обращайться к специалистам. Кромсе того, мы готовы помочь вам с проблемами по настройке большого числа GPU в одной системе (12 и более). не стесняйтесь и помните: мы поможем вам более эффективно использовать ваши средства!}.

В Интернента имеется множество пулов (коллективных ресурсов), которые предлагают майнинг Эфириума. Для подключения к некому пулу майнинга может применяться Ethminer с использованием приводимой ниже команды. Всякий пул публикует свои собственные инструкции, однако, обычно весь процесс подключения к пулу похож. Здесь отображён пример с ethereumpool.co:

ethminer -C -F http://ethereumpool.co/?miner=0.1@0x024a20cc5feba7f3dc3776075b3e60c20eb1459c@DrEquinox
		

Так как Эфириум интенсивно разрабатывается и развивается, имеется множество компонентов, клиентов и инструментов, которые на протяжении последних нескольких лет были развиты и внедрены. Ниже мы приводим некий список всех основных компонентов, клиентского программного обеспечения и инструментария, которые доступны для Эфириум. Данный список предоставляется для уменьшения неоднозначности вокруг многих доступных для Эфириум инструментов и клиентов. Предоставляемый перечень также поясняет варианты применения и значимость различных компонентов.

Это реализация Go для основного клиента Эфириум.

Представляет собой реализацию клиента Эфириум C++.

Является реализацией клиента Эфириум на Python.

Данная реализация построена с использованием Rust и разрабатывается EthCore. EthCore является компанией, которая работает над осуществлением клиента parity. Parity моно выгрузить с https://ethcore.io/parity.html.

Клиенты SPV выгружают только небольшое подмножество всего блокчейна. Это делает возможным для устройств с небольшими ресурсами, таких как мобильные телефоны, встраиваемые устройства или планшеты иметь возможность проверять имеющиеся транзакции. В этом случае нет нужды в полных блокчейне Эфириум и узле и клиенты SPV всё ещё могут проверять само исполнение транзакций. Клиенты SPV также именуются лёгкими клиентами. Эта идея аналогична идее клиентов SPV Биткойна. Имеется некий кошелёк (wallet), доступный в Jaxx (https://jaxx.io/), который может быть установлен в iOS и Android, предоставляющих функциональность SPV (Simple Payment Verification, Простой проверки платежа).

Последующая процедура установки описывает собственно установку различных клиентов Эфириум в системах Ubuntu. \введение в прочие операционные системы доступно в WIKIS Эфириум. Так как системы Ubuntu будут применяться в последующих примерах, здесь мы описываем только установку в Ubuntu.

Клиент Geth может быть установлен в системе Ubuntu с применением следующих команд:

> sudo apt-get install -y software-properties-common
> sudo add-apt-repository -y ppa:ethereum/ethereum
> sudo apt-get update
> sudo apt-get install -y ethereum
		

После того, как установка Geth завершена, Geth может быть запущен просто через вызов команды geth в приглашении командной строки, так как он поставляется предварительно настроенным со всеми необходимыми параметрами для соединения с существующей сетевой средой Эфириум (mainnet):

> geth
		

Установка Eth

Eth является реализацией C++ клиента Эфириум и может быть установлен с применением следующей командной строки в Ubuntu:

> sudo apt-get install cpp-ethereum
		

Браузер Mist

Браузер Mist является дружественным для пользователя интерфейсом, предназначенным для конечных пользователей с богатыми свойствами интерфейса графического пользователя, который применяется для просмотра DAPPS и для управления учётными записями и управления контрактами. Установка Mist обсуждается в следующей главе.

Когда Mist запускается впервые, он инициализирует geth в фоновом режиме и будет синхронизирован с имеющейся сетевой средой. Это может потребовать от нескольких часов до нескольких дней в зависимости от скорости и типа имеющейся сетевой среды для полной синхронизации с установленной сетевой средой. Если применяется TestNet, тогда синхронизация завершается относительно быстрее, так как имеющийся размер TestNet (Ropsten) не настолько велик, как MainNet. Дополнительная информация о том как подключаться к TestNet будет предоставлена в нашей следующей главе.

Браузер Mist не является кошельком; на самом деле он является браузером DAPPS и предоставляет дружественный пользователю интерфейс для создания и управления контрактами, учётными записями и просмотром децентрализованных приложений. Кошелёк (wallet) Эфириум является неким DAPP, который реализуется с помощью Mist.

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

Прочие кошельки включают MyEtherWallet, однако не ограничены им, причём MyEtherWallet является кошельком эфира с неким открытым исходным кодом, разрабатываемым в JavaScript. MyEtherWallet исполняется в имеющемся браузере клиента. Он доступен по ссылке https://www.myetherwallet.com.

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

Для рабочих мест, мобильных и веб платформ доступны различные кошельки. На следующем снимке представлен популярный Кошелёк iOS с названием Jaxx:

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

Новая учётная запись может быть создана различными способами. В нашем браузере Mist она может быть создана путём нажатия на меню Accounts и выбора пункта New account или путём клика по опции Add account в появляющемся окне Mist Accounts Overview.

Эта учётная запись нуждается в установке какого- то пароля, как это показано на предыдущем рисунке; когда данная учётная запись установлена, она будет отображаться в разделе обзора всех учётных записей нашего браузера Mist.

Учётные записи также можно добавлять в командной строке с помощью интерфейса командной строки geth или parity. Этот процесс отображается в нашем следующем разделе.

Geth

$ geth account new
Your new account is locked with a password. Please give a password. Do not
forget this password.
Passphrase:
Repeat passphrase:
Address: {21c2b52e18353a2cc8223322b33559c1d900c85d}
drequinox@drequinox-OP7010:~$
		

Приводимый список учётных записей может быть отображён при помощи geth с применением следующей команды:

$ geth account list

Account #0: {11bcc1d0b56c57aefc3b52d37e7d6c2c90b8ec35}
/home/drequinox/.ethereum/keystore/UTC--2016-05-07T13-04-15.175558799Z--11bcc1d0b56c57aefc3b52d37e7d6c2c90b8ec35

Account #1: {e49668b7ffbf031bbbdab7a222bdb38e7e3e1b63}
/home/drequinox/.ethereum/keystore/UTC--2016-05-10T19-16-11.952722205Z--e49668b7ffbf031bbbdab7a222bdb38e7e3e1b63

Account #2: {21c2b52e18353a2cc8223322b33559c1d900c85d}
/home/drequinox/.ethereum/keystore/UTC--2016-11-29T22-48-09.825971090Z--21c2b52e18353a2cc8223322b33559c1d900c85d
		

Консоль geth

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

Geth может быть подключён посредством исполнения демона, как это отображено на следующем снимке:

После того как geth успешно подключён к исполняющемуся экземпляру клиента эфириум (в данном случае, parity), он отобразит приглашение командной строки '>', которое предоставит интерактивный интерфейс командной строки для взаимодействия с этим клиентом эфириум с помощью нотации JavaScript.

Например, новаая учётная запись может быть добавлена с применением такой команды в данной консоли geth:

> personal.newAccount()
Passphrase:
Repeat passphrase:
"0xc64a728a67ba67048b9c160ec39bacc5626761ce"
>
		

Полный список учётных записей также может быть отображён аналогичным образом:

> eth.accounts
["0x024a20cc5feba7f3dc3776075b3e60c20eb1459c",
"0x11bcc1d0b56c57aefc3b52d37e7d6c2c90b8ec35",
"0xdf482f11e3fbb7716e2868786b3afede1c1fb37f",
"0xe49668b7ffbf031bbbdab7a222bdb38e7e3e1b63",
"0xf9834defb35d24c5a61a5fe745149e9470282495"]
		

Учреждение учётной записи с помощью биткойна

Эта опция доступна в браузеоре Mist после клика по необходимой учётной записи и последующем выборе этой опции для поиска необходимой учётной записи. Механизмом обслуживания данной операции является shapeshift.io и он может применяться для поиска необходимой учётной записи среди Биткойн или прочих валют, в том числе также и самой указанной опции.

После того,как обмен осуществлён, весь переданный Эфир будет доступным в этой учётной записи.

Parity является другой реализацией клиента Эфириум. Он был написан с использованием языка программирования Rust. Основная цель данной разработки parity состоит в высокой производительности, малом отпечатке и надёжности. Parity может быть установлен с применением следующих команд в Ubuntu и системах Mac:

bash <(curl https://get.parity.io -Lk)
		

Это инициирует выгрузку и установку необходимого клиента parity. По завершению данной установки parity, исполняющийся установщик также предложит установить клиента netstats. Такой клиент netstats является демоном, исполняемым в фоновом режиме и собирающим важные статистические данные с последующим их отображением в stats.ethdev.com.

На следующем снимке экрана отображается пример установки parity:

После того, как установка успешно завершена, будет отображено представленное ниже сообщение. Узел parity Эфириум затем может быть запущен с применением parity -j. Если для применения кошелька Эфириум (браузер Mist) через parity необходима совместимость с geth, тогда для запуска parity следует применить команду parity -geth. Она запустит parity в режиме совместимости с установленным клиентом geth и поэтому позволит Mist исполняться поверх parity.

Этот клиент может быть опционально присуствовать в перечне на https://ethstats.net/. Некий пример выглядит следующим образом:

Все подключённые клиенты перечисляются в ethstats.net/, как это показано на нашем следующем снимке экрана. Эти клиенты перечисляются с соответствующими атрибутами, такими как установленное название узла, тип узла, латентность, состояние майнинга, число одноранговых партнёров, число отложенных транзакций, последний блок, сложность, транзакции блока и число Дядюшек.

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

Всё это доступно через следующую команду:

$ parity ui
		

Она поднимает интерфейс, отображаемый следующим образом:

Если parity исполняется в режиме совместимости с geth, UI parity отключён. Чтобы включить этот UI вместе с совместимостью geth, необходимо применить следующую клманду:

$ parity --geth --force-ui
		

Приведённая выше команда запустит parity в режиме совместимости с geth и помимо этого также включит и пользовательский веб интерфейс.

Создание учётных записей при помощи командной строки Parity

Следующая команда может быть применена для создания новой учётной записи с помощью parity:

$ parity account new
Please note that password is NOT RECOVERABLE.
Type password:
Repeat password:
2016-11-30 02:18:55 UTC c8c92a910cfbce2e655c88d37a89b6657d1498fb
		

Эфир доступен на различных биржах для покупки и продажи. Текущая рыночная капитализация Эфириума составляет £680 277 967 на момент написания этих строк и Эфир стоит £7.89 {Прим. пер.: 30 января 2018 капитализация составляет $113 558 379 782 (£80 925 661 963) при стоимости Эфира $1,167.09 (£830.3)}. В последнее время {относительно момента написания книги} значение стоимости было очень волатильным и существенно обвалилось вниз из- за последних атак на Эфириум и последующего раздвоения имеющейся сетевой среды Эфириум.

Приводимая ниже диаграмма отображает подробности рыночной капитализации {на момент написания книги}:

Эфир можно приобрести на различных биржах, либо его можно добыть (намайнить). Имеются доступными службы интернета, такие как Etherscan.io, которые производят конвертацию одной валюты в другую.

Различные биржи интернета, такие как kraken, coinbase и многие прочие предлагают приобретение эфира с применением кредитных карт или иной виртуальной валюты, такой как биткойн.

Жёлтые страницы Эфириум были написаны Dr. Gavin Wood и служат в качестве некоторого формального определения имеющегося протокола Эфириум. Следуя приводимым в этом тексте определениям спецификации любой желающий может реализовать клиента. Этот текст может быть чем- то сложным для чтения, в особенности для тех читателей, которые не имеют основополагающих знаний в алгебре или математике и не знакомы с математическими обозначениями.

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

Таблица 7-15. Перечень символов жёлтой книги

Символ	Значение	Символ	Значение
≡	Определяется как	≤	Меньше чем или равно
=	Равен	σ	Сигма, Всемирное состояние
≠	Не равен	μ	Мю, Состояние машины
║…║	Длина	Υ	Юпсилон, функция изменения состояния Эфириума
∈	Является элементом	Π	Функция изменения состояния уровня блока
∉	Не является элементом	.	Конкатенация последовательности
∀	Для всех	∃	Существует
∪	Объединение	Λ	Функция создания контракта
∧	Логическое И	Δ	Приращение
:	Такой как
{}	Множество
()	Функция кортежа
{}	Множество
[]	Индексация массива
∨	Логическое ИЛИ
>	Больше чем
+	Сложение
-	Вычитание
Σ	Суммирование
{	Описывание различных вариантов Если, В противном случае
⌊…⌋	Пол (Floor), наименьший элемент
⌈…⌉	Потолок (Ceiling), наивысший элемент
│…│	Число байт
⊕	Исключающее ИЛИ
(a,b)	Вещественные числа большие или равные a и меньшие b
∅	пустое множество, null

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

MainNet является в настоящее время сетевой средой реального времени Эфириума. Текущей версией MainNet является homestead.

TestNet также именуется как Ropsten и является тестовой сетевой средой для существующего блокчейна Эфириум. Данный блокчейн применяется для тестирования адаптивных контрактов и DApps до их развёртывания в промышленное применение блокчена в реальном времени. Более того, являясь тестовой сетевой средой, оа позволяет проводить эксперименты и исследования.

Как и предписывается её названием, это та частная сетевая среда, которая может создаваться через генерацию нового блока порождения (genesis block). Обычно она применяется в случае распределённых сетей регистрации, в которых некая частная группа или юридические лица начинают свой собственный блокчейн и используют его в качестве какого- то допустимого блокчейна.

Дополнительное обсуждение того как подключаться к тестовой сети и как устанавливать частные сети будет выполнено в следующей главе.

Имеются различные поддерживаемые протоколы, которые находятся в разработке с тем, чтобы сопровождать имеющуюся полностью децентрализованную экосистему. Они включают в себя протоколы whisper и Swarm. Дополнительно к имеющемуся уровню контрактов, который является основным уровнем ядра блокчейна, имеются дополнительные уровни, которые нуждаются в децентрализации для достижения окончательно децентрализованной экосистемы. Они включают в себя децентрализованное хранение и децентрализованный обмен сообщениями. Whisper, будучи разработанным под Эфириум, является протоколом децентрализованного обмена сообщениями, в то время как Swarm является протоколом децентрализованного хранения. Обе эти технологии разрабатываются в настоящее время и представляются как обеспечивающие основу для полностью децентрализованного веб. В последующих разделах более подробно будут рассмотрены обе эти технологии.

Whisper

Whisper предоставляет децентрализованные одноранговые возможности обмена сообщениями с существующей сетевой средой Эфириум. По существу, whisper является протоколом взаимодействия, который использует узлы для их общения друг с другом. Внутри взаимодействий whisper все данные и маршруты сообщений шифруются. Более того, он спроектирован чтобы применяться для небольших обменов данных и в сценариях, в которых требуется взаимодействие в реальном времени. Whisper также спроектирован для предоставления некоего уровня взаимодействия, который не может отслеживаться и предоставлять "общение в тёмную" между частями. Блокчейн может применяться для взаимодействия, однако это является затратным и согласование в действительности не требуется для обмена сообщениями между узлами. Более того, whisper может применяться как протокол, который позволяет отслеживать соединение между Децентрализованными приложениями (DApps) в сетевой среде Эфириум {Прим. пер.: наша благодарность автору за завершение фразы после двухмеячного ожидания ответа на запрос}.

Whisper уже доступен в geth и может быть включён при помощи опции --shh при исполнении необходимого клиента Эфириум geth.

Swarm

Swarm разработана как некая распределённая платформа файлового хранения. Она чвляется децентрализованной, распределённой и одноранговой сетевой средой хранения. Файлы в этой сетевой среде имеют адресацию по хешу своего содержимого. Это отличает их от традиционных централизованных служб, в которых хранилище доступно только в центральном местоположении. Она разрабатывается как естественная служба базового уровня для стека Эфириум web 3.0. Swarm интегрирован с DevP2P, который является многопротокольным сетевым уровнем Эфириум. Swarm представляется как устойчивый к DDOS (Distributed Denial of service) и восстанавливающийся после отказов уровень распределённого хранения для Web 3.0 Эфириум. И whisper, и Swarm пребывают в разработке и, несмотря на то что для Swarm были выпущены версии Подтверждения Концепции и альфа, пока ещё нет стабильной версии для промышленного применения.

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

Имеются различные реализации DAO и адаптивных контрактов в Эфириум, причём что особенно относится к нему, the DAO, который был недавно взломан и потребовал жёсткого раздвоения для восстановления фонда. The DAO был создан как служба децентрализованной платформы для сбора и распределения инвестиций.

Augur является другим DAPP, который был реализован в Эфириуме и который является рынком децентрализованных прогнозов. Различные иные децентрализованные приложения перечисляются в http://dapps.ethercasts.com/.

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

Данная глава началась с обсуждения истории Эфириума, тех мотиваций, которые стоят за разработкой Эфириума, а также клиентов Эфириум. Затем вы были ознакомллены с основными понятиями имеющегося блокчейна Эфириум, такими как модель машины состояний, Всемирное состояние и состояние машины, учётные запси (счета) и типу учётных записей. Более того, также было представлено подробное введение во все центральные компоненты EVM (Ethereum virtual machine, Виртуальной машины Эфириум). Были введены и подробно обсуждались прочие понятия, такие как блоки, структура бока, газ и сообщения. Самые последние разделы данной главы ввели практическую установку клиентов Эфириум и управление ими. Были обсуждены два наиболее популярных клиента, geth и parity. Дальнейшее, относящееся к разработке, обсуждение этих клиентов будет вынесено в нашу следующую главу, в которой представлена разработка с применением Эфириума. Эфириум находится в постоянной разработке и новые улучшения постоянно выполняются посвятившим себя этому сообществом разработчиков. Предложения по улучшению Эфириум, доступны на https://github.com/ethereum/EIPs, также свидетельствуют о масштабах исследований и острой заинтересованности сообщества в данной технологии. Более того, недавно запущенная инициатива, Enterprise Ethereum Alliance (EAA, Льянс корпоративного Эфириум) имеет целью разработку платформы Эфириум корпоративного масштаба, которая будет способна соответствовать требованиям бизнеса корпоративного уровня. Поскольку проводятся исследования по таким темам, как масштабируемость, оптимизация, пропускная способность и безопасность, имеются основания полагать, что со временем Эфириум превратится в более надёжную и стабильную экосистему блокчейна.