🥇İctimai Test: Ethereum-da Məxfilik və Ölçəklənmə üçün Həll

Bloccain insan həyatının bir çox sahələrini təkmilləşdirməyi vəd edən innovativ texnologiyadır. O, real prosesləri və məhsulları rəqəmsal məkana köçürür, maliyyə əməliyyatlarının sürətini və etibarlılığını təmin edir, onların maya dəyərini azaldır, həmçinin mərkəzləşdirilməmiş şəbəkələrdə smart müqavilələrdən istifadə edərək müasir DAPP proqramlarını yaratmağa imkan verir.

Blockchain-in bir çox üstünlüklərini və müxtəlif tətbiqlərini nəzərə alsaq, bu perspektivli texnologiyanın hələ də hər sənayedə öz yerini tutmaması təəccüblü görünə bilər. Problem ondadır ki, müasir mərkəzləşdirilməmiş blokçeynlərdə miqyaslanma qabiliyyəti yoxdur. Ethereum saniyədə təxminən 20 əməliyyat həyata keçirir ki, bu da günümüzün dinamik bizneslərinin ehtiyaclarını ödəmək üçün kifayət deyil. Eyni zamanda, blokçeyn texnologiyasından istifadə edən şirkətlər, sındırma və şəbəkə uğursuzluqlarından yüksək dərəcədə qorunduğuna görə Ethereum-dan imtina etməkdə tərəddüd edirlər.

Blockchain-də mərkəzsizləşdirmə, təhlükəsizlik və miqyaslılığı təmin etmək, beləliklə, inkişaf qrupu Scalability Trilemma-nı həll etmək üçün Fürsət Ağıllı müqavilədən və Node.js-ə əsaslanan özəl şəbəkədən ibarət törəmə zəncir olan Plasma Cash yaratdı, bu da öz vəziyyətini vaxtaşırı kök zəncirinə (Ethereum) köçürür.

Plazma Cash-də əsas proseslər

1. İstifadəçi ağıllı müqavilə funksiyasını “depozit” adlandırır və ona Plasma Cash tokeninə depozit etmək istədiyi ETH məbləğini ötürür. Ağıllı müqavilə funksiyası əlamət yaradır və bu barədə hadisə yaradır.

2. Ağıllı müqavilə tədbirlərinə abunə olan Plasma Cash qovşaqları depozit yaratmaq haqqında hadisə alır və hovuza token yaratmaq haqqında əməliyyat əlavə edir.

3. Dövri olaraq xüsusi Plasma Cash qovşaqları hovuzdan bütün əməliyyatları (1 milyona qədər) götürür və onlardan blok təşkil edir, Merkle ağacını və müvafiq olaraq hash hesablayır. Bu blok yoxlama üçün digər qovşaqlara göndərilir. Düyünlər Merkle hashının etibarlı olub olmadığını və əməliyyatların etibarlı olub olmadığını yoxlayır (məsələn, tokenin göndəricisinin onun sahibi olub-olmaması). Bloku yoxladıqdan sonra qovşaq ağıllı müqavilənin “submitBlock” funksiyasını çağırır ki, bu da blok nömrəsini və Merkle hashını kənar zəncirdə saxlayır. Ağıllı müqavilə blokun uğurlu əlavə edilməsini göstərən bir hadisə yaradır. Əməliyyatlar hovuzdan silinir.

4. Blok təqdimetmə hadisəsini alan qovşaqlar bloka əlavə edilmiş əməliyyatları tətbiq etməyə başlayır.

5. Bir anda tokenin sahibi (və ya sahibi olmayan) onu Plazma Cash-dən çıxarmaq istəyir. Bunun üçün o, `startExit` funksiyasını çağırır, ona tokenin sahibi olduğunu təsdiqləyən son 2 tranzaksiya haqqında məlumat verir. Ağıllı müqavilə, Merkle heshindən istifadə edərək, bloklarda əməliyyatların mövcudluğunu yoxlayır və iki həftə ərzində baş verəcək tokeni geri götürməyə göndərir.

