A decentralized application architecture and construction method

Abstract

This invention discloses a decentralized application architecture and its construction method, belonging to the field of computer software architecture. The decentralized application (DApp) architecture includes an extended blockchain, a DApp front-end presentation layer, a logic business layer, and a data layer. These four parts work together to achieve the functional deployment and operation of the decentralized application. The decentralized application architecture integrates decentralized storage, decentralized databases, decentralized container services, the Web3 domain name system, and the basic blockchain to build a standardized decentralized application ecosystem. The decentralized application architecture construction method includes steps such as architecture deployment, service registration and discovery, data storage and interaction, container service scheduling, and fault self-healing. This invention effectively solves the problems of high storage costs, insufficient single-machine performance, and limited functionality in traditional decentralized applications, and is particularly suitable for decentralized application scenarios such as instant messaging, distributed social networking, data and application service sharing, and AI artificial intelligence agents.

Description

Technical Field

[0001] This invention belongs to the field of computer software architecture, specifically involving blockchain technology, decentralized application development, distributed storage and container services, etc. Background Technology

[0002] Currently, decentralized applications (DApps) largely rely on blockchain as a storage and logic execution platform, which presents three major pain points: First, storage costs are high, as writing data to the blockchain incurs fees, and frequent data interactions lead to a significant increase in user costs. Second, performance is limited, as the complexity of smart contract logic and read / write speeds are bottlenecks, making it difficult to support complex functions and high-concurrency scenarios. Third, the ecosystem is incomplete, with storage and service logic coupled on-chain, resulting in high barriers to DApp development, poor scalability, and limited practical application promotion. Existing technologies have attempted to introduce decentralized storage to optimize data storage, but have not addressed the core limitation of service logic relying on smart contracts. Other solutions optimize smart contract execution efficiency, but have not formed a standardized decentralized application architecture, making it difficult to adapt to diverse application needs. Therefore, there is an urgent need for a new application architecture that can separate on-chain storage and service logic while retaining decentralized characteristics, achieving synergistic optimization of cost reduction, performance improvement, and functional expansion. Summary of the Invention

[0003] This invention aims to provide a decentralized application architecture and implementation method based on extended blockchain. By building a standardized decentralized infrastructure, it solves the problems of high storage costs, insufficient performance, and limited functionality of traditional decentralized applications (DApps), and achieves efficient development, low-cost operation, and large-scale promotion of decentralized applications.

[0004] Technical solution of the present invention

[0005] A decentralized application architecture includes an extended blockchain, a decentralized application (DApp) front-end presentation layer, a logic business layer, and a data layer. These components work together to enable the deployment and operation of the decentralized application. The specific structure is as follows:

[0006] • Extended Blockchain: As a core infrastructure of the architecture, extended blockchain, also known as generalized blockchain, consists of at least a basic blockchain, decentralized storage, decentralized database, decentralized container service, and Web3 domain name system, providing applications with decentralized storage, computing, service scheduling, and resource discovery capabilities;

[0007] • DApp Front-end Presentation Layer: This refers to the front-end presentation layer of decentralized applications (DApps), which serves as the user interaction entry point. The DApp front-end presentation layer consists of at least the decentralized application DApp front-end interface module, identity authentication module, service addressing and connection management module, interaction adaptation and terminal feedback module, data encryption module, and local logic business module.

[0008] • Logic Business Layer: This is the core function execution unit of the application, consisting of custom services deployed by the developer. It runs in an equivalent container of the decentralized container service, replacing traditional smart contracts to implement backend logic processing. This layer interacts with the data layer through remote procedure call interfaces to complete data CRUD operations and complex business logic calculations. All container functions are equivalent and independent of each other, ensuring the decentralized nature and high availability of the system.

[0009] • Data Layer: This layer serves as the data storage carrier, consisting of decentralized storage and a decentralized database. It is responsible for storing the business data, configuration files, and container images required for application operation. Through the address resolution service provided by the Web3 domain name system, it enables efficient data interaction with the logical business layer.

[0010] in,

[0011] The components of a blockchain can be expanded as follows:

[0012] • Basic blockchain: Provides an account system, public and private key encryption mechanism, and transaction record storage function to ensure the legitimacy of user identity, data privacy and security, and the immutability of operations;

[0013] • Decentralized storage: Stores large amounts of unstructured data and files, alleviating storage pressure on blockchain and reducing data storage costs;

[0014] • Decentralized database: Supports multiple data structures such as key-value pairs, logs, and documents, enabling efficient management and cross-node synchronization of structured data;

[0015] • Decentralized container service: Composed of computing resources contributed by container providers, it provides a runtime environment for custom services in the logical business layer, and achieves load balancing and fault tolerance through container clusters;

[0016] • Web3 Domain Name System: A decentralized domain name resolution system based on blockchain that maps resource names to addresses, providing a unified entry point for service discovery and resource access;

[0017] The components of the DApp front-end presentation layer are as follows:

[0018] • DApp front-end interface module: responsible for user interface display and user interface input reception;

[0019] • Identity Authentication Module: Responsible for the management of local identity and extended blockchain accounts; the identity authentication module is based on the blockchain account system, supports public and private key signature verification, address verification and hierarchical permission functions, interacts with blockchain nodes through Web3 interface to complete user identity confirmation, automatically adapts to the account permission rules of the extended blockchain, and ensures that only legitimate users initiate operation requests;

[0020] • Service Addressing and Connection Management Module: Responsible for obtaining the service URI of the logical business layer and the service of the data layer through the Web3 domain name system; the Service Addressing and Connection Management Module resolves the SDK through the Web3 domain name system, supports fast mapping of resource names to service URIs and storage addresses, can automatically cache the resolution results and update them periodically; at the same time, it provides adaptive management of long connections and short connections, switches the connection mode according to the business scenario, and ensures stable communication with the container service of the logical business layer;

[0021] • Data encryption module: Responsible for encrypting and decrypting various types of data; the data encryption module integrates symmetric and asymmetric encryption dual encryption mechanisms to perform hierarchical encryption on user input data and interactive commands; it supports automatically converting encrypted data into a format compatible with extended blockchains, adapting to the data storage specifications of decentralized storage and databases;

[0022] • Local logic business module: responsible for the specific functional business of decentralized applications (DApps);

[0023] • Interaction Adaptation and Terminal Feedback Module: Responsible for transmitting user operation commands and displaying results between the DApp front-end interface module and the local logic business module; the interaction adaptation and terminal feedback module supports multi-terminal adaptation and is compatible with different devices through responsive layout; it monitors the service status of the extended blockchain in real time and provides users with operation progress and fault prompts in a visual form, while providing retry mechanism and alternative service addressing scheme.

[0024] The DApp front-end presentation layer, through seamless linkage with the extended blockchain, completes the entire closed-loop collaboration of identity verification, service location, encrypted data transmission, offline synchronization, and status feedback, ensuring secure and efficient interaction between the DApp front-end presentation layer and the logic business layer and data layer.

[0025] Furthermore, the DApp front-end presentation layer may also include the following modules:

[0026] • Application Command Management Module: Responsible for the command management of specific functional business of decentralized applications (DApps); The application command management module manages the commands of specific functional business of decentralized applications (DApps). Each specific functional business corresponds to a command. Decentralized applications (DApps) can execute functional business through the DApp front-end interface module or by receiving commands, thereby supporting the automated invocation and execution of AI artificial intelligence agents.

[0027] • Local database module: Responsible for storing local data of decentralized applications (DApps);

[0028] • Local Cache Module: Responsible for persistent caching of various temporary data generated by local logical business modules and unified proxy modules of various decentralized services; the local cache module can be divided into a temporary cache area and a persistent cache area. The temporary cache area stores the current session data and the parsed service address, and is automatically cleared after the session ends; the persistent cache area synchronously stores basic user information, commonly used service configurations and offline operation records, supports incremental synchronization with decentralized storage, and automatically uploads offline data when the network recovers, ensuring the feasibility of basic operations and data consistency in offline scenarios;

[0029] • Decentralized Service Unified Proxy Module: This module is responsible for communicating with the identity authentication module, service addressing and connection management module, local logic business module, extended blockchain, logic business layer, and data layer of decentralized applications (DApps), and also for data caching and retrieval with the local caching module.

