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