От переводчика: оригинальный материал состоит из двух частей, отвечающих на вопросы "Почему?" и "Как?". Я решил объединить их в одну статью, поскольку все самое интересное содержится во второй части. Вы можете с чистой совестью переходить к ней, если вам не интересно почему автор решил сделать этот проект и интересно только как он его реализовал. Поскольку стандартная ссылка на перевод на Хабре может вести только на одну публикацию, ссылка на оригинал второй статьи будет в начале второй части.
Я хочу также отметить, что статья не про криптовалюты и не объяснит вам как работает PoS. Она про использование искусственного интеллекта при разработке программного обеспечения.
Часть I. Почему я решил это сделать
Всем привет! Меня зовут Тим и я недавно завершил проект под названием ether-pos, цель которого — объяснить, как на самом деле работает система Proof of Stake (PoS, Доказательство доли владения) Ethereum. Если вы еще не видели ее, посмотрите здесь: ether-pos.
Позвольте мне немного рассказать о том, почему я его создал и чему я научился в процессе.
Небольшое введение
Два месяца назад я решил глубже погрузиться в технические вопросы криптовалют. Ранее я немного занимался криптовалютой и изучил основы Solidity и FunC TON, но я часто чувствовал пробелы в своем понимании, особенно при чтении технических дискуссий или расследований о взломах в твиттере. Я хотел преодолеть этот пробел и понять технологию блокчейн за пределами базового уровня.
Итак, я составил план обучения: создал доску Kanban в Notion, поставил ежедневные цели и обсудил свой подход с ChatGPT.
Одной из моих первых задач было прочитать Ethereum’s Mauve Paper — документ, в котором изложена дорожная карта перехода Ethereum от Proof of Work к Proof of Stake.
Читаем Mauve Paper
Mauve Paper — это короткий, но емкий документ — шесть страниц, которые описывают дизайн Ethereum 2.0 и его переход к PoS. Он начинается с простого прямолинейного введения, которое я нашел доступным для понимания.
Но как только я дошел до первого технического раздела «Минимальное доказательство доли владения», я уперся в стену. Я читал эту часть несколько раз в течение примерно 40 минут и все равно понял только половину.
На этом этапе у меня было два варианта: отложить статью в сторону пока я не изучу ее подробнее или углубиться в нее пока не пойму ее полностью.
Я выбрал последнее.
Я скопировал текст в ChatGPT и попросил его разбить каждый раздел. Это было не так просто — GPT не понял некоторые концепции и мне пришлось задать более 20 дополнительных вопросов. Но в конце концов, примерно через шесть часов, я закончил работу.
Удивительный раздел? Не было никаких ошеломляющих формул или сложных алгоритмов — только элегантное сочетание простых принципов, которые сформировали сложную архитектуру Ethereum 2.0.
Пробел в знаниях и почему он меня раздражает
Я потратил много времени на самообразование и почти в каждой интересующей меня области я заметил огромный разрыв между популярными ресурсами и объяснениями профессионального уровня.
Если вы введете в поисковике YouTube запрос «Что такое Proof of Stake?», вы найдете бесчисленное множество видеороликов продолжительностью 5–15 минут, которые дают достойный обзор.
Некоторые из них хорошо сделаны и интересны, но они никогда не дают полного ответа на вопрос «как работает PoS "под капотом"».
С другой стороны, чтение «Mauve Paper» или любого серьезного технического документа похоже на чтение чьей-то диссертации — требуется много контекста чтобы хотя бы понять терминологию.
Этот разрыв меня расстроил. Я хотел и то, и другое:
Глубокое понимание того, что происходит под капотом. Но в этом вопросе я реалист: если, например, есть какое-то сложное дифференциальное уравнение, возможно я никогда не смогу его понять, но, по крайней мере, я буду знать что сделал все возможное чтобы его понять.
Ценный пользовательский опыт — вроде анимированных видео на YouTube. Я готов посмотреть 10 или 20 из них и потратить много времени, но я не хочу читать статью из научного журнала в которой я не могу понять и половины слов.
Сочетание этих качеств, на мой взгляд, встречается довольно редко и часто находится в платным доступе. Хуже того, поскольку вы на самом деле не знаете, что вы получите после оплаты, вы можете потратить деньги и обнаружить что там нет ничего кроме того, что вы уже узнали из бесплатных видео на YouTube. Я это проверил.
Мой способ решения: ether-pos
Я хотел найти лучший способ понять сложные концепции не продираясь сквозь научные статьи или не тратя часы на их анализ с помощью ИИ. И я решил создать свой проект ether-pos.
План состоял в том, чтобы взять «Mauve Paper» — которая сложна, но, в конечном итоге, основана на простых концепциях — и представить ее следующим образом:
Можно понять меньше чем за час.
Можно участвовать самому и иметь наглядные примеры использования.
Должна быть достаточно глубокой чтобы чувствовать себя уверенно в этом вопросе.
Я прочитал весь свой чат с GPT, выделил ключевые моменты в которых я достиг понимания и перевел их в интерактивное веб-приложение. Я использовал React (который я едва знал) и не писал никакого кода сам, просто собрал его с помощью инструментов, которые были у меня под рукой.
Конечный результат — пошаговое руководство по сети Ethereum от становления валидатором до ставки на завершение (betting on finality). Он отражает разделы Mauve Paper, но преобразует их в удобоваримые интерактивные шаги.
В заключение первой части
Я потратил на этот проект более 50 часов — гораздо больше чем я ожидал. Теперь я понимаю почему подобные ресурсы обычно не находятся в свободном доступе в сети: требуется много времени, чтобы превратить такой контент во что-то доступное.
Я надеюсь оптимизировать этот проект в будущем, но даже в таком виде оно того стоило.
Независимо от того, интересовались ли вы Ethereum PoS раньше или нет, я надеюсь, что ether-pos поможет вам узнать что-то новое. Изначально я создал этот проект только для себя, но после его завершения и развертывания я понял, что хочу чтобы он был доступен и другим людям, которые также хотят глубже понять как работает криптовалюта вообще и PoS в частности.
Это мой первый проект с открытым исходным кодом и первый образовательный проект, и мой первый пост на Medium — поэтому у меня нет больших ожиданий. Но если вы найдете проект интересным, пожалуйста, не стесняйтесь делиться им. Я определенно буду создавать и другие проекты, подобные этому, углубляться в другие темы и делиться тем, что я узнаю по ходу дела.
Это мой первый опыт работы над чем-то некоммерческим, где мне не нужно думать о броских заголовках, текстах, наполненных смыслом чуть более чем наполовину, и прочей раздражающей коммерческой ерунде. И это потрясающе!
Спасибо, что дочитали.
Часть II. Как я это сделал
Оригинал тут: https://timsh.org/how-i-created-an-ethereum-proof-of-stake-demo-entirely-with-ai/
Введение
Итак, я решил создать этот проект, но как это сделать?
Коротко о себе:
Я никогда не работал разработчиком. Я изучил Python пару лет назад и использовал его для прототипирования и тестирования API, но я никогда не разрабатывал приложений промышленного уровня.
С начала 2023 года я пишу код с помощью ChatGPT — и очень доволен. Он хорошо подходит для небольших проектов (в идеале — отдельных файлов) и простых задач — например, для написания SQL-запроса или скрипта на Python.
Но, работая над более крупными проектами с помощью GPT, я чувствовал себя несчастным — я быстро терялся в хаосе бесконечных чатов, и обычно это заканчивалось тем, что проект становился хуже, чем он был раньше.
А затем, в июле 2024 года, я открыл для себя Cursor — версию VS Code на базе искусственного интеллекта, которая сохраняет вашу кодовую базу в контексте и автоматически применяет изменения к любому файлу.
И это изменило мой рабочий процесс, а также уровень и качество проектов, которые я делал. Ниже я опишу как я создал свой последний проект и что я узнал в процессе — надеюсь, вы найдете это полезным.
Причины использовать две LLM одновременно
Как я уже писал в первой части, я начал работать над этим проектом после очень долгой беседы с ChatGPT в попытке понять все технологии, алгоритмы и идеи, лежащие в основе каждого раздела «Mauve Paper».
Закончив работу, я составил список всех важных иллюстраций, примеров и шагов, которые помогли мне понять каждую конкретную часть Proof of Stake в Ethereum.
Затем я попытался сформулировать для себя шаги создания этого проекта — в то время я понятия не имел как он будет выглядеть и как он будет работать, я просто хотел построить что-то, чтобы объяснить все это интерактивным и интуитивно понятным способом. По моему мнению, вы действительно понимаете что-то теоретическое только после того, как увидите кучу примеров с реальными числами или даже попрактикуетесь в этом.
Именно тогда я сформулировал свою «проблему» в сравнении с моими предыдущими проектами, требующую нового подхода к работе с использованием ИИ.
Проблема:
Я хотел дать LLM работающему в качестве кодера четкие и подробные инструкции. В противном случае мы бы довольно скоро все испортили. Я бы в итоге смешивал свои мысли о том, как визуализировать что-то с реальными инструкциями о том, что делать или даже с вопросами об используемых технология — и тонул бы в ошибках и чепухе.
В то же время у меня еще не было этих инструкций и я не знал как их писать. Все, что было у меня в голове:
- то, что я смог понять из Mauve Paper
- упомянутый список примеров и ключевых моментов
- высокоуровневое видение того как может выглядеть UX
Решение, которое я придумал и которое использовал до развертывания готового проекта, представляло собой схему с двумя LLM помогающими друг другу.
ChatGPT в роли «менеджера проекта»
Я использовал ChatGPT 4o в качестве «менеджера проекта» который помогал мне разрабатывать пользовательский интерфейс и писать технические требования для каждой части проекта. Я выбрал ChatGPT просто потому, что мне нравится интерфейс его чата — когда вы общаетесь с менеджером проекта вам не нужно писать или внедрять код.
Примечание: я предпочитаю хранить все обсуждения одного проекта в одном чате. Таким образом вы никогда не потеряете то о чем спрашивали, и ChatGPT сможет запомнить все что обсуждалось.
Ключевые аспекты «менеджера проекта» для LLM + практические советы
Он должен понимать (или делать вид что понимает) тему над которой вы работаете — в нашем случае Mauve Paper. Ваше собственное понимание — очень важное предварительное условие. Это было первое что я отправил ему после введения — весь текст статьи. Позже, работая над проектом, я пересылал его в тот же чат более десяти раз, когда чувствовал что он теряет контекст в куче новых сообщений. Последнее чего вы хотите — это чтобы LLM начал придумывать следующий раздел или формулу из источника посреди проекта. Если вы не поймаете его в нужный момент у вас получится проект, основанный на ерунде.
Он должен понимать все, что понимаете вы и быть сосредоточенным на «деловой» стороне вещей — ваших целях, вашем определении выполненного и т. д. В этом контексте полезно время от времени просить его подвести итог всего проекта со всеми разделами и шагами (у меня их получилось около 20) и поправлять его если он начинает забывать общую картину.
Он должен вместе с вами выбрать весь стек технологий, который будет использоваться в проекте и определить начальную структуру проекта. Обратите внимание, что выбранный стек должен хорошо понимать как GPT, так и Cursor — по этой причине мы решили остановиться на React с MUI UI Kit. Но, что касается структуры проекта, я начал его с однофайлового «MVP», а позже как бы позволил Cursor выбирать любую понравившуюся ему опцию — часть разделов была написана в отдельных файлах, в то время как другие состояли из отдельных файлов для каждого шага (компонента). Это была одна из вещей на которой я недостаточно сосредоточился в начальне работы, а потом сильно об этом пожалел (это стоило мне более 10 часов педантичного рефакторинга).
Должно быть известно о других сторонах, работающих над проектом, и результатах, которые они предоставляют — в этом конкретном примере вам нужно рассказать ему о Cursor, его роли (кодера) и роли GPT. Кроме того, полезно напомнить GPT, что вы не хотите, чтобы он писал код для Cursor — вместо этого ему нужно сосредоточиться на технических требованиях и позволить Cursor выполнять свою работу.
После того как Cursor выполнит задачу (это относится к каждой задаче) вы должны отправлять GPT результат (в моем случае изменения в пользовательском интерфейсе) с вопросами типа: «Как вам нравится работа Cursor? Предложите какие-нибудь улучшения в новой инструкции». Это способ сообщить ChatGPT о ходе выполнения вашего проекта с точки зрения менеджера проекта — он не знает и не заботится о коде, он видит только то, что видите вы и конечные пользователи.
Очень важная вещь, которую я усвоил через несколько часов после начала разработки: ChatGPT любит возвращать вам вашу неопределенность. Например, вы можете попросить его: «Попроси Cursor использовать какой-нибудь модуль js для создания столбчатой диаграммы с данными». Обычно GPT помещает эту вашу неопределенность (какой модуль использовать) в инструкцию, как в примере ниже. Поэтому вам всегда нужно напоминать ему, что его работа — исследовать библиотеки, которые можно использовать, и, что самое важное, выбрать один вариант для включения в инструкцию для Cursor.
В заключение этого раздела
Относитесь к GPT как к настоящему менеджеру проекта. Он должен:
Знать что происходит.
Понимать что мы делаем для конченого пользователя.
Ставить для Cursor подробные и четкие задачи.
Совет: Всегда внимательно читайте предложения GPT. Если не уверены, повторно отправьте вводные данные. Не принимайте инструкции в которых нет определенности и подробностей — за это позже Cursor скажет вам спасибо.
CaaC (Cursor as a Coder)
Как уже упоминалось, моей целью было сохранить Cursor в состоянии определенности, снабдив его законченными инструкциями и техническими требованиями.
В августе 2024 года в Cursor появился замечательный режим под названием «Composer», который позволяет автоматически применять изменения к нескольким файлам. Я не пользовался чатом в правой боковой панели — он бесполезен по сравнению с Composer.
Работа с Composer имеет свои нюансы — ниже я попытаюсь изложить рабочий процесс и проблемы, с которыми мне пришлось столкнуться.
Ключевые аспекты работы Cursor в роли «кодера» + практические советы:
Поскольку я разделил роли между двумя вышеупомянутыми моделями, Cursor стало нехватать то ли понимания Mauve Paper, то ли высокоуровневого плана проекта (хотя в конечном итоге он понял все, что необходимо). Так что будьте готовы к бессмыслице, которую выдает Cursor — иногда он может ошибаться даже если инструкции были ясными и правильными, но в большинстве случаев бессмыслица в коде проистекает из плохих инструкций. Если вы обнаружите подобное — не вините себя, возвращайтесь в ChatGPT и заставьте его чувствовать себя виноватым :)
ДЕЛАЙТЕ КОММИТ ВСЕГО И ВСЕГДА. Даже самые незначительные изменения. Я сделал более 100 коммитов в процессе работы, это почти 15 на раздел, и это было мудрое решение. Поскольку вы работаете в Composer, вы не можете отслеживать все изменения, которые вносит Cursor. Иногда они могут включать удаление компонента или даже всей логики безо всякой причины.
Совет: используйте cmd (или ctrl) + K в терминале Cursor чтобы превратить ваш запрос на естественном языке в команду bash. Я нашел это очень полезным, особенно при работе с Git — после более чем 4 лет его использования я все еще не помню ничего, кроме базовых команд.
Для отладки используйте Cursor, а для архитектуры — ChatGPT. После отправки инструкций из ChatGPT в Cursor вы получите какой-то результат, который, наверняка, с первой попытки вам не понравится. Лично я разделил проблемы на две категории:
Проблемы с кодом. Это когда у вас отображается ошибка или какое-то значение оказывается не таким, каким должно быть и т.п. В этом случае программу надо отладить в Composer при помощи Cursor и обычно это решает проблему. При таком подходе вы экономите кучу времени, поскольку не делаете копипаст 10 раз подряд.
Проблемы архитектуры и дизайна. Имеется в виду как улучшение UI/UX, так и проблемы с логикой и тому подобное. В таких случаях я всегда упаковываю их в большое сообщение и отправляю в GPT, прося написать инструкцию для Cursor по устранению проблем и предложению улучшений. Я делаю это так, поскольку GPT находится в контексте вашего проекта и как бы понимает вашу архитектуру и подход к UX. Cursor — нет.
«Разблокирование» Cursor с помощью GPT. Иногда Cursor попадает в бесконечный цикл: вы просите его исправить что-то в 10-й раз подряд, но он все никак не может этого сделать. В таких случаях я копирую весь файл или несколько файлов, над которыми работает Cursor, и отправляю их в отдельный чат GPT (o-1 отлично подходит для этого) с инструкциями о том, что нужно исправить. В этом месте я ещё раз сделаю важное замечание: нужно специально попросить GPT отредактировать только нужную часть и отправить вам полный код, т.к. GPT очень любит пропускать ваши функции в ответе и издеваться над ними.
Если застряли и Cursor, и GPT, удалите задачу и начните решать её заново. Это довольно логично, но в какой-то момент вы можете забыть, что Composer может писать код снова и снова не прилагая усилий и боитесь, что вы что-то потеряете. Избегайте этого. Если у вас уже есть инструкция, написанная ChatGPT, скопируйте и вставьте ее как новое сообщение, затем скопируйте и вставьте проблемный код и краткий обзор того, что не сработало и как ваши совместные усилия все еще не помогли. Затем попросите GPT написать исправленную инструкцию, отправьте ее в Cursor и проверьте результат — удивительно, но иногда контекста достаточно и для GPT, и для Cursor, и вам даже может понравиться самая первая версия кода, написанная Cursor.
Создавайте локально файлы с копией хранилища данных и заставляйте Cursor обновлять их на каждом шаге. К сожалению, я пришел к этому только после того, как потратил 5 часов на то, чтобы разобраться с использованием локального хранилища в моем проекте. Дело в том, что Cursor имеет доступ только к тем файлам, которыми вы делитесь с Composer, таким как кодовая база или .cursorrules, упомянутым выше. К чему он не может получить доступ, так это к внешним хранилищам данных, например:
- базы данных (любого типа)
- локальное хранилище (важно для приложений, использующих React, как в моем случае)
Поскольку мой проект имеет каскадную структуру в которой предыдущие шаги влияют на последующие, мне нужно было где-то хранить промежуточные результаты (данные). Я использовал для этого локальное хранилище браузера. Проблема с которой я столкнулся заключалась в том, что, хотя Cursor писал код для чтения/записи переменных из локального хранилища, он не всегда запоминал структуру данных и точные имена переменных, разбросанные по кодовой базе. Как результат случалось такое: я просил Cursor «получить значение из «{variable_name}» в локальном хранилище и это приводило к проблемам. Решение, которое я придумал (и которое я настоятельно рекомендую), состояло в том, чтобы создать файл localStorage.json со структурой переменных в локальном хранилище, обновлять его каждый раз, когда Cursor добавляет новую строку кода, связанную с ним, и включать его в инструкции для новых функций.
Совет: указывайте типы данных в своих JSON, чтобы предотвратить ошибки, связанные с типами данных. Я потратил 1 час, пытаясь найти ошибку, которая произошла только потому, что Cursor думал, что переменная хранится как строка (а это было целое число). Я также обнаружил что передача JSON в ChatGPT была весьма полезной — с этими знаниями GPT мог ссылаться на точные имена переменных и полей в инструкциях, делая их еще более точными и подробными.
И наконец, некоторые вещи, которые я не сделал в этом проекте, и пожалел об этом
Если ваш проект включает тексты, которые может потребоваться отредактировать в будущем — подумайте заранее! В моем случае самые важные тексты были в боковой панели, во введении и в заключении. После завершения первого раздела я решил сохранить их в формате JSON, чтобы иметь возможность редактировать его отдельно от файлов проекта .js, содержащих код. Поместить его в файл «sidebarContent.json» показалось мне довольно удобным — я сказал об этом GPT и в каждой новой инструкции Cursor получал указание, что он должен импортировать sidebarContent.json и поместить в него новый текст боковой панели. Но в какой-то момент и GPT, и Cursor забыли об этом, поэтому в нескольких разделах текст был жестко закодирован в файлах .js. Таким образом первое важное знание — всегда напоминать GPT о том, как вы храните данные в проекте, когда запрашиваете новое задание.
Мне пришлось потратить некоторое время на доработку всех разделов, чтобы использовать один и тот же sidebarContent_new.json для содержимого боковой панели.
Затем возникла еще одна проблема: оказалось что часть моего текста была в формате Markdown (чтобы включать гиперссылки, формулы и т. д.), а некоторые разделы не были корректно настроены для обработки markdown. Из этого возникло еще одно знание — заранее продумывать что необходимо включить в текст, выбрать правильный формат (см. видео), а затем сказать GPT всегда напоминать Cursor об необходимости импорта модулей, используемых для обработки markdown и формул. Мне потребовался почти целый день на переписку текстов, рефакторинг всех разделов для правильной обработки и внесения окончательных правок. Не совершайте эту ошибку!Если в вашем проекте есть несколько страниц с одинаковой структурой — попросите Cursor создать шаблон! Это еще одна вещь, на которую я не обратил внимания в самом начале, и потом из-за этого набивал шишки несколько раз.
Мой проект структурирован довольно просто — в каждом разделе есть шаги, на каждом шаге присутствует боковая панель куда помещается специфический текст для данного шага, немного общего контента и кнопки «Назад» / «Вперед». Когда я создавал первый раздел, я думал, что могу просто ссылаться на его шаблон в инструкции для любого другого раздела и Cursor просто будет использовать тот же шаблон. Оказалось что это не так. Cursor испортил все, что мог — боковую панель, пропорции элементов, кнопки и индикатор прогресса. Мне нужно было сначала попросить Cursor создать пустой шаблон, а затем скопировать его и указывать Cursor редактировать содержимое с каждым новым разделом и шагом.По возможности избегайте сложных визуализаций при использовании внешних модулей для построения диаграмм. И используйте SVG! Если вам нужно создать динамическую диаграмму — старайтесь сделать ее как можно более простой, если вы хотите нарисовать что-то статическое, но более сложное — используйте вместо этого <svg>. Причина в том, что как Cursor, так и GPT не полностью понимают как изменение параметров диаграммы влияет на конечную визуализацию. Я сделал более 10 неудачных попыток когда пытался показать гистограмму на шаге выбора валидатора — это был кошмар. Но если использовать SVG — и Cursor, и GPT способны понимать как изменения в коде влияют на изображение. Попросить Cursor создавать SVG оказалось простой задачей которая обычно требовала не более одной итерации!
Смотрите примеры ниже.
Заключение
Что бы там ни говорили «эксперты», а серьезный проект с помощью ИИ построить за «2 подсказки и 5 минут» не получится, особенно с первой попытки. Это все равно требует много труда и времени.
Однако выбранное мною решение — использовать две LLM с разными ролями для работы над одним и тем же проектом — помогло мне сделать процесс понятным и организованным, что в конечном итоге позволило создать надежное веб-приложение.
Полученные мною навыки определенно помогут мне в будущих проектах. Я планирую создать более широкую базу знаний в которой будут собраны все мои идеи, подсказки и ошибки, чтобы поделиться ими со всеми вами — надеюсь, это поможет вам создать собственное приложение при помощи ИИ!
Огромное спасибо моему другу Виталику Павленко и его репозиторию шаблонов React с подробными инструкциями для проектов Cursor. Посмотреть их можно тут: https://github.com/vpavlenko/web-2024-template.
Впервые я узнал о Cursor из Telegram-канала Виталика, а затем консультировался у него (он очень щедрый человек, который охотно помогает другим). Он познакомил меня с Composer, и вот так все и началось.