Multichain specifications
work in progress
It is designed to be scalable from the start and incrementally improved over the coming years to be robust, attack-resilient, and accurate. The log stores a block for each transaction. This block transcribes the amount of MB's that are up- and downloaded between two peers, identified by their public keys. The peers also keep track of their total up- and download MB's. To prevent the creation of false records, the block is signed by both parties. To prevent people from hiding some of their blocks, and thereby their history, the blocks are chained together to form a blockchain. This means that for each peer there exists a unique, ordered sequence of blocks. This order is indicated by a sequence number for each peer that is included in the block. To prevent peers from replacing blocks in the chain, each block contains a hash that refers to the previous block.
The block then consists of the following fields:
The transaction part, which both peers always have:
- up
- down
- public key requester
- public key responder
The requester part, that contains the multichain status of the requester, and its signature. This is initially only guaranteed to be known for the requester:
- total up requester
- total down requester
- sequence number requester
- previous hash requester
- signature requester (signs all fields above it)
- [Stored, but not send] hash_requester (hashes all fields above it)
The responder part, same as above, but for the responder.
- total up responder
- total down responder
- sequence number responder
- previous hash responder
- signature responder (signs all fields above it (expect hash_requester))
- [Stored, but not send] hash_responder (hashes all fields above it (expect hash_requester))
When a peers wants to create a multichain block, he sends a request message to the peer it has interacted with. This request contains the transaction part and the requester part, and is already signed by the requester. The will also store this block in its incomplete form. If all goes well, this block will be replaced by the complete block.
The responder will receive the request, and perform some validation steps to verify that the request accurately describes the current interaction, and that the block is consistent with (the available knowledge of) the existing chain of the requester. If the responder agrees with the requester, he will add the responder part, sign the block, store the block, and send it back to the requester for him to store.
The signing of blocks occurs between to peers over the internet. This means it there can be a significant delay between the sending of a request and the receiving of a request. Because a peer should be able to interact with a large number of peers simultaneously, the chain should be able to be extended while waiting for a response. In order to do this the requester of a block should refer to the previous block using the hash of only his part since this is the only information guaranteed to be known at this point. This is the reason for the existence of the "hash requester" field. The "previous hash responder" fields refers to either the "hash requester" or "hash responder" of the previous block of the responder, depending on whether the current responder was a requester or a responder in the previous block. The same is true for the "previous hash requester"; The "previous hash requester" fields refers to either the "hash requester" or "hash responder" of the previous block of the requester, depending on whether the current requester was a requester or a responder in the previous block.