нНаша задача заключается в том, чтобы создать родственную для Эфириума сеть, которая расширит возможности, предоставляемые экосистемой виртуальной машины Эфириума (EVM). Для этого DFINITY должен привнести нечто большее, чем наши новые сетевые протоколы и криптография, которые, мы надеемся, тоже будут востребованы Эфириумом. В качестве комплимента Эфириуму и для расширения возможностей, предлагаемых его экосистемой, DFINITY вводит фундаментально отличное управление посредством новейшей децентрализованной системы принятия решений под названием «Blockchain Nervous System» («Нервная система блокчейна»), или BNS.

В рамках проекта были разработаны такие новые методики, получающие всё большее признание, как пороговое реле (Threshold Relay), валидационные башни (Validation Towers), валидационные деревья (Validation Trees) и USCID (Unique State Copy IDs) (идентификационные данные уникальных состояний). Многие из этих разработок полностью меняют правила – например, цепочки порогового реле повышают безопасность, обеспечивая в 50 раз более высокую скорость, чем сегодняшний Эфириум, что значительно улучшает обеспечиваемый распределёнными приложениями (Dapps) пользовательский опыт.

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

СОВЕТ: если вас уже не нужно убеждать в необходимости «нервной системы блокчейна», вы можете перейти сразу к разделу «Как это работает».

Проект децентрализованной платформы, авторы которого стремятся создать экосистему, хорошо сочетающуюся как с Ethereum, так и с его корпоративными клонами. Dfinity ICO является попыткой реализации так называемого «децентрализованного облака» — среды, в которой будут выполняться смарт-контракты Эфириума.

Команда разработчиков

Известно, что за проектом стоит DFINITY Stiftung — некоммерческий фонд в Цуге (Швейцария). По состоянию на апрель 2017 года ему принадлежали активы проекта в размере около $10 млн. Реализацией проекта занимается большая группа специалистов по компьютерным наукам и математике, криптографии, техническим новинкам и т. д.

Команда разработчиков и советников включает 35 человек, в том числе:

• Доминик Уильямс (президент и главный научный сотрудник, криптотеоретик и предприниматель, специалист по пороговому реле и цепям PSC, ранее руководил созданием MMO-игры с использованием собственных распределенных систем, которая привлекла миллионы пользователей).
• Тимо Ханке (руководитель инженерного отдела, ранее был профессором математики и криптографии в Аахенском университете в Германии, но затем увлекся Биткоином, в 2013 году он создал AsicBoost для повышения эффективности добычи Bitcoin на 20-30%, который затем стал стандартом для крупномасштабных майнинговых операций).
• Бен Линн (старший научный сотрудник и инженер, криптограф, ранее занимался технологиями в сфере безопасности, скорости и масштабирования публичных блочный сетей, имеет около 10 лет опыта работы на руководящих инженерных должностях в Google).
• Андреас Россберг (старший научный сотрудник и инженер, ранее был инженером по персоналу в Google, где участвовал в разработке виртуальной машины WebAssembly и возглавлял команду разработчиков JavaScript, работавшую над движком Chrome V8, является автором множества научных работ).
• Махнуш Мовахеди (старший научный сотрудник и инженер, ранее занимал должность постдокторанта в Йельском университете, работал над масштабируемыми и отказоустойчивыми распределенными алгоритмами для достижения консенсуса и безопасного многопартийного вычисления, конфиденциального обмена и интерактивной коммуникацией).

Основные цели и особенности Dfinity

Согласно исследованию, в настоящее время более 82,6% населения в мире используют компьютер. Каждый из ПК работает на разных типах операционных систем, таких как Windows, Linux, Dos и т. д. Однако любой компьютер и операционная система имеют определенные границы. У них есть ограничения по использованию технологий, которые пользователь не в состоянии пересечь. Пользователь может регулярно использовать компьютер в повседневной жизни, но не способен выходить за пределы операционной системы.

Авторы Dfinity предлагают создать компьютер без границ, для которого рамки той или иной операционной системы не будут иметь значения. Именно поэтому они называют свою идею децентрализованной InFINITY («бесконечность»).

Dfinity представляет собой блочный компьютер с неограниченной пропускной способностью, повышенной вычислительной способностью и алгоритмическим управлением. Разработчики создали новый вид публичного децентрализованного ресурса облачных вычислений. Он работает на новом блочном компьютере, который аналогичен концепции Ethereum, но имеет расширенную производительность, а в конечном счете должен получить неограниченную емкость.

Бизнес-приложения, которые будут работать на этом компьютере, не будут включать такие сложные компоненты, как базы данных, системы резервного копирования и восстановления или веб-службы Amazon. Это сократит расходы вычислительных ресурсов на 90% за счет привлечения необходимого человеческого капитала, но столь мощный общественный ресурс также будет нуждаться в управлении.

Как Dfinity может решит современные вычислительные проблемы?

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

Dfinity использует цепочки Threshold Relay для ограничения текущих ограничений. Сама сеть рассчитана на масштабирование для обработки неограниченного количества вычислений. Это позволит ей даже на начальной стадии развития обеспечить существенный рост технических возможностей без необходимости внедрения дополнительной системы масштабирования.

Это достигается благодаря тому, что цепочки пороговых реле не связаны с «пуассоновским процессом» систем на базе алгоритма Proof-of-Work, и майнеры могут осуществлять проверки транзакций без ущерба для коммерческих целей.

Ключевые особенности

Перечень основных отличий Dfinity от других блочных сетей включает:

Высокий уровень производительности

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

В системе Dfinity для осуществления транзакции потребуется всего лишь 2 подтверждения и 5-10 секунд времени. Для сравнения: в блокчейне Bitcoin транзакции проводятся в течение около 60 минут после 6 подтверждений, а в сети Ethereum — за 10 минут после 37 подтверждений.

Интероперабельность

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

Самоуправление

Dfinity предусматривает использование алгоритмического управления Blockchain Nervous System (BNS), которое может защитить пользователей от атак и помочь перезапустить сломанные системы, динамически оптимизировать сетевую безопасность и эффективность, обновить протокол и смягчить риски злоупотребления платформой.

Интернет 3.0

Разработчики охвачены идеей создания нового вида публичного децентрализованного ресурса облачных вычислений. Их цель — создание интернета 3.0, в котором вся сеть будет действовать как единый гигантский компьютер с радикально новыми свойствами.

