Marzo 2019

Volume 34 Numero 3

Il presente articolo è stato tradotto automaticamente.

[Blockchain]

Verifica i documenti elettronici con gli smart contract in Azure Blockchain Development Kit

Dal Stefano Tempesta | Marzo 2019

L'introduzione di smart Contract nelle reti di blockchain ha creato un livello di logica di business che non è presente nelle prime iterazioni di blockchain. Smart Contract offrono la possibilità di applicare la logica condizionale per le transazioni prima che vengono eseguiti. Comunque, smart Contract possono operare solo sui dati archiviati sulla contabilità digitale blockchain. Processi di business, tuttavia, raramente eseguiti in isolamento. Spesso necessitano di integrazione dei dati con sistemi esterni e dispositivi.

Processi, ad esempio, potrebbero includere transazioni avviate su un libro mastro distribuito che usa i dati originati da un sistema esterno, un servizio o un dispositivo. I sistemi esterni potrebbero essere necessario per rispondere agli eventi generati da smart Contract in risposta a una logica di convalida. Questo articolo descrive come automatizzare il segno di documento e verificare i flussi di lavoro in SharePoint con il Kit di sviluppo di Blockchain Azure rilasciate di recente (aka.ms/bcdevkit) per rendere persistenti i file hash e i metadati su una blockchain libro mastro digitale.

Kit di sviluppo di Blockchain di Azure

La versione di Azure Blockchain Development Kit, basato sulla tecnologia senza server di Microsoft, rappresenta un'attività cardine nell'adozione di tecnologie della blockchain nello spazio dell'organizzazione. Grazie al Kit di sviluppo di Blockchain, è ora possibile compilare soluzioni che integrano blockchain con il meglio di Microsoft e applicazioni software di terze parti. Come indicato nel relativo note sulla versione, la versione iniziale del kit assegna la priorità alle funzionalità relative ai tre temi principali: la connessione delle interfacce, l'integrazione di sistemi e dati e la distribuzione di reti di blockchain e smart Contract.

Connessione sono inclusi i canali di comunicazione, ad esempio dispositivi mobili e Web, SMS e vocali, nonché dispositivi IoT e persino chat BOT. Integrazione con applicazioni line-of-business si estende su più sistemi, tra cui SharePoint, OneDrive for Business, Dynamics 365, open source di e qualsiasi piattaforme abilitata per le API, nonché i protocolli legacy, ad esempio i file System, i server FTP o database SQL. La distribuzione di reti di blockchain e smart Contract verrà aiutare la tecnologia blockchain "Mainstream" nello sviluppo di software aziendale e introdurre DevOps e la governance per le procedure di sviluppo software di blockchain.

Kit di sviluppo di Blockchain funziona in combinazione con le App per la logica di Azure e il flusso, che forniscono un ambiente di progettazione visiva per flussi di lavoro che includono più di 200 connettori per servizi e sistemi di terze parti e Microsoft. In concerto, semplificano notevolmente lo sviluppo di applicazioni blockchain end-to-end a cui accedere ai dati in lettura e fuori dalla catena, gestire gli eventi generati per la contabilità digitale e sfruttare l'ecosistema di Azure per una soluzione semplice e integrata. Esaminiamo un'applicazione pratica nel contesto della gestione del contenuto aziendale.

Firmare elementi digitali

Con blockchain, è possibile immaginare un mondo in cui i documenti sono incorporati nel codice digitali e archiviati nei database trasparenti e condivisi, in cui che sono protette dalla revisione, manomissione e l'eliminazione. In questo mondo ogni contratto, ogni processo, tutte le attività e ogni pagamento sarebbe necessario un record digitale e la firma che può essere identificata, convalidata, archiviata e condivisi. Intermediari, ad esempio gli avvocati, Broker e istituti potrebbero non essere più necessari. Persone, organizzazioni e le macchine sarebbero liberamente transact e interagiscono tra loro con attrito poco. Questo è il potenziale enorme della blockchain.

