Introduction

To make users more intuitively to understand how the underly algorithms work, we provide this on-chain prototype smart contract to show the effects of the underlying mechanisms implemented in ink!.

Index

• Router selection mechanism
• Message verification mechanism

Demos

Router selection

Effects

A statistic result of this algorithm is as below:

• The Credibility Ratio is the probability distribution of the routers to be selected as working nodes according to their credibilities. In product implementation, this probability will be calculated considering both credibility(reflecting history work) and staking(reflecting economics incentives).
• The selected results is the result by calling selection_statistic.

We can see in the picture above, that the theoretical value of probability distribution is nearly the same as the real result of the selection algorithm.

Usage

Deploy

Try the following operations with polkadot.js.app. Or deploy the smart contract on a local substrate node.

• Method one: Launch a local substrate node and deploy the algorithm_prototype.contract on it to try.
• Method two: Use the deployed algorithm_prototype.contract on TEST ROCOCO & PARACHAINS : Contracts(1002). The address is 5GMZtFKF1r2mfSrDg4QF7sdQr9bY8wyLC571VPV9dhYLAufY, with the related metadate.

Operation

• Call randomRegisterRouters to register simulation off-chain routers. To make this test simple, you can register enough at a time with any credibilities you want in the parameter vector. The id of the routers will be dynamically created. The registered routers can be checked by calling getRegisteredRouters . The result will be something like this:

• Call selectionTest to randomly choose n routers according to their credibility. Note that the result will be the same if operates in the same block. The result will be like this:

• Call selection_statistic to provide an intuitive validation of the 'Probability distribution' results of the router selection algorithm. Parameter n is the number of sampling times. The result will be like this:

Message verification

In message verification algorithm prototype, we descide the limitation number of message copies to verify a message by a system paremeter self.msg_copy_count. When enough copies have been delivered, simu_message_verification will be called dynamically.

And the number determines how many routers one message needs to be delivered parallelly, which will be configured by users through SQoS settings in the product implementation.

Usage

• Call setSysinfo to set message-verification related system paremeters and getSysinfo to check the value.
  • 1 is the number of the message copies needed for one message to be verified
  • 2 is the credibility threshold, a factor of 10,000 was multiplied in order to calculate on-chain. 7000 means that one message copy will be accepted only if it has at least 70% of the aggregated weight according to credibilities.

• Call simuSubmitMessage to submite message copies manually. Note that message copies belong to the same message only if they have the same IReceivedMessage::id and IReceivedMessage::from_chain.

• The submitted message copies can be checked by simuGetMessage .

• When enough message copies are submitted, simu_message_verification will be called internally. The result will be cached in order to be checked manually and an event VerifiedMessage will be emitted to show the result, but the result event need to be decoded by Polkadot.js.

• Check the cached verification result by getVerifiedResults.

There are three contents of the submitted message copies. The first one is submitted by routers 0, 1, and 2. The second one is submitted by router 3. And the third one is submitted by router 4. The aggregated credibility weights are 240, 60, and 50 respectively. As 240 is only 68%(nead 70%) of the total 240 + 60 + 50 = 350, the verification, in this case, does not pass, so none of these three copies is accepted.