Blockchain is in ynnovative technology dy't belooft in protte gebieten fan it minsklik libben te ferbetterjen. It bringt echte prosessen en produkten oer yn 'e digitale romte, soarget foar snelheid en betrouberens fan finansjele transaksjes, ferleget har kosten, en lit jo ek moderne DAPP-applikaasjes meitsje mei tûke kontrakten yn desintralisearre netwurken.
Mei it each op de protte foardielen en ferskate tapassingen fan blockchain, kin it ferrassend lykje dat dizze kânsrike technology noch net yn elke yndustry syn paad hat makke. It probleem is dat moderne desintralisearre blockchains skaalberens misse. Ethereum ferwurket sawat 20 transaksjes per sekonde, wat net genôch is om te foldwaan oan 'e behoeften fan hjoeddeistige dynamyske bedriuwen. Tagelyk binne bedriuwen dy't blockchain-technology brûke, twifelje om Ethereum te ferlitten fanwege har hege beskerming tsjin hacking en netwurkmislearrings.
Om desintralisaasje, feiligens en skalberens yn 'e blockchain te garandearjen, sadat it Scalability Trilemma oplost, it ûntwikkelteam makke Plasma Cash, in dochterûndernimming keten besteande út in tûk kontrakt en in partikuliere netwurk basearre op Node.js, dy't periodyk oerstappen syn steat oan de woartel keatling (Ethereum).
Key prosessen yn Plasma Cash
1. De brûker neamt de tûke kontraktfunksje 'boarch', en bringt it bedrach fan ETH troch dat hy wol deponearje yn it Plasma Cash-token. De tûke kontraktfunksje makket in token en genereart dêr in evenemint oer.
2. Plasma Cash-knooppunten dy't ynskreaun binne op smart kontrakt-eveneminten krije in evenemint oer it meitsjen fan in boarch en foegje in transaksje ta oer it meitsjen fan in token oan it swimbad.
3. Periodyk nimme spesjale Plasma Cash-knooppunten alle transaksjes út it swimbad (oant 1 miljoen) en foarmje in blok fan har, berekkenje de Merkle-beam en, dus, de hash. Dit blok wurdt stjoerd nei oare knopen foar ferifikaasje. De knopen kontrolearje oft de Merkle-hash jildich is en oft de transaksjes jildich binne (bygelyks oft de stjoerder fan it token de eigner is). Nei it ferifiearjen fan it blok ropt de knoop de funksje 'submitBlock' fan 'e tûke kontrakt, dy't it bloknûmer en Merkle-hash oan 'e râneketen bewarret. It tûke kontrakt genereart in evenemint dat de suksesfolle tafoeging fan in blok oanjout. Transaksjes wurde fuorthelle út it swimbad.
4. Knooppunten dy't it blok-yntsjinjen-evenemint ûntfange, begjinne de transaksjes oan te passen dy't oan it blok tafoege binne.
5. Op in stuit wol de eigner (of net-eigner) fan it token it weromlûke fan Plasma Cash. Om dit te dwaan, neamt hy de funksje 'startExit', en jout dêryn ynformaasje oer de lêste 2 transaksjes op it token, dy't befêstigje dat hy de eigner fan it token is. De tûke kontrakt, mei de Merkle-hash, kontrolearret de oanwêzigens fan transaksjes yn 'e blokken en stjoert de token foar weromlûking, dy't yn twa wiken foarkomme.
6. As de token-weromlûkoperaasje barde mei oertredings (it token waard bestege nei't de weromlûkingsproseduere begon of it token wie al fan in oar foar it weromlûken), kin de eigner fan it token it weromlûken binnen twa wiken wjerlizze.
Privacy wurdt berikt op twa manieren
1. De rootketen wit neat oer de transaksjes dy't wurde generearre en trochstjoerd binnen de berneketen. Ynformaasje oer wa't deponearre en luts ETH út Plasma Cash bliuwt iepenbier.
2. De berneketen lit anonime transaksjes mei zk-SNARKs brûke.
Technology stack
- NodeJS
- Redis
- etherium
- Sild
Testing
By it ûntwikkeljen fan Plasma Cash testen wy de snelheid fan it systeem en krigen de folgjende resultaten:
- oant 35 transaksjes per sekonde wurde tafoege oan it swimbad;
- oant 1 transaksjes kinne wurde opslein yn in blok.
Tests waarden útfierd op de folgjende 3 servers:
1. Intel Core i7-6700 Quad-Core Skylake incl. NVMe SSD - 512 GB, 64 GB DDR4 RAM
3 falidearjende Plasma Cash knopen waarden grutbrocht.
2. AMD Ryzen 7 1700X Octa-Core "Summit Ridge" (Zen), SATA SSD - 500 GB, 64 GB DDR4 RAM
De Ropsten testnet ETH knooppunt waard ferhege.
3 falidearjende Plasma Cash knopen waarden grutbrocht.
3. Intel Core i9-9900K Octa-Core incl. NVMe SSD - 1 TB, 64 GB DDR4 RAM
1 Plasma Cash yntsjinjen knooppunt waard ferhege.
3 falidearjende Plasma Cash knopen waarden grutbrocht.
In test waard lansearre om transaksjes ta te foegjen oan it Plasma Cash-netwurk.
Totaal: 10 Plasma Cash knopen yn in privee netwurk.
Test 1
D'r is in limyt fan 1 miljoen transaksjes per blok. Dêrom falle 1 miljoen transaksjes yn 2 blokken (om't it systeem it slagget om diel te nimmen fan 'e transaksjes en yntsjinje wylst se ferstjoerd wurde).
Inisjele steat: lêste blok # 7; 1 miljoen transaksjes en tokens wurde opslein yn 'e databank.
00:00 - begjin fan transaksje generaasje skript
01:37 - 1 miljoen transaksjes waarden makke en it ferstjoeren nei it knooppunt begon
01:46 - submit node naam 240k transaksjes út it swimbad en foarmje blok #8. Wy sjogge ek dat 320k transaksjes wurde tafoege oan it swimbad yn 10 sekonden
01:58 - blok #8 wurdt tekene en stjoerd foar falidaasje
02:03 - blok #8 wurdt falidearre en de 'submitBlock'-funksje fan it tûke kontrakt wurdt oproppen mei de Merkle-hash en bloknûmer
02:10 - demo-skript klear mei wurkjen, dy't 1 miljoen transaksjes yn 32 sekonden stjoerde
02:33 - knopen begûnen ynformaasje te ûntfangen dat blok #8 waard tafoege oan 'e rootketen, en begon 240k transaksjes út te fieren
02:40 - 240k transaksjes waarden fuortsmiten út it swimbad, dy't al yn blok #8 binne
02:56 - submit node naam de oerbleaune 760k transaksjes út it swimbad en begon de Merkle-hash te berekkenjen en ûndertekeningsblok #9
03:20 - alle knopen befetsje 1 miljoen 240k transaksjes en tokens
03:35 - blok #9 wurdt tekene en stjoerd foar falidaasje nei oare knopen
03:41 - Netwurkflater barde
04:40 - wachtsjen op validaasje fan blok #9 hat in time-out
04:54 - submit node naam de oerbleaune 760k transaksjes út it swimbad en begon de Merkle-hash te berekkenjen en ûndertekeningsblok #9
05:32 - blok #9 wurdt tekene en stjoerd foar falidaasje nei oare knopen
05:53 - blok #9 wurdt falidearre en stjoerd nei de rootketen
06:17 - knopen begon ynformaasje te ûntfangen dat blok #9 waard tafoege oan 'e rootketen en begon 760k transaksjes út te fieren
06:47 - it swimbad hat ferwidere fan transaksjes dy't yn blok #9 binne
09:06 - alle knopen befetsje 2 miljoen transaksjes en tokens
Test 2
D'r is in limyt fan 350k per blok. As gefolch hawwe wy 3 blokken.
Inisjele steat: lêste blok # 9; 2 miljoen transaksjes en tokens wurde opslein yn 'e databank
00:00 - transaksjegeneraasjeskript is al lansearre
00:44 - 1 miljoen transaksjes waarden makke en it ferstjoeren nei it knooppunt begon
00:56 - submit node naam 320k transaksjes út it swimbad en foarmje blok #10. Wy sjogge ek dat 320k transaksjes wurde tafoege oan it swimbad yn 10 sekonden
01:12 - blok #10 wurdt tekene en stjoerd nei oare knopen foar falidaasje
01:18 - demo-skript klear mei wurkjen, dy't 1 miljoen transaksjes yn 34 sekonden stjoerde
01:20 - blok #10 wurdt falidearre en stjoerd nei de rootketen
01:51 - alle knopen krigen ynformaasje fan 'e rootketen dat blok #10 waard tafoege en begjinne 320k transaksjes oan te passen
02:01 - it swimbad hat wiske foar 320k transaksjes dy't waarden tafoege oan blok #10
02:15 - submit node naam 350k transaksjes út it swimbad en formulieren blok #11
02:34 - blok #11 wurdt tekene en stjoerd nei oare knopen foar falidaasje
02:51 - blok #11 wurdt falidearre en stjoerd nei de rootketen
02:55 - de lêste knooppunt foltôge transaksjes fan blok #10
10:59 - de transaksje mei it yntsjinjen fan blok #9 naam in heul lange tiid yn 'e rootketen, mar it wie foltôge en alle knopen krigen ynformaasje deroer en begûnen 350k transaksjes út te fieren
11:05 - it swimbad hat wiske foar 320k transaksjes dy't waarden tafoege oan blok #11
12:10 - alle knopen befetsje 1 miljoen 670k transaksjes en tokens
12:17 - submit node naam 330k transaksjes út it swimbad en formulieren blok #12
12:32 - blok #12 wurdt tekene en stjoerd nei oare knopen foar falidaasje
12:39 - blok #12 wurdt falidearre en stjoerd nei de rootketen
13:44 - alle knooppunten krigen ynformaasje fan 'e rootketen dat blok #12 waard tafoege en begjinne 330k transaksjes oan te passen
14:50 - alle knopen befetsje 2 miljoen transaksjes en tokens
Test 3
Yn 'e earste en twadde tsjinners waard ien falidearjende knooppunt ferfongen troch in yntsjinjende knooppunt.
Inisjele steat: lêste blok # 84; 0 transaksjes en tokens opslein yn 'e database
00:00 - 3 skripts binne lansearre dy't elk 1 miljoen transaksjes generearje en ferstjoere
01:38 - 1 miljoen transaksjes waarden makke en it ferstjoeren fan node #3 begon
01:50 - submit node #3 naam 330k transaksjes út it swimbad en foarmje blok #85 (f21). Wy sjogge ek dat 350k transaksjes wurde tafoege oan it swimbad yn 10 sekonden
01:53 - 1 miljoen transaksjes waarden makke en it ferstjoeren fan node #1 begon
01:50 - submit node #3 naam 330k transaksjes út it swimbad en foarmje blok #85 (f21). Wy sjogge ek dat 350k transaksjes wurde tafoege oan it swimbad yn 10 sekonden
02:01 - knooppunt #1 yntsjinje naam 250k transaksjes út it swimbad en foarmje blok #85 (65e)
02:06 - blok #85 (f21) wurdt tekene en stjoerd nei oare knopen foar falidaasje
02:08 - demoskript fan server #3, dy't 1 miljoen transaksjes yn 30 sekonden stjoerde, dien mei wurkjen
02:14 - blok #85 (f21) wurdt falidearre en stjoerd nei de rootketen
02:19 - blok #85 (65e) wurdt tekene en stjoerd nei oare knopen foar falidaasje
02:22 - 1 miljoen transaksjes waarden makke en it ferstjoeren fan node #2 begon
02:27 - blok #85 (65e) falidearre en stjoerd nei de rootketen
02:29 - submit node #2 naam 111855 transaksjes út it swimbad en foarmje blok #85 (256).
02:36 - blok #85 (256) wurdt tekene en stjoerd nei oare knopen foar falidaasje
02:36 - demoskript fan server #1, dy't 1 miljoen transaksjes yn 42.5 sekonden stjoerde, dien mei wurkjen
02:38 - blok #85 (256) wurdt falidearre en stjoerd nei de rootketen
03:08 - Server #2 skript klear mei wurkjen, dy't 1 miljoen transaksjes yn 47 sekonden stjoerde
03:38 - alle knooppunten krigen ynformaasje fan 'e rootketen dy't blokken #85 (f21), #86 (65e), #87 (256) waarden tafoege en begon 330k, 250k, 111855 transaksjes oan te passen
03:49 - it swimbad waard wiske op 330k, 250k, 111855 transaksjes dy't waarden tafoege oan blokken #85 (f21), #86(65e), #87(256)
03:59 - submit node #1 naam 888145 transaksjes út it swimbad en foarmje blok #88 (214), submit node #2 naam 750k transaksjes út it swimbad en foarmje blok #88 (50a), submit node #3 naam 670k transaksjes fan it swimbad en foarmen blok #88 (d3b)
04:44 - blok #88 (d3b) wurdt tekene en stjoerd nei oare knopen foar falidaasje
04:58 - blok #88 (214) wurdt tekene en stjoerd nei oare knopen foar falidaasje
05:11 - blok #88 (50a) wurdt tekene en stjoerd nei oare knopen foar falidaasje
05:11 - blok #85 (d3b) wurdt falidearre en stjoerd nei de rootketen
05:36 - blok #85 (214) wurdt falidearre en stjoerd nei de rootketen
05:43 - alle knooppunten krigen ynformaasje fan 'e rootketen dy't blokken #88 (d3b), #89 (214) binne tafoege en begjinne 670k, 750k transaksjes oan te passen
06:50 - fanwege in kommunikaasjefout, blok #85 (50a) waard net falidearre
06:55 - knooppunt #2 yntsjinje naam 888145 transaksjes út it swimbad en foarmje blok #90 (50a)
08:14 - blok #90 (50a) wurdt tekene en stjoerd nei oare knopen foar falidaasje
09:04 - blok #90 (50a) wurdt falidearre en stjoerd nei de rootketen
11:23 - alle knopen krigen ynformaasje fan de woartel keatling dat blok # 90 (50a) waard tafoege, en begjinne te passen 888145 transaksjes. Tagelyk hat tsjinner #3 al transaksjes tapast fan blokken #88 (d3b), #89(214)
12:11 - alle swimbaden binne leech
13:41 - alle knooppunten fan tsjinner #3 befetsje 3 miljoen transaksjes en tokens
14:35 - alle knooppunten fan tsjinner #1 befetsje 3 miljoen transaksjes en tokens
19:24 - alle knooppunten fan tsjinner #2 befetsje 3 miljoen transaksjes en tokens
Obstakels
Tidens de ûntwikkeling fan Plasma Cash tsjinkaam wy de folgjende problemen, dy't wy stadichoan oplosse en oplosse:
1. Konflikt yn 'e ynteraksje fan ferskate systeemfunksjes. Bygelyks, de funksje fan it tafoegjen fan transaksjes oan it swimbad blokkearre it wurk fan it yntsjinjen en validearjen fan blokken, en oarsom, wat late ta in drop yn snelheid.
2. It wie net fuortendaliks dúdlik hoe't jo in enoarm oantal transaksjes kinne ferstjoere, wylst de kosten foar gegevensferfier minimearje.
3. It wie net dúdlik hoe en wêr't gegevens opslein wurde moatte om hege resultaten te berikken.
4. It wie net dúdlik hoe't jo in netwurk tusken knooppunten organisearje, om't de grutte fan in blok mei 1 miljoen transaksjes sa'n 100 MB nimt.
5. Wurkje yn single-threaded modus brekt de ferbining tusken knopen as lange berekkeningen foarkomme (bygelyks in Merkle-beam bouwe en syn hash berekkenje).
Hoe binne wy mei dit alles omgean?
De earste ferzje fan 'e Plasma Cash-knooppunt wie in soarte fan kombinearjen dy't alles tagelyk koe dwaan: transaksjes akseptearje, blokken yntsjinje en falidearje, en in API leverje foar tagong ta gegevens. Sûnt NodeJS natuerlik single-threaded is, blokkearre de swiere Merkle-beam-berekkeningsfunksje de funksje tafoegje transaksje. Wy seagen twa opsjes foar it oplossen fan dit probleem:
1. Launch ferskate NodeJS-prosessen, wêrfan elk spesifike funksjes útfiert.
2. Brûk worker_threads en ferpleatse de útfiering fan in diel fan 'e koade yn threads.
As gefolch hawwe wy beide opsjes tagelyk brûkt: wy hawwe ien knooppunt logysk ferdield yn 3 dielen dy't apart kinne wurkje, mar tagelyk syngroan
1. Submission node, dy't akseptearret transaksjes yn it swimbad en makket blokken.
2. In falidearjende knooppunt dy't de jildigens fan knooppunten kontrolearret.
3. API-knooppunt - biedt in API foar tagong ta gegevens.
Yn dit gefal kinne jo ferbine mei elke knooppunt fia in unix-socket mei cli.
Wy ferpleatse swiere operaasjes, lykas it berekkenjen fan de Merklebeam, yn in aparte tried.
Sa hawwe wy berikt normale wurking fan alle Plasma Cash funksjes tagelyk en sûnder mislearrings.
Sadree't it systeem wie funksjoneel, wy begûn te testen de snelheid en, spitigernôch, ûntfong ûnfoldwaande resultaten: 5 transaksjes per sekonde en oant 000 transaksjes per blok. Ik moast útfine wat der ferkeard útfierd waard.
Om te begjinnen, begûnen wy it meganisme fan kommunikaasje te testen mei Plasma Cash om de peakkapasiteit fan it systeem út te finen. Wy skreaunen earder dat de Plasma Cash-knooppunt in unix-socket-ynterface leveret. Yn it earstoan wie it tekstbasearre. json-objekten waarden ferstjoerd mei `JSON.parse()` en `JSON.stringify()`.
```json
{
"action": "sendTransaction",
"payload":{
"prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
"prevBlock": 41,
"tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
"newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
"type": "pay",
"data": "",
"signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
}
}
```
Wy mjitten de oerdrachtsnelheid fan sokke objekten en fûnen ~ 130k per sekonde. Wy hawwe besocht de standertfunksjes te ferfangen foar it wurkjen mei json, mar de prestaasjes binne net ferbettere. De V8-motor moat goed optimalisearre wurde foar dizze operaasjes.
Wy wurken mei transaksjes, tokens en blokken troch klassen. By it meitsjen fan sokke klassen sakke de prestaasje mei 2 kear, wat oanjout dat OOP net geskikt is foar ús. Ik moast alles oerskriuwe nei in suver funksjonele oanpak.
Opname yn de databank
Yn earste ynstânsje waard Redis keazen foar gegevensopslach as ien fan 'e meast produktive oplossingen dy't oan ús easken foldocht: opslach fan kaaiwearden, wurkje mei hashtabellen, sets. Wy lansearre redis-benchmark en krigen ~ 80k operaasjes per sekonde yn 1 pipelining modus.
Foar hege prestaasjes hawwe wy Redis fyner ôfstimd:
- In unix socket ferbining is oprjochte.
- Wy hawwe it bewarjen fan de steat op skiif útskeakele (foar betrouberens kinne jo in replika ynstelle en opslaan op skiif yn in aparte Redis).
Yn Redis is in pool in hash-tabel, om't wy alle transaksjes yn ien query moatte kinne ophelje en transaksjes ien foar ien wiskje. Wy hawwe besocht in gewoane list te brûken, mar it is stadiger by it lossen fan 'e hiele list.
By it brûken fan standert NodeJS berikten de Redis-biblioteken in prestaasje fan 18k transaksjes per sekonde. De snelheid sakke 9 kear.
Sûnt de benchmark ús toande dat de mooglikheden dúdlik 5 kear grutter wiene, begonen wy te optimalisearjen. Wy feroare de bibleteek nei ioredis en krigen prestaasjes fan 25k per sekonde. Wy hawwe ien foar ien transaksjes tafoege mei it kommando 'hset'. Dat wy genereare in protte fragen yn Redis. It idee ûntstie om transaksjes yn batches te kombinearjen en se te stjoeren mei ien kommando `hmset`. It resultaat is 32k per sekonde.
Om ferskate redenen, dy't wy hjirûnder sille beskriuwe, wurkje wy mei gegevens mei `Buffer` en, sa docht bliken, as jo it konvertearje nei tekst (`buffer.toString('hex')`) foardat jo skriuwe, kinne jo ekstra krije optreden. Sa waard de snelheid ferhege nei 35k per sekonde. Op it stuit hawwe wy besletten om fierdere optimalisaasje op te hâlden.
Wy moasten oerstappe nei in binêr protokol omdat:
1. It systeem berekkent faak hashes, hantekeningen, ensfh., En dêrfoar hat it gegevens nedich yn 'e Buffer.
2. By ferstjoeren tusken tsjinsten weagje binêre gegevens minder as tekst. Bygelyks, by it ferstjoeren fan in blok mei 1 miljoen transaksjes, kinne de gegevens yn 'e tekst mear as 300 megabytes opnimme.
3. It konstant transformearjen fan gegevens beynfloedet prestaasjes.
Dêrom namen wy as basis ús eigen binêre protokol foar it opslaan en ferstjoeren fan gegevens, ûntwikkele op basis fan 'e prachtige 'binary-data' bibleteek.
As resultaat krigen wy de folgjende gegevensstruktueren:
-Transaksje
```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),
}
```
-Blok
```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,
}
```
Mei de gewoane kommando's `BD.encode(block, Protocol).slice();` en `BD.decode(buffer, Protocol)` konvertearje wy de gegevens yn `Buffer` foar opslaan yn Redis of trochstjoere nei in oare knooppunt en it opheljen fan de gegevens werom.
Wy hawwe ek 2 binêre protokollen foar it oerdragen fan gegevens tusken tsjinsten:
- Protokol foar ynteraksje mei Plasma Node fia unix socket
```json
{
type: BD.types.uint8,
messageId: BD.types.uint24le,
error: BD.types.uint8,
length: BD.types.uint24le,
payload: BD.types.buffer(({node}) => node.length)
}
```
wêr:
- `type` - de aksje dy't moat wurde útfierd, bygelyks, 1 - sendTransaction, 2 - getTransaction;
- `lading` - gegevens dy't moatte wurde trochjûn oan de passende funksje;
- `messageId` - berjocht id sadat it antwurd kin wurde identifisearre.
- Protokol foar ynteraksje tusken knopen
```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)
}
```
wêr:
- `koade` - berjochtkoade, bygelyks 6 - PREPARE_NEW_BLOCK, 7 - BLOCK_VALID, 8 - BLOCK_COMMIT;
- `versionProtocol` - protokolferzje, om't knooppunten mei ferskate ferzjes op it netwurk kinne wurde ferhege en se kinne oars wurkje;
- `seq` - berjochtidentifikaasje;
- `countChunk` и `chunkNumber` nedich foar it splitsen fan grutte berjochten;
- 'lengte' и `lading` lingte en de gegevens sels.
Om't wy de gegevens foarôf typten, is it definitive systeem folle flugger dan de `rlp`-bibleteek fan Ethereum. Spitigernôch hawwe wy it noch net kinnen wegerje, om't it needsaaklik is om it tûke kontrakt te finalisearjen, wat wy yn 'e takomst planne te dwaan.
As wy slagge om te berikken de snelheid 35 000 transaksjes per sekonde, wy moatte ek ferwurkje se yn 'e optimale tiid. Sûnt de ûngefear blok formaasje tiid nimt 30 sekonden, wy moatte opnimme yn it blok 1 000 000 transaksjes, dat betsjut ferstjoere mear 100 MB data.
Yn it earstoan brûkten wy de `ethereumjs-devp2p`-bibleteek om te kommunisearjen tusken knooppunten, mar it koe net safolle gegevens behannelje. As gefolch hawwe wy de `ws`-bibleteek brûkt en konfigureare it ferstjoeren fan binêre gegevens fia websocket. Fansels binne wy ek problemen tsjinkaam by it ferstjoeren fan grutte gegevenspakketten, mar wy hawwe se ferdield yn brokken en no binne dizze problemen fuort.
Ek foarmje in Merkle-beam en berekkenje de hash 1 000 000 transaksjes fereasket oer 10 sekonden fan trochgeande berekkening. Yn dizze tiid slagget de ferbining mei alle knopen te brekken. It waard besletten om dizze berekkening te ferpleatsen nei in aparte tried.
Konklúzjes:
Yn feite binne ús befiningen net nij, mar om ien of oare reden ferjitte in protte saakkundigen har by it ûntwikkeljen.
- It brûken fan funksjonele programmearring ynstee fan objektrjochte programmearring ferbettert de produktiviteit.
- De monolith is slimmer dan in tsjinst-arsjitektuer foar in produktyf NodeJS-systeem.
- It brûken fan 'worker_threads' foar swiere berekkening ferbettert de responsiviteit fan it systeem, benammen by it omgean mei i/o-operaasjes.
- unix-socket is stabiler en rapper dan http-oanfragen.
- As jo grutte gegevens fluch oer it netwurk moatte oerdrage, is it better om websockets te brûken en binêre gegevens te ferstjoeren, ferdield yn brokken, dy't kinne wurde trochstjoerd as se net komme, en dan kombineare yn ien berjocht.
Wy noegje jo út om te besykjen GitHub projekt:
It artikel waard mei-skreaun troch Alexander Nashivan, senior developer .
Boarne: www.habr.com