Offentlig test: lösning för privatliv och skalbarhet i Ethereum

Blockchain — en innovativ teknologi som lovar att förbättra många aspekter av människors liv. Den flyttar verkliga processer och produkter till det digitala rummet, säkerställer snabbhet och tillförlitlighet i finansiella transaktioner, sänker kostnaderna och möjliggör skapandet av moderna DAPP-applikationer med smarta kontrakt i decentraliserade nätverk.

Med tanke på de många fördelarna och olika tillämpningar av blockchain kan det verka konstigt att denna lovande teknik ännu inte har trängt in i alla branscher. Problemet är att dagens decentraliserade blockchainlösningar saknar skalbarhet. Ethereum hanterar cirka 20 transaktioner per sekund, vilket är otillräckligt för att möta behoven hos en modern, dynamisk verksamhet. Samtidigt tvekar företag som använder blockchainteknik att överge Ethereum på grund av dess höga säkerhet mot intrång och nätverksproblem.

För att säkerställa decentralisering, säkerhet och skalbarhet i blockchain, och därmed lösa Skalbarhetsparadoxen, har utvecklarteamet Opporty skapat Plasma Cash — en sidokedja bestående av ett smart kontrakt och ett privat nätverk baserat på Node.js, som periodiskt överför sitt tillstånd till huvudkedjan (Ethereum).

Nyckelprocesser i Plasma Cash

1. Användaren anropar funktionen för det smarta kontraktet `deposit`, och överför det belopp i ETH som han vill placera i Plasma Cash-token. Den smarta kontraktfunktionen skapar token och genererar ett event om detta.

2. Plasma Cash-noder som är prenumererade på händelser från det smarta kontraktet får meddelandet om skapandet av en insättning och lägger till transaktionen om skapandet av token i poolen.

3. Periodiskt tar speciella Plasma Cash-noder alla transaktioner från poolen (upp till 1 miljon) och bildar en block, beräknar Merkle-trädet och därmed hash. Denna block skickas till andra noder för verifiering. Noderna kontrollerar om Merkle-hashen är giltig och om transaktionerna är giltiga (t.ex. om avsändaren av token är dess ägare). Efter verifiering av blocket anropar noden funktionen `submitBlock` i det smarta kontraktet, som sparar blockets nummer och Merkle-hash i huvudkedjan. Det smarta kontraktet genererar ett event om att blocket har lagts till framgångsrikt. Transaktionerna tas bort från poolen.

4. Noder som har fått en händelse om blocksubmittering börjar tillämpa transaktioner som har lagts till i blocket.

5. Vid något tillfälle vill ägaren (eller icke-ägaren) av tokenen ta ut den från Plasma Cash. För detta anropar han funktionen `startExit` och skickar information om de senaste 2 transaktionerna för tokenen, som bekräftar att han verkligen är ägaren av tokenen. Smartkontraktet kontrollerar med hjälp av Merkle-hashen att transaktionerna finns i blocken och skickar tokenen för uttag, vilket kommer att ske om två veckor.

6. Om uttaget av tokenen skedde felaktigt (tokenen användes efter att uttagsförfarandet börjat eller tokenen redan tillhörde någon annan före uttaget), kan tokenägarna bestrida uttaget inom två veckor.

Integritet uppnås på två sätt

1. Rotkedjan vet ingenting om transaktionerna som bildas och skickas inom underkedjan. Det förblir offentlig information om vem som satt in och tagit ut ETH till/från Plasma Cash.

2. Underkedjan möjliggör anonyma transaktioner med hjälp av zk-SNARKs.

Teknikstack

• NodeJS
• Redis
• Etherium
• Soild

Testning

När vi utvecklade Plasma Cash testade vi systemets hastighet och fick följande resultat:

• upp till 35 000 transaktioner per sekund läggs till i poolen;
• upp till 1 000 000 transaktioner kan lagras i ett block.

Testerna genomfördes på följande tre servrar:

1. Intel Core i7-6700 Quad-Core Skylake inkl. NVMe SSD – 512 GB, 64 GB DDR4 RAM
Tre validerande Plasma Cash-noder startades.

2. AMD Ryzen 7 1700X Octa-Core "Summit Ridge" (Zen), SATA SSD – 500 GB, 64 GB DDR4 RAM
En Ropsten testnet ETH-nod startades.
Tre validerande Plasma Cash-noder startades.

