Square Peg in a Round Hole
Developers from the traditional domain are often caught off guard with the hardship in software design on the decentralized blockchain. The most frustrating part is mechanism design. In traditional centralized environment, developers can make strong rational assumptions about human behaviors, so much that one wouldn’t even need to worry about mechanism at all – that’s why most developers are not familiar with this aspect of decentralized blockchain development. Indeed, in a centralized environment, mostly developers wouldn’t need to worry about bad actors beyond access-control, since centralized institutions can deal with bad behaviors in an escalated order externally:
(a) Moderately permissioned and access-controlled systems can deter moderate bad behaviors by external means – the legal system (remember EULA⁵⁸ ?) and the police.
(b) Strictly permissioned and access-controlled systems can employ extra security measures (e.g., security clearance tokens, physical barriers, armed guards) against bad actors that won’t be easily deterred by power institutions.
(c) When all failed, as a last resort businesses could recoup their financial losses through insurance policies, though intangible losses are hard to recoup sometimes, e.g., loss of brand power after a data breach.
(d) Every so often the last resort – insurance policies – can fail in a stupendous fashion⁵⁹. In such situation the real last resort of the centralized system is to simply cheat – bail out the big houses too big to fail and throw everyone else under the bus.
On the decentralized blockchain, developers don’t have any of those external measures to guard against bad behaviors and must build security algorithmically by employing mechanism design themselves.
Last updated