В сети сейчас постоянно идёт нагнетание интереса к теме нейросетей, которые почему-то называют искусственным интеллектом (AI, ИИ). Поступает бесконечный контент о том, кто, кого и когда заменит.
Обладая знанием более чем пяти языков программирования на уровне мидла и сеньора, мне вроде бы это и не требовалось, но жажда познания чего-то нового победила.
Итак, я решил устроить челендж себе и нейронкам. Сможем ли мы создать сложное и нетиповое приложение/сервис? Я выбрал язык Rust (который не знал совсем), чтобы как программист я не мог сильно влиять на результат. А приложением стала блокчейн-нода с нуля. Конечно, я не собирался заставлять нейронку писать протоколы взаимодействия, методы хеширования и подписи, но и готовый фреймворк был под запретом.
В качестве нейронок были выбраны наилучшие (про, эксперт и т.д.) бесплатные, но лимитированные по запросам, а также локальные (но с ними в итоге не сложилось). Также были исключены китайские и российские нейросети. Я не называю имена, потому что они быстро прогрессируют, а кому надо всё равно сможет догадаться.
Я заранее знал о недостатках множествах решений в сфере блокчейна. К примеру, Solana, ТОН, Aptos слишком монструозны и избыточны. Их возможности ещё не скоро будут востребованы. Ethereum и BSC относительно примитивны. Биткоин так вообще мировая энергетическая угроза :) Экономику оставлю другим, я только про технологии.
В общем, я собрал все свои знания в кулак и понял, что мне как архитектору их всё-таки не хватает, и начал консультироваться с нейронками ещё до создания первых строк кода. Забегая вперёд, скажу, что ко всем запросам я добавлял «современное, энергоэффективное, лучшее и т.д.», чтобы избежать устаревших технологий — а они были, так как мне предлагалось даже PoW и штуки от биткоина…
Архитектура
p2p взаимодействие
Первое, что хотелось это быстрое общение между нодами, и нейронка почему-то начала с TCP, несмотря на указание быстрого обмена. Я настоял на UDP, и тут пошла полезная информация со скоростями и производительностью. Меня соблазняли скоростью x10 у голого UDP, но я понимал, что после навешивания верификации, шифрования и прочего может быть даже хуже, и в итоге выбрал libp2p + QUIC.
Формат сообщений между нодами
Предложенные варианты: RLP, SSZ, FlatBuffers, Cap’n Proto. По производительности выигрывает последнее, но нейронка настоятельно (после просьб покруче, побыстрее) рекомендует FlatBuffers. Обосновывает, что в Cap’n Proto есть лишний функционал (RPC), но ведь его можно не использовать, а скорость важнее. Поэтому я пока сомневаюсь…
Выбор базы данных
Сразу предложили RocksDB, но почему? Возможно, потому что он внедрён в ноду эфира? Я же предполагал, что быстрее LevelDB не может быть.
Изучив досконально тему RocksDB, я осознал, что она идеально подходит, но не является «pure Rust», и при компиляции я это сразу ощутил. Решил, пока не поздно, поменять на redb, которую мне также предлагали, но с пометкой о снижении производительности после 100 ГБ, а мне нужно 1 ТБ. Однако и тут нейронка меня обманывала, так как есть пара настроек и этот недостаток нивелируется, а потребление памяти всё равно не превысит RocksDB.
Формат хранения в БД
Первое, что было предложено по упаковке транзакций и блоков это RLP от эфира, и пришлось снова просить нейросеть подумать получше. В итоге пришли к SSZ, которое уже существовало, но почему-то не было предложено изначально?!
Хранение аккаунтов
Кардинально нового подхода я не нашёл, но в технологии Verkle Tree меня заинтересовал метод проверки данных без необходимости загружать всё дерево (в Ethereum его размер уже превысил 1 ТБ). Такой механизм позволяет клиенту получать доказательства корректности состояния например, балансов аккаунтов или отдельных транзакций без скачивания полного набора данных. Это открывает путь к созданию сверхлёгких stateless-клиентов: мобильных кошельков или веб-приложений, которые могут самостоятельно верифицировать данные блокчейна, не полагаясь на API сторонних нод.
Машина для смартконтрактов
Предложено было только самое хайповое, но при этом TVM от TON почему-то игнорировалось, и только когда я напрямую попросил, его добавили в таблицу. По итогу выиграла TVM за счёт большей производительности. По мнению нейросети, она выигрывает даже смартконтрактам на Rust в Solana. Упомяну, что мне постоянно навязывалась EVM от эфира, которая вовсе не является флагманом в производительности.
Остальное
Остальное что я решил применить, чтобы раскрыть тему выбора технологий блокчейна:
- BLAKE3 как алгоритм хеширования
- Ed25519 для цифровых подписей
- gRPC для апи с нодой (http API через отдельный прокси)
- Пороговое шифрование для рандномного выбора пропозера (комминтера) и возможного шифрования мемпула
- FunC смартконтракты
- Tokio для асинхронности
Так как вы уже поняли тенденцию, я завершу описание своих архитектурных изысканий на этом. Хотя ещё было немало подобных вопросов, но уже можно сделать однозначный промежуточный вывод, что нейросеть стремится не напрягаться и не погружаться глубоко в тему, выискивая идеальный вариант решения проблемы.
Вайбкодер соблазнится на предложенные варианты и не будет копать глубже, а если и будет, то велик шанс, что сама нейросеть пойдёт на его уговоры применить ту или иную предлагаемую технологию (у меня были случаи, где я настаивал, и приходилось открывать новый чат, чтобы убрать влияние).
Краткие итоговые недостатки нейросетей как советника:
- Стремление экономить на глубине изучения вопроса
- Стремление угодить собеседнику
- Актуальные выводы по прочтению нескольких статей, а не обобщённому действительному знанию вопроса.
- Может придумывать информацию (галлюцинируют), если не находит.
Программирование
Хочу сразу отметить, что далеко в разработке ноды блокчейна я не продвинулся даже близко к MVP и могу сказать, что код получился довольно плоский, поэтому мы процесс программирования рассмотрим на Тг боте, который я решил так-же сделать в рамках челенджа на расте.
ТГ бот будет запускать события по клику от любого участника. Будет иметь возможность добавлять события, поддерживать много чатов и т.д.
Первые же запросы и основа была собрана и почти сразу заработала и отправила «привет мир» в боте.
Вот оно счастье? Сделал запрос и приложение работает. Программисты больше не нужны! Сказали бы блогеры-популисты и хайпожоры. Но я продолжу.
И конечно, ранее я пробовал создавать разные микро-приложения и скрипты, но на языках, которые я понимал, где сразу видел ошибки и быстро их фиксил самостоятельно.
ТГ-бот постепенно наращивал функционал, и тут я решил, что всё-таки мне нужна мультиязычность и вынос текстовых сообщений в отдельный файл.
Кроме того, хотел форматирования сообщений в MarkdownV2 и тут началось…
Нейрокодер уже работал в режиме автоподтверждения предлагаемого кода, так как объём кода и язык Rust не позволял мне понимать, что происходит, да и хотелось именно, чтобы нейронка решила задачу.
Позже выяснилось, что он перебирает библиотеки методом тыка, пробует запускать и если получает ошибку, пробует другую, пробует менять версии и т.д. Всё это приводит к трате токенов за его же ошибки.
Форматирование в MarkdownV2 вскрыло, что нейрокодер не может адекватно работать с экранированием, которое сам же делал. Даже новый запуск уже работающего экранирования он хотел переделывать. Кстати эта проблема с экранирования позже проявилась и с Spring + Kotlin.
Как и с нодой блокчейна код был очень плоским и я попросил рефакторинга и разделения на модули. Но этого не произошло почему-то. Уже не помню, как добился разделения, возможно, частично вручную переносил.
В процессе работы с этим ботом я уже начал изучать Rust по видеоурокам и онлайн-книгам. Не столько по желанию, сколько от безысходности, что нейронка не может решить элементарные проблемы.
Далее я заметил, что данные сообщений модуля мультиязычности перечитываются с каждой отправкой сообщения, и я попросил, чтобы они загружались в память один раз и использовались и тут снова всё сломалось…
Нейрокодер начал исправлять, так как модуль не был потокобезопасным (на самом деле был) и пошло перебирание версий библиотек по новой, которое я в полуручном режиме уже исправлял ранее при интеграции мультиязычности. В итоге на время забросил проект и вернулся уже с некоторым знанием Rust и всё снова вручную исправлял.
Кстати, в написании ноды для блокчейна тоже была история, когда нейрокодер решил инициализацию TVM вставить в каждое исполнение смартконтракта вместо одной инициализации и передачи ссылки внутрь потоков.
Был момент, когда я хотел оставить 1-2 параметра в функциях вместо передачи одинаковых параметров. Попросил сделать одну структуру из этих переменных, чтобы не было списка на входе функции и тут вскрылся факт того что нейронке не хватает памяти для передачи (лимит миллион токенов). Было примерное 100-200 упоминаний функции и теоретически должна была произойти замена, но нейронка безрезультатно завершала работу.
Позже я выяснил, что нейронка использовала не последние стабильные библиотеки, а те что были описаны где-то в интернете с примерами, и оттуда тянула знания (хотя в логах размышлений было видно хождение за онлайн документацией).
Если вы попросите нейрокодер написать консольную утилиту, которая будет читать файл, то она напишет, но там не будет валидации ввода, приложение может вывалиться в ошибку если файла не существует, или повесить сервер если файл большой и сделать дыру в безопасности. Всё это надо просить, а откуда неопытному программисту знать, где надо подстелить солому?
Тем временем с помощью Spring Boot (и многих других современных фреймворков) можно так же просто создать асинхронный веб-сервер.
@RestController
class HelloController {
@GetMapping("/hello")
fun hello(): Mono<String> {
return Mono.just("Hello, World!")
}
}
Так-же может выглядеть код для обращения в базу данных, общения с сервисами сообщений, брокерами и т.д. Базовые возможности уже много раз придумали и сделали простыми и именно в них нейронка сильна.
Я думаю в этом и будет будущее разработки с нейросетями. А возможно и изобретение нового языка программирования, где человек визуально всё ещё будет понимать что происходит в приложении.
Итоговые недостатки нейросетей как кодера:
- «Плоский» код без архитектуры.
- Склонность использовать устаревшие или выдуманные библиотеки.
- Частые ошибки в инструменте замены, оставление артефактов и лишних символов.
- Переписывание функционала, которое не нужно было трогать.
- Зацикливание при исправлении своего же бага.
- Превосходство только в базовых алгоритмах и типичном ПО, которое уже много раз разрабатывалось.
- Экономность. Не напишет того, что не попросишь, но делать надо (отлов ошибок, валидаций ввода, тестов и т.д.).
- Вероятно полная бесполезность в монолитном легаси коде.
Несмотря на недостатки и критику, я однозначно считаю нейросети полезными в разработке ПО и во многих других жизненных и научных задачах, но нужно уметь правильно и полноценно ставить задачи. Боюсь что постановка задач от ПМа или даже аналитика без опыта в программизме будет недостаточна. Пока что не получится попросить "сделай хорошо" без деталей.
Нейросеть может успешно (как минимум приближается к этому) разрабатывать полноценные микросервисы и какие-то большие приложения/сервисы, но на основе автономных модулей и где функционал максимально покрыт тестами.
Мой эксперимент/челендж не закончен и возможно я ещё вернусь и уделю больше самому процессу разработки.