6. Technologies

As mentioned earlier, in order to achieve the goal of decentralizing the deployment and operation of large-scale applications, Ethanim must abandon the traditional design approach and adopt a new blockchain architecture, and actively embrace new technologies and flexible upgrades to the system.

6.1 Technology Overview

6.1.1 Underlying Revolution

The Trias layer-1 blockchain solution based on trusted computing is introduced to change the implementation path of "seeking consensus among untrusted nodes" to "making nodes trusted and performing computation", breaking the performance dilemma of traditional blockchain from the root.

6.1.2 Technology Lego

Ethanim offers a modular technology architecture that consists of pluggable integration of virtual GPU, cross-chain, edge computing, decentralized storage and other technologies to form a metaverse comprehensive solution that can be continuously expanded and evolved.

6.1.3 Eternal Computing

The state snapshot of the application will be stored permanently, and even if the application is tampered with or shut down, anyone can restore the application to the state at any moment according to the state snapshot stored on the chain to ensure the decentralization, security, and eternality of the application.

6.1.4 Perfect Support for Traditional Development Languages

A developer-friendly approach is an important foundation for ecological establishment. Ethanim supports developers to develop large-scale decentralized applications using the development language they are accustomed to, which greatly lowers the threshold to develop blockchain applications.

6.1.5 Diverse Digital Asset Protocols

Ethanim supports applications to create various digital assets and is compatible with digital assets published by applications on any other blockchains. Thus, it can meet the needs of different digital assets in various scenarios in the metaverse and supports interoperability and compatible demonstration in different ecological applications to provide a basis for users to freely create the metaverse.

6.2 Ethanim System Architecture

6.2.1 Security Underlayer — Mainnet

The public chain of Ethanim is a new generation of value exchange network positioned to provide infrastructure and node management capabilities for metaverse operations. It aims to reconstruct people, space and applications, and to create a new system of value exchange that is secure, efficient, autonomous, stable, easy to use and transparent by using blockchain, big data, artificial intelligence, cryptographic security, XR devices, 3D rendering and other fusion technologies. It will allow all medium and large-scale centralized applications to move towards a decentralized world and build their own gorgeous and colorful metaverse space through a completely decentralized technical solution and XR devices and technologies.

In the current blockchain world, we only have some simple GameFi that is based on the decentralized procedure of a public chain. For more complex gameplay, all need to rely on the original centralized service, because smart contracts and public chains cannot support such huge and high concurrent computations. We are committed to making all medium and large applications decentralized, so we combine Ethanim public chain and the RSM trusted computing container technology to solve the current problem.

The overall architecture of Ethanim is similar to a blockchain system with multiple application chains. The main chain is responsible for the security of all application chains, and it is also Layer 2 of Ethereum and other public chains, supporting pluggable cross-chain methods such as ZK Rollup and Optimistic Rollup. The security of the mainnet can be enhanced by the Layer 1 public chain.

The nodes on the mainnet consist of a "consensus node" and a "validation node".

6.2.1.1 Consensus Node

Consensus Mechanism

As the most important part of blockchain technology, after years of technical development, the consensus mechanism has introduced a variety of consensus algorithms, such as the most popular Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS) and Proof-Of-Authority (PoA), etc. But decentralization, security and performance can't be met at the same time. So that everyone has to make a choice, and different priorities are developed into different branches, especially for decentralization and performance, forming opposing ideas.

The Ethanim team adopted the Heterogeneous Consensus Graph (HCGraph) algorithm from the Trias Leviatom network, which combines heterogeneous TEE technologies (TPM, TXT, Intel SGX, ARM TrustZone, etc.) with graph computation algorithms (similar to Hashgraph or DAG). Heterogeneous TEE allows Leviatom to quickly identify misbehaving nodes while eliminating dependencies on any single technology provider, such as Intel SGX-based consensus that requires a strong reliance on Intel's centralized online verification service. At the same time, HCGraph's gossip protocol significantly reduces redundant TEE authentication while retaining a scalable and robust trusted network.

Service of Consensus Node

