Cross-Chain Innovation in the BNB Greenfield Programmable Environment

Introduction

The Greenfield ecosystem's true strength lies in its platform designed not only to store data but also to support the creation of value based on data assets and its related economy. Data asset traits are established by permissions, and when disconnected from the data, they become tradable assets, amplifying data value. Data permissions can be transferred cross-chain onto BSC, turning them into digital assets that can be integrated with existing DeFi protocols on BSC, opening up various possibilities for data-based applications.

Cross-chain communication serves as the foundation for enabling the exchange of assets, data, and functionalities across disparate blockchains, facilitating a more connected and efficient decentralised ecosystem.

This article explores the concept of cross-chain communication, and how different projects have tackled this challenge, paving the way for the BNB Greenfield and BNB Smart Chain (BSC) blockchain networks.

Cross-Communication Approaches

Polkadot XCM

Polkadot's cross-chain communication relies on a shared trust model through a common Relay Chain. Horizontal Relay-routed Message Passing (HRMP) and Cross-Consensus Messaging (XCM) optimise communication between parachains. HRMP manages message sending and receiving, while XCM serves as the universal messaging format. To ensure shared trust, all HRMP messages are stored on the Relay Chain, and opening channels requires a small bonded deposit approved by on-chain governance. The modular approach and shared security model differentiate Polkadot, allowing projects to inherit network security. However, the delay in core functionality for parachain interoperability is a trade-off of this approach.

Cosmos IBC

In contrast to Polkadot's shared security model, the Cosmos ecosystem follows a different approach. While it provides tools for creating independent blockchains, the security of the network is treated as an implementation detail of each individual chain. Consequently, Cosmos chains are effectively "external" to each other, necessitating the need for trustless communication between them from the outset. To address this, the Inter-Blockchain Communication (IBC) Protocol was developed, which allows arbitrary messages to be sent between chains without relying on any assumptions about the underlying network topology. It should be noted that Cosmos is actively working towards an Interchain Security model, similar to one of Polkadot, but currently all Cosmos chains are effectively “external” to each other, with no additional trust requirements beyond trusting the participating chains themselves.

Chainlink CCIP

Another cross-chain provider is Chainlink Cross-Chain Interoperability Protocol (CCIP). With CCIP, users can securely transfer tokens and send arbitrary data between blockchains through a unified interface. The protocol is still under development and currently in the "Early Access" stage, offering audited token pool smart contracts for EVM-based networks for secure token transfers.

Comparison vs BNB Greenfield

Cross-communication between BNB Greenfield and BSC stands apart from the approaches taken by Polkadot, Chainlink, and Cosmos in several significant aspects.

Bulk Messaging

To start with CCIP, it’s not suitable for wholesale (or bulk) communication between two blockchains like BNB Greenfield and BSC due to several limitations. Firstly, CCIP currently only supports EVM-based networks with smart contract functionality, making it incompatible with data storage networks like BNB Greenfield, which lacks an internal compute engine.

This would require extensive development to integrate BNB Greenfield with CCIP. Secondly, CCIP's generic unified interface for text and data messages introduces significant overhead, making it less efficient for wholesale communication. Wholesale communication demands a highly optimised protocol to achieve optimal performance and cost-effectiveness, which CCIP may not currently provide and wasn’t built for. As a result, alternative solutions may be more suitable for seamless cross-chain communication between BNB Greenfield and BSC.

EVM compatibility

A core vision of BSC is full backward compatibility with Ethereum, prioritising a fast and performant Ethereum Virtual Machine (EVM). This focus on Ethereum compatibility has led to BSC not natively supporting general-purpose cross-chain protocols like IBC, as they may introduce complexity, performance overhead, and impede compatibility with Ethereum EVM and its Layer 2 solutions.

Security model

Unlike the shared security model of Polkadot and the upcoming approach in Cosmos, BNB Greenfield was designed to be an independent performance and secure decentralised blockchain for all blockchains. This decision steered the project away from coupling with BSC during the design phase, emphasising its ambition to stand alone and offer a unique approach to cross-chain communication.

Tokenomics

