Blockchain teknolojiyek nûjen e ku soz dide ku gelek warên jiyana mirovan baştir bike. Ew pêvajo û hilberên rastîn di cîhê dîjîtal de vediguhezîne, lez û pêbaweriya danûstendinên darayî piştrast dike, lêçûna wan kêm dike, û di heman demê de dihêle hûn bi karanîna peymanên hişmend di torên nenavendî de serîlêdanên DAPP-a nûjen biafirînin.
Ji ber gelek feyde û serîlêdanên cihêreng ên blokê, dibe ku ecêb xuya bike ku vê teknolojiya soz hîna rê li her pîşesaziyê nekiriye. Pirsgirêk ev e ku zincîreyên nemerkezî yên nûjen kêmasiya mezinbûnê tune. Ethereum di saniyeyê de nêzî 20 danûstendinan dike, ku ji bo peydakirina hewcedariyên karsaziyên dînamîkî yên îro ne bes e. Di heman demê de, pargîdaniyên ku teknolojiya zincîra blokê bikar tînin dudil in ku dev ji Ethereum berdin ji ber parastina wê ya bilind a ji hakkirin û têkçûna torê.
Ji bo ku di zincîra blokê de desentralîzasyon, ewlehî û pîvandinê misoger bikin, bi vî rengî Trilemma Scalability, tîmê pêşkeftinê çareser bikin Plasma Cash afirand, zincîreyek pêvek ku ji peymanek jîr û torgilokek taybet a li ser bingeha Node.js pêk tê, ku bi awayekî periyodîk rewşa xwe vediguhezîne zincîra root (Ethereum).
Pêvajoyên sereke di Cash Plasma de
1. Bikarhêner ji fonksiyona peymana biaqil re dibêje `depozit`, mîqdara ETH ya ku ew dixwaze razanê bike tokena Cash Plasmayê, derbas dike. Fonksiyona peymana aqilmend nîşanek diafirîne û li ser wê bûyerek çêdike.
2. Girêkên diravê Plasmayê yên ku bûne aboneyên bûyerên peymana biaqil bûyerek di derbarê afirandina depoyek de digirin û danûstendinek li ser çêkirina tokenek li hewzê zêde dikin.
3. Dem bi dem, girêkên taybetî yên Plasma Cash hemî danûstendinan ji hewzê digirin (heta 1 mîlyon) û ji wan blokê çêdikin, dara Merkle û, li gorî vê yekê, heşê hesab dikin. Ev blok ji bo verastkirinê ji girêkên din re tê şandin. Girêk kontrol dikin ka Merkle hash derbasdar e û gelo danûstendin derbasdar in (mînak, ka şanderê token xwediyê wê ye). Piştî verastkirina blokê, nod fonksiyona `submitBlock` ya peymana jîr bang dike, ku jimara blokê û Merkle hash li zincîra keviya hildide. Peymana zîrek bûyerek çêdike ku lêzêdekirina serketî ya blokek destnîşan dike. Danûstandin ji hewzê têne rakirin.
4. Nodên ku bûyera radestkirina blokê distînin dest bi sepandina danûstendinên ku li blokê hatine zêde kirin dikin.
5. Di hin xalan de, xwedan (an nexwediyê) tokenê dixwaze wê ji Cash Plasma vekişîne. Ji bo vê yekê, ew bangî fonksiyona `startExit` dike, di derheqê 2 danûstendinên paşîn ên li ser tokenê de, ku piştrast dikin ku ew xwediyê tokenê ye, agahdarî digihîne wê. Peymana zîrek, bi karanîna hash Merkle, hebûna danûstendinan di blokan de kontrol dike û tokenê ji bo vekişînê dişîne, ku dê di du hefteyan de pêk were.
6. Ger operasyona vekişîna tokenê bi binpêkirinan pêk hat (token piştî destpêkirina prosedûra vekişînê hate xerc kirin an jî berî vekişînê nîşanek ji berê ve ya kesek din bû), xwediyê token dikare di nav du hefteyan de vekişînê red bike.
Nepenî bi du awayan tê bidestxistin
1. Zincîra root di derheqê danûstendinên ku di hundurê zincîra zarokan de têne çêkirin û şandin tiştek nizane. Agahdariya li ser kê ETH ji Cash Plasma razand û vekişand gelemperî dimîne.
2. Zincîra zarok destûrê dide danûstendinên nenas bi karanîna zk-SNARKs.
Stack Technology
- NodeJS
- Redis
- etherium
- Sild
Îmtîhanê
Dema ku pêşkeftina Plasma Cash, me leza pergalê ceriband û encamên jêrîn wergirtin:
- heya 35 danûstendinan di çirkeyê de li hewzê têne zêdekirin;
- heta 1 danûstandin dikarin di blokê de werin hilanîn.
Test li ser 3 serverên jêrîn hatin kirin:
1. Intel Core i7-6700 Quad-Core Skylake incl. NVMe SSD - 512 GB, 64 GB DDR4 RAM
3 girêkên Plasma Cash-ê yên pejirandî hatin rakirin.
2. AMD Ryzen 7 1700X Octa-Core "Summit Ridge" (Zen), SATA SSD - 500 GB, 64 GB DDR4 RAM
Nodeya ETH ya Ropsten testnet hate bilind kirin.
3 girêkên Plasma Cash-ê yên pejirandî hatin rakirin.
3. Intel Core i9-9900K Octa-Core incl. NVMe SSD - 1 TB, 64 GB DDR4 RAM
1 girêka radestkirina Cash Plasmayê hate bilind kirin.
3 girêkên Plasma Cash-ê yên pejirandî hatin rakirin.
Testek hate destpêkirin ku danûstendinan li tora Plasma Cash zêde bike.
Total: 10 girêkên Cash Plasma di torgilokek taybet de.
Test 1
Ji bo her blokek 1 mîlyon danûstendinan sînorek heye. Ji ber vê yekê, 1 mîlyon danûstendin dikevin 2 blokan (ji ber ku pergal di dema şandina wan de beşek ji danûstendinan digire û radest dike).
Rewşa destpêkê: bloka dawî #7; 1 mîlyon danûstendin û nîşanek di databasê de têne hilanîn.
00:00 - destpêka skrîpta hilberîna danûstendinê
01:37 - 1 mîlyon danûstendin hatin çêkirin û şandina bo nodê dest pê kir
01:46 - girêka bişînin 240 hezar danûstendin ji hewzê girt û bloka #8 pêk tîne. Di heman demê de em dibînin ku 320k danûstendin di 10 çirkeyan de li hewzê têne zêdekirin
01:58 - bloka #8 tê îmzekirin û ji bo pejirandinê tê şandin
02:03 - bloka #8 tê pejirandin û fonksiyona `submitBlock` ya peymana biaqil bi Merkle hash û hejmara blokê tê gazî kirin.
02:10 - skrîpta demo kar qedand, ku di 1 çirkeyan de 32 mîlyon danûstendin şandin
02:33 - girêkan dest bi wergirtina agahiyê kirin ku bloka #8 li zincîra root hate zêdekirin, û dest bi pêkanîna 240k danûstendinan kirin
02:40 - 240 hezar danûstendinên ku jixwe di bloka #8 de ne ji hewzê hatin rakirin.
02:56 - girêka radestkirinê 760 hezar danûstendinên mayî ji hewzê girt û dest bi hesabê Merkle hash û bloka #9 îmze kir.
03:20 - Hemî nod 1 mîlyon 240k danûstendin û nîşanan dihewîne
03:35 - bloka #9 tê îmzekirin û ji bo erêkirinê ji girêkên din re tê şandin
03:41 - Çewtiya torê derket
04:40 - li benda pejirandina bloka #9 dema xwe qediya
04:54 - girêka radestkirinê 760 hezar danûstendinên mayî ji hewzê girt û dest bi hesabê Merkle hash û bloka #9 îmze kir.
05:32 - bloka #9 tê îmzekirin û ji bo erêkirinê ji girêkên din re tê şandin
05:53 - bloka #9 tê pejirandin û ji zincîra root re tê şandin
06:17 - girêkan dest bi wergirtina agahiyê kirin ku bloka #9 li zincîra root hate zêdekirin û dest bi pêkanîna 760k danûstendinan kir
06:47 - hewz ji danûstendinên ku di bloka #9 de ne paqij bûye
09:06 - Hemî nod 2 mîlyon danûstendin û nîşanan dihewîne
Test 2
Ji bo her blokek 350k sînorek heye. Di encamê de 3 blokên me hene.
Rewşa destpêkê: bloka dawî #9; 2 mîlyon danûstendin û nîşanek di databasê de têne hilanîn
00:00 — skrîpta hilberîna danûstendinê jixwe dest pê kiriye
00:44 - 1 mîlyon danûstendin hatin çêkirin û şandina bo nodê dest pê kir
00:56 - girêka bişînin 320 hezar danûstendin ji hewzê girt û bloka #10 pêk tîne. Di heman demê de em dibînin ku 320k danûstendin di 10 çirkeyan de li hewzê têne zêdekirin
01:12 - bloka #10 tê îmzekirin û ji bo erêkirinê ji girêkên din re tê şandin
01:18 - skrîpta demo kar qedand, ku di 1 çirkeyan de 34 mîlyon danûstendin şandin
01:20 - bloka #10 tê pejirandin û ji zincîra root re tê şandin
01:51 - hemî girêk ji zincîra root agahiyê wergirtin ku bloka #10 hate zêdekirin û dest bi sepandina 320k danûstendinan dikin
02:01 - hewz ji bo 320k danûstendinên ku li bloka #10 hatine zêdekirin paqij bûye
02:15 - girêk bişînin 350 hezar danûstendin ji hewzê girtin û bloka #11 ava dike
02:34 - bloka #11 tê îmzekirin û ji bo erêkirinê ji girêkên din re tê şandin
02:51 - bloka #11 tê pejirandin û ji zincîra root re tê şandin
02:55 - girêka dawîn danûstandinên ji bloka #10 qedand
10:59 - danûstendina bi radestkirina bloka #9 re di zincîra root de demek pir dirêj girt, lê ew qediya û hemî girêkan derbarê wê de agahdarî wergirtin û dest bi pêkanîna 350k danûstendinan kirin.
11:05 - hewz ji bo 320k danûstendinên ku li bloka #11 hatine zêdekirin paqij bûye
12:10 - Hemî nod 1 mîlyon 670k danûstendin û nîşanekan dihewîne
12:17 - girêk bişînin 330k danûstendinan ji hewzê girt û bloka #12 pêk tîne
12:32 - bloka #12 tê îmzekirin û ji bo erêkirinê ji girêkên din re tê şandin
12:39 - bloka #12 tê pejirandin û ji zincîra root re tê şandin
13:44 - hemî girêk ji zincîra root ku bloka #12 hate zêdekirin agahdarî wergirtin û dest bi sepandina 330k danûstendinan dikin
14:50 - Hemî nod 2 mîlyon danûstendin û nîşanan dihewîne
Test 3
Di pêşkêşkerên yekem û duyemîn de, girêkek pejirandî bi girêkek radestkirî hate guheztin.
Rewşa destpêkê: bloka dawî #84; 0 danûstendin û nîşanek di databasê de hatine tomar kirin
00:00 — 3 senaryo hatin destpêkirin ku her yek mîlyon danûstendinan çêdikin û dişînin
01:38 - 1 mîlyon danûstendin hatin afirandin û şandina ji bo radestkirina node #3 dest pê kir
01:50 - girêka #3 bişîne 330k danûstendinan ji hewzê û bloka #85 (f21) pêk tîne. Em her weha dibînin ku 350k danûstendin di 10 çirkeyan de li hewzê têne zêdekirin
01:53 - 1 mîlyon danûstendin hatin afirandin û şandina ji bo radestkirina node #1 dest pê kir
01:50 - girêka #3 bişîne 330k danûstendinan ji hewzê û bloka #85 (f21) pêk tîne. Em her weha dibînin ku 350k danûstendin di 10 çirkeyan de li hewzê têne zêdekirin
02:01 - girêka #1 bişînin 250k danûstendin ji hewzê girt û bloka #85 (65e) pêk tîne
02:06 - bloka #85 (f21) tê îmzekirin û ji bo erêkirinê ji girêkên din re tê şandin
02:08 - skrîpta demo ya servera #3, ku di 1 çirkeyan de 30 mîlyon danûstendinan şand, xebata xwe qedand.
02:14 - bloka #85 (f21) tê pejirandin û ji zincîra root re tê şandin
02:19 - bloka #85 (65e) tê îmzekirin û ji bo erêkirinê ji girêkên din re tê şandin
02:22 - 1 mîlyon danûstendin hatin afirandin û şandina ji bo radestkirina node #2 dest pê kir
02:27 - bloka #85 (65e) pejirand û ji zincîra root re hate şandin
02:29 - girêka #2 bişîne 111855 danûstendinan ji hewzê û bloka #85 (256) pêk tîne.
02:36 - bloka #85 (256) tê îmzekirin û ji bo erêkirinê ji girêkên din re tê şandin
02:36 - skrîpta demo ya servera #1, ku di 1 çirkeyan de 42.5 mîlyon danûstendinan şand, xebata xwe qedand.
02:38 - bloka #85 (256) tê pejirandin û ji zincîra root re tê şandin
03:08 - Skrîpta server #2 bi dawî bû, ku di 1 çirkeyan de 47 mîlyon danûstandin şand
03:38 - hemî girêk ji zincîra root a ku #85 (f21), #86 (65e), #87 (256) asteng dike agahdarî wergirtin û dest bi sepandina 330k, 250k, 111855 kirin.
03:49 - hewz bi 330k, 250k, 111855 danûstendinên ku li blokên #85 (f21), #86(65e), #87(256) hatine zêdekirin hate paqij kirin
03:59 - girêka #1 bişînin 888145 danûstendin ji hewzê girtin û bloka #88 (214) pêk tîne, girêka #2 radest bike 750 hezar danûstendin ji hewzê girt û bloka #88 (50a) pêk tîne, girê #3 bişîne 670 hezar danûstendin ji hewzê girt. hewz û formên bloka #88 (d3b)
04:44 - bloka #88 (d3b) tê îmzekirin û ji bo erêkirinê ji girêkên din re tê şandin
04:58 - bloka #88 (214) tê îmzekirin û ji bo erêkirinê ji girêkên din re tê şandin
05:11 - bloka #88 (50a) tê îmzekirin û ji bo erêkirinê ji girêkên din re tê şandin
05:11 - bloka #85 (d3b) tê pejirandin û ji zincîra root re tê şandin
05:36 - bloka #85 (214) tê pejirandin û ji zincîra root re tê şandin
05:43 - Hemî girêk ji zincîra root a ku #88 (d3b), #89 (214) asteng dike agahdarî wergirtin û dest bi sepandina danûstendinên 670k, 750k dikin.
06:50 - ji ber têkçûna ragihandinê, bloka #85 (50a) nehat pejirandin
06:55 - girêka #2 bişîne 888145 danûstendinan ji hewzê û bloka #90 (50a) pêk tîne
08:14 - bloka #90 (50a) tê îmzekirin û ji bo erêkirinê ji girêkên din re tê şandin
09:04 - bloka #90 (50a) tê pejirandin û ji zincîra root re tê şandin
11:23 - hemî girêk ji zincîra root ku bloka #90 (50a) lê zêde bû, agahdarî wergirtin, û dest bi sepandina 888145 danûstendinan dikin. Di heman demê de, servera #3 jixwe ji blokên #88 (d3b), #89 (214) veguhertinan sepandiye.
12:11 - hemû hewz vala ne
13:41 - Hemî girêkên servera #3 3 mîlyon danûstendin û nîşanan dihewîne
14:35 - Hemî girêkên servera #1 3 mîlyon danûstendin û nîşanan dihewîne
19:24 - Hemî girêkên servera #2 3 mîlyon danûstendin û nîşanan dihewîne
Astengiyên
Di dema pêşkeftina Plasma Cash de, em rastî pirsgirêkên jêrîn hatin, ku me hêdî hêdî çareser kir û çareser dike:
1. Nakokî di danûstendina fonksiyonên pergalê yên cihêreng de. Mînakî, fonksiyona lêzêdekirina danûstendinan li hewzê xebata şandin û pejirandina blokan asteng kir, û berevajî vê yekê, ku bû sedema kêmbûna bilez.
2. Tavilê ne diyar bû ku meriv çawa hejmareke mezin danûstendinan bişîne dema ku lêçûnên veguheztina daneyê kêm bike.
3. Ne diyar bû ku meriv çawa û li ku daneyan hilîne da ku bigihîje encamên bilind.
4. Ne diyar bû ku meriv çawa torgilokek di navbera girêkan de organîze dike, ji ber ku mezinahiya blokek bi 1 mîlyon danûstendinan bi qasî 100 MB digire.
5. Dema ku hesabên dirêj çêdibin (wek nimûne, avakirina darek Merkle û hesabkirina heşê wê) di moda yek-têlan de xebitîn têkiliya di navbera girêkan de qut dike.
Me bi van hemûyan re çawa kir?
Guhertoya yekem a girêka Plasma Cash celebek tevlihev bû ku di heman demê de dikaribû her tiştî bike: danûstendinan qebûl bike, blokan radest bike û rast bike, û ji bo gihîştina daneyan API peyda bike. Ji ber ku NodeJS bi xwemalî yek-têlek e, fonksiyona hesabkirina dara Merkle ya giran fonksiyona danûstendinê ya lê zêde bike asteng kir. Me ji bo çareserkirina vê pirsgirêkê du vebijark dît:
1. Gelek pêvajoyên NodeJS dest pê bikin, ku her yek ji wan fonksiyonên taybetî pêk tîne.
2. Worker_threads bikar bînin û pêkanîna beşek kodê di nav mijaran de biguhezînin.
Wekî encamek, me her du vebijark di heman demê de bikar anîn: me bi mentiqî yek nod li 3 beşan dabeş kir ku dikarin ji hev cuda bixebitin, lê di heman demê de bi hevdemî
1. Nodeya radestkirinê, ku danûstendinan di hewzê de qebûl dike û blokan diafirîne.
2. Nodek pejirandî ya ku rastdariya girêkan kontrol dike.
3. Node API - API-ê ji bo gihîştina daneyê peyda dike.
Di vê rewşê de, hûn dikarin bi karanîna cli-ê bi pêvekek unix ve bi her girêkekê ve girêdin.
Me operasyonên giran, wek hesabkirina dara Merkleyê, xist nav mijarek cihê.
Bi vî rengî, me hemwext û bêyî têkçûn gihîştiye xebata normal a hemî fonksiyonên Cash Plasma.
Dema ku pergal bikêr bû, me dest bi ceribandina lezê kir û, mixabin, encamên ne têrker wergirtin: 5 danûstendin di çirkeyê de û heya 000 danûstendin di her blokekê de. Diviya bû ku ez fêhm bikim ka çi bi xeletî hatî pêkanîn.
Destpêkê, me dest bi ceribandina mekanîzmaya ragihandinê ya bi Plasma Cash kir da ku kapasîteya pezê ya pergalê fêr bibe. Me berê nivîsand ku girêka Plasma Cash pêwendiyek soketek unix peyda dike. Di destpêkê de ew li ser text-based bû. Tiştên json bi bikaranîna `JSON.parse()` û `JSON.stringify()` hatin şandin.
```json
{
"action": "sendTransaction",
"payload":{
"prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
"prevBlock": 41,
"tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
"newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
"type": "pay",
"data": "",
"signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
}
}
```
Me leza veguheztina tiştên weha pîva û di çirkeyê de ~ 130k dît. Me hewl da ku ji bo xebata bi json re fonksiyonên standard biguhezînin, lê performans baştir nebû. Pêdivî ye ku motora V8 ji bo van operasyonan baş xweşbîn be.
Me di nav dersan de bi danûstendin, nîşan û blokan re xebitî. Dema afirandina dersên weha, performansa 2 carî daket, ku ev destnîşan dike ku OOP ji me re ne maqûl e. Diviya bû ku ez her tiştî bi nêzîkatiyek bikêrhatî ji nû ve binivîsim.
Di databasê de tomarkirin
Di destpêkê de, Redis ji bo hilanîna daneyê wekî yek ji çareseriyên herî hilberîner ku hewcedariyên me têr dike hate hilbijartin: hilanîna nirx-kilît, xebata bi tabloyên hash, set. Me redis-benchmark da destpêkirin û di 80 moda boriyê de ~ 1k operasyon di çirkeyê de girt.
Ji bo performansa bilind, me Redis bi hûrgulî guhezand:
- Têkiliyek soketek unix hate saz kirin.
- Me hilanîna dewletê li ser dîskê neçalak kir (ji bo pêbaweriyê, hûn dikarin kopiyek saz bikin û li ser dîskê di Redisek cihêreng de hilînin).
Di Redis de, hewzek tabloyek hash e ji ber ku pêdivî ye ku em karibin hemî danûstendinan di yek pirsê de vegerînin û danûstendinan yek bi yek jêbirin. Me hewl da ku navnîşek birêkûpêk bikar bînin, lê dema ku tevahiya navnîşê dakêşin hêdîtir e.
Dema ku NodeJS standard bikar tînin, pirtûkxaneyên Redis performansa 18k danûstendinan di çirkeyê de bi dest xistin. Leza 9 caran daket.
Ji ber ku pîvan nîşanî me da ku îmkan bi eşkere 5 carî mezintir in, me dest bi xweşbîniyê kir. Me pirtûkxane guhert ioredis û performansa 25k di çirkekê de girt. Me bi fermana `hset` yek bi yek kiryaran zêde kir. Ji ber vê yekê me li Redisê gelek pirs çêkirin. Fikir çêbû ku danûstendinan li hev bikin û wan bi yek fermanê `hmset` bişînin. Encam 32k per second e.
Ji ber çend sedeman, ku em ê li jêr rave bikin, em bi daneyan re bi karanîna `Buffer` dixebitin û, wekî ku xuya dike, heke hûn berî nivîsandinê wê veguhezînin nivîsê (`buffer.toString('hex')`), hûn dikarin bêtir bistînin. birêvebirinî. Bi vî awayî, leza 35k di çirkekê de zêde bû. Di vê demê de, me biryar da ku xweşbîniya bêtir rawestînin.
Diviya bû ku em derbasî protokolek binary bibin ji ber ku:
1. Pergal bi gelemperî hashes, îmzeyan, hwd hesab dike, û ji bo vê yekê ew hewceyê daneyên di `Buffer de ye.
2. Dema ku di navbera karûbaran de têne şandin, daneyên binary ji nivîsê kêmtir giran dibin. Mînakî, dema şandina blokek bi 1 mîlyon danûstendinan, daneyên di nivîsê de dikare ji 300 megabyte zêdetir bigire.
3. Veguherîna domdar a daneyan bandorê li performansê dike.
Ji ber vê yekê, me protokola xweya binary ji bo hilanîn û veguheztina daneyan, ku li ser bingeha pirtûkxaneya "binary-data" ya ecêb hatî pêşve xistin, wekî bingeh girt.
Di encamê de, me strukturên daneya jêrîn wergirtin:
-Şandindayinî
```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),
}
```
-Deste
```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,
}
```
Bi fermanên asayî yên `BD.encode(block, Protocol).slice();` û `BD.decode(buffer, Protocol)` em daneyan diguherînin "Buffer" ji bo tomarkirina li Redis an şandina girêkek din û vegerandina dane paş.
Ji bo veguheztina daneyan di navbera karûbaran de 2 protokolên binary jî hene:
- Protokola danûstendina bi Nodeya Plasmayê re bi riya soketa 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)
}
```
derê
- `cure` - çalakiya ku tê kirin, mînakî, 1 - sendTransaction, 2 - getTransaction;
- `bargiran` - Daneyên ku hewce ne ku ji fonksiyona guncan re werin şandin;
- `messageId` - Nasnameya peyamê da ku bersiv were naskirin.
- Protokola danûstendina di navbera girêkan de
```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)
}
```
derê
- `kod` — Koda peyamê, mînak 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
- `versionProtocol` - Guhertoya protokolê, ji ber ku girêkên bi guhertoyên cihêreng dikarin li ser torê werin rakirin û ew dikarin cûda bixebitin;
- `seq` - Nasnameya peyamê;
- `countChunk` и `Hejmara perçeyê` ji bo dabeşkirina peyamên mezin pêwîst e;
- `dirêjî` и `bargiran` dirêj û daneyên xwe.
Ji ber ku me daneyan ji berê ve nivîsandin, pergala paşîn ji pirtûkxaneya `rlp` ya Ethereum pir zûtir e. Mixabin, me hîn nekariye wê red bikin, ji ber ku pêdivî ye ku peymana biaqil bi dawî bibe, ya ku em plan dikin ku di pêşerojê de bikin.
Ger em bigihîjin lezê 35 000 danûstendinên di çirkeyê de, em jî hewce ne ku wan di wextê çêtirîn de pêvajoyê bikin. Ji ber ku dema nêzîkbûna avakirina blokê 30 saniye digire, divê em tev li blokê bikin 1 000 000 muamele, ku tê wateya şandina zêdetir 100 MB daneyên.
Di destpêkê de, me pirtûkxaneya `ethereumjs-devp2p` bikar anî da ku di navbera girêkan de danûstendinê bike, lê ew nikarî ewqas daneyan bi rê ve bibe. Wekî encamek, me pirtûkxaneya `ws` bikar anî û şandina daneyên binary bi riya websocket vesaz kir. Bê guman, di dema şandina pakêtên daneya mezin de jî me rastî pirsgirêkan hat, lê me ew li perçeyan parve kirin û naha ev pirsgirêk ji holê rabûne.
Di heman demê de darek Merkle çêdibe û hash hesab dike 1 000 000 danûstendinan li ser hewce dike 10 saniyeyên hesabkirina berdewam. Di vê demê de, girêdana bi hemî girêkan re têk diçe. Biryar hat girtin ku ev hesab veguhezînin mijarek cûda.
Encamên
Bi rastî, vedîtinên me ne nû ne, lê ji ber hin sedeman gelek pispor dema pêşve diçin wan ji bîr dikin.
- Bikaranîna Bernamesaziya Fonksiyonel li şûna Bernamesaziya Objekt Oriented hilberandinê çêtir dike.
- Monolît ji mîmariya karûbarê ji bo pergalek NodeJS-ya hilberîner xirabtir e.
- Bikaranîna `karker_threads` ji bo hesabkirina giran, bersivdana pergalê çêtir dike, nemaze dema ku bi operasyonên i/o re mijûl dibin.
- soketa unix ji daxwazên http aramtir û bileztir e.
- Heke hûn hewce ne ku zû daneyên mezin li ser torê veguhezînin, çêtir e ku hûn websocket bikar bînin û daneyên binary, ku li perçeyan têne dabeş kirin, bişînin, ku heke ew negihin dikarin werin şandin, û dûv re di yek peyamê de werin berhev kirin.
Em we vedixwînin serdanê GitHub rêvename:
Gotar ji hêla hevrêz ve hatî nivîsandin Alexander Nashivan, pêşdebirê payebilind .
Source: www.habr.com