uPort Transactions

If you use uPort for signing transactions for your smart contract, you would have noticed that, you could not find any trace about the transaction against the contract if you check on Etherscan.io. This is because Etherscan for Rinkeby does not provide information about internal transactions. While we were developing our decentralised skill verification platform at Diwala, we face this problem and thought it would be useful to document about this as this would be useful to fellow developers. In this article, I’m trying to provide some details about journey of a transaction if someone use uPort to sign a transaction and possible way to get details of internal transactions.

Important point to remember is, when you use uPort for identity management, your private key is stored in your mobile device and it would never be exposed to outside. Hence, any transaction to the blockchain should go through your mobile device. This may not directly relevant to this article, but it immensely help when you design systems using uPort.

Journey of a transaction with uPort

DApp: Usually a transaction get formulated inside a DApp. Then ether through a QR Code or via deep links the transaction would transfer into the uPort app in your device.

uPort App: Use the private key inside uPort app to sign the transaction and send it to TxRelay contract.

TxRelay: Receive transaction from uPort app and this is the transaction that is visible to you if you use the transaction hash returned from uPort app. Once received as name suggest, TxRelay relay the message to MetaIdetityManager smart contract.

MetaIdentityManager: This contract provide means to send transaction without sender owning any ether. This contract finally forward the transaction to its final destination, which is your custom contract that you wanted to invoke at first place.

View data sent to a Smart Contract

Once a transaction is submitted (without uPort) and it successfully hit the destination in network, it is possible to pull all the data related to that transaction by calling Web3.js method web3.eth.getTransaction and decode its data parameter using a library like abi-decoder. But if you try this with the transaction hash you get after submitting a transaction via uPort, you would not see the data you submitted to your target smart contract’s function.

Reason for this is, behind the scenes, the uPort app does not send the transaction directly to your contract but it routed via TxRelay and MetaIdentityManager contracts.

So to view actual data sent to your contract by signing with uPort, following steps needed to be followed.

1. Pull the transaction using web3.eth.getTransaction by providing the transaction hash
2. Decode data using abi-decoder with the TxRelay contract’s ABI
3. Value of the data attribute received from step 2 , should be input to the abi-decoder but this time with the ABI of the MetaIdentityManager
4. And finally, value of data attribute received from step 3 should be input to the abi-decoder but this time with the ABI of the target contract

Summary

Once transaction signed from uPort app it traverse through multiple contracts before hit the target contract. So the data you get using transaction hash should be recursively decoded using relevant smart contract ABIs to liberate the data to the target contract. You could try this out at uPort Message Decoder or use the simple node module for developments. You could find a more generalised module done by Snorre where you could adopt this library to view internal transactions of any smart contract.

uPort Internal Transactions_So we have been playing around with uPort for our platform and found that the support for internal transactions on the…_medium.com

Resources

1. Reusable library (GitHub, NPM, Sample)
2. Online tool
3. MetaIdentityManager contract and ABI from Etherscan(Rinkeby)
4. TxRelay contract and ABI from Etherscan(Rinkeby)
5. ABI-Decoder library
6. uPort Project
7. uPort white paper