Design: Heavy blockchain

[cuteolaf]

Required functions and storage items for the heavy blockchain

Storage

• ComputationalWorkRecords(get_computational_works)
  Mapping of FB node identifiers to the computational works performed by them
• NodeDetails(get_node_info)
  Mapping of FB node identifiers to their details
  • registered_at: block number a node is registered
  • reliable: Whether the node is reliable or not
  • last_check: block number that the node is checked for the last time
• TotalNodes(total_nodes)
  Number of FB nodes registered in the HB runtime.

Extrinsics

• register_node(node_id)
  Register a FB node.
• remove_node(node_id)
  Remove a FB node.
• save_computational_work(records)
  The main interface for the FB nodes to report their computational works to the heavy blockchain.

Functions

• generate_test_data
  Randomly picks a node to be checked and generate required data for a check
  • node_id: The node ID to be checked
  • problem: The maths work to be used for the check
  • checkers: IDs of 3 checker nodes

RPC methods

• is_node_reliable(node_id)
• get_computational_works(node_id, offset, limit)
• generate_test_data
  I don't think this is necessary.

Helpers

• generate_random_number

[Lord-Nymphis]

What is stored in HB runtime vs FB runtime?
(do you find just the computational work hash written in FB blocks or you need to save also some data in FB runtime)? RAW or hash)?

Where is the RAW/hashed that the HB uses for the ComputationalWorkRecords (get_computational_works) coming from?
Is the get_computational_works(node_id, offset, limit) RPC Method directly speaking with the paired node or the HB is taking the data from the what is written in the already authored FB block? (taking data from FB block is probably more sicure for Hashed data the Paired validator could send a different hash from the one that is publicly known, if we are taking data only from him). Not totally sure where get_computational_works(node_id, offset, limit) is taking Raw data from (FB block? FB runtime? FB paired node?). In order to send it to the HB.

Basically, where is save_computational_work(records) taking the data from?

[Lord-Nymphis]

I don't have any comments for NodeDetails . I think that you description is correct.

[cuteolaf]

save_computational_work(records) is an extrinsic that is called by the FB nodes.
Or we can say it is the interface of HB to interact with FB.
We call save_computational_work(records) in the FB runtime to submit the results.

[Lord-Nymphis]

save_computational_work(records) is an extrinsic that is called by the FB nodes.
Or we can say it is the interface HB to interact with FB.
We call save_computational_work(records) in the FB runtime to submit the results.

Ok, but where is the "interface" reading the math_data from (Raw problem and Hashed result)? From the FB runtime of FB or from data provided by a single FB node?

Remember that in the mature infrastructure (after the Grant PoC) the Raw will be directly communicated off-chain by the user and sent to off-chain storage (like IPFS). For the mature infrastructure both the user and the storage are off-chain (and using a worker to peak, I guess).
For the Grant PoC the storage is in the HB runtime, but who is "sending" the RAW data to the HB (or, to put it in another way, where is the RPC reading the RAW data from)?

Is the save_computational_work(records) called by the same FB node/validator that is being checked (doesn't seem so safe)?

Are both Raw and Hashed data saved in the FB runtime?

[cuteolaf]

Ok, but where is the "interface" reading the math_data from (Raw problem and Hashed result)? From the FB runtime of FB or from data provided by a single FB node?
The extrinsic is called by relayers. To be exact, message relayers.
It's not called by the runtime. The runtimes just queue the messages and they are sent to the target chain by relayers.

Basically, a bridge has on-chain components and off-chain components.
On-chain components include the message pallets, relayer pallets and GRANDPA finality pallets.
Relayers are the main off-chain components. We have two types of relayers - header relayers and message relayers.
It's the message relayer, which is centralized and trusted by both blockchains, as well as calling extrinsics of the chains.
The relayers are rewarded.
In that way, we can implement cross-chain communication.
(This is what I learnt from the bridges repo, which took me several days. 😉)

[Lord-Nymphis]

The Relayer so is off-chain?

Do you have some quick docs explaining them?

But where the Relayer is reading taking the Raw and Hashed data from?
(The one that is sending to the HB)?

[cuteolaf]

Yes, it is off-chain.
https://github.com/paritytech/parity-bridges-common/blob/master/docs/high-level-overview.md

[Lord-Nymphis]

And where are we storing it, if it is off-chain?