Arquitectura típica de una Dapp con un cliente de navegador

Estoy tratando de entender la arquitectura típica de un Dapp con clientes de navegador. ¿Es correcto el siguiente entendimiento?

[Navegador web (usuario final)] <==> [Servidor (aplicación web/javascript <==> web3 <==> cliente ethereum como geth)] <==> [Red Ethereum (código de solidez)]

Oye, básicamente tienes razón. ¿Podría ayudarme a entender lo que quiere decir con el cliente ethereum?
Hola Borinho, cliente de ethereum como geth, eth, pyethapp, etc. que pueden comunicarse con contratos inteligentes en la red de ethereum.

Respuestas (2)

No estoy seguro de si está describiendo el flujo de datos en lugar de la arquitectura real del sistema, pero si es así, no es del todo correcto.

Descripción general de las aplicaciones descentralizadas:

Alex Van de Sande escribió un excelente artículo sobre la creación de aplicaciones sin servidor y en él contrasta la distinción entre una compilación centralizada y una compilación descentralizada.

https://blog.ethereum.org/2016/07/12/build-server-less-applications-mist/

Estructura centralizada tradicionalingrese la descripción de la imagen aquí

Estructura Descentralizada de Nueva Generacióningrese la descripción de la imagen aquí

El artículo habla mucho sobre Mist, pero esto fue cuando Mist realmente era lo único que se mostraba en la ciudad. Ahora tenemos Parity e incluso MetaMask que permiten a los usuarios acceder a web3.js y una conexión a una billetera Ethereum y, lo que es más importante, la capacidad de usar la billetera Ethereum para firmar transacciones en la red/cadena de bloques Ethereum.

Teniendo en cuenta tu ejemplo:

[Navegador web (usuario final)] <==> [Servidor (aplicación web/javascript <==> web3 <==> cliente ethereum)] <==> [Red Ethereum (código de solidez)]

El cliente Ethereum no suele estar del lado del servidor, hay excepciones como el caso de usar algo como MetaMask, pero en ese caso usarías MetaMasks del lado del servidor y no el tuyo. El cliente Ethereum sería parte del navegador web. Además, el cliente es lo que se comunica con la red Ethereum, no su servidor. Entonces, su estructura / relación debería dividirse en dos partes y parecerse más a:

Descargando el HTML y JS:

[Navegador web (usuario final <==> cliente Ethereum) ] <==> [Servidor (aplicación web/JavaJcript <==> web3) ]

Interactuando con la cadena de bloques:

[Navegador web (usuario final <==> cliente Ethereum) ] <==> [Red Ethereum (código de solidez) ]

Arriba hay una buena respuesta. Solo para que no parezca que los nodos del lado del servidor son terriblemente inusuales (nodejs, python, etc.), señalaría una pregunta similar aquí: ethereum.stackexchange.com/questions/11624/…
En realidad, por cliente de ethereum, quise decir geth/eth/pyethapp. Los usuarios finales son el público en general que simplemente escribe www.xyz.com en el navegador para acceder a la aplicación (dapp). ¡No podemos esperar que tengan todo el geth instalado en su computadora portátil! Debe haber una aplicación web en un servidor con javascript del lado del servidor (node.js), web3 y geth para ayudar a la aplicación web a conectarse a la red ethereum.
Por interés, ¿cómo administran sus usuarios sus claves Ethereum?
Hola Samyoul - Todavía no he ido hasta allí. Solo estoy tratando de entender cómo un contrato inteligente/dapp puede tener un cliente web. Por ejemplo, cuando visito etherscan.io , se comunica con la red ethereum (que tiene contratos inteligentes) para mostrar los datos que muestra. ¿Cómo lo hace? ¿El js en mi navegador local se conecta directamente a la red etheruem? No me parece. Lo que entiendo es que solo se puede acceder a la red ethereum a través de componentes como web3 (o similar) y geth (o similar) y no tengo ninguno de estos en mi computadora portátil. Entonces, ¿dónde están estos? ¿En algún lugar entremedio?
Depende de su caso de uso. ¿Quieres que tus usuarios interactúen con los contratos? Si es así, los usuarios necesitarán una forma segura de firmar sus transacciones. Un cliente Ethereum puramente del lado del servidor significará que los usuarios no podrán hacer esto, a menos que cree un servicio adicional que funcione como MetaMask.
Exactamente. Ese es el caso de uso del que estoy hablando. Los usuarios deberían poder interactuar con los contratos inteligentes en la cadena de bloques. (sí, la firma de transacciones puede ocurrir a través de un servicio). Entonces, el punto que quiero confirmar es que cualquier "componente" que intente interactuar con la red ethereum necesitará un web3 (o similar) + geth (o similar). Y ese "componente" puede ser cualquier cosa: aplicación de escritorio (como carteras) o código de servidor de una aplicación web (como carteras web y etherscan.io y solidez del navegador). Espero que mi comprensión esté en la dirección correcta.

@Ashish: su hipótesis es correcta, pero incompleta. Si bien esa es una forma común , de ninguna manera es la forma común ; hay múltiples patrones aceptables y dependen del caso de uso designado.

Este artículo examina los patrones arquitectónicos de Ethereum actuales más populares y proporciona un caso de uso para cada uno: https://blog.zeppelin.solutions/designing-the-architecture-for-your-ethereum-application-9cec086f8317 .

Arquitectura típica de una Dapp con un cliente de navegador
RespuestasAquíPolítica de privacidad1y, 0v