🥇Avalik test: lahendus privaatsuse ja skaleeritavuse tagamiseks Ethereumi

Plokiahel — innovatiivne tehnoloogia, mis lubab parandada paljusid inimelu valdkondi. See viib reaalprotsessid ja -tooted digitaalruumi, tagab finantstehingute kiirus ja usaldusväärsus, vähendab nende kulusid ning võimaldab luua kaasaegseid DAPP rakendusi nutikate lepingute abil detsentraliseeritud võrgustikes.

Arvestades blokeeringu arvukate eeliste ja rakendusvaldkondadega, võib tunduda kummaline, et see paljutõotav tehnoloogia pole veel tunginud kõikidesse tööstusharudesse. Probleem on selles, et kaasaegsetel detsentraliseeritud plokiahelatel puudub skaleeritavus. Ethereum töötleb umbes 20 tehingut sekundis, mis ei ole piisav kaasaegse dünaamilise äri vajaduste rahuldamiseks. Samal ajal ei julge plokiahela tehnoloogiat kasutavad ettevõtted loobuda Ethereumi oma kõrge häkkerite ja võrgukatkestuste kaitse tõttu.

Kuna tagada detsentraliseerimine, turvalisus ja skaleeritavus plokiahelas, lahendades niiviisi Skaleeritavuse Trilemma, arendajate meeskond Opporty loomis Plasma Cash — tütaraken, mis koosneb nutikas lepingust ja Node.js põhisel privaatvõrgust, mis edastab perioodiliselt oma oleku põhiringile (Ethereum).

Peamised protsessid Plasma Cashis

1. Kasutaja kutsub nutika lepingu funktsiooni `deposit`, edastades sellele ETH koguse, mille ta soovib Plasma Cashi tokenisse paigutada. Nutika lepingu funktsioon loob tokeni ja genereerib selle kohta sündmuse.

2. Plasma Cashi sõlmed, mis on allkirjastanud nutika lepingu sündmused, saavad deposiidi loomise sündmuse ja lisavad tokeni loomise tehingu järjekorda.

3. Aeg-ajalt saavad Plasma Cash erisolvurid kõik tehingud basseinist (kuni 1 miljon) ja koostavad neist ploki, arvutavad Merkle puu ja seega ka räsimise. See plokk saadetakse teistele solvudele kinnitamiseks. Solvud kontrollivad, kas Merkle räsimine on kehtiv ja kas tehingud on kehtivad (näiteks, kas tokeni saatja on selle omanik). Pärast ploki kinnitamist kutsub solv funktsiooni `submitBlock` nutilepingus, mis salvestab ketisse ploki numbri ja Merkle räsimise. Nutileping genereerib sündmuse ploki eduka lisamise kohta. Tehingud kustutatakse basseinist.

4. Solvud, kes said teate ploki esitamise kohta, hakkavad rakendama tehinguid, mis olid lisatud plokki.

5. Mingil hetkel soovib tokeni omanik (või mitte-omanik) selle Plasma Cash-ist välja võtta. Selleks kutsub ta funktsiooni `startExit`, edastades sellele teabe kahe viimase tehingu kohta tokeni osas, mis kinnitavad, et just tema on tokeni omanik. Nutileping kontrollib Merkle räsimise abil tehingute asukohta plokkides ja saadab tokeni väljavõtmiseks, mis toimub kahe nädala pärast.

6. Kui tokeni väljamakse toimus rikkumistega (tokeni kasutamine pärast väljamakseprotseduuri algust või token oli enne väljamaksmist juba kellegi teise oma), saab tokeni omanik kahe nädala jooksul väljamakset vaidlustada.

Privaatsus saavutatakse kaheviisi

1. Põhiketash ei tea tehingutest, mis genereeritakse ja edastatakse alamketas. Avalikuks jääb info selle kohta, kes sisestas ja võttis ETH Plasma Cashist.

2. Alamketas võimaldab korraldada anonüümsed tehingud, kasutades zk-SNARK-e.

Tehnoloogiline stack

NodeJS
Redis
Etherium
Soild

Testimine

Plasma Cashi arendamisel testisime süsteemi töökiirus ja saime järgmised tulemused:

