BSIP40 Implementation

[nathanielhourt]

My implementation for BSIP 40, Custom Active Authorities

A couple of notes:

• Equality comparison between two containers of mismatched types is not working because I can't get the SFINAE to compile... so comparing a flat_set<T> against a vector<T>, for instance, doesn't work.
• The fee logic is very simple, just a flat op price plus a price per byte. I believe this structure is adequate, and its simplicity will significantly reduce the complexity of frontend development.

[abitmore]

Equality comparison between two containers of mismatched types is not working because I can't get the SFINAE to compile... so comparing a flat_set against a vector, for instance, doesn't work.

Fortunately we only have flat_set used in operations? Otherwise I guess we need to add more types into GRAPHENE_OP_RESTRICTION_ARGUMENTS_VARIADIC.

The fee logic is very simple, just a flat op price plus a price per byte. I believe this structure is adequate, and its simplicity will significantly reduce the complexity of frontend development.

The front-end usually doesn't calculate fees by their own but simply calls get_required_fees API, the real work will still be done by the back end.

[nathanielhourt]

Equality comparison between two containers of mismatched types is not working because I can't get the SFINAE to compile... so comparing a flat_set against a vector, for instance, doesn't work.

Fortunately we only have flat_set used in operations? Otherwise I guess we need to add more types into GRAPHENE_OP_RESTRICTION_ARGUMENTS_VARIADIC.

Vectors are used in several operations. Mostly vector<char> though there are a few others. Comparing a vector to a flat_set is clumsy, so it doesn't need to work, but perhaps we should add some vectors to the legal restriction arguments...

Resolved

[nathanielhourt]

@MichelSantos has brought up an interesting point: the current spec/implementation does not really provide a way to restrict that a container field have only values selected from a defined list. The logical way to do this would be to allow the in predicate (any in the spec) to operate on a container type field as well as a scalar type field, to say "all values in the field must be in the argument". This could be done for the not_in predicate (none in the spec) as well, to say "no value in the field may be in the argument".

With a slightly loose interpretation of the wording, the spec supports this. Shall I add this functionality to the implementation?

[nathanielhourt]

Changes requested so far have been applied.

[pmconrad]

Shall I add this functionality to the implementation?

I tend to leaving this for a later release. Unsure though. I guess it's a small change only, but OTOH I can't imagine where it'd be useful.

[nathanielhourt]

Shall I add this functionality to the implementation?

I tend to leaving this for a later release. Unsure though. I guess it's a small change only, but OTOH I can't imagine where it'd be useful.

It is fairly straightforward to add, yeah. Michel was attempting to test a case where someone wants to set a custom authority that can appoint feed producers for an asset from an authorized list. I'm not sure how useful that is in real life, but it's an illustrative example.

[nathanielhourt]

I've added the specializations, but I can remove them if they are not desired.

[pmconrad]

Good job, thanks!

[sschiessl-bcp]

Awesome!

[jmjatlanta]

Compiled on Ubutntu 18.04 / Boost 1.65.1 / OpenSSL 1.1.1. chain_tests ran without errors. Code looks good.

[clockworkgr]

Yay!...this once lowly issue: #1061 led to this :)

Somewhat proud despite not actually having done much :D