Eltoo is a way of keeping payment channel state that works better than the original scheme used in Lightning. Since Lightning is a bunch of different protocols glued together, it can It replace just the part the previously dealed with keeping the payment channel.
Eltoo works like this: A and B want a payment channel, so they create a multisig transaction with deposits from both – or from just one, doesn't matter. That transaction is only spendable if both cooperate. So if one of them is unresponsive or non-cooperative the other must have a way to get his funds back, so they also create an update transaction but don't publish it to the blockchain. That update transaction spends to a settlement transaction that then distributes the money back to A and B as their balances say.
If they are cooperative they can change the balances of the channel by just creating new update transactions and settlement transactions and number them like 1, 2, 3, 4
Why do they need and update and a settlement transaction?
Because if B publishes update2 (in which his balances were greater) A needs some time to publish update4 (the latest, which holds correct state of balances).
Each update transaction can be spent by any newer update transaction immediately or by its own specific settlement transaction only after some time – or some block
How do they close the channel?
If they're cooperative they can just agree to spend the funding transaction, that first multisig transaction I mentioned, to whatever destinations they want. If one party isn't cooperating the other can just publish the latest update transaction, wait a while, then publish its settlement transaction.
How is this better than the previous way of keeping channel states?
Eltoo is better because nodes only have to keep the last set of update and settlement transactions. Before they had to keep all intermediate state updates.
If it is so better why didn't they do it first?
Because they didn't have the idea. And also because they needed an update to the Bitcoin protocol that allowed the presigned update transactions to spend any of the previous update transactions. This protocol update is called SIGHASH_NOINPUT, you've seen this name out there. By marking a transaction with SIGHASH_NOINPUT it enters a mystical state and becomes a floating transaction that can be bound to any other transaction as long as its unlocking script matches the locking script.
Why can't update2 bind itself to update4 and spend that?
Good question. It can. But then it can't anymore, because Eltoo – or maybe SIGHASH_NOINPUT, who knows – specifies a new fake OP_CHECKLOCKTIMEVERIFY constraint that doesn't actually check a locktime, but a sequence. It's all arcane stuff.
And then Eltoo update transactions are numbered and their lock/unlock scripts will only match if a transaction is being spent by another one that's greater than it.
If there is only a tiny penalty for attempting to breach you, why don't I just always try that?
actually there is no punishment at all besides the lost fees which could be considered a tiny punishment. this might be enough because the chances of you getting away with stealing funds are very small.
If it turns out, not to be big enough of a deterrent, a bigger punishment can always be agreed upon. This gives much more flexibility than the status quo which almost always leads to loss of funds due to error and not due to attempted stealing.
Loss of funds due to error turns out to hardly ever happen.