Digamos que una máquina está ejecutando un cliente Ethereum (geth o Parity), y también tiene una aplicación web (que se ejecuta como un servidor NodeJS, por ejemplo) que proporciona un front-end a los usuarios y se comunica con el nodo Ethereum local mediante llamadas web3 desde dentro de su código Javascript. Si la aplicación web desea proporcionar una función para que los usuarios creen una cuenta en Ethereum, podría proporcionar un formulario para que el usuario lo haga e implementarlo llamando a web3.personal.newAccount(<password>), usando IPC en el nodo local de Ethereum. Sin embargo, las claves se generarían en el nodo Ethereum y tendrían que ser administradas por la aplicación web.
¿Hay otra forma de hacer esto de modo que el par de claves se genere en la máquina del usuario para que la clave privada permanezca exclusivamente con el usuario? Una forma podría ser usando MetaMask, que (he leído) es una extensión de Chrome que "inyecta web3" en el navegador. Eso haría posible generar claves en la máquina del usuario. MetaMask también sería necesario más adelante para que el usuario envíe transacciones firmadas porque la firma debe realizarse del lado del usuario. ¿Eso también significaría que la transacción firmada se enviaría directamente desde el navegador al nodo Ethereum mediante una llamada web3.eth.sendRawTransaction(...)( web3proporcionada por MetaMask) y no a través de la aplicación web como proxy?
Pero luego todo esto obligaría al usuario a utilizar el navegador Chrome y tener instalada la extensión MetaMask. ¿Hay alguna manera de eliminar esta limitación? ¿O es cierto que una aplicación web (es decir, que se ejecuta en un servidor centralizado) que permite a los usuarios remotos crear cuentas de Ethereum tiene que administrar las claves por sí misma?
La razón por la que existen navegadores web3 como MetaMask, Mist y Parity es porque abordan directamente el modelo de seguridad de la cadena de bloques: todas las transacciones se envían desde "cuentas externas", que están controladas por una clave privada.
Si su usuario no tiene un navegador que pueda administrar una clave privada, entonces se ve obligado a confiar en su sitio con su clave privada, volviendo a una arquitectura de seguridad mucho más "centralizada".
MetaMask convierte todas las llamadas "normales" (que esperan que se desbloquee el RPC actual) como sendTransaction, y las firma antes de reenviarlas al RPC como sendRawTransaction, por lo que tiene razón sobre cómo funciona.
MetaMask tiene un envío a Firefox en este momento, e incluso está trabajando con el navegador Brave para trabajar en él eventualmente, por lo que no siempre requerirá Chrome. Si no le importa instalar sus propias extensiones, varios navegadores ya tienen compilaciones disponibles .
También se habla de una versión de MetaMask que no requiere una extensión y, en cambio, se basa en una etiqueta de secuencia de comandos, pero que aún no está disponible para el desarrollo.