Post
Topic
Board Идеи
Re: Просьба оценить идею
by
Fractal1
on 13/04/2018, 09:39:54 UTC
приведите, пожалуйста примеры сетей, где бы пользователь "А" видел бы новости пользователя "С", при учете, что "А" подписан на "В", а "В" подписан на "С". И "В" не репостит все подряд.
И где это видано, чтобы сиськи ничего не рекламировали?  Wink Wink
Например, рекомендации ВК, но там ещё ранжирование прикручено, дабы не сваливать кучу шлака в одну, простите за тавтологию, кучу.
Не пользуюсь контактом, надо посмотреть, насколько это похоже.

Регистрируете 10 млн уникальных аккаунтов? И ведете их достаточно активно?... Ну хрен знает, зачем оно Вам.
То есть не только количество связей и/или денег на кошельке играет роль. Значит, надо ещё это самое "ведение" хранить. Децентрализованно, конечно.
Хранить всю активность на блокчейне категорически неудобно: большие объемы и отсутствие анонимности. Эта функция должна остаться централизованной.

Как собираетесь обеспечивать случайность? Что мешает генерировать R=0 и быть победителем?
Как числовое значение первых N байт результата хэша предыдущего блока и публичного ключа узла, поделенное на максимально возможное значение 2^( N*8 ). Математически доказано, что результат SHA256 распределен равномерно на всем интервале возможных значений. Это уже реализовано в NXT например.
≠ случайно
выходной результат хэширования невозможно предсказать без проведения этого действия. Поэтому можно считать, что это приемлемый способ генерации случайного числа. Не подкинув монетку, Вы тоже не сможете сказать, какой стороной она упадет. Да, монетка каждый раз в идеале выдает непредсказуемый результат, а хэширование при одинаковых входных данных будет выдавать один и тот же результат. Но входные данные на каждом новом блоке меняются. Вы можете для всех узлов сети, зная их публичные адреса, в КАЖДЫЙ КОНКРЕТНЫЙ РАЗ вычислить победителя. Но это не дает абсолютно никаких преимуществ. На один, два, три хода вперед Вы вычислить победителя не сможете. Повторюсь, это зарекомендовавший себя способ.