[Realms] децентрализованные виртуальные миры

[Shaos]

вот думаю, а не уйти ли в полную анонимность? т.е. никаких е-мейлов и паролей - только ключ!

Тебе, конечно, виднее... но анонимность сейчас не тренд Интернета...
На многих радиотехнических сайтах тебе картинку скачать не дадут без регистрации.
На мой взгляд - это перебор... но таков уж общий тренд сейчас...

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

[Shaos]

Интересный вопро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 (отсортировал по убыванию количества активных пользователей за сутки):

Screenshot from 2020-09-28 01-52-54.png

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

Screenshot from 2020-09-28 02-39-41.png

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

[Shaos]

В биткоине (и многих других криптовалютах) для записи адресов в человеческом формате используется контринтуитивная система кодирования 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

[Icer]

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

[Shaos]

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

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

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

[Icer]

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

[Shaos]

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

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

[Shaos]

Существующие нынче криптовалюты подтверждают создание блока (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 рендеринг через трассировку лучей) - в этом случае проверка результата будет заключаться в выполнении того же задания на некоторых других узлах и последующей сверке результатов (если какой-то узел выдаёт левоту, несовпадающую с как минимум двумя другими копиями, то его надо наказывать)...

[Shaos]

Realms Credits (RC) можно разбить на более мелкие части:

Code: Select all

mRC -> milliRC (1/1000)
uRC -> microRC (1/1000000)
nRC ->  nanoRC (1/1000000000)
pRC ->  picoRC (1/1000000000000)

(хотя наверное пико сильно мелковато будет)

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

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

[Shaos]

В биткоине (и многих других криптовалютах) для записи адресов в человеческом формате используется контринтуитивная система кодирования 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

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

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

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

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

[Shaos]

Вобщем первопричина того, почему я смотрел в сторону 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 строки (два раза - для первой части секретного ключа и для публичного ключа), типа:

Code: Select all

ABR3ZYC54KWAXO
DWP2ELQWOE73EF
EJEJRL3OOIJK57
WORI34OJJKL334
DOP443DJKOROTE \
EPPWN2PO5OIN7R  \ ___ PUBLIC
PY3OVUI5OFI3PD  /     KEY
CVOPT3OLB56OPS /

И как я уже писал выше, если человек ошибся при вводе и ввёл 0 вместо O, 1 вместо I или 8 вместо B, то это можно легко поправить автоматически. Вот таблица кодирования BASE32 по RFC-4648 (ABCDEFGHIJKLMNOPQRSTUVWXYZ234567) :

Screenshot from 2024-11-03 21-31-42.png

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

Code: Select all

-----TEST 1

   ALGORITHM:
   Ed25519

   SECRET KEY:
   9d61b19deffd5a60ba844af492ec2cc4
   4449c5697b326919703bac031cae7f60

   PUBLIC KEY:
   d75a980182b10ab7d54bfed3c964073a
   0ee172f3daa62325af021a68f707511a

   MESSAGE (length 0 bytes):

   SIGNATURE:
   e5564300c360ac729086e2cc806e828a
   84877f1eb8e5d974d873e06522490155
   5fb8821590a33bacc61e39701cf9b46b
   d25bf5f0595bbe24655141438e7a100b

   -----TEST 2

   ALGORITHM:
   Ed25519

   SECRET KEY:
   4ccd089b28ff96da9db6c346ec114e0f
   5b8a319f35aba624da8cf6ed4fb8a6fb

   PUBLIC KEY:
   3d4017c3e843895a92b70aa74d1b7ebc
   9c982ccf2ec4968cc0cd55f12af4660c

   MESSAGE (length 1 byte):
   72

   SIGNATURE:
   92a009a9f0d4cab8720e820b5f642540
   a2b27b5416503f8fb3762223ebdb69da
   085ac1e43e15996e458f3613d0f11d8c
   387b2eaeb4302aeeb00d291612bb0c00

   -----TEST 3

   ALGORITHM:
   Ed25519

   SECRET KEY:
   c5aa8df43f9f837bedb7442f31dcb7b1
   66d38535076f094b85ce3a2e0b4458f7

   PUBLIC KEY:
   fc51cd8e6218a1a38da47ed00230f058
   0816ed13ba3303ac5deb911548908025

   MESSAGE (length 2 bytes):
   af82

   SIGNATURE:
   6291d657deec24024827e69c3abe01a3
   0ce548a284743a445e3680d7db5ac3ac
   18ff9b538d16f290ae67f760984dc659
   4a7c15e9716ed28dc027beceea1ec40a

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

[Shaos]

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



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

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

Screenshot from 2024-11-03 11-35-43.png

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

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

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

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

 screenshot

Screenshot from 2024-11-03 11-51-38.png

А вот Evolution Land там на 70 каком-то месте...

[Shaos]

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

Code: Select all

ABR3ZYC54KWAXO
DWP2ELQWOE73EF
EJEJRL3OOIJK57
WORI34OJJKL334
DOP443DJKOROTE \
EPPWN2PO5OIN7R  \ ___ PUBLIC
PY3OVUI5OFI3PD  /     KEY
CVOPT3OLB56OPS /

Сегодня узнал, что оказывается onion-адреса в торе формируются похожим образом

Code: Select all

6. Encoding onion addresses [ONIONADDRESS]

   The onion address of a hidden service includes its identity public key, a
   version field and a basic checksum. All this information is then base32
   encoded as shown below:

     onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion"
     CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2]

     where:
       - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service.
       - VERSION is a one byte version field (default value '\x03')
       - ".onion checksum" is a constant string
       - CHECKSUM is truncated to two bytes before inserting it in onion_address

  Here are a few example addresses:

       pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd.onion
       sp3k262uwy4r2k3ycr5awluarykdpag6a7y33jxop4cs2lu5uz5sseqd.onion
       xa4r2iadxm55fbnqgwwi5mymqdcofiu3w6rpbtqn7b2dyn7mgwj64jyd.onion

   For more information about this encoding, please see our discussion thread
   at [ONIONADDRESS-REFS].

https://github.com/torproject/torspec/blob/main/rend-spec-v3.txt

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