Привет Хабр,

В этом посте я расскажу о том, как мы строили компанию в кремниевой долине. За четыре года мы прошли путь от стартапа из двух человек в подвале одного из зданий в Сан-Франциско до большой узнаваемой компании с инвестициями в более чем $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/

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

Продвижение свободы слова за счет изменения экономической и цифровой инфраструктуры интернета

Будущее свободы слова

Серия статей, для переосмысления Первой поправки в эпоху цифровых технологий

Последние десять лет общество согласилось с пользой Интернета и социальных сетей, в попытке расширить возможности высказывания и улучшения рынка идей, но в последнее время эта точка зрения резко изменилась и теперь, кажется, что довольны далеко не все. Одни считают, что платформы наполнились троллингом, фанатизмом и ненавистью.¹ Другие считают, что они стали слишком навязчивы в плане политики, и систематически замалчивают или подвергают цензуре определенные точки зрения. ² Не говоря уже о конфиденциальности и о том, что они делают (или не делают) со всеми данными, которые они собирают.

Ситуация создала нечто вроде кризиса, как внутри, так и за пределами этих компаний. Платформы постоянно пытаются выполнять новые обязанности в качестве арбитров правды и доброты в интернете, несмотря на то, что исторически позиционируют себя защитниками свободы слова. Между тем, в США, политики из двух основных партий критикуют их, пусть даже и по совершенно разным причинам. Одни жалуются на то, что платформы потенциально допускают иностранное вмешательство в их выборы.³ Другие жалуются на то, что их использовали для распространения дезинформации и пропаганды.⁴ Третьи обвиняют платформы в том, что они просто слишком влиятельны.⁵ Следующие обращают внимание на неуместные аккаунты и удаление контента,⁶ в то время как другие рассуждают о попытках смягчения дискриминации по отношению к определенным политическим точкам зрения.⁷

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

Одни выступают за более строгое регулирование контента в интернете, в то время как такие компании, как Facebook, YouTube и Twitter, подумывают о найме тысяч сотрудников для своих команд модераторов.⁸ Одновременно продолжая инвестировать в искусственный интеллект для выявления спорного контента на ранней стадии процесса.⁹ Другие утверждают, что нужно изменить раздел 230 CDA, который дает платформам свободу действий в модерировании (или не модерировании) контента.¹⁰ Третьи предлагают вообще не допускать модерирования по крайней мере, для платформ определенного размера,чтобы они считались частью всеобщего доступа.¹¹

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

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

Этот подход: строить протоколы, а не платформы.

Это подход, который вернет нас к интернету, каким он был раньше. Он включал в себя множество различных протоколовинструкций и стандартов, которые каждый мог использовать для создания совместимых интерфейсов. Электронная почта использует SMTP (Simple Mail Transfer Protocol). Чат был сделан через IRC (Internet Relay Chat). Пользовательская сеть осуществляла функции распределенной дискуссионной системы, использующей NNTP (Network News Transfer Protocol). Сама Всемирная паутина имела свой собственный протокол: протокол передачи гипертекста, или HTTP.

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

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

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

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

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

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

Однако это принесло свои трудности. С установлением контроля, появилась и ответственность, которая повлекла более строгий контроль контента, размещенного на этих платформах. Фильтрование и предвзятость начали перерастать в обеспокоенность пользователей.¹³ И вдобавок, это закончилось доминированием нескольких интернет-компаний, что (вполне обоснованно) вызывает дискомфорт у многих.¹⁴

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

Ранние проблемы протоколов и качественные платформы

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

Чисто теоретически, и Usenet, и Reddit очень похожи. В обоих случаях речь идет о форумах, организованных по определенной теме. В Usenet они назывались группами новостей. На Reddit - сабреддитами.¹⁵ Каждая новостная группа или сабреддит, как правило, имеют модераторов, уполномоченных устанавливать различные правила. Пользователи могут размещать новые сообщения в рамках каждой группы, что ведет к threads с другими участниками группы и развитию дискуссии.

Тем не менее, Usenet был открытым протоколом (технически, протоколом передачи сетевых новостей или NNTP), к которому мог подключиться любой желающий, используя различные приложения. Reddit - централизованная платформа, полностью контролируемая одной компанией.

