Ⓐ

Protocols

Note:

I'm leaning toward a re-vamp of the protocol description scheme away from strict levels and more toward a bit-field support / no support for various protocol features.

Early thoughts

Just as the basic Assign Onward protocol supports multiple types of cryptographic methods, demonstrating the ability to include new methods as needed
1For instance: to transition to quantum ready cryptography.
the protocol handler itself supports multiple protocols, demonstrating the path toward interoperability with future protocols. Some sense of the protocol development plan is found in the roadmap.

Ⓐ¹

The Ⓐ¹ protocol is a basic, single recorder protocol. Many optimizations are possible in a single recorder scenario, such as assumption that the chain never forks because there is a single entity responsible for maintaining it. This means that the block chain is guaranteed sequential, non-forking and non-merging - and that transactions recorded thereon can also be reliably sequenced, so that once recorded information like public key identities and shares received amounts can be referred to in the future by just a sequence number in a particular blockchain.
2as identified by the hash of the genesis block

Ⓐ²

Ⓐ² protocol expands to support multiple, possibly competing, block chain recorders. Temporary forks and later re-merges of the blockchain are anticipated, and as such many of the optimizations in Ⓐ¹ which assume no forking become invalid. No matter, when software supports both Ⓐ¹ and Ⓐ² protocols, all they need to do is determine which protocol applies
3as identified by declaration in the genesis block
and handle accordingly.

and many more

On the one hand, it would be nice to develop a single protocol to serve most use cases. On the other, it would be naïve to assume that a single protocol will set forth and optimally address all the myriad of presently unknown uses for lightweight blockchain impmementations. While it is entirely possible
4as demonstrated by Bitcoin
to develop a single blockchain and endlessly modify an develop it over the years, I believe it is also practical to develop replacement protocols which can start fresh and take over for existing protocols,
5takeover to happen on the merits of the new protocol, if it is a truly superior protocol then it should be able to overcome the inertia of the existing implementations and replace them.
particularly in an ecosystem where no single blockchain is attempting to rule the entire world.