Introduzione

Corda

In FORFIRM, riteniamo che la tecnologia del ledger distribuito abbia il potenziale per trasformare l'industria dei servizi finanziari a beneficio dei suoi clienti e delle aziende partecipanti. Prevediamo un futuro in cui gli accordi finanziari siano registrati e gestiti automaticamente senza errori, in cui chiunque possa effettuare transazioni senza soluzione di continuità per qualsiasi scopo contrattuale senza frizione. Riteniamo che i mercati si orienteranno verso modelli in cui le parti degli accordi finanziari li registrano una volta e collaborano per mantenere record accurati e condivisi di tali accordi. Duplicazioni, riconciliazioni, partite fallite e interruzioni saranno cose del passato. Aspiriamo a definire un tessuto contabile condiviso per i casi di utilizzo di servizi finanziari che possono essere implementati all'interno di quadri legali esistenti e che si basano su tecnologie comprovate. La nostra filosofia può essere suddivisa in tre categorie: ingegneria per i requisiti delle istituzioni, attenzione ai requisiti non funzionali ed estensibilità. Questo documento introduce le caratteristiche progettuali della piattaforma Corda che riteniamo sia una scelta interessante per le istituzioni finanziarie regolamentate.

Contesto

Le banche sono state tra i primi attori ad adottare la tecnologia dell'informazione e, contrariamente a quanto si crede, hanno fatto un buon lavoro nell'automazione di processi precedentemente manuali e nella digitalizzazione di processi precedentemente fisici. Tuttavia, ci sono opportunità significative per migliorare il costo e l'efficienza delle architetture. In particolare, ciascuna istituzione finanziaria mantiene i propri libri contabili, che registrano la visione degli accordi e le posizioni rispetto al proprio gruppo di clienti e ai suoi omologhi. Le sue controparti, a loro volta, mantengono le loro opinioni. Questa duplicazione può portare a incongruenze e comporta la necessità di costose corrispondenze, riconciliazione e correzione degli errori da parte e tra le varie parti di una transazione. Se le differenze permangono tra le opinioni di due imprese sulla stessa transazione, questa è anche una fonte di rischio, potenzialmente sistemico. Una pluralità di istituzioni finanziarie guida la competizione e la scelta, ma la pluralità di piattaforme tecnologiche su cui poggiano spinge la complessità e crea rischi operativi. Tuttavia, fino a poco tempo fa ciò era inevitabile: tranne che per le infrastrutture di mercato centralizzate, c'erano pochi modi efficaci per consolidare la tecnologia su tutte le imprese senza consolidare anche le imprese stesse. I servizi centralizzati di infrastruttura di mercato hanno contribuito a incrementare la quantità di dati e la condivisione della logica di business tra le imprese, ma, soprattutto, il grado di integrazione raggiunto nel campo delle transazioni finanziarie è ancora molto indietro rispetto a quello che è stato raggiunto nel regno di scambio di informazioni dall'avvento del web.

Crediamo che la maturazione delle tecniche crittografiche, in parte esemplificate da quella che viene comunemente definita "tecnologia blockchain", offra una nuova opportunità: la possibilità di sistemi autorevoli di registrazione che siano condivisi in modo sicuro tra le imprese. Questa visione offre l'opportunità di trasformare l'economia delle imprese finanziarie, in particolare, ma non esclusivamente, nei servizi post-commerciali, implementando una nuova piattaforma condivisa per la registrazione degli eventi finanziari e l'elaborazione della logica di business: uno in cui un singolo libro contabile  globale è autorevole per tutti gli accordi tra le imprese registrati su di esso. Questa architettura definirà una nuova piattaforma condivisa per l'industria, sulla quale operatori storici, nuovi competitor e terze parti potranno concorrere per fornire nuovi prodotti e servizi innovativi.

schema1

Figura 1: Nel diagramma sopra, mostriamo una progressione da un mondo in cui le parti condividono fatti e gestiscono i propri record, con discrepanze e duplicazioni associate ("Bilaterale - Riconciliazione") o in cui le parti delegano il controllo e la responsabilità sull'elaborazione critica alle utility centralizzate ("Third Party / Market Infrastructure"), a una in cui collaborano per mantenere un record condiviso, assicurandosi di essere coerenti tra loro, consumando i servizi di fornitori di servizi esistenti e nuovi e fornitori di infrastrutture di mercato su base aperta e competitiva ("Shared Ledger Vision").
Riteniamo che i risparmi derivanti da dati di qualità superiore, minori discrepanze e un più rapido accordo sui dettagli tra le imprese saranno significativi. Inoltre, l'implementazione di questa architettura comune tra le aziende definirà una nuova piattaforma sulla quale i fornitori esistenti e nuovi potranno competere per soddisfare le esigenze dei clienti. Andando oltre, è possibile che tale piattaforma trovi anche applicazioni all'interno di aziende, dove il problema di più sistemi che registrano dettagli delle stesse operazioni è anche un importante fattore di costo e complessità.

