Securely Connecting to a Peer2Peer Network means you need to choose a client...
|FullNode||all Blockheaders and each transaction and all full state||~400GB
|all devp2p-messages||sync with only one chain||on servers, where full access is needed|
|Pruned Node||all Blockheaders and each transaction, but keeps the most recent state||~40GB
|all devp2p-messages||sync with only one chain||on servers|
|Light Client||only Blockheaders||~50MB
|all blockheader and status-messages + asking for proof and state when needed||sync with only one chain||on any pc, laptop or at stringer IOT-Devices|
|Remote Client||none - just trusted||0
|only when asked||one chain per url||browser and apps on mobile devices|
|slock.it Client||verification of single result (Merkle-Proof) based on deposit backed signed blockhash||0
|only when asked||connect to multiple chains||browser and apps on mobile devices and even small IOT-Devices|
The Client uses the Incubed-Network to connect to any chain. This Network of Remote Clients offers the features needed in order to run on small IOT-devices.
How does it work?
Incubed connects devices to the Blockchain in order to control access.
Each node may register for multiple chains. The client then can simply define per request which chain should be asked.
Depending on the stored deposit of the nodes and a random seed, the client will choose one or more nodes from the list and send the json-rpc-requests.
The client itself is a very small library easily included in an IOT-device, even if this runs on very low specs. This is possible since the device only needs to be able to send HTTP-Request when needed and doesn’t synchronize each blockheader.
There are 2 versions available:
- JS-Library, which can be fetched using npm and is included in any browser app.
- A bare metal version written in C, ready to be included in even a microcontroller.
- the full blockheader
- in case of an eth_call, the call is analyzed and all needed values from the state are added, including the complete Merkle-Proof.
- the signatures of all validators sign the same blocknumber and blockhash. By doing so, these validators risk their previously stored deposit in case they give a wrong hash, because these signed blockhashes can be used to convict the signer directly in the registry-contract.