What has Monero done to address CONOP factors?
How does the current Monero implementation compare to other existing cryptocurrency alternatives with regard to blocksize caps?
Is the any research about new adaptive blocksize formulas that may identify areas where Monero can make further scaling improvements?
[C]ost [O]f [N]ode [OP]eration is (theoretically) a way to measure to the cost of running a full node.
If we peg a blockchain with a 1 MB blocksize as having a CONOP of 1, then doubling the blocksize to 2 MB, would double the CONOP to 2, thus reducing decentralization since increasing CONOP would result in less people running full nodes (higher the price of something, less demand).
Of course, things don't only go up. As the cost of memory, hard drive space, internet speeds, etc. improve, the CONOP can also move down. So if you double the block size, but the cost of internet and hard drive space reduces, you can theoretically get an even lower CONOP than the original.
Monero can't really do much to affect the hardware aspects of CONOP, but it's adaptive blocksize algorithm attempts to keep blocks from becoming overly large, thus keeping the space component of CONOP within some reasonable range.
monerod on a low-end ARM device, I expect that to greatly increase the number of people running a public node, because it is easier to justify spending € 50 on a dedicated node then, than with € 1.000 for a simple server with SSD storage. Unfortunately, synchronizing the blockchain seems to be problematic for now on those ARM devices.
Riccardo Spagni was discussing CONOP (Cost of Node-Option) at the "OnChain Scaling Conferences" in a presentation called Dynamic Block Size Caps (YouTube):
