Cálculo del costo del gas en una iteración

Recomendaría encarecidamente que no se use una función de contrato iterativo para tal cosa porque es seguro que fallará en algún nivel de titulares de fichas. Incluso si está bien en 1.000, ¿qué pasa con 10.000? ¿Qué hay de 100.000?

Su primer instinto debería ser repensar la aplicación de tal manera que no se requiera tal iteración. Si eso es imposible, considere una pequeña función atómica que se ocupará de un titular de token a la vez y una estrategia de una dirección confiable encargada de realizar la iteración y enviar las muchas transacciones pequeñas. Cuida que cada "paso" deje el contrato en un estado válido. En otras palabras, es importante que las cosas sigan funcionando como se esperaba mientras el proceso por lotes está en curso.

En el caso de que el contrato se encuentre en un estado no válido mientras el proceso por lotes está en curso, puede reaccionar con un guardia para poner el contrato fuera de servicio hasta que el proceso por lotes se complete con éxito.

En mi opinión , todas estas medidas sugieren fuertemente que el proceso en sí necesita una revisión porque no está bien adaptado a los patrones de contratos inteligentes.

Espero eso ayude.

Actualizado

Por ejemplo, podría haber un requisito para distribuir dividendos o regalías a una gran cantidad de titulares de fichas. Dejaré de lado algunas preocupaciones relacionadas con el intercambio y me centraré en el tema de manejar un gran número de iteraciones.

El diseño de una plataforma de contrato inteligente con un techo duro (en movimiento) a menudo implica invertir el control. La distribución de miles de pagos es uno de esos ejemplos. Para invertir esto:

1. Cada poseedor de fichas reclama su distribución (favorecer "tirar" sobre "empujar").
2. El contrato verifica si el reclamo es aceptable
3. Si es aceptable, se asigna la reclamación y se actualiza el almacenamiento para evitar la doble reclamación.
4. Las reclamaciones son acumulativas. Los clientes pueden ejercer reclamaciones en su tiempo libre sin riesgo de pérdida.
5. Un "saldo" gastable sería el saldo regular, más cualquier distribución no reclamada. Para la mayoría de los propósitos, las matemáticas y el procesamiento pueden proceder como si el reclamo ya hubiera ocurrido.

Vale la pena señalar que todos los participantes pueden conocer y calcular los reclamos/derechos con o sin procesamiento real en la cadena. También vale la pena señalar que los propios clientes "pagarían" los costos de procesamiento de las transacciones.

Considere un caso simple con titulares de fichas que tienen un saldo y algún tipo de derecho, a intervalos:

function calculateUnclaimed(address holder) internal returns(uint pending) {
  // calculate accrued unclaimed for one user
  return calculation;
}

function getSpendable(address holder) public constant returns(uint spendable) {
  return balances[holder] + calculateUnclaimed(holder);
}

function processClaim(address holder) public returns(uint newBalance) {
  balances[holder] += calculateUnclaimed(holder);
  zeroOutPending(holder); 
     // as each distribution emerges, append to master list
     // as each claim is processed, note holder has claimed his part
  return balances[holder];
}

Este es un ejemplo ideado rápidamente para mostrar cómo se puede reorientar el procesamiento hacia los clientes que "tiran" de las reclamaciones en lugar de que el servidor "empuje" la distribución.

Incluso a primera vista, comienza a parecer que processClaimpuede no ser necesario en absoluto , pero puede ser útil para limpiar y reducir los costos de transacción. El objetivo debe ser lograr un costo de gas constante para todas las transacciones a cualquier escala.

Espero eso ayude.