A medida que aprendo más y más sobre el desarrollo de Dapps, tengo problemas para entender qué debe almacenarse en el contrato inteligente (sobre nuestra base de datos, etc.).
Tomemos el caso de un simple sitio web de apuestas . La forma en que me imagino creando un Dapp de un sitio web de apuestas sería la siguiente y corrígeme si me equivoco.
Tecnología utilizada : Ruby on Rails (Back-End), React (Front-end), Solidity (Smart Contract)
1) Almacenaría en mi base de datos la siguiente información:
2) Al crear un usuario, crearía una nueva billetera Ethereum con la misma contraseña que sus credenciales y almacenaría la dirección pública de su billetera en la base de datos.
3) Yo almacenaría en el Smart Contract :
Como resultado, el contrato inteligente solo contendría información relacionada con una transacción de apuestas (resultados de apuestas, monto apostado) y la base de datos contendrá el resto. Para recuperar el historial de apuestas de un usuario, recuperaría la lista de la base de datos y recuperaría los resultados del contrato inteligente (vinculado por la ID de la apuesta y el usuario).
¿Estoy entendiendo completamente mal el concepto de contrato Dapps/Smart? Por favor asesóreme, gracias !!
En primer lugar, es genial que estés aprendiendo más sobre DApps, siempre es genial ver crecer a la comunidad. Sin embargo, tiene algunos malentendidos sobre la forma en que deben diseñarse las DApps, por lo que intentaré señalarle la dirección útil.
Tecnología utilizada: Ruby on Rails (Back-End), React (Front-end), Solidity (Smart Contract)
Como se señala en esta respuesta:
Una DApp tiene su código de back-end ejecutándose en una red descentralizada de igual a igual.
Las DApps, por definición, no tienen un backend clásico, como sería el RoR. Eso significa que, para que su aplicación se llame DApp, los contratos inteligentes deben contener toda su lógica de back -end . La interfaz podría ser cualquier JavaScript, en realidad, junto con la biblioteca web3 que le brinda las API para comunicarse con el backend del contrato inteligente.
Este es un paradigma completamente diferente, que tuve problemas para entender durante bastante tiempo. Existen alternativas descentralizadas para algunas de las tecnologías clásicas, como IPFS o Swarm para el almacenamiento o el alojamiento de su sitio web DApp, los "usuarios" deben estar vinculados a las direcciones de la cadena de bloques, puede usar PouchDB , etc. La DApp debe ser completamente de código abierto. y autónomo.
Si desea crear la DApp de apuestas, realmente no necesita almacenar la información del usuario en la base de datos; puede programar la interfaz y, por ejemplo, interactuar a través del contrato que envía el % de cualquier apuesta a contratar bajo su control y tener modelo de negocio sólido al tiempo que brinda un buen servicio a los usuarios de DApp. Pero si desea cada apuesta en blockchain, los costos de transacción a veces serían demasiado altos. Sin embargo, esto no significa que no pueda tener una aplicación híbrida: las verdaderas DApps en su estado actual tienen algunas limitaciones.
Al trabajar en Lemon Email, tuvimos que sopesar algunos de los beneficios de las tecnologías establecidas (servidor SMTP, por ejemplo) junto con los beneficios de las aplicaciones descentralizadas, por lo que decidimos crear la DApp para todos. Usamos Ethereum Blockchain para almacenar metadatos de nuestras interacciones e IPFS como nuestro almacenamiento. Si lo desea, puede leer más sobre nuestra arquitectura aquí .
Algunas lecturas adicionales:
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
sharif2008