As many of you are anticipating, EdenChain will release the MVP in April. We’re pleased to announce that there will be TWO MVPs to be demonstrated in April!

Today, we will allow our trusted community to have a sneak preview of EdenChain’s first MVP. 🙂

E-Explorer is EdenChain’s web-based utility program. The basic function is completed, and the team has engaged designers to beautify the UI / UX. The E-Explorer will be updated and enhanced in subsequent releases.

Technical description of the E-Explorer are as follows:

What is E-Explorer?

E-Explorer is a web-based block browser that allows you to browse EdenChain’s block information.

With E-Explorer, anyone can easily retrieve and view information about EdenChain blocks and transactions.

The most important features of E-Explorer development are summarized into two points. 1) ease of use, and 2) connectivity of related data.

1) Usability

The primary users of E-Explorer is the general public rather than developers, therefore the UI / UX must be approachable in that anyone can easily browse an account or specific transaction. Even for the users without in-depth knowledge of block-chain technology or EdenChain should be able to use E-Explorer with ease. Therefore, E-Explorer is designed so to be intuitively used without any preconceived knowledge.

2) Connectivity of Related Data

Connectivity of related data has been implemented in E-Explorer to improve the inconvenience that plague other Block Explorer. A block is the basic unit for transaction data processing in block-chain. Multiple transactions are contained in a block. Developers often find needs to check the transactions along with the contents of the block in the corresponding transaction. In existing Block Explorers, this job is not handy. However, in the E-Explore, we implemented functions to obtain detailed information by clicking on related data such as block, batch and transactions.

What Can You do With E-Explorer?

The main functions in E-Explorer is as follows:

Block Data Browsing

– Allows users to look into the blocks within EdenChain and identify the details.

– Allows users to look into the blocks within EdenChain and identify the details. Batch Data Browsing

– Allows users to search the batch list within the block and identify the details.

– Allows users to search the batch list within the block and identify the details. Transaction Data Browsing

– Allows users to search the transaction list within the batch and identify the details.

– Allows users to search the transaction list within the batch and identify the details. State Data Browsing

– Allows users to look into the state list within EdenChain and identify the details.

– Allows users to look into the state list within EdenChain and identify the details. Transaction Search

Stat Data Provision

– Allows users to identify the statistics data within EdenChain

The functions above are similar to standard Block Explorers. The Block Explorer allows you to see data related to the blocks in EdenChain at a glance and allows easy search of related data with a few clicks.

Architecture

The E-Explorer is designed as an independent client and server architecture. The E-Explorer also uses APIs to network with one another.

The most challenging part of designing the architecture was minimizing the client and server decoupling. By minimizing client and client and server decoupling, the server is able to add necessary functions or update the existing structure regardless of the programming language or architecture used in the client.

Constant updates to EdenChain such as new features and changes to existing architectures will inevitably affect the architecture of the E-Explorer.

Each update affects the E-Explorer’s client, which can produce adverse results in various aspects such as productivity and stability. Therefore E-Explorer was structured to be independent without affecting the server and client.

Since the client and the server have no relation with each other, they are designed to exchange data with each other using an API. Therefore, the change of the server does not affect the client and vice versa.

If you need to add a new function, you need to define the necessary API to the server. The client needs to fetch the required data through the added API and display the data according to the design.

The architecture of E-Explorer that illustrates this concept is shown below.

As described above, the E-Explorer Server and E-Explorer Client are designed to communicate only through APIs, not by creating a Client Page or generating data from a server.

Data Structure

The essential function of E-Explorer is to examine and search the contents of the block, batch, and transaction within EdenChain. Therefore, understanding the EdenChain data structure is useful to understand the E-Explorer as well.

The data structure of EdenChain is different from other block-chains in that there is data called “batch” between block and transactions. (blocks and transactions are the same concept as other block chains, so they are not explained separately.) Batch is a group that groups related transactions and plays an important role in error handling and scalability.

For example, suppose “Seller A” and “Buyer B” trade. In order for these two people to trade, the following series of tasks are required.

Checking Account Information for “Seller A”

Checking Account information for “Buyer B”

Checking the balance of “Buyer B”

“Buyer B” transfers to “Seller A”