IT-системы предприятий, работающие на этом компьютере, будет невозможно остановить.

Защита пользователей

На платформе Dfinity будет действовать правило — «Код является законом». Это означает, что все будет зависеть от решений «нейронной» системы.

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

Основная цель встроенной в Dfinity функции BNS — вернуть средства там, где это возможно, и обратить вспять ущерб от взлома. BNS также может вносить правки в системы, которые просто потерпели неудачу из-за инженерных ошибок.

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

Система управления Dfinity

На платформе будет использоваться децентрализованный интеллект (DI), способный совершать произвольные изменения. Это помогает снизить уровень злоупотребления и защитить пользователей, решить проблемы, связанные с оптимизацией конфигурации сети и легко обновлять протоколы.

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

Создание единой экосистемы

На сегодняшний день приватные локальные сети могут подключаться к общественным сервисам в интернете. Однако отдельные облачные сети, созданные с использованием технологии Ethereum, изолированы. Их смарт-контракты не способны взаимодействовать с другими публичными сетями. Авторы Dfinity стремятся преодолеть эту проблему.

Платформа позволит программным методам, вызываемым на самом высоком уровне в приватных системах, контактировать с публичной сетью Dfinity. Затем система будет гарантировать выполнение как приватных, так и публичных методов, или невыполнение ни одного из них.

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

Период и условия проведения Dfinity ICO

Официальный сайт: https://dfinity.org/

На момент написания обзора официальная информация о проведении основного этапа ICO не была доступна. Однако в мае разработчики провели успешный airdrop для ранних сторонников на общую сумму около $35 млн. Токены планируется раздать в 4 квартале 2018 года.

Также авторы проекта сообщили на своей странице в Twitter о планах по продаже 10% токенов на сумму $350 млн.

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

Между тем, многие важные сведения о проекте (в том числе дорожная карта) пока отсутствуют в технической документации, и разработчики даже не пытаются это объяснить. На самом деле в «Белой книге» проекта практически нет стоящей информации, связанной с реальным процессом разработки платформы.

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

После того, как Ethereum стал логичным продолжением развития Bitcoin, он получил огромную популярность и завоевал абсолютную часть рынка ICO. Как и Bitcoin у Ethereum есть свои парадигмы, которые взяты за основу всей сети. Одна из таких ключевых парадигм, «Протокол — это закон». Это означает, что нет никакого интеллектуального управления, регулирующего использование платформы или базовую сеть, вследствие чего происходят хардфорки и софтфорки, когда возникает какая-либо угроза.

А теперь представьте себе сеть третьего поколения, в которых все существующие криптографические технологии и протоколы стали совершенны и способствуют бесконечной скорости. Сеть, в которой существует новая парадигма «Искусственный Интеллект(ИИ) – это закон». Безопасность такой сети будет основана на голосованиях участников сети и традиционных механизмах ИИ, которые способны мгновенно вычислять уязвимости, а в случае проникновения безболезненно «откатывать» сеть назад. Такая сеть позволяет динамически оптимизировать экономические параметры сети, проводить обновления протоколов и различных приложений, без нарушения работы системы. Именно в блокчейне третьего поколения извечная проблема масштабируемости и скорости транзакций будет окончательно решена, что позволит использовать его неограниченным количествам пользователей и приложений.

Если вам удалось хоть немного представить себе вышеописанную глобальную сеть, поздравляю вас, теперь вы немного знакомы с проектом Dfinity.

Суть и смысл

Прежде чем углубляться в то, как работает «нервная система» DFINITY, рассмотрим некоторые из событий и потребностей, которые привели к её созданию.

1. Mt. Gox, Bitfinex и другие случаи хищения токенов

Я считаю, что истории c Mt. Gox и Bitfinex – заслуженные шрамы для криптографического сообщества, однако из них необходимо сделать выводы. На мой взгляд, взлом Bitfinex, безусловно, был хуже всех. Сегодня, с помощью программ анализа блоков, можно наблюдать за движением украденных биткойнов на сумму более 100 млн долларов по блокчейну, но прежним владельцам их вернуть невозможно. Между тем, Bitfinex даже не опубликовали анализ безопасности с объяснением произошедшего, что дурно пахнет, однако кто знает, что произошло на самом деле. Дело в том, что, при хищении большого количества токенов из систем, работающих по принципу «код есть закон», как Биткойн или Эфириум, единственный способ исправить эту ситуацию – это хард-форк из предшествующей краже точки. Но это, как правило, слишком сложно исполнить, либо оборачивается причинением значительного ущерба сообществу.

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

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

Ясно, что Blockchain Nervous System (BNS), с привилегированным правом контроля принадлежности токенов, может служить по крайней мере одной цели.

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

2. DAO и уязвимые системы

Кто бы что сейчас ни говорил, DAO, несомненно, был одним из самых захватывающих финансовых экспериментов в истории. Люди со всего мира инвестировали токены в децентрализованный фонд, расположенный в киберпространстве. В общей сложности, этот фонд собрал 14 % всего эфира, существовавшего на тот момент, одновременно продемонстрировав, насколько огромным может стать спрос на ETH, и, вместе с тем, создав огромный риск для экосистемы. Однако я тогда был в лагере скептиков – не потому, что я не верил в концепцию DAO как таковую, а потому, что структура проекта содержала многочисленные недочёты с точки зрения теории игры, достаточно очевидные для разработчика протокола (несколько старых постов: 1, 2, 3). И всё же, губительными оказались не эти тонкие недостатки, но куда более прозаичные ошибки в коде: в программное обеспечение DAO был включён непроверенный код, не учитывающий возможность атак повторного входа.

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

Ко времени взлома DAO, концепция Blockchain Nervous System уже приняла достаточно ясные очертания, а после взлома работа над ней ускорилась многократно. Пользуясь привилегированным доступом к сети, BNS может инициировать исполнение произвольного кода с целью исправления взломанных систем, таких, как DAO.

3. Ускоряющаяся эволюция

