Similar to eth-proof but for transaction proofs.

There are two ways to run this prover. The simplest way to get started is to use the in-memory runtime of Paladin. This requires very little setup, but it's not really suitable for a large scale test. The other method for testing the prover is to leverage an AMQP like RabbitMQ to distribute workload over many workers.

Before running the prover, you'll need to compile the application. This command should do the trick:

env RUSTFLAGS='-C target-cpu=native' cargo build --release

You should end up with two binaries in your target/release folder. One is called worker and the other is leader. Typically, we'll install these somewhere in our $PATH for convenience.

Once you have application available, you'll need to create a block witness which essentially serves as the input for the prover. Assuming you've deployed the leader binary, you should be able to generate a witness like this:

paladin-leader rpc -u $RPC_URL -t 0x2f0faea6778845b02f9faf84e7e911ef12c287ce7deb924c5925f3626c77906e > 0x2f0faea6778845b02f9faf84e7e911ef12c287ce7deb924c5925f3626c77906e.json

You'll need access to an Ethereum RPC in order to run this command. The input argument is a transaction hash and in particular it is the last transaction has in the block.

Once you've successfully generated a witness, you're ready to start proving either with the in-memory runtime or the amqp runtime.

Running the prover with the in-memory flag requires no setup. You can attempt to generate a proof with a command like this.

env RUST_MIN_STACK=33554432 \
ARITHMETIC_CIRCUIT_SIZE="15..28" \
BYTE_PACKING_CIRCUIT_SIZE="9..28" \
CPU_CIRCUIT_SIZE="12..28" \
KECCAK_CIRCUIT_SIZE="14..28" \
KECCAK_SPONGE_CIRCUIT_SIZE="9..28" \
LOGIC_CIRCUIT_SIZE="12..28" \
MEMORY_CIRCUIT_SIZE="17..30" \
paladin-leader prove \
--runtime in-memory \
--num-workers 1 \
--input-witness 0x2f0faea6778845b02f9faf84e7e911ef12c287ce7deb924c5925f3626c77906e.json

The circuit parameters here are meant to be compatible with virtually all Ethereum blocks. This will create a block proof from an input state root of the preceding block. You can adjust the --num-workers flag based on the number of available compute resources. As a rule of thumb, you'd probably want at least 8 cores per worker. It's also worth noting that you'll probably want at least 40GB of physical memory to run the prover.

Proving in a distributed compute environment depends on an AMQP server. We're not going to cover the setup of RabbitMQ, but assuming you have something like that available you can run a "leader" which distribute proving tasks to a collection of "workers" which actually do the proving work.

In order to run the workers, you'll use a command like:

env RUST_MIN_STACK=33554432 \
ARITHMETIC_CIRCUIT_SIZE="15..28" \
BYTE_PACKING_CIRCUIT_SIZE="9..28" \
CPU_CIRCUIT_SIZE="12..28" \
KECCAK_CIRCUIT_SIZE="14..28" \
KECCAK_SPONGE_CIRCUIT_SIZE="9..28" \
LOGIC_CIRCUIT_SIZE="12..28" \
MEMORY_CIRCUIT_SIZE="17..30" \
paladin-worker --runtime amqp --amqp-uri=amqp://localhost:5672

This will start the worker and have it await tasks. Depending on the size of your machine, you may be able to run several workers on the same operating system. An example systemd service is included. Once that service is installed, you could enable and start 16 workers on the same VM like this:

seq 0 15 | xargs -I xxx systemctl enable paladin-worker@xxx
seq 0 15 | xargs -I xxx systemctl start paladin-worker@xxx

Now that you have your pool of paladin workers, you can start proving with a command like this:

paladin-leader prove \
--runtime amqp \
--amqp-uri=amqp://localhost:5672 \
--input-witness 0x2f0faea6778845b02f9faf84e7e911ef12c287ce7deb924c5925f3626c77906e.json

This command will run the same way as the in-memory mode except that the leader itself isn't doing the work. The separate worker processes are doing the heavy lifting.

Licensed under either of:

• Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

at your option.

The SPDX license identifier for this project is MIT OR Apache-2.0.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.