Según tengo entendido, la arquitectura típica de una aplicación de Ethereum es tener un contrato inteligente que actúe como back-end de un front-end centralizado y sin estado que se ejecuta en un solo servidor.
¿No representa esto un riesgo de seguridad bastante evidente? Si la aplicación frontal es secuestrada, todas las acciones de los usuarios pueden desviarse hacia lo que quiera el atacante (es decir, en lugar de enviar ether a un contrato inteligente útil, se envía a la billetera del atacante).
¿Hay alguna forma de alojar una aplicación front-end de forma descentralizada?
De hecho, esto presenta un riesgo de seguridad evidente. En teoría, el usuario obtiene una vista previa de su transacción en MetaMask, etc. antes de enviarla, por lo que no tiene que confiar en la dapp, pero en la práctica, los datos de la vista previa son una dirección de contrato críptica y una masa inescrutable de datos hexadecimales, y el contexto de esos datos. - por ejemplo, qué gatito tiene qué identificación - proviene de la dapp, por lo que un front-end deshonesto podría engañar fácilmente a los usuarios para que envíen transacciones diferentes a las que pretendían.
Es probable que el problema se solucione entregando datos dirigidos por contenido desde IPFS o Swarm servidos por una extensión de navegador, y usando un contrato de nombres que impone un proceso de implementación, por ejemplo, colocar código para revisión antes de implementar, para controlar qué código se puede mostrar al usuario. usuario para un nombre de aplicación dado. Sin embargo, estos sistemas son difíciles de diseñar y aún no existe una solución práctica que los desarrolladores de dapp puedan implementar fácilmente.
Por lo general, el propósito de un front-end para un Ethereum DApp es proporcionar un método "bonito" para llamar a las funciones que están en el contrato inteligente cargado. Por supuesto, el pirata informático podría cambiar la dirección del contrato inteligente con el que interactúa el usuario (pero el usuario siempre puede ver a dónde van sus transacciones). Puede alojar un front-end descentralizado con IPFS https://ipfs.io
Lo bueno de usar un backend descentralizado y herramientas como EtherScan es que siempre podemos ver a dónde va nuestro Ether y a quién con relativa simplicidad.
Si la interfaz de usuario fuera manipulada y el pirata informático cambiara la dirección del contrato, el usuario podría ver que sus transacciones no van a la dirección que debería ser (piense en ello como si supiera la dirección de la calle de sus amigos, alguien ha robado su teléfono y le envía un mensaje para que vaya a una dirección diferente con la intención de robarle, tendrá cuidado de ir a esa dirección ya que nunca ha ido allí antes y no hay ninguna razón de por qué). También podrá ver la cantidad de transacciones que ha tenido el contrato (solo es útil si recientemente ha sido secuestrado). Creo que este es un problema algo menor y se puede resolver usando IPFS (sin embargo, puede ser lento).
Para dar una visión general de lo que el hacker tendría que hacer para obtener Ether maliciosamente de los usuarios, ellos también tendrían que hacerlo;
Sí, eso es correcto, por lo que puede alojar sus dapps en IPFS+IPNS (después de construir con algo como un paquete web).
La misma lógica es válida para los oráculos, son puntos de falla centralizados.
hoyo de jazz
hoyo de jazz
Edmundo Edgar