search

Aimeedeer / realtps

https://realtps.net
MIT License
93 stars 25 forks source link

Add Internet Computer (ICP) #41

Closed niklabh closed 2 years ago

niklabh commented 2 years ago

Please add ICP https://internetcomputer.org/

domwoe commented 2 years ago

There's no RPC endpoint to fetch raw block data though. The endpoint to get update calls/s on the IC would be https://ic-api.internetcomputer.org/api/v3/metrics/message-execution-rate?message_type=update

Could this be integrated @brson ?

brson commented 2 years ago

I'll give it a look this week.

On Mon, Oct 3, 2022, 9:26 AM Dominic Wörner @.***> wrote:

There's no RPC endpoint to fetch raw block data though. The endpoint to get update calls/s on the IC would be https://ic-api.internetcomputer.org/api/v3/metrics/message-execution-rate?message_type=update

Could this be integrated @brson https://github.com/brson ?

— Reply to this email directly, view it on GitHub https://github.com/Aimeedeer/realtps/issues/41#issuecomment-1265438494, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABD6DWZ5NL7JSHZFZJASTTWBLNIHANCNFSM6AAAAAAQZRO7VQ . You are receiving this because you were mentioned.Message ID: @.***>

brson commented 2 years ago

I've done some reading to try to understand the options. ICP is different enough from other systems I'm familiar with that I am having a difficult time.

I can't find docs on the icp v3 api, nor the source for the ic-api server. If somebody can provide further reading that would be helpful.

Is it correct to think that a "message" with "message_type=update" is a message that requires writing some state that requires consensus? Is there some documentation on update messages that I can read?

domwoe commented 2 years ago

Is it correct to think that a "message" with "message_type=update" is a message that requires writing some state that requires consensus? Is there some documentation on update messages that I can read?

Yes, exactly. Update messages go through consensus and state changes are persisted. See https://internetcomputer.org/docs/current/concepts/canisters-code#query-and-update-methods However, a call from a user to a canister (an ingress message) might lead to multiple update calls, since the target canister might call other canisters. Since inter-canister calls on the Internet Computer are asynchronous, there's no notion of transactions.

brson commented 2 years ago

Is it correct to think that a "message" with "message_type=update" is a message that requires writing some state that requires consensus? Is there some documentation on update messages that I can read?

Yes, exactly. Update messages go through consensus and state changes are persisted. See https://internetcomputer.org/docs/current/concepts/canisters-code#query-and-update-methods However, a call from a user to a canister (an ingress message) might lead to multiple update calls, since the target canister might call other canisters. Since inter-canister calls on the Internet Computer are asynchronous, there's no notion of transactions.

Thanks for these clarifications. This matches my assumptions about how messages worked in ICP.

It seems to me that, while an update message is reasonable to consider a "transaction" within the context of ICP, that a single update message is not comparable to e.g. an EVM transaction, since a single ingress message can result in multiple asynchronous transactions.

Figuring out how to draw the best comparisons between chains is going to be a challenge as we add platforms that differ significantly from the bitcoin/evm models. Already I am looking at some we already have and thinking I need to document more clearly how chains and our accounting differ.

I would prefer to track ICP ingress update messages, and also to count them ourselves, not rely on a 3rd party counting them.

domwoe commented 2 years ago

I would prefer to track ICP ingress update messages, and also to count them ourselves, not rely on a 3rd party counting them.

Counting ingress update messages only wouldn't be fair as well, since one ingress message could trigger a cascade of internal update messages over many blocks and hit different subnets, which wouldn't be possible in synchronous execution environments. Furthermore, there are features like heartbeat (and soon a timer) that trigger messages internally without an ingress message.

In general, the Internet Computer won't provide public raw block data for every subnet (though there will be, starting with the NNS subnet), and currently, there's no way to count yourself. In the medium term, we plan to provide more metric data in the state tree itself or as a canister (Both would allow you to verify the data with the Internet Computer Public Key). It would still be great to get the Internet Computer on your page earlier :). For the other chains, you aren't running nodes as well, but trusting a single RPC endpoint. However, I understand your concerns and hope we can provide a more transparent data source soon.

brson commented 2 years ago

Counting ingress update messages only wouldn't be fair as well, since one ingress message could trigger a cascade of internal update messages over many blocks and hit different subnets, which wouldn't be possible in synchronous execution environments. Furthermore, there are features like heartbeat (and soon a timer) that trigger messages internally without an ingress message.

Acknowledged. I'll have to think about this more.