Для получения доступа к Usenet, первоначально нужно было специальное клиентское приложение для чтения новостей (их было несколько), а затем нужно было получить доступ к серверу Usenet. Многие интернет-провайдеры сначала предлагали свои собственные услуги (когда я впервые попал в интернет в 1993 году, я использовал Usenet через сервер новостей в моем университете, а также Usenet reader, предоставленный университетом). С популяризацией интернета, все больше организаций пытались создать веб-интерфейс для Usenet. Изначально доминировала служба Deja News Research Service, предоставившая один из первых веб-интерфейсов для Usenet; позже они добавили ряд дополнительных функций, включая (наиболее полезную) всеобъемлющую поисковую систему.

Пока DejaNews экспериментировали с различными бизнес-моделями, их поисковик закрылся. Google купил их в 2001¹⁶ году, вместе с архивами Usenet, которые стали ключевой частью Google Groups.

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

А период после сентября 1993 года запомнился поклонниками старой школы Usenet как Сентябрь, который никогда не закончился или Вечный сентябрь. Это был момент когда проприетарная платформа America Online (AOL) запустила Usenet у себя, и пришло огромное количество пользователей которых было не так легко приручить.¹⁷

Контент размещался не централизованно, а между различными серверами, поскольку серверов Usenet было очень много. У этого есть свои преимущества и недостатки, в том числе то, что разные серверы могут обрабатывать разный контент по-разному. Не каждый сервер Usenet должен хостить каждую группу, что означает, что нет централизованной власти, которая бы могла заниматься модерированием деструктивного поведения или троллинга. Однако некоторые серверы могут блокировать определенные группы новостей, и пользователи могут использовать такие инструменты, как kill files, для фильтрации нежелательного контента на основе критериев, выбранных ими самими.¹⁸

Другим серьезным недостатком первоначального Usenet было то, что он был не очень гибким и адаптивным, особенно когда доходило до широкомасштабных обновлений. В децентрализованном наборе протоколов для достижения консенсуса требуется согласие многих сторон, перед тем как какое либо изменение будет внесено в протокол. Даже маленькие изменения были очень трудоемкими и не всегда признавались на глобальном уровне . Создание новой группы новостей было довольно сложным процессом. Для некоторых иерархий существовал сложный процесс согласования, но другие alt категории настраивались намного проще (хотя это не гарантировало что все серверы Usenet несли эту плату).¹⁹ Для сравнения, легко создать новый сабреддит. У Reddit есть команда разработчиков и инженеров, которые могут вносить любые изменения, в то время как у пользователей особо не спрашивают.

Возможно, самой большой проблемой старой системы было отсутствие очевидной бизнес-модели. Как показало падение Deja News, запуск сервера Usenet никогда не был особенно выгодным. Со временем наблюдался рост профессиональных серверов Usenet, которые требовали оплаты за доступ, но они появились гораздо позже, и были не настолько велики как, например, Reddit, и обычно фокусировались на торговле пиратским контентом.²⁰

Нынешние проблемы больших платформ

В последние два десятилетия рост интернет платформFacebook, Twitter, YouTube, Reddit и других - можно сказать сместил ранее использовавшиеся протокольные системы. Платформы представляют собой единую (обычно коммерческую) компанию, которая предоставляет услуги конечным пользователям. Эти услуги обычно финансируются сначала венчурным капиталом, а затем за счёт рекламы (часто целевой).

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

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

Вторая проблема, с которой сегодня сталкиваются крупнейшие платформы, заключается в том, что их операторы все больше обеспокоены содержанием разрешенного контента, а также ответственностью, которую они несут за контроль или блокировку данного контента.²² Они столкнулись с растущим давлением со стороны пользователей и политиков, требующих от них более активной работы.²³ Были приняты законы, которые более четко требуют от платформ удалять определенный контент, постепенно снижают прежнюю неприкосновенность (например, Акт о соблюдении приличий в СМИ, раздел 230, в США, или Директива об электронной торговле в ЕС), которой многие платформы наслаждались ранее при выборе уровня модерирования.

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

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

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

