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

Я пытаюсь разработать платформу для социальных сетей на платформе Ethereum и интегрировать ее с моей валютой (маркер ERC20). Эта платформа позволит пользователям публиковать медиафайлы (статьи /изображения /видео), а другие будут просматривать и комментировать. Поэтому я здесь для ответов на несколько вопросов.

Первый вопрос: Каков рекомендуемый способ хранения медиафайлов в DApps?
Я знаю два варианта; IPFS и SWARM , но не знаю, что лучше всего подойдет в моем сценарии. Фактически рой находится в тестовой фазе.

Второй вопрос: . Каковы рекомендуемые способы аутентификации пользователей в DApp?
Чтобы избежать аутентификации на основе открытых открытых ключей, я нашел Uport , может использоваться в DApps для аутентификации пользователей в удобный для пользователя, но он все еще находится в Alpha.

Третий вопрос: Какой стек технологии рекомендуется использовать для интерфейса (Mobile, Web)? Есть ли необходимость в backend или промежуточном программном обеспечении для DApps?

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

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

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

6 голосов | спросил furusiyya 30 J000000Sunday17 2017, 03:20:45

1 ответ


2
  

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

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

  

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

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

 введите описание изображения здесь>> </a> </p>

<blockquote>
  <p> Какая технологияonk [sic] рекомендуется для интерфейса (Mobile, Web)? Есть ли необходимость в backend или промежуточном программном обеспечении для DApps? </p>
</blockquote>

<p> Есть несколько частей типичных стеков технических характеристик DApp: </p>

<ol>
<li> Твердые интеллектуальные контракты, которые выполняются и хранятся в блок-цепочке </li>
<li> Веб-клиент javascript, который подключается к узлам <code>---- +: = 3 =: + ----</code> (это способ подключения клиентов к блочной цепочке и взаимодействия с ним) </li>
<li> Клиенты в # 2 в основном запускают <a href=geth . web3 - это библиотека Javascript, написанная самим Ethereum. web3 определенно вам нужно и вы хотите познакомиться.

  • Возможно, IPFS для хранения данных вне сети, которая является одной или двумя из них: слишком велика для хранения в сети или слишком сложно работать с текущим ограничением языков высокого уровня Ethereum Virtual Machine.
  •   

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

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

      

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

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

    ответил JohnAllen 3 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 03 Sep 2017 07:56:26 +0300 2017, 07:56:26

    Похожие вопросы

    Популярные теги

    security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132