Cargo still doesn't support bin dependencies (rust-lang/cargo#1982). However, several dependencies we currently have (like JSON parser) are only for the bin target.

Until that, I suggest we separate sputnikvm and gaslighter into two different crates. This basically creates a structure like below:

sputnikvm/Cargo.toml
sputnikvm/src/mod.rs
sputnikvm/src/vm/..
gaslighter/Cargo.toml
gaslighter/src/mod.rs

The sputnikvm will then be used to build the library, and the gaslighter will be used to build the executable.

After adding a few print statements in key locations

method: "eth_getBlockByNumber"
params: ["0xc11f", "false"]
response: "{\"jsonrpc\":\"2.0\",\"id\":2,\"error\":{\"code\":-32602,\"message\":\"json: cannot unmarshal string into Go value of type bool\"}}\n"

The response contains an unmarshal error.

I'm keen to know your setup or if your setup produces this error.

related to #122

Part of #122. Two servers are being used to conduct the regression test:

• nulltl-big: That World's Jenkin CI.
• sputnikvm1: a private server.

Current status:

• Block 1..200000: nulltl-big. finished.
• Block 200000..300000: sputnikvm1, job 1. finished.
• Block 300000..400000: sputnikvm1, job 2. finished.
• Block 400000..500000: sputnikvm1, job 3. finished.
• Block 500000..600000: sputnikvm1, job 4. finished.
• Block 600000..700000: sputnikvm1, job 5. finished.
• Block 700000..800000: sputnikvm1, job 1. finished.
• Block 800000..900000: sputnikvm1, job 2. finished.
• Block 900000..1000000: sputnikvm1, job 3. finished.
• Block 1000000..1100000: sputnikvm1, job 4. finished.
• Block 1100000..1150000: sputnikvm1, job 5. finished.

This has been fixed in other EVMs long time ago. See ethereum/go-ethereum#1150 and ethereum/go-ethereum#1150

A placeholder until I fixed this.

One can imagine a language built on top of SputnikVM. It works as an interpreter (like python and irb). Every time when the user enters a command, it compiles that command into EVM byte codes and send it to SputnikVM.

This functionality can be easily added by making PC replaceable -- every time, a new PC is used for the execution, with Memory and Stack kept the same. However, this currently add some accidental complexity. So I'm only planning to do this after the tests have mature.

Part of #122.

Use reference instead of heap allocated objects to reduce footprint.

There's the FromStr (https://doc.rust-lang.org/std/str/trait.FromStr.html) trait in the standard library. It's better to make all the current from_str methods comply with it.

If adding it to the current test framework, it would take a long time to finish as the file is around 60MB. So I'm going to keep an issue there until we found a solution.

Problem:
blocks
49987
49994
200597
204007

fails with:

block 49987, transaction count: 1

working on transaction 0x9e2783b3c42dea792faf9b636aeba0b4384bc0ec19f1a47d931ffee686869637
Feeding VM account code at 0x109c4f2ccc82c4d77bde15f306707320294aea3f ...
Feeding VM account at 0x109c4f2ccc82c4d77bde15f306707320294aea3f ...
Feeding VM account storage at 0x109c4f2ccc82c4d77bde15f306707320294aea3f with index 0x0000000000000000000000000000000000000000000000000000000000000001 ...
Feeding VM account storage at 0x109c4f2ccc82c4d77bde15f306707320294aea3f with index 0x0000000000000000000000000000000000000000000000000000000000000003 ...
Feeding VM account storage at 0x109c4f2ccc82c4d77bde15f306707320294aea3f with index 0xc2575a0e9e593c00f959f8c92f12db2869c3395a3b0502d05e2516446f71f85c ...
Feeding VM account storage at 0x109c4f2ccc82c4d77bde15f306707320294aea3f with index 0x0000000000000000000000000000000000000000000000000000000000000000 ...
Feeding VM account storage at 0x109c4f2ccc82c4d77bde15f306707320294aea3f with index 0xc2575a0e9e593c00f959f8c92f12db2869c3395a3b0502d05e2516446f71f85b ...
Feeding VM account at 0x881b0a4e9c55d08e31d8d3c022144d75a454211c ...
thread 'main' panicked at 'assertion failed: carry == 0', bigint/src/u512.rs:143
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   6: <bigint::u512::U512 as core::ops::Add>::add
             at /home/stewart/dev/fractalide/etcdev/sputnikvm/bigint/src/u512.rs:143
   7: <sputnikvm::utils::gas::Gas as core::ops::Add>::add
             at /home/stewart/dev/fractalide/etcdev/sputnikvm/sputnikvm/src/utils/gas.rs:65
   8: <sputnikvm::vm::eval::Machine<M>>::step
             at /home/stewart/dev/fractalide/etcdev/sputnikvm/sputnikvm/src/vm/eval/mod.rs:344
   9: <sputnikvm::vm::ContextVM<M> as sputnikvm::vm::VM>::step
             at /home/stewart/dev/fractalide/etcdev/sputnikvm/sputnikvm/src/vm/mod.rs:154
  10: <sputnikvm::vm::transaction::TransactionVM<M> as sputnikvm::vm::VM>::step
             at /home/stewart/dev/fractalide/etcdev/sputnikvm/sputnikvm/src/vm/transaction.rs:213
  11: sputnikvm::vm::VM::fire
             at /home/stewart/dev/fractalide/etcdev/sputnikvm/sputnikvm/src/vm/mod.rs:61
  12: regtests::handle_fire
             at ./src/bin/main.rs:67
  13: regtests::test_block
             at ./src/bin/main.rs:154
  14: regtests::main
             at ./src/bin/main.rs:259
  15: std::panicking::try::do_call
  16: __rust_maybe_catch_panic
  17: std::rt::lang_start
  18: main
  19: __libc_start_main
  20: _start
             at ../sysdeps/x86_64/start.S:120

