Bitcoin и Ethereum: что происходит на узлах, которые не занимаются добычей, и что с ними будет дальше?


Введение


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


Факторов, сдерживающих развитие блокчейн систем, безусловно, много. Они могут иметь как техническую, так и экономическую, политическую или даже психологическую природу. В данной статье будут рассмотрены только некоторые технические ограничения двух наиболее популярных блокчейн систем — Bitcoin и Ethereum.


Предполагается, что Вы уже знакомы с основными принципами работы этих систем. Если какие-то термины окажутся не совсем понятными, их объяснение можно найти в книге Mastering Bitcoin Андреаса Антонопулоса (в сети можно найти перевод на русский язык), и в статье о принципах работы Ethereum на Geektimes.


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


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

Перспективы ускорения добычи блоков


В современных системах транзакции осуществляются значительно медленнее по сравнению с обычными платёжными системами. Наиболее популярные на сегодняшний день системы, в первую очередь, Bitcoin и Ethereum построены на использовании принципа доказательства работы (proof-of-work). Для подтверждения транзакции в таких системах требуется сначала дождаться, пока транзакция пройдёт очередь на добавление и будет зафиксирована в очередном блоке. Затем нужно ещё подождать некоторое время, в течение которого будет выполнен объём вычислительной работы, достаточный для гарантии того, что уже никто не сможет повторить эту работу самостоятельно с целью модификации добавленных данных. В системе Bitcoin обычно транзакция считается подтверждённой после добавления 6 блоков после блока, содержащего соответствующую транзакцию. Этот процесс занимает примерно один час. Что касается Ethereum, то здесь единого мнения относительно надёжного подтверждения нет: некоторые кошельки могут ждать подтверждения 5 блоков (около минуты), в то время как отдельные биржи могут требовать добавления нескольких сотен блоков для подтверждения.


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


Для совершения небольших покупок, ввиду низких рисков продавца, часто не требуется ждать подтверждения. Достаточно информации о том, что транзакция попала в сеть и добавлена в очередь. Но, если рассматривать систему в целом, основным элементом, ограничивающим производительность сети, по-прежнему остаётся добыча (mining) блоков, поскольку все отправленные транзакции всё равно рано или поздно должны быть добавлены в блоки. Сложность добычи не имеет под собой реальных физических оснований, а задаётся искусственно, чтобы обеспечить необходимое количество работы для надёжного подтверждения. В системе Bitcoin сложность добычи подбирается таким образом, чтобы среднее время добавления нового блока составляло приблизительно 10 минут. Если блоки начинают добываться быстрее, сложность увеличивается, если дольше — снижается. Частота добавления блоков в Ethereum выше – новый блок добавляется примерно каждые 15 секунд.


При необходимости частоту добавления новых блоков можно повысить, снизив сложность добычи, или же вообще отказаться от процесса добычи, переключив систему на работу в соответствии с принципом доказательства доли владения (proof-of-stake). Однако и в том и в другом случае вероятность одновременного нахождения новых блоков возрастёт, что приведёт к росту числа ветвлений цепи (fork) и соответствующим неудобствам. Критическим временем добавления блока здесь будет являться время, соответствующее характерному времени распространения блока по сети. После превышения данного порога майнеры слишком часто будут получать информацию о новом добытом блоке уже после того, как добудут его сами (возможно, включив в него другой набор транзакций) и отправят в сеть. Таким образом, добавление почти каждого блока будет сопровождаться ветвлением, что сделает невозможным нормальное функционирование сети. Время распространения данных по сети между разными континентами можно грубо оценить величиной 100 мс. Таким образом, скорость добавления блоков в Bitcoin можно повысить не более чем в $10 \cdot 60 \cdot 1 \; 000 / 100 = 6 \; 000 \; раз$, а в Ethereum – в $15 \cdot 1 \; 000 / 100 = 150 \; раз$.


Особенности хранения базы транзакций на полных узлах


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


Bitcoin


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



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


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



Рисунок 2. Зависимость размера блокчкйна Bitcoin от времени. Источник: blockchain.info.


