Остается только делать распределнный бэкенд с открытым исходным кодом, который умеет переживать нечестных участников (если их меньше 1/3, например), и поднимать сеть с независимыми участниками.
Как вы вообще это себе представляете? «Вася, бросай фиксить багу, тут нам кто-то резюме прислал, покопайся в его PR и тикетах на гитхабе часик-другой».
Как минимум соискатель может прямо в резюме указать PRы и тикеты, где он отличился, в этом случае имхо грех не покопаться минут 10. Если увиденное понравится — позвать на собеседование, у которого шансы закончиться положительно все-таки повыше. А учитывая, что в некоторых компаниях собеседования и по несколько часов могут длиться — в конечном счете экономия времени может оказаться значительной.
А если смотреть со стороны HRа — теоретически, если человек показывает, что его PRы куда-то приняли, особенно если они привязаны к тикетам с бурными обсуждениями — то наверное это означает, что он может договариваться с другими разработчиками, что тоже добавляет шансов, что собеседование пройдет хорошо, а значит время не будет потрачено впустую.
Да ладно, как раз работодатель может посмотреть в issue и PRы от потенциального работника и оценить:
— сложность задач
— качество кода
— умение разбираться в чужом коде
— умение договариваться (с мейнтейнером как минимум)
— умение грамотно выражать свои мысли
А что особенно забавно — Адам додумался до Hashcash в 1997 (и при этом на тот момент это предлагалось в первую очередь в качестве средства защиты от спама, а не валюты), но сам принцип proof of work был придуман не им, а еще за 5 лет до этого в 1992 (и тоже для борьбы со спамом): Dwork, Naor “Pricing via Processing or Combatting Junk Mail”
Именно книжки/учебника по теории не знаю, сам собирал информацию по статьям и презентациям. Если интересна ветка PBFT, то вероятно имеет смысл почитать:
в статье в списке литературы куча всякого полезного на самые разные темы, если интересна именно асинхронщина, то имеет смысл посмотреть статьи авторов Ben Or, Bracha, Cachin, Kursawe, Mostefaoui
В результате практические решения проблемы византийских генералов, были сосредоточены на различных методах выбора узла-лидера, который отправлял бы блок проверенной информации всем остальным узлам вместо того, чтобы пытаться достичь консенсуса по содержанию блока.
То, что leader-based PBFT-like протоколы (Tendermint кстати тоже к ним принадлежит) на данный момент очень популярны для всяких DLT не означает, что это единственное решение. На самом деле с тех же 80-х годов существует отдельная ветка исследований действительно асинхронных протоколов достижения консенсуса, в которых теорема FLP обходится недетерминированностью количества раундов за которые протокол сойдется, и 2016 вышла публикация с описанием протокола Honeybadger BFT, в котором ни в какой момент времени нет выделенных мастер-узлов, который не требует настройки никаких таймаутов, и имеет сравнимую с PBFT производительность. Причем этот Honeybadger на самом деле является развитием протокола SINTRA, опубликованного еще в 2002 году (всего на три года позже PBFT).
Учитывая хайп вокруг криптовалют у неподготовленного читателя после упоминания Etherium и не упоминания других проектов вообще может сложиться впечатление, что «аа, опять эти криптовалюты», хотя сфера применения этой структуры данных гораздо шире, поэтому и решил все-таки оставить комментарий. А заодно порадовать автора (ну, классная статья же, и ни одного комментария), и попутно чуть попиарить свой любимый проект.
Когда готовил свою статью — изначально писал в маркдауне, но при попытке опубликовать хабр обрезал чуть ли не половину. Однако методом тыка обнаружилось, что ровно то же количества текста в виде html отлично проходит. В итоге еще один лишний вечер на переверстку, и статью все-таки опубликовал, но осадок остался.
Еще в середине 80-х годов было доказано, что для обеспечения устойчивости распределенной системы она должна работать в условиях частичной синхронности.
Небольшая поправка — на самом деле частичная синхронность нужна только для детерминированной системы, в которой гарантируется достижение консенсуса за определенное число раундов. Однако есть полностью асинхронные протоколы, в которых консенсус достигается за случайное число раундов, но при этом матожидание этого числа вполне конечно.
узлы валидаторы голосуют за добавление блока в блокчейн, транслируя сообщение prevote
А что происходит, если propose от ведущего в данном раунде узла не пришел? Шлются nil- prevote по таймауту? Запоминаются ли ситуации, когда какие-то узлы тормозили с отсылкой propose, чтобы реже их выбирать "ведущими"?
Чтобы оценить возможности консенсуса, мы проверяли работу блокчейна на базе двух конфигураций: в одном дата-центре и нескольких, географически распределенных, дата-центрах.
Приходилось ли как-то настраивать таймауты для работы в одном дата-центре и нескольких? Измеряли ли производительность системы, когда некоторые узлы (в пределах 1/3 от общего числа) выключались или тормозили?
В Exonum-блокчейне фиксируются операции с деталями для поездов и данные техпаспорта каждого вагона. Это дает возможность отслеживать перемещение всех запчастей от официальных поставщиков и обнаруживать подделки.
Если не секрет — а кто при этом держит ноды? Какая-то одна организация, или по ноде на контрагента?
Также мы запустили образовательный блокчейн-проект на базе университета «Синергия». Реестр регистрирует и хранит все сведения об успеваемости студентов: оценки, результаты экзаменов и дипломы. По словам наших коллег, такой подход исключает возможность вносить изменения в документы об образовании и помогает экономить на их архивировании и сертификации.
Опять же — кто держит ноды? Если один университет — то возможность вносить изменения в документы все-таки есть, хотя любой держатель observer-ноды легко об этом узнает, но помешать не сможет.
Speaking of self-sovereign identity (SSI) I think it would be worth mentioning Hyperledger Indy project, which implements SSI using CL-based zero-knowledge proof cryptography with public parts stored in public permissioned ledger.
Да, потерявшиеся 8 мс меня тоже смутили, но подозреваю, что это может быть код, не связанный с графикой напрямую — видео вроде ведь не с графического движка в вакууме.
Хорошее — 500 объектов попадающих на отрисовку отправляются всего за 1 мс — не рекорд, но очень даже неплохо. State sorting в OSG все-таки работает, и возможно даже есть какой-то автоматический инстансинг.
Плохое — culling занимает 10 мс, иногда поднимается до 15. Это ОЧЕНЬ много, движок работает на грани, после которой начнутся тормоза, причем боттлнеком будет процессор, а не видеокарта. Вангую, что при необходимости усложнять сцену в лучшем случае вам придется либо пересматривать структуру своего scene graph, в худшем — смириться с архитектурными особенностями OSG, и отказаться от усложнения сцены.
Забавное — GPU тратит на кадр всего 2 мс. Это параллельно с CPU, который суммарно получается 12 мс и выше. Т.е. каждый кадр 10 мс видеокарта простаивает, и если даже вы увеличите площадь экрана или сложность шейдеров раз в 5 на итоговый FPS это не повлияет никак. В связи с этим очень рекомендую попробовать включить 8x MSAA — картнка должна стать намного более гладкой, без влияния на общую производительность. Более того, при этом можно попробовать перевести деревья на alpha to coverage и отключить для них сортировку по глубине — потенциально это может сэкономить прилично CPU, что в итоге скорее всего еще и поднимет FPS.
Я просто оставлю это здесь: https://crypto.stanford.edu/pbc/notes/crypto/voting.html
Как минимум соискатель может прямо в резюме указать PRы и тикеты, где он отличился, в этом случае имхо грех не покопаться минут 10. Если увиденное понравится — позвать на собеседование, у которого шансы закончиться положительно все-таки повыше. А учитывая, что в некоторых компаниях собеседования и по несколько часов могут длиться — в конечном счете экономия времени может оказаться значительной.
А если смотреть со стороны HRа — теоретически, если человек показывает, что его PRы куда-то приняли, особенно если они привязаны к тикетам с бурными обсуждениями — то наверное это означает, что он может договариваться с другими разработчиками, что тоже добавляет шансов, что собеседование пройдет хорошо, а значит время не будет потрачено впустую.
— сложность задач
— качество кода
— умение разбираться в чужом коде
— умение договариваться (с мейнтейнером как минимум)
— умение грамотно выражать свои мысли
Вроде есть подвижки в этом направлении, например gitcoin. К сожалению не знаю насколько хорошо это работает, но лучше что-то, чем ничего.
А что особенно забавно — Адам додумался до Hashcash в 1997 (и при этом на тот момент это предлагалось в первую очередь в качестве средства защиты от спама, а не валюты), но сам принцип proof of work был придуман не им, а еще за 5 лет до этого в 1992 (и тоже для борьбы со спамом): Dwork, Naor “Pricing via Processing or Combatting Junk Mail”
Именно книжки/учебника по теории не знаю, сам собирал информацию по статьям и презентациям. Если интересна ветка PBFT, то вероятно имеет смысл почитать:
Если интересно в принципе какие-то фундаментальные вещи, то вот например несколько статей:
Если интересно про Honeybadger и асинхронщину, то:
То, что leader-based PBFT-like протоколы (Tendermint кстати тоже к ним принадлежит) на данный момент очень популярны для всяких DLT не означает, что это единственное решение. На самом деле с тех же 80-х годов существует отдельная ветка исследований действительно асинхронных протоколов достижения консенсуса, в которых теорема FLP обходится недетерминированностью количества раундов за которые протокол сойдется, и 2016 вышла публикация с описанием протокола Honeybadger BFT, в котором ни в какой момент времени нет выделенных мастер-узлов, который не требует настройки никаких таймаутов, и имеет сравнимую с PBFT производительность. Причем этот Honeybadger на самом деле является развитием протокола SINTRA, опубликованного еще в 2002 году (всего на три года позже PBFT).
Про theft я в курсе, и имхо у него есть две серьезные проблемы:
Именно такого точно не было, возможно какой-то ещё кейс, но текст резало прямо в середине абзаца.
Небольшая поправка — на самом деле частичная синхронность нужна только для детерминированной системы, в которой гарантируется достижение консенсуса за определенное число раундов. Однако есть полностью асинхронные протоколы, в которых консенсус достигается за случайное число раундов, но при этом матожидание этого числа вполне конечно.
А что происходит, если propose от ведущего в данном раунде узла не пришел? Шлются nil- prevote по таймауту? Запоминаются ли ситуации, когда какие-то узлы тормозили с отсылкой propose, чтобы реже их выбирать "ведущими"?
Приходилось ли как-то настраивать таймауты для работы в одном дата-центре и нескольких? Измеряли ли производительность системы, когда некоторые узлы (в пределах 1/3 от общего числа) выключались или тормозили?
Если не секрет — а кто при этом держит ноды? Какая-то одна организация, или по ноде на контрагента?
Опять же — кто держит ноды? Если один университет — то возможность вносить изменения в документы все-таки есть, хотя любой держатель observer-ноды легко об этом узнает, но помешать не сможет.
Так уже… https://habr.com/ru/post/413445
Хорошее — 500 объектов попадающих на отрисовку отправляются всего за 1 мс — не рекорд, но очень даже неплохо. State sorting в OSG все-таки работает, и возможно даже есть какой-то автоматический инстансинг.
Плохое — culling занимает 10 мс, иногда поднимается до 15. Это ОЧЕНЬ много, движок работает на грани, после которой начнутся тормоза, причем боттлнеком будет процессор, а не видеокарта. Вангую, что при необходимости усложнять сцену в лучшем случае вам придется либо пересматривать структуру своего scene graph, в худшем — смириться с архитектурными особенностями OSG, и отказаться от усложнения сцены.
Забавное — GPU тратит на кадр всего 2 мс. Это параллельно с CPU, который суммарно получается 12 мс и выше. Т.е. каждый кадр 10 мс видеокарта простаивает, и если даже вы увеличите площадь экрана или сложность шейдеров раз в 5 на итоговый FPS это не повлияет никак. В связи с этим очень рекомендую попробовать включить 8x MSAA — картнка должна стать намного более гладкой, без влияния на общую производительность. Более того, при этом можно попробовать перевести деревья на alpha to coverage и отключить для них сортировку по глубине — потенциально это может сэкономить прилично CPU, что в итоге скорее всего еще и поднимет FPS.