Alitas New Milestone Reached

Alitas
6 min readApr 29, 2022

Alitas New Milestone Reached

As of April 2022, the development of the Alitas mainnet is well underway and has made some significant initial progress in terms of security, scalability, the efficiency of transactions, and the development of the GameFi SDK. We are confident that Alitas will shine in the web3 infrastructure sector as it continues to improve functionality, performance, and compatibility.

Security of the Mainnet

For this update, we have adopted the LMD-GHOST (Latest Message Driven Greediest Heaviest Observed SubTree) protocol as the fork selection rule for our mainnet consensus.

The figure above is an example of the LMD-GHOST fork selection rule, where the number on the block represents the weight (Each time a verifier approves one block, the weight is increased by one). Since each block is generated through the verifier proposal, all the witness messages have at least one weight each. In this algorithm, the fork with the highest weight is found recursively among all the forks that have received votes, and this fork is selected. So in the diagram above, the verifier will conclude that the chain of blue blocks will be the longest legal chain and that the block with a weight of 3 will be the latest blockhead of the current chain. The pseudo-code for the specific algorithm is as follows.

1: procedure LMD-GHOST(F)

2: B ← Bgenesis

3: Let M = [M1 . . . MN ] be the most-recent attestations of the N validators

4: while B has children do

5: B← argmax w(G,Bʹ, M)

Bʹ child of B

6: (ties are broken by the hash of the block header)

7: return B

Scalability and Efficiency of the Main Network

In blockchain systems, there is a well-known triangle of impossibility: it is impossible to achieve decentralization, consistency, and scalability in a distributed environment at the same time. So in many design processes, we need to weigh these three conditions.

The goal is to slice the existing all-in-one chain into smaller, faster chains so that the system can reach dynamic scalability bound. So how can we achieve this scalability? We divide the block state, account state, transaction information, etc., from all the blocks on a chain into each slice of the chain according to some balanced strategy. Each chain slice is independent, with its transaction book and state information.

So what exactly is a fragmented chain?

In most of the current blockchain systems, each node needs to process and store all the transaction information. That makes the performance bottleneck of blockchain depend on the single computer performance bottleneck and cannot fully exploit the advantages of horizontal scalings, such as the number of transactions per second in the Bitcoin system is 7, while the number of transactions per second in the Ethernet system is about 15. This low throughput makes it difficult for blockchain to be further developed and applied in society.

The design of the sharded chain is to take full advantage of the horizontal computer scaling so that the overall throughput of the blockchain system can be increased to a level comparable to the current mainstream centralized payment system. For example, we can route address transactions starting with 0x1 to the slice chain “a” and address transactions starting with 0x2 to the slice chain “b”. Or we can create different slice chains based on various assets, and process transactions for those assets on the corresponding slice chains. All of this relies on multiple small and fast chains.

To avoid unnecessary complexity, the current team prefers to build all the sharded chains at once when the main network is launched, and the current threshold of sharded chains is 32. At the same time, to make the distribution of transactions on each sharded chain more even, the transaction fees on the lower frequency sharded chains will be lower. At the same time, through the form of multi-partitioning, the theoretical TPS value of a single partition in the current test is 3000. So with 32 partitions, the total theoretical TPS value will reach 96000, which will provide a more convenient choice for those more low-frequency game operations to be chained.

Wasm Virtual Machine Replacement EVM

To be able to execute smart contracts on each slice chain and communicate with other slice chains, we use the new Wasm virtual machine. The main reason for this is that the EVM is inefficient because it does not support integers smaller than 256 bits, and any 256-bit operation must be performed by the CPU via 64-bit or 32-bit operations, while the ability to scale the EVM and the tools required to do so are rare.

For this reason, we will introduce the Wasm (WebAssembly) virtual machine now, a web browser standard developed by the W3C working group. It aims to allow code to deploy in any browser with the same results. Wasm is an extremely high performance, built to be as close to native machine code as possible while remaining platform-independent, facilitating the transfer of small binaries over the Internet to devices with slow connections. Once switched to the Wasm VM, developers can develop smart contracts in any familiar programming language, such as Golang, Java, Python, etc.

WebAssembly has the following advantages:

  • Memory-safe, sandboxed, and platform-independent.
  • Supports 64-bit and 32-bit integer operations, which correspond to CPU instructions.
  • Easy determinism by removing floating-point operations, which is required for consensus algorithms.
  • Supported by the LLVM compiler infrastructure project, which means Wasm will benefit from over a decade of LLVM compiler optimizations.
  • Once the Wasm virtual machine is perfectly embedded in the mainnet, it will give developers a wider and freer choice, and it will be a wonderful era for all kinds of blockchain applications to bloom.

Development of GameFi SDK

The overall framework for the GameFi SDK has been designed and half of the functionality has been implemented, and the security aspects of the SDK are being further refined. We are using a Link prophecy machine for off-chain data collection and calibration, which will be very friendly for games about the weather, news, etc. At the same time, the SDK is planning to support other major networks such as Bsc, Fantom, Avalanche, Solana, Terra, and Layer2 networks such as Arbitum, Optimism, Zksync, etc. So that game developers can focus more on the content and details of the game. And don’t need to struggle to choose which master network and which SDK to use. You can support multiple master chains with one click.

Future Versions

This major update to Alitas is an important step forward for the team. This update further improves the security, scalability, and efficiency of the mainnet. And the security level of the GameFi SDK has been greatly improved. We have also revised the main framework for subsequent versions of the mainnet to improve its compatibility, security, and code quality. This one is a vital step for the successful launch of the main-network.

In addition, we’ve made significant improvements to the development process. It may not be as shiny and exciting for the community, but it does mean that the team now has a fully automated release process with detailed changelogs. In addition, our automated tests have become faster, more reliable, and cover a wide range of important and serial test cases.

Based on the team’s planning for the future, we have started to lay out the fragmented chain, cross-chain bridge, DAO organization, NFT brand assets and more. We have a lot to look forward to and a lot of difficulties to solve. We hope to provide more frequent additional updates with fewer major changes, thus making Alitas more developer-friendly and a rising star in the next generation of public chains.

--

--

Alitas

Alitas is the underlying infrastructure of a new generation of value networks Contract address on #BSC: 0x5Ca09af27b8a4F1D636380909087536BC7e2D94D