Sådan bygger du et forsyningskædesystem med bilproduktion ved hjælp af Ethereum

Billede af PIRO4D på Pixabay

Her hos Daitan er vi altid på udkig efter nye teknologier, der kan hjælpe vores klienter med at løse deres problemer mere effektivt. Den seneste tid, der har fanget meget af vores og vores kunders opmærksomhed, er Blockchain.

I denne artikel er vores mål at præsentere en praktisk måde at implementere din egen supply chain-applikation baseret på en blockchain-platform!

Systemet bruges til et af problemerne, hvor jeg mener, at anvendelse af blockchain giver den højeste værdi: en forsyningskæde.

Denne applikation er blevet undersøgt meget for nylig på PoC'er, og enorme virksomheder eksperimenterer allerede med det for deres operationer.

Brug af blockchain til at løse denne type problemer er et godt alternativ, fordi vi kan drage fordel af den gennemsigtighed og den effektive sporingsproces, som er forbundet med teknologien.

Da denne artikel har til hensigt at være enkel og ikke et komplet projekt, vil vi strømline problemet meget.

I slutningen har vi stadig et ende-til-ende-system, der kan demonstrere teknologiens anvendelighed til netop dette sæt af problemer.

Valg af en platform

I øjeblikket er der en masse platforme, der giver dig mulighed for at lave din egen blockchain eller bruge en offentlig blockchain til dine egne projekter, så vi vil udnytte en i stedet for at bygge fra bunden.

Disse projekter har en masse opbakning fra spillere fra både virksomheder og open source-samfundet, så vi mener, at brug af en er den mest praktiske vej til de fleste problemer, så vi kan fokusere på forretningslogikken i stedet for infrastrukturen.

Til vores demo valgte vi Ethereum-projektet. Det er en populær platform, og alle tilgængelige udviklingsværktøjer gør implementering af løsninger over det let at udføre.

Fremstillingshistorien

Vi har oprettet domænet, men hvad agter vi specifikt at lave?
Lad os beskrive et simpelt bilproduktionsproblem og de spillere, der er involveret i processen.

For det første har vi dele fabrikken, der er ansvarlig for produktion af hjul, karosseridele, motorer og transmissioner. Fabrikken informerer hver delproduktion vha. Den smarte kontrakt “ProductManagement”, som vil opbevare detaljer om hver enkelt del og produkt.

Derudover angiver fabrikken, at det er ejeren af ​​en bestemt del ved at kalde en metode fra den smarte kontrakt "ChangeOwnership", som vil holde ejeren historie for hver del og produkt.

Når vi går videre på kæden, har vi en bilfabrik, der køber dele fra delfabrikken for at fremstille biler. "ChangeOwnership" -kontrakten er, hvor vi holder denne type operation, så vi har en anden metode til at give delefabrikken mulighed for at overføre delejerskabet til bilfabrikken.

Med tilstrækkelige dele kan bilfabrikken endelig begynde at fremstille biler. Ligesom hvad delefabrikken gjorde for at informere sit job, bruger bilfabrikken nu den smarte kontrakt "ProductManagement" til at angive en bestemt bilmontering. Hver bil har et sæt egenskaber, ligesom et serienummer, og har også en deleliste, der binder biler til bestemte dele.

Ejerskabet kontrolleres af “ChangeOwnership” -kontrakten, og bilindstillingen indstiller således bilejerskabet til sig selv.

Endelig tilføjer vi forhandlere til scenariet, og de kan købe biler fra en fabrik, og sidstnævnte kan overføre bilejerskabet ved hjælp af "ChangeOwnership". Blockchain gemmer hver transaktion, der involverede den bil eller nogen af ​​de dele, der komponerer den, så forhandleren (eller enhver anden del) kan spore alt, hvad en bestemt vare har gennemgået. I vores tilfælde sker denne sporing ved at se begivenhederne genereret af transaktionerne. Dette vil blive klart, når vi analyserer koden.

