[Abandoned doc.] Constraints Document for New PoS (Q3 2023)

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.