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

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

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

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

Ключови процеси в 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
• Етериум
• 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 — сабмит нодата взе от пула 240k транзакции и формира блок #8. Също така виждаме, че в пула се добавят 320k транзакции за 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 000 трансакции
11:05 — пулът беше разтоварен с 320 000 трансакции, които бяха добавени в блок #11
12:10 — всички ноди съдържат 1 670 000 трансакции и токени
12:17 — подавната нода взе от пула 330 000 трансакции и формулира блок #12
12:32 — блок #12 е подписан и изпратен на другите ноди за валидация
12:39 — блок #12 е валидиран и изпратен в кореновата верига
13:44 — всички ноди получиха информация от кореновата верига, че блок #12 е добавен и започват да прилагат 330 000 трансакции
14:50 — всички ноди съдържат 2 милиона трансакции и токени

Тест 3

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

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

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

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 едновременно и без смущения.

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

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

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

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

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

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

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

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

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

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

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

Тъй като benchmark ни показа възможности явно с 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` от Ethereum. За съжаление, все още не успяхме да се откажем от нея, тъй като е необходимо да доработим смарт-контракта, което планираме да направим в бъдеще.

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

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

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

Изводи:

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

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

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

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

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