Ethereum

Co dalej? Czyli o klientach i o planach.

Tomasz Drwięga

@tomusdrw

Parity Technologies

21.04.2018, Wrocław

Najbliższe spotkanie na początku maja.

https://www.meetup.com/Wroclaw-Blockchain-Meetup/

Parity Ethereum

Parity Bitcoin

Polkadot

IPFS, Whisper, Secret Store

 

+ wiele więcej

Nodes?

  • Thin Node?
  • Light Node?
  • geth --fast Node?
  • parity --warp Node?
  • Pruning / Garbage collection?
  • Archive Node?

Extra: Full Node, FatDB, Tracing

Rozmiar i czas

Czas Synchronizacji Rozmiar
Bazy Danych
Thin Node 0 0
Light Node 3 min 3 MB
geth --fast 12 h 60 GB+
parity --warp 3 h (12 h) 6 GB (60 GB)
Pruned Node 36 h 60 GB
Archive Node 36 h 600 GB

* Szacunkowe wartości na sprzęcie konsumenckim z SSD

Rozmiar i czas

Czas Synchronizacji Rozmiar
Bazy Danych
Thin Node 0 0
Light Node 3 min 3 MB
geth --fast 12 h 60 GB+
parity --warp 3 h (12 h) 6 GB (60 GB)
Pruned Node 36 h 60 GB
Archive Node 36 h 600 GB

Full nodes

Blockchain?

Block 1

Block 2

Block 3

Transactions

Transactions

Transactions

Blockchain?

Block 1

Block 2

Block 3

Transactions

Transactions

Transactions

(Header)

(Header)

(Header)

(Body)

(Body)

(Body)

State?

Block 1

Block 2

Block 3

Transactions

Transactions

Transactions

(Header)

(Header)

(Header)

(Body)

(Body)

(Body)

State after 1

State after 2

State after 3

State?

Block 1

Block 2

Block 3

Transactions

Transactions

Transactions

(Header)

(Header)

(Header)

(Body)

(Body)

(Body)

State after 1

State after 2

State after 3

Merkle root of the state

Dan Finlay's Intro to Ethereum: https://youtu.be/-SMliFtoPn8

Co Przechowujemy? 

Czas Synchronizacji Rozmiar
Bazy Danych

Co w bazie?
Thin Node 0 0
Light Node 3 min 3 MB
geth --fast 12 h 60 GB+
parity --warp 3 h (12 h) 6 GB (60 GB)
Pruned Node 36 h 60 GB
Archive Node 36 h 600 GB

* bodies = bodies + receipts

Archive Node

Sync speed: Slow | State access: Fast | Security: High

  • Synchronizacja i weryfikacja wszystkich bloków
  • Dostęp do historycznych stanów
  • Używany przez firmy budujące usługi na Ethereum (np. Etherscan)


Np.:
Geth --gcmode=archive
Parity --pruning=archive

Pruned Node

Sync speed: Slow | State access: Fast | Security: High*

  • Synchronizacja i weryfikacja wszystkich bloków
  • Dostęp do kilku ostatnich stanów
  • Potencjalny problem: re-organizacje


Np.:
Geth 1.8+
Parity --pruning=fast

Geth --fast

Sync speed: Medium | State access: Fast | Security: Medium

  • Synchronizacja bloków bez uruchamiania transakcji
  • Synchronizacja najnowszego stanu
  • Później zachowuje wszystkie stany
  • Problem: "Czy to na pewno dobry stan?"


Np.:
Geth --fast

Parity --warp

Sync speed: Fast | State access: Fast | Security: Medium

  • Synchronizacja najnowszego stanu + 30k ostatnich bloków
    (obecnie około 6GB danych dla mainnet)
  • Następnie synchronizacja historycznych bloków
  • Problem: "Czy to na pewno dobry stan?"


Np.:
parity --warp-barrier 5600000

Light Node

Sync speed: Extreme | State access: Medium | Security: Medium

  • Szybka synchronizacja nagłówków
  • Dostęp do stanu przez odpytywanie pełnych węzłów
  • Możliwość weryfikowania Merkle-Proof
  • Problem: "Skąd wziąć dane?"


Np.:
Geth --syncmode=light
Parity --light

Dan Finlay's Intro to Ethereum: https://youtu.be/-SMliFtoPn8

Thin Node

Sync speed: Instant | State access: Fast | Security: None+

  • Dostęp z przeglądarki
  • Dostęp do najnowszego stanu
  • Brak potrzeby synchronizowania
  • Dane dostarczane z centralnego serwera
  • Problem:  ¯\_(ツ)_/¯

 

Np. MyEtherWallet, MyCrypto

Podsumowanie

Sync State Acc. Security
Thin Node Instant Fast None
Light Node Extreme Medium Medium
geth --fast Medium Fast Medium
parity --warp Fast Fast Medium
Pruned Node Slow Fast High
Archive Node Slow Fast High

