BNB Greenfield Whitepaper
English
English
  • Table of Contents
    • BNB Greenfield Whitepaper
  • Intro
    • Overview
  • Part 1
    • Design of the BNB Greenfield and the Decentralized Storage Economy
      • 1 - Design Principiles
      • 2 - Assumptions
      • 3 - The Architecture in General
      • 4 - BNB Greenfield Core
      • 5 - The Greenfield Data Storage
      • 6 - Storage Economics and Its Primitives
      • 7 - Economy of Data Assets
      • 8 - "Not" Ending for the Design
  • Part 2
    • Showcases in Labs
      • 9 - Showcases: Decentralized Storage
      • 10 - Showcases: New Ways of Digital Publishing
      • 11 Showcases: User-Generated Content
      • 12 - Showcases: Personal Data Market
      • 13 - From Showcases to Real Production
  • Part 3
    • Simplified Technical Specifications
      • 14 - Ecosystem Players
      • 15 - User Identifier
      • 16 - Greenfield Blockchain
      • 17 - Storage MetaData Models
      • 18 - Payload Storage Management
      • 19 - Data Availability Challenge
      • 20 - Storage Transactions
      • 21 - Billing and Payment
      • 22 - Cross-Chain Models
      • 23 - SP APIs
  • Finish Words
    • Ending
Powered by GitBook
On this page
  1. Part 3
  2. Simplified Technical Specifications

20 - Storage Transactions

The Greenfield blockchain supports a series of transactions to create, update, and delete the Greenfield resources.

The bucket and object creation transactions have to interact with the SPs to ensure they are ready, while group and permission-related operations do not require that.

The users should always create a bucket before they can store any objects.

Greenfield bucket name follows the same naming specification as AWS S3 bucket name. It must be globally unique.

The CreateBucket transaction must have the below information:

  • sender, which can be derived from the transaction signer

  • bucket name

  • the ID of the SP that the bucket and all objects under this bucket will use as the Primary SP

There is a corresponding DeleteBucket transaction. It requires that all the objects under the bucket must be deleted first. As described in the earlier section, the bucket owner can delete any object under his/her bucket.

Object creation is described in Part 1. There is a corresponding DeleteObject transaction. The deletion will tell Greenfield to refund the reserved fees and reduce the payment stream.

There are group creation, deletion, and member management transactions.

There are transactions about permission creation and deletion, as they are the cornerstone functionality for the economy.

More worthy of highlighting, all of these transactions can be triggered via cross-chain infrastructure from BSC smart contracts and EOAs.

There are a few transactions about changing the Primary SP of users' buckets. It will be asynchronous as the action may take some time based on the number and size of the objects in the bucket. The bucket needs to be "Sealed" again by the new Primary SP.

Previous19 - Data Availability ChallengeNext21 - Billing and Payment

Last updated 2 years ago