BPF-based ink! smart contracts
This Request for Proposals is closed, meaning we are not looking for any more proposals on this topic at the moment.
Project Description 📄
Substrate's FRAME contracts pallet allows for WASM-based smartcontracts on Substrate, written in ink!, a Rust-based eDSL. WASM comes with a lot of advantages, such as high flexibility, tooling, a good compiler (wasmtime) and a lot of high level constructs. However, these features comes with a cost: complexity of the API and compiler implementation as well as impacts on performance. For example, Substrate does not embed the API for WASM VM due to its complexity.
eBPF as a WASM alternative
An alternative to WASM here would be eBPF, a technology for running sandboxed programs in an operating system kernel. It originated from BSD's BPF that comes with a permissive open-source license and represents a Linux-compatible implementation thereof, that instead uses a viral open-source license.
However, vanilla eBPF has some serious constraints:
- LLD can't link BPF code (LLD is the linker contained in LLVM which is the compiler framework that Rust's compiler
rustupdoesn't include any
stdlibrary for LLVM (and rustc)'s a upstream BPF targets (
- Loops are not fully supported.
While 1) and 2) technically can be worked around by using bpf-linker, 3) needs further research. Also, 2) will only work if loops are bound statically due to constraints within the LLVM backend. A viable solution here would be to replace this constraint by using gas metering.
Despite the constraints, eBPF-based ink! smart contracts would be expected to have the following advantages over its WASM-based counterpart:
- Simplicity: Due to its register-based instruction set it would be easier to compile
- Efficiency and performance
Alex and pepyakin have attempted to use eBPF instead of WASM for ink! smart contracts when attending a hackathon. While they didn't manage to compile to BPF, their resources might be useful as a starting point:
The goal of this RFP is to allow for eBPF-based smart contracts. To summarize, the rough process should be:
- Compile Rust-based ink! smart contracts using rBPF, returning an eBPF ELF file
- Store the ELF file on-chain
- Execute the ELF file within the eBPF VM that will convert it to machine code