🥇Javni preizkus: rešitev za zasebnost in razširljivost na Ethereumu

Blockchain je inovativna tehnologija, ki obljublja izboljšanje številnih področij človeškega življenja. Prenaša realne procese in produkte v digitalni prostor, zagotavlja hitrost in zanesljivost finančnih transakcij, znižuje njihove stroške, omogoča pa tudi ustvarjanje sodobnih DAPP aplikacij s pametnimi pogodbami v decentraliziranih omrežjih.

Glede na številne prednosti in raznolike aplikacije blockchaina se morda zdi presenetljivo, da ta obetavna tehnologija še ni prišla v vse industrije. Težava je v tem, da sodobnim decentraliziranim verigam blokov primanjkuje razširljivosti. Ethereum obdela približno 20 transakcij na sekundo, kar je premalo za potrebe današnjega dinamičnega poslovanja. Hkrati se podjetja, ki uporabljajo tehnologijo blockchain, obotavljajo opustiti Ethereum zaradi njegove visoke stopnje zaščite pred vdori in napakami v omrežju.

Da bi zagotovili decentralizacijo, varnost in razširljivost v verigi blokov ter tako rešili trilemo razširljivosti, je razvojna ekipa Opporty ustvaril Plasma Cash, hčerinsko verigo, sestavljeno iz pametne pogodbe in zasebnega omrežja, ki temelji na Node.js, ki periodično prenaša svoje stanje v korensko verigo (Ethereum).

Ključni procesi v Plasma Cash

1. Uporabnik funkcijo pametne pogodbe pokliče `depozit` in vanjo prenese znesek ETH, ki ga želi nakazati v žeton Plasma Cash. Funkcija pametne pogodbe ustvari žeton in ustvari dogodek o njem.

2. Vozlišča Plasma Cash, naročena na dogodke pametnih pogodb, prejmejo dogodek o ustvarjanju depozita in v skupino dodajo transakcijo o ustvarjanju žetona.

3. Občasno posebna vozlišča Plasma Cash vzamejo vse transakcije iz bazena (do 1 milijona) in iz njih oblikujejo blok, izračunajo drevo Merkle in s tem zgoščeno vrednost. Ta blok se pošlje drugim vozliščem v preverjanje. Vozlišča preverjajo, ali je Merkle hash veljaven in ali so transakcije veljavne (na primer, ali je pošiljatelj žetona njegov lastnik). Po preverjanju bloka vozlišče pokliče funkcijo `submitBlock` pametne pogodbe, ki shrani številko bloka in Merkle hash v robno verigo. Pametna pogodba ustvari dogodek, ki nakazuje uspešno dodajanje bloka. Transakcije so odstranjene iz bazena.

4. Vozlišča, ki prejmejo dogodek oddaje bloka, začnejo uporabljati transakcije, ki so bile dodane bloku.

5. Na neki točki želi lastnik (ali nelastnik) žetona le-tega dvigniti iz Plasma Cash. Za to pokliče funkcijo `startExit` in ji posreduje informacije o zadnjih 2 transakcijah na žetonu, ki potrjujeta, da je on lastnik žetona. Pametna pogodba z uporabo Merkle hash preveri prisotnost transakcij v blokih in pošlje žeton za dvig, ki se bo zgodil čez dva tedna.

6. Če je operacija dviga žetona potekala s kršitvami (žeton je bil porabljen po začetku postopka dviga ali je bil žeton pred dvigom že nekdo drug), lahko lastnik žetona dvig zavrne v dveh tednih.

Zasebnost se doseže na dva načina

1. Korenska veriga ne ve ničesar o transakcijah, ki so ustvarjene in posredovane znotraj podrejene verige. Podatki o tem, kdo je položil in dvignil ETH iz Plasma Cash, ostajajo javni.

2. Podrejena veriga omogoča anonimne transakcije z uporabo zk-SNARK.

Tehnološki sklad

NodeJS
Redis
Eterij
tla

Testiranje

Pri razvoju Plasma Cash smo testirali hitrost sistema in dobili naslednje rezultate:

v bazen je dodanih do 35 transakcij na sekundo;
v blok lahko shranite do 1 transakcij.

Testi so bili izvedeni na naslednjih 3 strežnikih:

1. Intel Core i7-6700 Quad-Core Skylake vklj. NVMe SSD – 512 GB, 64 GB DDR4 RAM
Vzpostavljena so bila 3 potrditvena vozlišča Plasma Cash.

2. AMD Ryzen 7 1700X Octa-Core “Summit Ridge” (Zen), SATA SSD – 500 GB, 64 GB DDR4 RAM
Vozlišče Ropsten testnet ETH je bilo postavljeno.
Vzpostavljena so bila 3 potrditvena vozlišča Plasma Cash.

3. Intel Core i9-9900K Octa-Core vklj. NVMe SSD – 1 TB, 64 GB DDR4 RAM
Postavljeno je bilo 1 vozlišče za predložitev Plasma Cash.
Vzpostavljena so bila 3 potrditvena vozlišča Plasma Cash.
Izveden je bil test za dodajanje transakcij v omrežje Plasma Cash.

Skupaj: 10 vozlišč Plasma Cash v zasebnem omrežju.

Test 1

Obstaja omejitev 1 milijona transakcij na blok. Zato 1 milijon transakcij pade v 2 bloka (sistem uspe prevzeti del transakcij in predložiti med pošiljanjem).

Začetno stanje: zadnji blok #7; V bazi podatkov je shranjenih 1 milijon transakcij in žetonov.

00:00 — začetek skripta za generiranje transakcije
01:37 - Ustvarjenih je bilo 1 milijon transakcij in začelo se je pošiljanje v vozlišče
01:46 — vozlišče za oddajo je vzelo 240 transakcij iz skupine in tvori blok št. 8. Vidimo tudi, da je 320k transakcij dodanih v bazen v 10 sekundah
01:58 — blok #8 je podpisan in poslan v validacijo
02:03 — blok št. 8 je potrjen in funkcija `submitBlock` pametne pogodbe je poklicana z zgoščeno vrednostjo Merkle in številko bloka
02:10 — Demo skript je končal delo, ki je v 1 sekundah poslalo 32 milijon transakcij
02:33 - vozlišča so začela prejemati informacije, da je bil blok št. 8 dodan v korensko verigo in začela izvajati 240k transakcij
02:40 - 240k transakcij je bilo odstranjenih iz bazena, ki so že v bloku #8
02:56 — vozlišče za predložitev je vzelo preostalih 760 transakcij iz bazena in začelo izračunavati Merkle hash in podpisovati blok št. 9
03:20 - vsa vozlišča vsebujejo 1 milijon 240k transakcij in žetonov
03:35 — blok #9 je podpisan in poslan v potrditev drugim vozliščem
03:41 - prišlo je do napake v omrežju
04:40 — čakanje na preverjanje bloka #9 je poteklo
04:54 — vozlišče za predložitev je vzelo preostalih 760 transakcij iz bazena in začelo izračunavati Merkle hash in podpisovati blok št. 9
05:32 — blok #9 je podpisan in poslan v potrditev drugim vozliščem
05:53 — blok #9 je preverjen in poslan v korensko verigo
06:17 - vozlišča so začela prejemati informacije, da je bil blok #9 dodan v korensko verigo in je začel izvajati 760k transakcij
06:47 — bazen je očiščen transakcij, ki so v bloku #9
09:06 - vsa vozlišča vsebujejo 2 milijona transakcij in žetonov

Test 2

Obstaja omejitev 350k na blok. Kot rezultat, imamo 3 bloke.

Začetno stanje: zadnji blok #9; V bazi podatkov je shranjenih 2 milijona transakcij in žetonov