Another key distinction lies in the utility token. Both BNB Greenfield and BSC share the same utility token, BNB, which simplifies fund management without exposing users to exchange rate fluctuations. In contrast, Chainlink, Polkadot, and Cosmos run their own tokens, LINK, DOT and ATOM respectively. Projects wishing to communicate with other blockchains through these networks must hold these tokens, adding an extra layer of complexity. Additionally, both ATOM and DOT suffer from a lack of utility since they must compete with the native tokens of blockchains within their own interchain system.

LINK token is only used to pay for messages in the context of cross-chain communication. For Cosmos, ATOM has very little utility other than securing Cosmos and being the de facto central currency of the IBC protocol—which is making Cosmos less of a "hub" and more of an onboarding platform for new IBC users. While DOT has slightly more utility, the Polkadot ecosystem as a whole is still lacking, and this may be due to having to compete against Kusama and parachain projects for developers.

Address scheme

Similarly, BNB Greenfield and BSC utilise the same address scheme, making account mapping a natural process. Having the same address value on both sides signifies the correspondence to the same account. This eliminates the need for an actual mirror or the requirement for users to have different wallets and manage multiple private keys. The result is a simplified system interaction, improved user experience (UX), and reduced risk of secret leakage.

Composability

Finally, the cross-community module between BNB Greenfield and BSC closely mirrors a battle-proven module that has been used between BSC and BNB Beacon Chain (BC). The fundamental framework for facilitating cross-chain interactions remains largely similar between BC and BSC. However, a crucial difference lies in the validation process. BC/BSC implements Merkle proofs to ensure the accuracy and validity of packages transferred between the chains, whereas BSC/Greenfield adopts an aggregated signature approach, drawing upon the majority consensus from validators.

This alteration in validation methods was driven by the objective of reducing the overall cost associated with cross-chain packages. Apart from this key distinction, the majority of other components and mechanisms within the cross-communication layer remain unchanged, fostering seamless interoperability and enhanced efficiency between these blockchain ecosystems.

This strategic choice to reuse working, audited components instead of reinventing the wheel adds to the efficiency and reliability of their cross-communication implementation, demonstrating a pragmatic approach to their development process.

For more details, follow the relayer library repository page.

Blockchain Finality

Finality in the blockchain context ensures that well-formed blocks cannot be revoked once committed to the chain. Consensus protocols play a crucial role in achieving finality. Nakamoto consensus-based systems, like Bitcoin, offer probabilistic finality, where the likelihood of transaction reversal decreases as the block sinks deeper into the chain. In contrast, PBFT-based protocols, like Tendermint, provide absolute finality, instantly confirming transactions upon inclusion in a block.

Polkadot's Substrate achieves finality through GRANDPA, requiring 2N/3 + 1 valid signatures from the validator set. Both BSC and Polkadot are based on probabilistic finality, necessitating users to wait for enough blocks for relative security. However, this approach can lead to longer wait times, impacting user experience for critical applications.

BSC aims to address finality concerns with the introduction of BEP-126, implementing a fast finality mechanism to ensure once a block is finalised, it remains irreversible forever. The process involves validators proposing and signing a block as a vote message, aggregating votes, and setting the aggregated vote attestation in the new block's header. With this approach, finality can be achieved within two blocks in most cases, minimising chain reorganisation and enhancing block production stability.

For more details, follow the BEP-126 discussion page.

Communication Layer between BNB Greenfield and BSC

The communication between BNB Greenfield and BSC is achieved through three layers. The Cross-Chain Communication Layer handles and verifies communication packages between BSC and Greenfield blockchains, ensuring smooth and secure information transfer. The Resource Mirror Layer manages resource assets on Greenfield, mirroring them onto BSC. Users can interact with these assets on BSC using smart contracts based on Greenfield's primitives, enabling seamless cross-chain asset management and resource allocation.

At the top, the Application Layer consists of community-developed smart contracts on BSC, allowing them to operate the mirrored resource entities on the Resource Mirror Layer. While Greenfield itself lacks programmability, the Application Layer can interact with Greenfield Core and supporting infrastructures, empowering developers to create innovative decentralised applications and leverage Greenfield's robust infrastructure and cross-chain capabilities.