Несколько лет назад я запустил MMO (массовую многопользовательскую онлайн) игру. Со временем, количество пользователей в ней достигло трёх миллионов. Я тогда жил в Великобритании, а не в Пало-Альто, и хотя, в конце концов, мне удалось привлечь венчурные инвестиции (после достижения отметки в миллион пользователей), всю работу на раннем этапе проделал я с небольшой командой, практически без денег. Ввиду ограниченности ресурсов, наши действия были обусловлены необходимостью продвигаться в наших исследованиях настолько эффективно, насколько это возможно, и горизонтально масштабировать наши технические системы предельно экономно и только в случае необходимости. В отношении исследовательской работы это означало, что, по большей части, мы были вынуждены полагаться на непроверенные решения и выкатывать значительные изменения без всестороннего тестирования и вспомогательных серверов.

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

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

Blockchain Nervous System может помочь нам решить эти задачи посредством управления протоколом и обновления программного обеспечения. Базовую реализацию сделать достаточно просто. Вместо того, чтобы подключать Dapps к Geth или Parity (два популярных клиента для Эфириума) напрямую, DFINITY добавляет между ними специальное программное обеспечение для инвертированного прокси-сервера и подключает Dapps к нему. Прокси получает сигналы от Blockchain Nervous System и следует его командам в отношении обновлений протокола. Когда блокчейн решает, что в некоем будущем блоке должно произойти обновление, он загружает инсталлятор клиентского программного обеспечения из сети BitTorrent, IPFS или Swarm по указанному хэшу. В нужный момент прокси временно накапливает запросы в буфере и автоматически обновляет клиентское приложение, не прерывая работы связанных с ним Dapps и не мешая их пользователям (факт обновления и его содержание от пользователей не скрываются).

Конечно, обновления BNS потребуют намного больше внимания, чем мы уделяли релизам моей MMO-игры. Серьёзные ошибки могут повлиять на состояние виртуального компьютера, а также на способность BNS принять решение об откате на последнюю рабочую версию. Тем не менее, поскольку «нервная система» DFINITY действует в пределах соответствующих допусков, мы делаем ставку на то, что обеспечение регулярных и прозрачных обновлений протокола без спорных хард-форков побудит разработчиков DFINITY осуществлять эволюцию значительно быстрее.

4. Больше безопасности и улучшенная экономика

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

В то время как участие систем Proof-of-Work (PoW) фундаментально опосредовано стоимостью электроэнергии, участие систем Proof-of-Stake (PoS) опосредовано стоимостью приобретения токенов сети. Проблема заключается в том, что, в то время как стоимость электроэнергии относительно стабильна, стоимость приобретения токенов сети буйно скачет вместе с их рыночной стоимостью. В квази-PoS системах, таких, как DFINITY, клиентские приложения для майнинга подключаются к сети, используя «майнинговое удостоверение», приобретаемое путём размещения залогового депозита в токенах. Опасность заключается в том, что, если во время обвала рынка цена токена резко падает, оппонент может недорого и более или менее безопасно контролировать сеть путём создания достаточного количества сущностей, обладающих «майнинговыми удостоверениями». В действительности, он мог бы даже намеренно вызвать обвал рынка с такой целью.

Колебание в цене родного токена сети представляет собой многоплановую проблему безопасности даже для сетей с PoW-доказательством, так как это влияет на стимулы участников сети. Мы считаем, что DFINITY имеет уникальную способность решать эти давние проблемы с помощью Blockchain Nervous System. Пользуясь привилегированным доступом к внутренним компонентам сети, BNS, по сути, может динамически изменять любые экономические параметры. Например, если цена токенов DFINITY резко падает, система может увеличить размер требуемого залогового депозита, а если ситуация не изменится, она может также увеличить вознаграждение за майнинг с целью повышения собственной устойчивости. Теоретически, она может даже предотвратить избыток майнеров, сократив выдачу новых «удостоверений» и собрав заявителей в пул ожидания.

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

5. Убийство рынка заказных убийств и пр.

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

Взять, например, рынки заказных убийств. Некоторые радикальные криптоанархисты выступали в их поддержку, говоря о том, что наличие таких рынков может удерживать под контролем поведение людей в децентрализованном мире. Лично я с этим не согласен. На мой взгляд, куда более вероятно, что они будут использоваться злыми людьми просто для устранения конкурентов. Но какого бы мнения вы не придерживались, в одном можно быть уверенным: правительства будут жёстко реагировать на подобные вещи, включая невольничьи рынки ИГИЛ (организация запрещена территории РФ), сервисы обмена детской порнографией и другие очевидно отвратительные вещи. Как разработчики протокола, мы стремимся создать сеть, которую невозможно остановить, чтобы она выдержала атаку даже правительственных спецслужб, однако сам факт существования такого рода систем может спровоцировать принятие согласованных международных ограничительных мер, что значительно снизит способность открытых блокчейнов быстро воплотить в жизнь свой невероятный потенциал.

Blockchain Nervous System предлагает решение этого противоречия. Напомню, что главная цель BNS заключается в максимизации стоимости токенов участия в сети DFINITY, таким образом, ею движет невидимая рука рынка. Имея абсолютный контроль над сетью, она может блокировать работу размещённых на ресурсах сети систем, которые, по данным BNS, причастны к атакам, подвергать их пользователей чрезвычайному регуляторному давлению либо исключать массовых пользователей из совместного хостинга. Решения будут основываться на компромиссах. Если BNS будет вести себя чересчур ограничительно, слишком непредсказуемо или деспотично, несправедливо закрывая маргинальные системы, многие пользователи откажутся от участия в сети. Мы делаем ставку на то, что рука рынка поможет DFINITY находить оптимальный баланс.

Описание ICO DFINITY
DFINITY — это общедоступная сеть клиентских компьютеров, обеспечивающая «децентрализованное глобальное вычислительное облако», где программное обеспечение может быть установлено и запускаться со всеми обычными преимуществами, ожидаемыми от систем «умного контракта», размещенных на традиционной блочной цепочке

Основная информация о ICO DFINITY
Категория: Облачное хранение данных
Сайт: https://dfinity.org/
Страна команды: США
Подробная инфа: WhitePapper
Видео о ICO DFINITY

Социальные сети ICO DFINITY

Информация о токене TBA
Тикер: TBA
Даты продаж: 12.02.2017 — 13.02.2017
Тип токена: Own wallet
Доступно к продаже: 4%
Мин. цель сбора: 1 000 000 USD
Макс. цель сбора: 1 000 000 USD
Собрано средств на Pre-ICO: 4 000 000 USD
Валюты: ETH

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

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

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

