🥇Avalik test: lahendus privaatsuse ja skaleeritavuse jaoks Ethereumis

Plokiahel — innovatiivne tehnoloogia, mis lubab parandada paljusid inimelu valdkondi. See viib reaalsed protsessid ja tooted digitaalsetesse ruumidesse, tagab finantstehingute kiirus ja usaldusväärsuse, vähendab nende maksumust ning võimaldab luua kaasaegseid DAPP rakendusi, kasutades nutikaid lepinguid detsentraliseeritud võrkudes.

Arvestades blockchaini arvukate eeliste ja mitmekesiste rakendusvaldkondadega, võib tunduda kummaline, et see lubav tehnoloogia pole veel kõigis tööstusharudes juurdunud. Probleemiks on see, et kaasaegsetel detsentraliseeritud blockchainidel puudub skaleeritavus. Ethereum töötleb umbes 20 tehingut sekundis, mis pole piisav, et rahuldada tänapäeva dünaamilise äri vajadusi. Samal ajal ei julge blockchaini tehnoloogiat kasutavad ettevõtted loobuda Ethereumi selle kõrge häkkimise ja võrgu tõrgete vastu kaitse tõttu.

Kuna tagada detsentraliseeritust, turvalisust ja skaleeritavust blockchainis, lahendades seega Skaala Trilemmas, on arendajate meeskond Opporty loodud Plasma Cash — alakee, mis koosneb nutilepingust ja Node.js põhist privaatsest võrgust, mis perioodiliselt edastab oma oleku põhikehasse (Ethereum).

Plasma Cashi peamised protsessid

1. Kasutaja kutsub nutilepingu `deposit` funktsiooni, edastades sellele summa ETHs, mille ta soovib Plasma Cashi tokenisse panna. Nutilepingu funktsioon loob tokeni ja genereerib selle kohta sündmuse.

2. Plasma Cash nodid, mis on registreeritud nutilepingu sündmustele, saavad deposiidi loomise sündmuse ja lisavad tokeni loomise tehingu tehingute punkti.

3. Perioodiliselt võtavad erilised Plasma Cash nodid kõik tehingud punktist (kuni 1 miljon) ja loovad neist ploki, arvutavad Merkle puu ja vastavalt hashi. Antud plokk saadetakse teistele nodidele verifitseerimiseks. Nodid kontrollivad, kas Merkle hashi on kehtiv, ja kas tehingud on kehtivad (näiteks, kas tokeni saatja on selle omanik). Pärast ploki verifitseerimist kutsub node nutilepingu `submitBlock` funktsiooni, mis salvestab põhikehasse ploki numbri ja Merkle hashi. Nutileping genereerib sündmuse ploki eduka lisamise kohta. Tehingud eemaldatakse punktist.

4. Node'id, mis said tagasi sündmuse blokki saatmisest, hakkavad rakendama tehinguid, mis on lisatud blokki.

5. Mõnes etapis tahab tokeni omanik (või mitteomanik) selle Plasma Cash'ist välja võtta. Selleks kutsub ta üles funktsiooni `startExit`, edastades sellele kaks viimast tehingut tokeni kohta, mis tõendavad, et just tema on tokeni omanik. Nutikas leping kontrollib, kasutades Merkle'i rippu, tehingute olemasolu blokkides ja saadab tokeni väljavõtmiseks, mis toimub kahe nädala jooksul.

6. Kui tokeni väljavõtmise operatsioon toimus rikkumistega (tokeni kulutamine pärast väljavõtmisprotsessi algust või token enne väljavõtmist juba oli kellegi teise käes), võib tokeni omanik väljavõtmise kahe nädala jooksul vaidlustada.

Privaatsus saavutatakse kahel viisil.

1. Põhikahel ei tea tehingutest, mis genereeritakse ja edastatakse tütarkahelas. Avalikuks jääb teave selle kohta, kes on sisse viinud ja välja võtnud ETH Plasma Cash'ist.

