Penalty in Distributed systems and Trust-risk mitigation

Blockchain is based on trustless architecture where users don’t have to trust people except an infallible mathematical algorithm. However, blockchain is extremely dumb when it comes to real-world data extraction and execution, and that’s a feature, not a bug. It keeps blockchain away from any centralized, mutable database, further keeping the blockchain as decentralized as possible. There are oracles. Oracles may help Blockchain in making sense of these real-world data but since the data can be stored into any centralized server, it’s prone to manipulation and central point of failure, thus further making it unreliable.

Bramble’s vision is to put Blockchain tech into the hands of non-tech people around the world. At Bramble, most of the data is being fetched by these so-called oracles into the database, which helps the algorithm in calculating the final rewards for the users playing the game, which is stored in a centralized server. As explained above there are central points of failures (CPoF) in this approach, notably:

  1. Fallacious data relay to oracles
  2. Non-Sybil resistance by unidentifiable actors
  3. Routing attacks for user-game server
  4. Freeloading attack

We’ve identified solutions to these attacks, which will be helpful in the short term until we completely migrate to a decentralized system through a progressive decentralization approach. Please note that these approaches are temporary so, As counter-intuitive as it may sound but to mitigate the CPoF, we need to approach this problem with a hybrid centralization-decentralization approach.

  1. Penalty slashing – Developers have to deposit a fixed amount of tokens into Bramble’s smart contract escrow which will prevent them from any malicious behaviors as the deposit will be prone to slashing penalty.
  2. Block-time based inflation – A fixed amount of tokens to be emitted per-game, per-user based on the network activity and block-time. A global maximum for each game instance to be implemented for Sybil resistance and routing attacks.
  3. SafetyNet API – Google’s safety net API protects any app from Sybil and freeloading attacks. https://developer.android.com/games/develop/safetynet
  4. Custodial wallet with 2FA – This is a user side implementation that will help the funds in user’s accounts secure from frauds. That also keeps the funds in our control which can later be blocked should we encounter any malicious behavior.
  5. Instance-reward limit – As discussed in the algorithm doc, each game instance has an upper limit of 1000 points (at least 5 achievements). A game can’t have points as a whole. However, developers can purchase additional points for more incentivization.
  6. Resource and reputation – And last but not the least, malicious behavior degrades the reputation of a user or game as a whole and (as found in the algorithm doc), which exponentially slashes their rewards per instance and reputation until it reaches zero and the user or game is kicked off from the network.

One-liner

“We have identified the issues regarding trust and have found potential solutions that prevent the user from being malicious and motivates them to stay honest. Approaches like penalty slashing, which slash the funds and reputation in an exponential manner, further freezing their account on the network, which makes their funds unusable.”

0 Shares:
You May Also Like
Read More

How to Lie with Statistics?

In this post, I will outline errors when it comes to the interpretation of statistics, and how these errors may create incorrect conclusions. It also shows how statistical graphs can be used to distort reality.