optimización ERC20

Estoy estudiando el código fuente del contrato inteligente de Ethereum popular y hay algo que no entiendo en el estándar ERC20.

Tomemos este ejemplo:

https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol

Aquí hay una parte del código fuente de solidez de este contrato inteligente:

mapping (address => uint256) private _balances;
uint256 private _totalSupply;

Como puede ver, el suministro total se almacena en una variable separada. Esta oferta total es la suma de todos los saldos.

Lo que aprendí sobre la optimización de Solidity es que debemos dar prioridad al almacenamiento en lugar del cálculo.

Si tuviera que escribir un contrato ERC20, escribiría una función de vista que suma _saldos para proporcionar el suministro total. Por qué ? Una función de visualización puede sumar saldos de gas gratis porque no escribe nada en la cadena de bloques. Si tenemos una variable _totalSupply, tenemos que actualizarla cada vez que cambia un saldo. Así que costará algo de gasolina escribir esta variable.

Mi pregunta es: ¿Por qué todos ponen una variable _totalSupply en los contratos ERC20, en lugar de una función de vista que suma los saldos?

Gracias

Respuestas (2)

Si tenemos una variable _totalSupply, tenemos que actualizarla cada vez que cambia un saldo. Así que costará algo de gasolina escribir esta variable.

Eso no es correcto. Por ejemplo, si Bob transfiere x tokens a Alice, se actualizarán sus saldos pero no el suministro total. El mismo principio se aplica al dinero fiduciario, una transferencia bancaria o en efectivo no tiene impacto en el suministro total. _totalSupplysin embargo, se actualiza para cada uno minty burncuáles son, respectivamente, la creación y destrucción de tokens. El estándar ERC20 no especifica estas funciones ya que el mecanismo de suministro es muy específico para cada token. Por lo tanto, su implementación es gratuita.

¿Por qué todos ponen una variable _totalSupply en los contratos ERC20, en lugar de una función de vista que suma saldos?

¿ Cómo implementas esta sumfunción? Para esto, necesitaría rastrear cada dirección que tenga tokens, lo cual no es una solución óptima. El _totalSupplyenfoque es mucho más fácil ya que el suministro total se rastrea mediante el uso de los métodos minty burn.

Es cierto, el suministro total solo cambia en las operaciones de acuñación y quema. Pero es posible hacer un bucle en equilibrio para sumar en una función de vista
Si está pensando en iterar sobre el mapeo, _balanceseso no es posible. No puede hacer un bucle en una asignación, ya que es un sistema clave/valor con una cantidad infinita de claves. Por ejemplo, existe una dirección que no contiene tokens en el mapeo y devolverá cero como valor.
Para sumar los saldos, puede usar una matriz para registrar todas las direcciones con una cantidad de tokens distinta de cero agregando algunas lógicas en la transferfunción.
Pero eso sería una mala idea si está buscando optimización.

Eso no es correcto. No podemos iterar la variable de mapeo. Entonces no podemos calcular la suma de _saldos.

Es cierto que el mapeo no es iterable, pero es posible agregar un índice al mapeo, consulte ethereum.stackexchange.com/questions/13167/… .
Sí, tiene usted razón. Existen algunas técnicas para el mapeo iterable, pero requiere mucha tarifa de gas. En lugar de implementar un mapeo iterable, simplemente podemos agregar _totalSupply.
optimización ERC20
RespuestasAquíPolítica de privacidad1y, 0v