Далеко не все пользователи готовы выделить на своём персональном компьютере несколько сотен гигабайт дискового пространства для хранения блокчейна. Нужно учесть, что это не просто файлы, хранящиеся на диске, а база данных, которая при добавлении новых блоков осуществляет перестроение части данных для обеспечения эффективности их хранения. В клиентах Bitcoin чаще всего используется NoSQL база LevelDB, построенная на LSM деревьях.


Проверку транзакций можно оптимизировать за счёт использования отдельной базы транзакций с непотраченными выходами (UTXO), так как именно эти данные представляют наибольший интерес. Теоретически, проверив подлинность UTXO, информацию о старых транзакциях из общей базы можно удалить с целью оптимизации. Однако оставшаяся база данных всё равно займёт не один гигабайт дискового пространства. Интенсивность обращений к диску при этом уменьшится незначительно. Размер базы, конечно, будет на порядок меньше, но помимо добавления транзакций в этом случае появятся и удаления UTXO с закрывшимися выходами. Таким образом, поддержание так называемого полного узла сети вызывает определённые неудобства у обычных пользователей. Есть мнение, что значительная часть полных узлов Bitcoin уже сейчас размещена в дата-центрах.


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


Ethereum


В Ethereum есть понятие состояния (state) аккаунта, которое включает в себя состояние счёта. В блокчейне хранятся изменения таких состояний. Узлы Ethereum хранят актуальные состояния аккаунтов и при получении новых блоков применяют изменения к имеющимся состояниям, поддерживая тем самым их актуальность. Для обеспечения надёжности хранить старые состояния не требуется, достаточно последнего актуального состояния и уверенности в том, что оно корректно. Благодаря этому в Ethereum не два а три типа узлов:


  • Архивные узлы. Такие узлы последовательно обрабатывают все транзакции, хранят всю историю состояний и позволяют в любой момент воссоздать всю историю операций, в частности, историю выполненя «умных» контрактов. Такие узлы используются, как правило, для отладки и статистического анализа. Также они могут потребоваться для объяснения и обоснования действий, произошедших в результате вызовов «умных» контрактов. Кроме того, наличие полной базы данных требуется для осуществления добычи.
  • Полные узлы. Полные узлы также выполняют все поступающие транзакции, но хранят лишь актуальные состояния и не хранят всю историю выполнения операций. С помощью таких узлов можно безопасно осуществлять переводы (есть гарантия того, что имеющаяся информация о балансе других участников сделки является достоверной), но нет возможности просматривать историю операций. Такие узлы разумно использовать на стационарных ПК для осуществления переводов.
  • Лёгкие узлы. Аналогично лёгким узлам Bitcoin такие узлы хранят минимальный набор информации и по мере необходимости запрашивают данные из сети. Использование таких узлов не является полностью безопасным. Зато узлы такого типа предъявляют значительно более низкие требования к компьютерам пользователей и могут работать на мобильных устройствах.

Более подробная информация о видах синхронизации приведена в статье на dev.to.


Проблемы архивных узлов Ethereum аналогичны проблемам полных узлов Bitcoin: размер базы данных исчисляется сотнями гигабайт и, если темп роста количества данных сохранится, то уже до конца 2018 года полная база данных перестанет помещаться на одном стандартном жёстком диске или твердотельном накопителе.



Рисунок 3. Зависимость размера блокчейна Ethereum от времени (для сравнения также приведена зависимость для Bitcoin). Источник: daniel.net.nz.


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



Рисунок 4. Зависимость размера базы данных полного узла Ethereum от времени. Источник: etherscan.io.


