nedoPC.org

ну можно скажем совсем новичкам запрещать общаться в чате - пусть только бродят как массовка
если они начнут участвовать в виртуальной экономике (выполнять контракты и зарабатывать виртуальные деньги), то у них будет расти карма и если карма будет больше скольки-то, то можно разрешать писать в чат (карму можно быстро заминусовать если они начнут хулиганить)
и потом полной анонимности небудет - система будет знать IP-адрес пользователя в любом случае

Интересный вопроc - чем собственно могут отличаться реалмы (т.е. Realm Virtburg скажем от какого-то гипотетического Realm Sirius)?

Что-то мне думается, что валюта между ними должна быть одна и таже ( Realm(s) Credits? ), но скажем пороги вхождения в разные реалмы могут быть разными - т.е. 100 кредитов, дающихся новому пользователю Realm Virtburg не даются просто так - пользователь выполняет какую-то задачу на своём компьютере, чтобы заработать эти кредиты. Другой реалм может иметь более низкий порог вхождения (скажем 10 кредитов или 1 кредит), но соответственно там может быть больше "хулиганов", которые зашли просто нагадить.

Может ли один и тот же пользователь иметь разные имена в разных реалмах? Да нет проблем!

Может ли пользователь заработать виртуальные деньги в одном реалме и истратить в другом? Наверное нет (т.к. в другом реалме может оказаться слишком просто их заработать) - скорее всего юзер входя в реалм первый раз переводит свои заработанные кредиты в виртуальные деньги реалма, но тогда валюты в разных реалмах будут всё-таки разные (хоть и эквивалентные).

Может ли пользователь заработать больше чем 100 кредитов, чтобы прийти в реалм с большим количеством денег? По идее в его виртуальном кошельке могут быть сколько угодно заработанных кредитов, но наверное при заходе в реалм первый раз надо брать только 100, чтобы все новички были равноправными (у каждого по 100).

Может ли пользователь дозаработать кредитов после того как зашёл в реалм и перевёл первые 100 кредитов? Наверное дозаработать может (выполнив ещё вычислительных задач), но он не сможет ввести заработанное в тот же самый реалм, куда он уже зарегистрировался, но он может перевести остаток на другой кошелёк - другому пользователю, причём как бесплатно, так и за реальные деньги! т.е. теоретически человек может не ждать 1 час, зарабатывая 100 кредитов, а может просто КУПИТЬ их на рынке за баксы и сразу зарегистрироваться в желаемом виртуальном мире (в данном случае Realm Virtburg)!!!

Выходит, что узел сети Realms, неподключённый ни к одному Realm-у, является чисто узлом некоей новой криптовалюты со своим блокчейном?...

P.S. Или может просто сесть на хвост к Ethereum и сделать всё на его платформе со смарт-контрактами и нон-фанджибл токенами?...

P.P.S. С другой стороны, если верить сайту https://www.stateofthedapps.com/ в настоящий момент существует 14 развитых платформ для распределённых приложений на блокчейнах:

• Ethereum
• EOS
• Klaytn
• Hive
• Blockstack
• ICON
• Steem
• POA
• xDai
• Neo
• OST
• Loom
• GoChain
• TRON

Так что добавление в этот список ещё одной платформы всего лишь требует выполнения следующих условий:

• Public DApp platform with smart contract capability
• Mainnet launched
• Decentralized nodes operated by separate parties
• Open source codebase
• At least 10 DApps live
• Block explorer that can link to individual contracts

P.P.P.S. Вот например 10 самых популярных распределённых приложений (Dapps) в категории Games (отсортировал по убыванию количества активных пользователей за сутки):

Вот например такая игра есть:

Судя по описанию, автора этой игры посещали те же мысли, что и меня 20 лет назад, когда я обдумывал Виртбург