3. Intel Core i9-9900K Octa-Core inkl. NVMe SSD – 1 TB, 64 GB DDR4 RAM
En submit Plasma Cash-nod startades.
Tre validerande Plasma Cash-noder startades.
Ett test för att lägga till transaktioner i Plasma Cash-nätverket kördes.

Totalt: 10 Plasma Cash-noder i ett privat nätverk.

Test 1

Det finns en gräns på 1 miljon transaktioner per block. Därför hamnar 1 miljon transaktioner i 2 block (eftersom systemet hinner ta en del av transaktionerna och skicka dem innan de skickas).

Ursprungligt tillstånd: sista blocket #7; 1 miljon transaktioner och tokenen är sparad i databasen.

00:00 — skriptet för att generera transaktioner startar
01:37 — 1 miljon transaktioner skapade och började skickas till noden
01:46 — submitnodet tog 240k transaktioner från poolen och bildar block #8. Vi ser också att 320k transaktioner läggs till i poolen på 10 sekunder.
01:58 — block #8 har signerats och skickats för validering.
02:03 — block #8 har validerats och funktionen `submitBlock` i smartkontraktet har kallats med Merklehash och blocknummer
02:10 — demoskrypten har slutat arbeta, som skickade 1 miljon transaktioner på 32 sekunder
02:33 — noderna började få information om att block #8 har lagts till i huvudkedjan och började utföra 240k transaktioner
02:40 — 240k transaktioner har tagits bort från poolen, som redan finns i block #8
02:56 — submitnodet tog från poolen de kvarstående 760k transaktionerna och började beräkna Merklehash och signera block #9
03:20 — alla noder innehåller 1 miljon 240k transaktioner och tokens
03:35 — block #9 har signerats och skickas för validering till andra noder
03:41 — ett nätverksfel inträffade
04:40 — valideringen av block #9 stoppades på grund av timeout
04:54 — submitnodet tog från poolen de kvarstående 760k transaktionerna och började beräkna Merklehash och signera block #9
05:32 — block #9 har signerats och skickas för validering till andra noder
05:53 — block #9 har validerats och skickats till huvudkedjan
06:17 — noderna började få information om att block #9 har lagts till i huvudkedjan och började utföra 760k transaktioner
06:47 — poolen har rensats från transaktioner som finns i block #9
09:06 — alla noder innehåller 2 miljoner transaktioner och tokens

Test 2

Det finns en gräns på 350k per block. Vi har därför 3 block.

Ursprungligt tillstånd: senaste block #9; det finns 2 miljoner transaktioner och tokens sparade i databasen

00:00 — skriptet för transaktionsgenerering har redan startats
00:44 — 1 miljon transaktioner har skapats och sändningen till noden har börjat
00:56 — submitnodet tog från poolen 320k transaktioner och formar block #10. Vi ser också att 320k transaktioner läggs till poolen på 10 sekunder
01:12 — block #10 har signerats och skickas till andra noder för validering
01:18 — demoskrypten har slutat arbeta, som skickade 1 miljon transaktioner på 34 sekunder
01:20 — block #10 har validerats och skickats till huvudkedjan
01:51 — alla noder har fått information från huvudkedjan om att block #10 har lagts till och börjar applicera 320k transaktioner
02:01 — poolen har rensats på 320k transaktioner, som har lagts till i block #10
02:15 — submitnodet tog från poolen 350k transaktioner och formar block #11
02:34 — block #11 har signerats och skickas till andra noder för validering
02:51 — block #11 har validerats och skickats till huvudkedjan
02:55 — den sista noden har utfört transaktioner från block #10
10:59 - mycket länge högkvalitativa transaktioner med submission av block #9 utfördes i den centrala kedjan, men den blev slutförd och alla noder fick information om detta och började utföra 350k transaktioner.
11:05 - poolen rensades på 320k transaktioner som lades till i block #11.
12:10 - alla noder innehåller 1 miljon 670k transaktioner och tokens.
12:17 - submissionsnod tog 330k transaktioner från poolen och formar block #12.
12:32 - block #12 har signerats och skickas till andra noder för validering.
12:39 - block #12 har validerats och skickats till den centrala kedjan.
13:44 - alla noder har fått information från den centrala kedjan om att block #12 har lagts till och börjar tillämpa 330k transaktioner.
14:50 - alla noder innehåller 2 miljoner transaktioner och tokens.

