Skip to main content

BPF-based ink! smart contracts

danger

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.

eBPF constraints​

However, vanilla eBPF has some serious constraints:

  1. LLD can't link BPF code (LLD is the linker contained in LLVM which is the compiler framework that Rust's compiler rustc relies on).
  2. rustup doesn't include any core nor std library for LLVM (and rustc)'s a upstream BPF targets (bpfeb-unknown-none and bpfel-unknown-none)
  3. 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.

eBPF advantages​

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

Previous work​

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:

Conclusion​

The goal of this RFP is to allow for eBPF-based smart contracts. To summarize, the rough process should be:

  1. Compile Rust-based ink! smart contracts using rBPF, returning an eBPF ELF file
  2. Store the ELF file on-chain
  3. Execute the ELF file within the eBPF VM that will convert it to machine code