DEP: an Innovation Workshop for Web 3 Applications

 

1.Introduction and Principle

Intro: Decentralized Edge-Computing Platform (DEP) is 

Web3 infrastructure based on Deeper Connect nodes. Through decentralized tasks executed via blockchain technology, each Deeper node may deploy different web2/web3 tasks and applications. Each node will act as an independent service provider, having ownership of its service and earning rewards by helping to execute, develop and maintain those services.

Basic Principle: Deeper nodes continuously monitor specific events through decentralized tasks published on the blockchain. Different execution workflows are triggered according to different events, and the application URL and operation parameters are parsed. The Runner is responsible for pulling, scheduling, and monitoring the execution status of tasks on the node. Task execution ends when certain conditions are met, such as execution time, block duration, etc.

Similar to the blockchain, this framework will create a decentralized launch environment, greatly simplifying the cost and effort of publishing a Web3 application; Traditional blockchains write Web2 data into the Web3 world. However, DEP will bring information back from Web3 into Web2, thus a closed loop blockchain ecosystem is formed.

2.Structure and Modes

The DEP consists of the Deeper-Chain and a Deeper-Edge-Device. All the Deeper-Chain devices send transactions and monitor the chain as a light-node. Devices monitor the event data in different formats.

Deeper-Chain is a high-performance chain developed based on Substrate which integrates EVM & WASM dual contract platforms, Ethereum & BSC dual platform cross-chain bridge, and customizes on-chain services such as device management, credit management, system management, micropayment module, and staking module, for all users and devices.  

Deeper-edge-device provides a free network with secure and privacy features, including advertisement filtering, malicious URL filtering, tracker blocking, and parental control; Privacy features, including the triple encryption technology, block device encryption, file and file system encryption, and the AtomOS operating system which provides a 7-layer firewall.

Figure 1

As shown in Figure 1, there are a couple ways for terminal nodes to interact with the chain. This includes the smart contract mode and the application chain mode. Currently, the DEP for the EVM contract is completed, and the DEP for the application chain mode is currently being worked on.

• All modes are categorized to be in either full-node mode, N-node mode or single-node mode.

① Full-node mode

When a node monitors this type of task, the execution file is analyzed according to the event content. The event parameters determine the start and end of a task. When the node completes the task, the "completeSubIndexForTask" transaction will be sent.

This mode is suitable for the tasks that require as many nodes as possible, thus consuming more EZC.

② N-node mode

When a node monitors a type of tasks, it first determines whether it can be executed based on the task authorization status of the node. And then the node sends "raceSubIndexForTask" transaction to win orders, and confirm whether the task is successfully won or not. Finally, the node executes based on the task parameter and analysis, and sends the "completeSubIndexForTask" transaction after completing the task.

This mode is suitable for a certain number of nodes to perform tasks, which can balance the costs and benefits. It is also the underlying implementation mode for most Web3 applications.

③ Self-developed mode

When a node monitors such tasks, its event contains a specific EVM_address. This can either be the developer's address or a device address which can be located in a specified place or time zone. Other nodes will filter for this type of task and after completing the task, the "completeSubIndexForTask" transaction will be sent.      

This mode is suitable for rapid development, debugging, or custom applications. It can be learned, explored, and practiced at minimal cost, and customized for developers.

• Based on the node’s address, it is divided into: Designated-node mode and Non-designated-node mode.

① Designated-node mode:

When a node monitors such tasks, it includes a specific set of evm_addresses. This represents a type of device, such as a device with a public IP address. It also represents ownership, such as the ownership of audio and video files after a contract transaction.

② Non-designated-node mode:

When a node monitors this type of tasks, its event does not include any node address. Therefore any node has the opportunity to pursue  tasks. This type of task is random and anonymous, and provides high security and privacy protection. The node will not reveal its position before completing the task, and the data will be written to the designated location on the blockchain after completing the task.

• Based on the execution modes, they are divided into short-term task modes and long-term task modes.

① Short-term task mode:

When a node monitors this type of task, its event parameter “maintainBlocks” is 0 or within 100 blocks. After this type of task is executed, resources will be released in a very short time to enable more applications to execute concurrently on the node.

② Long-term task mode:

When a node monitors this type of task, its event parameter “maintainBlocks” will be charged by increasing the coefficient by 1 for each additional 100 blocks. Such tasks will last on the node for a long time, such as maintaining decentralized websites, decentralized mail services, etc. Combined with the specified node, the service can be deployed to run on the appropriate node.

3.Application Scenarios

3.1 Web2 scenarios- stress test

Traditional stress tests are rigorous tests performed specifically to confirm the stability of a particular system or component. The user's service quality is tested according to the pressure measurement data. Let's use a video platform as an example where users watch videos at home or in their office. The server stress test results cannot truly reflect users’ actual viewing experience. This situation cannot be solved under the current technical framework.

3.2 Web3 scenarios- Oracle:

Traditional oracles are centralized and usually have fixed or public nodes. There are security risks associated with this because the oracle relies on centralized servers or a DevOps team to manually execute tasks. This creates a situation where there is a central point of failure.

When DEP processes oracle tasks, the process will be much more secure. When an oracle executes a task, the nodes responsible for executing the oracle are randomly chosen. The load and network status of network nodes also plays a factor.     

Using the DEP, most of the nodes executing an oracle are hidden on the Intranet. The difference from cloud nodes is that it is difficult for hackers to attack through reverse tracing to the IP on the Intranet. Even if they successfully find a Deeper device to attack, they still have to pass the Deeper 7-layer firewall and triple-layer file encryption system, which makes malicious attacks much harder, and nearly impossible. Due to the randomness of task distribution, the nodes that execute an oracle task this time may not be guaranteed to be assigned to execute the very next time.

Even if hackers were to somehow break into one Deeper device, the attack is much less effective and has very little impact on the network. Developers have the ability to control the task delivery frequency. They can choose their own economic solution based on the actual needs of their projects. Because most of the Deeper devices are placed in a users’ home, the operating costs can be significantly reduced and the service can be cheaper and more secure.

4.Future Plans

Deeper Network's goal for DEP is to provide developers with an easy and convenient Web2 / Web3 application infrastructure, enabling rapid deployment and startup of Web3 applications with the help of Deeper's decentralized hardware platform which has expanded to 150+ countries and 80,000 + nodes around the world.

 

 

Upcoming roadmap:

① Develop precompiled contracts, governance voting

② Develop multiple types of DEP interface, including application linking interface and WASM contract interface

③ Integrate Polkadot relay chain to provide cross-chain DEP call interface for other projects to request services

④ Provide Github URL mode to replace docker URL mode allowing off-chain code to be open source and transparent

⑤ Explore the Magnet URI scheme mode to provide users with privacy and directional file pushing capabilities

5.Reference Links

DEP contract code: https://github.com/deeper-chain/web3d/blob/master/contract/DEP.sol  

Stress Test Demo: https://github.com/deeper-chain/decoded-demo/tree/master/benchmark-demo 

Oracle Demo: https://github.com/deeper-chain/decoded-demo/tree/master/oracle-demo