🥇Публичен тест: решение за приватност и мащабируемост в Етериум

Блокчейн — иновационна технология, обещаваща да подобри много сфери на живота на човека. Тя пренася реални процеси и продукти в дигиталното пространство, осигурява бързина и надеждност на финансовите операции, намалява разходите им и позволява създаването на съвременни DAPP приложения с използване на интелигентни договори в децентрализираните мрежи.

Въпреки многобройните предимства и разнообразните приложения на блокчейн, може да изглежда странно, че тази обещаваща технология все още не е проpenetrрал във всички отрасли. Проблемът е, че съвременните децентрализирани блокчейни страдат от недостиг на мащабируемост. Етерът обработва около 20 транзакции в секунда, което е недостатъчно за задоволяване на нуждите на съвременния динамичен бизнес. В същото време компаниите, които използват блокчейн технология, не искат да се откажат от Етерът заради високото му ниво на защита от хакерски атаки и мрежови сривове.

За да се осигури децентрализация, сигурност и мащабируемост в блокчейна, решавайки по този начин проблемът с Мащабируемостта, екип от разработчици Opporty създаде Plasma Cash — дъщерна верига, състояща се от интелигентен договор и частна мрежа на базата на Node.js, която периодично предава състоянието си в основната верига (Етерът).

Ключови процеси в Plasma Cash

1. Потребителят извиква функцията на интелигентния договор `deposit`, предавайки сумата в ETH, която желае да положи в токена Plasma Cash. Функцията на интелигентния договор създава токен и генерира събитие за това.

2. Plasma Cash възли, подписани на събития от интелигентния договор, получават съобщение за създаването на депозита и добавят транзакцията за създаването на токена в пула.

3. Периодично специализирани Plasma Cash възли взимат всички транзакции от пула (до 1 милион) и формулират блок от тях, изчисляват дървото на Меркле и съответно, хеша. Този блок се изпраща на другите възли за верификация. Възлите проверяват дали хешът на Меркле е валиден, валидни ли са транзакциите (например, дали изпращачът на токена е негов собственик). След верификация на блока възелът извиква функцията `submitBlock` на интелигентния договор, която запазва в основната верига номера и хеша на блока. Интелигентният договор генерира събитие за успешно добавяне на блока. Транзакциите се премахват от пула.

4. Нодите, получили събитие за подаване на блок, започват да прилагат транзакции, които са били добавени в блока.

5. В определен момент собственикът (или несобственикът) на токена иска да го изтегли от Plasma Cash. За тази цел той извиква функцията `startExit`, предавайки информация за последните 2 транзакции по токена, които потвърдиха, че именно той е собственик на токена. Смарт-договорът, използвайки хеш Меркле, проверява наличието на транзакции в блоковете и изпраща токена за извеждане, което ще се случи след две седмици.

6. Ако операцията по извеждане на токена е извършена с нарушения (токенът е бил похарчен след началото на процедурата по извеждане или токенът преди извеждане вече е бил чужд), собственикът на токена може да оспори извеждането в срок от две седмици.

Приватността се постига по два начина

1. Коренната верига не знае нищо за транзакциите, които се генерират и изпращат в рамките на дочерната верига. Публична остава информацията за това, кой е внесъл и изтеглил ETH в/от Plasma Cash.

2. Дочерната верига позволява организирането на анонимни транзакции, използвайки zk-SNARKs.

Технологичен стек

NodeJS
Redis
Etherium
Soild

Тестиране

При разработването на Plasma Cash, протестирахме скоростта на работа на системата и получихме следните резултати:

до 35 000 транзакции в секунда се добавят в пул;
до 1 000 000 транзакции могат да се съхраняват в блок.

Тестовете бяха проведени на 3 следващи сървъра:

1. Intel Core i7-6700 Quad-Core Skylake incl. NVMe SSD — 512 GB, 64 GB DDR4 RAM
Бяха стартирани 3 валидиращи ноди Plasma Cash.

2. AMD Ryzen 7 1700X Octa-Core «Summit Ridge» (Zen), SATA SSD — 500 GB, 64 GB DDR4 RAM
Беше стартирана Ropsten testnet ETH нода.
Бяха стартирани 3 валидиращи ноди Plasma Cash.

