Cross-chain Identification
Last updated
Was this helpful?
Last updated
Was this helpful?
The cross-chain identification protocol plays an important role in the TRAVA.FINANCE architecture. It can be used to verify that multiple addresses on different chains belong to the same user. The protocol allows TRAVA.FINANCE to provide an overview of anonymous users, including their total cryptos and other digital assets, statistics for their transactions, and their relationships with other blockchain addresses. These types of information and relationships are stored on the cross-chain knowledge graph. The protocol can (i) improve the credit score of the users and their wallet address so that they can get favorable interest rates, (ii) save them transaction fees since they can use up all of their cryptos as collateral in a single transaction, and (iii) allow them to get their cryptos back when they lose one of their wallet address.
To implement the protocol, we develop a wallet application so that users can manage their accounts and prove their ownership of multiple accounts. The application provides users with two functionalities: “Add account” and “Create a proof of ownership”. Users can add a new account to the wallet application in multiple ways, e.g., (i) create an account, (ii) import a private key, and (iii) connect to a hardware wallet.
To foster their DeFi transactions, they might need to prove that they are the owner of n addresses. To this end, they can use our wallet application to perform a transaction that activates the cross-chain identification protocol. Receiving the transaction, TRAVA validators check the accuracy of the data associated with the transaction. If the data is valid, the validators accept the transaction and write the sameAs relationship among the owners of the addresses to the knowledge graph.
In the following we describe our processing to verify the cross-chain identification of multiple wallet addresses.
Assume that a user would like to confirm her ownership for 3 accounts, the wallet creates a message containing 3 data elements, each includes a pair of a chainId and a public key. Every element has a fixed size of 41 bytes: 8 bytes for the chainId and 33 bytes for the public key. The data format is as follows:
data1 (41 bytes) := chainId1 (8 bytes) + pub1 (33 bytes)
data2 (41 bytes) := chainId2 (8 bytes) + pub2 (33 bytes)
data3 (41 bytes) := chainId3 (8 bytes) + pub3 (33 bytes)
The wallet uses the Merkle tree to hash the data and obtains the rootHash (32 bytes)
rootHash := MerkleTree([data1,data2,data3]).getRoot()
The user then uses her 3 private keys to sign on the rootHash. Each signing creates a signature, named si (64 bytes):
s1 := Sign(rootHash, prv1)
s2 := Sign(rootHash, prv2)
s3 := Sign(rootHash, prv3)
Finally, a transaction is generated and broadcasted to validators. A sample of transaction payload is as follows:
Type (8 bytes): "SameAs"
Number (4 bytes): 3 // The number of addresses
Message (n*41 bytes): data1 data2 data3
Signatures (n*64 bytes): s1 s2 s3
Timestamp (8 bytes): 1619602364
The total size of a transaction to prove n accounts of the same user is: 20 + n * 105 bytes
Receiving the transaction, TRAVA validators verify the timestamp and then verify the signatures as follows. They first extract the message {data1, … datan} and the list of signatures {s1, … sn}. From each data element datai, the validators get the chainId and the public key (i.e., pubi). They use the Merkle tree to hash the data and regenerate the rootHash:
rootHash := MerkleTree([data1, data2, data3]).getRoot()
The validators then use pubi to verify signature si on the rootHash:
verifySignature(rootHash, s1 , pub1) => valid/invalid
verifySignature(rootHash, s2 , pub1) => valid/invalid
verifySignature(rootHash, s3 , pub1) => valid/invalid
Once all signatures are valid, the validators agree that all accounts stored in the message belong to the same user. From n pairs of chainId and public key, the validators calculate the respective addresses of the user. To eliminate useless addresses, the validators perform additional checks on the age of the address, its average balance, or the total number of transactions related to the address. Finally, the validators store the sameAs relationship among the valid addresses of the user on the knowledge graph.