Эта установка расстраивает всех участников, и вряд ли в ближайшее время изменится к лучшему.

Вместо заключения

Мнения, выраженные в этой статье, являются мнениями Mike Masnick, цитируемого выше, и не обязательно соответствуют мнениям NEAR.

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

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

Если у вас есть идеи сервисов, управляемых сообществом, и вы хотите над ними работать, приходите в нашупрограмму поддержки предпринимателей.

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

Протоколы спешат на помощь

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

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

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

Пример этого уже можно увидеть в пространстве электронной почты. Существует множество различных реализаций электронной почты, основанной на открытых стандартах, таких как SMTP, POP3 и IMAP²⁴. Популярные системы имейла в 1980-х и 1990-х годах опирались на настройки клиент-сервера, в которых провайдер услуг (будь то коммерческий провайдер интернет-услуг, университет или работодатель) размещал электронную почту только на короткий промежуток времени на сервере, пока она не была загружена на собственный компьютер пользователя через клиентское программное обеспечение, такое как Microsoft Outlook, Eudora или Thunderbird. Или пользователи могли получить доступ к электронной почте через текстовый интерфейс, например, Pine или Elm²⁵.

В конце 1990-х годов наблюдался рост интернет-почты, начался с Rocketmail (приобретенный Yahoo, ставший Yahoo Mail) и Hotmail (приобретённый Microsoft, через несколько лет ставший Outlook.com). Google представил Gmail в 2004 году, положивший начало новому этапу инноваций, так как было предоставлено значительно больше места для хранения электронной почты, а также более быстрый пользовательский интерфейс²⁶.

И при этом открытые стандарты предлагают большую гибкость. Пользователь может использовать адрес электронной почты, отличный от Gmail, в интерфейсе Gmail. Или он может использовать учетную запись Gmail с совершенно другим клиентом, таким как Microsoft Outlook или Apple Mail²⁷. Кроме того, можно создавать новые интерфейсы поверх самого Gmail, например, с расширением Chrome²⁸.

Такая гибкость имеет много преимуществ для конечного пользователя. Даже если одна платформа, подобная Gmail, становится более популярной на рынке, стоимость переключения значительно ниже. Если пользователю не нравится, как Gmail обрабатывает определенные функции или он беспокоится о политике конфиденциальности Google, переключение на другую платформу намного проще, и пользователь не теряет доступа ко всем своим старым контактам или возможности написать кому-то еще (даже тем контактам, которые остаются пользователями Gmail).

Обратите внимание, что эта гибкость служит сильным стимулом со стороны Google для убеждения, что Gmail хорошо относится к своим пользователям; Google с меньшей вероятностью предпримет действия, которые могут привести к быстрому исходу. Это отличается от полностью проприетарной платформы, такой как Facebook или Twitter, где выход из этих платформ означает, что вы больше не общаетесь с людьми таким путем и не можете легко получить доступ к их контенту и коммуникациям. С такой системой, как Gmail, легко экспортировать контакты, архивные электронные письма и переключиться на любой сервис, не теряя возможности оставаться на связи с кем угодно.

Кроме того, это создает более благоприятные условия для конкуренции. Несмотря на то, что Gmail является особенно популярным почтовым сервисом, другие смогут строить крупные почтовые сервисы, такие как Outlook.com или Yahoo Mail, или запускать успешные стартапы имейл-сервисов, ориентированные на различные рынки и ниши, типа Zohomail или Protonmail²⁹. Также, это создает другие сервисы, строящиеся поверх существующей экосистемы электронной почты, с меньшим опасением зависеть от одной платформы, которая может закрыть их. Например, и Twitter³⁰, и Facebook³¹ имеют тенденцию менять направление продукта и отключать сторонние приложения, но в сфере электронной почты существует развивающийся рынок услуг и компаний, таких как Boomerang, SaneBox и MixMax, каждая из которых предоставляет дополнительные сервисы, которые могут работать на множестве различных почтовых платформ³².

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

Защита свободы слова и ограничение воздействия оскорбительного поведения

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

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