Den komplette produktstrøm kan ses på billedet herunder:

Bilproduktion Forsyningskæde

Vi ved hvad vi skal gøre, men vi er stadig nødt til at bevæbne os med nogle værktøjer til at muliggøre udviklingen.

Miljø og værktøjer

For det første er vi nødt til at gøre en klar sondring mellem netværkene i Ethereum-økosystemet. Hovednetværket (kaldet Mainnet) er hvor de rigtige apps er bosiddende, og hvor hver enhedsenhed har reel værdi.

Dette betyder, at alt, hvad du registrerer der, er bundet til at eksistere, så længe Ethereum selv findes. Derudover kan ether kun opnås ved minedrift eller ved at købe den med rigtige penge.

Brug af dette netværk til at udvikle demonstrationer virker som en dårlig idé, så der er andre netværk, der er bedre til at støtte udvikling. Disse netværk kan være offentlige netværk, som det der kaldes Rinkeby, eller du kan endda oprette dit eget Ethereum-netværk!

Mens brug af et offentligt testnet som Rinkeby giver os en bedre måde at validere vores DApp (decentraliseret app), opretter vi vores eget netværk for at forkorte transaktionsaccepttid og forenkle udviklingen mest.

Det værktøj, vi vil bruge til at oprette vores netværk, kaldes Ganache.

Ganache er et simpelt værktøj, der opretter et lokalt Ethereum-netværk, og du kan oprette forbindelse til det, ligesom du ville gjort med hovednetværket. Det giver dig også 10 konti med 100 ether, hver gang du kører den.

Jeg kan godt lide at bo på terminalen, så i stedet for at bruge Ganache UI, vil jeg bruge ganache-cli, kommandolinjeversionen af ​​Ganache, der er et NodeJS-baseret værktøj og kan installeres med npm:

npm installere -g ganache-cli

For at køre, skal du bare køre ganache-cli, og du er god til at gå! Når du kører CLI, genererer det en mnemonic til dine tegnebøger. Den mnemonic er en 12-ordssætning, der er roden til at generere de private kontotaster og dermed tegnebøgerne.

Outputet er som følgende billede:

Gem mnemonik til senere brug. Hver gang du har brug for at køre Ganache igen, kan du bevare de samme konti, der giver mnemonic med -m-parameteren:

ganache-cli -m "nu ramme lejer kronisk ovn terning minut immunblad ur efterspørgsel volumen"

Bemærk: Mnemonics oprettet af Ganache er ikke sikkert og bør ikke bruges til tegnebøger på Ethereum-netværket

Nu hvor vi har vores netværk, er vi nødt til at kunne teste og distribuere vores kontrakter til det. Dette opnås med et andet værktøj kaldet Truffle, del af den samme udviklingssuite som Ganache. Trøffel kan også installeres med npm, så bare kør:

npm installere -g trøffel

Vi vil bruge trøfle til at forberede vores projektstruktur, så kør trøffel init og kontroller den mappestruktur, der er oprettet:

ethereum-supply-chain
| -contracts
| - Migrations.sol
| -migrations
| - 1_initial_migration.js
| -test
trøffel-config.js
  • Kontrakter: indeholder koden for vores smarte kontrakter
  • Migrationer: indeholder installationsinstruktioner til vores kontrakter
  • Test: indeholder testene for kontrakterne
  • Truffle-config.js (eller truffle.js afhængigt af din O.S.): hovedkonfigurationsfil, peger på Ethereum-netværk, som vi kan distribuere til

Konfigurationsfilen leveres med meget indhold, men det meste er kommenteret. For at føje vores lokale netværk til installationsindstillingerne skal du blot fjerne følgende del (linjer 49–53):

Endelig skal vi levere en grænseflade til vores brugere, så de kan interagere med Ethereum-netværkene.

En af mulighederne for dette er at installere Metamask, et browserplugin, der administrerer tegnebøger og også giver websystemer mulighed for at tale med Ethereum-netværk.

Når installationen er installeret, giver Metamask en grænseflade til at kontrollere tegnebogsmidler på forskellige netværk. Hver gang et websystem kræver en operation, der involverer betaling, beder Metamask om brugergodkendelse.

For at installere det skal du bare gå til deres websted og vælge udvidelsen til din browser.

Efter installationen skal Metamask oprette eller importere en tegnebog, så vælg "import med frøfrase" og indsæt den mnemonic, du fik fra ganache-cli.

Bemærk: Metamask er i øjeblikket i beta, så husk det, hver gang du bruger den, og følg instruktionerne givet efter konfigurationen

Og det er alt, hvad vi har brug for nu, lad os dykke ind i koden!

Smart kontrakter hænder på

Den første ting, vi skal gøre, er at implementere logikken bag hver af de smarte kontrakter, så vi begynder med “ProductManagement”.

Denne kontrakt skal have en metode til registrering af dele og en anden til at registrere produkter, selvom kravene til hver operation er meget ens.
Det gør vi, fordi vi vil kontrollere, at alle dele findes, når vi prøver at bygge et nyt produkt. Så vi kan have følgende metoder:

  • Delregistrering: opret en kortlægning med oplysningerne om selve delen (type, serienummer og fremstillingsdato), fabrikken, der lavede den (fabriks-id) og den aktuelle ejer (ejer-id).
  • Produktregistrering: Opret en kortlægning, der er det samme som delregistrering plus id for hver af de dele, der findes på produktet.
  • Indsamler kortlægningerne, så vi kan kontrollere eksistensen af ​​dele og produkter og få deres detaljer.

Den kontraktkode, som vi har brug for at implementere, er:

Vi definerer strukturer for dele og produkter, der kortlægger al den information, der kræves for at "bygge" vores dele og produkter, og derefter tilføjer vi de kortlægninger, der vil beholde alle registrerede varer.

BuildPart-metoden er enkel: den bruger en hjælperfunktion til at sammenkæde afsenderadresse og dele oplysninger om en bytesarray og beregne en hash. Denne hash er nøglen, der bruges til registrering og senere forespørgsel om dataene, så vi vender tilbage til hjælp til udvikling.

Da Ethereum-transaktioner ikke er valideret og køres, når du ringer til den smarte kontrakt, modtager vi en transaktion hash og kan ikke bruge den til vores webapp, men vi kan sende et opkald i stedet for en transaktion for let at kontrollere resultaterne.

I et rigtigt system ville vi forvente, at fabrikanten leverer den delvis-hash med den fysiske del, men vi vil ikke tænke over denne mekanisme her. Vi kender de oplysninger, der bruges til at generere hash, så vi kan beregne det, når vi har brug for, og det er præcis, hvad vi gør på testkoden og også på webappen.

Vi dækker ikke testkoden, så vi ikke udvider artiklen, men tjek den ud i vores lager!

BuildProduct-metoden er bare en udvidelse af buildPart-metoden og tilføjer en simpel check for at garantere, at alle dele blev registreret, før du forsøgte at oprette produktet.

To ting er virkelig værd at bemærke om koden:

  • Soliditet genererer automatisk bogstaver til offentlige kortlægninger, så vi behøver ikke at bekymre dig om det!
  • Men vi er nødt til at bekymre os, når vi returnerer matrixværdier, nøjagtigt tilfældet for vores produktdele. Vi har oprettet en "getParts" -funktion til at imødekomme dette behov.

Fortsætter vores udvikling koder vi "ChangeOwnership" -kontrakten. Det har et simpelt formål: administrere del og produktoverførsel mellem interesserede parter.

Da vi vil bruge ID'er til ejendomsoverførselsoperationen, kan vi have en metode til, at producenter kan registrere deres “oprindelige ejerskab” og en anden metode til at ændre ejerskabet til andre parter.

Vi har bare brug for at modtage en parameter for at fortælle os, om vi vil registrere dele eller produkter for at vide, hvilken kortlægning der skal tjekkes på "ProductManagement" -kontrakten, og også hvor vi skal gemme den aktuelle vareejer. Koden er følgende:

