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

15 - User Identifier

Previous14 - Ecosystem PlayersNext16 - Greenfield Blockchain

Last updated 2 years ago

Each user has their own address as the identifier for his/her account. The addresses can create objects to store on Greenfield, bear and manage the permissions, and pay fees.

Greenfield defines its account in the same format as BSC and Ethereum. It starts with ECDSA secp256k1 curve for keys and is compliant with for full paths. The root HD path for Greenfield-based accounts is m/44'/60'/0'/0. In the readable presentation, a Greenfield address is a 42-character hexadecimal string derived from the last 20 bytes of the public key of the controlling account with 0x as the prefix.

With this compatible address scheme, the users can reuse existing accounts and infrastructure from BSC on Greenfield. For example, they can use TrustWallet and Metamask (or other compatible wallets) to deposit their BNB from BSC to Greenfield and interact with dApps on Greenfield. It is also easy to identify the same owner by referring to the same addresses on both BSC and Greenfield.

Greenfield blockchain is an application-specific chain without EVM, the transaction data structure and API are different from BSC. Greenfield will not support full functions in existing wallets, e.g. Transfer, Send Transactions, etc. But it will enable the existing wallets to sign transactions with the standard. This standard allows wallets to display data in signing prompts in a structured and readable format. This is an of how to use it in Metamask. Eventually, wallets will start supporting Greenfield directly.

15.1 User Balance

The user identifier is mapped to an account in the ledger of Greenfield. The account can hold a balance of BNB. These BNBs can be used to participate in staking, pay for gas fees of Greenfield transactions, and pay for Greenfield services.

This balance can be added via native BNB transfer on Greenfield, or cross-chain transfer between Greenfield and BSC.

EIP84
BIP44
EIP712
example