[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.
Overview
EdenChain’s platform gives developers the ability to create their own blockchain systems through Namespace technology. It means that each Eden dApp can have full control over their chain configurations, which guarantees greater transparency and privacy. We named these independent blockchains Supernodes. System of independent Supernodes enables parallel execution, thereby allowing the platform to carry out a vast number of transactions simultaneously.
You may ask us a question. “What if one of these dApps (Supernodes) have malicious intents and manipulates the data? How would EdenChain audit all these blockchains for potential abnormalities?” That is 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.
Hypernode Anchoring System is the name we gave to the process narrated 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.
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.
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!
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.
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.