Test 3

På den första och andra servern har en validerande nod ersatts med en submissionsnod.

Ursprungligt tillstånd: senaste block #84; 0 transaktioner och tokens sparades i databasen.

00:00 - Tre skript har startats som genererar och skickar 1 miljon transaktioner vardera.
01:38 - 1 miljon transaktioner har skapats och började skickas till submissionsnod #3.
01:50 - submissionsnod #3 tog 330k transaktioner från poolen och formar block #85 (f21). Vi ser också att 350k transaktioner tillkommer i poolen på 10 sek.
01:53 - 1 miljon transaktioner har skapats och började skickas till submissionsnod #1.
01:50 - submissionsnod #3 tog 330k transaktioner från poolen och formar block #85 (f21). Vi ser också att 350k transaktioner tillkommer i poolen på 10 sek.
02:01 - submissionsnod #1 tog 250k transaktioner från poolen och formar block #85 (65e).
02:06 - block #85 (f21) har signerats och skickas till andra noder för validering.
02:08 - demo-skriptet för server #3 har avslutats och skickade 1 miljon transaktioner på 30 sekunder.
02:14 - block #85 (f21) har validerats och skickats till den centrala kedjan.
02:19 - block #85 (65e) har signerats och skickas till andra noder för validering.
02:22 - 1 miljon transaktioner har skapats och börjar skickas till submissionsnod #2.
02:27 - block #85 (65e) har validerats och skickats till den centrala kedjan.
02:29 - submissionsnod #2 tog 111855 transaktioner från poolen och formar block #85 (256).
02:36 - block #85 (256) har signerats och skickas till andra noder för validering.
02:36 - demo-skriptet för server #1 har avslutats och skickade 1 miljon transaktioner på 42,5 sekunder.
02:38 - block #85 (256) har validerats och skickats till den centrala kedjan.
03:08 - demo-skriptet för server #2 har avslutats och skickade 1 miljon transaktioner på 47 sekunder.
03:38 - alla noder har fått information från den centrala kedjan om att block #85 (f21), #86 (65e), #87 (256) har lagts till och börjar tillämpa 330k, 250k, 111855 transaktioner.
03:49 — poolen har rensats på 330k, 250k, 111855 transaktioner som har lagts till i block #85 (f21), #86(65e), #87(256)
03:59 — submit node #1 tog 888145 transaktioner från poolen och formar block #88 (214), submit node #2 tog 750k transaktioner från poolen och formar block #88 (50a), submit node #3 tog 670k transaktioner från poolen och formar block #88 (d3b)
04:44 — block #88 (d3b) har signerats och skickas till andra noder för validering
04:58 — block #88 (214) har signerats och skickas till andra noder för validering
05:11 — block #88 (50a) har signerats och skickas till andra noder för validering
05:11 — block #85 (d3b) har validerats och skickats till huvudkedjan
05:36 — block #85 (214) har validerats och skickats till huvudkedjan
05:43 — alla noder har fått information från huvudkedjan om att block #88 (d3b), #89(214) har lagts till och börjar applicera 670k, 750k transaktioner
06:50 — på grund av förbindelseavbrott har block #85 (50a) inte validerats
06:55 — submit node #2 tog 888145 transaktioner från pool och formar block #90 (50a)
08:14 — block #90 (50a) har signerats och skickas till andra noder för validering
09:04 — block #90 (50a) har validerats och skickats till huvudkedjan
11:23 — alla noder har fått information från huvudkedjan om att block #90 (50a) har lagts till och börjar applicera 888145 transaktioner. Vid detta tillfälle har server #3 länge applicerat transaktioner från block #88 (d3b), #89(214)
12:11 — alla pooler är tomma
13:41 — alla noder på server #3 innehåller 3 miljoner transaktioner och tokens
14:35 — alla noder på server #1 innehåller 3 miljoner transaktioner och tokens
19:24 — alla noder på server #2 innehåller 3 miljoner transaktioner och tokens

Hinder

Under utvecklingen av Plasma Cash stötte vi på följande problem som vi gradvis har löst och fortfarande löser:

1. Konflikt i interaktionen mellan olika funktioner i systemet. Till exempel, funktionen för att lägga till transaktioner i poolen blockerade arbetet med submit och validering av block, och vice versa, vilket ledde till en försämring av hastigheten.

