Skip to content

Latest commit

 

History

History
96 lines (56 loc) · 2.97 KB

tip-138.md

File metadata and controls

96 lines (56 loc) · 2.97 KB

tip: 138 
title: Pedersen hash function 
author: federico<[email protected]>
discussions-to: https://github.com/tronprotocol/tips/issues/138
status: Final
type: Standards Track
category: VM
created: 2020-03-10

Simple Summary

The TIP provides the Pedersen hash computation function in the shielded TRC-20 contract (TIP-135), which can be used in shielded token transactions.

Abstract

The TIP introduces the pedersenHash function, which is used for the computation of Merkle tree node value in the shielded TRC-20 contract. The function is implemented in the form of the precompiled contract.

Motivation

To implement shielded transactions for TRC-20 token, We have developed the shielded TRC-20 contract (TIP-135) and it needs the Merkle tree construction and proof, which further needs the Pedersen hash computation. So providing the Pedersen hash function pedersenHash is necessary for shielded TRC-20 contract implementation.

Specification

pedersenHash function is used to compute the node value in the Merkle tree.

nodeValue = pedersenHash(level, left, right);
  • level - Merkle tree level, in the range [0, 31]
  • left - the left child node in the Merkle tree
  • right - the right child node in the Merkle tree
[uint32 for level][32 bytes for left][32 bytes for right]

For the output, nodeValue returns the parent node value in the Merkle tree. The time cost of perdersenHash function takes less than 1ms.

Rationale

By introducing the Pedersen hash computation function, it will be more convenient for Merkle tree construction and shielded TRC-20 contract implementation, which can provide users stronger privacy for shielded TRC-20 transactions.

Test Case

(1)test case 1

Input:

level : 0

left : 0x0100000000000000000000000000000000000000000000000000000000000000

right: 0x0100000000000000000000000000000000000000000000000000000000000000

Output:

nodeValue : 0x817de36ab2d57feb077634bca77819c8e0bd298c04f6fed0e6a83cc1356ca155

(2)test case 2

Input:

level : 1

left : 0x817de36ab2d57feb077634bca77819c8e0bd298c04f6fed0e6a83cc1356ca155

right: 0x817de36ab2d57feb077634bca77819c8e0bd298c04f6fed0e6a83cc1356ca155

Output:

nodeValue : 0xffe9fc03f18b176c998806439ff0bb8ad193afdb27b2ccbc88856916dd804e34

(3)test case 1

Input:

level : 2

left : 0xffe9fc03f18b176c998806439ff0bb8ad193afdb27b2ccbc88856916dd804e34

right: 0xffe9fc03f18b176c998806439ff0bb8ad193afdb27b2ccbc88856916dd804e34

Output:

nodeValue : 0xd8283386ef2ef07ebdbb4383c12a739a953a4d6e0d6fb1139a4036d693bfbb6c

Implementation