TLDR:

Have slave blocks ever been considered to be done in monero ?
well i had this unfundamented vague idea about having slave / master blocks. the current blocks are considered master blocks. and within them there are hash pointers from slave blocks. these slave blocks have transactions within them . what im saying is that instead of having just "your keys your coins" you also need the digital storage of the slave block. The advantage is that instead of storing the tx's themselves you only store one hash, per slave block. First and foremost if a block is mined wich does contain slave blocks how does the user get his slave block in a safe, reliable way. The second problem is that the amount of verifications done at each normal block is very high because the user needs to send to the miner his signed tx and his digital storage of the block. the third is preventing double spends. So within a slave block no change can be sent to the same address in a transaction. Therefore when sending from one Address (or utxo this is handwavy) the change needs to be sent to a new address or subaddress. So lets ignore the monero protocol for the sake of simplicity. Assume a primitive working protocol where each transaction goes from address A to Address B (A->B). Furthermore a transaction is indexeable, this is, the receiving address is at certain simple coordinates, in the slave block. each coordinate forms a tuple. this is only for illustrative purposes. Say we are at block j . And some address D received funds within a sub-block in a block i. So later in the block j (j>i), there would be after the set of hashes of slave blocks, a set of blocked addresses (from wich the funds have just been spent in this block or slave block). it would suffice to have { {i, s, stx}, ...} . where i is the index of the block . s is the index of the slave block within the block. and stx is the index of the tx inside the slave block. so instead of having like a list of the form { {B1, S1, Stx1}, {B2, S2, Stx2}, {B3, S3, Stx3}, ... {Bn, Sn, Stxn}} . A more compact way would be desirable like if your blocking n addresses wich are indexeable tuples like that, you could have a single polynom where its roots are exactly and only those n tuples.
Notice that its somehow like passing a hot potatoe, you need your slave block to make a transaction and the receiving person needs to receive also its slave block.

Comments :
i mean there are huge mining farms, with fields and fields of mining hardware, why not having aswell some room with storage place to keep the current slave blocks that are beeing verified?
and for the UX its great the user does not care if its wallet on the phone or on the usb stick has a couple of megs more.
And keep your enemy closer let the banks store the slave blocks so that they have something to do !
At 50k tx/s no company in the world will keep the entire blockchain anyway i guess, because there is no economic incentive to buy 1 tb or more per day. So let a small portion of the computing power of a miner do the verifications for 50k tx/s .
If the btc network can send 1mb block over the network, is it then not really doable to send 10 times 1mb slave-blocks? Is this transmission of blocks parallelizable over the wan?
Since this represents the worst case scenario in so many ways storage, computing power, and required bandwith, is it aswell not a believable uppest bound that can be achieved?

Where are the problems here ? Is this infeasable? Or could this solve the scaling issue altogether under the assumption that users want to store ugly slave blocks ?