Јавен тест: решение за приватност и приспособливост на Ethereum

Блокчејн е иновативна технологија која ветува подобрување на многу области од човечкиот живот. Пренесува реални процеси и производи во дигиталниот простор, обезбедува брзина и сигурност на финансиските трансакции, ја намалува нивната цена, а исто така ви овозможува да креирате модерни DAPP апликации користејќи паметни договори во децентрализирани мрежи.

Со оглед на многуте придобивки и разновидните апликации на блокчејнот, може да изгледа изненадувачки што оваа ветувачка технологија сè уште не се пробила во секоја индустрија. Проблемот е што модерните децентрализирани блокчејнови немаат приспособливост. Ethereum обработува околу 20 трансакции во секунда, што не е доволно за да ги задоволи потребите на денешните динамични бизниси. Во исто време, компаниите кои користат блокчејн технологија се двоумат дали да го напуштат Ethereum поради неговиот висок степен на заштита од хакирање и неуспеси на мрежата.

За да се обезбеди децентрализација, безбедност и приспособливост во блокчејнот, со што ќе се реши Трилемата за приспособливост, тимот за развој Можност создаде Плазма Кеш, синџир подружница што се состои од паметен договор и приватна мрежа базирана на Node.js, која периодично ја пренесува својата состојба во коренскиот синџир (Ethereum).

Клучни процеси во готовина во плазма

1. Корисникот ја нарекува функцијата за паметен договор „депозит“, пренесувајќи го во неа износот на ETH што сака да го депонира во токенот за готовина на плазма. Функцијата паметен договор создава токен и генерира настан за него.

2. Јазлите на плазма кеш претплатени на настани со паметни договори добиваат настан за создавање депозит и додаваат трансакција за создавање токен во базенот.

3. Периодично, специјалните јазли Plasma Cash ги земаат сите трансакции од базенот (до 1 милион) и формираат блок од нив, го пресметуваат дрвото Меркл и, соодветно, хашот. Овој блок се испраќа до други јазли за верификација. Јазлите проверуваат дали хашот на Merkle е валиден и дали трансакциите се валидни (на пример, дали испраќачот на токенот е неговиот сопственик). По потврдувањето на блокот, јазолот ја повикува функцијата `submitBlock` на паметниот договор, со што се зачувува бројот на блокот и хашот на Merkle во синџирот на рабовите. Паметниот договор генерира настан што укажува на успешно додавање на блок. Трансакциите се отстранети од базенот.

4. Јазлите што го примаат настанот за поднесување блок почнуваат да ги применуваат трансакциите што беа додадени во блокот.

5. Во одреден момент, сопственикот (или не-сопственикот) на токенот сака да го повлече од Плазма Кеш. За да го направите ова, тој ја нарекува функцијата `startExit`, пренесувајќи во неа информации за последните 2 трансакции на токенот, кои потврдуваат дека тој е сопственик на токенот. Паметниот договор, користејќи го хашот Меркл, го проверува присуството на трансакции во блоковите и го испраќа токенот за повлекување, што ќе се случи за две недели.

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

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

1. Коренскиот синџир не знае ништо за трансакциите што се генерираат и препраќаат во рамките на синџирот за деца. Информациите за тоа кој депонирал и повлекол ETH од Плазма Кеш остануваат јавни.

2. Детскиот синџир дозволува анонимни трансакции користејќи zk-SNARK.

Технолошки оџак

• NodeJS
• Redis
• Етериум
• Почва

Тестирање

Додека го развивавме Плазма Кеш, ја тестиравме брзината на системот и ги добивме следниве резултати:

• до 35 трансакции во секунда се додаваат во базенот;
• може да се складираат до 1 трансакции во блок.

Тестовите беа извршени на следните 3 сервери:

1. Intel Core i7-6700 Quad-Core Skylake вкл. NVMe SSD – 512 GB, 64 GB DDR4 RAM
Беа подигнати 3 валидни јазли на плазма кеш.

2. AMD Ryzen 7 1700X Octa-Core „Summit Ridge“ (Zen), SATA SSD – 500 GB, 64 GB DDR4 RAM
ЕТХ-јазолот Ropsten тест мрежа беше подигнат.
Беа подигнати 3 валидни јазли на плазма кеш.

3. Intel Core i9-9900K Octa-Core вкл. NVMe SSD – 1 TB, 64 GB DDR4 RAM
Беше подигнат 1 јазол за поднесување готовина за плазма.
Беа подигнати 3 валидни јазли на плазма кеш.
Беше лансиран тест за додавање трансакции во мрежата на Плазма Кеш.

Вкупно: 10 плазма кеш јазли во приватна мрежа.

Тест 1

Има лимит од 1 милион трансакции по блок. Затоа, 1 милион трансакции спаѓаат во 2 блока (бидејќи системот успева да земе дел од трансакциите и да поднесе додека се испраќаат).

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

