🥇Uji Umum: Solusi kanggo Privasi lan Skalabilitas ing Ethereum

Blockchain minangka teknologi inovatif sing njanjeni kanggo nambah akeh bidang urip manungsa. Iki mindhah proses lan produk nyata menyang ruang digital, njamin kacepetan lan linuwih transaksi finansial, nyuda biaya, lan uga ngidini sampeyan nggawe aplikasi DAPP modern nggunakake kontrak cerdas ing jaringan desentralisasi.

Amarga akeh keuntungan lan macem-macem aplikasi blockchain, bisa uga kaget yen teknologi sing janjeni iki durung mlebu ing saben industri. Masalahe yaiku blockchains desentralisasi modern ora duwe skalabilitas. Ethereum ngolah babagan 20 transaksi per detik, sing ora cukup kanggo nyukupi kabutuhan bisnis dinamis saiki. Ing wektu sing padha, perusahaan sing nggunakake teknologi pamblokiran ragu-ragu kanggo ninggalake Ethereum amarga tingkat perlindungan sing dhuwur saka peretasan lan kegagalan jaringan.

Kanggo mesthekake desentralisasi, keamanan lan skalabilitas ing pamblokiran, saéngga ngrampungake Skalabilitas Trilemma, tim pangembangan Kesempatan digawe Plasma Cash, chain tambahan dumadi saka kontrak pinter lan jaringan pribadi adhedhasar Node.js, kang periodik nransfer negara kanggo chain ROOT (Ethereum).

Proses kunci ing Plasma Cash

1. Pangguna nelpon fungsi kontrak cerdas `simpenan`, ngliwati jumlah ETH sing pengin disetor menyang token Plasma Cash. Fungsi kontrak pinter nggawe token lan ngasilake acara babagan.

2. Node Plasma Cash sing langganan acara kontrak pinter nampa acara babagan nggawe simpenan lan nambah transaksi babagan nggawe token menyang blumbang.

3. Secara periodik, simpul Plasma Cash khusus njupuk kabeh transaksi saka blumbang (nganti 1 yuta) lan mbentuk blok saka wong-wong mau, ngetung wit Merkle lan, kanthi mangkono, hash. Blok iki dikirim menyang simpul liyane kanggo verifikasi. Node mriksa apa hash Merkle bener lan apa transaksi kasebut sah (contone, apa pangirim token iku pemilike). Sawise verifikasi pamblokiran, simpul kasebut nelpon fungsi `submitBlock` saka kontrak cerdas, sing nyimpen nomer blok lan hash Merkle menyang rantai pinggir. Kontrak cerdas ngasilake acara sing nuduhake sukses tambahan blok. Transaksi dibusak saka blumbang.

4. Node sing nampa acara pengajuan blok wiwit ngetrapake transaksi sing ditambahake ing blok kasebut.

5. Ing sawetara titik, pemilik (utawa non-pemilik) token pengin mbatalake saka Plasma Cash. Kanggo nindakake iki, dheweke nelpon fungsi `startExit`, menehi informasi babagan 2 transaksi pungkasan ing token, sing konfirmasi yen dheweke minangka pemilik token kasebut. Kontrak cerdas, nggunakake hash Merkle, mriksa anané transaksi ing pamblokiran lan ngirim token kanggo penarikan, sing bakal kedadeyan ing rong minggu.

6. Yen operasi penarikan token dumadi kanthi pelanggaran (token dileksanakake sawise prosedur penarikan diwiwiti utawa token kasebut wis dadi milik wong liya sadurunge penarikan), pemilik token bisa mbantah penarikan kasebut sajrone rong minggu.

Privasi digayuh kanthi rong cara

1. Rantai ROOT ora ngerti apa-apa babagan transaksi sing digawe lan diterusake ing rantai anak. Informasi babagan sapa sing nyetor lan mbatalake ETH saka Plasma Cash tetep umum.

2. Rantai anak ngidini transaksi anonim nggunakake zk-SNARKs.

Teknologi tumpukan

NodeJS
Redis
Etilium
Sild

Tes

Nalika ngembangake Plasma Cash, kita nyoba kacepetan sistem lan entuk asil ing ngisor iki:

munggah 35 transaksi per detik ditambahake menyang blumbang;
nganti 1 transaksi bisa disimpen ing blok.

Tes ditindakake ing 3 server ing ngisor iki:

1. Intel Core i7-6700 Quad-Core Skylake kalebu. NVMe SSD - 512 GB, 64 GB DDR4 RAM
3 simpul Plasma Cash sing validasi diunggahake.

2. AMD Ryzen 7 1700X Octa-Core "Summit Ridge" (Zen), SATA SSD - 500 GB, 64 GB DDR4 RAM
Ropsten testnet ETH node diangkat.
3 simpul Plasma Cash sing validasi diunggahake.

3. Intel Core i9-9900K Octa-Core kalebu. NVMe SSD - 1 TB, 64 GB DDR4 RAM
1 Plasma Cash node pengajuan diangkat.
3 simpul Plasma Cash sing validasi diunggahake.
Tes diluncurake kanggo nambah transaksi menyang jaringan Plasma Cash.

Total: 10 node Plasma Cash ing jaringan pribadi.

Tes 1

Ana watesan 1 yuta transaksi saben blok. Mulane, 1 yuta transaksi dadi 2 blok (amarga sistem bisa njupuk bagéyan saka transaksi lan ngirim nalika lagi dikirim).

negara wiwitan: pamblokiran pungkasan # 7; 1 yuta transaksi lan token disimpen ing database.

00:00 - wiwitan skrip generasi transaksi
01:37 - 1 yuta transaksi digawe lan ngirim menyang simpul diwiwiti
01:46 - ngirim simpul njupuk 240k transaksi saka blumbang lan formulir blok #8. Kita uga weruh yen 320k transaksi ditambahake menyang blumbang ing 10 detik
01:58 — blok #8 ditandatangani lan dikirim kanggo validasi
02:03 — blok #8 divalidasi lan fungsi `submitBlock` saka kontrak pinter diarani nganggo hash Merkle lan nomer blok
02:10 - skrip demo rampung digunakake, sing ngirim 1 yuta transaksi sajrone 32 detik
02:33 - simpul wiwit nampa informasi sing pamblokiran # 8 ditambahake menyang chain ROOT, lan wiwit nindakake 240k transaksi
02:40 - 240k transaksi dibusak saka blumbang, sing wis ana ing blok #8
02:56 - simpul kirim njupuk sisa 760k transaksi saka blumbang lan wiwit ngitung hash Merkle lan blok tandha #9
03:20 - kabeh node ngemot 1 yuta 240k transaksi lan token
03:35 — blok #9 ditandatangani lan dikirim kanggo validasi menyang simpul liyane
03:41 - ana kesalahan jaringan
04:40 — ngenteni validasi blok #9 wis entek
04:54 - simpul kirim njupuk sisa 760k transaksi saka blumbang lan wiwit ngitung hash Merkle lan blok tandha #9
05:32 — blok #9 ditandatangani lan dikirim kanggo validasi menyang simpul liyane
05:53 - blok #9 wis divalidasi lan dikirim menyang chain ROOT
06:17 - simpul wiwit nampa informasi sing pamblokiran # 9 ditambahake menyang rantai ROOT lan wiwit nindakake transaksi 760k
06:47 — blumbang wis ngresiki transaksi sing ana ing blok #9
09:06 - kabeh node ngemot 2 yuta transaksi lan token

Tes 2

Ana watesan 350k saben blok. Akibaté, kita duwe 3 blok.

negara wiwitan: pamblokiran pungkasan # 9; 2 yuta transaksi lan token disimpen ing database