6. Tokenin çıxarılması əməliyyatı pozuntularla baş veribsə (token çıxarılması proseduru başlandıqdan sonra xərclənib və ya token çəkilməzdən əvvəl artıq başqasının idi), tokenin sahibi iki həftə ərzində çıxarılmasını təkzib edə bilər.

Məxfilik iki yolla əldə edilir

1. Kök zəncir uşaq zəncirində yaradılan və yönləndirilən əməliyyatlar haqqında heç nə bilmir. Plazma Cash-dən ETH-ni kimin yerləşdirdiyi və çıxardığı barədə məlumat açıq olaraq qalır.

2. Uşaq zənciri zk-SNARK-lardan istifadə edərək anonim əməliyyatlara imkan verir.

Texnologiya yığını

NodeJS
Redis
Eterium
Torpaq

Test

Plazma Nağd pulu inkişaf etdirərkən sistemin sürətini sınaqdan keçirdik və aşağıdakı nəticələri əldə etdik:

hovuza saniyədə 35-ə qədər əməliyyat əlavə edilir;
blokda 1-a qədər əməliyyat saxlanıla bilər.

Testlər aşağıdakı 3 serverdə aparılmışdır:

1. Intel Core i7-6700 Quad-Core Skylake daxil olmaqla. NVMe SSD – 512 GB, 64 GB DDR4 RAM
3 təsdiqləyici Plazma Pul qovşağı qaldırıldı.

2. AMD Ryzen 7 1700X Octa-Core “Summit Ridge” (Zen), SATA SSD – 500 GB, 64 GB DDR4 RAM
Ropsten testnet ETH qovşağı qaldırıldı.
3 təsdiqləyici Plazma Pul qovşağı qaldırıldı.

3. Intel Core i9-9900K Octa-Core daxil olmaqla. NVMe SSD – 1 TB, 64 GB DDR4 RAM
1 Plazma Nağd pul göndərmə qovşağı qaldırıldı.
3 təsdiqləyici Plazma Pul qovşağı qaldırıldı.
Plasma Cash şəbəkəsinə tranzaksiyaların əlavə edilməsi üçün sınaq başladıldı.

Ümumi: Şəxsi şəbəkədə 10 Plazma Pul qovşağı.

Test 1

Blok başına 1 milyon əməliyyat limiti var. Buna görə də, 1 milyon əməliyyat 2 bloka düşür (çünki sistem əməliyyatların bir hissəsini götürməyi və göndərilərkən təqdim etməyi bacarır).

İlkin vəziyyət: son blok #7; Məlumat bazasında 1 milyon əməliyyat və token saxlanılır.

00:00 — əməliyyat generasiya skriptinin başlanması
01:37 - 1 milyon tranzaksiya yaradıldı və qovşaqlara göndərilmə başladı
01:46 — təqdim node hovuzdan 240k əməliyyat apardı və 8 nömrəli bloku formalaşdırır. 320 saniyə ərzində hovuza 10k əməliyyatın əlavə olunduğunu da görürük
01:58 — №8 blok imzalanır və təsdiq üçün göndərilir
02:03 — 8 nömrəli blok təsdiqlənir və ağıllı müqavilənin “göndərmə bloku” funksiyası Merkle hash və blok nömrəsi ilə çağırılır.
02:10 — 1 saniyə ərzində 32 milyon əməliyyat göndərən demo skript işləməyi başa çatdırdı
02:33 - qovşaqlar 8 nömrəli blokun kök zəncirinə əlavə edildiyi barədə məlumat almağa başladı və 240k əməliyyat həyata keçirməyə başladı.
02:40 - 240-ci blokda olan 8k əməliyyat hovuzdan silindi
02:56 — Göndərmə nodu hovuzdan qalan 760k əməliyyatı götürdü və Merkle hashını hesablamağa və №9 imza blokuna başladı.
03:20 - bütün qovşaqlarda 1 milyon 240k əməliyyat və token var
03:35 — blok №9 imzalanır və digər qovşaqlara təsdiq üçün göndərilir
03:41 - şəbəkə xətası baş verdi
04:40 — №9 blokun təsdiqlənməsini gözləmə vaxtı bitdi
04:54 — Göndərmə nodu hovuzdan qalan 760k əməliyyatı götürdü və Merkle hashını hesablamağa və №9 imza blokuna başladı.
05:32 — blok №9 imzalanır və digər qovşaqlara təsdiq üçün göndərilir
05:53 — blok №9 təsdiqləndi və kök zəncirinə göndərildi
06:17 - qovşaqlar №9 blokun kök zəncirinə əlavə olunduğu və 760k əməliyyat həyata keçirməyə başladığı barədə məlumat almağa başladı.
06:47 — hovuz 9-cu blokda olan əməliyyatlardan təmizləndi
09:06 - bütün qovşaqlarda 2 milyon əməliyyat və token var

