AELF BLOCKCHAIN ($ELF) | Aelf Will Launch Mainnet on 10th

[aelf blockchain]

✏️Sign up for the aelf Hacker Bounty Writing Contest.  Let's see how good you are at #blogging. Ledger

💰Win a prize of up to 888 ELF = 88 USD   

⏰7th August - 16th August   

You have 9 days to sign up & submit your articles.

✅ Topic: The Future of aelf Cross-Chain Transfer Protocol   

1️⃣ You can submit more than one article, but the content must be original. 

2️⃣ Explain your understanding of the CCTP or its role in blockchain security & future application in aelf-eco.

💥How to Submit: 

1️⃣ Publish your article(s) on at least 2 platforms, for example, tech blogs, forums, Medium, Twitter, etc.

2️⃣ Submit this form with the article link: : https://docs.google.com/forms/d/e/1FAIpQLSeHs34I9iQr41F9oKnIQfKMmmp28M0EWZ0HwBvRkFPceZqShA/viewform?usp=sf_link

⚠️ We will review all submissions & announce the winners at the end of the event.

[aelf blockchain]

[aelf blockchain]

[aelf blockchain]

[aelf blockchain]

A Beginner’s Guide to Understanding the aelf WhitePaper (Part 1)



What is a blockchain?

In the Bingo game DApp demo, we’ve already talked about the aelf real random number generator, which can generate unpredictable random numbers between 0 and 255, making it a useful tool. The interaction logic of this DApp’s backend is very much the same as that of blockchain smart contract. But this DApp is so simple that it doesn’t really show what aelf is capable of. In fact, aelf’s got an awful lot more in its arsenal. When it comes to supporting enterprise-level applications, this is where aelf comes in. For someone who is new to aelf, the best way to aquaint yourself with aelf’s technology is to read the aelf technical whitepaper.

If you have read the whitepaper of some blockchain projects, you might find them difficult to understand or even make no sense. As a result, readers (not speculators) are often at a loss as to what these projects are trying to do. Unfortunately, many projects often assume their readers are all experts and can understand the whitepapers with no difficulty. In reality, most blockchain projects are much more complex than Bitcoin. Therefore, if readers only know how Bitcoin works, they still cannot understand these projects’ whitepapers. If you want to draw potential developers to your platform, it is necessary to provide a beginner’s guide to understanding your whitepaper.

That’s why we have prepared this guide. But before reading this guide, you can quickly go through our website, read our slogan, watch the promo video on the homepage, download the whitepaper and before long, you may find something you cannot understand. Don’t worry, let’s start with aelf’s slogan:
Aelf, a Decentralized Cloud Computing Blockchain Network

Cloud computing is the most fundamental feature driving the entire aelf blockchain ecosystem. Running data intensive computation on multiple computers is obviously more cost-effective than on one mainframe computer. Suppose these computers are assembled in a huge building called data center, say thousands of computers, with professional maintenance by a company, say, Amazon, then these data centers are called a cloud, such as Amazon Web Services (AWS).

Having said that, it is still hard for a beginner to understand why cloud computing gives aelf an indispensable edge. This is because most people, including some in the blockchain sector, don’t have a sound knowledge of some of blockchain’s key concepts. As a result, it is difficult for them to move on to the more complex technology, let alone analyze the pros and cons of a blockchain project and its potentials. As far as I know, I think it is necessary to set the record straight on two important blockchain concepts.
What is a blockchain?

This is nonsense! We all know blockchain is a tamper-proof distributed ledger or database technology, as any professional would explain to you. You most probably have memorized this definition by heart and would rattle it off whenever someone asks you what blockchain is. The truth is, this definition is very misleading. Blockchain is not a new invention, nor does it have any magical features (for example: the magical tamper-proof feature). In this sense, it is different from the magical stuff in an alchemist’s furnace. Instead of viewing blockchain as a ledger or database, it is better to see it as a distributed system. So what is a distributed system?

