Ничего, но так не происходит. Случаев в истории протоколов блокчейна, когда форк стал успешнее оригинала, почти нет.
С другой стороны, фундаментально протокол блокчейна с закрытым кодом не имеет никакого смысла, вся идея блокчейна заключается в том, что все, что в нем происходит, прозрачно. Нельзя быть уверенным, что умные контракты на цепи выполняются согласно протоколу, если нельзя убедиться что сама цепь работает согласно протоколу.
Что касается мержа открытых состояний — можно строить приложения так, чтобы этот мерж не происходил.
Можно представить себе две модели. В одной у пользователя есть два похожих приложения, каждое из которых имеет свое состояние, и в какой-то момент времени пользователь хочет состояния объединить (например, я использую Evernote и OneNote, и теперь хочу использовать одно).
Вторая модель — это что два похожих приложения построены поверх одной библиотеки с открытым состоянием, которая хранит данные. То есть оба приложения уже оперируют на общем состоянии (и ни одно приложение не имеет монополии над этим состоянием), и соответственно мержить ничего не надо, оба приложения могут менять состояние только через endpoints которые библиотека определяет, и эти endpoints всегда поддерживают состояние в консистентном состоянии.
Действительно, выбирая между тем, чтобы строить открытый протокол и продукт в открытой экосистеме, или закрытый протокол, второе чаще всего будет выгоднее экономически.
К счастью, многие технологические компании начинаются программистами / людьми с техническим прошлым, и утверждается, что часть культуры программистов — это создание открытых взаимодействующих друг с другом систем.
Соответственно задача не сделать разработку приложений с открытым состоянием выгоднее приложений с закрытым. Задача — сделать разработку приложений с открытым состоянием в принципе выгодной.
Пример базы данных, которую не поддерживает никакая корпорация / регулятор, в которой нельзя переписать данные — это блокчейн.
В идеальном варианте OpenUber и OpenLyft не реализуют свою систему рейтинга, вместо этого существует общий для всех таких сервисов контракт, на котором поддерживается рейтинг водителей. OpenUber и Open Lyft могут через конкретный end-point submitRating(driver_id, passenger_id, rating, service) (пока что не будем решать проблему анонимности, но она тоже решается) добавить рейтинг.
Более централизованный сервис может вызывать submitRating напрямую, на основе своих проприетарных алгоритмов, более открытый реализует назначение водителей поездкам на цепи тоже, и вызов submitRating будет разрешен только пассажиром назначенным водителю.
На блокчейне легко настраиваются права, и настроить чтобы только OpenUber мог засылать рейтинги с service = OpenUber, и только OpenLyft мог засылать рейтинги с service = OpenLyft делается тривиально.
Затем каждый сервис может аггрегировать рейтинги засланные сервисами, которым конкретный сервис доверяет. Никто не может менять рейтинги, удалять или добавлять, в обход протокола. Если OpenUber использует проприетарную логику для submitRating, OpenLyft может решить не доверять ему, и не использовать для своих рейтингов.
Насколько я понимаю OAuth, он не решает описанные мной проблемы.
Он не решает аутентификацию by design (не смотря на название). И в тех контекстах где он решает авторизацию, информация, которую приложения передают, все еще хранится на серверах приложений, а не где-то на моем аккаунте.
Вот конкретный пример: в нормальном интернете у меня не должны быть отдельные социальные графы на похожих сервисах. Как используя существующие решения сделать такой примитив, где существует социальный граф, который несколько приложений могут изменять с моего разрешения, но ни одно приложение не имеет эксклюзивное право забрать у меня доступ к нему, или менять без моего разрешения?
Все остальное — просто маркетинг вокруг onepage. Даже не whitepaper, извините...
Несомненно, это маркетинговая, а не техническая статья, она не пытается быть whitepaper.
Техническая информация есть здесь. Код тоже открыт. В очень доступном виде можно на английском посмотреть здесь, где мы с одним из исследователей из Ethereum Serenity разбираем детали NEAR и различия с Serenity.
Имеется ввиду что они проспонсируют дорогие исследования, и сделают большое количество этих ASICs, которые раздадут бесплатно / будут продавать очень дешево.
Идея в том, что если ASIC дешевый и общедоступный, то разумно ожидать что средний участник сети может его себе позволить, и можно выкрутить VDF с ожиданием на то, что такой ASIC у него есть. Так как теперь сложность VDF настроена на существующий ASIC, злоумышленникам чтобы вычислить VDF быстрее надо сделать новый ASIC который в 100 раз быстрее чем существующий ASIC, а не, допустим, CPU.
Там есть еще требование, которое я забыл упомянуть, что вычисление нельзя выполнить параллельно. Для большинства NP-полных задач удвоение вычислительной мощности уменьшает время почти вдвое.
Смотря что такое "плоском". От дерева нам совсем избавиться нельзя, потому что надо быстро пересчитывать корень merkle tree.
Мы просто добавляем хеш-таблицу для чтений, и вероятно избавляемся от персистентности, там персистентность упрощает реализацию, но не необходима.
В БД в текущей реализации храним как персистентное дерево, но даже в краткосрочной перспективе это не работает, потому что чтения слишком медленные.
Синхронизация идет блок за блоком, но не обязательно с genesis, и параллельная валидация планируется позже (но сейчас далеко не самая приоритетная задача).
"Достаточно быстро" — сейчас мы валидируем все заголовки, это занимает меньше часа. Но есть возможность синхнонизоваться намного быстрее скачивая только два заголовка на каждый день. Мы уже используем этот вариант для моста с Эфиром, и в скором времени полная нода тоже будет также синхронизовываться прежде чем скачивать недавнее состояние. Такая валидация занимает меньше минуты на каждый год работы протокола. Скачивание состояния в таком варианте — самая тяжелая часть. Но опять же, состояние разбито на шарды, так что скачивать все состояние тоже не надо.
NEAR разбивает состояние на несколько шардов, синхронизовать ноду, которая только подмножество шардов смотрит, быстрее (но учитывая что каждый шард потенциально ~30x быстрее чем Эфир, даже один шард синхронизовать в среднесрочной перспективе станет очень долго). Состояние каждого шарда — это подмножество всего состояния, и соответственно хранить его дешевле, чем все состояние.
За хранение данных надо не платить, а класть токены в залог (когда данные удалены, токены освобождаются). Соответственно общий размер данных ограничен сверху.
Если нет цели валидировать все с genesis, то нода может достаточно быстро проверить заголовки блоков, убедиться что с genesis до текущего момента все блоки имеют правильные подписи, и скачать состояние где-то на начало дня, которое можно проверить имея недавний заголовок. Потом можно валидировать вперед.
В среднесрочной перспективе мы будем просто выкладывать большие блобы, которые хранят состояние шарда на, допустим, начало месяца, и все транзакции в этом шарде в этом месяце, и соответственно если необходимо все-таки валидировать все с genesis, валидацию можно будет выполнить параллельно по месяцам и шардам.
У нас очень разные статьи в очереди, и такие же "узконаправленные", и о разработке на NEAR, и более научно-популярные.
Есть вот такой очень простой пример гостевой книги, там можно открыть в Gitpod и прямо из браузера собрать и запустить. Не совсем твитер, но показывает как примерно выглядит разработка.
Но вообще хранить твиты или сообщения в гостевой книге на цепи дорого, для этого нужно другое решение.
После нашего с Ильей ухода третий участник продолжил работу в компании, и достаточно быстро нашел несколько новых сотрудников. Я полагаю инвесторы сочли что шансы на успех все еще были достаточно высокие чтобы считать это хорошей инвестицией.
Наставления верные, и даже если инвесторы готовы вкладываться в идею, для которой не очевидно существование рынка, вероятность что компания не сгорит весьма низкая.
$800K — это размер посевного раунда, на этом стадии инвесторы готовы брать риски выше, и вкладывают в команду, а не в идею.
Наш пример на самом деле подтверждает обе точки зрения: (1) наша идея не была подтверждена рынком, и, как и ожидалось, оказалась никому не нужна, но (2) инвесторы вложились в команду, а не в идею, и команда в итоге нашла другую идею, которая оказалась гораздо успешнее.
По факту да — удобный и быстрый блокчейн со смарт-контрактами.
У блокчейна есть много применений, я их все в один комментарий не вмещу. Про самые интересные у нас будут посты.
"Еще один" — это очень громко сказано, сегодня реально работающих и используемых блокчейнов со смарт-контрактами есть, фактически, три, и у всех трех есть много нерешенных проблем. Рынок еще очень молодой.
На такой стадии компании обычно используется специальный документ, который называется SAFE (simple agreement of future equity), который не дает почти никаких гарантий инвестору, и почти полную свободу компании.
Соответственно, ситуации такие не обговариваются. Основатели компании рискуют только репутацией, и истории, когда основатели просто улетают на юга с миллионом долларов в кармане, случаются.
В моей когорте в YC я такого не помню, а вот в когорте MemSQL в 2011 была такая история. Там ребята, получив $150K от YC, улетели на Гавайи, и выкладывали фотографии с вечеринок там.
В нашем случае мы не успели потратить значительной части тех $400K, и просто предложили их вернуть инвесторам. Правда, никто обратно деньги не забрал.
Вы вот говорите "игры писал 18 лет назад". Я сначала подумал "Опять старики пришли ностальгировать", а потом посчитал, тоже оказывается 18 лет назад :(
Ничего, но так не происходит. Случаев в истории протоколов блокчейна, когда форк стал успешнее оригинала, почти нет.
С другой стороны, фундаментально протокол блокчейна с закрытым кодом не имеет никакого смысла, вся идея блокчейна заключается в том, что все, что в нем происходит, прозрачно. Нельзя быть уверенным, что умные контракты на цепи выполняются согласно протоколу, если нельзя убедиться что сама цепь работает согласно протоколу.
Что касается мержа открытых состояний — можно строить приложения так, чтобы этот мерж не происходил.
Можно представить себе две модели. В одной у пользователя есть два похожих приложения, каждое из которых имеет свое состояние, и в какой-то момент времени пользователь хочет состояния объединить (например, я использую Evernote и OneNote, и теперь хочу использовать одно).
Вторая модель — это что два похожих приложения построены поверх одной библиотеки с открытым состоянием, которая хранит данные. То есть оба приложения уже оперируют на общем состоянии (и ни одно приложение не имеет монополии над этим состоянием), и соответственно мержить ничего не надо, оба приложения могут менять состояние только через endpoints которые библиотека определяет, и эти endpoints всегда поддерживают состояние в консистентном состоянии.
Действительно, выбирая между тем, чтобы строить открытый протокол и продукт в открытой экосистеме, или закрытый протокол, второе чаще всего будет выгоднее экономически.
К счастью, многие технологические компании начинаются программистами / людьми с техническим прошлым, и утверждается, что часть культуры программистов — это создание открытых взаимодействующих друг с другом систем.
Соответственно задача не сделать разработку приложений с открытым состоянием выгоднее приложений с закрытым. Задача — сделать разработку приложений с открытым состоянием в принципе выгодной.
Пример базы данных, которую не поддерживает никакая корпорация / регулятор, в которой нельзя переписать данные — это блокчейн.
В идеальном варианте OpenUber и OpenLyft не реализуют свою систему рейтинга, вместо этого существует общий для всех таких сервисов контракт, на котором поддерживается рейтинг водителей. OpenUber и Open Lyft могут через конкретный end-point
submitRating(driver_id, passenger_id, rating, service)(пока что не будем решать проблему анонимности, но она тоже решается) добавить рейтинг.Более централизованный сервис может вызывать submitRating напрямую, на основе своих проприетарных алгоритмов, более открытый реализует назначение водителей поездкам на цепи тоже, и вызов submitRating будет разрешен только пассажиром назначенным водителю.
На блокчейне легко настраиваются права, и настроить чтобы только OpenUber мог засылать рейтинги с service = OpenUber, и только OpenLyft мог засылать рейтинги с service = OpenLyft делается тривиально.
Затем каждый сервис может аггрегировать рейтинги засланные сервисами, которым конкретный сервис доверяет. Никто не может менять рейтинги, удалять или добавлять, в обход протокола. Если OpenUber использует проприетарную логику для submitRating, OpenLyft может решить не доверять ему, и не использовать для своих рейтингов.
Конкретный аккаунт живет на конкретном шарде.
Между шардами транзакции не атомарные.
Грубо говоря любая транзакция, которая работает в рамках одного шарда имеет уровень изоляции REPEATABLE_READ, а между шардами — READ_UNCOMMITTED.
Насколько я понимаю OAuth, он не решает описанные мной проблемы.
Он не решает аутентификацию by design (не смотря на название). И в тех контекстах где он решает авторизацию, информация, которую приложения передают, все еще хранится на серверах приложений, а не где-то на моем аккаунте.
Вот конкретный пример: в нормальном интернете у меня не должны быть отдельные социальные графы на похожих сервисах. Как используя существующие решения сделать такой примитив, где существует социальный граф, который несколько приложений могут изменять с моего разрешения, но ни одно приложение не имеет эксклюзивное право забрать у меня доступ к нему, или менять без моего разрешения?
Несомненно, это маркетинговая, а не техническая статья, она не пытается быть whitepaper.
Техническая информация есть здесь. Код тоже открыт. В очень доступном виде можно на английском посмотреть здесь, где мы с одним из исследователей из Ethereum Serenity разбираем детали NEAR и различия с Serenity.
Имеется ввиду что они проспонсируют дорогие исследования, и сделают большое количество этих ASICs, которые раздадут бесплатно / будут продавать очень дешево.
Идея в том, что если ASIC дешевый и общедоступный, то разумно ожидать что средний участник сети может его себе позволить, и можно выкрутить VDF с ожиданием на то, что такой ASIC у него есть. Так как теперь сложность VDF настроена на существующий ASIC, злоумышленникам чтобы вычислить VDF быстрее надо сделать новый ASIC который в 100 раз быстрее чем существующий ASIC, а не, допустим, CPU.
Там есть еще требование, которое я забыл упомянуть, что вычисление нельзя выполнить параллельно. Для большинства NP-полных задач удвоение вычислительной мощности уменьшает время почти вдвое.
Смотря что такое "плоском". От дерева нам совсем избавиться нельзя, потому что надо быстро пересчитывать корень merkle tree.
Мы просто добавляем хеш-таблицу для чтений, и вероятно избавляемся от персистентности, там персистентность упрощает реализацию, но не необходима.
В БД в текущей реализации храним как персистентное дерево, но даже в краткосрочной перспективе это не работает, потому что чтения слишком медленные.
Синхронизация идет блок за блоком, но не обязательно с genesis, и параллельная валидация планируется позже (но сейчас далеко не самая приоритетная задача).
"Достаточно быстро" — сейчас мы валидируем все заголовки, это занимает меньше часа. Но есть возможность синхнонизоваться намного быстрее скачивая только два заголовка на каждый день. Мы уже используем этот вариант для моста с Эфиром, и в скором времени полная нода тоже будет также синхронизовываться прежде чем скачивать недавнее состояние. Такая валидация занимает меньше минуты на каждый год работы протокола. Скачивание состояния в таком варианте — самая тяжелая часть. Но опять же, состояние разбито на шарды, так что скачивать все состояние тоже не надо.
NEAR разбивает состояние на несколько шардов, синхронизовать ноду, которая только подмножество шардов смотрит, быстрее (но учитывая что каждый шард потенциально ~30x быстрее чем Эфир, даже один шард синхронизовать в среднесрочной перспективе станет очень долго). Состояние каждого шарда — это подмножество всего состояния, и соответственно хранить его дешевле, чем все состояние.
За хранение данных надо не платить, а класть токены в залог (когда данные удалены, токены освобождаются). Соответственно общий размер данных ограничен сверху.
Если нет цели валидировать все с genesis, то нода может достаточно быстро проверить заголовки блоков, убедиться что с genesis до текущего момента все блоки имеют правильные подписи, и скачать состояние где-то на начало дня, которое можно проверить имея недавний заголовок. Потом можно валидировать вперед.
В среднесрочной перспективе мы будем просто выкладывать большие блобы, которые хранят состояние шарда на, допустим, начало месяца, и все транзакции в этом шарде в этом месяце, и соответственно если необходимо все-таки валидировать все с genesis, валидацию можно будет выполнить параллельно по месяцам и шардам.
У нас очень разные статьи в очереди, и такие же "узконаправленные", и о разработке на NEAR, и более научно-популярные.
Есть вот такой очень простой пример гостевой книги, там можно открыть в Gitpod и прямо из браузера собрать и запустить. Не совсем твитер, но показывает как примерно выглядит разработка.
Но вообще хранить твиты или сообщения в гостевой книге на цепи дорого, для этого нужно другое решение.
После нашего с Ильей ухода третий участник продолжил работу в компании, и достаточно быстро нашел несколько новых сотрудников. Я полагаю инвесторы сочли что шансы на успех все еще были достаточно высокие чтобы считать это хорошей инвестицией.
Наставления верные, и даже если инвесторы готовы вкладываться в идею, для которой не очевидно существование рынка, вероятность что компания не сгорит весьма низкая.
$800K — это размер посевного раунда, на этом стадии инвесторы готовы брать риски выше, и вкладывают в команду, а не в идею.
Наш пример на самом деле подтверждает обе точки зрения: (1) наша идея не была подтверждена рынком, и, как и ожидалось, оказалась никому не нужна, но (2) инвесторы вложились в команду, а не в идею, и команда в итоге нашла другую идею, которая оказалась гораздо успешнее.
Строить компанию — это намного выше риск, но и намного выше отдача.
"Риск и головные боли" — это скорее "приключения и воспоминания", которых в Microsoft и MemSQL было намного меньше.
По факту да — удобный и быстрый блокчейн со смарт-контрактами.
У блокчейна есть много применений, я их все в один комментарий не вмещу. Про самые интересные у нас будут посты.
"Еще один" — это очень громко сказано, сегодня реально работающих и используемых блокчейнов со смарт-контрактами есть, фактически, три, и у всех трех есть много нерешенных проблем. Рынок еще очень молодой.
На такой стадии компании обычно используется специальный документ, который называется SAFE (simple agreement of future equity), который не дает почти никаких гарантий инвестору, и почти полную свободу компании.
Соответственно, ситуации такие не обговариваются. Основатели компании рискуют только репутацией, и истории, когда основатели просто улетают на юга с миллионом долларов в кармане, случаются.
В моей когорте в YC я такого не помню, а вот в когорте MemSQL в 2011 была такая история. Там ребята, получив $150K от YC, улетели на Гавайи, и выкладывали фотографии с вечеринок там.
В нашем случае мы не успели потратить значительной части тех $400K, и просто предложили их вернуть инвесторам. Правда, никто обратно деньги не забрал.
Обещают в 2021.
Вы вот говорите "игры писал 18 лет назад". Я сначала подумал "Опять старики пришли ностальгировать", а потом посчитал, тоже оказывается 18 лет назад :(
и
Gorodnya как в воду глядел, разве что не важно предназначен канал связи или нет