Near

Привет Хабр,

В этом посте я расскажу о том, как мы строили компанию в кремниевой долине. За четыре года мы прошли путь от стартапа из двух человек в подвале одного из зданий в Сан-Франциско до большой узнаваемой компании с инвестициями в более чем $30M от известных фондов, включая таких гигантов, как a16z.

Под катом много интересных историй про Y Combinator, венчурные инвестиции, поиск команды, и другие аспекты жизни и работы в долине.

Предыстория

Я приехал в долину в 2011 году, где присоединился к компании MemSQL, которая только выпустилась из Y Combinator. В MemSQL я был первым сотрудником. Мы работали из трёхкомнатной квартиры в городе Менло-Парк, в которой и жили (в одной комнате я с супругой, в другой CEO с супругой, а CTO компании Никита Шамгунов спал на диване в зале). Время текло, MemSQL сегодня это большая enterprise компания с сотнями сотрудников, многомиллионными сделками и офисом в центре Сан-Франциско.

В 2016 году я понял, что компания меня переросла, и решил, что пора начинать что-то новое. Еще не решив, что делать дальше, я сидел в кофейне в Сан-Франциско и читал какую-то статью того года по машинному обучению. Ко мне подсел другой молодой человек и сказал я заметил, ты про машинку читаешь, давай знакомиться. Такие ситуации в Сан-Франциско обычное дело. Большинство людей в кофейнях, в ресторанах и на улице сотрудники стартапов или больших технологических компаний, поэтому вероятность так вот с кем-то познакомиться очень высокая. Через ещё две встречи с этим молодым человеком в кофейне мы решили начать строить компанию, которая строит умных помощников. Samsung только что купил VIV, Google анонсировал Google Assistant, и казалось, что будущее где-то в этом направлении.

В качестве ещё одного примера того, как много людей в СФ работают в области ИТ, спустя неделю или две с этим же молодым человеком мы сидели в той же кофейне, и я делал какие-то изменения в наш будущий сайт, а ему было нечем заняться. Он просто повернулся к случайному молодому человеку, сидящему через стол от нас, и сказал а ты машинкой занимаешься?, на что тот молодой человек удивленно ответил да, как ты знаешь?

В октябре 2016 года мы решили начать поднимать венчурные инвестиции. Я предполагал, что попасть на встречу с топовыми инвесторами очень сложно. Оказалось, что это совершенно не так. Если у инвестора есть хотя бы минимальное подозрение, что компания может взлететь, они с радостью потратят час своего времени на общение. Большой шанс потратить час на бесперспективную компанию намного лучше, чем маленький шанс пропустить следующего единорога. Тот факт, что я был первым сотрудником MemSQL позволил нам получить в календаре встречи с шестью очень крутыми инвесторами в долине за неделю работы. Мы были окрылены. Но с той же лёгкостью, с которой мы эти встречи получили, мы эти встречи провалили. Инвесторы встречаются с такими командами как мы по несколько раз в день и умеют за минимальное время понять, что ребята перед ними не имеют ни малейшего представления, что они делают.

Заявка в Y Combinator

Нам нужно было подтянуть наши навыки в строительстве компании. Строить компанию это не код писать. Это понимать, что нужно людям, проводить user studies, прототипировать, правильно решать, когда пивотиться, а когда продолжать, найти product-market-fit. Как раз в это время проходил набор в Y Combinator Winter 2017. Y Combinator это самый престижный акселератор в Кремниевой долине, через который прошли такие гиганты, как Dropbox, Reddit, Airbnb, даже MemSQL. Критерии Y Combinator и венчурных инвесторов очень схожи: им надо из большого числа компаний в Кремниевой долине выбрать небольшое количество и максимизировать шанс поймать следующего единорога. Чтобы попасть в Y Combinator, надо заполнить анкету. Анкета отсекает примерно 97% заявок, поэтому её заполнение это невероятно ответственный процесс. После анкеты проходит интервью, которое отсекает половину из оставшихся компаний.

Мы потратили неделю на заполнение анкеты, перезаполнение, чтение с друзьями, чтение ещё раз, перезаполнение опять. В итоге спустя пару недель мы получили приглашение на интервью. В 3% попали, осталось попасть в 1.5%. Интервью проходит в головном офисе YC в Маунтин-Вью (это 40 минут на машине от СФ) и длится 10 минут. Вопросы задаются примерно одни и те же и хорошо известны. Есть сайты в интернете, где засекается таймер на 10 минут и рандомно выбираются вопросы из известной методички и показываются. Мы по этим сайтам занимались каждый день часами, попросили несколько наших друзей, кто прошли через YC в прошлом, поинтервьюировать нас тоже. В общем подошли серьезнее, чем мы подходили к встречам с инвесторами за месяц до этого.

