hyperledger / iroha-2-docs

https://hyperledger.github.io/iroha-2-docs/
Apache License 2.0
6 stars 26 forks source link

FAQ / Fabric architecture comparison: transaction log #436

Open 6r1d opened 9 months ago

6r1d commented 9 months ago

Today, Matías Salimbene asked whether Iroha 2 supports something similar to Fabric's transaction log. Can anyone comment?

Hello there. In Fabric there's this idea of World State and Transaction Log. The World State being the current state of records that results after completion of every transaction in the Transaction Log. The transaction Log is the actual blockchain, and I'm able to query it.

In Iroha I've read about the World State View, which appears to be pretty similar to the World State in fabric, but I've not seen the "Transaction Log". (The entire log of transaction that result in the current World State View). Is this log available in Iroha?

But I think it's not exactly the same, in that in fabric I can get the transaction log for a particular chaincode state, which may not necessarily be all blocks, but only those related to that chaincode. Let say I need to get the history of transactions for a particular asset, I want to know how many mints/burns lead to its current state

But I guess also the chaincode model an data model are different, so perhaps I should approach this differently.

matisalimbene commented 9 months ago

To add more context to the question. Let's say I want to get a list of all transaction that resulted in the current state of an asset (i.e all mints/burns), or the transaction log that resulted in the current state of an account (i.e assets assigned, transferred, etc).

In yet other words, I get that with the World State View I see the current state of the world, but what If I want the transactions history that resulted in this World State View?

6r1d commented 9 months ago

A reply from @mversic:

the chain of blocks is transaction log. If you use listen_for_blocks you will get the log. It's the same thing in Hyperledger Fabric. Alternatively you can read blocks from disk with kura_inspector.


ok, I understand you. You want a way to follow a trail of transactions through the blockchain. We don't support that

blockchain is the transaction log. What you want are facilities to inspect the blockchain(transaction log)

unfortunately no, we don't provide such facilities. You could implement some crude use-cases yourself via listen_for_blocks. Get all the blocks and do the search on client side

we have FindTransactionsByAccountId query that may be of help to you

This chain also can be read back to the very start of the blockchain.

matisalimbene commented 7 months ago

To add more context on this issue, this is a related question that I asked on telegram and it's reply:

I already got the answer for this but I need to double-check. Let's say I got an asset (type quantity). I want to get a list of all the transactions that lead to a given account to have the current amount. So to make it simple, I got two users, User1 mints 100 assets named Token, and transfers 10 of those to User2.

  • If I execute FindTransactionsByAccountId for User1, I will get said mint and transfer transactions.
  • But if I execute FindTransactionsByAccountId for User2, I get nothing. This is because FindTransactionsByAccountId returns the full set of transactions that the account has submitted.

In other words, there's no way for me to get a list of transactions for User2, because they never submitted any transaction. So whatever the current amount is for User2, I cannot know who sent them assets. (I mean using Iroha queries, I would need to keep track of those operations myself, somehow)

And the reply:

Hello, Matias.

According to Bogdan you are correct, and:

I guess that's because User2 is just a parameter of a specific transaction instruction sent by User1. Stick to the first option mentioned (FindTransactionsByAccountId for User1, then filter for transfers which have User2 set as the destination)

So, long story short, currently there's no query available to get the list of transactions for an account when said account wasn't the submitter (like the scenario of the account being the receiver of a transfer).