Perform the shuffle algorithm: The selection of consensus nodes for the Ethanim public chain is done by a committee using the shuffle algorithm. The verifiable random function (VRF) algorithm running on the mainnet is randomly assigned. The assignment results are locally verifiable by the verifier, but are invisible from the network to avoid attacks. Each subset performs consensus voting on the RSM in the network. To enhance security, only the votes that exceed a security threshold for the specific number of validation nodes are recognized by the mainnet, otherwise, multiple rounds of voting are conducted.

The shuffle algorithm will select a set of consensus nodes for each round of operation. We randomly select an axis point in each round and randomly choose whether to replace each consensus node in each round. And the calculation of the axis position is optimized, which solves the inefficiency problem derived by shuffling the whole consensus nodes each time. The efficiency is greatly improved in each round of shuffle.

Consensus on validation results: Unlike consensus acceleration techniques above the consensus layer (e.g., layer 1 or layer 2 improvements), Leviatom addresses the performance problem by tapping into one layer "below" the consensus layer: to achieve improvement on Layer '-1'. Layer '-1' focuses on building trusted relationships between voting nodes. Its main goal is to identify the set of nodes that are most difficult to "lie", i.e., the difficulty of executing an unexpected procedure without being identified. It also solves the problem of managing redundancy by performing remote proofs between nodes by introducing a transfer-matrix of trusted relations with the multi-partition operators of Applied Mathematics. With this matrix, Leviatom only needs to select a few nodes with the highest values as voting nodes to perform consensus procedures on target transactions, which greatly improves consensus efficiency.

Provide hash index: When Leviatom completes the selection and block generation of consensus nodes, the consensus nodes will also pack the hash index of application snapshot files into the blockchain ledger, and will undertake the retrieval of application snapshots in the eternal file system when application recovery requests are received. Everyone can retrieve and check the date and backup of past data snapshots through the records of the hash, and check whether the data has been tampered with, etc.

6.2.1.2 Validation Node

Introduction

The validation node is the "miner" program in Ethanim public chain system, which is like the miner in BTC and ETH 1.0. In BTC and ETH public chain system, the block is generated by the miner who packages the transaction and participates in the hash calculation. The generator of each block is the first miner who solves each question of the miner. The block will become the current block and the miner will get the block reward, which is the proof of work. In Ethanim public chain, also has miners, but we do not need to compete for the calculation of the block question, the work of the validation node is mainly involved in the RSM for heartbeat linking and trusted validation, which has reached the final consensus.

Validation nodes can be installed and deployed by anyone at low cost on servers, laptops, or even cell phones. Building validation nodes requires staking Ethanim mainnet tokens, and when validation nodes do evil, they will be punished. The number of validation nodes can be expanded at any time according to demand, and can cope with the security needs of applications at any scale.

Validation Mechanism

Validator: The operator of the validation node is called the validator, which is a "virtual miner" in the Ethanim system who signs and votes on the trusted state of the RSM. These votes are recorded in the mainnet, which mainly records the validator address, state, proof and the validated address of RSM of each validator. Validators need to register with the mainnet for activation.

Committee: A committee is a subset of dynamic validation nodes that are randomly assigned by a verifiable random function (VRF) algorithm running on the mainnet. With the assignment results are locally validated by the validator but invisible from the network to avoid attacks. Each subset performs consensus voting on the RSM in the network. To enhance security, only votes that exceed a security threshold number of validation nodes are accepted by the mainnet, otherwise, multiple rounds of voting are performed.

Validation period: The committee members are replaced periodically instead of holding the position permanently. The duration of each turnover is called a validation period. The validation period is set to a reasonable length in order to ensure that the validation of the subset can reach consensus effectively and to avoid the validation nodes within the subset having time to collude and do evil. Verification nodes can verify each other and perform challenge proofs to get rewards.

RSM - validation node - validator - committee forms a complete chain. The work from block generation to validation is divided into parts with mutual constraints and supervision. Under the premise of ensuring security, it aims to improve as much as possible block generation efficiency and computing performance and avoid the waste of a lot of resources. The trusted computing container technology on the RSM implements the original decentralized miner node in another way.

6.2.2 Decentralized Service Layer — Reliable State Machine

The core component of Ethanim, similar to a "sandbox", runs on a computing node and places the server side of large metaverse applications in a trusted environment. The program is constrained and verified by a reliable state machine. It simplifies complex computational validation to trusted state verification, which significantly improves consensus efficiency and raises the throughput of decentralized applications to a new level. It completely revolutionizes the consensus method of blockchain.

The RSM uses SHA256 checksum verification to verify the integrity of the application code from time to time and uses a whitelist sequence detector to continuously validate the process to determine the trusted value. Then detects whether the system has been tampered with. Once the application runs abnormally or the RSM itself is damaged, it outputs a false trusted state to the validation node to shut down the program and disable data transmission, so as to minimize the loss caused by the attack and thus ensure the integrity of the application system operation.

Meanwhile, the RSM continuously clones snapshots of the application state and stores them on the storage nodes and keeps the hash index of the data on the main chain. Anyone can address the application state snapshot based on the hash index of the main chain and restore the application to the trusted state at any moment entirely.

This allows applications to balance performance with decentralization and be "eternal".

6.2.2.1 Operation Principle

Trusted Container

At present, Trusted Computing attracts much attention. When it is combined with Docker, the most popular lightweight virtualized container system nowadays, the Reliable State Machine(RSM) is implemented.

Docker has some advantages in development and operations: faster delivery and deployment, more efficient resource utilization, easier migration, scaling and simpler update management. In addition, Docker has the most obvious performance benefits. The traditional virtualization methods have a virtual GuestOS for each virtual machine, which requires additional OS overhead. Docker containers use a common host OS and consume no additional system resources beyond running the applications in the container. In a recent survey by the Linux Foundation, Docker is the most popular open-source project for cloud computing after OpenStack. Google, Microsoft, Amazon and other companies have implemented support for Docker on their cloud platforms. They also make some new attempts with Docker, such as using Docker to migrate web services to cloud services. It's obvious that Docker is popular in the industry.

However, Docker still has many problems, for example, users in the container can access the underlying resources without permission, the container itself can be tampered with or the container services can be invaded. These security risks have become a key factor to hinder the development of Docker. From the various security problems found in Docker, we can see that Docker mirror images and containers are at risk of being tampered with, while incomplete isolation leads to the risk of unauthorized communication between containers. The malicious processes or malicious data inside containers also bring risks to Docker systems and even hosts. Due to its incomplete isolation, it is possible to introduce trusted reinforcement, such as trusted computing, a chain of trust, Hook, etc. It constructs a chain of trust from hardware to processes and files inside containers and adds a security protection module that includes three major functions in process monitoring, file system metrics, and network monitoring. This provides all-round metrics and fine-grained monitoring for Docker, and builds a secure and reinforced Docker trusted container system. When our application generates a Docker reliable state machine through the builder, the corresponding hash encryption signature is uploaded to Ethanim public chain by the builder. Then the trust chain completes the closed loop, and then the validation client periodically validates the trusted state and integrity of the Docker.

Trusted State

The RSM trusted container has a complete life cycle from the first official building completion to the state release. The first validation is done by the official, then the RSM trusted container of the project comes in the state of hosting, where the daily operation needs to consume the token of the corresponding account as running costs. The RSM trusted container is in a trusted state, and the program can run normally. The RSM trusted container provides services to the outside world, then there will be a validators' node to validate the RSM trusted container periodically. When validation is needed, the RSM trusted container becomes the state to be validated. In this state, the RSM trusted container can still provide services and run for one validation period, or it will enter the abnormal state. If it is not validated in three consecutive periods, it will be switched to a state signaling red and stop service. After the RSM trusted container is validated again, it will enter the recovery state to start running and gradually resume restricted service. The trusted state will be restored to normal operation and service after three successive validation.

6.2.2.2 Management Operations

Management: The management of the project is the sole responsibility of the DAO community, and Ethanim provides DAO community management tools. The project should establish the corresponding DAO community before applying for the online RSM trusted container. All the online releases, modifications, deletions or any code upgrade of the project need to initiate a bill vote through the DAO community. If it passed, you can get the corresponding hash validation value, which is used to upgrade, start and stop the project.

Application code upgrade: As a decentralized metaverse infrastructure provider, we require the management of applications to be decentralized as well. So the management of applications is the responsibility of the corresponding DAO community, which gives the right to each application participant. When there is an attack or the application developer is out of touch, the DAO community can initiate a bill, and can pass a vote to pull up the backup in the eternal file system, which allows the application to continue service. When the further development and function upgrade of the application requires upgrading the code in the RSM trusted container, a bill needs to be initiated in the community for voting. When the DAO community vote exceeds the threshold, the bill will be passed, and the contract associated with Ethanim public chain will distribute the hash validation value for the upgrade, which is obtained by verifying the signatures of the submitted application and the DAO community by submitting the bill number. When the application code is upgraded, the RSM trusted container will be rebuilt. The container program will verify the hash value and submit it to the chain to permanently record the code upgrade.

Application successor: When the application is not maintained by the developer or the project, or when the project is lost or the right to maintain the application is abandoned, a vote can be initiated by anyone in the DAO community to perform application backtracking, which will pull up the last backup application or restore the application in the current RSM trusted container to service. The person who initiates the vote will automatically be granted the status of application successor, and a vote can also be initiated in the DAO community to elect a successor. The newly elected member will assume the development and maintenance of the application, and the revenue and support will be inherited by the successor.

Expense account: The RSM system will generate an expense account for each application, which is maintained by the Ethanim public chain, and will charge a certain amount of EPU daily as running cost according to the size of the application, service frequency and network usage. When the balance of the expense account is estimated to be insufficient, the DAO community and the application owner will be automatically reminded to recharge the account. The insufficient expense will cause the application to enter an abnormal state.

6.2.3 Decentralized Storage Layer — Eternal File System

6.2.3.1 Introduction

The eternal file system is a decentralized storage system that is run and maintained by storage nodes. Anyone can contribute their hard disk storage to become a storage node.

The storage node is mainly responsible for storing snapshots of the application state output from the RSM, code files of the application, etc. The files are sliced into multiple hashes. After hashing encryption, Merkle roots are generated to verify the stored evidence. Meanwhile, the hash index of the files is packed by the consensus node to the ledger of the mainnet. When the application needs to be restored, the computing node can run the RSM, query the hash index from the mainnet, obtain the application code and state snapshot file at the storage node, and restore the application to the state at any moment.

6.2.3.2 Operation Principle

The eternal file system is a distributed storage system composed of several modules such as storage nodes, file slicing system and file propagation network. When the user's data is uploaded, it will be sliced and hash encrypted by the file slicing system, and finally, the slices will be transferred to different nodes with space for storage. When users download the file slices, the current node will find the corresponding file hash to get the address of the stored node, download all parts and merge them to the original file. This process uses P2P discovery network technology for file transfer, where the storage nodes form a huge network. The whole network maintains a huge file index hash table, where its items follow the form <Key, Value>. The Key is usually the hash value calculated by some hashing algorithm according to the file (it can also be the file name or file content description), and the Value is the IP address of the stored file. When querying, only the Key needs to be provided to query the address of the storage node from the table and return it to the query node.

We use a layered architecture and protocol services. The overall system is divided into the connection layer, the routing layer and data block exchange layer, and it also provides the traditional HTTP protocol and RPC protocol, as well as file system. It can also define folders and files, which is easy for users to manage files and mounting file systems.

The eternal file system adopts a blockchain encryption mechanism, all users' files need to be encrypted by the private key. Users need to provide the correct key for file reading, modification, deletion, etc. The system uses the public key to verify the key signature of the operation, the public key is managed by the system in the storage file.

6.2.3.3 Storage Nodes

Storage nodes are the most important part of the eternal file system and are the most basic component in the eternal file system network, which is responsible for basic tasks such as distributed storage and file slicing.

At present, the storage node in the eternal file system is designed as a set of open-source node programs, and users can choose different language versions of node programs by device and build storage nodes on their own devices. After the program is successfully built, it will automatically link to the surrounding storage nodes to undertake storage tasks. The tasks will be received and completed according to the current device's computing power and storage size. The node program will detect the device's hardware and monitor the device's operation. The node program can link to user's Ethanim wallet, and the nodes involved in the storage task will receive the token as rewards after completing the tasks.

6.2.4 Decentralized Rendering Layer — Meta GPU

6.2.4.1 Introduction

The metaverse needs larger scale and higher quality requirements for image computing, while there are billions of idle GPUs distributed around the world. Even for the physical machine clusters in the same IDC room, sometimes the computing resources can not be reasonably allocated. It may result in overload on some devices, while remaining a high idle rate on other devices. The contradiction between demand and resource waste is obvious.

As a key component of Ethanim, the Meta GPU is a metaverse-oriented image computing solution. With virtual resource pooling, distributed computing and edge computing, the system can be more decentralized while increasing the computing power by virtualizing and pooling the distributed idle GPU resources into a "pool" and supporting applications to allocate on demand. This virtual GPU technology is indispensable in distributed systems for metaverse applications, especially for screen rendering of large game applications.

The metaverse applications will require far more image computation than traditional applications, which increases pressure on centralized computing. Ethanim's Meta GPU regards the GPU hardware devices as virtual resources in terms of computing power, which aggregates GPU devices with lower computing power to process large computation tasks. The GPU devices with high computing power can also be split to process multiple small-scale computations in parallel to improve resource utilization. At the same time, edge computing technology can be used to allocate computing tasks to the computing resources closest to the users. It can reduce the impact of network latency on applications and significantly improve the experience of using online applications.

Meta GPU is an optimized refactoring of GPU resources from the point of view of hardware, which has no impact on the software level of the application. The developers can still use the original methods to develop software.

6.2.4.2 Operation Principle

The rendering computing "pool" is built by the Meta GPU program, where the rendering node is the basic unit of this "pool". The rendering node is a set of open-source programs that will find the same programs and automatically compose the pool of rendering computing power. When an image computation task that needs to be rendered enters the rendering pool, the pool will select the rendering node that matches the computing power requirement, and idle devices will undertake the task. The pool maintains the hardware conditions and current busy level of each node, and allocates tasks according to the current work of the nodes in the pool and the computation volume of the current task. When the computation of the task is very large, the task will be split into multiple and assigned to different nodes for computing and rendering, and finally the complete results will be merged into the public chain.

6.2.4.3 Rendering Node

The rendering node is a metaverse-oriented image computing solution, which is an important part of Ethanim and the most basic component of the rendering computing "pool" network. It is responsible for the basic task of image computing. We will open source the node program, and users can choose different language versions of the node program by the device to build rendering nodes on their own devices. The pool of rendering computing is responsible for receiving and completing tasks, which is the drawer of visual effects in the Ethanim metaverse.

6.2.5 Visual Presentation Layer — XR devices

6.2.5.1 Overview

XR refers to a combined real and virtual, human-computer interactive environment generated by computers, artificial intelligence and other technologies as well as wearable devices. Extended reality (XR) includes virtual reality (VR), augmented reality (AR) and mixed reality (MR), and is known as the ultimate form of future virtual reality interaction.

At present, the application of XR technology in games, movies and other commercial fields has been developed, in a human science fiction novel "Snow Crash" which explores virtual reality, the main character can see, hear, smell and even touch everything in the virtual world after wearing a pair of special glasses. In the future, XR technology, supported by 5G, artificial intelligence, big data and other technologies, will further break the boundaries between virtual and real environments and promote changes in human-computer interaction, enabling people to "see" and "hear" scenes and objects that are actually inaccessible to them. Further, the field will be expanded to a deeper and wider space. At that time, virtual reality technology will be presented in a new form in front of people.

With the development of technology, the current XR devices are diverse, with headgear, XR glasses, gloves, handheld sensors, etc. Perhaps in the future, there will be XR space capsules, so that we can have a more immersive metaverse experience.

6.2.5.2 Technical Principles

Among the XR-related technologies, SLAM is an important one. SLAM stands for Simultaneous Localization and Mapping, which refers to the process of building a map of the environment while calculating the position of the moving object based on the information from sensors. Currently, the main application areas of SLAM are robotics, virtual reality and augmented reality. It has been adopted in the localization of the sensor itself, as well as following path planning and scene understanding.

With different types of sensors and installation methods, the implementation and difficulty of SLAM can vary greatly. According to the sensors, SLAM is mainly divided into two categories: laser and vision. Among them, laser SLAM has been studied earlier, and the theory and engineering are more sophisticated. Currently, most vision solutions are in the laboratory research stage, with few practical product applications. It has been nearly 30 years since SLAM was proposed in 1988. Early SLAM research focused on using filter theory to minimize the noise of motion body poses and land marker points of maps. Entering the 21st century, researchers began to draw on the approach in SfM (Structure from Motion) to solve SLAM problems based on optimization theory. This approach has achieved some and has achieved a dominant position in the field of visual SLAM.

