Stratum v2 rappresenta un'evoluzione significativa nel protocollo di comunicazione per il mining di Bitcoin in pool, progettato per superare le limitazioni della sua precedente versione, Stratum v1 . Questo nuovo protocollo funge da ponte di comunicazione tra i minatori e le mining pool, con l'obiettivo primario di migliorare la sicurezza, l'efficienza e, soprattutto, la decentralizzazione del processo di mining . Tra i miglioramenti chiave introdotti da Stratum v2 spiccano una maggiore sicurezza attraverso la crittografia delle comunicazioni, una maggiore efficienza grazie alla trasmissione di dati in formato binario, e una più ampia autonomia per i minatori nella selezione delle transazioni da includere nei blocchi . L'intento è quello di rendere il mining in pool più simile al mining solitario per quanto riguarda il controllo sui set di transazioni . Per raggiungere questi obiettivi, Stratum v2 introduce diverse nuove sub-protocolli . L'evoluzione da Stratum v1 a v2 riflette una crescente necessità di un ecosistema di mining più sicuro, efficiente e decentralizzato. L'introduzione della selezione delle transazioni controllata dai minatori rappresenta un cambio di paradigma fondamentale, spostando il potere decisionale precedentemente centralizzato nelle mani delle pool verso i singoli partecipanti .  

Nel contesto di Stratum v2, il termine "job" si riferisce a un'unità di lavoro assegnata ai minatori, contenente tutte le informazioni necessarie per eseguire l'hashing su un'intestazione di blocco candidata . Le mining pool distribuiscono questi "mining job" ai singoli minatori, indipendentemente dalle loro capacità hardware . Stratum v2 definisce principalmente due tipi di job: lo Standard Job e l'Extended Job . Gli Standard Job sono destinati all'header-only mining (HOM) con Merkle Root fissi, mentre gli Extended Job consentono Merkle Root variabili . Con l'introduzione del Job Declaration Protocol, sono stati introdotti anche i Custom Job, che permettono ai minatori di scegliere i propri set di transazioni . Il concetto di "job" ha quindi subito un'evoluzione in Stratum v2 per accogliere una maggiore autonomia da parte dei minatori riguardo al contenuto dei blocchi su cui lavorano, superando il modello di Stratum v1 incentrato sulle pool . In Stratum v1, i job erano interamente decisi dalla pool. L'introduzione dei "Custom Job" in Stratum v2, e i meccanismi per proporli e dichiararli, indicano un passaggio verso un processo di mining più collaborativo e meno gerarchico.  

Il Job Negotiator è un componente cruciale di Stratum v2 che consente ai minatori di influenzare i set di transazioni inclusi nei blocchi che minano . Questa funzionalità innovativa permette ai minatori di costruire i propri template di blocco e di proporli alla pool per l'approvazione . Questo processo è parte del Job Negotiation Protocol . Il Job Negotiator opera come un sub-protocollo responsabile della distribuzione dei template dei minatori alla pool . In sostanza, i minatori possono negoziare con una pool un template di blocco, incluso il set di transazioni . Questa capacità rappresenta un cambiamento fondamentale nelle dinamiche di potere del mining in pool, offrendo ai minatori un maggiore controllo sull'inclusione delle transazioni e migliorando la resistenza alla censura .  

