Путь к RPCh — часть 3
(Оригинал статьи от 01.02.2023) Мы вернулись из Колумбии с новой командой и большим желанием. RPCh должен быть первым продуктом на базе HOPR — четкий сценарий использования протокола, который не просто обеспечивал неопределенное усовершенствование конфиденциальности, а решал острую и своевременную проблему в web3. Пользователи были в предвкушении, кошельки были в ожидании, мы были в волнении.
Но нужно было начинать настоящую работу, причем быстро. За последний месяц мы сотрудничали с полудюжиной электронных кошельков, и все они были готовы предоставить своим пользователям конфиденциальность через RPCh посредством прямой интеграции в свой пользовательский интерфейс. Это был огромный успех для HOPR, но эти контракты зависели от того, что решение будет готово через несколько месяцев, а не лет.
Архитектурный дайджест
В ходе хакатона была создана великолепная концепция, но она была далека от продукта или даже от эскиза для него. Эта версия RPCh требовала, чтобы пользователь самостоятельно обеспечивал себя необходимым — сервером RPC, узлом HOPRd.
Она работала, что было огромным достижением, но это был не продукт и не сервис. При таком раскладе мы должны были платить пользователям, а не наоборот!
И это был первый из многих вопросов, которые мы больше не могли откладывать. Кто будет платить за RPCh? Будут ли за это платить пользователи, возможно, в качестве дополнительной платы за газ? Или же платить будут кошельки, которые либо возьмут на себя расходы, либо каким-то образом переложат их на пользователей?
Наши внутренние исследования показали, что потребители ответили, что были бы рады платить, но это всегда проблема с конфиденциальностью: все заявляют, что хотят ее, но когда доходит до дела, то немногие готовы что-то сделать для этого.
Быстро было решено, что RPCh будет предназначен для кошельков в качестве дополнения к существующему решению RPC.
Однако это решение уже имело огромные последствия: если вы предлагаете пакеты услуг, например, 10 миллионов запросов RPC в месяц, вам нужен способ задать квоту, отследить ее и ограничить услугу, когда она закончится. Архитектура такой системы будет полностью отличаться от той, где RPCh оплачивается за транзакцию. Не говоря уже о последствиях для того, как RPCh будет распространяться и распространяться на рынке.
И это только один из многих аспектов, которые необходимо было рассмотреть, каждый из которых имел свои последствия и ограничения для дизайна.
Это может показаться непосильной задачей, но одна из самых приятных частей разработки программного обеспечения — это разбиение огромной проблемы на все более четкие и управляемые задачи. Нет ничего лучше, чем начать со схемы и идеи, а закончить дорожной картой и упорядоченным списком для упакованного спринта в GitHub.
По крайней мере, для меня :)
Путь к дорожной карте
Как и во всем в RPCh, работа была командной. Сначала были размышления на профессиональном уровне: как будет выглядеть RPCh как услуга? Кто будет платить? Кто будет управлять узлами RPCh и получать за это вознаграждение? Будут ли они отличаться от стандартных узлов HOPR в своей работе и механизме вознаграждения? Каким образом?
В результате был разработан проект архитектуры с различными компонентами, их функциями и взаимосвязями. Я не могу приписать себе эту заслугу: большая часть работы была выполнена основателями и командой, поэтому, когда я вернулся в цюрихский офис после отпуска в Колумбии, меня ждал высокотехнологичный проект.
Моя задача, как руководителя проекта, заключалась в том, чтобы взять этот эскиз и превратить его в реальный замысел дальнейшей разработки. Как будут собираться различные компоненты и в каком порядке мы будем их собирать? Как они будут тестироваться? Как и когда кошельки получат доступ, через SDK или иным образом?
И, что очень важно, кому будет поручено создание отдельных функций?
Поскольку наряду со всей этой работой над дизайном существовала параллельная задача, решение которой было чрезвычайно полезным. Мы наняли Камилио, Диего и Луис — трех колумбийцев, которые показали отличные результаты на хакатоне, — в качестве членов новой команды RPCh. Мы были очень впечатлены их работой и энтузиазмом, но они все еще были относительно молодыми специалистами, особенно когда дело касалось крипты. График разработки RPCh означал, что большая часть их обучения должна была проходить без отрыва от работы. Они также находились в совершенно другом часовом поясе, чем я, что означало, что им нужно было иметь возможность работать над задачами без присмотра на протяжении значительной части их дня.
Как и все остальные члены команды HOPR, новички прошли через стандартный процесс адаптации в HOPR, начиная с изучения наших различных процессов и инструментов командной работы и заканчивая потрясающими практическими занятиями по Ethereum от нашего основателя Себастьяна (которые проходят все в HOPR, независимо от роли или технического опыта).
Это отличный способ обучения, однако он также имел важные последствия для дорожной карты. Как и любой проект, создание RPCh имеет некоторые зависимости — вещи, которые должны быть построены в определенном порядке, потому что они зависят друг от друга. Есть и внешние зависимости: протокол HOPR все еще находится в разработке, поэтому нам нужно работать в рамках дорожной карты. Также нужно спланировать, как и когда передать RPCh нашим коллегам по кошельку для окончательной интеграции.
Существуют также определенные отношения внутри команды. У каждого свой набор навыков и им имеет смысл работать над определенными задачами. К счастью для нас, новые колумбийские сотрудники прибыли как нечто вроде полного комплекта: Диего был наиболее опытен в devops и архитектуре, Камило обладал знаниями в области front-end, а Луису было удобнее всего создавать различные образы Docker, на которые будет опираться RPCh.
Но в большинстве случаев порядок приоритетов имел более мягкие требования. Имело смысл создавать определенные вещи первыми, потому что это позволяло нам быстрее достичь минимального набора работоспособных функций. Это хорошо для тестирования и релизов, но также и для понимания.
Я решил, что мы будем создавать поэтапные версии песочницы или RPCh, где будут представлены рудиментарные версии каждого компонента, чтобы команда могла увидеть, как все взаимодействует и как сочетаются отдельные компоненты, над которыми они работают. Затем мы переходили к альфа-версии, бета-версии и так далее, улучшая и добавляя компоненты по мере продвижения.
Работа в сложном режиме
Одним из самых важных моментов было создание плавной динамики уровней сложности для команды.
Они начинали работать в новой компании, занимаясь разработкой новой технологии, а это может быть нелегко. Хотя в разработке программного обеспечения неизбежны неудачи, для меня было очень важно создать среду, в которой мы чувствовали бы, что всегда добиваемся прогресса. Это означало, что нужно было начинать, по возможности, с низко висящих фруктов, отмечать такие вехи, как первые коммиты и PR, и повышать сложность задач по мере продвижения по спринтам.
Я также извлек уроки из своего опыта работы в основной команде HOPR и убедился, что с самого первого дня необходимо создать понятные механизмы, а также проводить регулярные заседания по анализу, чтобы отметить то, что работает, и исправить любые проблемы до того, как они станут проблемами.
Я не хочу загадывать, но до сих пор это, работало. RPCh прошел все этапы разработки и команда с лихвой справилась с постоянно растущим напряжением. Было бы ошибкой сказать, что не было никаких неудач (о некоторых из них мы расскажем в следующий раз), но тщательное планирование и встроенные буферы и резервы минимизировали последствия, и мы вполне укладываемся в сроки, согласованные с нашими партнерами по проекту еще в октябре.
Это всего лишь попытка описать проблемы и аспекты, которые возникают при планировании даже такого относительно скромного проекта по разработке программного обеспечения, как RPCh, но я надеюсь, что вам было интересно увидеть ту сторону крипты, которая редко обсуждается.
В заключительной части мы рассмотрим дальнейшее расширение команды RPCh и некоторые из наиболее важных уроков, полученных за последние несколько месяцев.
Steven Noni
Руководитель разработки RPCh
Website: https://www.hoprnet.org
Twitter: https://twitter.com/hoprnet
Telegram: https://t.me/hoprnet
Discord: https://discord.gg/dEAWC4G
Forum: https://forum.hoprnet.org
Staking: https://stake.hoprnet.org
Bounties: https://bounties.hoprnet.org
Playground: https://playground.hoprnet.org
