This patch reduces stack space used with EVM in ENABLE_EVMC=1 mode, from 13 MB
worst case to 550 kB, a 24x reduction.
This completes fixing the "stack problem" and closes #575 (`EVM: Different
segmentation faults when running the test suite with EVMC`).
It also closes #256 (`recursive EVM call trigger unrecoverable stack overflow`).
After this patch, it is possible to re-enable the CI targets which had to be
disabled due to #575.
This change is also a required precursor for switching over to "nearly EVMC" as
the clean and focused Nimbus-internal API between EVM and sync/database
processes, and is also key to the use of Chronos `async` in those processes
when calling the EVM.
(The motivation is the internal interface has to be substantially changed
_anyway_ for the parallel sync and database processes, and EVMC turns out to be
well-designed and well-suited for this. It provides good separation between
modules, and suits our needs better than our other current interface. Might as
well use a good one designed by someone else. EVMC is 98% done in Nimbus
thanks to great work done before by @jangko, and we can use Nimbus-specific
extensions where we need flexibility, including for performance. Being aligned
with the ecosystem is a useful bonus feature.)
All tests below were run on Ubuntu 20.04 LTS server, x86-64. This matches one
of the targets that has been disabled for a while in CI in EVMC mode due to
stack overflow crashing the tests, so it's a good choice.
Measurements before
===================
Testing commit `e76e0144 2021-04-22 11:29:42 +0700 add submodules: graphql and
toml-serialization`.
$ rm -f build/all_tests && make ENABLE_EVMC=1 test
$ ulimit -S -s 16384 # Requires larger stack than default to avoid crash.
$ ./build/all_tests 9 | tee tlog
[Suite] persist block json tests
...
Stack range 38416 depthHigh 3
...
Stack range 13074720 depthHigh 1024
[OK] tests/fixtures/PersistBlockTests/block1431916.json
These tests use 13.07 MB of stack to run, and so crash with the default stack
limit on Ubuntu Server 20.04 (8MB). Exactly 12768 bytes per EVM call stack
frame.
$ rm -f build/all_tests && make ENABLE_EVMC=1 test
$ ulimit -S -s 16384 # Requires larger stack than default.
$ ./build/all_tests 7 | tee tlog
[Suite] new generalstate json tests
...
Stack range 14384 depthHigh 2
...
Stack range 3495456 depthHigh 457
[OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest639.json
...
Stack range 3709600 depthHigh 485
[OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest458.json
...
Stack range 7831600 depthHigh 1024
[OK] tests/fixtures/eth_tests/GeneralStateTests/stCreate2/Create2OnDepth1024.json
These tests use 7.83MB of stack to run. About 7648 bytes per EVM call stack
frame. It _only just_ avoids crashing with the default Ubuntu Server stack
limit of 8 MB. However, it still crashes on Windows x86-64, which is why the
Windows CI EVMC target is currently disabled.
On Linux where this passes, this is so borderline that it affects work and
testing of the complex storage code, because that's called from the EVM.
Also, this greatly exceeds the default thread stack size.
Measurements after
==================
$ rm -f build/all_tests && make ENABLE_EVMC=1 test
$ ulimit -S -s 600 # Because we can! 600k stack.
$ ./build/all_tests 9 | tee tlog
[Suite] persist block json tests
...
Stack range 1936 depthHigh 3
...
Stack range 556272 depthHigh 1022
Stack range 556512 depthHigh 1023
Stack range 556816 depthHigh 1023
Stack range 557056 depthHigh 1024
Stack range 557360 depthHigh 1024
[OK] tests/fixtures/PersistBlockTests/block1431916.json
$ rm -f build/all_tests && make ENABLE_EVMC=1 test
$ ulimit -S -s 600 # Because we can! 600k stack.
$ ./build/all_tests 7 | tee tlog
[Suite] new generalstate json tests
...
Stack range 1392 depthHigh 2
...
Stack range 248912 depthHigh 457
[OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest639.json
...
Stack range 264144 depthHigh 485
[OK] tests/fixtures/eth_tests/GeneralStateTests/stRandom2/randomStatetest458.json
...
Stack range 557360 depthHigh 1024
[OK] tests/fixtures/eth_tests/GeneralStateTests/stStaticCall/static_CallRecursiveBombPreCall.json
For both tests, a satisfying *544 bytes* per EVM call stack frame, and EVM
takes less than 600 kB total. With other overheads, both tests run in 600 kB
stack total at maximum EVM depth.
We must add some headroom on this for database activity called from the EVM,
and different compile targets. But it means the EVM itself is no longer a
stack burden.
This is much smaller than the default thread stack size on Linux (2MB), with
plenty of margin. (Just fyi, it isn't smaller than a _small_ thread stack on
Linux from a long time ago (128kB), and some small embedded C targets.)
This size is well suited to running EVMs in threads.
Further reduction
=================
This patch solves the stack problem. Windows and Linux 64-bit EVMC CI targets
can be re-enabled, and there is no longer a problem with stack usage.
We can reduce further to ~340 bytes per frame and 350 kB total, while still
complying with EVMC. But as this involves changing how errors are handled to
comply fully with EVMC, and removing `dispose` calls, it's not worth doing now
while there are other EVMC changes in progress that will have the same effect.
A Nimbus-specific extension will allow us to avoid recursion with EVMC anyway,
bringing bytes per frame to zero. We need the extension anyway, to support
Chronos `async` which parallel transaction processing is built around.
Interop with non-Nimbus over EVMC won't let us avoid recursion, but then we
can't control the stack frame size either. To prevent stack overflow in
interop I anticipate using (this method in Aleth)
[6e96ce34e3/libethereum/ExtVM.cpp (L61)
].
Smoke test other versions of GCC and Clang/LLVM
===============================================
As all builds including Windows use GCC or Apple's Clang/LLVM, this is just to
verify we're in the right ballpark on all targets. I've only checked `x86_64`
though, not 32-bit, and not ARM.
It's interesting to see GCC 10 uses less stack. This is because it optimises
`struct` returns better, sometimes skipping an intermediate copy. Here it
benefits the EVMC API, but I found GCC 10 also improves the larger stack usage
of the rest of `nimbus-eth1` as well.
Apple clang 12.0.0 (clang-1200.0.26.2) on MacOS 10.15:
- 544 bytes per EVM call stack frame
GCC 10.3.0 (Ubuntu 10.3.0-1ubuntu1) on Ubuntu 21.04:
- 464 bytes per EVM call stack frame
GCC 10.2.0 (Ubuntu 10.2.0-5ubuntu1~20.04) on Ubuntu 20.04 LTS:
- 464 bytes per EVM call stack frame
GCC 11.0.1 20210417 (experimental; Ubuntu 11-20210417-1ubuntu1) on Ubuntu 21.04:
- 8 bytes per EVM call stack frame
GCC 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) on Ubuntu 20.04 LTS:
- 544 bytes per EVM call stack frame
GCC 8.4.0 (Ubuntu 8.4.0-3ubuntu2) on Ubuntu 20.04 LTS:
- 544 bytes per EVM call stack frame
GCC 7.5.0 (Ubuntu 7.5.0-6ubuntu2) on Ubuntu 20.04 LTS:
- 544 bytes per EVM call stack frame
GCC 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2) on Ubuntu 19.10:
- 528 bytes per EVM call stack frame
Signed-off-by: Jamie Lokier <jamie@shareable.org>
Nimbus: an Ethereum 2.0 Sharding Client for Resource-Restricted Devices
Rationale
Nimbus: an Ethereum 2.0 Sharding Client. The code in this repository is currently focusing on Ethereum 1.0 feature parity, while all 2.0 research and development is happening in parallel in nimbus-eth2.
Development Updates
To keep up to date with changes and development progress, follow the Nimbus blog.
Building & Testing
We currently do not guarantee that Nimbus will work on Windows.
Prerequisites
- RocksDB
- PCRE
- GNU Make, Bash and the usual POSIX utilities. Git 2.9.4 or newer.
On Windows, a precompiled DLL collection download is available through the fetch-dlls
Makefile target: (Windows instructions).
# MacOS with Homebrew
brew install rocksdb pcre
# Fedora
dnf install rocksdb-devel pcre pcre-devel
# Debian and Ubuntu
sudo apt-get install librocksdb-dev libpcre3-dev
# Arch (AUR)
pakku -S rocksdb pcre-static
rocksdb
can also be installed by following their instructions.
Obtaining the prerequisites through the Nix package manager
Experimental
Users of the Nix package manager can install all prerequisites simply by running:
nix-shell default.nix
Build & Develop
POSIX-compatible OS
# The first `make` invocation will update all Git submodules.
# You'll run `make update` after each `git pull`, in the future, to keep those submodules up to date.
make nimbus
# See available command line options
build/nimbus -- help
# Start syncing with mainnet
build/nimbus
# Update to latest version
git pull
make update
# Run tests
make test
To run a command that might use binaries from the Status Nim fork:
./env.sh bash # start a new interactive shell with the right env vars set
which nim
nim --version
# or without starting a new interactive shell:
./env.sh which nim
./env.sh nim --version
Our Wiki provides additional helpful information for debugging individual test cases and for pairing Nimbus with a locally running copy of Geth.
Windows
(Experimental support!)
Install Mingw-w64 for your architecture using the "MinGW-W64 Online Installer" (first link under the directory listing). Run it and select your architecture in the setup menu ("i686" on 32-bit, "x86_64" on 64-bit), set the threads to "win32" and the exceptions to "dwarf" on 32-bit and "seh" on 64-bit. Change the installation directory to "C:\mingw-w64" and add it to your system PATH in "My Computer"/"This PC" -> Properties -> Advanced system settings -> Environment Variables -> Path -> Edit -> New -> C:\mingw-w64\mingw64\bin (it's "C:\mingw-w64\mingw32\bin" on 32-bit)
Install Git for Windows and use a "Git Bash" shell to clone and build Nimbus.
If you don't want to compile RocksDB and SQLite separately, you can fetch pre-compiled DLLs with:
mingw32-make fetch-dlls # this will place the right DLLs for your architecture in the "build/" directory
You can now follow those instructions in the previous section by replacing make
with mingw32-make
(regardless of your 32-bit or 64-bit architecture):
mingw32-make nimbus # build the Nimbus binary
mingw32-make test # run the test suite
# etc.
Raspberry PI
Experimental The code can be compiled on a Raspberry PI:
- Raspberry PI 3b+
- 64gb SD Card (less might work too, but the default recommended 4-8GB will probably be too small)
- Rasbian Buster Lite - Lite version is enough to get going and will save some disk space!
Assuming you're working with a freshly written image:
# Start by increasing swap size to 2gb:
sudo vi /etc/dphys-swapfile
# Set CONF_SWAPSIZE=2048
# :wq
sudo reboot
# Install prerequisites
sudo apt-get install git libgflags-dev libsnappy-dev
mkdir status
cd status
# Install rocksdb
git clone https://github.com/facebook/rocksdb.git
cd rocksdb
make shared_lib
sudo make install
cd..
# Raspberry pi doesn't include /usr/local/lib in library search path - need to add
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
git clone https://github.com/status-im/nimbus.git
cd nimbus
# Follow instructions above!
Android
Experimental Code can be compiled and run on Android devices
Environment setup
- Install the Termux app from FDroid or the Google Play store
- Install a PRoot of your choice following the instructions for your preferred distribution. Note, the Ubuntu PRoot is known to contain all Nimbus prerequisites compiled on Arm64 architecture (common architecture for Android devices). Depending on the distribution, it may require effort beyond the scope of this guide to get all prerequisites.
Assuming Ubuntu PRoot is used
# Install prerequisites
apt install librocksdb-dev libpcre3-dev
# Clone repo and build Nimbus just like above
git clone https://github.com/status-im/nimbus.git
cd nimbus
make
make nimbus
build/nimbus
Development tips
Interesting Make variables and targets are documented in the nimbus-build-system repo.
-
you can switch the DB backend with a Nim compiler define:
-d:nimbus_db_backend=...
where the (case-insensitive) value is one of "rocksdb" (the default), "sqlite", "lmdb" -
the Premix debugging tools are documented separately
-
you can control the Makefile's verbosity with the V variable (defaults to 0):
make V=1 # verbose
make V=2 test # even more verbose
- same for the Chronicles log level:
make LOG_LEVEL=DEBUG nimbus # this is the default
make LOG_LEVEL=TRACE nimbus # log everything
- pass arbitrary parameters to the Nim compiler:
make NIMFLAGS="-d:release"
- if you want to use SSH keys with GitHub (also handles submodules):
make github-ssh
- force a Nim compiler rebuild:
rm vendor/Nim/bin/nim
make -j8 build-nim
Git submodule workflow
Working on a dependency:
cd vendor/nim-chronicles
git checkout -b mybranch
# make some changes
git status
git commit -a
git push origin mybranch
# create a GitHub PR and wait for it to be approved and merged
git checkout master
git pull
git branch -d mybranch
# realise that the merge was done without "--no-ff"
git branch -D mybranch
# update the submodule's commit in the superproject
cd ../..
git status
git add vendor/nim-chronicles
git commit
It's important that you only update the submodule commit after it's available upstream.
You might want to do this on a new branch of the superproject, so you can make a GitHub PR for it and see the CI test results.
Don't update all Git submodules at once, just because you found the relevant
Git command or make
target. You risk updating submodules to other people's
latest commits when they are not ready to be used in the superproject.
Adding the submodule "https://github.com/status-im/foo" to "vendor/foo":
vendor/nimbus-build-system/scripts/add_submodule.sh status-im/foo
# or
./env.sh add_submodule status-im/foo
# want to place it in "vendor/bar" instead?
./env.sh add_submodule status-im/foo vendor/bar
Removing the submodule "vendor/bar":
git submodule deinit -f -- vendor/bar
git rm -f vendor/bar
Checking out older commits, either to bisect something or to reproduce an older build:
git checkout <commit hash here>
make clean
make -j8 update
Running a dependency's test suite using nim
instead of nimble
(which cannot be
convinced not to run a dependency check, thus clashing with our jury-rigged
"vendor/.nimble/pkgs"):
cd vendor/nim-rocksdb
../nimbus-build-system/scripts/nimble.sh test
# or
../../env.sh nimble test
Metric visualisation
Install Prometheus and Grafana. On Gentoo, it's emerge prometheus grafana-bin
.
# build Nimbus
make nimbus
# the Prometheus daemon will create its data dir in the current dir, so give it its own directory
mkdir ../my_metrics
# copy the basic config file over there
cp -a examples/prometheus.yml ../my_metrics/
# start Prometheus in a separate terminal
cd ../my_metrics
prometheus --config.file=prometheus.yml # loads ./prometheus.yml, writes metric data to ./data
# start a fresh Nimbus sync and export metrics
rm -rf ~/.cache/nimbus/db; ./build/nimbus --prune:archive --metricsServer
Start the Grafana server. On Gentoo it's /etc/init.d/grafana start
. Go to
http://localhost:3000, log in with admin:admin and change the password.
Add Prometheus as a data source. The default address of http://localhost:9090 is OK, but Grafana 6.3.5 will not apply that semitransparent default you see in the form field, unless you click on it.
Create a new dashboard. Click on its default title in the upper left corner ("New Dashboard"). In the new page, click "Import dashboard" in the right column and upload "examples/Nimbus-Grafana-dashboard.json".
In the main panel, there's a hidden button used to assign metrics to the left or right Y-axis - it's the coloured line on the left of the metric name, in the graph legend.
To see a single metric, click on its name in the legend. Click it again to go back to the combined view. To edit a panel, click on its title and select "Edit".
Troubleshooting
Report any errors you encounter, please, if not already documented!
- Turn it off and on again:
make clean
make update
License
Licensed and distributed under either of
- MIT license: LICENSE-MIT or http://opensource.org/licenses/MIT
or
- Apache License, Version 2.0, (LICENSE-APACHEv2 or http://www.apache.org/licenses/LICENSE-2.0)
at your option. These files may not be copied, modified, or distributed except according to those terms.