Blockchain teknologia berritzailea da, gizakiaren bizitzako arlo asko hobetuko dituela agintzen duena. Benetako prozesuak eta produktuak espazio digitalera transferitzen ditu, finantza-transakzioen abiadura eta fidagarritasuna bermatzen ditu, haien kostua murrizten du eta DAPP aplikazio modernoak sortzeko aukera ematen du sare deszentralizatuetan kontratu adimentsuak erabiliz.
Blockchain-en abantaila ugari eta aplikazio askotarikoak ikusita, harrigarria badirudi etorkizun handiko teknologia honek oraindik industria guztietan sartu ez izana. Arazoa da bloke deszentralizatu modernoek eskalagarritasunik ez dutela. Ethereum-ek segundoko 20 transakzio inguru prozesatzen ditu, eta hori ez da nahikoa egungo negozio dinamikoen beharrak asetzeko. Aldi berean, blockchain teknologia erabiltzen duten enpresek zalantzan jartzen dute Ethereum alde batera uzteko hacking-aren eta sarearen akatsen aurkako babes-maila handia dela eta.
Blockchain-en deszentralizazioa, segurtasuna eta eskalagarritasuna bermatzeko, horrela Eskalagarritasun Trilema konponduz, garapen taldea sortu zuen Plasma Cash, kontratu adimendun batek eta Node.js-en oinarritutako sare pribatu batek osatutako kate subsidiarioa, aldian-aldian bere egoera erro katera (Ethereum) transferitzen duena.
Funtsezko prozesuak Plasma Cash-en
1. Erabiltzaileak "gordailua" deitzen dio kontratu adimendunaren funtzioari, Plasma Cash tokenean sartu nahi duen ETH kopurua helaraziz. Kontratu adimendunaren funtzioak token bat sortzen du eta horri buruzko gertaera bat sortzen du.
2. Kontratu adimendunen ekitaldietara harpidetutako Plasma Cash nodoek gordailua sortzeari buruzko gertaera bat jasotzen dute eta token bat sortzeari buruzko transakzio bat gehitzen dute igerilekuan.
3. Aldian-aldian, Plasma Cash nodo bereziek igerilekuko transakzio guztiak hartzen dituzte (milioi 1 arte) eta haietatik bloke bat osatzen dute, Merkle zuhaitza kalkulatzen dute eta, horren arabera, hash-a. Bloke hau beste nodo batzuetara bidaltzen da egiaztatzeko. Nodoek Merkle hash-a baliozkoa den eta transakzioak baliozkoak diren egiaztatzen dute (adibidez, tokenaren igorlea bere jabea den). Blokea egiaztatu ondoren, nodoak kontratu adimendunaren `submitBlock` funtzioa deitzen du, bloke-zenbakia eta Merkle hash-a ertz-katean gordetzen dituena. Kontratu adimendunak gertaera bat sortzen du bloke bat arrakastaz gehitu dela adierazten duena. Transakzioak igerilekutik kentzen dira.
4. Blokea bidaltzeko gertaera jasotzen duten nodoak blokeari gehitutako transakzioak aplikatzen hasten dira.
5. Noizbait, tokenaren jabeak (edo ez-jabeak) Plasma Cash-etik kendu nahi du. Horretarako, `startExit` funtzioari deitzen dio, tokenaren azken 2 transakzioei buruzko informazioa helaraziz, tokenaren jabea dela baieztatzen dutenak. Kontratu adimendunak, Merkle hash-a erabiliz, blokeetan transakzioen presentzia egiaztatzen du eta bi aste barru gertatuko den erretiratzeko tokena bidaltzen du.
6. Token-a kentzeko eragiketa urraketarekin gertatu bada (tokena erretiratzeko prozedura hasi ondoren gastatu zen edo tokena jada beste norbaitena zen erretiratzea baino lehen), tokenaren jabeak erretiratzea ezeztatu dezake bi aste barru.
Pribatutasuna bi modutan lortzen da
1. Erro-kateak ez daki ezer kate umearen barruan sortzen eta bidaltzen diren transakzioei buruz. Plasma Cash-etik ETH gordailatu eta atera duenari buruzko informazioa publikoa izaten jarraitzen du.
2. Haur-kateak transakzio anonimoak ahalbidetzen ditu zk-SNARK-ak erabiliz.
Teknologia pila
- NodeJS
- Birbanaketa
- eterioa
- Sild
Testing
Plasma Cash garatzen ari ginen bitartean, sistemaren abiadura probatu genuen eta emaitza hauek lortu genituen:
- segundoko gehienez 35 transakzio gehitzen zaizkio multzoari;
- Bloke batean gehienez 1 transakzio gorde daitezke.
Probak honako 3 zerbitzarietan egin dira:
1. Intel Core i7-6700 Quad-Core Skylake barne. NVMe SSD - 512 GB, 64 GB DDR4 RAM
Plasma Cash baliozkotzeko 3 nodo planteatu ziren.
2. AMD Ryzen 7 1700X Octa-Core "Summit Ridge" (Zen), SATA SSD - 500 GB, 64 GB DDR4 RAM
Ropsten testnet ETH nodoa planteatu zen.
Plasma Cash baliozkotzeko 3 nodo planteatu ziren.
3. Intel Core i9-9900K Octa-Core barne. NVMe SSD - 1 TB, 64 GB DDR4 RAM
1 Plasma Cash bidaltzeko nodoa sortu da.
Plasma Cash baliozkotzeko 3 nodo planteatu ziren.
Proba bat jarri zen martxan Plasma Cash sarera transakzioak gehitzeko.
Guztira: 10 Plasma Cash nodo sare pribatu batean.
1. proba
Bloke bakoitzeko milioi bat transakzio muga dago. Hori dela eta, milioi bat transakzio 1 bloketan sartzen dira (sistemak transakzioen zati bat hartu eta bidaltzen diren bitartean bidaltzea lortzen baitu).
Hasierako egoera: azken blokea #7; 1 milioi transakzio eta token gordetzen dira datu-basean.
00:00 — transakzio sortzeko gidoiaren hasiera
01:37 - 1 milioi transakzio sortu ziren eta nodora bidaltzen hasi zen
01:46 - Bidali-nodoak 240 transakzio hartu zituen igerilekutik eta inprimakien blokeko #8. Gainera, ikusten dugu 320k transakzio igerilekuan gehitzen direla 10 segundotan
01:58 — # 8 blokea sinatu eta baliozkotzeko bidaltzen da
02:03 — # 8 blokea balioztatu da eta kontratu adimendunaren `submitBlock` funtzioa Merkle hash eta bloke-zenbakiarekin deitzen da
02:10 — Demo script-a funtzionatzen amaitu zuen, milioi bat transakzio bidali zituen 1 segundotan
02:33 - nodoak 8. blokea erro-katean gehitutako informazioa jasotzen hasi ziren eta 240k transakzio egiten hasi ziren.
02:40 - 240 transakzio igerilekutik kendu dira, dagoeneko #8 blokean daudenak
02:56 - Bidali-nodoak igerilekuko gainerako 760 transakzioak hartu zituen eta Merkle hash-a kalkulatzen hasi zen eta #9 sinatzeko blokea
03:20 - nodo guztiek 1 milioi 240k transakzio eta token dituzte
03:35 — #9 blokea sinatu eta beste nodo batzuetara baliozkotzeko bidaltzen da
03:41 - sareko errorea gertatu da
04:40 — 9. blokearen baliozkotzearen zain denbora-muga gainditu da
04:54 - Bidali-nodoak igerilekuko gainerako 760 transakzioak hartu zituen eta Merkle hash-a kalkulatzen hasi zen eta #9 sinatzeko blokea
05:32 — #9 blokea sinatu eta beste nodo batzuetara baliozkotzeko bidaltzen da
05:53 — #9 blokea balioztatu eta erro-katera bidaltzen da
06:17 - nodoak 9. blokea erro-katean gehitu zelako informazioa jasotzen hasi ziren eta 760k transakzio egiten hasi ziren
06:47 - igerilekuak #9 blokean dauden transakzioetatik garbitu ditu
09:06 - nodo guztiek 2 milioi transakzio eta token dituzte
2. proba
Bloke bakoitzeko 350k-ko muga dago. Ondorioz, 3 bloke ditugu.
Hasierako egoera: azken blokea #9; Datu-basean 2 milioi transakzio eta token gordetzen dira
00:00 — Transakzio sortzeko gidoia dagoeneko abiarazi da
00:44 - 1 milioi transakzio sortu ziren eta nodora bidaltzen hasi zen
00:56 - Bidali-nodoak 320 transakzio hartu zituen igerilekutik eta inprimakien blokeko #10. Gainera, ikusten dugu 320k transakzio igerilekuan gehitzen direla 10 segundotan
01:12 — # 10 blokea sinatzen da eta beste nodo batzuetara bidaltzen da baliozkotzeko
01:18 — Demo script-a funtzionatzen amaitu zuen, milioi bat transakzio bidali zituen 1 segundotan
01:20 — # 10 blokea balioztatu eta erro-katera bidaltzen da
01:51 - Nodo guztiek 10. blokea gehitu zen erro-katearen informazioa jaso zuten eta 320k transakzio aplikatzen hasi ziren
02:01 - igerilekuak 320. blokean gehitu diren 10 transakzioetarako garbitu du
02:15 — Bidali-nodoak 350 transakzio hartu zituen igerilekutik eta inprimakien bloke #11
02:34 — # 11 blokea sinatzen da eta beste nodo batzuetara bidaltzen da baliozkotzeko
02:51 — #11 blokea balioztatu eta erro-katera bidaltzen da
02:55 - azken nodoak #10 blokeko transakzioak burutu ditu
10:59 - # 9 blokea bidaltzeko transakzioak oso denbora luzea izan zuen erro-katean, baina amaitu zen eta nodo guztiek horri buruzko informazioa jaso zuten eta 350k transakzio egiten hasi ziren.
11:05 - igerilekuak 320. blokean gehitu diren 11 transakzioetarako garbitu du
12:10 - nodo guztiek 1 milioi 670k transakzio eta token dituzte
12:17 — bidaltzeko nodoak 330 transakzio hartu zituen igerilekutik eta inprimakien bloke #12
12:32 — # 12 blokea sinatzen da eta beste nodo batzuetara bidaltzen da baliozkotzeko
12:39 — # 12 blokea balioztatu eta erro-katera bidaltzen da
13:44 - Nodo guztiek 12. blokea gehitu zen erro-katearen informazioa jaso zuten eta 330k transakzio aplikatzen hasi ziren
14:50 - nodo guztiek 2 milioi transakzio eta token dituzte
3. proba
Lehenengo eta bigarren zerbitzarietan, baliozkotze-nodo bat bidalketa-nodo batek ordezkatu zuen.
Hasierako egoera: azken blokea #84; 0 transakzio eta token gordeta datu-basean
00:00 — Bakoitzak milioi bat transakzio sortzen eta bidaltzen dituzten 3 script abiarazi dira
01:38 - 1 milioi transakzio sortu ziren eta #3 nodoa bidaltzeko bidalketa hasi zen
01:50 — Bidali # 3 nodoak 330 transakzio hartu zituen igerilekutik eta inprimakien bloke # 85 (f21). Gainera, ikusten dugu 350k transakzio igerilekuan gehitzen direla 10 segundotan
01:53 - 1 milioi transakzio sortu ziren eta #1 nodoa bidaltzeko bidalketa hasi zen
01:50 — Bidali # 3 nodoak 330 transakzio hartu zituen igerilekutik eta inprimakien bloke # 85 (f21). Gainera, ikusten dugu 350k transakzio igerilekuan gehitzen direla 10 segundotan
02:01 — bidali # 1 nodoak 250 transakzio hartu zituen igerilekutik eta inprimakien bloke # 85 (65e)
02:06 — # 85 blokea (f21) sinatzen da eta beste nodo batzuetara bidaltzen da baliozkotzeko
02:08 — 3. zerbitzariaren demo scripta, 1 segundotan milioi bat transakzio bidali zituena, lanean amaitu zen
02:14 — # 85 blokea (f21) balioztatu eta erro-katera bidaltzen da
02:19 — # 85 blokea (65e) sinatzen da eta beste nodo batzuetara bidaltzen da baliozkotzeko
02:22 - 1 milioi transakzio sortu ziren eta #2 nodoa bidaltzeko bidalketa hasi zen
02:27 — # 85 blokea (65e) balioztatu eta erro-katera bidali
02:29 — Bidali #2 nodoak 111855 transakzio hartu zituen igerilekutik eta inprimakien bloke #85 (256).
02:36 — # 85 blokea (256) sinatzen da eta beste nodo batzuetara bidaltzen da baliozkotzeko
02:36 — 1. zerbitzariaren demo scripta, 1 segundotan milioi bat transakzio bidali zituena, lanean amaitu zen
02:38 — # 85 blokea (256) balioztatu eta erro-katera bidaltzen da
03:08 — 2. zerbitzariaren gidoia funtzionatzen amaitu zuen, milioi bat transakzio bidali zituen 1 segundotan
03:38 - nodo guztiek # 85 (f21), # 86 (65e), # 87 (256) blokeak gehitu ziren eta 330k, 250k, 111855 transakzioak aplikatzen hasi ziren erro-katearen informazioa jaso zuten.
03:49 - igerilekua 330k, 250k, 111855 transakziotan garbitu zen # 85 (f21), # 86 (65e), # 87 (256) blokeetan gehitu ziren.
03:59 — Bidali #1 nodoak 888145 transakzio hartu zituen multzotik eta inprimaki-blokeak #88 (214), bidali #2 nodoak 750 transakzio hartu zituen multzotik eta inprimaki-blokeak #88 (50a), bidali #3.k 670k transakzio hartu zituen. igerilekua eta 88 blokea osatzen dute (d3b)
04:44 — # 88 blokea (d3b) sinatzen da eta beste nodo batzuetara bidaltzen da baliozkotzeko
04:58 — # 88 blokea (214) sinatzen da eta beste nodo batzuetara bidaltzen da baliozkotzeko
05:11 — # 88 (50a) blokea sinatzen da eta beste nodo batzuetara bidaltzen da baliozkotzeko
05:11 — # 85 blokea (d3b) balioztatu eta erro-katera bidaltzen da
05:36 — # 85 blokea (214) balioztatu eta erro-katera bidaltzen da
05:43 - nodo guztiek # 88 (d3b), # 89 (214) blokeak dituen erro-katearen informazioa jaso dute eta 670k, 750k transakzioak aplikatzen hasi dira.
06:50 — Komunikazioaren hutsegite bat dela eta, 85. blokea (50a) ez da balioztatu
06:55 — Bidali #2 nodoak 888145 transakzio hartu ditu multzotik eta inprimakien bloke #90 (50a)
08:14 — # 90 (50a) blokea sinatzen da eta beste nodo batzuetara bidaltzen da baliozkotzeko
09:04 — #90 blokea (50a) balioztatu eta erro-katera bidaltzen da
11:23 - nodo guztiek #90 (50a) bloke hori gehitu zen erro katearen informazioa jaso zuten eta 888145 transakzio aplikatzen hasi ziren. Aldi berean, # 3 zerbitzariak # 88 (d3b), # 89 (214) blokeetako transakzioak aplikatu ditu dagoeneko
12:11 - igerileku guztiak hutsik daude
13:41 - 3. zerbitzariaren nodo guztiek 3 milioi transakzio eta token dituzte
14:35 - 1. zerbitzariaren nodo guztiek 3 milioi transakzio eta token dituzte
19:24 - 2. zerbitzariaren nodo guztiek 3 milioi transakzio eta token dituzte
Oztopoak
Plasma Cash-en garapenean, honako arazo hauek topatu genituen, pixkanaka konpondu eta konpontzen ari garen:
1. Gatazka sistemaren hainbat funtzioren elkarrekintzan. Esaterako, transakzioak biltegian gehitzeko funtzioak blokeak bidaltzeko eta baliozkotzeko lana blokeatu zuen, eta alderantziz, eta horrek abiaduraren jaitsiera ekarri zuen.
2. Ez zegoen berehala transakzio kopuru handi bat nola bidali datuen transferentzia kostuak gutxituz.
3. Ez zegoen argi nola eta non gorde datuak emaitza handiak lortzeko.
4. Ez zegoen argi nodoen arteko sarea nola antolatu, milioi bat transakzio dituen bloke baten tamainak 1 MB inguru hartzen baititu.
5. Hari bakarreko moduan lan egiteak nodoen arteko konexioa hausten du kalkulu luzeak gertatzen direnean (adibidez, Merkle zuhaitz bat eraikitzea eta hash kalkulatzea).
Nola egin diogu aurre honi guztiari?
Plasma Cash nodoaren lehen bertsioa dena aldi berean egin zezakeen konbinazio moduko bat zen: transakzioak onartu, blokeak bidali eta balioztatu eta datuak atzitzeko API bat eskaintzea. NodeJS berez hari bakarrekoa denez, Merkle zuhaitzaren kalkulu funtzio astunak gehitzeko transakzio funtzioa blokeatu zuen. Arazo hau konpontzeko bi aukera ikusi ditugu:
1. Abiarazi hainbat NodeJS prozesu, eta horietako bakoitzak funtzio zehatzak betetzen ditu.
2. Erabili worker_threads eta mugitu kodearen zati baten exekuzioa harietara.
Ondorioz, bi aukerak aldi berean erabili ditugu: logikoki nodo bat bereizita lan egin dezaketen 3 zatitan banatu dugu, baina aldi berean sinkronoki.
1. Bidalketa nodoa, transakzioak igerilekuan onartzen dituena eta blokeak sortzen dituena.
2. Nodoen baliozkotasuna egiaztatzen duen baliozko nodo bat.
3. API nodoa - datuak atzitzeko API bat eskaintzen du.
Kasu honetan, nodo bakoitza unix socket baten bidez konekta zaitezke cli erabiliz.
Eragiketa astunak, hala nola, Merkle zuhaitza kalkulatzea, beste hari batera eraman genituen.
Horrela, Plasma Cash funtzio guztien funtzionamendu normala aldi berean eta hutsegiterik gabe lortu dugu.
Behin sistema funtzionatzen zuenean, abiadura probatzen hasi ginen eta, tamalez, emaitza desegokiak jaso genituen: 5 transakzio segundoko eta gehienez 000 transakzio bloke bakoitzeko. Oker inplementatu zena asmatu behar izan nuen.
Hasteko, Plasma Cash-ekin komunikazio-mekanismoa probatzen hasi ginen, sistemaren gaitasun gorena ezagutzeko. Lehenago idatzi genuen Plasma Cash nodoak unix socket interfazea eskaintzen duela. Hasieran testuetan oinarrituta zegoen. json objektuak `JSON.parse()` eta `JSON.stringify()` erabiliz bidali ziren.
```json
{
"action": "sendTransaction",
"payload":{
"prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
"prevBlock": 41,
"tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
"newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
"type": "pay",
"data": "",
"signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
}
}
```
Horrelako objektuen transferentzia-abiadura neurtu genuen eta ~ 130k segundoko aurkitu genuen. Json-ekin lan egiteko funtzio estandarrak ordezkatzen saiatu gara, baina errendimendua ez da hobetu. V8 motorra ondo optimizatu behar da eragiketa horietarako.
Transakzioekin, tokenekin eta blokeekin lan egin genuen klaseen bidez. Horrelako klaseak sortzean, errendimendua 2 aldiz jaitsi zen, eta horrek adierazten du OOP ez dela egokia guretzat. Dena berridatzi behar izan nuen ikuspegi funtzional huts batera.
Datu-basean grabatzea
Hasieran, Redis datuak biltegiratzeko aukeratu zen gure eskakizunak betetzen dituen irtenbide produktiboenetako bat bezala: gako-balioen biltegiratzea, hash-taulekin lan egitea, multzoak. Redis-benchmark abiarazi genuen eta ~ 80k eragiketa lortu genituen segundoko 1 kanalizazio moduan.
Errendimendu handia lortzeko, Redis finago sintonizatu dugu:
- Unix socket konexioa ezarri da.
- Egoera diskoan gordetzea desgaitu dugu (fidagarritasuna lortzeko, erreplika bat konfigura dezakezu eta diskoan gorde Redis bereizi batean).
Redis-en, pool bat hash taula bat da, transakzio guztiak kontsulta batean berreskuratu eta transakzioak banan-banan ezabatu ahal izan behar ditugulako. Zerrenda arrunt bat erabiltzen saiatu gara, baina motelagoa da zerrenda osoa deskargatzean.
NodeJS estandarra erabiltzean, Redis liburutegiek segundoko 18k transakzioko errendimendua lortu zuten. Abiadura 9 aldiz jaitsi zen.
Erreferentziak aukerak argi eta garbi 5 aldiz handiagoak zirela erakutsi zigunez, optimizatzen hasi ginen. Liburutegia ioredis-era aldatu genuen eta segundoko 25k-ko errendimendua lortu genuen. Transakzioak banan-banan gehitu ditugu `hset` komandoa erabiliz. Beraz, Redis-en kontsulta asko sortzen ari ginen. Transakzioak loteetan konbinatzeko eta `hmset` komando batekin bidaltzeko ideia sortu zen. Emaitza 32k segundoko da.
Jarraian deskribatuko ditugun hainbat arrazoirengatik, `Buffer` erabiliz lan egiten dugu datuekin eta, antza denez, testura (`buffer.toString('hex')`) idazten baduzu, idatzi aurretik, gehigarriak lor ditzakezu. errendimendua. Horrela, abiadura 35k segundoko igo zen. Momentuz, optimizazio gehiago etetea erabaki dugu.
Protokolo bitar batera aldatu behar izan dugu zeren eta:
1. Sistemak sarritan hashak, sinadurak, etab. kalkulatzen ditu, eta horretarako `Buffer-eko datuak behar ditu.
2. Zerbitzuen artean bidaltzen direnean, datu bitarrak testuak baino pisu txikiagoa dute. Adibidez, milioi bat transakzio dituen bloke bat bidaltzean, testuko datuek 1 megabyte baino gehiago har ditzakete.
3. Datuak etengabe eraldatzea errendimenduari eragiten dio.
Hori dela eta, datuak gordetzeko eta transmititzeko gure protokolo bitar propioa hartu genuen oinarri, `data-datuen` liburutegi zoragarrian garatua.
Ondorioz, datu-egitura hauek lortu ditugu:
—Transakzioa
```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),
}
```
—Blokea
```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,
}
```
`BD.encode(block, Protocol).slice();` eta `BD.decode(buffer, Protocol)` ohiko komandoekin datuak `Buffer' bihurtzen ditugu Redis-en gordetzeko edo beste nodo batera birbidaltzeko eta berreskuratzeko. datuak atzera.
Zerbitzuen artean datuak transferitzeko 2 protokolo bitar ere baditugu:
— Unix socket bidez Plasma Node-rekin elkarreragiteko protokoloa
```json
{
type: BD.types.uint8,
messageId: BD.types.uint24le,
error: BD.types.uint8,
length: BD.types.uint24le,
payload: BD.types.buffer(({node}) => node.length)
}
```
non:
- `mota` — egin beharreko ekintza, adibidez, 1 — sendTransaction, 2 — getTransaction;
- `karga erabilgarria` — dagokien funtziora pasatu behar diren datuak;
- `messageId` — mezuaren IDa, erantzuna identifikatu ahal izateko.
— Nodoen arteko elkarrekintzarako protokoloa
```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)
}
```
non:
- `kodea` — mezuaren kodea, adibidez 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
- `versionProtocol` — protokoloaren bertsioa, sarean bertsio desberdinak dituzten nodoak sor daitezkeelako eta modu ezberdinean lan egin dezaketelako;
- `sekuentzia` — mezuaren identifikatzailea;
- `countChunk` и `chunkNumber` mezu handiak banatzeko beharrezkoak;
- `luzera` и `karga erabilgarria` luzera eta datuak berak.
Datuak aurrez idatzi ditugunez, azken sistema Ethereum-en `rlp` liburutegia baino askoz azkarragoa da. Zoritxarrez, oraindik ezin izan diogu uko egin, etorkizunean egiteko asmoa dugun kontratu adimenduna bukatzea beharrezkoa baita.
Abiadura iristea lortuko bagenu 35 000 segundoko transakzioak, denbora optimoan prozesatu behar ditugu ere. Blokeak eratzeko gutxi gorabeherako denborak 30 segundo behar dituenez, blokean sartu behar dugu 1 000 000 transakzioak, hau da, gehiago bidaltzea 100 MB datu.
Hasieran, `ethereumjs-devp2p` liburutegia erabili genuen nodoen artean komunikatzeko, baina ezin izan zuen hainbeste datu kudeatu. Ondorioz, `ws` liburutegia erabili dugu eta websocket bidez datu bitarrak bidaltzea konfiguratu dugu. Noski, datu-pakete handiak bidaltzerakoan ere arazoak izan ditugu, baina zatitan banatu ditugu eta orain arazo hauek desagertu egin dira.
Merkle zuhaitz bat osatuz eta hash kalkulatzea ere 1 000 000 transakzioak buruz eskatzen du 10 kalkulu jarraituaren segundoak. Denbora horretan, nodo guztiekiko konexioa haustea lortzen da. Kalkulu hau beste hari batera eramatea erabaki zen.
Ondorioak:
Izan ere, gure aurkikuntzak ez dira berriak, baina arrazoiren batengatik aditu askok ahazten dituzte garatzerakoan.
- Objektuetara zuzendutako programazioaren ordez Programazio Funtzionala erabiltzeak produktibitatea hobetzen du.
- Monolitoa NodeJS sistema produktibo baterako zerbitzu-arkitektura bat baino okerragoa da.
- Konputazio astunetarako `worker_threads` erabiltzeak sistemaren erantzuna hobetzen du, batez ere i/o eragiketekin aurre egiten denean.
- unix socket egonkorragoa eta azkarragoa da http eskaerak baino.
- Datu handiak azkar transferitu behar badituzu sarean, hobe da websocketak erabiltzea eta datu bitarrak bidaltzea, zatitan banatuta, iristen ez badira birbidali daitezkeenak, eta gero mezu batean konbinatu.
Bisitatzera gonbidatzen zaitugu GitHub proiektua:
Artikulua elkarrekin idatzi du Alexander Nashivan, garatzaile seniorra .
Iturria: www.habr.com