Overall Design / Use Case Questions

Adding here different questions from some chapters from the BNB Greenfield Whitepaper ( GitHub - bnb-chain/greenfield-whitepaper: Whitepaper for Greenfield, the decentralized data economy)

6.4 Data Read and Download

It is stated that data encryption is left to the SP’s preference? Wouldn’t that be hard to implement at each SP’s level, without default encryption available?

Does data encryption have an impact on performance? (EX. For SPs to give the files, they should decrypt them first and provide it)

6.7 Data Integrity and Availability Challenge

How can Proof of Challenge be executed by other SPs if the data is unavailable to SPs to make the checks?

Is the Validator off-chain P2P check done automatically by validators / or is this a manual effort like Governance voting?

9.2.3 Snapshots and Block Data Backups

The topics highlighted in this chapter are true, we are actually running this service on: Snapshots - BwareLabs and it currently runs on R2 - Cloudflare storage solution. The only conditions for this to be migrated to Greenfield would be:

  • if it has lower costs - compared with R2;
  • if it has a similar or better performance
  • ease of programmable uploads - Since we are taking daily snapshots, nobody uploads them by hand, and we have a programmable way of doing it. If that’s not available or taken into account in Greenfield, from an architectural standpoint, then that solution is not something worth exploring.

Hey,

6.4 Data Read and Download

  1. While it’s true that leaving data encryption to the SP’s preference might introduce some implementation challenges, it also allows for flexibility in choosing the encryption methods that best suit the SP’s infrastructure and capabilities. However, it is recommended that developers building applications on Greenfield provide default encryption options to simplify the process for SPs.
  2. Right, this process can introduce latency, depending on the encryption method used and the hardware capabilities of the SP. Nevertheless, encryption is crucial for ensuring data privacy and security.

6.7
hmm, good question. Let me try to see.

Q1: It is stated that data encryption is left to the SP’s preference? Wouldn’t that be hard to implement at each SP’s level, without default encryption available?

A1: The original blob in white paper is:

SPs may use their encryption logic as they wish, but when the data is being downloaded, it shows the same bytes as it was uploaded. Users may choose their own encryption scheme or use the default one provided by the client software if they want the data to be unrecognizable by SPs or any others, even though SPs have the obligation to not circulate these data out of users' instruction.

There are actually two scenarios for encryption here: users encrypting their own data, and service providers (SP) encrypting data before store it. The default algorithm for user data encryption can be provided by the dapp, while for SP, we will provide a default plugin implementation in the future.

Q2: Does data encryption have an impact on performance? (EX. For SPs to give the files, they should decrypt them first and provide it)

A2: Yes, these additional costs inevitably increase the delay of the service, so it is not recommended to encrypt insensitive data.

Q3: How can Proof of Challenge be executed by other SPs if the data is unavailable to SPs to make the checks?

A3: The “Proof of Challenge” is performed by a group of validators known as the challenge verifier. This verifier signs the query request using a special key owned by the validator. The service provider then allows the request from the challenge verifier to prove the data integrity and availability.