2. Tütarkahel võimaldab korraldada anonüümsed tehingud, kasutades zk-SNARKs.

Tehnoloogiakogum

Far manager
Redis
Etherium
Soild

Testimine

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

kuni 35 000 tehingut sekundis lisatakse puuli;
kuni 1 000 000 tehingut võib hoida blokis.

Testid viidi läbi järgmiste kolme serveriga:

1. Intel Core i7-6700 Quad-Core Skylake koos NVMe SSD — 512 GB, 64 GB DDR4 RAM
Käivitati 3 valideerivat Plasma Cash node'i.

2. AMD Ryzen 7 1700X Octa-Core "Summit Ridge" (Zen), SATA SSD — 500 GB, 64 GB DDR4 RAM
Käivitati Ropsten testnet ETH node.
Käivitati 3 valideerivat Plasma Cash node'i.

3. Intel Core i9-9900K Octa-Core koos NVMe SSD — 1 TB, 64 GB DDR4 RAM
Käivitati 1 Plasma Cash node'i, mis toob kokku.
Käivitati 3 valideerivat Plasma Cash node'i.
Tehti test tehingute lisamiseks Plasma Cash'i võrku.

Kokkuvõtteks: 10 Plasma Cash node'i privaatvõrgus.

Test 1

Blokis on piirang 1 miljon tehingut. Seetõttu satuvad 1 miljon tehingut 2 blokkidesse (sest süsteem suudab osa tehingutest võtta ja need edastada, kuni need saadetakse).

Algne seisund: viimase blokk #7; andmebaasis on salvestatud 1 miljon tehingut ja tokenit.

00:00 — skripti käivitamine tehingute genereerimiseks
01:37 — loodud 1 miljon tehingut ja saadetud node'isse
01:46 — submit node võttis puul 240k tehingut ja genereerib blokk #8. Samuti näeme, et puusse lisatakse 320k tehingut 10 sekundi jooksul.
01:58 — blokk #8 allkirjastatakse ja saadetakse valideerimiseks.
02:03 — plokk #8 on valideeritud ja kutsuti esile smartrakenduse `submitBlock` funktsioon, millel on Merkle'i hash ja ploki number
02:10 — lõppes demo-skripti töö, mis saatis 1 miljon tehingut 32 sekundiga
02:33 — sõlmed hakkasid saama teavet selle kohta, et plokk #8 on lisatud põhivõrku ja hakkasid tegema 240k tehingut
02:40 — 240k tehingut eemaldati basseinist, mis juba on plokis #8
02:56 — submit sõlm võttis basseinist ülejäänud 760k tehingut ja hakkas arvutama Merkle'i hash'i ja allkirjastama ploki #9
03:20 — kõik sõlmed sisaldavad 1 miljon 240k tehingut ja tokeneid
03:35 — plokk #9 on allkirjastatud ja saadetud valideerimiseks teistele sõlmedele
03:41 — võrgus ilmnes viga
04:40 — ajanäitaja lõppes, ploki #9 valideerimise ootamine lõpetati
04:54 — submit sõlm võttis basseinist ülejäänud 760k tehingut ja hakkas arvutama Merkle'i hash'i ja allkirjastama ploki #9
05:32 — plokk #9 on allkirjastatud ja saadetud valideerimiseks teistele sõlmedele
05:53 — plokk #9 on valideeritud ja saadetud põhivõrku
06:17 — sõlmed hakkasid saama teavet selle kohta, et plokk #9 on lisatud põhivõrku ja hakkasid tegema 760k tehingut
06:47 — bassein on puhastatud tehingutest, mis on plokis #9
09:06 — kõik sõlmed sisaldavad 2 miljonit tehingut ja tokeneid

Test 2

Ploki limit on 350k. Tulemuseks on 3 plokki.

Algne seisund: viimane plokk #9; andmebaasis on salvestatud 2 miljonit tehingut ja tokeneid

