Protocol-based metering for randomness distribution

[CluEleSsUK]

The Filecoin network relies on drand to generate randomness needed by the blockchain. We propose a mechanism through which Filecoin can compensate the drand protocol for the operational costs required to maintain and generate the randomness beacons.

Crucial chain activities, such as leader elections and proving sectors, are dependent on drand randomness beacons. A distributed, high-entropy, unbiased, and publicly verifiable mechanism for generating the randomness beacons is necessary to guarantee the fairness and security of the blockchain. drand randomness beacons are, therefore, an essential part of the Filecoin blockchain.

Problem Statement

The Filecoin protocol does not have a mechanism to support the costs of distributing randomness beacons. However, Filecoin must ensure the continuous operation of drand, a prerequisite for the liveness of Filecoin’s Expected Consensus. In this discussion, we propose various ways to cover the cost of operations of the drand protocol for its value to the Filecoin protocol.

Principles

We consider the following principles when designing a solution:

1. minimal additional burden on Filecoin participants and minimal impact on Filecoin macroeconomics.
2. accurately compensate the drand protocol for its value to Filecoin.

Design Space

The drand randomness beacon enables the FIlecoin chain to progress and thus, enables the Filecoin protocol to generate revenue. To ensure that the drand protocol is funded to continue generating the necessary randomness needed for Filecoin, a portion of the Filecoin protocol revenue can be redirected to drand. There are several ways to accomplish this.

Protocol revenue is generated by burning the base_fee portion of the Gas needed to write messages to blocks. One option is to share a small portion of this protocol revenue and redirect it to the drand protocol instead of burning it. The advantage of this method is that it is simple to implement, and would have minimal impact to Filecoin’s macroeconomics and SPs. However, it can be considered an imprecise approach since it does not transfer value to the drand protocol proportional to what is provided.

An iteration of this is to tie revenue to the drand protocol precisely to its value to Filecoin. The drand protocol provides direct value to the Filecoin protocol through Leader election and sector proving, through the WinningPoST and WindowPoST messages. Since the efficacy of these messages is enabled by the drand protocol, a proposal could be to compensate the drand protocol every time these messages are written to the blockchain. In addition to following the principle of precisely transferring value commensurate with the services provided, this approach has several other benefits:

1. being in line with other proposals that seek to more precisely transfer value; for example, onboarding fees,
2. it decouples and does not create externalities related to base_fee
3. it scales according to usage (fees for WinningPoST scale with block generation frequency). The fees can be set appropriately to satisfy Principle 1

[Stebalien]

Rewarding anyone out of the base fee is probably a non-starter, there's a reason Ethereum switched to burning the basefee.

Any reward here would have to come out of the mining reserve or a new token.

[momack2]

Maybe there's a way to structure this similar to the proposed idea of "storage onboarding fees" instead of a gas fee related burn?

[anorth]

The premise that Filecoin relies on drand is certainly true, as is that there is no consideration for that service. I do agree that, as a network and community, we should seek to rectify that somehow.

I don't think that the proposed mechanism is appropriate.

• Reducing burn is unpalatable to almost all participants. A premise of the referenced onboarding fees idea is to increase burn (but only in line with service/value provided by the Filecoin network to the participants).
• Filecoin network success does and will rely on other things beyond drand. These might make similar claims on protocol revenue. Implementing something for drand could set precedent for a flood of other, similar proposals. If supported, this could add significant complexity right at the core of the protocol. And core protocol governance isn't the right place to have the kinds of debates and tradeoffs involved.
• There are other ways to ensure some consideration for the service. Both FF and PL are currently still vesting significant amounts of the token supply. While this remains true, I find it hard to justify taxing all other holders (who are already "taxed" by the supply inflation, which should then pay for such services).
• After such vesting stops, we will need a new mechanism. This doesn't need to be on-chain, and I would sincerely hope that participants can come together to find an off-chain solution to funding drand and other critical dependencies. That will be much more flexible, and move the messy decisions involved into an appropriately scoped arena.
• If off-chain collective action fails to secure sufficient buy-in (i.e. funds) to pay for what the network needs, maybe we could suffer a single on-chain collection mechanism (not from base fee, but maybe a drip out of future onboarding/service fees). However I would advocate that funds collected should be distributed by some committee sponsored by FF, rather than the distribution be hardcoded into L1 protocol rules.

[CluEleSsUK]

What else than PoRep that is relying on Drand?

As I understand it PoRep, PoSt, WinningPoSt, and expected consensus all rely on drand. I'm not the right person to quantify the implications of using chain generated randomness for each of them, but my initial impression is that chain randomness is biasable and may be a poor fit taking into account MEV considerations

