[TD] Hypernode Anchoring Analysis – EdenChain

[TD] Hypernode Anchoring Analysis – EdenChain

Storing information on a blockchain virtual space is very much like storing items in a physical space. You need to know the address of the storage unit and the means to carry the items to the location.

Give me the address of the storage unit, please.

At EdenChain, we call the virtual blockchain address Namespace, as we are literally naming the space. The following is the schematic we chose for creating a Namespace in our Hypernode to store all the anchor hash values of TEDN transactions.

As the sole purpose of this particular Namespace is for EdenChain Hypernode to store all the transactional hashes from the circulating TEDN, we decided to keep the creator and the token owner of the Namespace identical to avoid the trouble of issuing a new private key.

As any blockchain stores information by the mean of executing a transaction, the “Creator” and the “Token Owner” for the CREATE transaction (assigning an address, Namespace, for this Anchor in our Hypernode) shows the same “From ADDR” and “To ADDR” in the E-explorer.

The above Namespace value that starts with 0f, is the Namespace ID (address) for all the future TEDN anchoring hashes. Just by checking the Namespace ID, we know that this hash value is for the anchoring of TEDN transactions. Now we have the address, how do we carry the information?

Do we need a rental truck? Help me carry these items to the storage!

As you probably already know, there must be an expiration of a token transaction to store data in a blockchain environment. As such, even simple data storage must be carried out as a token transaction. Therefore, anchoring appears on the E-Explorer as another token transaction. As this token transaction is only a mean to move the items to the storage (this transaction is the rental truck, per se), the token transaction of itself does not hold much value. What matters is the Meta Data, the transactional hash values from a supernode, TEDN transaction in this case.

We designed the system to carry out the process of anchoring in every few minutes to store all changes in a manageable size. To make the process efficient, we decided to assign the identical “From ADDR” and “To ADDR” to avoid the issue of generating a new private key for each new anchoring session.

As you can see, the Namespace (the address) tells you that this TX is for anchoring data for TEDN transaction. The time stamp tells you at which point the anchoring was done. The operation also shows you the purpose of the transaction. Because of the systematic design, it shows the same “From ADDR” and “To ADDR.” We set the token amount at the minimum, 1, simply to facilitate the transaction, and thereby storing the metadata in the blockchain. You can also see under Meta Data that it genuinely is for anchoring transactional data, nothing else. The value under “last_tx_id” in this section denotes the last Supernode transaction value included to create this particular Anchor hash.

Because of this, you may sometimes notice on our E-Explorer a token transaction with the same “From ADDR” and “To ADDR.” When you do, there is no need to alarm. It is a sign of added security for your protection.

Published at Tue, 02 Jul 2019 10:41:09 +0000