В биткоине (и многих других криптовалютах) для записи адресов в человеческом формате используется контринтуитивная система кодирования Base58 (это когда последовательность битов заменяется на последовательность символов в количестве 58 штук, т.е. не являющимся степенью двойки - 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz) - я думаю у нас за основу можно взять что-то более стандартное и простое (с основанием, которое есть степень двойки), например систему кодирования Base32 описанную в RFC4648: https://tools.ietf.org/html/rfc4648#section-6 (более распространённая base64 для записи названий ключей не подходит т.к. там есть похожие символы O и 0, 1 и l, а также символы нецифробуквенные, которые при клике в текст мышой определяются как разделители и не выделяются). При кодировании Base32 (ABCDEFGHIJKLMNOPQRSTUVWXYZ234567) ключ длиной 32 байта (256 битов) будет закодирован 52 символами, причём последний 52й символ покроет только последний бит и т.к. лишние 4 бита всегда будут нулями, то последним символом может быть только один из двух символов A (последний бит 0) или Q (последний бит 1). При ручном вводе ключа если человек ошибся и написал 1 или 0, то их можно автоматически подменять на I и O - точно также 8 можно подменять на B (ошибка такого плана менее вероятна, но кто знает - пусть такая замена тоже будет).

P.S. А вот в Ethereum используется обычная hex-запись, например https://etherscan.io/address/0x9469d013805bffb7d3debe5e7839237e535ec483

Ноль должен быть с чертой
Интересно с каких пор пошла мода на пустые нули?

Ну в графических средах нули редко перечёркнутые