L'applicazione potenziale di decentramento contenuto e la distribuzione è enorme. Con un archivio record singolo, non modificabile e verificabile, persone conterrà i record e l'identità digitale, ovvero si tratta di identità o residenza documenti, cartelle cliniche dei pazienti, didattici o professionisti certificati e licenze. Tutti questi documenti e i relativi metadati possono essere rilasciati nella blockchain ed essere firmati digitalmente. Non è più simulare le certificazioni, nessun mills grado più, non più di "photoshopped" paper.

Gli studenti, ad esempio, possono richiedere abbonamenti ulteriore study, un processo o conformità a un altro paese; e nel processo potrebbe essere richiesto di dimostrare il livello di studi o conoscenza del linguaggio per la partecipazione university. Le entità, ad esempio dei reclutatori, datori di lavoro, gli enti governativi e università possibile verificare le credenziali di student senza basarsi su autorità centrale, in pochi minuti e con alcun agli altri intermediari.

Figura 1 descrive lo scenario indicato. I certificati vengono rilasciati da un'autorità, ad esempio un istituto di istruzione (1), archiviata in un server di gestione centralizzata dei documenti (2), o in un file system distribuito, ad esempio pagina non valida (ipfs.io) e firmati con una funzione di crittografia. Più avanti nell'articolo mi porto in informazioni sulla pagina non valida. L'hash del contenuto e hash dei metadati del certificato sono archiviate sulla blockchain digitale contabilità (3) e quindi collegati alle identità digitali dell'utente come un indirizzo di contratto intelligente che archivia le informazioni (4). Rappresenta una sorta di token, autenticità univoco che identifica il documento in modo non dubbie.

Gli attori e processo di firma
Figura 1, gli attori e processo di firma

Un modello comune consiste nel generare un hash univoco dell'asset digitali e un hash univoco dei metadati che lo descrive. Questi hash vengono quindi archiviati in una blockchain. Se l'autenticità di un documento viene messo in discussione, il file fuori dalla catena può essere nuovamente con hash in un secondo momento e tale hash rispetto al valore nella catena. Se i valori hash corrispondono, il documento sia autentico, ma se solo un carattere in un documento viene modificato, l'hash non corrispondono, rendere evidente che si è verificata una modifica.

Compilare il flusso di App per la logica firma

Esaminiamo una potenziale implementazione del flusso di lavoro con App per la logica di Azure. Il flusso di App per la logica verrà generare un hash di documento e i metadati e archiviare la precedente in SharePoint e quest'ultimo in una rete Ethereum, usando il connettore Ethereum disponibile come parte del Kit di sviluppo Blockchain di Azure. Il calcolo del valore hash viene eseguito in una funzione di Azure basato sullo stack di runtime di .NET. La funzione si basa sul modello di trigger HTTP e verrà eseguito non appena viene ricevuta una richiesta HTTP.

Il codice nel figura 2 implementa la funzione di Azure ComputeHashFunction per calcolare un hash mediante l'algoritmo SHA256. Dopo aver letto il corpo della richiesta nel metodo Run, la funzione calcola l'hash usando la libreria SHA256 disponibile nello spazio dei nomi Cryptography. Il valore hash viene restituito sotto forma di stringa con codifica UTF8.

Figura 2 i ComputeHashFunction

public static class ComputeHashFunction
{
  [FunctionName("ComputeHashFunction")]
  public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function,
      "get", "post", Route = null)] HttpRequest req, ILogger log)
  {
    string requestBody =
      await new StreamReader(req.Body).ReadToEndAsync();
    string hash = ComputeHash(requestBody);
    return (ActionResult)new OkObjectResult(hash);
  }
  private static string ComputeHash(string data)
  {
    // Create a SHA256 hash
    using (SHA256 sha256 = SHA256.Create())
    {
      byte[] bytes = sha256.ComputeHash(Encoding.UTF8.GetBytes(data));
      // Convert the byte array to a string
      return Encoding.UTF8.GetString(bytes);
    }
  }
}