00:00 — skript za generiranje transakcij je že zagnan
00:44 - Ustvarjenih je bilo 1 milijon transakcij in začelo se je pošiljanje v vozlišče
00:56 — vozlišče za oddajo je vzelo 320 transakcij iz skupine in tvori blok št. 10. Vidimo tudi, da je 320k transakcij dodanih v bazen v 10 sekundah
01:12 — blok #10 je podpisan in poslan drugim vozliščem v preverjanje
01:18 — Demo skript je končal delo, ki je v 1 sekundah poslalo 34 milijon transakcij
01:20 — blok #10 je preverjen in poslan v korensko verigo
01:51 - vsa vozlišča so prejela informacijo iz korenske verige, da je bil dodan blok #10 in so začela uporabljati 320k transakcij
02:01 - bazen je očiščen za 320 transakcij, ki so bile dodane v blok #10
02:15 — vozlišče za oddajo je vzelo 350 transakcij iz skupine in tvori blok št. 11
02:34 — blok #11 je podpisan in poslan drugim vozliščem v preverjanje
02:51 — blok #11 je preverjen in poslan v korensko verigo
02:55 — zadnje vozlišče je zaključilo transakcije iz bloka #10
10:59 — transakcija s predložitvijo bloka #9 je trajala zelo dolgo v korenski verigi, vendar je bila zaključena in vsa vozlišča so prejela informacije o tem in začela izvajati 350k transakcij
11:05 - bazen je očiščen za 320 transakcij, ki so bile dodane v blok #11
12:10 - vsa vozlišča vsebujejo 1 milijon 670k transakcij in žetonov
12:17 — vozlišče za oddajo je vzelo 330 transakcij iz skupine in tvori blok št. 12
12:32 — blok #12 je podpisan in poslan drugim vozliščem v preverjanje
12:39 — blok #12 je preverjen in poslan v korensko verigo
13:44 - vsa vozlišča so prejela informacijo iz korenske verige, da je bil dodan blok #12 in so začela uporabljati 330k transakcij
14:50 - vsa vozlišča vsebujejo 2 milijona transakcij in žetonov

Test 3

V prvem in drugem strežniku je bilo eno potrditveno vozlišče nadomeščeno s predložitvenim vozliščem.

Začetno stanje: zadnji blok #84; V bazi podatkov je shranjenih 0 transakcij in žetonov