A distributed system is a large number of interconnected computers, which makes it a peer-to-peer system. It was invented around 1960, long before the advent of Internet. There are already a lot of well-known distributed-system-based softwares, such as Bit-torrent and Netflix. In these softwares, people can upload the files on their computers to the P2P network and anyone can download them. But a distributed system can do much more. In the distributed system discipline, people have to solve a big problem, that is, everyone (every node) in the P2P network need to make an unanimous decision no matter what information they receive, and this unanimous decision is what we call a consensus, and this problem is called the Byzantine General Problem.

Say there are three Byzantine generals wanting to attack the same fortress, and they are at three different locations, they could only rely on couriers to send messages. In this situation, any general can only make a decision based on the other two generals’ messages. If one general wants to attack, he let couriers send the “attack” message to the other two generals, so do the other two generals. If the generals are all loyal, each of them should receive “attack, attack” coming from other two generals, and all three generals would attack the fortress. But if one of them is a traitor, he could send one general “attack” and send the other “retreat”, this other general will receive “attack, retreat”, if he follows majority rule, he will not make a decision because the votes on attack and retreat are the same. At the same time, the other general will attack, and the result is that these three generals will not reach a consensus on attack.

The generals are just like the nodes of a distributed system (i.e. blockchain). There are at least two points worth noting: first, all massages (transactions), have to be sent to the other generals (nodes) to keep them informed; second, all the nodes have to reach a consensus.

The first point means that it takes time for sending a message to all the nodes in a huge network, the second means that after a new block has been broadcast to the entire network, there should be a mechanism for all the nodes to agree on this block (a package of messages or logs), and it also takes time.

[aelf blockchain]

[aelf blockchain]

A Beginner’s Guide to Understanding the aelf WhitePaper (Part 2)



If you have read the whitepaper of some blockchain projects, you might find them difficult to understand or even make no sense. As a result, readers (not speculators) are often at a loss as to what these projects are trying to do. Unfortunately, many projects often assume their readers are all experts and can understand the whitepapers with no difficulty. In reality, most blockchain projects are much more complex than Bitcoin. Therefore, if readers only know how Bitcoin works, they still cannot understand these projects’ whitepapers. If you want to draw potential developers to your platform, it is necessary to provide a beginner’s guide to understanding your whitepaper.

Yesterday we talked about what is the blockchain, today we would like to introduce the smart contract.

What is a smart contract?

The definition of smart contract in many books, articles and videos is very misleading from a developer’s point of view. They often explain that smart contract is a new generation of legal contract, deed, or proof of ownership, etc., and since they is code-based, smart contracts are highly intelligent. But this definition is only for those working in finance or other sectors who do not know computer science and coding. They need only to know that smart contract is very powerful, and that’s enough (in some sense, this is all very well). But what is smart contract exactly?

In fact, smart contract is neither smart nor is it a contract, it is just a string of code. So why do people call it smart contract rather than a more intuitive name? That’s because it has been called smart contract all along, and programmers are too lazy to change the name. Smart contracts, like Python or Java codes, are written in a high-level language, and compiled into bytecode to be run as opcode on a virtual machine. You might already know things like JVM and Python-VM, or EVM on the Ethereum blockchain. For the aelf project, smart contracts are written in C#, and they are run on the .NET framework after being compiled.

Calling the execution of a smart contract is in some sense similar to making an http request: In a traditional requesting process, you type in a URL to tell the remote server to send you back some data (html, css, javascripts, etc.), or tell the server to execute some server-side programs which could be written in Java to change some states of the server. The same is true for smart contracts. Just like a request, we send a transaction to the target contract address, whether it costs cryptocurrency or not. When the contract receives the calling request from the transaction, it will execute some specific functions in the smart contract code, depending on the parameters in your transaction. If there is enough gas, the executing result will change this smart contract’s state, send you the data of the result, or send you cryptocurrency.

However, in comparison to the instant response from a remote server after an http request, the execution of a smart contract will take some time after you send a transaction. As I have mentioned in the Bingo game article, when you send a transaction, the transaction will be broadcast to as many nodes as possible, and every mining node will include it into its candidate block. After a while, when one mining node produces a new block, it will broadcast this block to other nodes, of course, this block is confirmed. This process will take some time, and for most real applications only producing one new block cannot guarantee the safety and validity of the transaction, so more blocks should be concatenated consecutively after this block. On the aelf blockchain, at least 8 new blocks should be generated after the production of the block containing the transaction. Of course, if one block containing this transaction is finally packaged by a mining node, when satisfying a certain consensus condition, the target smart contract is then executed on a full node (full node can be a mining node, or vice versa). But with more and more blocks being generated after this block, it will be virtually impossible to tamper with the execution result of this smart contract by forking to another chain.

