NDRS-142: Implement block executor

[mpapierski]

Implements simplified BlockExecutor component.

• Takes post_state_hash from chainspec handler
• Updates post_state_hash after each commit for each execution result
• Can execute as much deploys as passed through FinalizedBlock and commit them
• There are some test assumptions regarding error handling still (i.e. assumes post state hash exists otherwise panics)
• Client is updated to accept --session-args session_args.json and --payment-args payment_args.json and makes deploy hashes random. Right now it's simplified to allow only CLValues serialized into base16 (see below)
• Also node is actually doing AccountHash from PublicKey as documented both in chainspec and during execution.
• Signatures/authorized keys right now just assumed to be same as the deploying account

Testing

I was able to test the execution end to end with a new totally random secret key:

dd if=/dev/urandom of=secret_key.raw bs=1 count=32
# PUBLIC_KEY=$(here obtain public key in base16 using a print statement inside a client)
echo "$PUBLIC_KEY,ed25519,1000000000000000,0" >> resources/production/accounts.csv

Run node:

RUST_LOG=trace cargo run -- validator --config=$(pwd)/mynode.toml

Put deploy:

cargo run --bin=casperlabs-client -- put-deploy http://localhost:7777 \
  --payment-code target/wasm32-unknown-unknown/release/standard_payment.wasm \
  --payment-args payment_args.json \
  --session-code target/wasm32-unknown-unknown/release/revert.wasm \
  --session-args session_args.json \
  --secret-key secret_key.raw

Where args are:

payment_args.json

[
  {
    "name": "amount",
    "value": {
      "raw_bytes": "050000000400e1f50508"
    }
  }
]

session_args.json

[]

[goral09]

What does the long do? Also, it looks like you're adding it to session_code rather than payment_args. Is that intentional?

[mpapierski]

Yes that's intentional. payment_code, payment_args, session_code, session_args are all meant to be valid paths (parse(from_os_str)) and will be parsed from command line as --payment-code <filename> (long)

[goral09]

Can you update the comment – it passes it to the BlockExecutor, not Contract Runtime anymore.

[mpapierski]

Corrected

[goral09]

if it needs only the post-state hash then it shouldn't have to accept the whole ChainSpecHandler.

[mpapierski]

I wanted to hide that fact so only block executor would know what he needs from chainspec to function properly but fair enough I changed it

[goral09]

In the event sourcing pattern, events are in the past tense b/c they represent something that has already happened. Here, you're mixing requests and events.

[mpapierski]

Can you describe how naming of those variants could be improved? Here I tried to follow similar Event enums from other components:

• https://github.com/mpapierski/casperlabs-node/blob/7ade3bded4bc466bc5c35b6cab7936aabe1a5954/node/src/components/api_server/event.rs#L11-L25
• https://github.com/mpapierski/casperlabs-node/blob/274f785e1f253bba076ce256dc001203748b84c0/node/src/components/small_network/event.rs#L46-L48

[goral09]

Why do both execution and commit events have to have the Vec<ExecutionResult>?

[goral09]

Why do we call the same method, process_execution_results both in DeploysExecutionResult and CommitExecutionEffects?

[mpapierski]

To avoid duplication as process_execution_results checks if there's more results, and if there's more then it will schedule another event to commit them, otherwise it will just respond to the main_responder.

[goral09]

Personally, in cases like this one, I prefer to duplicate rather than confusion. But maybe it's just me that is confused.

[goral09]

So this will be called for both DeploysExecutionResult and CommitExecutionEffects? I am a bit lost.

[mpapierski]

CommitExecutionEffects will be called repeatedly with ExecutionResults until it's empty and then it will respond. I changed naming slightly to follow other component's naming for similar events.