За последние несколько месяцев мы создали прототип , провели хакатон , наняли совершенно новую команду , представили RPCh в качестве сервиса, чтобы предоставить кошелькам (и пользователям) их первый частный блокчейн-шлюз, и создали версию песочницы , чтобы показать, что все было осуществимо.

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

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

Чтобы подготовиться к альфе, команда снова расширилась. Опытный фронтенд-разработчик Михал был переведен на общих основаниях из команды по связям с общественностью HOPR, а новый сотрудник Мартинс был нанят, чтобы помочь с растущими требованиями RPCh к devops.

В сорняки

Одним из основных изменений при разработке РПЧ-альфа стало повышенное внимание к деталям и испытаниям. Приятно говорить о конфиденциальности в теории и играть с прототипами, но реальный продукт должен выживать и процветать в реальном мире. Мир предложения, спроса и мизерной маржи.

RPCh должен обрабатывать живые звонки, сделанные реальными пользователями, занимающимися своим бизнесом DeFi. Это создает две проблемы масштаба:

• Может ли RPCh (и сеть HOPR под ним) обрабатывать живой трафик?
• Может ли RPCh обрабатывать большие вызовы RPC?

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

В основном это означает разделение каждого вызова на куски размером с укус.

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

Сейчас большинство вызовов RPC небольшие. Несколько пакетов вершины. И в первоначальном прототипе и на хакатоне мы в основном тестировали ванильные транзакции, которые просты. Но некоторые вызовы RPC огромны! Тестирование показало, что для одной транзакции Cowswap может потребоваться до 50 сегментов RPCh, каждый из которых проходит через смешанную сеть HOPR по своему маршруту.

И если один из них пропадет, весь вызов не удастся.

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

Теперь наши первоначальные партнеры — это небольшие кошельки, ориентированные на конфиденциальность — мы ведем переговоры с Metamask, но до этого еще далеко — но у них все еще много пользователей. Сотни тысяч звонков в день от всех их пользователей.

Таким образом, даже в альфа-версии RPCh должен обрабатывать множество вызовов одновременно, некоторые из них необычно большие.

Но это слишком расплывчато, чтобы быть полезным. Таким образом, нам нужно было по-настоящему разобраться в фактической услуге, которую будет предоставлять РПЧ. Не просто «отправить кучу вызовов RPC через HOPR», а «какие вызовы?», «сколько?», «насколько они велики?», «сколько одновременно?» Не просто догадки, а точные цифры.

Поэтому я поручил Диего и Луису собрать данные. Они часами управляли кошельками наших партнерских проектов, записывая сделанные звонки и их точный размер в байтах.

Это была скучная работа, не буду врать, но важно точно знать, с какой нагрузкой РПЧ-альфа должен справиться.

Это будет работать?

Может показаться странным, что мы зашли так далеко, не работая на таком уровне детализации. Что, если он просто не может работать?

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

"Это будет работать?" означает разные вещи на разных этапах.

Еще в сентябре, когда я кодировал первый прототип РПЧ в Испании, «он будет работать?» просто означало «Это даже отдаленно возможно?»

Во время хакатона «Сработает ли?» означало «Можем ли мы интегрировать это в настоящий кошелек?»

И по мере того, как мы приближаемся к запуску, то, что значит для работы РПЧ, становится все более и более конкретным.

Недостаточно, чтобы отправка транзакций была возможной в частном порядке. Сервис должен быть надежным. Это не может привести к неприемлемой задержке. Он должен быть в состоянии справиться с ожидаемой пропускной способностью кошельков наших партнеров. UX должен быть плавным. Он должен использовать реальную сеть HOPR, а не теоретическую версию песочницы, которую мы раскручиваем локально.

И в дело вступают реалии бизнеса. Не будем себя обманывать — кошельки заботятся о конфиденциальности, но не любой ценой. Он должен быть простым в использовании, легко интегрируемым.

И деньги говорят. В идеале РПЧ должен быть дешевле, чем у конкурентов, или обеспечить экономию средств в другом месте.

Мы считаем, что у нас есть дизайн, который достигает всех этих целей, но нам все еще нужно испытать его.

Тестирование!

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

работа в команде HOPR

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

Но добавление команды РПЧ снова изменило ситуацию. Сейчас у нас три команды с разными целями, сроками и требованиями. Структура укрепилась, и теперь можно неделями не взаимодействовать с некоторыми членами команды, за исключением нашего общего собрания.

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

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

Дорога к РПЧ-альфа почти завершена. Это было сложно, но чрезвычайно полезно. И конечно альфа это только начало. Будет больше функций, больше улучшений и больше кошельков и пользователей для поддержки.

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

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