Co dalej?

  • State jest coraz większy (6GB)
  • Przetwarzanie bloku jest czasochłonne (1s)
  • Synchronizacja jest wolna (36- h)
  • Blockchain jest już długi (40GB)
  • Raz zapisane dane zostają na wieki
  • Transakcji coraz więcej

Dla userów

  • Rozwój Light Clients
  • Możliwość uruchamiania Light Client w przeglądarce (kompilacja do WebAssembly)
  • Możliwość uruchamiania Light Client na telefonach (iOS, Android)
  • Problem: Dlaczego ktoś miałby mieć full node?

ZachEty dla Full Node

 

  • Problem: Proof of Custody
  • Problem: Mikropłatności

Co Dalej?

Najistotniejsze problemy:

  • Zmniejszenie rozmiaru bazy (stanu)
  • Szybkość przetwarzania transakcji
  • Koszt transakcji
  • Ograniczenie "wydatków" na bezpieczeństwo sieci i zużycie energii
  • Komunikacja między-sieciowa

Network Bridges

Rozwiązanie dostępne w krótkim terminie

 

 

Main Net

 

 

 

 

Other Net
(Kovan)

 

 

Lock ETH

Create
"W-ETH"

Burn
"W-ETH"

Unlock ETH

Technologia: parity-bridge
Bezpieczeństwo: Proof of Authority

"sieć heterogeniczna"

Easy Parallelizability

Rozwiązanie dostępne w średnim terminie

https://github.com/ethereum/EIPs/issues/648

  • Transakcje deklarują, których części stanu potrzebują
  • Niezależne transakcje można uruchamiać równolegle
  • Stan można przygotować przed samym uruchomieniem transakcji

BlockChain Rent

Rozwiązanie dostępne w średnim terminie

https://github.com/ethereum/EIPs/issues/35

  • Za przechowywanie danych w stanie trzeba płacić cyklicznie
  • Kontrakty płacą za "przestrzeń dyskową"

Payment Channels

Rozwiązanie dostępne w średnim terminie

  • Rozwiązanie mikropłatności
  • Raiden - Odpowiednik Lightning Network
  • Blokujemy środki na głównym łancuchu,
    potem wymieniamy się odpowiednimi transakcjami między sobą, ale ich nie publikujemy
  • Główny łańcuch = arbiter

State Channels

Rozwiązanie dostępne w średnim terminie

  • Bardziej ogólne niż płatności
    (czyli smart kontrakty)
  • Otwieramy kanał podobnie do Payment Channels, wewnątrz kanału zachodzą dowolne zmiany
  • Główny łańcuch = arbiter

Plasma

Rozwiązanie dostępne w średnim terminie

 

 

Main Net

 

 

 

Plasma Chain
(Side Chain)

 

 

Lock ETH

Acknowledged

Escape

Unlock ETH

Smart Contracty mogące sprawdzać "Fraud Proof"

Plasma

Polkadot

Rozwiązanie dostępne w średnim terminie

 

Ethereum

Main Net

 

 

Bitcoin

Mainnet

 


Polkadot Relay Chain
 


Polkadot ParaChain

 

Bridge

Bridge

eWASM

Rozwiązanie dostępne w długim terminie

  • Wymiana maszyny wirtualnej EVM na WebAssembly (WASM)
  • Lepsza szybkość działania i więcej "pracy" w rozwój
  • Możliwość pisania kontraktów w dowolnym* języku

Bridge + PWASM

Rozwiązanie dostępne w krótkim terminie

  • Wersja WASM dla Polkadot i testnetu Kovan
  • Lepsza szybkość działania i więcej "pracy" w rozwój (współpraca z Mozilla)
  • Możliwość pisania kontraktów w dowolnym* języku
  • Możliwość interakcji między kontraktami EVM i WASM

SHARDING

Rozwiązanie dostępne w długim terminie

  • Sieć homogeniczna (wszystkie części takie same)
  • Podział stanu na części (shards)
  • Możliwość przetwarzania tylko pewnej części
  • Ale wciąż pełna interakcja z innymi częściami

StateLess Clients

Rozwiązanie dostępne w długim terminie

  • Transakcje zawierają potrzebne fragmenty stanu
  • Wykonanie transakcji polega na weryfikacji stanu i uruchomieniu
  • Większość nodeów nie potrzebuje w ogóle stanu
  • Ale to kto ma pełny stan?

https://ethresear.ch/t/the-stateless-client-concept/172

Dodatkowe
Technologie

Casper FFG (PoS)

Rozwiązanie dostępne w średnim terminie

  • Finalizacja transakcji (ekonomiczna)
  • Hybryda PoS + PoW
  • Z czasem zmniejszająca się rola PoW
  • Testnet już działa

Account Abstraction

Rozwiązanie dostępne w średnim terminie

  • Kontrakty mogą płacić za transakcje użytkowników
  • Dowolne metody replay-protection
  • Dowolne schematy authentykacyjne (nie ECDSA)
  • Potencjalnie możliwość opłaty transakcyjnej w tokenach

Pytania?

Tomasz Drwięga

@tomusdrw

Parity Technologies

Made with Slides.com