Lifecycle of a Payment
In Mina, payments pass through several steps before they are considered verified and complete.
This document walks through what happens to a single payment in a simplified overview to help you understand how Mina payments work. It it not a comprehensive technical overview, but instead a simplified walkthrough for users.
Gossip Protocol
Mina uses a gossip protocol to ensure that messages can be reliably transmitted to all other members of the network in a timely manner.
Payments
A payment is a type of transaction, requesting to transfer value from one account to another account, and the associated fee the sender is willing to pay for the payment to go through.
This scenario walks through a scenario where a sender, Bob, wants to send some MINA to a receiver, Alice.
Step 1: To create a payment, Bob clicks send
Any member of the network can create a payment and share it with the Mina network. The payment is cryptographically signed with a private key so that the sender's account can be verified. The payment is then sent out to peers on the network to be processed. The payment, when received by a peer, exists in their local transaction pool, which is an in-memory store of all the transactions that peer has heard on the network.
Step 2: To produce a block, Bob's payment gets put in a todo list
A block producer node is chosen on the network for a given time slot. The currently active producer choses in-flight payments based on payment fees and places them in a list to be processed called a transition block. Block producers earn mina for building these blocks. The producer generates a SNARK defining the structure of the transition block as compared to the previous block (but not yet verifying these new payments). The producer transmits this new information for SNARK workers to process.
Step 3: To prove a SNARK transaction, Bob's payment gets SNARK-signed
SNARK worker nodes on the network begin performing SNARK calculations on each step of the new transition block. These are individual proofs of each payment and then merge proofs of neighboring payments. Eventually, all the payments are verified. SNARK workers can earn currency by generating these proofs, paid for by block producers from their block rewards. These proofs are transmitted out over the network.
Step 4: To verify a payment, Alice and Bob's accounts show the result of the transfer
After the whole block has been proven, the block producer sends out a confirmation of the transition block. Then member nodes on the network apply the changes to their local account balances to reflect these changes.
Step 5: To achieve a payment confidence level, Alice is confident the transfer is complete
With each subsequent block, a recipient has a higher degree of confidence that the payment is actually complete and that the network has consensus about that block. However, like in most blockchains, payments are said to be confirmed after a certain number of blocks, also known as transaction finality.
In the Bitcoin network, a transaction is confirmed after 6 blocks (60 mins) with an assumption that an attacker is unlikely to amass more than 10% of the hashrate.
With a slot duration of 3 mins and assuming 90% honest stake, the following table shows the finality in blocks, the average time it takes to produce the corresponding number of blocks, and the confidence that payment will be confirmed.
| Finality (in blocks) | Average time for finality | Finality confidence (%) |
|---|---|---|
| 8 | 33 mins | 98.6709 |
| 15 | 60 mins | 99.9231 |
| 23 | 1hr 32mins | 99.9965 |
| 30 | 2hrs | 99.9998 |
| 38 | 2hrs 32mins | 100 |
Average time is calculated based on consensus constants that determine the number of slots filled per epoch. This is currently set to 75%.
The recommended wait time for a transaction to be confirmed is 15 blocks which provides a 99.9% confidence that the transaction will not be reversed.
Failure Scenarios
Payments can fail for several reasons.
Transaction is not accepted by the network
Several reasons why a transaction shared with peer nodes might not get accepted:
- The transaction is not fundamentally valid. For example, the sender's account doesn't exist, the account doesn't have sufficient funds, the signature doesn't match with the account, or the nonce in the transaction was not incremented.
- There could be adversarial nodes in the network that collude to deny service to specific senders in the network. However, this behavior is highly disincentivized and one honest node is enough to prevent this issue.
Transaction is not included in a block
If a transaction is valid and the network is honest, then in all likelihood, a transaction will make it into a block. However, there is one case where a transaction can be dumped from a transaction pool:
- If the transaction pool hits its capacity, or
max_txpool_size, then it evicts the transaction with the lowest fee in the pool, causing it to be dumped from memory. If this happens, the sender needs to resend the transaction with a higher fee, according to market dynamics at the time.