00:00 — tehingute genereerimise skript on juba käivitatud
00:44 — on loodud 1 miljon tehingut ja alustatud saatmist sõlme
00:56 — submit sõlm võttis basseinist 320k tehingut ja koostab ploki #10. Samuti näeme, et basseini lisandub 320k tehingut 10 sekundiga
01:12 — plokk #10 on allkirjastatud ja saadetud teistele sõlmedele valideerimiseks
01:18 — lõppes demo-skripti töö, mis saatis 1 miljon tehingut 34 sekundiga
01:20 — plokk #10 on valideeritud ja saadetud põhivõrku
01:51 — kõik sõlmed said põhivõrgust teavet selle kohta, et plokk #10 on lisatud, ja hakkavad rakendama 320k tehingut
02:01 — bassein on puhastatud 320k tehingutest, mis lisati plokki #10
02:15 — submit sõlm võttis basseinist 350k tehingut ja koostab ploki #11
02:34 — plokk #11 on allkirjastatud ja saadetud teistele sõlmedele valideerimiseks
02:51 — plokk #11 on valideeritud ja saadetud põhivõrku
02:55 — viimane sõlm täitis ploki #10 tehingud
10:59 — juureketis toimus väga pikaajaline tehing blokk #9 esitamisega, kuid see viidi lõpule ja kõik sõlmed said sellest teavet ning alustasid 350k tehingu töötlemist
11:05 — bassein puhastati 320k tehingust, mis lisati blokk #11
12:10 — kõik sõlmed sisaldavad 1 miljon 670k tehingut ja tokenit
12:17 — esitussõlm võttis basseinist 330k tehingut ja vormib blokk #12
12:32 — blokk #12 on allkirjastatud ja saadetud teistele sõlmedele valideerimiseks
12:39 — blokk #12 on valideeritud ja saadetud juureketti
13:44 — kõik sõlmed said juureketist teavet, et blokk #12 on lisatud, ja alustavad 330k tehingu rakendamist
14:50 — kõik sõlmed sisaldavad 2 miljonit tehingut ja tokenit

Test 3

Esimeses ja teises serveris asendati üks valideeriv sõlm esitussõlmiga.

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