Однако на практике не всё оказывается так просто. В результате экспериментов с одной из наиболее популярных реализаций клиента Ethereum – Geth (Go Ethereum), — в январе 2018 года оказалось, что примерно за две недели работы клиента размер базы данных увеличился с 40 Гбайт до 80 Гбайт. Дальнейшее исследование показало, что после завершения синхронизации базы данный клиент переходит в режим архивного узла. То есть из базы данных не удаляется информация об устаревших состояниях аккаунтов, что приводит к увеличению размера базы, который относительно быстро может превысить несколько сотен гигабайт (см. рисунок 3). Разработчики о проблеме знают, но тикет закрыт почти полгода назад без принятия каких-либо мер по решению проблемы. Единственная практическая рекомендация заключается в следующем: удалить базу данных и загрузить её заново в режиме «быстрой» синхронизации (может занять несколько дней). В этом случае загруженная база, действительно, окажется меньше, но после завершения синхронизации клиент опять переключится в режим полной синхронизации и размер базы данных опять начнёт быстро увеличиваться.


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


Виртуальная машина Ethereum


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



Рисунок 5. Зависимость количества транзакций в одном блоке блокчейна Ethereum от времени (скорость добавления блоков практически постоянна и равна примерно четырём блокам в минуту).


Оценить рост вычислительной сложности обработки «умных» контрактов можно, загрузив полную базу данных. Среди прочего в полной базе хранится код всех контрактов, полная история их состояний и аргументы, с которыми они вызывались. Всё это позволяет повторно воспроизвести все вызовы контрактов и получить трассы их выполнения в операциях виртуальной машины Ethereum (EVM – Ethereum Virtual Machine). Список используемых команд можно посмотреть, например, на GitHub.


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



Рисунок 6. Зависимость количества вызовов операции вычисления хеш-функции sha3 в контрактах Ethereum от времени.



Рисунок 7. Зависимость количества вызовов различных операций обращения к памяти в контрактах Ethereum от времени.



Рисунок 8. Зависимость количества системных вызовов в контрактах Ethereum от времени.


Как видно из графиков, на данный момент виртуальная машина Ethereum для своей работы не требует большого количества ресурсов: за секунду осуществляется вычисление примерно ста хеш-функций (с учётом скорости добычи в 4 блока в минуту), несколько сотен доступов в память различного вида и порядка 10 системных вызовов. Даже если учесть десятикратный рост в течение года, проблемы с хранением данных, возникнут гораздо раньше (см. предыдущие разделы).


Профилирование Ethereum


Несмотря на то, что виртуальная машина Ethereum не должна потреблять много ресурсов в процессе своей работы, клиент Geth почти полностью загружает ЦП и достаточно активно использует память и жёсткий диск. База данных Ethereum содержит значительное число записей, поэтому, возможно, для работы с ней требуется достаточно много ресурсов. Можно грубо оценить частоту обращений к диску. При выполнении транзакции нужно проверить, что средства отправителя зафиксированы в блокчейне. Для этого нужно совершить поиск в базе данных на диске. С учётом логарифмического времени поиска и накладных расходов, связанных со структурой LSM деревьев, одну операцию поиска в базе можно оценить как 100 случайных обращений к диску. В каждом блоке содержится приблизительно 100 транзакций (см. предыдущий раздел). В минуту добавляется приблизительно 4 блока. Таким образом, только для проверки транзакций в минуту нужно совершить $4 \cdot 100 \cdot 100 \approx 10^4 - 10^5$ случайных обращений к диску.


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


На диаграмме ниже приведены результаты измерения времени работы различных горутин (аналог потоков в языке go) в процессе работы клиента Geth после завершения полной синхронизации. Измерения проводились в течение 60 секунд.



Рисунок 9. Время выполнения 10 наиболее требовательных к ресурсам горутин клиента Geth после завершения полной синхронизации в случае размещения базы данных на жёстком диске. Время измерения – 1 минута.


Из диаграммы видно, что большую часть времени занимает работа загрузчика, который должен импортировать блоки, проверять транзакции, выполнять соответствующие вызовы контрактов с использованием виртуальной машины и обновлять соответствующие состояния в базе данных. В силу небольшого количества данных (4 блока приблизительно по 100 транзакций в минуту), сама загрузка не должна занимать много времени. Работа виртуальной машины, как оказалось, тоже. Более подробный анализ профиля показал, что за время измерения (1 минута) было совершено около 100 000 системных вызовов, большая часть которых представляет собой обращения к файлам базы данных LevelDB, которые располагались на жёстком диске (то есть оценка, приведённая выше, оказалась верной). Таким образом, среднее время между соседними обращениями к файлам составляет $60 \; 000 \; 000 \; мкс / 100 \; 000 \; вызовов = 600 \; мкс$, что по порядку величины сопоставимо со временем случайного доступа к жёсткому диску. Исходя из этого, можно сделать вывод о том, что обращения к диску и являются в данном случае наиболее узким местом. Это предположение имеет и экспериментальное подтверждение в виде стабильно высокой загрузки диска в процессе работы клиента.


