Disk partition for skaled

[PolinaKiporenko]

It would be beneficial to have the ability to allocate and distribute different amounts of resources, such as configuring the resource allocation for the state parameter.

[PolinaKiporenko]

@dmytrotkk please add document once feature will be implemented

[payvint]

Default: 1/3 per each(contract storage, file storage, consensus DB)

Total amount of space: 1000 Default: 334, 333, 333

During SKALE chain creation:

1. it should be possible to allocate up to 900 in contract storage and not less than 100
2. It should be possible to allocate up to 800 in file storage and not less than 0
3. It should be possible to allocate up to 900 in consensus DB and not less than 100

Sum of partitions should 1000.

Consensus DB and contract storage are important storages which should not be allocated to zero. But file storage - is not a standard EVM storage - it can be allocated to zero.

Partition represent percentile allocated to specific storage in the total SKALE chain storage

[payvint]

After discussion on 22 May 2024

Decided to make some standard types of partitions with a reason that it hard to maintain and calculate the exact amount of bytes on all nodes and potential accuracy problem after node rotations.

So similar to other computational power and storage providers like AWS, Azure and etc propose options of partitions.

Here are a list of options which should be available:

1. Default(33% of each)
2. No Filestorage, bigger contract storage (66% - contract storage, 33% - consensus DB)
3. No FIlestorage, Max contract storage (90% - contract storage, 10% - consensus DB)
4. Max Filestorage, min contract storage (80% - filestorage, 10% - contract storage, 10% - consensus DB)
5. Min FIlestorage (10% - filestorage, 45% - contract storage, 45% - consensus DB)
6. Min Filestorage, max contract storage (10% - filestorage, 80% - contract storage, 10% - consensus DB)
7. Max consensus DB (90% - consensus DB, 10% - contract storage)
8. Medium consensus DB (66% - consensus DB. 33% - contract storage)

[TheGreatAxios]

Notes from 7/30 Discussion

1. If resources (time/costs) needed for each possible configuration grow linearly then can reduce number of configurations to start down to ~5.
2. If resources needed for each possible configuration are simple to manage then suggestion is to add more pre-defined options to start to reduce need for upgrade later.

Proposed Top Ratios Keys: FS = FileStorage, CS = Contract Storage, CD = Consensus DB

1. Default - 33% FS, 33% CS, 33% CD
2. No FS, Split CS/CD 50%
3. Max CS - 85% CS, 15% CD
4. Max FS - 70% FS, 15% CS, 15% CD
5. Max CD - 20% CS, 80% CD

Why?

1. Perfect for projects looking for the default chain setup where they need a little bit of everything
2. Great for projects looking for put more on-chain and that are not using the Filestorage module
3. Perfect for ecosystems looking to put a lot of information on-chain or data heavy applications. Will require historical nodes to be run sooner
4. Great for for media heavy projects interested in making heavy use of SKALE Filestorage without sacrificing core contract space.
5. Great for ecosystems looking to have a small amount of state but still put a ton of information on-chain. Great for event heavy ecosystems.

[DmytroNazarenko]

@TheGreatAxios , agreed with you. Let’s start with these 5 types of the disk partition

[EvgeniyZZ]

4. Will require indexer node. Storing data in filestorage db == x2 in blockchain db, in case if they need 0 block and other earlier data.

[badrogger]

4. Will require indexer node. Storing data in filestorage db == x2 in blockchain db, in case if they need 0 block and other earlier data.

This types of storage allocation do not make much sence for indexer node since it has no limits for consensus db.

[EvgeniyZZ]

@badrogger You don't get the point. Skale node has limits. In case if we do not setup indexer or archive node from start, we can lost blocks history.