search

hyperledger-iroha / iroha

Iroha - A simple, enterprise-grade decentralized ledger
https://wiki.hyperledger.org/display/iroha
Apache License 2.0
438 stars 280 forks source link

Record trigger execution as a transaction #4968

Open mversic opened 2 months ago

mversic commented 2 months ago

Financial applications need to track the flow of assets. It has been noted that trigger execution isn't transactional. If a trigger is invoked and it transfers asset from user A to user B this is hard to track (for blockchain explorers) unless the trigger also makes a record in the metadata.

This doesn't mean that blockchain state is ever inconsistent across peers. If the whole blockstore is replayed then every peer will reach the same state, but no transactions will be recorded for trigger executions.

I'm not sure whether we should change this behavior. Maybe we can make it so that every trigger execution is recorded as a transaction in a block. This means that the leader will inject the appropriate transactions when constructing a block and all other peers will also verify that indeed a correct transaction was injected

Mingela commented 2 months ago

I guess it would be more transparent to create a specific transaction type for that (e.g. TriggerExecution). If events are contained in blocks it could be just an event type instead.

s8sato commented 2 months ago

I think it makes sense. If transactions include trigger executions, it would be redundant as a source of state, which is disadvantageous in terms of memory space, but it would become complete as a history of changes. I guess transactions might be separated into extrinsic (ordinary) one as a source of state and intrinsic (generated from triggers) one as a complementary history of changes.

Alternatively, what do you think about having a logging system that is the responsibility of each user, which listens for events and records transactional data including trigger executions?

0x009922 commented 4 days ago

Alternatively, what do you think about having a logging system that is the responsibility of each user, which listens for events and records transactional data including trigger executions?

IMO it makes sense to not store the "inferrable" history in the blockchain, but to emit it as events.

However, we might extend the existing EventBox::TriggerCompleted event with the actual list of instructions that were executed from within the trigger. After all, all mutations from smartcontracts are still performed in terms of instructions, so why not track them as a list and let the clients know?