Какие элементы серверной части Dapp обычно хранятся в децентрализованном месте?

Мне неясно, какие элементы внутреннего кода Dapp на самом деле децентрализованы.

В следующей ссылке указано, что серверная часть Dapp полностью хранится в блокчейне. Однако, если бы я должен был создать веб-приложение Dapp, какая часть того, что обычно называют в смысле веб-разработки «бэкэндом», на самом деле находится в блокчейне?

Например, если бы я разрабатывал веб-приложение с использованием Python, была бы вся функция моего кода Python заменена смарт-контрактом, если бы я разрабатывал Dapp, или только ключевые элементы бизнес-логики?

Ответы (2)

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

В настоящее время я выбираю подход:

  • Замена Java (бэкенд-кода) смарт-контрактом Ethereum, написанным на Solidity.
  • Мое приложение обычно связано с базой данных для постоянного хранения. Чтобы отразить это в моем новом DApp, я выбираю использование IPFS .
  • IPFS хранит статический контент, который размещается в сети узлов. например, изображения, интерфейсный код, данные.
  • Когда у нас есть статическое содержимое, то есть HTML, JS, CSS, мы можем взаимодействовать с нашим локальным узлом Ethereum. то есть блокчейн (точнее, смарт-контракт, который был развернут в сети через его адрес контракта и контракты «аби».)
  • На изображении мы видим, что стрелка указывает от Ethereum к IPFS . Это объясняется просто. Мы можем сохранить хэш файла, который был опубликован в IPFS, в смарт-контракте. С помощью этой ссылки мы можем в любое время получить ее с помощью нашего узла IPFS.
  • IPFS NODE ----> REQUESTSс содержанием#
  • IPFS NODE <---- RECEIVESсоответствующий контент из сети
  • Новый блестящий файл контента теперь включен в DApp, чтобы пользователь мог играть с ним!

Полезная визуализация

У меня есть стандартное веб-приложение, которое позволяет пользователям загружать свои профили. Объем кода Java заключается в чтении данных через конечные точки и сохранении в базе данных. Сервер приложений также будет передавать статический контент пользователю, нажимающему определенный URL-адрес. Децентрализованная версия этого простого приложения будет выглядеть следующим образом:

  • Серверная часть Solidity для приема пользовательских данных в виде хэша (заменяет серверную часть Java). Изменение приложений "Глобальное состояние"
  • IPFS, на которой хранится веб-страница, будет обслуживать ее по запросу.
  • IPFS содержит больше данных, касающихся хэшей, хранящихся в смарт-контракте.

Большая часть логики в приложении перенесена во внешний код. Обратите внимание, что это вымышленное приложение, которое использовалось только в качестве примера.

Вот отличный пример подключения IPFS к контракту Solidity и выполнения запросов через консоль JS в вашем браузере.

Спасибо, я надеюсь, что это поможет!

Если мы рассмотрим DAPP = интерфейс + серверная часть
, то передняя часть (не в блокчейне) будет стандартным веб-интерфейсом, например, javascript (web3js) + HTML, используемая технология должна избавиться от RPC API, который взаимодействует с клиентом ethereum.
Бэкэнд = смарт -контракт (хранящийся в блокчейне), например, контракты на солидность, в которых вы определяете свою бизнес-логику (транзакции и т. д.) и помните, что смарт-контракт имеет свое хранилище (расположенное в блокчейне), где вы можете хранить данные своего приложения.
За исключением смарт-контрактов, все находится за пределами блокчейна.

Вот как я думал, что Эфириум работает, но у нас с коллегой были небольшие разногласия по поводу того, сколько хранится в Эфириуме. Смарт-контракты имеют смысл только для меня.
Может ли смарт-контракт быть интерфейсом в любом случае?
Какие элементы серверной части Dapp обычно хранятся в децентрализованном месте?
СпросиСетьПолитика конфиденциальности1y, 0v