Ситуация с rpc.ServerRequest (задача, которая заняла второе место по времени выполнения) аналогичная – достаточно большое число системных вызовов, в момент совершения которых верхняя часть стека имеет вид:


syscall.Pread:1372
os.(*File).pread:238
os.(*File).ReadAt:120
github.com/ethereum/go-ethereum/vendor/github.com/syndtr/goleveldb/leveldb/table.(*Reader).readRawBlock:564
github.com/ethereum/go-ethereum/vendor/github.com/syndtr/goleveldb/leveldb/table.(*Reader).readFilterBlock:653
* * *

На третьем месте по времени выполнения находится обслуживание базы данных – leveldb.tCompaction. Далее следуют накладные расходы, связанные со сборкой мусора в языке go. Выполнение остальных горутин занимает пренебрежимо мало времени.


Таким образом, в случае хранения полной базы на жёстком диске (не SSD), ограничивающим фактором является работа базы данных, а точнее файловый ввод-вывод. Поэтому для обеспечения эффективной работы полного узла рекомендуется использовать твердотельные накопители, которые теоретически могут ускорить работу базы данных на 2-3 порядка. Дополнительно снизить нагрузку на базу данных можно путём использования быстрой синхронизации. В этом случае размер базы данных должен быть на порядок меньше (десятки гигабайт вместо сотен), поэтому обновление данных в такой базе должно осуществляться быстрее, в том числе и за счёт меньшего количества обращений к жёсткому диску. Результаты профилирования клиента Geth в процессе добавления блоков после быстрой синхронизации в условиях размещения базы на SSD приведены на диаграмме ниже. Измерения проводились в течение 10 минут.



Рисунок 10. Время выполнения 10 наиболее требовательных к ресурсам горутин в клиенте Geth после завершения быстрой синхронизации в случае размещения базы данных на твердотельном накопителе. Время измерения – 10 минут.


В результате профилирования оказалось, что больше всего времени занимает выполнение горутины miner.(*worker).update. На первый взгляд результаты кажутся удивительными, поскольку перед запуском профилирования добыча была отключена путём явного вызова соответствующей функции API. Более детальный анализ результатов профилирования и просмотра исходного кода Geth показал, что, не смотря на отключенную добычу, майнер продолжает обрабатывать поступающие транзакции и добавлять их в свою базу данных. Таким образом, реальной добычи здесь нет, и большая часть работы майнера сводится к работе с базой данных и системным вызовам для обращения к соответствующим файлам.


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


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


Хеширование используется не только для подтверждения и проверки блоков в системах, основанных на принципе подтверждения работой (proof-of-work), но и лежит в основе хранения данных в блоках и проверки их целостности. Поэтому проблема вычисления хеш-функций возникнет и в системах, основанных на доказательстве доли владения (proof-of-stake). Решением данной проблемы может стать использование ускорителей, которые могут быть построены как на основе видеокарт общего назначения, так и на основе специализированных сопроцессоров или микросхем, которые уже сегодня применяются для добычи в системе Bitcoin.


Заключение


Если не учитывать процесс добычи, как искусственно созданные сложности, наиболее узким местом с точки зрения производительности в современных блокчейн системах являются базы данных. Если темпы роста количества совершаемых транзакций не снизятся, то, вероятно, уже до конца 2018 года полные цепочки блоков наиболее популярных блокчейн систем перестанут помещаться на один жёсткий диск. В одном из наиболее популярных клиентов системы Ethereum до сих пор нет нормальной поддержки полного узла в режиме «подстриженных» деревьев (pruned mode). В системе Bitcoin такие режимы явным образом не предусмотрены.


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


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


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


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


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