[0030] Furthermore, the DApp front-end interface in the presentation layer can be developed using HTML, CSS, JavaScript, or Uniapp technologies, and the logical business layer service URI is resolved through the Web3 domain name system. The local caching module is used to cache basic user data, improve interaction response speed, and ensure the feasibility of basic operations in offline scenarios. The local caching module can adopt a hybrid storage strategy of IndexedDB and localStorage, storing user session data, accessed resource URI mapping relationships, and encrypted private key fragments in IndexedDB, and storing interface configuration and lightweight state in localStorage. When the user revisits, the cached URI mapping table is loaded first from the local caching module, and then incremental updates are performed through the Web3 domain name system to reduce the number of address requests.

[0031] Furthermore, the logical business layer consists of custom services developed by developers. All containers carrying these custom services are functionally equivalent and operate independently. There is no master-slave distinction or difference in computing power among the container nodes, ensuring the system's decentralization and high service availability. This layer abandons the traditional smart contract logic execution mode and achieves low-latency data interaction with the data layer through a standardized remote procedure call interface, completing operations such as adding, deleting, modifying, and querying data, complex business logic calculations, and multi-node data collaborative processing. At the same time, the logical business layer supports development in multiple programming languages ​​such as Java, Go, and JavaScript, and is compatible with various service development architectures such as microservices and monolithic services. Developers can flexibly write custom service code according to business needs without adapting to the exclusive development syntax and execution specifications of blockchain smart contracts, significantly reducing the backend development threshold of decentralized applications. Moreover, the running efficiency of custom services is not limited by the blockchain block generation speed or on-chain resources, and can support high-concurrency and high-complexity business logic execution scenarios.

[0032] Furthermore, the decentralized container service in the extended blockchain can receive user container rental orders, generate distributed scheduling proposals, achieve global decisions through a "consensus mechanism," issue deployment instructions to target container worker nodes, execute container creation, monitor the status of worker nodes and containers in real time and trigger fault self-healing, complete order settlement and reward distribution, and release resources. The "consensus mechanism" can be a lightweight PoS mechanism, with voting weights calculated based on the amount of pledged assets of the management node and the node's online time. Voting data is signed by the node's private key and written to decentralized storage to ensure immutability and traceability.

[0033] Furthermore, the Web3 domain name system in the extended blockchain is a decentralized domain name resolution system based on blockchain, supporting the mapping of resource names to IP addresses or decentralized storage CIDs; resource registration, resolution, and update operations are executed through smart contracts, and registration information is stored on the blockchain to ensure immutability and transparency; the innovation of the Web3 domain name system lies in its multi-layer URI resolution architecture: the first layer is application identifier resolution, which is resolved to service CID through smart contracts; the second layer is service resource resolution, which is resolved to a specific IPFS node address; the third layer is data object resolution, which is resolved to a connection handle for a decentralized database; at the same time, a resolution result caching mechanism is introduced: the most recently resolved records are cached in the client and a cache validity period is set. During the cache period, the same request directly returns the cached result, thereby reducing on-chain query operations.

[0034] Furthermore, the hash value of the operation result in the data layer is written to the blockchain to ensure data integrity and traceability. Access to the decentralized storage and decentralized database in the data layer requires address resolution through the Web3 domain name system to achieve precise resource location and secure access. The architecture also innovatively optimizes the data layer components. For decentralized storage: a data sharding and encrypted storage strategy is adopted, automatically splitting files larger than 10MB into multiple 5MB data blocks. Each data block is encrypted using an encryption algorithm and then independently uploaded to different storage nodes. The file's metadata is stored in the decentralized database. During reading, each shard is retrieved in parallel and decrypted and reassembled. For the decentralized database: a master-slave multi-active replication architecture is adopted, synchronously replicating data to more than 3 nodes during writing. Each data record is appended with a hash check value, and Merkle tree comparisons are used periodically to ensure data consistency across multiple nodes. It supports three data models: key-value pairs, document-oriented, and relational, and is accessed through a unified SQL-compatible interface.

[0035] Furthermore, the various components of the extended blockchain achieve seamless collaboration through a unified standardized interface; it supports the access of third-party decentralized components to the architecture according to specifications, and the architecture is compatible with background computing tasks and interactive container tasks, adapting to diverse decentralized application scenarios such as instant messaging, distributed social networking, and data sharing, thereby improving the scalability and compatibility of the ecosystem; the unified standardized interface is implemented as follows:

[0036] (1) Interface Protocol Layer: JSON-RPC 2.0 is used as the unified communication protocol, and all component interface requests and responses follow the same format specification:

[0037] - Request format: { "jsonrpc": "2.0", "method": "<method name>", "params": { <parameter object>}, "id": "<request ID>"}

[0038] - Response format: { "jsonrpc": "2.0", "result": { <result object>}, "id": "<request ID>"};

[0039] (2) Interface Abstraction Layer: Defines a standard interface description file for each component, and uses an interface description language to define the input and output specifications of each component:

[0040] - Blockchain account module interface: connect(), sign(data), verify(signature), getBalance()

[0041] - Decentralized storage interfaces: upload(file), download(cid), pin(cid), unpin(cid)

[0042] - Decentralized database interface: connect(uri), query(sql), insert(table, data), update(table, id, data), delete(table, id)

[0043] - Decentralized container service interface: deploy(container), start(instance), stop(instance), scale(count), getStatus()

[0044] - Web3 Domain Name System Interface: register(uri, cid), resolve(uri), update(uri,newCid), revoke(uri);

[0045] (3) Interface adaptation layer: Develop a unified SDK adapter for each component and encapsulate the private APIs of the underlying components into standard interfaces;

[0046] (4) Interface Registry: Built-in service discovery and registration module. When each component starts up, it automatically registers its available interface list and access endpoints with the registry. The registration information includes: component type identifier, interface version number and compatible protocol, access address (HTTP / WebSocket / gRPC), authentication method (API Key / signature verification / no authentication) and health check endpoint address;

[0047] (5) Interface call process: When the application layer calls the extension layer service, the following unified process shall be followed:

[0048] - Step 1: Obtain the interface definition and access endpoint of the target component through the service registry;

[0049] - Step 2: Construct a standard JSON-RPC request based on the interface definition, and attach the user signature and request timestamp;

[0050] - Step 3: The request is routed to the corresponding component adapter via the interface adaptation layer;

[0051] - Step 4: The adapter translates the standard request into the private protocol of the underlying component and executes it;

[0052] - Step 5: The execution result is encapsulated into a standard JSON-RPC response by the adapter and returned to the application layer;

[0053] (6) Interface version management: Each interface supports multiple versions in parallel. The version number adopts semantic standard. When the interface changes:

[0054] - Backward compatibility changes: Minor version numbers are incremented (e.g., v1.0.0 → v1.1.0), and older version interfaces are retained;

[0055] - Changes that are not backward compatible: Major version number increments (e.g., v1.0.0 → v2.0.0), and old version interfaces are retained for at least a 6-month transition period.

[0056] Furthermore, the present invention also provides a method for constructing a decentralized application architecture, the method comprising the following specific steps:

[0057] First, expand the construction of blockchain infrastructure: Based on the basic blockchain, connect decentralized storage, decentralized databases, decentralized container services, and the Web3 domain name system to build an extended blockchain; the Web3 domain name system realizes the name service function of the entire Web3 system. The Web3 domain name system can run on the basic blockchain or run independently; the service access information of decentralized storage, decentralized databases, and decentralized container services needs to be registered in the Web domain name system;

[0058] 2. DApp Application Development: Developers develop the DApp front-end interface based on presentation layer technology, write custom back-end service code for the logic business layer, and complete the service addressing from the presentation layer to the logic business layer and from the logic business layer to the data layer through the Web3 domain name system to realize the interaction between different layers; package the front-end interface and back-end service into container images respectively, upload the images to decentralized storage, and register the service name and image address through the Web3 domain name system;

[0059] 3. DApp application deployment: Submit a container rental order in the decentralized container service. The registration parameters include task type, container hardware specifications, base image address, usage duration, startup script, and payment cost; successfully deploy the DApp front-end interface and back-end service.

