FIR-18: Blockchain confirmation listeners #18
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Peter Broadhurst <peter.broadhurst@kaleido.io>
peterbroadhurst
changed the title
5 tasks
EnriqueL8
reviewed
Jun 12, 2024
Comment on lines
+38
to
+60
| # Guide-level explanation | ||
| [guide-level-explanation]: #guide-level-explanation | ||
|
|
||
| Explain the proposal as if it was already included in FireFly and you were | ||
| teaching it to another FireFly developer. That generally means: | ||
|
|
||
| - Introducing new named concepts. | ||
| - Explaining the feature largely in terms of examples. | ||
| - Explaining how FireFly programmers should *think* about the feature, and how | ||
| it should impact the way they use FireFly. It should explain the impact as | ||
| concretely as possible. | ||
| - If applicable, provide sample error messages, deprecation warnings, or | ||
| migration guidance. | ||
| - If applicable, describe the differences between teaching this to established | ||
| and new FireFly developers. | ||
| - If applicable, describe any changes that may affect the security of | ||
| communications or administration. | ||
|
|
||
| For implementation-oriented FIRs (e.g. for validator internals), this section | ||
| should focus on how contributors should think about the change, and give | ||
| examples of its concrete impact. For policy FIRs, this section should provide | ||
| an example-driven introduction to the policy, and explain its impact in | ||
| concrete terms. |
There was a problem hiding this comment.
I believe you've talked this in the summary so might be worth just extending it a little bit with an example
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently in FireFly you can:
operationthat you submit via your particular FireFly serverHowever, there is a common pattern of programming that is not well served by this:
This requires a reliable ordered stream of receipts that are delivered in the order they are confirmed on the blockchain (the block containing them pass a point of finality), and the ability to decode the events associated with that receipt.
This issue proposes we:
Blockchain confirmationscollection into FireFly core with appropriate listening/filtering