Torrenting for Syncing and Block Discovery

When people hear the word "torrent," they usually think about downloading movies, software, or other large files from the internet - often in the context of digital pirating.

However pirating is not the only use of torrent based technology. Contractless uses the same basic idea for something very different.

Instead of downloading an entire block from one node the way most blockchains do, Contractless divides that block into smaller pieces. Those pieces can then be downloaded from several connected nodes at the same time.

This makes torrenting an important part of two different processes:

• Syncing a new or outdated node
• Distributing newly discovered blocks across the network

As blocks become larger and contain more transactions, this process becomes increasingly valuable.

🧩 What Is a Contractless Torrent?

Every Contractless block is stored as a complete block file.

After that block is created, Contractless divides its data into smaller pieces. It then creates a small torrent file containing the information needed to locate, rebuild, and verify that block.

The torrent file includes information such as:

• The total block size
• The size of each piece
• A hash for every individual piece
• A hash of the complete block data
• The block header hash
• The previous block hash
• The block difficulty
• The block timestamp
• The wallet address of the miner

The torrent does not contain the complete block.

Instead, it acts as a map showing nodes how the block must be reconstructed and what every piece should look like.

This is a custom torrenting system built directly into Contractless. It does not depend on or work with public BitTorrent trackers or outside torrenting software and services.

🌐 How a Torrenting Pool Is Created

A Contractless torrenting pool is made from the miner nodes that are already connected to a given node.

This includes both:

• Incoming node connections
• Outgoing node connections

There is no special group of torrenting servers.

There is also no central server responsible for distributing every block.

The same nodes that validate transactions, mine blocks, and maintain the network can also provide block pieces to one another.

For example, imagine Node A is connected to Node B, Node C, and Node D.

When Node A needs a block, it can request:

• Piece 1 from Node B
• Piece 2 from Node C
• Piece 3 from Node D

These requests can happen at the same time.

Each connected peer handles one active piece at a time. This spreads the work across the available connections instead of overwhelming one node and being limited to its connection speeds.

If one peer is slow or cannot provide a piece, that piece can be requested from another connected peer.

🔄 How a New Node Syncs

When a new node starts, it first connects to another Contractless node and completes the normal startup process.

Before syncing begins, it checks whether its genesis block is compatible with the network. A node with no genesis block can begin syncing, while a node using a different genesis block must be rejected.

The new node then compares its local block height with the height of the remote node.
If blocks are missing, it begins requesting torrent information for those block heights.

The basic process looks like this:

1. Request the torrent for a missing block.
2. Read the torrent to learn how many pieces are required to obtain the full block.
3. Build a pool from available incoming and outgoing node connections.
4. Request different pieces from those connected nodes.
5. Verify each piece as it arrives.
6. Reassemble the pieces in their correct positions.
7. Verify the completed block.
8. Save the block locally.
9. Continue with the next block.

Contractless can prepare downloads for multiple upcoming blocks while it works.

However, blocks are still validated and saved in their correct order. Block 500 cannot be permanently accepted before block 499 because its balances, difficulty, parent, and other rules depend on the chain state created before it.

This creates a balance between speed and safety.

The network can download ahead, but it does not blindly save blocks out of order.

⚡ Why Pieces Improve Syncing Speed

Without torrenting, a new node would normally download each complete block from a single remote node.

That creates a bottleneck.

The syncing speed becomes limited by:

• That node’s upload speed
• The quality of one connection
• The amount of traffic that node is already handling
• The distance between the two nodes
• Whether that node temporarily becomes slow or unavailable

Torrenting distributes that work.

If ten peers have the same block, the syncing node does not need to depend entirely on one of them. It can collect pieces from several peers at once.

This becomes more useful as blocks grow.

Downloading a very small block from one node may already be fast. The advantage becomes more noticeable when blocks contain more transactions and more data.

Instead of one node serving the entire block to everyone, many nodes can share the work of distributing it.

📡 How Newly Discovered Blocks Propagate

Torrenting is not only used when a node is thousands of blocks behind.

It is also used for normal block discovery.

When a miner discovers a new block, it saves the complete block and creates its torrent metadata.

The torrent is then announced to connected miner nodes.

Because the torrent is much smaller than the full block, the announcement can move through the network quickly.

Each receiving node can then use its own connection pool to request the pieces it needs.

This means a newly discovered block does not have to travel through the network as one large message repeatedly sent from node to node.

The torrent metadata travels first.

The block pieces are then collected from the available nodes that have them.

As more nodes receive and save the block, more nodes become available to serve its pieces. Distribution capacity can therefore grow while the block is moving through the network.

