Scaling FIL+ VC Allocation

Status

🔵

DRI

nikkolasg g

Team

🔮 Protocol Opportunities

Date

Goal

Quarter

2023Q3

OKR

🚨Problem

The FIL+ allocation strategy is slow, costly and does not scale onchain.

💡Goal

Clients can create a single allocation for data that will span multiple sectors.

The primary goal is to reduce the workload/cost on the client and for the SP as well by claiming multiple allocations at once.

🚀 Mechanism

We propose the client use a commitment to represent a set of Piece CIDs (CommPs) that the client wishes to put on Filecoin.

The client can then do a single allocation for this set of CommPs.

The SP can claim set of commPs either incrementally (one by one) or by batches.

Expected gas cost improvements:

📚 Documents

FIP discusison https://github.com/filecoin-project/FIPs/discussions/708

Internal draft: https://www.notion.so/pl-strflt/FIP-Discussion-d45d24322ad14a22a4484e79da70c757

‣

Gas improvements

‣

Overall cost for syscall

10gas/ns is the translation factor
20k overhead per syscall
0.6gas per byte

‣

Overall cost for storage

‣

1300 gas / byte (non indexed storage), 3400 / byte indexed

‣

KZG cost (syscall): approx 10M

‣

pairing check 1ms computation → 10M gas

‣

373microseconds → 373k gas

‣

KZG takes 48 bytes proofs + indices + values

X * 32 * 2 * 0.6 = nothing, 2k for 64 opening

‣

KZG Cost storage: 48B

‣

Merkle Tree cost for 1 opening:

‣

320B * 1300 = 416k

‣

Merkle Tree cost for 64 opening:

‣

320*64*1300 = 26M