Arquitectura técnica de la aplicación Blockchain

Digamos que quiero crear una aplicación que no esté completamente descentralizada, de hecho, sirve API de Restful en la interfaz y usa una cadena de bloques ethereum privada en la parte de atrás para procesar datos confidenciales y administrar los permisos de los usuarios. Creo para cada usuario cuando se registra en mi backend una cuenta de ethereum usando su contraseña. El backend ejecuta NodeJS express y está conectado a la instancia web3. Cada vez que el usuario desea realizar una acción, debe ingresar su contraseña, luego uso esta contraseña para desbloquear su cuenta y enviar una transacción (o podría ser una llamada de contrato).

  1. ¿Tiene sentido actuar como un middleware entre el usuario y la cadena de bloques privada? Quiero decir, desde el punto de vista del diseño de ethereum, ¿es esta una práctica común? ¿Cómo debe el usuario ser consciente de esta práctica si no está viendo nada relacionado con blockchain porque todo el trabajo se realiza entre bastidores? ¿Cómo podría el usuario confiar en mi sistema de que su contraseña no se va a filtrar?

  2. ¿Se recomienda en tal caso usar múltiples nodos para esta cadena de bloques privada? ¿Qué beneficio trae consigo? ¿Es solo la alta disponibilidad y la eliminación del punto central de falla?

1. no, no lo hagas... confía en mí en este caso. 2. no, a menos que se asocie con varias entidades que hagan lo mismo, y todos lo hagan en una cadena de bloques común acordada.
@OWADVL ... ¿puede proporcionar un poco más de información sobre la respuesta a la primera pregunta?

Respuestas (2)

Antes de intentar responder a sus preguntas: hay ciertos beneficios para el uso de blockchain y ethereum en particular. Estos beneficios son:

  • La tecnología Blockchain ayuda a rastrear cosas, utilizando su exclusivo sistema de moneda y "tokens"
  • La tecnología Blockchain puede proporcionar una prueba indiscutible de la integridad de cualquier tipo de datos.
  • Los contratos inteligentes de Ethereum pueden proporcionar medios de transacciones transparentes entre entidades automatizadas. entidades que están reguladas por "Códigos de Leyes".
  • Los contratos inteligentes de Ethereum crean una especie de comerciante automatizado en todo tipo de bienes (una máquina expendedora para todo)

estos beneficios son los que necesita para implementar una plataforma basada en ethereum. Aparte de eso, ethereum se convertirá rápidamente en una responsabilidad y un punto débil en su sistema.

Tus preguntas :

1) En muchos grandes proyectos actuales y en la mayoría de los futuros, los nodos de Ethereum no serán visibles para el usuario de ninguna manera. Lo que construirá la confianza entre la plataforma (sistema) y el usuario será la promesa de transparencia y solidez. Una buena práctica es decirles explícitamente a sus usuarios que está administrando sus cuentas en su nombre y darles la posibilidad de optar por no participar y administrar sus cuentas y transacciones de Ethereum por sí mismos mientras se benefician de los servicios de su plataforma.

2) No son necesarios múltiples nodos en el caso de una red privada. Es posible que deba usar muchos nodos si la lógica detrás de su sistema requiere el intercambio real de decisiones entre esos nodos. Algo así como un nodo para cada país, o un nodo para cada partido. Tener muchos nodos también puede reducir la presión sobre su hardware y aumentar la capacidad y la tolerancia a fallas de su sistema.

Digamos que quiero hacer un sistema de fidelización de confianza para mis usuarios. ¿Debo crear un token ERC-20? O realmente no lo necesito ya que estoy administrando la lógica en el contrato inteligente.
Al decir que le da al usuario la opción de interactuar directamente con la cadena de bloques, ¿cómo puede ser esta una opción usando una aplicación móvil?
@abed Puede integrar un servicio similar a metamask para su aplicación móvil (si existen)
De hecho, hay un cliente geth de ios y android, aunque nunca lo probé.
@abed probablemente no sea un nodo completo, tal vez uno ligero. es difícil encajar un Geth en dispositivos móviles

Implementé una cadena de bloques privada con un sistema de back-end en nodejs que maneja algunos de los obstáculos, pero dejé que la cadena de bloques hiciera el mejor trabajo: dar confianza. Entonces, básicamente implementé una solución que funciona de manera opuesta a lo que describiste aquí.

En mi arquitectura, la clave privada de un usuario está en el cliente y los datos del usuario se registran en un servidor mongodb junto con la cuenta de usuario en ethereum. Cada vez que se solicita una transacción, el cliente la crea en la cadena de bloques utilizando la clave privada del usuario (en una aplicación móvil se almacena en el área de almacenamiento, en una aplicación web es administrada por MetaMask) y, si tiene éxito, registra la transacción en la base de datos con una referencia al hash de la transacción.

De esta forma, la verdad se mantiene en la cadena de bloques, nadie puede robar contraseñas y en la base de datos tienes datos que son demasiado caros para mantener en la cadena de bloques.

Entonces, ¿la clave privada del usuario se almacena en el dispositivo móvil y se envía a través de REST api a su servidor cada vez que el usuario desea enviar una transacción?
Absolutamente no. Tenemos una aplicación móvil que almacena la clave privada en el teléfono inteligente y crea la transacción en Blockchain sin usar el servidor backend. Una vez que se confirma la transacción en la cadena de bloques, la aplicación móvil envía algunos datos al servidor backend junto con el hash de la transacción.
Bien, eso suena genial, así que si la aplicación móvil se trata de una cadena de bloques privada, ¿involucra al usuario en el proceso de creación de la billetera? ¿Qué pasa si desinstala la aplicación y luego quiere volver a iniciar sesión? ¿Cómo puede restaurar la clave privada?
@abed Sí, durante el proceso de registro del usuario, la aplicación crea la clave privada. Luego, el usuario tiene que guardar la semilla de 12 palabras, imprimirla o guardarla en algún lugar (¿GDrive?). Para reducir el desorden, si tiene preguntas más específicas, envíeme un correo electrónico (dirección en el perfil)