Optimización de costos de lanzamiento aéreo

Estoy planeando un airdrop de un token minable ERC20 creado a través de un contrato de venta colectiva basado en Open Zeppelin .

Ahora, lo que me pregunto es cuál sería la forma rentable de agregar una funcionalidad de lanzamiento aéreo. Esto es lo que podría pensar:

  • Envíe todos los tokens reservados para airdrop a la billetera del propietario de crowdsale en la creación del contrato y luego escriba una pequeña aplicación Node.js + Web3 + ethereumjs-tx que simplemente recorre la lista de billeteras airdrop y envía a cada uno de ellos algunos tokens (wallet a la billetera) usando sendSignedTransaction.

  • Agregue un método de lanzamiento aéreo al contrato de Crowdsale que recibirá la matriz de direcciones de billetera y las recorrerá, mint()enviando y transfiriendo los tokens a cada una de ellas. Luego llame a ese método a través de Node.js + Web3 pasándole la lista de direcciones.

¿Hay una mejor manera que me estoy perdiendo?

¿Cuál sería la forma más barata de hacer esto?

Respuestas (1)

El método 2 es el más utilizado. En lugar de pagar una tarifa por cada transferencia, agrupa varias transferencias.

Un enfoque diferente es tener un airdrop "virtual" donde solo se generan eventos y los saldos reales se acreditan en la primera transferencia.

Pero deberías escribir el código y probarte a ti mismo.

pero en el método 2, digamos que paso 100 direcciones al método, aún necesitaría hacer 100 transferencias, por lo que aún pagaría una tarifa por cada transferencia, ¿verdad? ¿O me estoy perdiendo algo?
Hacer dos transferencias en una sola transacción debería ser más económico que hacer dos transferencias en dos transacciones. Pero en cualquier caso, no debe confiar en mí, programe las dos soluciones y mida el gas utilizado.
ok, ya veo, y ¿qué pasa con el airdrop virtual? No estoy seguro de entender lo que quieres decir con que los saldos se acreditan en la primera transferencia. ¿Qué primera transferencia?
La idea es generar solo eventos de Transferencia, eso debería ser barato porque el contrato de almacenamiento no se modifica. Las billeteras y/o los exploradores de bloques mostrarán el saldo del evento Transferir. Cuando alguien solicite un saldo, verificará si la cuenta se inicializó, si no se inicializó, devolverá un valor fijo. Las cuentas se inicializarán cuando realicen su primera transferencia, cuando llamen transfer o transferFrom desde el contrato.
¿Para qué serviría tal lanzamiento aéreo?
Los Airdrops de @NikitaFuchs se utilizan para diferentes propósitos: ICO, marketing, pago de clientes/usuarios, distribución de ganancias, etc. Un tema importante es minimizar los costos asociados y hacer un mejor uso de la red Ethereum. En mi humilde opinión, es posible que no nos gusten los lanzamientos aéreos, pero no hay forma de prohibirlos , por lo que es mejor buscar formas de hacerlos más eficientes.
@Ismael Me refería al propósito de sugerir al usuario que recibió tokens cuando en realidad no los recibió, mediante el uso de la activación de eventos
@NikitaFuchs La idea es tener un saldo virtual que solo se inicialice cuando se use.
Pero para poder usarlo, ¿tendrá que haber otra transacción que realmente otorgue ese saldo al usuario?
@NikitaFuchs La idea es inicializar solo el saldo cuando se ejecuta una transferencia.
¿Cómo se supone que funciona? Las llamadas a funciones no tienen acceso a los datos de eventos anteriores, por lo que el usuario definitivamente no puede inicializarlos por sí mismo.
@NikitaFuchs El saldo se actualiza cuando llamas transfer(), mi caso de uso fue cuando cada usuario se inicializó con la misma cantidad.
Aaaaaah, te pillo.
Optimización de costos de lanzamiento aéreo
RespuestasAquíPolítica de privacidad1y, 0v