Well current blockchain SDKs is a little broad. That encompasses everything from really just a bunch of api's like the list linked:
https://www.programmableweb.com/category/blockchain/sdksTo do you mean actually working with say the direct blockchain's internal api. e.g: bitcoind bitcoin-cli ( for all the coins too )
Looking more at the api side of websites that do checks on the chain of a coin for you then make it an api I have had quite a few interesting problems on my little projects:
https://bitcointalk.org/index.php?topic=5090189.0You can actually see in my thread someone talk about how I didn't have bech32 working and the site they initially proposed to me didn't work because my entire project is built in javascript so that I don't ever see anyone's data. This requires me to make every request out to these third party blockchain apis through javascript which don't always really make their api for javascript requests. (my problem with a few was cross site origin requests which if they don't provide the correct headers in their response then your browser deny the request) They think everyone is doing it from a server first then delivering / looking at data. Which would have killed the entire point of paper wallet checker.
The other thing many do is force you into api keys which also would kill my idea because then either I get throttled if a bunch of people are checking addresses or I simply can't use them. ( I didn't use ones with an api key ) Again the point being not having data collected on the end user as well as I wanted the request to not have to be linked to anything beyond the basic request for the balance of an address mainly.
If I earned any money there is a guy in the Bitcoin SV community that actually came up with a pretty brilliant way of running a node with a mongo database which would allow even more complex queries to a node that are quite a pain to do in vanilla node api calls. ( bitcoind bitcoin-cli / JSON-rpc for example ) Being even faster in being able to reply meaning that not only is your node faster to respond but that means it uses less cpu resources to respond. I would take this and modify it to work on bitcoin and other coins to run a node for all the coins I check so that I could make the api I wanted with no api keys and keep the promise of not looking at user data in any way.
So from a working with nodes that then turn them into an api there are many problems
Now if you are talking about from a working with the straight node software then there are plenty for every coin. One of which being how hard it is to getting into it and figuring out what the hell is going on first. This takes a huge amount of time and it isn't always well documented. Even one that is (Bitcoin). Like this free book:
https://github.com/bitcoinbook/bitcoinbookYou get into chapter 3 and finally start messing around with the node software and Andreas tells you essentially you should run a full node if you want to be a bitcoin developer. This is all fine and dandy and he is right at some point however if you are in an area with terrible internet you can't at home while trying to learn do this, it is simply impossible, while later on after learning if you have a server hosting your node somewhere it can be. However he doesn't mention anything about --regtest mode which essentially allows you to just create a personal fake blockchain locally that you can do all these operations against without needing a real node of any kind but it acts the exact same way. This mode is also really used to test blockchain applications before even trying them on a testnet.
None of what I talked about even starts with decentralized app development which as others have stated immutability is a big thing because if you push a mistake live ( especially with dapps ) you are essentially screwed. ( DAO, Parity, countless other examples....) The only thing you can do is in fact start an entirely new dapp but if funds are caught up in the old one you are up a shit creek without a paddle.
Also just the technical side of how addresses are created / transactions / cryptography / networking / network game theory. All of these things need to be known at least to an extent to do anything ( depending at what level you are at, a dapp doesn't need to know a lot of these things but they have countless other things to deal with )
So yea there are lots of things, so many that I think you are a little broad. Unless the paper is meant to be broad in which case there is countless numbers of things you can talk about.
Cheers
PS
I think SDK / API are poorly defined really. Most things we call an SDK can really be also called an API. I typically think of an SDK with an IDE ( integrated development environment) for example android studio for android phone development is an sdk ( it has a code editor / phone emulators / ect ). As opposed to API ( application programmable interface ) which I personally think is what people really are talking about most of the time. Maybe there is an SDK for some dapp chain out there but really everyone is just working with internal APIs in my opinion. SDK ( software development kit ) usually a bundled piece of software that aids in development.
