А смысл в кредитных организациях тогда?)
краудфандинг как существующий вариант. Может еще что-то появится. Общество самое решает во что готово вкладываться.

А у волмарт точно блокчейн? Коин не значит блокчейн.

Не уверен.

Да, блокчейн, посмотрелч

Смотри.

Интересно, на какой платформе

Сейчас централизация сдерживает рост. Те же банки - супер-медленные, неповоротливые и неудобные. Автоматизация процессов ведет в том числе к отчуждаемости этих процессов. Отчуждаемость в ряде случаев ведет к автономности. Автономность к развитию и переосмыслению, появлению новых паттернов и системному эффекту. А дальше - децентрализация становится возможной. Мы это уже во многих отраслях наблюдаем.
Помнишь бум электронных валют? И всякие еголды, голдмани, вебмани, манибукерс. Это ведь тоже элемент децентрализации.
А децентрализация в купе с анонимностью делает невозможным регулирование.
И вот тут я не знаю, что может случиться. По идее это делает невозможным и уплату налогов, а значит ставит под сомнение возможность существования государства, если оно не выйдет на самоокупаемость :)

Это ведёт к анархии)

Центробанки планомерно запрещают подобное, вот фактически анонимные переводы уже и запретили в РФ.

Когда (если) уровень мирового океана начнёт подниматься, после таяния ледников, то некоторые страны будут инвестировать в дамбы, а некоторые - в плавучие города.
С социальными глобальными изменениями история примерно такая же.

Реакционеров пока больше, но выиграют те, кто встроятся.

Государство преследует цель борьбы с серой экономикой, и, скорее всего, государства между собой договорятся как не допустить эмиссии альтернативных валют.
Прямой обмен ценностями - вот что будет крайне сложно остановить регулированием, прямой обмен товарами/услугами по взаимной договоренности.

Есть чисто технический архитектурный вопрос. Мне интересно мнение большинства.
Контекст такой: есть ресурс в системе, который имеет несколько уникальных идентификаторов разного вида. Как правильнее описать REST интерфейс к нему?
Предположительно есть такие варианты:
1. Разбить получение объекта на два запроса:
первый - получить основной идентфикатор: /resources/ids?id-type={idType}&id-value={idValue}
основной идентификатор можно назначить из перечня всех
второй - получить по основному - ресурс: /resources/{id}
2. Сделать сложный ключ, из типа и значения идентификатора:
/resources/{idType}:{idValue}
3. Отойти от стандарта и явно включить тип идентификатора в контракт:  /resources/{idType}/{idValue}

Они уникальны сами по себе или в паре?

В паре Тип-Значение.

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

использование идентификаторов сгенерированных клиентами в REST и вообще в горизонтально масштабируемых системах это боль, не делайте так. Идентификаторы, сгенерированные клиентами могут быть лишь дополнением к первичному идентификатору, сгенерированному сервером.

Тут речь не идет про идентификаторы клиентов. Просто есть интеграция нескольких подсистем. И объект в разных подсистемах видент под разынми ID. И если его представлять через API всей системы, получается, что у него несколько id из разных систем. Назначить естественный upstream и подчинить все подсистемы ему - проблематично.

"несколько уникальных идентификаторов" - кажется, что ваша проблема лежит где-то глубже. Можно немного конкретнее описать ситуацию?

По ендпойнту на подсистему. Конечно если число idType-ов невелико