In this case, a minimum of four transactions are required because each operation is a transaction. These four transactions are considered to be the same, because they are intended to deal with “Seller A” and “Buyer B” transactions.

If an error occurs during the process, all four transactions will be invalidated. Such proper handling of errors enables the Transaction speed and accuracy to increase drastically for the respective block-chain platform. This is why EdenChain uses Transaction Group Data called Batch.

Server

The primary role of the E-Explorer Server is as an API Server. Since the data requested by the client is made in JSON format and data is transmitted quickly, there is no need for UI related codes. The EdenChain API collects necessary information or connects to the database, then processes the data.

The Server is a kind of Dispatcher that executes a function that has an execution logic for the API called by the Client. Server should be able to process multiple API calls in a short time-span, so it is important to write a code that is concise and quick.

The E-Explorer Server was developed using the Django Framework, since the Django Framework is heavy, the Django Framework is not the best choice to use as an API Server, but Djano Framework was chosen considering that the framework was the mos favored by EdenChain developers.

Stateless Data



Since the E-Explorer server handles API requests of multiple E-Explorer clients, the server must be able to effortlessly increase the number of E-Explorer servers. In terms of performance, Python Django is not the best choice, so another method is required to ensure the scalability. In the future, as EdenChain becomes more popular, the number of E-Explorer users will also increase linearly. Therefore, the processing capacity of E-Explorer server needs to be solved by simply adding a server.

In order to apply such a method “Stateless Data” which does not have state information in the data to be used, is required. Since “Stateless Data” does not have state information that each server should share, API calls can be handled regardless of the server, so scalability can be relatively easily secured.

For example, when “Client A” requests two API calls, the API calls can be processed separately on different API servers and return the results. Because E-Explorer utilizes “Stateless Data” in the foundation of the program, it is possible to increase the processing capacity of API Server without difficulty by using Load Balancer.

Load Balancer

In order to achieve scalability by operating multiple API Servers, it is necessary to distribute incoming requests appropriately and deliver them to the running API Server. In this case, you can use Load Balancer. The diagram below shows the role of Load Balancer.

The Load Balancer is the end point exposed to the outside, and the E-Explorer Client calls the API to the Load Balancer without directly calling the E-Explorer Server. The Load Balancer sends it to the connected E-Explorer, processes the actual API call, and passes the result to the originally called E-Explorer Client.

Nginx is used as the Load Balancer. Nginx is a stable; high performance web server that is most widely used in the Apache web server. Nginex can also be used as a load balancer, a proxy server, and various other way.

Client

The E-Explorer Client is a Javascript-based stand-alone application that uses AJAX to communicate with the E-Explorer Server. Unlike the server, UI / UX is very important to the Client, so users should be able to use the Client without any prior learning and display various screens according to the appropriate event.

The main purpose of the E-Explorer Client is viewing the block information of EdenChain, so Grid and Form becomes the main component of the UI. Also, because the E-Explorer has a UI, the E-Explorer is easy to update functions and screens and add new functions.

Therefore, it necessary to design with such an architecture that does not affect the existing architectures while quickly responding to these requirements.

MVVM

The E-Explorer Client uses the Model-View-View Model (MVVM) architecture pattern. The most common architectural pattern for developing client programs is MVC (Model-View-Controller). The MVC pattern is advantageous in that the MVC separates the code according to each role, but there are also counter-properties.

The complexity increases with the increase of the web pages when applying MVC. Especially,what I do not like personally is that the criterion for the controller is not clear. When one writes some codes, the distinction of whether to put the controller in the View or put it in the Model becomes more difficult as the program becomes more complicated. The complexity becomes even more problematic if several people need to collaborate. If the code is not classified as Controller, View, or Model, then the benefit of applying MVC is lost in the first place.

Therefore, the EdenChain Team uses MVVM. The biggest advantage of applying the MVVM architecture pattern is that you can build the entire structure based on the View. Considering that the Client program is to display several prepared screens according to the user’s needs, we can see that MVVM is more suitable for client programs with UI than MVC.

Programmable Economy Platform, EdenChain !!

Stay tuned, and follow our social media channels for updates.

Website (Click)

Twitter (Click)

Telegram (Click)

Reddit (Click)

Facebook (Click)