kuni 35 000 tehingut sekundis lisatakse puuli;
kuni 1 000 000 tehingut saab salvestada plokki.

Testid viidi läbi kolmel järgmistel serveritel:

1. Intel Core i7-6700 Quad-Core Skylake, sealhulgas NVMe SSD — 512 GB, 64 GB DDR4 RAM
Käivitatud on 3 valideerivat Plasma Cashi sõlme.

2. AMD Ryzen 7 1700X Octa-Core «Summit Ridge» (Zen), SATA SSD — 500 GB, 64 GB DDR4 RAM
Käivitatud on Ropsten testnet ETH sõlm.
Käivitatud on 3 valideerivat Plasma Cashi sõlme.

3. Intel Core i9-9900K Octa-Core, sealhulgas NVMe SSD — 1 TB, 64 GB DDR4 RAM
Käivitatud on 1 submit Plasma Cashi sõlm.
Käivitatud on 3 valideerivat Plasma Cashi sõlme.
Plasma Cash võrku lisanduvate tehingute test käivitus.

Kokku: 10 Plasma Cash sõlme privaatvõrgus.

Test 1

Tehingute piir on 1 miljon plokis. Seetõttu satuvad 1 miljon tehingut 2 plokki (sest süsteem suudab osa tehingutest võtta ja esitada, samal ajal kui need saadetakse).

Algne seisund: viimane plokk #7; andmebaasis on salvestatud 1 miljon tehingut ja tokenit.

00:00 — tehingute genereerimise skripti käivitamine
01:37 — loodud 1 miljon tehingut ja käivitati edastamine sõlme
01:46 — sõlm võttis 240k tehingut jooksvalt ja koostab ploki #8. Samuti näeme, et 10 sekundi jooksul lisandub 320k tehingut puul.
01:58 — plokk #8 on allkirjastatud ja saadetud valideerimiseks
02:03 — plokk #8 on valideeritud ja kutsutud välja `submitBlock` funktsioon nutilepingus koos Merkle'i hash'iga ja ploki numbriga
02:10 — demo-skript lõpetas tööd, edastades 1 miljon tehingut 32 sekundi jooksul
02:33 — sõlmed hakkasid saama teavet, et plokk #8 on lisatud juureahelasse, ning hakkasid täitma 240k tehingut
02:40 — puult eemaldati 240k tehingut, mis juba on plokis #8
02:56 — submit node took the remaining 760k transactions from the pool and began calculating the Merkle hash and signing block #9
03:20 — all nodes contain 1 million 240k transactions and tokens
03:35 — block #9 has been signed and is being sent for validation to other nodes
03:41 — a network error occurred
04:40 — waiting for validation of block #9 timed out
04:54 — submit node took the remaining 760k transactions from the pool and began calculating the Merkle hash and signing block #9
05:32 — block #9 has been signed and is being sent for validation to other nodes
05:53 — block #9 has been validated and sent to the root chain
06:17 — nodes began receiving information that block #9 has been added to the root chain and started processing 760k transactions
06:47 — the pool has been cleared of transactions included in block #9
09:06 — all nodes contain 2 million transactions and tokens

Test 2

There is a limit of 350k per block. As a result, we have 3 blocks.

Initial state: last block #9; 2 million transactions and tokens are saved in the database

00:00 — the transaction generation script has already started
00:44 — 1 million transactions have been created and sending to the node has begun
00:56 — nod täitis 320k tehingut puul ja vormib ploki #10. Samuti näeme, et puule lisatakse 320k tehingut 10 sekundi jooksul
01:12 — plokk #10 on allkirjastatud ja saadetud teistele nodadele valideerimiseks
01:18 — demo skript lõpetas töö, mis saatis 1 miljon tehingut 34 sekundi jooksul
01:20 — plokk #10 on valideeritud ja saadetud juure ahelasse
01:51 — kõik nodad said juure ahelast teavet, et plokk #10 on lisatud, ja hakkavad rakendama 320k tehingut
02:01 — puu on puhastatud 320k tehingutest, mis lisati plokki #10
02:15 — nod täitis 350k tehingut puust ja vormib ploki #11
02:34 — plokk #11 on allkirjastatud ja saadetud teistele nodadele valideerimiseks
02:51 — plokk #11 on valideeritud ja saadetud juure ahelasse
02:55 — viimane nod täitis tehingud plokist #10
10:59 — juure ahelas kestis väga kaua tehing ploki #9 esitamises, kuid see toimus ning kõik nodad said teavet ja hakkasid täitma 350k tehingut
11:05 — puu on puhastatud 320k tehingutest, mis lisati plokki #11
12:10 — kõik nodad sisaldavad 1 miljon 670k tehingut ja tokenit
12:17 — submitt node võttis poolist 330k tehingut ja vormib ploki #12
12:32 — plokk #12 on allkirjastatud ja saadetud teistele nodedele valideerimiseks
12:39 — plokk #12 on valideeritud ja saadetud juurekettasse
13:44 — kõik nodid said juureketta kaudu teavet, et plokk #12 on lisatud, ja alustavad 330k tehingu rakendamist
14:50 — kõik nodid sisaldavad 2 miljonit tehingut ja tokenit