2. Det var inte klart hur man skulle skicka en stor mängd transaktioner och samtidigt minska kostnaderna för datatransmission.

3. Det var oklart hur och var man skulle lagra data för att uppnå höga resultat.

4. Det var oklart hur man skulle organisera nätverket mellan noderna, eftersom storleken på ett block med 1 miljon transaktioner tar upp ungefär 100 MB.

5. Arbete i en enda tråd bryter anslutningen mellan noderna när det sker långa beräkningar (till exempel, konstruktionen av Merkle-trädet och beräkningen av dess hash).

Hur hanterade vi allt detta?

Den första versionen av Plasma Cash-noden var en kombination som kunde göra allt på en gång: ta emot transaktioner, skicka och validera block, och erbjuda ett API för att få åtkomst till data. Eftersom NodeJS från början är enstaka trådar, blockerade den tunga funktionen för att beräkna Merkle-träd funktionen för att lägga till transaktioner. Vi såg två lösningar på detta problem:

1. Att köra flera NodeJS-processer, där varje process utför specifika funktioner.

2. Använda worker_threads och flytta delar av koden till trådar.

Till slut använde vi båda alternativen samtidigt: vi delade logiskt upp en nod i tre delar, som kan arbeta oberoende, men samtidigt synkront.

1. En submit-nod, som tar emot transaktioner i poolen och skapar block.

2. En validerande nod, som kontrollerar nodernas giltighet.

3. API-nod — tillhandahåller ett API för att få tillgång till data.

Varje nod kan anslutas via unix-socket genom cli.

Tunga operationer, så som beräkning av Merkle-träd, flyttade vi till en separat tråd.

Således lyckades vi få alla funktioner i Plasma Cash att fungera samtidigt och utan avbrott.

Så snart systemet fungerade testade vi hastigheten och, tyvärr, fick vi otillfredsställande resultat: 5 000 transaktioner per sekund och upp till 50 000 transaktioner i blocket. Vi var tvungna att ta reda på vad som var implementerat felaktigt.

Först började vi testa kommunikationsmekanismen med Plasma Cash, för att hitta systemets maximala kapacitet. Tidigare nämnde vi att Plasma Cash-noden tillhandahåller en unix-socketgränssnitt. Den var ursprungligen textbaserad. JSON-objekt skickades med hjälp av `JSON.parse()` och `JSON.stringify()`.

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

Vi mätte hastigheten på överföring av sådana objekt och fick ~ 130k per sekund. Vi försökte byta ut standardfunktionerna för JSON-hantering, men prestandan förbättrades inte. V8-motorn verkar vara väl optimerad för dessa operationer.

Arbetet med transaktioner, tokens och block genomfördes via klasser. När sådana klasser skapades försämrades prestandan med 50 %, vilket indikerar att OOP inte passar oss. Vi var tvungna att skriva om allt till en ren funktionell metod.

Skrivning till databasen

Inledningsvis valdes Redis som en av de mest prestanda-effektiva lösningarna, som uppfyllde våra krav: en key-value lagring, arbete med hash-tabeller och mängder. Vi körde redis-benchmark och fick ~80 000 operationer per sekund med 1 pipelining.

För hög prestanda optimerade vi Redis ytterligare:

• Vi installerade en unix socket-anslutning.
• Vi stängde av lagring av tillstånd på disk (för tillförlitlighet kan en replika konfigureras och lagring på disk göras i en separat Redis).

I Redis är en pool en hash-tabell, eftersom vi behöver möjligheten att få alla transaktioner med en begäran och ta bort transaktioner individuellt. Vi försökte använda en vanlig lista, men den var långsammare vid utvinning av hela listan.

Vid användning av standard NodeJS-biblioteket Redis fick vi en prestanda på 18 000 transaktioner per sekund. Hastigheten minskade med 9 gånger.

Eftersom benchmarken visade att vi har potential att klara av upp till 5 gånger mer, började vi optimera. Vi bytte bibliotek till ioredis och fick en prestanda på 25 000 per sekund. Vi lade till transaktioner individuellt med kommandot `hset`. På så sätt genererade vi många begärningar till Redis. Idén uppstod att gruppera transaktioner i buntar och skicka dem med ett kommando `hmset`. Resultatet blev 32 000 per sekund.

