discussion: azoth version divergence in Nomad nodes

[g4titanx]

azoth is integrated into the Nomad network where nodes need to validate and reproduce obfuscated contracts deterministically. now, as azoth evolves with new transforms, version divergence across Nomad nodes creates consensus issues.
for example:

// Node A (v2.0) - has 2 new Transforms and removed 1 of the old one
transforms: [Shuffle, OpaquePredicate, SomeNewTransform, AnotherNewTransform]

// Node B (v1.5) - missing new Transforms
transforms: [Shuffle, OpaquePredicate, JumpAddressTransformer]

// Same seed -> different results -> consensus failure

one important thing is any node should be able to reproduce and verify obfuscation results

@ozwaldorf proposed a solution:

// current seed structure
[256 bits of pure randomness]

[8 bits version][248 bits randomness]
// reserve the first 8 bits (1 byte) as a version identifier, leaving 248 bits for randomness.

[ozwaldorf]

We could also just prefix/suffix the seed bits with 8 or 16 bits and keep the same seed material size.

[ 16 bits version ] [ 256 bits seed data ]

Which can be represented as [u8; 34] or a tuple (u16, [u8; 32])

[g4titanx]

We could also just prefix/suffix the seed bits with 8 or 16 bits and keep the same seed material size.

[ 16 bits version ] [ 256 bits seed data ]

Which can be represented as [u8; 34] or a tuple (u16, [u8; 32])

yeah that could work too!