A solution proposal for the historical blockchain dependency impracticality

To moderators: Please read this post and consider moving it to a more appropriate section, since this is not a newbie question but a proposal to solve a problem in Bitcoin, and it may be worthy of a proper discussion. Leave that to your judgement, if you will. Thank you for your attention.

Introduction

If Bitcoin is to be the next generation monetary system, it should consider or suppose that one day it will be the only means of transaction, and so every single transaction in the planet will be a Bitcoin transaction. Just imagine the transaction rate, and thus the blockchain growth rate. The growth of the block chain will become impractical to store--if it already isn't, which in my opinion is.

So the problem is: How to get rid of the dependency on the historical block chain?

My candidate solution

I am posting this here so you can find a flaw (or flaws) in this system. If you do, please post an answer and explain the flaw, and if possible, its solution too! (So long as it doesn't involve depending on the historical blockchain.)

What I think is key in finding the solution is the following consideration:

Quote

Once a transaction of funds is validated by enough nodes, the history of the coins involved in the transaction becomes irrelevant.

Now, from the above premise, I have designed a system which I now will submit to critique. What I submit below is an array of ideas organized as best as I could so the reader is suggested ideas and then explained whatever is not clear about them.

Please read patiently and keep note of whatever remains unclear as you read. If you have a list by the end of your reading of these ideas, please comment so and I will clarify for you with pleasure.

The system depends solely on a network of nodes.
A node has two capabilities in the network: participate in a transaction or witness one.
A transaction can only occur between two wallets.
Only a node can have wallets.
A node can have any number of wallets.
For a transaction to occur, the participating nodes must trust said transaction.
A node trusts a transaction when a minimum number of witness nodes it trusts have signed it.
The trust of a node is expressed with its signature.
A node can select to trust any number of other nodes.
A node signs a transaction when it trusts it.
Only a node can sign.
A node can only sign a transaction, or a wallet.
A node can only sign a transaction when it is not involved in it.
A node can only sign a wallet if it does not belong to the said node.
"Signing a wallet" is an action alias for the action of the signing of the state of a wallet.
When a node signs a wallet, the signing node sends the wallet owner node a certificate which attests that the signer node signed the wallet.
"State of a wallet" is an alias for the wallet's balance.
A node can only sign a wallet when the wallet is involved in a transaction, or when it is new.
A wallet is new when its balance is 0 and it hasn't undergone any transactions.
When a node creates a new wallet, it broadcasts a request for nodes to sign the new wallet.
When a node broadcasts a message, every node connected to it listens to the message.
A node cannot refuse to sign a new wallet.
"Signing of a transaction" is an action alias for the action of signing the final state of the two wallets involved in a transaction.
A transaction has two states:
The state before the transaction.
The state after the transaction.
When a node participates in a transaction, it broadcasts a request for nodes to sign it.
When a node requests one of its none new wallets to be signed by other nodes, it makes the wallet's certificates available to the latter nodes.
The signing of a transaction is considered by a node only upon a request.
A node signs a transaction when it trusts the initial state of both wallets involved in the said transaction.
A node signs a wallet only if a minimum number of the nodes it trusts have signed it.
A node only agrees to participate in a transaction when it agrees with the final state of the wallet(s) owned by it.
A node can only agree with the final state of one of its wallets when the user in control of the node commands it.
A user commands a node via any of its user interfaces, e.g. GUI and CLI.
A node can request its user for a command.
A node asks another for participation in a transaction only when the user of the first node commands so.
A node can cancel a transaction participation request if the requested node has not agreed.
When a transaction is completed, the participating nodes automatically discard all old certificates.
A certificate is old when it no longer certifies the latest transaction of a wallet.

I would expect myself to have left ideas behind (and thus concepts unclear,) for this is a long list. Please comment now if you see that there are unclear concepts.

Of course, this is just an outline of the system. I have intended to define the most essential aspects of it. The system shares some traits with the current Bitcoin system, like it is to be expected.