Make updating fees and chain_parameters take a single fee / parameter at a time via static_variant

[vikramrajkumar]

From @theoreticalbts on February 4, 2016 22:25

Currently the committee_member_update_global_parameters_operation takes a monolithic structure containing all chain parameters and fees. This is incredibly brittle:

• New fees / parameters have to be implemented as extensions. While the extension<T> template introduced by Feature: Special authorities cryptonomex/graphene#516 implementation makes this fairly straightforward, it still inevitably involves some amount of awkward boilerplate.
• Unnatural semantics. Usually people want to make a committee proposal of the form "change parameter/fee X and leave all other parameters the same." However this is not possible, you can only have a proposal of the form "set all parameters/fees to these values". Consequences:
• UI's are harder to code (since now you have to essentially implement diffing of these structs in the UI code)
• If a proposal to change fee A to X is created, then another proposal to change fee B to Y is created, then the committee cannot approve both proposals; whichever proposal goes through last will undo the other proposal! Worse, a UI which only shows diffs actually implies diff semantics, so if the UI shows that the first proposal will change A to X and the second proposal will change B to Y, it is very counter-intuitive that A will be changed back to its previous value by the second proposal!
• FBA requires some fees to be settable by someone other than the committee. It is hard to write code to inspect the current data structures to determine who has permission to do a particular fee update.

Here is a plan for a migration which can address these shortcomings:

• Rename fee_parameters to fee_parameter.
• blockchain_fee_update_operation takes a fee_parameter object which is a static_variant of all possible fee types.
• Replace each chain parameter with a single-member struct.
• blockchain_parameter_update_operation takes a chain_parameter object which is a static_variant of all such struct
• The current serialized versions of fee_schedule and chain_parameters are put into a new include/graphene/chain/protocol/legacy directory and graphene::chain::protocol::legacy namespace
• New versions of fee_schedule and chain_parameters go into include/graphene/chain which can be updated with new fields without changing serialization; new code containing new fees / parameters will consider them to already exist and have their default values, they will merely be immutable until the hardfork date passes (i.e. blockchain_fee_update_operation / blockchain_parameter_update_operation targeting new fee/parameter values should fail evaluation until the hardfork date arrives; by the hardfork date, most witnesses will have upgraded and will understand the new static_variant members when they appear on the wire)
• The GPO will still be a monolithic object that includes all fees and parameters, wallets shouldn't have to change their fee determination code as long as they ignore unknown keys in the JSON

Copied from original issue: cryptonomex/graphene#554

[vikramrajkumar]

From @theoreticalbts on February 4, 2016 22:27

Also add to this: In a future patch, stop accepting the old operations some time after the new operations have been enabled and we've verified clients can use them. A separate issue to remind us to do this should be filed when this ticket is closed.

[vikramrajkumar]

From @theoreticalbts on February 5, 2016 17:55

All existing fee parameters and chain parameters happen to be integers -- uint, bool or share_type -- and that seems likely for future parameters as well.

Essentially the "set fee operation" or "set parameter operation" is a committee action which (when consensus is achieved) writes an integer to a particular location, which is then read by chain logic.

This is similar to software driver which configures hardware by writing to memory-mapped registers -- the software (set parameter operation) writes a value which is read by chain logic (hardware) to make the chain (hardware) act in a certain way.

So we conceptually the new unified fee / parameter change operation can be:

write( parameter_space_id, pid1, pid2, parameter_value )

where parameter_space_id = 0 for global chain parameters and parameter_space_id = 1 for fees. The pid1 and pid2 specify the place to write:

• In the case of parameters, pid1 specifies the parameter and pid2 is 0.
• In the case of fees, pid1 specifies the operation and pid2 specifies which of the fee parameters for the operation to set.

We could conceivably combine pid1 and pid2 into a single integer field, but keeping them separate allows an easily explainable numbering convention.

Setting of GPO / fee structure fields by pid1 and pid2 can mostly be automated with existing fc reflection and some templates. The existing fee structures should be moved to legacy namespace.

[vikramrajkumar]

From @theoreticalbts on February 5, 2016 18:5

The reason to do things as described in the above post is to have an unchanging serialization which doesn't require separate support for old and new structures. When replacing an old parameter / fee structure with a new structure, the objects get new fields and the JSON dictionaries seen by clients get new keys. The new code will still understands previous operations.

[vikramrajkumar]

From @abitmore on February 6, 2016 5:27

Good idea. Not only this operation, but also the blacklist/whitelist features of account_update and asset_update should be considered this way.

[vikramrajkumar]

From @theoreticalbts on March 14, 2016 17:35

Here's the beginnings of progress. I'm going to shelve this for now as I've spent way, way too much time on this issue and haven't even gotten something close to compiling yet.

[vikramrajkumar]

wontfix