Литература


  1. Andreas M. Antonopoulos. Mastering Bitcoin.
  2. Preethi Kasireddy. How does Ethereum work, anyway? (перевод)
  3. The Role of Bitcoin Nodes: Do Full Nodes Running in Data Centers Benefit the Bitcoin Network?
  4. The Ethereum-blockchain size will not exceed 1TB anytime soon.
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 32
    0

    Похоже Ethereum тоже следует использовать offchain транзакции, хотя и по другой причине.

      0

      Вы плохо подготовились в данном вопросе: в Ethereum полным ходом идет разработка нового протокола LES2 и нового режима работы ноды ultra light client(ULC).
      А будущее таково, что за услуги полных нод (les, whisper, swarm) клиенты будут платить, полные ноды по своему желанию смогут оставлять пул для запросов от клиентов не платящих ничего, но платящие будут в приоритете.

        0
        Фигня какая-то… В долгосрочной перспективе никаких дисков не хватит чтобы хранить весь этот объем блокчейна. Да и вообще это выглядит бессмысленно и безумно, каждому человеку хранить все транзакции всех людей в мире. Особенно на смартфоне.
        Нужно придумывать что-то другое. Возможно, в той же распределенной сети должно быть средство согласованного (все тем же консенсусом) удаления мусора (т.е. того что гарантированно не нужно и не может понадобиться ни одному из участников сети, включая находящихся оффлайн) из блокчейна. Да, нужен критерий «мусора».
        А про неэффективность PoW уже говорилось, здесь альтернативы придумываются.
          +2
          В блокчейне биткойна можно назвать мусором, например, кошельки по которым не было никакого движения с момент их создания в прошлом. Вы предлагаете, по сути, их удалить?

          Представьте себе — некто положил доллары сша и рубли СССР в стеклянную банку 50 лет назад. Одну валюту посчитали мусором один раз отменили и два раза поменяли при деноминации. Другую и сейчас можно использовать для покупок. Вы бы какую криптовалюту хотели бы получить в будущем?
            0
            Простите а как упала покупательная способность оставшейся в цене валюты за 50 лет? Хмм… погуглил и нашёл. Правда данные только до 2016-го. Итого 48 лет (с 1968-го):

            Делюсь результатом, — по разным оценкам доллар обесценился в пределах от 5.4 до 19.8 раз.

            Но на ваш комментарий данные цифры никак не влияют. Он по сути верен.
              0
              Вот это соревнование обычных валют в порче монеты наперегонки и стало предпосылкой появления криптовалют. Для общества потребления не выгодны потребители, которые сберегают.
              0
              Нет, мусор это не кошельки, а сама история транзакций. Если транзакция произошла, и все деньги, которые в ней участвовали, уже после этого поучаствовали во множестве других транзакций — то зачем хранить исходную? Понятно что механизм биткоина предполагает возможность верификации путем прослеживания всей цепочки до самого начала. Но здесь нужно придумывать что-то чтобы не хранить всю историю за много лет и десятилетий, а например заменять ее криптографически верифицированной информацией меньшего объема.
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Вы смотрите на это как разработчик. А вам советуют в комментариях подумать о сути этого, с экономической и даже, рискну, морально-человеческой точки зрения
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    Это пока еще не критические затраты — никто не заставляет поднимать ноды. Те, кто поднимает — оплачивают их затраты самостоятельно. А вот то, что вы предлагаете убрать в угоду дешевеющим гигабайтам дисков (у меня дома уже год как 30Тб только для фильмов стоит, к примеру) ключевой принцип полного личного контроля за средствами — недопустимо.

                    Для решения этой задачи есть другие методы )
                    • НЛО прилетело и опубликовало эту надпись здесь
              0
              К тезисам статьи комментарии.

              Список нод сети биткойна можно посмотреть в режиме реального времени на сайте: bitnodes.earn.com

              Нет никакого сюрприза в том, что 10% мировых нод размещены в одном провайдере — Hetzner! Вобще получается такой народный рейтинг провайдеров. В некоторых странах количество нод биткойна исчесстляется единицами! Однако, хорошая новость состоит в том, что нода биткойна после синхронизации пока еще нормально работает на старом 7200 rpm SATA диске.

              К сожалению, на Ethereum с его клиентом Geth использовать SATA диск перестало быть возможным еще осенью 2017 года. Объем дисковых операций перестал успевать за транзакциями сети. Поэтому нода Ethereum может быть запущена на SSD диске или SSD виртуальном сервере.

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

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

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

              Оба подхода иявляются принципиально разными, но хотелось бы видеть больше статей об этом и читать разные комментарии.
                –1
                >количество нод биткойна исчесстляется
                комбо и страйк! (без обид)

                >Для биткойна это Lighting Network,
                строго говоря, лайтнинг не только для битка. Там вся суть тормозов в том что если его запустить так как изначально задумывалось — встает вопрос а нафига вообще биток если можно с кем угодно.
                Ну и кросс чейновые переводы — можно было бы затронуть если бы был затронут лайтнинг (спойлер — они уже работают с некоторыми криптами без переделки протоколов и лайтинга, биток да — не в списке)
                  0
                  Lighting Network отменяет основную идею, где все данные есть у всех и все клиенты согласны с произведёнными изменениями, блокчейн получается вообще тогда не нужен, что хочу то и ворочу
                    0
                    Lightning пригоден по сути для микротранзакций и для платежей с известными контрагентами. Получение суммы от неизвестного, либо суммы большей чем открытый канал и все. Идем в основную сеть и снова грузим ее.
                    К тому же каналы это значит заморозить деньги.
                    Сотни и тысячи транзакций внутри канала возможны лишь при активном взаимообмене. Односторонние платежи быстро вычерпают канал.

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

                    С шардами интересно, но мастерноды это уход децентрализации.

                    Есть еще перспективные варианты вместо chain использовать направленный граф типа tangle, но там тоже проблема с объемами хранения не решена.
                      0
                      Технологически с лайтнингом все понятно. Непонятно приживется ли идея морозить средства в канале.
                        0
                        В том то и проблема что прижиться она может только в случае нескольких больших пулов, с которыми у клиентов есть каналы, а эти пули соотв. держат каналы между собой. То есть что то вроде визы и мастеркарда в крипте (упрощенно, я понимаю что это не так). Но тогда выхватываем централизацию. Не монополия, но централизация. Не уверен что это плохо, но народ в массе своей недоволен.
                      0
                      то-есть все плюсы, децентрализация, анонимность, независимость, отменяются в ближайшее время и мы получаем те же банки, разве что владельцы другие и при этом у них даже статуса банка не будет по крайней мере поначалу, печаль, революции значит не будет
                        0
                        Фишка в том, что «банком» может быть любой. Купил сервер, купил канал, купил асик/видюху, нашел клиентов и вперед. Нет лицензий, нет обязанности слушаться других. Клиент может спокойно уйти от нерадивого «банка» к другому.
                        Полная децентрализация — иллюзия, и сказка для маленьких. Она просто неэффективна.
                        Должна быть децентрализация для решения проблем, а не децентрализация ради децентализации. Олигополия вполне себе рабочая схема, если у олигархов есть конфликт интересов, и не возможен полный сговор.
                          0
                          ну не правда, децентрализация эффективна если предположить что все честные и не будут 2 раза одними деньгами платить то всё уже сейчас работает, нужно лишь найти эффективный способ борьбы с недобросовестными пользователями и тогда можно будет имея телефон оплачивать всё что угодно и моментально, даже наличка не нужна будет, а главное не будет манипуляции с количеством денег если есть заданный процент инфляции и бесконечночное количество койнов то можно через 5 лет всех обеспечить криптой и привести все страны к единой независимой валюте, скорее всего не обойдётся без жертв, но что поделать.

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

                              Это пока нет лицензии. Как только появятся такие крупные игроки, надобность в лицензии вам серьёзные дяди в костюмах быстро организуют. Негоже прибыли мимо бюджета ходить. Собственно, верность моего суждения уже сейчас прекрасно иллюстрируют замашки органов власти на лицензирование майнинга.
                            0
                            Личный опыт с эфром. Официальный Ethereum Wallet в режме light client не работает. Да это пока бета, но она совсем не работает, клиент не может найти ни одной ноды за несколько дней.
                            В дефолтном режиме, он начинает синхронизироваться и даже может за 3-7 дней синхронизироваться с нуля. Очень сильно нагружает компьютер, работать при этом становиться невозможно. У меня нормальный стационарный комьютер, ssd, что уж там с ноутбуками становиться я не знаю.
                            Но если его пару дней не запускать, то потом досинхронизироваться очень сложно.
                            Использовать Parity или myetherwallet я опасаюсь.

                            В биткойне юзал Bitcoin Core и Electrum. Вообще никаких проблем.

                              0
                              Когда последний раз смотрел, у них была открытая бага такого плана, что полный клиент игнорировал параметр-ограничение на количество подключений легких нод, как воркэраунд эти рукосуи поставили дефолтное значение лимита подключений в 0. Т.к. практически никто его не меняет, полных нод готовых обслуживать легких клиентов сейчас в сети нет.
                              0
                              Для обеспечения надёжности хранить старые состояния не требуется, достаточно последнего актуального состояния и уверенности в том, что оно корректно. Благодаря этому в Ethereum не два а три типа узлов
                              Это точно так же справедливо и для Bitcoin:
                              • полный узел хранящий все блоки
                              • полный узел с опцией -prune (хранит только непотраченные выходы)
                              • легкий клиент.

                                0
                                Майнеры уже некоторое время хранят базу данных в RAM-драйве.
                                Для этого нужно много-много-много RAM…
                                  –1
                                  мне не совсем понятно почему нельзя использовать нормальные базы данных, и зачем нужен вообще блокчейн как таковой? есть другие уже рабочие способы обеспечения неизменяемости данных и репликации между нодами, зачем этот майнинг? ну и самая большая непонятка с мощностью майнинга, если сеть подстраивается под 10 минут на блок то в чём смысл увеличения мощностей майнинга?
                                    0
                                    Bitcoin: A Peer-to-Peer Electronic Cash System
                                    пересказывать документацию вряд ли вам кто будет. Поверхностно — это игровая ситуация, мощности увеличиваются не потому что кто то приказал а потому что майнерам хочется заработать больше. Это искусственно созданная игровая ситуация, поскольку решение этой игры дает решение проблемы траста — чем больше мощностей тем меньше вероятность того что чейн перерасчитают толстые дяди с толстыми компьютерами. Что позволяет нам с некоторой долей оптимизма рассчитывать на то что правила консенсуса выполняются не только текущим моментом но и задним числом (то есть то что есть в чейне не перепишется) при этом у чейна нет хозяина. Если Вы с этим несогласны — предложите свою схему НАДЕЖНОГО (не в плане стабильности а в плане доверия) децентрализованного хранилища. Если у Вас есть такая схема и Вы не знаете как ее монетизировать — скажите мне, я помогу.
                                    0
                                    Зачем требуется хранить трассу смартконтракта? Ведь достаточно хранить список операций с базой данных, которые он выполнил.
                                      0

                                      Прошу прощения, я не совсем корректно выразился. Сами трассы в базе данных не хранятся, но там есть вся необходимая для их получения информация:


                                      • Код контрактов.
                                      • История состояний (в промежутках между вызовами).
                                      • Аргументы, передаваемые при вызове.

                                      Подробнее можно прочитать тут: https://github.com/ethereum/go-ethereum/wiki/Tracing:-Introduction#tracing-prerequisites


                                      Что это даёт?


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


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


                                      Вариантов здесь может быть несколько:


                                      • Ожидаемое поведение контракта.
                                      • Неожиданное, но корректное поведение контракта.
                                      • Проэксплуатированная уязвимость.

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

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

                                    Самое читаемое