Me pregunto si hay casos de ejemplo en los que tendría sentido usar una aplicación cliente-servidor típica de Node.js donde el nodo de cadena de bloques se ejecutaría en el servidor. A primera vista, esto traería de vuelta los problemas de centralización relacionados con la confianza en el servidor si es el propio servidor el que ejecuta el nodo. Sin embargo, me preguntaba si hay casos reales en los que esto sería apropiado (aquí hay preguntas de personas que parecen estar haciendo esto, esto , esto , por ejemplo).
Para mayor aclaración: leí esta publicación que afirma que aún no se han recopilado las herramientas necesarias para el desarrollo de Dapp. Como tal, me preguntaba si pensaba en alternativas que aún pudieran aprovechar las características de confiabilidad de la cadena de bloques, etc., pero ejecutándose en un marco cliente-servidor.
Creo que la respuesta de @JohnAllen no tiene sentido para mí. La práctica más común es precisamente que la interfaz de usuario frontal de una DApp se implemente como una aplicación NodeJS que utiliza la biblioteca Web3 Javascript para comunicarse con un nodo Ethereum que se ejecuta localmente, es decir, en el mismo servidor que la aplicación NodeJS.
Aquí, el servidor NodeJS no está ejecutando el nodo Ethereum. (Tenga cuidado de diferenciar entre los dos usos del término "nodo" aquí) Tanto el nodo Ethereum (que podría ser geth, Parity, pyethapp o cualquier otro software de cliente Ethereum) como la aplicación NodeJS se ejecutan en la misma máquina. El nodo Ethereum es un cliente de la cadena de bloques Ethereum con la que está sincronizado. La aplicación NodeJS que se comunica con un nodo Ethereum que se ejecuta localmente, de hecho, reduce la centralización, porque las diferentes aplicaciones no necesitan confiar en ningún nodo Ethereum remoto en particular. Además, las cuentas siempre se crean en un nodo local porque las claves privadas generadas deben permanecer en la máquina local. Los comandos para crear y administrar cuentas están en elweb3.eth.personalinterfaz que, de forma predeterminada, solo está habilitada a través de IPC (comunicación entre procesos), es decir, solo se puede ejecutar en un nodo Ethereum local.
ADICIÓN : Si la interfaz frontal de una DApp es atendida por una aplicación NodeJS que se ejecuta en un servidor en particular, introduce algo de centralización. Sin embargo, siempre que la DApp aún pueda mantener el estado de su modelo (usando "modelo" en el sentido de MVC) incluso si el servidor NodeJS se cae, y si alguien más pudiera alojar la aplicación NodeJS, restaurando así la "vista" de MVC y proporcionando acceso al back-end (código de contrato desplegado en la cadena de bloques), entonces se minimiza la desventaja de la centralización. Entonces, mi punto es que la centralización/descentralización no es una clasificación de blanco o negro. Cualquier aplicación se encuentra en algún lugar de un espectro. Una DApp podríahacer que su interfaz de usuario también se sirva de forma descentralizada, por ejemplo, he oído que Swarm e IPFS sugirieron esto, pero no conozco más detalles sobre cómo se haría. Todo depende del caso particular y de cuánta descentralización se necesita realmente.
Esto en su mayoría no tiene sentido para mí, he aquí por qué:
dónde se ejecutaría el nodo blockchain en el servidor
La definición de a blockchain nodees uno de los muchos miles de nodos de Ethereum que almacenan los datos de la cadena de bloques y, a menudo, responden a solicitudes sobre esos datos.
Entonces, cuando tiene una arquitectura con Ethereum nodeun Node.jsservidor y un cliente, ¿qué haría el servidor Node.js?
Por lo general Node.js, se usa para responder a solicitudes del lado del servidor, ejecutar lógica y consultar una base de datos centralizada; pero con Dapps, la cadena de bloques y web3(que es una biblioteca de servidor o cliente) consultan los datos de la cadena de bloques y un nodo Ethereum responde con los datos solicitados que luego se devuelven al cliente.
Usted menciona el almacenamiento de datos Node.jsen un comentario. Otra opción es almacenar los datos de forma centralizada o IPFS. Puede almacenar un hash simple o CID (identificador de contenido) en la cadena y los datos a los que apunta el hash en una base de datos centralizada, consultar los hash que están almacenados en la cadena (que tiene el contenido codificado en el hash), consultar sus datos por hash, ejecute la misma función hash en los datos consultados para verificar que sean los mismos y luego devuelva esos datos a su cliente.
rehashingel contenido para que los usuarios puedan verificar que el contenido es el mismo.if the server is the one running the node<- ¿Quiere decir que si el geth nodeservidor y el servidor Node.js se ejecutan en la misma máquina, el hash podría verse comprometido en la forma en que se almacena en la cadena? Probablemente ese sea el caso, pero básicamente todo podría verse comprometido. Solo recuerda el Node.jsservidor y geth nodeson dos cosas muy separadas y diferentes.En un mundo descentralizado, tiene mucho sentido tener nodos de blockchain en todo tipo de lugares. A veces, su cliente tendrá acceso a uno, a veces no. Con suerte, lo harán cada vez con más frecuencia, pero mientras esperamos clientes más ligeros y redes más escalables, es muy válido considerar los momentos en los que también podría querer ejecutar un cliente de cadena de bloques en un servidor.
Realmente, los clientes de blockchain del lado del cliente solo tienen sentido cuando el usuario es un humano con un navegador web. En cualquier transacción de máquina a máquina, un proceso de NodeJS tendría más sentido.
Además, aunque Web3 es muy conveniente porque la API ya puede existir en el navegador del usuario, está lejos de ser una API de búsqueda óptima. Puede ejecutar un nodo del lado del servidor solo para indexar información relevante para su aplicación, de modo que pueda servirla a los usuarios más rápido.
En cuanto a la firma, definitivamente creo que es más seguro dejar las claves en manos del usuario, pero no es descabellado esperar que algunos servicios firmen en nombre de los usuarios, desde un proceso del lado del servidor.
Un cliente de cadena de bloques es solo un software que permite que otro contexto acceda a la cadena de bloques. No hay nada al respecto que lo fuerce a un contexto u otro, y si la web descentralizada realmente despega y ofrece escalabilidad y rendimiento, creo que la pregunta más difícil de responder será: "¿En qué contexto NO querrías un cliente de cadena de bloques?" ¿en?"
Me preguntaba si pensaba en alternativas que aún pudieran aprovechar las características de confiabilidad de la cadena de bloques, etc., pero ejecutándose en un marco cliente-servidor.
Puede crear aplicaciones web híbridas que utilicen Python/Node/lo que sea como un servidor back-end centralizado para algunas tareas y hacer uso de la cadena de bloques para otras tareas.
Un ejemplo demasiado simplificado para dapps híbridas sería una dapp para hipotecar un token ERC20 a cambio de ETH. Ahora, el prestamista y el prestatario desean negociar las tasas de interés y la duración del préstamo. El prestatario también quiere saber si alguien está dispuesto a ofrecerle mejores tasas. Este proceso de descubrimiento puede ocurrir a través de un servicio centralizado sin tener que gastar ETH en gasolina para cada mensaje. Podría haber un grado de censura en este punto en el que los prestamistas que ofrecen tasas más bajas no se le muestran por alguna razón, pero usted no ha asumido ningún riesgo y aún puede retirarse del proceso.
Una vez que se completa la negociación, tanto el prestamista como el prestatario pueden simplemente hacer clic en un botón en la página web y crear un contrato inteligente en la cadena de bloques que tiene información sobre todos los términos de la hipoteca y se comportará en consecuencia. En este punto, no tiene que confiar en el sitio web centralizado o en el prestamista para mantener segura su garantía, ya que estaría bloqueada en un contrato.
Entonces, está sacrificando la falta de confianza por la velocidad y el costo en un paso y haciendo uso de la falta de confianza por seguridad en otro paso.
Por supuesto. Por ejemplo, imagine que tiene una tienda de comercio electrónico (por ejemplo, venta de teléfonos inteligentes) escrita en node.js. Le gustaría tenerlo conectado a blockchain para controlar, por ejemplo, los pagos. Por lo tanto, los clientes pagarán en su dirección a través de Metamask o Mist y el backend de su tienda se conectará al nodo Ethereum (que podría estar en el mismo servidor) para verificar que el pago se haya realizado y continuar con el pedido.
En este caso de uso, el servidor con el nodo ethereum no es una forma de centralizar la aplicación, es solo una forma de acceder a contratos/cuentas inteligentes por parte del sistema informático, no del ser humano en sí.
mcansado
const web3 = new Web3(new Web3.providers.HttpProvider(provider));siempre estaría en el código del lado del cliente y nunca en el código del lado del servidor? ¿Es esto correcto?Juan Allen
Ajoy Bhatia
Ajoy Bhatia
web3objeto también podría estar en el código del lado del cliente o del lado del servidor, en referencia a la adición a mi respuesta. Esos serían diferentes niveles de centralización. Creo que, si está ejecutando el navegador Mist, entonces elweb3objeto está solo en el lado del cliente.desvalido
Ajoy Bhatia