Here we describe some of the next directions for PoS and design constraints we want to take into account.
Two main desiderata (emerged from PoRep events in Q2):
- Security in the latency model
- Fast unsealing
Security in the latency model
Motivation
TODO
Avenues
- more fine-grained analysis of current constructions (SDR)
Fast Unsealing
Motivation
TODO
Avenues
We want to obtain a construction that works on small windows.
TODO: say why small windows give fast unsealing. Do we have a doc for that?
- VDFs
- Ways we could use VDFs and challenges
- Option: Replace SHA with VDF
- Issue: Current hardware for VDF provide limited throughput
- DRG assumption with better parameteres
- Other assumptions rather than DRG
Speed = (Number of seq encodings that you need to do) X ((time to load data to VDF) + (time to execute VDF))
Assert(Speed = 300ms)
Example 1:
- num of encodings = 1
- time to load data = 0
- time to execute = 300
- This one matches
Example 2
- number of encodings = 1000
- time to load data = 0
- time to execute VDF must be 0.3ms
Another dimension: (unseal window)
given a total amount of data to unseal, you must divide it by the number of windows. This gives the number of cores you need
num_of_cores = target_unseal_size / num_windows
(1 core can handle 32B)
number of VDF cores to unseal
amount of data to unseal
Supranational: (to ask on channel)
- cost of chip
- latency of bringing data to VDF
Note: above could be SHA or the other VDF that Supranational is creating
Goal: understanding if we want to use VDF hw or simply SHA based on these constraints
main problem today:
- relation between d and e (fraction to cancel) is very large (space gap efficiency)
- relation between honest and attacker (sealing efficiency) is also large. Today is around 50 (for latency)
if we want polling time of 300ms then sealing time today is 300x50. Which is bad.
Can we do better constructions so that we can get better numbers (better sealing efficiency).
Q (for example): can increasing the number of connections in the graph help? (e.g. with log or some other indegree)
Ideally (ideally!): we would like to get 1GB in 300ms.
Goals:
- make sealing efficiency as good as possible
- make unseling throughput as good as possible
Route 1:
DRG based solution
Route 2:
non DRG based solution through VDF
(probably to rule out because of constraints of real world VDFs)
Other routes?
- permutation argument
Making a doc:
breaking getting better pos
assumption: timestamp service+not spending too much on cores+ reaching 300ms
routes: basically write what we have above.