Проблемы на пути блокчейна 3.0: как агрегационный кластер улучшит инфраструктуру Graphene

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

Она способна увеличивать пропускную способность сети за счет использования инвертируемых поисковых таблиц Блума (IBLTs) и Bloom-фильтров на базе технологии Simplified Payment Verification. На данный момент максимальная скорость транзакций, выявленная в процессе тестирований, — 10628 х/с. Для сравнения, максимальный показатель скорости транзакций в блокчейне Ethereum — 30 x/c.

О существующей инфраструктуре Graphene, ее главных проблемах и путях их решения журналу ForkLog рассказал блокчейн-архитектор и создатель блокчейн-протоколов Scorum.com и DEIP.world Алекс Шкор.

Проблемы инфраструктуры Graphene:

1. Пользовательский опыт и внедрение

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

2. Проблема масштабируемости

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

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

Решение

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

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

Фреймворк Graphene обрабатывает каждую операцию в одном потоке и хранит все данные в памяти. Благодаря этому его пропускная способность достигает нескольких тысяч транзакций в секунду и создает огромный потенциал для дальнейшей настройки и оптимизации. Прообразом Graphene послужила архитектура LMAX, в которой представлен быстрейший в мире трейдинговый движок, способный обработать 6 млн транзакций в секунду.

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

Так, в Graphene все данные находятся в состоянии строгой согласованности, что очень важно для блокчейн-проекта. Однако помимо данных, необходимых для валидации домена, Graphene хранит информацию для отображения на UI.

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

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

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

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

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

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

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

Кластер обеспечивает необходимый уровень избыточности данных для того, чтобы откатить состояние в любую временную точку. Это происходит через ивент-центрическую модель (event centric design model), принцип CQRS и парадигму «согласованности в конечном счете» для модели чтения, но в то же время поддерживая модель записи данных в строгой согласованности.

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

Постоянные улучшения

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

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

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

Скачивайте приложение ForkLog для Android-смартфонов!