Vision

A lungo termine, si può immaginare un "registro globale" con cui interagiranno tutti gli attori economici e che consentirà a qualsiasi parte di registrare e gestire accordi tra loro in modo sicuro, coerente, affidabile, privato e autorevole. Diciamo che è globale nel senso che tutti vedono gli stessi dati che li riguardano e logici nel senso che l'implementazione fisica può essere composta differentemente. Come tale, un possibile stato finale è quello in cui ci siamo spostati da sistemi autorevoli di record mantenuti all'interno di aziende a sistemi autorevoli globali di record condivisi tra aziende.

End-State Principles

I principi alla base di un possibile stato finale che utilizza la tecnologia del registro distribuito possono includere:

• I fatti registrati dal libro mastro sono, per contratto, accettati come prove ammissibili e legalmente vincolanti da tutte le parti in qualsiasi controversia.

• I fatti registrati dal libro mastro sono considerati autorevoli piuttosto che "ombre" di dati autorevoli conservati altrove, consentendo agli insediamenti di avere luogo direttamente attraverso la piattaforma.

• Una volta che tutte le parti di un accordo hanno acconsentito, i fatti registrati nel libro mastro sono finali e immutabili; errori e svolgimento devono essere elaborati attraverso una transazione successiva. Le imprese saranno sotto pressione per riprogettare i loro processi interni per aumentare la precisione e la qualità.

• Qualsiasi attore autorizzato può, in linea di principio, collegarsi direttamente al libro mastro e utilizzarlo per registrare accordi con le sue controparti. Nessun attore è obbligato a occuparsi di altri, ma potremmo assistere a un declino dei modelli di mercato "a più livelli" o gerarchici.

• Promuovendo standard aperti e accesso inclusivo, i fornitori di servizi esistenti e nuovi possono connettersi e competere con i servizi offerti da altri, promuovendo la scelta e la concorrenza.

• Le uniche parti che dovrebbero avere accesso ai dettagli di una transazione finanziaria sono quelle parti stesse e altre persone con un legittimo bisogno di sapere.

Tuttavia, la visione comprende la nozione di stati provvisori, come quelli che si focalizzano innanzitutto sulla condivisione della sola logica aziendale.

Questo è inteso a riconoscere la realtà che i sistemi di oggi saranno con noi per il prossimo futuro, richiedendo percorsi di coesistenza, integrazione e migrazione come parte fondamentale della progettazione della soluzione. Questi stati provvisori possono anche fornire un valore considerevole mentre le implicazioni giuridiche e altre non tecniche della visione a lungo termine sono affrontate in parallelo. non assume alcuna supposizione in merito alla sua sofisticazione o modalità operativa. L'impegno normativo è un elemento chiave del processo di progettazione. Dalla nostra analisi dei requisiti e dalla valutazione delle piattaforme di contabilità distribuita esistenti, abbiamo concluso che nessuna piattaforma esistente soddisfaceva le nostre esigenze. In sostanza, i modelli di minaccia alla base dei progetti di database tradizionali distribuiti non erano adatti per il nostro uso: il caso di portare al consenso entità legali reciprocamente diffidenti; e le architetture dei sistemi di blockchain esistenti non erano adatte per il nostro requisito di condivisione dei dati limitata e attentamente specificata a livello di singoli accordi legali. Di conseguenza, abbiamo progettato e iniziato lo sviluppo di Corda.

Caratteristiche principali

Corda è una piattaforma di contabilità distribuita per la registrazione e l'elaborazione di accordi finanziari, progettata per implementare la visione contenuta in questo documento. La piattaforma Corda supporta contratti intelligenti, in linea con la definizione di Clack, Bakshi, Braine.3 Il nostro contratto intelligente è un accordo la cui esecuzione è sia automatizzabile da codice computerizzato che utilizza input e controllo umani, i cui diritti e obblighi, espressi in prosa legale , sono legalmente esecutivi. Il contratto intelligente collega la logica aziendale e i dati aziendali alla prosa legale associata al fine di garantire che gli accordi finanziari sulla piattaforma siano radicati nella legge e possano essere applicati e che abbiamo un chiaro percorso da seguire in caso di ambiguità, incertezza o controversia.