Solution: I'll add it

A placeholder until I finished removing them.

Solution: (three of them)

The path forward with the least amount of friction is publish your merkle.rs fork to crates.io and we bump the rustRegistry index. If we start venturing too far into nix land we should go the path of nixcrates this would be a very positive thing as it would ensure we have reproducible builds (not bitwise), but I hesitate about this direction as it would detract work from sputnikvm. So either we refactor the .travis.yml file to remove the nix functionality (which would be a pity) or we publish your merkle.rs fork to crates.io or go full blown nixcrates.

1. remove nix from travis: Travis would need to have a capnproto compile step and require hours of pain waiting through travis compile steps. (I personally am not prepared to suffer this pain any longer) this allows us to use git attributes in Cargo.toml files.
2. if feels dirty to publish a merkle.rs fork but crates.io is an accretion system so it's legit usage. This allows us to keep the flexibility of the nix environment without the hair pulling travis nonsense.
3. nixcrates: hardcore route it mixes pain, suffering but the rewards are great. Sadly those rewards aren't immediately felt by the ETC community. Basically at this stage we don't need cargo and Cargo.toml files.

I suggest number 2

Part of #122

Right now in https://github.com/ethereumproject/sputnikvm/wiki/VM-Integrator we have a large chunk of code file. The problem with this is that it's not directly runable, and the rendering looks bad.

I suggest we use Rust's cargo examples feature to handle those code.

This issue records the documentation status. It will be closed once we finalized the initial version of the documentation.

VM Specifications

• rfcs

User Documentation

• unstarted

Developer Documentation

• unstarted

Rust Docs

• unstarted

For testing edge cases of this EVM, hand-crafting a large amount of tests is overwhelming as we have limited man-power. One thing we can do is code review -- to make sure all codes comply with the yellow paper. Here I propose an additional method to address this problem -- by re-runing all the transactions in the existing ETC blockchain and make sure they return the same result using several different ETC clients and our SVM. I call it "compliance test".

Method 1: Full Node

We can use one or multiple existing ETC clients to run a full node. Those full nodes have all its internal states of all the accounts maintained. So we can extract them, and then re-run the transaction using SVM.

Method 2: Using A Blockchain Explorer

This makes it so that we don't need to download more than 30GB of data if we only want to test against several recent blocks. Many ETC explorer (such as gastracker.io) has the input details of a transaction and additional transactions it triggers if it is a message call (see https://gastracker.io/tx/0x1a2ce1a9128eaf575244278c89a822198ae4002454e9dd434f5291677d4a8d9e for an example). However, storage information and output details are not in the explorer, which might be a problem.

