PREGUNTA:
¿Vale la pena tener eventos en tu token? Cada transacción generalmente tiene el evento dentro, lo que significa que se gasta más gasolina para los usuarios (lo cual es malo). No tengo una imagen completa de todos los buenos eventos que aportan a la imagen, por lo que es difícil para mí decidir si incluirlos en los tokens que codifico.
ELABORANDO:
Después de mucho investigar, llegué a comprender que los eventos (como los del estándar de token ERC-20) son solo registros que brindan una forma más fácil para que las aplicaciones verifiquen lo que sucede con su token, pero no brindan ninguna funcionalidad. en términos de hacer que el token funcione. Por ejemplo, aquí hay un subconjunto de código del estándar de token ERC-20 :
function transfer(address _to, uint _value) returns (bool success);
event Transfer(address indexed _from, address indexed _to, uint _value);
La primera línea es la declaración de la función de transferencia , mientras que la segunda es la declaración del evento Transfer . En términos de transacciones, el token ERC-20 funciona bien sin un evento de transferencia . Entonces, ¿por qué deberían incluirse los eventos si agregan costos de gas a cada transacción? No sé cuáles son los lados buenos de tener eventos, y si superan los lados malos, por eso planteo esta pregunta.
Es una configuración predeterminada bastante buena usar registros de eventos para crear un registro de auditoría de modo que todo el historial de estado del contrato pueda, en teoría, reconstruirse con nada más que el código fuente y los registros de eventos.
Los registros de eventos son útiles para los clientes (actuales y futuros ) y son muy económicos. En mi opinión , es mejor errar por el lado de la exhaustividad e incluir registros de eventos completos que registren cada cambio de estado importante.
Obviamente, si uno quiere cumplir con un estándar y el estándar incluye registros de eventos, entonces la preferencia personal es discutible y el registro de eventos es imprescindible para una implementación compatible.
Espero eso ayude.
Desde el punto de vista de la funcionalidad, no hay ninguna razón por la que necesite llamar a la función de transferencia. Quiero decir que el resultado neto es el mismo independientemente de si lo llama o no, por lo que si todo lo que quiere hacer es mantener un saldo contable de asignaciones en su contrato, no hay absolutamente ninguna razón para que emita los eventos excepto uno muy importante uno.
Es el estándar.
Si no emite un evento cada vez que se produce una transferencia, no está implementando un token estándar ERC20.
Se podría decir que lo que está implementando es como un token ERC20, pero afectaría su capacidad para aparecer como un token ERC20 en un intercambio, para ser rastreado como un token ERC20 por sitios de blockchain, etc.
Ves que esos sitios esperan que tu token actúe de cierta manera. Esperan poder escuchar a nivel global en los eventos de transferencia para ver cuándo actualizar los saldos, etc.
Sin esta funcionalidad, necesitarían conocer su ABI e interpretar las llamadas de su función, tener que llamar a su balanceOffunción para cada dirección posible, o interpretar su contrato para averiguar cómo su contrato realiza un seguimiento de los saldos en las variables.
Y claro, la mayoría de los contratos mantienen saldos en un mapping(address=>uint), pero este no es necesariamente el caso. Tal vez podrían realizar un seguimiento de todas las llamadas a transfer(), pero nuevamente, esta no es la única forma en que los contratos pueden modificar los saldos.
supakaidad