﻿---
title: "Canali di stato"
description: "I canali di stato consentono a partecipanti fissi di scambiare stati firmati off-chain mantenendo una via on-chain per imporre l’ultimo risultato valido."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Canali di stato

> Solo a scopo educativo; non è consulenza finanziaria o di sicurezza. I fondi possono andare persi se chiavi, stato corrente, monitoraggio o capacità di rispondere on-chain non sono disponibili.

<a id="answer"></a>

## Risposta diretta

Un canale di stato è un protocollo in cui partecipanti fissi bloccano asset o stabiliscono regole eseguibili su blockchain, poi scambiano aggiornamenti autenticati off-chain. La blockchain non elabora ogni aggiornamento: arbitra in via definitiva alla chiusura o in caso di disaccordo.

Ogni aggiornamento accettato vincola canale, stato o allocazione dell’applicazione e un valore crescente, come turno o nonce. Il nuovo stato valido prevale sul vecchio secondo le regole. Un canale di pagamento segue soprattutto saldi; uno generale può rappresentare anche mosse, scambi o altri dati deterministici.

I vantaggi includono bassa latenza, una certa riservatezza dalla cronologia pubblica e nessuna commissione di base per aggiornamento ordinario. Tuttavia partecipanti e capitale sono in genere fissi, tutti devono conservare le prove e la catena base deve restare disponibile ed economicamente accessibile durante una disputa.

<a id="mechanism"></a>

## Come funziona

1. **Apertura e finanziamento.** Le parti concordano identità, regole, durata della contestazione e allocazione iniziale. Bloccano fondi in un arbitro on-chain o derivano il canale da uno finanziato; quei fondi non sono saldo ordinario spendibile.
2. **Scambio degli stati firmati.** Calcolano lo stato valido successivo e scambiano firme o messaggi necessari. Identificatore unico e ordine crescente impediscono di sostituire firme di altri canali o turni precedenti.
3. **Conservazione del pacchetto esecutivo.** Wallet o nodo salva ultimo stato, firme, trasferimenti condizionati e dati di revoca o segreti richiesti. Una seed phrase può recuperare le chiavi, non necessariamente questi dati mutevoli.
4. **Prosecuzione off-chain.** Molti aggiornamenti non richiedono transazioni base. La capacità limita l’invio all’allocazione e alle riserve in quella direzione; percorsi multicanale aggiungono dipendenze di liquidità e operatività a ogni passaggio.
5. **Chiusura cooperativa.** Le parti firmano l’esito finale e inviano la transazione minima. Di norma evitano così una gara di contestazione e regolano prima o a minor costo rispetto alla chiusura unilaterale.
6. **Disputa on-chain.** Se qualcuno scompare o propone uno stato obsoleto, un’altra parte presenta prove eseguibili. L’arbitro applica ordine, scadenze e transizioni. Alcuni sistemi sfidano il vecchio stato col nuovo; quelli tipo Lightning usano commitment e revoche, non una gara generica al nonce massimo.
7. **Finalizzazione dopo i termini.** Scaduto il periodo o timelock, si reclama l’esito. Fino alla risoluzione di ogni output può servire monitorare riorganizzazioni e aumentare le commissioni urgenti.

<a id="example"></a>

## Esempio

Alice e Bob aprono un canale bilaterale con `5 ETH` ciascuno, per `10 ETH`. Lo stato iniziale firmato è il turno `0`: Alice riceve `5 ETH` e Bob riceve `5 ETH` al regolamento.

Alice paga Bob `1 ETH`. Validano e firmano il turno `1`, con `4 ETH` ad Alice e `6 ETH` a Bob. Poi Bob paga Alice `2 ETH`; il turno `2` assegna `6 ETH` ad Alice e `4 ETH` a Bob. In cooperazione, solo finanziamento e saldo finale raggiungono la catena base.

