Estoy tratando de encontrar la mejor solución para integrar los pagos basados en Ethereum en la aplicación web y busco el consejo de alguien que ya haya enfrentado esta tarea.
Mi caso: Solución de juegos de azar en línea donde los usuarios pueden depositar dinero en su cuenta y hacer apuestas.
Requisitos: los pagos deben basarse en Ethereum, es decir, los usuarios transfieren ETH y obtienen algo de dinero del juego (tokens) o ven su saldo directamente en ETH.
Soluciones que estoy viendo y sus problemas:
1) El usuario transfiere ETH a la dirección del propietario de la aplicación y obtiene tokens (agregamos tokens al usuario en la base de datos de la aplicación). Esto no me parece una buena solución porque no es fácil identificar qué usuario realizó la transferencia de dinero. Para hacer esto, debemos almacenar las direcciones de los usuarios en la base de datos de la aplicación y analizar las transacciones de la dirección del propietario de la aplicación.
2) Cree algo similar al contrato Token. En este caso, el usuario podrá transferir ETH a alguna dirección y obtener tokens (almacenados en la cadena de bloques).
Problema: identificar al usuario: nuevamente no es tan fácil (el mismo problema descrito anteriormente).
Sé que es posible usar MetaMask, en este caso no es necesaria la identificación del usuario, pero en este caso la lógica del juego debe colocarse en un contrato inteligente. Usar MetaMask y una aplicación completamente descentralizada no es aceptable, será demasiado costoso. En primer lugar, debido a que los juegos son muy dinámicos con muchos cambios de estado (juego en curso, dinero en el juego, etc.), se necesitará mucha gasolina. En segundo lugar, las acciones dependen del estado, por lo que los cambios de estado deben estar disponibles momentáneamente, no es aceptable esperar mientras se extrae la transacción.
3) Cree una nueva dirección de ethereum para cada usuario registrado (guarde las claves privadas en la base de datos). En este caso, se requerirá alguna lógica de sincronización en el backend de la aplicación (ETH a moneda interna [tokens en la base de datos de la aplicación]).
Por ejemplo, el usuario transfiere ETH a la dirección creada, luego ingresa a la aplicación y hace clic en el botón 'Sincronizar', luego la aplicación verifica la cantidad de ETH creados para la dirección del usuario, transfiere estos ETH a la dirección del propietario de la aplicación y agrega tokens (moneda interna) para esto usuario en la base de datos de la aplicación.
4) Cree un contrato inteligente por el cual los usuarios podrán transferir ETH con datos adicionales (algún identificador único). En este caso, también se requiere una lógica de sincronización complicada.
Ejemplo: cuando el usuario quiere obtener tokens (moneda interna), la aplicación le proporciona la dirección del contrato y el identificador único generado y guarda este identificador en la base de datos de la aplicación (uno a muchos usuarios/identificadores). El usuario transfiere ETH a la dirección del contrato proporcionada y agrega datos adicionales (identificador único generado), el contrato guarda cuántos ETH se transfirieron usando este identificador único, el backend de la aplicación usa esta información para agregar tokens (moneda interna) en la base de datos de la aplicación [llamada de funciones que no 't cambiar el estado son gratis].
En cuanto a mí, las opciones 3 y 4 parecen más aceptables, pero no estoy seguro de que mis pensamientos sean correctos, porque soy el más nuevo en el desarrollo de blockchain. Quizás haya soluciones mejores y más correctas.
a) ¿Comprendo correctamente los flujos descritos?
b) ¿Existen soluciones mejores o más correctas para mi caso?
c) ¿Qué solución debo elegir?
Antes de continuar... Debe comprender qué es una billetera activa y qué es una billetera fría, y cómo usarlas y mantenerlas seguras. Es increíblemente fácil operar sitios como estos y perder el dinero de todos e ir a la cárcel por mucho tiempo. Si no confía en su conocimiento de estos conceptos criptográficos, deje de leer, investigue un poco más y vuelva aquí más tarde.
Entonces... para responder a tu pregunta real... En realidad hay mucho en juego aquí...
1) El valor propuesto de permitir que los usuarios conozcan su empresa es líquido. Puede pensar que los usuarios se preocupan por esto, pero los intercambios de criptomonedas y otros sitios de apuestas de bitcoin generalmente optan por la solución propuesta n. ° 1 porque, al final, lo único que los usuarios realmente quieren hacer es comerciar / apostar. # 1 reduce las tarifas de blockchain, siempre que opere su billetera de manera eficiente, lo que me lleva al siguiente punto...
2) El costo propuesto de operar su billetera de manera eficiente. Realmente, podría ejecutar esta billetera de cualquier manera y probablemente esté bien, pero la forma más eficiente de operar esta billetera sería usar algoritmos que efectivamente tomen las monedas restantes en cada entrada/salida, minimizando el polvo. Puede que no sea una mala idea mantener todas sus monedas en unas pocas direcciones (una dirección sería la más barata, pero varias aumentan la seguridad). El "costo" aquí es la investigación y/o el desarrollo para encontrar el software de billetera Ethereum existente para manejar correctamente las entradas y salidas de transacciones, minimizando las tarifas y el polvo.
3) El valor propuesto en la operación de su billetera de forma anónima. Enviar dinero de ida y vuelta entre diferentes direcciones de ethereum puede ayudar a aumentar el anonimato con respecto a su sitio. Tenga en cuenta esto en contraste directo con el n. ° 1. Si la aplicación de la ley puede estar molestándote, querrás hacer algún tipo de CoinJoin o un servicio ethereum similar.
No recomendaría agregar un contrato inteligente a la ecuación. Hay algunos sitios muy exitosos como estos que no usan ninguna característica especial de Ethereum. Si desea utilizar funciones especiales de Ethereum, integre su sitio con algo como Augur o Gnosis .