[anorth]

Can we replace drand with chain generated randomness

It's a good question to ask, but I think the answer is "not easily". As well as PoRep/PoST, drand is a critical part of leader election. Filecoin wouldn't have used drand in the first place if we could make these all secure despite biasable or predictable randomness.

[Fatman13]

As well as PoRep/PoST, drand is a critical part of leader election.

This to me, imho, is a single point of failure of Filecoin network security? Drand seems to another attack vector to Filecoin network. What would happen if Drand is compromised?

[CluEleSsUK]

drand is certainly another attack vector, but was included in the threat model for filecoin launch.
Given the randomness is deterministic (and thus unbiasable), the only risks are preimaging all future randomness or denying service.
To that end, it’s not a ’single’ point of failure as it would require compromising (or DoSing) a threshold number of drand nodes (who run on a variety of premises/systems/setups/jurisdictions).

[AnomalRoil]

Also, I want to add here that this needs not be rushed.

Note that randomness and especially on-chain VRF s are difficult to do well: Ethereum did already 2 failed attempts at moving away from their current (biasable) RANDAO system, which was partially responsible for delaying the Eth2 upgrade for so long, etc.

The current model Filecoin relies on is not unheard of: it's also how DFINITY or Sui are doing randomness, and it's battle tested cryptography, hard to hack, even harder to exploit in practice in case of a hack as mentioned above.

So while I think everyone agrees a nice VDF based system would be better and that ideally randomness should be commoditized at the protocol level by blockchains, solutions to do so aren't entirely there.
For instance, a promising VDF system (MinRoot) on which Protocol Labs and Ethereum Foundation both had based a lot of hope to solve the "on-chain randomness is hard when you need consensus on random values without bias and with unpredictability" problem was recently broken, sending many researchers and engineers back to the drawing board.

The goal of this FIP discussion is to open a discussion around how the current VRF system that Filecoin relies on could be funded in the future in a decentralized manner to ensure its liveness, but not in perpetuity, and not in a way that would prevent future replacement with better VDF systems shall these come to life in the coming years (although current horizon for these is more in the 5-10 years timeframe than sooner, unless MinRoot is "patched" somehow).

There is no immediate urgency and FIPs themselves are typically taking a long time to get implemented, and this isn't even a FIP. But it is very valuable to discuss how protocol-level public goods such as drand can be funded by the protocol itself.

[ZenGround0]

Here is a slight tangent from the main point about compensation for filecoin base layer operations:
what if we had a builtin fee charged for evm contract access of randomness? DRAND has a highly differentiated use case in timelock decryption. It would be pretty simple to set up on chain infrastructure and expectations that running syscalls to do timelock decryption incurs a protocol fee to enable continued operation of the network that makes it possible. I'd be all for it anyway.

[ZenGround0]

When it comes to the base layer I'm probably in a minority but I think micro fees from the block reward would not be crazy and maybe acceptable to SPs. I also think forking a proportional sliver from FF and PL original vesting accounts would also not be crazy and would maybe be acceptable to those keyholders.

[ZenGround0]

Rather than taking from base fee we could also strictly add a new gas fee at some fraction of the miner premium that users pay to drand account.

[steven004]

It is true that the Filecoin network relies on drand to generate the necessary randomness for the blockchain and that Filecoin should compensate the drand protocol for its related costs. However, there are a few considerations to keep in mind:

1. General Purpose of DRAND: DRAND is a general randomness generator network with excellent features that can support the entire web3 world. Filecoin is intended to be just one of its clients.
2. Network Load: There are nearly 3000 storage providers (SPs) in the Filecoin network, each fetching randomness from DRAND every 30 seconds. This results in a very low load. With about 20 nodes running in the DRAND network, the transactions per second (TPS) remain in the single digits.

So, what are the costs, and how much should the SPs pay?

Considering a general cloud platform, this level of load is usually free for users. I am not suggesting that the service should be free, but it should be paid for in a way that does not require changes to the core protocol.

Originally, the DRAND team was sponsored by Protocol Labs, and this support possibly continues. Moving forward, this could be supported by Filecoin Foundation (FF) to some degree. Additionally, the DRAND team should explore expanding its business to generate more revenue across the web3 ecosystem, including the Filecoin ecosystem. For instance, projects that require frequent randomness could heavily utilize API services.

Similar services operate effectively without charging fees from the Layer 1 chain, such as data availability (DA) services for Ethereum. DRAND may consider adopt a similar model too.