3. Intel Core i9-9900K Octa-Core incl. NVMe SSD — 1 TB, 64 GB DDR4 RAM
Беше стартирана 1 сабмит нода Plasma Cash.
Бяха стартирани 3 валидиращи ноди Plasma Cash.
Извърши се тест за добавяне на транзакции в мрежата Plasma Cash.

Общо: 10 ноди Plasma Cash в частна мрежа.

Тест 1

Има лимит от 1 милион транзакции в блок. Ето защо 1 милион транзакции попадат в 2 блока (тъй като системата успява да вземе част от транзакциите и да ги подаде, докато те се изпращат).

Начално състояние: последен блок #7; в базата са запазени 1 млн транзакции и токени.

00:00 — стартиране на скрипта за генериране на транзакции
01:37 — създадени са 1 млн транзакции и е започнало изпращането им към нодата
01:46 — сабмит нодата е взела от пула 240к транзакции и образува блок #8. Също така виждаме, че в пула се добавят 320к транзакции за 10 секунди
01:58 — блок #8 е подписан и изпратен за валидация
02:03 — блок #8 е валидиран и е извикана функцията `submitBlock` на смарт договора с хеш от Меркле и номер на блока
02:10 — демо скриптът приключи работа, като изпрати 1 млн. транзакции за 32 сек.
02:33 — нодовете започнаха да получават информация, че блок #8 е добавен в основната верига и започнаха да изпълняват 240к транзакции
02:40 — от пул също бяха премахнати 240к транзакции, които вече са в блок #8
02:56 — сабмит нода взе от пула останалите 760к транзакции и започна да изчислява хеша от Меркле и да подпише блок #9
03:20 — всички нодовете съдържат 1млн 240к транзакции и токени
03:35 — блок #9 е подписан и изпратен за валидация на други нодове
03:41 — възникна грешка в мрежата
04:40 — изтече времето за изчакване за валидация на блок #9
04:54 — сабмит нода взе от пула оставащите 760к транзакции и започна да изчислява хеша от Меркле и да подпише блок #9
05:32 — блок #9 е подписан и изпратен за валидация на други нодове
05:53 — блок #9 е валидиран и изпратен в основната верига
06:17 — нодовете започнаха да получават информация за това, че блок #9 е добавен в основната верига и започнаха да изпълняват 760к транзакции
06:47 — пулът е очистен от транзакции, които са в блок #9
09:06 — всички нодовете съдържат 2 млн. транзакции и токени

Тест 2

Има лимит от 350к на блок. В резултат на това имаме 3 блока.

Начално състояние: последен блок #9; в базата са съхранени 2 млн. транзакции и токени

00:00 — скриптът за генериране на транзакции вече е стартиран
00:44 — създадени са 1 млн. транзакции и е започнало изпращането им в нода
00:56 — сабмит нода взе от пула 320к транзакции и формира блок #10. Също така виждаме, че в пулът се добавят 320к транзакции за 10 сек.
01:12 — блок #10 е подписан и изпратен на други нодове за валидация
01:18 — демо скриптът приключи работа, като изпрати 1 млн. транзакции за 34 сек.
01:20 — блок #10 е валидиран и изпратен в основната верига
01:51 — всички нодовете получиха от основната верига информация, че блок #10 е добавен, и започват да прилагат 320к транзакции
02:01 — пулът е очистен с 320к транзакции, които бяха добавени в блок #10
02:15 — сабмит нода взе от пула 350к транзакции и формира блок #11
02:34 — блок #11 е подписан и изпратен на други нодове за валидация
02:51 — блок #11 е валидиран и изпратен в основната верига
02:55 — последният нод изпълни транзакциите от блок #10
10:59 — много дълго време в основната верига се изпълняваше транзакция със сабмит от блок #9, но тя бе изпълнена и всички нодове получиха информация за това и започнаха да изпълняват 350к транзакции.
11:05 — пулът се изчисти с 320к транзакции, които бяха добавени в блок #11.
12:10 — всички нодове съдържат 1 млн 670к транзакции и токени.
12:17 — сабмит нодът взе от пула 330к транзакции и формира блок #12.
12:32 — блок #12 е подписан и изпратен на другите нодове за валидация.
12:39 — блок #12 е валидиран и изпратен в основната верига.
13:44 — всички нодове получиха от основната верига информация, че блок #12 е добавен и започват да прилагат 330к транзакции.
14:50 — всички нодове съдържат 2 млн транзакции и токени.

