Contrato de venta colectiva y retiros seguros

De acuerdo con el contrato de crowdsale en https://www.ethereum.org/crowdsale , los tokens se transfieren a una cuenta de usuario cuando se llama a la "función () pagable" mediante el uso de la función externa tokenReward.transfer (msg.sender, cantidad/precio). Sin embargo, cuando el usuario reclama sus éteres en safeWithdrawal() porque no se ha alcanzado el objetivo de financiación, no se llama a la función externa tokenReward.transfer(), por lo que me parece que los tokens comprados no se retiran correctamente, aunque el éter se envía a el usuario.

¿Alguien ha usado este código para vender tokens y realizar un retiro como usuario? ¿El saldo del token en el contrato del token disminuye correctamente cuando se llama a safeWithdrawal? ¿Cómo es eso posible?

Referencias:

Contratos pre ico e ico crowdsale

¿Comprar tokens ICO?

Compra y venta de mis tokens

En el ejemplo de crowdsale, no entiendo la razón por la que se usa Ethereum Alarm Clock. ¿Alguien quiere explicar?

Respuestas (1)

¿Alguien ha usado este código para vender tokens y realizar un retiro como usuario?

En mi opinión, ese código es más un boceto de un ICO real y no pretende ser una implementación de referencia de ICO segura y adecuada. Tiene al menos un problema que se describe a continuación. Además, no conozco a nadie que use exactamente este código, la mayoría de las veces el límite superior (cap) parece ser más relevante que el límite inferior que se implementa aquí.

¿El saldo del token en el contrato del token disminuye correctamente cuando se llama a safeWithdrawal? ¿Cómo es eso posible?

Este contrato rastrea las contribuciones pagadas (en Wei) además del contrato de token por separado (consulte a continuación algunos problemas relacionados con esta implementación). Dentro de la safeWithdrawalfunción tienes la siguiente línea que se encarga de resetear la aportación pagada cuando no se ha llegado al límite de financiación:

balanceOf[msg.sender] = 0;

Este contrato de venta de tokens tiene como objetivo trabajar con cualquier token. Por lo tanto, la "destrucción" de los tokens reembolsados ​​tendría que manejarse caso por caso en ese contrato de token. Específicamente, usted como usuario primero tendría que llamar a la approvefunción de un token estándar y ahora el contrato aquí podría intentar quemar los tokens enviándolos a una dirección no prescindible (por ejemplo, 0x000...) o enviándoselos a sí mismo.

Su punto de que al reembolsar Ether, los tokens no se destruyen/reembolsan es correcto. Sin embargo, podría argumentar que estos tokens simplemente no tienen sentido si se ha reembolsado todo el Ether. Podría ir aún más lejos y decir que en realidad ahorra gasolina para cada inversor que quiere que se le reembolse su Ether; de todos modos, el token no tiene sentido si el proyecto no obtuvo ningún Ether, entonces, ¿por qué reasignar los saldos de los tokens?

Ahora para

La cuestión:

Este contrato de venta multitudinaria sobrescribe el Ether aportado por dirección en lugar de aumentar el saldo:

uint amount = msg.value;
balanceOf[msg.sender] = amount;

Este es un problema para los inversores que envían múltiples transacciones y luego perderían fondos en el período de reembolso. De hecho, todos los Ether, excepto los enviados en la última transacción, estarían bloqueados en el contrato inteligente para siempre.

Por lo tanto, sugeriría

Un arreglo:

uint amount = msg.value;
balanceOf[msg.sender] += amount;

Por supuesto, sería una buena práctica para una biblioteca como SafeMath en lugar de hacer un incremento simple.

Ahora ya no tiene que preocuparse por reembolsar o destruir Ether, cualquier inversor siempre puede simplemente recuperar su monto aportado si no se ha alcanzado el límite de financiación. Por supuesto, todos los titulares de tokens deben saber que, en ese caso, simplemente están involucrados en otro token de Ethereum totalmente inútil .