Tes publik: solusi untuk privasi dan skalabilitas dalam Ethereum

Blockchain adalah teknologi inovatif yang menjanjikan untuk meningkatkan banyak bidang kehidupan manusia. Ini mentransfer proses dan produk nyata ke ruang digital, memastikan kecepatan dan keandalan transaksi keuangan, mengurangi biaya mereka, dan juga memungkinkan Anda untuk membuat aplikasi DAPP modern menggunakan kontrak pintar dalam jaringan desentralisasi.

Mengingat banyak keuntungan dan beragam penggunaan blockchain, mungkin aneh bahwa teknologi yang menjanjikan ini belum menembus semua sektor. Masalahnya adalah bahwa blockchain modern yang terdesentralisasi tidak memiliki skalabilitas. Ethereum memproses sekitar 20 transaksi per detik, yang tidak cukup untuk memenuhi kebutuhan bisnis yang dinamis saat ini. Pada saat yang sama, perusahaan yang menggunakan teknologi blockchain tidak berani meninggalkan Ethereum karena tingkat perlindungan yang tinggi terhadap peretasan dan kegagalan jaringan.

Untuk memastikan desentralisasi, keamanan, dan skalabilitas pada blockchain, sehingga menyelesaikan Skalabilitas Trilemma, tim pengembangan Opporty menciptakan Plasma Cash - rantai anak yang terdiri dari kontrak pintar dan jaringan pribadi berdasarkan Node.js, yang secara berkala memindahkan negara ke rantai akar ( Ethereum).

Proses utama di Plasma Cash

1. Pengguna memanggil fungsi kontrak pintar `setoran`, mentransfer jumlah dalam ETH ke dalamnya, yang ingin dimasukkan ke dalam token Kas Plasma. Fungsi kontrak pintar membuat token dan menghasilkan acara tentang hal itu.

2. Node tunai Plasma yang dilanggankan pada peristiwa-peristiwa dalam kontrak pintar menerima peristiwa tentang penciptaan setoran dan menambahkan transaksi tentang pembuatan token ke kumpulan.

3. Secara berkala, simpul Cash Plasma khusus mengambil semua transaksi dari kumpulan (hingga 1 juta) dan membentuk blok darinya, menghitung pohon Merkle dan, dengan demikian, hash. Blok ini dikirim ke node lain untuk verifikasi. Node memeriksa apakah hasle Merkle valid, apakah transaksi valid (misalnya, jika pengirim token adalah pemiliknya). Setelah memverifikasi blok, node memanggil fungsi `submitBlock` dari kontrak pintar, yang menyimpan nomor dan hash Merkle dari blok dalam rantai jejak. Kontrak yang cerdas menghasilkan acara tentang penambahan blok yang berhasil. Transaksi dihapus dari kumpulan.

4. Node yang menerima acara tentang penyerahan blok mulai menerapkan transaksi yang ditambahkan ke blok.

5. Pada titik tertentu, pemilik (atau bukan pemilik) token ingin menariknya dari Plasma Cash. Untuk melakukan ini, ia memanggil fungsi `startExit`, menyampaikan informasi tentang 2 transaksi terakhir pada token ke dalamnya, yang mengkonfirmasi bahwa ia adalah pemilik token. Kontrak pintar, menggunakan hasle Merkle, memeriksa transaksi dalam blok dan mengirimkan token ke output, yang akan terjadi dalam dua minggu.

6. Jika operasi penarikan token telah terjadi dengan pelanggaran (token dihabiskan setelah dimulainya prosedur penarikan atau token sudah menjadi orang asing sebelum penarikan), pemilik token dapat menyangkal penarikan dalam waktu dua minggu.

Privasi dicapai dengan dua cara.

1. Rantai root tidak tahu apa-apa tentang transaksi yang dibentuk dan diteruskan di dalam rantai anak. Informasi tetap mengenai siapa yang memulai dan menarik ETH ke / dari Plasma Cash.

2. Rantai anak memungkinkan Anda untuk mengatur transaksi anonim menggunakan zk-SNARKs.

Tumpukan teknologi

• NodeJS
• Redis
• Ethereum
• Soild

