Amend the PoW node implementation to bring back the block payload and populate it as follows:

For each block the node tries to mine, it generates a token ID for the (potential) block reward. Note that the token IDs for all successfully mined blocks must be distinct. The easiest way to achieve this seems to be to generate a new (pseudo)random ID for each attempted block. The IDs must also be unpredictable to any outside party. Thus generating them by iteratively hashing some seed value is not good but generating them by hashing a seed+counter value, for example, would be OK. See Sec 6.1.6 Mining of the YP for more details.
For each block the node tries to mine, it obtains the latest Unicity Trust Base record from the BFT cluster. Each new record needs to be authenticated before accepting it. If there is no new UTB record (the latest UTB record has already been published in a previous PoW block), the value remains blank. See Sec 6.2 Snapshot Publishing of the YP for more details.
The PoW node adds the root hash of the 2-leaf Merkle tree built on the two previous items to the block header before passing the template on to the miner process. See Sec 6.1.4 Block Structure of the YP for more details.

To enable the owner of the node to mint their reward tokens, they need a way to access the token IDs for all successfully mined blocks. Eventually the minting process should be automated, but for the scope of this task, a CLI option to just list the token IDs for recent successfully mined blocks (along with the corresponding block heights and hashes) is sufficient.

[TGE] BFT state snapshots to PoW chain #1

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions