Идеи из чата viz-world

Здравствуйте. Первая часть тут.
Идеи написаны на основе истории чата https://t.me/viz_world

"социальный" шлюз — на основе IP адреса как 4 версии, так и 6.

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

заходишь на сайт, он показывает твой йп — и тут же кошелек.

Так как сейчас многие используют динамические IP и прокси/vpn, упоминается ipv6.

Примеры

ты зашел в quake 3 arena и поиграл на сервере, и по йп сервака наградил админа.
тебе не надо заранее спрашивать — эй, а есть ли у тебя аккаунт виз: он через простой api запрос который руками можно сделать сможет востребовать награду.

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

идея смешная, странная, но интересная.

Анонимные хабы

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

• перевод туда с зашифрованным мемо
• хаб расшифровывает через свой мемо
• и ждет востребования

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

социальный шлюз повышенной точности — по email: авторизация по коду который пришел на почту.

По восстановлению аккаунтов:

Мультисиг с вариантом

• Владелец вес 2
• Доверенный вес 1
• Доверенный вес 1

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

Защищённые переводы (transfer)

сделать защищенный transfer через посредника (для проверки платежа), secure_transfer
Сейчас у нас есть простые лимиты — до 1000 руб оплата без пин-кода. До 15т.р. в сутки с пин-кодом. Больше без подобных платежей в прошлом не пустит, пока не подтвердишь свое владение акком.
Суть в том, что можно иметь как посредника персону/организацию, так и смарт-алгоритм/аккаунт, который предоставляет сервис с подобной механикой.
owner ключ может добавить переключатель через кого идут secure_transfer, простые transfer отключаются
secure_transfer ставятся на подтверждение, когда посредник/смарт-алгоритм подтверждает перевод — он проходит

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

Про стейт

Как синхронизацию сделать быстрее?
Для этого нужен плагин для того, чтобы делать слепок стэйта, скажем, каждые 1000 блоков, и сохранять его в json файл, и загружаться и начинать работать с него.
надо туда сериализовать все объекты стэйта:

• глобальные параметры, аккаунты, делегаты, параметры делегатов, expire award, делегированние, разделегирование, комитет, инвайты
• объект witness schedule

как механизм в теории должен работать

параметр в config-ini для плагина + плагин. Он ждет когда block_num % периодичность = 0, и запускает процесс создания слепка.
для ноды идет доп параметр --load-state, и он берет файл, разворачивает его и коннектится для синхронизации уже с него

Особенность bitshares/steem/eos в том, что дерева меркла нет
конечно, по поводу этого можно спорить: https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md#merkle-proofs-for-light-client-validation-lcv, но смысл в том, что нам не нужно дерево хэшей.
если есть консенсус и протокол блокчейна и доверие к определенным нодам, то можно рассматривать блокчейн как состояние леджера
поэтому вариант — плагин, который сохраняет стэйт + загружает его при запуске довольно весомый.
более того, он может применяться только локально, поэтому нужен еще параметр для ноды — может ли он делиться стэйтом по p2p запросу, тогда синхронизация ноды по доверенному узлу будет выглядить примерно так:

• дай стэйт!
• вот тебе - отправляет json файл + хэш от данных
• сверка хэша + распаковка стэйта
• запуск с стэйта + запрос новых блоков

это исключает многодневную синхронизацию.

этапность разработки тоже понятна — параметры, проверка параметров + создание стэйта, запись в json файл, загрузка ноды через воссоздание стэйта через файл, расширение сетевого протокола для передачи стэйта

Ускорение финальности, или как получать необратимый блок быстрее после отправки транзакции

Классический irreversible 17 из 21 + сверху ещё тендерминт что-ли обвес, получается что финализация при активности делегатов гораздо выше.
Я предлагал дополнить network протокол добавив согласование блока делегатами из будущих 17 слотов из очереди. При досрочной согласованности блок раньше становится irreversible.
То есть старый способ пассивный, он ждёт когда делегат поучаствует сформированным блоком в консенсусе, А новый способ активный - делегат утверждает, что такой-то блок считает валидным и в своей цепи.
Скорее всего протокол нужно будет дополнить виртуальной операцией, где делегат подтверждает хэш согласованного блока.

Сайдчейны

Сайдчейн — другая логика, другие механизмы, свой протокол и операции, но инициализация пользователей с цепи VIZ.
То-есть пользователь может придти и попросить активировать аккаунт X с паблик ключем Y, представляясь юзером виза Z и подписывая запрос используя ключ W. Сайдчейн принимает это и создает в своем стэйте новый аккаунт.
Использование сайдчейна — похоже будет на EOS в плане производительности, все зависит от того, как построить консенсус. Он касается решения проблематики конфликтующих транзакций: если на два узла подать одновременно разные команды использующие твой баланс — то делегатская нода получив их из сети решит, какую он примет, а какую откинет. Скорее всего это fifo.
у нас много узлов разноудаленных + децентрализация по всему земному шару накладывает ограничения в виде блока в 3 сек, а сайдчейн централизован по своей сути, есть инициализатор, которому нужна скорость обработки транзакций + своя логика работы.
Сайдчейнам редко нужна децентрализация в виде "подписи блоков", им нужна децентрализация по дистрибьюции данных + аудита валидности данных.
Структуру данных тогда можно представить в виде не блоков, а транзакций. Просто с счетчиком:
1
2
3
4
5
6

