koinos / koinos-types

The Rosetta Stone of the Koinos ecosystem. Allows for the interpretation of Koinos data structures in a multitude of languages. Useful in the development of microservices, clients, and smart contracts.
MIT License
12 stars 3 forks source link

Changes to block structure #152

Closed theoreticalbts closed 3 years ago

theoreticalbts commented 3 years ago

Implement block header

Currently, previous, height and timestamp are buried in the opaque active data. The purpose of this is to allow future flexibility in serialization format. However, code in several places has to get this information.

Currently several places in the code fully unbox active_data just to get this information, which defeats the purpose of opaque.

One solution is to write custom limited deserialization logic that only deserializes the needed fields.

After some discussion, a less awkward alternative has been proposed: Add header to blocks, including previous_block, height and timestamp members. (In the case of timestamp, we need to check at some point that the block timestamp is not too far in the future compared to real time, and it is helpful if this check doesn't have to delve into active_data.)

Move operations inside active

Transactions go too far in the opposite direction. The vector<operation> is directly in the transaction, meaning all code that gets any information from a transaction has to understand the operation format. This makes it hard to e.g. add new operations in-band.

This could be fixed by changing vector<operation> to vector<opaque<operation>> or opaque<vector<operation>> or even opaque<vector<opaque<operation>>>.

However, we've instead decided to move vector<operation> inside active_transaction_data.

Add ID to blocks and transactions

We've decided that each block and transaction should contain its ID. The included ID obviously can't depend on itself, rather we're simply adding new cryptographic constraints between fields.

Add signer_address to active_block_data

Cryptographic ECC recovery of the signing address should be separate from validation that the given address has permission to produce a block. In keeping with the ID, it makes sense to simply add a field and a cryptographic constraint on the field's content. To sign a block, Alice effectively has to sign her own address, but this is perfectly doable; there is no cryptographic cycle.

sgerbino commented 3 years ago