Sign.Club investing in Web 3 gaming DATA management & security with BNB GreenField
The Sign Club team is happy to announce that will be deeply involved in the study and therefore the integration of future data custody and management techniques in Web3, via “GreenField”. The new frontier of BlockChain data management developed by Binance BNB GreenField.
In this regard, we introduce Binance’s philosophy regarding data management, a point of view that connects the past of Web2 and the innovative challenges of the contemporary and future universe of Web3:
“ After 14 years and a few bull markets, people start getting familiar with blockchains, Distributed (or decentralized) Ledger Technology, cryptocurrency, DeFi, …, and derived economy models around these concepts and practices. Many hold and exchange tokens and participate in related activities that may change or have changed the way how values are exchanged and governed.
“Web3”, the term coined in 2014 by Gavin Wood, becomes a popular buzzword again in 2021. Among all the definitions of “Web3”, we, the BNB Foundation and BNB Chain Core Dev, embrace the below narrative from Eshita the most:
Web3 is adding “Own” to Web2’s “Read-Write”.
We believe what blockchains bring is the freedom of how assets and valuable things are owned, exchanged, and transferred among people.
The crypto industry has already picked up financial assets: the tokens, stablecoins, and DeFi cover many economic scenarios. On the other hand, NFTs implement arts and collectibles. But there are plenty of items that are not innovated well enough, such as credit, real-world asset (RWA) tokenizations, and the one we’d like to focus on in this paper:
Data.
The value of a data asset is not self-evident when it is just held by one person. They become much more valuable when they are shared and used. It is valuable to possess and exchange the power to write, read, grant rights for sharing the data, and even execute one data to generate another. These abilities have derived value with financial traits: they are tradable and the trades can generate even more value and benefit the two parties, instead of one.
We foresee the need to create a new Web3 infrastructure for data, as two major features are still missing: a performant, convenient, and friendly decentralized storage infra, and the data-focused smart contract synergy.
Thus we decide to create a new BNB side blockchain and relevant infrastructure, with which the users and developers can:- “login” with anonymous cryptographic-based keys (IDs);
- Create, read, share, and even execute data with the user experience and cost close to the state-of-art cloud storage service today;
- Fully own their data assets and control who can use them and how;
- Easily put their data assets into a wide, smart-contract-based economic context to gain financial value with them.
In short, with this new infrastructure, users can “login”, create, own, share, execute, and trade their data assets at another level of freedom, and what is more, enjoy another level of transparency on how their data is owned and used.
Transparency of the data lifecycle is key in the Web3 era. It helps to show how the data is generated and how it is used so that users can and want to control it. More importantly, it encourages the community to introduce new business models, which should be more open and fair. “
What you have just read and excellently explained by the Binance authors is connected to the fundamental role that every project in the blockchain is about to play, every single project will have this role: secure data management and the value of the collected data.
In the case of Sign Club Gaming Dapp & Hub, we will certainly have to manage user data in a huge amount (try to think about the gaminig industry flow of data connected to the players, the guilds, each game and kol influencers as well with communities and social media).
So, not only the wallets connected to our native NFT market, but also those connected to the DIGITAL IDENTITIES for each gamer profile. We may have to regulate these gamers digital identities with the use of KYC, or even convert only the wallets connected to each user using systems such as SPACE ID, in fact we are evaluating a future collaboration with this innovative reality of the crypto sphere, indeed not only with BNB Greenfields.
So to conclude we want to simultaneously excite and reassure our community and our investors… On the one hand, to excite them with the big news arriving during 2023 in terms of gaming and gamers data management, on the other hand, to reassure them because the data will be secured in very safe hands!
We will find the best winning path together… Continue to trust us in our wonderful communities. That’s all see you soon! Here the official Sign Club LINKTREE one stop hub! One click for everyting :)
Many greetings from the SIGN CLUB Team
Do you want to know more and deeply about BNB GreenField? Here we share with you the whole WhitePaper with all the details, enjoy it:
Table of Content
- Overview
- Part 1 Design of the BNB Greenfield and the Decentralized Storage Economy
- 1 Design Principles
- 2 Assumptions
- 3 The Architecture in General
- 3.1 Greenfield Core
- 3.2 BNB Greenfield dApps
- 3.3 The Cross-Chain with BSC
- 3.4 The Trinity
- 4 BNB Greenfield Core
- 4.1 The BNB Greenfield Blockchain
- 4.2 The Storage Providers, SPs
- 4.3 The Pair Synergy
- 5 The Greenfield Data Storage
- 5.1 Data with Consensus
- 5.1.1 Accounts and Balance
- 5.1.2 Validator and SP Metadata
- 5.1.3 Storage Metadata
- 5.1.4 Permission Metadata
- 5.1.5 Billing Metadata
- 5.2 Off-Chain Payload Object Data Storage
- 5.2.1 Primary and Secondary SPs
- 5.2.2 Data Redundancy
- 6 Storage Economics and Its Primitives
- 6.1 Account Creation
- 6.2 Data Object Creation
- 6.3 Data Storage
- 6.4 Data Read and Download
- 6.5 Permissions and Group
- 6.6 Fees and Payments
- 6.7 Data Integrity and Availability Challenge
- 6.8 Data Delete
- 7 Economy of Data Assets
- 7.1 Cross-Chain with BSC
- 7.2 Framework
- 7.3 Communication Layer
- 7.4 Resource Mirror Layer
- 7.4.1 Resource Entity Mirror
- 7.4.2 Cross-Chain Operating Primitives
- 8 “Not” Ending for the Design
- 8.1 Acknowledgement
- Part 2 Showcases in Labs
- 9 Showcases: Decentralized Storage
- 9.1 Web Hosting and Personal Cloud Drive
- 9.2 Data Availability Layer for Public Blockchain
- 9.2.1 Layer 1 Blockchain Data Swapping
- 9.2.2 Data Availability Layer for the Layer 2 Rollups
- 9.2.3 Snapshots and Block Data Backups
- 10 Showcases: New Ways of Digital Publishing
- 10.1 Grass-Root Digital Publishing
- 10.2 Data Market
- 10.3 Risk: Anti-Piracy
- 11 Showcases: User-Generated Content
- 11.1 Anti-Monopoly and Anti-Censorship
- 11.2 Token Curated Registries
- 12 Showcases: Personal Data Market
- 13 From Showcases to Real Production
- Part 3 Simplified Technical Specifications
- 14 Ecosystem Players
- 14.1 Greenfield Validators
- 14.2 Storage Providers (SPs)
- 14.3 Greenfield dApps
- 15 User Identifier
- 15.1 User Balance
- 16 Greenfield Blockchain
- 16.1 Token Economics
- 16.2 Consensus and Validator Election
- 16.3 Governance Transactions
- 16.3.1 Create and Edit Validator
- 16.3.2 Staking Reward Distribution
- 16.3.3 Create Storage Provider
- 16.3.4 Remove Storage Provider
- 17 Storage MetaData Models
- 17.1 Bucket
- 17.2 Object
- 17.3 Group
- 17.4 Permission
- 17.4.1 Ownership
- 17.4.2 Permission Definitions
- 17.4.3 Permission Removal
- 17.4.4 Examples
- 18 Payload Storage Management
- 18.1 Segments
- 18.2 Erasure Code and Data Redundancy
- 18.2.1 Data Redundancy Design
- 18.2.2 Erasure Code
- 18.2.2.1 Encoding
- 18.2.2.2 Decoding: Data Recovery
- 19 Data Availability Challenge
- 19.1 The Initial Data Integrity and Redundancy Metadata
- 19.2 Data Availability Challenge Process
- 20 Storage Transactions
- 21 Billing and Payment
- 21.1 Concepts and Formulas
- 21.1.1 Terminology
- 21.1.2 Formula
- 21.1.3 Types and Interfaces
- 21.2 Key Workflow
- 21.2.1 Deposit and Withdrawal
- 21.2.2 Payment Stream
- 21.2.3 Forced Settlement
- 21.2.4 Payment Account
- 21.2.5 Account Freeze and Resume
- 21.2.6 Storage Fee Price and Adjustment
- 22 Cross-Chain Models
- 22.1 Communication Channels and Packages
- 22.1.1 Vote Poll
- 22.1.2 Channel and Sequence
- 22.1.3 Reliability Protocol
- 22.1.4 Validator Update
- 22.2 Economic
- 22.2.1 Fee and Reward of Cross-Chain Packages
- 22.2.2 Race to Deliver Cross-Chain Packages
- 22.2.3 Callbacks and Limited Gas
- 22.2.4 Cross-Chain Infrastructure Contracts on BSC
- 22.3 Error and Failure Handling
- 23 SP APIs
- 23.1 Universal Endpoint
- 23.1.1 URI Standard
- 23.1.2 HTTPS REST API
- 23.1.3 P2P RPC
- 23.2 List Operations
- Ending