testing: Add Ethereum simnet harness. #956
Conversation
JoeGruffins
force-pushed
the
ethharness
branch
from
3e97ef7
to
6e79501
Compare
dex/testing/eth/harness.sh
Outdated
| # Write mining javascript. | ||
| # NOTE: This sometimes mines more than one block. It is a race. | ||
| cat > "${MINE_JS}" <<EOF | ||
| function mine() { | ||
| miner.start(); | ||
| miner.stop(); | ||
| admin.sleep(1.1); | ||
| return true; | ||
| } | ||
| EOF |
There was a problem hiding this comment.
This could definitely be improved, but I currently can't see how. I don't think there's a way to specify the number of blocks you want to mine. calling start and stop in succession usually mines one, but sometimes, rarley, it mines two. Also, mining will only happen every second. So, if you were to call start stop start stop without waiting, it would only mine one block (or maybe two...) Sleeping for 1.1 secounds seems to ensure that you mine at least the number of blocks you wanted, but could be more.
There was a problem hiding this comment.
0 also possible
[harness-ctl]$ ./mine-alpha 6
1
1
1
0
2
1
There was a problem hiding this comment.
Dang. There's gotta be a js while loop solution to spin until a block is mined.
dex/testing/eth/harness.sh
Outdated
| echo "Starting simnet beta node" | ||
| "${HARNESS_DIR}/create-node.sh" "$SESSION:2" "beta" "$BETA_NODE_PORT " \ | ||
| "$CHAIN_ADDRESS" "$PASSWORD" "$CHAIN_ADDRESS_JSON " \ | ||
| "$CHAIN_ADDRESS_JSON_FILE_NAME" "$BETA_ADDRESS" "$PASSWORD" \ | ||
| "$BETA_ADDRESS_JSON " "$BETA_ADDRESS_JSON_FILE_NAME" "$BETA_NODE_KEY" | ||
|
|
||
| # NOTE: This will cause beta to connect automatically to alpha. | ||
| echo "Connecting nodes" | ||
| "${NODES_ROOT}/harness-ctl/alpha" "attach --exec admin.addPeer('enode://${BETA_ENODE}@127.0.0.1:$BETA_NODE_PORT')" |
There was a problem hiding this comment.
Maybe this needs a sleep in-between starting and connecting, but this is working fine for me.
|
|
||
| CHAIN_ADDRESS_JSON_FILE_NAME="UTC--2021-01-27T08-20-38.123221057Z--9ebba10a6136607688ca4f27fab70e23938cd027" | ||
| CHAIN_ADDRESS="9ebba10a6136607688ca4f27fab70e23938cd027" | ||
| CHAIN_ADDRESS_JSON='{"address":"9ebba10a6136607688ca4f27fab70e23938cd027","crypto":{"cipher":"aes-128-ctr","ciphertext":"dcfbe17de6f315c732855111b782496d76b2d703169afddaaa69e1bc9e02ec51","cipherparams":{"iv":"907e5e050649d1c5c0be782ec7db5cf1"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":262144,"p":1,"r":8,"salt":"060f4e16d601069a6bccae0693a15cd72090baf1ab20e408c89883117d4f7c51"},"mac":"b9ca7dad75a04b77dc7751a814c051f32752603334e4bb4046caf927196a5579"},"id":"74805e39-6a2f-46eb-8125-70c41d12c6d9","version":3}' |
There was a problem hiding this comment.
This is basically what an eth wallet looks like. The wiki says that users should use this: https://geth.ethereum.org/docs/clef/tutorial
afaict, clef can provide deterministic keys. It then automatically saves those keys to the datadir/keystore directory it is pointing to. I am still looking into what we will need to work with this "wallet"? I think with certain rules we can have it serve us up addresses on demand. Not sure at all yet though.
There was a problem hiding this comment.
Adding clef "wallets" in another pr. Perhaps they cannot be used while mining? I was able to cause some panics... Will add separate trading node/wallets that make use of clef.
There was a problem hiding this comment.
I've decided against using clef. It only seems to complicate things. We can get what we need straight from geth. I don't think geth's account management should be something we should have to worry about so much. I have the basics for using clef going here, in case it turns out we should use it: JoeGruffins@2240d49
From the clef readme it looks like this is mostly a plus for remote signers. Since we will be requiring the eth node be local, I don't think it benefits us. If we decided to go with explorers, we would use it. That has not been our design pattern so far however.
There was a problem hiding this comment.
How did you generate this json for CHAIN_ADDRESS_JSON?
There was a problem hiding this comment.
I just copy pasted straight from an "account" created with geth. You can find them as files in ~/.ethereum/keystore/long-name-with-date.
JoeGruffins
force-pushed
the
ethharness
branch
from
6e79501
to
6a689dd
Compare
|
Added a "group" directory so that we can have |
|
I had to add more funds to send a simple transaction. This still may not be enough. |
JoeGruffins
force-pushed
the
ethharness
branch
from
67bbe18
to
17b3ca4
Compare
dex/testing/eth/harness.sh
Outdated
| BETA_NODE_PORT="30303" | ||
| BETA_NODE_PORT="30305" |
There was a problem hiding this comment.
30303 was mainnet port, whoops
There was a problem hiding this comment.
Awesome work, @JoeGruffins! I think we're going to to learn a lot about how to do stuff like reliably mining a single block, and managing multiple accounts (wallets), as we proceed, and this is a wonderful start.
Just a couple small changes.
|
Odd test failure. Something known or should look into it? |
That's a new one. Will have to review what merged today to see if anything is to blame. For now, just retriggering the tests. |
This adds a basic ethereum private network testing harness.
This network relies on proof of authority. More about this can be found here https://eips.ethereum.org/EIPS/eip-225
It creates two nodes, either of which can add new blocks to the network. Each node starts with funds that can be sent to addresses that we later create in tests.
The harness does not start an rpc client. I think it is best that we use ipc (Inter-process communication) as this seems to be the most secure. Other options are an http or ws server, but neither is permissioned. They can be restricted to the local network, but at that point it doesn't seem much different than using ipc.
closes #940