Vi bruger et "ProductManagement" -forekomst til at spørge efter dele og produkter, hver gang vi prøver at interagere med dem. Dette fremhæver et vigtigt aspekt af smarte kontrakter: du kan bruge dem til at kalde andre smarte kontrakter! En mulighed for at gøre det er at erklære kontrakten ABI i begyndelsen af ​​kontraktfilen, men bare de dele, der kræves af din kontrakt. I vores tilfælde betyder det:

For at pege på den rigtige kontrakt skal vi bare videregive kontraktadressen, når den øjeblikkelig indgås, som denne:

pm = ProductManagement (prod_contract_add);

Fortsætter med “ChangeOwnership” -kodegennemgangen, kan vi også se, at vi definerer to begivenheder, TransferPartOwnership og TransferProductOwnership. Begivenheder kan logges med transaktioner, så det vil være kernen i vores "tracking" -funktionalitet.

Hver gang en del eller et produkt overføres til en anden konto, udsender vi en begivenhed.

Tag addOwnership-funktionen som et eksempel: vi verificerer, at varen findes, kontrollerer, om den stadig ikke er registreret, og at producenten er den, der beder om ejerskab. Hvis vi verificerer alt det, gemmer vi producenten som delejeren og registrerer det på Ethereum som en begivenhed. Senere kan vi spørge om begivenheder om denne del fra dens hash og se alle overførsler.

Det eneste andet punkt, der skal bemærkes om denne kode, er på funktionen "ChangeOwnership": hver gang en bil skifter ejer, ændrer vi også ejerskabet til de dele, der komponerer den. Men nok til at gennemgå kode, lad os kontrollere, hvordan du implementerer den.

Implementering af kontrakt

For at migrere vores kontrakter til Ethereum er vi nødt til at oprette en simpel implementeringsfil i mappen "implementeringer". Vi kan basere os på filen "1_initial_migration.js", der er oprettet af Truffle, så vores kode bliver:

Vi kan omsider implementere vores kode på vores lokale Ethereum-netværk ved at køre:

udvikling af trøffel migrere - netværk

Når du kører det, vil du sandsynligvis bemærke, at ganache-cli-terminalen udsender en masse meddelelser, herunder nogle som:

Transaktion: 0x9fe6d2ece9cdca2f12b574ead7abb7bea7feab316f5cd6ebbd5b713e76850a1d
Oprettet kontrakt: 0xb6a3c3cf9d1e27e43e5fb12e505d79764748edbe

Disse repræsenterer vores kontraktadresser, så red dem for at kunne kommunikere senere. Vi har brug for denne adresse på vores webgrænseflade!

Webgrænseflade Hands On

Vores system har nu både smarte kontrakter klar, og alt hvad vi har brug for er grænsefladen til at bruge dem.

Vi lavede en side til hver rolle i vores scenarie, så vi har en "Del fabriksvisning", en "bilfabriksvisning" og en "forhandlervisning". Vi kommer ikke ind på detaljerne i de metoder, der er implementeret til interaktionerne, men lad os give et overblik for at få dig til at kontrollere koden!

Fabriksinteraktionerne som del, som delregistrering, tilføjelse af ejerskab og overføring af ejerskab kan udføres på grænsefladen vist nedenfor. Det er interessant at bemærke Metamask, der beder om tilladelse til hver enkelt transaktion, vi foretager.

Delproduktionsgrænseflade

Ser vi på ting fra en bilproducentens perspektiv, har vi delelisten udfyldt fra posterne på blockchain, derefter delsvalget til at samle bilen, bilbygningen, og til sidst overfører vi ejerskabet til en forhandler. Ligesom en delfabrik har bilfabrikken også sin egen grænseflade, der er vist nedenfor. Alle interaktioner med Ethereum bruger den del / bil-hash, der er oprettet ud fra deres egenskaber.

Interface til bilfremstilling