00:00 — почеток на скрипта за генерирање трансакции
01:37 - Создадени се 1 милион трансакции и започна испраќањето до јазолот
01:46 — испрати јазол зеде 240 трансакции од базенот и формира блок #8. Гледаме и дека 320 илјади трансакции се додаваат во базенот за 10 секунди
01:58 — блокот #8 е потпишан и испратен на валидација
02:03 — блокот #8 е потврден и функцијата `submitBlock` на паметниот договор се повикува со хашот на Merkle и бројот на блокот
02:10 — заврши со работа демо скрипта, која испрати 1 милион трансакции за 32 секунди
02:33 - јазлите почнаа да добиваат информации дека блокот #8 е додаден во коренскиот синџир и почнаа да вршат 240 илјади трансакции
02:40 - 240 илјади трансакции беа отстранети од базенот, кои се веќе во блок #8
02:56 — поднеси јазол ги зеде преостанатите 760 трансакции од базенот и почна да го пресметува хашот на Merkle и да го потпишува блокот #9
03:20 - сите јазли содржат 1 милион 240k трансакции и токени
03:35 — блокот #9 е потпишан и испратен за валидација до други јазли
03:41 - се појави мрежна грешка
04:40 — истече времето на чекање за валидација на блок #9
04:54 — поднеси јазол ги зеде преостанатите 760 трансакции од базенот и почна да го пресметува хашот на Merkle и да го потпишува блокот #9
05:32 — блокот #9 е потпишан и испратен за валидација до други јазли
05:53 — блокот #9 е потврден и испратен до коренскиот синџир
06:17 - јазлите почнаа да добиваат информации дека блокот #9 е додаден во коренскиот синџир и почна да врши 760k трансакции
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 и почнуваат да применуваат 320k трансакции
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 и почнуваат да применуваат 330k трансакции
14:50 - сите јазли содржат 2 милиони трансакции и токени

Тест 3

Во првиот и вториот сервер, еден јазол за проверка беше заменет со јазол за поднесување.

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

00:00 — Лансирани се 3 скрипти кои генерираат и испраќаат по 1 милион трансакции
01:38 — Создадени се 1 милион трансакции и започна испраќањето до поднесување јазол #3
01:50 — поднесете јазол #3 зеде 330k трансакции од базенот и формира блок #85 (f21). Исто така, гледаме дека 350 илјади трансакции се додаваат во базенот за 10 секунди
01:53 — Создадени се 1 милион трансакции и започна испраќањето до поднесување јазол #1
01:50 — поднесете јазол #3 зеде 330k трансакции од базенот и формира блок #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) беа додадени и почнаа да применуваат 330k, 250k, 111855 трансакции
03:49 - базенот беше исчистен со 330k, 250k, 111855 трансакции кои беа додадени во блоковите #85 (f21), #86(65e), #87(256)
03:59 — поднеси јазол #1 зеде 888145 трансакции од базенот и формира блок #88 (214), поднесе јазол #2 зеде 750k трансакции од базенот и формира блок #88 (50a), поднесе јазол #3 зеде 670k трансакции од базенот и формира блок #88 (d3b)
04:44 — блокот #88 (d3b) е потпишан и испратен до други јазли за валидација
04:58 — блокот #88 (214) е потпишан и испратен до други јазли за валидација
05:11 — блокот #88 (50а) е потпишан и испратен до други јазли за валидација
05:11 — блокот #85 (d3b) е потврден и испратен до коренскиот синџир
05:36 — блокот #85 (214) е потврден и испратен до коренскиот синџир
05:43 - сите јазли добија информации од коренскиот синџир што блоковите #88 (d3b), #89(214) се додадени и почнуваат да применуваат трансакции од 670k, 750k
06:50 — поради дефект на комуникацијата, блокот #85 (50а) не беше потврден
06:55 — поднесете јазол #2 зеде 888145 трансакции од базенот и формира блок #90 (50а)
08:14 — блокот #90 (50а) е потпишан и испратен до други јазли за валидација
09:04 — блокот #90 (50а) е потврден и испратен до коренскиот синџир
11:23 - сите јазли добија информации од коренскиот синџир дека е додаден блок #90 (50a) и почнуваат да применуваат 888145 трансакции. Во исто време, серверот #3 веќе примени трансакции од блоковите #88 (d3b), #89(214)
12:11 - сите базени се празни
13:41 — сите јазли на серверот #3 содржат 3 милиони трансакции и токени
14:35 — сите јазли на серверот #1 содржат 3 милиони трансакции и токени
19:24 — сите јазли на серверот #2 содржат 3 милиони трансакции и токени

Пречки

При развојот на Плазма Кеш наидовме на следниве проблеми кои постепено ги решававме и ги решаваме:

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

2. Не беше веднаш јасно како да се испратат огромен број трансакции додека се минимизираат трошоците за пренос на податоци.

3. Не беше јасно како и каде да се складираат податоците за да се постигнат високи резултати.

4. Не беше јасно како да се организира мрежа помеѓу јазли, бидејќи големината на блок со 1 милион трансакции зафаќа околу 100 MB.

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

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

Првата верзија на јазолот Plasma Cash беше еден вид комбајн кој можеше да направи сè во исто време: прифаќа трансакции, поднесува и потврдува блокови и обезбедува API за пристап до податоци. Бидејќи NodeJS е природно со една нишка, тешката функција за пресметување на дрвото Merkle ја блокираше функцијата за додавање трансакција. Видовме две опции за решавање на овој проблем:

