Pensavo che la revoca fosse la parte più semplice del Sign Protocol: basta revocare on-chain e il gioco è fatto. L'emissione è la parte complessa: bisogna verificare l'identità, progettare lo schema, costruire fiducia.
Ma questo è il fraintendimento più pericoloso.
Quando una credenziale viene revocata su Sign, l'emittente fa solo una cosa: registra un record on-chain che questa credenziale non è più valida. Quel record è immutabile, accessibile a tutti, non può essere modificato.
Dal punto di vista tecnico, tutto è corretto.
Il problema risiede nel resto del sistema.
Quanti verificatori hanno controllato quella credenziale prima che venisse revocata? Quanti di loro hanno conservato il risultato della verifica invece di interrogare di nuovo ogni volta? Quanti sistemi sapranno automaticamente che lo stato è cambiato?
Sign non diffonde questa informazione. La revoca non è una trasmissione. È una verità basata su richiesta — chi vuole conoscere lo stato più recente deve andare a interrogare, nessuno avvisa attivamente.
Questo è il gap di propagazione della revoca: la distanza tra il momento in cui la credenziale è stata revocata on-chain e il momento in cui l'intero sistema smette di accettarla.
Quella distanza non è teoria.
Immagina un utente che sta usando una credenziale per accedere a un sistema di pagamento. La credenziale è stata revocata a causa di frodi, e il record on-chain si aggiorna immediatamente. Ma il terminale del commerciante, l'app bancaria o il portale dei servizi stanno ancora utilizzando i risultati della verifica precedenti — cache di 1 ora, 1 giorno, o addirittura indefinitamente.
Per tutto il tempo, il sistema continua a operare su una credenziale che non è più valida.
La revoca si è verificata sulla chain. Ma non è accaduto nella realtà.
Non è colpa di Sign. Questa è una limitazione strutturale di tutti i sistemi decentralizzati: non c'è un'autorità centrale per spingere lo stato a tutti i verificatori, quindi tutto dipende dal fatto che il verificatore controlli attivamente o meno.
E se non c'è nulla che li costringa a controllare, non controlleranno.
Il sistema di certificazione di Internet ha affrontato questo problema. Il browser non verifica solo una volta e poi si fida per sempre, ma deve controllare nuovamente lo stato del certificato in ogni connessione. Non è perfetto, ma riconosce un fatto importante: la revoca ha significato solo se il verificatore ne è a conoscenza.
Il Sign non ha ancora un meccanismo equivalente a livello di protocollo. Non ci sono notifiche di revoca. Non ci sono standard obbligatori per la re-verifica. Nulla impedisce a un sistema di memorizzare in cache i risultati di verifica indefinitamente.
Con un caso d'uso piccolo, questo è un inconveniente.
Con infrastrutture sovrane come CBDC e ID nazionali, questo è un rischio sistemico.
In quell'ambiente, la revoca non è un caso limite. È una funzione fondamentale: frode, conformità, cambiamento di policy dipendono tutte dalla revoca tempestiva della credenziale e dalla corretta reazione di tutto il sistema.
Se la propagazione non avviene in tempo, il sistema sta operando con informazioni errate — su scala di milioni di transazioni.
Il controllo del rischio non è su Sign. È nelle mani di chi costruisce su Sign.
Qualsiasi sistema di produzione che richiede una rigorosa revoca deve progettare autonomamente uno strato di re-verifica: interrogare nuovamente lo stato della credenziale prima di ogni azione importante, stabilire chiaramente la durata di validità dei risultati della verifica per ogni risultato di verifica e non considerare mai un risultato di verifica precedente come valido indefinitamente.
Altrimenti, hai involontariamente trasformato una credenziale che potrebbe essere revocata in una credenziale permanente — solo perché non hai controllato di nuovo.
Ecco perché monitoro Sign non in base alla velocità di revoca on-chain, ma se riescono a costruire un meccanismo per ridurre il gap di propagazione della revoca.
La revoca on-chain è una dichiarazione.
La revoca è realmente l'azione del verificatore.