This week Elastos released a Financial Report, the core development team released a thorough technical update, and we get to take a deeper look at Neo Smart Contracts.

Let’s recap.

Technical Dynamics

Trinity:
– Increased the task of compiling Android targets on the Mac platform in Continuous Integration(CI) builds;
– Fixed a bug in the Camera plugin the camera data couldn’t be obtained and the local image path would be incorrect;
– Fixed a bug in Media plugin; Media has been able to play normally, fixing the problem of writing path of resource file path;
– Carrier plugin now uses the latest released Carrier SDK inside Trinity;
– Fixed a bug in parsing manifest;
– Trinity and Carrier are now consistent with the Android SDK requirements; the toolchain script now changes defaultMiniSdk from 19 to 21;

Hive:
– Continuous improvement of IPFS node/cluster Restful Http APIs test case set code;
– Fixed key/Value synchronization problem between internal nodes of IPFS node/cluster service;
– Completed IPFS Native SDK code;
– Completed IPFS Node/Cluster interface documentation;
– Continuous improvement of the IPFS Android SDK and interface testing;
– Porting standard IPFS-based texture applications to Hive Cluster-based platforms;
– Synchronization stability and performance improvements;

Carrier:
– Improved the carrier offline messaging function (depends on the Hive project’s Key-Value node synchronization problem);
– Optimized and simplified the startup process of tests and apps in the Carrier Native SDK;
– Adjusted the engineering structure of the Carrier Android SDK and integrated a simple app with module import;
– Synchronously updated the Carrier Remoter demo application repository;
– Changed the main warehouse license related to the carrier to GPLv3 (mentioned last week), and then solved the license pollution problem of the dependent library;
– Fixed some accumulated low priority bugs, as well as made some optimizations;

DPoS:
– Ela-cli tool is updated to adjust to the DPoS consensus;
– Mainline upgrade support voting and registration and logout of super nodes;
– Cloud environment DPoS routine process testing and bug fixes;
– DPoS branch has completed CI integration, enabling all unit tests and white box tests to pass;
– Arbitrators directly depend on the memory model (state), no longer need be logged into the database;
– Filtered the P2P network address without forwarding the wallet address;

SPV wallet:
– Android platform spv wallet voting function test and bug fixes

Ethereum side chain:
– Determined the solution for the first call to the transfer contract without the cost of gas;
– Fixed details of the charge;

C++ SPV:
– Repairing the feedback of overseas communities where the repo was too large to package into npm packages, and some error logs were causing confusion;
– KYC function bug fix;

Blockchain Browser:
– Fixed main chain blockchain browser unknown transaction issues;
– Main chain blockchain browser to support voting type transactions;
– Main chain blockchain browser upgrade main network official service test deployment;

NEO side chain:
– Replaced the common and crypto packages in the reference utlity with references in the main chain;

Miscellaneous:
– Elastos.ELA.Monitor design – this program is mainly used to monitor node status and DPOS consensus;
– Completed the main node log analysis program encoding work;

Cyber Republic

Check out the latest Cyber Republic Weekly Report here: https://blog.cyberrepublic.org/2019/02/25/weekly-report-february-25-2019/

Participate in the Cyber Republic forums at https://forum.cyberrepublic.org. All logins are linked to your Cyber Republic login, this includes the forums and, in the future, your Elastos DIDs.

Community News

– In accordance with our bi-annual release schedule and our commitment to transparency, The Elastos Foundation is pleased to share our Financial Report covering July 2018 to December 2018.

– Rong Chen discusses his journey to decentralization with Crypto Briefing: https://cryptobriefing.com/rong-chen-elastos-decentralization/

Events

Hong Kong: March 13-14

Rong Chen will be at Token2049  in Hong Kong where he will be on a panel called, “The Decentralized Future: Interoperability and Scalability,” with representatives from Aion, Wanchain, Celer Network, and ICON. For more information: https://www.token2049.com/

Xiaobin Zhang spoke about NeoVM Elastos sidechain on Elastos Talk

Xiaobin Zhang is a senior software engineer and blockchain engineer. He is also a student in DACA blockchain open class. In 2018, he joined the Elastos team and participated in the development of the Elastos wallet SDK. Later, he successfully ported Neo’s smart contract virtual machine (NeoVM) onto Elastos sidechain. He currently is on the development team of the Elastos Ethereum sidechain.

NEO VM and Smart Contract

Smart contracts are the ideas put forward by Nick Sabo in the 1990s. A smart contract is a set of commitments defined in digital form, including agreements on which contract participants can execute these commitments.

The NEO VM is a stack-based virtual machine that executes NEO smart contract code. NEO smart contract developers can use almost any language they are good at to develop NEO smart contracts. NEO provides compilers and plug-ins for these languages, compiling them into instruction sets supported by NEO virtual machines.

My name is Xiaobin Zhang. I will share with you today my understanding of NEO VM in the migration of virtual machines. I will not share too much though, just the basic information. I hope that everyone will have some understanding for smart contract which are the code running on the blockchain.

