Por ejemplo, un sitio web que dará la opción de registrar una cuenta de ethereum. El usuario presionaría el botón de registro y el servidor, que asumo está ejecutando un nodo las 24 horas del día, los 7 días de la semana y generará una cuenta a través de web3.eth.personal.newAccount. Luego, el servidor devuelve la clave pública y privada de esta cuenta al usuario.
Ahora el sitio web también tiene la opción de permitir a los usuarios implementar un contrato inteligente. Para hacer esto, asumo que enviarían su clave pública/clave privada y el servidor la usará para implementar el contrato desde la cuenta de los usuarios después de desbloquearlo.
Pero esta cuenta tendría 0 ether ya que el usuario no está minando con ella porque ni siquiera tiene un nodo ethereum. Otra solución podría ser que el servidor tenga una cuenta que contenga ether ya que el servidor está minando. Luego, el servidor implementa todos los contratos de esta cuenta en nombre de los otros usuarios, pero los declara como propietarios del contrato de alguna manera.
¿Alguien podría aclarar qué enfoque se toma para implementar un sitio web de este tipo?
Lo más probable es que el flujo de trabajo que mencionó no sea óptimo por motivos de seguridad.
En tono rimbombante:
Ningún usuario debe confiar en un servicio que genera claves en su servidor centralizado
Afortunadamente, puede incluir la biblioteca web3 en el navegador web, para que sus usuarios puedan generar y almacenar claves allí. Nuevamente NOTA: Existen varias mejores prácticas y procedimientos para hacer esto de manera segura.
Como mencionó, este Ethereum accountno tendrá fondos disponibles para publicar transacciones (o contratos inteligentes en la red Ethereum). La transferencia de fondos a esta nueva cuenta es un flujo separado y requeriría que el usuario obtenga ETH de algún lugar (su servicio podría proporcionar una pequeña cantidad de ETH a la cuenta en el momento de la creación).
Su segundo escenario de ofrecer un "servicio gratuito de publicación de contratos inteligentes" es posible, pero presenta nuevos desafíos: evitar que los usuarios exploten su servicio y asegurarse de que todos los contratos implementados sean de sus usuarios y no solo la clave que está publicando en la cadena de bloques ownable. con.
Flujo concebible:
Idealmente, por motivos de seguridad, crearía o respaldaría una billetera de usuario o clientcomo una aplicación o en un navegador que permitiría a los usuarios administrar claves.
En segundo lugar, los usuarios deberían obtener su propio ETH (o la gente intentará explotar su servicio ETH gratuito).
En tercer lugar, después de que sus usuarios tengan claves y ETH, su software de cliente puede generar y firmar un código de contrato inteligente para los usuarios.
Por último, después de que se firmen los contratos (por las claves de los usuarios, con fondos disponibles), su servicio puede publicarlos en la red Ethereum (por ejemplo).