В такой системе ошибки Типа I (ложноположительный) и Типа II (ложноотрицательный) встречаются не просто часто; они неизбежны. Контент, который, по мнению многих, должен быть удален, остается наверху³⁴, в то время как контент, который, по мнению других, должен оставаться наверху, удаляется³⁵. Несколько сотрудников, занимающихся модерацией контента, могут рассматривать контент совершенно по-разному, и модераторы контента практически не могут принять во внимание контекст (отчасти потому, что большая часть контекста может быть недоступна или очевидна для них, а отчасти потому, что время, необходимое для полностью исследовать каждую ситуацию делает невозможным рентабельность). Точно так же ни одно технологическое решение не может должным образом учитывать контекст или намерение - компьютер не может распознавать такие вещи, как сатира или гипербола, даже на уровне, очевидном для любого читающего человека.

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

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

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

Важно сделать эту систему правил общедоступной, прозрачной и контролируемой любым конечным пользователем. Я хотел бы иметь возможность выбрать использование общедоступных элементов управления EFF для Twitter, используя интерфейс, предоставленный новой некоммерческой организацией, но затем перенастроить параметры, если я предпочитаю, скажем, больше контента о ЕС. Или, если я хочу использовать сеть в основном для чтения новостей, я могу использовать интерфейс, предоставленный New York Times. Или, если я хочу пообщаться с друзьями, я мог бы использовать специальный интерфейс, предназначенный для лучшего общения между небольшими группами друзей.

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

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

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

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

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

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

Защита данных и конфиденциальности пользователей

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

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

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

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

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

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

Создание условий для расширения инновационной деятельности

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

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

Однако, если кто-то мог представить новый интерфейс, или новые возможности, или лучшую модерацию, то неожиданно конкуренция в рамках конкретного протокола (ранее платформы) может быстро стать ожесточенной. Различные идеи будут испробованы и отброшены, но эксперимент в условиях реального мира, скорее всего, в кратчайшие сроки покажет, как эти услуги могут стать инновационными и быстро обеспечить большую ценность. В настоящее время многие платформы предлагают API, позволяющие третьим сторонам разрабатывать новые интерфейсы, но API управляются централизованными платформами - и они могут менять их ни с того, ни сего. В самом деле, Twitter много, много раз менял свою поддержку APIs и сторонних разработчиков - но в рамках протокольной системы APIs был бы открыт, с расчетом на то, что любой человек мог бы на нем строить, и не было бы централизованной компании для блокировки разработчиков³⁷.

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

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

Создание новых бизнес-моделей

Одна из основных причин того, что протоколы из раннего Интернета стали терять популярность по сравнению с централизованными платформами, - это проблема бизнес-модели. Наличие собственной платформы (если она приживется) - это модель, которая приносит компаниям много денег. Однако создание и поддержание протокола было проблемой на протяжении долгого времени. Большую часть работы обычно выполняли добровольцы, а протоколы со временем остановили развитие без внимания. Например, в 2014 году было обнаружено, что OpenSSL, основной протокол безопасности, на котором держится очень большая часть Интернета, имеет серьезный недостаток безопасности, известный как Heartbleed. Примерно в это же время было отмечено, что поддержка OpenSSL практически полностью отсутствует. Над OpenSSL работала небольшая группа добровольцев и один человек, работавший полный рабочий день. Фонд, который им руководил, первоначально получал довольно скромные гранты³⁸.

Таких историй много. Как упоминалось ранее, Deja News не смогла построить большую часть бизнеса с помощью Usenet, поэтому его продали Google. Электронная почта никогда не считалась таким источником дохода, как протокол, и обычно она включалась бесплатно в вашу учетную запись интернет-провайдера. Несколько первых компаний пытались создать веб-платформы на основе электронной почты, но два значимых таких примера были быстро куплены крупными компаниями (Rocketmail от Yahoo, Hotmail от Microsoft), чтобы включить их в более крупные продукты³⁹. В конце концов Google запустил Gmail, и он заработал приличную сумму после запуска электронной почты на своей платформе, но это не рассматривалось как крупный источник дохода. Тем не менее успехи Google и Microsoft с Gmail и Outlook, соответственно, показывают, что крупные компании могут создавать очень успешные услуги на основе открытых протоколов. Если Google испортит Gmail или создаст сложности с этой услугой, людям не составит труда перейти на другую почтовую систему и сохранить доступ ко всем, с кем они общаются.

