[TD] Hypernode Anchoring Analysis

By July 2, 2019 English

[TD] Hypernode Anchoring Analysis

Today, we would like to address a key feature in EdenChain’s platform: Hypernode Anchoring System. It is a unique technical component of the EdenChain platform that makes it scalable and accessible while simultaneously maintaining a high level of security. To better explain the system, let us first give you an overview of our platform design.


Structure of EdenChain’s Platform

EdenChain’s platform gives developers the ability to create their own blockchain systems through Namespace technology. This means that each Eden dApp can have full control over its chain configurations, which guarantees greater transparency and privacy. We named these independent blockchains Supernodes. A system of independent Supernodes enables parallel execution, thereby allowing the EdenChain platform to carry out a vast number of transactions simultaneously.

A reasonable question might be “What if one of these dApps (Supernodes) has malicious intent and manipulates data? How can EdenChain audit all these blockchains for potential abnormalities?” That’s actually a great question. At EdenChain, we store all transactional hash keys from Supernodes in an upper-level blockchain. If there are any changes made to Supernodes after the fact, then it will affect these hash keys and inform us of the modifications. We named the upper-level blockchain created for data integrity Hypernode.

The Hypernode Anchoring System is the name we gave to the process described above; the process of storing hash keys from Supernodes to the Hypernode to guarantee the integrity of our blockchain structure.

Hypernode Anchoring Analysis

Anchoring is one of the many roles the Hypernode plays. N number of transactions from a Supernode are hashed, then the hash value is stored in the Hypernode. This value will respond to any modification done to the transactions at later points; therefore, it audits the data stored in Supernodes from potential attacks.

EdenChain’s Anchoring system differs from that of Bitcoin. Bitcoin uses different wallet addresses when performing Anchoring Transaction. However, EdenChain Anchoring Transaction is done using different Namespace IDs.

Storing information on a blockchain’s 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 process of assigning an address to a virtual blockchain location Namespace, as we are literally naming the space. The following is the schematic we chose for creating a Namespace ID 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 ID identical to avoid the trouble of issuing a new private key.

How we created an address (Namespace) in the Hypernode for anchoring TEDN transactions

Since a blockchain stores information by means of executing a transaction, assigning an address is also done as a token transaction. As such, the “Creator” is assigned to “From ADDR,” and the “Token Owner” to “To ADDR” for the CREATE transaction (creating an address, Namespace ID, for this Anchor in our Hypernode), and they are identical for the reasons stated above. Below is what you see on the E-Explorer.

E-Explorer showing records for the CREATE transaction for the Anchor designated for TEDN transaction hashes

The above Namespace value that starts with 0f is the Namespace ID (address) that will be assigned to 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 that we have the address, how do we carry the information?

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

How we created an anchor hash value

As we mentioned earlier, a token transaction must be executed 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 mechanism to move the items to storage (this transaction is the rental truck, per se), the token transaction itself does not hold much value. What matters is the Meta Data, the transactional hash values from a Supernode, which in this case is a TEDN transaction.

We designed the system to carry out the process of anchoring every few minutes in order to store all changes in a manageable size. To make the process efficient, we decided to assign identical “From ADDR” and “To ADDR” to avoid the issue of generating a new private key for each new anchoring session. This system can be likened to a boomerang that shuttles back and forth between the Creator (a Supernode for TEDN TXs) and the Storage Unit (the designated Namespace ID), loading and unloading information (transactional hashes) between the two locations.

E-Explorer showing records for a TRANSFER transaction for the Anchor designated for TEDN transaction hashes

As you can see, the Namespace (the address) tells you that this TX is for anchoring data for a TEDN transaction. The timestamp 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, to simply facilitate the transaction and thereby store the metadata in the blockchain. You can also see under Meta Data that this TX was done solely for anchoring transactional data, nothing else. The value under “last_tx_id” in this section denotes the last Supernode transactional value included to create this particular Anchor hash.

For these reasons, 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 be alarmed: it is a sign of added security, enabled for your protection.