In the Bingo game example, the “bet” button is such a method in our smart contract. When we place a bet, a transaction is sent to the contract. After one block is packaged, the method is executed and thus the contract will know how much you want to bet. In order to let the contract know your bet amount and to avoid anyone tampering with your bet amount, you have to wait until 8 subsequent new blocks are produced. So how long does it take? As is shown in the last article or in the demo video, it takes about 30 seconds. In fact, no one knows exactly how long does it take to generate 8 blocks, but we know that after 30s more than 8 blocks must have been already produced.

Having explained these two basic concepts, it is much easier to understand any blockchain projects, including aelf. No matter how sophisticated the technologies a blockchain project applies, they will all be based on these two concepts.

In the next article, we will dive into the aelf blockchain whitepaper to demystify all the important features of this enterprise-level project! To be continued.

[aelf blockchain]

[aelf blockchain]

[aelf blockchain]

The launch of BancorV2 has generated lots of buzz in the last few days.

aelf Resource Token is based on Bancor, which ensures the instant exchange between resource token and ELF.

In the future, aelf will also launch its own DEX and build a decentralized lending platform.

[aelf blockchain]

[aelf blockchain]

[aelf blockchain]

A breakdown of the aelf blockchain whitepaper — Part 1



Why cloud computing is a must

We have already mentioned that cloud computing is a key feature. For Bingo Game, the aelf team only deployed 2 simple smart contracts (compile a C# file into intermediate code and upload it onto the aelf blockchain by creating a transaction with a special contract). Anyone can compile C# contracts and deploy them on the blockchain so that other people can invoke the contract to do whatever they want, say, developing a DApp. If only a few people are using the aelf blockchain, then it does not really matter. However, for any enterprise-level scenarios, this blockchain architecture is a recipe for disaster, just think of the torrent of data flowing in a supply chain. Under such circumstances, the number of deployed contracts will be in the MILLIONS, and if they are invoked by a lot of people, the transactions and contract code executions can easily soar to BILLIONS! As mentioned, a full node or mining node (also “block producer”) executes contract opcode under the dotnet framework, if we give millions of contracts for this node to execute, it will take so long a time that no application can handle. Try to imagine if there are 2,500,000 contracts queuing up to be executed by a single computer before your contract is executed, it would be so frustrating! For a common blockchain, this is called “network congestion”.
It is therefore easy to see why a cloud computing solution comes in handy. Instead of using a run-of-the-mill computer as a full node, why not use a super-computer?

Why not run in parallel?

In addition to cloud computing, nodes can also run smart contract code in parallel on the aelf blockchain. Before aelf, smart contracts on all blockchains are executed in a single-threaded way, like the event loop of the Javascript engine. But the aelf team, excelling at C#, found that the C# infrastructure can support parallel execution, so they applied this feature to the design of the aelf blockchain architecture. Combined with some designing patterns, the aelf team finally designed this mechanism, ushering in a new era of blockchain nodes with parallel execution.

For example, suppose there are 1,000 tasks to be executed (transactions or contracts), the aelf system will first check if these tasks change the same value simultaneously, if they do, then they will be executed in sequence because we don’t want these tasks to conflict with one another during parallel execution. If they don’t, then these non-conflicting tasks can be executed in parallel where they are divided into several groups according to whether they conflict with each other. So the result will be, say, 4 groups: [200 tasks, 300 tasks, 250 tasks, 250 tasks], and the overall execution speed will roughly be 4 times faster.

Just like Marvel superheroes assembled together to fight Thanos, aelf combined cloud computing and parallel processing to make sure any enterprise-level use cases have a seamless experience. Now let’s dive deeper into the technical stuff..

Delegated Proof of Stake (DPoS) and aelf Delegated Proof of Stake (AEDPoS)

As mentioned in “What is a blockchain” in the last article, in a distributed system, it always takes time for a transaction or a block to be broadcast to every node when there is a large number of nodes involved. We know that in the Bitcoin system, only mining nodes are responsible for producing new blocks, so why not reduce the number of mining nodes as much as possible? As a result, the Delegate Proof of Stake(DPoS) consensus mechanism came along. Proof of Stake is a variety of consensus algorithms that use something (for example, the token amount) as stake to package new blocks, the higher the stake, the likelier this new block will be confirmed. In DPoS, there aren’t so many mining nodes (strictly speaking, there is no mining concept in PoS, rather, they are called validating nodes), because we simply delegate a very few validation nodes to produce blocks and broadcast them to other delegated nodes. Clearly, DPoS solved the problem of long broadcast time in the blockchain distributed system. However, since there are only a few validating nodes at play, how can we prevent these nodes from plotting with each other to manipulate the whole chain and undermine the decentralized principle? That’s why all types of DPoS have a strict voting mechanism to ensure these elected delegates act fairly and transparently.

In fact, DPoS stems from the EOS blockchain project. In DPoS’s design, there are at least three types of nodes: block producer (BP, or less strictly, mining node), candidate node and common node. The candidate node is a block producer (BP) candidate who applies for the role via a smart contract. Theoretically, any common node with sufficient computing power (in aelf, we recommend a computer with at least a 8-core CPU, 8GB of RAM and 500GB SSD) can be a candidate node. In practice, only a small fraction of them can be real BP through voting by other common nodes. On the financial side, a typical blockchain project which chose DPoS as its consensus mechanism always rewards nodes with some tokens if they vote for candidates, thus encouraging participation. The voting mechanism is essentially a smart contract with voting methods that request voting node’s address, who it votes for and how many tokens they want to stake (the higher the stake, the greater the vote weight). In aelf, we don’t know how many common nodes can become candidate nodes, but only the 17 candidate nodes with the most votes can become a BP.

With some special techniques, aelf has upgraded DPoS to the unique AEDPoS (aelf DPoS). The creators have drafted a specific suite of round-based block production mechanism. If you look this up in the whitepaper you’ll see lots of mathematical expressions, but don’t worry, the core concept behind it is quite simple and straightforward.

Before explaining, let me remind you of two things: First, the real random number generation method (we’ll talk about this in details in the next articles). This method can not only generate a random number, but also shuffle a collection (say, a list), which makes the process impossible to be predicted, manipulated and plotted. Second, the Byzantine General Problem. Let’s have a quick recap of this problem: formally proposed by Lamport et. al in 1982, the Byzantine General Problem imagines a three-generals scenario, as was mentioned in the last article, if anyone of the three is a traitor who wants to alter the message, it is impossible for the three of them (the whole system) to reach consensus. Based on this observation, Lamport deduced that in the case of 3n nodes (n is a countable number) in the system, if there are at least n nodes who are traitors, the whole system can never reach a consensus. So in many other articles, you can always see the following statement:

If there are f evil nodes, there should be at least 3f+1 nodes for the distributed system to be useful.

In aelf’s DPoS, if the aelf main/test net is launched, the default setting is 2N+1 BPs, in the first year N=8, and N increases by 1 every year. There are 17 BPs at the very beginning. If 13 (no more than 5 BPs corrupt the network) of them behave normally, all the BPs will finally reach a consensus. Under this condition, aelf defines a round in which every BP packages blocks sequentially, and after that, aelf randomly picks a BP to package blocks. After this round, we shuffle the BP list, and repeat this process. The key is that the block production sequence is random enough to prevent BPs from plotting with each other. Of course, there are other designs involved, but we don’t need to know them to understand how AEDPoS works.

Like common DPoS, the BP list is always changing based on their votes. A common node can vote for BPs and candidates at any time (the aelf blockchain now supports this feature), and the aelf system will check the ranking every month, those who are at the bottom will be replaced by candidate nodes with higher rankings.

[aelf blockchain]

📢🔥 ATTENTION, please!

aelf Wallet is now available on Android and iOS!

Click the link 🔗 to download and try it out!

Android: http://d.alphaqr.com/aelfwalletandroid

 IOS: https://testflight.apple.com/join/TclFysmO

[aelf blockchain]

[aelf blockchain]

[aelf blockchain]

A breakdown of the aelf blockchain whitepaper — Part 2



Breaking down the aelf side-chain

Cloud computing, parallel processing, and AEDPoS have greatly improved the execution performance of any kind of smart contract, but when they are applied to enterprise-level scenarios, new problems crop up. To begin with, in software design, it is a rather bad idea to program all the methods in the same class. We always write a series of classes to inherit a base class, in order to decouple the functionalities and make the class extensible whenever needed. The same also applies to blockchain design. Second, since all the data and transactions are accessible to anyone through a blockchain explorer, if we put the smart contract and data of different enterprises or government sectors on a single blockchain, then everyone can see them, which means there will be no data privacy. Although there are encryption techniques which can mask data, such as zero knowledge proof, it is always better to put the data of different enterprises on different blockchains.

Based on these considerations, long before other projects even realized it, aelf proposed that side-chain technology should be applied to this scenario. Unfortunately, for someone who is new to blockchain, it is almost impossible to understand how side-chain works. Side-chain is not what it literally means, it is not subordinate to the main chain. On the contrary, a side chain is a blockchain distributed system with the same functions and nodes as a main chain (say, the aelf blockchain). As mentioned above, we can put the data of different enterprises on different blockchains. This means we can build many blockchains, and work magic (of course not magic in its literal sense) to make these chains connect to the aelf main chain (in fact, we can call any of these blockchains a main chain and the rest side chains). Currently, the most popular method of connecting any two blockchains, which we also call cross-chain, is using a middle-man. When we want to use bitcoin to play a decentralized game on Ethereum, we need to send a transaction with some amount of bitcoin to a locking bitcoin address, then the middle-man will exchange the locked BTC for ETH at a certain exchange rate and allocate to you the equivalent amount of ETH on Ethereum, which you can use for playing games.

But in aelf, we use a metadata indexing method, which is more straightforward. Unlike other projects who built on the blockchains of those already successful projects (such as Ethereum or the HyperLedger fabric framework for consortium blockchains), the aelf team has writen all the code and build the infrastructure from scratch. From the beginning, the aelf team has defined how the data structure of a blockchain, a block, a transaction etc. should look like in C#. In an aelf blockchain data structure, there is an attribute called blockchain ID, which is a unique hash; and in block data structure, there are several attributes called blockchain ID , Merkle tree root and related side chain block list. There is also one more important thing: all of aelf’s data structures are serialized and stored in Redis (a popular key-value pair database system), so is the side chain information. As a result, as the aelf main chain is growing with block production by BPs, other side chains can send transactions to cross-chain contracts, which then execute the related code to connect to the main chain’s network port and request the main chain to index the side chain block and pay the indexing fee.
The core issue here is how to index a side chain: when a main chain (the block data structure on the main chain, or the data records with main chain ID in Redis), receives a request from a side chain, it adds the side chain’s block head data structure to the related side chain block list, which means theoretically we have indexed or related a side chain. We have mentioned that there is also a blockchain ID in each block, this attribute allows a main chain to index blocks from different side chains. When a user on a main chain wants to access data on a side chain or vise versa, they just need to find the target block on the main chain and its related side chain block list, and then find the target block on the side chain via key indexing.

As we will explain later, blockchains for different application scenarios generate blocks at different speeds. Under such circumstances, a chain with slower speed might index many blocks from a chain that produces blocks faster. This method can be applied to scenarios such as forking.

In practice, we can build any number of blockchains, and relate it via indexing to the aelf main chain, with a specific category of smart contracts running on each of them. For example, we can allow only banking-related smart contracts deployed on a specific blockchain, and e-commerce smart contracts on another. Our whitepaper summarizes it best:
One chain, one contract.

Moreover, the indexing method can make many blockchains into a hierarchical tree structure, the root being the so-called main chain. That’s because a related blockchain can then again index another blockchain as its side chain, and the process can keep going on. Logically, this is in perfect accordance with hierarchical taxonomy, for example, the financial sector has many subcategories, such as banking, lending, investment and insurance, and under investment banking, there are venture capital, investment bank etc… Each subcategory is supported by an indexed blockchain.

So how do these blockchains collaborate in a distributed system? First we need to be know that any node in a distributed system is just a software instance running on your computer, or a process. In TCP/IP, a node is allocated a port number, so we can run any number of this type of instances on a computer. However, each instance has its own port number: we can run several blockchain nodes, one IPFS node, one bit-torrent node and etc. simultaneously. In aelf, you should first start a main chain instance, and then you can build and run a side chain instance. Transactions broadcast on the side chain are collected by the BP nodes (block production nodes) on the main chain. When smart contracts deployed on the side chain is triggered, the BP and full nodes on the main chain will run them.

Aelf — a blockchain based operating system

To perfect the design of our software system, aelf made the system extensible, flexible and pluggable. Just as there are thousands of Linux OS with only one Linux kernel. As Ethereum Founder Vitalik Buterin has explained, Ethereum can be seen as a world computer because there are lots of smart contracts running on it, and the contract execution results are consistent in all the distributed systems around the world. This idea is also embedded in aelf’s system and we call it a “blockchain infrastructure operating system”, or a distributed operating system.

Just like any OS, aelf has a kernel and a shell. In fact, aelf’s kernel is not something like a Linux kernel, it is just an analogy. There is a special concept in aelf’s kernel called the minimum viable blockchain system, which defines the most fundamental aspect of a blockchain. If a developer wants to create a new blockchain system or a new blockchain project, he does’t have to start from scratch, instead, he can directly extend and customize using the aelf blockchain open-source code. The technologies described above are all included in the minimum viable blockchain system. With these, anyone can customize:

- Block property: block data structure, block packaging speed, transaction data structure, etc.

- Consensus type: AEDPoS is used by default, but you can also use incentive consensus, like PoW and PoS. And you can also use the consensus of traditional distributed systems, like PoS and Practical Byzantine Fault Tolerance, or PBFT. In fact, the f evil nodes of 3f+1 nodes are the upper limit for any distributed system to reach a consensus, which is called the Byzantine Fault Tolerance, or BFT. In order to do this, there is a specific algorithm, but in 1999, a much more efficient algorithm to reach this consensus came along, that is the PBFT. In scenarios like private blockchain or consortium blockchain where there is no need for a incentive model, PBFT will be a good option.

- Smart contract collection: In aelf, there are many predefined smart contracts that can be used directly by other contracts, such as token contract, cross-chain contract (also called CCTP, or cross chain transfer protocol), consensus contract, organization voting contracts, etc. Of course, you can also create your own contract with a brand new implementation logic.

- Others.

Summary

So this is our breakdown of the aelf blockchain whitepaper. In previous articles, we first introduced two basic concepts which are often misinterpreted by other articles. After helping you get these two concepts straight, we then introduced aelf’s vast arsenal of powerful technology. If these articles helped you understand the aelf blockchain better, then I have reached my goal. But I must advise you to read the whitepaper for a more detailed explanation. With all this knowledge at your disposal, I believe you will be much more comfortable developing DApps on aelf.

[aelf blockchain]

📢AMA Announcement 🔥

 ❗️Dear community members, aelf will hold a Live AMA with aelf COO @czhuling on Telegram https://t.me/aelfblockchain!  Come and talk about DeFi with @czhuling!

Time: August 28, 5pm - 6pm (GMT +

Research the aelf project and prepare some good questions!
(Users who do not follow the rules below will not be able to share out the prize pool.)
1️⃣Twitter Session (15 Questions)
2️⃣Live Session (10 Questions)

Rules :
1️⃣Join the aelf community on Telegram https://t.me/aelfblockchain
2️⃣Follow us on Twitter @aelfblockchain https://twitter.com/aelfblockchain
3️⃣Like, Retweet & Tag 3 Friends and Comment With Your Questions  https://twitter.com/aelfblockchain/status/1298199934781411328

[aelf blockchain]

What is AMM (automated market maker)?

AMM, short for automated market maker, is an innovative trading model derived from Defi projects. Unlike the traditional order book transaction model, AMM decentralized market makers and automated trading process.

Everyone can put token into the liquidity pool, become a small market maker, and then enjoy the profits from trading pair service fees. Funds in the liquidity pool are controlled by decentralized open source contracts, and AMM transaction data are all on the chain.

[aelf blockchain]

aelf is Testing AESwap Internally



In 2020, Ethereum’s DeFi ecosystem saw exponential growth and DEX (decentralized exchange) boomed. Against this backdrop, aelf officially launched AESwap, a decentralized trading platform.
AESwap is a smart contract protocol based on the aelf network, which adopts the constant product market maker (CPMM) model. No need for pre-mining and financing is a distinct feature of the project. Once it goes live, the product will offer free access to users around the world and help all people to participate in the open financial market. The follow-up funds will be managed by the aelf DAO Management Committee to ensure the project runs securely and efficiently.

AESwap is the first DeFi project based on the aelf network, with complete DeFi supporting infrastructure, including cross-chain assets, interoperability solutions, stablecoin, etc. AWSwap aims to be the world’s leading automatic trading platform and offer a more efficient, convenient and secure DeFi product than Uniswap. The mobile version of AESwap integrates the templates of aelf account management, which makes it easier to learn and get started and is more user-friendly.

The mobile version of AESwap (Closed Beta) has completed phase 1 of feature development and will be available for public testing soon. The desktop version is still under development. AESwap Phase 1 mainly provides two major features, one is that market makers make money by adding liquidity to trading pairs and they can also create trading pairs. The other is that token holders can exchange one token for another token by paying a 0.3% transaction fee, which will be used as the market makers’ commission. The protocol does not charge any commission.

AESwap Highlights:

Performance: Low transaction fee, fast trading without delay
Security: Self-developed based on the aelf network, High Security
User-friendly: Ease of use, available on both mobile and desktop
Profit: Achieve asset interoperability with adequate liquidity

At present, compared with many DEX, the biggest advantage of AESwap is “Transaction Speed”. Although Ethereum currently has the most popular DeFi ecosystem, it cannot handle high transaction throughput and fully support the expanding DeFi ecosystem until the Ethereum network adds layer 2 or upgrades to 2.0.
The underlying public chain of AESwap is the aelf network, so there will be no network congestion. Aelf adopts the main-side chain structure, which uses one chain for one specific scenario and thus can truly realize resource isolation, ensure transaction efficiency and avoid high gas fees. At the same time, under the premise of the main chain security, the side-chain and the main-chain can share security. Moreover, AESwap is independently developed by the aelf team, and its security is guaranteed. Recently, YAM’s collapse due to the existence of loopholes in the smart contract has caused a great stir, so contract security is also very important.

Aeswap liquidity pool uses a constant product market maker model to execute transactions, abandons the concept of limit order book, and can automatically adjust the exchange rate according to the available liquidity. Therefore, it can achieve fast trading and ensure the persistence of capital flow. Constant product can be regarded as an inverse proportional function x * y = K. No matter how x and y change, K is always a constant value. In AESwap transactions, the product of the tokens’ number in the liquidity pool is constant before and after a transaction, that is, the product before the purchase = the product after the purchase.

Because Ethereum platform has issued the largest number of cryptocurrency assets, the exchange’s value would be significantly reduced if it could not access these assets and the original ETH. aelf also takes this into account, so it will provide a set of interoperability solutions with other public chains’ tokens. AESwap will support the migration of Ethereum token. By reducing the cost of user migration, users can easily migrate to the aelf platform by using Ethereum token instead of purchasing or exchanging other aelf tokens to ensure sufficient liquidity and reduce the risk.

As the infrastructure of aelf ecosystem, AESwap is the basic tool to realize token trading. In the future, aelf will lay out other derivatives applications based on AESwap, form a stable financial system, and promote the prosperity of other APP and related token. In addition, AESwap can also be connected with other APP on aelf DeFi ecosystem to promote each other. In the future, the aelf will launch the AESwap public testing. Please stay tuned!