Precompiled Contracts in Neon: A Case Study of ERC-20 Wrapper

The Neon EVM core program is based on the Sputnik VM, an implementation of the Ethereum Virtual Machine written in Rust. Sputnik VM includes a feature to embed third-party Rust code that can be invoked from Ethereum contracts. This embedded code is known as a “precompiled contract”.

The third-party code of precompiled contracts may be compiled and linked with Sputnik VM code in one common binary.

Case Study: Neon’s ERC-20 Wrapper

The Neon Labs team has already developed and embedded a number of precompiled contracts into the Neon EVM core program. One of these precompiled contracts in the Neon EVM is the ERC-20 Wrapper. The following is a deep dive into the ERC-20 Wrapper, what it’s intended for, and how it works.

The ERC-20 Wrapper consists of 2 parts:

• The Solidity contract
• Precompiled Rust code embedded into the Neon EVM

ERC-20 Wrapper Solidity Contract

The ERC-20 Wrapper’s Solidity contract code includes the IERC-20 Interface with its standard functions and events, and the Neon code extends this Interface with its own functions, implementing only the constructor and the fallback function.

Fallback functions are triggered when a function identifier does not match any of the available functions in a smart contract. Since the contract has no other functions, any call of a ERC-20 wrapper method falls/defaults back into this function.

In the fallback function, the call data is prepared and the Solidity method “delegatecall” is called at the hardcoded address of the precompiled contract. Here, the “delegatecall” method invokes a precompiled contract function with the given function identifier and parameters.

The contract uses the constant address “NeonERC20”. This is the hardcoded address of the precompiled contract, from which it can be called.

Precompiled Rust Code

All Neon EVM precompiled contracts are currently located in one module. This module contains the constant addresses of all of these contracts, including “SYSTEM_ACCOUNT_ERC20_WRAPPER”, which is the address of the ERC-20 Wrapper.

When a precompiled contract function is called, the function call falls into the “call_precompile” function. If the given contract address matches the SYSTEM_ACCOUNT_ERC20_WRAPPER constant, the “erc20_wrapper” function is called. “erc20_wrapper” is the function that is used for all the invocations of the ERC-20 Wrapper interface.

Inside the “erc20_wrapper” function, the parameters are parsed. In Ethereum, function identifiers are 4 bytes in length and are calculated by keccak256 from the function signature, which includes the function’s name and parameters.

All the ERC-20 interface methods are described in this function, with their identifiers hardcoded as constants. After the method that was called is selected via the “match” operator, the code of this method is executed and the result is returned.

Conclusion

The Neon EVM’s ERC-20 Wrapper is an excellent example of the kind of precompiled contract that is commonly used in the Neon EVM. It includes both a Solidity contract and precompiled code in Rust that is embedded in that contract.

As we’ve seen, this type of software architecture allows Neon to effectively integrate third-party software and functionality into its on-chain operation. Stay tuned for future case studies on Neon’s precompiled contracts! More to come.