Skip to content
Simon Jentzsch edited this page Jun 19, 2018 · 3 revisions

This is the main wiki for the Incubed.

INCUBED = A trustless INcentivized remote Node Network = IN3

Nodes

The IN3-Network is a decentralized permissionless Network, where anybody can setup a node and register this node in a smart contract, called the registry. Nodes should also store a deposit, which they would lose, if they are signing wrong blockhashes. This will lead to more trust and more request will lead to more payment.

Each node may register for multiple chains. The client then can simply define per request which chain should be asked.

Client

The client acts stateless. The only information it needs to store and update is the list of nodes in the network. This list is taken from the registry-contract on the blockchain. 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 a IOT-device, even if this runs on very low specs. This is possible since the device only need to be able to send HTTP-Request if needed and not synchronize each blockheader. There are 2 version available:

  • JS-Library, which can be fetched using npm and included in any browser app.
  • A bare metal version written, ready to be included in even microcontroller (planned)

Proof

The Client is sending a JSON-RPC-Request to a randomly choosen node including a optional list of validator-nodes. The Node will execute the Request, and prepare all needed data needed in order to verify the result. In most cases this means:

  • the full Blockheader
  • in case of eth_call, the call is analysed and all needed values from the state will be added including the complete Merkele-Proof.
  • the signatures of all validators signing the same blocknumber and blockhash.

By doing so, these validatores would risk their previously stored deposit in case they would give a wrong hash, because these signed Blockchashes can be used to convict the signer directly in the registry-contract. The client can then verify the response by replaying this transaction in a local evm and validate all values by using the Merkele-Proofs.

For more Details, see Etherem Verification and MerkleProofs.