Blockchain yn dechnoleg arloesol sy'n addo gwella llawer o feysydd o fywyd dynol. Mae'n trosglwyddo prosesau a chynhyrchion go iawn i'r gofod digidol, yn sicrhau cyflymder a dibynadwyedd trafodion ariannol, yn lleihau eu cost, a hefyd yn caniatáu ichi greu cymwysiadau DAPP modern gan ddefnyddio contractau smart mewn rhwydweithiau datganoledig.
O ystyried manteision niferus a chymwysiadau amrywiol blockchain, gall ymddangos yn syndod nad yw'r dechnoleg addawol hon wedi cyrraedd pob diwydiant eto. Y broblem yw nad oes gan blockchains datganoledig modern scalability. Mae Ethereum yn prosesu tua 20 o drafodion yr eiliad, nad yw'n ddigon i ddiwallu anghenion busnesau deinamig heddiw. Ar yr un pryd, mae cwmnïau sy'n defnyddio technoleg blockchain yn betrusgar i roi'r gorau i Ethereum oherwydd ei lefel uchel o amddiffyniad rhag hacio a methiannau rhwydwaith.
Er mwyn sicrhau datganoli, diogelwch a scalability yn y blockchain, a thrwy hynny ddatrys y Scalability Trilemma, y tîm datblygu creu Plasma Cash, cadwyn atodol sy'n cynnwys contract smart a rhwydwaith preifat yn seiliedig ar Node.js, sy'n trosglwyddo ei gyflwr o bryd i'w gilydd i'r gadwyn wreiddiau (Ethereum).
Prosesau allweddol yn Plasma Cash
1. Mae'r defnyddiwr yn galw'r swyddogaeth contract smart yn 'blaendal', gan drosglwyddo iddo faint o ETH y mae am ei adneuo i'r tocyn Plasma Cash. Mae'r swyddogaeth contract smart yn creu tocyn ac yn cynhyrchu digwyddiad amdano.
2. Mae nodau Plasma Cash sydd wedi tanysgrifio i ddigwyddiadau contract smart yn derbyn digwyddiad am greu blaendal ac yn ychwanegu trafodiad am greu tocyn i'r pwll.
3. O bryd i'w gilydd, mae nodau Arian Plasma arbennig yn cymryd yr holl drafodion o'r pwll (hyd at 1 miliwn) ac yn ffurfio bloc oddi wrthynt, cyfrifwch y goeden Merkle ac, yn unol â hynny, y hash. Anfonir y bloc hwn i nodau eraill i'w ddilysu. Mae'r nodau'n gwirio a yw'r hash Merkle yn ddilys ac a yw'r trafodion yn ddilys (er enghraifft, ai anfonwr y tocyn yw ei berchennog). Ar ôl dilysu'r bloc, mae'r nod yn galw swyddogaeth `submitBlock` y contract smart, sy'n arbed rhif y bloc a hash Merkle i'r gadwyn ymyl. Mae'r contract smart yn cynhyrchu digwyddiad sy'n nodi ychwanegu bloc yn llwyddiannus. Mae trafodion yn cael eu tynnu o'r pwll.
4. Mae nodau sy'n derbyn y digwyddiad cyflwyno bloc yn dechrau cymhwyso'r trafodion a ychwanegwyd at y bloc.
5. Ar ryw adeg, mae perchennog (neu berson nad yw'n berchennog) y tocyn am ei dynnu'n ôl o Plasma Cash. I wneud hyn, mae'n galw'r swyddogaeth `startExit`, gan drosglwyddo gwybodaeth iddo am y 2 drafodyn olaf ar y tocyn, sy'n cadarnhau mai ef yw perchennog y tocyn. Mae'r contract smart, gan ddefnyddio hash Merkle, yn gwirio presenoldeb trafodion yn y blociau ac yn anfon y tocyn i'w dynnu'n ôl, a fydd yn digwydd mewn pythefnos.
6. Os digwyddodd y weithred tynnu tocyn gyda throseddau (cafodd y tocyn ei wario ar ôl i'r weithdrefn tynnu'n ôl ddechrau neu os oedd y tocyn eisoes yn un rhywun arall cyn tynnu'r tocyn yn ôl), gall perchennog y tocyn wrthbrofi'r tynnu'n ôl o fewn pythefnos.
Sicrheir preifatrwydd mewn dwy ffordd
1. Nid yw'r gadwyn wreiddiau yn gwybod dim am y trafodion sy'n cael eu cynhyrchu a'u hanfon ymlaen o fewn y gadwyn blant. Mae gwybodaeth am bwy a adneuodd ac a dynnodd ETH yn ôl o Plasma Cash yn parhau i fod yn gyhoeddus.
2. Mae'r gadwyn plant yn caniatáu trafodion dienw gan ddefnyddio zk-SNARKs.
pentwr technoleg
- NodeJS
- Redis
- Etheriwm
- Pridd
Profi
Wrth ddatblygu Plasma Cash, gwnaethom brofi cyflymder y system a chael y canlyniadau canlynol:
- hyd at 35 o drafodion yr eiliad yn cael eu hychwanegu at y gronfa;
- gellir storio hyd at drafodion 1 mewn bloc.
Cynhaliwyd profion ar y 3 gweinydd canlynol:
1. Intel Core i7-6700 Quad-Core Skylake gan gynnwys. NVMe SSD - 512 GB, 64 GB DDR4 RAM
Codwyd 3 nod dilysu Plasma Cash.
2. AMD Ryzen 7 1700X Octa-Core “Summit Ridge” (Zen), SSD SATA - 500 GB, 64 GB DDR4 RAM
Codwyd nod testnet ETH Ropsten.
Codwyd 3 nod dilysu Plasma Cash.
3. Intel Core i9-9900K Octa-Core gan gynnwys. NVMe SSD - 1 TB, 64 GB DDR4 RAM
1 Codwyd nod cyflwyno Plasma Cash.
Codwyd 3 nod dilysu Plasma Cash.
Lansiwyd prawf i ychwanegu trafodion at y rhwydwaith Plasma Cash.
Cyfanswm: 10 nod Plasma Cash mewn rhwydwaith preifat.
Prawf 1
Mae terfyn o 1 miliwn o drafodion fesul bloc. Felly, mae 1 miliwn o drafodion yn disgyn i 2 floc (gan fod y system yn llwyddo i gymryd rhan o'r trafodion a'u cyflwyno tra'u bod yn cael eu hanfon).
Cyflwr cychwynnol: bloc olaf #7; Mae 1 miliwn o drafodion a thocynnau yn cael eu storio yn y gronfa ddata.
00:00 - dechrau'r sgript cynhyrchu trafodion
01:37 - Crëwyd 1 miliwn o drafodion a dechreuwyd anfon at y nod
01:46 - cymerodd nod cyflwyno 240k o drafodion o'r pwll a bloc ffurflenni #8. Rydym hefyd yn gweld bod 320k o drafodion yn cael eu hychwanegu at y gronfa mewn 10 eiliad
01:58 - bloc #8 wedi'i lofnodi a'i anfon i'w ddilysu
02:03 - mae bloc #8 wedi'i ddilysu a gelwir swyddogaeth `submitBlock` y contract clyfar gyda'r hash Merkle a'r rhif bloc
02:10 - gorffennodd y sgript demo weithio, a anfonodd 1 miliwn o drafodion mewn 32 eiliad
02:33 - dechreuodd nodau dderbyn gwybodaeth bod bloc #8 wedi'i ychwanegu at y gadwyn wreiddiau, a dechreuodd gyflawni 240k o drafodion
02:40 - Tynnwyd 240k o drafodion o'r pwll, sydd eisoes ym mloc #8
02:56 - cymerodd y nod cyflwyno weddill y 760k o drafodion o'r pwll a dechreuodd gyfrifo stwnsh Merkle a bloc llofnodi #9
03:20 - mae pob nod yn cynnwys 1 miliwn o drafodion 240k a thocynnau
03:35 - bloc #9 wedi'i lofnodi a'i anfon i nodau eraill i'w ddilysu
03:41 - gwall rhwydwaith wedi digwydd
04:40 - aros am ddilysiad bloc #9 wedi dod i ben
04:54 - cymerodd y nod cyflwyno weddill y 760k o drafodion o'r pwll a dechreuodd gyfrifo stwnsh Merkle a bloc llofnodi #9
05:32 - bloc #9 wedi'i lofnodi a'i anfon i nodau eraill i'w ddilysu
05:53 - mae bloc #9 yn cael ei ddilysu a'i anfon i'r gadwyn wreiddiau
06:17 - dechreuodd nodau dderbyn gwybodaeth bod bloc #9 wedi'i ychwanegu at y gadwyn wreiddiau a dechrau cyflawni 760k o drafodion
06:47 - mae'r gronfa wedi clirio trafodion sydd ym mloc #9
09:06 - mae pob nod yn cynnwys 2 filiwn o drafodion a thocynnau
Prawf 2
Mae terfyn o 350k y bloc. O ganlyniad, mae gennym 3 bloc.
Cyflwr cychwynnol: bloc olaf #9; Mae 2 filiwn o drafodion a thocynnau yn cael eu storio yn y gronfa ddata
00:00 - sgript cynhyrchu trafodion eisoes wedi'i lansio
00:44 - Crëwyd 1 miliwn o drafodion a dechreuwyd anfon at y nod
00:56 - cymerodd nod cyflwyno 320k o drafodion o'r pwll a bloc ffurflenni #10. Rydym hefyd yn gweld bod 320k o drafodion yn cael eu hychwanegu at y gronfa mewn 10 eiliad
01:12 - bloc #10 wedi'i lofnodi a'i anfon i nodau eraill i'w ddilysu
01:18 - gorffennodd y sgript demo weithio, a anfonodd 1 miliwn o drafodion mewn 34 eiliad
01:20 — mae bloc #10 yn cael ei ddilysu a'i anfon i'r gadwyn wreiddiau
01:51 - derbyniodd pob nod wybodaeth o'r gadwyn wreiddiau a ychwanegwyd bloc #10 a dechrau cymhwyso 320k o drafodion
02:01 - mae'r pwll wedi clirio ar gyfer 320k o drafodion a gafodd eu hychwanegu at floc #10
02:15 - cymerodd nod cyflwyno 350k o drafodion o'r pwll a bloc ffurflenni #11
02:34 - bloc #11 wedi'i lofnodi a'i anfon i nodau eraill i'w ddilysu
02:51 — mae bloc #11 yn cael ei ddilysu a'i anfon i'r gadwyn wreiddiau
02:55 - cwblhaodd y nod olaf drafodion o floc #10
10:59 - cymerodd y trafodiad gyda chyflwyno bloc #9 amser hir iawn yn y gadwyn wreiddiau, ond fe'i cwblhawyd a derbyniodd pob nod wybodaeth amdano a dechreuodd berfformio trafodion 350k
11:05 - mae'r pwll wedi clirio ar gyfer 320k o drafodion a gafodd eu hychwanegu at floc #11
12:10 - mae pob nod yn cynnwys 1 miliwn o drafodion 670k a thocynnau
12:17 - cymerodd nod cyflwyno 330k o drafodion o'r pwll a bloc ffurflenni #12
12:32 - bloc #12 wedi'i lofnodi a'i anfon i nodau eraill i'w ddilysu
12:39 — mae bloc #12 yn cael ei ddilysu a'i anfon i'r gadwyn wreiddiau
13:44 - derbyniodd pob nod wybodaeth o'r gadwyn wreiddiau a ychwanegwyd bloc #12 a dechrau cymhwyso 330k o drafodion
14:50 - mae pob nod yn cynnwys 2 filiwn o drafodion a thocynnau
Prawf 3
Yn y gweinydd cyntaf a'r ail, disodlwyd un nod dilysu gan nod cyflwyno.
Cyflwr cychwynnol: bloc olaf #84; 0 trafodion a thocynnau wedi'u cadw yn y gronfa ddata
00:00 - Mae 3 sgript wedi'u lansio sy'n cynhyrchu ac yn anfon 1 miliwn o drafodion yr un
01:38 - Crëwyd 1 miliwn o drafodion a dechreuwyd anfon i gyflwyno nod #3
01:50 - nod cyflwyno #3 cymerodd 330k o drafodion o'r pwll a bloc ffurflenni #85 (f21). Rydym hefyd yn gweld bod 350k o drafodion yn cael eu hychwanegu at y gronfa mewn 10 eiliad
01:53 - Crëwyd 1 miliwn o drafodion a dechreuwyd anfon i gyflwyno nod #1
01:50 - nod cyflwyno #3 cymerodd 330k o drafodion o'r pwll a bloc ffurflenni #85 (f21). Rydym hefyd yn gweld bod 350k o drafodion yn cael eu hychwanegu at y gronfa mewn 10 eiliad
02:01 - nod cyflwyno #1 cymerodd 250k o drafodion o'r pwll a bloc ffurflenni #85 (65e)
02:06 — bloc #85 (f21) wedi'i lofnodi a'i anfon at nodau eraill i'w ddilysu
02:08 - sgript demo gweinydd #3, a anfonodd 1 miliwn o drafodion mewn 30 eiliad, wedi gorffen gweithio
02:14 — mae bloc #85 (f21) yn cael ei ddilysu a'i anfon at y gadwyn wreiddiau
02:19 — bloc #85 (65e) wedi'i lofnodi a'i anfon at nodau eraill i'w ddilysu
02:22 - Crëwyd 1 miliwn o drafodion a dechreuwyd anfon i gyflwyno nod #2
02:27 — bloc #85 (65e) wedi'i ddilysu a'i anfon at y gadwyn wreiddiau
02:29 - nod cyflwyno #2 cymerodd 111855 o drafodion o'r pwll a bloc ffurflenni #85 (256).
02:36 — bloc #85 (256) wedi'i lofnodi a'i anfon at nodau eraill i'w ddilysu
02:36 - sgript demo gweinydd #1, a anfonodd 1 miliwn o drafodion mewn 42.5 eiliad, wedi gorffen gweithio
02:38 — mae bloc #85 (256) yn cael ei ddilysu a'i anfon at y gadwyn wreiddiau
03:08 - gorffennodd sgript gweinydd #2 weithio, a anfonodd 1 miliwn o drafodion mewn 47 eiliad
03:38 - derbyniodd pob nod wybodaeth o'r gadwyn wreiddiau sy'n blocio #85 (f21), #86(65e), #87(256) a dechreuodd gymhwyso trafodion 330k, 250k, 111855
03:49 - cliriwyd y pwll ar 330k, 250k, 111855 o drafodion a gafodd eu hychwanegu at flociau #85 (f21), #86(65e), #87(256)
03:59 - nod cyflwyno #1 cymerodd 888145 o drafodion o'r pwll a bloc ffurflenni #88 (214), cyflwynodd nod #2 cymerodd 750k o drafodion o'r pwll a bloc ffurflenni #88 (50a), cymerodd nod cyflwyno #3 670k o drafodion o y pwll a bloc ffurflenni #88 (d3b)
04:44 — bloc #88 (d3b) wedi'i lofnodi a'i anfon at nodau eraill i'w ddilysu
04:58 — bloc #88 (214) wedi'i lofnodi a'i anfon at nodau eraill i'w ddilysu
05:11 — bloc #88 (50a) yn cael ei lofnodi a'i anfon at nodau eraill i'w ddilysu
05:11 — mae bloc #85 (d3b) yn cael ei ddilysu a'i anfon at y gadwyn wreiddiau
05:36 — mae bloc #85 (214) yn cael ei ddilysu a'i anfon at y gadwyn wreiddiau
05:43 - derbyniodd pob nod wybodaeth o'r gadwyn wreiddiau sy'n blocio #88 (d3b), #89(214) ac yn dechrau cymhwyso trafodion 670k, 750k
06:50 - oherwydd methiant cyfathrebu, ni ddilyswyd bloc #85 (50a).
06:55 - nod cyflwyno #2 cymerodd 888145 o drafodion o'r pwll a bloc ffurflenni #90 (50a)
08:14 — bloc #90 (50a) yn cael ei lofnodi a'i anfon at nodau eraill i'w ddilysu
09:04 — mae bloc #90 (50a) yn cael ei ddilysu a'i anfon at y gadwyn wreiddiau
11:23 - derbyniodd pob nod wybodaeth o'r gadwyn wreiddiau a ychwanegwyd bloc #90 (50a), a dechrau cymhwyso 888145 o drafodion. Ar yr un pryd, mae gweinydd #3 eisoes wedi cymhwyso trafodion o flociau #88 (d3b), #89(214)
12:11 - mae pob pwll yn wag
13:41 - mae holl nodau gweinydd #3 yn cynnwys 3 miliwn o drafodion a thocynnau
14:35 - mae holl nodau gweinydd #1 yn cynnwys 3 miliwn o drafodion a thocynnau
19:24 - mae holl nodau gweinydd #2 yn cynnwys 3 miliwn o drafodion a thocynnau
Rhwystrau
Yn ystod datblygiad Plasma Cash, daethom ar draws y problemau canlynol, y gwnaethom eu datrys yn raddol ac rydym yn eu datrys:
1. Gwrthdaro yn y rhyngweithio rhwng swyddogaethau system amrywiol. Er enghraifft, roedd swyddogaeth ychwanegu trafodion i'r pwll yn rhwystro'r gwaith o gyflwyno a dilysu blociau, ac i'r gwrthwyneb, a arweiniodd at ostyngiad mewn cyflymder.
2. Nid oedd yn glir ar unwaith sut i anfon nifer enfawr o drafodion tra'n lleihau costau trosglwyddo data.
3. Nid oedd yn glir sut a ble i storio data er mwyn cyflawni canlyniadau uchel.
4. Nid oedd yn glir sut i drefnu rhwydwaith rhwng nodau, gan fod maint bloc gyda 1 miliwn o drafodion yn cymryd tua 100 MB.
5. Mae gweithio mewn modd un edau yn torri'r cysylltiad rhwng nodau pan fydd cyfrifiadau hir yn digwydd (er enghraifft, adeiladu coeden Merkle a chyfrifo ei hash).
Sut wnaethon ni ddelio â hyn i gyd?
Roedd fersiwn gyntaf y nod Plasma Cash yn fath o gyfuniad a allai wneud popeth ar yr un pryd: derbyn trafodion, cyflwyno a dilysu blociau, a darparu API ar gyfer cyrchu data. Gan fod NodeJS yn frodorol un edau, rhwystrodd swyddogaeth cyfrifo coeden Merkle trwm y swyddogaeth trafodion ychwanegu. Gwelsom ddau opsiwn ar gyfer datrys y broblem hon:
1. Lansio nifer o brosesau NodeJS, pob un ohonynt yn cyflawni swyddogaethau penodol.
2. Defnyddiwch worker_threads a symudwch weithrediad rhan o'r cod yn edafedd.
O ganlyniad, gwnaethom ddefnyddio'r ddau opsiwn ar yr un pryd: fe wnaethom rannu un nod yn rhesymegol yn 3 rhan a all weithio ar wahân, ond ar yr un pryd yn gydamserol
1. Nod cyflwyno, sy'n derbyn trafodion i'r pwll ac yn creu blociau.
2. Nod dilysu sy'n gwirio dilysrwydd nodau.
3. Nod API - yn darparu API ar gyfer cyrchu data.
Yn yr achos hwn, gallwch gysylltu â phob nod trwy soced unix gan ddefnyddio cli.
Fe wnaethon ni symud gweithrediadau trwm, fel cyfrifo'r goeden Merkle, i mewn i edau ar wahân.
Felly, rydym wedi cyflawni gweithrediad arferol holl swyddogaethau Plasma Cash ar yr un pryd a heb fethiannau.
Unwaith y byddai'r system yn weithredol, dechreuon ni brofi'r cyflymder ac, yn anffodus, cawsom ganlyniadau anfoddhaol: 5 o drafodion yr eiliad a hyd at 000 o drafodion y bloc. Roedd yn rhaid i mi ddarganfod beth a weithredwyd yn anghywir.
I ddechrau, gwnaethom ddechrau profi'r mecanwaith cyfathrebu â Plasma Cash i ddarganfod gallu brig y system. Ysgrifennom yn gynharach fod y nod Plasma Cash yn darparu rhyngwyneb soced unix. I ddechrau roedd yn seiliedig ar destun. anfonwyd gwrthrychau json gan ddefnyddio `JSON.parse()` a `JSON.stringify()`.
```json
{
"action": "sendTransaction",
"payload":{
"prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
"prevBlock": 41,
"tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
"newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
"type": "pay",
"data": "",
"signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
}
}
```
Fe wnaethom fesur cyflymder trosglwyddo gwrthrychau o'r fath a chanfod ~ 130k yr eiliad. Fe wnaethom geisio disodli'r swyddogaethau safonol ar gyfer gweithio gyda json, ond ni wellodd perfformiad. Rhaid optimeiddio'r injan V8 yn dda ar gyfer y gweithrediadau hyn.
Buom yn gweithio gyda thrafodion, tocynnau, a blociau trwy ddosbarthiadau. Wrth greu dosbarthiadau o'r fath, gostyngodd y perfformiad 2 waith, sy'n dangos nad yw OOP yn addas i ni. Roedd yn rhaid i mi ailysgrifennu popeth i ddull cwbl ymarferol.
Cofnodi yn y gronfa ddata
I ddechrau, dewiswyd Redis ar gyfer storio data fel un o'r atebion mwyaf cynhyrchiol sy'n bodloni ein gofynion: storio gwerth allweddol, gweithio gyda thablau hash, setiau. Fe wnaethom lansio ailddis-meincnod a chael ~80k o weithrediadau yr eiliad mewn 1 modd piblinellu.
Ar gyfer perfformiad uchel, fe wnaethom diwnio Redis yn fanylach:
- Mae cysylltiad soced unix wedi'i sefydlu.
- Fe wnaethom analluogi arbed y cyflwr i ddisg (ar gyfer dibynadwyedd, gallwch sefydlu replica a'i gadw ar ddisg mewn Redis ar wahân).
Yn Redis, mae cronfa yn dabl hash oherwydd mae angen i ni allu adalw'r holl drafodion mewn un ymholiad a dileu trafodion fesul un. Fe wnaethon ni geisio defnyddio rhestr reolaidd, ond mae'n arafach wrth ddadlwytho'r rhestr gyfan.
Wrth ddefnyddio NodeJS safonol, cyflawnodd y llyfrgelloedd Redis berfformiad o drafodion 18k yr eiliad. Gostyngodd y cyflymder 9 gwaith.
Gan fod y meincnod yn dangos i ni fod y posibiliadau'n amlwg 5 gwaith yn fwy, fe ddechreuon ni wneud y gorau. Fe wnaethom newid y llyfrgell i ioredis a chael perfformiad o 25k yr eiliad. Fe wnaethom ychwanegu trafodion fesul un gan ddefnyddio'r gorchymyn `hset`. Felly roeddem yn cynhyrchu llawer o ymholiadau yn Redis. Cododd y syniad i gyfuno trafodion yn sypiau a'u hanfon gydag un gorchymyn `hmset`. Y canlyniad yw 32k yr eiliad.
Am nifer o resymau, y byddwn yn eu disgrifio isod, rydym yn gweithio gyda data gan ddefnyddio `Buffer` ac, fel mae'n digwydd, os byddwch yn ei drosi i destun (`buffer.toString ('hex')`) cyn ysgrifennu, gallwch gael ychwanegol perfformiad. Felly, cynyddwyd y cyflymder i 35k yr eiliad. Ar hyn o bryd, penderfynasom atal optimeiddio pellach.
Roedd yn rhaid i ni newid i brotocol deuaidd oherwydd:
1. Mae'r system yn aml yn cyfrifo hashes, llofnodion, ac ati, ac ar gyfer hyn mae angen data yn y `Buffer.
2. Pan gaiff ei anfon rhwng gwasanaethau, mae data deuaidd yn pwyso llai na thestun. Er enghraifft, wrth anfon bloc gyda 1 miliwn o drafodion, gall y data yn y testun gymryd mwy na 300 megabeit.
3. Mae trawsnewid data yn gyson yn effeithio ar berfformiad.
Felly, fe wnaethom gymryd fel sail ein protocol deuaidd ein hunain ar gyfer storio a throsglwyddo data, a ddatblygwyd ar sail y llyfrgell `data deuaidd` wych.
O ganlyniad, cawsom y strwythurau data canlynol:
—Trafodiad
```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,
}
```
— Tocyn
```json
{
id: BD.types.string(null),
owner: BD.types.buffer(20),
block: BD.types.uint24le,
amount: BD.types.string(null),
}
```
—Bloc
```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,
}
```
Gyda'r gorchmynion arferol `BD.encode(bloc, Protocol).sleisen();` a `BD.decode(buffer, Protocol)` rydym yn trosi'r data yn `Buffer` ar gyfer arbed yn Redis neu ei anfon ymlaen i nod arall ac adalw'r data yn ôl.
Mae gennym hefyd 2 brotocol deuaidd ar gyfer trosglwyddo data rhwng gwasanaethau:
— Protocol ar gyfer rhyngweithio â Plasma Node trwy soced 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)
}
```
lle:
- `math` — y weithred i'w chyflawni, er engraifft, 1 — anfonTransaction, 2 — getTransaction;
- `llwyth tâl` — data y mae angen ei drosglwyddo i'r swyddogaeth briodol;
- `messageId` — id neges fel y gellir nodi'r ymateb.
— Protocol ar gyfer rhyngweithio rhwng nodau
```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)
}
```
lle:
- `cod` — cod neges, er enghraifft 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
- `Protocol fersiwn` — fersiwn protocol, gan y gellir codi nodau â fersiynau gwahanol ar y rhwydwaith a gallant weithio'n wahanol;
- `seq` — dynodwr neges;
- `cyfrif' и `Rhif talp' angenrheidiol ar gyfer hollti negeseuon mawr;
- `hyd` и `llwyth tâl` hyd a'r data ei hun.
Ers i ni deipio'r data ymlaen llaw, mae'r system derfynol yn llawer cyflymach na llyfrgell `rlp` Ethereum. Yn anffodus, nid ydym wedi gallu ei wrthod eto, gan fod angen cwblhau'r contract smart, yr ydym yn bwriadu ei wneud yn y dyfodol.
Pe baem yn llwyddo i gyrraedd y cyflymder 35 000 trafodion yr eiliad, mae angen inni hefyd eu prosesu yn yr amser gorau posibl. Gan fod yr amser ffurfio bloc bras yn cymryd 30 eiliad, mae angen i ni ei gynnwys yn y bloc 1 000 000 trafodion, sy'n golygu anfon mwy 100 MB o ddata.
I ddechrau, gwnaethom ddefnyddio'r llyfrgell `ethereumjs-devp2p` i gyfathrebu rhwng nodau, ond ni allai drin cymaint o ddata. O ganlyniad, fe wnaethom ddefnyddio'r llyfrgell `ws` a ffurfweddu anfon data deuaidd trwy websocket. Wrth gwrs, cawsom hefyd broblemau wrth anfon pecynnau data mawr, ond fe wnaethom eu rhannu'n dalpiau ac yn awr mae'r problemau hyn wedi diflannu.
Hefyd yn ffurfio coeden Merkle a chyfrifo'r hash 1 000 000 trafodion yn gofyn am 10 eiliadau o gyfrifiad parhaus. Yn ystod yr amser hwn, mae'r cysylltiad â'r holl nodau yn llwyddo i dorri. Penderfynwyd symud y cyfrifiad hwn i edefyn ar wahân.
Casgliadau:
Mewn gwirionedd, nid yw ein canfyddiadau yn newydd, ond am ryw reswm mae llawer o arbenigwyr yn anghofio amdanynt wrth ddatblygu.
- Mae defnyddio Rhaglennu Swyddogaethol yn lle Rhaglennu sy'n Canolbwyntio ar Wrthrychau yn gwella cynhyrchiant.
- Mae'r monolith yn waeth na phensaernïaeth gwasanaeth ar gyfer system NodeJS cynhyrchiol.
- Mae defnyddio `worker_threads` ar gyfer cyfrifiant trwm yn gwella ymatebolrwydd y system, yn enwedig wrth ddelio â gweithrediadau i/o.
- mae soced unix yn fwy sefydlog ac yn gyflymach na cheisiadau http.
- Os oes angen i chi drosglwyddo data mawr yn gyflym dros y rhwydwaith, mae'n well defnyddio socedi gwe ac anfon data deuaidd, wedi'i rannu'n dalpiau, y gellir eu hanfon ymlaen os na fyddant yn cyrraedd, ac yna eu cyfuno'n un neges.
Rydym yn eich gwahodd i ymweld GitHub prosiect:
Cyd-ysgrifenwyd yr erthygl gan Alexander Nashivan, uwch ddatblygwr .
Ffynhonnell: hab.com