Git-Mirrors/xmr-btc-swap
1
0
Fork 0
mirror of https://github.com/comit-network/xmr-btc-swap.git synced 2024-07-15 15:51:53 +00:00
Code Issues Packages Projects Releases Wiki Activity
3e82211a82
xmr-btc-swap/xmr-btc/tests/e2e.rs

357 lines
11 KiB
Rust
Raw Normal View History

Suppress compiler noise in tests folder By having two modules that declare and use the `harness` module we ran into a situation where not all parts of the `harness` module were being used by both of these other test modules. This was producing annoying warnings. For now this can be solved by marking the `harness` module declaration as public. This has no real effect since modules under `/tests` cannot be depended on elsewhere, but it satisfies the compiler. It does mean that we will not hear about unused functions, but this change should be temporary and it's a very minor problem given that it's just test code.
2020-10-15 10:53:55 +00:00
pub mod harness;
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
mod tests {
Increase Rust minimum stack size in CI
2020-10-21 04:52:51 +00:00
// NOTE: For some reason running these tests overflows the stack. In order to
// mitigate this run them with:
//
// RUST_MIN_STACK=100000000 cargo test
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
use crate::{
Move test functions out of lib
2020-10-08 22:28:51 +00:00
harness,
Fix build after merge
2020-10-22 03:42:36 +00:00
harness::{
init_bitcoind, init_test,
node::{run_alice_until, run_bob_until},
ALICE_TEST_DB_FOLDER, BOB_TEST_DB_FOLDER,
},
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
};
Move test functions out of lib
2020-10-08 22:28:51 +00:00
use futures::future;
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
use monero_harness::Monero;
use rand::rngs::OsRng;
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
Improve database type safety The database is now bound to a type eg. alice::State or bob::State. The caller cannot expect to retrieve a type that is different to the type that was stored.
2020-10-22 02:34:01 +00:00
use crate::harness::storage::Database;
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
use std::{convert::TryInto, path::Path};
Move test functions out of lib
2020-10-08 22:28:51 +00:00
use testcontainers::clients::Cli;
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
use tracing_subscriber::util::SubscriberInitExt;
use xmr_btc::{
alice, bitcoin,
bitcoin::{Amount, TX_FEE},
bob,
};
#[tokio::test]
async fn happy_path() {
let _guard = tracing_subscriber::fmt()
.with_env_filter("info")
.set_default();
let cli = Cli::default();
Simplify xmr-btc/tests Monero wallet - Make it the same for Alice and Bob. - Make it contain a wallet client instead of the `Monero` struct. Also: Remove `Container` from inside `Monero` struct. The caller of `new` can simply ensure that `Container` is not dropped to keep the container alive. This makes the `Monero` struct easier to work with, as it just holds the data necessary to create the different clients created during `init`, and does not have any lifetime restrictions.
2020-10-20 01:18:27 +00:00
let (monero, _container) = Monero::new(&cli);
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
let bitcoind = init_bitcoind(&cli).await;
let (
alice_state0,
bob_state0,
mut alice_node,
mut bob_node,
initial_balances,
swap_amounts,
Test on-chain protocol happy path
2020-10-21 23:57:42 +00:00
) = init_test(&monero, &bitcoind, None, None).await;
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
let (alice_state, bob_state) = future::try_join(
run_alice_until(
&mut alice_node,
alice_state0.into(),
Move test functions out of lib
2020-10-08 22:28:51 +00:00
harness::alice::is_state6,
&mut OsRng,
),
run_bob_until(
&mut bob_node,
bob_state0.into(),
harness::bob::is_state5,
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
&mut OsRng,
),
)
.await
.unwrap();
let alice_state6: alice::State6 = alice_state.try_into().unwrap();
let bob_state5: bob::State5 = bob_state.try_into().unwrap();
let alice_final_btc_balance = alice_node.bitcoin_wallet.balance().await.unwrap();
let bob_final_btc_balance = bob_node.bitcoin_wallet.balance().await.unwrap();
let lock_tx_bitcoin_fee = bob_node
.bitcoin_wallet
.transaction_fee(bob_state5.tx_lock_id())
.await
.unwrap();
Test on-chain protocol happy path
2020-10-21 23:57:42 +00:00
let alice_final_xmr_balance = alice_node.monero_wallet.get_balance().await.unwrap();
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
Simplify xmr-btc/tests Monero wallet - Make it the same for Alice and Bob. - Make it contain a wallet client instead of the `Monero` struct. Also: Remove `Container` from inside `Monero` struct. The caller of `new` can simply ensure that `Container` is not dropped to keep the container alive. This makes the `Monero` struct easier to work with, as it just holds the data necessary to create the different clients created during `init`, and does not have any lifetime restrictions.
2020-10-20 01:18:27 +00:00
monero.wait_for_bob_wallet_block_height().await.unwrap();
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
Test on-chain protocol happy path
2020-10-21 23:57:42 +00:00
let bob_final_xmr_balance = bob_node.monero_wallet.get_balance().await.unwrap();
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
Improve formatting of tests
2020-10-08 21:56:20 +00:00
assert_eq!(
alice_final_btc_balance,
initial_balances.alice_btc + swap_amounts.btc
- bitcoin::Amount::from_sat(bitcoin::TX_FEE)
);
assert_eq!(
bob_final_btc_balance,
initial_balances.bob_btc - swap_amounts.btc - lock_tx_bitcoin_fee
);
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
assert_eq!(
alice_final_xmr_balance,
Test on-chain protocol happy path
2020-10-21 23:57:42 +00:00
initial_balances.alice_xmr - swap_amounts.xmr - alice_state6.lock_xmr_fee()
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
);
assert_eq!(
bob_final_xmr_balance,
Test on-chain protocol happy path
2020-10-21 23:57:42 +00:00
initial_balances.bob_xmr + swap_amounts.xmr
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
);
}
#[tokio::test]
async fn both_refund() {
let _guard = tracing_subscriber::fmt()
.with_env_filter("info")
.set_default();
let cli = Cli::default();
Simplify xmr-btc/tests Monero wallet - Make it the same for Alice and Bob. - Make it contain a wallet client instead of the `Monero` struct. Also: Remove `Container` from inside `Monero` struct. The caller of `new` can simply ensure that `Container` is not dropped to keep the container alive. This makes the `Monero` struct easier to work with, as it just holds the data necessary to create the different clients created during `init`, and does not have any lifetime restrictions.
2020-10-20 01:18:27 +00:00
let (monero, _container) = Monero::new(&cli);
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
let bitcoind = init_bitcoind(&cli).await;
let (
alice_state0,
bob_state0,
mut alice_node,
mut bob_node,
initial_balances,
swap_amounts,
Test on-chain protocol happy path
2020-10-21 23:57:42 +00:00
) = init_test(&monero, &bitcoind, None, None).await;
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
let (alice_state, bob_state) = future::try_join(
run_alice_until(
&mut alice_node,
alice_state0.into(),
Move test functions out of lib
2020-10-08 22:28:51 +00:00
harness::alice::is_state5,
&mut OsRng,
),
run_bob_until(
&mut bob_node,
bob_state0.into(),
harness::bob::is_state3,
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
&mut OsRng,
),
)
.await
.unwrap();
let alice_state5: alice::State5 = alice_state.try_into().unwrap();
let bob_state3: bob::State3 = bob_state.try_into().unwrap();
bob_state3
.refund_btc(&bob_node.bitcoin_wallet)
.await
.unwrap();
alice_state5
.refund_xmr(&alice_node.bitcoin_wallet, &alice_node.monero_wallet)
.await
.unwrap();
let alice_final_btc_balance = alice_node.bitcoin_wallet.balance().await.unwrap();
let bob_final_btc_balance = bob_node.bitcoin_wallet.balance().await.unwrap();
// lock_tx_bitcoin_fee is determined by the wallet, it is not necessarily equal
// to TX_FEE
let lock_tx_bitcoin_fee = bob_node
.bitcoin_wallet
.transaction_fee(bob_state3.tx_lock_id())
.await
.unwrap();
Simplify xmr-btc/tests Monero wallet - Make it the same for Alice and Bob. - Make it contain a wallet client instead of the `Monero` struct. Also: Remove `Container` from inside `Monero` struct. The caller of `new` can simply ensure that `Container` is not dropped to keep the container alive. This makes the `Monero` struct easier to work with, as it just holds the data necessary to create the different clients created during `init`, and does not have any lifetime restrictions.
2020-10-20 01:18:27 +00:00
monero.wait_for_alice_wallet_block_height().await.unwrap();
Test on-chain protocol happy path
2020-10-21 23:57:42 +00:00
let alice_final_xmr_balance = alice_node.monero_wallet.get_balance().await.unwrap();
let bob_final_xmr_balance = bob_node.monero_wallet.get_balance().await.unwrap();
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
Improve formatting of tests
2020-10-08 21:56:20 +00:00
assert_eq!(alice_final_btc_balance, initial_balances.alice_btc);
assert_eq!(
bob_final_btc_balance,
// The 2 * TX_FEE corresponds to tx_refund and tx_cancel.
initial_balances.bob_btc - Amount::from_sat(2 * TX_FEE) - lock_tx_bitcoin_fee
);
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
// Because we create a new wallet when claiming Monero, we can only assert on
// this new wallet owning all of `xmr_amount` after refund
Test on-chain protocol happy path
2020-10-21 23:57:42 +00:00
assert_eq!(alice_final_xmr_balance, swap_amounts.xmr);
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
assert_eq!(bob_final_xmr_balance, initial_balances.bob_xmr);
}
#[tokio::test]
async fn alice_punishes() {
let _guard = tracing_subscriber::fmt()
.with_env_filter("info")
.set_default();
let cli = Cli::default();
Simplify xmr-btc/tests Monero wallet - Make it the same for Alice and Bob. - Make it contain a wallet client instead of the `Monero` struct. Also: Remove `Container` from inside `Monero` struct. The caller of `new` can simply ensure that `Container` is not dropped to keep the container alive. This makes the `Monero` struct easier to work with, as it just holds the data necessary to create the different clients created during `init`, and does not have any lifetime restrictions.
2020-10-20 01:18:27 +00:00
let (monero, _container) = Monero::new(&cli);
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
let bitcoind = init_bitcoind(&cli).await;
let (
alice_state0,
bob_state0,
mut alice_node,
mut bob_node,
initial_balances,
swap_amounts,
Test on-chain protocol happy path
2020-10-21 23:57:42 +00:00
) = init_test(&monero, &bitcoind, None, None).await;
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
let (alice_state, bob_state) = future::try_join(
run_alice_until(
&mut alice_node,
alice_state0.into(),
Move test functions out of lib
2020-10-08 22:28:51 +00:00
harness::alice::is_state4,
&mut OsRng,
),
run_bob_until(
&mut bob_node,
bob_state0.into(),
harness::bob::is_state3,
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
&mut OsRng,
),
)
.await
.unwrap();
let alice_state4: alice::State4 = alice_state.try_into().unwrap();
let bob_state3: bob::State3 = bob_state.try_into().unwrap();
alice_state4
.punish(&alice_node.bitcoin_wallet)
.await
.unwrap();
let alice_final_btc_balance = alice_node.bitcoin_wallet.balance().await.unwrap();
let bob_final_btc_balance = bob_node.bitcoin_wallet.balance().await.unwrap();
// lock_tx_bitcoin_fee is determined by the wallet, it is not necessarily equal
// to TX_FEE
let lock_tx_bitcoin_fee = bob_node
.bitcoin_wallet
.transaction_fee(bob_state3.tx_lock_id())
.await
.unwrap();
assert_eq!(
alice_final_btc_balance,
initial_balances.alice_btc + swap_amounts.btc - Amount::from_sat(2 * TX_FEE)
);
assert_eq!(
bob_final_btc_balance,
initial_balances.bob_btc - swap_amounts.btc - lock_tx_bitcoin_fee
);
}
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
#[tokio::test]
async fn recover_protocol_state_from_db() {
let _guard = tracing_subscriber::fmt()
.with_env_filter("info")
.set_default();
let cli = Cli::default();
Fix buld after merge of db branch
2020-10-21 21:28:51 +00:00
let (monero, _container) = Monero::new(&cli);
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
let bitcoind = init_bitcoind(&cli).await;
Improve database type safety The database is now bound to a type eg. alice::State or bob::State. The caller cannot expect to retrieve a type that is different to the type that was stored.
2020-10-22 02:34:01 +00:00
let alice_db: Database<alice::State> =
harness::storage::Database::open(Path::new(ALICE_TEST_DB_FOLDER)).unwrap();
let bob_db: Database<bob::State> =
harness::storage::Database::open(Path::new(BOB_TEST_DB_FOLDER)).unwrap();
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
let (
alice_state0,
bob_state0,
mut alice_node,
mut bob_node,
initial_balances,
swap_amounts,
Fix build after merge
2020-10-22 03:42:36 +00:00
) = init_test(&monero, &bitcoind, None, None).await;
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
{
let (alice_state, bob_state) = future::try_join(
run_alice_until(
&mut alice_node,
alice_state0.into(),
harness::alice::is_state5,
&mut OsRng,
),
run_bob_until(
&mut bob_node,
bob_state0.into(),
harness::bob::is_state3,
&mut OsRng,
),
)
.await
.unwrap();
// save state to db
Improve database type safety The database is now bound to a type eg. alice::State or bob::State. The caller cannot expect to retrieve a type that is different to the type that was stored.
2020-10-22 02:34:01 +00:00
alice_db.insert_latest_state(&alice_state).await.unwrap();
bob_db.insert_latest_state(&bob_state).await.unwrap();
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
};
let (alice_state6, bob_state5) = {
// recover state from db
Improve database type safety The database is now bound to a type eg. alice::State or bob::State. The caller cannot expect to retrieve a type that is different to the type that was stored.
2020-10-22 02:34:01 +00:00
let alice_state = alice_db.get_latest_state().unwrap();
let bob_state = bob_db.get_latest_state().unwrap();
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
let (alice_state, bob_state) = future::try_join(
run_alice_until(
&mut alice_node,
Improve database type safety The database is now bound to a type eg. alice::State or bob::State. The caller cannot expect to retrieve a type that is different to the type that was stored.
2020-10-22 02:34:01 +00:00
alice_state,
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
harness::alice::is_state6,
&mut OsRng,
),
run_bob_until(
&mut bob_node,
Improve database type safety The database is now bound to a type eg. alice::State or bob::State. The caller cannot expect to retrieve a type that is different to the type that was stored.
2020-10-22 02:34:01 +00:00
bob_state,
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
harness::bob::is_state5,
&mut OsRng,
),
)
.await
.unwrap();
let alice_state: alice::State6 = alice_state.try_into().unwrap();
let bob_state: bob::State5 = bob_state.try_into().unwrap();
(alice_state, bob_state)
};
let alice_final_btc_balance = alice_node.bitcoin_wallet.balance().await.unwrap();
let bob_final_btc_balance = bob_node.bitcoin_wallet.balance().await.unwrap();
let lock_tx_bitcoin_fee = bob_node
.bitcoin_wallet
.transaction_fee(bob_state5.tx_lock_id())
.await
.unwrap();
Fix buld after merge of db branch
2020-10-21 21:28:51 +00:00
let alice_final_xmr_balance = alice_node.monero_wallet.0.get_balance(0).await.unwrap();
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
Fix buld after merge of db branch
2020-10-21 21:28:51 +00:00
monero.wait_for_bob_wallet_block_height().await.unwrap();
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
Fix buld after merge of db branch
2020-10-21 21:28:51 +00:00
let bob_final_xmr_balance = bob_node.monero_wallet.0.get_balance(0).await.unwrap();
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
assert_eq!(
alice_final_btc_balance,
initial_balances.alice_btc + swap_amounts.btc
- bitcoin::Amount::from_sat(bitcoin::TX_FEE)
);
assert_eq!(
bob_final_btc_balance,
initial_balances.bob_btc - swap_amounts.btc - lock_tx_bitcoin_fee
);
assert_eq!(
alice_final_xmr_balance,
Fix build after merge
2020-10-22 03:42:36 +00:00
initial_balances.alice_xmr.as_piconero()
- swap_amounts.xmr.as_piconero()
- alice_state6.lock_xmr_fee().as_piconero()
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
);
assert_eq!(
bob_final_xmr_balance,
Fix build after merge
2020-10-22 03:42:36 +00:00
initial_balances.bob_xmr.as_piconero() + swap_amounts.xmr.as_piconero()
Save and recover protocol state from disk NOTE: This implementation saves secrets to disk! It is not secure. The storage API allows the caller to atomically record the state of the protocol. The user can retrieve this recorded state and re-commence the protocol from that point. The state is recorded using a hard coded key, causing it to overwrite the previously recorded state. This limitation means that this recovery mechanism should not be used in a program that simultaneously manages the execution of multiple swaps. An e2e test was added to show how to save, recover and resume protocol execution. This logic could also be integrated into the run_until functions to automate saving but was not included at this stage as protocol execution is currently under development. Serialisation and deserialisation was implemented on the states to allow the to be stored using the database. Currently the secret's are also being stored to disk but should be recovered from a seed or wallets.
2020-10-13 22:32:25 +00:00
);
}
Execute Alice and Bob state machines concurrently Previously we were testing the protocol by manually driving Alice and Bob's state machines. This logic has now be moved to an async state transition function that can take any possible state as input. The state transition function is called in a loop until it returns the desired state. This allows use to interrupt midway through the protocol and perform refund and punish tests. This design was chosen over a generator based implementation because the the generator based implementation results in a impure state transition function that is difficult to reason about and prone to bugs. Test related code was extracted into the tests folder. The 2b and 4b states were renamed to be consistent with the rest. Macros were used to reduce code duplication when converting child states to their parent states and vice versa. Todos were added were neccessary.
2020-09-29 05:36:50 +00:00
}
Reference in New Issue Copy Permalink