Se Bob presenta poi il turno `1`, in un sistema basato sul turno massimo Alice deve produrre il turno `2` pienamente supportato entro il termine. Il contratto respinge il vecchio e regola il turno `2`. Se Alice ha perso il turno `2`, non usa la chiave, non ha asset base per le fee o resta offline troppo a lungo, il protocollo non può dedurre la storia privata. Il risultato eseguibile può differire dall’ultimo accordo.

È un esempio concettuale. I protocolli reali definiscono firme, transizioni, pagamenti condizionati, chiamate e scadenze esatte. Non trasferire fondi basandosi solo su questa aritmetica semplificata.

<a id="risks"></a>

## Rischi e controlli

- **Regolamento obsoleto.** Conservare il pacchetto completo più recente e provarne il ripristino. Capire dati e poteri prima di usare una watchtower.
- **Termine mancato.** Monitorare la catena corretta fino alla risoluzione, con margine realistico per guasti, riorganizzazioni, congestione e intervento umano.
- **Fee e congestione.** Tenere asset base libero e un modo per aumentare le fee. Dispute simultanee possono rendere costosa proprio un’uscita urgente.
- **Perdita di chiave o stato.** Usare il backup documentato. Non ripristinare un canale attivo da snapshot vecchio senza garanzia esplicita.
- **Capacità o routing.** Controllare liquidità in/out, riserve, massimi condizionati, scadenze e intermediari. Il saldo totale non è capacità disponibile.
- **Controparte e operatività.** Di norma non può riscrivere un esito protetto, ma può rifiutare aggiornamento o chiusura comune e imporre la disputa lenta.
- **Implementazione.** Bug di client, arbitro, dominio di firma, transizioni o upgrade possono annullare le garanzie. Verificare deployment e audit.
- **Perdita di privacy.** Off-chain non significa anonimo: peer, router, osservatori, backup e disputa finale possono rivelare rapporti o dati.

<a id="misconceptions"></a>

## Fraintendimenti comuni

- **“Off-chain significa trustless senza blockchain.”** È il ricorso on-chain credibile a limitare la fiducia; sicurezza, disponibilità e costo contano ancora.
- **“Ogni stato firmato da entrambi verrà regolato.”** Ordine, validità, finalità, revoca e scadenze del protocollo decidono le prove eseguibili.
- **“La seed phrase ripristina l’intero canale.”** Di solito recupera le chiavi, non necessariamente stato recente, segreti, trasferimenti pendenti o database peer.
- **“Si può restare offline per sempre.”** Molti sistemi richiedono osservazione e risposta entro un termine, direttamente o tramite servizio delegato.
- **“La capacità equivale al saldo wallet.”** I fondi vanno impegnati e la capacità dipende da direzione, riserve, pendenze e liquidità del percorso.
- **“I canali sostituiscono sempre i rollup.”** Sono adatti a interazioni ripetute tra parti note; adesione aperta, stato globale e ampia componibilità possono favorire rollup o esecuzione on-chain.

<a id="related"></a>

## Argomenti correlati

- [Commissione gas](/crypto/gas-fee/)
- [HTLC](/crypto/htlc/)
- [Layer 2](/crypto/layer2/)
- [Rollup](/crypto/rollup/)
- [Smart contract](/crypto/smart-contract/)

<a id="sources"></a>

## Fonti

- [Reti generali di canali di stato](https://doi.org/10.1145/3243734.3243856) - ACM (consultato: 2026-08-21)
- [Protocollo Nitro](https://eprint.iacr.org/2019/219) - Cryptology ePrint Archive (consultato: 2026-08-21)
- [Stati e canali](https://docs.statechannels.org/protocol-tutorial/0010-states-channels/) - State Channels (consultato: 2026-08-21)
- [BOLT #2: protocollo peer per la gestione dei canali](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning Specifications (consultato: 2026-08-21)
- [BOLT #5: gestione delle transazioni on-chain](https://github.com/lightning/bolts/blob/master/05-onchain.md) - Lightning Specifications (consultato: 2026-08-21)

Source: https://wiki.fcontext.com/it/crypto/state-channels/index.mdx