• Flusso di lavoro coreografico tra le aziende senza un controller centrale.

• Sostenere il consenso tra le imprese a livello di singole offerte, non un sistema globale.

• Sostenere l'inclusione di nodi osservatori normativi e di vigilanza.

• Convalida delle transazioni esclusivamente tra le parti della transazione.

• Supporto di una varietà di meccanismi di consenso.

• Registrazione di collegamenti espliciti tra documenti in prosa legale in lingua umana e codice di contratto intelligente.

• Utilizzo di strumenti standard del settore.

• Limitazione dell'accesso ai dati di un accordo solo a coloro che ne hanno esplicitamente diritto o che hanno privilegi logici.
Queste caratteristiche contribuiscono alla progettazione di una piattaforma appropriata per l'uso in organizzazioni di servizi finanziari complessi. Si noti che questo design non utilizza una criptovaluta nativa o impone un limite di velocità della transazione globale.

Concetti

Iniziamo con l'idea di un libro contabile globale: un'unica fonte affidabile. Tuttavia, nel nostro modello, non è vero che le transazioni e le voci contabili siano globalmente visibili. Nei casi in cui le transazioni riguardano solo un piccolo sottogruppo di parti, ci impegniamo a mantenere i dati rilevanti esclusivamente all'interno di tale sottogruppo. L'oggetto fondamentale nel nostro concetto è un oggetto stato, che è un documento digitale che registra l'esistenza, il contenuto e lo stato corrente di un accordo tra due o più parti. È destinato a essere condiviso solo con coloro che hanno una ragione legittima per vederlo. Per garantire la coerenza in un sistema globale condiviso dove non tutti i dati sono visibili a tutti i partecipanti, facciamo affidamento su hash crittografici sicuri per identificare parti e dati. Il libro mastro è definito come un insieme di oggetti di stato immutabili. Parliamo e pensiamo in termini di stato degli accordi e il nostro obiettivo è quello di garantire che tutte le parti dell'accordo restino in consenso riguardo a questo stato che si evolve. Si potrebbe sostenere che questa è l'essenza del concetto di blockchain: garantire che i dati detenuti da diversi attori siano e rimangano coerenti con l'applicazione delle operazioni per aggiornare tali dati e che questo costituisca il fondamento su cui sono costruite transazioni affidabili: da semplici pagamenti monetari a sofisticate transizioni di contratti intelligenti.

schema2

Figura 2: Nel diagramma sopra, vediamo un oggetto di Stato che rappresenta un credito in contanti di £ 100 nei confronti di una banca commerciale, di proprietà di un'impresa di navigazione ufficiale. L'oggetto statale si riferisce esplicitamente all'hash alla sua prosa legale e al codice contrattuale che governa le sue transizioni.
La nostra attenzione agli stati degli accordi è in contrasto con i sistemi in cui i dati su cui i partecipanti raggiungono molto il consenso sono lo stato di un intero libro mastro o lo stato di un'intera macchina virtuale. Corda fornisce tre strumenti principali per raggiungere un consenso distribuito globale:

• Logica del contratto intelligente per garantire che le transizioni di stato siano valide secondo le regole concordate.

• Servizi di unicità e timestamping per ordinare temporaneamente le transazioni ed eliminare i conflitti.

• Un framework di orchestrazione che semplifica il processo di scrittura di complessi protocolli a più fasi tra più differenti partiti.

Consensus

In Corda, gli aggiornamenti vengono applicati utilizzando le transazioni, che consumano oggetti di stato esistenti e producono nuovi oggetti di stato. Ci sono due aspetti del consenso:
1. Validità della transazione: le parti possono raggiungere la certezza che una transazione di aggiornamento proposta che definisce gli stati di uscita è valida controllando che il codice del contratto associato funzioni correttamente e che abbia tutte le firme richieste; e che tutte le transazioni a cui si riferisce questa transazione sono anche valide.
2. Unicità della transazione: le parti possono raggiungere la certezza che la transazione in questione è il consumatore unico di tutti i suoi stati di input. Cioè: non esiste altra transazione, sulla quale abbiamo precedentemente raggiunto il consenso (validità e unicità), che consuma uno degli stessi stati.

