Greetings to all readers of the blog! From today’s article you will learn more about the FUPE basics. Have a productive reading!
What is FUPE?
FUPE = FU (Functional Unit) + PE (Processing Ellement)
The main reason for entering FUPE is the need to limit smart contracts on “necessary and sufficient” functionality to comply with various tade-offs – compromises of the integrity and efficiency of the entire system.
FUPE will be closed to a specialized functional programming language GOL.
Base blocks for FUPE will be selected very carefully.
The usual model of contracts based on Ethereum EVM requires ideological expansion in the transition to more complex dApps (outside the concept of Solidity).
For example, to run Android applications, Dalvik VM is used, which is a register machine. While EVM is a stack machine (for simplicity and security, as intended). Therefore, if we want to do something like a blockchain phone [Sirin Labs], then we have to go to the register machine. But it would be better if the new VM will support both the stack part (EVM) and the register part (Dalvik) by clustering the functional.
We have created such VM – GONT VM. GONT VM is a new generation virtual machine! It is a basic container for all FUPE functionality.
At the same time, the GONT VM must be (and it is) the “cycle equivalent” for rtl (Verilog, VHDL) code – for further implementation in HW.
Hybrid contract languages:
There are many languages for writing contracts (besides Solidity), and some are making progress. For example, the NEO project supports contracts for .NET and made partnership with Microsoft. It has a very positive effect on the capitalization of the project.
AlGas and PIPE of any length:
During the execution of a transaction, a transaction channel (TREVAL) is created, which implements a functional Pipeline of arbitrary length.
Pre-Exec and routing:
The concept of Pre-Exec provides a way to implement the dynamic creation of a transaction execution channel.
FUPE classification:
- Simple: Registers, ALU, FPU
- Complex: VES
Data types:
GONT extends data stream processing. The gVM cores have an interface for working with large data streams, such as video.
For example, for video encoding gas, this option will be relevant.
GVM core requirements for implementing the AlGas approach:
- Automatic assembly from meta information (about instructions and registers).
- Availability of both cycle accurate and fast model (why QEMU is not suitable – the lack of cycle accurate).
- The presence of an interface for verification relative to the rtl code (for future implementation in HW).
Thank you for attention! See you in the next articles.
GONT