00:00 — skrip generasi transaksi wis diluncurake
00:44 - 1 yuta transaksi digawe lan ngirim menyang simpul diwiwiti
00:56 - ngirim simpul njupuk 320k transaksi saka blumbang lan formulir blok #10. Kita uga weruh yen 320k transaksi ditambahake menyang blumbang ing 10 detik
01:12 — blok #10 ditandatangani lan dikirim menyang simpul liyane kanggo validasi
01:18 - skrip demo rampung digunakake, sing ngirim 1 yuta transaksi sajrone 34 detik
01:20 - blok #10 wis divalidasi lan dikirim menyang chain ROOT
01:51 - kabeh simpul nampa informasi saka rantai oyod sing diblokir #10 ditambahake lan wiwit ngetrapake transaksi 320k
02:01 - blumbang wis ngresiki kanggo 320k transaksi sing ditambahake kanggo pamblokiran #10
02:15 - kirim simpul njupuk 350k transaksi saka blumbang lan formulir blok #11
02:34 — blok #11 ditandatangani lan dikirim menyang simpul liyane kanggo validasi
02:51 — pamblokiran #11 wis divalidasi lan dikirim menyang chain ROOT
02:55 — simpul pungkasan rampung transaksi saka blok #10
10:59 - transaksi karo pengajuan blok #9 njupuk wektu sing suwe banget ing rantai oyod, nanging rampung lan kabeh simpul nampa informasi babagan iki lan wiwit nindakake transaksi 350k
11:05 - blumbang wis ngresiki kanggo 320k transaksi sing ditambahake kanggo pamblokiran #11
12:10 - kabeh simpul ngemot 1 yuta 670k transaksi lan token
12:17 - kirim simpul njupuk 330k transaksi saka blumbang lan formulir blok #12
12:32 — blok #12 ditandatangani lan dikirim menyang simpul liyane kanggo validasi
12:39 - blok #12 wis divalidasi lan dikirim menyang chain ROOT
13:44 - kabeh simpul nampa informasi saka rantai oyod sing mblokir #12 ditambahake lan wiwit ngetrapake transaksi 330k
14:50 - kabeh node ngemot 2 yuta transaksi lan token

Tes 3

Ing server pisanan lan kaloro, siji simpul validasi diganti karo simpul sing ngirim.

negara wiwitan: pamblokiran pungkasan # 84; 0 transaksi lan token disimpen ing database

00:00 - 3 skrip wis diluncurake sing ngasilake lan ngirim 1 yuta transaksi saben
01:38 - 1 yuta transaksi digawe lan ngirim ngirim simpul #3 diwiwiti
01:50 - ngirim simpul #3 njupuk 330k transaksi saka blumbang lan mbentuk blok #85 (f21). Kita uga weruh yen 350k transaksi ditambahake menyang blumbang ing 10 detik
01:53 - 1 yuta transaksi digawe lan ngirim ngirim simpul #1 diwiwiti
01:50 - ngirim simpul #3 njupuk 330k transaksi saka blumbang lan mbentuk blok #85 (f21). Kita uga weruh yen 350k transaksi ditambahake menyang blumbang ing 10 detik
02:01 — kirim simpul #1 njupuk 250k transaksi saka blumbang lan formulir blok #85 (65e)
02:06 — blok #85 (f21) ditandatangani lan dikirim menyang simpul liyane kanggo validasi
02:08 — skrip demo server #3, sing ngirim 1 yuta transaksi sajrone 30 detik, rampung kerja
02:14 — blok #85 (f21) wis divalidasi lan dikirim menyang chain ROOT
02:19 — blok #85 (65e) ditandatangani lan dikirim menyang simpul liyane kanggo validasi
02:22 - 1 yuta transaksi digawe lan ngirim ngirim simpul #2 diwiwiti
02:27 - pamblokiran # 85 (65e) divalidasi lan dikirim menyang chain ROOT
02:29 — ngirim simpul #2 njupuk 111855 transaksi saka blumbang lan formulir pemblokiran #85 (256).
02:36 — blok #85 (256) ditandatangani lan dikirim menyang simpul liyane kanggo validasi
02:36 — skrip demo server #1, sing ngirim 1 yuta transaksi sajrone 42.5 detik, rampung kerja
02:38 — blok #85 (256) wis divalidasi lan dikirim menyang chain ROOT
03:08 — skrip server #2 rampung digunakake, sing ngirim 1 yuta transaksi sajrone 47 detik
03:38 - kabeh simpul nampa informasi saka chain ROOT sing mblokir #85 (f21), #86(65e), #87(256) ditambahake lan wiwit aplikasi 330k, 250k, 111855 transaksi
03:49 - blumbang wis dibusak ing 330k, 250k, 111855 transaksi sing ditambahake menyang pamblokiran #85 (f21), #86(65e), #87(256)
03:59 — ngirim simpul #1 njupuk 888145 transaksi saka blumbang lan formulir blok #88 (214), ngirim simpul #2 njupuk 750k transaksi saka blumbang lan formulir blok #88 (50a), ngirim simpul #3 njupuk 670k transaksi saka blumbang lan wangun blok #88 (d3b)
04:44 — blok #88 (d3b) ditandatangani lan dikirim menyang simpul liyane kanggo validasi
04:58 — blok #88 (214) ditandatangani lan dikirim menyang simpul liyane kanggo validasi
05:11 — blok #88 (50a) ditandatangani lan dikirim menyang simpul liyane kanggo validasi
05:11 — blok #85 (d3b) wis divalidasi lan dikirim menyang chain ROOT
05:36 — blok #85 (214) wis divalidasi lan dikirim menyang chain ROOT
05:43 - kabeh simpul nampa informasi saka rantai oyot sing mblokir #88 (d3b), #89(214) wis ditambahake lan wiwit ngetrapake transaksi 670k, 750k
06:50 — amarga gagal komunikasi, blok #85 (50a) ora divalidasi
06:55 — kirim simpul #2 njupuk 888145 transaksi saka blumbang lan formulir blok #90 (50a)
08:14 — blok #90 (50a) ditandatangani lan dikirim menyang simpul liyane kanggo validasi
09:04 - blok #90 (50a) wis divalidasi lan dikirim menyang chain ROOT
11:23 - kabeh kelenjar nampa informasi saka chain ROOT sing pemblokiran # 90 (50a) ditambahake, lan wiwiti aplikasi 888145 transaksi. Ing wektu sing padha, server #3 wis ngetrapake transaksi saka blok #88 (d3b), #89(214)
12:11 - kabeh blumbang kosong
13:41 - kabeh simpul server #3 ngemot 3 yuta transaksi lan token
14:35 - kabeh simpul server #1 ngemot 3 yuta transaksi lan token
19:24 - kabeh simpul server #2 ngemot 3 yuta transaksi lan token