Test 3

Esimeses ja teises serveris asendati üks valideeriv node submitt nodiga.

Algne seis: viimane plokk #84; andmebaasis on salvestatud 0 tehingut ja tokenit

00:00 — Käivitatud on 3 skripti, mis genereerivad ja saadavad 1 miljoni tehingu
01:38 — loodud 1 miljon tehingut ja saadeti submitt node #3
01:50 — submitt node #3 võttis poolist 330k tehingut ja vormib ploki #85 (f21). Samuti näeme, et 10 sekundi jooksul lisatakse puule veel 350k tehingut
01:53 — loodud 1 miljon tehingut ja saadeti submitt node #1
01:50 — submitt node #3 võttis poolist 330k tehingut ja vormib ploki #85 (f21). Samuti näeme, et 10 sekundi jooksul lisatakse puule veel 350k tehingut
02:01 — submitt node #1 võttis poolist 250k tehingut ja vormib ploki #85 (65e)
02:06 — plokk #85 (f21) on allkirjastatud ja saadetud teistele nodedele valideerimiseks
02:08 — serveri #3 demo skript on lõpetanud töö, saates 1 miljon tehingut 30 sekundi jooksul
02:14 — plokk #85 (f21) on valideeritud ja saadetud juureketti
02:19 — plokk #85 (65e) allkirjastatud ja saadetakse teistele sõlmedele valideerimiseks
02:22 — loodud 1 miljon tehingut ja alustatud saatmine esitamisse sõlmele #2
02:27 — plokk #85 (65e) on valideeritud ja saadetud juureketti
02:29 — esitussõlm #2 võttis 111855 tehingut basseinist ja vormib plokki #85 (256).
02:36 — plokk #85 (256) allkirjastatud ja saadetakse teistele sõlmedele valideerimiseks
02:36 — serveri #1 demo-skripti töö lõppes, mis saatis 1 miljon tehingut 42,5 sekundi jooksul
02:38 — plokk #85 (256) on valideeritud ja saadetud juureketti
03:08 — serveri #2 skripti töö lõppes, mis saatis 1 miljon tehingut 47 sekundi jooksul
03:38 — kõik sõlmed said juureketist teabe, et plokid #85 (f21), #86 (65e), #87 (256) on lisatud ja hakkavad rakendama 330k, 250k, 111855 tehingut
03:49 — bassein puhastati 330k, 250k, 111855 tehingust, mis lisati plokkidesse #85 (f21), #86 (65e), #87 (256)
03:59 — esitussõlm #1 võttis basseinist 888145 tehingut ja vormib plokki #88 (214), esitussõlm #2 võttis basseinist 750k tehingut ja vormib plokki #88 (50a), esitussõlm #3 võttis basseinist 670k tehingut ja vormib plokki #88 (d3b)
04:44 — plokk #88 (d3b) on allkirjastatud ja saadetud teistele sõlmedele valideerimiseks
04:58 — plokk #88 (214) on allkirjastatud ja saadetud teistele sõlmedele valideerimiseks
05:11 — plokk #88 (50a) on allkirjastatud ja saadetud teistele sõlmedele valideerimiseks
05:11 — plokk #85 (d3b) on valideeritud ja saadetud juureahelasse
05:36 — plokk #85 (214) on valideeritud ja saadetud juureahelasse
05:43 — kõik sõlmed said juureahelast teavet, et plokid #88 (d3b), #89 (214) on lisatud ja hakkavad rakendama 670k, 750k tehinguid
06:50 — ühenduse katkestamise tõttu ei ole plokk #85 (50a) saanud valideeritud
06:55 — sõlm #2 võttis punasest 888145 tehingut ja loob ploki #90 (50a)
08:14 — plokk #90 (50a) on allkirjastatud ja saadetud teistele sõlmedele valideerimiseks
09:04 — plokk #90 (50a) on valideeritud ja saadetud juureahelasse
11:23 — kõik sõlmed said juureahelast teavet, et plokk #90 (50a) on lisatud ning hakkavad rakendama 888145 tehingut. Samal ajal oli server #3 juba ammu rakendanud tehingud plokkidest #88 (d3b), #89 (214)
12:11 — kõik basseinid on tühjad
13:41 — kõik serveri #3 sõlmed sisaldavad 3 miljonit tehingut ja tokenit
14:35 — kõik serveri #1 sõlmed sisaldavad 3 miljonit tehingut ja tokenit
19:24 — kõik serveri #2 sõlmed sisaldavad 3 miljonit tehingut ja tokenit

