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.
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.
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 ofopaque
.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, includingprevious_block
,height
andtimestamp
members. (In the case oftimestamp
, 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 intoactive_data
.)Move operations inside active
Transactions go too far in the opposite direction. The
vector<operation>
is directly in thetransaction
, 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>
tovector<opaque<operation>>
oropaque<vector<operation>>
or evenopaque<vector<opaque<operation>>>
.However, we've instead decided to move
vector<operation>
insideactive_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.