Я сделал демонстрацию Ethereum Proof of Stake при помощи искусственного интеллекта

От переводчика: оригинальный материал состоит из двух частей, отвечающих на вопросы “Почему?” и “Как?”. Я решил объединить их в одну статью, поскольку все самое интересное содержится во второй части. Вы можете с чистой совестью переходить к ней, если вам не интересно почему автор решил сделать этот проект и интересно только как он его реализовал. Поскольку стандартная ссылка на перевод на Хабре может вести только на одну публикацию, ссылка на оригинал второй статьи будет в начале второй части.

Я хочу также отметить, что статья не про криптовалюты и не объяснит вам как работает 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.

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

Именно тогда я сформулировал свою «проблему» в сравнении с моими предыдущими проектами, требующую нового подхода к работе с использованием ИИ.

Проблема:

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

2. В то же время у меня еще не было этих инструкций и я не знал как их писать. Все, что было у меня в голове:
   – то, что я смог понять из 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 вы получите какой-то результат, который, наверняка, с первой попытки вам не понравится. Лично я разделил проблемы на две категории:

  1. Проблемы с кодом. Это когда у вас отображается ошибка или какое-то значение оказывается не таким, каким должно быть и т.п. В этом случае программу надо отладить в Composer при помощи Cursor и обычно это решает проблему. При таком подходе вы экономите кучу времени, поскольку не делаете копипаст 10 раз подряд.

  2. Проблемы архитектуры и дизайна. Имеется в виду как улучшение 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, и вот так все и началось.