Многие из тем, затронутых в данной статье, представляют собой разжевывание тех основных понятий, с которыми вы, вероятно, уже не раз сталкивались, читая yellow paper (от англ. «желтая бумага» – официальная спецификация для Эфириума). Мною были добавлены собственные пояснения и диаграммы для того, чтобы вы как можно быстрей разобрались с данной технологией. Ну, а для самых храбрых и технически подкованных я могу посоветовать прочтения Ethereum yellow paper.

Что такое блокчейн

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

• «Криптографически безопасный» означает, что безопасность криптовалюты обеспечивается сложными математическими алгоритмами, которые практически невозможно обойти. Защита, выстроенная с помощью данных алгоритмов, представляет собой подобие файрвола: благодаря используемым алгоритмам обход системы безопасности практически невозможен (например, невозможно создание поддельных транзакций, уничтожение транзакций и т. д.).
• «Транзакционная одноэлементная система» означает, что существует только одно заданное состояние системы, благодаря которому происходят все транзакции, создаваемые в данной системе. Другими словами, для данной системы предусмотрено только одно состояние, которое является единственно верным.
• «С общим состоянием» означает, что состояние, заданное в системе, является общим и открытым для всех.

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

ПАРАДИГМА БЛОКЧЕЙНА ПЛАТФОРМЫ ЭФИРИУМ

Блокчейн Эфириум является, по сути, системой состояния транзакций. В информатике такое понятие, как «система состояний» или «машина состояний» – это система, которая обрабатывает вводимую информацию и на основании последней преобразуется в новое состояние.

В машине состояний Эфириума все процессы начинаются с «первоначального состояния». Такое состояние представляет собой аналог нулевого состояния, в котором находится машина до того момента, как в ее сети начнут происходить какие-либо действия, связанные с транзакциями. Когда такие действия начнут происходить, первоначальное состояние заменяется на конечное, при этом в любой момент времени конечное состояние отображает текущее состояние Эфириума.
Состояние Эфириума имеет миллионы транзакций. Эти транзакции сгруппированы в «блоки». Блок содержит ряд транзакций, при этом каждый последующий блок соединен с предыдущим, благодаря чему обеспечивается своеобразная цепочка блоков.

Транзакция должна быть корректной, для того чтобы вызвать ее переход из одного состояния в другое. Транзакция считается корректной только тогда, когда она прошла процесс проверки – так называемый «майнинг». Майнинг — это когда группа узлов (компьютеров) расходует свои вычислительные ресурсы для создания блока корректных транзакций.

Любой узел в сети, объявляющий себя майнером, может попытаться создать и проверить блок транзакций. Распространенным опытом является попытки множества майнеров одновременного создания и проверки блока транзакций. Каждый майнер предоставляет свое математическое «доказательство» при отправке блока в блокчейн, и это доказательство выступает в роли своеобразной гарантии: в случае если доказательство существует, транзакции в блоке считаются корректными.

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

Майнер, который обосновывает новый блок, получает определенное вознаграждение за выполнение этой работы. О каком вознаграждении идет речь? В блокчейне Эфириума используется встроенный цифровой токен, который носит название «эфир» (от англ. ether— «эфир»). Каждый раз, когда майнер обосновывает свой блок транзакций, создается новый токен или новый эфир, а майнер получает вознаграждение за его создание.

Тогда, у вас может возникнуть вполне логичный вопрос: где гарантия того, что каждый майнер будет придерживается только одной цепочки блоков? Как мне убедиться в том, что другая команда майнеров не решит создать свою собственную цепочку блоков?

В самом начале данной статьи мы уже приводили такое понятие как «транзакционная одноэлементная система с общим состоянием». Исходя из такого определения можно сделать вывод, что не бывает двух и более корректных текущих состояний – оно является единственным в своем роде. Таким образом, каждый, кто принимает участие в процессе обоснования новых блоков, должен принять это утверждение за истину. Наличие нескольких состояний (или цепей) разрушило бы всю систему, потому что было бы невозможно договориться о том, какое из состояний является корректным. Например, представим, что существовало бы несколько цепочек блоков. Тогда, в теории, вы могли бы собрать 10 монет на одной цепочке, на другой – 20 монет, на третьей – 40 монет и т.д. В таком случае было бы невозможно определить, какая цепь является наиболее «корректной».

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

Чтобы определить, какой из возможных путей является корректным, и предотвратить образования множества цепей, в Эфириуме применяется метод, называемый «протокол GHOST».

GHOST – «Жадное-и-Самое-Весомое-из-Известных-Дочерних-Деревьев» (Greedy Heaviest Observed Subtree)

Попробую объяснить простыми словами: протокол GHOST объявляет, что мы должны выбрать только тот путь, на котором было выполнено наибольшее число вычислений. Для определения такого пути можно использовать номер того блока, который был определен последним («листовой блок»). Благодаря такому подходу можно определить общее число блоков, находящихся в текущем пути (без учета блока первоначального состояния). Чем выше находится блок, тем длиннее путь и тем больше обоснований должны предоставить майнеры. Исходя из таких соображений, принимается единственно верная версия для текущего состояния.

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

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

Небольшое отступление перед тем, как мы начнем: при упоминании хэша X имеется ввиду хэш KECCAK-256, используемый в Эфириуме.

Учетные записи

Глобальное общее состояние платформы Эфириум состоит из множества небольших объектов – учетных записей, которые взаимодействуют между собой за счет парадигмы обмена сообщениями. У каждой учетной записи есть определенное состояние и 20-байтовый адрес. Адресом в Эфириум является 160-битный идентификатор, используемый для идентификации любой из учетных записей.

Всего существует два вида учетных записей:

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

Внешние и контрактные учетные записи

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

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

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

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

Состояние каждой из учетных записей, вне зависимости от их типа, может принимать одно из четырех значений:

• nonce: Если настоящая учетная запись соответствует внешней учетной записи, то полученное число представляет собой количество транзакций, которые были отправлены с адреса учетной записи. Если учетная запись является контрактной учетной записью, то элемент nonce – это количество контрактов, созданных в данной учетной записи.
• balance: общее количество wei, приобретенных данной учетной записью. Например, каждый эфир, который является обменной единице Эфириума, содержит 10^18 wei – дробных частей эфира.
• storageRoot: хэш корневого узла префиксного дерева Меркла (что собой представляет дерево Меркла мы рассмотрим немного позже). Дерево Меркла кодирует хэш содержимого данной учетной записи, при этом по умолчанию оно является пустым.
• codeHash: хэш EVM-кода (от англ. Ethereum Virtual Machine; что это такое я расскажу немного позже) учетной записи. Для контрактных учетных записей данное поле является кодом, который хэшируется и хранится в виде codeHash.