1. Стартувајте неколку NodeJS процеси, од кои секоја извршува специфични функции.

2. Користете worker_threads и преместете го извршувањето на дел од кодот во нишки.

Како резултат, ги користевме двете опции истовремено: логично поделивме еден јазол на 3 дела кои можат да работат одделно, но во исто време синхроно

1. Јазол за поднесување, кој прифаќа трансакции во базенот и создава блокови.

2. Јазол за валидација кој ја проверува валидноста на јазлите.

3. API јазол - обезбедува API за пристап до податоци.

Во овој случај, можете да се поврзете со секој јазол преку приклучок за Unix користејќи cli.

Ги преместивме тешките операции, како што е пресметувањето на дрвото Меркл, во посебна нишка.

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

Откако системот беше функционален, почнавме да ја тестираме брзината и, за жал, добивме незадоволителни резултати: 5 трансакции во секунда и до 000 трансакции по блок. Морав да сфатам што е спроведено погрешно.

За почеток, почнавме да го тестираме механизмот на комуникација со Plasma Cash за да ја откриеме максималната способност на системот. Претходно напишавме дека јазолот Plasma Cash обезбедува интерфејс со уникс сокет. Првично беше базиран на текст. 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 беше избран за складирање на податоци како едно од најпродуктивните решенија што ги задоволува нашите барања: складирање на вредности на клучеви, работа со табели за хаш, комплети. Воведовме редиза-бенчмарк и добивме ~ 80 илјади операции во секунда во 1 режим на цевковод.

За високи перформанси, пофино го наместивме Redis:

• Воспоставена е врска со уникс сокет.
• Го оневозможивме зачувувањето на состојбата на дискот (за сигурност, можете да поставите реплика и да зачувате на диск во посебен Redis).

Во Redis, базенот е хеш-табела затоа што треба да можеме да ги вратиме сите трансакции во едно барање и да ги бришеме трансакциите една по една. Се обидовме да користиме редовна листа, но таа е побавна при растоварување на целата листа.

При користење на стандардниот NodeJS, библиотеките Redis постигнаа перформанси од 18 илјади трансакции во секунда. Брзината падна 9 пати.

Бидејќи реперот ни покажа дека можностите се јасно 5 пати поголеми, почнавме да се оптимизираме. Ја сменивме библиотеката во ioredis и добивме перформанси од 25k во секунда. Додадовме трансакции една по една со помош на командата `hset`. Така, генериравме многу прашања во Редис. Се појави идејата да се комбинираат трансакциите во серии и да се испратат со една команда `hmset`. Резултатот е 32 илјади во секунда.

Од неколку причини, кои ќе ги опишеме подолу, работиме со податоци користејќи „Buffer“ и, како што се испоставува, ако ги претворите во текст (`buffer.toString('hex')`) пред пишувањето, можете да добиете дополнителни перформанси. Така, брзината беше зголемена на 35k во секунда. Во моментов, решивме да ја прекинеме понатамошната оптимизација.

Моравме да се префрлиме на бинарен протокол затоа што:

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

2. Кога се испраќаат помеѓу услугите, бинарните податоци тежат помалку од текстот. На пример, кога се испраќа блок со 1 милион трансакции, податоците во текстот може да заземат повеќе од 300 мегабајти.

3. Постојаното трансформирање на податоците влијае на перформансите.

Затоа, како основа го зедовме нашиот сопствен бинарен протокол за складирање и пренос на податоци, развиен врз основа на прекрасната библиотека „бинарни податоци“.

Како резултат на тоа, ги добивме следните структури на податоци:

- Трансакција

  ```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 бинарни протоколи за пренос на податоци помеѓу сервисите:

— Протокол за интеракција со плазма јазол преку уникс приклучок

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

каде што:

• „тип“. — дејството што треба да се изврши, на пример, 1 — sendTransaction, 2 — getTransaction;
• `корисна носивост` — податоци што треба да се пренесат на соодветната функција;
• `Идентификација на порака` — ИД на пораката за да може да се идентификува одговорот.

— Протокол за интеракција помеѓу јазли

  ```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;
• „верзија Протокол“. — верзија на протоколот, бидејќи јазлите со различни верзии можат да се подигнат на мрежата и можат да работат поинаку;
• `сек` — идентификатор на пораката;
• `countChunk` и „Број на парче“. неопходни за разделување големи пораки;
• `должина` и `корисна носивост` должина и самите податоци.

Бидејќи претходно ги впишавме податоците, конечниот систем е многу побрз од библиотеката `rlp` на Ethereum. За жал, сè уште не успеавме да го одбиеме, бидејќи е неопходно да се финализира паметниот договор, што планираме да го направиме во иднина.

Ако успееме да ја достигнеме брзината 35 000 трансакции во секунда, исто така треба да ги обработиме во оптимално време. Бидејќи приближното време за формирање блок трае 30 секунди, треба да го вклучиме во блокот 1 000 000 трансакции, што значи испраќање повеќе 100 MB податоци.

Првично, ја користевме библиотеката `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.

Извор: www.habr.com