00:00 — Predstavljeni so bili 3 skripti, ki ustvarijo in pošljejo vsak po 1 milijon transakcij
01:38 — Ustvarjenih je bilo 1 milijon transakcij in začelo se je pošiljanje v vozlišče št
01:50 — vozlišče za oddajo št. 3 je vzelo 330 transakcij iz skupine in tvori blok št. 85 (f21). Vidimo tudi, da je 350 transakcij dodanih v bazen v 10 sekundah
01:53 — Ustvarjenih je bilo 1 milijon transakcij in začelo se je pošiljanje v vozlišče št
01:50 — vozlišče za oddajo št. 3 je vzelo 330 transakcij iz skupine in tvori blok št. 85 (f21). Vidimo tudi, da je 350 transakcij dodanih v bazen v 10 sekundah
02:01 — vozlišče za oddajo št. 1 je vzelo 250 transakcij iz bazena in tvori blok št. 85 (65e)
02:06 — blok #85 (f21) je podpisan in poslan drugim vozliščem v preverjanje
02:08 — Demo skripta strežnika #3, ki je v 1 sekundah poslala 30 milijon transakcij, je končala z delom
02:14 — blok #85 (f21) je preverjen in poslan v korensko verigo
02:19 — blok #85 (65e) je podpisan in poslan drugim vozliščem v preverjanje
02:22 — Ustvarjenih je bilo 1 milijon transakcij in začelo se je pošiljanje v vozlišče št
02:27 — blok #85 (65e) preverjen in poslan v korensko verigo
02:29 — vozlišče za oddajo #2 je vzelo 111855 transakcij iz bazena in oblikuje blok #85 (256).
02:36 — blok #85 (256) je podpisan in poslan drugim vozliščem v preverjanje
02:36 — Demo skripta strežnika #1, ki je v 1 sekundah poslala 42.5 milijon transakcij, je končala z delom
02:38 — blok #85 (256) je preverjen in poslan v korensko verigo
03:08 — skript strežnika #2 je končal z delom, ki je v 1 sekundah poslal 47 milijon transakcij
03:38 - vsa vozlišča so prejela informacijo iz korenske verige, da so bili bloki #85 (f21), #86(65e), #87(256) dodani in so začeli uporabljati 330k, 250k, 111855 transakcij
03:49 - bazen je bil počiščen pri 330k, 250k, 111855 transakcijah, ki so bile dodane v bloke #85 (f21), #86(65e), #87(256)
03:59 — vozlišče za oddajo #1 je vzelo 888145 transakcij iz bazena in blok obrazcev #88 (214), vozlišče za oddajo #2 je vzelo 750 transakcij iz bazena in blok #88 obrazcev (50a), vozlišče za oddajo #3 je prevzelo 670 transakcij iz bazen in obrazci blok #88 (d3b)
04:44 — blok #88 (d3b) je podpisan in poslan drugim vozliščem v preverjanje
04:58 — blok #88 (214) je podpisan in poslan drugim vozliščem v preverjanje
05:11 — blok #88 (50a) je podpisan in poslan drugim vozliščem v preverjanje
05:11 — blok #85 (d3b) je preverjen in poslan v korensko verigo
05:36 — blok #85 (214) je preverjen in poslan v korensko verigo
05:43 - vsa vozlišča so prejela informacijo iz korenske verige, da so bili bloki #88 (d3b), #89(214) dodani in začenjajo uporabljati 670k, 750k transakcij
06:50 — zaradi okvare komunikacije blok #85 (50a) ni bil preverjen
06:55 — vozlišče za oddajo #2 je vzelo 888145 transakcij iz skupine in tvori blok #90 (50a)
08:14 — blok #90 (50a) je podpisan in poslan drugim vozliščem v preverjanje
09:04 — blok #90 (50a) je preverjen in poslan v korensko verigo
11:23 - vsa vozlišča so prejela informacijo iz korenske verige, da je bil dodan blok #90 (50a), in začela uporabljati 888145 transakcij. Hkrati je strežnik #3 že uporabil transakcije iz blokov #88 (d3b), #89(214)
12:11 - vsi bazeni so prazni
13:41 — vsa vozlišča strežnika #3 vsebujejo 3 milijone transakcij in žetonov
14:35 — vsa vozlišča strežnika #1 vsebujejo 3 milijone transakcij in žetonov
19:24 — vsa vozlišča strežnika #2 vsebujejo 3 milijone transakcij in žetonov

Ovire

Pri razvoju Plasma Cash smo naleteli na naslednje težave, ki smo jih postopoma reševali in jih rešujemo:

1. Konflikt v interakciji različnih sistemskih funkcij. Na primer, funkcija dodajanja transakcij v bazen je blokirala delo pri oddaji in potrjevanju blokov in obratno, kar je povzročilo padec hitrosti.

2. Ni bilo takoj jasno, kako poslati ogromno število transakcij in hkrati zmanjšati stroške prenosa podatkov.

3. Ni bilo jasno, kako in kje hraniti podatke za doseganje visokih rezultatov.

4. Ni bilo jasno, kako organizirati omrežje med vozlišči, saj velikost bloka z 1 milijonom transakcij zavzame približno 100 MB.

5. Delo v enonitnem načinu prekine povezavo med vozlišči, ko pride do dolgih izračunov (na primer izdelava drevesa Merkle in izračun njegove zgoščene vrednosti).

Kako smo se z vsem tem spopadli?

Prva različica vozlišča Plasma Cash je bila neke vrste kombinacija, ki je lahko počela vse hkrati: sprejemala transakcije, pošiljala in potrjevala bloke ter zagotavljala API za dostop do podatkov. Ker je NodeJS izvorno enoniten, je težka funkcija izračuna drevesa Merkle blokirala funkcijo dodajanja transakcij. Videli smo dve možnosti za rešitev te težave:

1. Zaženite več procesov NodeJS, od katerih vsak izvaja posebne funkcije.

2. Uporabite worker_threads in premaknite izvajanje dela kode v niti.

Posledično smo uporabili obe možnosti hkrati: eno vozlišče smo logično razdelili na 3 dele, ki lahko delujejo ločeno, a hkrati sinhrono