Общее состояние системы

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

Дерево Меркла (или «Merkle trie») представляет собой тип двоичного файла, состоящего из набора узлов, которые включают:

• определенное количество листовых узлов, которые располагаются в нижней части дерева, содержащего базовые данные;
• набор промежуточных узлов, при этом каждый узел представляет собой хэш двух его дочерних узлов
• один корневой узел, также образованный из хэша двух дочерних узлов, который представляет вершину дерева

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

Для каждого значения, хранящегося внутри данного дерева, вам потребуется ввести определенный ключ. Для получения соответствующего значения, хранящегося в листовых узлах, вы должны получить команду ключа: цепочки какого дочернего узла необходимо придерживаться. Что касается Эфириума, то отображение ключа/значения, необходимого для дерева состояний, находится между адресами и связанными с ними учетными записями, в том числе balance, nonce, codeHash, а также storageRoot для каждой из учетных записей, при этом storageRoot является деревом.

Подобная структура префиксного дерева также может применяться для хранения как транзакций, так и страницы приема оплаты. Если останавливаться на этом более подробно, то каждый блок имеет так называемый «header» или заголовочный файл, в котором хранится хэш корневого узла трех разных структур дерева Меркла, в том числе:

• Состояние префиксного дерева
• Транзакции префиксного дерева
• Страницы приема оплаты для префиксного дерева

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

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

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

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

Любой узел, для которого требуется проверка какой-либо части данных, использует так называемое «доказательством Меркла». Последнее состоит из:

• Фрагмента данных, который должен быть проверен
• Корневого хэша дерева
• Так называемой «ветви» – всех хэшей, от проверяемого фрагмента данных до корня.

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

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

Горючее и вознаграждение

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

Горючее – это единица измерения, которая используется для определения размера оплаты по конкретному вычислению. Цена на горючее – это количество «эфира», которое вы способны потратить на каждую единицу горючего. Измеряется цена на горючее в «gwei». Wei является самой маленькой единицей эфира, где 1018 Wei –это всего 1 эфир. Один gwei равен 1 000 000 000 Wei.

Для проведения любой транзакции отправитель должен установить лимит горючего, а также цену на горючее. Цена на горючее и лимит горючего – это максимальная сумма в Wei, которую отправитель готов заплатить за проведение транзакции.

Давайте представим, что отправитель устанавливает лимит горючего в 50 000 gwei, а цену на горючее – в 20 gwei. Это значит, что отправитель готов потратить не более 50 000 х 20 gwei = 1 000 000 000 000 000 Wei или 0,001 эфира для проведения данной транзакции.

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

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

«Куда именно я отправляю горючее?» — спросите вы. Итак, все деньги, которые были потрачены на приобретение отправителем горючего, отправляются на адрес бенефициария, который в большинстве случаев является адресом майнера. Поскольку майнеры выполняют расчеты и проверку транзакций, то именно они получают плату за горючее в качестве вознаграждения.

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

Оплата за использование хранилища

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

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

Для чего предусмотрена оплата?

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

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

Вполне вероятно, что вы подумаете: «А я-то тут причем? Зачем я буду платить за использование хранилища?» Ну, что вам сказать, вся сеть Эфириума берет на себя плату как за вычисления, так и за использования хранилища…как-то так.

Транзакции и сообщения

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

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

Всего существует два типа транзакций: отправка сообщений и создание контракта (другими словами, такие транзакции создают новые контракты в сети Эфириума).

Все транзакции содержат следующие элементы, вне независимости от типа первых:

• nonce – количество транзакций, которые были отправлены отправителем.
• gasPrice – количество Wei, которое отправитель готов отдать за единицу горючего, необходимую для совершения сделки.
• gasLimit – максимальное количество горючего, которое отправитель готов заплатить за проведение данной транзакции. Такая сумма задается и оплачивается заранее, прежде чем какие-либо вычисления будут проведены.
• to – адрес получателя. На момент выполнения транзакции, связанной с созданием контракта, адреса учетной записи контракта еще не существует, поэтому вместо него используется пустое значение.
• value – количество Wei, которые будут переданы от отправителя к получателю. В транзакциях, связанных с созданием контрактов, данная величина является стартовым балансом для вновь созданной учетной записи.
• v, r, s – данные обозначения, используемые для создания подписи, которая идентифицирует отправителя транзакции.
• init – предназначен только для транзакций, связанных с созданием контрактов. Фрагмент EVM-кода, используемый для инициализации вновь созданной учетной записи контракта. init запускается только единожды и в дальнейшем не используется. Когда init запускается в первый раз, данный элемент возвращает тело кода учетной записи, которое представляет собой часть кода, постоянно связанную с учетной записью контракта.
• data – это входные данные (параметры) для вызова сообщения (data является необязательным элементом, который предназначен только для вызовов сообщений). Например, если смарт-контракт играет роль службы регистрации домена, то вызов этого контракта может ожидать поля ввода (например, домен и IP-адрес).

Из информации, приведенной в разделе «Учетные записи», мы выяснили, что транзакции – как для вызовов сообщений, так и для создания контрактов –инициируются внешними учетными записями, а затем перенаправляются в блокчейн. Другими словами, транзакции – это своеобразный мост, соединяющий внешний мир и внутреннее состояние платформы Эфириума.

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

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

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

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

Блоки

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

Такие блоки состоят из:

• заголовка блока
• информации о серии транзакций, включенных в данный блок
• серии других заголовков блоков для текущих оммеров

Что такое «оммеры»?

Давайте разберемся с тем, что такое оммер (от англ. «ommer»). Оммер – это блок, родителем которого является родительский элемент текущего блока. В этой главе я вкратце опишу, для чего вообще нужны оммеры, а также из каких соображений в блоке содержится заголовки блоков для оммеров.

Их наличие, в первую очередь, обосновано тем, что время блокировки в Эфириуме намного ниже (примерно 15 секунд), чем для других блокчейнов, например, для биткоинов (примерно 10 минут). Благодаря такой особенности скорость транзакций проведения увеличивается. С другой стороны, одной из негативных сторон более короткого времени блокировки является то, что борьба майнеров за очередное блочное решение только усиливается. Такие конкурирующие блоки еще называют «блоки без родителя» (т.е. такие блоки не входят в основную цепочку блоков).