Tõkked

Plasma Cash'i arendamise käigus kohtasime järgmisi probleeme, mida lahendasime järk-järgult:

1. Süsteemi erinevate funktsioonide omavaheline konflikt. Näiteks blokeeris tehingute lisamise funktsioon submittimise ja plokkide valideerimise toimimise ning vastupidi, mis viis kiiruslanguseni.

2. Ei olnud kohe selge, kuidas saata tohutult tehinguid ja samal ajal andmeedastuskulusid minimeerida.

3. Ei olnud selge, kuidas ja kus andmeid salvestada, et saavutada kõrgeid tulemusi.

4. Ei olnud selge, kuidas korraldada suhtlust sõlmede vahel, sest miljoni tehingu kogumahu plokk võtab umbes 100 MB.

5. Ühe toimesüsteemi töö katkestab sõlmede vaheline ühendus, kui toimuvad pikad arvutused (nt Merkle puu ehitamine ja selle räsimise arvutamine).

Kuidas me kõigega hakkama saime?

Plasma Cash node'i esimene versioon oli kombinatsioon, mis suutis kõike korraga teha: vastu võtta tehinguid, esitama ja valideerima plokke ning pakkuma API-d andmetele juurdepääsuks. Kuna NodeJS on algselt ühetahuline, siis keeruline Merkle puu arvutus takistas tehingu lisamise funktsiooni. Me nägime kahte võimalust selle probleemi lahendamiseks:

1. Käivitada mitu NodeJS protsessi, millest igaüks täidab kindlaid funktsioone.

2. Kasutada worker_threads ja viia osa koodist silmustesse.

Kokkuvõttes kasutasime mõlemat varianti üheaegselt: loogiliselt jagasime ühe nodi kolme osaks, mis saavad töötada iseseisvalt, kuid samas ka sünkroonselt.

1. Esitamisnod, mis võtab tehingud järjekorda ja loob plokke.

2. Valideerimisnode, mis kontrollib nodide kehtivust.

3. API node — pakub API-d andmetele juurdepääsuks.

Iga nodiga saab ühenduda unix socketi kaudu cli kaudu.

Raskete operatsioonide, nagu Merkle puu arvutamine, viime eraldi silmusesse.

Nii saavutasime, et kõik Plasma Cash funktsioonid töötavad korraga ja probleemideta.

Kui süsteem oli funktsionaalselt töökorras, alustasime kiiruseteste ja kahjuks saime rahuldavad tulemused: 5000 tehingut sekundis ja kuni 50 000 tehingut plokis. Pidi välja selgitama, mis oli valesti teostatud.

Alguses hakkasime katsetama suhtlemismehhanismi Plasma Cashiga, et teada saada süsteemi tippvõimekust. Oleme varem kirjutanud, et Plasma Cash'i sõlm pakub unix socketi liidese. Esialgu oli see tekstiline, json objektid edastati, kasutades `JSON.parse()` ja `JSON.stringify()`.