L'interazione tra il minatore e la pool attraverso il Job Negotiator prevede uno scambio di messaggi strutturato. Sebbene non esista un "Job Negotiator Protocol" formalmente definito nella documentazione, si possono identificare i messaggi chiave coinvolti. Il minatore, attraverso il suo Job Negotiator, richiede innanzitutto un token per poter proporre un lavoro, utilizzando il messaggio AllocateMiningJobToken . La pool risponde con un AllocateMiningJobToken.Success, fornendo il token necessario per le successive fasi della negoziazione . Questo scambio iniziale indica un processo gestito per autorizzare i minatori a partecipare alla negoziazione dei job, prevenendo invii incontrollati. Una volta ottenuto il token, il minatore, spesso in coordinamento con un Template Provider (che può essere un nodo Bitcoin locale), costruisce un template di blocco con le transazioni desiderate. Il Template Provider, come un nodo Bitcoin locale gestito dal minatore, fornisce i dati delle transazioni, che il Job Negotiator utilizza poi per costruire la proposta di job per la pool . Questa proposta viene inviata alla pool tramite il messaggio CommitMiningJob . Nella sua attuale implementazione di riferimento (SRI), la pool è tenuta a rispondere con un messaggio CommitMiningJob.Success, accettando la proposta del minatore . Questo impone alla pool di accettare le transazioni suggerite dal minatore, sottolineando l'enfasi sull'autonomia del minatore nella fase iniziale di implementazione di questa funzionalità. Tuttavia, sono previsti aggiornamenti futuri che includeranno meccanismi di fallback per i minatori nel caso in cui la pool dovesse rifiutare le loro proposte . Questo permetterà ai minatori di passare a un'altra pool o di minare in solitario se le loro selezioni di transazioni venissero costantemente rifiutate, rafforzando ulteriormente la resistenza alla censura. L'intero flusso di interazione, descritto come la "JN dance", evidenzia la connessione iniziale, la richiesta e l'allocazione del token, la consegna del template dal Template Provider, la proposta del job e la sua accettazione .  

Il Job Declarator è un altro ruolo fondamentale in Stratum v2, coinvolto nella dichiarazione di template di blocco personalizzati dai minatori alla pool . Opera all'interno del Job Declaration Protocol . L'obiettivo principale del Job Declarator è impedire che le pool impongano unilateralmente il lavoro ai minatori . Questo protocollo prevede due ruoli distinti: il Job Declarator Client (JDC) lato minatore e il Job Declarator Server (JDS) lato pool . Il JDC riceve i template dal Template Provider e dichiara i job personalizzati al JDS . Il JDS, a sua volta, alloca token al JDC per la dichiarazione di job personalizzati e ne riconosce l'avvenuta dichiarazione .  

Il Job Declaration Protocol prevede una serie di messaggi ben definiti per coordinare la creazione di lavoro personalizzato . Il JDC inizia richiedendo un identificatore per un futuro job di mining al JDS tramite il messaggio AllocateMiningJobToken . Il JDS risponde con successo con AllocateMiningJobToken.Success, fornendo un token che autorizza il client a dichiarare un job di mining . Successivamente, il JDC propone un set selezionato di transazioni al JDS per la creazione di un lavoro personalizzato attraverso il messaggio DeclareMiningJob . Il JDS riconosce l'avvenuta dichiarazione con DeclareMiningJob.Success o segnala un rifiuto con DeclareMiningJob.Error . In caso di collisioni negli ID brevi delle transazioni o se il JDS non riesce a ricostruire l'hash della lista completa delle transazioni, invia un messaggio IdentifyTransactions al JDC, che risponde con IdentifyTransactions.Success fornendo gli hash completi delle transazioni . Se il JDS rileva transazioni mancanti nel messaggio DeclareMiningJob, richiede i dati completi tramite ProvideMissingTransactions, a cui il JDC risponde con ProvideMissingTransactions.Success inviando le transazioni richieste . Infine, una volta trovato un blocco valido, il JDC lo invia al JDS tramite il messaggio SubmitSolution . Questo flusso di messaggi indica un processo strutturato che garantisce la coerenza tra il template proposto dal minatore e la visione della pool, in particolare riguardo al mempool delle transazioni. Il JDC ha anche la responsabilità di implementare strategie di fallback, come il passaggio ad altre pool o il mining solitario, nel caso in cui il JDS rifiuti le dichiarazioni di job o le share, incentivando l'onestà da parte della pool . Questa separazione del Job Declaration Protocol dal Mining Protocol principale permette alle pool di gestire le connessioni di dichiarazione in modo indipendente dalle connessioni di mining (invio di share), migliorando la robustezza e l'efficienza del sistema complessivo .  

Nelle prime versioni di Stratum V2, il "Job Negotiator" era un sottoprotocollo che permetteva ai miner di negoziare con i pool la selezione delle transazioni da includere nel blocco. Il termine "Negotiator" è stato sostituito con "Declarator" per sottolineare che i miner dichiarano unilateralmente i propri template, senza una negoziazione bidirezionale. La modifica rispondeva a feedback della community per chiarire il funzionamento unidirezionale.