To see what happens in the network its sufficient to connect to any validator log stream, e.g. one you are deploying to. But any validator will do, as all of them receive blocks and replay content. So, let's listen for node0. To not overload output, better remove some noisy messages.

curl --no-buffer -s http://node0.testnet.rchain-dev.tk:8181/logs/name:rnode | grep -v "Must wait for more blocks from other validators\|Streamed packet\|Streaming packet\|Received request for block"

Validators propose sequentially round robin, starting from node0 and ending with node9. We need this because merging is not implemented yet in CA. Because of this it will took some time for particular validator to propose. You should see repeating messages "Seen X senders", which gives a hint, which validator proposed last. As we are looking into node0, the seq. number of node that is proposing at the moment = X+1. So to minimise waiting time, it's reasonable to deploy to validator X+2 or X+3 and observe replay results on a node you are listening to.

Test1. Pay for deploy with wallet that has enough REV, observe deploy execution and payer balance decreased.

Alice owns wallet with private key 4021c7b19e7442cd299b5d541761ab86af34fcb74f24f5cd44360838d19618b7 and address 11112KDmzrKHjGRv43JqL1H7NiuwViQVx99EwacQdsPKBEm7xZgyVk. She has some of REV in that wallet sent by a friend (around 10^6 nanoREV). Worth mentioning that balances are stored on chain in nanoREVs, so when checking the balance, the unit of amount printed is REV*10^-9.

1. Alice checks the wallet balance by deploying contract, that contains printing of wallet balance to stdout, to e.g. validator node0.testnet.rchain-dev.tk (choose validator that should propose soon to minimise waiting time).
   rnode --grpc-host node0.testnet.rchain-dev.tk deploy --phlo-limit 100000 --phlo-price 1 --private-key 4021c7b19e7442cd299b5d541761ab86af34fcb74f24f5cd44360838d19618b7 alice_checks_balance.rho

   alice_checks_balance.rho

   new 
     rl(`rho:registry:lookup`), stdout(`rho:io:stdout`), 
     revVaultCh, vaultCh, balanceCh, log
   in {
     rl!(`rho:rchain:revVault`, *revVaultCh) |
     for (@(_, revVault) <- revVaultCh) {
       match "11112KDmzrKHjGRv43JqL1H7NiuwViQVx99EwacQdsPKBEm7xZgyVk" {
         revAddress => {
           @revVault!("findOrCreate", revAddress, *vaultCh) |
           for (@(true, vault) <- vaultCh) {
             @vault!("balance", *balanceCh) |
             for (@balance <- balanceCh) {
               log!("Balance of " ++ revAddress ++ " is ${balance}."%%{"balance":balance})
             }
           }
         }
       }
     } |
   
     contract log(@data) = {
       stdout!("COST ACCOUNTING TEST: Alice deploys. " ++ data)
     }
   }

2. When validator proposes block, it sends it to all peers including validator that logs you are listening to. During replay it will print Alice's wallet balance. Observe that number.
3. Deploy check balance contract several times to subsequent validators (e.g. node2, node3, node4, one deploy per validator), observe that Alice's balance is decreasing when node you are listening to replays new blocks. 

4. Alice's friend, Bob, who has no REVs and even do not have a wallet, ask her to create wallet for him with address 1111iNXW2k2S3S5bWL3W8w87itK1ky3y1ywySFBt9DkfPiZYo3KNU, so Alice deploys

   alice_creates_wallet.rho

   new 
     rl(`rho:registry:lookup`), stdout(`rho:io:stdout`), 
     revVaultCh, vaultCh, balanceCh, log
   in {
     rl!(`rho:rchain:revVault`, *revVaultCh) |
     for (@(_, revVault) <- revVaultCh) {
       match "1111iNXW2k2S3S5bWL3W8w87itK1ky3y1ywySFBt9DkfPiZYo3KNU" {
         revAddress => {
           @revVault!("findOrCreate", revAddress, *vaultCh) |
           for (@(true, vault) <- vaultCh) {
             @vault!("balance", *balanceCh) |
             for (@balance <- balanceCh) {
               log!("Wallet " ++ revAddress ++ " created. Balance is ${balance}."%%{"balance":balance})
             }
           }
         }
       }
     } |
   
     contract log(@data) = {
       stdout!("COST ACCOUNTING TEST: Alice creates wallet for Bob. " ++ data)
     }
   }

   You should observe in logs, that wallet with zero balance is created.

Test2. Pay for deploy with wallet with not enough REV, observe execution not happening and payer balance untouched.

Bob now owns wallet with private key 29f65cfc9a513d5b3ec542be590b9756fad3da173e6af3714cfe600595f812c8 and address 1111iNXW2k2S3S5bWL3W8w87itK1ky3y1ywySFBt9DkfPiZYo3KNU. He has 0 REV in that wallet.

1. Bob forgot that each deploy submitted to the network should be paid for or won't be executed, so he tries to run the same contract as Alice did. He deploys contract to validator node0.testnet.rchain-dev.tk and wait for validator to propose a new block expecting to see balance of his wallet as a visible sign of deploy execution.

   rnode --grpc-host node0.testnet.rchain-dev.tk deploy --phlo-limit 100000 --phlo-price 1 --private-key 4021c7b19e7442cd299b5d541761ab86af34fcb74f24f5cd44360838d19618b7 bob_checks_balance.rho

   bob_checks_balance.rho

   new 
     rl(`rho:registry:lookup`), stdout(`rho:io:stdout`), 
     revVaultCh, vaultCh, balanceCh, log
   in {
     rl!(`rho:rchain:revVault`, *revVaultCh) |
     for (@(_, revVault) <- revVaultCh) {
       match "1111iNXW2k2S3S5bWL3W8w87itK1ky3y1ywySFBt9DkfPiZYo3KNU" {
         revAddress => {
           @revVault!("findOrCreate", revAddress, *vaultCh) |
           for (@(true, vault) <- vaultCh) {
             @vault!("balance", *balanceCh) |
             for (@balance <- balanceCh) {
               log!("Balance of " ++ revAddress ++ " is ${balance}."%%{"balance":balance})
             }
           }
         }
       }
     } |
   
     contract log(@data) = {
       stdout!("COST ACCOUNTING TEST: Bob deploys. " ++ data)
     }
   }

2. Now you have to listen to proposing validators, as peers wont get this deploy at all.
   curl --no-buffer -s http://node0.testnet.rchain-dev.tk:8181/logs/name:rnode | grep -v "Must wait for more blocks from other validators\|Streamed packet\|Streaming packet\|Received request for block"
   When validator proposes block, so executes deploy - observe "Insufficient funds" message. Next repeat this test again but listen to another validator to observe that there are no signs of deploy execution there.