Как разрабатывать большие приложения поверх блокчейна?

Каков рекомендуемый способ хранения медиафайлов в DApps?

Нет рекомендуемого способа. Большинство DApp имеют дело не с медиа, а с ценностью, безопасностью и проблемами, которые требуют криптографических доказательств или аутентификации (кто есть кто и кому принадлежит определенный закрытый ключ). И да, IPFS и Swarm — это варианты хранения данных. IPFS сейчас находится на переднем крае, а это означает, что не все идеально. Он растет, у них потрясающая команда (например, суперкрутая), и теперь у них почти неограниченный капитал, так что это сулит хорошее будущее для IPFS и Filecoin. Медиафайлы, как правило, большие по сравнению с текстом, а хранение данных в блокчейне Эфириума обходится очень дорого ( от $0.09-$0.90 за КБ по текущим ценам Эфириума). Не говоря уже об ограничениях и сложности работы с медиафайлами (при условии, что вам нужно делать что-то большее, чем просто хранить их) в Solidity.

Каковы рекомендуемые способы аутентификации пользователей в DApp?

Это одна приятная особенность DApps: только те, у кого есть закрытый ключ и парольная фраза учетной записи, могут аутентифицироваться как эта учетная запись, поэтому аутентификация пользователей встроена в Ethereum. Вы упомянули uPort, который сам по себе находится на ранней стадии, но у него тоже хорошая команда. uPort доставляет ваш открытый ключ Ethereum (это восходит к биту открытого/закрытого ключа, который встроен в Ethereum). Этот адрес является очень уникальным идентификатором пользователя. См. public_keyбит на следующем изображении из недавней записи в блоге uPort :

Какой стек технологий рекомендуется для внешнего интерфейса (мобильный, веб)? Есть ли необходимость в бэкэнде или промежуточном программном обеспечении для DApps?

Есть несколько частей типичного технического стека DApp:

1. Смарт-контракты Solidity, которые выполняются и хранятся в блокчейне
2. Веб-клиент javascript, который подключается к gethузлам (это способ подключения клиентов к блокчейну и взаимодействия с ним).
3. Клиенты в № 2 в основном работают под управлением web3. web3— это библиотека Javascript, написанная самим Ethereum. web3это определенно то, что вам нужно и с чем вы хотите ознакомиться.
4. Возможно, IPFS для хранения данных вне сети, которые являются одним или обоими: слишком большими для хранения в сети или слишком сложными для работы с текущими ограничениями языков высокого уровня виртуальной машины Ethereum.

Четвертый вопрос: можно ли разработать систему обычным способом с централизованной базой данных (marai/mongo/casendra), которая взаимодействует с серверной частью, но серверная часть также связана с блокчейном для сохранения хэшей данных для подтверждения их существования.

Короткий ответ: да, это возможно. Меня, работающего над http://Disten.se , сейчас очень интересует, как решается эта проблема . Например, мы создали инструмент, который сопоставляет gitхэши с IPFSхешами (чтобы обеспечить защиту состояния репо в цепочке). Это способ хранения (для чего блокчейны действительно хороши) указателя на правильное или истинное состояние некоторого контента в другом месте. Как вы намекнули, хэш на самом деле может кодировать сам контент (что является удивительным свойством хеш-функций) и может обновляться в соответствии с набором правил, записанных в коде вашего смарт-контракта.

Пятый вопрос: каковы передовые методы или рекомендуемый способ проектирования и разработки огромных систем на основе блокчейна (Dapps)?

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