Le parti possono concordare la validità della transazione eseguendo autonomamente lo stesso codice contrattuale e la stessa logica di convalida. Tuttavia, il consenso sull'unicità richiede un osservatore predeterminato, che in molti casi dovrà essere indipendente.

schema3-2 scritto

Figura 3: il consenso sulla validità della transazione viene eseguito solo dalle parti della transazione in questione. Pertanto, i dati vengono condivisi solo con quelle parti che sono obbligate a vederlo. Altre piattaforme generalmente raggiungono il consenso a livello di libro mastro. Pertanto, qualsiasi dato attore in un sistema Corda vede solo un sottoinsieme dei dati complessivi gestiti dal sistema nel suo complesso. Diciamo che un dato è "onledger" se almeno due attori del sistema sono in accordo sulla sua esistenza e sui dettagli e permettiamo alle combinazioni arbitrarie di attori di partecipare al processo di consenso per ogni dato dato. I dati detenuti da un solo attore sono "o ff- ledger".
Corda ha servizi di unicità "collegabili". Questo per migliorare la privacy, la scalabilità, la compatibilità con i sistemi legali e l'agilità algoritmica. Un singolo servizio può essere composto da molti nodi reciprocamente sfuggenti che si coordinano tramite un algoritmo tollerante ai guasti bizantino, o potrebbe essere molto semplice, come una singola macchina. In alcuni casi, come quando l'evoluzione di uno stato richiede la firma di tutte le parti interessate, potrebbe non esserci alcun bisogno di un servizio di unicità. È importante notare che questi servizi di unicità sono richiesti solo per attestare se gli stati consumati da una determinata transazione sono stati precedentemente consumati; non sono tenuti ad attestare la validità della transazione stessa, che è una questione per le parti della transazione. Ciò significa che i servizi di unicità non sono obbligati a (e, nel caso generale, non lo saranno) a vedere l'intero contenuto di tutte le transazioni, migliorando significativamente la privacy e la scalabilità del sistema rispetto ai progetti di libri a distribuzione e blockchain alternativi. Questa decisione progettuale rappresenta una scelta importante per quanto riguarda le tecniche accettabili nelle architetture di condivisioni condivise ed è esplorata in modo più completo nel prossimo whitepaper tecnico.

Business Logic

Corda applica la logica di business attraverso il codice di contratto intelligente, che è costruito come una pura funzione che accetta o rifiuta una transazione e che può essere composta da funzioni più semplici e riutilizzabili. Le funzioni interpretano le transazioni come prendendo gli stati come input e producendo stati di output attraverso l'applicazione di comandi (smart contract) e accettano la transazione se le azioni proposte sono valide. I contratti definiscono parte della logica di business del libro mastro e sono mobili: i nodi scaricheranno ed eseguiranno contratti all'interno di una sandbox senza alcuna revisione in alcune implementazioni, sebbene prevediamo l'uso di codice firmato per implementazioni Corda nella sfera regolamentata. La macchina virtuale che abbiamo selezionato per l'esecuzione e la validazione del contratto è la Java Virtual Machine5, poiché ha una vasta gamma di librerie esistenti e una vasta base di competenze, e il riutilizzo di uno standard industriale rende più facile per le banche riutilizzare il codice esistente all'interno dei contratti. Tuttavia, lo aumentiamo con una sandbox personalizzata che è radicalmente più restrittiva della normale sandbox JVM, e applica non solo i requisiti di sicurezza ma anche l'esecuzione deterministica. Come Ethereum6, la scelta di standardizzare un insieme di bytecode piuttosto che un linguaggio consente agli utenti di innovare nella progettazione del linguaggio contrattuale, o riutilizzare lingue ben conosciute, secondo il gusto. Inoltre, rende facile l'uso diretto del codice del contratto dalle applicazioni interne, una volta che il contratto è stato rivisto, il che dovrebbe semplificare notevolmente lo sviluppo delle applicazioni.

Concetti finanziari centrali

L'architettura di Corda è stata pesantemente influenzata da tre casi d'uso architettonicamente significativi, ritenuti rappresentativi di problemi comuni a cui è probabile che siano mirati. Questi casi d'uso sono: contanti, uno strumento di sicurezza e un contratto derivato. In tutti e tre i casi, li consideriamo come esempi di accordi finanziari:

• Un saldo di cassa (ad es. "La seguente banca e io concordo che mi devono $ 1 milione").

• Un servizio di custodia cautelare (ad es. "La seguente banca depositaria e accetto di possedere 1000 azioni della seguente società").

