Liquidity: Gérer les problèmes d'envoi de pièces sur le compte de réserve

Créé le 27 mai 2021  ·  4Commentaires  ·  Source: tendermint/liquidity

Résumé du bogue

Lorsque quelqu'un envoie des pièces sur le compte de réserve d'un pool, cela peut causer des problèmes, notamment :

  • Un pool avec un solde de montant nul sur un côté de la pièce de réserve, ce qui entraîne un calcul incorrect du prix du pool

    • En retirant toutes les pièces du pool et en envoyant ensuite une seule pièce de réserve directement sur le compte de réserve

  • Une panique dans la logique de dépôt, lors du calcul du ratio de pièces de réserve (diviser par zéro erreur avec un pool décrit ci-dessus)
  • ...

Version

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

Étapes pour reproduire

L'exécution de ce test provoque une panique :

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)
}

À l'usage de l'administrateur

  • [x] Pas de problème en double
  • [x] Libellés appropriés appliqués
  • [ ] Contributeurs appropriés tagués
  • [ ] Contributeur attribué/auto-attribué
bug

Commentaire le plus utile

Si nous définissons un pool épuisé comme un pool avec zéro réserve de pièces de pool , et non un pool avec zéro réserve , nous pouvons empêcher la chaîne de paniquer dans les situations mentionnées.

Je vais y travailler.

Tous les 4 commentaires

Si nous définissons un pool épuisé comme un pool avec zéro réserve de pièces de pool , et non un pool avec zéro réserve , nous pouvons empêcher la chaîne de paniquer dans les situations mentionnées.

Je vais y travailler.

Une chose qui peut être envisagée est d'utiliser des comptes de module qui sont sur liste noire (via le module bancaire) pour recevoir des jetons, mais c'est un changement plus important par rapport à la solution ci-dessus.

@migueldingli1997 Nous avons d'abord pensé à cette approche, mais comme ReserveAcc est créé dynamiquement lorsqu'il y a un nouveau pool, nous pensons que l'implémentation nécessite une modification plus importante de blockedAddrs . Nous explorons toujours cette approche pour voir s'il existe une solution de contournement.

Ouais c'est correct. Une solution de contournement consiste alors à utiliser un seul compte de module (créé à la genèse et avec les restrictions appropriées), mais vous devrez ensuite suivre les soldes de réserve pour chaque pool dans le module de liquidité, plutôt que de le laisser à la banque. module. Je comprends que cela pourrait ne pas être souhaitable cependant.

Cette page vous a été utile?
0 / 5 - 0 notes