Test 2

Hər blok üçün 350k limit var. Nəticədə 3 blokumuz var.

İlkin vəziyyət: son blok #9; Məlumat bazasında 2 milyon əməliyyat və token saxlanılır

00:00 — əməliyyat yaratma skripti artıq işə salınıb
00:44 - 1 milyon tranzaksiya yaradıldı və qovşaqlara göndərilmə başladı
00:56 — təqdim node hovuzdan 320k əməliyyat apardı və 10 nömrəli bloku formalaşdırır. 320 saniyə ərzində hovuza 10k əməliyyatın əlavə olunduğunu da görürük
01:12 — №10 blok imzalanır və təsdiq üçün digər qovşaqlara göndərilir
01:18 — 1 saniyə ərzində 34 milyon əməliyyat göndərən demo skript işləməyi başa çatdırdı
01:20 — №10 blok təsdiqlənir və kök zəncirinə göndərilir
01:51 - bütün qovşaqlar №10 blokun əlavə edildiyi kök zəncirindən məlumat aldı və 320k əməliyyat tətbiq etməyə başladı.
02:01 - hovuz №320 bloka əlavə edilmiş 10k əməliyyat üçün təmizləndi
02:15 — Göndərmə nodu hovuzdan 350k əməliyyat apardı və №11 blokunu formalaşdırır
02:34 — №11 blok imzalanır və təsdiq üçün digər qovşaqlara göndərilir
02:51 — №11 blok təsdiqləndi və kök zəncirinə göndərildi
02:55 — sonuncu qovşaq 10-cu blokdan əməliyyatları tamamladı
10:59 — 9 saylı blokun təqdim edilməsi ilə əməliyyat kök zəncirində çox uzun çəkdi, lakin tamamlandı və bütün qovşaqlar bu barədə məlumat aldı və 350 min əməliyyat həyata keçirməyə başladı.
11:05 - hovuz №320 bloka əlavə edilmiş 11k əməliyyat üçün təmizləndi
12:10 - bütün qovşaqlarda 1 milyon 670k əməliyyat və token var
12:17 — Göndərmə qovşağı hovuzdan 330k əməliyyat apardı və №12 bloku formalaşdırır
12:32 — №12 blok imzalanır və təsdiq üçün digər qovşaqlara göndərilir
12:39 — №12 blok təsdiqlənir və kök zəncirinə göndərilir
13:44 - bütün qovşaqlar kök zəncirindən məlumat aldı ki, №12 blok əlavə edildi və 330k əməliyyat tətbiq etməyə başladı.
14:50 - bütün qovşaqlarda 2 milyon əməliyyat və token var

Test 3

Birinci və ikinci serverlərdə bir təsdiqləyici qovşaq göndərmə qovşağı ilə əvəz olundu.

İlkin vəziyyət: son blok #84; Verilənlər bazasında saxlanılan 0 əməliyyat və token