Communication Layer and Relayers

A group of Greenfield Relayers plays a vital role in facilitating messages between blockchains. Each validator in the network runs a relayer, equipped with a BLS private key. The address of this key is stored on-chain as part of the validator's mandatory information.

The relayer actively monitors cross-chain events occurring on both BSC and the BNB Greenfield blockchain independently. When a sufficient number of blocks have been confirmed to reach finality, the relayer employs its BLS key to sign a message, which serves as a confirmation for these events. This signed message is referred to as the "vote." Subsequently, the relayer broadcasts this vote through a peer-to-peer (p2p) network to other relayers.

To achieve successful cross-chain communication, multiple votes from various relayers are required. Once a sufficient number of votes have been collected, the relayer assembles a cross-chain package transaction. This transaction includes the necessary data and instructions for the cross-chain communication. The relayer then submits this package to either the BSC or BNB Greenfield network, ensuring the seamless transfer of information and assets between the two blockchains.

Reliability in communication between the relayers is ensured through a defined protocol that guarantees the dependable delivery of data between BSC and BNB Greenfield. The protocol incorporates a sequence number for each package and requires positive acknowledgment (ACK) from the target chain. The three types of packages used are SYN (initial cross-chain packages), ACK (positive acknowledgment), and FAIL_ACK (negative acknowledgment). Each communication package must start with SYN and end with either ACK or FAIL_ACK, allowing for error recovery and maintaining data integrity.

The mechanism remains resilient to relayer changes through the use of an aggregatable multi-signature scheme, such as BLS. The cross-chain process is lightweight, with appended data indicating validators who sign the events, done through a bitmap and an on-chain validator set. BNB Greenfield validators sync information to BSC using a BNB Greenfield light client, ensuring up-to-date and reliable communication despite changes in the BNB Greenfield validator set.

For more details, follow the cross-chain documentation page.

Resource Mirror

What is Mirroring?

Mirroring in the context of BNB Greenfield refers to transferring control of objects stored on BNB Greenfield to a smart contract on BSC. This process enables on-chain management of the object on BSC, allowing users or smart contracts to perform various operations and changes through on-chain transactions. By transferring control to the BSC smart contract, mirroring leverages BSC's smart contract functionality to enhance the functionality and interoperability between the two blockchains, enabling seamless management of objects on BSC while preserving data integrity on BNB Greenfield.

During mirroring, the actual file content is not copied from BNB Greenfield to BSC, meaning data and file metadata stored on the BNB Greenfield blockchain are not duplicated. As a result, there is no size limit imposed on the mirroring process.

Mirroring allows for changing metadata attributes of objects, including properties and permissions. For instance, users can initiate on-chain transactions on BSC to modify the permission settings of a specific object stored on BNB Greenfield. Users can change object metadata attributes through on-chain transactions on BSC, which are propagated to BNB Greenfield through relayers, as described above.

How Mirroring works?

Mirroring on BSC is a fascinating process where resources from BNB Greenfield are duplicated as non-fungible tokens (NFTs) on BSC, following the ERC-721 standard for objects and ERC-1155 for the authorisation process. These resources, like buckets, objects, and groups, become directly manageable by BSC smart contracts, allowing changes on BSC to impact the corresponding data on BNB Greenfield.

Importantly, the mirroring process preserves the ownership of objects, keeping it with the original creator even after mirroring to BSC. However, mirroring isn't automatic; users must manually initiate it, offering them control over which objects are mirrored. And once an object is mirrored to BSC, its management solely occurs on BSC, and there's no direct "un-mirroring" to revert it back to BNB Greenfield.

Mirroring and Storage Providers

BNB Greenfield is committed to full decentralisation, empowering users with the freedom to switch storage providers for their objects whenever they choose. This aligns with the vision of avoiding vendor lock-in, ensuring no single entity has control over the data.

The mirroring process in BNB Greenfield is highly robust and vendor lock-free. It operates based on the unique object ID, making it resilient to changes like modifications in metadata. Even if an object is renamed, the mirroring remains unaffected, showcasing the platform's flexibility and decentralisation principles.

