Protocols
Update 2021
All applications which interact with other Ⓐ applications do so through a defined Ⓐ protocol. ProtoDev is an application which assists in the development, testing and demonstration of DⒶ protocols.A protocol definition block describes valid data blocks which are communicated between defined actors for the possible functions (roles) defined in the protocol, like:
- Recording data
- Retrieving recorded data
- Querying available protocols / supported functions under those protocols
- Querying known contact addresses for other servers
- Required elements
- Optional elements
- Required relationships among elements
The first series of protocols are designated DⒶx, for "Development." DⒶ0 defines a minimal protocol for the roles of data writer client and server, and data reader client and server. ProtoDev includes a demonstration of modules which implement DⒶ0, DⒶ1 and DⒶ2; the latter add fields for communication of the the client unique identifier and a chain unique identifier.
Current thinking is to develop from these ultra simple protocols, defined as above, implementing in a way that builds from the protocol definition as much as possible for implementation so that when additions and modifications are made to the protocol for more complex functions, the implemenation of those functions can reuse the existing code wherever possible - being data driven from the protocol definition instead of copy-paste or similar.
Automated testing should also be possible based on protocol definitions, maybe not all testing, but at least the basics should be testable based on the definitions.
Blockchain implementations will treat protocol definitions as a kind of Genesis block, defining the rules for all blocks which follow in the chain. However, a protocol block might make reference to a parent block and definitions within the protocol block might reference the previous blockchain as a basis for value and other things active in the post-protocol definition blockchain.
The thinking now is to leave the protocol definition very flexible, but eventually settle on one good protocol that can serve a large number of use cases
*and an even larger number of independent blockchains serving the various use cases
, with a focus on open public blockchains which support the exchange of value. Cross-chain exchanges within a single protocol will be simpler, but if multiple protocols gain wide adoption, they can be expanded to recognize each other and perform secure cross-protocol cross-chain exchanges.Another direction for protocol development would be toward HAM radio and similar hobbies. Instead of open public chains for exchange of value, HAM chains could be closed
*Closed meaning: served, recorded and controlled by a select group or individual, while remaining publicly accessible.
public services, possibly for the exchange and publication of QSL cards, HOWTO guides, and similar data signed by the licensee who provides it.Existing protocol definition languages like Apache Thrift and Cap'n Proto or maybe Cozy might be thought of as inspirational, but still falling somewhat short of the descriptives that tell, for instance, how to calculate a hash or sequentiality requirements for successive timestamps.
Early thoughts
(now deprecated)Just as the basic Assign Onward protocol supports multiple types of cryptographic methods, demonstrating the ability to include new methods as needed
*For 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.*as 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*as 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*as 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,*takeover 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.
Assign Onward
6 July 2018
MIT License
Copyright (c) 2018 Assign Onward
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright (c) 2018 Assign Onward
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.