[0060] 4. Service registration and discovery for DApp application operation: Users initiate operation requests through the DApp front-end in the presentation layer. The DApp front-end resolves the URI of the target service through the Web3 domain name system and establishes a connection with the container service in the logical business layer. After receiving the request, the container service obtains the storage and database address of the data layer through the Web3 domain name system to realize interaction with the data layer.

[0061] 5. Data storage and interaction in DApp application operation: Data interaction and storage. The container service in the logic business layer executes the business logic corresponding to the user request. If data operation is required, it interacts with the decentralized database or storage through remote calls to complete the addition, deletion, modification and query of data. Sensitive data is stored after being encrypted with the public and private keys of the blockchain account to ensure data privacy and security. The hash value of the data operation result is written to the blockchain to ensure data integrity and traceability.

[0062] 6. Service scheduling and load balancing for DApp application operation: The decentralized container service monitors the resource utilization and running status of the container cluster in real time and dynamically allocates service requests based on preset scheduling rules; when the number of service requests exceeds the load threshold of a single container, new container instances are automatically started to share the load, achieving elastic scaling.

[0063] 7. Self-healing of decentralized container service failures in DApp application operation: The decentralized container service monitors the status of containers and nodes through a node heartbeat mechanism. If a container failure is detected, a restart or migration command is immediately triggered, and the task is assigned to other healthy containers. If a node is detected to be disconnected, after confirmation through a consensus mechanism, the containers on that node are migrated to other nodes in the computing power pool to ensure service continuity.

[0064] 8. DApp application termination: When a user exits the DApp or the service finishes execution, the container service terminates data interaction and releases temporary resources; long-term stored data is retained in decentralized storage and database, and the blockchain records complete operation logs and data hashes for subsequent auditing and verification.

[0065] 9. The DApp application is now complete.

[0066] The specific content involved in this invention and the meaning of the terms used are as follows:

[0067] (1) Decentralized Container Service: A decentralized container service is a blockchain-like node cluster that relies on all nodes that join it to jointly provide container services. Its main functions include: receiving user container rental orders and verifying account legitimacy; generating distributed scheduling proposals and reaching global decisions through a consensus mechanism; issuing deployment instructions to target container worker nodes and executing container creation; monitoring the status of "nodes" and "containers" in real time and triggering fault self-healing; completing order settlement and reward distribution and releasing resources. The decentralized container service system includes: blockchain, a decentralized container service management node set, a container worker node set, and a decentralized storage system. Decentralized container services can effectively solve the problems of single point of failure, low resource utilization, and centralized scheduling in traditional centralized container services, and are especially suitable for container service needs in scenarios such as distributed computing power sharing and edge computing.

[0068] (2) Web3 Domain Name System: The Web3 Domain Name System is a decentralized domain name resolution system built on blockchain technology. Its core function is to map resource names to corresponding addresses, replacing traditional centralized DNS while inheriting the decentralized, immutable, secure, and transparent characteristics of blockchain. Its registration, resolution, and update operations are all executed through smart contracts. Registration information is stored in the blockchain to ensure immutability and traceability. As the core resource registration and resolution entry point for extending the blockchain, it can provide a unified and efficient resource location capability for service calls and data access in decentralized applications. Users or service callers can quickly locate the address of the required service or data through easy-to-remember resource names without relying on centralized servers, ensuring the security and stability of resource access in the decentralized ecosystem.

[0069] (3) Blockchain account system: Both users and miners need to register a blockchain account. The account balance, pledged assets, and transaction records cannot be tampered with, ensuring the transparent execution of fees and rewards;

[0070] (4) Decentralized storage: Store core data such as orders, snapshots, and logs. Avoid data loss through multi-node backup and achieve efficient retrieval through content addressing.

[0071] (5) Decentralized Database: A decentralized database is a data storage and management system built on distributed technology. Its core feature is that data is distributed across multiple nodes in the network rather than a single server, which avoids the risk of single point of failure and ensures high availability and persistence of data. It supports various data structures such as key-value pairs, logs, documents, and graphs, and can adapt to the business needs of different decentralized applications. It also has the ability to automatically synchronize data across nodes and support offline operations, ensuring data consistency across multiple terminals. It protects data privacy and security through encryption mechanisms and flexible access control policies, and is easy to integrate with decentralized components such as blockchain and container services, providing reliable, secure and decentralized data storage support for distributed applications such as DApps, solving the problems of centralized data control and lack of trust in traditional centralized databases.

[0072] Advantages and beneficial effects of the present invention:

[0073] This invention expands upon blockchain to build a standardized decentralized application ecosystem, with the following core advantages and beneficial effects:

[0074] 1. Significantly reduce usage costs: By separating storage and service logic from the chain, and retaining only management and hash verification information on the chain, blockchain transaction fees and storage consumption are greatly reduced, resulting in a significant reduction in user costs.

[0075] 2. Improve system performance and scalability: The decentralized container service replaces smart contracts to execute business logic, supports the development of complex functions and high-concurrency processing, and greatly reduces message transmission latency, which is far superior to the traditional DApp architecture.

[0076] 3. Ensure decentralization and security: Relying on the distributed architecture of extended blockchain, the risk of single point of failure is avoided; through blockchain encryption mechanism and data hash verification, data privacy, security and immutability are ensured.

[0077] 4. Simplify the development process: Provide standardized architectural components and interfaces, support development in multiple programming languages, lower the threshold for DApp development, and adapt to diverse application scenarios such as instant messaging, distributed social networking, and data sharing.

[0078] 5. Building a sustainable ecosystem: Incentivize container providers and developers to participate through economic reward mechanisms, forming a collaborative ecosystem of "users-developers-container providers" to promote the large-scale deployment of decentralized applications. Attached Figure Description

[0079] Figure 1 This is a schematic diagram of the decentralized application architecture in this invention.

[0080] Figure 2 This is a flowchart of the decentralized application architecture construction method in this invention.

[0081] Figure 3 This is a diagram of the interface of DTalk, the decentralized chat software in this invention.

[0082] Figure 4 This is a diagram showing the business functions and structure of the decentralized chat software DTalk.

[0083] Figure 5 This is a list of development tools for the decentralized chat software DTalk.

[0084] Figure 6 This is an extended blockchain deployment diagram in this invention.

[0085] Figure 7 This is the data layer architecture in the decentralized application architecture of this invention.

[0086] Figure 8 This is an extended blockchain logic diagram in this invention.

[0087] Figure 9 This is a comparative experimental result diagram of smart contracts, traditional container services, and decentralized container services in this invention. Detailed Implementation

[0088] This invention provides a decentralized application architecture and construction method.

[0089] The decentralized application architecture provided by this invention includes the following components, such as... Figure 1 As shown:

[0090] The decentralized application architecture includes an extended blockchain 200, a decentralized application (DApp) front-end presentation layer 10, a logic business layer 20, and a data layer 30. These components work together to enable the deployment and operation of the decentralized application. The specific structure is as follows:

[0091] • Extended Blockchain 200: As a core infrastructure of the architecture, extended blockchain is also known as generalized blockchain, such as... Figure 1 and 8 As shown, the extended blockchain consists of at least a blockchain (i.e., the basic blockchain) 190, decentralized storage 180, decentralized database 170, decentralized container service 150 and Web3 domain name system 160, providing applications with decentralized storage, computing, service scheduling and resource discovery capabilities;

[0092] • DApp Front-End Presentation Layer 10: This refers to the decentralized application (DApp) front-end presentation layer, which serves as the user interaction entry point, such as... Figure 1 As shown, the DApp front-end presentation layer consists of at least a decentralized application DApp front-end interface module, an identity authentication module, a service addressing and connection management module, an interaction adaptation and terminal feedback module, a data encryption module, and a local logic business module.

[0093] • Logic Business Layer 20: This is the core function execution unit of the application, consisting of custom services deployed by the developer. It runs in an equivalent container of the decentralized container service, replacing traditional smart contracts to implement backend logic processing. This layer interacts with the data layer through remote procedure call interfaces to complete data addition, deletion, modification, query and complex business logic operations. All container functions are equivalent and independent of each other, ensuring the decentralized nature and high availability of the system.