As we all know, smart contracts are segments of code that runs on a blockchain system. The NEO VM is the virtual machine that executes this code. How does the NEO VM recognize this code and run it? If you understand the stack which is a kind of data structure, it will be easier to understand what we are going to share today because the NEO VM is based on the stack. Besides, the Ethereum virtual machine EVM is also based on the stack.

Here, I summarize several features of the NEO VM as follows:

  • NEOVM: a virtual machine that generates AVM code after compilation
  • Stack-based. It uses 32 bytes OpCode
  • Turing completeness. There is no endless loop within the contract, which is guaranteed by gas consumption.
  • Access blockchain data through interoperable layers.
  • Gas consumption is calculated by instructions. No gas refund.

For the NEO smart contract, one of the primary features is that it can be programmed using C#, Java. NEO provides compilers and plug-ins for these languages, compiling them into instruction sets supported by NEO virtual machines.

The above figure illustrates the virtual machine structure. The picture is officially provided by NEO and is the most important picture to understand the NEO virtual machine.

First of all, the top layer is the compiler, the code compilation layer where the code is that we usually write. For example, Java will generate AVM through the compiler we use, such as Visual Studio. This AVM is the code to be executed inside the virtual machine, which is OpCode.

The middle part is the virtual machine which runs on each of our nodes. As you can see, its structure is divided into execution engine, stack, and interoperability layer. The execution engine is the executor responsible for putting our OpCode and instructions into the stack. As can be seen from the above figure, this includes the flow control, the stack structure, the array operation, the logic processing algorithm and other functions to be implemented in the virtual machine. These functions represent some data structures and algorithms that can be used when coding the contract.

The interoperability layer is used to access data of the blockchain system, such as Block Transaction. The interoperability layer can also be used to access external data, but it has not yet been implemented. The bottom layer is the blockchain system Distributed Ledger. These three layers constitute the execution structure of the entire smart contract.

Let’s take a look at how the AVM compiler generates OPCode.

The above is a flow chart I made. As you can see from this figure, the programming editor Visual Studio uses C# to translate the intermediate language of MSIL directly into OpCode via Mono.

For a deeper understanding, the above flow chart may not be enough. I will show you the code of the above flow chart and the actual data.

As you can see from this figure, the first part is C# code and then it will generate MSIL through the compiler. As you can see, MSIL is actually a stack-based operation instruction code that is Microsoft intermediate language, a pseudo-assembly language between high-level languages and Intel-based assembly language.

The intermediate language of MSIL can be directly translated into OpCode for the NEO VM through the C# compiler. That is, Microsoft stack OpCode is converted into the OpCode of the NEO VM. It is the middle hexadecimal value. This value actually corresponds to an OpCode operation instruction which again corresponds to an operation method of the stack.

Next is the core part. Now take a look at a simple addition contract with C# code and understand how it works in the stack.

The above figure is an addition contract that is coded with C#

Then Microsoft’s compiler Visual Studio can translate the C# code into the MSIL (Microsoft intermediate language).

Then MSIL is translated into the corresponding hexadecimal value of OpCode through Mono.Ceil

These hexadecimal values then correspond to operation instructions of the virtual machines as shown in the figure above.

The following shows the process how these instructions run in the stack.

The above figures are actually a stacking process which is used for an addition of 3 and 4.

Now everyone should understand the process through the above figure. This diagram is the stacking process for the addition in the simplified version. In fact, NEO’s compiler still has a lot of room for improvement.

Now let’s talk about how loops are implemented inside the stack.

In fact, the implementation of the loop inside the stack means implementation of a jump instruction JMP. That is, if the current instruction is a JMP, then find the stack address to be jumped basing on the top stack data, and then continues from the current stack position until the jump is met again, thus executing a part of the code inside the stack. This will loop through some segments of the code inside the stack.

The above figure lists the controls of data structures and algorithms that are implemented inside the virtual machine, including operations on the stack, such as popping, stacking, and exchanging processes. The jump and even the IF as just mentioned are also implemented by JMP. Besides, arithmetic instructions, encrypted instructions, and other stream-based operations are implemented in the same way.

You may also be interested in how to consume GAS inside the contract. Let’s take a look at this part of the code.

Executing the contract in the NEO VM means the execution of the instruction. Each instruction consumes GAS. As it can be seen from the above figure, the system consumes 1 GAS per instruction by default, and it will consume differently for other instructions. There will always be a day when GAS is exhausted, thus it guarantees that there will be no endless loops within the contract.

 Technical summary

  • A smart contract is a segment of code that runs on a blockchain. This code is Turing complete, theoretically can achieve the logic you want.
  • Required technical modules: compiler, executor (virtual machine), blockchain. Blockchain is a prerequisite for smart contracts.
  • NeoVM is a virtual machine that executes smart contracts. It implements a stack-based opcode set and the corresponding executor

Useful links:

A Developer Beginner’s Guide

Developer Portal in Cyber Republic

Developer Documentation on Github

Elastos Smartweb Alpha

Elastos Community

Elastos Community Global

LEAVE A REPLY

Please enter your comment!
Please enter your name here