Block builder

[cryptocode]

Implements a builder pattern for all block types.

[rkeene]

What if someone does something like:

auto block = builder.state().clear().sign(key.prv, key.pub).balance(1).build();

Maybe an assert that can catch these kinds of errors, or nullify members which become invalid after updating ?

[cryptocode]

@rkeene The sign function returns a base class type so attempted to call balance will be a compile error.

The param-less build() will assert if there's an internal error. We just have to decide what those errors should be. It's currently decoding errors. To catch your example, we might have to track some state. I'm fine with that, just need a list of things to catch.

[clemahieu]

Can we use sentinel values to pack unset/invalid_decoding information in the value itself? We should have a way to query can_build if the block has all the appropriate items set, based on its type. I think build() should assert if can_build is false and make it a precondition to being called.

[cryptocode]

The whole domain for some values (like destination pubkey) seems to be valid so no sentinel will do IIUC. Could we use an uint8_t bitmap in the builder which is updated while building, and then validated on build() ?

edit: Actually, the std::error_code might be usable for this while building to save space.

[clemahieu]

Since it's a 256bit value , if we use a random internal sentinel it shouldn't be a problem. Globals create random values for not-a-block or not-an-account.

[cryptocode]

@clemahieu that makes sense, thanks!

[cryptocode]

There are work (64-bit) and amount (128-bit) values too though. The 64-bit one is in the realm of collisions (maybe max-1 works? 0 is used in tests)

[cryptocode]

After discussing it a bit, currently reworking this to use builder state instead of sentinels. This allows for fast validation through per-block-type masks.

edit: updated

[rkeene]

Looks good to me !