День интервью был очень интересный. Наше интервью было около 10 утра. Мы приехали заранее. Для меня день интервью представлял определенную проблему. Так как моя компания пока явно не взлетала, я диверсифицировал свои инвестиции времени, начав испытательный срок в компании OpenAI. Один из сооснователей OpenAI, Сэм Альтман, по совместительству являлся президентом Y Combinator. Если я попаду к нему на интервью и он в моей заявке увидит OpenAI, нет ни малейшего сомнения, что он спросит о моих успехах на моем испытательном сроке у моего менеджера. Если я затем не попаду в Y Combinator, то мой испытательный срок в OpenAI тоже окажется под большим вопросом.

К счастью, Сэм Альтман не был в группе, которая проводила интервью у нас.

Если Y Combinator принимает компанию, они звонят в тот же день. Если отвергают, то пишут email на следующий день с развернутым объяснением почему. Соответственно, если до вечера звонка не поступило, значит не повезло. А если позвонили, то, не снимая трубки, можно знать, что нас взяли. Интервью мы прошли с лёгкостью, все вопросы оказались из методички. Вышли воодушевлённые, поехали в СФ. Прошло полчаса, мы были в десяти минутах от города, как нам позвонили.

Попасть в Y Combinator это мечта почти каждого человека, который строит компанию в Кремниевой долине. Тот момент, когда позвонил телефон, входит в топ 3 самых запоминающихся моментов в моей карьере. Забегая вперед, второй из трёх случится в этот же день спустя всего несколько часов.

Девушка на том конце совсем не спешила радовать нас новостями о нашем приёме. Она сообщила нам, что им нужно провести второе интервью. Это редкое событие, но в интернете о нём тоже было написано. Что интересно, по статистике среди компаний, которые вызвали на второе интервью, принимают те же самые 50%, то есть тот факт, что нам надо возвращаться, даёт нем 0 новой информации о том, попадём мы в YC или нет.

Развернулись, приехали назад. Подошли к комнате. Сэм Альтман. Не повезло

Я написал своему менеджеру в OpenAI в слэк, что так и так, я сегодня в Y Combinator прохожу интервью, тебе наверняка напишет Сэм, не удивляйся. Прошло все ОК, моему менеджеру в OpenAI, кажется, не могло быть более фиолетово.

Второе интервью длилось пять минут, задали пару вопросов, отпустили нас. Такого же ощущения, что мы разнесли их, не было. Казалось, что на интервью просто ничего не произошло. Поехали в СФ, менее воодушевлённые в этот раз. Через 30 минут опять позвонили. В этот раз уже чтобы сообщить, что мы приняты.

Y Combinator

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

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

Помимо этого был поднят портал, на котором мы могли в любой момент создавать встречи с разными умными ребятами, у которых опыт в самых разных областях строительства компаний: продажи, маркетинг, user studies, дизайн, UX. Мы этим пользовались достаточно много и набрались кучи опыта. Почти всегда эти ребята находились в СФ, поэтому даже не надо было далеко ехать. Часто даже не нужна была машина.

Поиск ещё одного сооснователя

Вдвоем компанию не поднять. Но у нас есть $150K, которые YC дает в начале программы. Надо найти людей. Учитывая, что мы едва сами знаем, что мы пишем, искать сотрудников пока что дело гиблое, но, может, мы найдем ещё человека, который хочет быть с нами сооснователем? В ВУЗе я занимался ACM ICPC, и многие из людей, кто в моём поколении им занимались, сейчас имели успешные карьеры в долине. Я начал писать своим старым друзьям, которые теперь жили в СФ. И долина не была бы долиной, если бы за первые пять сообщений я бы не нашёл кого-то, кто хочет строить компанию. Супруга одного из моих друзей с поездок на ICPC строила очень успешную карьеру в Facebook, но рассматривала вариант уйти и начать компанию. Мы с ней встретились. Она уже тоже была в активном поиске сооснователей и познакомила меня с её другом Ильёй Полосухиным. Илья был одним из инженеров в команде, которая строила TensorFlow. Спустя несколько встреч девушка решила остаться в Facebook, а Илья пришёл к нам в компанию третьим основателем.

