Путь к RPCh — часть 4

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

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

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

Чтобы получить возможность подготовиться к альфа-версии, команда вновь пополнилась. Опытный front-end разработчик Michal был привлечен на совместной основе из команды HOPR, а новый сотрудник Martins был принят на работу, чтобы помочь с растущими требованиями RPCh к devops.

Сквозь тернии

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

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

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

Это не технический блог, но второй пункт требует пояснений.

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

Это означает, что каждый вызов нужно разделить на отдельные фрагменты.

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

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

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

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

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

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

Но это слишком туманно, чтобы быть нужным. Поэтому нам нужно было разобраться в том, какой именно сервис будет предоставлять RPCh. Не просто “послать кучу вызовов RPC через HOPR”, а “Какие вызовы?”, “Сколько?”, “Насколько они велики?”, “Сколько одновременно?”. Не просто предположения, а точные цифры.

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

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

Будет ли это работать?

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

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

Вопрос “Будет ли это работать?” означает разные вещи на разных этапах.

Еще в сентябре, когда я разрабатывал первый прототип RPCh в Испании, “Будет ли это работать?” означало просто “Возможно ли это вообще?”.

Во время хакатона “Будет ли это работать?” означало “Сможем ли мы интегрировать это в реальный кошелек?”.

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

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

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

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

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

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

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

Командная работа HOPR

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

Однако присоединение команды RPCh еще раз изменило ситуацию. Теперь у нас три команды с разными целями, сроками и требованиями. Структура упрочнилась, и теперь мы можем неделями не общаться с некоторыми членами команды, за исключением совещаний по всем вопросам.

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

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

Путь к выпуску альфа-версии RPCh почти завершен. Он был трудным, но чрезвычайно полезным. И, разумеется, альфа-версия — это только начало. Будет больше функций, больше улучшений, больше кошельков и пользователей для поддержки.

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

Steven Noni
Руководитель разработки RPCh