00:00 — Hər biri 3 milyon əməliyyat yaradan və göndərən 1 skript işə salındı
01:38 — 1 milyon tranzaksiya yaradıldı və №3 qovşağın təqdim edilməsinə göndərilmə başladı
01:50 — 3 nömrəli qovşaq hovuzdan 330k tranzaksiya aparıb və 85-ci bloku (f21) formalaşdırır. 350 saniyə ərzində hovuza 10k əməliyyatın əlavə olunduğunu da görürük
01:53 — 1 milyon tranzaksiya yaradıldı və №1 qovşağın təqdim edilməsinə göndərilmə başladı
01:50 — 3 nömrəli qovşaq hovuzdan 330k tranzaksiya aparıb və 85-ci bloku (f21) formalaşdırır. 350 saniyə ərzində hovuza 10k əməliyyatın əlavə olunduğunu da görürük
02:01 — №1 node hovuzdan 250k tranzaksiya apardı və №85 (65e) blokunu formalaşdırın
02:06 — blok №85 (f21) imzalanır və təsdiq üçün digər qovşaqlara göndərilir.
02:08 — 3 saniyə ərzində 1 milyon tranzaksiya göndərən 30 saylı serverin demo skripti işləməyi başa vurdu
02:14 — blok #85 (f21) təsdiqləndi və kök zəncirinə göndərildi
02:19 — blok №85 (65e) imzalanır və təsdiq üçün digər qovşaqlara göndərilir.
02:22 — 1 milyon tranzaksiya yaradıldı və №2 qovşağın təqdim edilməsinə göndərilmə başladı
02:27 — blok #85 (65e) təsdiqləndi və kök zəncirinə göndərildi
02:29 — 2 nömrəli qovşaq hovuzdan 111855 əməliyyat aparıb və 85 (256) blokunu formalaşdırır.
02:36 — blok №85 (256) imzalanır və təsdiq üçün digər qovşaqlara göndərilir.
02:36 — 1 saniyə ərzində 1 milyon tranzaksiya göndərən 42.5 saylı serverin demo skripti işləməyi başa vurdu
02:38 — blok #85 (256) təsdiqləndi və kök zəncirinə göndərildi
03:08 — 2 saniyə ərzində 1 milyon tranzaksiya göndərən №47 server skripti işləməyi başa vurdu
03:38 - bütün qovşaqlar #85 (f21), #86(65e), #87(256) bloklarının əlavə edildiyi və 330k, 250k, 111855 əməliyyat tətbiq etməyə başladığı barədə kök zəncirindən məlumat aldı.
03:49 - hovuz #330 (f250), #111855(85e), #21(86) bloklarına əlavə edilmiş 65k, 87k, 256 əməliyyatda təmizləndi
03:59 — göndərmə qovşağı №1 hovuzdan və 888145 (88) blokundan 214 tranzaksiya apardı, təqdim qovşağı №2 hovuzdan və 750 (88a) blokundan 50 min əməliyyat apardı, 3 nömrəli qovşaqdan 670 min əməliyyat apardı. hovuz və formalar bloku №88 (d3b)
04:44 — blok №88 (d3b) imzalanır və təsdiq üçün digər qovşaqlara göndərilir.
04:58 — blok №88 (214) imzalanır və təsdiq üçün digər qovşaqlara göndərilir.
05:11 — blok №88 (50a) imzalanır və təsdiq üçün digər qovşaqlara göndərilir.
05:11 — blok #85 (d3b) təsdiqləndi və kök zəncirinə göndərildi
05:36 — blok #85 (214) təsdiqləndi və kök zəncirinə göndərildi
05:43 - bütün qovşaqlar #88 (d3b), #89(214) bloklarının əlavə edildiyi və 670k, 750k əməliyyatları tətbiq etməyə başladığı barədə kök zəncirindən məlumat aldı
06:50 — rabitə xətası səbəbindən 85-ci blok (50a) təsdiq edilmədi
06:55 — 2 nömrəli qovşaq hovuzdan 888145 əməliyyat apardı və 90 nömrəli blok (50a) formalarını təqdim etdi.
08:14 — blok №90 (50a) imzalanır və təsdiq üçün digər qovşaqlara göndərilir.
09:04 — blok #90 (50a) təsdiqləndi və kök zəncirinə göndərildi
11:23 - bütün qovşaqlar 90-cı blokun (50a) əlavə edildiyi kök zəncirindən məlumat aldı və 888145 əməliyyat tətbiq etməyə başladı. Eyni zamanda, №3 server artıq #88(d3b), #89(214) bloklarından tranzaksiya tətbiq edib.
12:11 - bütün hovuzlar boşdur
13:41 — №3 serverin bütün qovşaqlarında 3 milyon əməliyyat və token var
14:35 — №1 serverin bütün qovşaqlarında 3 milyon əməliyyat və token var
19:24 — №2 serverin bütün qovşaqlarında 3 milyon əməliyyat və token var