Pengujian

Ketika mengembangkan Plasma Cash, kami menguji kecepatan sistem dan mendapatkan hasil berikut:

• hingga 35.000 transaksi per detik ditambahkan ke kumpulan;
• hingga 1.000.000 transaksi dapat disimpan di blok.

Pengujian dilakukan pada 3 server berikut:

1. Intel Core i7-6700 Quad-Core Skylake termasuk. NVMe SSD - 512 GB, 64 GB DDR4 RAM
3 simpul Cash Plasma yang divalidasi dimunculkan.

2. AMD Ryzen 7 1700X Octa-Core "Summit Ridge" (Zen), SSD SATA - 500 GB, RAM DDR4 64 GB
Simpul ETH testop Ropsten dinaikkan.
3 simpul Cash Plasma yang divalidasi dimunculkan.

3. Intel Core i9-9900K Octa-Core termasuk. NVMe SSD - 1 TB, RAM DDR4 64 GB
1 Kirim Plasma Kas simpul dinaikkan.
3 simpul Cash Plasma yang divalidasi dimunculkan.
Tes diluncurkan untuk menambahkan transaksi ke jaringan Kas Plasma.

Total: 10 Node tunai Plasma dalam jaringan pribadi.

Tes 1

Ada batas 1 juta transaksi per blok. Oleh karena itu, 1 juta transaksi terbagi dalam 2 blok (karena sistem berhasil mengambil bagian dari transaksi dan mengajukan sementara mereka dikirim).


Status awal: blok terakhir # 7; 1 juta transaksi dan token disimpan dalam basis data.

00:00 - mulai skrip pembuatan transaksi
01:37 - 1 juta transaksi telah dibuat dan pengiriman ke node dimulai
01:46 - node kirim mengambil 240k transaksi dari pool dan membentuk blok # 8. Kami juga melihat bahwa transaksi 320k ditambahkan ke kumpulan dalam 10 detik
01:58 - blok # 8 ditandatangani dan dikirim untuk validasi
02:03 - blok # 8 divalidasi dan fungsi `submitBlock` dari kontrak pintar dengan hash dan nomor blok Merkle disebut
02:10 - skrip demo selesai bekerja, yang mengirim 1 juta transaksi dalam 32 detik
02:33 - node mulai menerima informasi bahwa blok # 8 ditambahkan ke rantai root, dan mulai melakukan 240k transaksi
02:40 - 240k transaksi dihapus dari kumpulan, yang sudah ada di blok # 8
02:56 - submit node mengambil sisa transaksi 760k dari pool dan mulai menghitung hash Merkle dan menandatangani blok # 9
03:20 - semua node berisi 1mln 240r transaksi dan token
03:35 - blok # 9 ditandatangani dan dikirim untuk validasi ke node lain
03:41 - kesalahan jaringan telah terjadi
04:40 - oleh batas waktu, menunggu validasi blok # 9 telah berhenti
04:54 - node kirim mengambil sisa transaksi 760k dari pool dan mulai menghitung hash Merkle dan menandatangani blok # 9
05:32 - blok # 9 ditandatangani dan dikirim untuk validasi ke node lain
05:53 - blok # 9 divalidasi dan dikirim ke rantai root
06:17 - node mulai menerima informasi bahwa blok # 9 ditambahkan ke rantai root dan mulai melakukan transaksi 760k
06:47 - kumpulan dibersihkan dari transaksi yang ada di blok # 9
09:06 - semua node berisi 2 juta transaksi dan token

Tes 2

Ada batas 350rb per blok. Hasilnya, kami memiliki 3 blok.


Status awal: blok terakhir # 9; 2 juta transaksi dan token disimpan dalam database

00:00 - skrip pembuatan transaksi sudah berjalan
00:44 - 1 juta transaksi telah dibuat dan pengiriman ke node dimulai
00:56 - node kirim mengambil 320k transaksi dari pool dan membentuk blok # 10. Kami juga melihat bahwa transaksi 320k ditambahkan ke kumpulan dalam 10 detik
01:12 - blok # 10 ditandatangani dan dikirim ke node lain untuk validasi
01:18 - skrip demo selesai bekerja, yang mengirim 1 juta transaksi dalam 34 detik
01:20 - blok # 10 divalidasi dan dikirim ke rantai root
01:51 - semua node menerima informasi dari rantai root yang memblokir # 10 telah ditambahkan, dan mereka mulai menerapkan transaksi 320k
02:01 - kumpulan itu dihapus untuk transaksi 320k yang ditambahkan ke blok # 10
02:15 - kirim node mengambil 350 ribu transaksi dari pool dan membentuk blok # 11
02:34 - blok # 11 ditandatangani dan dikirim ke node lain untuk validasi
02:51 - blok # 11 divalidasi dan dikirim ke rantai root
02:55 - simpul terakhir melakukan transaksi dari blok # 10
10:59 - waktu yang sangat lama dalam rantai root transaksi dieksekusi dengan pengiriman blok # 9, tetapi selesai dan semua node menerima informasi tentang ini dan mulai menjalankan 350k transaksi
11:05 - kumpulan itu dihapus untuk transaksi 320k yang ditambahkan ke blok # 11
12:10 - semua node berisi 1 juta 670 ribu transaksi dan token
12:17 - kirim node mengambil 330k transaksi dari pool dan membentuk blok # 12
12:32 - blok # 12 ditandatangani dan dikirim ke node lain untuk validasi
12:39 - blok # 12 divalidasi dan dikirim ke rantai root
13:44 - semua node menerima informasi dari rantai root yang memblokir # 12 telah ditambahkan dan mulai menerapkan transaksi 330k
14:50 - semua node berisi 2 juta transaksi dan token

Tes 3

Di server pertama dan kedua, satu simpul validasi diganti dengan simpul pengiriman.


Status awal: blok terakhir # 84; 0 transaksi dan token disimpan dalam basis data

00:00 - 3 skrip diluncurkan yang menghasilkan dan mengirim 1 juta transaksi
01:38 - 1 juta transaksi telah dibuat dan pengiriman untuk mengirimkan simpul # 3 dimulai
01:50 - kirim simpul # 3 mengambil 330k transaksi dari kumpulan dan membentuk blok # 85 (f21). Kami juga melihat bahwa transaksi 350 ribu ditambahkan ke kumpulan dalam 10 detik
01:53 - 1 juta transaksi telah dibuat dan pengiriman untuk mengirimkan simpul # 1 dimulai
01:50 - kirim simpul # 3 mengambil 330k transaksi dari kumpulan dan membentuk blok # 85 (f21). Kami juga melihat bahwa transaksi 350 ribu ditambahkan ke kumpulan dalam 10 detik
02:01 - kirim node # 1 mengambil 250k transaksi dari pool dan membentuk blok # 85 (65e)
02:06 - blok # 85 (f21) ditandatangani dan dikirim ke node lain untuk divalidasi
02:08 - skrip demo server # 3 telah selesai berfungsi, yang mengirim transaksi 1mln dalam 30 detik
02:14 - blok # 85 (f21) divalidasi dan dikirim ke rantai root
02:19 - blok # 85 (65e) ditandatangani dan dikirim ke node lain untuk divalidasi
02:22 - 1 juta transaksi telah dibuat dan pengiriman untuk mengirimkan simpul # 2 dimulai
02:27 - blok # 85 (65e) divalidasi dan dikirim ke rantai root
02:29 - kirimkan simpul # 2 dari transaksi pool 111855 dan bentuk blok # 85 (256).
02:36 - blok # 85 (256) ditandatangani dan dikirim ke node lain untuk divalidasi
02:36 - skrip demo server # 1 selesai bekerja, yang mengirim transaksi 1mln dalam 42,5 detik
02:38 - blok # 85 (256) divalidasi dan dikirim ke rantai root
03:08 - skrip server # 2, yang mengirim 1 juta transaksi dalam 47 detik, selesai bekerja
03:38 - semua node menerima informasi dari rantai root bahwa blok # 85 (f21), # 86 (65e), # 87 (256) telah ditambahkan dan mulai menerapkan transaksi 330k, 250k, 111855
03:49 - kolam dibersihkan pada 330k, 250k, 111855 transaksi yang ditambahkan ke blok # 85 (f21), # 86 (65e), # 87 (256)
03:59 - kirim simpul # 1 ambil dari pool 888145 transaksi dan bentuk blok # 88 (214), kirim simpul # 2 ambil dari pool 750k transaksi dan bentuk blok # 88 (50a), kirim simpul # 3 ambil dari pool 670k transaksi dan formulir blok # 88 (d3b)
04:44 - blok # 88 (d3b) ditandatangani dan dikirim ke node lain untuk validasi
04:58 - blok # 88 (214) ditandatangani dan dikirim ke node lain untuk divalidasi
05:11 - blok # 88 (50a) ditandatangani dan dikirim ke node lain untuk validasi
05:11 - blok # 85 (d3b) divalidasi dan dikirim ke rantai root
05:36 - blok # 85 (214) divalidasi dan dikirim ke rantai root
05:43 - semua node menerima informasi dari rantai root yang memblokir # 88 (d3b), # 89 (214) ditambahkan dan mulai menerapkan transaksi 670k, 750k
06:50 - karena pemutusan, blok # 85 (50a) tidak divalidasi
06:55 - kirim node # 2 mengambil 888145 transaksi dari pool dan membentuk blok # 90 (50a)
08:14 - blok # 90 (50a) ditandatangani dan dikirim ke node lain untuk divalidasi
09:04 - blok # 90 (50a) divalidasi dan dikirim ke rantai root
11:23 - semua node menerima informasi dari rantai root yang memblokir # 90 (50a) ditambahkan, dan 888145 transaksi mulai diterapkan. Pada saat yang sama, server # 3 telah lama menerapkan transaksi dari blok # 88 (d3b), # 89 (214)
12:11 - semua kolam kosong
13:41 - semua node server # 3 berisi 3 juta transaksi dan token
14:35 - semua node server # 1 berisi 3 juta transaksi dan token
19:24 - semua node server # 2 berisi 3 juta transaksi dan token

