В минувшее воскресенье сооснователь Ethereum Виталик Бутерин в очередной раз сделал в своём Twitter интересные заявления о будущем децентрализованных криптоплатформ.
Он акцентировал внимание на том, что вся их экосистема ещё должна созреть для приёма крупных институциональных инвестиций. А пока она должна внутренне развиваться максимально свободно, без сковывающего его развитие регулирования, даже если это снизит приход в неё средств. Нет сомнений, что Бутерин знает, что говорит, и именно он особо остро чувствует многие проблемы отрасли, в том числе находящиеся в сфере технологий. В том числе — проблемы масштабирования и объёмов копий блокчейнов.
Для иллюстрации рассмотрим воображаемую простейшую блокчейн-платформу, которая фиксирует самые простые операции по переходу из рук в руки неких токенов. Допустим, что в её сообществе есть всего 10 миллионов кошельков физических и/или юридических лиц. Допустим, что запись о каждой транзакции занимает 100 байт: 32 байта — кошелёк отправителя, 32 байта – данные или сумма переходящего актива, и ещё 32 байта – кошелёк получателя. Ещё 4 байта – служебная информация, допустим дата и время.
Абстрагируемся от способа и времени укладки блоков, возможного архивирования и шифрования данных. Примем за допущение, что каждый клиент сети в день совершает в среднем 10 транзакций.
Тогда ежедневный объём информации составит 100 байт * 10 транзакций * 10 000 000 пользователей = 10 000 000 000 байт или 10 Гбайт (Gbyte). За месяц — 300 000 000 000 байт (300 Гбайт). За год 3 650 000 000 000 байт, то есть 3,65 терабайт.
Конечно, этот объём не критичен для современных носителей, вполне доступных частным лицам, желающим держать у себя ноды блокченов. Но мы рассматривали самую простую и компактную схему. А если, как в Ethereum, для подтверждения нового блока необходимы данные о состоянии всех смарт-контрактов (в том числе закрытых) и надо хранить их код? Да, в блокчейнах практикуются «обрезки» и «отсечки» старого. Однако объёмы упираются в скорость проверки, а это – время.
Кстати, в дне 86400 секунд, и для нашей простой гипотетической системы потребуется скорость не менее 1158 транзакций в секунду. Конечно, все эти проблемы преодолимы, но для этого потребуютя архитектурные решения и время.
