Blockchain je inovativna tehnologija koja obećava poboljšanje mnogih područja ljudskog života. Prenosi stvarne procese i proizvode u digitalni prostor, osigurava brzinu i pouzdanost financijskih transakcija, smanjuje njihove troškove, a također vam omogućuje stvaranje modernih DAPP aplikacija pomoću pametnih ugovora u decentraliziranim mrežama.
S obzirom na mnoge prednosti i raznoliku primjenu blockchaina, može se činiti iznenađujućim da ova obećavajuća tehnologija još nije uspjela ući u sve industrije. Problem je u tome što modernim decentraliziranim lancima blokova nedostaje skalabilnost. Ethereum obrađuje oko 20 transakcija u sekundi, što je nedovoljno za potrebe današnjeg dinamičnog poslovanja. U isto vrijeme, tvrtke koje koriste blockchain tehnologiju oklijevaju napustiti Ethereum zbog njegovog visokog stupnja zaštite od hakiranja i mrežnih kvarova.
Kako bi se osigurala decentralizacija, sigurnost i skalabilnost u blockchainu, čime se rješava trilema skalabilnosti, razvojni tim stvorio Plasma Cash, lanac podružnica koji se sastoji od pametnog ugovora i privatne mreže temeljene na Node.js, koja povremeno prenosi svoje stanje u glavni lanac (Ethereum).
Ključni procesi u Plasma Cashu
1. Korisnik funkciju pametnog ugovora naziva `depozit`, prosljeđujući u nju iznos ETH koji želi uplatiti u Plasma Cash token. Funkcija pametnog ugovora stvara token i generira događaj o njemu.
2. Plasma Cash čvorovi pretplaćeni na događaje pametnih ugovora primaju događaj o stvaranju depozita i dodaju transakciju o stvaranju tokena u skup.
3. Povremeno posebni Plasma Cash čvorovi preuzimaju sve transakcije iz skupa (do 1 milijun) i formiraju blok od njih, izračunavaju Merkleovo stablo i, sukladno tome, hash. Ovaj blok se šalje drugim čvorovima na provjeru. Čvorovi provjeravaju je li Merkle hash valjan i jesu li transakcije valjane (na primjer, je li pošiljatelj tokena njegov vlasnik). Nakon provjere bloka, čvor poziva funkciju `submitBlock` pametnog ugovora, koja sprema broj bloka i Merkle hash u rubni lanac. Pametni ugovor generira događaj koji ukazuje na uspješno dodavanje bloka. Transakcije se uklanjaju iz skupa.
4. Čvorovi koji primaju događaj podnošenja bloka počinju primjenjivati transakcije koje su dodane u blok.
5. U nekom trenutku, vlasnik (ili nevlasnik) tokena želi ga povući iz Plasma Casha. Da bi to učinio, on poziva funkciju `startExit`, prosljeđujući joj informacije o zadnje 2 transakcije na tokenu, koje potvrđuju da je on vlasnik tokena. Pametni ugovor, koristeći Merkle hash, provjerava prisutnost transakcija u blokovima i šalje token na povlačenje, što će se dogoditi za dva tjedna.
6. Ako se operacija povlačenja tokena dogodila s kršenjima (token je potrošen nakon početka postupka povlačenja ili je token već bio tuđi prije povlačenja), vlasnik tokena može pobiti povlačenje u roku od dva tjedna.
Privatnost se postiže na dva načina
1. Korijenski lanac ne zna ništa o transakcijama koje se generiraju i prosljeđuju unutar podređenog lanca. Informacije o tome tko je uplatio i podigao ETH iz Plasma Casha ostaju javne.
2. Podređeni lanac omogućuje anonimne transakcije pomoću zk-SNARK-ova.
Tehnološki skup
- NodeJS
- Redis
- Etherium
- tlo
Testiranje
Tijekom razvoja Plasma Casha testirali smo brzinu sustava i dobili sljedeće rezultate:
- do 35 000 transakcija u sekundi dodaje se u skup;
- do 1 transakcija može se pohraniti u blok.
Testovi su provedeni na sljedeća 3 poslužitelja:
1. Intel Core i7-6700 Quad-Core Skylake uklj. NVMe SSD – 512 GB, 64 GB DDR4 RAM
Podignuta su 3 validacijska Plasma Cash čvora.
2. AMD Ryzen 7 1700X Octa-Core “Summit Ridge” (Zen), SATA SSD – 500 GB, 64 GB DDR4 RAM
Ropsten testnet ETH čvor je podignut.
Podignuta su 3 validacijska Plasma Cash čvora.
3. Intel Core i9-9900K Octa-Core uklj. NVMe SSD – 1 TB, 64 GB DDR4 RAM
Pokrenut je 1 čvor za podnošenje Plasma Cash-a.
Podignuta su 3 validacijska Plasma Cash čvora.
Pokrenut je test za dodavanje transakcija u Plasma Cash mrežu.
Ukupno: 10 Plasma Cash čvorova u privatnoj mreži.
Test 1
Postoji ograničenje od 1 milijun transakcija po bloku. Stoga 1 milijun transakcija spada u 2 bloka (budući da sustav uspije uzeti dio transakcija i poslati ih dok se šalju).
Početno stanje: posljednji blok #7; U bazi podataka pohranjeno je 1 milijun transakcija i tokena.
00:00 — početak skripte za generiranje transakcije
01:37 - Kreirano je 1 milijun transakcija i počelo je slanje na čvor
01:46 — čvor za podnošenje preuzeo je 240 tisuća transakcija iz skupa i formira blok #8. Također vidimo da se 320 tisuća transakcija dodaje u skup za 10 sekundi
01:58 — blok #8 je potpisan i poslan na provjeru
02:03 — blok #8 je potvrđen i poziva se funkcija `submitBlock` pametnog ugovora s Merkleovim hashom i brojem bloka
02:10 — demo skripta završila s radom, koja je poslala milijun transakcija u 1 sekunde
02:33 - čvorovi su počeli primati informaciju da je blok #8 dodan u korijenski lanac i počeo je obavljati 240k transakcija
02:40 - Iz bazena je uklonjeno 240 tisuća transakcija koje su već u bloku #8
02:56 — čvor za podnošenje uzeo je preostalih 760 tisuća transakcija iz skupa i počeo izračunavati Merkle hash i blok za potpisivanje #9
03:20 - svi čvorovi sadrže 1 milijun 240 tisuća transakcija i tokena
03:35 — blok #9 je potpisan i poslan na provjeru drugim čvorovima
03:41 - Došlo je do greške na mreži
04:40 — čekanje na provjeru valjanosti bloka #9 je isteklo
04:54 — čvor za podnošenje uzeo je preostalih 760 tisuća transakcija iz skupa i počeo izračunavati Merkle hash i blok za potpisivanje #9
05:32 — blok #9 je potpisan i poslan na provjeru drugim čvorovima
05:53 — blok #9 je potvrđen i poslan korijenskom lancu
06:17 - čvorovi su počeli primati informacije da je blok #9 dodan u korijenski lanac i počeo izvoditi 760k transakcija
06:47 — skup je očišćen od transakcija koje su u bloku #9
09:06 - svi čvorovi sadrže 2 milijuna transakcija i tokena
Test 2
Postoji ograničenje od 350k po bloku. Kao rezultat toga, imamo 3 bloka.
Početno stanje: posljednji blok #9; U bazi podataka pohranjeno je 2 milijuna transakcija i tokena
00:00 — skripta za generiranje transakcije već je pokrenuta
00:44 - Kreirano je 1 milijun transakcija i počelo je slanje na čvor
00:56 — čvor za podnošenje preuzeo je 320 tisuća transakcija iz skupa i formira blok #10. Također vidimo da se 320 tisuća transakcija dodaje u skup za 10 sekundi
01:12 — blok #10 je potpisan i poslan drugim čvorovima na provjeru valjanosti
01:18 — demo skripta završila s radom, koja je poslala milijun transakcija u 1 sekunde
01:20 — blok #10 je potvrđen i poslan korijenskom lancu
01:51 - svi čvorovi primili su informaciju iz korijenskog lanca da je dodan blok #10 i počinju primjenjivati 320k transakcija
02:01 - skup je očišćen za 320 tisuća transakcija koje su dodane u blok #10
02:15 — čvor za podnošenje preuzeo je 350 tisuća transakcija iz skupa i formira blok #11
02:34 — blok #11 je potpisan i poslan drugim čvorovima na provjeru valjanosti
02:51 — blok #11 je potvrđen i poslan korijenskom lancu
02:55 — posljednji čvor je završio transakcije iz bloka #10
10:59 — transakcija s podnošenjem bloka #9 trajala je jako dugo u korijenskom lancu, ali je završena i svi čvorovi su dobili informaciju o tome i počeli obavljati 350 tisuća transakcija
11:05 - skup je očišćen za 320 tisuća transakcija koje su dodane u blok #11
12:10 - svi čvorovi sadrže 1 milijun 670k transakcija i tokena
12:17 — čvor za podnošenje preuzeo je 330 tisuća transakcija iz skupa i formira blok #12
12:32 — blok #12 je potpisan i poslan drugim čvorovima na provjeru valjanosti
12:39 — blok #12 je potvrđen i poslan korijenskom lancu
13:44 - svi čvorovi su primili informaciju iz korijenskog lanca da je dodan blok #12 i počinju primjenjivati 330 tisuća transakcija
14:50 - svi čvorovi sadrže 2 milijuna transakcija i tokena
Test 3
U prvom i drugom poslužitelju, jedan čvor za provjeru valjanosti zamijenjen je čvorom za podnošenje.
Početno stanje: zadnji blok #84; 0 transakcija i tokena spremljeno u bazi podataka
00:00 — Lansirane su 3 skripte koje generiraju i šalju po milijun transakcija
01:38 — 1 milijun transakcija je kreirano i počelo je slanje na submit node #3
01:50 — čvor za podnošenje #3 preuzeo je 330 tisuća transakcija iz skupa i formira blok #85 (f21). Također vidimo da se 350 tisuća transakcija dodaje u skup za 10 sekundi
01:53 — 1 milijun transakcija je kreirano i počelo je slanje na submit node #1
01:50 — čvor za podnošenje #3 preuzeo je 330 tisuća transakcija iz skupa i formira blok #85 (f21). Također vidimo da se 350 tisuća transakcija dodaje u skup za 10 sekundi
02:01 — čvor za slanje #1 preuzeo je 250 tisuća transakcija iz skupa i formira blok #85 (65e)
02:06 — blok #85 (f21) je potpisan i poslan drugim čvorovima na provjeru valjanosti
02:08 — završila s radom demo skripta poslužitelja #3 koji je poslao milijun transakcija u 1 sekundi
02:14 — blok #85 (f21) je potvrđen i poslan korijenskom lancu
02:19 — blok #85 (65e) je potpisan i poslan drugim čvorovima na provjeru valjanosti
02:22 — 1 milijun transakcija je kreirano i počelo je slanje na submit node #2
02:27 — blok #85 (65e) potvrđen i poslan korijenskom lancu
02:29 — čvor za slanje #2 preuzeo je 111855 transakcija iz skupa i formira blok #85 (256).
02:36 — blok #85 (256) je potpisan i poslan drugim čvorovima na provjeru valjanosti
02:36 — završila s radom demo skripta poslužitelja #1 koji je poslao milijun transakcija u 1 sekundi
02:38 — blok #85 (256) je potvrđen i poslan korijenskom lancu
03:08 — skripta poslužitelja #2 završila je s radom, što je poslalo milijun transakcija u 1 sekundi
03:38 - svi čvorovi su primili informaciju iz korijenskog lanca da su dodani blokovi #85 (f21), #86(65e), #87(256) i počeli primjenjivati 330k, 250k, 111855 transakcija
03:49 - skup je očišćen na 330k, 250k, 111855 transakcija koje su dodane u blokove #85 (f21), #86(65e), #87(256)
03:59 — čvor za slanje #1 preuzeo je 888145 transakcija iz skupa i formira blok #88 (214), čvor za slanje #2 preuzeo je 750 tisuća transakcija iz skupa i blok obrazaca #88 (50a), čvor za slanje #3 preuzeo je 670 tisuća transakcija od bazen i forme blok #88 (d3b)
04:44 — blok #88 (d3b) je potpisan i poslan drugim čvorovima na provjeru valjanosti
04:58 — blok #88 (214) je potpisan i poslan drugim čvorovima na provjeru valjanosti
05:11 — blok #88 (50a) je potpisan i poslan drugim čvorovima na provjeru valjanosti
05:11 — blok #85 (d3b) je potvrđen i poslan korijenskom lancu
05:36 — blok #85 (214) je potvrđen i poslan korijenskom lancu
05:43 - svi čvorovi su primili informaciju iz korijenskog lanca da su blokovi #88 (d3b), #89(214) dodani i počinju primjenjivati 670k, 750k transakcije
06:50 — zbog kvara u komunikaciji blok #85 (50a) nije validiran
06:55 — čvor za slanje #2 uzeo je 888145 transakcija iz skupa i formira blok #90 (50a)
08:14 — blok #90 (50a) je potpisan i poslan drugim čvorovima na provjeru valjanosti
09:04 — blok #90 (50a) je potvrđen i poslan korijenskom lancu
11:23 - svi su čvorovi primili informaciju iz korijenskog lanca da je dodan blok #90 (50a) i počinju primjenjivati 888145 transakcija. U isto vrijeme, poslužitelj #3 već je primijenio transakcije iz blokova #88 (d3b), #89(214)
12:11 - svi bazeni su prazni
13:41 — svi čvorovi poslužitelja #3 sadrže 3 milijuna transakcija i tokena
14:35 — svi čvorovi poslužitelja #1 sadrže 3 milijuna transakcija i tokena
19:24 — svi čvorovi poslužitelja #2 sadrže 3 milijuna transakcija i tokena
Prepreke
Tijekom razvoja Plasma Cash-a susreli smo se sa sljedećim problemima koje smo postupno rješavali i rješavamo:
1. Sukob u međudjelovanju različitih funkcija sustava. Na primjer, funkcija dodavanja transakcija u pool blokirala je rad podnošenja i provjere valjanosti blokova i obrnuto, što je dovelo do pada brzine.
2. Nije bilo odmah jasno kako poslati ogroman broj transakcija uz minimiziranje troškova prijenosa podataka.
3. Nije bilo jasno kako i gdje pohraniti podatke da bi se postigli visoki rezultati.
4. Nije bilo jasno kako organizirati mrežu između čvorova, budući da veličina bloka s milijunom transakcija zauzima oko 1 MB.
5. Rad u jednonitnom načinu rada prekida vezu između čvorova kada se dogode dugi izračuni (na primjer, izgradnja Merkleovog stabla i izračunavanje njegovog hasha).
Kako smo se nosili sa svim tim?
Prva verzija čvora Plasma Cash bila je neka vrsta kombinacije koja je mogla raditi sve u isto vrijeme: prihvaćati transakcije, slati i potvrđivati blokove i pružati API za pristup podacima. Budući da je NodeJS izvorno jednonitni, značajna funkcija izračuna stabla Merkle blokirala je funkciju dodavanja transakcije. Vidjeli smo dvije opcije za rješavanje ovog problema:
1. Pokrenite nekoliko NodeJS procesa, od kojih svaki obavlja određene funkcije.
2. Koristite worker_threads i premjestite izvršenje dijela koda u niti.
Kao rezultat toga, koristili smo obje opcije u isto vrijeme: logično smo podijelili jedan čvor u 3 dijela koji mogu raditi odvojeno, ali u isto vrijeme sinkrono
1. Submission node, koji prihvaća transakcije u skup i stvara blokove.
2. Čvor za provjeru valjanosti koji provjerava valjanost čvorova.
3. API čvor - pruža API za pristup podacima.
U ovom slučaju, možete se spojiti na svaki čvor preko unix utičnice koristeći cli.
Premjestili smo teške operacije, kao što je izračun Merkleovog stabla, u zasebnu nit.
Time smo postigli normalan rad svih Plasma Cash funkcija istovremeno i bez kvarova.
Nakon što je sustav proradio, počeli smo testirati brzinu i, nažalost, dobili nezadovoljavajuće rezultate: 5 transakcija u sekundi i do 000 50 transakcija po bloku. Morao sam shvatiti što je pogrešno implementirano.
Za početak, počeli smo testirati mehanizam komunikacije s Plasma Cashom kako bismo saznali vrhunsku sposobnost sustava. Ranije smo napisali da Plasma Cash čvor pruža unix socket sučelje. U početku se temeljio na tekstu. json objekti poslani su pomoću `JSON.parse()` i `JSON.stringify()`.
```json
{
"action": "sendTransaction",
"payload":{
"prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
"prevBlock": 41,
"tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
"newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
"type": "pay",
"data": "",
"signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
}
}
```
Izmjerili smo brzinu prijenosa takvih objekata i pronašli ~ 130k u sekundi. Pokušali smo zamijeniti standardne funkcije za rad s jsonom, ali izvedba se nije poboljšala. V8 motor mora biti dobro optimiziran za ove operacije.
Radili smo s transakcijama, tokenima i blokovima kroz klase. Prilikom izrade takvih klasa, izvedba je pala 2 puta, što ukazuje da OOP nije prikladan za nas. Morao sam sve prepisati na čisto funkcionalni pristup.
Snimanje u bazi podataka
U početku je Redis odabran za pohranu podataka kao jedno od najproduktivnijih rješenja koje zadovoljava naše zahtjeve: pohrana ključ-vrijednosti, rad s hash tablicama, setovi. Pokrenuli smo redis-benchmark i dobili ~80 tisuća operacija u sekundi u 1 cjevovodnom načinu.
Za visoke performanse, finije smo podesili Redis:
- Unix socket veza je uspostavljena.
- Onemogućili smo spremanje stanja na disk (radi pouzdanosti, možete postaviti repliku i spremiti je na disk u zasebnom Redisu).
U Redisu, skup je hash tablica jer moramo biti u mogućnosti dohvatiti sve transakcije u jednom upitu i izbrisati transakcije jednu po jednu. Pokušali smo upotrijebiti običnu listu, ali je sporija pri istovaru cijele liste.
Pri korištenju standardnog NodeJS-a, Redis biblioteke postigle su izvedbu od 18k transakcija u sekundi. Brzina je pala 9 puta.
Budući da nam je benchmark pokazao da su mogućnosti jasno 5 puta veće, počeli smo optimizirati. Promijenili smo biblioteku u ioredis i dobili izvedbu od 25 k u sekundi. Dodavali smo transakcije jednu po jednu pomoću naredbe `hset`. Pa smo generirali mnogo upita u Redisu. Pojavila se ideja da se transakcije spajaju u pakete i šalju jednom naredbom `hmset`. Rezultat je 32 k u sekundi.
Iz nekoliko razloga, koje ćemo opisati u nastavku, radimo s podacima koristeći `Buffer` i, kako se pokazalo, ako ih pretvorite u tekst (`buffer.toString('hex')`) prije pisanja, možete dobiti dodatne izvođenje. Time je brzina povećana na 35k u sekundi. Trenutno smo odlučili obustaviti daljnju optimizaciju.
Morali smo prijeći na binarni protokol jer:
1. Sustav često izračunava hashove, potpise itd., a za to su mu potrebni podaci u `Bufferu.
2. Kada se šalju između usluga, binarni podaci teže manje od teksta. Primjerice, pri slanju bloka s milijunom transakcija podaci u tekstu mogu zauzeti više od 1 megabajta.
3. Stalna transformacija podataka utječe na performanse.
Stoga smo kao osnovu uzeli vlastiti binarni protokol za pohranu i prijenos podataka, razvijen na temelju prekrasne biblioteke `binary-data`.
Kao rezultat dobili smo sljedeće strukture podataka:
-Transakcija
```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),
}
```
-Blok
```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,
}
```
S uobičajenim naredbama `BD.encode(block, Protocol).slice();` i `BD.decode(buffer, Protocol)` pretvaramo podatke u `Buffer` za spremanje u Redis ili prosljeđivanje na drugi čvor i dohvaćanje podaci natrag.
Također imamo 2 binarna protokola za prijenos podataka između usluga:
— Protokol za interakciju s Plasma Nodeom putem unix socketa
```json
{
type: BD.types.uint8,
messageId: BD.types.uint24le,
error: BD.types.uint8,
length: BD.types.uint24le,
payload: BD.types.buffer(({node}) => node.length)
}
```
gdje je:
- `tip` — radnja koju treba izvesti, na primjer, 1 — sendTransaction, 2 — getTransaction;
- `korisni teret` — podatke koje je potrebno proslijediti odgovarajućoj funkciji;
- `id poruke` — ID poruke kako bi se odgovor mogao identificirati.
— Protokol za interakciju između čvorova
```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)
}
```
gdje je:
- `kod` — kod poruke, na primjer 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
- `versionProtocol` — verzija protokola, budući da se na mreži mogu podići čvorovi s različitim verzijama i mogu raditi drugačije;
- `seq` — identifikator poruke;
- `countChunk` и `broj komada` potrebno za razdvajanje velikih poruka;
- `duljina` и `korisni teret` dužina i sami podaci.
Budući da smo unaprijed upisali podatke, konačni sustav puno je brži od Ethereumove biblioteke `rlp`. Nažalost, još ga nismo uspjeli odbiti jer je potrebno finalizirati pametni ugovor, što planiramo učiniti u budućnosti.
Ako smo uspjeli postići brzinu 35 000 transakcija u sekundi, također ih moramo obraditi u optimalnom vremenu. Budući da približno vrijeme formiranja bloka traje 30 sekundi, moramo ga uključiti u blok 1 000 000 transakcija, što znači slanje više 100 MB podataka.
U početku smo koristili biblioteku `ethereumjs-devp2p` za komunikaciju između čvorova, ali nije mogla podnijeti toliko podataka. Kao rezultat toga, upotrijebili smo biblioteku `ws` i konfigurirali slanje binarnih podataka putem websocketa. Naravno, naišli smo i na probleme pri slanju velikih paketa podataka, ali smo ih podijelili na dijelove i sada tih problema više nema.
Također formiranje Merkleovog stabla i izračunavanje hash-a 1 000 000 transakcije zahtijeva oko 10 sekundi kontinuiranog izračuna. Tijekom tog vremena, veza sa svim čvorovima uspije prekinuti. Odlučeno je da se ovaj izračun premjesti u zasebnu temu.
Zaključak:
Zapravo, naša otkrića nisu nova, ali iz nekog razloga mnogi stručnjaci zaboravljaju na njih tijekom razvoja.
- Korištenje funkcionalnog programiranja umjesto objektno orijentiranog programiranja poboljšava produktivnost.
- Monolit je gori od servisne arhitekture za produktivan NodeJS sustav.
- Korištenje `worker_threads` za teška izračunavanja poboljšava odziv sustava, posebno kada se radi o I/O operacijama.
- unix socket je stabilniji i brži od http zahtjeva.
- Ako trebate brzo prenijeti velike podatke preko mreže, bolje je koristiti websockets i poslati binarne podatke, podijeljene u dijelove, koji se mogu proslijediti ako ne stignu, a zatim spojiti u jednu poruku.
Pozivamo Vas da posjetite GitHub projekt:
Članak su napisali Aleksandar Našivan, stariji programer .
Izvor: www.habr.com