```json
{
  "action": "sendTransaction",
  "payload":{
    "prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
    "prevBlock": 41,
    "tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
    "newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
    "type": "pay",
    "data": "",
    "signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
  }
}
```

Me mõõtsime selliste objektide edastamise kiirus ja saime ~ 130k sekundis. Proovisime asendada standardseid json-funktsioone, aga jõudlus ei paranenud. Tundub, et V8 mootor on nende operatsioonide jaoks hästi optimeeritud.

Meie süsteemis toimusid tehingute, tokenite ja plokkide töötlemine klasside kaudu. Selliste klasside loomisel vähenes jõudlus kahekordselt, mis tõendab, et OOP ei sobi meile. Pidi kogu asja ümber kirjutama puhta funktsionaalse lähenemisega.

Salvestamine andmebaasi

Alguses valisime andmete salvestamiseks Redis, kuna see on üks kõige efektiivsemaid lahendusi, mis vastab meie nõuetele: key-value salvestus, töötamine hash-tabelitega, kogud. Käivitasime redis-benchmarki ja saime ~80k operatsiooni sekundis 1 pipelining režiimis.

Kõrge täpsuse saavutamiseks sättisime Redisit veel täiendavalt:

Seadsime unix socket'i ühenduse.
Keelasime oleku salvestamise kettale (usaldusväärsuse tagamiseks saab seadistada replika ja salvestada kettale eraldi Redis's).

Redis'is on bassein - see on hash-tabel, kuna meil on vaja võimalust saada kõik tehingud ühe päringuga ja eemaldada tehingud ükshaaval. Proovisime kasutada tavalist loendit, kuid see töötab tervete loendite väljavõtmisel aeglasemalt.

Standardse NodeJS Redis'i teegi kasutamisel saime jõudluse 18k tehingut sekundis. Kiirus langes 9 korda.

Kuna benchmark näitas meile selgelt viielist suuremat võimekust, alustasime optimeerimisega. Vahetasime raamatukogu ioredise vastu ja saime tootlikkuse 25 000 sekundis. Transaktsioone lisasime ükshaaval, kasutades käsku `hset`. Nii genereerisime palju päringuid Redisese. Tekkis idee ühendada transaktsioonid paketiks ja saata need ühes käsus `hmset`. Tulemuseks oli 32 000 sekundis.

Mõnel põhjusel, mida we allpool selgitame, töötame andmetega kasutades `Buffer`it ning nagu selgus, kui see kirjutamise eel teksti viia (`buffer.toString('hex')`), saab saavutada täiendavat tootlikkust. Nii õnnestus kiirus tõsta 35 000 sekundisse. Praegu otsustasime edasise optimeerimise peatada.

Pidime minema üle binaarprotokollile, kuna:

1. Süsteem arvutab sageli räsimärke, allkirju jne, ja selleks on tal vaja andmeid `Buffer`is.

2. Teenuste vahel edastamisel on binaarsed andmed kergemad kui tekst. Näiteks, kui saata plokk 1 miljoni transaktsiooniga, võivad tekstina andmed hõivata rohkem kui 300 megabaiti.

3. Pidev andmete konverteerimine mõjutab tootlikkust.

Seetõttu põhinesime oma andmete salvestamise ja edastamise protokolli loomisel suurepärasel `binary-data` teegil.

Tulemuseks on järgmised andmestruktuurid:

— Tehing

  ```json
  {
    prevHash: BD.types.buffer(20),
    prevBlock: BD.types.uint24le,
    tokenId: BD.types.string(null),
    type: BD.types.uint8,
    newOwner: BD.types.buffer(20),
    dataLength: BD.types.uint24le,
    data: BD.types.buffer(({current}) => current.dataLength),
    signature: BD.types.buffer(65),
    hash: BD.types.buffer(32),
    blockNumber: BD.types.uint24le,
    timestamp: BD.types.uint48le,
  }
  ```

— Token

  ```json
  {
    id: BD.types.string(null),
    owner: BD.types.buffer(20),
    block: BD.types.uint24le,
    amount: BD.types.string(null),
  }
  ```

— Plokk

  ```json
  {
    number: BD.types.uint24le,
    merkleRootHash: BD.types.buffer(32),
    signature: BD.types.buffer(65),
    countTx: BD.types.uint24le,
    transactions: BD.types.array(Transaction.Protocol, ({current}) => current.countTx),
    timestamp: BD.types.uint48le,
  }
  ```

Tavaliste käskudega `BD.encode(block, Protocol).slice();` ja `BD.decode(buffer, Protocol)` muundame andmed `Buffer`-iks, et salvestada neid Redis-sse või edastada teisele noodile ning andmeid tagasi hankida.

Kasutame ka kahte binaarset protokolli andmete edastamiseks teenuste vahel:

— Protokoll Plasma Node'iga suhtlemiseks unix socketi kaudu

  {
    type: BD.types.uint8,
    messageId: BD.types.uint24le,
    error: BD.types.uint8,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }

kus:

`type` — tegevus, mida on vaja teha, näiteks 1 — sendTransaction, 2 — getTransaction;
`payload` — andmed, mida on vaja vastavasse funktsiooni edastada;
`messageId` — sõnumi ID, et saaks tuvastada vastuse.

— Protokoll, mille kaudu sõlmed omavahel suhtlevad

  {
    code: BD.types.uint8,
    versionProtocol: BD.types.uint24le,
    seq: BD.types.uint8,
    countChunk: BD.types.uint24le,
    chunkNumber: BD.types.uint24le,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }

kus:

`code` — sõnumi kood, näiteks 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
`versionProtocol` — protokolli versioon, kuna võrgus võivad olla erineva versiooni sõlmed ja need võivad toimida erinevalt;
`seq` — sõnumi identifikaator;
`countChunk` ja `chunkNumber` vajalikud suurte sõnumite jagamiseks;
`length` ja `payload` pikkus ja andmed.

Kuna me tüübisime andmed eelnevalt, töötab lõpp-süsteem palju kiiremini kui Ethereumist pärinev `rlp` teek. Kahjuks ei ole me veel suutnud sellest loobuda, kuna on vajalik täiustada nutilepingut, mida me plaanime tulevikus teha.

Kui suudame saavutada kiirus 35 000 tehingute sekundis, peame neid ka töötlema optimaalse aja jooksul. Kuna ploki loomise eeldatav aeg on 30 sekundit, peame plokki lisama 1 000 000 tehingut, mis tähendab enam kui 100 mb andmete edastamist.

Alguses kasutasime `ethereumjs-devp2p` teeki nodede omavaheliseks suhtlemiseks, kuid see ei suutnud nii palju andmeid töödelda. Seetõttu kasutasime `ws` teeki ja seadistasime binaarsete andmete edastamise websocketide kaudu. Loomulikult kohtasime ka probleeme suurte andmepakettide edastamisel, kuid jagasime need osadeks ning nüüd neid probleeme enam ei esine.

Samuti nõuab Merkle puu loomine ja tehingute hashi arvutamine umbes 1 000 000 sekundit pidevat arvutamist. Selle aja jooksul katkeb ühendus kõigi nodede külge. Otsustasime selle arvutamise viia eraldi lõime. 10 sekundit pidea arvutust. Selle aja jooksul katkeb ühendus kõigi nodidega. Otsustati viia see arvutus eraldi lõime.

Järeldused:

Tegelikult pole meie järeldused uudsed, aga mingil põhjusel unustavad paljud spetsialistid neid arendamisel.

Funktsionaalse programmeerimise kasutamine objekti-orienteeritud programmeerimise asemel suurendab töötlustõhusust.
Monoliit on halvem kui teenusaarhitektuur tootlikule NodeJS süsteemile.
Töötajate lõime (`worker_threads`) kasutamine raskete arvutuste jaoks parandab süsteemi vastupidavust, eriti i/o operatsioonide käitamisel.
Unix socket on stabiilsem ja kiirem kui http päringud.
Kui peate kiiresti edastama suuri andmeid üle võrgu, on parem kasutada websocket'e ja saata binaarseid andmeid, jagatuna tükkideks, mida saab vajadusel edastada ja hiljem ühte sõnumisse taastada.

Kutsume teid külastama GitHub projekti: https://github.com/opporty-com/Plasma-Cash/tree/new-version

Artikkel kirjutati koostöös Aleksandr Našivaniga, vanem arendaja Clever Solution Inc.

Allikas: habr.com