Tengo un problema extraño al trabajar con algunos contratos de token ERC20 que he escrito:
Cuando especifico un valor decimal, digamos 4 aquí para simplificar, los valores se muestran de manera diferente en Mist vs etherscan.
Por ejemplo, si creo un token con un suministro de 1 con decimales de 4, los tokens aparecen como un valor de 0.0001 en Mist pero el valor aparece como 1 en etherscan; sin embargo, si hago clic en el ícono ERC20 en etherscan para ver los detalles del token, allí está de acuerdo con Mist y establece que el suministro del token es 0.0001.
Entonces, entiendo que el contrato funcionará con la unidad más pequeña del token, según lo establecido por el valor de los decimales en el constructor; pero no estoy muy seguro de cómo obtener el valor del token en sí, en lugar de las unidades más pequeñas, para que se muestre en Mist y etherscan. Déjame saber si eso no tiene sentido.
La forma en que pienso sobre esto es que la cantidad de tokens es:
tokenSupply = tokensIActuallyWant * (10 ** decimales)
Si quiero 1 token con la capacidad de subdividirlo con una precisión de 2 decimales, lo represento como 100.
Del mismo modo, si quiero 1 token con la capacidad de subdividirlo en 18 decimales, necesito representarlo como 10000000000000000000 (1 con 18 ceros).
Espero que ayude.
totalSupply= tokensIActuallyWant * (10 ^ decimals)decimals = 0?Al igual que muchas palabras en criptografía (por ejemplo, billetera), el término token tiene varias definiciones distintas, principalmente según el contexto.
Token : generalmente abreviatura de token ERC20 en la red principal de Ethereum.
Token (o reemplazado por el nombre o símbolo del token): unidad utilizada por los contratos inteligentes para la contabilidad (los contratos inteligentes funcionan con números enteros , por lo que no puede haber decimales). Piense en ello como la unidad más pequeña posible, comparable a wei para Ether.
Token (o reemplazado por el nombre o símbolo del token): unidad utilizada para mostrar a los usuarios (en cualquier interfaz de usuario, desde billeteras hasta intercambios o cualquier Dapp). Esto es comparable a Ether, que usa 18 decimales para mostrar. Cuando se muestra 1080250000000000000000 para un token de 18 decimales, es mucho más fácil de usar mostrarlo como 1'080.25.
Para mantener la precisión, asegúrese de usar números enteros grandes en su JS y convierta a/desde flotante justo después/antes de desinfectar la entrada del usuario. Y en su contrato inteligente, solo razona en números enteros [vea las notas a continuación], y ese es el único tipo de números que espera recibir como datos de transacción.
Tenga mucho cuidado si usa menos de 18 decimales, y más aún con cero. Las divisiones exhibirán un comportamiento gradual cuando se apliquen a cantidades pequeñas (o no tan pequeñas, se sorprendería) de tokens y su contrato inteligente podría comportarse de manera extraña. Incluso puede dificultar la capacidad del token para intercambiarse de manera eficiente, o incluso cotizarse en los intercambios.
[notas] Solidity puede manejar fracciones y cálculos de alta precisión, pero cuando se trata de almacenar el resultado, solo puede almacenar valores enteros. Usando el tipo más común y óptimo, uint256podrá almacenar números tan grandes como 10**77.
Si su token ERC20 usa 18 decimales, su suministro total máximo de "token de visualización" es de alrededor de 10**59. No hay ganancia en usar un tipo más pequeño (por ejemplo, uint192) debido a cómo funciona el EVM, y con 18 decimales ya hay un amplio espacio en ambas direcciones (suministro total y precisión de división). Mantenga los 18 decimales predeterminados a menos que realmente sepa lo que está haciendo, por qué y con qué consecuencias.
Naval