Тест 3

В първия и втория сървър, един валидиращ нод беше заменен със сабмит нод.

Начално състояние: последен блок #84; в базата са запазени 0 транзакции и токени.

00:00 — Стартирани са 3 скрипта, които генерират и изпращат по 1 млн транзакции.
01:38 — създадено е 1млн транзакции и започна изпращането в сабмит нод #3.
01:50 — сабмит нод #3 взе от пула 330к транзакции и формира блок #85 (f21). Също така виждаме, че в пула се добавят 350к транзакции за 10 секунди.
01:53 — създадено е 1млн транзакции и започна изпращането в сабмит нод #1.
01:50 — сабмит нод #3 взе от пула 330к транзакции и формира блок #85 (f21). Също така виждаме, че в пула се добавят 350к транзакции за 10 секунди.
02:01 — сабмит нод #1 взе от пула 250к транзакции и формира блок #85 (65e).
02:06 — блок #85 (f21) е подписан и изпратен на другите нодове за валидация.
02:08 — завърши работа демо-скриптът на сървър #3, който изпрати 1млн транзакции за 30 секунди.
02:14 — блок #85 (f21) е валидиран и изпратен в основната верига.
02:19 — блок #85 (65e) е подписан и изпратен на другите нодове за валидация.
02:22 — създадено е 1млн транзакции и започна изпращането в сабмит нод #2.
02:27 — блок #85 (65e) е валидиран и изпратен в основната верига.
02:29 — сабмит нод #2 взе от пула 111855 транзакции и формира блок #85 (256).
02:36 — блок #85 (256) е подписан и изпратен на другите нодове за валидация.
02:36 — завърши работа демо-скриптът на сървър #1, който изпрати 1млн транзакции за 42.5 секунди.
02:38 — блок #85 (256) е валидиран и изпратен в основната верига.
03:08 — завърши работа демо-скриптът на сървър #2, който изпрати 1млн транзакции за 47 секунди.
03:38 — всички нодове получиха от основната верига информация, че блоковете #85 (f21), #86 (65e), #87 (256) са добавени и започват да прилагат 330к, 250к, 111855 транзакции.
03:49 — пулът се почисти на 330к, 250к, 111855 транзакции, които бяха добавени в блок #85 (f21), #86(65e), #87(256)
03:59 — сабмита на нода #1 взе от пула 888145 транзакции и формулира блок #88 (214), сабмита на нода #2 взе от пула 750к транзакции и формулира блок #88 (50a), сабмита на нода #3 взе от пула 670к транзакции и формулира блок #88 (d3b)
04:44 — блок #88 (d3b) е подписан и изпратен на други нодове за валидиране
04:58 — блок #88 (214) е подписан и изпратен на други нодове за валидиране
05:11 — блок #88 (50a) е подписан и изпратен на други нодове за валидиране
05:11 — блок #85 (d3b) е валидиран и изпратен в кореновата верига
05:36 — блок #85 (214) е валидиран и изпратен в кореновата верига
05:43 — всички нодове получиха от кореновата верига информация, че блоковете #88 (d3b), #89(214) са добавени и започват да прилагат 670к, 750к транзакции
06:50 — поради прекъсване на връзката блок #85 (50a) не беше валидиран
06:55 — сабмита на нода #2 взе от пула 888145 транзакции и формулира блок #90 (50a)
08:14 — блок #90 (50a) е подписан и изпратен на други нодове за валидиране
09:04 — блок #90 (50a) е валидиран и изпратен в кореновата верига
11:23 — всички нодове получиха от кореновата верига информация, че блок #90 (50a) е добавен и започват да прилагат 888145 транзакции. Междувременно, вече отдавна сървър #3 приложи транзакции от блоковете #88 (d3b), #89(214)
12:11 — всички пулове са празни
13:41 — всички нодове на сървър #3 съдържат 3млн транзакции и токени
14:35 — всички нодове на сървър #1 съдържат 3млн транзакции и токени
19:24 — всички нодове на сървър #2 съдържат 3млн транзакции и токени

Препятствия

По време на разработката на Plasma Cash се сблъскахме със следните проблеми, които постепенно решаваме:

1. Конфликт на взаимодействие между различни функции на системата. Например, функцията за добавяне на транзакции в пула блокираше работата на сабмита и валидирането на блоковете, и обратно, което водеше до спад в скоростта.