Maneələr

Plazma Cash-in inkişafı zamanı biz tədricən həll etdiyimiz və həll etməkdə olan aşağıdakı problemlərlə qarşılaşdıq:

1. Müxtəlif sistem funksiyalarının qarşılıqlı təsirində münaqişə. Məsələn, hovuza əməliyyatlar əlavə etmək funksiyası blokların təqdim edilməsi və təsdiqlənməsi işini blokladı və əksinə, sürətin azalmasına səbəb oldu.

2. Məlumat ötürmə xərclərini minimuma endirərkən çox sayda əməliyyatın necə göndəriləcəyi dərhal aydın deyildi.

3. Yüksək nəticələr əldə etmək üçün məlumatların necə və harada saxlanacağı bəlli deyildi.

4. 1 milyon əməliyyatı olan bir blokun ölçüsü təxminən 100 MB tutduğundan, qovşaqlar arasında şəbəkənin necə təşkil ediləcəyi aydın deyildi.

5. Tək yivli rejimdə işləmək uzun hesablamalar baş verdikdə (məsələn, Merkle ağacının qurulması və onun hashinin hesablanması) qovşaqlar arasındakı əlaqəni pozur.

Bütün bunlarla necə məşğul olduq?

Plazma Nağd qovşağının ilk versiyası eyni anda hər şeyi edə bilən bir növ kombayn idi: əməliyyatları qəbul etmək, blokları təqdim etmək və təsdiqləmək və məlumatlara daxil olmaq üçün API təmin etmək. NodeJS yerli olaraq tək yivli olduğundan, ağır Merkle ağacı hesablama funksiyası əlavə əməliyyat funksiyasını blokladı. Bu problemi həll etmək üçün iki variant gördük:

1. Hər biri xüsusi funksiyaları yerinə yetirən bir neçə NodeJS prosesini işə salın.

2. worker_threads istifadə edin və kodun bir hissəsinin icrasını mövzulara köçürün.

Nəticədə, biz hər iki variantdan eyni vaxtda istifadə etdik: məntiqi olaraq bir düyünü ayrı-ayrılıqda, lakin eyni zamanda sinxron işləyə bilən 3 hissəyə ayırdıq.

1. Hovuzda əməliyyatları qəbul edən və bloklar yaradan təqdimetmə qovşağı.

2. Düyünlərin etibarlılığını yoxlayan doğrulama qovşağı.

3. API node - verilənlərə daxil olmaq üçün API təmin edir.

Bu halda, cli istifadə edərək unix yuvası vasitəsilə hər bir node-a qoşula bilərsiniz.

Merkle ağacının hesablanması kimi ağır əməliyyatları ayrı bir mövzuya köçürdük.

Beləliklə, biz bütün Plasma Cash funksiyalarının eyni vaxtda və nasazlıq olmadan normal işləməsinə nail olduq.

Sistem işlək olduqdan sonra biz sürəti sınamağa başladıq və təəssüf ki, qeyri-qənaətbəxş nəticələr aldıq: saniyədə 5 000 əməliyyat və blok başına 50 000-ə qədər əməliyyat. Nəyin səhv həyata keçirildiyini anlamalı idim.

Başlamaq üçün sistemin ən yüksək imkanlarını öyrənmək üçün Plasma Cash ilə əlaqə mexanizmini sınaqdan keçirməyə başladıq. Daha əvvəl Plazma Nağd qovşağının unix yuva interfeysi təmin etdiyini yazmışdıq. Əvvəlcə mətn əsaslı idi. json obyektləri `JSON.parse()` və `JSON.stringify()` istifadə edərək göndərilib.

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