Оммеры были созданы для того, чтобы майнеры могли получить заслуженную награду за включение блоков без родителей в основную цепочку. Оммеры, включенные майнерами в основную цепочку, должны быть «действительными»: они, оммеры, должны быть потомками в шестом или более раннем поколении текущего блока. Например, после шестого поколения такие потомки не могут быть включены в основную цепь в качестве блоков без родителя: более поздние транзакции могут негативно влиять на работу системы в целом.

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

Заголовки блоков

Я уже упоминал ранее о том, что каждый блок имеет заголовок, но мы так толком и не разобрались, что это такое?

Заголовок блока – это часть блока, которая состоит из:

• parentHash – является хэшем заголовка родительского блока (благодаря чему, собственно, блок попадает в цепочку блоков)
• ommersHash – хэш текущего списка блоков оммеров
• beneficiary – адрес учетной записи, на который поступает оплата за включение этого блока
• stateRoot – хэш корневого узла состояния префиксного дерева (ранее я писал, что состояние префиксного дерева хранится в заголовке, тем самым для тонких клиентов упрощается процесс утверждения состояния)
• transactionsRoot – хэш корневого узла префиксного дерева, содержащий все транзакции, которые перечислены в данном блоке
• receiptsRoot – хэш корневого узла префиксного дерева, который содержит информацию об оплате для всех транзакций, перечисленных в данном блоке
• logsBloom – Фильтр Блума (структура данных), состоящий из информации, содержащейся в журналах
• difficulty – уровень сложности текущего блока
• number – номер текущего блока (первоначальный блок имеет номер, равный нулю; номер блока увеличивается на единицу для каждого последующего блока)
• gasLimit – текущий лимит горючего для текущего блока
• gasUsed – общее количество горючего, используемого для транзакций в текущем блоке
• timestamp – временная отметка, предназначенная для создания текущего блока
• extraData – дополнительные данные, которые касаются текущего блока
• mixHash – хэш, который в сочетании с элементом nonce утверждает, что для текущего блока выполняется достаточно вычислений
• nonce – хэш, который в сочетании с элементом mixHash утверждает, что для текущего блока выполняется достаточно вычислений

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

• состояния (stateRoot)
• проведения транзакции (transactionsRoot)
• получения информации об оплате (receiptsRoot)

Такие структуры префиксного дерева являются ничем иным, кроме как префиксным деревом Меркла, которое мы уже рассматривали выше.

Кроме того, для такого определения существует несколько терминов, которые, вероятно, должны вам показаться интересными.

Журналы

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

Запись журнала включает:

• адрес учетной записи регистратора
• ряд задач, которые отображают различные события, выполненные для текущей транзакции
• любые данные, которые имеют отношение к данным событиям

Записи журналов хранятся в Фильтре Блума, благодаря которому появляется возможность эффективно хранить бесконечное количество данных.

Получение информации об оплате

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

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

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

Сложность блока – понятие, используемое для обеспечения согласованности времени, которое необходимо для валидации блоков. Для первоначального блока сложность составляет 131 072 единиц. Для вычисления сложности любого из блоков применяется специальная формула. В том случае если валидация одного из блоков произошла более быстро чем, например, валидация последующего, то протокол, используемый в Эфириуме, увеличивает сложность последнего.

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

Единственный способ определить параметр nonce, который будет отвечать представленному формуле условию, заключается в использовании алгоритма проверки работоспособности для поиска всех его возможных значений. Ожидаемое время поиска всех соответствующих данному условию значений – это и есть сложность блока. Тогда мы можем сделать вывод: чем большее значение сложности блока, тем сложнее найти параметр nonce, и, таким образом, тем сложнее провести валидацию блока, в результате чего, в свою очередь, увеличивается время, необходимое для валидации последующих блоков. Значит, на основании значения, полученного в ходе определения сложности блока, используемый протокол определяет, сколько необходимо времени для валидации текущего блока.

В том случае если время, требуемое для валидации блока, оказывается меньше, чем ожидалось, то протокол занижает сложность текущего блока. Таким образом, время, требуемое для валидации блока, задается автоматически для постоянного соответствия текущим параметрам (в среднем такое время составляет 15 секунд).

Проведение транзакций

Ну, что ж, вот мы и подошли к, пожалуй, самой сложной части протоколов, используемых в Эфириуме – проведения транзакций. Давайте представим, что вы задали в сети Эфириума выполнение какой-либо транзакции. И что по вашему мнению, будет происходить с состоянием Эфириума, при проведении вашей транзакции?

Во-первых, любая транзакция должна отвечать определенным требованиям, для того чтобы ее выполнение не было отменено, а именно:

• Транзакции должны отвечать требованиям RLP. RLP – это рекурсивная длина префикса (от англ. Recursive Length Prefix), представляющий собой формат данных, который используется для кодирования вложенных массивов двоичных данных. Формат RLP используется в Эфириуме для упорядочивания объектов.
• Наличие валидной подписи транзакции.
• Наличие валидного значения nonce. Напомню, что nonce – это количество транзакций, отправленных с текущей учетной записи. Для того чтобы такое значение было валидным, оно должно соответствовать значению nonce для учетной записи отправителя.
• Лимит горючего для транзакции должен быть равным или больше заданного количества горючего. Заданное количество горючего включает:

1. предопределенная стоимость, равная 21 000 единиц горючего, необходимого для выполнения транзакции
2. Плата за горючее, используемое для отправки данных об транзакции (4 единицы горючего за каждый байт данных или код, равный нулю, и 68 – за каждый ненулевой байт данных или ненулевой код)
3. Дополнительные 32000 единицы горючего, если транзакция связана с заключением договора

• Баланс текущего счета отправителя должен содержать достаточное количество эфира для покрытия «авансовой» стоимости горючего, которую отправитель обязуется оплатить. Авансовая стоимость горючего вычисляется следующим образом: лимит стоимости горючего умножается на стоимость горючего для текущей транзакции, в результате чего мы находим максимальную стоимость горючего. Далее, к максимальной стоимости добавляется общее количество горючего, переправляемого от отправителя получателю.

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

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

