BEP-334: Greenfield CrossChain Permission Module

BEP
1 
  BEP: 334
  Title: Greenfield CrossChain Permission Module
  Status: Draft
  Type: Standards
  Created: 2023-12-06

BEP-334: Greenfield CrossChain Permission Module

1. Summary

Currently, Greenfield supports creating buckets and groups from the smart contracts deployed on BSC/opBNB. This means that the owner of a bucket can be a contract address. However, contract addresses cannot upload objects or put policies under the bucket, resulting in empty buckets owned by smart contracts.
To address this issue, we are going to introduce the cross-chain permission module. With this BEP, smart contracts can grant EOA addresses the ability to upload objects under their buckets, and even support additional functions.

2. Abstract

Greenfield CrossChain Permission Module has several significant differences and improvements compared to current implementations:

  • BSC/opBNB account is allowed to put policy for Greenfield resources.
  • BSC/opBNB account is allowed to disable policy for Greenfield resources.

3. Motivation

In the current framework, users could only change resource permission on Greenfield. The proposal allows Greenfield users to change resource permission directly on the BSC/opBNB network.

4. Specification

4.1 Definitions

  • PermissionHub Contract: A new middle-layer contract to request permission changes from BSC to Greenfield

4.2 Interface

4.2.1 Create Policy

The interface to create policy is as follows:
function createPolicy(bytes calldata _data, ExtraData memory _extraData) external;
_data is the RLP encoded bytes of the struct MsgPutPolicy as follows:

type MsgPutPolicy struct {
    Principal *types.Principal `json:"principal,omitempty"`
    Resource string `json:"resource,omitempty"`
    Statements []*types.Statement `json:"statements,omitempty"`
    ExpirationTime *time.Time `json:"expiration_time,omitempty"`
}

type Statement struct {
    Effect Effect `json:"effect,omitempty"`
    Actions []ActionType `json:"actions,omitempty"`
    Resources []string `protobuf:"bytes,3,rep,name=resources,proto3" json:"resources,omitempty"`
    ExpirationTime *time.Time `json:"expiration_time,omitempty"`
    LimitSize *common.UInt64Value `json:"limit_size,omitempty"`
}

For MsgPutPolicy:
Principal defines the roles that can grant permissions. Currently, it can be account or group.
Resource defines a greenfield standard resource name that can be generated by GRN structure
Statements defines a list of individual statement which describe the detail rules of policy
ExpirationTime defines the whole expiration time of all the statements.

For Statement:
Effect define the impact of permissions, which can be Allow/Deny
ActionType defines the operation type you can act on. greenfield defines a set of permission that you can specify in a permissionInfo. see ActionType enum for detail.
ExpirationTime defines how long the permission is valid. If not explicitly specified, it means it will not expire.
LimitSize defines the total data size that is allowed to operate. If not explicitly specified, it means it will not limit.

ExtraData is as follows:

struct ExtraData {
    address appAddress;     // callback app address 
    address refundAddress;  // refund callback gas fee
    bytes callbackData;     // calldata for callback
}

appAddress defines the callback contract after receiving the cross-chain ack package.
refundAddress defines the refund address to receive the unspent callback gas fee.
callbackData defines the calldata for the callback call.

4.2.2 Delete Policy

The interface to delete policy is as follows:
function deletePolicy(uint256 policyId) external payable returns (bool);

policyId is generated while creating policy.

5. License

The content is licensed under CC0.

2 Likes
2

Good job. If the contract can become the owner of the bucket is a great action. If I understand correctly, then when the contract authorizes the EOA user in Greenfield to upload objects, the owner of all of the uploaded objects should also be contract. This is a great help in monetizing and trading data.

First of all, we should be clear that there are two levels of trading for data:

  • Transactions for access rights
  • Transaction of ownership

For access rights transactions:

In Greenfield, the owner of a user has full control over the data, and can directly delete the original data after selling the access control right of its own data, while the buyer of the data access right suffers losses. However, this is not the case if the owner of the data is a contract.

For ownership transactions:

Data in Greenfield has an owner, but ownership is not tradable. However, if the real owner of the data is a contract, a set of user ownership mechanism can be realized on the BSC through the contract, and the ownership transaction can be completed.

So, BEP-334 is important for promoting data trading and DataFi!

1 Like