NutBerry - Offroading Ethereum Transactions
A NutBerry a day keeps the sunshine your way.
The goal of this project is a permissionless layer-2 solution with support for stateful smart contracts. The design is similiar to what we generally call rollups but it intentionally has the same transaction encoding and signing scheme as Ethereum transactions to be one-to-one compatible with the existing ecosystem.
The most anticipated feature is the possibility for on-chain EVM verification, that makes it possible to run smart contracts on a permissionless / trustless layer 2 solution. Though, the runtime has some restrictions like not be able to call other contracts. That is; a state-minimized EVM or LEVM - Lean Ethereum Virtual Machine.
Data availability is fully achieved on the root-chain and the contract is able verify and replay all transactions either through directly finalizing a Block of transactions on-chain or via an interactive computation verification game to offload the computation and to enforce correctness on-chain for any given block.
1st Milestone Support the ERC20 token standard.
2nd Milestone Support the ERC721 standard.
3rd Milestone Support arbitray stateless smart contracts.
4th Milestone Stateful smart contracts, aka smart contracts with support for storage.
How to get started
To install the dependencies:
This project uses
geth to run the integration tests.
Make sure that you have at least
geth v1.8.21 available in your environment.
You can run the tests with
scripts/deploy.js - is a little deployment helper script.
You can run it like this:
GAS_GWEI=3 RPC_URL=http://localhost:8222 PRIV_KEY=0x2bdd21761a483f71054e14f5b827213567971c676928d9a1808cbfa4b7501200 ./scripts/deploy.js
This script also supports passing
MNEMONIC instead of a private key.
In addition, you can leave both
RPC_URL allows signing.
The NutBerry client-node
js/bin.js needs the following environment variables:
BRIDGE_ADDRESS- 0x... The contract address of the Bridge on the root-chain.
PRIV_KEY- 0x... The private key for a root-chain account. That account should have some ether to be useful.
PORT- The port to listen on for the RPC interface.
ROOT_RPC_URL- The URL of the root-chain rpc provider.
HOST- The address to listen on for the RPC interface. Defaults to
DEBUG_MODE- Used for testing, if
=1enables additional RPC methods and other things meant for development.
BAD_NODE_MODE- Used for testing, if
=1it will compute wrong solutions to trigger the verification game.
Additionaly, taking a look at
tests/Bridge.js will give you an idea how things fit together.
Join the Gitter chat to ask questions, harvest NutBerries and to hang out.