AppLayer Explained: Modular EVM Layer for Cross-chain Applications

Disclaimer: The content presented in this article, along with others, is based on opinions developed by the analysts at Dewhales and does not constitute sponsored content. At Dewhales, we firmly adhere to a transparency-first philosophy, making our wallets openly available to the public through our website or DeBank , and our articles serve as vehicles for self-expression, education, and contribution to the ecosystem.

Dewhales Capital does not provide investment advisory services to the public. Any information should not be taken as investment, accounting, tax or legal advice or as a recommendation to purchase, sell or hold or to pursue any investment style or strategy. The accuracy and appropriateness of the information is not guaranteed by Dewhales Capital.

1. Introduction
2. AppLayer Review
3. AppLayer components and network participants
4. Transaction lifecycle in AppLayer
5. What advantages does AppLayer offer for GameFi and DeFi developers
6. Team
7. Partnerships and integrations
8. Backers
9. Conclusion

1. Introduction

The AppLayer actually has a rather long development history focused on scaling solutions. Initially, the team worked on Æverest++, which emerged during a hackathon at the Avalanche Summit 2022. The project had a simple goal — to build a deterministic subnet that met two key requirements: support high throughput and be built using C++. This development later evolved into SparqNet — a protocol with tools for creating subnets and decentralized applications with record-breaking transaction speeds, enabling what was once thought impossible.

SparqNet offered great value in a range of protocol-level services, starting with a bridge that processes transactions from any EVM chain within the SparqNet and beyond. Additionally, SparqNet is not language-dependent, and its bridge is compatible with any chain, ensuring seamless transfer of smart contracts and assets. Even back in 2022, the team leaned towards GameFi and DeFi, and they continue along this trajectory.

Currently, we see this project as the AppLayer — a modular EVM layer for cross-chain applications. How does it work, and how is it different from other solutions? Let's take a closer look.

2. AppLayer Review

First, it's worth noting that while the AppLayer is EVM-specific, it has several unique features. In particular, the AppLayer aims to solve inherent EVM issues. For example, in the case of the Ethereum Virtual Machine, you won't be able to perform any of the following actions:

• Execute a function loop more than 50 times due to gas limit restrictions;

• Have a stack size greater than 16 variables due to EVM limitations;

• Parallelize the execution of multiple contracts (for instance, each time a new block contains multiple transactions interacting with different contracts, you need to load the contract, analyze it, and save the changes to the database for each contract in a specific order).

As quoted by Itamar, the AppLayer’s developer and CTO: "The biggest problem is that everyone is sharing the same computer, and that computer is a Commodore 64."

Thus, AppLayer, being a modular blockchain with multiple layers, aims to address these limitations. It introduces a blockchain system that includes pre-compilation with state tracking, allowing third parties to deploy and initially maintain these contracts within a unified network that shares its state. This is all supported by EVM integration, pre-compilation with state preservation, and chain abstraction.

Moreover, one of the biggest challenges in blockchain development is handling block rollbacks. For instance, in the Bitcoin chain, if we assume there's a final block followed by another block, and a node receives a block that replaces the last one, the next block and all transactions within it are also replaced, leading to a rollback of the blockchain state by one block.

Bitcoin and other derivative blockchains follow the "longest chain rule." However, rollbacks expose problems in this rule. For example, when a developer creates dApps where they have to deal with such special conditions, it can require significant effort depending on the size and/or complexity of the application.

The solution to this problem is to completely avoid the rollback condition. This can be achieved by deterministically defining which network node can create a block, thus eliminating block race conditions and synchronizing everyone in the network with the same final block.

AppLayer implements this concept as random deterministic proof-of-stake (rdPoS), which combines a block overload system and a random number generator system, allowing only one validator to create a block at any given time, thereby avoiding rollbacks and achieving consensus in ultra-fast networks.

3. AppLayer components and network participants

At a basic level, the AppLayer network consists of three parts:

• A Blockchain Development Kit (hereinafter referred to as BDK) with extensive developer documentation, allowing them to easily create their own AppLayers with unprecedented freedom.

• An EVM network built using the Blockchain Development Kit, which allows developers to deploy EVM smart contracts and scale them with C++ pre-compilation and state tracking.

• A network that enables data and asset aggregation between these application chains and external chains, referred to as the Chain Abstraction Network (CAN).

Thus, blockchains created using the BDK can interact with each other through the AppLayer.

For this system to function, the AppLayer has several participants and auxiliary components:

• Validator — a computer, usually hosted in a data center and often referred to as a server, whose sole purpose is to operate and secure the blockchain network. Validators are required to stake at least 200,000 $APPL tokens and are responsible for creating blocks, generating the "random" seed used to select the next block creator, and collecting and signing bridge and block data. According to the documentation, the team is exploring the possibility of implementing slashing mechanisms.

• Sentinels are similar to Validators, except that they cannot create blocks or operate independently. Both randomly selected Validators and Sentinels must submit the same data to the requesting party; otherwise, they will be reported to the network as a malicious node. AppLayer Labs and its partners host them to ensure this doesn’t happen. Sentinels are open to being hosted by trusted third parties and are subject to a rigorous KYC process. Eventually, as the network and core technology evolve, Sentinels will be gradually phased out in favor of a fully permissionless system. Sentinels are also required to stake 200,000 $APPL.

• Application Chain — the central part, also known as AppLayer™, consists of blockchains built using the AppLayer's Blockchain Development Kit (BDK) and deployed on the AppLayer's Chain Abstraction Layer. AppLayer's BDK currently supports C++ and Solidity for development, with plans to add other languages such as Rust, C#, Golang, and more. These application chains are compiled into binary files for efficient execution alongside Solidity bytecode.

• Bridge — a component that allows AppLayer-supported blockchains to communicate natively with each other, using the Chain Abstraction Network (CAN) as an intermediary, where AppLayer serves as the bridge between two dApp chains trying to communicate. The bridge is also maintained by sets of Validators and Sentinels.

• rdPoS (Random Deterministic Proof of Stake) — allows Validators and Sentinels to handle block overloads and random number generation. The core of rdPoS is RandomGen, a deterministic uint256_t generator, used for almost everything related to consensus. This deterministic randomness ensures that each node has a chance to respond to a given request (block, randomness, bridge, etc.), while also ensuring that the selected nodes are truly random and not compromised by malicious actors.

4. Transaction lifecycle in AppLayer

1. The list of network validators is generated randomly and sorted using the "randomness" seed from the previous block.

1. The first validator from the list becomes the block creator, while at least four others generate a random 32-byte string and perform two transactions with it: one containing the hash of the specified string and the other containing the string itself, both signed.

1. The hashes are verified to ensure they match their corresponding random strings.

2. The first validator creates a new block by combining and hashing the random strings of the other validators to generate a new "randomness" seed, which will be used in the next block.

1. The block is signed and published to the network by the first validator, while the other validators verify that all transaction signatures (both random and hashed) match the list generated at the beginning.

2. The genesis block (the very first block in the chain) provides a valid fixed randomness since there is no previous block before the genesis from which randomness could be derived. Additionally, at least five hard-coded validators are required to bootstrap the network, as each block requires at least four validators to confirm the string and hash transaction signatures and one to sign the block itself.

On a separate note, the documentation has very detailed descriptions of internal functions and files for BDKs and contracts - both regular, EVM and pre-built.

5. What advantages does AppLayer offer for GameFi and DeFi developers

GameFi:

Previously, GameFi developers had to manually decode transaction data and call the corresponding function in Dynamic Contracts. For example, in a game where a player earns an in-game token after reaching a certain stage, the developer had to manually decode this transaction and initiate the token issuance. This process could be time-consuming and prone to errors.
With the new auto-registration feature, this process is automated. Dynamic function identification and registration allow the system to automatically issue the token as soon as the player reaches a checkpoint.

In the past, using std::string to store various types of data led to confusion and complexity, especially in games where multiple data types are used. For example, a game might use bytes to store image data, literal strings for player names, and hexadecimal for color codes. Storing all of this in std::string was not intuitive.
With the new update, developers can store these types in appropriate types — Bytes, BytesArr, and BytesArrView — resulting in more readable code and fewer debugging issues.

The overhaul of the P2P protocol can radically improve multiplayer game performance. In a fast-paced multiplayer game, every millisecond counts. Using Websockets for P2P communication can cause latency and degrade the gaming experience.
By switching to Raw TCP Sockets in the new update, communication between peers has become much faster and more efficient. This means quicker game synchronization and data transmission, leading to an improved gaming experience, more real-time interaction, and happier players.

Before simplified contract management via reflection, developers had to manually register dynamic contracts in the Contract Manager, which could lead to complex workflows. Imagine a game that involves several smart contracts — one for player rankings, another for token issuance, and yet another for in-game purchases. Each contract had to be registered manually, which was a tedious process.
The introduction of proper contract return types simplifies the development process. Consider a game with a marketplace where players can buy, sell, and trade in-game assets. Previously, when a player purchased an item, the contract function would return a generic type, requiring the developer to handle type conversions and interpretations. This was complex and error-prone.

DeFi:

Previously in DeFi, if a developer wanted to encode a function in a dynamic contract that allows token swapping, they had to manually decode the transaction data. For example, swapping one type of cryptocurrency for another involved manually registering each step of the transaction.
With auto-registration, this process is simplified, as the system can dynamically identify and register functions in dynamic contracts.

Storing various data types, such as transaction details, addresses, or token information, in std::string could lead to confusion and increased debugging time, reducing the overall efficiency of DeFi operations and slowing down the execution of smart contracts.

A significant overhaul of the P2P protocol can enhance the performance of DeFi applications. Previously, using Websockets could slow down transactions or result in inefficient data transmission.

