Hello everyone! This week we got something very exciting for you — we’ll briefly talk about the NFT pallet on the Litentry parachain, and more importantly, the technology we use to do NFT airdrop: Merkle tree. 
NFT pallet
We’re building an NFT pallet to foster identity track building and DAO governance in Web 3. Through weighted computation of users’ aggregated identity data, ML labeling and classifying, users meeting the corresponding identity score range or specific identity attributes will receive their identity NFT. The identity NFT is closely related to the user’s on-chain historical behaviors, such as transactions, on-chain governance participation, IDO participation, etc., and can reflect the user’s attributes and creditworthiness.
For example, if a user participates frequently in Polkadot governance, and this governance is considered important for the ecosystem, Litentry will issue an corresponding NFT for this user to claim. When claiming the NFT, our off-chain workers will go to the Polkadot blockchain to confirm whether the user has actually participated in the governance. If yes, the claim will pass and the NFT of the governance will be sent to the user’s address.
Merkle Airdrop on the NFT pallet
Merkle tree is a hash tree data structure that is used for data verification and synchronization. The concept was introduced by Ralph Merkle and patented in 1979. As you can see from the graph below, all data lay at the bottom of the tree, and each non-leaf node is a hash of its child nodes. For example, H(12) is the hash of node 1 and node 2; H(12, 34) is the hash of node H(12) and node H(34). By hashing multiple layers of the nodes, we get the Merkle root which is the hash of the entire tree.
Merkle tree example
Merkle airdrop saves costs for crypto projects because it is highly efficient in storage. To precisely target audiences, crypto projects usually have to use a whitelist of user addresses for their airdrop. However, such a whitelist would take up lots of space if they’re directly stored on-chain, which also puts a lot of pressure on on-chain transaction confirmation. As such, we turn the whitelist into a Merkle tree, so that the only thing needed to be stored on-chain is the Merkle root, which is of 1 hash value, around 8 bytes. This significantly improves the utilization of storage on the blockchain.
Building a Merkle tree:
- Airdrop whitelist as the source data of the tree. Each data element consists of two things: the index and the account address. An index is automatically distributed and counted from 0 to the length of whitelist -1.
- Hash each data element using keccak256 so that we get a 32 bytes long hash value of each data, which composes leave nodes of the Merkle Tree.
- Now build a binary Merkle Tree with each pair sorted ascendingly pre-hashing.
the software architecture of Merkle airdrop
Though only the Merkle root is stored on-chain, the entire Merkle tree is stored off-chain on either IPFS or a normal web server. As such, during the verification process, we can easily find the right nodes for computation. Alongside that, each address is encoded and pre-assigned a corresponding Merkle proof for verification purposes. For example, the user of address 5 will receive index #5 and Merkle proof including H(6), H(78), H(12, 34) from the frontend. When the user claims an NFT, they will need to provide an address, index #, and Merkle proof to the Litentry runtime, then the runtime will check if the information matches the pre-stored root. If passes, the claiming user will receive the NFT s/he claims, or else the request will be rejected. Each NFT claiming event is then recorded on-chain with the unique index number to prevent duplication.
Testnet: Merkle claim, TEE integration
- Finalized Merkle claim implementation, unit tests and documentation
- Established and finalized a NodeJS project to generate Merkle Tree and Merkle Proof as a demo to interact with NFT pallet in terms of claiming functionality
- Investigated SubstraTEE and made plans of MVP of TEE integration
- Token migration test planning
- Benchmark test for on_finalize method in off-chain worker
- SubstraTEE setup and investigated the SDK version problem
- Updated parachain dependencies to v0.9.6
- Updated account-linker and added pallet documentation
Litentry App: header, notification, firebase
- Refactor navigation header
- Integrated firebase
- Setup Notification screen
- Notification deep linking
Misc: Chainbridge, forum, validators upgrade
- Fixed CI issue with 0.9.5 and 0.9.6 upgrades
- Finalized Chainbridge setup scripts
- Added Testnet config file for Chainbridge
- Added parachain, relayer chain setup scripts
- Upgraded Litentry Forum
- Upgraded Polkadot/Kusama validators
Cheers from Munich!
We’re hanging out in Munich! From left to right in the picture, we have Jiani (operation), Jutta(design), Zongxiong(dev), Qiuhai (business), Hanwen (CEO), and Fei (CTO). Ah, truly hope covid will pass soon so we can have more gathering time like this! 
Until next time!
About Litentry
Litentry is a Decentralized Identity Aggregator that enables linking user identities across multiple networks. Featuring a DID indexing protocol and a Substrate-built distributed DID validation blockchain, Litentry provides a decentralized, interoperable identity aggregation service that mitigates the difficulty of resolving agnostic DID mechanisms. Litentry provides a secure vehicle through which users manage their identities and dApps obtain real-time DID data of an identity owner across different blockchains.