-
Notifications
You must be signed in to change notification settings - Fork 533
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BEP-362: Greenfield Storage Fee Paymaster #362
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,115 @@ | ||
<pre> | ||
BEP: 362 | ||
Title: Greenfield Storage Fee Paymaster | ||
Status: Draft | ||
Type: Standards | ||
Created: 2024-03-14 | ||
</pre> | ||
|
||
|
||
# BEP-362: Greenfield Storage Fee Paymaster | ||
|
||
- [BEP-362: Greenfield Storage Fee Paymaster](#bep-362-greenfield-storage-fee-paymaster) | ||
- [1. Summary](#1-summary) | ||
- [2. Motivation](#2-motivation) | ||
- [3. Status](#3-status) | ||
- [4. Specification](#4-specification) | ||
- [4.1 Create and update bucket](#41-create-and-update-bucket) | ||
- [4.2 Set the flow rate limit for a bucket](#42-set-the-flow-rate-limit-for-a-bucket) | ||
- [4.3 Update bucket payment address](#43-update-bucket-payment-address) | ||
- [5. License](#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, 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 sections) for the bucket, they may not use the bucket normally. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. change MsgSetBucketFlowRateLimit to |
||
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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
||
``` | ||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. hightlight |
||
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](https://creativecommons.org/publicdomain/zero/1.0/). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you explain a bit what this
MsgCreateBucket
is?