He visto este fragmento en muchos ejemplos en línea. ¿Podría explicar qué está haciendo y por qué lo usamos en una función de pago?
function () public payable {
revert () ;
}
La función sin nombre: function ()se llama función de reserva . Se ejecuta cuando el contrato recibe algo de ETH sin que se llame explícitamente a una función.
Ponerlo revert();significa que no puede enviar ETH al contrato sin llamar explícitamente a una función de pago.
Creo que este patrón no es necesario en versiones de Solidity tan antiguas como la 0.4.0 (lanzada en septiembre de 2016). De https://github.com/ethereum/solidity/blob/develop/Changelog.md#040-2016-09-08 (mi énfasis):
Los contratos que desean recibir Ether con un simple "envío" deben implementar una función de respaldo con el modificador pagadero. Los contratos ahora se lanzan si no se define una función de respaldo pagable y ninguna función coincide con la firma.
Creo que function () payable { revert(); }fue un patrón utilizado para evitar la aceptación implícita de ether en versiones de Solidity anteriores a la 0.4.0, pero hoy en día esto no es necesario. Me imagino que la práctica se ha llevado adelante en gran parte mediante copiar y pegar.
La función anterior básicamente evitará que las cuentas transfieran directamente ether al contrato.
La función anterior es lo que se llama la función Fallback en solidez. Si alguien envía una transacción al contrato inteligente sin especificar un nombre de función (o el nombre de la función llamada no coincide con ninguna función existente), se llamará a esa función alternativa.
Entonces, si alguien hiciera, contract.transfer(someValue);la función de respaldo se ejecutaría, pero dado que todo lo que hace es revertir (), la llamada a la función falla y el gas no gastado y el éter enviado se devuelven a la persona que llama.
Querría hacer esto para evitar que las personas envíen ether a su contrato por error.
Como nota al margen: Esta función exacta también puede ser utilizada por un contrato malicioso para atacar algunos contratos como en el caso King Of Ether: https://www.kingoftheether.com/postmortem.html#Causes
En ese momento el problema fue causado por no limitar los estipendios de gasolina, pero con la lógica original (que no usa un patrón de retiro) alguien puede codificar un contrato que envía éter para convertirse en el rey y luego cuando este contrato es destronado y el El contrato de KoE quiere enviar ether de vuelta al contrato, siempre fallará y retrocederá debido a que la función de respaldo rechaza cualquier transacción entrante con la llamada revert().
usuario19510