VIZ.cx
denis-skripnik posted text :

Мы перевернули суть блокчейнов с ног на голову


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

Но начиная со Steem началась какая-то ерунда:
Статьи стали пихать в блоки... Которые предназначены для финансов и околофинансовых вещей (те же nft).

За Стимом пошли и Голос с Визом. Хорошо у нас отошли от постов в пользу каттомных наград и протоколов.

Но появился https://t.me/viz_social_bot, а после него была принята концепция социальных шлюзов, которые используют эмуляцию экономики Viz, а фонд наград формируют из самонаград.
Идея то интересная, но вот есть существенный недостаток: начали опираться на централизованные сервера и базы данных.
В финансовой составляющей.

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

Можно стремиться к переходу в L-2 режим со своими валидаторами, но это усложнение, которое может навредить...

Что предлагаю:
pending key-value дочерний аккаунту.

Это объект, содержащий ключом логин несуществующего суб-аккаунта, а значение - накопленную сумму наград.
Как только она достигает 10 VIZ, ключ со значением удаляются из объекта, и создаётся аккаунт с соответствующим логином и соответствующей суммой VIZ в соц. капитале.
Т. е. если награды идут на несуществующий аккаунт, они суммируются там.
Естественно аккаунт такой может содержать в логине Telegram id, youtube channel id или что ещё. Тем самым убирая необходимость в хранении данных с централизованных сервисов в БД...

Создатель аккаунта указывает публичный ключ по умолчанию аналогично memo key.

Приведу пример:
1. @social указывает award_reg_key VIZ1...
2. Пользователь заходит на Youtube и награждает канал Y1 с видео fs.
Отправляется награда аккаунту Y1.social с memo "fs".
fs - id видео. По сути, просто нечто для фильтрации или рейтингов...
3. Ноды видят, что аккаунта такого нет, но у social есть award_reg_key:
Добавляется в pending key-value с указанием суммы.
Естественно если уже было там, прибавляется.

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

Всё.

Comments


on1x  •  Только добрался ответить. Предубеждения мешают новому. У нас с тобой большой опыт как в Графен цепочках, так и EVM экосистемах. Коротко пройдусь по тезисам: То что совсем не правильно пихать тексты в блокчейн. Это решают владельцы актива и наблюдатели сети. Хотят хранить - хранят. Запретить писать в цепочку невозможно. Консенсус? В чем? Эти вещи опциональные. Когда крупный держатель оплачивает газ/капитал на запись в бч сотне ботов, это его право. Когда сеть сталкивается с перегрузкой - её и надо решать. Каждая экосистема придумывает свои способы. Один из них - не надо пихать все в оперативную память. Это была ошибка, а точнее более простое решение. Вот описали структуру поста и вот пишем в память объекты. То что это выльется в слишком дорогие сервера для Голоса/Стима - называется в корпоративном мире "технический долг". Его решение - перенести такие объекты из памяти в СУБД, которые вполне могут быть как SQL, так и NoSQL на жестком диске. Поэтому рубить с плеча "надо или не надо" - неразумно. Как это решают другие сети? Приходят к удалению истории и сохранении только важных вещей, необходимых для работы сети. Состояние системы важнее истории. К этому идут все сети. И этот переход логичный, который и будет разделять по типу сети - blockchain это или ledger. Более того, некоторые сети делают еще хитрее. Даже важные вещи не вечные. Например в TON у смарт-контракта есть депозит за storage данных контракта. У этих данных есть экспирация. Когда транзакция затрагивает работу контракта - она пополняет этот депозит и оплачивает время простоя данных которые в storage контракта. Если контрактом никто не пользуется и наступило время экспирации хранения его данных - они УДАЛЯЮТСЯ. Шок контент, из блокчейна удаляется смарт-контракт :D Каждый кто пользуется смарт-контрактом в ТОН - оплачивает его же работу и хранение данных. Теперь про L2. Они хотят быть достоверными и доказуемыми, за счет публикации root хэша транзакций и дерева меркла. Но это СТОИТ газа в верхней цепи. Получается такая зависимость. Как показали наблюдения за 5+ лет - 99% пользователям все равно где происходит активность. Ончейн каждая транзакция, обернутая очередь транзакций или хэш транзакции в L2, подписанная непонятно кем и где. Это пользовательский опыт, желание делать ончейн есть не у всех. И это уже вопрос личной осознанности в инструментарии и действиях. Пример супер-успешных приложений на TON показал - что простой юзер БЕЗ кошелька и активов - все равно пройдет по воронке в экосистему, если ему будет интересно. Цель продукта - удовлетворить юзера. Поэтому тот же Fanzee с рынком предсказаний на Тоне - не спрашивает у тебя сид фразу и не генерит новый кошелек/аккаунт. Он просто в своей базе делает отметку, сколько у твоего telegram id какое количество токенов. И позволит в будущем делать пополнение и вывод. Они уже получили 2 миллиона долларов инвестиций и помощь от TONCoin Fund (https://blog.ton.org/toncoin-fund-why-we-invested-fanzee). И таких примеров много. Экосистема не обязана расти только с on-chain активностями. Хотя и хочется, да. Теперь про VIZ - он интересный. Аккаунт модели, хранение только важного, архивные ноды сами задают сколько времени хранить историю транзакций. И масштабирование возможно теми же способами, как и в TON - когда приложение записывает количество токенов проекта рядом с telegram id. А ввод/вывод уже в самой сети, хоть с конвертированием VIZ в один из токенов. Желание сделать кошельки всем - интересное. Но неразумное в долгую. Не всем людям нужны onchain транзакции. Я как представлю, что у Fanzee с их 1.8 миллионами игроков. Создать каждому кошелек стоит 0,0055 TON за адрес, получится 9900 TON, это около $67k на данный момент. А ведь если еще и onchain делать все активности - с смарт контрактами ТОНа это не дешевая вещь. Например, поменять на DEX один актив на другой уходит $0.50 за один обмен. А в смарт-контрактах на рынке предсказаний вряд ли будет дешевле. Люди не готовы платить за это такую цену. Одно дело зайти и поиграть на рынке предсказаний делая ставки с игровыми токенами (минимальная ставка 100 FNZ, около $2.4), другое дело отдавать 25% от ставки за комиссию сети. Именно поэтому, по моему мнению, Мир и пришел к гибридной модели. Когда не вся активность нужна on-chain. На больших объемах пользователей это избыточная и дорогая модель. Понимая, что RAM не резиновый и каждый созданный объект в блокчейн-системе занимает место и требует обслуживания - в Виз и есть минимальный социальный капитал требуемый для создания аккаунта. Это просто необходимость. И граница между "ой, это дешево" и "ой, это дорого" довольно быстро меняется. В зависимости от нагрузки и цены/востребованности токена.

social.denis-skripnik  •  Уже ночь, поэтому не подумал, что одинаковый публичный ключ позволит пользователям с такими логинами получать доступ и к другим... Как и писал: нужны доработки будут идеи... Пока вижу только 2 варианта: 1. Аккаунт может в любой момент отправить специальную транзакцию, назначающую аккаунту будущему публичный ключ. Он добавляется во второй объект, где ключи - аккаунты, значение - ключ. 2. Генерировать ключи для каждого аккаунта на основе ключей более высокого уровня. Таким образом владелец аккаунта будет иметь доступ к начальным ключам, а сами пользователи друг к другу - нет...