tests for update

[Alexangelj]

DFMM/src/LogNormal/LogNormal.sol

Lines 250 to 280 in e64e222

	function update(
	address sender,
	uint256 poolId,
	IDFMM.Pool calldata pool,
	bytes calldata data
	) external onlyDFMM {
	if (sender != internalParams[poolId].controller) revert InvalidSender();
	LogNormalLib.LogNormalUpdateCode updateCode =
	abi.decode(data, (LogNormalLib.LogNormalUpdateCode));
	if (updateCode == LogNormalLib.LogNormalUpdateCode.SwapFee) {
	internalParams[poolId].swapFee = LogNormalLib.decodeFeeUpdate(data);
	} else if (updateCode == LogNormalLib.LogNormalUpdateCode.Sigma) {
	(uint256 targetSigma, uint256 targetTimestamp) =
	LogNormalLib.decodeSigmaUpdate(data);
	internalParams[poolId].sigma.set(targetSigma, targetTimestamp);
	} else if (updateCode == LogNormalLib.LogNormalUpdateCode.Tau) {
	(uint256 targetTau, uint256 targetTimestamp) =
	LogNormalLib.decodeTauUpdate(data);
	internalParams[poolId].tau.set(targetTau, targetTimestamp);
	} else if (updateCode == LogNormalLib.LogNormalUpdateCode.Strike) {
	(uint256 targetStrike, uint256 targetTimestamp) =
	LogNormalLib.decodeStrikeUpdate(data);
	internalParams[poolId].strike.set(targetStrike, targetTimestamp);
	} else if (updateCode == LogNormalLib.LogNormalUpdateCode.Controller) {
	internalParams[poolId].controller =
	LogNormalLib.decodeControllerUpdate(data);
	} else {
	revert InvalidUpdateCode();
	}
	}

This function is externally exposed in the core dfmm contract update() which can be called by anyone. I'm pretty sure it is possible to update the pool to a state that would require the arbitrageur to deposit funds into the pool (+ both sides), which they would not be incentivized to do. This would lead to a pool that does not get arbitraged after update. But, I'm not sure. We should work on some dedicated tests for this to figure it out, and get the insights on this behavior from the sim

[clemlak]

I'm not entirely sure about the scenario you're describing. We've already identified a few potential "attacks" using update though, such as "flash updates" that could take the form of two updates in a row, sandwiching the transactions of the liquidity providers or arbitragers to abuse them. However this attack is only possible if the pool controller is malicious.