[0094] • Data Layer 300: This is the data storage carrier, consisting of decentralized storage 180 and decentralized database 170. The data layer is responsible for storing the business data, configuration files, and container images required for application operation. It achieves efficient data interaction with the logical business layer through the address resolution service provided by the Web3 domain name system.

[0095] in,

[0096] The components of a blockchain can be expanded as follows:

[0097] • Basic Blockchain 190: Provides an account system, public and private key encryption mechanism, and transaction record storage function to ensure the legitimacy of user identity, data privacy and security, and the immutability of operations;

[0098] • Decentralized Storage 180: Stores large amounts of unstructured data and files, alleviating storage pressure on blockchain and reducing data storage costs;

[0099] • Decentralized Database 170: Supports multiple data structures such as key-value pairs, logs, and documents, enabling efficient management and cross-node synchronization of structured data;

[0100] • Decentralized Container Service 150: Composed of computing resources contributed by container providers, it provides a runtime environment for custom services in the logical business layer and achieves load balancing and fault tolerance through container clusters;

[0101] • Web3 Domain Name System 160: A decentralized domain name resolution system based on blockchain that maps resource names to addresses, providing a unified entry point for service discovery and resource access;

[0102] The components of DApp front-end presentation layer 10 are as follows:

[0103] • DApp Front-end Interface Module 50: Responsible for user interface display and user interface input reception;

[0104] • Identity Authentication Module 100: Responsible for the management of local identity and extended blockchain accounts; the identity authentication module is based on the blockchain account system, supports public and private key signature verification, address verification and hierarchical permission functions, interacts with blockchain nodes through Web3 interface to complete user identity confirmation, automatically adapts to the account permission rules of the extended blockchain, and ensures that only legitimate users initiate operation requests;

[0105] • Service Addressing and Connection Management Module 110: Responsible for obtaining the service URI of the logical business layer and the service of the data layer through the Web3 domain name system; the Service Addressing and Connection Management Module resolves the SDK through the Web3 domain name system, supports fast mapping of resource names to service URIs and storage addresses, can automatically cache the resolution results and update them regularly; at the same time, it provides adaptive management of long connections and short connections, switches the connection mode according to the business scenario, and ensures stable communication with the container service of the logical business layer;

[0106] • Data Encryption Module 140: Responsible for various data encryption and decryption; the data encryption module integrates symmetric and asymmetric encryption dual encryption mechanisms to perform hierarchical encryption on user input data and interactive commands; it supports automatically converting encrypted data into a format compatible with extended blockchains, adapting to the data storage specifications of decentralized storage and databases;

[0107] • Local Logic Business Module 60: Responsible for the specific functionalities of decentralized applications (DApps);

[0108] • Interaction Adaptation and Terminal Feedback Module 130: Responsible for transmitting user operation commands and displaying results between the DApp front-end interface module and the local logic business module; the interaction adaptation and terminal feedback module supports multi-terminal adaptation and is compatible with different devices through responsive layout; it monitors the service status of the extended blockchain in real time and provides users with operation progress and fault prompts in a visual form, while providing retry mechanism and alternative service addressing scheme.

[0109] The DApp front-end presentation layer 10, through seamless linkage with the extended blockchain and Web3 domain name system 160, completes the entire closed-loop collaboration of identity verification, service positioning, encrypted data transmission, offline synchronization and status feedback, ensuring secure and efficient interaction between the DApp front-end presentation layer 10 and the logical business layer 20 and data layer 30.

[0110] Furthermore, the DApp front-end presentation layer may also include the following modules, such as... Figure 1 As shown:

[0111] • Application Command Management Module 80: Responsible for the command management of specific functional business of decentralized application (DApp); The application command management module manages the commands of specific functional business of decentralized application (DApp). Each specific functional business corresponds to a command. Decentralized application (DApp) can execute functional business through the decentralized application (DApp) front-end interface module or by receiving commands, thereby supporting the automated invocation and execution of AI artificial intelligence agents.

[0112] • Local Database Module 70: Responsible for storing local data of decentralized applications (DApps);

[0113] • Local Cache Module 120: Responsible for persistent caching of various temporary data generated by local logical business modules and unified proxy modules for various decentralized services; the local cache module can be divided into a temporary cache area and a persistent cache area. The temporary cache area stores the current session data and the parsed service address, and is automatically cleared after the session terminates; the persistent cache area synchronously stores user basic information, commonly used service configurations and offline operation records, supports incremental synchronization with decentralized storage, and automatically uploads offline data when the network recovers, ensuring the feasibility of basic operations and data consistency in offline scenarios;

[0114] For the local caching module, the caching strategy employs a high-frequency data priority caching and expiration cleanup mechanism. Frequently accessed data such as commonly used service addresses and user configurations are cached first, and the cache validity period is dynamically adjusted based on the data update frequency. The local caching module uses browser storage technologies such as IndexedDB or LocalStorage to support persistent storage of structured data. Cache data types include service address mapping cache, user configuration information, recent chat history, and offline message queues. The local caching module also supports offline mode. When the user's network is disconnected, the frontend caches user operations locally, and automatically synchronizes them to the logical business layer after the network is restored, ensuring the continuity of user operations.

[0115] • Decentralized Service Unified Proxy Module 90: This module is responsible for communicating with the identity authentication module, service addressing and connection management module, local logic business module, extended blockchain, logic business layer, and data layer of decentralized applications (DApps), and also for data caching and reading with the local caching module.

[0116] The specific steps of the decentralized application architecture construction method provided by this invention are as follows: Figure 2 As shown:

[0117] First, expand the blockchain infrastructure: Based on the basic blockchain, integrate decentralized storage, decentralized databases, decentralized container services, and the Web3 domain name system to build an extended blockchain; the Web3 domain name system provides name service functionality for the entire Web3 system. The Web3 domain name system can run on top of the basic blockchain or independently; service access information for decentralized storage, decentralized databases, and decentralized container services needs to be registered in the Web3 domain name system, such as... Figure 8 As shown;

[0118] 2. DApp Application Development: Developers develop the DApp front-end interface based on presentation layer technology, write custom back-end service code for the logic business layer, and complete the service addressing from the presentation layer to the logic business layer and from the logic business layer to the data layer through the Web3 domain name system to realize the interaction between different layers; package the front-end interface and back-end service into container images respectively, upload the images to decentralized storage, and register the service name and image address through the Web3 domain name system;

[0119] 3. DApp application deployment: Submit a container rental order in the decentralized container service. The registration parameters include task type, container hardware specifications, base image address, usage duration, startup script, and payment cost; successfully deploy the DApp front-end interface and back-end service.

[0120] 4. Service Registration and Discovery in DApp Application Operation: Users initiate operation requests through the DApp frontend in the presentation layer. The DApp frontend resolves the URI of the target service through the Web3 domain name system, establishing a connection with the container service in the logical business layer. After receiving the request, the container service obtains the storage and database address of the data layer through the Web3 domain name system, realizing interaction with the data layer, such as... Figure 6 As shown;

[0121] 5. Data Storage and Interaction in DApp Application Operation: Data interaction and storage. The container service in the logic business layer executes the business logic corresponding to user requests. If data operations are required, they are performed through remote calls and interactions with decentralized databases or storage to complete data CRUD operations. Sensitive data is stored after being encrypted using the public and private keys of the blockchain account to ensure data privacy and security. The hash value of the data operation result is written to the blockchain to ensure data integrity and traceability. Figure 7 As shown;

[0122] 6. Service Scheduling and Load Balancing for DApp Application Operation: The decentralized container service monitors the resource utilization and operating status of the container cluster in real time, and dynamically allocates service requests based on preset scheduling rules. When the number of service requests exceeds the load threshold of a single container, new container instances are automatically started to share the load, achieving elastic scaling. Figure 6 As shown;

[0123] 7. Self-healing of Decentralized Container Service Faults in DApp Application Operation: The decentralized container service monitors the status of containers and nodes through a node heartbeat mechanism. If a container failure is detected, a restart or migration command is immediately triggered, and tasks are distributed to other healthy containers. If a node is detected as disconnected, after confirmation through a consensus mechanism, the containers on that node are migrated to other nodes in the computing power pool to ensure service continuity. Figure 6 As shown;

