Раздувание блокчейна: как Ethereum решает проблемы хранения данных

24 270 токенов. 27 358 ожидающих транзакций. 463 713цифровые котята.

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

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

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

И разработчики признают эту проблему.

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

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

«Тот факт, что улучшение этого материала имеет решающее значение, был известен с конца 2016 года, идеи витали в воздухе от полугода до года. Где же реализации?» — недавно заявил создатель Ethereum Виталик Бутерин на канале разработчиков.

Разочарование ощутимо как у Бутерина, так и у Афри Шоедона, который управляет техническими коммуникациями в клиентском провайдере программного обеспечения Ethereum Parity. Шоедон сказал CoinDesk:

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

В попытке ограничить последствия громоздкого состояния два самых популярных клиента Ethereum — Geth и Parity — недавно выпустили обновления, которые пытаются улучшить ситуацию.

С турбонаддувом

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

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

Обновление даже вызвало восторженный отклик у Бутерина, который написал на канале разработчиков: «Ух ты! Как вы, ребята, этого добились?»

В результате обновления пользователисообщализначительно улучшенный опыт.

В то же время независимый разработчик Алексей Ахунов работал над переписыванием клиента geth, названного «turbo geth». Ахунов описывает его как"одержимость,"Цель проекта — устранить множество ненужных повторений в том, как клиенты Ethereum обрабатывают общее состояние.

Хотя он еще далек от готовности, он открыл некоторые интересные пути «спекулятивной оптимизации», сказал Ахунов в недавнем чате разработчиков.

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

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

Пределы

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

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

«Теперь я поддерживаю подход безгражданского клиента», — написал Бутерин.

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

Ахунов в недавней статье писал, что такие клиенты могут стать возможным решением проблем масштабирования, с которыми столкнулся Ethereum после успеха CryptoKitties. запись в блоге: «Я считаю, что (клиенты без сохранения состояния) могут быть реализованы уже сейчас, без какого-либо хард-форка, «просто» путем изменения клиентов Ethereum ... Это означает, что узлам не нужно получать доступ к хранилищу из файлов, а время проверки блоков должно значительно сократиться».

Однако оптимизация клиентов T может быть единственным, на что полагается сеть для снижения беспокойства о состоянии.

По словам Силади

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

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

«Мы можем оптимизировать базу данных и сделать ее в десять раз быстрее и оптимальнее, что дает нам возможность вырасти в десять раз по сравнению с нашим текущим размером», — сказал Силади, добавив:

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

Жесткий дискизображение через Shutterstock