Den endelige visning er fra forhandlere, og for vores eksempel er det den enkleste: vi kan bare tjekke biler og dele for ejers historie. Tjek billedet herunder for detaljer:

Forhandlervisning med ejers historie til biler og dele

Under hætten bruger vi web3-biblioteket til at kalde vores smarte kontrakters metoder. Biblioteket giver os objekter, der repræsenterer vores kontrakter og metoder, og til det behøver vi kun at indstille:

  • Netværksplacering
  • Kontrakt ABI (definition af smart kontrakt)
  • Kontraktsadresse
  • Pung der skal bruges til operationer

Som standard kører ganache-cli netværket på 8545-porten, og ABI genereres hver gang du kompilerer og distribuerer dine kontrakter (men kun når vi opdaterer koden, så vi behøver ikke at ændre det).

Hvis du nogensinde har brug for det, skal du få værdien gemt i “build” -mappen i opsætningen.
Den kontraktadresse, vi skal specificere med de gemte værdier før, så skift følgende linjer til dine værdier:

Nu hvor vi har vores side klar til at interagere med vores smarte kontrakter, er vi bare nødt til at forberede de funktioner, der bruger de objekter, der leveres af web3, og vores system er komplet!

Funktionerne henter dybest set dataene fra inputfelterne på siden og kalder derefter funktionerne med dem som parametre. Den komplette kode er for stor til at passe til denne artikel, men lad os tjekke kun to dele, der forklarer det meste af interaktioner med blockchain. Den første er:

Objektet “windows.co” er vores “ChangeOwnership” -kontrakt, og både currentPartOwner og addOwnership er metoder, der leveres af det.
Forskellen her er på den funktion, der bruges til at kalde dem: opkald vs send.
Web3 1.0 kræver, at du angiver den type interaktion, du vil gøre med blockchain: læser eller transaktioner.

Så når du bruger en metode med "opkald", læser du bare data fra blockchain, det koster dig ingen æter og ændrer heller ikke kædetilstand.

På den anden side, hvis du bruger "send", skal du sende gas for at udføre handlingen, og det opretter en transaktion. Som vi tidligere har sagt, udvindes transaktioner ikke med det samme, så tag det i betragtning, når du udvikler Dapps i den virkelige verden.

Endelig er den anden del, der skal fremhæves:

Kan du huske, da vi sagde, at begivenheder ville være vores kerne i forsyningskæden? Denne linje bruges til at hente alle begivenheder fra en bestemt type ved at filtrere resultaterne efter delen hash.

Det betyder, at vi kan få alt, hvad der skete med en enkelt del, og hvis vi ønsker, kan vi også få deldetaljerne ved hjælp af den samme hash og kalde “dele” fra “ProductManagement”.

Temmelig sej, ikke?

Afslutter

Og vi er færdige!

Hver gang en delproducent ønsker at underrette en ny delproduktion, ønsker en bilproducent at samle det i en bil, eller vi vil flytte dele og biler fra en ejer til en anden, kan vi blot bruge webgrænsefladen til at gøre det.

Vi har en gennemsigtig registrering, der giver producenter, forhandlere og købere mulighed for at have de samme oplysninger om produkterne.

Hvis der findes et problem omkring et bestemt serienummerområde i fabrikkerne, kan fabrikken kontrollere, hvor problemet skal løses.

Det samme er tilfældet i den modsatte retning: forhandlere og købere kan spore deres produkts dele tilbage til fabrikkerne, hvis de har problemer eller har brug for udskiftning.

Implementering af systemet baseret på en blockchain giver også en distribueret og konsekvent registrering, som ingen af ​​deltagerne kan ændre uden spor, så vi undgår dårligt spil.

Vi har forenklet forsyningskædescenariet meget, men vi håber, at denne demo har vist kraften ved at bruge blockchain i denne sammenhæng. Nu kan du starte din løsningsplanlægning og betragte den som et implementeringsalternativ.

Jeg håber du nød det!