1. Submission vozlišče, ki sprejema transakcije v bazen in ustvarja bloke.

2. Potrditveno vozlišče, ki preverja veljavnost vozlišč.

3. API vozlišče – ponuja API za dostop do podatkov.

V tem primeru se lahko povežete z vsakim vozliščem prek vtičnice unix z uporabo cli.

Težke operacije, kot je izračun Merklovega drevesa, smo premaknili v ločeno nit.

Tako smo dosegli normalno delovanje vseh funkcij Plasma Cash hkrati in brez okvar.

Ko je sistem deloval, smo začeli testirati hitrost in na žalost prejeli nezadovoljive rezultate: 5 transakcij na sekundo in do 000 transakcij na blok. Moral sem ugotoviti, kaj je bilo implementirano narobe.

Za začetek smo začeli testirati mehanizem za komunikacijo s Plasma Cashom, da bi ugotovili največjo zmogljivost sistema. Prej smo pisali, da vozlišče Plasma Cash zagotavlja vmesnik vtičnice unix. Sprva je temeljil na besedilu. json objekti so bili poslani z uporabo `JSON.parse()` in `JSON.stringify()`.

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

Izmerili smo hitrost prenosa takih predmetov in ugotovili ~ 130k na sekundo. Poskušali smo zamenjati standardne funkcije za delo z json, vendar se zmogljivost ni izboljšala. Motor V8 mora biti dobro optimiziran za te operacije.

Delali smo s transakcijami, žetoni in bloki skozi razrede. Pri ustvarjanju takšnih razredov je zmogljivost padla za 2-krat, kar pomeni, da OOP ni primeren za nas. Vse sem moral prepisati na čisto funkcionalen pristop.

Snemanje v bazo podatkov

Sprva je bil Redis izbran za shranjevanje podatkov kot ena najbolj produktivnih rešitev, ki zadovoljuje naše zahteve: ključ-vrednost shranjevanje, delo z zgoščenimi tabelami, nizi. Zagnali smo redis-benchmark in dobili ~80 operacij na sekundo v 1 cevovodnem načinu.

Za visoko zmogljivost smo Redis natančneje prilagodili:

Vzpostavljena je povezava z vtičnico unix.
Onemogočili smo shranjevanje stanja na disk (zaradi zanesljivosti lahko nastavite repliko in shranite na disk v ločenem Redisu).

V Redisu je bazen zgoščena tabela, ker moramo imeti možnost pridobiti vse transakcije v eni poizvedbi in izbrisati transakcije eno za drugo. Poskušali smo uporabiti običajni seznam, vendar je počasnejši pri raztovarjanju celotnega seznama.

Pri uporabi standardnega NodeJS so knjižnice Redis dosegle zmogljivost 18k transakcij na sekundo. Hitrost je padla 9-krat.

Ker nam je merilo uspešnosti pokazalo, da so možnosti očitno 5-krat večje, smo začeli z optimizacijo. Knjižnico smo spremenili v ioredis in dobili zmogljivost 25k na sekundo. Transakcije smo dodajali eno za drugo z ukazom `hset`. Zato smo v Redisu ustvarili veliko poizvedb. Pojavila se je ideja, da bi transakcije združili v pakete in jih poslali z enim ukazom `hmset`. Rezultat je 32k na sekundo.

Iz več razlogov, ki jih bomo opisali spodaj, delamo s podatki z uporabo `Buffer` in, kot se je izkazalo, če jih pretvorite v besedilo (`buffer.toString('hex')`) pred pisanjem, lahko dobite dodatne izvedba. Tako se je hitrost povečala na 35k na sekundo. Trenutno smo se odločili, da prekinemo nadaljnjo optimizacijo.

Morali smo preiti na binarni protokol, ker:

