La porta dei servizi di asset digitali, infrastruttura dei dati on-chain - Tiger Research

1. Il muro che affrontano gli asset digitali, dati on-chain poco amichevoli {#rps-1}

Il mercato degli asset digitali sta evolvendo rapidamente. Le stablecoin gestiscono già transazioni annuali per miliardi di dollari e vengono utilizzate nei settori dei pagamenti e dei trasferimenti di denaro, mentre la tokenizzazione di asset finanziari tradizionali come azioni e obbligazioni sta prendendo piede. Questo dimostra che il ruolo della tecnologia blockchain si sta ampliando a tutta la catena del valore finanziario, dall'emissione e distribuzione degli asset ai pagamenti e alla liquidazione.

Ora la blockchain è passata dalla fase di discussione delle possibilità a quella della costruzione di infrastrutture concrete. Di conseguenza, il focus della discussione si è spostato non più sulla necessità di adottare la tecnologia, ma su come operarla all'interno della finanza regolamentata. In particolare, si tratta di come integrare l'infrastruttura blockchain con i flussi di lavoro esistenti in contabilità, tassazione, audit e conformità. Anche se la blockchain funziona come una nuova infrastruttura di base, le procedure e gli standard richiesti dalla finanza regolamentata rimangono invariati.

Il problema è che integrare l'infrastruttura blockchain nei flussi di lavoro finanziari esistenti è complicato. I sistemi finanziari legacy funzionano su dati strutturati standardizzati, mentre i dati on-chain sono più simili a dati grezzi che richiedono indicizzazione, decodifica e normalizzazione. In altre parole, non si tratta di un libro contabile ben organizzato, ma di un'enorme pila di ricevute non classificate.

Pertanto, per utilizzare i dati on-chain è necessaria una pipeline di dati separata. È necessario raccogliere i registri delle transazioni dai registri distribuiti e purificarli per scopi specifici. Inoltre, è fondamentale avere un'infrastruttura in grado di memorizzare in modo sicuro decine di terabyte di dati e di recuperarli rapidamente quando necessario. In definitiva, sebbene i dati on-chain siano pubblici, non sono dati facilmente utilizzabili di per sé.

2. Realtà e limiti della costruzione dell'infrastruttura dei dati on-chain {#rps-2}

Tuttavia, all'inizio, quando la dimensione e l'ambito di utilizzo del mercato degli asset digitali erano limitati, i problemi di accessibilità ai dati non erano così evidenti. La maggior parte dei servizi di asset digitali era simile a esperimenti su piccola scala destinati a un numero limitato di partecipanti. Ad esempio, il progetto di token di deposito della banca d'investimento globale JP Morgan era un mezzo di pagamento limitato progettato solo per pochi clienti istituzionali. In un ambiente in cui i partecipanti e gli scopi d'uso erano chiari, anche i tipi di transazioni da elaborare erano semplici e la tempestività o la precisione dei dati non erano così importanti.

In quel periodo, i criteri richiesti per i dati on-chain erano relativamente flessibili. Anche se non tutte le condizioni corrispondevano rigorosamente in tempo reale, non c'erano grandi problemi operativi finché, dopo un certo periodo, la coerenza risultava corretta. In altre parole, un approccio basato sulla coerenza finale era sufficientemente accettabile. In questo ambiente, era possibile gestire senza problemi operando nodi limitati o integrando endpoint RPC esterni o semplici API di dati on-chain.

Tuttavia, man mano che l'ambiente on-chain si espandeva, non era più possibile gestire tutto con i metodi esistenti. La varietà degli asset trattati e l'aumento rapido del volume delle transazioni hanno ampliato drasticamente l'ambito di elaborazione dei dati. Di conseguenza, i requisiti tecnici che l'infrastruttura dei dati deve soddisfare si sono evoluti da semplici query a forme molto più sofisticate e in tempo reale. Con l'ingresso in una fase operativa concreta, i criteri richiesti per l'infrastruttura sono cambiati radicalmente.

3. Requisiti dell'infrastruttura dei dati on-chain per la finanza regolamentata {#rps-3}

Per soddisfare questi requisiti elevati, i criteri per valutare l'infrastruttura devono cambiare. Tiger Research propone tre criteri fondamentali per l'infrastruttura dei dati on-chain che la finanza regolamentata può fidarsi e utilizzare: completezza, coerenza e stabilità. Questi sono requisiti essenziali che i dati on-chain devono soddisfare per funzionare come libro mastro di riferimento per i servizi reali.

3.1. Completezza: tutte le transazioni sono incluse? {#rps-4}

La completezza è il requisito più fondamentale per l'infrastruttura dei dati on-chain. Questo criterio determina se le transazioni registrate nel libro mastro blockchain sono state raccolte senza omissioni e se sono state riflettute senza mancanze anche nel processo di elaborazione successivo. Nella finanza regolamentata, anche un'unica omissione di transazione può alterare il calcolo del saldo, la contabilizzazione e i risultati di liquidazione.

Le omissioni nei dati possono verificarsi già nella fase di raccolta. La blockchain raggruppa le transazioni verificatesi in un certo periodo in blocchi e li registra nel libro mastro. L'infrastruttura dei dati raccoglie e elabora questi blocchi in ordine. Tuttavia, se un guasto del nodo o un problema di rete interrompe la raccolta dei blocchi in un determinato intervallo, anche i registri delle transazioni in quell'intervallo possono andare persi. Tuttavia, le omissioni nella fase di raccolta possono essere verificate e affrontate in modo relativamente chiaro. È possibile riempire i dati attraverso un'operazione di backfill per raccogliere nuovamente l'intervallo di blocchi mancanti.

Un altro problema si presenta nel processo di elaborazione dopo aver raccolto tutti i dati dei blocchi originali. L'indicizzatore estrae i registri delle transazioni necessari dai dati originali e li converte in una forma consultabile. In questo caso, se i dati non vengono analizzati correttamente, alcuni registri possono andare persi durante il processo di elaborazione. Ad esempio, supponiamo di indicizzare i dati di trasferimento dei token di Solana. Solana ha standard di token sia esistenti che estesi. Se l'indicizzatore è progettato per analizzare solo lo standard esistente, i registri di movimento dei token emessi secondo lo standard esteso possono andare persi.

Nei chain ad alte prestazioni, il carico per mantenere la completezza aumenta ulteriormente. Più breve è il ciclo di creazione dei blocchi e maggiore è il volume delle transazioni, maggiore sarà anche la quantità di dati che la pipeline deve elaborare in un breve periodo. Anche se non ci sono difetti nella logica di raccolta e elaborazione, se l'elaborazione in tempo reale non riesce a tenere il passo con la velocità della chain, il riflesso dei registri delle transazioni che si sono verificati nel frattempo può essere ritardato. In definitiva, la completezza deve andare oltre il semplice recupero dei dati, ma deve anche essere in grado di rispondere continuamente ai cambiamenti e alla velocità della chain.

3.2. Coerenza: i dati raccolti sono accurati? {#rps-5}

Se la completezza verifica l'assenza di omissioni nei dati, la coerenza è il criterio che determina se i dati raccolti corrispondono al libro mastro blockchain. Nella finanza regolamentata, la coerenza è altrettanto importante della completezza. Se un dato è errato, tutti i calcoli e le valutazioni basati su di esso possono essere distorti.

Nel blockchain, durante il processo di conferma del registro, i dati possono temporaneamente variare. I sistemi finanziari tradizionali registrano e gestiscono i dati basandosi su un server centrale, mentre il blockchain consente a più partecipanti di verificare ciascun blocco e aggiornare il registro attraverso un consenso. In questo processo, possono verificarsi situazioni in cui blocchi diversi sembrano essere validi contemporaneamente a causa di ritardi nella rete o differenze nei tempi di verifica.

In questo processo, un blocco inizialmente considerato valido può essere escluso dal registro finale e sostituito da un altro blocco, portando a una riorganizzazione (Reorg) dei blocchi. In questo caso, le transazioni incluse in quel blocco possono essere escluse dal registro finale o reinserite in un altro blocco successivamente. Ciò può causare problemi di coerenza, poiché i dati raccolti in un determinato momento possono differire dallo stato finale del registro.

I problemi di coerenza possono verificarsi anche nei nodi client. I nodi client sono il software fondamentale che gestisce i nodi del blockchain, simile a un sistema operativo (OS) per il blockchain. Se questo software presenta difetti, possono verificarsi errori nel processo di interpretazione e calcolo dei dati del registro. In effetti, ci sono stati casi in cui i principali nodi client di Ethereum hanno presentato errori nel processo di elaborazione delle transazioni o nel calcolo delle commissioni. Questo è simile a incidenti in cui gli asset dei clienti nei servizi finanziari sono stati erroneamente riportati o le commissioni sono state calcolate in modo errato.

Pertanto, la coerenza dei dati on-chain non è garantita semplicemente raccogliendo i dati. I dati raccolti in un determinato momento possono differire dal registro finale, e i difetti nei nodi client possono portare a una cattiva interpretazione dei dati del registro. Pertanto, per utilizzare i dati on-chain come dati di riferimento nel sistema finanziario, è necessario confrontare e verificare continuamente che i dati raccolti corrispondano al registro.

3.3. Stabilità: è stabile anche in ambienti operativi su larga scala?

Se completezza e coerenza sono criteri per verificare la qualità dei dati, la stabilità è un criterio per valutare se la raccolta, l'elaborazione e la consultazione dei dati possano continuare senza interruzioni anche in ambienti operativi su larga scala. In un'industria in cui anche un singolo guasto o ritardo può avere conseguenze fatali, questo è un requisito non negoziabile. In particolare, l'infrastruttura on-chain presuppone una rete che non si ferma mai, quindi i requisiti di stabilità sono inevitabilmente più elevati.

In ambienti operativi su larga scala, è necessario gestire molte richieste contemporaneamente. Nelle infrastrutture server tradizionali, è possibile aumentare la capacità di elaborazione distribuendo le richieste su più server tramite bilanciamento del carico (Load Balancing). Tuttavia, nelle infrastrutture blockchain, è difficile ottenere lo stesso effetto semplicemente gestendo più nodi. I tempi di sincronizzazione dei blocchi di ciascun nodo possono differire, quindi anche per la stessa richiesta di consultazione possono essere restituiti risultati diversi.

Ad esempio, supponiamo che un utente controlli lo stato di elaborazione immediatamente dopo aver inviato una transazione. Il nodo che riceve la prima richiesta potrebbe aver verificato la transazione, ma un altro nodo che riceve la richiesta di consultazione potrebbe non averla ancora riflessa. In questo caso, anche se l'infrastruttura risponde normalmente, l'utente potrebbe vedere stati diversi per la stessa transazione.

Man mano che la quantità di dati aumenta, diventa più difficile garantire la stabilità. Nel sistema finanziario, non è sufficiente controllare solo lo stato più recente. È necessario valutare lo stato degli asset in un determinato momento e verificare anche quali storie di transazione hanno contribuito a formare quello stato. Per fare ciò, è necessario un nodo di archivio (Archive Node) che conserva i record passati, ma a seconda della catena, la sua dimensione può raggiungere decine di terabyte. In un ambiente in cui è necessario memorizzare e consultare dati così vasti, aumenta anche la possibilità di ritardi nella consultazione e colli di bottiglia nel sistema.

La manutenzione continua è anche un requisito importante per la stabilità. Il blockchain continua a cambiare anche durante il funzionamento, con hard fork (Hard Fork), aggiornamenti della catena e aggiornamenti dei nodi client. Se in quel momento la pipeline di raccolta e elaborazione dei dati non riesce a rispondere a questi cambiamenti, anche un'infrastruttura che funzionava normalmente può fermarsi all'improvviso. Alla fine, la stabilità non è garantita solo dalla costruzione iniziale, ma deve essere mantenuta rispondendo continuamente ai cambiamenti nell'ambiente della catena.

4. Lambda256: infrastruttura di dati on-chain per il sistema finanziario

È raro che un'azienda che prepara un'attività di asset digitali costruisca autonomamente tutta l'infrastruttura di base. Di solito, scelgono un'infrastruttura di catena globale con tecnologia comprovata e concretizzano il modello di business su di essa. Anche l'infrastruttura di dati on-chain deve essere vista da questa prospettiva. L'infrastruttura di dati on-chain che possiede completezza, coerenza e stabilità, come presentato in precedenza, non è semplicemente un compito di costruzione di un database.

In un ambiente multi-chain complesso, è necessario indicizzare in tempo reale dati strutturati in modo diverso per ciascuna catena e mantenere elevata stabilità e prestazioni di elaborazione anche in presenza di un traffico elevato. Inoltre, è necessario rispondere continuamente ogni volta che si verificano nuovi standard o aggiornamenti della catena. Alla fine, l'infrastruttura di dati on-chain non è un progetto di sviluppo che si conclude in breve tempo, ma è più simile a un grande progetto infrastrutturale che richiede enormi capitali, tempo ed esperienza operativa.

Pertanto, per le aziende, è più realistico scegliere un partner di infrastruttura verificato e concentrarsi sul proprio business piuttosto che sviluppare direttamente tutta l'infrastruttura. Anche il fatto che Lambda256 sia diventata un partner tecnologico per i principali operatori di asset digitali in Corea del Sud si basa su questo. Lambda256, una sussidiaria tecnologica di Dunamu, fornisce infrastrutture blockchain a borse, istituzioni finanziarie e aziende Web3, accumulando esperienza operativa nel mercato domestico.

Basandosi su questa esperienza, Lambda256 ha lanciato nel 2024 la piattaforma di sviluppo Web3 'Nodit'. Il recente prodotto 'DataShare' è un'infrastruttura di dati on-chain progettata tenendo conto della qualità dei dati e dell'ambiente operativo richiesti dal sistema finanziario. Prima del lancio ufficiale, ha fornito servizi in forma di data warehouse a alcuni partner per oltre due anni, il che la rende un'infrastruttura già testata in ambienti reali.

4.1. Differenziali tecnologici: motore di indicizzazione proprietario e pipeline di dati ad alte prestazioni

Il differenziale tecnologico di DataShare risiede nella capacità di fornire dati frammentati in un ambiente multi-chain come dataset compatibili con i flussi di lavoro esistenti. In un ambiente multi-chain, poiché la struttura dei dati e il metodo di registrazione differiscono per ciascuna catena, anche i criteri di raccolta e elaborazione devono essere progettati in base alle caratteristiche di ciascuna catena. Inoltre, poiché l'ambiente operativo di ciascuna catena continua a cambiare, come l'introduzione di nuovi standard o aggiornamenti della rete, la difficoltà di gestione dell'infrastruttura dei dati aumenta ulteriormente. DataShare ha una struttura in grado di rispondere continuamente a queste differenze e cambiamenti operativi, grazie a personale specializzato con conoscenze di dominio, un motore di indicizzazione proprietario e pipeline di dati ad alte prestazioni. Maggiori dettagli sul differenziale tecnologico di DataShare possono essere trovati in un articolo redatto congiuntamente da Lambda256 e Discypher (Associazione di tecnologia blockchain dell'Università di Seul).

Per garantire che questa struttura funzioni in modo stabile, è necessario supportare anche l'ambiente infrastrutturale dei nodi che acquisiscono i dati sorgente. DataShare è fornito sulla base dell'architettura Hyper Node di Nodit, il che consente di rispondere in modo flessibile anche a richieste su larga scala o a situazioni di guasto dei nodi. È stato progettato per gestire i criteri minimi di disponibilità dei nodi e controllare le soglie di latenza e recupero, in modo che i problemi di un nodo specifico non si diffondano all'intero processo di raccolta. Inoltre, ha una struttura che consente di rispondere senza interruzioni a cambiamenti ambientali come aggiornamenti della mainnet o sostituzioni del software dei nodi.

Un altro punto importante che distingue DataShare è che i dati raccolti passano attraverso un processo di verifica separato. DataShare verifica continuamente se i dati raccolti corrispondono allo stato reale della catena attraverso un processo di auto-verifica. In questo processo, vengono controllate le discrepanze nei dati che possono sorgere a causa di riaggiustamenti dei blocchi, errori nei client dei nodi o aggiornamenti della catena, e viene verificato anche se i risultati del trattamento delle singole transazioni sono riflessi in modo coerente nei registri degli eventi e nelle variazioni di saldo. In altre parole, attraverso la verifica incrociata tra ciò che è registrato sulla catena e i risultati elaborati da DataShare, si riducono le omissioni di dati o gli errori di elaborazione, garantendo così l'affidabilità che può essere utilizzata come dati di riferimento nei flussi di lavoro esistenti.

Tuttavia, per utilizzare i dati on-chain nelle operazioni reali, è necessario non solo garantire l'accuratezza dei dati, ma anche fornire un'ampia gamma di catene e tipi di dati necessari. DataShare attualmente supporta 13 catene principali ad alta domanda di mercato e può anche supportare l'espansione di set di dati personalizzati basati su oltre 50 multi-chain gestiti da Nodit. In futuro, è previsto di fornire dati etichettati che combinano indirizzi di portafoglio degli exchange, contratti intelligenti DeFi e dati sui prezzi, ampliando così l'ambito di utilizzo non solo per la contabilità e la fiscalità, ma anche per la gestione del rischio e il monitoraggio delle transazioni anomale.

4.2. Differenziali operativi: risposta alla compliance e integrazione dei flussi di lavoro esistenti

Per utilizzare i dati on-chain nel settore finanziario regolamentato, è necessario soddisfare non solo la qualità dei dati, ma anche i requisiti di compliance. In particolare, il settore finanziario nazionale ha criteri rigorosi quando si tratta di introdurre infrastrutture di dati esterni, come la separazione delle reti, il controllo degli accessi e le norme operative delle reti interne. DataShare supporta la costruzione on-premise all'interno di IDC nazionali, tenendo conto di questo ambiente, e ha anche ottenuto la certificazione SOC2 per garantire l'affidabilità del sistema di gestione della sicurezza. Ciò consente alle istituzioni finanziarie di introdurre dati on-chain in conformità con le politiche di sicurezza interne e le linee guida normative.

È anche importante che le istituzioni finanziarie possano gestire direttamente la posizione di archiviazione dei dati e i diritti di accesso. DataShare supporta un'architettura che invia direttamente i dati on-chain ai repository cloud utilizzati dalle istituzioni finanziarie. Ad esempio, caricando i dati on-chain in tempo reale in ambienti di dati interni come AWS S3, le istituzioni possono mantenere il controllo sulla gestione dei dati e sul controllo degli accessi, pur utilizzando soluzioni infrastrutturali esterne.

Inoltre, DataShare prevede di continuare a rafforzare l'integrazione con gli ambienti di analisi dei dati già utilizzati dalle istituzioni finanziarie. Supportando l'integrazione con principali data warehouse e piattaforme di analisi come Snowflake, BigQuery e Databricks, l'obiettivo è garantire che i dati on-chain possano essere collegati in modo organico ai flussi di lavoro esistenti.

Il sistema di supporto operativo di Lambda256 è anche un punto di forza di DataShare. Poiché l'infrastruttura dei dati on-chain si basa su una rete blockchain operativa 24 ore su 24, è fondamentale avere la capacità di rilevare e rispondere rapidamente a guasti o ritardi. DataShare fornisce monitoraggio continuo e supporto tecnico dedicato attraverso personale specializzato nazionale, riducendo il carico operativo che le istituzioni finanziarie devono affrontare direttamente. Ciò consente alle istituzioni di gestire e utilizzare i dati on-chain in modo stabile senza dover espandere significativamente un'organizzazione di infrastruttura blockchain separata.

5. Momenti in cui è necessaria l'infrastruttura dei dati on-chain

Scenario 1: Problema di tracciamento preciso degli azionisti tokenizzati on-chain

Nel settore finanziario regolamentato, ci sono sempre più casi in cui le azioni quotate vengono emesse simultaneamente in forma tokenizzata sulla blockchain. Un esempio rappresentativo è Galaxy Digital, un'azienda globale di asset digitali, che ha tokenizzato le sue azioni ordinarie ($GLXY) e le ha emesse sulla blockchain di Solana. Anche Securitize, un'azienda di tokenizzazione degli asset, ha emesso le proprie azioni ($SECZ) sulla blockchain di Solana in concomitanza con la quotazione alla Borsa di New York (NYSE). Solana, con la sua velocità di elaborazione rapida e costi contenuti, è stata scelta come infrastruttura principale da parte delle istituzioni finanziarie che cercano di tokenizzare azioni quotate in conformità con le normative.

Le istituzioni finanziarie che gestiscono sia asset tradizionali che titoli tokenizzati on-chain affrontano nuove sfide operative. Le società di intermediazione devono tracciare con precisione lo stato degli azionisti tokenizzati registrati sulla blockchain e dimostrarlo alle autorità di regolamentazione e ai revisori. Questo è un compito chiave che si ripete non solo al momento della chiusura dei conti, ma anche nelle date di registrazione dei dividendi e di calcolo dei diritti di voto. Se i dati vengono omessi o se il saldo in un determinato momento è calcolato erroneamente, ciò può portare a rischi fatali come pagamenti errati, errori di comunicazione e fallimenti nella risposta ai controlli.

Il problema è che la struttura dei dati unica di Solana rende difficoltoso questo lavoro finanziario. Sebbene Solana sia vantaggiosa in termini di costi e velocità, la sua struttura prevede che i registri delle transazioni siano distribuiti su numerosi account. Anche solo una transazione DeFi può frammentare i dati in conti di token, pool di liquidità e conti delle commissioni. Inoltre, considerando che la dimensione dei dati accumulati nei nodi di archivio di Solana raggiunge centinaia di terabyte, ricostruire lo stato degli azionisti e la cronologia delle transazioni in un determinato momento del passato diventa un compito realisticamente difficile per le singole istituzioni.

Pertanto, per integrare gli asset tokenizzati basati su Solana nel settore finanziario regolamentato, è essenziale avere un'infrastruttura dati che consenta analisi immediate senza elaborazione. DataShare purifica i dati sorgente frammentati e li fornisce in una forma normalizzata che può essere interrogata immediatamente nei data warehouse esistenti delle istituzioni finanziarie. In particolare, ottimizzando la pipeline per un ambiente ad alta velocità con un ciclo di generazione dei blocchi inferiore a 0,4 secondi, DataShare ha ottenuto una base di prestazioni in grado di elaborare in tempo reale circa 20.000 transazioni al secondo per catena, minimizzando i ritardi di indicizzazione.

Scenario 2: Pagamenti agentici, problemi di gestione del rischio nei pagamenti on-chain {#rps-12}

Il mercato dei pagamenti agentici (Agentic Payment), in cui gli agenti AI decidono ed eseguono i pagamenti per conto degli utenti, sta emergendo. Dopo il lancio del protocollo di pagamento on-chain x402 da parte di Coinbase, è iniziata anche la costruzione di un'infrastruttura di pagamento autonomo basata su stablecoin.

Tuttavia, affinché i pagamenti autonomi tra agenti si stabilizzino come servizi finanziari commerciali, la qualità dei dati on-chain che fungono da base per le decisioni è di fondamentale importanza. Man mano che le procedure di verifica umana diminuiscono, il sistema deve determinare la disponibilità di saldo, la conferma delle transazioni e la possibilità di transazioni anomale esclusivamente tramite i dati. Se in questo processo i dati on-chain vengono omessi o distorti, possono verificarsi errori fatali in tutto il processo di approvazione e rifiuto dei pagamenti.

Quali sono quindi i fattori specifici che causano l'omissione e la distorsione di questi dati nell'ambiente blockchain reale? Una delle cause più rappresentative è il fallimento delle transazioni. A seconda della congestione della rete, oltre il 20% delle transazioni può fallire, e in particolare nel caso di Solana, il tasso di fallimento delle transazioni non votate supera il 40%.

Se il sistema di pagamento scambia queste transazioni fallite per transazioni elaborate correttamente, si verifica un errore di discrepanza di saldo, in cui il saldo viene considerato diminuito anche se non è avvenuto alcun pagamento reale. Inoltre, il fenomeno di riordino dei blocchi, in cui una transazione che sembrava approvata in un certo momento viene successivamente annullata, agisce come una variabile fatale che intensifica la distorsione dei dati.

DataShare affronta questi problemi di affidabilità dei dati selezionando solo i dati per i quali è stata garantita la finalità e il successo finale, per fornire al sistema di pagamento. Verifica in tempo reale le transazioni non confermate o i registri di fallimento inclusi nei dati di origine della blockchain durante la fase di pipeline e fornisce solo set di dati raffinati, eliminando così il rischio di malfunzionamenti dovuti a distorsioni on-chain.

Inoltre, sta continuando ad espandere il proprio ambito di supporto a importanti blockchain locali sia nazionali che internazionali, come GIWA e Kaia, garantendo così la versatilità commerciale. Questo rappresenta un valore fondamentale in quanto consente all'infrastruttura di pagamento agentico di superare i limiti di dipendenza da specifiche mainnet globali e di diversificarsi in modo flessibile in base all'ambiente di servizio e ai requisiti normativi di ciascuna regione.

6. Conclusione {#rps-13}

Il successo o il fallimento delle attività di asset digitali dipende da quanto accuratamente vengono gestiti i dati. Tutti i processi finanziari, dall'emissione degli asset ai pagamenti e ai regolamenti, sono riorganizzati attorno ai dati on-chain. Pertanto, l'omissione o l'errore dei dati può portare a una diminuzione della fiducia nel servizio e, oltre a ciò, a rischi normativi fatali. DataShare funge da infrastruttura di collegamento per ridurre questi rischi operativi e consentire alle istituzioni finanziarie di utilizzare i dati on-chain in conformità con i propri standard operativi.

Inoltre, le istituzioni finanziarie possono utilizzare le varie soluzioni tecnologiche finanziarie di Lambda256 per espandere le funzionalità necessarie in modo personalizzato, oltre a DataShare. Ad esempio, è possibile migliorare la completezza del sistema introducendo SCOPE per la regolazione e l'operazione degli asset digitali o CLAIR per la conformità normativa, in base alle fasi di crescita del business. In altre parole, è un modo per combinare gradualmente le funzionalità necessarie nell'ambiente esistente senza il peso di ricostruire completamente l'infrastruttura fin dall'inizio.

Di conseguenza, le istituzioni finanziarie possono liberarsi completamente del peso della gestione di infrastrutture complesse o della manutenzione dei sistemi e concentrarsi sul valore commerciale intrinseco dell'innovazione dei servizi e della differenziazione dei prodotti. Si completa così una struttura che consente di ottenere stabilmente le funzionalità necessarie in qualsiasi momento, in linea con l'espansione futura del business e i cambiamenti normativi, abbassando al contempo le barriere all'ingresso iniziali.

Questo articolo è un contributo di Tiger Research, un'agenzia di ricerca specializzata in Web3 globale, partner di Block Media, intitolato 'L'infrastruttura dei dati on-chain, la porta d'accesso ai servizi di asset digitali'.