Rintangan

Selama pengembangan Plasma Cash, kami menghadapi masalah berikut, yang secara bertahap kami pecahkan dan selesaikan:

1. Konflik interaksi berbagai fungsi sistem. Misalnya, fungsi menambahkan transaksi ke kumpulan memblokir pengiriman dan validasi blok, dan sebaliknya, yang menyebabkan penurunan kecepatan.

2. Tidak segera jelas cara mengirim sejumlah besar transaksi dan pada saat yang sama meminimalkan biaya transfer data.

3. Tidak jelas bagaimana dan di mana menyimpan data untuk mencapai hasil yang tinggi.

4. Tidak jelas bagaimana mengatur jaringan antar node, karena ukuran blok dengan 1 juta transaksi membutuhkan sekitar 100 MB.

5. Bekerja dalam mode single-threaded memutus koneksi antara node ketika perhitungan panjang terjadi (misalnya, membangun pohon Merkle dan menghitung hash-nya).

Bagaimana kita menangani semua ini?

Versi pertama dari simpul Plasma Cash adalah sejenis gabungan yang dapat melakukan semuanya pada saat yang sama: menerima transaksi, mengirim dan memvalidasi blok, menyediakan API untuk mengakses data. Karena NodeJS pada mulanya single-threaded, fungsi perhitungan Merkle tree yang berat memblokir fungsi add transaksi. Kami melihat dua opsi untuk menyelesaikan masalah ini:

1. Jalankan beberapa proses NodeJS, yang masing-masing menjalankan fungsi tertentu.

2. Gunakan pekerja_lebar dan letakkan eksekusi kode ke utas.

Sebagai hasilnya, kami menggunakan kedua opsi pada saat yang sama: secara logis membagi satu simpul menjadi 3 bagian, yang dapat bekerja secara terpisah, tetapi pada saat yang sama secara serempak

1. Kirim simpul yang menerima transaksi ke kumpulan dan membuat blok.

2. Memvalidasi node yang memverifikasi validitas node.

3. Node API - menyediakan API untuk mengakses data.

Pada saat yang sama, Anda dapat terhubung ke setiap node melalui soket unix menggunakan cli.