Furthermore, BNB Greenfield facilitates seamless migration of mirrored objects between storage providers. The mirroring process is deeply tied to the data and metadata residing on BNB Greenfield, rather than duplicating content onto BSC. As a result, migrating the actual content from one storage provider to another has no impact on the mirroring process. This design ensures users can enjoy a decentralised and vendor lock-free experience while managing their data across different storage providers.

Advantages of Mirroring

The advantages of mirroring include increased flexibility and control over decentralised storage on BNB Greenfield for all dApps on BSC. By transferring control to the BSC smart contract, mirroring leverages BSC's smart contract functionality to enhance the functionality and interoperability between the two platforms, enabling seamless management of objects on BSC while preserving data integrity on BNB Greenfield.

Another big advantage of mirroring relates to BNB Greenfield being based on CometBFT, incorporating the latest security patches and featuring an improved Application Blockchain Interface (ABCI) known as ABCI++.

ABCI++ introduces Vote Extensions, enabling validators to include additional arbitrary information during block execution. This empowers the state machine to leverage this validator-provided data in subsequent blocks, expanding its capabilities. Since cross-chain communication is performed by the BNB Greenfield validators, can leverage ABCI++ to embed supplementary information as part of the block production process, optimising and streamlining the communication between the networks on the block level.

With the ability to support and facilitate more complex data flows, mirroring can extend the platform's capabilities beyond storage use-cases. This enhancement empowers BNB Greenfield to handle intricate data interactions and processes within the system, opening the doors to a wider range of innovative use cases and applications. As a result, BNB Greenfield is already transforming from a decentralised storage solution into a comprehensive, versatile ecosystem that caters to diverse needs and opportunities in the blockchain space.

Disadvantages of Mirroring

While the benefits of cross-chain resource mirroring are enticing, the chosen design also brings forth unique challenges that the community must address to fully harness these advantages and explore new potential use-cases.

1. Manual Execution: Mirroring is not automatic and requires users to initiate the process, complicating user onboarding and overall dApp user experience. Users need to sign transactions on both BNB Greenfield and BSC networks, necessitating familiarity with web3 wallets and careful selection of the correct blockchain network to avoid errors.

2. Limited Support: Currently, mirroring is only supported to BSC, limiting the interoperability with other blockchains. Although mirroring to other blockchains is on the roadmap, it is not currently available, restricting the options for cross-chain communication.

3. Block Finality Constraints: Mirroring involves cross-chain communication, requiring the sender's block to be finalised before acting on the message. Similarly, the replying message block must also be finalised, which can throttle performance based on block finality. Although the Fast Finality feature (BEP-126) on BSC is expected to improve this, it will still fall short of sub-second communication offered by traditional messaging platforms like Kafka or RabbitMQ.

Operating Primitives

BNB Greenfield provides comprehensive support for basic CRUD (Create, Read, Update, Delete) operations, as well as authorization and membership management. Users have the ability to create and delete objects, buckets, and folders. They can also create and delete groups, and further assign or unassign members to these groups, defining access permissions and privileges.

During the mirroring process, creating an object mints a BEP721 token on the BSC side, which is transferred to the object owner. Similarly, assigning a member to a group, which entails granting specific permissions over the object, results in the minting of a BEP1155 token for the authorised user, as explained in the ‘Under the hood’ section.

The goal is to ensure that all these operations function seamlessly under mirroring, allowing users to manage their data effectively while leveraging the capabilities of BNB Greenfield and BSC. Implementation progress and further details can be found on the documentation page.

Gas and Fees

BSC users and smart contracts interacting with BNB Greenfield will need to pay additional transaction gas to cover the cross-chain communication process. Both SYN and ACK/FAIL_ACK packages incur gas fees for relaying. Users initiating SYN cross-chain packages must pay the fee for both types. BSC dApps can implement custom logic to handle ACK or FAIL_ACK packages, with smart contracts registering callback functions and defining gas limitations for ACK or FAIL_ACK packages in advance, and relayers may refund any excessive fees later.