После этого начинается выполнение транзакции. В течение проведения текущей транзакции в Эфириуме происходит отслеживание «подсостояния». Подсостояние необходимо для записи информации, которая была собрана во время проведения текущей транзакции. Такая информация будет необходима сразу по завершении выполнения транзакции и содержит:

• Self-destruct set: набор учетных записей, которые будут удалены по завершении проведения транзакции
• Log series: заархивированные и проиндексированные контрольные точки, необходимые для выполнения кода виртуальной машины.
• Refund balance: сумму, которая должна быть возвращена отправителю по завершении транзакции. Я уже упоминал ранее, что использование хранилища, предусмотренного в Ethereum, стоит определенного количества денег, и эти деньги возвращаются отправителю после того, как он перестает использовать такое хранилище. В системе Ethereum сохраняется информация об использовании хранилища и возврата средств за его использование отправителю.

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

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

После завершения (удачного) транзакции и возврата горючего отправителю происходит следующее:

• определенное количество эфира, использованного для приобретения горючего, отправляется майнеру;
• горючее, использованное для проведения транзакции, записывается в блок для подсчета горючего (данный блок используется для хранения информации об общем количестве горючего, которое было использовано для проведения всех транзакций в данном блоке; кроме того, такой блок используется в течение валидации;
• вся информация об учетных записях, содержащаяся в разделе self-destruct set удаляется.

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

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

Создание контрактов

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

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

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

В момент, когда мы приступили к созданию новой учетной записи, мы, по сути, уже ее создали с помощью init-кода, который автоматически отправляется в начале транзакции (забыли, что такое init-код – смотрите раздел «Транзакции и сообщения»). Существует несколько вариантов развития событий в течение выполнения init-кода (например, может произойти: обновление хранилища для учетной записи, создание другой учетной записи для текущего контракта, отправка сообщения и т.д.).

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

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

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

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

Сообщения

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

Для выполнение данной операции применение init-кода совершенно не требуется, поскольку в результате ее выполнения не создается новой учетной записи. Тем не менее, для такой операции возможно понадобятся входные данные, но только в том случае, если такие данные были переданы получателем в результате проведения транзакции. После выполнения операции по отправке сообщения становится доступным новый блок, содержащий выходную информацию, использование которой происходит при повторном выполнении такой операции.

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

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

Модель выполнения

В предыдущий разделах я рассказал вам о том, как происходит выполнение транзакций. Теперь же я предлагаю вам разобраться с тем, что происходит в VM (от англ. Virtual Machine — виртуальная машина) в момент выполнения транзакций.

Часть протокола, который выполняет обработку транзакций в операционной системе Эфириума называется виртуальной машиной Эфириума (ВМЭ).

ВМЭ является машиной Тьюринга, как это уже упоминалось в данной статье ранее. Единственное отличие ВМЭ от типичной машины Тьюринга заключается в том, что для работы первой требуется виртуальное «горючее». Таким образом, все вычисления, которые могут быть выполнены в ВМЭ, так или иначе ограничены количеством циркулирующего в ней, виртуальной машине, «горючего».

Кроме того, ВМЭ присущи все особенности стековой архитектуры. Стековая машина – это компьютер, в котором применяется алгоритм LIFO.

Размер любого элемента стека в ВМЭ равен 256 битам, а максимальный размер стека достигает 1024 битов.

Для ВМЭ предусмотрен некоторый объем памяти, который не является постоянным. В нем элементы хранятся в виде массивов байтов с обращением к словам.

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

Для ВМЭ также предусмотрен свой специальный язык – байт-код ВМЭ. Когда программист, такой как вы или, например, я, пишет смарт-контракт, который будет выполняться в системе Эфириума, это обычно происходит с помощью высокоуровневого языка, такого как Solidity. После написания такого кода мы компилируем его в байт-код ВМЭ, чтобы ВМЭ могла понять написанную нами команду.

Перейдем непосредственно в выполнения операций.

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

• Состояние системы
• Информация о достаточном для выполнения требуемой операции количестве горючего
• Адрес учетной записи, которому принадлежит выполняемый код
• Адрес отправителя транзакции – инициатора выполнения текущей операции
• Адрес учетной записи – инициатора выполняемого кода (может отличаться от адреса отправителя-инициатора)
• Информация о требуемом для выполнения транзакции количества горючего
• Входные данные для выполнения операции
• Количество Wei, которое должно быть отправлено на счет данной учетной записи в результате проведения текущей операции
• Информация о выполняемом машинном коде
• Информация о заголовке блока для текущего блока
• Глубина выполнения текущего сообщения или создания контракта

Непосредственно до начала выполнения программы память системы является абсолютно пустой, а счетчик команд равен нулю.

PC: 0 STACK: [] MEM: [], STORAGE: {}

После чего в ВМЭ начинается рекурсивное выполнение транзакции: вычисление состояние системы и состояние машины для каждого цикла. Состояние системы – это глобальное состояние Эфириума. Состояние машины включает в себя:

• доступное количество горючего;
• счетчик команд;
• содержимое памяти;
• активное количество слов в памяти;
• контент стека.

Элементы стека добавляются или удаляются с левого края фрагмента кода.

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

Всего существует три возможных варианта окончания цикла:

1. Операции, выполняемые машиной, достигают исключительного состояния (например, ввиду нехватки виртуального горючего, неверных инструкций, недостаточного количества элементов стека, значения элемента стека, превышающего размер в 1024 бит, неверного назначения JUMP/JUMPI) и, таким образом, процесс выполнения операции приостанавливается.
2. Последовательность действий переходит к выполнению следующего цикла
3. Операции, выполняемые машиной, достигают логического завершения (завершения выполнения процесса)

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

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

Окончательное оформление блоков

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

«Окончательное оформление» может происходить по двум вариантам, в зависимости от того, создаем ли мы блок или он уже создан. В том случае если мы только создаем блок, то окончательное оформление означает процесс майнинга текущего блока. С другой стороны, если блок уже создан, то такое определение означает процесс валидации текущего блока. В обоих из представленных выше случаев необходимо выполнить четыре условия для окончательного оформления блока.

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

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

3) Назначение оплаты (только в случае майнинга): В адрес бенефициария назначается 5 единиц эфира за майнинг каждого блока (в соответствии с предложением EIP-649 данная оплата будет уменьшена до 3 единиц эфира). Более того, за каждый оммер, бенефициарию текущего блока назначается оплата в виде дополнительных 1/32 от общей оплаты за текущий блок. И последнее: бенефициарию блока оммеров также назначается оплата в виде определенной суммы, для определение которой существует специальная цифра.

