🚅Speed Force Value Transactions

This page explains how Speed Force tokens are sent and received in the Speed Force network with references to more detailed content.

Simple Example

To explain how Speed Force tokens are transferred from one address to another, this topic follows three characters: Alice, Bob, and Charlie.

The Goal

Charlie wants to transfer 10 $SF to Bob.

Choosing Where to Attach Messages

To transfer 10 SF to Bob, Charlie must attach a value block to the Tangle. For that, he needs between one and eight tip blocks that he can attach to his block.

To get these tip blocks, Charlie requests them from a node.

The node selects these blocks by using an algorithm called Uniform Random Tip Selection URTS. This algorithm selects between one and eight valid tips that lead to a valid ledger state.

• The ledger state is a record of all blocks of value that have Speed Force tokens transferred in the Tangle, including the state of all balances on addresses. This state must always be balanced: the total number of Speed Force tokens must always be added to the total supply.

SEND DATA

The Stardust protocol allows you to attach metadata to any transaction.

Signing the Messages

Charlie signs an input block with his private key to prove to the nodes that he is indeed the owner of the Speed Force tokens in his address. This input block takes 10 SMRs from his address.

Charlie then creates an output block depositing 10 SF into Bob's address. This block does not require a signature as it does not withdraw Speed Force tokens.

Charlie then puts all the blocks into a transmitter and sends them to a node on the Speed Force network.

Waiting for the Messages to be Confirmed

Anyone is free to send blocks to nodes at any time. Therefore, selecting an effective tip block is not always a simple matter. Milestones, however, determine which blocks to include and confirm based on deterministic ordering.

For example, what if Charlie actually appended two blocks to the Tangle: one to transfer 10 SF to Bob, and the other to transfer 10 SF to Alice? Together, these blocks are known as double spends because they attempt to transfer the same Speed Force tokens to different addresses.

Messages in the Tangle are confirmed by special blocks called milestones. Milestones are issued by a special node called the Coordinator, which is run by the Speed Force Foundation and thus remains a centralized part of the consensus.

After Charlie's block is confirmed by the milestone, the node updates his and Bob's balances to reflect the transfer of 10 SMR to Bob's address. Bob can now spend his new Shimmer tokens.

We can observe individual steps taken by participants in more detail.

Clients

Everything starts with the customer. A client is the software that initiates and creates Speed Force transactions for a user (whether human, machine, or device). Most user clients will come in the form of wallet software such as Firefly Wallet.

There are also simple command-line tools for professional users, such as a CLI wallet.

Machines, sensors, devices, etc. will use the code of the Speed Force wallet library to autonomously create and execute transactions.

To send a value transaction to the Speed Force network, a client creates a Speed Force block containing the signed transaction payload. In this payload, all data is specified to tell the Speed Force network how many tokens from address A (owned by the block's issuer) should be transferred to address B, and the state of the Shimmer Ledger can be upgraded accordingly.

Signed transaction payloads must contain a digital signature to guarantee that the sender of the transaction is the current owner of the address where those funds are stored. This is guaranteed by signing the transaction with that address' private key. The public key is also part of the block and is used to verify the ownership of the funds.

The next step is for the client to connect to a node in the Speed Force network and ask that node to provide a valid hint for inclusion in a block. After the hints (between the first one and eight blocks of the Tangle) are known to the client, they can be included in a block and create a reference path within the Tangle for that block. Finally, the client submits the block containing the transaction payload to the node for verification and processing.

Nodes

Nodes are the bookkeepers, decision makers and validators of all information in the Speed Force network. Every node in the Speed Force network knows the exact state and value of all existing addresses in the Speed Force network at any given time. This is called the ledger state.

Nodes are also the entry points for clients into the network. Clients submit blocks to nodes through designated ports in the node. The node collects all incoming traffic for that ingress port in its inbox and first checks that the block is well-formed and can be processed.

If all bits of the block are readable to the node and the node detects the signed transaction payload contained in the block, the verification process begins.

First, nodes verify that the address trying to send these funds has the required balance. So it checks what it currently knows about the address (ledger state) to see if it has enough funds. It also checks that the transaction is semantically correct, taking into account the constraints defined in the funds to be spent. The node also checks the network for known conflicts that would make it possible to spend more funds than are currently sitting on the address (in other words, double spending). So if another block currently exists and the node is known to want to spend the same funds at that address, a conflict will be detected and both blocks will be processed as conflict resolution; you will read about this process later More information.

If no conflicts are detected, the next step for the node is to submit the requested ledger state update: "Delete amount x from address A and add these amounts to address B". Committing takes place through the so-called gossip protocol.

The node sends its updated ledger state to all its directly connected neighbors. Each node is connected to several other nodes. These nodes receive updated ledger states from their neighbors. Each node compares the request to its currently known version of the ledger and checks again for conflicts. If no conflicts are found, the node updates its ledger state and sends the updated state to its neighbors again.

This causes the ledger update to propagate rapidly through the network, and within seconds, it has reached every node in the network and is therefore accepted and confirmed. At this stage, the block has reached full confirmation and is considered reliable. It will now be added to each node's tip pool and can be used as a reference for new blocks.