Мы вернулись из Колумбии с новой командой и новым драйвом. RPCh должен был стать первым продуктом поверх HOPR — четкий вариант использования протокола, который не только обеспечивал неопределенное повышение конфиденциальности, но и решал насущную и своевременную проблему в web3. Пользователи были взволнованы, кошельки были взволнованы, мы были взволнованы.

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

Архитектурный дайджест

Хакатон дал отличное доказательство концепции, но это было далеко не продукт и даже не проект для него. Эта версия RPCh требовала, чтобы пользователь предоставил все — сервер RPC, узел HOPRd — сам.

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

И это был фактически первый из многих вопросов, которые мы больше не могли откладывать. Кто будет платить за РПЧ? Это то, за что пользователи будут платить, возможно, в качестве дополнительной платы сверх газа? Или кошельки будут платить и либо поглощать расходы, либо каким-то образом перекладывать их на пользователей?

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

Было быстро решено, что RPCh будет нацелен на кошельки в качестве обновления существующего решения RPC.

Но это уже имело огромные последствия: если вы предлагаете пакеты услуг, например, 10 миллионов вызовов RPC в месяц, вам нужен способ назначать эту квоту, отслеживать ее и ограничивать услугу, когда она заканчивается. Архитектура такой системы будет полностью отличаться от той, в которой RPCh оплачивается за транзакцию. Не говоря уже о побочных эффектах того, как RPCh будет сообщаться и продаваться.

И это был лишь один из многих аспектов, каждый из которых имел свои последствия и ограничения для дизайна.

Это может показаться невыполнимой задачей, но одна из самых приятных частей разработки программного обеспечения — это разбиение гигантской проблемы на все более четкие и управляемые задачи. Нет ничего лучше, чем начать с диаграммы и мечты и закончить дорожной картой и упорядоченным списком для насыщенного спринта в GitHub.

По крайней мере для меня :)

Дорога к дорожной карте

И, как и все в РПЧ, это была командная работа. Сначала были соображения высокого уровня: как будет выглядеть РПЧ как услуга? Кто будет платить? Кто будет запускать узлы RPCh и получать вознаграждение? Будут ли они отличаться от стандартных узлов HOPR по своей работе и стимулированию? Как?

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

Моя задача как руководителя продукта состояла в том, чтобы превратить этот план в конкретный план развития. Как будут создаваться различные компоненты и в каком порядке мы будем их строить? Как их будут проверять? Как и когда кошелькам будет предоставлен доступ через SDK или иным образом?

И, что особенно важно, кому будет поручено построить каждую часть?

Потому что наряду со всей этой дизайнерской работой существовала параллельная задача, хотя и очень полезная для решения. Мы наняли Камило, Диего и Луиса — трех колумбийцев, которые так хорошо выступили на хакатоне, — в качестве членов новой команды RPCh. Мы были очень впечатлены их работой и энтузиазмом, но они все еще были относительно молодыми, особенно когда дело касалось криптографии. График разработки RPCh означал, что большая часть их адаптации должна проходить на рабочем месте. Кроме того, они находились в совершенно другом часовом поясе, а это означало, что большую часть дня они должны были работать над задачами без присмотра.

Как и любой другой член команды HOPR, новобранцы прошли стандартный процесс адаптации HOPR, от изучения наших различных процессов и инструментов командной работы до замечательных практических занятий Ethereum с нашим основателем Себастьяном (которые проходят все в HOPR, независимо от роли). или техническую экспертизу).

Это отличный способ учиться, но он также имел серьезные последствия для дорожной карты. Как и в любом проекте, в сборке RPCh есть некоторые зависимости — вещи, которые нужно строить в определенном порядке, потому что они зависят друг от друга. Затем есть внешние зависимости: протокол HOPR все еще находится в стадии разработки, поэтому нам нужно работать в рамках дорожной карты. Нам также нужно спланировать, как и когда передать RPCh нашим коллегам по кошельку для окончательной интеграции.

Есть также зависимости внутри команды. У всех разный набор навыков, и им имеет смысл работать над конкретными задачами. К счастью для нас, новые колумбийские рекруты прибыли как нечто вроде полного пакета: Диего был самым опытным в devops и архитектуре, у Камило был опыт работы с интерфейсом, а Луису было наиболее комфортно создавать различные образы Docker, на которые полагался RPCh.

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

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

Игра в сложном режиме

Одним из наиболее важных соображений было создание плавной кривой сложности для команды.

Они начинали работу в новой компании, работающей над новой технологией, что может быть пугающим. Хотя неудачи в разработке программного обеспечения неизбежны, для меня было очень важно создать среду, в которой мы чувствовали бы, что всегда добиваемся прогресса. Это означало, что нужно начинать, где это возможно, с легко висящих плодов, отмечая вехи, такие как первые коммиты и PR, и повышая сложность по мере прохождения спринтов.

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

Не хочу ничего сглазить, но пока вроде получилось. RPCh преодолела все этапы разработки, и команда более чем готова справиться с растущими вызовами. Было бы ложью сказать, что не было никаких неудач (о некоторых из них мы поговорим в следующий раз), но тщательное планирование, встроенные буферы и избыточность свели к минимуму последствия, и мы соблюдаем согласованные сроки. с нашими партнерами по кошельку еще в октябре.

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

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

Стивен Нони
Ведущий специалист по продукции РПЧ

Веб-сайт:https://www.hoprnet.orgТвиттер:https://twitter.com/hoprnetТелеграмма:https://t.me/hoprnetДискорд:https://discord.gg/dEAWC4G

Форум:https://forum.hoprnet.orgСтейкинг:https://stake.hoprnet.orgНаграды:https://bounties.hoprnet.orgДетская площадка:https://playground.hoprnet.org