[0124] 8. DApp application termination: When a user exits the DApp or the service finishes execution, the container service terminates data interaction and releases temporary resources; long-term stored data is retained in decentralized storage and database, and the blockchain records complete operation logs and data hashes for subsequent auditing and verification.

[0125] 9. The DApp application is now complete.

[0126] Furthermore, the DApp front-end interface in the presentation layer can be developed using HTML, CSS, JavaScript, or Uniapp technologies, and the logical business layer service URI is resolved through the Web3 domain name system. The local caching module is used to cache basic user data, improve interaction response speed, and ensure the feasibility of basic operations in offline scenarios. The local caching module can adopt a hybrid storage strategy of IndexedDB and localStorage, storing user session data, accessed resource URI mapping relationships, and encrypted private key fragments in IndexedDB, and storing interface configuration and lightweight state in localStorage. When the user revisits, the cached URI mapping table is loaded first from the local caching module, and then incremental updates are performed through the Web3 domain name system to reduce the number of address requests.

[0127] Furthermore, the logical business layer consists of custom services developed by developers. All containers carrying these custom services are functionally equivalent and operate independently. There is no master-slave distinction or difference in computing power among container nodes, ensuring the system's decentralization and high service availability. This layer abandons the traditional smart contract logic execution mode, achieving low-latency data interaction with the data layer through standardized remote procedure call interfaces. It performs operations such as adding, deleting, modifying, and querying data, complex business logic calculations, and multi-node data collaborative processing. Simultaneously, the logical business layer supports development in multiple programming languages, including Java, Go, and JavaScript, and is compatible with various service development architectures such as microservices and monolithic services. Developers can flexibly write custom service code according to business needs without adapting to the proprietary development syntax and execution specifications of blockchain smart contracts, significantly reducing the backend development threshold for decentralized applications. Moreover, the running efficiency of custom services is not limited by the blockchain block generation speed or on-chain resources, supporting high-concurrency and high-complexity business logic execution scenarios, such as... Figure 9 The comparison diagrams shown illustrate the advantages of this invention.

[0128] Furthermore, the decentralized container service in the extended blockchain can receive user container rental orders, generate distributed scheduling proposals, achieve global decisions through a "consensus mechanism," issue deployment instructions to target container worker nodes, execute container creation, monitor the status of worker nodes and containers in real time and trigger fault self-healing, complete order settlement and reward distribution, and release resources. The "consensus mechanism" can be a lightweight PoS mechanism, with voting weights calculated based on the amount of pledged assets of the management node and the node's online time. Voting data is signed by the node's private key and written to decentralized storage to ensure immutability and traceability.

[0129] Furthermore, the Web3 domain name system in the extended blockchain is a decentralized domain name resolution system based on blockchain, supporting the mapping of resource names to IP addresses or decentralized storage CIDs; resource registration, resolution, and update operations are executed through smart contracts, and registration information is stored on the blockchain to ensure immutability and transparency; the innovation of the Web3 domain name system lies in its multi-layer URI resolution architecture: the first layer is application identifier resolution, which is resolved to service CID through smart contracts; the second layer is service resource resolution, which is resolved to a specific IPFS node address; the third layer is data object resolution, which is resolved to a connection handle for a decentralized database; at the same time, a resolution result caching mechanism is introduced: the most recently resolved records are cached in the client and a cache validity period is set. During the cache period, the same request directly returns the cached result, thereby reducing on-chain query operations.

[0130] Furthermore, the hash value of the operation result in the data layer is written to the blockchain to ensure data integrity and traceability. Access to the decentralized storage and decentralized database in the data layer requires address resolution through the Web3 domain name system to achieve precise resource location and secure access. The architecture also innovatively optimizes the data layer components. For decentralized storage: a data sharding and encrypted storage strategy is adopted, automatically splitting files larger than 10MB into multiple 5MB data blocks. Each data block is encrypted using an encryption algorithm and then independently uploaded to different storage nodes. The file's metadata is stored in the decentralized database. During reading, each shard is retrieved in parallel and decrypted and reassembled. For the decentralized database: a master-slave multi-active replication architecture is adopted, synchronously replicating data to more than 3 nodes during writing. Each data record is appended with a hash check value, and Merkle tree comparisons are used periodically to ensure data consistency across multiple nodes. It supports three data models: key-value pairs, document-oriented, and relational, and is accessed through a unified SQL-compatible interface.

[0131] Furthermore, the various components of the extended blockchain achieve seamless collaboration through a unified standardized interface; it supports the access of third-party decentralized components to the architecture according to specifications, and the architecture is compatible with background computing tasks and interactive container tasks, adapting to diverse decentralized application scenarios such as instant messaging, distributed social networking, and data sharing, thereby improving the scalability and compatibility of the ecosystem; the unified standardized interface is implemented as follows:

[0132] (1) Interface Protocol Layer: JSON-RPC 2.0 is used as the unified communication protocol, and all component interface requests and responses follow the same format specification:

[0133] - Request format: { "jsonrpc": "2.0", "method": "<method name>", "params": { <parameter object>}, "id": "<request ID>"}

[0134] - Response format: { "jsonrpc": "2.0", "result": { <result object>}, "id": "<request ID>"};

[0135] (2) Interface Abstraction Layer: Defines a standard interface description file for each component, and uses an interface description language to define the input and output specifications of each component:

[0136] - Blockchain account module interface: connect(), sign(data), verify(signature), getBalance()

[0137] - Decentralized storage interfaces: upload(file), download(cid), pin(cid), unpin(cid)

[0138] - Decentralized database interface: connect(uri), query(sql), insert(table, data), update(table, id, data), delete(table, id)

[0139] - Decentralized container service interface: deploy(container), start(instance), stop(instance), scale(count), getStatus()

[0140] - Web3 Domain Name System Interface: register(uri, cid), resolve(uri), update(uri,newCid), revoke(uri);

[0141] (3) Interface adaptation layer: Develop a unified SDK adapter for each component and encapsulate the private APIs of the underlying components into standard interfaces;

[0142] (4) Interface Registry: Built-in service discovery and registration module. When each component starts up, it automatically registers its available interface list and access endpoints with the registry. The registration information includes: component type identifier, interface version number and compatible protocol, access address (HTTP / WebSocket / gRPC), authentication method (API Key / signature verification / no authentication) and health check endpoint address;

[0143] (5) Interface call process: When the application layer calls the extension layer service, the following unified process shall be followed:

[0144] - Step 1: Obtain the interface definition and access endpoint of the target component through the service registry;

[0145] - Step 2: Construct a standard JSON-RPC request based on the interface definition, and attach the user signature and request timestamp;

[0146] - Step 3: The request is routed to the corresponding component adapter via the interface adaptation layer;

[0147] - Step 4: The adapter translates the standard request into the private protocol of the underlying component and executes it;

[0148] - Step 5: The execution result is encapsulated into a standard JSON-RPC response by the adapter and returned to the application layer;

[0149] (6) Interface version management: Each interface supports multiple versions in parallel. The version number adopts semantic standard. When the interface changes:

[0150] - Backward compatibility changes: Minor version numbers are incremented (e.g., v1.0.0 → v1.1.0), and older version interfaces are retained;

[0151] - Changes that are not backward compatible: Major version number increments (e.g., v1.0.0 → v2.0.0), and old version interfaces are retained for at least a 6-month transition period.

[0152] To further understand the technical content, features, and effects of this invention, the following application examples are provided, along with... Figure 3 Detailed explanation is as follows:

[0153] Application example: DTalk, a decentralized chat application

[0154] Taking the decentralized instant messaging chat software DTalk as an example, the DTalk application supports features such as blockchain wallet login, peer-to-peer one-on-one chat, group chat, encrypted file transfer, offline message synchronization, and real-time status updates. Figure 4 As shown, all business logic in DTalk applications is executed by container services, data is stored in layers, and key operations are hashed and recorded on the blockchain, featuring full decentralization, end-to-end encryption, low latency, high concurrency, and low cost.