Мы уже обсуждали конкуренцию между различными реализациями интерфейса и фильтров, для обеспечения лучшего сервиса, но, вероятно, также будет конкуренция за бизнес-модели. Скорее всего, будут проводиться эксперименты с различными типами бизнес-моделей, включающими как сервисы хранилища данных, взимающих плату за премиальный доступ и хранение (а также за безопасность), так и сервисы, как Dropbox и Amazon Web Services. Также может существовать множество бизнес-моделей, сформированных на основе реализаций и фильтров. Могут быть предложения по подписке на премиальные услуги или функции или альтернативные формы оплаты.

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

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

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

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

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

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

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

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

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

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

Что может не сработать

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

Сложность убивает

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

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

Наконец, одна из причин, по которой платформы с самого начала опережали протоколы, заключается в том, что все, что контролируется одним объектом, также приводит к явному повышению производительности. В мире протоколов с отдельными хранилищами данных/интерфейсами вы будете больше рассчитывать на то, что несколько компаний объединятся. Интернет-гиганты, такие как Google, Facebook и Amazon, действительно усовершенствовали свою работу, взаимодействуя друг с другом, включение в эту группу нескольких сторонних производителей повысит риск. Однако в этой области были широко распространены технологические усовершенствования (и, действительно, крупные платформенные компании открыли исходный код некоторых из своих собственных технологий, которые сделали это возможным). Вдобавок ко всему, скорости широкополосного доступа увеличились и должны продолжать расти, возможно, минимизируя техническое препятствие.

Существующие платформы слишком велики и это никогда не изменятся

Еще одним потенциальным препятствием является то, что существующие платформы - Facebook, YouTube, Twitter, Reddit и тд- уже настолько велики и внедрены в повседневную жизнь, что от них практически невозможно избавиться с помощью подхода, основанного на протоколах. Эта критика предполагает, что единственный способом избавления от платформ является создание совершенно новой системы, основанной на протоколах. Это может сработать, но сами платформы также могут рассмотреть возможность использования протоколов.

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

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

Во-вторых, продолжение того, что они делают, будет обходиться все дороже. Facebook уже недавно пообещал нанять еще десять тысяч модераторов; YouTube также пообещал нанять тысячи модераторов⁴². Наем всех этих людей будет увеличивать расходы и для компаний. Переход на систему, основанную на протоколах, переместит элемент модерации на конечных пользователей или на конкурирующие третьи стороны, снимая эти расходы с бухгалтерских книг для крупных платформ.

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

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

Это ухудшит проблему пузыря фильтров

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

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

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

Работа с более проблемным контентом

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

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

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

Пример в действии / Как это будет выглядеть на практике

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

В качестве альтернативы для этого могут быть созданы новые протоколы. Уже есть ряд попыток на разных уровнях. Такие сервисы, как IPFS (межпланетная файловая система) и связанное с ним предложение Filecoin, уже закладывают основу и инфраструктуру для распределенного набора сервисов, построенных на его протоколе и валюте⁴⁴. Сам изобретатель всемирной паутины Тим Бернерс-Ли работал над системой под названием Solid, которая теперь находится в его новой компании Inrupt, которая поможет сделать Интернет более распределенным⁴⁵. Другие проекты, такие как Indieweb, объединяют людей для создания многих частей, которые могут внести свой вклад в будущий мир протоколов вместо платформ⁴⁶.

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

Заключение

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

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

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

Это было бы радикальным изменением, но к нему следует относиться серьезно.

От NEAR

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

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

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

Если у вас есть идеи сервисов, управляемых сообществом, и вы хотите над ними работать, приходите в нашупрограмму поддержки предпринимателей.

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

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

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

Зачем вообще нужно генерировать случайные числа участникам, не доверяющим друг другу? Одна из областей применения -- это децентрализованные приложения. Например, приложение, которое принимает ставку от участника и либо удваивает сумму с вероятностью 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 можно здесь.

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

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

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

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

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

Немного криптографии

