Agregação de Requisições para Grandes Fazendas

Configure agregação para atender milhares de mineradores com apenas algumas conexões.

Connection aggregation means many miners share a small number of upstream pool connections. It is not "merge every miner into one difficulty". Each miner must keep its own vardiff, or the pool marks machines offline.

When it is allowed

The current product rule, written in the repository docs and meant to replace the older shared-session design, allows aggregation only when all of these are true:

The pool URL is stratum2+tcp:// (Stratum V2).
The pool has authority_pubkey set, for Noise authentication.
The port mapping has agg_enabled = true.

A Stratum V1 pool, including the usual BTC/LTC JSON stratum, must stay 1:1. The API should return 400 if you enable aggregation there. If a client still receives an illegal mapping, it is supposed to ignore aggregation and forward 1:1.

The docs are explicit that the client crate still contains the older V1 shared-session aggregator, and that the new SV2 behavior is the one to follow. Do not plan a V1 farm around "1,000 miners, 2 connections". That model raises one shared difficulty and the pool then treats most workers as down.

If you do have an SV2 pool

json

{
  "listen_port": 3333,
  "pool_id": 1,
  "protocol": "tcp",
  "enabled": true,
  "agg_enabled": true,
  "miners_per_conn": 64
}

miners_per_conn is the channel cap on one upstream SV2 connection, suggested range 64–128. It is not the old "500 miners on one V1 session" knob. agg_protocol is kept for compatibility; miner V1 vs V2 is detected from the first packet, not from that field.

Each miner is its own Standard Channel with its own SetTarget. The saving is connection count and handshakes, not a single shared job.

← Entendendo a Arquitetura de Túnel em Três Camadas Setup Multi-Moeda: Melhores Práticas de Mapeamento de Porta →