-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
testing: Add Ethereum simnet harness. #956
Conversation
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0 also possible
[harness-ctl]$ ./mine-alpha 6
1
1
1
0
2
1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How did you generate this json for CHAIN_ADDRESS_JSON
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just copy pasted straight from an "account" created with geth. You can find them as files in ~/.ethereum/keystore/long-name-with-date
.
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. |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
30303 was mainnet port, whoops
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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