How to best read/process ICP blocks?

Hello! I am thinking of writing a service that wakes up every N seconds and reads all the ICP blocks that were added since. It will specifically look at transfers and try to pick the ones that are of interest to it.

What’s the best way to read blocks that were added to the chain in the last N seconds (N < 120) and process them?

The IC is not a traditional blockchain as it does not have one single chain with public blocks. In the interest of scalability, blocks far enough in the past are discarded and only somewhat-current state is kept on the responsible nodes. (see more about subnets here) Also, those blocks are not public knowledge.

What you may be interested in is the Ledger canister where all ICP transactions are kept. For this, I recommend you start with this page: Rosetta | Internet Computer Home

5 Likes

@Severin, is it totally impossible to readout the available blocks of a particular sub-net?

Not ‘totally impossible’ in the sense of being able to store passwords in plaintext - Node providers could read the memory and figure out the state (including private unencrypted information).

But yes, ‘totally impossible’ in the sense of publicly accessible information

@Severin , is there any plan to make block information public? I am asking because this could enable the creation of services that currently are not possible. In general services that require the collection of transactions involving a particular principal_id (e.g. comprehensive tax declaration including transactions not involving a ledger), or services to verify offline the proper/expected execution of a canister, or services to recover from catastrophic loss of canister data. In my opinion having this public interface will soon or later be seen as a must have. What do you think about it?

AFAIK there are no plans to make everything available, but I heard multiple times already that at least the governance / system subnet will have public blocks at some point - exactly for the kind of verification you’re talking about.

But I have no idea how concrete those plans are at the moment

2 Likes

In my opinion, this is a major problem that may keep the IC Defi ecosystem from growing: the current lack of a canister independent way to access and certify all transactions may prevent the arrival of high volume sophisticated traders willing to access diverse marketplaces. Even more modest participants may pull back from interacting with the IC due the complexity to retrieve complete and reliable historical transactions to compute their tax obligations.

Isnt this what CAP is for? What transaction history and verification do you need that Sonic (CAP supported) doesnt give for example? https://cap.ooo/

Thank you @JaMarco for the link. I was not aware of this project and it is certainly an answer in the right direction. Besides that not a single DEFI platform is using this service, my most immediate concern is that there is no guarantee that the stored data is not manipulated, and there is no guarantee that the stored data is not lost forever due to CAP going out of business or due to some other failure or hack. Even if in the future they use external block chain storage from filecoin, this service is basically a backup for private ledgers and is not storing much richer information contained in the IC blocks which could allow to reconstruct and to trace the state of the IC at any point in the time. Perhaps a similar CAP service able to periodically save subnet blocks could be great.