1. Sistem pogosto izračuna zgoščene vrednosti, podpise itd., za to pa potrebuje podatke v `Buffer.

2. Pri pošiljanju med storitvami binarni podatki tehtajo manj kot besedilo. Na primer, pri pošiljanju bloka z 1 milijonom transakcij lahko podatki v besedilu zavzamejo več kot 300 megabajtov.

3. Nenehno spreminjanje podatkov vpliva na zmogljivost.

Zato smo za osnovo vzeli lasten binarni protokol za shranjevanje in prenos podatkov, razvit na podlagi čudovite knjižnice `binary-data`.

Kot rezultat smo dobili naslednje podatkovne strukture:

— Transakcija

  ```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,
  }
  ```

- Žeton

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

— Blokiraj

  ```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,
  }
  ```

Z običajnimi ukazi `BD.encode(block, Protocol).slice();` in `BD.decode(buffer, Protocol)` pretvorimo podatke v `Buffer` za shranjevanje v Redis ali posredovanje v drugo vozlišče in pridobivanje podatke nazaj.

Imamo tudi 2 binarna protokola za prenos podatkov med storitvami:

— Protokol za interakcijo s Plasma Node prek vtičnice unix

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

kjer je:

`tip` — dejanje, ki naj se izvede, na primer 1 — sendTransaction, 2 — getTransaction;
`tovor` — podatke, ki jih je treba posredovati ustrezni funkciji;
`id sporočila` — ID sporočila, da je mogoče prepoznati odgovor.

— Protokol za interakcijo med vozlišči

  ```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)
  }
  ```

kjer je:

`koda` — koda sporočila, na primer 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
`versionProtocol` — različica protokola, saj je mogoče v omrežju dvigniti vozlišča z različnimi različicami in lahko delujejo različno;
`seq` — identifikator sporočila;
`countChunk` и `število kosa` potrebno za razdelitev velikih sporočil;
`dolžina` и `tovor` dolžina in podatki sami.

Ker smo podatke vnaprej vnesli, je končni sistem veliko hitrejši od Ethereumove knjižnice `rlp`. Žal nam je še ni uspelo zavrniti, saj je treba pametno pogodbo dokončati, kar načrtujemo v prihodnosti.

Če nam je uspelo doseči hitrost 35 000 transakcij na sekundo, jih moramo tudi obdelati v optimalnem času. Ker približen čas oblikovanja bloka traja 30 sekund, ga moramo vključiti v blok 1 000 000 transakcij, kar pomeni pošiljanje več 100 MB podatkov.

Sprva smo za komunikacijo med vozlišči uporabljali knjižnico `ethereumjs-devp2p`, vendar ni mogla obdelati toliko podatkov. Posledično smo uporabili knjižnico `ws` in konfigurirali pošiljanje binarnih podatkov prek spletne vtičnice. Seveda smo naleteli tudi na težave pri pošiljanju velikih podatkovnih paketov, vendar smo jih razdelili na kose in teh težav zdaj ni več.

Tudi oblikovanje Merklovega drevesa in izračun hash-a 1 000 000 transakcij zahteva približno 10 sekund neprekinjenega izračuna. V tem času se povezava z vsemi vozlišči uspe prekiniti. Odločeno je bilo, da se ta izračun premakne v ločeno nit.

Sklepi:

Pravzaprav naše ugotovitve niso nove, a mnogi strokovnjaki nanje pri razvoju iz nekega razloga pozabijo.

Uporaba funkcionalnega programiranja namesto objektno usmerjenega programiranja izboljša produktivnost.
Monolit je slabši od storitvene arhitekture za produktiven sistem NodeJS.
Uporaba `worker_threads` za težke izračune izboljša odzivnost sistema, zlasti pri v/i operacijah.
vtičnica unix je stabilnejša in hitrejša od zahtev http.
Če morate po omrežju hitro prenesti velike količine podatkov, je bolje uporabiti spletne vtičnice in poslati binarne podatke, razdeljene na dele, ki jih je mogoče posredovati, če ne prispejo, in nato združiti v eno sporočilo.

Vabimo vas na obisk GitHub projekt: https://github.com/opporty-com/Plasma-Cash/tree/new-version

Članek je bil soavtor Aleksander Našivan, višji razvijalec Clever Solution Inc.

Vir: www.habr.com

Javni preizkus: rešitev za zasebnost in razširljivost na Ethereumu