Visual SLAM can be divided into three categories: monocular, binocular (multi-nocular), RGBD, and there are also special cameras including fish-eye and panoramic. SLAM on monocular camera is shortened to MonoSLAM, which can implement SLAM with only one camera. The biggest advantage is that the sensor is simple and inexpensive, but there is also a big problem in that the depth cannot be obtained exactly.

On the one hand, monocular SLAM cannot get the real size of the robot motion trajectory and map because the absolute depth is unknown and if both the trajectory and the room are enlarged twice, the monocular will see the same image. So the monocular SLAM can only estimate a relative depth. On the other hand, the monocular camera cannot rely on one image to obtain the relative distance of the object in the image from itself. To estimate this relative depth, the monocular SLAM has to rely on triangulation in motion to solve for the camera motion and estimate the spatial location of the pixels. That is, its trajectory and map can only converge after the camera motion. If the camera is not in motion, you cannot know the position of the pixel. Also, the camera motion cannot be purely rotational, which creates some problems for monocular SLAM applications. Unlike monocular cameras, the stereo vision of binoculars can estimate the depth both in motion and at rest, which eliminates the troubles of monocular vision. However, the configuration and calibration of binocular or multinocular cameras are more complex, and their depth range is limited by the baseline and resolution of the binoculars. Calculating pixel distances from binocular images is a very computationally intensive task, which is now mostly done with FPGAs. We combine Meta GPU to switch different cameras such as monocular, binocular and RGBD for building visual effects in different scenes, which is expected to solve the above disadvantages of different cameras.

The architecture of the visual SLAM framework consists of roughly five parts.

Sensor Data: It is mainly for the reading and pre-processing of camera image information in vision SLAM. In robotics, there may also be reading and synchronization of information from code disks, inertial sensors, etc.

Visual Odometry: The main task of visual odometry is to estimate the camera motion between adjacent images and what the local map looks like. The simplest is to predict the motion relationship between two images. How the computer determines the camera motion from an image. Given an image, we can only see one pixel at a time and know that they are the result of the projection of certain spatial points onto the imaging plane of the camera. So we must first understand the geometric relationship between the camera and the spatial points. Visual Odometry (also called front-end) is able to estimate the camera motion from the images between adjacent frames and recover the spatial structure of the scene. It is called an odometer because it only calculates the motion at adjacent moments and is not associated with past information further back in time. The adjacent moment motions are concatenated to form the robot's motion trajectory, thus solving the localization problem. On the other hand, the map is obtained by calculating the location of the spatial points corresponding to each pixel based on the camera position at each moment.

Backend optimization: It is mainly to deal with the problem of noise in the SLM process. Any sensor has noise, so in addition to dealing with "how to estimate the camera motion from the image", it also has to be concerned with how much noise this estimate carries. The front end provides the data to be optimized and the initial values of these data for backend, while the backend is responsible for the overall optimization process. The backend only deals with the data and does not care about where the data comes from. In visual SLAM, the front end is more relevant to the field of computer vision research, such as feature extraction and matching of images, while the backend focuses on filtering and nonlinear optimization algorithms.

Loop Closure Detection: Also closed-loop detectioin. It refers to the robot's ability to identify scenes that have been reached before. If the detection is successful, it can significantly reduce the cumulative error. Loop closure detection is essentially an algorithm that detects the similarity of observed data. For visual SLAM, most systems use the Bag-of-Words (BoW) model, which is currently more sophisticated. The Bag-of-Words model clusters visual features (SIFT, SURF, etc.) in an image and then build a lexicon to find which word is contained in each image. Some researchers have also used traditional pattern recognition methods to regard loop closure detection as a classification problem and train classifiers to classify them.

Mapping: It is mainly to build a map corresponding to the task requirements based on the estimated trajectory. In robotics, there are four main types of map representations: grid maps, direct representations, topological maps, and point feature maps. The feature point map is a representation of the environment with relevant geometric features (e.g., points, lines, and surfaces), which is commonly used in visual SLAM. These maps are generated by vSLAM algorithms(such as GPS, UWB) and cameras with sparse methods, which have the advantage of relatively small data storage and computation, and are mostly used in the earliest SLAM algorithms.