Pipedream idea for an "ideal" cryptocurrency

This thread is not about an existing or soon-to-exist altcoin.
It's just a discussion about optimal/ideal cryptocurrency implementations.

I have been thinking about what an "ideal" might look like in terms of cryptocurrency implementations.
This is more of a dream I had, rather than a concise recipe on how to build a cryptocurrency.
It is probably unfeasible, except in my dreams, but I had to write it down.

WEIRD PIPEDREAM CONCEPT FOR THE "IDEAL" CRYPTOCURRENCY:

- The "state" of the system is stored publicly, however it appears to be a jumble of meaningless numbers.
  NOTE: I make use of a printing analogy in this description.
  Therefore it might help to visualise the system state as a piece of paper onto which transactions are printed, one on top of the other. Imagine each transaction looks like one of those "magic eye" 3D images, and they all get printed on top of one another, creating an unrecognisable mess.
- An address can only contain one coin or no coin. A transaction simply consists of an origin and destination address.
- The state "encodes" only the current state of the ledger, not the historical state - nodes are welcome to save historical states, but it is not necessary.
- The "encoding" is obfuscated - to make a payment, a user first creates their signed funding transaction, then performs some kind of magical mathematical operation (TBD) that encodes their transaction into a piece of data the size of the system state - creating what we'll call a "preimage"
- The transaction preimage just looks like a bunch of garbled nonsense like the system state.
- For someone with no information about the keys/addresses involved, they can verify if the transaction is valid by downloading the latest valid system state, imprinting it with the transaction preimage, and seeing what the resulting "balance" is.
- It is possible to create overfunded preimages - known as "payment" preimages - as well as underfunded preimages - known as "invoice" preimages.
- The mechanism through which transactions are sent is by sending a payment preimage or invoice preimage to the payer/payee respectively, who then imprints this with their respective invoice or payment preimage to complete the full transaction preimage - i.e. balance = 0 - then submits it to the network.
  For example, if you want to send funds to an as-yet unknown address, you can just send the person the payment preimage through an encrypted channel, and then they can simply "imprint" their invoice preimage onto it.
  Or conversely, if you want to receive funds from an as-yet unknown address, you can just send the person the invoice preimage - no need to send through an encrypted channel since it doesn't represent any unsecured value - and then they can imprint their payment preimage onto it, then submit it to the network.
- After this, the transaction preimage can be sent to a node operator, who will imprint it onto the current system state.
- The system state is nothing more than the sum of imprints of all prior transaction preimages starting with the genesis block - all of which is entirely obfuscated.
- An incongruous transaction preimage - i.e. a transaction preimage where the origin address contains no coin, or the destination address already contains a coin - will simply return a negative/positive balance (from the destination address) when the preimage is imprinted with the system state.
  In this way, even if a transaction preimage is imprinted twice (or a thousand times) onto the system state, the subsequent imprints will not cause problems.
- The system state is updated by way of gathering and imprinting transaction preimages in a completely unordered fashion. A multitude of transaction preimages could be gathered by a node operator, all imprinted together to form a "preimage set", and submitted to the network in one go. A preimage set is indistinguishable from a single preimage to someone without knowledge of the addresses/pubkeys.
- Even if there are millions of duplicate transactions - e.g. when one node operators system state is imprinted onto another node operators in order to settle two "tails" - the duplications will be invisible in the output.
- In this way, consensus is achieved, even though there is no blockchain to speak of. Even though the system is highly chaotic and unordered, the state is always valid.
- If a node operator attempts to proliferate a completely fabricated system state, it will be instantly recognisable to all users, since EVERYONE's coins would disappear.
- Node operators are incentivised not to proliferate old states, since they can be paid by users for updating the system state with new transactions. Most likely, users will submit overfunded transaction preimages that they send to node operators, who then imprint the preimage with an unfunded invoice, and imprint this onto the system state.
- Alternatively, users could request invoices from node operators for submitting their transaction to the network. If a user wanted to make certain their transaction would make it into the consensus system state, they could even pay multiple node operators with a single transaction.
- Note that at any time, anyone can add payment onto a preimage or preimage set. For example, if the receiver of a payment wanted to bump their transaction, they could resubmit it with additional payment.
- Additionally, node operators could use fees they've collected to pay other node operators to accept their preimage set.
- Conflicting states - i.e. double spends - are resolved automatically during imprinting. Imprinting is a non-commutative operation: if state alpha contains a transaction spending from address X to address A, and another state beta contains a transaction spending from address X to address B, then the order of the imprint operation will decide which of A or B receives the payment. If state alpha is imprinted onto state beta, then address B will receive the payment. If conversely, state beta is imprinted onto state alpha, then address A will receive the payment.
- Someone who wishes to surveil people's transactions can only do so by archiving all states and preimages/preimage sets he receives, and then imprinting them with new states and preimages/preimage sets, and comparing the difference, thereby building a model of the differences in time. It might be possible to surmise some transaction information this way, but it will be difficult and resource intensive.
- I realise the system state would be prohibitively huge if you scaled it up to 2.1e15 coins and 160 bit addresses like bitcoin. It would be something like 32000 TB. I am hoping there is a way to collapse the state down to some kind of sparse representation like bitcoin. Or possibly have multiple chains operating in isolation which have smaller states, and then a way of merging smaller and larger state systems.

EDIT: I have a hunch that the encoding scheme would need to make use of Fast Fourier Transforms... just a hunch.

I know all this probably sounds ridiculous and impossible to anyone who knows anything about cryptography. This is just a thought I had and I had to write it down and share it somewhere.
Please let me know what you think.Would love input from cryptography experts.

Cheers,
Tony