You probably mean "obstacles to be tackled
within the next decade"
Well, we clearly need to standardize how our Layer-2 transactions system works (lightning network), since at the rate the price is going in the long term, fees will be too high in USD value for smaller transactions.
Eltoo is a nice step towards that direction but it's clear that standardization won't happen with a bunch of completing LN clients being maintained, the only way I can see a set of LN internals being cemented for good is if they're merged into Bitcoin Core itself. Not the protocol, just the client.
To do that we need to invent a way to make scripts with complex rules, what you folks call "smart contracts". Bitcoin Script is too simple to make something like this, as I wrote about in
another post.
Normally you'd think about using a general-purpose language such as e.g. Lisp (or even C, but I think that's too big) and then your scripting engine evaluates the commands to do algorithms that you would otherwise be able to do in "grownup" programming languages.
For an example of the above, there is a need for a method to make two parties "bind", or agree, to a particular transaction that one will send to another, and not to send other transactions that haven't been agreed upon. This logic would be too large to fit in a Bitcoin transaction at a reasonable size, and too complex to do in Bitcoin Script anyway. So it will need its own protocol and network of nodes that specifically understand, and speak, this logic. And what can already be done today, is broadcasting the final state to bitcoin's blockchain (and a "sentinel" initial state that proves there's an L2 contract in place). This is the basics of how LN channels work.
The challenge is that the scripts must not be too large or they won't fit inside blocks and/or will cause transactions to be too big to include many of them in a block at the same time, which will congest the network. However, this is usually what happens when you're using such languages (unless you choose one that can be translated to "bytecode" similar to the one Bitcoin Script reads, e.g. something like Java but way smaller).
There are two solutions to this problem. One is to increase the block size, but without an improved scripting system that can parse these kinds of complex conditions, you'll just end up making the blockchain too big for most people to download fairly quickly.
The other solution is to somehow offload this logic to another protocol, and just broadcast a final result, and proof that there's a contract happening, like in the above example. And this is what devs are currently trying to do.
Now after all that is done, there's the additional problem of getting most people to use LN. User adoption is fairly slow and cannot be sped up, and obviously, not everyone is going to use LN. Even today some exchanges and users are still using legacy addresses. So naturally, LN will be subject to this adoption rate as well. This is where exchanges supporting LN and mass media promotion of LN will be useful.