Lorsque quelqu'un envoie des pièces sur le compte de réserve d'un pool, cela peut causer des problèmes, notamment :
https://github.com/tendermint/liquidity/releases/tag/v1.2.5
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)
}
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.
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.