Update hip-551.md #1090
Update hip-551.md #1090
Conversation
Add new updates to HIP-551 after implementation discussions
✅ Deploy Preview for hedera-hips ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Michael Garber <[email protected]>
|
Hi team, Hope you're all doing well! Just wanted to follow up on PR #Update hip-551.md. It's fantastic to see the engagement so far, thank you for all of your inputs. There are still 3 unresolved discussions that require your perspectives. The insights which each of you hold are extremely valuable to shaping this project. If you could find some time to go through these discussions and share your views, that would be highly appreciated. Thanks again and looking forward to your inputs! Best, @SimiHunjan - There's an unresolved discussion from 2025-01-17. Could you please take a look and either resolve or provide additional context? Link to discussion |
|
I resolved the conversations. Thanks for the follow-up! |
Signed-off-by: Kim Rader <[email protected]>
Signed-off-by: Michael Heinrichs <[email protected]>
Signed-off-by: Michael Heinrichs <[email protected]>
| - The batch transaction will be processed as a single unit. If any inner transaction fails, the entire batch will fail. | ||
| - The batch transaction will return a single transaction response as usual. In general, inner transactions are not checked during pre-check. | ||
| - The batch transaction and all executed inner transactions create TransactionReceipts. In order to see response codes for inner transactions, the user must query the individual inner transactions receipts. | ||
| - Transaction records for inner transactions will have the `parentConsensusTimestamp` set to the `consensusTimestamp` of the containing AtomicBatch transaction. The `parentConsensusTimestamp` can be used to correlate all transaction records for the batch. Block streams are handled similarly. |
There was a problem hiding this comment.
It isn't clear to me how a transaction record is accessed for an inner transaction. I don't see any protobuf updates in this design to support this. Currently there is only a single transaction record per stream item
There was a problem hiding this comment.
I am not sure if I understand the question.
| 4. Are deduplicated on an individual basis. | ||
| 5. Are authorized solely by their keys; batch keys are not used. | ||
| 6. If one of the inner transactions has a child transaction, the parent transaction is in the batch, and the batch isn't successful, then the child transaction should also be reverted. | ||
| 4. Are deduplicated on an individual basis. If two inner transactions within the same batch have the same transactionID, the transaction will be rejected. |
There was a problem hiding this comment.
A TransactionID has many components. To be clear, they each should provide a unique combination of accountID plus transactionValidStart? They should still continue to set scheduled=false and nonce=0, right?
There was a problem hiding this comment.
Yes. Inner transaction are regular transactions with the only difference that the batchKey is set and nodeAccountID is 0.0.0.
There was a problem hiding this comment.
Maybe we can add a short comment to the HIP to clarify that scheduled=false and nonce=0 for all inner transactions.
| 5. Are authorized solely by their keys; batch keys are not used for authorization. | ||
| 6. Cannot be batch transactions. A batch transactions cannot contain another batch transaction. | ||
| 7. Cannot be network freeze transactions, but may be other privileged transactions. | ||
| 8. Must have nodeAccountID set to 0.0.0. This acts as a marker to indicate that an inner transaction is part of a batch, and it allows resubmitting a batch transaction without the need to re-sign the inner transactions. |
There was a problem hiding this comment.
This will be troublesome or at least confusing for non-zero realms. Can't we just say that its nodeAccountID should not be set instead of using some sentinel value?
There was a problem hiding this comment.
Why? It should never be used (except for checking that it is set to 0.0.0.
|
|
||
| The batch: | ||
| The AtomicBatch outer transaction: | ||
|
|
||
| 1. Has its own payer and signatures. | ||
| 2. Considers inner transactions as part of its signed bytes. | ||
| 3. Makes the batch payer cover node+network fees for handling the batch, excluding inner transaction fees. | ||
| 4. Has deduplication based on its unique transaction ID. |
There was a problem hiding this comment.
So there's no relation between the TransactionID of the outer and its inners? So on hashscan or mirror node API if I look up a transaction by its TransactionID is it expected that only the single inner or outer transaction that it refers to shows up? Or should it somehow show all?
| - The batch transaction will be processed as a single unit. If any inner transaction fails, the entire batch will fail. | ||
| - The batch transaction will return a single transaction response as usual. In general, inner transactions are not checked during pre-check. | ||
| - The batch transaction and all executed inner transactions create TransactionReceipts. In order to see response codes for inner transactions, the user must query the individual inner transactions receipts. | ||
| - Transaction records for inner transactions will have the `parentConsensusTimestamp` set to the `consensusTimestamp` of the containing AtomicBatch transaction. The `parentConsensusTimestamp` can be used to correlate all transaction records for the batch. Block streams are handled similarly. |
There was a problem hiding this comment.
It's still not quite clear. So will each outer and inner be assigned a distinct consensus timestamp? And will each inner consensus timestamp each be offset by one nanosecond from the outer just like regular child transactions? What will occur if inner transaction 3 has 10 synthetic child transactions and inner 5 has 2 synthetic children?
There was a problem hiding this comment.
The consensus timestamp is counted up for all transactions as they appear in the stream. The hierarchy has no influence. If inner transaction 3 has nanosecond n, then the 10 synthetic child transactions will have n+1...n+10, and the next inner transaction 4 has n+11.
There was a problem hiding this comment.
Thanks for clarifying, but I meant these sort of details should be in the HIP since this is a new concept of having inners with children.
Add new updates to HIP-551 after implementation discussions
Description:
Updated information and implementation description into HIP-551