Начало NEAR

После YC поднимать венчурные инвестиции немного проще. В последние дни программы Y Combinator организует Demo Day, где мы презентуем перед 100 инвесторами. YC построили систему, в которой инвесторы выражают интерес к нам прямо во время презентации, а мы к ним в конце дня, а потом там строится взвешенное паросочетание и мы с ними встречаемся. Мы подняли $400K, я и Илья в этом процессе не были очень вовлечены, мы писали код, поэтому много интересных историй рассказать не могу. Но одна есть.

В качестве маркетинга мы проводили в Сан-Франциско встречи по машинному обучению с топовыми исследователями (многие из которых работают в Google Brain, OpenAI, учатся в Стэнфорде или Беркли, и поэтому находятся географически тут же в долине) и строили локальное сообщество. На одной из таких встреч мы убедили одного из абсолютно топовых исследователей в области быть нашим advisor. Мы уже почти подписали документы, когда через неделю он понял, что его текущая компания не позволяет ему быть advisorом. Но он чувствовал, что он нас подводит, и поэтому предложил вместо того, чтобы эдвайзить, в нас просто инвестировать. Сумма в масштабе компании была небольшой, но получить топового исследователя в области не просто как эдвайзера, но как инвестора, это было очень круто.

Это уже был июнь 2017, Google Pixel вышел и был популярен. В отличие, к сожалению, от встроенного в него Google Assistant. Я брал у друзей Пиксели, зажимал home button и в 10 случаях из 10 видел настройте Google Assistant перед первым использованием. Samsung никак купленный VIV не использовал, а выпустил вместо этого Bixby с хардварной кнопкой, и в Samsung Store стали популярны приложения, которые заменяли Bixby на фонарик.

На фоне всего этого наша с Ильёй вера в будущее ассистентов погасла, и мы покинули ту компанию. Мы сразу основали новую компанию Near Inc, потеряв в процессе бейджик Y Combinator на компании, $400K и топового исследователя как инвестора.

В тот момент нам обоим была очень интересна тема program synthesis когда модельки сами пишут (или дописывают) код. Мы решили закопаться в тему. Но совсем без денег тоже нельзя, поэтому сначала нужно восполнить потерянные $400K.

Венчурные инвестиции

К тому моменту между графами знакомств меня и Ильи почти все инвесторы в долине были в одном или двух рукопожатиях, поэтому, как и в первый раз, получить встречи было очень легко. Первые встречи шли очень неудачно, и мы получили несколько отказов. Как я узнаю за этот и следующие 2 фандрейза, в которых я буду участвовать, до первого ДА от инвесторов надо получить десятки НЕТ. После первого ДА следующее ДА приходит в следующие 3-5 встреч. Как только есть два-три ДА, НЕТ уже больше почти не бывает, и становится проблемой выбрать из всех ДА, кого же взять.

Наше первое ДА пришло от инвестора Х. Я ничего хорошего про Х не скажу, поэтому и имя упоминать не буду. Х сбивал оценку компании на каждой встрече и пытался добавить дополнительные условия, которые были невыгодны команде и основателям. Конкретный человек, с которым мы работали в X, был в начале своей карьеры как инвестора в большом фонде, и для него закрыть очень выгодную сделку это лестница в карьеру. И так как кроме него нам ДА никто не говорил, он мог требовать всё, что угодно.

Х познакомил нас с рядом других инвесторов. Инвесторы не любят инвестировать в одиночку, они любят инвестировать с другими. Наличие других инвесторов повышает вероятность, что они не допускают ошибку (ведь кто-то ещё думает, что это хорошая инвестиция), и повышает шансы компании выжить. Проблема в том, что если Х познакомил нас с Y, Y после этого не инвестирует без Х, потому что это будет плевок Х в лицо, а им ещё часто иметь дело друг с другом. Второе ДА после этих знакомств поступило сравнительно скоро, а затем и третье, и четвёртое. Проблема была в том, что Х хотел выжать из нас все соки и дать деньги под самые невыгодные условия, а другие инвесторы, которые узнали о нас от Х, может и были бы готовы инвестировать в нас на лучших условиях, но не будут делать это за спиной Х.

В одно солнечное утро в Сан-Франциско я получил письмо от Никиты Шамгунова, уже тогда CEO MemSQL, Introducing Alex (NEAR) to Amplify Partners. Спустя буквально 17 минут совершенно независимо и по чистому совпадению приходит письмо от X с точно таким же заголовком. Ребята из Amplify оказались невероятно крутыми. Условия, которые нам предлагали Х, казались им драконовскими, и они были готовы инвестировать в нас на разумных условиях. Ряд инвесторов был готов инвестировать вместе с Amplify. В таких условиях мы отказались от инвестиции Х и подняли раунд с Amplify в качестве главного инвестора. Amplify тоже не был рад инвестировать в обход X, но так как первое интро пришло от Никиты, а не от Х, общий язык между всеми нашёлся, и никто ни на кого в обиде не остался. Если бы Никита в тот день прислал письмо на 18 минут позже, всё могло бы быть немного сложнее.

У нас теперь было $800K, чтобы существовать, и начался год, полный хардкорных моделек на PyTorch, общения с десятками компаний в долине, чтобы понять, где на практике можно было бы применять program synthesis, и других не очень интересных приключений. К июлю 2018 у нас был какой-то прогресс по моделькам и несколько статей на NIPS и ICLR, но не было понимания, где модели достижимого на то время уровня могли быть применены на практике.

Первое знакомство с блокчейн

Мир блокчейна это очень странный мир. Я его достаточно целенаправленно избегал долгое время, но в итоге наши пути пересеклись. В поисках применения program synthesis мы в итоге пришли к тому, что что-то на пересечении program synthesis и смежной темы formal verification может быть очень полезно для смарт-контрактов. Мы ничего не знали про блокчейн, но долина не была бы долиной, если бы среди моих старых друзей там не нашлось хотя бы нескольких, кто этой темой интересовался. Мы начали с ними общаться и поняли, что formal verification это хорошо, но в блокчейне есть проблемы более насущные. В 2018 году Ethereum уже справлялся с нагрузкой достаточно тяжело, и разработать протокол, который работал бы значительно быстрее, было очень насущной проблемой.

Мы, конечно, далеко не первые, кому такая идея пришла в голову, но быстрое изучение рынка показало, что в то время как конкуренция там есть, и высокая, выиграть его можно. Что важнее, и я, и Илья очень хорошие системные программисты. Моя карьера в MemSQL была, разумеется, гораздо ближе к разработке протоколов, чем строительству моделек на PyTorch, а Илья в Google был одним из разработчиков TensorFlow.

Я начал обсуждать эту идею со своими бывшими коллегами по MemSQL и моим сокомандником со времен ICPC, и идея строить быстрый блокчейн протокол оказалась интересна четырём из пяти людей, с кем я пообщался. За один день в августе 2018 года NEAR вырос с трёх человек до семи и до девяти в течение следующей недели, когда мы наняли head of operations и head of business development. При этом уровень людей был просто невероятным. Все инженеры были либо из ранней команды MemSQL, либо проработали по многу лет в Google и Facebook. Трое из нас имели золотые медали ICPC. Один из семи первых инженеров выиграл ICPC дважды. На тот момент дважды чемпионов в мире было шесть (сегодня количество дважды чемпионов в мире уже девять, но теперь два из них работают в NEAR, так что статистика со временем улучшилась).

Это был взрывной рост, но была проблема. Никто не работал бесплатно, и офис в центре СФ тоже далеко не дешёвый, и покрывать аренду офиса и зарплаты уровня долины девяти людям, имея то, что осталось от $800K спустя год было проблематично. NEAR осталось существовать 1.5 месяца, прежде чем в банке останется ноль.

Снова венчурные инвестиции

Имея в комнате с доской семь очень сильных системных программистов с средним опытом около 8 лет, мы смогли в короткие сроки придумать какой-то разумный дизайн для протокола и пошли опять общаться с инвесторами. К сожалению, многие инвесторы избегают блокчейна. В то время (да и сейчас) в этой индустрии было невероятное количество оппортунистов, и отличить серьезно настроенных ребят от оппортунистов было сложно. Раз обычные инвесторы избегают блокчейн, нам нужно идти к инвесторам, которые инвестируют целенаправленно в блокчейн. Таких в долине тоже много, но это совсем другое множество, с незначительным пересечением с инвесторами, не специализирующимися на блокчейне. Вполне ожидаемо, у нас оказались в нашем графе знакомств люди и в таких фондах в одном рукопожатии. Одним из таких фондов был Metastable.

