BEP-362: Greenfield Storage Fee Paymaster

[yutianwu]

  BEP: 362
  Title: Greenfield Storage Fee Paymaster
  Status: Draft
  Type: Standards
  Created: 2024-03-14

BEP-362: Greenfield Storage Fee Paymaster

• BEP-362: Greenfield Storage Fee Paymaster
  • 1. Summary
  • 2. Motivation
  • 3. Status
  • 4. Specification
    • 4.1 Create and update bucket
    • 4.2 Set the flow rate limit for a bucket
    • 4.3 Update bucket payment address
  • 5. License

1. Summary

The BEP introduces a storage fee paymaster solution for sponsors to cover storage costs on Greenfield, making it easier
for regular users to utilize the platform. Currently, users need to pay the storage fee for the buckets by themselves,
so they need to hold BNB in Greenfield and understand the charging mechanism. Allowing the sponsors to pay the storage
fee for the users will make it easier to use Greenfield.

2. Motivation

Objects stored on Greenfield incur storage fees, with additional data access incurring read traffic fees.
Greenfield employs stream payment to charge for storage and read traffic. For regular users, grasping the concept of
stream payment and knowing when to renew can be challenging. Users need to know what is the stream payment and they
need to calculate the cost of the BNB according to the price of storage which is confusing for normal users.
To address this, we aim to introduce the Paymaster approach, enabling sponsors to cover storage and read traffic costs for their users seamlessly.

3. Status

This BEP is in progress.

4. Specification

4.1 Create and update bucket

When creating a bucket via MsgCreateBucket, users can specify a payment address for the bucket to make payments.

message MsgCreateBucket {  
  string creator = 1;  
  string bucket_name = 2;  
  VisibilityType visibility = 3;  
  string payment_address = 4;  
  ...
}

In previous implementations, this payment address had to be the bucket owner or be created by the bucket owner.
However, in the new design, we allow this payment address to be any address.

Users can specify any payment address when creating the bucket. But if the payment address does not set a flow rate
limit(which you can refer to below section) for the bucket, they may not use the bucket normally.

Users can also update the payment address for the bucket via the MsgUpdateBucketInfo by specifying the payment address
to be replaced if they want to use another payment address after creating the bucket.

We recommend setting the bucket's payment address to the sponsor's payment address for optimal convenience and flexibility.

4.2 Set the flow rate limit for a bucket

When the payment account’s owner of a bucket is different from the bucket owner, it is necessary to check if the current
payment flow exceeds the flow rate limit when deducting charges for streaming payments.

The payment account owner can use the MsgSetBucketFlowRateLimit transaction to set the maximum payment flow size for a
specific bucket. The default flow rate limit is 0, but if the payment account is owned by the bucket owner, the default
flow rate limit is unlimited. If the payment account owner hasn't set a flow rate limit for the bucket, users can't create
any objects in it or set read quota for the bucket.

message MsgSetBucketFlowRateLimit {  
  // operator defines the account address of the operator, either the object owner or the updater with granted permission.  
  string operator = 1;  
  // bucket_name defines the name of the bucket  
  string bucket_name = 2;  
  // bucket_owner defines the account address of the bucket owner  
  string bucket_owner = 3;  
  // payment_address defines an account address to pay the fee for the bucket.  
  string payment_address = 4;  
  // flow_rate_limit defines the flow rate limit of the bucket  
  string flow_rate_limit = 5;  
}

The payment account owner can send a MsgSetBucketFlowRateLimit transaction on the Greenfield side to set the flow rate
limit for a bucket. However, this process requires maintaining a backend program to detect the creation of a qualifying
bucket and trigger the transaction for setting it up. A more recommended approach would be to wait for the implementation
of the GreenfieldExecutor contract in another BEP for improving Greenfield cross-chain programming capability to enable
setting flow rate limits via smart contract. Once this is in place, users can directly create buckets on the BSC/opBNB
side and specify a payment address as a contract address. By doing so, users can simultaneously create a bucket and invoke
the payment contract address to set the flow rate limit, eliminating the need for backend transaction triggers and enabling
automatic flow rate limit configuration.

The payment account owner can adjust the flow rate limit for the bucket. The rules for adjusting the limit are as follows:

1. Setting the new flow rate limit to 0 indicates will stop the payment for the bucket, the bucket is rate-limited and the user can’t use the bucket as normal.
2. Setting the new flow rate limit under the current flow rate of the bucket is the same as setting the new flow rate limit to 0.
3. To resume payment for the bucket, the flow rate limit must be set to a value not lower than the current net flow rate of the bucket.
4. The user’s operation will be rejected if the flow rate of the bucket exceeds the flow rate limit.

4.3 Update bucket payment address

When the payment account no longer pays for the bucket or the bucket is rate-limited by the current payment account,
the bucket owner can update the payment address to continue using the bucket. In this case, users will need to utilize
the new payment address for making payments.

5. License

The content is licensed under CC0.

[unclezoro]

can you explain a bit what this MsgCreateBucket is?

[unclezoro]

which you can refer to below sections ==> I think Markdown support jump to the section, let us change it.

[unclezoro]

change MsgSetBucketFlowRateLimit to MsgSetBucketFlowRateLimit, always hightlight the special wording.

[unclezoro]

• or use any read quota

[unclezoro]

hightlight MsgSetBucketFlowRateLimit please.