Il flusso di App per la logica viene attivato quando un nuovo documento viene caricato in un sito di SharePoint. Questo evento viene gestito da uno del "quando viene creato un file..." le azioni del connettore SharePoint (come illustrato nella figura 3). Per configurare questa azione, dopo aver immesso le credenziali di autenticazione per SharePoint, è necessario specificare l'indirizzo del sito del sito di SharePoint da monitorare per i nuovi file e la cartella specifica in cui vengono caricati i file. È anche possibile impostare la frequenza di polling in questa cartella e il controllo dei nuovi file. Un'impostazione ragionevole consiste nel controllare una volta al minuto.

L'azione di App per la logica che gestisce l'evento di creazione di File in SharePoint
Figura 3 l'azione di App per la logica che gestisce l'evento di creazione di File in SharePoint

Il passaggio successivo nel flusso è, come già anticipato, l'hash del contenuto e metadati del file caricato. Come ho implementato la funzione di hashing come una funzione di Azure, è sufficiente per richiamare questa funzione è scegliere un'azione di funzioni di Azure dal connettore di funzioni di Azure. Dopo aver selezionato ComputeHashFunction dall'elenco di funzioni disponibili, verrà richiesto di specificare il corpo della richiesta che verrà passato alla funzione stessa. Si tratta di un oggetto JSON che verrà trasferito nell'input della funzione, ottenere il valore hash come output. Ho definito i seguenti attributi come i metadati del file, come illustrato nella figura 4: contentType, etag, id, nome e percorso.

Attributi nel corpo della richiesta per la funzione Hash
Figura 4 attributi nella richiesta corpo per la funzione Hash

Il passaggio precedente è necessario eseguire l'hashing i metadati del file. A questo punto afferma hash anche l'intero contenuto del file, per mantenere lo stato non modificabile in rete blockchain. Come prima, aggiungere un altro scegliere un'azione di funzioni di Azure da del connettore di funzioni di Azure, ma questa volta, anziché gli attributi di file diversi, selezionare File di contenuto.

Dopo aver ottenuto i valori hash per i metadati del file sia il contenuto di file, è possibile archiviarli in rete blockchain. Per questo scopo, ho utilizzato Azure Blockchain Workbench (aka.ms/abcworkbench) come ambiente di runtime per smart Contract in esecuzione su Ethereum. Blockchain Workbench è previsto il supporto di più piattaforme di blockchain, ma per ora verrà illustrata la procedura Ethereum.

È possibile ottenere l'accesso per la contabilità digitale inviando un messaggio al Bus di servizio di Azure distribuito come parte della soluzione Blockchain Workbench. Un sistema esterno, ad esempio un'azione dell'App per la logica può comunicare con un contratto smart ospitato in Blockchain Workbench inviando un messaggio al Bus di servizio. Il messaggio viene prelevato dal runtime di Blockchain Workbench e viene creata una nuova transazione di blockchain, che contiene il messaggio. Comunicazione con Ethereum può verificarsi solo tramite la generazione di una transazione che richiama un contratto intelligente, come illustrato nella figura 5.

Invia un messaggio a un contratto intelligente
Figura 5 l'invio di un messaggio a un contratto intelligente

Per inviare un messaggio da un flusso di App per la logica al Bus di servizio è possibile usare l'azione invio messaggio del connettore del Bus di servizio. Una connessione a un Bus di servizio di Azure è identificata da un nome di connessione e una stringa di connessione. È possibile immettere qualsiasi nome si ritenga opportuno come nome della connessione e ottenere la stringa di connessione del Bus di servizio dal portale di Azure in cui viene distribuito. Inoltre, il messaggio da inviare al Bus di servizio richiede i parametri seguenti:

  • requestId: Un identificatore univoco per la richiesta generata dall'azione di App per la logica
  • processedDateTime: Timestamp della richiesta inviata
  • userChainIdentifier: Indirizzo di utente nella rete Ethereum distribuita
  • applicationName: Nome del contratto smart richiamato su Ethereum
  • workflowName: Nome del flusso di lavoro richiamato nella Blockchain Workbench