Metastable топовый фонд, и получить ДА от них значило бы закрыть раунд почти сразу. Мы уже к тому времени набрали 3-4 НЕТ, и количество фондов, с кем можно пообщаться, быстро сокращалось, как и время до того, как NEAR останется без средств к существованию. В Metastable работало несколько невероятно умных ребят, задача которых была разнести наши идеи в щепку и найти минимальные неточности в нашем дизайне. Так как нашему дизайну в то время было несколько дней, как и нашему опыту в блокчейне на тот момент, на митинге с Metastable они нас с Ильей уничтожили. Количество НЕТ в копилке увеличилось еще на один.

В следующие пару недель работа перед доской продолжалась, и дизайн начал собираться во что-то серьёзное. Мы, несомненно, поторопились с нашей встречей с Metastable. Если бы встреча прошла сейчас, уничтожить нас так легко бы не получилось. Но Metastable не встретится с нами спустя всего две недели. Что же делать?

Решение нашлось. По случаю дня рождения Илья устроил шашлыки на крыше своего дома (которая, как и многие крыши в квартирных комплексах в СФ, представляла из себя ухоженный парк), куда были приглашены все сотрудники NEAR и друзья, включая Ивана Богатого друга Ильи, который работал в Metastable в тот момент, а также некоторые другие инвесторы. В отличие от презентации инвесторам в комнате для совещаний, на шашлыках вся команда из NEAR могла пообщаться в простой обстановке с пивом в руках с Иваном и другими инвесторами о нашем текущем дизайне и целях. К концу шашлыков Иван подошел к нам и сказал, что, кажется, нам есть смысл встретиться ещё раз.

Эта встреча прошла намного лучше, и мы с Ильёй смогли защитить дизайн от коварных вопросов. Metastable позвали нас встретиться с её основателем Навалом Равикантом спустя пару дней в офисе компании Angellist. В офисе было абсолютно пусто, потому что компания почти всем составом уехала на Burning Man. На этой встрече НЕТ превратилось в ДА, и NEAR больше не была в шаге от смерти. Митинг закончился, мы сели в лифт. Новости о том, что Metastable в нас инвестирует, разлетелись очень быстро. Лифт еще не доехал до первого этажа, когда на нашу почту без какого-либо участия с нашей стороны прилетело второе ДА, тоже от топового фонда. Больше НЕТ в том фандрейзе не было, и через неделю мы опять решали задачу о рюкзаке, чтобы вместить самые лучшие предложения в ограниченный раунд.

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

Скорость не самая большая проблема

В конце 2018 года мы пошли на хакатон ETH San Francisco. Это один из множества хакатонов по всему миру, посвященных Ethereum. На хакатоне у нас была большая команда, которая хотела построить первую версию моста между NEAR и Эфиром.

Я от команды отделился и решил пойти другим путём. Я нашёл глазами Влада Замфира, известного инфлюенсера в экосистеме, который писал свою версию шардинга для Ethereum, подошел к нему и сказал "Привет, Влад, я писал шардинг в MemSQL, давай участвовать в одной команде". Влад был с девушкой, и на его лице ясно читалось, что я выбрал не самое лучше время для общения. Но девушка сказала "это звучит круто, Влад, тебе нужно взять его в команду". Так я оказался в команде с Владом Замфиром, и следующие 24 часа узнавал о том, как работает его дизайн, и писал вместе с ним прототип.

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

По итогам этого хакатона и огромного количества user-studies, которые за ним последовали, мы поняли, что самая большая проблема блокчейнов это не их скорость. Самая большая проблема это то, что приложения на блокчейн ужасно сложно писать и ещё сложнее использовать конечным пользователям. Наш фокус в 2019 году расширился, мы привели людей, разбирающихся в user experience, собрали команду, чей фокус исключительно developer experience, и сделали основным фокусом удобность для разработчиков и пользователей.

Строим узнаваемость

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

