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

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

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

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

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

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

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

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

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

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

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

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

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

2. Дъщерната верига позволява анонимни транзакции с помощта на zk-SNARK.

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

• NodeJS
• Redis
• Етериум
• Soild

Тестване

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

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

Извършени са тестове на следните 3 сървъра:

1. Intel Core i7-6700 Quad-Core Skylake вкл. 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
ETH възелът на Ropsten testnet беше повдигнат.
Бяха повдигнати 3 валидиращи Plasma Cash възли.

3. Intel Core i9-9900K Octa-Core вкл. 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 — възелът за изпращане взе 240k транзакции от пула и формира блок #8. Виждаме също, че 320k транзакции се добавят към пула за 10 секунди
01:58 — блок №8 е подписан и изпратен за валидиране
02:03 — блок #8 е валидиран и функцията `submitBlock` на интелигентния договор се извиква с хеша на Merkle и номера на блока
02:10 — демо скриптът приключи работа, който изпрати 1 милион транзакции за 32 секунди
02:33 - възлите започнаха да получават информация, че блок #8 е добавен към основната верига и започнаха да изпълняват 240k транзакции
02:40 - 240k транзакции бяха премахнати от пула, които вече са в блок #8
02:56 — възелът за изпращане взе останалите 760k транзакции от пула и започна да изчислява хеша на Merkle и блок за подписване #9
03:20 - всички възли съдържат 1 милион 240k транзакции и токени
03:35 — блок #9 е подписан и изпратен за валидиране до други възли
03:41 - възникна мрежова грешка
04:40 — времето за изчакване за валидиране на блок #9 изтече
04:54 — възелът за изпращане взе останалите 760k транзакции от пула и започна да изчислява хеша на Merkle и блок за подписване #9
05:32 — блок #9 е подписан и изпратен за валидиране до други възли
05:53 — блок #9 е валидиран и изпратен до основната верига
06:17 - възлите започнаха да получават информация, че блок #9 е добавен към основната верига и започна да изпълнява 760k транзакции
06:47 — пулът е изчистен от транзакции, които са в блок #9
09:06 - всички възли съдържат 2 милиона транзакции и токени

Тест 2

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

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

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

Тест 3

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

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

00:00 — Стартирани са 3 скрипта, които генерират и изпращат по 1 милион транзакции всеки
01:38 — Бяха създадени 1 милион транзакции и започна изпращането към възел #3 за подаване
01:50 — възел за изпращане #3 взе 330k транзакции от пула и формира блок #85 (f21). Виждаме също, че 350 10 транзакции се добавят към пула за XNUMX секунди
01:53 — Бяха създадени 1 милион транзакции и започна изпращането към възел #1 за подаване
01:50 — възел за изпращане #3 взе 330k транзакции от пула и формира блок #85 (f21). Виждаме също, че 350 10 транзакции се добавят към пула за XNUMX секунди
02:01 — възел #1 за подаване взе 250k транзакции от пула и формира блок #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) са добавени и започнаха да прилагат 330k, 250k, 111855 транзакции
03:49 - пулът беше изчистен при 330k, 250k, 111855 транзакции, които бяха добавени към блокове #85 (f21), #86(65e), #87(256)
03:59 — възел за подаване #1 взе 888145 88 транзакции от пула и формира блок #214 (2), възел за подаване #750 взе 88k транзакции от пула и формира блок #50 (3a), възел за подаване #670 взе 88k транзакции от басейнът и формите блок #3 (dXNUMXb)
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) са добавени и започват да прилагат 670k, 750k транзакции
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 MB.

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

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

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

1. Стартирайте няколко NodeJS процеса, всеки от които изпълнява специфични функции.

2. Използвайте worker_threads и преместете изпълнението на част от кода в нишки.

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

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

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

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

В този случай можете да се свържете към всеки възел чрез unix сокет, като използвате cli.

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

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

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

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

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

Измерихме скоростта на трансфер на такива обекти и открихме ~ 130k в секунда. Опитахме се да заменим стандартните функции за работа с json, но производителността не се подобри. Двигателят V8 трябва да бъде добре оптимизиран за тези операции.

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

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

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

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

• Установена е връзка с unix сокет.
• Деактивирахме запазването на състоянието на диск (за надеждност можете да настроите реплика и да запазите на диск в отделен Redis).

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

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

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

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

Трябваше да преминем към двоичен протокол, защото:

1. Системата често изчислява хешове, подписи и т.н. и за целта се нуждае от данни в `Буфер.

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;
• `полезен товар` — данни, които трябва да бъдат предадени на съответната функция;
• `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)
  }
  ```

където:

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

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

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

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

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

Изводи:

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

• Използването на функционално програмиране вместо обектно-ориентирано програмиране подобрява производителността.
• Монолитът е по-лош от сервизната архитектура за продуктивна NodeJS система.
• Използването на `worker_threads` за тежки изчисления подобрява отзивчивостта на системата, особено когато се работи с I/O операции.
• unix socket е по-стабилен и по-бърз от http заявките.
• Ако трябва бързо да прехвърлите големи данни по мрежата, по-добре е да използвате websockets и да изпращате двоични данни, разделени на части, които могат да бъдат препратени, ако не пристигнат, и след това комбинирани в едно съобщение.

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

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

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