-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define a sane "max randomness" lookback limit #1118
Comments
Alternatively, we can just charge proportional to the lookback distance. |
cc @anorth who has thought about this in the past. |
I do think there should be a fixed limit, and whatever's required for our current sector onboarding seems like a reasonable guide to start. |
Would err on the side of conservativeness, so what @anorth proposed makes sense. We can always expand later, can never constrict. |
So, the question is: What is required. @ZenGround0 any ideas? |
I'm punting this to M2.2. We've disabled the related precompile, so this is no longer a critical issue. |
One weird but useful benefit to arbitrary or at least longer term lookback is the ability to rerun previous PoReps without trust. There are situations where this might be useful. But If we actually wanted to support this we'd probably want to use an accumulator and have the syscall take a proof. We could do that fairly easily in an upgrade too. As @anorth says above the easiest safe thing to do is restrict on current PoRep lookback limts. |
After thinking about this a bit... I think we really can just allow arbitrary lookbacks without too much difficulty, what we need is:
This may also be important with respect to things like time-lock encryption. |
For drand timelock, the drand randomness is self-certifying by BLS signature verification. Arbitrary ticket randomness lookup would require the whole chain of block headers (which we do right now AFAIK), but I'm not sure if we want to lock ourselves into it.
The optimal data structure for this would be skip-list, allowing for arbitrary lookback using See https://github.com/Kubuxu/go-skiplist-ipld/, which I developed as a base to enable a decentralised Drand randomness index. |
Yeah, I guess you're right. We can force users to send this information from off-chain if they need infinite lookback.
I think that depends on how much data this is. But my understanding is that it's "not much".
That's assuming we need to walk the chain on-disk. @arajasek found that it's pretty reasonable to simply cache chain info in memory so having an actual skiplist embedded into the chain isn't really necessary. |
Yes, but this full cache has quite a long and unpredictable warmup time. If we want to expose it, we would have to require everyone to pre-warm it on every startup, at which point it will be too slow and annoying so we will be looking for on-disk solution. We also don't have to embed the skip list into the chain, you can think of it as a side-chain/separate IPLD-based index. |
A few minutes isn't terrible... but yeah, an on-disk solution is probably a good idea (but annoying to maintain).
If we're doing things locally, I'd just maintain an on-disk by-epoch index. We actually already do this, we just don't keep track of the canonical chain. All that's left would be to mark specific epochs as "finalized". |
Ok, discussed this with @arajasek. The short-term solution is a simple in-memory lookup table and a lookback limit (2-3 days?). |
Scott's thoughts: To resolve uncertainty around what's best to do, focus on "what use case requires a more complicated answer than 'You can only lookup past 1000 epochs'". |
The current answer is prove-commit, which I'm pretty sure is 30 days and change (86,550 epochs). This could be solved by requiring storage providers to submit two pre-commit messages: one pre-commit, and one to confirm pre-commit randomness. We can't do it in one message as we need to wait a delay after the first message for security. |
Unassigning Steb so it looks pretty in my sprint tracker :P |
From our discussion yesterday:
In the future, we'd like to change this to be a constant cost but that requires client guarantees we can't make right now. |
Closing this since we have a good plan now. Next steps are FIP and gas pricing change. |
The builtin actors currently enforce their own limits, but we need to set a global one.
The text was updated successfully, but these errors were encountered: