How does it support Mutable Data?

BNB Greenfield
1

Alternative solutions like IPFS/Filecoin Arweave only support immutable data and are mainly suitable for static & immutable data.

Is it also true for greenfield? Does it support data mutability?

1 Like
2

Ans:
“”"
Hey Liang,

thanks for the questions, let us reply in the forum directly.

But shortly, greenfield support the deletion of a file, which means that by default a file can be deleted by a user if the user as the right ownership.

In principale If nobody has the access right to delete a file this file would be alive as long as the payment flow to keep the file is active.
“”"

3

Qns:
“”"
Thanks for the reply

  1. so what is the identifier of a file (how is the ID derived?)
  2. if users can delete a file, does that mean they could “update” a file as well?

“”"

4
  1. All objects can be identified and accessed via a universal path:

gnfd://<bucket_name>/[prefix]/[0…n]/object-id

where:

  • “gnfd://” is the fixed leading identifier, which is mandatory
  • bucket_name is the bucket name of the object, which is mandatory
  • prefix and other prefixes are all prefixes defined for the object, which are optional
  • object-id is the ID for the object, which is mandatory

This path should be 1:1 mapped to an object.

  1. Updating an existing object doesn’t differ from creating it in the first place, i.e. the very same operation is used to upload the object and will overwrite the existing one.

It will however be deleting and uploading a new one - not updating. So if you need to update a 1Mb file with 1 byte, you’ll have to upload the whole file again.

Updating usually suggests adding bytes to the existing file, without uploading/rewriting the whole file - this is not possible.

1 Like
5

Is data read/write performance tied to block time or independent?
Say if I want to store database blobs on GreenField, since there is only “overwrite”, an I am encouraged to batch and write instead of doing small updates?

6

independent. The data is uploaded directly to the storage provided. once uploaded, the checksum of the data along with other metadata, like permissions, are recorded to the blockchain - only this last part is tied to the block time

7

It is fair to say that in this regard, just like IPFS and Arweave, BNB Greenfield is not suitable for mutable data storage directly?

8

No, the files are immutable so you cannot open an IO channel and change a particular bit. The reason for this is file’s checksum is calculated and written to the blockchain. If editing were allowed, then the system would have to recalculate the whole checksum and redo the replication across all secondary SPs - a lot of overhead. It’s simpler in a way just to rewrite the whole file and delete the old one.

1 Like
9

I was thinking about how to build mutable storage on top of immutable storage layer like IPFS, GreenField, Arweave, because overall immutable data is more useful for archiving/backup and not very easy to work with to build dynamic & interactive applications.

By “checksum”, does it mean the file is content-addressed? In comparison, we could retrieve files using CID from IPFS.

Files being immutable totally make senses! So I would assume in order to support mutability, we need another layer of data structure on top of the immutable storage layer the way ipfs mutable filesystem or ethereum contract storage merkletree works…

10

I think the mutability support is a useful feature. As files on Greenfield are not contend addressed, it is possible to achieve data update.

1 Like
11

I think a simple way to implement the mutable object is that the greenfield can supports object overwrite and object versioning.