Мы только начинали, а у наших конкурентов уже были большие фан-базы. А есть ли способ как-то достучаться до этих фан-баз, чтобы все оказались в плюсе? Мы сидели небольшой компанией в кофейне Red Door в Сан-Франциско утром когда в голову пришла феноменальная идея. В мире, где десятки протоколов конкурируют за то, чтобы быть the next big thing, реально у людей нет никакого источника информации об этих протоколах, кроме их собственных маркетинговых материалов. Было бы здорово, если бы кто-то достаточно умный встал с исследователями и разработчиками таких протоколов перед доской и разносил их. Такие видео хороши для всех. Для них (если их не разнесут), потому что их сообщество может видеть, что их дизайн не трава. Для нас возможность быть замеченными их сообществом, а ещё возможность узнать хорошие идеи. Почти все протоколы, включая NEAR, разрабатываются открыто, поэтому идеи и код в целом не скрываются, но найти эти идеи иногда сложно. За один час перед доской с умным человеком можно научиться очень многому.

Долина в очередной раз оказалась полезной. NEAR далеко не единственный протокол, у которого есть офис в СФ, и идея записать такие видео была встречена разработчиками других протоколов с огромным энтузиазмом. Мы быстро положили в календарь первые встречи для записи видео с ребятами, которые тоже географически были в СФ, и на сегодня таких видео уже почти сорок.

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

Дальнейшая история

Команда росла, и в жизни стартапа самое важное это иметь достаточно финансов, чтобы поддерживать рост. Третий фандрейзинг тоже начался удачно не сразу, мы получили несколько НЕТ, но одно ДА опять перевернуло всё с ног на голову, и мы быстро его закрыли. Четвёртый фандрейзинг в начале этого года начался с ДА почти сразу, мы получили финансирование от Andreessen Horowitz, самого топового фонда как в принципе, так и в области блокчейнов, и имея a16z как инвестора раунд закрылся очень быстро. В последнем раунде мы подняли $21.6M.

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

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

Разработка на этом не заканчивается. Протокол имеет встроенный механизм перехода на новые версии, и впереди ещё много работы.

В заключение

Это первый пост в корпоративном блоге NEAR. В ближайшие месяцы я буду рассказывать, как работает NEAR, почему мир лучше с хорошим удобным блокчейн протоколом, чем без него, и какие интересные алгоритмы и задачи мы решали в ходе разработки: шардирование, генерация случайных чисел, алгоритмы консенсуса, мосты с другими цепями, т.н. Layer 2 протоколы и многое другое. Мы приготовили хорошую комбинацию научно-популярных и глубоких технических постов.

Небольшой список ресурсов для тех, кто хочет закопаться глубже уже сейчас:

1. Посмотреть как выглядит разработка под NEAR, и поэкспериментировать в онлайн-IDE можно здесь: https://examples.near.org.

2. Код протокола открыт, его можно поковырять лопаткой тут: https://github.com/nearprotocol/nearcore

3. Если вы хотите запустить свою ноду в сети и помочь её децентрализации, можно присоединиться к программе Stake Wars. Есть русскоговорящее телеграм сообщество, где люди прошли через программу и запустили ноды и могут помочь в процессе.

4. Обширная документация для разработчиков на английском доступна здесь: https://docs.near.org.

5. Следить за всеми новостями на русском можно в уже упомянутой группе в телеграме, и в группе на ВКонтакте

Наконец, позавчера мы запустили онлайн хакатон с призовым фондом в $50K, на котором предлагается написать интересные приложения, которые используют мост между NEAR и Ethereum. Больше информации (на английском) здесь: https://near.org/rainbow/

До скорых встреч!

Привет, Хабр!

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

Зачем вообще нужно генерировать случайные числа участникам, не доверяющим друг другу? Одна из областей применения -- это децентрализованные приложения. Например, приложение, которое принимает ставку от участника и либо удваивает сумму с вероятностью 49%, либо забирает с 51%, будет работать только если оно может непредвзято получить случайное число. Если злоумышленник может повлиять на результат работы генератора случайных чисел, и даже незначительно увеличить свой шанс получить выплату в приложении, он легко опустошит его.

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

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

2. Он должен быть непредсказуемым. Другими словами, ни один участник не должен иметь возможность предугадать, какое число будет сгенерировано (или вывести какие-либо его свойства) до того, как оно будет сгенерировано.

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

В этой статье мы рассмотрим два подхода: RANDAO + VDF и подход, основанный на стирающих кодах. В следующей части мы подробно разберем подход, основанный на пороговых подписях.

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

RANDAO

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

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

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