2. Не беше веднага ясно как да се изпратят огромно количество транзакции и в същото време да се минимизират разходите за предаване на данни.

3. Не беше ясно как и къде да се съхраняват данните, за да се постигнат високи резултати.

4. Не беше ясно как да се организира мрежата между нодовете, тъй като размерът на блока с 1 милион транзакции заема около 100 Мб.

5. Работата в еднопоточен режим разкъсва връзката между нодовете, когато се извършват дълги изчисления (например, построяване на дървото на Меркле и изчисляване на неговия хеш).

Как се справихме с всичко това?

Първата версия на Plasma Cash нодата представляваше нещо като комбайн, който можеше да прави всичко едновременно: да приема транзакции, да сабмитва и валидира блокове, предоставяше API за достъп до данни. Тъй като NodeJS е първоначално еднопоточна, тежката функция за изчисляване на дървото на Меркле блокираше функцията за добавяне на транзакции. Видяхме два варианта за решение на този проблем:

1. Да стартираме няколко NodeJS процеса, всеки от които изпълнява определени функции.

2. Да използваме worker_threads и да изнесем изпълнението на част от кода в потоци.

В крайна сметка се възползвахме от двата варианта едновременно: логически разделихме една нода на 3 части, които могат да работят отделно, но в същото време синхронно.

1. Сабмит нода, която приема транзакции в пул и се занимава със създаването на блокове.

2. Валидираща нода, която проверява валидността на нодовете.

3. API нода — предоставя API за достъп до данни.

Към всяка нода може да се свърже чрез unix socket с помощта на CLI.

Тежките операции, като изчисляването на дървото на Меркле, изнесохме в отделен поток.

По този начин постигнахме нормална работа на всички функции на Plasma Cash едновременно и без проблеми.

След като системата функционално заработи, започнахме да тестваме скоростта и, за съжаление, получихме незадоволителни резултати: 5 000 транзакции в секунда и до 50 000 транзакции в блок. Трябваше да разберем какво е реализирано неправилно.

Първоначално започнахме да тестваме механизма на комуникация с Plasma Cash, за да разберем пиковата капацитет на системата. По-рано написахме, че Plasma Cash нодата предоставя unix socket интерфейс. Първоначално той беше текстов. json обектите се изпращаха, използвайки `JSON.parse()` и `JSON.stringify()`.

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

Замерихме скоростта на пренос на такива обекти и получихме ~ 130к в секунда. Опитахме се да заменим стандартните функции за работа с json, но производителността не се увеличи. Явно V8 е добре оптимизиран за тези операции.

Работата с транзакции, токени и блокове се осъществяваше чрез класове. При създаването на такива класове производителността намаля два пъти, което показва, че OOP не ни подхожда. Прибегнахме до пренаписване на всичко на чисто функционален подход.

Запис в база данни

Първоначално за съхранение на данни избрахме Redis като едно от най-производителните решения, които отговарят на нашите изисквания: хранилище тип ключ-стойност, работа с хеш таблици, множества. Стартирахме redis-benchmark и получихме ~80к операции в секунда в режим 1 pipelining.

За висока производителност настроихме Redis по-подробно:

Настроихме unix socket връзка.
Изключихме запазването на състоянието на диска (за надеждност можем да настроим реплика и да правим запис на диска в отделен Redis).

В Redis пулът е хеш таблица, тъй като имаме нужда от възможността да получим всички транзакции с едно запитване и да изтриваме транзакции поотделно. Опитахме да използваме обикновен списък, но той работи по-бавно при извеждане на целия списък.

При използване на стандартната NodeJS библиотека Redis получихме производителност от 18к транзакции в секунда. Скоростта намаля 9 пъти.

Тъй като бенчмаркът показа явно способности, поне 5 пъти по-големи, започнахме да оптимизираме. Сменихме библиотеката на ioredis и получихме производителност вече 25к в секунда. Транзакциите добавяхме поотделно, използвайки командата `hset`. Така генерирахме много запитвания в Redis. Появи се идеята да обединяваме транзакции в пачки и да ги изпращаме с една команда `hmset`. Резултатът — 32к в секунда.