Для того, чтобы понять, как работают пороговые подписи, надо понимать немного базовой криптографии. Мы будем использовать две концепции: скаляры, или просто числа, которые мы будем обозначать строчными буквами (x, y) и точки на эллиптической кривой, которые мы будем обозначать прописными буквами.

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

1. Точки на эллиптической кривой можно складывать и умножать на скаляр (умножение на скаляр мы будем обозначать как xG, хотя нотация G^x тоже часто используется в литературе). Результат сложения и умножения на скаляр -- это точка на эллиптической кривой.

2. Зная только точку G и ее произведение со скаляром xG нельзя вычислить x.

Мы будем также использовать концепцию полинома p(x) степени k-1. В частности, мы будем использовать следующее свойство полиномов: если мы знаем значение p(x) для любых k различных x (и не имеем больше никакой информации о p(x)), мы можем вычислить p(x) для любого другого x.

Интересно, что для любого полинома p(x) и некоторой точки на кривой G, зная значение p(x)G для любых k различных значений x, можно также вычислить p(x)G для любой x.

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

Генератор случайных чисел на пороговых подписях

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

Допустим существует такой полином p(x) степени k-1, что первый участник знает p(1), второй знает p(2), и так далее (n-ый знает p(n)). Также допустим, что для некоторой заранее определенной точки G все знают p(x)G для всех значений x. Мы будем называть p(i) приватной компонентой i-ого участника (потому что только i-ый участник знает ее), и p(i)G публичной компонентой i-ого участника (потому что все участники знают ее). Как вы помните, знание p(i)G не достаточно чтобы восстановить p(i).

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

Как мы можем использовать такой полином, чтобы сгенерировать случайное число? Для начала нам нужно некоторая строка, которая прежде не использовалась как вход для генератора. В случае блокчейна хеш последнего блока h -- хороший кандидат для такой строки. Пусть участники хотят создать случайное число, используя h как seed. Сначала участники конвертируют h в точку на кривой используя любую заранее определенную функцию:

H = scalarToPoint(h)

Затем каждый участник i вычисляет и публикует H_i = p(i)H, что они могут сделать, потому что они знают p(i) и H. Раскрытие H_i не позволяет другим участникам восстановить приватную компоненту i-ого участника, и поэтому один набор приватных компонент можно использовать от блока к блоку. Таким образом, дорогой алгоритм создания полинома, описанный ниже, необходимо выполнить только однажды.

Когда k участников вскрыли H_i = p(i)H, все могут вычислить H_x = p(x)H для всех x благодаря свойству полиномов, которые мы обсудили в прошлом разделе. В этот момент все участники вычисляют H₀ = p(0)H, и это и есть результирующее случайное число. Обратите внимание, что никто не знает p(0), и следовательно единственный способ посчитать p(0)H это интерполяция p(x)H, что возможно только когда k значений p(i)H известны. Вскрытие любого меньшего количества p(i)H не дает никакой информации о p(0)H.

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

Есть одна проблема, которую мы аккуратно обошли стороной выше. Чтобы интерполяция работала, важно чтобы значение H_i которое опубликовал каждый участник i действительно было равно p(i)H. Так как никто кроме i-ого участник не знает p(i), никто кроме i-ого участника не может проверить что H_iдействительно посчитано правильно, и без какого-то криптографического доказательства корректности H_i злоумышленник может опубликовать любое значение в качестве H_i, и произвольно влиять на вывод генератора случайных чисел:

Есть по меньшей мере два способа доказать корректность H_i, мы их рассмотрим после того, как разберем генерацию полинома.

Генерация полинома

В прошлом разделе мы допустили, что у нас есть такой полином p(x) степени k-1 что участник i знает p(i), и никто другой не имеет никакой информации об этом значении. В следующем разделе нам также будет необходимо чтобы для некоторой заранее определенной точки G все знали p(x)G для всех x.

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

Один возможный протокол генерации полинома следующий:

1. Каждый участник i локально создает произвольный полином p_i(x) степени k-1. Они затем посылают каждому участнику j значение p_i(j), зашифрованное публичным ключом X_j. Таким образом только i-ый и j-ый участник знают p_i(j). Участник i также публично анонсирует p_i(j)G для всех j от 1 до k включительно.