транзакция приходит сайдчейну, он нумерует ее и подписывает, что она валидна именно под этим номером. Другие могут синхронизироваться и аудировать такой сайдчейн.
Что это позволяет делать — криптографический сайдчейн с почти мгновенным ответом + отсутствием irreversible + отсутствие необходимости хранить какие-то данные в основной цепи. Она очень близка в LT.
Чтобы добавить D — нужно разработать консенсус для децентрализации и протоколу
если десяток нод согласятся валидировать данные транзакций по номерам
единственное что необходимо им будет делать — это общаться друг с другом и соглашаться по поводу нумерации транзакций.
Тут появляется шанс рассинхрона, как раз по поводу того, когда 1 аккаунт (с балансом 100) инициализирует 2 транзакции, переводом 80 из 100 и 90 из 100, притом отдает их разным нодам. Ноды могут не согласиться друг с другом по поводу нумерации, и тут выходит на сцену господин "Консенсус".
Если нода опрашивая соседей видит, что у них расходятся номера, то она может расчитать процент несоответствия и решить - принимать транзакцию или нет.
Но тут создается лаг, то-есть цена децентрализации — время опроса других нод и решение по поводу транзакции. На это уйдет 3-4-6 секунд.
Она может отвергнуть транзакцию и принять от соседей, если по ней больше согласия, и мы получаем DLT сайдчейн :).
Distributed это и значит учет транзакций.
Тут не может заходить речи про "награду" за подпись блока: все участники соглашаются их учитывать на добровольном начинании.
Как видно сайдчейн может быть централизированным (один доверенный подписант) и децентрализированным (много подписантов, но они находят консенсус между друг другом).

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

Представим, что мы хотим на нем сделать аналог SMT токена.
Механики вида SMT токенов работают иттерационно. Раз в блок происходит учет всех операций, по-порядку, чтобы стэйт соответствовал друг другу на разных машинах.
С учетом транзакций без блочной структуры, а просто нумеруя их, мы получаем проблему в отсутствии иттерационного механизма привязанного к времени.
Транзакция секунду назад была, а следующая спустя 10 секунд. А другая между ними.
Без четкой структуры блоков происходит проблема в виде инфляционных механик на ревард пул.
Можно привести консенсус в виде синхронизации нод в виде таймеров. И добавить иттератор инфляции и эмиссии, допустим, каждую секунду, тогда транзакции, которые приходят в промежуточные состояния работают с глобальной переменной между этими временными интервалами.
Как сделать их мгновенными? Существует проблема в виде когда пришло 2 транзакции одновременно. fifo? В централизированном сайдчейне — да.
В распределенном сайдчейне? Определенно нет.
Так как это сделать в распределенном сайдчейне. Пример:

• стэйт ревард пула в 0 секунд 1000 GV
• транзакция 1 award которая берет из пула часть 0.5 GV
• транзакция 2 award которая берет из пула часть 0.3 GV
• стэйт ревард пула в 1 секунду — остаток + 0.05 GV

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

• стэйт ревард пула в 0 секунд 0.6 GV
• транзакция 1 award которая берет из пула часть 0.5 GV
• транзакция 2 award которая берет из пула часть 0.3 GV
• стэйт ревард пула в 1 секунду — остаток + 0.05 GV

Прочие короткие идеи:

Первые 3 от @on1x.

1. Аналог localbitcoins.net, только с обменом viz.
   Но не конкретно переводы фиата в viz, а продажа электронного товара, фиксация передачи, споры, например при продаже внутри-игровой валюты
2. Dapp аля google docs, когда документы привязываются к авторизации VIZ, шифруются по паролю простым шифрованием.
   В идеале делать таблицы, а не документы классические. Переход по ссылке запрашивает авторизацию в блокчейне + сверка уровней доступа документа. Документ загружается в браузер юзера и js уже расшифровывает его по паролю который ввел юзер
3. key-value в tarantool как смартконтракт на HiddenEngine для Codius с оплатой в VIZ, варианты монетизации: продажа % памяти машины за VIZ или за делегирование VIZ (как самоокупаемость в ревардпуле).
4. Идея от 19 марта 2019, автор @ae: встроенный бот, который периодически утилизирует непотраченную энергию (себе или по списку аккаунтов). Подойдёт для @viz.plus. Ещё можно добавить такую фичу, как отложенное награждение, перевод токенов и т.п. при помощи пропозалов.
5. Идея протея @ksantoprotein
   если к примеру виз сделает так, что при транзакциях субдоменов можно было бы тратить бендвиш домена, то Анатоль уделает кибервей в самом зародыше
6. Идея от @ae
   ввести делегирование доли на определённый срок без права возврата до конца срока.
   Предполагаю, что это было бы полезно для тех, кто организует аренду делегирования. Возможно и что ещё, но больше мыслей нет.
7. Идея от @ivanzar про oauth в БЧ Viz:
   Мне кажется, что для безопасности можно в бч сделать систему типа OAuth. У аккаунта есть поле auth. В нем хранятся ключи со сроком жизни и разрешениями на разные транзакции. Допустим, auth: [["VIZ key", 27-01-2017, ["award", "custom.media"]]]
   Комментарии Анатолия @on1x:
   с разными операциями мне кажется проблемно будет сделать, есть уже предустановки, хотя... Может и можно что-то подобное сделать, но тогда нужно вводить операции добавления ключа, изменение ключа (+ продление), удаление ключа. + все операции модифицировать, чтобы был обход ключей и сверка их с подписью транзакции
   В списке идей, но использование под вопросом.

P.S.

50% бенефициарских распределены между авторами идей:

1. @on1x 25%;
2. @ae 20%;
3. @ksantoprotein 3%;
4. @ivanzar 2%.