Bu cür obyektlərin ötürmə sürətini ölçdük və saniyədə ~ 130k tapdıq. Biz json ilə işləmək üçün standart funksiyaları əvəz etməyə çalışdıq, lakin performans yaxşılaşmadı. V8 mühərriki bu əməliyyatlar üçün yaxşı optimallaşdırılmalıdır.

Biz dərslər vasitəsilə əməliyyatlar, tokenlər və bloklarla işləmişik. Bu cür siniflər yaratarkən, performans 2 dəfə aşağı düşdü, bu, OOP-nun bizim üçün uyğun olmadığını göstərir. Mən hər şeyi sırf funksional yanaşmaya yenidən yazmalı oldum.

Verilənlər bazasında qeyd

İlkin olaraq, Redis tələblərimizə cavab verən ən məhsuldar həllərdən biri kimi məlumatların saxlanması üçün seçildi: açar-dəyər saxlama, hash cədvəlləri, dəstlərlə işləmə. Biz redis-benchmark-ı işə saldıq və 80 boru kəməri rejimində saniyədə ~1k əməliyyat əldə etdik.

Yüksək performans üçün biz Redis-i daha incə köklədik:

Unix soket bağlantısı quruldu.
Biz vəziyyəti diskdə saxlamağı qeyri-aktiv etdik (etibarlılıq üçün siz replika qura və diskə ayrıca Redis-də saxlaya bilərsiniz).

Redis-də hovuz hash cədvəlidir, çünki biz bir sorğuda bütün əməliyyatları əldə etməyi və əməliyyatları bir-bir silməyi bacarmalıyıq. Biz adi siyahıdan istifadə etməyə çalışdıq, lakin bütün siyahını boşaldarkən daha yavaş olur.

Standart NodeJS istifadə edərkən, Redis kitabxanaları saniyədə 18k əməliyyat performansına nail oldu. Sürət 9 dəfə aşağı düşüb.

Benchmark bizə imkanların 5 dəfə daha çox olduğunu göstərdiyi üçün biz optimallaşdırmağa başladıq. Kitabxananı ioredis-ə dəyişdik və saniyədə 25k performans əldə etdik. “hset” əmrindən istifadə edərək əməliyyatları bir-bir əlavə etdik. Beləliklə, biz Redis-də çoxlu sorğular yaradırdıq. Tranzaksiyaları partiyalara birləşdirmək və onları bir “hmset” əmri ilə göndərmək ideyası yarandı. Nəticə saniyədə 32k.