• Un accordo derivato bilaterale (es. "Le Banche A e B concordano di essere parti del seguente Interest Rate Swap (IRS), il che significa che accettano di scambiare i seguenti flussi di cassa (compensati) a scadenze prestabilite con una formula di pagamento concordata" ).
Prendendo uno di questi esempi, il design di cassa di Corda modella esplicitamente la realtà aziendale che non esiste un "denaro in una banca", solo una richiesta di denaro che un proprietario ha nei confronti di un'istituzione denominata. Quindi il nostro contratto Core in contanti è estremamente semplice, ma potente: registriamo l'identità legale dell'emittente di contanti, la valuta, l'importo, il proprietario (e altre informazioni sulla natura del credito, con un link esplicito alla prosa legale che disciplina l'accordo, che è anche previsto specificare le procedure di risoluzione in caso di controversia) e utilizzarle per costruire tutti gli altri concetti relativi al contante (pagamenti, netting e così via).

schema4

Figura 4: Nel diagramma sopra, vediamo una delle più semplici transazioni Corda: una transazione di emissione. Vediamo la creazione di un nuovo stato di cassa, rilasciato da una banca commerciale a una compagnia di navigazione ufficiale. L'operazione di emissione è firmata dalla banca emittente. Da questo semplice modello, è possibile costruire transazioni notevolmente più complicate, come pagamenti, contratti di consegna contro pagamento e obblighi futuri.

Riassunto del modello Corda

I concetti chiave del nostro modello sono:

• Oggetti di stato, che rappresentano un accordo tra due o più parti, regolati da un codice di contratto leggibile meccanicamente. Questo codice fa riferimento e intende implementare porzioni di prosa legale leggibile.

• Transazioni, quali oggetti dello stato di transizione attraverso un ciclo di vita

• Protocolli di transazione o Business Flow, consentendo alle parti di coordinare le azioni senza un controller centrale.

Il determinismo è massimizzato e la quantità di stato condiviso richiesta viene minimizzata da restrizioni selettive e decisive dell'universo delle tecniche di programmazione consentite. La combinazione di oggetti di stato (dati), codice contratto (operazioni consentite), protocolli di transazione (coreografia di business logic), eventuali API necessarie, plug-in portafoglio e componenti dell'interfaccia utente possono essere pensati per un'applicazione di contabilità condivisa o applicazione distribuita Corda ("CorDapp “). Questo è il nucleo di componenti che uno sviluppatore di contratti sulla piattaforma dovrebbe aspettarsi di costruire.

Confronti con altre piattaforme

Corda è stato creato da un ampio lavoro con i professionisti finanziari ed è stato progettato pensando alle loro esigenze. Tuttavia, il suo design è ispirato anche a lavori precedenti, tra cui quello introdotto negli scritti di Todd Boyle e Ian Grigg sulla contabilità di triple entry e gli aspetti delle piattaforme di contabilità distribuita esistenti come Bitcoin ed Ethereum. Quindi potrebbe essere più facile per le persone che non conoscono Corda capirlo in termini di queste piattaforme.

Confronti con Bitcoin

Corda ha alcune somiglianze significative con Bitcoin:

• Gli stati immutabili che vengono consumati e creati dalle transazioni sono gli stessi.

• Le transazioni hanno più ingressi e uscite. Bitcoin a volte si riferisce al libro mastro come risultato del set di output della transazione non speso (set UTXO).

• Un contratto è pura funzione; i contratti non hanno spazio di archiviazione o la capacità di interagire con nulla. Data la stessa transazione, la funzione "verifica" di un contratto produce sempre esattamente lo stesso risultato.

Tuttavia, una transazione Bitcoin ha un unico e rigido formato di dati e può contenere pochissimi dati oltre a quantità di bitcoin e regole di spesa associate (script). Alcune persone sono state conosciute per cercare di aggirare questa limitazione incorporando i dati in luoghi semi-standardizzati nel codice del contratto in modo che i dati possano essere estratti attraverso la corrispondenza dei modelli, ma questo è un approccio inadeguato. Al contrario, i nostri stati possono includere dati tipizzati arbitrari. Inoltre, le nostre transazioni invocano non solo i contratti di input, ma anche i contratti degli output. L'accettazione di una transazione Bitcoin è controllata solo dal codice del contratto negli stati di input consumati. Usiamo il termine "contratto" per riferirsi a un insieme di logiche di business che può gestire varie attività diverse, al di là della verifica delle transazioni. Ad esempio, attualmente i nostri contratti includono anche il codice per la creazione di transazioni valide (questo è spesso chiamato "codice wallet" in Bitcoin). A uno script Bitcoin può essere assegnato un set fisso di matrici di byte come input. Ciò significa che non è possibile per un contratto esaminare la struttura dell'intera transazione, il che limita fortemente ciò che i contratti possono fare. I nostri contratti sono completi di Turing e possono essere scritti in qualsiasi linguaggio di programmazione ordinario rivolto alla JVM. Corda consente di specificare limiti temporali arbitrariamente precisi nelle transazioni (che devono essere attestate da un timestamp attendibile) piuttosto che basarsi sul momento in cui un blocco viene estratto. Questo è importante dato che molti tipi di contratto che prevediamo supportano richiedono precisione nei tempi e perché le nostre implementazioni di consenso primarie utilizzano algoritmi di risoluzione del conflitto senza blocchi. Va notato che Corda non utilizza Proof of Work o ha un concetto di "mining".

Confronti con Ethereum

Come Ethereum, il codice viene eseguito all'interno di una macchina virtuale relativamente potente e può contenere una logica complessa. I linguaggi di programmazione non assemblati possono essere utilizzati per la programmazione del contratto. Sono entrambi destinati alla modellazione di molti diversi tipi di contratti finanziari. Tuttavia, il termine "contratto" in Ethereum si riferisce ad una istanziazione di un programma che è replicato e mantenuto da ogni nodo partecipante. Questa istanziazione è molto simile a un oggetto in un programma orientato agli oggetti: può ricevere e inviare messaggi, aggiornare la memoria locale e così via. Al contrario, la nostra implementazione del contratto intelligente in codice fa riferimento a un insieme di funzioni, solo una delle quali è una parte del mantenimento del sistema sincronizzato (la funzione di verifica). Questa funzione è pura e senza stato (cioè, potrebbe non interagire con altre parti del sistema durante l'esecuzione). Poiché i contratti non hanno alcun tipo di memoria mutevole, non vi è alcun concetto di "messaggio". Ethereum sostiene inoltre di essere una piattaforma non solo per la logica finanziaria, ma letteralmente per qualsiasi tipo di applicazione. La nostra piattaforma considera le applicazioni non finanziarie fuori dal campo di applicazione, almeno inizialmente.

