1

My understanding is transactions in a block, are considered to have happened, at the same time.

Order of transactions

Which raises a question with regard to getting signatures for address, as to how much of a block will be returned when setting "until" or "before" bounds.

Consider this state

Block 1
 Transaction A Does Not TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
 Transaction B Mentions TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
Block 2
 Transaction C Does Not Mention
 Transaction D Mentions TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
Block 3
 Transaction E Does Not Mention
 Transaction F Mentions TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA

NOTE: Again the assumption is transaction order is arbitrary, and so "A" And "B" are just for name distinction and not intended to imply order.

Given the following search:

https://docs.solana.com/developing/clients/jsonrpc-api#getsignaturesforaddress

...
"method": "getSignaturesForAddress",
"params": [
    "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",
    {"until": "Transaction A"
...

Would "Transaction B" in Block 1, be reliably returned?

Some initial testing indicates that the inclusion of other qualifying transactions, in the same block, may be undefined or inconsistent.

I ran the following against devnet

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getSignaturesForAddress",
    "params": [
        "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",
        {
            "limit": 3,
            "commitment": "finalized",
            "minContextSlot": 138000000,
            "until": "5nKKRz89w73kKUdaENhQGSgWP6UF48Hug16U6TZDrAKrsA8mWCQsUAXkji5APpGJnSas6HRMRS96rggQtPgg74XL"
        }
    ]
}

Which returned 3 transactions

5YAeP1S3CosHHEu1nhKYcJWP4ZjMt1biu1GQdRS4uZU2GsHvR2Ca87enG92VVZzrGxmiTQH1tmcLTNRPsQFFxNmf 5Ua5HGPbt1bgtjj8iHo1ViHdDiKryH92xVtgnwNuuNkm5bc31M7wGCsLL8NymPBDgsWXUFRRutfENTJzxqsBqBto 5JaZcKtkbUweUvBUathCxuuD8Ju2mvDq8NCk3CKrZVH4KFVi4dYBF8ZWrTDmLDSr3s3RxHqdUisd11CiVq4eRGcD

All in the same slot

151506243

I then, ( as fast as I could.. )

Ran the following ( includes the "middle" transaction )

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getSignaturesForAddress",
    "params": [
        "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA",
        {
            "limit": 400,
            "commitment": "finalized",
            "until": "5Ua5HGPbt1bgtjj8iHo1ViHdDiKryH92xVtgnwNuuNkm5bc31M7wGCsLL8NymPBDgsWXUFRRutfENTJzxqsBqBto"
        }
    ]
}

I received exactly 2 transactions from the same slot as the original query, only one of which intersects with my initial result.

5YAeP1S3CosHHEu1nhKYcJWP4ZjMt1biu1GQdRS4uZU2GsHvR2Ca87enG92VVZzrGxmiTQH1tmcLTNRPsQFFxNmf 22FxsPMiBksxzzFok9RuzcjJSu3hXEHnTpu1CyGYPaw3iybG5Y58eKEG8cdbvPsKGTgFarQH9uMVeeYG3Pvcd8H2

And only 289 results from my of my 400 result limit, were included in this follow up query, so it doesn't appear I was "at limit" in the terminating slot. Request took 897 ms against https://api.devnet.solana.com.

It appears as though the transaction bounds, within the same slot, are undefined.

Is that accurate?

Update: If I was to wager a guess, the scan traversed backwards from now as documented, through the slots, but then forward, through the arbitrarily ordered transaction signatures within the slot where the "until" signature was found, with that until signature then being exclusive.

Resulting in discovery of a newly discovered "22FxsPMiB..." tx, that preceded my initial set ( in the nodes current arbitrary internal tx order ), and the first transaction in my initial result set, ending , with exclusion a the 'middle' transaction.

1 Answer 1

2

I believe the results will be consistent for transactions in the same slot, so long as they are not also in the same entry. If they are in the same entry, they may be returned in arbitrary order

1
  • 1
    I feel like things could get more interesting when using an RPC cluster where each request can be load balanced to a different node with potentially different state (on non-finalized commitment though)
    – zfedoran
    Commented Aug 2, 2022 at 2:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.