АМА-сессия с Дмитрием Герасимовым, 26 сентября 2024

Привет всем! Меня зовут Дмитрий Герасимов, я руководитель проекта Cellframe. Это наша регулярная АМА-сессия, и сейчас я отвечу на вопросы, которые вы присылали заранее.

Расскажите, пожалуйста, как продвигается подготовка к запуску двустороннего моста? На каком этапе находится внешний аудит?

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

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

Теперь Cellframe Dashboard и Cellframe Node существуют как отдельные приложения. Какие преимущества дает такое разделение?

Мы движемся по специфическому пути: одни сервисы мы разъединяем, а другие объединяем, но по-новому. Речь идет о варианте для мобильных платформ. Здесь мы переработали модель взаимодействия ноды и дашборда. Сейчас пользователи часто сталкиваются с ситуацией, когда нода, которая автоматически устанавливается на устройство вместе с Cellframe Dashboard, очень сильно нагружает устройство, когда постоянно работает в фоновом режиме. Таких ситуаций больше не будет, потому что мы поменяли схему взаимодействия ноды и дашборда. Теперь нода будет активна только тогда, когда активен кошелек. Поэтому именно для мобильных версий мы создаем монолитное приложение, которое объединяет в себе и ноду и сервис дашборда и Cellframe Wallet.

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

И последний use-кейс самый интересный: Cellframe Wallet для работы с внешней аппаратной нодой. В преддверии этого мы и делаем такое разделение.

Планируются ли в будущем еще какие-нибудь значительные изменения в Cellframe Dashboard?

Самое важное изменение — это объединение с Cellframe Wallet. К тому же, мы продолжаем расширять нашу экосистему, и соответственно, будем и дальше добавлять новые расширения для работы с сервисами в Cellframe Dashboard. Мы изначально планировали его как «суперприложение», и дальше будем продолжать двигаться в этом направлении.

Какое количество мастернод, на ваш взгляд, будет оптимальным для сети Backbone? Возможна ли ситуация, когда мастернод в сети «слишком много»?

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

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

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

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

Проект QEVM работает над внедрением поддержки смарт-контрактов в экосистеме Cellframe. Означает ли это, что команде Cellframe больше не нужно разрабатывать поддержку смарт-контрактов?

К сожалению, нет. Нам все равно нужны нативные смарт-контракты для ряда задач. Мы будем использовать стандартные WASM смарт-контракты на Rust и постараемся сделать их максимально совместимыми с другими экосистемами, такими как Solana и Polkadot.

Нужны ли экосистеме Cellframe оракулы? Если да, используются ли они в настоящее время или их внедрение планируется в будущем?

Да, оракулы, конечно, нужны, и они уже активно используются, но часто не в самой оптимальной форме. Можно провести аналогию со старыми шутками среди программистов: в сложных программах всегда скрывается плохо спроектированная и неоптимизированная Lisp-машина. Хотя когда-то была идея внедрять Lisp или Haskell повсюду, в реальности это не сработало.

С оракулами складывается похожая ситуация: разные проекты используют свои специфические, часто несовершенные версии оракулов. Это касается, например, мостов между блокчейнами и проектов вроде Dotflat, где тоже разрабатывают собственные оракулы. Я задумывался над созданием универсального механизма для оракулов, и нашим решением могут стать t-Dapps, которые мы уже используем. Возможно, в будущем мы разработаем поверх них что-то еще более универсальное, но на данном этапе я не вижу острой необходимости в этом.

Многие небольшие проекты сталкиваются с трудностями в период «медвежьего рынка». Если такие проекты захотят присоединиться к Cellframe, готовы ли вы им помочь?

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

Планируете ли вы разработку новых сервисов на основе блокчейна? Возможно, L2-решений?

Да, мы планируем.

В каких случаях целесообразно создавать отдельную сеть для сервиса, а когда выгоднее использовать уже существующую?

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

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

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

Станет ли квантовая безопасность одним из ключевых вопросов на следующем буллране?

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

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

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

Это были все вопросы на сегодня. До новых встреч!