Retiro automático de Solidity Smart Contract (ETH)

Soy un poco nuevo en los contratos inteligentes, busqué mucho, pero espero que alguien aquí pueda ayudarme.

Trataré de explicar lo mejor que pueda. Estoy minando Ethereum con un par de plataformas.

Cada plataforma individual envía automáticamente el ETH a una dirección ETH específica a través del grupo. Así que ahora tengo varias direcciones ETH (más de 30) que reciben ETH. Muy frustrante verificar cada dirección y enviar el ETH a mi cuenta principal a mano.

¿Hay alguna manera de enviar automáticamente ETH desde cada cuenta a mi cuenta PRINCIPAL con un contrato inteligente (solidez)?

Digamos; La dirección 1 recibe 0,1 ETH, envío automático (inmediatamente después de que entra la transacción) 0,1 ETH a la dirección PRINCIPAL de ETH.

Las direcciones reciben diferentes cantidades de ETH, algunos 0.1 ETH, algunos 0.05 ETH, etc. No importa qué cantidad se envíe a la dirección de minería, debe transferirse a la cuenta principal.

Espero que alguien pueda ayudarme con esto.

Editar: Ejemplo

0x0000DIRECCIÓN1: 0.1ETH

0x0000DIRECCIÓN2: 0.3ETH

0x0000DIRECCIÓN3: 0.2ETH

0x0000DIRECCIÓN4: 0.1ETH

(Escriba un contrato inteligente para cada dirección anterior, cuando ETH esté en las direcciones anteriores, transfiera ETH a PRINCIPAL)

0x0000DIRECCIÓN PRINCIPAL: 0.7ETH

function () public payable { mainAccount.transfer(msg.value); }
Gracias @smarx por tus respuestas. Pero, ¿podría explicar un poco más lo que quiere decir con la línea anterior? Como dije, soy un poco nuevo en los contratos inteligentes.

Respuestas (2)

no funciona como parece pensar y eso hace que sea un poco desafiante responder directamente con algunos consejos que no conducirán a una larga curva de aprendizaje.

En Ethereum, tiene cuentas de propiedad externa (EOA) (carteras) y contratos, los cuales están representados por direcciones y apenas se distinguen en el lenguaje de contrato inteligente. Nunca sucede nada en la cadena a menos que alguien firme una transacción de un EOA. Los contratos ejecutan código cuando reciben un mensaje.

En particular, ningún EOA o contrato puede gastar dinero de la cuenta de otra persona. Los contratos reciben dinero y lo envían como una billetera. Entonces, realmente no podemos hacer un contrato que absorba el dinero de las direcciones. Podríamos, por el contrario, implementar contratos bajo el control de varias cuentas y las distintas cuentas podrían firmar transacciones para comenzar, pero ¿cómo abordaría eso su objetivo? ¿Ves el problema?

Su objetivo se puede lograr con un diseño Hub and Spoke razonablemente simple con los pagos del Pool destinados a contratos que son Spokes. Transmite todos los fondos recibidos a un Hub. Hub le permite a un usuario privilegiado (usted) retirar fondos, y Hub le permite generar nuevos Spokes, inspeccionar la lista de Spokes, etc.

Siento que el código de ejemplo podría estar llevándolo a un proyecto de complejidad inesperada porque tendría que acostumbrarse a algo un poco extraño en comparación con cómo funcionan las cosas actualmente.

Espero eso ayude.

Hola Rob, muchas gracias por tu información tan detallada. Esto explica muchas cosas. Ahora entiendo que ese no es el camino. ¿Existe la posibilidad de que pueda obtener una solución creando algún tipo de secuencia de comandos directamente en la plataforma de minería? Digamos que creo una secuencia de comandos que, cuando llega un pago, la secuencia de comandos firma automáticamente una transacción en mi principal. ¿cuenta? (sin el uso de un contrato inteligente quiero decir)
No es inviable. Probablemente podría preparar algo para que se ejecute periódicamente y verificar si la cuenta de coinbase tiene un saldo> 0 y reenviar los fondos. También podría considerar copiar las claves de la keystorecarpeta (si usa geth) y simplemente importar todas esas cuentas a una billetera en una estación de trabajo. Eso podría ser incluso mejor, sin código.

Entiendo que no podemos simplemente reenviar ethers recibidos en un contrato:

Para recibir éteres en un contrato, necesitará una función sin parámetros ni valor de retorno, es decir, una función alternativa marcada como pagadera. Pero (como indica la documentación http://solidity.readthedocs.io/en/v0.4.21/contracts.html ) cuando se envían éteres, dicha función de respaldo está limitada por 2300 unidades de gas, y la operación de envío de éteres solo consume más gasolina (ibid).

Así, los éteres enviados deberán permanecer en los contratos que los reciban. Necesitará un contrato de supervisión que contenga una lista de los contratos de recepción. Necesitará una función (como transferEthersUp()) en los contratos de recepción que transferirá ethers al contrato de supervisión. También necesitará una función en el contrato de supervisión (como collectEthers()) que iteraría todos los contratos de recepción y llamaría a la función transferEthersUp().

Para recolectar éteres, simplemente llame periódicamente a collectEthers().

Por supuesto, habrá que implementar algunas cuestiones de seguridad importantes: comprobar que solo el contrato de supervisión puede llamar a transferEthersUp(), comprobar que solo el propietario del contrato puede llamar a collectEthers().

Y desafortunadamente, este servicio de recolección le costará algo de gasolina adicional.