Before the update, registering dynamic contracts for managing liquidity pools, staking protocols, or yield farming schemes had to be done manually in the Contract Manager. This could be time-consuming and complex.
Now, this update automates the registration process, simplifying the management of multiple contracts, allowing developers to focus on building more advanced DeFi protocols instead of managing administrative tasks, thereby accelerating the evolution of DeFi applications.

With the introduction of proper contract return types, interactions have become simpler. For example, if a user wants to check their loan balance, the contract function now returns the correct type, eliminating the need for complex type conversions. This simplifies the user experience, making DeFi more accessible to a broader audience.

6. Team

AppLayer has experienced founders as well as 5 Developers, 3 BDs and 3 Marketing team members.

Michael Weinrub, Co-Founder and Head of Business - has been in the crypto space since the very early days of Bitcoin. Michael has experience building companies from 0-1 and have worked in technology solution sales for companies like Microsoft and Citrix.

Itamar Carvalho, Co-Founder and CTO - Itamar  has been building custom blockchains for businesses since 2016 and leverages a lot of the knowledge and experience from these custom implementations. Also Itamar had been working on creating a highly flexible blockchain solution dating back to 2018 which allows for super custom blockchain systems to be implemented and we decided in 2022 to merge our two frameworks as an SDK other builders could leverage leading to a hackathon win at the Avax Summit.

7. Partnerships and integrations

AppLayer has a wide variety of partnerships in different areas, including those inherited from SparQnet before the rebranding: L2, DeFi, infrastructure solutions, AI and tools, but with a special focus on partnerships in Gaming. 

In the L2 and Infrastructure track, AppLayer has partnerships and integrations with projects and products such as IoTex, KuCoin Chain, Avy Domains, Covalent, P2P Cloud, Biometric Financial, and NUVO. These integrations are aimed at both increasing the performance of existing solutions and creating new products or add-ons through AppLayer technology. And they are also implemented to introduce additional functionality into AppLayer itself.

In the DeFi and NFTs track, AppLayer has partnerships and integrations with projects such as OilSwap, EZSwap, StreamNFT. This track involves user experience improvements with mutual integrations.

In the AI and Tools track, AppLayer has ties with projects such as OpenFabric, ChainFuse, SendingNetwork, and Mises Browser. Shared ambition fuels these partnerships, paving the way for seamless integration between decentralised finance and artificial intelligence.

The most extensive track that stems from the previous section is partnerships and intgerations towards Gaming, where AppLayer can fully deploy the essence of its product as Appchains, offering impressive speed, scalability and multilingual support. In particular, gaming projects are utilising AppLayer's OrbiterSDK to create complex smart contracts to take the gaming experience to the next level. These projects include MetaStrike, CheersLand, Kingdom Karnage, CatacombCrawler, Meta2150s, Cosmic Force, Yesports, Ready Player DAO, LULU Market, Bionic Owls, Apes Planet, Battle For Giostone, Janus Network, HypaVerse, Eternis, Mental Maze, Stratagems.world, GGNation, Battledogs Arena.

8. Backers

Due to its experience and extensive connections, AppLayer has Backers like Dewhales Capital, Cogitent Ventures, Big Brain Holdings,  Magnus Capital, Curiosity Capital, Builder Capital, Zephyrus Capital, FrensDAO, Rengen Family Office, Brian Johnson (Republic Capital), Connectico Capital.

9. Conclusion

The AppLayer represents a significant advancement in blockchain technology, addressing long-standing limitations within the Ethereum Virtual Machine (EVM) ecosystem. By leveraging its modular architecture and advanced features, such as Random Deterministic Proof-of-Stake (rdPoS) and enhanced blockchain development tools, AppLayer is poised to offer unparalleled scalability, efficiency, and flexibility for cross-chain applications.

For developers in the GameFi and DeFi sectors, AppLayer delivers substantial improvements. Its automation features, such as dynamic contract registration and enhanced P2P communication protocols, streamline development processes, reduce debugging complexity, and enhance application performance. These advancements promise to significantly boost user experience, making the platform highly attractive for new and existing projects alike.

The AppLayer’s strategic partnerships and integrations with key industry players across L2 solutions, DeFi, NFTs, and AI demonstrate its broad utility and collaborative approach. The focus on gaming, supported by a robust ecosystem of gaming projects, further emphasizes its potential to transform and elevate the gaming experience within the blockchain space.

AppLayer links:

Website | Twitter | Discord | Medium | Documentation | GitHub

To help us improve and provide you with the best content possible, we'd appreciate it if you could share your thoughts and opinions on the article you just read. Your feedback is very valuable to us and won't take more than 2-4 minutes.

Also, this post is public so feel free to share it post as well

Thank you so much! ❤️

Our links:
🔗 Website
🐦 Twitter
✉️ Substack
🔸 DeBank