Transaction Foundations as Balance Snapshots

Development & Technical discussion about Timekoin.
Forum rules
Bug Collecting Database is Click Here
GitHub Account is Click Here
Post Reply
JohnES
Posts: 6
Joined: Tue Feb 18, 2014 1:47 pm

Transaction Foundations as Balance Snapshots

Post by JohnES »

In reviewing the documentation and the source code, I realized that although TimeKoin uses Transaction Foundations to improve the speed at which transactions for a certain time period are verified, there is no such roll-up feature for tracking balances (or other types of data) for public keys. Because of this, every peer must have the complete transaction history in order to determine the current balance of any public key.

Perhaps we can use the Transaction Foundation for more than just speeding up the cryptographic calculations when verifying requests. We could possibly use them to roll up all important data into a single "snapshot". This snapshot can be generated and hashed by each peer. The hash of the snapshot can then be recorded in the Transaction Foundation, making its contents verifiable.

One way this can be done is by performing an additional operation which generates a blob of data rolling up the balance of all public keys into a single list. This is already recorded in the balance_index table, so this would be trivial to generate. It can have the following format:

PublicKeyHash|T:Balance
PublicKeyHash|T:Balance

i.e.:

abd673920...|T:65
901ffe2bf...|T:25981

Each line would have a SHA256 hash of a public key, and the current TimeKoin balance. A SHA256 hash of the blob can be generated and stored with the Transaction Foundation. Peers will calculate and hash this blob independently, and all nodes will have to match up. If a node gets the hash wrong, it has a problem with its balance index, and will have to regenerate it.

As time moves forward and the next transaction foundation occurs, we take the blob values from the previous foundation, apply the changes that occurred since then, and generate a new blob. We hash the value and record it. Moving forward, rebuilding the balance index would be as simple as looking up the value stored in the previous foundation blob and applying the changes recorded since then.

This would effectively make every transaction foundation a complete snapshot of the current state of the TimeKoin system. This makes holding transaction history beyond the last foundation optional for peers that do not want to keep it, but allowing those peers to remain functional for enforcing the system rules (balance checking, etc). In order to make sure there is some payback for keeping history, we can limit TimeKoin generation to only those nodes that keep a certain percentage (i.e. over 70%) of history stored.

Just so we don't paint ourselves into a corner, we could make the format extensible, so when additional features appear that may use the transaction history to store other types of data (Easy Keys, etc), we can include these extra types in the snapshot as well. For instance, when storing Easy Keys in the transaction history, the roll-up blob can be something like the following format:

PublicKeyHash|T:Balance,EK:easykey1!expiration_time,EK:easykey2!expiration_time
PublicKeyHash|T:Balance

I think, overall, a solution similar to this would simplify many of the issues that could come up as the system grows. It would keep the effort needed to create a balance index fairly constant, while allowing peers with limited or fixed storage requirements to participate indefinitely.

Any thoughts?
Post Reply