alangan

Sajrone pangembangan Plasma Cash, kita nemoni masalah ing ngisor iki, sing mboko sithik dirampungake lan dirampungake:

1. Konflik ing interaksi saka macem-macem fungsi sistem. Contone, fungsi nambah transaksi menyang blumbang mblokir karya ngirim lan validasi pamblokiran, lan kosok balene, kang mimpin kanggo gulung ing kacepetan.

2. Ora langsung jelas carane ngirim transaksi sing akeh banget nalika nyuda biaya transfer data.

3. Ora jelas carane lan ing ngendi kanggo nyimpen data kanggo entuk asil sing dhuwur.

4. Ora jelas carane ngatur jaringan ing antarane simpul, amarga ukuran blok kanthi 1 yuta transaksi mbutuhake udakara 100 MB.

5. Makarya ing mode single-threaded ngilangi sambungan antarane kelenjar nalika petungan dawa kelakon (contone, mbangun wit Merkle lan ngetung hash sawijining).

Kepiye carane kita ngatasi kabeh iki?

Versi pisanan saka simpul Plasma Cash minangka jinis gabungan sing bisa nindakake kabeh ing wektu sing padha: nampa transaksi, ngirim lan validasi pamblokiran, lan nyedhiyakake API kanggo ngakses data. Wiwit NodeJS asli siji-Utas, fungsi pitungan wit Merkle abot ngalangi fungsi nambah transaksi. Kita ndeleng rong pilihan kanggo ngrampungake masalah iki:

1. Bukak sawetara proses NodeJS, sing saben-saben nindakake fungsi tartamtu.

2. Gunakake worker_threads lan pindhah eksekusi bagean kode menyang thread.

Akibaté, kita nggunakake opsi loro ing wektu sing padha: kita dibagi kanthi logis siji simpul dadi 3 bagean sing bisa digunakake kanthi kapisah, nanging ing wektu sing padha bebarengan.

1. Node pengajuan, sing nampa transaksi menyang blumbang lan nggawe pamblokiran.