Какие из свойств, которые мы описали выше, есть у RANDAO? Он непредсказуем, имеет ту же жизнеспособность, что и лежащий в его основе протокол консенсуса, но он является предвзятым. В частности, злоумышленник может наблюдать за сетью, и после того, как другие участники раскроют свои числа, он может вычислить их XOR, и решить, раскрывать или не раскрывать своё число, чтобы повлиять на результат. В то время как это не позволяет злоумышленнику единолично определить вывод генератора случайных чисел, это все еще дает ему 1 бит влияния. А если злоумышленники управляют несколькими участниками, то число контролируемых ими битов будет равно числу участников под их управлением.

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

RANDAO + VDF

Один из вариантов, как сделать RANDAO непредвзятым, состоит в следующем: после того, как все числа вскрыты, и XOR посчитан, его результат подается на вход функции, которая занимает очень много времени, чтобы ее вычислить, но позволяет проверить правильность вычисления очень быстро.

(vdf_output, vdf_proof) = VDF_compute(input) // это очень медленноcorrect = VDF_verify(input, vdf_output, vdf_proof) // это очень быстро

Такая функция называется Verifiable Delay Function, или VDF. Если вычисление окончательного результата занимает больше времени, чем этап раскрытия чисел, то злоумышленник не сможет предсказать эффект от демонстрации или утаивания своего числа, а следовательно он потеряет возможность влиять на результат.

Разработка хороших VDF чрезвычайно сложна. В последнее время было сделано несколько прорывов, например этот и этот, которые сделали VDF более применимыми на практике, и Ethereum 2.0 в долгосрочной перспективе планирует использовать RANDAO с VDF в качестве источника случайных чисел. Помимо того факта, что этот подход непредсказуем и непредвзят, у него есть дополнительное преимущество, которое заключается в жизнеспособности, если хотя бы два участника доступны в сети (при условии, что используемый протокол консенсуса жизнеспособен при работе с таким небольшим количеством участников).

Самая большая сложность этого подхода заключается в такой настройке VDF, чтобы даже участник с очень дорогим специализированным оборудованием не смог вычислить VDF до окончания фазы раскрытия. В идеале алгоритм должен иметь даже значимый запас прочности, скажем, 10x. На рисунке ниже показана атака участника, имеющего специализированный ASIC, который позволяет ему запускать VDF быстрее, чем время, выделенное для раскрытия подтверждения RANDAO. Такой участник может по-прежнему вычислять конечный результат используя и не используя своё число, и после этого, на основе расчетов, выбирать, показывать его или нет.

Для упомянутого выше семейства VDF производительность специализированного ASIC может быть в 100+ раз выше, чем у обычного оборудования. Таким образом, если фаза раскрытия длится 10 секунд, то VDF, вычисляемая на такой ASIC, должна занимать более 100 секунд, чтобы иметь 10-кратный запас безопасности, и, таким образом, тот же VDF, вычисленный на обычном оборудовании, должен занять 100 x 100 секунд = ~ 3 часа.

Ethereum Foundation планирует решить эту проблему за счет создания собственных общедоступных бесплатных ASIC. Как только это произойдет, все другие протоколы также могут использовать преимущества этой технологии, но до тех пор подход RANDAO + VDF не будет столь же жизнеспособным для протоколов, которые не могут инвестировать в разработку своих собственных ASIC.

Много статей, видео и другой информации о VDF собрано на этом сайте.

Используем стирающие коды

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

Основная идея протокола заключается в следующем. Для простоты предположим, что в нем ровно 100 участников. Допустим также что у всех участников локально есть некоторый приватный ключ, и публичные ключи всех участников известны всем участникам:

1. Каждый участник локально придумывает длинную строку, разбивает ее на 67 частей, создает стирающие коды для получения 100 долей, таких, что любых 67 достаточно для восстановления строки, назначает каждую из 100 долей одному из участников и шифрует их с помощью открытого ключа того же участника. Затем все закодированные доли публикуются.

2. Участники используют некоторый консенсус, чтобы достичь согласия о закодированных наборах от конкретных 67 участников.

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

4. Как только 67 участников выполнили шаг (3), все согласованные наборы могут быть полностью декодированы и восстановлены благодаря свойствам стирающих кодов, и окончательное число может быть получено как XOR начальных строк, с которых участники начали в (1).

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

