Eden is a permissioned blockchain consisting of three layers: a distributed ledger layer, a validation layer, and a bridge layer. The distributed ledger layer is a place in which data used in the blockchain are separately stored, and only data of transactions agreed to in the validation layer are processed. Distributed ledger data can be added through transactions. The validation layer is where a transaction is executed and verified; this layer includes an EVM that runs the smart contract. The validation layer has a transaction scheduling function, which has a significant impact on the performance and scalability of Eden.
The bridge layer is used to securely import data needed by an on-chain smart contract within the blockchain in cooperation with an off-chain. In the bridge layer, nodes naturally exist on-chain and off-chain, and an E-Protocol that implements can encryption technique called Elliptic Curve Cryptography –Threshold Cryptography (ECC-TC) is used for reliable communication between these nodes.
Distributed Ledger Layer
The distributed ledger layer provides decentralized database functionality to Eden and is used on the basis of the Linux Foundation’s open source project, Hyperledger. The DLL stores all data generated by Eden in a block. The data cannot be modified and can be only added. The DLL stores the data on a disk device and assumes that all of the stored data originated from a legitimate transaction.
The DLL can find the necessary data from the outside by using a block ID or a transaction ID, and also provides a function of accessing information about all transactions included in the block. The DLL has a BlockCache module to minimize disk access.
BlockCache mainly stores currently used blocks in memory, and when a requested block cannot be found, it reads the block from a disk and loads it into the memory. Depending on frequency of use, it is possible to determine blocks that should be kept in the memory and those that should not, and thus a cache effect with optimal use of memory can be achieved.
The Execution Layer (EL) executes, processes, and verifies transactions, providing important functions for the smart contracts running on the Eden platform.
Transactions must be used in order to update the data in Eden’s distributed ledger. The EL provides a Trusted Execution Environment (TEE) in which the transaction can be safely protected from data extortion or data forgery by hacker attacks. All transactions and key logic including smart contracts are executed in the TEE.
The EL has Transaction Execution Scheduling (TES) which specifies how transactions are to be executed and on which node. TES is an important technical factor that affects performance and can show different processing performances with the same computing resources depending on how transactions are managed and executed. TES also includes an Ethereum Virtual Machine (EVM) to run smart contracts written in Solidity. If a transaction being executed is a smart contract running on Ethereum, the EL executes the EVM.
The bridge layer (BL) is an important technical element that differentiates Eden from other blockchains and guarantees zero-knowledge trusted connectivity between on-chain and off-chain.
In Ethereum, smart contracts can interact with external systems using Oracle, but this does not guarantee trustworthiness of data from external sources. To realize a smart contract-based programmable economy it is necessary to secure trusted connectivity that enables the blockchain and external systems to securely function despite threats from hackers. Once trusted connectivity is secured, it is possible to expand functions by interacting with external systems and by automating various services.
The BL is composed of an on-chain module for interacting with a smart contract, an off-chain module for interacting with an external system, and modules for networking between the on-chain and off-chain modules. The on-chain module serves as a gateway for responding to external data requests required by smart contracts. The off-chain module fetches data requested with an on-chain module by accessing the actual external system; it then verifies the data, selects a specific value, and transmits it to the on-chain module. Since the on-chain and off-chain modules are located in different networks, they configure a network on which they can securely communicate and exchange data.
The above diagram shows service architecture of EdenChain from end to end.
The API module is the only one exposed to the public as it allows access to external systems.
It receives all kinds of requests and forwards them to corresponding modules. In that this way we can keep access points consistent and secure the platform by isolating the core modules from external systems.
EIAM plays an important role in service because it deals with internal communication in a secure manner. Sensitive transactions such as sending and receiving coins are supposed to have a signature and EIAM comes into the picture with a strong protection mechanism. dApp Server and dApp Client correspond to blockchain business applications. Those modules use Eden’s API and SDK to build the service.
We have an internal cache system to respond to clients’ requests quickly. Two kinds of query systems are introduced: file based and memory based ones. These internal cache system boost EdenChain ‘s performance.
Coin server is a dedicated module for handling coin related requests to minimize transaction handling time.
The transaction server processes most transaction except for coin related requests.
Hypernode & Supernode
EdenChain has adopted a sort of side chain into its architecture to achieve high performance, full controllability and security.
Eden’s blockchain platform gives developers the ability to create their own dedicated blockchain systems through the namespace technology. This means that each Eden DApp can have full control on their individual chain configurations which guarantees greater transparency and privacy. Each of these dedicated blockchain is operated through a specific set of super nodes/ super blocks. To ensure that the transaction data stored in each super blocks is fully secured, the transaction data hash key is stored in hyper nodes.
You can regard the supernode as a sidechain, the hypernode as EdenChain ‘s blockchain.
As the Eden network expands and the number of DApps increases, more super node/super block networks will be created to support greater platform scalability. In a network of 100 DApps for example, up to 100 super blocks can be created. As an additional layer of security, all transactional hash keys will be stored in the hyper node /hyper blocks network after the transaction is processed through the super blocks.
The below image explains dApp, super node and hyper node relationship.