Aşağıda təsvir edəcəyimiz bir neçə səbəbə görə biz `Bufer` istifadə edərək verilənlərlə işləyirik və belə çıxır ki, onu yazmadan əvvəl mətnə (`buffer.toString('hex')) çevirsəniz, əlavə əldə edə bilərsiniz. performans. Beləliklə, sürət saniyədə 35k-a qədər artırıldı. Hazırda biz əlavə optimallaşdırmanı dayandırmaq qərarına gəldik.

İkili protokola keçməli olduq, çünki:

1. Sistem tez-tez hashları, imzaları və s. hesablayır və bunun üçün `Buferdə məlumat lazımdır.

2. Xidmətlər arasında göndərildikdə, ikili məlumat mətndən daha az çəkir. Məsələn, 1 milyon tranzaksiya ilə blok göndərilərkən, mətndəki məlumatlar 300 meqabaytdan çox tuta bilər.

3. Daim məlumatların dəyişdirilməsi performansa təsir edir.

Buna görə də, biz gözəl “ikili verilənlər” kitabxanası əsasında hazırlanmış verilənlərin saxlanması və ötürülməsi üçün öz binar protokolumuzu əsas götürdük.

Nəticədə aşağıdakı məlumat strukturlarını əldə etdik:

- Əməliyyat

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

Adi `BD.encode(block, Protocol).slice();` və `BD.decode(bufer, Protocol)` əmrləri ilə biz məlumatları Redis-də saxlamaq və ya başqa noda yönləndirmək və əldə etmək üçün `Bufer`ə çeviririk. məlumat geri.

Həmçinin xidmətlər arasında məlumat ötürmək üçün 2 ikili protokolumuz var:

— Unix yuvası vasitəsilə Plazma Node ilə qarşılıqlı əlaqə protokolu

  ```json
  {
    type: BD.types.uint8,
    messageId: BD.types.uint24le,
    error: BD.types.uint8,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

Ü:

`növ` — yerinə yetiriləcək hərəkət, məsələn, 1 — sendTransaction, 2 — getTransaction;
`faydalı yük` — müvafiq funksiyaya ötürülməsi lazım olan məlumatlar;
`messageID` — cavabı müəyyən etmək üçün mesaj id.

— Qovşaqlar arasında qarşılıqlı əlaqə protokolu

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

Ü:

`kod` — mesaj kodu, məsələn 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
`versiya Protokolu` — protokol versiyası, çünki müxtəlif versiyaları olan qovşaqlar şəbəkədə qaldırıla bilər və onlar fərqli işləyə bilər;
`seq` — mesaj identifikatoru;
'countChunk' и 'parça nömrəsi' böyük mesajları bölmək üçün lazımdır;
`uzunluq` и `faydalı yük` uzunluğu və məlumatların özü.

Məlumatları əvvəlcədən yazdığımız üçün son sistem Ethereum-un `rlp` kitabxanasından daha sürətlidir. Təəssüf ki, biz hələ bundan imtina edə bilməmişik, çünki gələcəkdə etməyi planlaşdırdığımız ağıllı müqaviləni yekunlaşdırmaq lazımdır.

Sürətə çata bilsəydik 35 000 saniyədə əməliyyatlar, biz də onları optimal müddətdə emal etməliyik. Təxmini blokun formalaşma müddəti 30 saniyə çəkdiyi üçün biz bloka daxil etməliyik 1 000 000 əməliyyatlar, bu daha çox göndərmək deməkdir 100 MB məlumat.

Əvvəlcə qovşaqlar arasında əlaqə yaratmaq üçün `ethereumjs-devp2p` kitabxanasından istifadə etdik, lakin o, bu qədər məlumatı idarə edə bilmədi. Nəticədə, biz `ws` kitabxanasından istifadə etdik və ikili məlumatların vebsoket vasitəsilə göndərilməsini konfiqurasiya etdik. Təbii ki, biz də böyük məlumat paketləri göndərərkən problemlərlə qarşılaşdıq, lakin biz onları parçalara ayırdıq və indi bu problemlər aradan qalxdı.

Həmçinin Merkle ağacının formalaşdırılması və hashın hesablanması 1 000 000 haqqında əməliyyatlar tələb edir 10 saniyə fasiləsiz hesablama. Bu müddət ərzində bütün qovşaqlarla əlaqə pozulmağı bacarır. Bu hesablamanın ayrı bir mövzuya köçürülməsi qərara alındı.

Sonuç:

Əslində, bizim tapıntılarımız yeni deyil, amma nədənsə bir çox ekspertlər inkişaf edərkən onları unudurlar.

Obyekt yönümlü proqramlaşdırma əvəzinə Funksional Proqramlaşdırmadan istifadə məhsuldarlığı artırır.
Monolit məhsuldar NodeJS sistemi üçün xidmət arxitekturasından daha pisdir.
Ağır hesablamalar üçün `worker_threads`-dən istifadə xüsusilə giriş/çıxış əməliyyatları ilə məşğul olarkən sistemin cavab vermə qabiliyyətini yaxşılaşdırır.
unix yuvası http sorğularından daha sabit və sürətlidir.
Şəbəkə üzərindən böyük məlumatları sürətlə ötürmək lazımdırsa, veb-soketlərdən istifadə etmək və ikili məlumatları göndərmək daha yaxşıdır, hissələrə bölünür, onlar gəlmədikdə yönləndirilə bilər və sonra bir mesajda birləşdirilə bilər.

Sizi ziyarətə dəvət edirik Github layihə: https://github.com/opporty-com/Plasma-Cash/tree/new-version

Məqaləni birgə yazmışdır Aleksandr Nəşivan, baş tərtibatçı Clever Solution Inc.

Mənbə: www.habr.com

İctimai Test: Ethereum Məxfilik və Ölçeklenebilirlik Həlli