Что происходит, если на шаге (1) один из участников отправил другим участникам закодированные доли, которые не являются корректным стирающим кодом некоторой строки? Без дополнительных изменений разные участники либо не смогут восстановить строку совсем, либо восстановят разные строки, что приведет к тому, что разные участники получат разное случайное число. Чтобы это предотвратить, можно сделать следующее: каждый участник, помимо закодированных долей, вычисляет также дерево меркла всех таких долей, и каждому участнику посылает как саму закодированную долю, так и корень дерева меркла, и доказательство включения доли в дерево меркла. В консенсусе на шаге (2) затем участники не просто соглашаются на множестве наборов, но на множестве конкретных корней таких деревьев (если некоторый участник отошел от протокола, и отправил разные корни дерева меркла разным участникам, и два таких корня показаны во время консенсуса, его строка не включается в результирующий набор). По итогу консенсуса мы будем иметь 67 закодированных строк и соответствующих им корней дерева меркла таких, что есть хотя бы 67 участников (не обязательно тех же кто предложили соответствующие строки), у которых для каждой из 67 строк есть сообщение с долей стирающего кода, и доказательство вхождения их доли в соответствующее дерево меркла.

Когда на шаге (4) участник расшифровывает 67 долей для некоторой строки, и пытается по ним восстановить оригинальную строку, возможен один из вариантов:

1. Строка восстанавливается, и если ее затем закодировать стирающими кодами опять, и посчитать дерево меркла для посчитанных локально долей, корень совпадает с тем, на котором достигнут консенсус.

2. Строка восстанавливается, но посчитанный локально корень не соответствует тому, на котором достигнут консенсус.

3. Строка не восстанавливается.

Легко показать, что если хотя бы для одного участника выше случился вариант (1), то для всех участников случится вариант (1), и наоборот, если хотя бы для одного участника случился вариант (2) или (3), то для всех участников случится вариант (2) или (3). Таким образом, для каждой строки в наборе либо все участники успешно ее восстановят, либо все участники не смогут ее восстановить. Затем результирующее случайное число это XOR только тех строк, которые участники смогли восстановить.

Пороговые подписи

Другой подход к случайности заключается в использовании так называемых пороговых подписей BLS. Генератор случайных чисел, основанный на пороговых подписях, имеет точно такие же гарантии, как и описанный выше алгоритм на основе стирающих кодов, но имеет значительно меньшую асимптотику количества сообщений, пересылаемых по сети на каждое сгенерированное число.

Подписи BLS это конструкция, которая позволяет нескольким участникам создавать одну общую подпись для сообщения. Такие подписи часто используются для экономии места и пропускной способности за счет того, что не требует рассылки нескольких подписей.

Частое применение для BLS-подписей в протоколах блокчейна, помимо генерации случайных чисел, это подписывание блоков в протоколах BFT. Скажем, 100 участников создают блоки, и блок считается окончательным, если 67 из них подписывают его. Все они могут представить свои части BLS-подписи и использовать некоторый консенсус-алгоритм, чтобы согласовать 67 из них, а затем объединить их в одну BLS-подпись. Любые 67 (или больше) частей могут быть использованы для создания итоговой подписи, которая будет зависеть от того, какие именно 67 подписей были объединены, и поэтому может различаться, но не смотря на то, что разный выбор 67-ми участников будет создавать разную подпись, любая такая подпись будет корректной подписью для блока. Остальным участникам затем достаточно получить по сети и проверить только одну подпись на каждый блок, вместо 67, что заметно понижает нагрузку на сеть.

Оказывается, что если закрытые ключи, которые используют участники, генерируются определенным образом, то независимо от того, какие 67 подписей (или больше, но никак не меньше) агрегированы, получающаяся в результате подпись будет одинаковой. Это может быть использовано в качестве источника случайности: участники сначала договариваются о некотором сообщении, которое они подпишут (это может быть вывод RANDAO или просто хэш последнего блока, на самом деле это не имеет значения, лишь бы оно каждый раз менялось и было согласованным), и создают для него BLS-подпись. Результат генерации будет непредсказуемым, пока 67 участников не предоставят свои части, а после этого выходные данные уже предопределены и не могут зависеть от действий любого участника.

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

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

В заключение

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

Код протокола открыт, наша реализация написана на Rust, её можно найти тут.

Посмотреть как выглядит разработка под NEAR, и поэкспериментировать в онлайн-IDE можно здесь.

Следить за всеми новостями на русском можно в группе в телеграме и в группе на ВКонтакте, а на английском в официальном твиттере.

До скорых встреч!