как установить блокчейн на телефон
Как сделать свой блокчейн. Часть 1 — Создание, Хранение, Синхронизация, Отображение, Майнинг и Доказательная работа
Доброго всем! Мы тут потихоньку начали исследовать новое совсем для нас направление для обучения — блокчейны и нашли то, что оказалось интересным в рамках нашего курса по Python, в том числе. Чем, собственно, и хотим поделиться с вами.
Я могу узнать, когда у меня появился первый Bitcoin, из истории кошелька в моем аккаунте на Coinbase — входящая транзакция в 2012 году в подарок за регистрацию. Bitcoin в то время стоил около 6.50$. Если бы я сохранил те 0.1 BTC, на момент написания статьи это бы уже стоило более 500$. Если кому-то интересно, я продал их, когда Bitcoin стоил 2000$. Так что я получил только 200$ вместо ныне возможных 550$. Не стоило торопиться.
И тогда я внезапно понял, что нужно чуть глубже разобраться в этой теме. И начал с “исследования” — прочитал огромное количество статей в интернете, объясняющую их суть. Некоторые были хорошие, некоторые плохие, некоторые глубокие, а некоторые очень поверхностные.
Чтения оказалось недостаточно, а если существует одна вещь, которую я знаю наверняка, так это то, что чтение не объяснит и сотой доли того, что объяснит программирование. И так я понял, что стоит написать свой собственный локальный блокчейн.
Нужно учитывать, что есть большая разница между базовым блокчейном, который я описываю и “профессиональным” блокчейном. Эта цепь не создаст криптовалюту. Блокчейны не требуют производства монет, которые можно продавать и менять на физические деньги.
Блокчейны используются для хранения и подтверждения информации. Монеты побуждают узлы участвовать в валидации, но их наличие не обязательно.
Я пишу пост по нескольким причинам: 1) Чтобы люди, прочитавшие его, смогли узнать больше о блокчейнах; 2) Чтобы я смог понять больше, объяснив код, а не просто написав его.
В этом посте я покажу способ хранения данных блокчейна и генерации начального блока, синхронизацию узла с локальными данными блокчейна, отображение блокчейна (что впоследствии будет использоваться для синхронизации с другими узлами), а затем, майнинг и создание валидных новых блоков. В первом посте не будет никаких других узлов. Никаких кошельков, пиров, важных данных. О них поговорим позднее.
Если вы не хотите углубляться в детали и читать код, или если вы наткнулись на этот пост, рассчитывая на статью, которая бы понятным языком объясняла блокчейны, я постараюсь кратко резюмировать, как они работают.
На самом высоком уровне, блокчейн — база данных, где каждый, участвующий в блокчейне, может хранить, просматривать, подтверждать и никогда не удалять данные.
На более низком уровне, данные в этих блоках могут быть чем угодно, пока это позволяет конкретный блокчейн. Например, данные в Bitcoin блокчейне — исключительно транзакции Bitcoin между аккаунтами. Ethereum блокчейн позволяет как аналогичные транзакции Ether, так и транзакции, использующиеся для запуска кода.
Прежде чем блок будет создан и объединен в блокчейн, он подтверждается большинством людей, работающих над блокчейном — их называют узлами. Настоящий блокчейн — цепь, состоящая из огромного множества блоков, подтвержденных большинством узлов. Таким образом, если узел попытается изменить данные предыдущего блока, новые блоки не будут валидны, и узлы не будут доверять данным из некорректного блока.
Не волнуйтесь, если это сбивает с толку. Мне понадобилось время, чтобы самому вникнуть в это, и еще больше времени на написание такого поста, чтобы даже моя сестра (которая ничего не знает о блокчейнах) смогла понять.
Если хотите изучить код, посмотрите ветку part 1 на Github. Смело присылайте мне любые вопросы, комментарии, правки и похвалы (если вы в настроении сделать что-то особо хорошее), или просто пишите в твиттер.
Шаг 1 — Классы и Файлы
Первый шаг — написание класса, обрабатывающего блоки при запуске узлов. Я назову этот класс Block. Честно говоря, много делать не придется. В функции __init__ мы будем верить, что вся необходимая информация уже представлена в словаре. Для производственного блокчейна — это не самое мудрое решение, но подходит в качестве примера, потому что код пишу только я. Также я напишу метод, запаковывающий важную информацию блока в словарь, а после заведу более удобный способ для отображения информации блока при его печати в терминал.
Чтобы создать первый блок, запустим этот простой код:
Отлично. Последний вопрос в этой части — где хранить данные в файловой системе. Это необходимо, если мы не хотим потерять локальные данные блока при отключении узла.
Я назову папку с данными ‘chaindata’, в какой-то степени подражая схеме папок Etherium Mist. Каждому блоку теперь присвоен отдельный файл, названный по его индексу. Нужно убедиться, что имена файлов содержат в начале достаточное количество нулей, чтобы блоки перечислялись по порядку.
С учетом кода выше, нужно написать следующее для создание первого блока:
Шаг 2 — Синхронизация блокчейна, локально
Прежде чем начать майнинг, интерпретацию данных или отправку/создание новых данных для цепи, необходимо синхронизировать узел. В нашем случае других узлов нет, поэтому я говорю только о чтении блоков из локальных файлов. В будущем частью синхронизации будет не только чтение из файлов, но и коммуникация с пирами для сбора блоков, которые были сгенерированы, пока ваш узел не был запущен.
Пока просто и красиво. Чтение строк из файлов их загрузка в структуры данных не требуют чрезмерно сложного кода. Пока это работает. Но в будущих постах, где я буду писать о возможностях коммуникации разных узлов, эта функция sync станет значительно сложнее.
Шаг 3 — Отображение блокчейна
Теперь наш блокчейн находится в памяти, и поэтому я хочу отобразить цепь в браузере. Для того, чтобы сделать это прямо сейчас, есть две причины. Во-первых, необходимо подтвердить в браузере, что изменения произошли. Во-вторых, я буду использовать браузер в будущем для просмотра и совершения каких-либо операций, связанных с блокчейном. Например, отправка транзакций или управление кошельком.
Для этого я использую Flask — у него низкий порог вхождения, и я решил, что он подходит для наших целей.
Ниже представлен код для отображения json блокчейна. Я проигнорирую импорты для экономии места.
Запустите этот код, зайдите на localhost:3000/blockchain.json и увидите текущий блок.
Шаг 4 — “Майнинг”, также известный как создание блока
Сейчас есть только генезис блок, но если у нас появится больше данных, которые необходимо хранить и распределять, нужен способ включить это в новый блок. Вопрос — как создать новый блок и соединить его с предыдущим.
Сатоши описывает это следующим образом в Bitcoin whitepaper. Учтите, что “timestamp сервер” назван “узлом”.
“Начнем описание нашего решения с timestamp сервера. Его работа заключается в хэшировании блока данных, на который нужно поставить timestamp, и открытой публикации этого хэша… Timestamp показывает, что в данный момент конкретные данные существовали и потому попали в хэш блока. Каждый хэш включает в себя предыдущий timestamp: так выстраивается цепь, где очередное звено укрепляет все предыдущие.”
Скриншот изображения, прикрепленного под описанием:
Основная идея раздела — при необходимости соединить блоки, мы создаем хэш информации о новом блоке, включая время создания блока, хэш предыдущего блока и информацию в самом блоке. Я буду называть всю эту информацию “хедером” блока. Таким образом, мы можем проверить корректность блока, посчитав все хэши перед ним, подтвердив последовательность.
В данном случае хедер, который я создаю, объединяет значения строки в одну огромную строку. Я включил следующие данные:
Поясню один момент — объединение строк информации не является обязательным для создания хедера. Требование состоит в том, чтобы каждый знал, как генерировать хедер блока и хэш предыдущего блока внутри него. Делается это для того, чтобы каждый мог убедиться в корректности хэша в новом блоке и подтвердить связь между двумя блоками.
Хедер Bitcoin значительно сложнее объединения строк. Он использует хэши данных и времени и завязан на то, как данные расположены в памяти. Но в нашем случае объединения строк достаточно.
Теперь у нас есть хедер и можно вычислить валидность хэша. Я буду использовать метод, отличающийся от метода Bitcoin, но все равно запущу хедер блока через функцию sha256.
Для майнинга блока мы используем функцию выше, чтобы получить хэш, положить его в новый блок и сохранить этот блок в директории chaindata.
Готово! Но при таком типе создания блока кто угодно с самым быстрым CPU сможет создавать самые длинные цепи, которые другие узлы посчитают корректными. Нужен способ снизить скорость создания блока и подтверждение до перехода к следующему блоку.
Шаг 5 — Доказательство выполнения работы
Для снижения скорость я использую Доказательство выполнения работы, как и Bitcoin. Доказательство доли владения — другой способ, используемый в блокчейнах для достижения консенсуса, но в этом случае я воспользуюсь работой.
Способ сделать это — установить требования к структуре хэша блока. Как и в случае с bitcoin, необходимо убедиться, что хэш начинается с определенного количества нулей, перед тем, как перейти к следующему. А для этого нужно добавить в хедер дополнительную информацию — случайно перебираемое число (nonce).
Теперь функция майнинга настроена для создания хэша, но если хэш блока не содержит достаточного количества нулей, мы увеличиваем значение nonce, создаем новый хедер, вычисляем новый хэш и проверяем хватает ли нулей.
Отлично. Новый блок содержит валидное значение nonce, поэтому другие узлы могут подтвердить хэш. Мы можем сгенерировать, сохранить и распределить новый блок остальным.
На этом все! Пока что. Осталось еще много вопросов и фичей в блокчейнах, которые я не объяснил.
Например, как задействовать другие узлы? Как узлы передают данные, когда включаются в блок? Существуют ли иные способы хранения данных кроме огромных строк данных?
Ответы на эти вопросы можно будет найти в следующих частях этой серии постов, как только я сам найду на них ответы. Пожелания по содержанию можно писать мне в твиттер, в комментарии к посту или через форму обратной связи!
Спасибо моей сестре Саре за уточняющие вопросы о блокчейнах и помощь в редактировании поста!
Комментарии, вопросы, как всегда, приветствуются и тут, и на дне открытых дверей.
Эксперимент с блокчейном на мобильной платформе. Часть 1.
Много работая с технологией блокчейн, мы задумываемся о том, какие перспективы развития и применения у неё есть. В этом цикле статей мы хотим поделится своими размышлениями и практическими результатами на тему развития применения технологии блокчейн на мобильных устройствах. Мы не приводим готовых рецептов, но делимся мыслями, которые появились у нас в результате работы, а в следующих статьях поделимся результатами практического воплощения этих идей.
Введение
Во времена зарождения и развития технологии блокчейн основным средством выхода в сеть Интернет был персональный компьютер. Идея децентрализации, лежащая в основе блокчейн технологии, хорошо сочеталась с привычным для людей способом взаимодействия с глобальной сетью: вся информация хранится и обрабатывается независимыми узлами, развёрнутыми на компьютерах пользователей.
Однако время шло, появлялись новые технологии и менялись привычки людей — теперь пользователь большую часть времени взаимодействует с мобильными устройствами. Эти изменения затронули и техническую сторону вопроса: всё меньше приложений создаётся исключительно для ПК, как правило, происходит разделение на общий бэкенд и фронтенд для различных устройств (телефон, планшет, периодически включаемый ноутбук). В случае с блокчейном это привело к тому, что люди всё реже разворачивают узлы на своих ПК, большинство узлов развёрнуты на специальных устройствах (майнерах), в облаках и т.д. Основной причиной этого процесса является то, что классические PoW-алгоритмы оптимальнее работают на специализированном оборудовании. Также, классические PoW блокчейны отличаются низкой пропускной способностью, по сравнению с набирающими популярность блокчейнами с выделенными валидаторами (dPOS, dBFT). В результате большое количество узлов может оказываться под контролем узкого круга лиц, создавая опасную централизацию, что противоречит принципам, положенным в основу технологии.
Размышляя над этими изменениями, мы задались вопросом: возможно ли адаптировать технологию под изменившуюся среду и в каких случаях это целесообразно?
Ограничения платформы
Идея развернуть блокчейн узлы на мобильных устройствах не нова, но попытки её реализации неизбежно сталкиваются с несколькими проблемами.
Слабые вычислительные мощности. Большинство широко распространённых публичных блокчейн сетей использует в качестве алгоритма консенсуса Proof of Work (PoW), основная идея которого, несколько упрощая, и заключается в том, чтобы заставить валидаторов потратить значительные вычислительные (и энергетические, как следствие) ресурсы на подтверждение транзакции. Мобильное устройство никогда не сравнится по вычислительной способности со специализированным оборудованием, в результате сеть мобильного PoW-блокечейна будет подвержена атакам с использованием такого рода оборудования с высоким хэшрейтом.
Низкая энергоэффективность. Если всё же решиться использоваться телефон для PoW вычислений, ограниченность ресурса батареи будет приводить к быстрой его разрядке. К тому же, организация постоянной работы мобильного устройства в режиме обслуживания p2p траффика также приведет к крайне быстрому расходу энергии батареи.
Малый объем хранилища. Полные узлы популярных блокчейн сетей могут занимать значительные объемы физической памяти (Bitcoin — более 100 GB, Ethereum — более 1TB), в то время как её объём в среднем телефоне редко превышает 64GB.
Это три основные причины, вследствие которых большинство популярных блокчейнов не смогут развернуть полный узел на мобильном устройстве. Чтобы сделать это возможным, нужны новые подходы к организации блокчейна.
Области применения
Перед тем как ответить на вопрос о том, как обойти выше упомянутые ограничения, необходимо понять: кому и для чего может потребоваться блокчейн на мобильном устройстве? Мы выделили три основных направления, которые хорошо сочетаются с технологией:
· Хранение и обмен не слишком объемной, но важной информации (пароли, ключевые слова, заметки важные для конкретного человека). Информация такого рода может храниться на телефоне пользователя, а также определённых им доверенных лиц в зашифрованном виде.
· Система обмена ценностями (криптовалютами или другими эквивалентами, только обмен, без майнинга). Такая система пригодится людям, которые не хотят зависеть от оператора, который может заблокировать перевод или заморозить средства на счету.
· Децентрализованный P2P мессенджер. Учитывая ситуацию с Telegram, мессенджер, который невозможно заблокировать в силу отсутствия центральных узлов выглядит интересным направлением работы.
Наверняка можно выделить ещё множество направлений, но именно эти показались нам наиболее интересными, поэтому мы рассмотрим, как можно обойти ограничения, связанные с мобильной платформой в их контексте.
Как обойти ограничения мобильной платформы?
Чтобы ответить на этот вопрос рассмотрим каждое ограничение отдельно:
Малый объём хранилища. Чтобы не столкнутся с ситуацией, когда есть один постоянно растущий блокчейн, необходимо реализовать шардинг или деление общего блокчейна на микрочейны и хранить на устройстве только те микрочейны, в работе которых данное устройство принимает участие.
Слабые вычислительные мощности. Чтобы это ограничение не было фатальным для всей системы, необходимо отказаться от «тяжелого» алгоритма консенсуса PoW в пользу более лёгких, например, Proof of Authority (PoA). PoA хорош тем, что не требует решения сложных математических задач, но в этом случае все узлы микрочейна должны доверять друг другу. Предлагаемая реализация: добавляемые в микрочейн узлы должны обменяться публичными ключами ЭП и внести, с разрешения оператора, полученный ключ в список доверенных.
Для систем, где между участниками нет доверия, можно использовать (d)PoS и (d)BFT алгоритмы, которые также как PoW требуют вычислений, но значительно более «лёгких».
Низкая энергоэффективность. Для того, чтобы работа полноценного узла на мобильном устройстве была возможна, требуется энергоэффективный способ обмена P2P данными. Организация такого обмена ставит перед разработчиком два вопроса:
1) Как устройства будут находить друг друга?
· Один из вариантов решения — использование discovery-сервера. Когда мобильное устройство подключается к блокчейну, оно обращается к ближайшему discovery-серверу, который хранит данные об устройствах, состоящих в блокчейне. Такой discovery-сервер должен иметь открытый исходный код для обеспечения доверия, а развернуть его должен быть уполномочен любой желающий. Минусом данного варианта является необходимость поддержания серверной архитектуры и возможность нарушить работу сети помешав корректной работе discovery-сервера.
· Второй вариант — первоначальное подключение к блокчейну может осуществляться через локальные Wi-fi сети или Bluetooth протокол. В этом сценарии пользователь, желающий подключится к блокчейну, отправляет широковещательный запрос устройствам уже подключённых пользователей и, в случае положительного решения, получает список адресов других участников.
· Третий вариант — комбинированный, когда при подключении нового узла подключающий узел вместо прямых адресов участников посылает известные ему адреса discovery-серверов через локальные каналы (Wi-Fi/BT) или целевым сообщением (Push, SMS, etc)
2) По какому протоколу будет проходить связь?
· TCP/IP сокеты — вариант который первым приходит в голову, но выглядит трудным для реализации, так как пользователи в течении дня перемещаются между провайдерами связи (Wi-Fi/сотовая), а их устройства меняют свои IP адреса.
· WebSocket — те же недостатки, что и в первом варианте.
· Платформенные Push-сообщения– этот вариант выглядит наиболее перспективным, так как требует наименьших энергозатрат и выглядит наиболее эффективным из вышеперечисленных.
Итоговая концепция
Обсудив ограничения мобильных платформ и способы их обойти, мы можем сформулировать концепцию, в рамках которой можно организовать полноценный блокчейн на мобильном устройстве.
1. Сеть состоит из мобильных устройств, на которых запущено приложение узла сети
2. Каждый узел сети может входить в 1 или более микрочейнов
3. Каждый микрочейн хранит свои данные на каждом устройстве, входящем в него
4. В качестве алгоритма консуса предлагаем использовать PoA
5. Для добавления устройства в микрочейн, его владелец рассылает входящим в микрочейн участникам запрос, включающий его публичный ключ. Участники должны его добавить в доверенные — т.е. сделать новым участником. Принятие решения может быть организованно следующими способами:
a. консенсусное решение о добавлении
b. личное решение и консенсус уже по результатам подписи транзакций (не добавившие отбрасывают транзакции)
c. личное решение о добавлении создателя микрочейна
6. Валидация в рамках PoA: каждый узел валидирует транзакции в микрочейне по ЭП инициатора и набору бизнес-правил, которые могут варьироваться между микрочейнами
7. Устройства в сети адресуются своими номерам и общаются P2P с помощью пуш-нотификаций
8. Устройства в сети находят друг друга через Wi-Fi/Bluetooth при подключении к микрочейну — подключаемый отправляет запрос подключающему, тот в ответ (при позитивном решении) высылает ему таблицу адресов других участников микрочейна
Приглашаем сообщество к обсуждению данной концепции блокчейна на мобильном устройстве — будем рады услышать мысли других специалистов на этот счёт. В следующей статье мы поделимся результатами попыток воплощения описанных идей на практике.
