Generación de múltiples direcciones de depósito para una cuenta

Quiero crear algo como un intercambio de criptomonedas, en el que necesito generar diferentes direcciones de depósito únicas para cada usuario, para que puedan enviar fondos a sus cuentas mientras yo puedo hacer un seguimiento de cuánto depositó cada usuario. Esto es bastante fácil en otras criptomonedas como bitcoin. Sin embargo, parece que esto es imposible en Ethereum (o tal vez me equivoque).

El principal problema aquí es que si genero varias claves privadas, o uso una billetera HD y manejo varias claves privadas desde ella, los fondos enviados a la muerte de estas billeteras deben firmarse con diferentes claves para gastar, por lo tanto, tengo que pagar. una gran cantidad de tarifa de transacción (una vez por cuenta) si trato de enviar todos los fondos a una billetera grande para mantenimiento.

Entonces, me preguntaba si puedo generar múltiples direcciones de depósito, todas correspondientes a una cuenta en Ethereum para que cada usuario pueda enviar fondos a una dirección diferente, por lo tanto, puedo rastrear qué usuario envió cuánto y cuándo quiero gastar estos fondos, puedo firmar la transacción con una clave privada y pagar la tarifa de transacción solo una vez (gastar todos los éteres juntos)? Y si es totalmente imposible tener varias direcciones de depósito correspondientes a una cuenta, ¿qué puedo hacer?


PD: He visto varias preguntas como esta en este StackExchange, pero ninguna de las respuestas respondió realmente a mi pregunta. Por lo tanto, dude antes de marcar esto como un duplicado.

PS2: No estoy buscando una solución usando contratos inteligentes, porque eso requeriría que mis usuarios depositaran usando billeteras especiales que admitan web3 como metamask, estoy más interesado en saber cómo manejan esto otros intercambios como Binance, para que los usuarios puedan depositar desde cualquier tipo de billetera!!!!

Respuestas (1)

Está tratando de aplicar un modelo que sea apropiado para Bitcoin principalmente debido a sus limitaciones. Será una estrategia incómoda para Ethereum que pasa por alto sus puntos fuertes.

Bitcoin: no es especialmente programable, pero es fácil de transferir fondos de varias cuentas. Ethereum: especialmente programable, pero no tan fácil de extraer fondos de varias cuentas.

Ethereum también tiene consideraciones de seguridad únicas y es importante confirmar que su cliente tiene todas las capacidades que su contrato asume que tiene, como la capacidad de realizar una transacción y firmar una solicitud de retiro. Ese NO es el caso si están enviando desde otro intercambio, por lo que debe evitarlo. Probablemente necesite registrarse/KYC en cualquier caso, así que confirme que tienen el control total de las cuentas que usarán y luego informen al contrato que están "aprobados" para enviar dinero.

  1. Puede usar una sola cuenta de depósito: todo el dinero junto, por lo que no es necesario barrer.
  2. Puede saber quién lo envió y emitir eventos, registrarlo, etc., todos los requisitos contables.
  3. Es programable, pase lo que pase a continuación.

Debe confirmar que sus usuarios pueden firmar una transacción. Esto garantizará que puedan trabajar con cualquier interfaz de contrato que les muestre en el futuro .

  1. Pídeles que firmen un mensaje y te lo envíen, fuera de la cadena (gratis). Confirme su dirección con ecrecover.
  2. Ahora ya sabes quién es quién. No de donde llegó el dinero. Por donde vino. No hay motivo para que un usuario no pueda confirmar varias cuentas (paso 1), pero no es aconsejable aceptar fondos de remitentes desconocidos.

Para abreviar, omitiré la función de retiro porque probablemente transferirá los fondos a las cuentas operativas tan pronto como se reciban y es posible que tenga un contrato completamente diferente en el que envíe fondos para retirarlos o enviarlos al usuario en función de un sitio web. interacción del sitio.

Esto no se presenta como un contrato de producción listo para la batalla, sino más bien como un ejemplo simple para mostrar el enfoque.

pragma solidity 0.5.16;

contract Deposit {

    address payable public wallet;

    mapping(address => bool) public approved;

    event LogApproved(address approver, address approved);
    event LogDeposit(address sender, uint amount);

    function authorize(address allowed) public {
        require(msg.sender == wallet, "Only the owner can do this, e.g. from their admin server.");
        emit LogApproved(msg.sender, allowed);
        approved[allowed] = true;
    }

    function deposit() public payable {
        require(approved[msg.sender], "Unauthorized sender. Please register.");
        emit LogDeposit(msg.sender, msg.value);  // <=== there's your accounting
        wallet.transfer(msg.value);
    }
}

La preocupación contable se inmortaliza en la cadena de bloques y un cliente externo, por ejemplo, nodejs, puede inspeccionarla. El dinero va a tu walletcuenta y puedes continuar desde allí.

Espero eso ayude.

Gracias por su respuesta detallada. aunque parece un buen enfoque, creo que los intercambios de cifrado como Binance no usan este enfoque. ya que enviar ether a Binance es como enviarle BTC. Entonces, en realidad me preguntaba cómo resuelven este problema para el éter.
Ciertamente puede hacerlo 1) generando una cuenta, 2) vigilando el dinero y 3) enviando el dinero hacia adelante. El servidor tendrá las claves de firma de las cuentas que cree. El servidor enviará desde "mi cuenta", saldo de cuenta y pago de gasolina.
@Rob Hitchens. El último enfoque que describiste se adapta a mis necesidades. Sin embargo, veo un problema, el envío cuesta gasolina. Funciona cuando se envía ETH a direcciones de depósito. ¿Qué sucede si se envía el token ERC20 y la dirección de depósito no tiene ETH para pagar con gasolina por el reenvío?