Block validity not currently exposed

[lrettig]

In general there should be zero or one block per layer. On rare occasions there may be more than one, see, e.g., spacemeshos/go-spacemesh#4825.

In these situations the API must make clear which block is the canonical block. go-spacemesh knows which one is canonical (spacemeshos/explorer-backend#92 (comment)) but this is not currently exposed via the API.

[Avionic23]

Hey, @lrettig. Sorry for bothering you again) I have a question related to block validity in case of multiple blocks in the layer. I've been reading documentation and noticed that only transactions from the valid block are processed by STF. Can we verify block validity by fetching transaction states from all layer blocks with '/spacemesh.v1.TransactionService/TransactionsState' RPC call and including only ones with 'TransactionState_TRANSACTION_STATE_PROCESSED' state? If yes, then how many layers should we wait before we can verify that?

[lrettig]

@Avionic23 The way things work today with API v1, the API only returns the canonical block for a given layer. See:

https://github.com/spacemeshos/go-spacemesh/blob/3302f7cf53c9364bda28ee6ac5a8b8e3d988a4bd/api/grpcserver/mesh_service.go#L277-L278

@kacpersaw we plan to do the same thing for API v2, correct? I'm referring to this comment: #300 (comment).

At this time we don't have a plan for the API to return all blocks, including non-canonical ones. I don't see a use case, @Avionic23 do you?

[Avionic23]

@lrettig @kacpersaw Yeah, I see that only one canonical block is always returned for the layer. What about transactions validity? I read in the documentation that there are possibilities of failed transactions in global state included in layer/block and I'm not sure how to figure them out. I see that it doesn't make sense to verify transactions with '/spacemesh.v1.TransactionService/TransactionsState' call because the 'LayersQuery' response already includes 'types.APPLIED' txs and this status is interchangeable with 'TransactionState_TRANSACTION_STATE_PROCESSED'. Please, tell me if I'm wrong about this and all txs with 'types.APPLIED' state are assumed to be valid

[lrettig]

For API v1 please see https://github.com/spacemeshos/wiki/wiki/Integration-guide#tracking.

For API v2, @kacpersaw how do we plan to handle tx status and validity? #300 included transaction state and status (https://github.com/spacemeshos/api/blob/090594ffe68db70745b8a22a82a4cc9a292ac18b/spacemesh/v2/tx.proto) but I don't see this in #319. This is something we plan to add in a later phase?

[Avionic23]

@lrettig I'm referring to this:
"A transaction that was successfully applied can still fail if, e.g., the principal account doesn't have enough funds to pay for its gas: we call this an "ineffective" transaction. This is not currently captured cleanly in the API. Implementing transaction receipts is still a work in progress."
Do I understand correctly that failed transactions are included in layer/block and returned from this RPC call /spacemesh.v1.MeshService/LayersQuery ?

[lrettig]

Sorry I realize there's contradictory information in the integration guide. I'm almost certain that it's not possible for a tx to be included in a block today but still be ineffective. Transactions that don't pay enough gas are filtered out and not included in the first place. It's possible in theory (which is what the section you quote is referring to) but probably not in practice. We'll fix this when we roll out the new VM, which will need to include proper tx receipts.

[Avionic23]

@lrettig ok, I get it. Does it mean that duplicate transactions are also filtered out in a block lvl and only ones with unique ids are included in the final state?

[lrettig]

Yes, that should also be the case. Let me know if you have more questions.

…

Message ID: ***@***.***>

[Avionic23]

@lrettig What about transaction duplications in layer lvl? Is it possible to have tx duplicates in multiple layers (for example in case of reorganisation)?
Sorry for such silly questions. I'm only familiar with longest chain blockchains like Ethereum or Bitcoin, so I'm not sure how Spacemesh handle this scenarios

[lrettig]

@Avionic23 these are excellent questions, please keep them coming. But this is not the right forum or medium to discuss and answer them. I propose the following. Draw up a list of questions, as a google doc or hackmd or something like that. Send me the link, and I'll make sure you get answers, and that we update the relevant docs for posterity. I also want to make sure others on the team can weigh in. Does that work? Thanks!

[lrettig]

Here's another option: https://github.com/orgs/spacemeshos/discussions

[Avionic23]

@lrettig Sounds good. I'll come up with a list of questions)