Operasi berat, seperti perhitungan pohon Merkle, kami lakukan dalam aliran terpisah.

Dengan demikian, kami mencapai operasi normal semua fungsi Cash Plasma secara bersamaan dan tanpa kegagalan.

Segera setelah sistem berfungsi, kami mulai menguji kecepatan dan, sayangnya, mendapat hasil yang tidak memuaskan: 5.000 transaksi per detik dan hingga 50.000 transaksi dalam satu blok. Saya harus mencari tahu apa yang diterapkan dengan tidak benar.

Untuk mulai dengan, kami mulai menguji mekanisme komunikasi dengan Plasma Cash untuk mengetahui kemampuan puncak sistem. Sebelumnya kami menulis bahwa simpul Plasma Cash menyediakan antarmuka soket unix. Itu awalnya tekstual. objek json dikirim menggunakan `JSON.parse ()` dan `JSON.stringify ()`.

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

Kami mengukur kecepatan transfer objek tersebut dan menerima ~ 130k per detik. Mereka mencoba mengganti fungsi standar dengan json, tetapi kinerjanya tidak membaik. Harus ada mesin V8 yang dioptimalkan dengan baik untuk operasi ini.

Bekerja dengan transaksi, token, blok dilakukan melalui kelas. Saat membuat kelas seperti itu, kinerja turun 2 kali lipat, yang menunjukkan: OOP tidak cocok untuk kita. Saya harus menulis ulang semuanya dengan pendekatan fungsional murni.

Menulis ke basis data

Awalnya, Redis dipilih untuk penyimpanan data sebagai salah satu solusi paling produktif yang memenuhi persyaratan kami: penyimpanan nilai kunci, bekerja dengan tabel hash, dan banyak lagi. Kami meluncurkan redis-benchmark dan mendapat ~ 80k operasi per detik dalam 1 mode pipelining.

Untuk kinerja tinggi, kami menyetel Redis lebih halus:

• Membuat koneksi soket unix.
• Nonaktifkan status penyimpanan ke disk (untuk keandalan, Anda dapat mengonfigurasi replika dan sudah menyimpan ke disk dalam Redis terpisah).

Di Redis, kumpulan adalah tabel hash, karena kita memerlukan kemampuan untuk menerima semua transaksi dalam satu permintaan dan menghapus transaksi satu per satu. Kami mencoba menggunakan daftar reguler, tetapi ia bekerja lebih lambat ketika membongkar seluruh daftar.

Menggunakan perpustakaan NodeJS standar, perpustakaan Redis mencapai 18k transaksi per kinerja kedua. Kecepatan turun 9 kali.

Karena tolok ukur menunjukkan kepada kami kemungkinan dengan jelas 5 kali lebih banyak, mereka mulai mengoptimalkan. Kami mengubah perpustakaan menjadi ioredis dan mendapatkan kinerja 25k per detik. Kami menambahkan transaksi satu per satu menggunakan perintah `hset`. Jadi, kami menghasilkan banyak permintaan di Redis. Ada ide untuk menggabungkan transaksi menjadi bundel dan mengirimkannya dengan satu perintah hmset. Hasilnya adalah 32rb per detik.

Karena beberapa alasan, yang akan dijelaskan di bawah ini, kami bekerja dengan data menggunakan `Buffer` dan, ternyata, jika Anda menerjemahkannya ke dalam teks (` buffer.toString ('hex') `) sebelum menulis, Anda bisa mendapatkan kinerja tambahan. Dengan demikian, kecepatannya ditingkatkan menjadi 35k per detik. Saat ini, kami memutuskan untuk menunda pengoptimalan lebih lanjut.

Kami harus beralih ke protokol biner karena:

