Hyperledger Mentorship Spotlight: Support NFT standards in Weaver for cross-network asset operations

Hyperledger Mentorship Spotlight: Support NFT standards in Weaver for cross-network asset operations

What did you work on?

Project name: Support NFT standards in Weaver for cross-network asset operations

Dhinakaran Vinayagamurthy, IBM Research
Venkatraman Ramakrishna, IBM Research
Krishnasuri Narayanam, IBM Research
Sandeep Nishad, IBM Research

The aim of the Weaver lab (a Hyperledger lab this now part of Hyperledger Cacti) is to ensure smooth interoperability of assets between blockchain networks. During this mentorship, I had the pleasure of implementing different ERC asset standards interoperability for Weaver with the possibility to ensure future interoperability. 

The three token standards are ERC-20, ERC-721 and ERC-1155. ERC-20 are the most common fungible token standard, while ERC-721 is standard for non-fungible token commonly known as NFT. ERC-1155 is a hybrid standard of ERC-20 and ERC-721. ERC-1155 acts like a token factory that allows you to create multiple tokens in a single smart contract. 

There are three main components for weaver-interoperability for Hyperledger Besu

  • Besu-SDK
  • Solidity contract
  • Besu-CLI

Protobuf implementation in interoperability contract:

In order to support protobuf, we decided to use the Solidity protobuf library. It is a library that can automatically generate encoder and decoder for serialized protobuf messages in Solidity. Then we ran into the issue that converting types is difficult for Solidity. In the end, we used assembly in Solidity to convert strings to address, etc. This is far from optimal, but we did it as a tradeoff between using more gas and interoperability. 

Implementation of scalability in interoperability contract:

In order to ensure ease of implementation and future standard interoperability, an interface has been defined for which every standard has to extend it. This ensures the interoperability contracts can handle any future standard. The interoperability interface consists of two functions: approve and transfer. The interface uses the token contract as an intermediate to transfer assets between users and manage asset contracts. The motivation behind is to ensure compatibility with any asset type. In other words, the interoperability contract can handle any asset if they implement such an interface.

Other implementation:

Update in BESU-CLI and BESU-SDK and additionally testing for ERC20, ERC1155 and ERC721.

What did you learn or accomplish?

During this mentorship I have learned that there are many design tradeoffs such as the one we made in the implementation of the interoperability contract. While one protobuf message can adapt to different and future asset standards due to compatibility issues, three different types of protobuf messages are used. Moreover, I learned how to use protobuf as an exchange format.

What comes next?

There are things that could be refactored in the interoperability Solidity contract. For example, currently three different types of protobufs (Non Fungible, Fungible, Hybrid) are being used in the lockAsset function. Ideally, we could use a single type of protobuf for this purpose, but, in order to use this, we need to update protobuf in other types of blockchain such as Hyperledger Fabric and Corda. Additionally asset exchange tests between Corda, Hyperledger Besu and Hyperledger Fabric could be set up.

Back to all blog posts

Sign up for Hyperledger Horizon & /dev/weekly newsletters 

By signing up, you acknowledge that your information is subject to The Linux Foundation's Privacy Policy