Right now as we build on stable Rust, const fn is not available. Thus struct like Gas are constructed on the fly (the config file only store a u64). Performance can be improved if we utilize lazy_static or const fn, if the latter ever stabilize (rust-lang/rust#24111).

Is this under active usage (I remember we're switching to leveldb for the blockchain regression)?

Also, at this stage, the library doesn't have any plan for any non-cargo dependency. There might be one or more dependency (merkle, for example). However, after #79 is applied, sputnikvm dependency will be specified using path = "../sputnikvm". This again breaks the Nix building system. Right now it seems that Nix still doesn't bring us many benefits. So do you think it is okay to temporarily switch to the standard rust environment for Travis before nixcrates is finished?

Right now except balance and values, all other variables internally used by SVM is M256 (or usize). However, although currently we've properly checked to make sure it never happen, there's some variables that should never overflow. This includes index-like variables and others. They should be changed to use U256.

Potential Solution:

Rename the "need more information" "error" to be a Need More Information or NMI concept.
This keeps the semantics clear, it also means that when we speak about an error in execution it very clearly means the VM failed to execute.

As refactoring goes on, some documentations will need to be modified. This feature-issue keeps track of those changes.

This issue records all the current test status for VMTests in the ethereumproject/tests repository. It will be closed when all tests pass.

Individual files test status

vmArithmeticTest.json

🆗 All passed.

vmBitwiseLogicOperationTest.json

🆗 All passed.

vmBlockInfoTest.json

🆗 All passed.

vmEnvironmentalInfoTest.json

🆗 All passed.

vmInputLimits.json

Not yet.

vmIOandFlowOperationsTest.json

🆗 All passed.

vmLogTest.json

🆗 All passed.

vmPerformanceTest.json

🆗 All passed.

vmPushDupSwapTest.json

🆗 All passed.

vmSha3Test.json

🆗 All passed.

vmSystemOperationsTest.json

Not yet.

vmtests.json

Not yet.

Problem:
blocks
46169
46170
46194
46205
46220
46230
46235
46238
46240
46242
46245
46246
46247
46250
46251
46254
46256
46259
46260
46261
46262
46269
... (seems to be many)
fails with this error

working on transaction 0x19f1df2c7ee6b464720ad28e903aeda1a5ad8780afc22f0b960827bd4fcf656d
Feeding VM account code at 0x5c12a8e43faf884521c2454f39560e6c265a68c8 ...
thread 'main' panicked at 'assertion failed: !v', bigint/src/u256.rs:362
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   6: <bigint::u256::U256 as core::ops::Sub>::sub
             at /home/stewart/dev/fractalide/etcdev/sputnikvm/bigint/src/u256.rs:362
   7: sputnikvm::vm::commit::account::AccountState::decrease_balance
             at /home/stewart/dev/fractalide/etcdev/sputnikvm/sputnikvm/src/vm/commit/account.rs:383
   8: <sputnikvm::vm::eval::Machine<M>>::finalize
             at /home/stewart/dev/fractalide/etcdev/sputnikvm/sputnikvm/src/vm/eval/mod.rs:196
   9: <sputnikvm::vm::transaction::TransactionVM<M> as sputnikvm::vm::VM>::step
             at /home/stewart/dev/fractalide/etcdev/sputnikvm/sputnikvm/src/vm/transaction.rs:224
  10: sputnikvm::vm::VM::fire
             at /home/stewart/dev/fractalide/etcdev/sputnikvm/sputnikvm/src/vm/mod.rs:61
  11: regtests::handle_fire
             at ./src/bin/main.rs:67
  12: regtests::test_block
             at ./src/bin/main.rs:134
  13: regtests::main
             at ./src/bin/main.rs:192
  14: std::panicking::try::do_call
  15: __rust_maybe_catch_panic
  16: std::rt::lang_start
  17: main
  18: __libc_start_main
  19: _start
             at ../sysdeps/x86_64/start.S:120

Solution: move the github.com/sorpaas/u256 file into sputnikvm to reduce development latency. Once u256 stabilizes we can move it out to sorpaas/u256 and bump the crate.

three paths:

A) feed ethereumproject/tests into cli using it as "magnetic north". then by hand craft a new set of capnp tests.
B) code write ethereumproject/tests to tests/*.capnp, this will require we constantly change the code writer as we mature the vm (i.e. added parameter, externalities etc). This path is laborious.
C) use ethereumproject/tests as the canonical test form and compile to capnp binary for fast execution. This path doesn't have human readable tests, and any bugs that require a test would need to be added in the json form. This path is annoying

Solution:

Path A

Part of #122. I can use That World's Jenkin server for CI setup.

Currently, the only problem for setting up a CI is to find a good public RPC endpoint. This seems to be a problem right now. HTTP nodes are preferred to HTTPS nodes, as we don't need additional dependencies. A suitable candidate is http://api.gastracker.io/web3, however, it does not work against the current setup.

@sjmackenzie Can you help to test regtests running against a local Geth RPC endpoint?

Currently MessageCallMachine and ContractCreationMachine doesn't handle upfront cost payment in YP section 6.2. This is not needed for transactions executed by code. The ContractCreation finalization cost should also be handled.

Those things are not presented in the tests, but is handled by our API. So we need to add a flag specifying whether the user wants the VM to handle the upfront cost.

We've got a basic communication mechanism for SputnikVM. It works like this:

1. Client creates a new VM either through an execution context, a message call transaction, or a contract creation transaction.
2. Client fires or steps the VM, and inspects the internal of the VM. The VM will return either OK, an Err, or a NeedMoreInfo.
3. If the VM returns an error, the internal of the VM will not be changed.
4. NeedMoreInfo can be RequireAccount, RequireAccountCode, RequireBlockhash. The client then knows it needs to commit the relevant information back to the VM and fire it again.
5. The VM never mutates state outside of itself.
6. The VM handles CALL/CREATE transaction execution without any need from the client.
7. When the execution is finished or in the middle, the client can inspect the state to be changed if the client wants to accept the result of the VM. This includes account information (either full account information, or an increase/decrease of balance), logs and transactions.

Now we need to design a capnp or json schema and communication method for the socket protocol.

We might also want to test this library build on nightly and beta, just to make sure it works correctly.

I'm doing some big refactoring on run.rs so things might break hard.

Problem:
blocks
46274
46284
46343
46344
46390
46398
46456
46480
46531
46546
46582
46647
46674
46695
46710
46722
46724
46797
46823
46826
46854
46878
46891
46893
46947
46955
46985
46989
47026
47185
47214
47233
47237
47250
47254
47318
47361
47395
47403
47425
47460
47498
47571
47584
47633
47640
47657
47658
47689
47707
47719
47726
47752
47830
47913
48015
48034
48040

... (seems to be many)
fail with this error

block 46274, transaction count: 1

working on transaction 0x669890439f5093b7dfbca9b06de1d6da78ceacf1ec0753252b3e6cf10ff81a3e
Feeding VM account code at 0xff68c2f39c4e7fe2f92c2dc2f8615b1bf070e0fa ...
VM exited with ExitedOk.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ErrorImpl { code: Message("invalid type: unit value, expected struct RPCBlock"), line: 1, column: 39 }', /checkout/src/libcore/result.rs:859
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: std::panicking::begin_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::result::unwrap_failed
             at /checkout/src/libcore/macros.rs:29
  10: <core::result::Result<T, E>>::unwrap
             at /checkout/src/libcore/result.rs:737
  11: gethrpc::GethRPCClient::rpc_object_request
             at /home/stewart/dev/fractalide/etcdev/sputnikvm/gethrpc/src/lib.rs:162
  12: gethrpc::GethRPCClient::get_block_by_hash
             at /home/stewart/dev/fractalide/etcdev/sputnikvm/gethrpc/src/lib.rs:278
  13: regtests::is_miner_or_uncle
             at ./src/bin/main.rs:124
  14: regtests::test_block
             at ./src/bin/main.rs:214
  15: regtests::main
             at ./src/bin/main.rs:259
  16: std::panicking::try::do_call
  17: __rust_maybe_catch_panic
  18: std::rt::lang_start
  19: main
  20: __libc_start_main
  21: _start
             at ../sysdeps/x86_64/start.S:120

Problem:
block
46147
46214
46217
46219
46237
46253
... (seems to be many)
fails with this error:

$ RUST_BACKTRACE=1 cargo run --bin regtests -- -r http://127.0.0.1:8545 -n 46147
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `/home/stewart/dev/etcdev/sputnikvm/target/debug/regtests -r 'http://127.0.0.1:8545' -n 46147`
net version: 1
block 46147, transaction count: 1

working on transaction 0x5c504ed432cb51138bcf09aa5e8a410dd4a1e204ef84bfed1be16dfba1b22060
Feeding VM account code at 0x5df9b87991262f6ba471f09758cde1c0fc1de734 ...
VM exited with ExitedOk.
thread 'main' panicked at 'not yet implemented', src/bin/main.rs:167
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   6: regtests::test_block
             at ./src/bin/main.rs:167
   7: regtests::main
             at ./src/bin/main.rs:196
   8: std::panicking::try::do_call
   9: __rust_maybe_catch_panic
  10: std::rt::lang_start
  11: main
  12: __libc_start_main
  13: _start

A placeholder until I get this done.

Currently there're ongoing patch wars #172, #173, #174, #122. Those affect SputnikVM's development process.

While we aim to resolve them, before they are settled, all important issues are being moved to the wiki page. This issue documents the process.

When the regression test is finished, we might be able to work on the RPC protocol as specified in https://etcrfc.that.world/16-EVMJSON

Move the upfront_cost function to sputnikvm crate.

Iterate over the Ethereum Classic blockchain and test EVM.

• RPC Protocol
• test_transaction fn
• Block iteration
• CI setup
• Check all blocks and fix bugs along the way

All tests completed:

• 1-1150000 (#172)
• 1150000-2500000 (#174)
• 2500000-3000000 (#237)
• 3000000-4000000 (#240)

Code coverage is a good indicator to see whether we lack testing. There are some guides (http://sunjay.ca/2016/07/25/rust-code-coverage) for how to create a code coverage matrix for a Rust program.

It's not covered by the test. This will be dealt with later.

Problem:
blocks
50107
50438
50559
50820

fail with this error:

block 50107, transaction count: 1

working on transaction 0x3f97c969ddf71f515ce5373b1f8e76e9fd7016611d8ce455881009414301789e
Feeding VM account code at 0x109c4f2ccc82c4d77bde15f306707320294aea3f ...
Feeding VM account at 0x109c4f2ccc82c4d77bde15f306707320294aea3f ...
Feeding VM account storage at 0x109c4f2ccc82c4d77bde15f306707320294aea3f with index 0x0000000000000000000000000000000000000000000000000000000000000001 ...
Feeding VM account storage at 0x109c4f2ccc82c4d77bde15f306707320294aea3f with index 0x0000000000000000000000000000000000000000000000000000000000000003 ...
Feeding VM account storage at 0x109c4f2ccc82c4d77bde15f306707320294aea3f with index 0xc2575a0e9e593c00f959f8c92f12db2869c3395a3b0502d05e2516446f71f85c ...
Feeding VM account storage at 0x109c4f2ccc82c4d77bde15f306707320294aea3f with index 0x0000000000000000000000000000000000000000000000000000000000000000 ...
Feeding VM account storage at 0x109c4f2ccc82c4d77bde15f306707320294aea3f with index 0xc2575a0e9e593c00f959f8c92f12db2869c3395a3b0502d05e2516446f71f85b ...
Feeding VM account at 0x881b0a4e9c55d08e31d8d3c022144d75a454211c ...
Feeding VM account storage at 0x109c4f2ccc82c4d77bde15f306707320294aea3f with index 0x0000000000000000000000000000000000000000000000000000000000000002 ...
VM exited with ExitedErr(EmptyGas).
thread 'main' panicked at 'assertion failed: M256::from_str(&expected_value).unwrap() == value', src/bin/main.rs:184
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:511
   6: regtests::test_block
             at ./src/bin/main.rs:184
   7: regtests::main
             at ./src/bin/main.rs:259
   8: std::panicking::try::do_call
   9: __rust_maybe_catch_panic
  10: std::rt::lang_start
  11: main
  12: __libc_start_main
  13: _start
             at ../sysdeps/x86_64/start.S:120

However, the type Gas is using U512 for internal representation. This should be changed to U256.

Solution: The product of sputnikvm is machine.used_gas() currently returns a utils::gas::Gas type. Let's come up with a single unified return type containing Gas, and stuff like Code (next point of execution to pick up from) from which we can extract nicely.

This will allow us to format it into what ever way we need and send it over the wire/ABI/etc

Part of #122.

• 1150000..1200000: job 1. Finished.
• 1200000..1400000: job 2. Finished.
• 1400000..1600000: job 3. Finished.
• 1600000..1800000: job 4. Finished.
• 1800000..2000000: job 5. Finished.
• 2000000..2200000: job 6. Finished.
• 2200000..2400000: job 7. Finished.
• 2400000..2500000: job 8. Finished.

New failing numbers:

• 2400721
• 2204923
• 2002936
• 1800463
• 1605122
• 1431916
• 2305882
• 2420342
• 1240203
• 1240205
• 1721877

We'll need to have a closer look into this test in file vmPerformanceTest.json.

The test does not contain "out", so gaslighter expects it to fail. However, spunikvm runs it succeeded without any problem. The full code for this test is:

0x60e060020a6000350480632839e92814601e57806361047ff414603457005b602a6004356024356047565b8060005260206000f35b603d6004356099565b8060005260206000f35b600082600014605457605e565b8160010190506093565b81600014606957607b565b60756001840360016047565b90506093565b609060018403608c85600186036047565b6047565b90505b92915050565b6000816000148060a95750816001145b60b05760b7565b81905060cf565b60c1600283036099565b60cb600184036099565b0190505b91905056