Questi parametri è possibile definire come variabili nel flusso di App per la logica, usando l'azione di variabile Initialize dal connettore di variabili. L'ID richiesta può essere impostata su guid, che è un'espressione che genera un GUID univoco. La variabile processedDateTime può essere impostata su utcNow, che rappresenta l'ora corrente. Per userChainIdentifier, è possibile immettere l'indirizzo di un utente nella Blockchain Workbench che è autorizzato a eseguire il contratto intelligente, mentre applicationName e workflowName sono definiti in base al nome e il flusso di lavoro del contratto intelligente che elabora questa transazione.

Nella sezione successiva descrive il contratto intelligente per l'elaborazione di questi messaggi inviati dal flusso di App per la logica. Figura 6 riepiloga il corpo del messaggio, in formato JSON, per inviare al Bus di servizio. Le espressioni in < parentesi ad angolo acuto > devono essere sostituiti con il valore corrispondente.

Figura 6 struttura del messaggio inviato al Bus di servizio di Azure

{
  "requestId": "<The requestId variable>",
  "userChainIdentifier": "<User address in Azure Blockchain Workbench>",
  "applicationName": "<Smart contract name>",
  "workflowName": "<Smart contract workflow name>",
  "parameters": [
    {
      "name": "registryAddress",
      "value": "<Contract address in Azure Blockchain Workbench>"
    },
    {
      "name": "fileId",
      "value": "<File identifier>"
    },
    {
      "name": "location",
      "value": "<File path>"
    },
    {
      "name": "fileHash",
      "value": "<File content hash>"
    },
    {
      "name": "fileMetadataHash",
      "value": "<File metadata hash>"
    },
    {
      "name": "contentType",
      "value": "<File content type>"
    },
    {
      "name": "etag",
      "value": <File entity tag>
    },
    {
      "name": "processedDateTime",
      "value": "<The processedDateTime variable>"
    }          
  ],
  "connectionId": 1,
  "messageSchemaVersion": "1.0.0",
  "messageName": "CreateContractRequest"
}

Contratto intelligente per l'elaborazione di risorse digitali

Prima di tutto, è possibile rafforzare il messaggio che non sono archiviate risorse digitali su blockchain. Sono valori hash dei metadati di file e del contenuto. In questo articolo è descrivere l'archiviazione dei documenti in SharePoint, che è un servizio centralizzato. In una distribuzione di blockchain "pure", è possibile ottenere decentramento inoltre del servizio di archiviazione. Il Interplanetary File System (pagina non valida) è un protocollo peer-to-peer ipermedia (che ho menzionato in precedenza) che fornisce l'archiviazione file decentralizzata. Integrazione con pagina non valida non rientra nell'ambito di questo articolo, ma se si è interessati a sapere come questa tecnologia consente di rimuovere la centralizzazione dell'archiviazione che non fa parte di un blocco in una blockchain, è possibile vedere il video "Pagina non valida in Azure" su Channel 9 (bit.ly/2CURRq0).

Come si usa Azure Blockchain Workbench per l'esecuzione di mio contratto intelligente, ho bisogno di due file:

  • FileContract.sol per descrivere il contratto intelligente stesso, nel linguaggio di programmazione Solidity.
  • FileContract.json per configurare il flusso di lavoro viene caricato in Azure Blockchain Workbench come applicazione.

Il contratto smart FileContract descrive un file tramite i relativi metadati, in base ai valori passati nel messaggio inviato dall'App per la logica di Blockchain Workbench tramite il Bus di servizio di Azure. Ecco un frammento del codice sorgente del contratto intelligente che definisce questi parametri:

contract FileContract
{
  // File metadata
  string public FileId; // File identifier
  string public Location; // File path
  string public FileHash; // File content hash
  string public FileMetadataHash; // File Metadata Hash
  string public ContentType; // File content type
  string public Etag; // File entity tag
  string public ProcessedDateTime; // Timestamp
  address public User; // User address

Per archiviare i metadati del file in una blockchain, ho bisogno di una struttura di file definita, come indicato di seguito:

struct File {
  string FileId;
  address FileContractAddress;
}

Un'entità di file è identificata dal relativo ID di file e l'indirizzo nella blockchain kontraktu FileContract intelligente che contiene i metadati. Questa struttura viene salvata in una raccolta privata definita come un dizionario, la cui chiave corrisponde alla stringa FileId. La parola chiave mapping in Solidity definisce un dizionario e i relativi tipi di chiave e valore come indicato di seguito:

mapping(string => File) private Registry;

Per salvare un entità file (ID e metadati), aggiungere semplicemente i valori che costituiscono per il dizionario del Registro di sistema nel metodo Save. Per semplicità, ho omesso qualsiasi controllo necessario sulla validità dell'indirizzo, ID e il contratto di file e indica se il file esiste già nel Registro di sistema. Il codice è il seguente:

function Save(string fileId, address fileContractAddress) public
{
  Registry[fileId].FileId = fileId;
  Registry[fileId].FileContractAddress = fileContractAddress;
}

Il processo di verifica

Gli utenti che hanno bisogno di verificare i certificati con una terza parte farlo condividendo il token di autenticità (vale a dire, il file del contratto indirizzo), che contiene tutte le informazioni necessarie per verificare che il documento esista e sia autentico e non contraffatte. Figura 7 descrive le entità e le azioni coinvolti nel processo di verifica. L'utente recupera il certificato per la verifica dal relativo percorso (1) e avvia una nuova transazione sulla rete, blockchain trasferimento il token di autenticità (2) all'autorità di verifica. L'autorità Ottiene il contenuto firmato e i metadati del certificato da verificare (3), che viene archiviato sulla contabilità digitale modificabile e vengono quindi confrontate con i valori hash equivalente dalla copia fuori dalla catena. Se i valori corrispondono, il documento è verificato (4).

Il processo e gli attori di verifica
Figura 7 il processo e gli attori di verifica

Dopo che sono firmati e verificati i documenti e dati non strutturati, e un hash del contenuto e i metadati vengono archiviati in una blockchain, crea un oggetto non modificabile e verificabile e indipendente dalla registrazione delle transazioni. Questo processo è definito come prova dell'esistenza e la dimostrazione di autenticità di asset digitali.

Verifica dell'esistenza fa riferimento alla creazione di una data non modificabile e un timestamp per un oggetto specifico. Ciò significa che è possibile dimostrare che un determinato oggetto di informazioni, come un messaggio di posta elettronica, documenti o immagine, ovvero esistenti in un determinato punto nel tempo.

Verifica dell'autenticità asserisce che un oggetto sia autentico, vale a dire, non è stato modificato dopo l'archiviazione al momento indicato immediata. Questa operazione viene eseguita la firma digitale di un oggetto e quindi di creare un hash, il relativo identificatore univoco. L'identificatore quindi ottiene eseguito il commit nel libro mastro blockchain distribuita e la transazione Ottiene timestamp, nonché. Poiché ogni voce nella finestra di blockchain è modificabile, significa che si dispone di prova di esistenza di questo oggetto specifico in un determinato punto nel tempo.

Usa lo stesso approccio, un oggetto è possibile verificare e convalidare. Un flusso simile a quello che descritto per il processo di firma crea un identificatore univoco e viene verificato questo identificatore univoco per la contabilità di blockchain. Se non esiste una corrispondenza, il contratto smart restituisce il valore hash originale. In caso contrario, il documento in fase di verifica non è identico a quella originale e non deve essere attendibile in modo implicito. In questo modo, sarà possibile, non solo qualsiasi dubbio, per dimostrare che il documento o qualsiasi oggetto digitale, siano autentico ed esistente in un determinato momento.

Il contratto smart FileContract espone un metodo GetFile che, dato un ID di file input e restituisce il relativo indirizzo di contratto di blockchain. Dall'indirizzo di contratto del file è possibile ottenere il contenuto del file e metadati valori hash e confronta con i valori hash del documento in fase di verifica, nel modo seguente:

function GetFile(string fileId) public constant
returns(address fileContractAddress)
{
  return Registry[fileId].FileContractAddress;
}

Conclusioni

Perché usare blockchain per firmare e verificare le risorse digitali, quando le soluzioni per la firma elettronica esistano già e sono ampiamente adottate nel settore? In breve, blockchain eliminare la necessità di un autorità di certificazione centrale o un server centrale timestamp e abilitare le firme digitali archiviate in una blockchain durata (TTL) indipendentemente dall'oggetto viene apposta la firma. Verrà aperta per le opportunità per la verifica della firma parallelo e indipendente, con o senza l'oggetto stesso.

Le soluzioni tradizionali di firma e archiviano le firme digitali all'interno del documento. Ciò significa che chiunque deve controllare se viene firmato un documento avrà accesso in lettura completo a tutto il contenuto del documento. Inoltre, poiché il documento viene modificato con ogni firma, la firma dei documenti in parallelo non è possibile: deve essere affermativa; firmare il documento in modo sequenziale. Per la firma dei documenti in una blockchain, l'oggetto stesso non viene modificato tramite la firma e in questo modo è possibile firmare i documenti in parallelo e implementare regole di business basate su mandati, 4-eyes, voto maggioranza dei nodi, anzianità e simili.

Infine, ma non meno importante, è possibile registrare più azioni in una sequenza in una blockchain. Ogni registrazione è collegato a un caso specifico, documenti e attività eseguite dalle parti coinvolte, creando una catena di transazioni: un itinerario controllabile. Questa traccia di controllo può essere verificato da terze parti autorizzate, fornendo la trasparenza, conformità e, ancora più importante, considerare attendibile.

Per altre informazioni su Azure Blockchain Development Kit, è possibile trovare una serie di video su Channel 9, Mostra "Parlare di blocco" (aka.ms/bcblocktalk). Se si desidera, è inoltre possibile essere aggiornati con gli annunci più recenti del team del prodotto Azure Blockchain seguendo l'handle di Twitter @MSFTBlockchain (twitter.com/MSFTBlockchain).

Il progetto Azure Blockchain Development Kit è lieta di ricevere contributi e suggerimenti. La maggior parte dei contributi è necessario accettare a un collaboratore contratto di licenza (CLA) dichiara di avere il diritto di ed effettivamente concede, Microsoft i diritti di utilizzo al contributo. Quando si invia una richiesta pull, un bot CLA determinerà automaticamente se è necessario fornire un CLA e decorare la richiesta in modo appropriato (che è, aggiungere etichette o commenti al codice).


Stefano Tempestaè un Microsoft Regional Director, MVP su intelligenza artificiale e applicazioni aziendali e membro del Consiglio di Blockchain. Partecipa regolarmente come oratore a conferenze IT internazionali, tra cui Microsoft Ignite e Tech Summit, interessi di Tempesta estendono blockchain e tecnologie correlate per intelligenza artificiale. Ha creato "Blogchain spazio" (blogchain.space), un blog sulle tecnologie della blockchain, scrive per MSDN Magazine e MS Dynamics e pubblica esperimenti di machine learning in Azure AI Gallery.

Grazie al seguente esperto tecnico per la revisione dell'articolo: Jonathan Waldman