docs: Implement ADR-001: Smart Transaction Submission#706
docs: Implement ADR-001: Smart Transaction Submission#706
Conversation
|
@matiwinnetou We have started drafting the spec to enhance the current transaction submission endpoint with rollback awareness capability. In the initial phase, we plan to store submitted transactions and monitor a certain number of blocks for confirmation. If a rollback occurs, the system may resubmit the same signed transaction and notify the application. Feel free to review it, and if you have any specific requirements, please add your comments here. |
| └────│ ROLLED_BACK │ ← RollbackEvent detected | ||
| └──────┬───────┘ | ||
| │ | ||
| │ Can return to |
There was a problem hiding this comment.
We have twice confirmed here, there should be "FINAL" state at the bottom.
There was a problem hiding this comment.
Thanks @matiwinnetou . The second CONFIRMED state is for re-submission after a rollback.
Agree. We should introduce a FINALIZED state, which is set after 2,160 blocks (security parameter in genesis file) when the block becomes truly immutable.
SUCCESS is determined by the number of block confirmations configured according to the application’s requirements. This can vary across applications. We can either define a single property for the number of confirmations or make it transaction specific.
We also need an efficient way to transition the status from SUCCESS to FINALIZED after 2160 blocks. The watch scheduler stops after SUCCESS, but perhaps another method could periodically check for transactions that are eligible to move to the FINALIZED state after each new block.
There was a problem hiding this comment.
Watcher for sure should not stop after SUCCESS, it should monitor until FINALIZED, this is how we did this in Reeve back in the days.
| cbor_hex TEXT NOT NULL, | ||
|
|
||
| status VARCHAR(20) NOT NULL, | ||
| -- Values: SUBMITTED, CONFIRMED, SUCCESS, FAILED, ROLLED_BACK |
There was a problem hiding this comment.
FINALIZED as a new status?
Maybe we could also introduce partial completion. For a lot of use cases, like 10 blocks would already give strong enough indication it is fine. This is what we doing in REEVE, special status after 10 blocks. FINALIZED is after mathemetically finalising it according to Ouroboros Prasos or in the future consider Ouroboros Peras, which will have likely different finality. So ideally solution should be prepared for Ouroboros Peras.
There was a problem hiding this comment.
Yes, we need a FINALIZED status. please check my previous comment.
…support - Introduced a new `submit` component for smart transaction submission with lifecycle tracking. - Implemented transaction states: SUBMITTED, CONFIRMED, SUCCESS, FINALIZED, FAILED, and ROLLED_BACK. - Added REST API endpoints for submitting transactions and querying their status. - Integrated WebSocket support for real-time notifications on transaction status updates. - Configured lifecycle properties and database schema for tracking submitted transactions. - Enhanced the build configuration to include new dependencies for WebSocket and Hibernate types.
…TxSubmissionService - Removed the SmartTxSubmissionService, consolidating transaction submission logic into TxLifecycleService. - Updated TxLifecycleController to utilize TxLifecycleService for transaction submissions. - Enhanced TxLifecycleService to handle transaction submission and lifecycle tracking directly. - Cleaned up unused imports and methods in OgmiosService and TxSubmissionService.
…hook, and Event Log support - Added WebSocket and Webhook notification channels for real-time transaction status updates. - Introduced an Event Log for auditing transaction status changes, including database schema for event logging. - Enhanced SubmitLifecycleProperties to include configurations for webhook and event log settings. - Created interfaces and implementations for notification channels, allowing for extensibility in future notification methods. - Updated application configuration to support new notification features.
…iguration and application properties
- Introduced new methods in TxLifecycleService for finding existing transactions, confirmed transactions after a specific slot, and transactions by status and confirmed block number. - Updated TxLifecycleProcessor to utilize the new service methods for improved transaction status updates. - Refactored SubmittedTransactionRepository to support new query methods for transaction management. - Removed unnecessary inheritance from BaseEntity in SubmittedTransactionEntity and TxEventLogEntity for cleaner model definitions.
|
3 participants
#705