00:00 — Käivitatud 3 skripti, mis genereerivad ja saadavad 1 miljon tehingut
01:38 — loodud 1 miljon tehingut ja saadeti esitussõlmele #3
01:50 — esitussõlm #3 võttis basseinist 330k tehingut ja vormib blokk #85 (f21). Samuti näeme, et basseinile lisatakse 350k tehingut 10 sekundi jooksul
01:53 — loodud 1 miljon tehingut ja saadeti esitussõlmele #1
01:50 — esitussõlm #3 võttis basseinist 330k tehingut ja vormib blokk #85 (f21). Samuti näeme, et basseinile lisatakse 350k tehingut 10 sekundi jooksul
02:01 — esitussõlm #1 võttis basseinist 250k tehingut ja vormib blokk #85 (65e)
02:06 — blokk #85 (f21) on allkirjastatud ja saadetud teistele sõlmedele valideerimiseks
02:08 — lõpetas töö demo-skript serveris #3, mis saatis 1 miljon tehingut 30 sekundi jooksul
02:14 — blokk #85 (f21) on valideeritud ja saadetud juureketti
02:19 — blokk #85 (65e) on allkirjastatud ja saadetud teistele sõlmedele valideerimiseks
02:22 — loodud 1 miljon tehingut ja saadeti esitussõlmele #2
02:27 — blokk #85 (65e) on valideeritud ja saadetud juureketti
02:29 — esitussõlm #2 võttis basseinist 111855 tehingut ja vormib blokk #85 (256).
02:36 — blokk #85 (256) on allkirjastatud ja saadetud teistele sõlmedele valideerimiseks
02:36 — lõpetas töö demo-skript serveris #1, mis saatis 1 miljon tehingut 42,5 sekundi jooksul
02:38 — blokk #85 (256) on valideeritud ja saadetud juureketti
03:08 — lõpetas töö demo-skript serveris #2, mis saatis 1 miljon tehingut 47 sekundi jooksul
03:38 — kõik sõlmed said juureketist teavet, et blokid #85 (f21), #86 (65e), #87 (256) on lisatud ja alustavad 330k, 250k, 111855 tehingu rakendamist
03:49 — bassein puhastati 330k, 250k, 111855 tehinguga, mis lisati blokki #85 (f21), #86(65e), #87(256)
03:59 — submit node #1 võttis basseinist 888145 tehingut ja loob bloki #88 (214), submit node #2 võttis basseinist 750k tehingut ja loob bloki #88 (50a), submit node #3 võttis basseinist 670k tehingut ja loob bloki #88 (d3b)
04:44 — blokk #88 (d3b) on allkirjastatud ja saadetud teistele node'idele valideerimiseks
04:58 — blokk #88 (214) on allkirjastatud ja saadetud teistele node'idele valideerimiseks
05:11 — blokk #88 (50a) on allkirjastatud ja saadetud teistele node'idele valideerimiseks
05:11 — blokk #85 (d3b) on valideeritud ja saadetud juureketti
05:36 — blokk #85 (214) on valideeritud ja saadetud juureketti
05:43 — kõik node'id said juureketist teavet, et blokk #88 (d3b), #89(214) on lisatud ja hakkavad rakendama 670k, 750k tehingut
06:50 — seoses ühenduse katkeemisega blokk #85 (50a) ei olnud valideeritud
06:55 — submit node #2 võttis basseinist 888145 tehingut ja loob bloki #90 (50a)
08:14 — blokk #90 (50a) on allkirjastatud ja saadetud teistele node'idele valideerimiseks
09:04 — blokk #90 (50a) on valideeritud ja saadetud juureketti
11:23 — kõik node'id said juureketist teavet, et blokk #90 (50a) on lisatud ja hakkavad rakendama 888145 tehingut. Samal ajal on server #3 juba ammu rakendanud tehingud blokidest #88 (d3b), #89(214)
12:11 — kõik basseinid on tühjad
13:41 — kõik serveri #3 node'id sisaldavad 3 miljonit tehingut ja tokenit
14:35 — kõik serveri #1 node'id sisaldavad 3 miljonit tehingut ja tokenit
19:24 — kõik serveri #2 node'id sisaldavad 3 miljonit tehingut ja tokenit

Takistused

Plasma Cash arendamise ajal kohtusime järgmiste probleemidega, mida oleme järk-järgult lahendanud ja lahendame:

1. Süsteemi erinevate funktsioonide vastastikuse mõju konflikt. Näiteks tehingute lisamise funktsioon basseinidesse takistas submit'i ja bloki valideerimise tööd ja vastupidi, mis põhjustas kiiruslanguse.

2. Polnud kohe selge, kuidas saata tohutul hulgal tehinguid ja samal ajal andmeedastuskulusid minimaalsetena hoida.

3. Polnud selge, kuidas ja kus andmeid hoida, et saavutada kõrgeid tulemusi.

4. Polnud selge, kuidas korraldada võrku node'ide vahel, kuna 1 miljoni tehinguga blokk võtab umbes 100 MB.

5. Üksike töö režiim katkestab ühenduse node'ide vahel, kui toimuvad pikaajalised arvutused (nt Merkle puu ehitamine ja selle rühma hash'i arvutamine).

Kuidas me kõigi nende väljakutsetega hakkama saime?

Esimene versioon Plasma Cash node'ist oli mingi kombo, mis suutis teha kõike korraga: vastu võtta tehinguid, esitada ja valideerida plokke, pakkuda API-d andmetele juurdepääsuks. Kuna NodeJS on algselt ühetasandiline, siis koormav Merkle puu arvutamise funktsioon takistas tehingute lisamise funktsiooni. Me nägime kahte varianti selle probleemi lahendamiseks:

1. Käivitada mitu NodeJS protsessi, kus igaühel on oma kindlad funktsioonid.

2. Kasutada worker_threads, et viia osa koodist eraldi niitidesse.

Lõpuks kasutasime mõlemaid variante korraga: loogiliselt jagasime ühe node kolmeks osaks, mis võivad töötada eraldi, kuid samas ka sünkroonselt.

1. Tehingute vastuvõtmise node, mis haldab tehingute puulis ja nõustab plokkide loomist.

2. Valideerimise node, mis kontrollib node'ide kehtivust.

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

Samuti saab igale node'ile ühenduda läbi unix socketi CLI kaudu.

Koormavad operatsioonid, nagu Merkle puu arvutamine, viidi eraldi niiti.

Nii saavutasime Plasma Cash kõikide funktsioonide sujuva toimimise samal ajal ja ilma tõrgeteta.

Kuna süsteem hakkas funktsionaalselt tööle, alustasime kiiruseteste ja, kahjuks, saime rahuldavaid tulemusi: 5000 tehingut sekundis ja kuni 50 000 tehingut plokis. Pidin välja selgitama, mis oli valesti rakendatud.

Esiteks alustasime Plasma Cashiga suhtlemise mehhanismi testimist, et teada saada süsteemi tipvõimekust. Varem kirjutasime, et Plasma Cash node pakub unix socketi liidest. See oli algselt tekstipõhine. JSON objektid edastati, kasutades `JSON.parse()` ja `JSON.stringify()`.

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

Mõõtsime selliste objektide edastamise kiirust ja saime ~ 130k sekundis. Proovisime asendada standardseid JSON töötlemisfunktsioone, kuid jõudlust see ei parandanud. Tõenäoliselt on V8 mootor selliste operatsioonide jaoks hästi optimeeritud.

Tehingute, tokenite ja plokkidega töötamine toimus meil läbi klasside. Selliste klasside loomisel langes jõudlus kahekordselt, mis näitab, et OOP ei sobi meile. Pidi kirjutama kõik ümber puhtale funktsionaalsele lähenemisele.

Kirjutamine andmebaasi

Alguses valiti andmete salvestamiseks Redis kui üks kõige jõudlusest pakkuv lahendus, mis vastas meie nõudmistele: key-value salvestus, töötamine hash-tabelitega, hulgad. Käivitasime redis-benchmarki ja saime ~80k operatsiooni sekundis 1 pipelining režiimis.

Kõrge jõudluse saavutamiseks häälestasime Redis’e peenemalt:

Seadsime unix socket ühenduse.
Lülitasime välja oleku salvestamise kettale (usaldusväärsuse tagamiseks võib seadistada replikatsiooni ja juba eraldi Redis’is teha salvestamise kettale).

Redis'es on bassein — see on hash-tabel, kuna meil on vaja saada kõik tehingud ühe päringuga ja eemaldada tehingud ükshaaval. Proovisime kasutada tavalist nimekirja, kuid see toimis nimekirja laadimisel aeglasemalt.

Kasutades standardset NodeJS Redis teeki, saime jõudluse 18k tehingut sekundis. Kiirus langes 9 korda.

Kuna benchmark näitas meile selgelt 5 korda suuremaid võimalusi, alustasime optimeerimist. Muutsime teeki iorediseks ja saime jõudluse juba 25k sekundis. Tehingud lisasime ükshaaval, kasutades käsku `hset`. Sel viisil genereerisime palju päringuid Redis’ile. Tekkinud idee oli koguda tehingud partiidena ja saata need ühe käsuga `hmset`. Tulemuseks oli 32k sekundis.

Mitmel põhjusel, millest räägime allpool, töötame andmetega kasutades `Buffer`it ja, nagu selgus, kui see tõlkida tekstiks (`buffer.toString(‘hex’)`) enne salvestamist, saame lisajõudlust. Nii õnnestus kiirus tõsta 35k sekundini. Hetkel otsustasime edasise optimeerimise peatada.

Pidime minema üle binaarsesse protokolli, kuna:

1. Süsteem arvutab sageli hässe, allkirju jne, ja selleks on tal vaja andmeid `Buffer’ina.

2. Teenuste vahel edastades kaaluvad binaarsed andmed vähem kui tekst. Näiteks, kui saata blokk 1 miljoni tehinguga, võivad andmed tekstina võtta rohkem kui 300 megabaidi.

3. Andmete pidev konverteerimine mõjutab jõudlust.

Seetõttu põhinesime omaenda binaarsel protokollil andmete salvestamiseks ja edastamiseks, mis on välja töötatud suurepärase `binary-data` teegi baasil.

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` formaati, et salvestada need Redis-sse või edastada teisele sõlmele ja andmed uuesti välja võtta.

Meil on ka 2 binaarset protokolli andmete edastamiseks teenuste vahel:

— Protokoll Plasma Noode suhtlemiseks unix-soketiga

  ```json
  {
    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` — tegu, mida tuleb sooritada, näiteks 1 — sendTransaction, 2 — getTransaction;
`payload` — andmed, mis tuleb edastada vastavale funktsioonile;
`messageId` — sõnumi ID, et saaks tuvastada vastuse.

— Protokoll sõlmede vahel

  ```json
  {
    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 erinevate versioonidega sõlmed, mis võivad töötada erinevalt;
`seq` — sõnumi identifikaator;
`countChunk` ja `chunkNumber` on vajalikud suurte sõnumite osadeks jagamiseks;
`length` ja `payload` pikkus ja andmed.

Kuna oleme andmed eelnevalt tüübinud, töötab lõpp-süsteem palju kiiremini kui Ethereumi `rlp` teek. Kahjuks ei ole me veel suutnud sellest loobuda, kuna smart-leping vajab täiendavat arendust, mida plaanime tulevikus teha.

Kui suutsime saavutada kiirus 35 000 tehingut sekundis, peame neid ka töötlema optimaalse aja jooksul. Kuna ploki moodustamise ligikaudne aeg on 30 sekundit, peame plokki lisama 1 000 000 tehingut, mis tähendab enam kui 100 mb andmeid.

Alguses kasutasime `ethereumjs-devp2p` teeki sõlmede ühendamiseks, kuid see ei suutnud nii palju andmeid hallata. Selle tulemusel kasutasime `ws` teeki ja seadistasime binaarsete andmete edastamise websocketi kaudu. Loomulikult kohtasime ka probleeme suurte andmepakettide edastamisel, kuid jagasime need chunkideks ja nüüd pole meil enam neid probleeme.

Samuti kulub Merkle puu koostamiseks ja räsimise arvutamiseks umbes 1 000 000 sekundit pidevat arvutust. Selle aja jooksul katkeb ühendus kõigi sõlmedega. Otsustati kanda see arvutus eraldi tõõle. 10 Tegelikult ei ole meie järeldused uudsed, kuid mingil põhjusel unustavad paljud spetsialistid need arendamisel.

Kokkuvõtted:

Funktsionaalse programmeerimise kasutamine objektorienteeritud programmeerimise asemel tõstab jõudlust.

Monoliitne arhitektuur on halvem kui teenuse arhitektuur produktiivses NodeJS süsteemis.
Töötajate lõime (`worker_threads`) kasutamine raskete arvutuste jaoks parandab süsteemi reageerimisvõimet, eriti i/o operatsioonide teostamisel.
Unix socket on stabiilsem ja kiirem kui http päringud.
Kui on vaja kiiresti edastada suuri andmeid üle võrgu, on parem kasutada websocket'e ja saata binaarsete andmete choke'id, mida saab edastada, kui need ei jõu, ja seejärel ühendada üheks sõnumiks.
Plokiahel on innovaatiline tehnoloogia, mis lubab parandada paljusid inimelu valdkondi.

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

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

Allikas: habr.com