2. Все участники используют некоторый консенсус чтобы выбрать k участников, чьи полиномы будут использоваться. Так как некоторые участники могут быть оффлайн, мы не можем ждать пока все n участников опубликуют полиномы. Результат этого шага множество Z состоящее из хотя бы k полиномов, созданных на шаге (1).

3. Участники убеждаются, что известные им значения p_i(j) соответствуют публично анонсированным p_i(j)G. После этого шага в Z должны остаться только полиномы, для которых приватно переданные p_i(j) соответствуют публично анонсированным p_i(j)G.

4. Каждый участник j вычисляет свою приватную компоненту p(j) как сумму p_i(j) для всех i в Z. Каждый участник также вычисляет все значения p(x)G как сумму p_i(x)G для всех i в Z.

Обратите внимание, что p(x) это действительно полином степени k-1, потому что это сумма отдельных p_i(x), каждый из которых это полином степени k-1. Затем, обратите внимание, что в то время как каждый участник j знает p(j), у них нет никакой информации об p(x) для x j. Действительно, чтобы вычислить это значение, им необходимо знать все p_i(x), и покуда участник j не знает хотя бы один из выбранных полиномов, у них нет достаточной информации об p(x).

Это весь процесс генерации полинома, который был необходим в прошлом разделе. Шаги 1, 2 и 4 выше имеют достаточно очевидную реализацию. А вот шаг 3 не такой тривиальный.

Конкретно, нам нужно уметь доказывать, что зашифрованные p_i(j) действительно соответствуют опубликованным p_i(j)G. Если мы не можем это доказать, злоумышленник i может послать мусор вместо p_i(j) участнику j, и участник j не сможет получить настоящее значение p_i(j), и не сможет вычислить свою приватную компоненту.

Есть криптографический протокол, который позволяет создать дополнительное сообщение proof_i(j), такое что любой участник, имея некоторое значение e, а также proof_i(j) и p_i(j)G, может локально убедиться, что e это действительно p_i(j), зашифрованное ключом участника j. К сожалению, размер такого доказательства невероятно большой, и учитывая что необходимо опубликовать O(nk) таких доказательств, использовать их для этой цели не получится.

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

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

Доказательства корректности H_i

Последняя часть, которую осталось обсудить, это как доказать корректность опубликованных H_i, а именно что H_i = p(i)H, без вскрытия p(i).

Вспомним, что значения H, G, p(i)G публичны и известны всем. Операция получения p(i) зная p(i)G и G называется дискретный логарифм, или dlog, и мы хотим доказать, что:

dlog(p(i)G, G) = dlog(H_i, H)

без разглашения p(i). Конструкции для таких доказательств существуют, например Schnorr Protocol.

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

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

Пытливый читатель может спросить: так как финальное случайное число это H₀, и p(0)G это публичная информация, зачем нужно доказательство для каждого отдельного Hi, почему вместо этого не отправить доказательство того, что

dlog(p(0)G, G) = dlog(H₀, H)

Проблема, что с помощью Schnorr Protocol нельзя создать такое доказательство, потому что никто не знает значение p(0), необходимое для создания доказательства, и более того, весь генератор случайных чисел основан на том, что никто не знает это значение. Поэтому необходимо иметь все значения H_iи их индивидуальные доказательства, чтобы доказать корректность H₀.

Однако, если бы на точках на эллиптических кривых была бы какая-то операция, которая семантически схожа с умножением, доказательство корректности H₀было бы тривиальным, мы бы просто убедились, что

H₀G = p(0)G H

Если выбранная кривая поддерживает elliptic curve pairings, такое доказательство работает. В этом случае H₀ это не только вывод генератора случайных чисел, который может проверить любой участник, который знает G, H и p(0)G. H₀ это еще и подпись на сообщении, которое использовалось как seed, подтверждающая, что k и n участников подписали это сообщение. Таким образом, если seed это хеш блока в протоколе блокчейна, то H₀ это одновременно мульти-подпись на блоке, и очень хорошее случайное число.

В заключение

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

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

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

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

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