2. A simpul validasi sing mriksa validitas simpul.

3. API node - nyedhiyakake API kanggo ngakses data.

Ing kasus iki, sampeyan bisa nyambung menyang saben simpul liwat soket unix nggunakake cli.

Kita mindhah operasi abot, kayata ngitung wit Merkle, menyang benang sing kapisah.

Mangkono, kita wis entuk operasi normal kabeh fungsi Plasma Cash bebarengan lan tanpa gagal.

Sawise sistem fungsional, kita wiwit nguji kacepetan lan, sayangé, nampa asil sing ora nyenengake: 5 transaksi per detik lan nganti 000 transaksi saben blok. Aku kudu ngerteni apa sing ditindakake kanthi ora bener.

Kanggo miwiti, kita wiwit nyoba mekanisme komunikasi karo Plasma Cash kanggo ngerteni kemampuan puncak sistem kasebut. Kita nulis sadurunge yen simpul Plasma Cash nyedhiyakake antarmuka soket unix. Wiwitane iku adhedhasar teks. obyek json dikirim nggunakake `JSON.parse()` lan `JSON.stringify()`.

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

Kita ngukur kacepetan transfer obyek kasebut lan nemokake ~ 130k per detik. Kita nyoba ngganti fungsi standar kanggo nggarap json, nanging kinerja ora saya apik. Mesin V8 kudu dioptimalake kanthi apik kanggo operasi kasebut.

Kita nggarap transaksi, token, lan pamblokiran liwat kelas. Nalika nggawe kelas kasebut, kinerja mudhun kaping 2, sing nuduhake yen OOP ora cocog kanggo kita. Aku kudu nulis maneh kabeh menyang pendekatan sejatine sifate fungsi.

Ngrekam ing database

Kaping pisanan, Redis dipilih kanggo panyimpenan data minangka salah sawijining solusi sing paling produktif sing nyukupi kabutuhan kita: panyimpenan kunci-nilai, nggarap tabel hash, set. Kita ngluncurake redis-benchmark lan entuk ~ 80k operasi per detik ing 1 mode pipelining.

Kanggo kinerja dhuwur, kita nyetel Redis luwih apik:

Sambungan soket unix wis digawe.
Kita mateni nyimpen negara menyang disk (kanggo linuwih, sampeyan bisa nyiyapake replika lan nyimpen menyang disk ing Redis sing kapisah).

Ing Redis, blumbang minangka tabel hash amarga kita kudu bisa njupuk kabeh transaksi ing siji pitakon lan mbusak transaksi siji-siji. Kita nyoba nggunakake dhaptar biasa, nanging luwih alon nalika mbongkar kabeh dhaptar.

Nalika nggunakake NodeJS standar, perpustakaan Redis entuk kinerja 18k transaksi per detik. Kacepetan mudhun 9 kaping.

Wiwit pathokan nuduhake kita kemungkinan cetha 5 kaping luwih, kita wiwit ngoptimalake. Kita ngganti perpustakaan dadi ioredis lan entuk kinerja 25k per detik. Kita nambahake transaksi siji-siji kanthi nggunakake printah `hset`. Dadi, kita nggawe akeh pitakon ing Redis. Ide kasebut muncul kanggo nggabungake transaksi dadi batch lan dikirim nganggo siji printah `hmset`. Asil punika 32k per detik.

Kanggo sawetara alasan, sing bakal kita jelasake ing ngisor iki, kita nggarap data nggunakake `Buffer` lan, kayane, yen sampeyan ngowahi dadi teks (`buffer.toString('hex')`) sadurunge nulis, sampeyan bisa entuk tambahan. kinerja. Mangkono, kacepetan tambah dadi 35k per detik. Ing wayahe, kita mutusake kanggo nundha optimasi luwih lanjut.

Kita kudu ngalih menyang protokol binar amarga:

1. Sistem kasebut asring ngetung hash, teken, lan liya-liyane, lan iki mbutuhake data ing `Buffer.

2. Nalika dikirim ing antarane layanan, data binar bobote kurang saka teks. Contone, nalika ngirim blok karo 1 yuta transaksi, data ing teks bisa njupuk luwih saka 300 megabyte.

3. Ganti data sing terus-terusan mengaruhi kinerja.

Mulane, kita njupuk minangka basis protokol binar kita dhewe kanggo nyimpen lan ngirim data, dikembangaké ing basis saka perpustakaan `binary-data` apik.

Akibaté, kita entuk struktur data ing ngisor iki:

- Transaksi

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

Kanthi prentah biasanipun `BD.encode(block, Protocol).slice();` lan `BD.decode(buffer, Protocol)` kita ngowahi data dadi `Buffer` kanggo disimpen ing Redis utawa diterusake menyang simpul liyane lan njupuk data bali.

Kita uga duwe 2 protokol binar kanggo nransfer data antarane layanan:

- Protokol kanggo interaksi karo Plasma Node liwat soket 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)
  }
  ```

ing pundi:

`tipe` - tumindak sing bakal ditindakake, contone, 1 - sendTransaction, 2 - getTransaction;
`muatan` - data sing kudu dikirim menyang fungsi sing cocog;
`pesenId` - id pesen supaya respon bisa dikenali.

- Protokol kanggo interaksi antarane node

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

ing pundi:

`kode` - kode pesen, contone 6 - PREPARE_NEW_BLOCK, 7 - BLOCK_VALID, 8 - BLOCK_COMMIT;
`versionProtocol` - versi protokol, wiwit kelenjar karo versi beda bisa wungu ing jaringan lan padha bisa digunakake beda;
`seq` - pengenal pesen;
`countChunk` и `nomer klepon` perlu kanggo pamisah pesen gedhe;
`dawa` и `muatan` dawa lan data dhewe.

Wiwit kita wis ngetik data, sistem pungkasan luwih cepet tinimbang perpustakaan `rlp` Ethereum. Sayange, kita durung bisa nolak, amarga kudu ngrampungake kontrak cerdas, sing bakal ditindakake ing mangsa ngarep.

Yen kita bisa nggayuh kacepetan 35 000 transaksi per detik, kita uga kudu proses ing wektu optimal. Wiwit wektu pambentukan blok kira-kira njupuk 30 detik, kita kudu kalebu ing blok kasebut 1 000 000 transaksi, kang tegese ngirim liyane 100 MB data.

Kaping pisanan, kita nggunakake perpustakaan `ethereumjs-devp2p` kanggo komunikasi antarane simpul, nanging ora bisa nangani akeh data. Akibaté, kita nggunakake perpustakaan `ws` lan ngatur ngirim data binar liwat websocket. Mesthi, kita uga nemoni masalah nalika ngirim paket data gedhe, nanging kita dibagi dadi potongan lan saiki masalah kasebut ilang.

Uga mbentuk wit Merkle lan ngitung hash 1 000 000 transaksi mbutuhake babagan 10 detik pitungan terus-terusan. Sajrone wektu iki, sambungan karo kabeh kelenjar bisa rusak. Diputusake kanggo mindhah pitungan iki menyang thread sing kapisah.

Kesimpulan:

Nyatane, panemuan kita ora anyar, nanging sawetara sebab akeh ahli lali babagan kasebut nalika ngembangake.

Nggunakake Pemrograman Fungsional tinimbang Pemrograman Berorientasi Objek nambah produktivitas.
Monolith luwih elek tinimbang arsitektur layanan kanggo sistem NodeJS sing produktif.
Nggunakake `worker_threads` kanggo komputasi abot nambah respon sistem, utamane nalika nangani operasi i/o.
soket unix luwih stabil lan luwih cepet tinimbang panjalukan http.
Yen sampeyan kudu nransfer data gedhe liwat jaringan kanthi cepet, luwih becik nggunakake websockets lan ngirim data binar, dibagi dadi potongan, sing bisa diterusake yen ora teka, banjur digabungake dadi siji pesen.

Kita ngajak sampeyan ngunjungi GitHub proyek: https://github.com/opporty-com/Plasma-Cash/tree/new-version

Artikel iki ditulis bebarengan dening Alexander Nashivan, pangembang senior Solusi Clever Inc.

Source: www.habr.com

Tes Umum: Solusi kanggo Privasi lan Skalabilitas ing Ethereum