[0155] The DTalk application is fully adapted to the decentralized application architecture proposed in this invention, which includes extended blockchain, presentation layer, logic business layer, and data layer. It comprehensively covers the functions of each module of the architecture, unified and standardized interface calls, decentralized container service scheduling, fault self-healing, multi-layer resolution of Web3 domain name system, data layer sharding and encrypted storage, and other core patented technologies. It clearly presents the entire process operation logic of the architecture and verifies the high availability, decentralized characteristics, low cost and high scalability of the architecture in the instant messaging scenario.

[0156] like Figure 5 As shown, in terms of the development environment, the DTalk application front-end development is based on the Uniapp cross-platform framework, using HBuilderX as the development tool. It combines HTML, CSS, and JavaScript to complete the development of the front-end interface and interaction logic. At the same time, it integrates the Web3.js library to realize interaction with the blockchain and Web3 domain name system, and uses ipfs-http-client.js to realize the connection with decentralized storage. When debugging locally, it adopts a combination of simulator and real device, supporting multi-terminal adaptation for iOS and Android.

[0157] DTalk application backend development uses the Node.js + Express framework and VSCode as the development tool, supporting full-stack JavaScript development features to maintain consistency with the frontend technology stack and reduce development and collaboration costs. During backend development, the official CovenantSQL SDK is integrated to enable interaction with the decentralized database. Custom containerization scripts are used to package the backend service into a Docker image, ensuring image standardization and portability.

[0158] 1. System Deployment Prerequisites

[0159] • Expanding blockchain deployment: such as Figure 6 As shown, a test chain was built as the underlying blockchain, an IPFS cluster was deployed as decentralized storage, and CovenantSQL was deployed as a decentralized database; a Web3 domain name system smart contract was built to realize the mapping between resource names and addresses;

[0160] • Container service cluster: Management node cluster, 8 physical machines, 4 cores and 8GB RAM, stable public IP address, deploying management node clients; Worker node cluster, 50 physical machines, 2 cores and 4GB RAM, deploying worker node clients;

[0161] Development environment: The front-end uses the Uniapp framework to develop the DApp interface, and the back-end uses the Node.js + Express framework to develop custom services. web3.js is used to interact with the blockchain, and ipfs-http-client.js is used to interact with IPFS.

[0162] 2. Architecture and Operation Methods (i.e., building decentralized applications based on the architecture)

[0163] 1) Infrastructure initialization and interface registration:

[0164] Launch a cluster of blockchain, IPFS, CovenantSQL, Web3 domain name system, and container services. All components report information to the registry center through standardized interfaces, generating a unified interface mapping table to achieve seamless collaboration among the various components of the extended blockchain.

[0165] 2) DTalk Application Development and Resource Registration:

[0166] Presentation Layer: Implements five modules: identity authentication, service addressing, data encryption, local caching, and interactive feedback. It adapts to multiple terminals and supports offline incremental data synchronization. Logic Business Layer: Develops six equivalent independent microservices, including identity authentication, message processing, user management, and file storage. It also develops RPC interfaces to interact with the data layer. For example... Figure 7 As shown, the front-end and back-end microservices are packaged into Docker images, uploaded to IPFS to obtain unique CIDs, and the image metadata is stored in CovenantSQL. The application CID (dtalk.wei), service.dtalk.wei (service URI), and data.dtalk.wei (database handle) are registered in the Web3 domain name system, and their relationships are resolved and stored on the blockchain.

[0167] 3) Decentralized container service deployment:

[0168] Developers submit container rental orders (task type, hardware specifications, image CID, per-second billing rules, etc.). After the management node verifies the account's legitimacy, it generates a scheduling proposal. The management node votes through lightweight PoS consensus, and once approved, it issues deployment instructions to 20 idle worker nodes, creating 1 frontend instance and 6 backend microservice instances. After all container instances start, they report their status to the registry center, completing the DTalk distributed deployment.

[0169] 4) Core user-side operations and architecture interactions:

[0170] • User login: Users log in using their blockchain account private key. The front end completes public and private key signature verification and identity confirmation through the Web3 interface. The URI mapping table and user information are loaded from the local cache first, and incremental updates are performed through the Web3 domain name system to reduce on-chain queries.

[0171] • One-to-one instant messaging: Text messages are encrypted with AES. The frontend obtains the message service URI through Web3 domain name resolution, establishes a WebSocket connection, and sends the message. After receiving the message, the business logic layer stores the encrypted message in CovenantSQL, generates a hash value, and writes it to the blockchain. If the recipient is online, the message is pushed via a P2P network, and the recipient decrypts and displays the message using their private key. The frontend provides real-time feedback on the delivery status. When the recipient is offline, the message is temporarily stored as offline data and automatically synchronized to the local persistent cache upon returning online.

[0172] • Large file transfer: After encrypting a 20MB video file, the front end automatically splits it into four 5MB chunks and uploads them in parallel to different IPFS nodes. Each chunk obtains an independent CID. File metadata (chunk CID, reassembly rules, decryption key) is stored in CovenantSQL, and the entire file hash is uploaded to the blockchain. The receiver pulls the chunks, decrypts and reassembles them locally, and the front end displays the real-time transfer progress.

[0173] • High-concurrency load balancing: When the number of online users in a group reaches 200 and the message service load exceeds 80%, the container service automatically generates a scaling proposal. After consensus is reached, two new message service instances are quickly launched. After the new instances are registered, the scheduling module allocates requests according to a round-robin strategy to achieve load sharing. The message transmission latency remains ≤100ms, which is imperceptible to the user.

[0174] The elastic scaling mechanism dynamically adjusts the number of container instances based on cluster load. The system collects cluster load data in real time, including metrics such as CPU utilization, memory utilization, network bandwidth utilization, and concurrent requests. It automatically scales up when the load exceeds a threshold and automatically scales down when the load falls below the threshold. During scaling up, container images are pulled from the IPFS cluster and new instances are launched on the target worker nodes. The number of instances added is calculated based on the proportion of load exceeding the threshold, and the selection of target nodes comprehensively evaluates factors such as resource sufficiency, network latency, and load balancing. During scaling down, instances are gradually reduced proportionally to the load, migrating traffic to the remaining instances to ensure uninterrupted service. The triggering conditions for elastic scaling consider both the current load and the load change rate. The load change rate is used to predict short-term load trends. When the load rises rapidly, the system scales up in advance to avoid increased service response latency; when the load drops rapidly, the system scales down in advance to avoid resource waste.

[0175] The load balancing algorithm uses a weighted round-robin approach, calculating a comprehensive weight based on the container instance's health score and load score. The health score is determined by a comprehensive evaluation of metrics such as container runtime, failure history, and response latency; container instances with longer runtime, fewer failure histories, and lower response latency receive higher health scores. The load score is determined by a comprehensive evaluation of metrics such as current CPU utilization, memory utilization, and concurrent request count; container instances with lower load receive higher load scores.

[0176] Elastic scaling and load balancing work together to form a complete resource scheduling system. When a node is overloaded, new requests are automatically distributed to nodes with lower loads, achieving real-time load balancing. When the load exceeds a threshold, new container instances are automatically started, and after scaling up, the new instances are automatically added to the load balancing pool to handle requests. When the load decreases, the system prioritizes scaling down the instance with the lowest load score, migrating traffic to the remaining instances, and updating the load balancing weights after scaling down. Through the synergy of elastic scaling and load balancing, the system maintains excellent and stable performance in high-concurrency scenarios while avoiding resource waste.

[0177] Fault self-healing and service continuity:

[0178] If a message service instance crashes, the management node will immediately issue a restart command upon detecting a loss of heartbeat connection. If the restart fails, the task will be quickly migrated to a healthy node, with a processing time of ≤5 seconds. If a user management service node experiences a network failure, the management node will migrate the container to two healthy nodes and create a multi-active instance after consensus confirmation. After synchronizing the data, the registry information will be updated, with a migration time of 8 seconds and uninterrupted service throughout the process.

[0179] 5) Operation Termination and Resource Management:

[0180] When a user exits DTalk, the frontend disconnects and clears the temporary cache, while the persistent cache retains the user's information and chat history. The container service distributes token rewards based on node computing power contributions and deducts developer tokens based on actual consumption, with all settlement records recorded on the blockchain. Core data is stored long-term in IPFS and CovenantSQL, and all data operation hashes are recorded on the blockchain for audit traceability. Users can initiate data deletion requests, and operation records are also recorded on the blockchain for evidence.

[0181] like Figure 9 As shown, comparative experiments were conducted on smart contracts, traditional container services, and decentralized container services across multiple dimensions, including execution environment, development language, concurrency capabilities, functional complexity, storage access, external calls, development threshold, and degree of decentralization. Decentralized container services are undoubtedly the best. Furthermore, the decentralized application architecture in this area includes extended blockchains and decentralized container services, giving the next generation of decentralized applications better advantages in terms of complete decentralization, end-to-end encryption, low latency, high concurrency, and low cost.

[0182] In view of the description and exemplary embodiments of the invention disclosed herein, other embodiments of the invention will be apparent to those skilled in the art. These descriptions and embodiments are considered as examples only, and any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the scope of protection of the invention.

Claims

1. A decentralized application architecture, characterized in that, The decentralized application architecture includes an extended blockchain, a decentralized application (DApp) front-end presentation layer, a logic business layer, and a data layer. These components work together to enable the deployment and operation of the decentralized application. The specific structure is as follows: • Extended Blockchain: As a core infrastructure of the architecture, extended blockchain, also known as generalized blockchain, consists of at least a basic blockchain, decentralized storage, decentralized database, decentralized container service, and Web3 domain name system, providing applications with decentralized storage, computing, service scheduling, and resource discovery capabilities; • DApp Front-end Presentation Layer: This refers to the front-end presentation layer of decentralized applications (DApps), which serves as the user interaction entry point. The DApp front-end presentation layer consists of at least the decentralized application DApp front-end interface module, identity authentication module, service addressing and connection management module, interaction adaptation and terminal feedback module, data encryption module, and local logic business module. • Logic Business Layer: This is the core function execution unit of the application, consisting of custom services deployed by the developer. It runs in an equivalent container of the decentralized container service, replacing traditional smart contracts to implement backend logic processing. This layer interacts with the data layer through remote procedure call interfaces to complete data CRUD operations and complex business logic calculations. All container functions are equivalent and independent of each other, ensuring the decentralized nature and high availability of the system. • Data Layer: This layer serves as the data storage carrier, consisting of decentralized storage and a decentralized database. It is responsible for storing the business data, configuration files, and container images required for application operation. Through the address resolution service provided by the Web3 domain name system, it enables efficient data interaction with the logical business layer. in, The components of a blockchain can be expanded as follows: • Basic blockchain: Provides an account system, public and private key encryption mechanism, and transaction record storage function to ensure the legitimacy of user identity, data privacy and security, and the immutability of operations; • Decentralized storage: Stores large amounts of unstructured data and files, alleviating storage pressure on blockchain and reducing data storage costs; • Decentralized database: Supports multiple data structures such as key-value pairs, logs, and documents, enabling efficient management and cross-node synchronization of structured data; • Decentralized container service: Composed of computing resources contributed by container providers, it provides a runtime environment for custom services in the logical business layer, and achieves load balancing and fault tolerance through container clusters; • Web3 Domain Name System: A decentralized domain name resolution system based on blockchain that maps resource names to addresses, providing a unified entry point for service discovery and resource access; The components of the DApp front-end presentation layer are as follows: • DApp front-end interface module: responsible for user interface display and user interface input reception; • Identity Authentication Module: Responsible for the management of local identity and extended blockchain accounts; the identity authentication module is based on the blockchain account system, supports public and private key signature verification, address verification and hierarchical permission functions, interacts with blockchain nodes through Web3 interface to complete user identity confirmation, automatically adapts to the account permission rules of the extended blockchain, and ensures that only legitimate users initiate operation requests; • Service Addressing and Connection Management Module: Responsible for obtaining the service URI of the logical business layer and the service of the data layer through the Web3 domain name system; the Service Addressing and Connection Management Module resolves the SDK through the Web3 domain name system, supports fast mapping of resource names to service URIs and storage addresses, can automatically cache the resolution results and update them periodically; at the same time, it provides adaptive management of long connections and short connections, switches the connection mode according to the business scenario, and ensures stable communication with the container service of the logical business layer; • Data encryption module: Responsible for encrypting and decrypting various types of data; the data encryption module integrates symmetric and asymmetric encryption dual encryption mechanisms to perform hierarchical encryption on user input data and interactive commands; it supports automatically converting encrypted data into a format compatible with extended blockchains, adapting to the data storage specifications of decentralized storage and databases; • Local logic business module: responsible for the specific functional business of decentralized applications (DApps); • Interaction Adaptation and Terminal Feedback Module: Responsible for transmitting user operation commands and displaying results between the DApp front-end interface module and the local logic business module; the interaction adaptation and terminal feedback module supports multi-terminal adaptation and is compatible with different devices through responsive layout; it monitors the service status of the extended blockchain in real time and provides users with operation progress and fault prompts in a visual form, while providing retry mechanism and alternative service addressing scheme. The DApp front-end presentation layer, through seamless linkage with the extended blockchain, completes the entire closed-loop collaboration of identity verification, service location, encrypted data transmission, offline synchronization, and status feedback, ensuring secure and efficient interaction between the DApp front-end presentation layer and the logic business layer and data layer.

2. The architecture according to claim 1, characterized in that, The DApp front-end presentation layer may also include the following modules: • Application Command Management Module: Responsible for the command management of specific functional business of decentralized applications (DApps); The application command management module manages the commands of specific functional business of decentralized applications (DApps). Each specific functional business corresponds to a command. Decentralized applications (DApps) can execute functional business through the DApp front-end interface module or by receiving commands, thereby supporting the automated invocation and execution of AI artificial intelligence agents. • Local database module: Responsible for storing local data of decentralized applications (DApps); • Local caching module: Responsible for persistent caching of various temporary data generated by local logical business modules and unified proxy modules for various decentralized services; The local caching module can be divided into a temporary cache and a persistent cache. The temporary cache stores the current session data and the parsed service address, and is automatically cleared after the session ends. The persistent cache synchronously stores basic user information, common service configurations, and offline operation records. It supports incremental synchronization with decentralized storage and automatically uploads offline data when the network recovers, ensuring the feasibility of basic operations and data consistency in offline scenarios. • Decentralized Service Unified Proxy Module: This module is responsible for communicating with the identity authentication module, service addressing and connection management module, local logic business module, extended blockchain, logic business layer, and data layer of decentralized applications (DApps), and also for data caching and retrieval with the local caching module.

3. The architecture according to claim 1 or 2, characterized in that, The DApp front-end interface in the presentation layer can be developed using HTML, CSS, JavaScript, or Uniapp technologies, and resolves the service URI of the logical business layer through the Web3 domain name system. The local caching module is used to cache basic user data, improve interaction response speed, and ensure the feasibility of basic operations in offline scenarios. The local caching module can adopt a hybrid storage strategy of IndexedDB and localStorage, storing user session data, accessed resource URI mapping relationships, and encrypted private key fragments in IndexedDB, and storing interface configuration and lightweight state in localStorage. When the user revisits, the cached URI mapping table is loaded first from the local caching module, and then incremental updates are performed through the Web3 domain name system to reduce the number of address requests.

4. The architecture according to claim 1, characterized in that, The logical business layer consists of custom services developed by developers. All containers carrying these custom services are functionally equivalent and operate independently. There is no master-slave distinction or difference in computing power among the container nodes, ensuring the system's decentralization and high service availability. This layer abandons the traditional smart contract logic execution mode and achieves low-latency data interaction with the data layer through a standardized remote procedure call interface, completing operations such as adding, deleting, modifying, and querying data, complex business logic calculations, and multi-node data collaborative processing. At the same time, the logical business layer supports development in multiple programming languages ​​such as Java, Go, and JavaScript, and is compatible with various service development architectures such as microservices and monolithic services. Developers can flexibly write custom service code according to business needs without adapting to the exclusive development syntax and execution specifications of blockchain smart contracts, significantly reducing the backend development threshold of decentralized applications. Moreover, the running efficiency of custom services is not limited by the blockchain block generation speed or on-chain resources, and can support high-concurrency and high-complexity business logic execution scenarios.