Av flera skäl, som vi kommer att beskriva nedan, arbetar vi med data med hjälp av `Buffer`, och det visade sig att om vi konverterar det till text (`buffer.toString('hex')`) innan skrivning, kan vi få bättre prestanda. På så sätt lyckades vi öka hastigheten till 35 000 per sekund. För tillfället har vi beslutat att pausa vidare optimering.

Vi var tvungna att gå över till ett binärt protokoll eftersom:

1. Systemet beräknar ofta hash, signaturer osv., och för detta behöver det data i `Buffer.

2. När data skickas mellan tjänster väger binära data mindre än text. Till exempel, när vi skickar ett block med 1 miljon transaktioner, kan datan i textform ta upp mer än 300 megabyte.

3. Ständiga datakonverteringar påverkar prestandan.

Därför har vi baserat oss på vårt eget binära protokoll för lagring och överföring av data, utvecklat med den fantastiska biblioteken `binary-data`.

Som ett resultat har vi fått följande datatyper:

— Transaktion

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

— Block

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

Genom vanliga kommandon `BD.encode(block, Protocol).slice();` och ` BD.decode(buffer, Protocol)` konverterar vi data till `Buffer` för lagring i Redis eller för att skicka till en annan nod och extrahera data tillbaka.

Vi har också 2 binära protokoll för dataöverföring mellan tjänster:

— Protokoll för interaktion med Plasma Nod via 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)
  }
  ```

där:

• `type` — åtgärden som ska utföras, till exempel 1 — sendTransaction, 2 — getTransaction;
• `payload` — data som måste skickas till motsvarande funktion;
• `messageId` — meddelande-id för att kunna identifiera svaret.

— Protokoll för interaktion mellan noder

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

där:

• `code` — meddelandekod, till exempel 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
• `versionProtocol` — version av protokollet, då det kan finnas noder med olika versioner i nätverket som kan fungera olika;
• `seq` — meddelandeidentifierare;
• `countChunk` och `chunkNumber` är nödvändiga för att dela upp stora meddelanden;
• `length` och `payload` längd och själva data.

Eftersom vi har typat datan i förväg fungerar det slutliga systemet mycket snabbare än `rlp`-biblioteket från Ethereum. Tyvärr har vi ännu inte kunnat avstå från det, eftersom smartkontraktet behöver förbättras, vilket vi planerar att göra i framtiden.

Om vi har lyckats nå hastigheten 35 000 transaktioner per sekund, vi behöver också bearbeta dem inom en optimal tid. Eftersom den ungefärliga tiden för blockgenerering är 30 sekunder, behöver vi inkludera i blocket 1 000 000 transaktioner, vilket betyder överföring av mer än 100 MB data.

Till en början använde vi `ethereumjs-devp2p`-biblioteket för att ansluta noder, men det klarade inte av den mängden data. Därför använde vi `ws`-biblioteket och ställde in överföringen av binära data över websocket. Självklart stötte vi också på problem med att överföra stora datapaket, men vi delade upp dem i bitar och nu finns det inga sådana problem.

Dessutom tar skapandet av Merkle-trädet och beräkningen av hash 1 000 000 transaktioner omkring 10 sekunders oavbruten beräkning. Under denna tid hinner kopplingen till alla noder bryta. Det beslutades att flytta denna beräkning till en separat tråd.

Slutsatser:

Faktum är att våra insikter inte är nya, men av någon anledning glömmer många specialister dem vid utveckling.

• Att använda funktionell programmering istället för objektorienterad programmering ökar prestandan.
• Monolit är sämre än en tjänsteorienterad arkitektur för ett högpresterande system på NodeJS.
• Att använda `worker_threads` för tunga beräkningar förbättrar systemets responsivitet, särskilt vid arbete med i/o-operationer.
• Unix-socket är mer stabil än http-förfrågningar.
• Om du snabbt behöver överföra stora datamängder över nätet, är det bättre att använda websockets och skicka binära data uppdelade i bitar, som kan skickas om de inte når fram, och sedan kombineras till ett meddelande.

Vi inbjuder dig att besöka GitHub projektet: https://github.com/opporty-com/Plasma-Cash/tree/new-version

Artikeln skrevs i samarbete med Alexander Nashivan, seniorutvecklare Clever Solution Inc.

Källa: habr.com