🔐 How Piece Hashes Protect the Block

Every block piece has its own cryptographic hash.

A hash can be thought of as a fingerprint created from the exact bytes inside that piece.
If even one byte changes, the resulting hash changes.

When a node receives a piece, it calculates the hash of the data it received and compares it with the expected hash in the torrent.

If the hashes match, the piece can be retained.

If they do not match, the piece is rejected and another node can be asked for it.

This prevents a dishonest or damaged peer from silently inserting incorrect data into one section of a block.

A bad piece cannot simply be combined with the valid pieces and accepted.

🧱 Verifying the Complete Block

Individual piece hashes are only the first layer of verification.

After every piece has been received, Contractless combins them in their numbered order.

The node then verifies that:

• Every required piece exists
• The completed data has the expected length
• Every piece appeared in the correct position
• The complete block matches the torrent’s full-data hash
• The reconstructed block header matches the advertised block header hash
• The previous block hash matches
• The block itself passes Contractless validation

This distinction is important.

The torrent does not replace block validation.

Torrenting proves that the pieces fit together to recreate the exact block described by the torrent. The normal validation process then determines whether that block follows the rules of the blockchain.

Both parts must succeed before the block is accepted.

🛡️ Why Reordering Pieces Does Not Work

A dishonest node cannot take valid pieces and rearrange them to create a different valid block.

Each piece is assigned a specific number.

The torrent records those piece numbers in order, and the completed block must produce the expected full-data hash.

Changing the order changes the completed bytes.

That changes the final hash.

The reconstructed block would therefore fail verification.

The same is true if someone attempts to:

• Remove a piece
• Duplicate a piece
• Replace a piece
• Shorten the data
• Add extra data
• Change a transaction inside a piece

Any of those changes prevents the completed block from matching its expected cryptographic fingerprint.

🚧 What Happens When a Peer Fails?

Internet connections are not perfect.

A peer may disconnect, time out, return an error, or send a piece that does not match its expected hash.

Contractless does not need to discard the entire block download when that happens.

The failed piece can return to the download pool and be requested from another connected node.

Pieces that were already downloaded and verified do not need to be downloaded again simply because another peer failed.

This is another major advantage over relying on one source for an entire block.

A single failed peer does not necessarily mean starting the complete download over.

📈 Why Torrenting Matters as Contractless Grows

Torrenting may look like a more complex way to distribute blocks, but it solves a problem that becomes more important as a blockchain grows.

Small blocks are easy to move.

Large blocks containing many transactions require more bandwidth, more time, and more work from the node serving them.

A traditional one-node-to-one-node download places the full burden on one connection.

Contractless instead allows the network to share that burden.

As more nodes hold a block, more sources can provide its pieces.

This gives Contractless several advantages:

• Faster block propagation
• Faster synchronization
• Less dependence on one peer
• Better use of available network bandwidth
• Immediate detection of damaged pieces
• Easier recovery from failed downloads
• Better scaling as block data grows

The torrenting process does not make large blocks free. Every byte still has to move across the network.

What it changes is how efficiently that work can be distributed.

⚖️ Speed Without Removing Validation

Blockchain speed should not come from skipping the rules that make a blockchain reliable.

Contractless uses torrenting to improve how data moves without treating that data as trusted.

Pieces are checked individually.

The completed data is checked again.

The reconstructed block header is checked.

The transactions and block rules are still validated before the block is saved.

Torrenting makes the delivery process faster and more resilient. It does not give peers permission to decide what the blockchain should accept.

🖥️ Every Node Strengthens the Torrenting Network

Every additional Contractless node adds another potential source for block pieces.

That means running a testnet node does more than add another miner.

It can help:

• Distribute newly discovered blocks
• Provide historical blocks to syncing nodes
• Reduce dependence on individual peers
• Test torrenting under real internet conditions
• Expose connection and propagation problems before mainnet

Contractless is currently operating as a public testnet.

Anyone with a Windows or Linux computer, cloud server, or VPS can participate with a public IP address and an open port.

The more independent nodes that join, the more accurately the torrenting system can be tested under the conditions a real blockchain must survive.

📚 Learn More About Contractless

Extensive documentation for the Contractless blockchain is available at contractless.dev/contractless/Contractless. The source code and precompiled testnet binaries can also be found there.

Documentation can explain how a blockchain is designed, but running a node is one of the best ways to understand how it operates in practice.

Contractless is currently running as a public testnet. Anyone interested is encouraged to set up a node, observe the network firsthand, and help test its operation under real-world conditions.