Подумалось тут как сортировать текстовые строки, записанные в base32 (ABCDEFGHIJKLMNOPQRSTUVWXYZ234567) - наверное можно временно подменить 234567 на [\]^_` тогда символы будут идти чётко друг за другом в соответствии с кодами ASCII, а после сортировки вернуть обратно 2...7

Ну или в бинарном виде сортировать, а base32 использовать только для ввода человеком и вывода человеку...

Как вариант от начинающего Кэпа: сделать свою таблицу кодирования где цифры идут первыми.
Или нужна совместимость с base32?

Лучше брать что-то стандартное, чтобы не возникало недовольства пользователей

Существующие нынче криптовалюты подтверждают создание блока (consensus) либо через Proof-of-Work (перебирание хешей, чтобы получить красивый хеш с определённым количеством нулей вначале) либо через Proof-of-Stake (голосуют только те, у кого фантиков накопилось больше) с небольшими вариациями (см. https://www.investopedia.com/terms/c/consensus-mechanism-cryptocurrency.asp). Я вот задумался про новую концепцию "Proof-of-Useful-Work", чтобы не просто тупо хеши считать, а делать что-то полезное, например запускать некие полезные программки, выдающие предсказуемый и повторяемый вывод (оказывается уже были такие мысли и у других - см. видео тут: https://www.coursera.org/lecture/cryptocurrency/proof-of-useful-work-aD8Pb).

P.S. Вот такая штука существует какое-то время - типа криптовалюта на базе BOINC вычислений: https://gridcoin.us/
Минус на мой взгляд что BOINC программы приходят отдельно и имеют полный доступ к машине как обычные программы
В реальности полезные вычисления должны быть на виртуальной машине, работающей песочнице - чтобы небыло доступа к диску и к чужим областям памяти
И можно даже сделать так, чтобы исключить центральный авторитет, который будет эти программы одобрять-неодобрять - типа засылать в сетку можно будет любые программы, но они должны выдавать повторяемый результат и работать какое-то определённое время, иначе засылальщик будет наказан временным или постоянным отключением от сети.

P.P.S. Программы могут быть такие, где можно относительно быстро проверить результат (например поиск каких-то паттернов игры Жизнь либо построение оптимальных троичных схем в DDT) - тут всё понятно, а могут быть программы, результат работы которых неизвестен (например проведение массовых боёв роботов по типу Robot Warfare 1 или 3D рендеринг через трассировку лучей) - в этом случае проверка результата будет заключаться в выполнении того же задания на некоторых других узлах и последующей сверке результатов (если какой-то узел выдаёт левоту, несовпадающую с как минимум двумя другими копиями, то его надо наказывать)...

Realms Credits (RC) можно разбить на более мелкие части:
(хотя наверное пико сильно мелковато будет)

P.S. Например по умолчанию, когда узел не участвует ни в одном реалме, он не может получать или отправлять сообщения (чтобы исключить спам), но если очень надо, то можно послать ненулевое количество RC денег кому-то, написав сообщение в поле memo, и минимальным ненулевым количеством денег может стать 1 nRC

P.P.S. Плюс как минимум 1 nRC пойдёт валидаторам блока для включения транзакции в блок, который потом прицепится в блокчейн - сумма всех денег на оплату транзакций включённых в блок может быть поделена между тремя валидаторами - 50% может пойти самому первому валидатору, решившему задачу и по 25% двум другим, которые быстрее всего подтвердили корректность решения...

Для укорачивания адресов можно воспользоваться ещё не сломанным хешом 25-летней давности RIPEMD-160 (как в биткоине):

https://homes.esat.kuleuven.be/~bosselae/ripemd160.html

20-байтовый хеш в таком случае форматом Base32 будет закодирован в виде строки длиной всего 32 символа, что несколько лучше, чем 52 символа...

P.S. Ну или просто отбрасывать какую-то часть публичного ключа (меньше половины?), чтобы получать из оставшегося уникальный адрес - и в одном, и в другом случае надо будет по укороченному хешу уметь вытаскивать из распределённого хранилища полный ключ для проверки цифровой подписи

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

Публичный ключ ed25519 имеет длину 32 байта

Секретный ключ ed25519 имеет длину 64 байта, но его вторая половина (последние 32 байта) равна публичному ключу

Электронная подпись, сгенерированная по алгоритму ed25519, имеет длину 64 байта и выглядит непохожей ни на публичный, ни на секретный ключ (вот её можно передавать в BASE64 или вообще прямо в хексе или даже в бинарном виде, т.к. она будет всегда идти электронным способом)

К записи ключа в формате BASE32 можно присовокупить контрольную сумму - скажем первые сколько-то байт из хеша RIPEMD-160 бинарного представления ключа, чтобы при вводе оно сразу определило правильно введён ключ или нет (если использовать тот же SHA512, то его будет сложнее посчитать на мелкодевайсах, которые могли бы проверять валидность ключа при вводе). Можно сделать так, чтобы дополненные байты делали половинки ключа длиной кратной 5, чтобы всё чётко ложилось на BASE32 без дыр и пустот. Например, если представлять первые 32 байта секретного ключа и 32 байта публичного ключа (которые равны последним 32 байтам секретного ключа) независимо друг от друга, то к каждому из них можно дописать по 3 байта контрольной суммы, что в результате даст 35+35 байт, что выльется в 56+56 символов BASE32, которые можно написать в несколько строк - скажем по 8 символов в 7 строк либо по 14 символов в 4 строки (два раза - для первой части секретного ключа и для публичного ключа), типа:
И как я уже писал выше, если человек ошибся при вводе и ввёл 0 вместо O, 1 вместо I или 8 вместо B, то это можно легко поправить автоматически. Вот таблица кодирования BASE32 по RFC-4648 (ABCDEFGHIJKLMNOPQRSTUVWXYZ234567) :


P.S. Интересно, что RFC-8032 в случае Ed25519 называет "secret key" 32-байтовое начало 64-байтового полного ключа: https://datatracker.ietf.org/doc/html/rfc8032

P.P.S. Проверил - программы, что в архиве выше, отрабатывают эти примеры правильно...

За прошедшие 4 года эта игра сильно изменилась:

https://spintop.network/gamepedia/games/evolution-land

P.S. Старый сайт, который показывал статистику по блокчейн-играм похоже помер (точнее стал перенаправлять просто на анализатор криптовалют), но вроде теперь есть другой сайт, который правда не умеет сортировать по игрокам в сутки, но можно например по marketcap упорядочить:

https://spintop.network/gamepedia/games/?tags=&sort=marketcap

Там в первой десятке есть кроме всего прочего ранее упомянутые Decentralend и The Sandbox:
А вот Evolution Land там на 70 каком-то месте...

Сегодня узнал, что оказывается onion-адреса в торе формируются похожим образом
https://github.com/torproject/torspec/blob/main/rend-spec-v3.txt

Там тоже к публичному ключу ed25519 добавляется 3 байта (2 байта контрольная сумма и один байт для обозначения версии 3), чтобы получить 35 в байтах, что при конверсии в base32 превращается в те же 56 символов, но без разбивания на блоки и буквы там почему-то маленькие...