Поради няколко причини, които ще опишем по-долу, работим с данни, използвайки `Buffer` и, както се оказа, ако го преведем в текст (`buffer.toString(‘hex’)`) преди запис, можем да получим допълнителна производителност. Така успяхме да увеличим скоростта до 35к в секунда. В момента решихме да спрем допълнителната оптимизация.

Наложи се да преминем на бинарен протокол, тъй като:

1. Системата често изчислява хешове, подписи и т.н., и за това и трябват данни в `Buffer.

2. При пренос на бинарни данни между услугите, те заемат по-малко място в сравнение с текстовите данни. Например, при изпращане на блок с 1 милион транзакции, данните в текста могат да заемат над 300 мегабайта.

3. Постоянното преобразуване на данни оказва влияние върху производителността.

Затова за основа взехме собствен бинарен протокол за съхранение и предаване на данни, разработен на базата на забележителната библиотека `binary-data`.

В резултат на това получихме следните структури от данни:

— Транзакция

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

— Токен

  ```json
  {
    id: BD.types.string(null),
    owner: BD.types.buffer(20),
    block: BD.types.uint24le,
    amount: BD.types.string(null),
  }
  ```

— Блок

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

С обикновените команди `BD.encode(block, Protocol).slice();` и ` BD.decode(buffer, Protocol)` преобразуваме данните в `Buffer` за съхранение в Redis или пренос до друга нода и извличане на данните обратно.

Также имаме 2 бинарни протоколи за пренос на данни между услугите:

— Протокол за взаимодействие с Plasma Node чрез unix socket

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

където:

`type` — действие, което трябва да се извърши, например 1 — sendTransaction, 2 — getTransaction;
`payload` — данни, които трябва да се предадат на съответната функция;
`messageId` — идентификатор на съобщението, за да може да се идентифицира отговорът.

— Протокол за взаимодействие между нодите

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

където:

`code` — код на съобщението, например 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
`versionProtocol` — версия на протокола, тъй като в мрежата могат да бъдат активирани ноди с различни версии и те могат да работят по различен начин;
`seq` — идентификатор на съобщението;
`countChunk` и `chunkNumber` необходими за разделяне на големи съобщения;
`length` и `payload` дължина и самите данни.

Тъй като предварително типизирахме данните, крайната система работи много по-бързо от библиотеката `rlp` на Етериум. За съжаление, все още не успяваме да се откажем от нея, тъй като е необходимо да доразвием смарт-контракта, което планираме да направим в бъдеще.

Ако успеем да достигнем скоростта 35 000 на транзакции в секунда, ще трябва да ги обработваме и в оптимално време. Тъй като средното време за генериране на блок е 30 секунди, е необходимо да включим в блока 1 000 000 транзакции, което означава прехвърляне на повече 100 мб данни.

Първоначално използвахме библиотеката `ethereumjs-devp2p` за свързване на възлите, но тя не смогваше да обработва толкова голямо количество данни. В резултат на това се възползвахме от библиотеката `ws` и настроихме прехвърляне на бинарни данни по websocket. Разбира се, също така се сблъскахме с проблеми при прехвърлянето на големи пакети данни, но ги разделихме на чанкове и сега тези проблеми вече ги няма.

Също така, генерирането на Меркле дърво и изчисляването на хеша 1 000 000 на транзакции изисква около 10 секунди непрекъснато изчисление. През това време връзката с всички възли успява да се прекъсне. Беше решено да преместим това изчисление в отделен поток.

Изводи:

Всъщност, нашите изводи не са нови, но по някаква причина много специалисти забравят за тях при разработката.

Използването на функционално програмиране вместо обектно-ориентирано програмиране увеличава производителността.
Монолитната архитектура е по-неподходяща от микросервизната архитектура за производителна система на NodeJS.
Използването на `worker_threads` за трудни изчисления подобрява отзивчивостта на системата, особено при работа с операции i/o.
Unix сокетите са по-стабилни и бързи от http заявките.
Ако трябва да предавате големи данни бързо през мрежата, е по-добре да използвате websocket-и и да изпращате бинарни данни, разделени на чанкове, които могат да бъдат повторно изпратени, ако не стигнат, а след това да се обединят в едно съобщение.

Каним ви да посетите GitHub проекта: https://github.com/opporty-com/Plasma-Cash/tree/new-version

Статията беше написана в съавторство с Александър Нашиван, старши разработчик на Clever Solution Inc.

Източник: habr.com