You don't need to store Terabytes per day for 1B daily transactions. BC does it differently, but you could get away with 4 byte time-stamp, 4 byte amount, 32 byte source public key, 32 byte destination public key = unique transaction + 32 byte signature demonstrating sender with correct private key signed that transaction. Now, 1 billion of those = 100GB per day = 36 TB per year which sounds like a lot but most nodes don't need the full amount just current state + verifiable hash + new transactions.
But even that's not needed, suppose every node includes a subset of the account amounts so every K nodes allows you to recover the state of all accounts. That way you don't need a full database just the most recent K nodes and they have complete state. Some people can keep a historic archive, but the system operates even if that information was lost. (You would want some GC as well so accounts must either be larger than A or have a transaction within the last Z steps.)
Granted, managing pending transactions increases bandwidth needs, but nodes can manage reputations based on only forwarding valid transactions. Some metrics so their is some statistical chance of conformation and you end up with ~2x overhead for unconfirmed but likely transactions.
PS: You can also have the protocol grow so if the 11 of the last 20 nodes where full the new node is 1% larger.