User Flow

With cross chain communication developers can just use the solidity code, deployed to BSC, to control the access and ownership of files stored on BNB Greenfield. This in turn enables the technical possibility of data ownership and tokenization.

The sequence diagram below illustrates the mirroring process between BNB Greenfield and BSC.

The steps are as follows:

1. The User initiates the mirror process through the Front-end application.

2. The Front-end sends a MsgCreateGroup to BNB Greenfield to create a new group.

3. BNB Greenfield processes the request and emits an EventCreateGroup event as a successful notification.

4. The Front-end then sends a MsgMirrorGroup to BNB Greenfield, indicating the intention to mirror the group to BSC.

5. BNB Greenfield triggers an EventCrossChain internally, preparing the SYN_PACKAGE for cross-chain communication.

6. The Cross-chain contract on BSC receives the SYN_PACKAGE.

7. The Cross-chain contract mints a GroupToken (ERC721) on BSC, representing the mirrored representation of the object as a group.

8. The Cross-chain sends the cross-chain fees through an addReward call to Relayer-hub (BSC) contract - as described in the ‘Gas and Fees’ section.

9. The Relayer-hub processes the addReward request and emits a RewardTo event.

10. The Cross-chain contract then finalises the mirroring process and emits a MirrorSuccess event.

11. The Cross-chain contract also emits a CrossChainPackage event back to BNB Greenfield.

12. BNB Greenfield receives the CrossChainPackage event and emits an EventMirrorGroup to the Front-end, confirming the successful mirroring of the group.

13. Subsequently, the Front-end sends a MsgPutPolicy to BNB Greenfield to define the policy for the newly mirrored group.

14. BNB Greenfield processes the MsgPutPolicy request and emits an EventPutPolicy back to the Front-end.

15. The Front-end notifies the User of the successful mirroring process.

Overall, the sequence diagram demonstrates the step-by-step communication and actions involved in the mirroring process, ensuring the synchronisation and representation of data and objects between BNB Greenfield and BSC.

Future Planning

Cross-chain communication plays a pivotal role in enhancing the interoperability of blockchain networks. As the BNB Greenfield and BSC blockchain ecosystems take shape, understanding and implementing efficient cross-chain communication will be crucial for unlocking the full potential of decentralised applications and services.

The future prospects of BNB Greenfield hold immense potential for enhancing cross-chain communication and decentralisation. One significant enhancement lies in making the minted BEP721 and BEP1155 tokens transferable, enabling seamless transfer of ownership and permissions over objects without excessive cross-chain calls. This advancement would streamline user interactions and provide a more efficient and flexible management experience.

Moreover, the introduction of the ability to "un-mirror" objects back to Greenfield offers promising opportunities for mirroring BNB Greenfield objects to BSC L2s, like opBNB which is much cheaper and faster than BSC, as well as other blockchains, expanding the ecosystem's interoperability and reach. This potential integration with other blockchains unlocks new possibilities for cross-chain collaborations and data sharing.

Additionally, as the BNB Greenfield community works towards introducing "data operation" capability through executable objects, cross-chain communication is expected to witness remarkable improvements in terms of performance and security. These executable objects would enhance data processing efficiency and provide a robust and secure environment for data interactions.

For more details, follow the forum discussion page.

Conclusion

In conclusion, the cross-communication between BNB Greenfield and BSC presents a significant advancement in the realm of decentralised storage and blockchain interoperability. Through the mirroring process, users gain the ability to seamlessly manage objects stored on BNB Greenfield directly from BSC's smart contracts, promoting a fluid and decentralised experience.

The use of BEP721 and BEP1155 tokens on BSC facilitates ownership tracking and authorization, empowering users to interact with mirrored objects efficiently and securely. As the ecosystem continues to evolve, the combination of BNB Greenfield's immutable storage and BSC's smart contract capabilities paves the way for innovative, trustless, and decentralised applications across both platforms.

Follow us to stay updated on everything BNB Chain!

Website | Twitter | Twitter (Devs) | Telegram | dApp Store | YouTube | Discord | LinkedIn | Build N' Build Forum | Dev Community|