Liquidity: Behandeln Sie Probleme beim Senden von Coins auf das Reservekonto

Erstellt am 27. Mai 2021  ·  4Kommentare  ·  Quelle: tendermint/liquidity

Zusammenfassung des Fehlers

Wenn jemand Coins auf das Reservekonto eines Pools sendet, kann dies einige Probleme verursachen, darunter:

  • Ein Pool mit einem Nullbetrag auf einer Seite der Reservemünze, was zu einer falschen Berechnung des Poolpreises führt

    • Indem Sie alle Coins aus dem Pool abheben und dann nur einen Reservecoin direkt auf das Reservekonto senden

  • Eine Panik in der Einzahlungslogik bei der Berechnung des Reserve-Coin-Verhältnisses (dividiere durch Null-Fehler bei einem oben beschriebenen Pool)
  • ...

Ausführung

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

Schritte zum Reproduzieren

Das Ausführen dieses Tests verursacht eine Panik:

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

Zur Verwendung durch Administratoren

  • [x] Kein doppeltes Problem
  • [x] Entsprechende Labels angebracht
  • [ ] Geeignete Mitwirkende markiert
  • [ ] Mitwirkender zugewiesen/selbst zugewiesen
bug

Hilfreichster Kommentar

Wenn wir einen erschöpften Pool als einen Pool mit Null-Pool-Münzenversorgung und nicht als einen Pool mit Null-Reserven definieren , können wir in den genannten Situationen verhindern, dass die Kette in Panik gerät.

Ich werde daran arbeiten.

Alle 4 Kommentare

Wenn wir einen erschöpften Pool als einen Pool mit Null-Pool-Münzenversorgung und nicht als einen Pool mit Null-Reserven definieren , können wir in den genannten Situationen verhindern, dass die Kette in Panik gerät.

Ich werde daran arbeiten.

Es kann in Betracht gezogen werden, Modulkonten zu verwenden, die (über das Bankmodul) auf die schwarze Liste gesetzt sind, um Token zu erhalten, aber dies ist eine größere Änderung im Vergleich zur obigen Lösung.

@migueldingli1997 Wir dachten zuerst über diesen Ansatz nach, aber da ReserveAcc dynamisch erstellt wird, wenn ein neuer Pool vorhanden ist, denken wir, dass die Implementierung eine größere Änderung an blockedAddrs erfordert. Wir untersuchen diesen Ansatz noch, um zu sehen, ob es eine Problemumgehung gibt.

Ja das ist richtig. Ein Workaround besteht darin, nur ein Modulkonto zu verwenden (erstellt bei Genesis und mit den entsprechenden Einschränkungen), aber dann müssen Sie die Reservesalden für jeden Pool im Liquiditätsmodul im Auge behalten, anstatt es der Bank zu überlassen Modul. Ich verstehe jedoch, dass dies möglicherweise nicht wünschenswert ist.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen