Знакомство с Ethereum в деталях
Криптовалюты Altcoin и Bitcoin с 2011 года Проект Эфириум и «Умные контракты» с 2014 Децентрализованные Автономные Организации (DAO) с 2015 Децентрализация интернет вещей с 2015 Экономика роботов с 2016
\n\n
Работа с технологией блокчейн была начата в 2011 году. Удалось познать ее благодаря криптовалюте биткоин. Позже уделялось внимание аутсорсингу, а в 2013 году прошло знакомство с альтчейнами и трудами Niko Zabo. На это время выпал Research Develop. Благодаря трудам Niko Zabo удалось познакомиться с проектом Виталика Бутерина — Ethereum. Сразу после ICO эфира была начата работа с комьюнити. На это же время пришлись первые работы с блокчейном. Создание первого контракта заняло около 6 месяцев. Работало над ним все сообщество.
\n\n
Два года назад, ровно, когда был запущен проект Эфириум, все стало динамичнее. Контракты стали более грамотными, повсеместно стал использоваться язык Solidity, и возникли библиотеки. Несмотря на то, что создавать контракты можно было, используя массу иных языков, Solidity стал более востребованным сообществом.
\n\n
Есть ряд наработок, с которыми следовало бы познакомить всех тех, кто неравнодушен к блокчейну и криптовалютам. Также следует в деталях рассказать о том, что такое Ethereum и Virtual Machine в сети Эфириум.
\n\n
Децентрализованный компьютер
\n\n
\n\n
Прежде всего, децентрализованный компьютер Эфириум. Что представляет собой Виртуальная машина. В целом это часть протокола, а если сказать точнее, то модуль протокола. Его задача заключается в выполнении на локальной машине тех или иных вычислений. Имеет место и второе понятие, которое более излюблено СМИ. Согласно ему, это компьютер децентрализованного типа мирового масштаба, работающий 24 часа в сутки и 7 дней в неделю. Остановить его не представляется возможным. Разработчики считают его инструментом, без которого невозможно создать ни одно децентрализованное приложение.
\n\n
Гэвин Вуд, находясь в Лондоне на Devcon1, довольно-таки доходчиво рассказал о машине Ethereum. Следует добавить, что выступал он в 2015 году. Рассказчик поведал о том, что виртуальная машина Эфириум достаточно дорогой в обслуживании компьютер, скорость работы которого оставляет желать лучшего. Он бы был к месту в середине 20 века, но никак не в 21.
\n\n
О чем поведал Гэвин Вуд, выступая в Лондоне
\n\n
\n\n\n
Возникает простой вопрос — для какой цели он был создан?
\n\n
Стоит принять во внимание, что это единственный в своем роде единый компьютер, ареал работы которого — это весь мир. К настоящему времени не было создано ни одного аналога данной машины.
\n\n
Виртуальная машина Ethereum является децентрализованной. Это значит, что нет кнопки, которая могла бы выключить ее работу. Внесенные сведения в Эфириум тут же записываются в блок, где и хранятся в нем до тех пор, пока существует сам проект.
\n\n
Не обошлось без философии: Ethereun Virtual Machine (EVM) есть везде, где присутствует виртуальная сеть. Исходный код открыт каждому. Можно прямо сейчас заняться созданием виртуальных машин, которые будут базироваться на публичном или открытом блокчейне. Несмотря на это, работы будут вестись над децентрализованным компьютером. Доступ к нему есть у каждого жителя планеты. Чтобы его получить нужно только скачать исходный код.
\n\n
Это оказывает влияние на многое. Если ранее для пользования теми или иными системами требовалось идентифицироваться, то в данном случае в этом потребности нет. Требуется лишь скачать EVM, развернуть его и после этого он будет полноценно функционировать, не нуждаясь в поддержке со стороны.
\n\n
Ethereum пользуется огромной популярностью — почему?
\n\n
\n\n
В свое время Эфириуму удалось обзавестись стабильной аудиторией. Кроме этого технологии, которые появились благодаря протоколу Ethereum, пользуются спросом.
\n\n
JavaScript и Solidity — это родственные языки программирования. Разработчики неравнодушны и к HTML5. Множество популярных технологий являются близкими Эфириум-протоколу. Работая с ним, не составит труда найти людей, которые будут не прочь что-нибудь разработать совместно. Увы, но протокол Ethereum имеет и недостаток — это концептуальная сложность. Заключается она в архитектуре EVM и нелишним будет познакомиться с ней.
\n\n
О Тьюринг полноте и EVM
\n\n
На EVM можно написать код для любой программы. Это стало возможным благодаря тому, что Виртуальная машина Эфириума поддерживает Тьюринг полноту, и тем самым разработчики не ограничены в своих архитектурных возможностях. В EVM можно запустить любой программируемый процесс.
\nУвы, но не обошлось и без ограничений. Своему появлению они обязаны среде, в которой существуют, а она, как уже многие знают, децентрализованная. Перед тем как начать рассказывать о них, следует познакомиться с определением Аккаунты.
\n\n
«Smart Contracts» и Виртуальная машина Эфириум
\n\n
Существует два типа аккаунтов в сети Ethereum:
\n\n
- Обычный аккаунт. В среде Эфириум они получили название Externally owned account (EOAs). Чтобы обзавестись локальным аккаунтом требуется лишь скачать в сети протокол, и позже создать приватный ключ.
- Контракт. Отличается от EOAs наличием собственного кода, выделенной памяти, а также возможности внесения изменений и управления посредством кода.
\n
\n\n
Объединяет аккаунты и контракты то, что они в полной мере подходят для хранения эфира. Но, контракт не может начать работать без обычного аккаунта. У контрактов есть возможность сотрудничать с другими контрактами, но это ничто иное, как internal transaction. Точнее говоря, это внутренние контракты, создающиеся аккаунтом внешнего плана.
\n\n
Компьютер можно смело назвать мертвым, если пользователи не прибегают к EOAs транзакциям в сети Эфириум. Ситуация не меняется. Исключительно обычные аккаунты имеют возможность заставить виртуальную машину начать работать. Разнообразие возможностей велико: отправка транзакций с одного аккаунта на другой, а также биткоин переводы. Для отправки биткоинов требуется запустить контракт и выбрать функцию, предназначенную для старта другого контракта. Такое возможно лишь в случае, если обычным аккаунтом был вызван первичный контракт.
\n\n
С этим следует разобраться основательно. Ведь из-за этого часто появляются проблемы. Многие создают контракты, позже обращаются к внешнему миру, где находят требуемые сведения, интегрируют их к себе, а после уведомляют сообщество. Такое не допускается.
\n\n
Bytecode: умный контракт и его особенности
\n\n
Существуют контракты в Эфириум Блокчейне в бинарном виде (Virtual Machine bytecode). Их создание осуществляется на языке программирования Solidity. После этого происходит компиляция контракта и получение машинно-независимого кода первичного уровня — bytecode из основного.
\n\n
Bytecode хранится в Эфириум Блокчейне. Исходный код контракта туда не отправляется и не является местом его хранения. Существуют декомпиляторы, но их количество невелико.
\n\n
Bytecode был создан, и далее используется команда «Создание контракта», которая отправляет контракт в сеть Эфириум. После этого bytecode обзаводится уникальным адресом.
\n\n
Как обычный аккаунт, так и контракт обладают неотличимыми адресами. По внешнему виду сложно понять, что удалось получить — контракт или EOA. Выяснить это возможно, лишь обратив внимание на блокчейн. В случае с контрактом будет иметь место транзакция на создание. Ведь первое, что отражается в Эфириум Блокчейне — это транзакции с обычными аккаунтами вида Creation Contract. Тут же возникает адрес у контракта. Если на глаза попалась такого рода транзакция, то становится понятно, что это контракт.
\n\n
Abi: умный контракт и его особенности
\n\n
При наличии исходного кода достаточно лишь компилировать его, чтобы получить bytecode. Он автоматически отправится на хранение в блокчейн. Есть те, кто считает, что достаточно ввести этот адрес в строку, чтобы приступить к работе с ним. В действительности все иначе. Панель управления (интерфейс) контрактом к сохраненному bytecode не отправляется на хранение в блокчейн Эфириума. При компиляции контракта возникает переменная с abi (Application Binary Interface) с байткодом. Это и есть панель управления, которая должна быть отправлена тому, кто будет пользоваться контрактом. Можно работать вручную с контрактами, обмениваясь друг с другом файлами.
\n\n
Соответственно, требуется указать abi к нему и адрес. Лишь после этого возникает возможность увидеть, какими функциями и переменными он обладает, а также содержимым. К личному проекту abi должен быть запрошен в HTML. Он должен быть сохранен отдельно от блокчейна, что весьма важно.
\n\n
Gas: умный контракт и его особенности
\n\n
Под данным контрактом понимается метрика операций и вычислений, предназначенных для записи информации в Эфириум Блокчейн.
\n\n
В чем его назначение? Сеть Эфириум должна иметь мощность вычислений ниже, чем у среднего компьютера, который работает в сети. Связано это с перевыполнением вычислений каждым пользователем. Допустим, возникло неограниченное количество самых разных вычислений. Создается контракт с нелимитированным циклом. Максимум вычислений отсутствует, что очень скоро приведет к перевыполнению памяти, а это, в свою очередь, к отключению нодов. Аналогичного плана ситуация произошла в Шанхае на Devcon2. На первой лекции собралось множество людей. Кому-то из участников посчастливилось найти ошибку. Она не могла преодолеть газ и приводила к перевычислению, а также к переполнению памяти. Окончилось все тем, что машины на конференции просто перестали функционировать.
\n\n
Для того, чтобы исключить данного рода проблемы, была разработана внутренняя метрика Gas. Она же является системой ограничений и элементом защиты безопасности основного компьютера, который должен поддерживать бесперебойную работу всего сообщества Эфириум.
\n\n
Gas обладает экономическим стимулом. Допустим, в биткоине оплата осуществляется в биткоинах. Сумма в этой криптовалюте фиксированная, но она может быть повышена, что автоматически приведет к повышению ранжирования на проведение транзакции. Почему у них все настолько просто? Причина выражается в том, что каждая транзакция в биткоине обладает одинаковой сложностью вычислений. Каждый знает, сколько требуется отправить с одного компьютера на другой по вычислительным мощностям. В Эфириуме немного все иначе. У пользователей есть возможность создавать любого плана контракты, но в конечном итоге сложно сказать о том, что будет делать контракт. Новые контракты могут быть наделены функциями самого разного плана.
\n\n
Вот как раз для защиты компьютера и создания системы, которая будет иметь ценность, был разработан газ.
\n\n
Сложность у каждого вычисления различная (более подробно об этом поведал Гэвин Вуд в Yellow Paper). Определенной операции присуща своя сложность. В связи с этим была разработана схема, показывающая, сколько требуется газа для проведения операций с той или иной сложностью. При создании контракта газ становится байткодом, и появляются опкоды, которые требуется ему выполнить. В соответствии с этими параметрами количества выполняемых опкодов, указывается стоимость в газе: какой объем вычислений необходим в EVM, чтобы появилась логика, заложенная в контракте.
\n\n
Перед созданием контракта можно будет понять, какое количества газа требуется для его работы. Всем тем, кто планирует разработать контракт, рекомендуется для начала рассчитать по таблице количество газа для каждой функции. После этого провести стресс-тестирование и протестировать каждую функцию, чтобы убедиться в том, что она расходует то количество газа, которое было определено заранее. Возможно, что в результате теста удалось обнаружить функции, потребляющее много газа. Избавиться от них следует тут же. Они попросту не смогут существовать.
\n\n
К примеру, на Эфириуме был запущен SatoshiDice. Является рядовым гемблинг-проектом. На нем использовался рандом, в результате которого участники могли проиграть или выиграть. Разработчики проекта задействовали цикл по увеличению количества ставок. В результате этого объем операций в одном цикле дошел до лимита блока сети, и было заморожено несколько тысяч эфиров. Ситуация неприятная, но ее можно избежать, если создать таблицу, где будет отображено количество газа. Несколько раз создаем контракт, и такое же количество задействуем каждую функцию. Если расход газа остался на прежнем уровне, то контракт можно считать удачным. В ином случае придется пересмотреть функции.
\n\n
Как работает механизм ранжирования
\n\n
Gas — это не сумма в эфирах, которую должен пользователь. Это компонент механизма ранжирования, представленный ограниченным количество газа в блоке и неограниченным количеством участников, желающих разместить в нем свою транзакцию.
\n\n
При наличии газа и метрики необходимо воплотить в реальность приоритетность и ранжирование. На первый взгляд проще считать людей, отправивших транзакцию первыми, но в децентрализованных сетях такое не работает. Ведь это не обладает экономическим стимулом, когда майнингом блоков занимается множество майнеров.
\n\n
При отправке транзакции, требуется определить, сколько вэев (составная часть эфира) будет уплачено за один газ. Лишь это гарантирует поселение в блоке.
\n\n
На Devcon2 многие пользователи начали возмущаться выводом нодов из строя. В результате этого были проведены некоторые доработки, а лимит газа в блоке ограничен до 1 миллиона. Стоимость рядовой транзакции составляет 22 тысячи газа. Чтобы уверенно попасть в блок, биржи начали платить значительно больше вэев за один газ. Соответственно, первыми стали добавляться в блок транзакции, за которые майнерам полагалось наиболее крупное вознаграждение.
\n\n
Для попадания в блок необязательно без меры поднимать стоимость единицы газа. Достаточно лишь создать приложение, которое будет анализировать среднее количество газа, гарантирующее попадание в блок.
\n\n
От сложности контракта зависит его стоимость.
\n\n
О примере с бесконечным циклом
\n\n
Был создан бесконечный цикл в контракте. На первый взгляд, кажется, что майнеры откажутся его проводить. В действительности все иначе. Они проведут контракт, но немного иным образом.
\n\n
Как функционирует блок у майнеров? Появляются транзакции, которые подвергаются ранжированию, далее настает время вычислений. За них майнер получает вознаграждение. Допустим определенной функции нужно намного больше газа, чем есть в одном блоке. Майнер прокрутит контракт, за что получит вознаграждение, но из-за недостатка газа пометит его как out of gas. Контракт останется прежним. В нем не произойдут какие-либо изменения. Получается, что майнер получил вознаграждение за то, что довел вычисления до состояния реверт.
\n\n
У майнеров есть локальная возможность корректировать лимит газа, но не более чем на 0,09% в одном блоке. Если возникнет новая версия или заплатка, что приведет к изменению газа, то он повысится лишь с течением времени. Если сказать точнее, то повышение будет происходить с каждым новым блоком на 0,01%. В результате этого нагрузка на сеть снижается.
\n\n
Метрика это газ, но не прямо-таки fee. Требуется указать сколько пользователь готов внести за выполнение того или иного вычисления глобальным компьютером Эфириум. Для указания суммы используется внутренняя валюта. Все должно подвергаться предварительному расчету. Блокам присущ лимит газа, который может незначительно повышаться. С каждым новым блоком количество газа может быть уменьшено или увеличено, но строго в заранее установленных рамках.
\n\n
Таким образом выглядит компилированный контракт в консоли.
\n\n
\n\n
Хранение первого кода осуществляется в данном виде. Можно будет узнать в дальнейшем язык, использованный для компиляции, а также версию компилятора. По этой причине abi лучше сохранить уже отдельно.
\n\n
Эфириум блокчейн и инструменты для работы с ним
\n\n
Клиент №1: Geth
\n\n
https://github.com/ethereum/go-ethereum
\n\n
Geth — это первый клиент, который был запущен во Frontier Release.
\n\n
Применяется многими пользователями, являясь интерфейсом командной строки протокола Эфириум. Клиент прост в использовании. Рядовая утилита для консоли. Добавляет ему плюсов язык Go.
\n\n
Geth является надежным клиентом. С 2014 по 2017 год увидело свет порядка 120 релизов.
\n\n
Применение клиента: Api and Interfaces
\n\n
- Command line options
- Javascript Console
- Server RPC JSON
- RPC JSON API
- Библиотека Dapp API web3 JavaScript
\n
\n\n
Пример отправки контракта в сеть Ethereum
\n\n
\n\n
Parity
\n\n
Существует два типа клиентов:
\n\n
- Для поднятия сетки с выделенными узлами, обладающими правами внесения изменений в blockchain (Proof of authority)
- Работают с публичными нодами Эфириума
\n
\n\n
Основан на языке Rust
\n\n
Около 70% майнеров приходится на Parity. Его работе присуща стабильность, но Geth также является хорошим клиентом.
\n\n
Parity — это детище Гэвина Вуда, трудящегося в Ethcore. Некоторое время назад он перестал работать вместе с Виталиком Бутерином и посвятил себя Ethcore. Разрабатывается этот проект весьма успешно. Был представлен миру в 2016 году.
\n\n
Parity: API and interfaces
\n\n
Обладает Parity режимом совместимости с Geth, но в действительности не работает
- Dapp API web3 JavaScript
- Parity JavaScript Dapp API (+web3)
- JSON RPC API
\n
\n\n
Ethereumj
\n\n
Своему появлению Ethereumj обязан команде Hack.ether.camp
\n\n
При наличии интереса к клиенту на Java, допускается его дописывание своими силами. Чуть более 30 релизов появилось с сентября 2014 года.
\n\n
Ethereum Wallet & Mist
\n\n
Являются прикладными решениями, которые использует в своей работе сообщество. Уже канул в прошлом Ethereum Wallet. Его создатели работают с Mist. Что касается Mist, то это браузер, обладающий библиотекой web3. Идет в комплекте с Geth нодой. Как только запускается Mist, тут же начинает свою работу и Geth. Он с ним синхронизируется.
\n\n
Заходя на ресурс, где имеется поддержка web3, он автоматически показывает балансы, которые можно использовать тут же, а также возможности, присущие Эфириум протоколу. Последний работает на машине пользователя.
\n\n
Не рекомендуется использовать: Electron+Meteor
\n\n
MetaMask
\n\n
MetaMask — плагин для браузера Chrome
\n\n
Дает возможность запускать Dapp, исключив полную ноду на клиенте.
\n\n
Автоматически возникнет приватный ключ, если будет решено попросить клиента установить MetaMask. Он получает RPC-канал для подключения к нему. Теперь он сохранен в инфраструктуре. О выкачке блокчейна речь не идет.
\n\n
Коммуникация с полной нодой посредством JSON RPC API
\n\n
Реализован на JavaScript
\n\n
Умный контракт как он есть
\n\n
В наличии 1 токен. Его можно задействовать для проведения эмиссии, что и станет его функцией. Достаточно указать: какому адресу необходимо исполнять данную эмиссию и создать функцию, предназначенную для смены того, кто может корректировать данную эмиссию.
\n\n
Рассмотрим сценарий системы энергетического плана, которая нуждается во внутренней единице. Access Control List. В наличии Smart Contract, предназначенный для создания групп и указания адресов участников группы. Эмитентом будет указан не адрес-аккаунт, а ACL. Создаем несколько солнечных панелей. При выработке энергии этими панелями, автоматически будут выпускаться токены.
\n\n
Аналогичный принцип подходит и для иных проектов, где требуется выпуск токенов многими участниками, а не одним.
\nЕще имеют место проекты, где трудится масса участников. Они создают сервер, устанавливают на него защиту, оснащают отдельными ключами и многим другим. На это уйдет много времени и это нет смысла делать, так как проще сразу задействовать группу ACL. Останется лишь определить тех, кто имеет право вносить адреса и заниматься эмиссией.
\n\n
Репозиторий Airalab на Github
\n\n
Это и есть контракты: https://github.com/airalab/core, разделенные по типу.
\n\n
Обладает директория token различными видами токенов:
\n\n
- TokenEmissionACL. Обладает ACL;
- Токен, не предполагающий эмиссии. Он создается единожды и после используется неограниченное количество времени;
- TokenEmission. Здесь допускается эмиссия.
\n
\n\n
С каждым из перечисленных токенов можно начать работать прямо сейчас.
\n\n
Возможно, что стоит задача создать систему для голосования. Для этой цели требуется использовать контракт Congress, который можно найти в директории foundation.
\n\n
Умный контракт для рынка можно отыскать в директории market. Его особенность заключается в возможности взаимодействия с токенами.
\n
