Domande tecniche e obiezioni ricorrenti#
Questo capitolo offre risposte concise alle verifiche più frequenti di sviluppatori, auditor e specialisti blockchain. Le risposte rinviano sempre al modello operativo, evitando slogan.
“Il registro è centralizzato: allora a cosa serve la blockchain?”#
Il registro centralizza la responsabilità autoritativa perché strumenti, identità, rettifiche e finalità richiedono un soggetto governato. Il rail pubblico aggiunge interoperabilità, verificabilità della supply, automazione permissioned e un circuito esterno sostituibile. Non viene usato per fingere che la responsabilità sia decentralizzata.
“Se il token è nel mio wallet, perché non sono automaticamente il titolare?”#
Il wallet dimostra controllo di una chiave. La titolarità dipende dal regime giuridico, dal registro riconosciuto, dall’identità associata e dalle restrizioni dello strumento. CertiExch riconcilia il wallet con il conto di registrazione; non equipara automaticamente address e persona.
“Perché usare un token permissioned su una rete permissionless?”#
La rete pubblica offre infrastruttura condivisa e verificabilità. Il contratto permissioned applica le regole dello strumento. Permissionless descrive chi può osservare e partecipare al consenso della rete, non chi può detenere legalmente ogni strumento.
“T2 su Bitcoin rende superfluo Polygon?”#
T2 e Polygon hanno funzioni diverse. T2 ancora prove; Polygon esegue il mirror EVM. Uno può essere sostituito senza cambiare l’altro.
“Polygon è una sidechain, quindi la sicurezza non è Ethereum.”#
Corretto: la finalità nativa deriva dal consenso Polygon e dalle milestone; i checkpoint aggiungono ancoraggio a Ethereum per funzioni specifiche. Il manuale non presenta Polygon come rollup Ethereum. La scelta del rail è una decisione di rischio, costo, operatività e interoperabilità.
“Un amministratore può forzare un trasferimento?”#
Le capacità dipendono dal contratto e dalla matrice dei ruoli. Il mirror di riferimento è deliberatamente sottile e le correzioni autoritative avvengono nel registro con workflow governato. Un potere amministrativo, quando previsto, deve essere visibile, limitato e auditato; non va nascosto dietro la parola decentralizzazione.
“Come provate che il contratto pubblicato è quello revisionato?”#
Si collegano source/bytecode, ABI, versione, compiler settings, contract address, deployment transaction e hash del Master Record. La verifica deve controllare il bytecode on-chain, non soltanto il nome del contratto su un explorer.
“Cosa succede se Polygon si ferma?”#
Il registro continua a conservare la fonte di verità. Le operazioni sul rail vengono sospese, riconciliate e riprese secondo runbook. Il titolo e il servicing non scompaiono perché il rail è indisponibile.
“Perché non mettere documenti e PII on-chain?”#
Per minimizzazione, riservatezza, rettificabilità dei dati personali e costi. On-chain si pubblicano commitment e dati strettamente necessari; i contenuti restano in sistemi governati.
“È davvero trustless?”#
No, e non pretende di esserlo. È un sistema a fiducia esplicita e verificabile: ruoli, provider, chiavi e responsabilità sono dichiarati, mentre le prove riducono la possibilità di alterazioni non rilevate.