Sometimes, in software architecture, a change that may seem small at the surface can have major impact further down. Today I started with a change at the surface for the coinZdense project that may or may not trickle down into major architecture changes.
In this post I discussed the initial setup for an application RC file for a blockchain project choosing to use the (future) CoinZdense libraries.
In this post, I want to discuss my ideas for this change and how they would reflect on projects using CoinZdense in the future.
Let's start with the HIVISH json from the previous iteration of the coinZdense design and see what is inconvenient about it.
{
"appname": "HIVEISH",
"hashlen": 32,
"otsbits": 5,
"heights" : [9, 9, 8],
"reserved": 12,
"hierarchy": {
"ACTIVE": {
"POSTING": {
"comment": {}
}
},
"recover_account": {}
},
"delegate_space": [
{
"name": "active",
"allocate": 38,
"reserved" : 5
},
{
"name": "posting"
},
{
"name": "rare",
"heights": [6, 6]
}
]
}
Moving from JSON to YAML
The first problem that is easy enough to fix is the use of JSON for configuration files. As is today the convention in a lot of projects, we switch to YAML. Here is the same configuration in YAML format.
---
appname: HIVEISH
hashlen: 32
otsbits: 5
heights:
- 9
- 9
- 8
reserved: 12
hierarchy:
ACTIVE:
POSTING:
comment: {}
recover_account: {}
delegate_space:
- name: active
allocate: 38
reserved: 5
- name: posting
- name: rare
heights:
- 6
- 6
In the above we see two different structures that in the implementation map into one, the hierarchy tree and the delegate_space array. While this division works great for mapping to code for CoinZdense, it isn't actually that easy on the brain, and next to that, the solution lacks a specific form of flexability that might not be optimal in usage. Because recover_account is at the same level in the hierarchy as ACTIVE, it gets all the same parameters that ACTIVE gets. This may not be either intuitive or sufficiently flexible.
The actual new YAML format
So let's see if we can fix it, first by defining a more flexible YAML format for the application RC file, and next by changing the design and the code to accept the expresiveness of the file format.
---
appname: HIVEISH
hashlen: 32
otsbits: 5
heights:
- 9
- 9
- 8
subkeys:
- typ: default
shared: 4096
- name: ACTIVE
allocated: 38
subkeys:
- typ: default
allocate: 0
shared: 4096
- name: POSTING
allocate: 128
shared: 4096
subkeys:
- typ: default
allocate: 0
shared: 4096
heights:
- 6
- 6
- name: comment
- name: recover_account
heights:
- 6
- 6
Let's discuss the updated RC format. The hierarchy and delegate_space sections have been replaced by the subkeys section.
default
The subkeys section is an array with at most one default objects followed by one or more subkey objects. The default object (typ : default) contains default values for all other objects. So if the default entry defines a shared field but s sub-key entry does not, then the sub-key will inherit the shared value from the default entry.
no more 'reserved'
Instead of the reserved field thar depicted the number of bits used to represent key space allocated for specific level sub-keys, we now have two fields: shared and allocated. Both are in actual numbers, not number of bits.
The reserved field depicts the minimum number of subkeys of this type that the parent key MUST be able to allocate regardless of other sub-key types allocated. The shared field depicts the number of subkeys of this type that could be allocated if
- Only sub-keys of this specific type are allocated
- The parent key isn't too close to exaustion from signing transactions to still allow this many sub keys to get signed.
heights
The heights field is no longer level defined. Different subkey types at the same level can now have different heigth field values. In the example, the OWNER/ACTIVE/POSTING keys all have heights 9/9/8
and both a comment and a recover_account key have a height of 6/6, eventhough ACTIVE and recover_account both live on the same level. While this may seem like a trivial change, this change is likely to have quite a deep impact on the actual implementation of coinZdense.
A more HIVE-ish RC file.
---
appname: HIVEISH
hashlen: 32
otsbits: 5
heights:
- 9
- 9
- 8
subkeys:
- typ: default
shared: 4096
heights:
- 6
- 6
- name: ACTIVE
allocated: 38
heights:
- 9
- 9
- 8
subkeys:
- typ: default
allocate: 0
shared: 4096
- name: POSTING
allocate: 128
shared: 4096
subkeys:
- typ: default
allocate: 0
shared: 4096
heights:
- 6
- 6
- name: vote
- name: comment
- name: delete_comment
- name: comment_options
- name: claim_reward_balance
- name: custom_json
subkeys:
- typ default
allocate: 0
shared: 128
heights:
- 6
- 6
- name: actifit
- name: sm
subkeys:
- typ: default
allocate: 0
shared: 128
heights:
- 5
- 5
- 4
- name: sm_find_match
- name: sm_start_match
- name: sm_cancel_match
- name: transfer
- name: transfer_to_vesting
- name: withdraw_vesting
- name: limit_order_create
- name: limit_order_cancel
- name: convert
- name: create_claimed_account
- name: claim_account
- name: account_update
- name: account_witness_vote
- name: account_witness_proxy
- name: custom
- name: request_account_recovery
- name: escrow_transfer
- name: escrow_dispute
- name: escrow_release
- name: escrow_approve
- name: transfer_to_savings
- name: transfer_from_savings
- name: cancel_transfer_from_savings
- name: delegate_vesting_shares
- name: recover_account
- name: change_recovery_account
- name: decline_voting_rights
- name: set_reset_account
Anyone familiar with the HIVE API will recognize a few of the items in this RC file. The structure of the file might even make sense.
It is easy to see that the above RC file could help determine that a POSTING key can do e vote transaction but isn't allowed to do a set_reset_account transaction. What however might not be directly evident is that it would be possible to create a set_reset_account sub-key that can only do a set_reset_account transaction. And the granularity doesn't need th stop there. Notice the custom_json operation? That operation is used bt multiple DApps, including in this example Splinterlands or sm. The nested hierarchy of the RC file,within the limits of 64 bit the key-space can create a sub-key that can only do splinterlands operations, or for example a sub-key that can only do a sm_cancel_match operation witin splinterlands custom_json operations.
Maybe this is a bit far feched right now in terms of granularity, but it is I think an importand demonstration of what the RC format could define. You can define keys that only can do specific operations.
It is important to note that a composite subkey should also be possible, but there are some caveatsas to deterministic subkey parameter determination. These caveat sneed to be worked out, and it is very much possible that an RC file could end up not allowing certin composites, or that certain composites would end up wastefull in terms of index space usage. That is something I still need to figure out. Let's say you want to create a composite subkey that can vote, do splinterlands operations, and do witness votes. What key attributes would the composite key get? I'm going to write an other blog post about that as soon as I figure out the best answer to that question.