Liquidity: Manejar problemas de envío de monedas a la cuenta de reserva.

Creado en 27 may. 2021  ·  4Comentarios  ·  Fuente: tendermint/liquidity

Resumen de error

Cuando alguien envía monedas a la cuenta de reserva de un grupo, puede causar algunos problemas que incluyen:

  • Un grupo con saldo de monto cero en una cara de la moneda de reserva, lo que lleva a un cálculo incorrecto del precio del grupo

    • Retirando todas las monedas del grupo y luego enviando solo una moneda de reserva directamente a la cuenta de reserva

  • Un pánico en la lógica de depósito, al calcular la relación de la moneda de reserva (dividir por error cero con un grupo descrito anteriormente)
  • ...

Versión

https://github.com/tendermint/liquidity/releases/tag/v1.2.5

Pasos para reproducir

Ejecutar esta prueba provoca pánico:

func TestSwapHalfZeroReserve(t *testing.T) {
    simapp, ctx := createTestInput()
    params := simapp.LiquidityKeeper.GetParams(ctx)
    pool, addr, err := createPool(simapp, ctx, sdk.NewInt(1000000), sdk.NewInt(1000000), DenomX, DenomY)
    require.NoError(t, err)
    pc := simapp.BankKeeper.GetBalance(ctx, addr, pool.PoolCoinDenom)
    _, err = simapp.LiquidityKeeper.WithdrawLiquidityPoolToBatch(ctx, types.NewMsgWithdrawWithinBatch(addr, pool.Id, pc))
    require.NoError(t, err)
    liquidity.BeginBlocker(ctx, simapp.LiquidityKeeper)
    liquidity.EndBlocker(ctx, simapp.LiquidityKeeper)
    require.True(t, simapp.BankKeeper.GetBalance(ctx, pool.GetReserveAccount(), DenomX).IsZero())
    require.True(t, simapp.BankKeeper.GetBalance(ctx, pool.GetReserveAccount(), DenomY).IsZero())
    err = simapp.BankKeeper.SendCoins(ctx, addr, pool.GetReserveAccount(), sdk.NewCoins(sdk.NewInt64Coin(DenomX, 10000)))
    require.NoError(t, err)
    _, err = simapp.LiquidityKeeper.SwapLiquidityPoolToBatch(ctx,
        types.NewMsgSwapWithinBatch(
            addr, pool.Id, types.DefaultSwapTypeId, sdk.NewInt64Coin(DenomX, 1000), DenomY, sdk.MustNewDecFromStr("1.0"), params.SwapFeeRate), 0)
    require.NoError(t, err)
    liquidity.BeginBlocker(ctx, simapp.LiquidityKeeper)
    liquidity.EndBlocker(ctx, simapp.LiquidityKeeper)
}

Para uso administrativo

  • [x] No es un problema duplicado
  • [x] Se han aplicado las etiquetas adecuadas
  • [] Colaboradores apropiados etiquetados
  • [] Colaborador asignado / autoasignado
bug

Comentario más útil

Si definimos un grupo agotado como un grupo con suministro de monedas de grupo cero , no un grupo con reserva cero , podemos evitar que la cadena entre en pánico en las situaciones mencionadas.

Trabajaré en eso.

Todos 4 comentarios

Si definimos un grupo agotado como un grupo con suministro de monedas de grupo cero , no un grupo con reserva cero , podemos evitar que la cadena entre en pánico en las situaciones mencionadas.

Trabajaré en eso.

Algo que se puede considerar es hacer uso de las cuentas del módulo que están en la lista negra (a través del módulo bancario) para recibir tokens, pero este es un cambio mayor en comparación con la solución anterior.

@ migueldingli1997 Pensamos en ese enfoque al principio, pero dado que ReserveAcc se crea dinámicamente cuando hay un nuevo grupo, creemos que la implementación requiere un cambio mayor a blockedAddrs . Todavía estamos explorando este enfoque para ver si existe una solución.

Sí, eso es correcto. Una solución alternativa es usar solo una cuenta de módulo (creada en la génesis y con las restricciones apropiadas), pero luego tendrá que realizar un seguimiento de los saldos de reserva para cada grupo en el módulo de liquidez, en lugar de dejarlo en manos del banco. módulo. Sin embargo, entiendo que esto podría no ser deseable.

¿Fue útil esta página
0 / 5 - 0 calificaciones