Is your feature request related to a problem?
Currently, there is no guarantee a transaction is included in a beacon summary aggregate -- which list of the transactions of the day.
To avoid malicious actor to inject a new transaction in the past, we should provide some proof about sealing of a beacon aggregate and ensure a transaction cannot be injected in a previous transaction listing.
Describe the solution you'd like
All the nodes are doing the self-repair, during this phase, the nodes are forging a beacon aggregate to accumulate and create aggregation of all the transactions for all the subsets (0-256 beacon). Hence, we have a complete view of the transactions to seal.
At this point, a node can forge a transaction's beacon summary, including a Merkel tree proof, from the list of transactions hashes for the given aggregate.
For the validation of the transaction, because all the nodes have the access of the beacon aggregate, the nodes are capable to check if the Merkel root is valid.
Later on, to check if a transaction is part of the beacon summary, the nodes could generate a Merkel verification path to ensure the transaction is part or not part of the list, and accept the transaction or not.
Additional context
No response
Epic
No response
Is your feature request related to a problem?
Currently, there is no guarantee a transaction is included in a beacon summary aggregate -- which list of the transactions of the day.
To avoid malicious actor to inject a new transaction in the past, we should provide some proof about sealing of a beacon aggregate and ensure a transaction cannot be injected in a previous transaction listing.
Describe the solution you'd like
All the nodes are doing the self-repair, during this phase, the nodes are forging a beacon aggregate to accumulate and create aggregation of all the transactions for all the subsets (0-256 beacon). Hence, we have a complete view of the transactions to seal.
At this point, a node can forge a transaction's beacon summary, including a Merkel tree proof, from the list of transactions hashes for the given aggregate.
For the validation of the transaction, because all the nodes have the access of the beacon aggregate, the nodes are capable to check if the Merkel root is valid.
Later on, to check if a transaction is part of the beacon summary, the nodes could generate a Merkel verification path to ensure the transaction is part or not part of the list, and accept the transaction or not.
Additional context
No response
Epic
No response