Xahau: Architectural Philosophy
Is there an architectural philosophy that can guide modern cryptographic networks?
The Crypto Thinker
One of the characteristics that attracted me to Xahau in the first place, as a speculator, was the idea of a simplified layer one. One that has a compact, minimalist code base.
- One that has very few 'code collision' vectors.
- One that is light-weight and easily understood ... and taught.
- One that allows further human-designated complexities to arise in a dynamic fashion.
- One that allows the greatest flexibility of use case implementation.
It's a preference borne from the lessons of the web-based technologies and architectural approaches like the OSI model, which guides the construction of components for a communication system. In the OSI model, it is noted that the HTTP protocol, while considered an 'application layer', is merely an instrument of facilitation; not an instrument of implementation. In other words, it has a small set of techniques for request & response, and allows human-created applications above it to utilize its capabilities and implement them in support of the greatest variety of use cases.
OSI Web Model
The opposite of this would be for an application layer to try and 'code' an implementation geared for specific use cases, such as one for commerce; one for financial applications; one for publishing.
If that was the route chosen, we'd have many ways to interface with HTTP, or even separate 'Internets' and browser types.
Fortunately, the architects of the Interweb understood the necessity of maintaining a minimal, but flexible, application layer and allowing others to build on an empty canvas ... the empty canvas being the HTTP protocol, among others.
Xahau carries this overall concept into the world of cryptographic networks.
How?
In its integration of 'hook' smart contracts, it allows the complexities to be coded by individual developers. For example, Xahau allows individual account owners to install a smart contract that prevents all small-amount transactions, otherwise known as 'spam' transactions. In the XRP Ledger, the ability to reject small transactions would need to be added to the layer one protocol itself, using a system such as 'flags' or another approach.
This points to a fundamental, philosophical difference between the two networks; one network (Xahau) allows unlimited complexities to be added by developers via smart contracts, while the other (XRP Ledger) necessitates changing the core protocol.
Development Speed
Another important difference between these two overall approaches can be observed: one is much faster than the other in implementing code to address use cases.
Turbo Development Speed
in the case of Xahau, a developer does not have to 'wait' for community approval of an amendment to the core protocol to try something new. They can simply code a novel smart contract and experiment with an idea, rather than create a fresh branch of the XRP Ledger and propose an amendment and pull request.
Is this comparing apples to oranges?
Some readers may hesitate to nod in agreement with these conclusions, given the fact that one network is considered a smart contract network, and the other is not.
But that may, in fact, be the key difference that allows a simplified architectural approach.
Exceptions That Prove The Rule?
Even though Xahau follows this general approach, there are still changes that the core protocol needs, to address specific use cases. The most recent example of this is the implementation of the 'batch' amendment on the XRP Ledger. The use cases mentioned in the documentation include:
'Batch' Use Cases
And while some of this can be addressed by Xahau's ability to generate new transactions, triggered by hooks and their smart contracts, other requirements necessitate 'all or nothing' type of conditions - a.k.a. 'atomic' linking of related transactions, rather than sequential processing.
So this use case necessitates a change to the core protocol, noted by its lead technical proponent, Denis Angell:
Protocol Changes
Final Thoughts
The architectural philosophy of moving code complexities into smart contracts instead of core protocol changes is, whether intentional or not, a key differentiator between the Xahau network and its predecessor network, the XRP Ledger. This difference may result in more compact and efficient code at layer one, while facilitating a much faster response time to new use cases via smart contracts.
X>
Sources:
https://stackoverflow.com/questions/38596488/in-which-layer-is-http-in-the-osi-model
https://www.codecademy.com/article/osi-model-complete-guide-to-the-7-network-layers
Race Car Image: https://unsplash.com/photos/close-up-photography-of-mclaren-p1-b6f7WaA-NZk?utm_content=creditCopyText&utm_medium=referral&utm_source=unsplash
https://github.com/XRPLF/XRPL-Standards/discussions/162
https://github.com/XRPLF/XRPL-Standards/discussions/299