Een Blockchain-platform voor de onderneming
Goedemiddag, beste lezers, mijn naam is Nikolai Nefedov, ik ben een technische IBM-specialist, in dit artikel wil ik u kennis laten maken met het blockchain-platform - Hyperledger Fabric. Het platform is bedoeld voor het bouwen van bedrijfsapplicaties op bedrijfsniveau (Enterprise-klasse). Het niveau van het artikel is voor onvoorbereide lezers met basiskennis van IT-technologieën.
Hyperledger Fabric is een open-sourceproject, een van de takken van het Hyperledger open source-project, een consortium van de Linux Foundation. Hyperledger Fabric is oorspronkelijk gelanceerd door Digital Assets en IBM. Het belangrijkste kenmerk van het Hyperledger Fabric-platform is de focus op bedrijfstoepassingen. Daarom is het platform ontwikkeld rekening houdend met de hoge transactiesnelheid en hun lage kosten, evenals met de identificatie van alle deelnemers. Deze voordelen worden bereikt door de transactieverificatieservice te scheiden en nieuwe blokken van het gedistribueerde register te vormen, evenals door een certificeringsinstantie te gebruiken en deelnemers te autoriseren.
Mijn artikel maakt deel uit van een reeks artikelen over Hyperledger Fabric waarin we het project beschrijven van een systeem voor het registreren van studenten die een universiteit binnenkomen.
Algemene architectuur van Hyperledger Fabric
Hyperledger Fabric is een gedistribueerd blockchain-netwerk dat bestaat uit verschillende functionele componenten die op netwerkknooppunten zijn geïnstalleerd. Hyperledger Fabric-componenten zijn Docker-containers die gratis kunnen worden gedownload van DockerHub. Hyperledger Fabric kan ook worden uitgevoerd in een Kubernetes-omgeving.
Om slimme contracten (kettingcode in de context van Hyperledger Fabric) te schrijven, gebruikten we Golang (hoewel je met Hyperledger Fabric ook andere talen kunt gebruiken). Om een aangepaste applicatie te ontwikkelen, werd in ons geval Node.js gebruikt met de bijbehorende Hyperledger Fabric SDK.
De knooppunten voeren bedrijfslogica (slim contract) uit - kettingcode, slaan de status van het gedistribueerde register op (grootboekgegevens) en voeren andere platformsysteemservices uit. Een node is slechts een logische eenheid, er kunnen verschillende nodes op dezelfde fysieke server bestaan. Veel belangrijker is hoe de knooppunten zijn gegroepeerd (vertrouwd domein) en met welke functies van het blockchain-netwerk ze zijn geassocieerd.
De algemene architectuur ziet er als volgt uit:
Afbeelding 1. Algemene architectuur van Hyperledger Fabric
Gebruikersapplicatie (Submitting Client) is een applicatie waarmee gebruikers werken met het blockchain netwerk. Om te werken, moet u autorisatie doorlopen en de juiste rechten hebben voor verschillende soorten acties op het netwerk.
Peers (Nodes) hebben verschillende rollen:
- Endorsing Peer is een node die de uitvoering van een transactie simuleert (voert de slimme contractcode uit). Na het valideren en uitvoeren van het slimme contract, stuurt het knooppunt de uitvoeringsresultaten samen met de handtekening terug naar de clienttoepassing.
- Ordering Service is een gedistribueerde service op verschillende knooppunten, het wordt gebruikt om nieuwe blokken van het gedistribueerde grootboek te vormen en een reeks te maken voor het uitvoeren van transacties. Ordering Service voegt geen nieuwe blokken toe aan het register (verplaatst naar Comitting Peers voor betere prestaties).
- Comitting Peer - een knooppunt dat een gedistribueerd register bevat en nieuwe blokken aan het register toevoegt (die zijn gevormd door de bestelservice). Alle Comitting Peers bevatten een lokale kopie van het gedistribueerde grootboek. De Comitting Peer controleert, alvorens lokaal een nieuw blok toe te voegen, alle transacties binnen het blok op geldigheid.
Endorsement Policy is een beleid om een transactie op geldigheid te controleren. Dit beleid definieert de noodzakelijke set knooppunten waarop het slimme contract moet worden uitgevoerd om de transactie als geldig te laten erkennen.
Het Distributed Registry - Lerger - bestaat uit twee delen: WolrldState (ook wel State DataBase genoemd) en BlockChain.
BlockChain is een keten van blokken die records opslaat van alle wijzigingen die zijn opgetreden in gedistribueerde grootboekobjecten.
WolrldState is een gedistribueerde registercomponent die de huidige (extreme) waarden van alle gedistribueerde registerobjecten opslaat.
WorldState is een database, in de basisversie - LevelDB of complexer - CouchDB, die sleutel-waardeparen bevat, bijvoorbeeld: Voornaam - Ivan, Achternaam - Ivanov, registratiedatum in het systeem - 12.12.21/17.12.1961/XNUMX, datum van geboorte - XNUMX/XNUMX/XNUMX, enz. WorldState en het gedistribueerde grootboek moeten consistent zijn voor alle leden van een bepaald kanaal.
Aangezien Hyperledger Fabric een netwerk is waarin alle deelnemers bekend en geverifieerd zijn, wordt hier een speciale certificeringsinstantie gebruikt - CA (Certification Authority). CA werkt op basis van de X.509-standaard en public key infrastructure - PKI.
Lidmaatschapsservice is een service waarmee leden verifiëren dat een object bij een bepaalde organisatie of kanaal hoort.
Een transactie is in de meeste gevallen een vastlegging van nieuwe gegevens in een gedistribueerd grootboek.
Er zijn ook transacties voor het creëren van kanalen of slimme contracten. De transactie wordt geïnitieerd door de gebruikerstoepassing en eindigt met een schrijven naar het gedistribueerde grootboek.
Channel (Channel) is een gesloten subnet bestaande uit twee of meer deelnemers in het blockchain-netwerk, ontworpen om vertrouwelijke transacties uit te voeren binnen een beperkte, maar bekende kring van deelnemers. Het kanaal wordt bepaald door de deelnemers, het gedistribueerde grootboek, slimme contracten, bestelservice, WorldState. Elk kanaallid moet geautoriseerd zijn om toegang te krijgen tot het kanaal en het recht hebben om verschillende soorten transacties uit te voeren. Autorisatie wordt uitgevoerd met behulp van de Lidmaatschapsservice.
Typisch transactie-uitvoeringsscenario
Vervolgens wil ik het hebben over een typisch scenario voor het uitvoeren van een transactie aan de hand van het voorbeeld van ons project.
Als onderdeel van ons interne project hebben we een Hyperledger Fabric-netwerk gemaakt, dat is ontworpen om studenten die naar universiteiten komen te registreren en te registreren. Ons netwerk bestaat uit twee organisaties, eigendom van Universiteit A en Universiteit B. Elke organisatie bevat een klantapplicatie, evenals een eigen Comitting en Endorsing Peer. Daarnaast maken wij gebruik van de gebruikelijke Bestelservice, Lidmaatschapsservice en Certificatie Autoriteit.
1) Transactie-initiatie
De gebruikerstoepassing start met behulp van de Hyperledger Fabric SDK een transactieverzoek en stuurt het verzoek naar knooppunten met slimme contracten. Het verzoek kan zijn om te wijzigen of uit een gedistribueerd grootboek (Ledger) te lezen. Als we een voorbeeld bekijken van onze testconfiguratie van het systeem voor boekhouding voor universiteitsstudenten, dan stuurt de clienttoepassing een transactieverzoek naar de knooppunten van universiteiten A en B, die zijn opgenomen in het goedkeuringsbeleid van het zogenaamde slimme contract. Knooppunt A is een knooppunt dat zich bevindt op de universiteit die een inkomende student registreert, en knooppunt B is een knooppunt dat zich op een andere universiteit bevindt. Om een transactie op te slaan in een gedistribueerd grootboek, is het noodzakelijk dat alle knooppunten die volgens de bedrijfslogica de transactie moeten goedkeuren, met succes slimme contracten uitvoeren met hetzelfde resultaat. De gebruikerstoepassing van knooppunt A ontvangt met behulp van de Hyperledger Fabric SDK-tools het goedkeuringsbeleid (goedkeuringsbeleid) en zoekt uit naar welke knooppunten een transactieverzoek moet worden verzonden. Dit is een verzoek om een bepaald slim contract (kettingcodefunctie) aan te roepen (aan te roepen) om bepaalde gegevens naar het gedistribueerde grootboek te lezen of te schrijven. Technisch gezien gebruikt de client-SDK de overeenkomstige functie, waarvan de API een object met transactieparameters wordt doorgegeven, en voegt ook een clienthandtekening toe en stuurt deze gegevens via protocolbuffer over gRPC naar de juiste knooppunten (endorsing peers).
Afbeelding 2. Transactie-initiatie
2) Slimme contractuitvoering
Nodes (Endorsing Peers), die een verzoek hebben ontvangen om een transactie uit te voeren, de handtekening van de klant controleren en als alles in orde is, nemen ze een object met de verzoekgegevens en voeren een simulatie uit van de uitvoering van een slim contract (kettingcodefunctie) met deze gegevens. Een smart contract is de zakelijke logica van een transactie, een bepaalde set voorwaarden en instructies (in ons geval is dit een studentencheque, is het een nieuwe student, of is hij al ingeschreven, leeftijdscontrole, enz.). Om een smart contract uit te voeren, heb je ook gegevens van WorldState nodig. Als resultaat van de slimme contractsimulatie op de Endorsing-peer, worden twee datasets verkregen: leesset en schrijfset. Read Set en Write Set zijn de oorspronkelijke en nieuwe WorldState-waarden. (nieuw - in de zin verkregen door een slim contract te simuleren).
Afbeelding 3. Slimme contractuitvoering
3) Gegevens terugsturen naar de clienttoepassing
Na de simulatie van het slimme contract sturen Endorsing Peers de initiële gegevens en het resultaat van de simulatie terug naar de clienttoepassing, evenals de RW-set ondertekend door hun certificaat. In dit stadium zijn er geen wijzigingen in het gedistribueerde grootboek. De clienttoepassing verifieert de handtekening van de Endorsing Peer en vergelijkt ook de originele transactiegegevens die zijn verzonden en de gegevens die zijn geretourneerd (dat wil zeggen, er wordt gecontroleerd of de originele gegevens waarop de transactie is gesimuleerd, beschadigd zijn). Als de transactie alleen bedoeld was voor het lezen van gegevens uit het register, ontvangt de clienttoepassing dienovereenkomstig de benodigde leesset en hierop wordt de transactie meestal met succes voltooid zonder het gedistribueerde register te wijzigen. Bij een transactie die de gegevens in het register moet wijzigen, controleert de clienttoepassing bovendien of het Endorsing-beleid is geïmplementeerd. Het is mogelijk dat de clienttoepassing het resultaat van de uitvoering van het goedkeuringsbeleid niet controleert, maar het Hyperledger Fabric-platform zorgt in dit geval voor het controleren van het beleid op de knooppunten (Comitting Peers) in de fase van het toevoegen van een transactie aan het register.
Afbeelding 4. Gegevens terugsturen naar de clienttoepassing
4) RW-sets naar bestellende peers sturen
De clienttoepassing stuurt de transactie samen met de bijbehorende gegevens naar de bestelservice. Dit omvat de RW-set, handtekeningen van onderschrijvende peers en de kanaal-ID.
Bestelservice - op basis van de naam is de belangrijkste functie van deze service om inkomende transacties in de juiste volgorde op te bouwen. Evenals de vorming van een nieuw blok van het gedistribueerde register en gegarandeerde levering van nieuw gegenereerde blokken aan alle Commiting-knooppunten, waardoor gegevensconsistentie wordt gegarandeerd op alle knooppunten die het gedistribueerde register bevatten (Committing-peers). Tegelijkertijd verandert de bestelservice zelf het register op geen enkele manier. Bestelservice is een essentieel onderdeel van het systeem, dus het is een cluster van verschillende knooppunten. De Bestelservice controleert de transactie niet op geldigheid, maar accepteert gewoon een transactie met een specifiek kanaal-ID, rangschikt inkomende transacties in een specifieke volgorde en vormt daaruit nieuwe blokken van het gedistribueerde grootboek. Eén Besteldienst kan meerdere kanalen tegelijkertijd bedienen. De Bestelservice bevat een Kafka-cluster, die de juiste (onveranderde) transactiewachtrij bijhoudt (zie punt 7).
Afbeelding 5. RW-sets verzenden naar bestellende peers
5) De gegenereerde blokken naar de Comitting Peer sturen
De in de Bestelservice gevormde blokken worden naar alle netwerkknooppunten uitgezonden. Elk knooppunt, dat een nieuw blok heeft ontvangen, controleert of het voldoet aan het Endorsing-beleid, controleert of alle Endorsing Peers hetzelfde resultaat (Write Set) hebben ontvangen als resultaat van de slimme contractsimulatie, en controleert ook of de oorspronkelijke waarden zijn gewijzigd (dat wil zeggen - Read Set - gegevens gelezen door het slimme contract van WorldState) sinds de start van de transactie. Als aan alle voorwaarden is voldaan, wordt de transactie als geldig gemarkeerd, anders krijgt de transactie de status niet geldig.
Afbeelding 6. Gegenereerde blokken naar de Comitting Peer sturen
6) Een blok toevoegen aan het register
Elk knooppunt voegt een transactie toe aan zijn lokale kopie van het gedistribueerde grootboek en als de transactie geldig is, wordt Write Set toegepast op de WorldState (huidige status), respectievelijk worden nieuwe waarden van objecten die door de transactie zijn beïnvloed, geschreven . Als een transactie een token heeft ontvangen dat niet geldig is (er waren bijvoorbeeld twee transacties met dezelfde objecten binnen hetzelfde blok, dan is een van de transacties niet geldig, aangezien de oorspronkelijke waarden al zijn gewijzigd door een andere transactie ). Deze transactie wordt ook toegevoegd aan het gedistribueerde grootboek met een ongeldige markering, maar de schrijfset van deze transactie is niet van toepassing op de huidige status van de WorldState en verandert dienovereenkomstig de objecten die deelnemen aan de transactie niet. Daarna wordt er een melding naar de gebruikerstoepassing gestuurd dat de transactie voor altijd aan het gedistribueerde grootboek is toegevoegd, evenals de status van de transactie, dat wil zeggen of deze geldig is of niet ...
Afbeelding 7. Een blok toevoegen aan het register
BESTELSERVICE
De bestelservice bestaat uit een Kafka-cluster met bijbehorende ZooKeeper-knooppunten en een bestelserviceknooppunt (OSN) die zich tussen de bestelserviceclients en het Kafka-cluster bevindt. Kafka-cluster is een gedistribueerd, fouttolerant platform voor stroombeheer (berichten). Elk kanaal (onderwerp) in Kafka is een onveranderlijke reeks records die alleen het toevoegen van een nieuw record ondersteunt (het verwijderen van een bestaand record is niet mogelijk). Een illustratie van de onderwerpstructuur wordt hieronder gegeven. Het is deze eigenschap van Kafka die wordt gebruikt om het blockchain-platform te bouwen.
overgenomen van kafka.apache.org
- Afbeelding 8. Structuur van het onderwerp Service bestellen*
Handige links
Dankbetuigingen
Ik betuig mijn grote dank aan mijn collega's voor hun hulp bij het opstellen van het artikel:
Nikolaj Marina
Igor Khapov
Dmitri Gorbatsjov
Alexander Zemtsov
Ekaterina Guseva
Bron: www.habr.com