Decentralisation roadmap
Last updated
Was this helpful?
Last updated
Was this helpful?
(WIP) 🚧🛠️
Fluidity worker/contract architecture - centralised, little trust in the randomness generation <- we are here
Distributed worker/contract architecture - publicly sourced randomness from a multiparty computation with leader election, competition with batching powered by members of the community
100% decentralised architecture including randomness generation, zero dependency on Fluidity services
We're at stage 1. We built the second stage of the architecture in the past using Merkle Proofs mixed with randomness sourced off-chain (random.org), including signature verification and a suite of protections to prevent abuse that happen entirely on-chain. We found in practice that bar building an off-chain platform (sidechain?) it was too unreliable given the : instant rewards. We found that a fork would significantly degrade the user experience overall.
We found that Solana lacks cryptographic primitives well understood by our team (and the community at large following discussions in some cases) to build trustworthiness into the platform without validating the product. Fluidity takes steps to ensure we properly maintain the systems by to "peer behind the curtain" and to quarantine large rewards until the second stage is built.
Stage 2 is possible to build with a relaxation of the instant rewards law, with hyper efficient markets, with an off-chain platform and with something in between. It's also possible to build with RANDAO and the beacon chain.
We found that an on-chain approach to randomness violates the : no extra fees. With the randomness generated by the beacon chain being accessible from userspace, we can generate randomness entirely on-chain including the leader election.
When Fluidity was started and we begun experimenting with approaches, the timing of the merge was unknown and historically RANDAO has been shown to be biasable - given the number that could be possibly won in one foul sweep we didn't eliminate the possibility that an attacker would understand one stage of the VDF enough to attack the second.
A natural suggestion would be to use a service provided by Chainlink (an oracle or a VRF) but we found with the latter we would violate the We didn't investigate the former. The problem with a large fixed number that could be won instantaneously means there's a way to estimate within a margin of error the amount that would be needed to drain the amount instantly. So there's a large incentive to "move the needle" in markets with leveraged positions then close them out following draining the prize pool.
Stage 3 is possible to build following solving some of the randomness challenges and the development of the token and incentive program overall. The three laws make this system a challenge, but by relaxing the instant reward constraint in attacker-led scenarios and matching large payouts with a market (a la Boba) it can be done. We can guarantee liveliness with the token and the staking incentive system and generate the graph needed for the longterm infrastructure including the sell-down of accumulated randomness.
There are other considerations in our decentralisation roadmap including:
IPFS hosting everything
We've since spent some time ideating these in a pair of whitepapers which explores these further:Whitepapers
Stay tuned to this page and look forward to an announcement.