5. The architecture according to claim 1, characterized in that, The decentralized container service in the extended blockchain can receive user container rental orders, generate distributed scheduling proposals, achieve global decisions through a "consensus mechanism", issue deployment instructions to target container worker nodes, execute container creation, monitor the status of worker nodes and containers in real time and trigger fault self-healing, complete order settlement and reward distribution and release resources; The "consensus mechanism" can be a lightweight PoS mechanism, with voting weights calculated based on the amount of staked assets of the management node and the node's online time. Voting data is written to decentralized storage after being signed by the node's private key, ensuring immutability and traceability.

6. The architecture according to claim 1, characterized in that, The Web3 domain name system in the extended blockchain is a decentralized domain name resolution system based on blockchain, which supports the mapping of resource names to IP addresses or decentralized storage CIDs; resource registration, resolution and update operations are executed through smart contracts, and registration information is stored in the blockchain to ensure immutability and transparency; the innovation of the Web3 domain name system lies in the adoption of a multi-layer URI resolution architecture, the first layer: application identifier resolution, which is resolved into service CID through smart contracts; The second layer: service resource resolution, which resolves the resource to a specific IPFS node address; The third layer: data object parsing, which is parsed into a connection handle for a decentralized database; at the same time, a parsing result caching mechanism is introduced: the most recently parsed record is cached in the client and a cache validity period is set. During the cache period, the same request directly returns the cached result, thereby reducing on-chain query operations.

7. The architecture according to claim 1, characterized in that, The hash value of the operation results in the data layer is written to the blockchain to ensure data integrity and traceability. Access to the decentralized storage and decentralized database in the data layer requires address resolution through the Web3 domain name system to achieve precise resource location and secure access. The architecture also innovates and optimizes the data layer components. For decentralized storage: a data sharding and encrypted storage strategy is adopted, automatically splitting files larger than 10MB into multiple 5MB data blocks. Each data block is encrypted using an encryption algorithm and uploaded independently to different storage nodes. The file's metadata is stored in the decentralized database. During reading, each shard is retrieved in parallel and decrypted and reassembled. For the decentralized database: a master-slave multi-active replication architecture is adopted, synchronously replicating data to more than 3 nodes during writing. Each data record is appended with a hash check value, and Merkle tree comparisons are used periodically to ensure data consistency across multiple nodes. It supports three data models: key-value pairs, document-oriented, and relational, and is accessed through a unified SQL-compatible interface.

8. The architecture according to claim 1, characterized in that, The various components of the extended blockchain achieve seamless collaboration through a unified standardized interface; it supports the access of third-party decentralized components to the architecture according to specifications, and the architecture is compatible with background computing tasks and interactive container tasks, adapting to diverse decentralized application scenarios such as instant messaging, distributed social networking, and data sharing, thereby improving the scalability and compatibility of the ecosystem; the unified standardized interface is implemented as follows: (1) Interface Protocol Layer: JSON-RPC 2.0 is used as the unified communication protocol, and all component interface requests and responses follow the same format specification: - Request format: { "jsonrpc": "2.0", "method": "<method name>", "params": { <parameter object>}, "id": "<request ID>"} - Response format: { "jsonrpc": "2.0", "result": { <result object>}, "id": "<request ID>"}; (2) Interface Abstraction Layer: Defines a standard interface description file for each component, and uses an interface description language to define the input and output specifications of each component: - Blockchain account module interface: connect(), sign(data), verify(signature), getBalance() - Decentralized storage interfaces: upload(file), download(cid), pin(cid), unpin(cid) - Decentralized database interface: connect(uri), query(sql), insert(table, data), update(table, id, data), delete(table, id) - Decentralized container service interface: deploy(container), start(instance), stop(instance), scale(count), getStatus() - Web3 Domain Name System Interface: register(uri, cid), resolve(uri), update(uri, newCid), revoke(uri); (3) Interface adaptation layer: Develop a unified SDK adapter for each component and encapsulate the private APIs of the underlying components into standard interfaces; (4) Interface Registry: Built-in service discovery and registration module. When each component starts up, it automatically registers its available interface list and access endpoints with the registry. The registration information includes: component type identifier, interface version number and compatible protocol, access address (HTTP / WebSocket / gRPC), authentication method (API Key / signature verification / no authentication) and health check endpoint address; (5) Interface call process: When the application layer calls the extension layer service, the following unified process shall be followed: - Step 1: Obtain the interface definition and access endpoint of the target component through the service registry; - Step 2: Construct a standard JSON-RPC request based on the interface definition, and attach the user signature and request timestamp; - Step 3: The request is routed to the corresponding component adapter via the interface adaptation layer; - Step 4: The adapter translates the standard request into the private protocol of the underlying component and executes it; - Step 5: The execution result is encapsulated into a standard JSON-RPC response by the adapter and returned to the application layer; (6) Interface version management: Each interface supports multiple versions in parallel. The version number adopts semantic standard. When the interface changes: - Backward compatible changes: Minor version numbers are incremented, and older version interfaces are retained; - Changes that are not backward compatible: Major version numbers are incremented, and old version interfaces are retained for at least a 6-month transition period.

9. A method for constructing the decentralized application architecture as described in claim 1, characterized in that, The method includes the following specific steps: First, expand the construction of blockchain infrastructure: Based on the basic blockchain, connect decentralized storage, decentralized databases, decentralized container services, and the Web3 domain name system to build an extended blockchain; the Web3 domain name system realizes the name service function of the entire Web3 system. The Web3 domain name system can run on the basic blockchain or run independently; the service access information of decentralized storage, decentralized databases, and decentralized container services needs to be registered in the Web domain name system; 2. DApp Application Development: Developers develop the DApp front-end interface based on presentation layer technology, write custom back-end service code for the logic business layer, and complete the service addressing from the presentation layer to the logic business layer and from the logic business layer to the data layer through the Web3 domain name system to realize the interaction between different layers; package the front-end interface and back-end service into container images respectively, upload the images to decentralized storage, and register the service name and image address through the Web3 domain name system; 3. DApp application deployment: Submit a container rental order in the decentralized container service. The registration parameters include task type, container hardware specifications, base image address, usage duration, startup script, and payment cost; successfully deploy the DApp front-end interface and back-end service.

4. Service registration and discovery for DApp application operation: Users initiate operation requests through the DApp front-end in the presentation layer. The DApp front-end resolves the URI of the target service through the Web3 domain name system and establishes a connection with the container service in the logical business layer. After receiving a request, the container service obtains the storage and database address of the data layer through the Web3 domain name system to enable interaction with the data layer; 5. Data storage and interaction in DApp application operation: Data interaction and storage. The container service in the logic business layer executes the business logic corresponding to the user request. If data operation is required, it interacts with the decentralized database or storage through remote calls to complete the addition, deletion, modification and query of data. Sensitive data is stored after being encrypted with the public and private keys of the blockchain account to ensure data privacy and security. The hash value of the data operation result is written to the blockchain to ensure data integrity and traceability.

6. Service scheduling and load balancing for DApp application operation: The decentralized container service monitors the resource utilization and running status of the container cluster in real time and dynamically allocates service requests based on preset scheduling rules; when the number of service requests exceeds the load threshold of a single container, new container instances are automatically started to share the load, achieving elastic scaling.

7. Self-healing of decentralized container service failures in DApp application operation: The decentralized container service monitors the status of containers and nodes through a node heartbeat mechanism. If a container failure is detected, a restart or migration command is immediately triggered, and the task is assigned to other healthy containers. If a node is detected to be disconnected, after confirmation through a consensus mechanism, the containers on that node are migrated to other nodes in the computing power pool to ensure service continuity.

8. DApp application termination: When the user exits the DApp or the service finishes execution, the container service terminates data interaction and releases temporary resources. Long-term stored data is kept in decentralized storage and databases, and the blockchain records complete operation logs and data hashes for subsequent auditing and verification; 9. The DApp application is now complete.

Images