The design in previous sections assumes an already established reputation system and ensures that as long as the reputation system is sufficiently accurate—i.e., the reputation of a reputation party is close to his probability of being honest—the protocol will behave according to its abstract specification, i.e., it will securely realize a decentralized transaction ledger. Thus our cryptographic analysis is orthogonal to the mechanism that establishes, updates, and extends the reputation system. Nonetheless in this section we discuss a number of directions and associated research questions that relate to the deployment and rational analysis of the system.

The incentive structure. By design, ΠBCPoR/PoS assumes a very simple incentive structure to characterize the reputation parties’ rationality: Reputation parties should always prefer higher reputation values. Below, we make this simple incentive structure more concrete, by utilizing the financial incentives from Möbby as a cryptocurrency. We will give an overview of how we will incentivize honest behavior by tying the parties’ reputation with their actual stake/money in the system, as well as their future rewards. In particular, we will (1) tie the reputation of an active consensus participant to a deposited collateral, and (2) tie the reputation gained (and thus future rewards from creating blocks) to the parties’ behavior.

Collateral for becoming an active consensus participant Our current design will require reputation parties who will be actively participating in the PoS/PoR to lock part of their stake (their coins) as collateral.

Normalizing reputation values. Additionally, the following mechanism can ensure that reputations are not artificially inflated¹⁵ : Periodically, an amortization factor will be applied to all reputations, so that their relative value changes marginally, but their absolute value is preserved within limits that represent probabilities, i.e., stays between 0 and 1.

Updating reputation system according to the parties’ behavior. A mechanism taking advantage of transaction fees and rewards will be associated with the parties’ reputation to ensure that parties prefer to increase their reputations. We apply the following reputation scheme to ensure that reputation parties with the above preferences: (1) are sufficiently available, and (2) do not attempt to disrupt the systems consistency (and create forks):

• Declaring availability: Reputation parties can declare availability for future slots. A party declaring themselves as available will be entered in the PoR consensus lottery and, when selected, they will receive reputation increase (along with financial rewards) accordingly if they honestly participate in the protocol. However, a party’s reputation will decrease drastically if they declare themselves available but do not participate. We remark that this second property is trivial to ensure assuming instant-delivery channels—as everyone can decide in round ρ whether or not a party sent its round ρ - 1 message—but it is tricky in the bounded-delay network, as a party might have sent its message, which is delayed (by the adversary) in the network. One can rectify this by waiting sufficiently long—at least as much as the network delay Δ—to decide on the reputation, but this incurs the risk of a malicious party abstaining in the protocol and then quickly delivering a message for the reputation update mechanism. Instead we will use the blockchain itself to implement a voting protocol for parties to ensure that a message was contributed by a reputation party on the slot it volunteered for. Although not directly related with the cryptographic design of the system, the game-theoretic analysis of such a mechanism is part of our team’s research agenda. An initial model of the incentive structure for declaring availability, can be found in App.  G.2 .
• Misbehavior: If any party presents on the blockchain verifiable evidence of some reputation-party cheating (e.g., two conflicting signatures from that party for the same slot) then the reputation of that party is set to 0 by anyone that views this evidence. This means that the related reputation party is effectively removed from the reputation set.

6.1 Initializing and Endorsing Reputation

In order to ensure a stable launch, in the first phase of mainnet launch, only core nodes run by the Möbby team will be responsible for running the PoR protocol. As such, no block rewards will be distributed in this phase. After this first phase of mainnet, we will move towards decentralisation, allowing a gradual increase of fraction of blocks being chosen outside of core nodes via our PoR lottery. In the decentralisation phase, parties will be able to endorse any reputation party. Block rewards will be split among the block creator as well as those who endorsed the block creator. The details and formal specification of endorsement and block rewards are to be released following the whitepaper.

6.2 Dynamically Joining Parties

The static reputation assumption makes it easy to join the protocol as a user: In order for a user (who knows the current value of the clock) to read the blockchain he simply needs to query any of the parties for receiving all ρ blocks, where ρ is the current round, and check that all blocks are valid, i.e., they are properly signed by a majority of parties in a committee that is the result of running the lottery on the previous blocks. Extending this to dynamic reputation requires the use of key-evolving signatures and also requires all the reputation updates to be recorded on the blockchain before taking effect. A complete treatment of that case is left as a future research direction.

6.3 Real-World Recommendation Systems and External Sources of Reputation

In addition to the above mechanism, our reputation-based blockchain has, as discussed in our introduction, the potential to disrupt the recommendation systems industry which currently uses opaque algorithms to decide recommendations and rankings. An interesting research direction in the intersection of AI and cryptography/security is to take as input to the reputation calculation the rankings of existing recommendation systems, e.g., Amazon, Yelp, Ebay, etc., to develop a universal, transparent, and decentralized recommendation system running on our blockchain. The high throughput of our protocol will be instrumental in linking on-chain pointers to potentially externally stored, yet immutable reviews.