По мере того, как я все больше и больше узнаю о разработке Dapps, у меня возникают проблемы с пониманием того, что нужно хранить в смарт-контракте (в нашей базе данных и т. д.).
Возьмем простой сайт для ставок . То, как я представляю себе создание Dapp веб-сайта для ставок, будет следующим, и, пожалуйста, поправьте меня, если я ошибаюсь.
Используемая технология : Ruby on Rails (внутренняя часть), React (внешняя часть), Solidity (смарт-контракт).
1) Я бы сохранил в своей базе данных следующую информацию:
2) После создания пользователя я бы создал новый кошелек Ethereum с тем же паролем, что и его учетные данные, и сохранил публичный адрес его кошелька в базе данных.
3) Я бы сохранил в смарт-контракте :
В результате смарт-контракт будет содержать только информацию, связанную с транзакцией ставок (результаты ставок, сумма ставки), а база данных будет содержать все остальное. Чтобы получить историю ставок пользователя, я должен получить список из базы данных и получить результаты из смарт-контракта (связанного идентификатором ставки и пользователем).
Я совершенно неправильно понимаю концепцию Dapps/Smart Contract? Посоветуйте, спасибо!!
Во-первых, здорово, что вы узнаете больше о DApps, всегда приятно видеть, как растет сообщество. Однако у вас есть некоторое непонимание того, как должны быть разработаны DApps, поэтому я попытаюсь указать вам полезное направление.
Используемая технология: Ruby on Rails (внутренняя часть), React (внешняя часть), Solidity (смарт-контракт).
Как указано в этом ответе:
Серверный код DApp работает в децентрализованной одноранговой сети.
У DApps по определению нет классического бэкенда, как у RoR. Это означает, что для того, чтобы ваше приложение называлось DApp, смарт-контракты должны содержать всю вашу внутреннюю логику . На самом деле интерфейсом может быть любой JavaScript, наряду с библиотекой web3 , которая предоставляет вам API для связи с серверной частью смарт-контракта.
Это совершенно другая парадигма, которую я довольно долго не мог уложить в голове. Существуют децентрализованные альтернативы некоторым классическим технологиям, таким как IPFS или Swarm для хранения или размещения вашего веб-сайта DApp, «пользователи» должны быть привязаны к адресам блокчейна, вы можете использовать PouchDB и т. д. DApp должен быть полностью открытым исходным кодом. и автономный.
Если вы хотите создать DApp для ставок, вам действительно не нужно хранить информацию о пользователе в базе данных — вы можете запрограммировать интерфейс и, например, взаимодействовать через контракт, который отправляет % любой ставки в контракт под вашим контролем и имеет надежная бизнес-модель, предоставляя пользователям DApp хороший сервис. Но если вам нужна каждая ставка на блокчейн, транзакционные издержки иногда могут оказаться слишком высокими. Однако это не означает, что у вас не может быть гибридного приложения — настоящие DApp в их текущем состоянии имеют некоторые ограничения.
Работая над Lemon Email, нам пришлось взвесить некоторые преимущества устоявшихся технологий (например, SMTP-сервер) вместе с преимуществами децентрализованных приложений, поэтому мы решили создать DApp, чтобы он подходил всем. Мы использовали блокчейн Ethereum для хранения метаданных наших взаимодействий и IPFS в качестве хранилища. При желании вы можете подробнее прочитать о нашей архитектуре здесь .
Некоторое дополнительное чтение:
https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/
https://www.packtpub.com/big-data-and-business-intelligence/mastering-blockchain
Шариф2008