Team members: @Kevin Messali, @Lio, @Clara , @Malo

Architecture

Implementation

Libraries research peer discovery

Concept

The role of an API is to act as a "font door" for front-end applications to access and send information in a secure and standardised way.

Untitled

Detailed explanation

An essential part of a blockchain node is to communicate with other nodes and sync its blockchain copy with all others. If one node adds some blocks onto the blockchain, it must be able to broadcast this change to everyone else provided the block is valid. The rules used for keeping all this in sync are as follows:

• When a node generates a new block, it broadcasts it to the network
• When a node connects to a new other node it asks for its copy of the latest block
• When a node encounters a block that has an index larger than the current known block (meaning it is supposedly newer), it either adds the block the its current chain or requests the full blockchain copy just to be sure

Node communicate with each other by requesting "routes", each with a different purpose. These routes are setup on each node and can be accessed by their address. For instance, such a route may be accessed like this:

<aside> 🔗 xcoin://d84sf3d4f8sf4x.c4jh3shj84bs21fghd8/blocks/ to fetch blocks of the node with a given ECDSA public-key ****address (d84sf3d4f8sf4x.c4jh3shj84bs21fghd8)

</aside>

More specifically, another node may interact with a given node in the following ways:

• List all blocks (/blocks)
• Create a new block with a specific content (/mintBlock)
• List or add peers (connected nodes) (/peers and /addPeers)
• Interact with transaction pool (see about this later)