1. Sistem sering menghitung hash, tanda tangan, dll., Dan untuk ini diperlukan data dalam `Buffer.

2. Saat mentransfer antar layanan, data biner memiliki berat kurang dari teks. Misalnya, saat mengirim blok dengan 1 juta transaksi, data dalam teks dapat menempati lebih dari 300 megabita.

3. Konversi data berkelanjutan mempengaruhi kinerja.

Oleh karena itu, kami menggunakan protokol biner kami sendiri untuk menyimpan dan mentransmisikan data, yang dikembangkan atas dasar perpustakaan data biner yang luar biasa.

Akibatnya, kami memiliki struktur data berikut:

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

- Blokir

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

Dengan perintah biasa `BD.encode (blok, Protokol) .slice ();` dan `BD.decode (buffer, Protocol)`, kami mengonversi data menjadi `Buffer` untuk menyimpannya ke Redis atau mentransfernya ke simpul lain dan mengambil data kembali.

Kami juga memiliki 2 protokol biner untuk mentransfer data antar layanan:

- Protokol untuk berinteraksi dengan Plasma Node melalui 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) } ``` 

dimana:

• `type` - tindakan yang harus dilakukan, misalnya, 1 - sendTransaction, 2 - getTransaction;
• `payload` - data yang akan ditransfer ke fungsi yang sesuai;
• `messageId` - id pesan sehingga respons dapat diidentifikasi.

- Protokol interaksi antar 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) } ``` 

dimana:

• `code` - kode pesan, misalnya 6 - PREPARE_NEW_BLOCK, 7 - BLOCK_VALID, 8 - BLOCK_COMMIT;
• `versionProtocol` - versi protokol, karena node dengan versi yang berbeda dapat dimunculkan di jaringan dan mereka dapat bekerja dengan cara yang berbeda;
• `seq` - pengidentifikasi pesan;
• Diperlukan `countChunk` dan` chunkNumber` untuk membagi pesan-pesan besar;
• `length` dan` payload` panjang dan data itu sendiri.

Karena kita mengetik data sebelumnya, sistem final jauh lebih cepat daripada perpustakaan `rlp` dari Ethereum. Sayangnya, kami belum bisa menolaknya, karena itu perlu untuk menyelesaikan kontrak pintar, yang kami rencanakan untuk dilakukan di masa depan.

Jika kami berhasil mencapai kecepatan 35.000 transaksi per detik, kami juga perlu memprosesnya dalam waktu yang optimal. Karena perkiraan waktu pembentukan blok memakan waktu 30 detik, kami perlu memasukkan 1.000.000 transaksi di blok tersebut, yang berarti mengirim lebih dari 100 mb data.

Awalnya, kami menggunakan pustaka `ethereumjs-devp2p` untuk mengkomunikasikan node, tetapi tidak bisa mengatasi begitu banyak data. Sebagai hasilnya, kami menggunakan pustaka `ws` dan mengatur transfer data biner di websocket. Tentu saja, kami juga mengalami masalah saat mengirim paket data besar, tetapi kami membaginya menjadi beberapa bagian dan sekarang tidak ada masalah seperti itu.

Juga, pembentukan pohon Merkle dan perhitungan hash dari 1.000.000 transaksi membutuhkan sekitar 10 detik perhitungan berkelanjutan. Selama waktu ini, koneksi dengan semua node berhasil terputus. Diputuskan untuk mentransfer perhitungan ini ke utas terpisah.

Kesimpulan:

Faktanya, temuan kami bukanlah hal baru, tetapi karena beberapa alasan, banyak ahli melupakannya selama pengembangan.

• Menggunakan Pemrograman Fungsional bukan Pemrograman Berorientasi Objek meningkatkan kinerja.
• Monolith lebih buruk daripada arsitektur layanan untuk sistem produksi di NodeJS.
• Menggunakan `worker_threads` untuk komputasi berat meningkatkan responsif sistem, terutama ketika bekerja dengan operasi i / o.
• soket unix lebih stabil dan lebih cepat dari permintaan http.
• Jika Anda perlu dengan cepat mentransfer data besar melalui jaringan, lebih baik menggunakan soket web dan mengirim data biner, dipecah menjadi beberapa bagian, yang dapat diteruskan jika tidak mencapai, dan kemudian digabung menjadi satu pesan.

Kami mengundang Anda untuk mengunjungi proyek GitHub : https://github.com/opporty-com/Plasma-Cash/tree/new-version

Artikel ini ditulis bersama oleh Alexander Nashivan , pengembang senior Clever Solution Inc.