4) Верификация состояния и значения nonce: Для проведения данной процедуры вам необходимо обеспечить выполнение всех транзакций, а также изменение результирующих состояний. После чего вам также потребуется задать новый блок после того, как оплата за данный блок была отправлена. Процесс верификации происходит посредством сравнения завершающего состояния с состоянием префиксного дерева, хранящегося в заголовке.

Майнинг, направленный на доказательство работы

В разделе «Блоки» мы кратко ознакомились с таким понятием, как сложность блоков. Алгоритм, благодаря которому возникло понятие сложность блоков, называется доказательство выполнения работы (PoW от англ. Proof of Work).

Алгоритм PoW, используемый в системе Эфириум, носит название Ethash (ранее, но назывался Dagger-Hashimoto).

Данный алгоритм имеет следующий вид:

где m – это mixHash; n – nonce; Hn – заголовок нового блока (nonce и mixHash не входят сюда, поскольку данные значения должны высчитываться); Hn – nonce для заголовка блока; d – комплект данных DAG.

В разделе «Блоки» мы также ознакомились с различными значениями, предусмотренными для заголовка блока. К ним, как вы помните, относятся такие значения как mixHash и nonce. Еще раз напомню:

• mixHash представляет собой хэш, который вместе со значением nonce подтверждает, что для текущего блока было выполнено достаточное количество вычислений.
• nonce также представляет собой хэш, который вместе со значением mixHash подтверждает, что для текущего блока было выполнено достаточное количество вычислений.

Таким образом PoW необходимо для подсчета вышеприведенных значений.

Объяснить каким именно образом mixHash и nonce высчитываются с помощью функции PoW достаточно сложная задача, и, собственно, этому моменту можно посвятить целую статью. Но если вкратце, то происходит следующее:

Значение «семени» рассчитывается для каждого из блоков. Для подсчета каждого из семени существует свой собственный «интервал», при этом каждый из интервалов равен 30000 блоков. Для каждого интервала семя является хэшем, равным серии из 32-байтовых нулей. Для каждого последующего интервала предусмотрен определенный хэш – хэш для предыдущего семени. С помощью данного семени узел находит значение псевдослучайного «хэша».

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

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

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

Майнинг как механизм защиты

В общем, целью PoW является криптографически доказать, что определенные вычисления были направлены на получение определенного результата (значения nonce). Так ужу вышло, что не существует другого способа нахождения nonce, значение которого не превышает определенного лимита, кроме как с помощь перечисления всех возможных вариантов вплоть до нахождения требуемого. Распределение выходных данных для постоянно используемого хэша функций происходит равномерно. Таким образом, мы точно знаем, что необходимое для нахождения значения nonce время явно зависит от порога сложности: чем выше порог сложности, тем дольше будет происходить поиск необходимого значения nonce. Алгоритм PoW представляет концепцию сложности, используемой в рассматриваемом блокчейне.

Что же значит безопасный блокчейн? Ответ довольно прост: безопасный блокчейн – это блокчейн, которому будут доверять абсолютно ВСЕ ПОЛЬЗОВАТЕЛИ. Как я уже писал выше, в случае если в блокчейне существует более двух цепочек, то, вполне логично предположить, пользователи не будут чувствовать себя уверено во время работы с блокчейном, поскольку никто не сможет с точностью сказать, какая из представленных цепочек является валидной.

Именно для этого применяется алгоритм PoW: обеспечивает единство цепочки в блокчейне, препятствуя созданию других цепочек блоков, которые могут повлиять на историю выполнения транзакций (например создание ненастоящих транзакций или удаление или изменение существующих). Таким образом, для того чтобы злоумышленник смог первым провести валидацию своих блоков, ему придется постоянно определять значение nonce, при чем делать это быстрее всех других пользователей сети (надеюсь, вы помните про протокол GHOST, который я описывал ранее). Само собой, для злоумышленника такой метод будет неосуществим, если только в его распоряжении не находится большая часть майнинговых ресурсов сети – такой сценарий известен как атака 51 %.

Майнинг как средство распределения финансов

Помимо того, что алгоритм PoW обеспечивает безопасную работу блокчейна, благодаря ему также осуществляется распределение вознаграждения тем пользователям, чьи вычисления были использованы для обеспечения безопасности. Я уже писал выше, что майнеры получают вознаграждение за майнинг того или иного блока, а также:

• вознаграждение в 5 единиц эфира за «выигравший» блок (в скором времени эта цифра должна опуститься до 3 единиц)
• стоимость за горючее, израсходованное в результате проведения транзакции в блоке
• дополнительное вознаграждение за включение оммеров в блок

Для обеспечения согласованности работы метода PoW – что необходимо для гарантии безопасности – и распределения вознаграждений Эфириума постоянно придерживается двух принципов, представленных ниже:

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

Например, в системе Bitcoin существует проблема с выполнением двух вышеприведенных принципов: ее алгоритм PoW использует хэш-функцию SHA256. Проблема последней заключается в том, что ее решение может оказаться намного проще в случае использование специальных аппаратных средств – ASICs.

Для того чтобы не допустить подобных проколов в Эфириуме применяется специальный алгоритм PoW с последовательной памятью (Ethhash). структура алгоритма построена таким образом, что для вычисления значения nonce требуется задействовать большой объем памяти и высокую пропускную способности соединения. Требования, связанные с наличие большого объема памяти, подразумевают, что для компьютера с обычным объемом памяти будет очень сложно провести параллельное вычисление нескольких значений nonce одновременно. Что до требований к высокой пропускной способности, то даже для сверхбыстрого компьютера обнаружение нескольких значений nonce одновременно станет непростой задачей. Таким образом, благодаря таким особенностям данной системы обеспечивается снижение вероятности централизации рисков и, кроме того, создаются более равномерные условия для работы различных узлов, выполняющих верификацию.

Кстати, не так давно я узнал о том, что Эфириуме собирается переключиться с алгоритма PoW к некоему методу, который носит название «Доказательство доли владения» (от англ. Proof-of-stake). Такой метод сам по себе достоин отдельной статьи для обзора и обсуждений.