Roadmap

Per arrivare a questo progetto, abbiamo prima simulato e prototipato componenti di Corda in codice per convalidare aspetti del concetto. Questa è una lista di alcune, ma non tutte, estensioni del modello Corda che dovrebbero essere consegnate nel prossimo medio periodo.

• Transaction Decomposition and Unqueness Enhancements: integrazione dei meccanismi per oscurare selettivamente parti di transazioni, inclusa l'offuscamento dai servizi di unicità.

• Sandbox Veri fi cazione del contratto: whitelist esplicita del link-time di un insieme aggressivamente minimo di librerie Java. • Un portafoglio basato su plug-in per l'inferenza della posizione.

• Calcolo di oracoli o gateway a esecutori di logica di business proprietari (o altri) (ad esempio, Controparti centrali o agenti di valutazione) che possono essere veri fi cati sui registri dai partecipanti.

• Utilizzo del modello Corda per gestire l'identità degli utenti.

• Interoperabilità e integrazione dei dati, in particolare rispetto a FpML, ISO20022, supporto per altri formati di dati e integrazione / interoperabilità con altre piattaforme.

• Creazione di applicazioni per i dati di riferimento.

• Miglioramenti della privacy che utilizzano tecnologie come la randomizzazione degli indirizzi, prove a conoscenza zero, schemi di rielaborazione delle risorse.

• Contratti di riferimento per ulteriori strumenti finanziari.

• Supporto nativo della logica di business a livello di portafoglio, come le aggregazioni di oggetti di stato.

Conclusioni

In contrasto con la maggior parte delle piattaforme esistenti di libri contabili e blockchain oggi, Corda è stata costruita con lo scopo esplicito di registrare e far rispettare gli accordi commerciali tra le istituzioni finanziarie registrate; non è destinato a essere una soluzione generica per tutti i problemi. In quanto tale, assume un approccio unico alla distribuzione dei dati e alla semantica delle transazioni mantenendo le caratteristiche dei registri distribuiti che hanno prima attratto le istituzioni in progetti come R3, ovvero l'esecuzione affidabile degli accordi finanziari in modo automatizzabile e applicabile.