OFF-CHAIN APPLICATION DEVELOPMENT FRAMEWORK
Because the state dependency graph requires a dedicated development framework. According to the usability principle, DAG provides a complete SDK for creating, tracking, and providing a complete solution for off-chain status. Through the SDK, the speed of popularizing DAG’s off-chain solutions has been improved, and it has a good reflection on the applicability of popularization.
Generally, we divide decentralized applications into two categories: simple applications and more complex multiparty applications. Microservices from real-world entities (such as data relay) and streaming media networks that pass through do not need to conditionally rely on other off-chain states, nor do they need a streamlined transport layer API on top of the routing layer. This situation can be met.
The multi-party application scenario has a relatively complex general structure. The SDK defines a set of design patterns and a common framework for developers to express conditional dependencies. We plan to extend existing smart contracts, through annotation processing and dependency injection, so that dependency information can be explicitly expressed without interference. The compiler detects invalid or unfillable dependencies and generates human-readable errors to help developers debug.
To help developers further reason about dependencies, the SDK will be able to serialize charts into common formats and make them easy to imagine and present. The SDK also provides a code generator parses the application binary interface (ABI), which specifies all callable functions in a signed smart contract, and generates bridge methods in the corresponding platform-specific language (Such as Java). The main advantage is that this method is type-safe and can run faithfully in smart contracts, providing static and powerful compile time, and when the method is dispatched to a second-tier network runtime, it is checked before execution. On the network side, the lifecycle of a multi-party communication DApp is handled during runtime. It also provides a set of metadata for secure multiparty computing, capable of supporting complex user scenarious such as games, communications.
If the receiver fails, whether it is an abnormal stop or a Byzantine conflict, the runtime will forward the dispute to the on-chain state. When the client enters a hang, the runtime handles the exception and performs a corresponding rollback. When the client comes back online, the runtime synchronizes the local state with the on-chain state. We name the decentralized applications running on the DAG DApps.
For local off-chain state management, the conditional state diagram is bundled in the DAPP by the SDK of the second layer network and passed to the off-chain runtime for execution. The runtime acts as the basic framework for creation, update, storage, and monitoring. The off-chain state is local to the KDAG network client. It can track internal logic and cause applications running on it to perform DAG traversal of state updates. This method can also make up for the lack of relay routing capabilities.
The core of the second-tier network runtime is to bundle native virtual machines (VMs) to run smart contracts. Although we intend to deploy the second-tier network to many platforms, networks, mobile devices, and loT devices, we enable developers to write common business logic only once and run the exact same on-chain smart contract code in each environment instead of having to implement multiple variants of the same logic. By adopting this principle, our goal is to eliminate code duplication and ensure a high degree of consistency across platforms.
In terms of scalability, the second layer of the network can also be built with the language that is most suitable for each platform(for example, Kotlin for Android and Swift for iOS). Through these advanced technologies, the development efficiency of developers has been significantly improved.
The runtime provides VM native bridging in different languages to enable platform-specific code to interact with the underlying business logic. For example, consider a DApp that eats chicken games running on iOS, and write a user interface in Swift and business logic written in solidity. Of course, the UI layer needs to query the game state of the VM, and it will be able to bridge through Solidity-Swift. Because the contract’s code is available at compile time, at that time, the code generator’s SDK generates a bridge method called chicken.getstate, which is dispatched to the VM for the actual query. We take advantage of language’s external function interfaces (Such as JNI) to reduce the overhead of calling back and forth between smart contracts and native code. Developers can also use the same debugging and analysis tools to debug on-chain smart contracts in related scenarios. In order to truly replicate the state changes that may occur on the chain, in the second layer network runtime environment, the VM executes with the same bytecode as it does. If they are executed on-chain, then there are some differences to be aware of.
The first difference is that the VM needs to update the storage state locally rather than on the blockchain. To achieve seamless and transparent interoperation between VMs and the rest of the second layer network, we will implement a set of storage backends that bridge the platform-specific API VMs.
The second major difference is that due to the long connection, the local virtual machine can be shut down unexpectedly at any time, such as a software error, a hardware failure, or just a power outage. Therefore, we need to implement robust logging, inspection, and submission protocols. The third small difference is that the logic of the calculation can be omitted because the execution is performed locally, and charging gas is meaningless. The bundled VM needs to be lightweight and Ethereum VM, we are working on a more common virtual machine implementation mechanism(for example, Web Assembly), with the goal of supporting more contract languages and other blockchains.
In our approach to VM implementation, we will apply the latest VM technology, including advance compilation(AOT) and just-in-time compilation (JIT) to achieve near-preliminary compilation and performance through smart contract execution. Rather than interpreting its binary code, as most Ethereum virtual machines currently do, we talk about compiling the code into a lower-level binary machine language to make it closer to the native code. If the code for a contract is available at compile time (for example, the contract is already deployed on the chain), we statically compile ahead of time and link the binary with the rest of the application. For dynamic contracts, they are loaded at runtime, and we analyze them for frequently called functions (i.e, “hot” code) and perform on-the-fly compilation. We believe that the combination of these two technologies will achieve a great balance between performance and energy consumption, which is critical for mobile and loT devices.